4. PCEP

This section contains information on the following topics:

  1. Introduction to the Path Computation Element (PCE) Communication Protocol (PCEP)
  2. Base Implementation of Path Computation Elements (PCE)
  3. PCEP Session Establishment and Maintenance
  4. PCEP Parameters
  5. PCEP Support for RSVP-TE LSPs
  6. LSP Path Diversity and Bidirectionality Constraints
  7. Configuring RSVP-TE LSPs with PCEP Using the CLI
  8. PCEP Configuration Command Reference

4.1. Introduction to the Path Computation Element (PCE) Communication Protocol (PCEP)

Note:

The 7705 SAR operates as a PCE Client (PCC) only, supporting PCC capabilities for RSVP-TE LSPs. References to PCE router operation and SR-TE LSPs apply to the 7750 SR product family and are included for informational purposes only.

The Path Computation Element Communication Protocol (PCEP) is one of several protocols used for communication between a wide area network (WAN) software-defined network (SDN) controller and network elements.

The Nokia WAN SDN Controller is known as the Network Services Platform (NSP). The NSP is a set of applications which are built on a common framework that hosts and integrates them by providing common functions. The applications are developed in a Java environment.

The NSP provides two major functions:

  1. programmable multi-vendor service provisioning
  2. network resource control, including resource management at Layer 0 (optical path), Layer 1 (ODU path), Layer 2 (MPLS tunnel), and at the IP flow level

The network discovery and control function implements a common set of standards-based southbound interfaces to the network elements for both topology discovery and tunnel and flow programming. A virtual 7705 SAR (vSAR) applies the southbound interfaces to the network elements and the adaptation layer to the applications. The southbound interfaces include IGP and the Network Functions Manager - Packet (NFM-P) for topology discovery, PCEP for handling path computation requests and LSP state updates with the network elements, and forwarding plane programming protocols such as Openflow, BGP flowspec, and I2RS.

The above NSP functions are provided in a number of modules that can be used together or separately as illustrated in Figure 14.

Figure 14:  NSP Functional Modules 

The two main components of the NSP are:

  1. Network Services Director (NSD)
    The NSD is a programmable and multi-vendor service provisioning tool providing a single and simple API to the user and OSS. It implements a service model abstraction and adapts to each vendor-specific service model. It supports provisioning services such as E-Line, E-LAN, E-Tree, Layer 3 VPN, traffic steering, and service chaining.
  2. Network Resource Controller (NRC)
    The NRC implements separate modules for computing and managing optimal paths for optical tunnels (NRC-T) and MPLS tunnels (NRC-P), and for computing optimal routing and placement of IP flows (NRC-F). In addition, a resource controller for inter-layer IP and optical path computation and more complex inter-domain MPLS path computation is provided as part of the NRC-X.

The Network Resource Controller - Packet (NRC-P) implements the stateful Path Computation Element (PCE) for packet networks. Figure 15 illustrates the NRC-P architecture and its main components.

Figure 15:  NRC-P Architecture 

The NRC-P has the following architecture:

  1. a single Virtual Machine (VM) handling the Java implementation of an MPLS path computation engine, a TE graph database, and an LSP database
  2. a plug-in adapter with the Nokia CPROTO interface, providing reliable, TCP-based message delivery between vSAR and Java-VM. The plug-in adapter implements a compact encoding/decoding (codec) function for the message content using Google ProtoBuf. Google ProtoBuf also provides for automatic C++ (vSAR side) and Java (Java-VM side) code generation to process the exchanged message content.
  3. a single VM running a vSAR image that handles the functions of topology discovery of multiple IGP instances and areas via IGP and NFM-P. For larger network domains, one VM running the vSAR image can be dedicated to a specific function.

The PCE module uses PCEP to communicate with its PCE Clients (PCCs). It also uses PCEP to communicate with other PCEs to coordinate inter-domain path computation. Each router acting as a PCC initiates a PCEP session to the PCE in its domain.

When the user enables PCE control for one or more segment routing (SR) or RSVP-TE LSPs, the PCE owns the path updating and periodic reoptimization of the LSPs. In this case, the PCE acts in an active stateful role. The PCE can also act in a passive stateful role for other LSPs on the router by discovering the LSPs and taking into account their resource consumption when computing the path for the LSPs it has control ownership of.

The following is a high-level description of the PCE and PCC capabilities:

  1. base PCEP implementation, as per RFC 5440
  2. active and passive stateful PCE LSP update, as per draft-ietf-pce-stateful-pce
  3. delegation of LSP control to the PCE
  4. synchronization of the LSP database with network elements for PCE-controlled LSPs and network element-controlled LSPs
  5. support for PCC-initiated LSPs, as per draft-ietf-pce-stateful-pce
  6. support for LSP path diversity across different LERs using extensions to the PCE path profile, as per draft-alvarez-pce-path-profiles
  7. support for LSP path bidirectionality constraints using extensions to the PCE path profile, as per draft-alvarez-pce-path-profiles

4.2. Base Implementation of Path Computation Elements (PCE)

The base implementation of the PCE uses the PCEP extensions defined in RFC 5440.

The main functions of PCEP are:

  1. PCEP session establishment, maintenance, and closing
  2. path computation requests using the PCReq message
  3. path computation replies using the PCRep message
  4. notification messages (PCNtf) by which the PCEP speaker can inform its peer about events, such as path request cancellation by the PCC or path computation cancellation by the PCE
  5. error messages (PCErr) by which the PCEP speaker can inform its peer about errors related to processing requests, message objects, or TLVs

Table 29 lists the base PCEP TLVs, objects, and messages.

Table 29:  Base PCEP TLVs, Objects, and Messages 

TLV, Object, or Message

Contained in Object

Contained in Message

OPEN Object

N/A

OPEN, PCErr

Request Parameter (RP) Object

N/A

PCReq, PCRep, PCErr, PCNtf

NO-PATH Object

N/A

PCRep

END-POINTS Object

N/A

PCReq

BANDWIDTH Object

N/A

PCReq, PCRep, PCRpt 1

METRIC Object

N/A

PCReq, PCRep, PCRpt 1

Explicit Route Object (ERO)

N/A

PCRep

Reported Route Object (RRO)

N/A

PCReq

LSPA Object

N/A

PCReq, PCRep, PCRpt 1

Include Route Object (IRO)

N/A

PCReq, PCRep

SVEC Object

N/A

PCReq

NOTIFICATION Object

N/A

PCNtf

PCEP-ERROR Object

N/A

PCErr

LOAD-BALANCING Object

N/A

PCReq

CLOSE Object

N/A

CLOSE

    Note:

  1. Nokia proprietary

The behavior and limitations of the implementation of the objects in Table 29 are as follows.

  1. The PCE treats all supported objects received in a PCReq message as mandatory, regardless of whether the P-flag in the object’s common header is set (mandatory object) or not (optional object).
  2. The PCC implementation will always set the B-flag (B=1) in the metric object containing the hop metric value, which means that a bound value must be included in PCReq message. The PCE returns the computed value in the PCRep message with flags set identically to the PCReq message.
  3. The PCC implementation will always set flags B=0 and C=1 in the metric object for the IGP or TE metric values in the PCReq message. This means that the request is to optimize (minimize) the metric without providing a bound value. The PCE returns the computed value in the PCRep message with flags set identically to the PCReq message.
  4. The IRO and LOAD-BALANCING objects are not part of the NSP PCE feature. If the PCE receives a PCReq message with one or more of these objects, it will ignore them regardless of the setting of the P-flag, and will process the path computations normally.
  5. The LSPA, metric, and bandwidth objects are also included in the PCRpt message. The inclusion of these objects in the PCRpt message is proprietary to Nokia.

The following features are not supported on the 7705 SAR:

  1. PCE discovery using IS-IS, per RFC 5089, and OSPF, per RFC 5088, along with corresponding extensions for discovering stateful PCE, per draft-sivabalan-pce-disco-stateful
  2. security of the PCEP session using MD5 or TLS between PCEP peers
  3. PCEP synchronization optimization as per draft-ietf-pce-stateful-sync-optimizations
  4. support of end-to-end secondary backup paths for an LSP. PCE standards do not currently support an LSP container with multiple paths, and the PCE treats each request as a path with a unique PLSP-ID. It is up to the router to tie the two paths together to create 1:1 protection and to request path or SRLG diversity among them when it makes the request to the PCE.
  5. jitter, latency, and packet loss metrics support as per RFC 7471 and draft-ietf-isis-te-metric-extensions, and their use in the PCE metric object as per draft-ietf-pce-pcep-service-aware

4.3. PCEP Session Establishment and Maintenance

PCEP operates over TCP using destination TCP port 4189. The PCC always initiates the connection. When the user configures the PCEP local address and the peer address on the PCC, the PCC initiates a TCP connection to the PCE. When a connection is established, the PCC and PCE exchange OPEN messages, which initializes the PCEP session and exchanges the session parameters to be negotiated.

The PCC always checks first to determine if the remote PCE address is reachable out-of-band via the management port. If the remote address is not reachable, the PCC will try to reach the remote PCE address in-band. When the session comes up out-of-band, the system IP address is always used; the local address configured by the user is ignored and is only used for an in-band session.

A keepalive mechanism is used as an acknowledgment of the acceptance of the session within the negotiated parameters. It is also used as a maintenance function to detect whether or not the PCEP peer is still alive.

The negotiated parameters include the keepalive timer and the dead timer, and one or more PCEP capabilities such as support of stateful PCE and the LSP Path type.

The PCEP session initialization steps are illustrated in Figure 16.

Figure 16:  PCEP Session Initialization 

If the session to the PCE times out, the router acting as a PCC keeps the last successfully programmed path provided by the PCE until the session to the PCE is re-established. Any subsequent change to the state of an LSP is synchronized at the time the session is re-established.

When a PCEP session to a peer times out or closes, the rate at which the PCEP speaker attempts the establishment of the session is subject to an exponential back-off mechanism.

4.4. PCEP Parameters

The following PCEP parameters are user-configurable on the PCC:

  1. keepalive timer
    A PCEP speaker must send a keepalive message if no other PCEP message is sent to the peer at the expiry of this timer. This timer is restarted every time a PCEP message is sent or the keepalive message is sent.
    The keepalive mechanism is asymmetric, meaning that each peer can use a different keepalive timer value.
    The range of this timer is 1 to 255 seconds and the default value is 30 seconds.
  2. dead timer
    This timer tracks the amount of time a PCEP speaker waits after the receipt of the last PCEP message before declaring its peer down.
    The dead timer mechanism is asymmetric, meaning that each PCEP speaker can propose a different dead timer value to its peer to use to detect session timeouts.
    The range of this timer is 1 to 255 seconds and the default value is 120 seconds.
  3. maximum rate of unknown messages
    When the rate of received unrecognized or unknown messages reaches the configured limit, the PCEP speaker closes the session to the peer.
    The range of this message rate is 1 to 255 messages per minute and the default value is 10 messages per minute.
  4. session reestablishment and state timeout
    If the PCEP session to the PCE goes down, all delegated PCC-initiated LSPs have their state maintained in the PCC and are not timed out. The PCC continues to try re-establishing the PCEP session. When the PCEP session is re-established, the LSP database is synchronized with the PCE database, and any LSP that went down since the last time the PCEP session was up has its path updated by the PCE.

4.4.1. PCC Configuration

The following PCC parameters can be modified while the PCEP session is operational:

  1. report-path-constraints
  2. unknown-message-rate

The following PCC parameters cannot be modified while the PCEP session is operational:

  1. local-address
  2. keepalive
  3. dead-timer
  4. peer (regardless of shutdown state)

4.4.2. Stateful PCE

The main function introduced by stateful PCE over the base PCE implementation is the ability to synchronize the LSP state between the PCC and the PCE. This allows the PCE to have all the required LSP information to perform reoptimization and updating of the LSP paths.

Table 30 describes the TLVs, objects, and messages supported by stateful PCE on the 7705 SAR.

Table 30:  PCEP Stateful PCE Extension TLVs, Objects, and Messages 

TLV, Object, or Message

Contained in Object

Contained in Message

Path Computation State Report (PCRpt)

N/A

New message

Path Computation Update Request (PCUpd)

N/A

New message

STATEFUL-PCE-CAPABILITY TLV

OPEN

OPEN

Stateful Request Parameter (SRP) Object

N/A

PCRpt 1, PCErr

LSP Object

ERO

PCRpt 1, PCReq, PCRep

LSP-IDENTIFIERS TLV

LSP

PCRpt 1

SYMBOLIC-PATH-NAME TLV

LSP, SRP

PCRpt 1

LSP-ERROR-CODE TLV

LSP

PCRpt 1

RSVP-ERROR-SPEC TLV

LSP

PCRpt 1

    Note:

  1. Nokia proprietary

The behavior and limitations of the implementation of the TLVs, objects, and messages in Table 30 are as follows.

  1. The PCC and PCE support all PCEP capability TLVs defined in this document and will always advertise them. If the OPEN object received from a PCEP speaker does not contain one or more of the capabilities, the PCE or PCC will not use them during that specific PCEP session.
  2. The PCC always includes the LSP object in the PCReq message to make sure that the PCE can correlate the PLSP-ID for this LSP when a subsequent PCRpt message arrives with the delegation bit set. The PCE will, however, still honor a PCReq message without the LSP Object.
  3. PCE path computation will only consider the bandwidth used by LSPs in its LSP-DB. As a result, there are two situations where PCE path computation will not accurately take into account the bandwidth used in the network:
    1. when there are LSPs that are signaled by the routers but are not synchronized with the PCE. The user can enable the reporting of the LSP to the PCE LSP database for each LSP.
    2. when the stateful PCE is peering with a third-party stateless PCC, implementing only the original RFC 5440. While the PCE will be able to bring the PCEP session up, the LSP database will not be updated, because stateless PCC does not support the PCRpt message. Therefore, PCE path computation will not accurately take into account the bandwidth used by these LSPs in the network.
  4. The PCE ignores the R-flag (reoptimize flag) in the PCReq message when acting in passive stateful mode for an LSP and will always return the newly computed path, regardless whether it is link-by-link identical or has the same metric as the current path. The decision whether to initiate the new path in the network belongs to the PCC.
  5. The synchronization vector (SVEC) object is not supported on the 7705 SAR and the NSP. If the PCE receives a PCReq message with the SVEC object, it will ignore the SVEC object and treat each path computation request in the PCReq message as independent, regardless of the setting of the P-flag in the SVEC object common header.
  6. When an LSP is delegated to the PCE, there may be no prior state in the NRC-P LSP database for the LSP. This could be due to the PCE not having received a PCReq message for the same PLSP-ID. In order for the PCE to become aware of the original constraints of such an LSP, the following additional procedures are performed. These procedures are proprietary to Nokia.
    1. The PCC appends a duplicate of each of the LSPA, metric, and bandwidth objects in the PCRpt message. The only difference between the two objects of the same type is that the P-flag is set in the common header of the duplicate object to indicate a mandatory object for processing by the PCE.
    2. The value of the metric or bandwidth in the duplicate object contains the original constraint value, while the first object contains the operational value. This is applicable to hop metrics in the metric object and bandwidth object only. The 7705 SAR PCC does not support putting a bound value on the IGP or TE metric in the path computation.
    3. The path computation on the PCE uses the first set of objects when updating a path if the PCRpt message contains a single set. If the PCRpt message contains a duplicate set, PCE path computation must use the constraints in the duplicate set.
    4. For interoperability, implementations compliant with PCEP standards should be able to accept the first metric object and ignore the second object without additional error handling. Because there are also bandwidth and LSPA objects, the [no] report-path-constraints command is provided in the PCC on a per-PCEP session basis to disable the inclusion of the duplicate objects. Duplicate objects are included by default.

4.4.3. LSP Initiation

An LSP that is configured on the router is referred to as a PCC-initiated LSP. An LSP that is not configured on the router, but is instead created by the PCE at the request of an application or a service instantiation, is referred to as a PCE-initiated LSP.

The 7705 SAR supports three modes of operation for PCC-initiated LSPs, which are configurable on a per-LSP basis:

  1. PCC-initiated and PCC-controlled
    When the path of the LSP is computed and updated by the router acting as a PCE Client (PCC), the LSP is referred to as PCC-initiated and PCC-controlled.
    A PCC-initiated and PCC-controlled LSP has the following characteristics:
    1. The LSP can contain strict or loose hops, or a combination of both.
    2. CSPF is supported for RSVP-TE LSPs. Local path computation takes the form of hop-to-label translation for LSPs.
    3. LSPs can be reported to synchronize the LSP database of a stateful PCE server using the pce-report option. In this case, the PCE acts in passive stateful mode for this LSP. The LSP path cannot be updated by the PCE. The control of the LSP is maintained by the PCC.
  2. PCC-initiated and PCE-computed
    When the path of the LSP is computed by the PCE at the request of the PCC, it is referred to as PCC-initiated and PCE-computed.
    A PCC-initiated and PCE-computed LSP has the following characteristics:
    1. The pce-computation option must be enabled for the LSP so that the PCE can perform path computation at the request of the PCC only. The PCC retains control.
    2. LSPs can be reported to synchronize the LSP database of a stateful PCE server using the pce-report option. In this case, the PCE acts in passive stateful mode for this LSP.
  3. PCC-initiated and PCE-controlled
    When the path of the LSP is updated by the PCE following a delegation from the PCC, it is referred to as PCC-initiated and PCE-controlled.
    A PCC-initiated and PCE-controlled LSP has the following characteristics:
    1. The pce-control option must be enabled for the LSP so that the PCE can perform path updates following a network event without an explicit request from the PCC. The PCC delegates full control.
    2. The pce-report option must be enabled for LSPs that cannot be delegated to the PCE. The PCE acts in active stateful mode for this LSP.

4.4.4. PCC-Initiated and PCE-Computed or PCE-Controlled LSPs

The following is the procedure for configuring and programming a PCC-initiated LSP when control is delegated to the PCE.

  1. The LSP configuration is created on the PE router via CLI or via the OSS/NSP NFM-P.
    The configuration dictates which PCE control mode is desired: active (pce-control and pce-report options enabled) or passive (pce-computation enabled and pce-control disabled).
  2. PCC assigns a unique PLSP-ID to the LSP. The PLSP-ID uniquely identifies the LSP on a PCEP session and must remain constant during its lifetime. PCC on the router must keep track of the association of the PLSP-ID to the Tunnel-ID and Path-ID, and use the latter to communicate with MPLS about a specific path of the LSP. PCC also uses the SRP-ID to correlate PCRpt messages for each new path of the LSP.
  3. The PE router does not validate the entered path. Note however that in the 7705 SAR OS, the PCE supports the computation of a path for an LSP with empty-hops in its path definition. While PCC will include the IRO objects in the PCReq message to PCE, the PCE will ignore them and compute the path with the other constraints except the IRO.
  4. The PE router sends a PCReq message to the PCE to request a path for the LSP, and includes the LSP parameters in the METRIC object, the LSPA object, and the BANDWIDTH object. The PE router also includes the LSP object with the assigned PLSP-ID. At this point, the PCC does not delegate the control of the LSP to the PCE.
  5. The PCE computes a new path, reserves the bandwidth, and returns the path in a PCRep message with the computed ERO in the ERO object. It also includes the LSP object with the unique PLSP-ID, the METRIC object with any computed metric value, and the BANDWIDTH object.
    Note:

    For the PCE to be able to use the SRLG path diversity and admin-group constraints in the path computation, the user must configure the SRLG and admin-group membership against the MPLS interface and make sure that the traffic-engineering option is enabled in IGP. This causes IGP to flood the link SRLG and admin-group membership in its participating area, and for PCE to learn it in its TE database.

  6. The PE router updates the CPM and the data path with the new path.
    Up to this point, the PCC and PCE are using passive stateful PCE procedures. The next steps will synchronize the LSP database of the PCC and PCE for both PCE-computed and PCE-controlled LSPs. They will also initiate the active PCE stateful procedures for the PCE-controlled LSP only.
  7. The PE router sends a PCRpt message to update the PCE with an UP state, and also sends the RRO as confirmation. It now includes the LSP object with the unique PLSP-ID. For a PCE-controlled LSP, the PE router also sets the delegation control flag to delegate control to the PCE. The state of the LSP is now synchronized between the router and the PCE.
  8. Following a network event or a reoptimization, the PCE computes a new path for a PCE-controlled LSP and returns it in a PCUpd message with the new ERO. It will include the LSP object with the same unique PLSP-ID assigned by the PCC, as well as the Stateful Request Parameter (SRP) object with a unique SRP-ID-number to track error and state messages specific to this new path.
  9. The PE router updates the CPM and the data path with the new path.
  10. The PE router sends a PCRpt message to inform the PCE that the older path is deleted. It includes the unique PLSP-ID value in the LSP object and the R (Remove) bit set.
  11. The PE router sends a new PCRpt message to update PCE with an UP state, and also sends the RRO to confirm the new path. The state of the LSP is now synchronized between the router and the PCE.
  12. If PCE owns the delegation of the LSP and is making a path update, MPLS will initiate the LSP and update the operational value of the changed parameters while the configured administrative values will not change. Both the administrative and operational values are shown in the details of the LSP path in MPLS.
  13. If the user makes any configuration change to the PCE-computed or PCE-controlled LSP, MPLS requests that the PCC first revoke delegation in a PCRpt message (PCE-controlled only), and then MPLS and PCC follow the above steps to convey the changed constraint to PCE which will result in the programming of a new path into the data path, the synchronization of the PCC and PCE LSP databases, and the return of delegation to PCE.

The above procedure is followed when the user performs a no shutdown command on a PCE-controlled or PCE-computed LSP. The starting point is an LSP which is administratively down with no active path. For an LSP with an active path, the following items may apply:

  1. If the user enabled the pce-computation option on a PCC-controlled LSP with an active path, no action is performed until the next time the router needs a path for the LSP following a network event of a LSP parameter change. At that point, the prior procedure is followed.
  2. If the user enabled the pce-control option on a PCC-controlled or PCE-computed LSP with an active path, the PCC will issue a PCRpt message to the PCE with an UP state, as well as the RRO of the active path. It will set the delegation control flag to delegate control to the PCE. The PCE will keep the active path of the LSP and make no updates to it until the next network event or reoptimization. At that point, the prior procedure is followed.

4.5. PCEP Support for RSVP-TE LSPs

This section describes the support of PCC-initiated RSVP-TE LSPs. PCEP support of an RSVP-TE LSP is described in LSP Initiation with the following differences:

  1. each primary and secondary path is assigned its own unique path LSP-ID (PLSP-ID)
  2. the PCC indicates to the PCE the state of each path (either up or down) and which path is currently active and carrying traffic (active state)

This section includes the following topics:

  1. RSVP-TE LSP Configuration for a PCC Router
  2. Behavior of the LSP Path Update
  3. Behavior of LSP MBB
  4. Behavior of Secondary LSP Paths
  5. PCE Path Profile Support

4.5.1. RSVP-TE LSP Configuration for a PCC Router

The following MPLS-level and LSP-level CLI commands are used to configure RSVP-TE LSPs in a router acting as a PCEP Client (PCC). See MPLS and RSVP-TE Command Reference for command descriptions.

  1. config>router>mpls>
         pce-report rsvp-te {enable | disable}
  2. config>router>mpls>lsp>
         path-profile profile-id [path-group group-id]
         pce-computation
         pce-control
         pce-report {enable | disable | inherit}
  3. config>router>mpls>lsp-template
         pce-report {enable | disable | inherit}

The cspf option must be enabled on the LSP before enabling the pce-computation or pce-control options. An attempt to disable the cspf option on an RSVP-TE LSP that has the pce-computation or pce-control options enabled will be rejected.

If the LSP has disabled PCE reporting, either due to inheritance from the MPLS-level configuration or due to LSP-level configuration, enabling the pce-control option for the LSP has no effect. To help troubleshoot this situation, the output of the show commands for the LSP displays the operational values of both the pce-report and pce-control options.

Note:

The PCE function implemented in the NSP and referred to as the NRC-P, supports only Shared Explicit (SE) style bandwidth management for RSVP-TE LSPs. The PCEP does not support the ability of the PCC to convey this value to the PCE. Therefore, whether the LSP configuration option rsvp-resv-style is set to se or ff, the PCE will always use the SE style in the CSPF computation of the path for a PCE-computed or PCE-controlled RSVP-TE LSP.

A one-hop-p2p or a mesh-p2p RSVP-TE auto-lsp only supports the pce-report command in the LSP template:

  1. config>router>mpls>lsp-template>
         pce-report {enable | disable | inherit}

The user must first shut down the LSP template before changing the value of the pce-report option.

A manual bypass LSP does not support any of the PCE-related commands. Reporting a bypass LSP to the PCE is not required because the bypass LSP does not book bandwidth.

All other MPLS, LSP, and path-level commands are supported, with the exception of the following commands:

  1. least-fill
  2. srlg (on secondary standby path)

For more information on RSVP-TE PCC instantiation modes, see LSP Initiation.

4.5.2. Behavior of the LSP Path Update

When the pce-control option is enabled, the PCC delegates control of the RSVP-TE LSP to the PCE.

The NRC-P sends a path update using the PCUpd message in the following cases:

  1. a failure event that impacts a link or a node in the path of a PCE-controlled LSP
    The operation is performed by the PCC as a Make-Before-Break (MBB) if the LSP remained in the up state due to protection provided by FRR or a secondary path. If the LSP went down, the update brings it into the up state. A PCRpt message is sent by the PCC for each change to the state of the LSP during this process. See Behavior of LSP MBB for more information.
  2. a topology change that impacts a link in the path of a PCE-controlled LSP
    This topology change can be a change to the IGP metric, the TE metric, admin-group, or SRLG membership of an interface. This update is performed as an MBB by the PCC.
  3. the user performed a manual resignal of a PCE-controlled RSVP-TE LSP path from the NRC-P
    This update is performed as an MBB by the PCC.
  4. the user performed a Global Concurrent Optimization (GCO) on a set of PCE-controlled RSVP-TE LSPs from the NRC-P
    This update is performed as an MBB by the PCC.

The procedures for the path update are described in LSP Initiation. However, for an RSVP-TE LSP, the PCUpd message from the PCE contains the interface IP address or system IP address in the computed ERO. The PCC signals the path using the ERO returned by the PCE and, if successful, programs the data path, then sends the PCRpt message with the resulting RRO and hop labels provided by RSVP-TE signaling.

If the signaling of the ERO fails, the ingress LER returns a PCErr message to the PCE with the LSP Error code field of the LSP-ERROR-CODE TLV set to a value of 8 (RSVP signaling error).

If an RSVP-TE LSP has the no adaptive option set, the ingress LER cannot perform an MBB for the LSP. A PCUpd message received from the PCE is then failed by the ingress LER, which returns a PCErr message to the PCE with the LSP Error code field of the LSP-ERROR-CODE TLV set to a value of 8 (RSVP signaling error).

4.5.2.1. Path Update with Empty ERO

When the NRC-P reoptimizes the path of a PCE-controlled RSVP-TE LSP, it is possible that a path that satisfies the constraints of the LSP no longer exists. In this case, the NRC-P sends a PCUpd message with an empty ERO, which forces the PCC to bring down the path of the RSVP-TE LSP.

The NRC-P sends a PCUpd message with an empty ERO if any of the following cases are true:

  1. the requested bandwidth is the same as the current bandwidth, which avoids bringing down the path due to a resignal during an MBB transition
  2. local protection is not currently in use, which avoids bringing down a path that activated an FRR backup path. The LSP can remain on the FRR backup path until a new primary path can be found by the NRC-P.
  3. the links of the current path are all operationally up, which allows the NRC-P to ensure that the RSVP control plane will report the path down when a link is down and not prematurely bring the path down with an empty ERO

4.5.3. Behavior of LSP MBB

In addition to the MBB support when the PCC receives a path update, as described in Behavior of the LSP Path Update, an RSVP-TE LSP supports the MBB procedure for any parameter configuration change, including the PCEP-related commands when they result in a change to the path of the LSP.

If the user adds or modifies the path-profile command for an RSVP-TE LSP, a config change MBB is only performed if the pce-computation, pce-report, or pce-control options are enabled on the LSP. Otherwise, no action occurs. When pce-computation, pce-report, or pce-control are enabled on the LSP, the path update MBB (tools>perform>router>mpls>update-path) fails, resulting in no operation.

MBB is also supported for the manual resignal and auto-bandwidth MBB types.

When the LSP goes into an MBB state at the ingress LER, the behavior is dependent on the operating mode of the LSP.

This section contains information on the following LSP MBB procedures:

  1. PCC-Controlled LSPs
  2. PCE-Computed LSPs
  3. PCE-Controlled LSPs

4.5.3.1. PCC-Controlled LSPs

All MBB types are supported for PCC-controlled LSPs. The LSP MBB procedures for a PCC-controlled LSP (pce-computation and pce-control disabled) are as follows.

  1. MPLS submits a path request, including the updated path constraints, to the local CSPF.
  2. If the local CSPF returns a path, the PCC signals the LSP with the RSVP control plane and moves traffic to the new MBB path. If pce-report is enabled for this LSP, the PCC sends a PCRpt message with the delegation bit clear to retain control and containing the RRO and LSP objects, with the LSP-IDENTIFIERS TLV containing the LSP-ID of the new MBB path. The message includes the metric, LSPA, and bandwidth objects where the P-flag is clear, which indicates the operational values of these parameters. Unless the user disables the report-path-constraints option under the pcc context, the PCC also includes a second set of metric, LSPA, and bandwidth objects with the P-flag set to convey to the PCE the constraints of the path.
  3. If the CSPF returns no path or the RSVP-TE signaling of the returned path fails, MPLS puts the LSP into retry mode and sends a request to the local CSPF every retry-timer seconds and up to the value of retry-count.
  4. When pce-report is enabled for the LSP and the FRR global revertive MBB is triggered following a bypass LSP activation by a PLR in the network, the PCC issues an updated PCRpt message with the new RRO reflecting the PLR and RRO hops. The PCE releases the bandwidth on the links that are no longer used by the LSP path.

4.5.3.2. PCE-Computed LSPs

All MBB types are supported for PCE-computed LSPs. The LSP MBB procedures for a PCE-computed LSP (pce-computation enabled and pce-control disabled) are as follows.

  1. The PCC issues a PCReq for the same PLSP-ID and includes the updated constraints in the metric, LSPA, and bandwidth objects.
    1. If the PCE successfully finds a path, it replies with a PCRep message with the ERO.
    2. If the PCE does not find a path, it replies with a PCRep message containing the No-Path object.
  2. If the PCE returns a path, the PCC signals the LSP with the RSVP control plane and moves traffic to the new MBB path. If pce-report is enabled for this LSP, the PCC sends a PCRpt message with the delegation D-bit clear to retain control and containing the RRO and LSP objects, with the LSP-IDENTIFIERS TLV containing the LSP-ID of the new MBB path. The message includes the metric, LSPA, and bandwidth objects where the P-flag is clear, which indicates the operational values of these parameters. Unless the user disables the report-path-constraints option under the pcc context, the PCC also includes a second set of metric, LSPA, and bandwidth objects with the P-flag set to convey to the PCE the constraints of the path.
  3. If the PCE returns no path or the RSVP-TE signaling of the returned path fails, MPLS puts the LSP into retry mode and sends a request to PCE every retry-timer seconds and up to the value of retry-count.
  4. When the pce-report is enabled for the LSP and the FRR global revertive MBB is triggered following a bypass LSP activation by a PLR in the network, the PCC issues an updated PCRpt message with the new RRO reflecting the PLR and RRO hops. The PCE releases the bandwidth on the links that are no longer used by the LSP path.
  5. If the user changes the RSVP-TE LSP configuration from pce-computation to no pce-computation, MBB procedures are not supported. In this case, the LSP path is torn down and is put into retry mode to compute a new path from the local CSPF on the router to signal the LSP.

4.5.3.3. PCE-Controlled LSPs

The LSP MBB procedures for a PCE-controlled LSP (pce-control enabled) are as follows.

Note:

Items 1 through 5 of the following procedure apply to the config change, manual resignal, and auto-bandwidth MBB types. The delayed retry MBB type used with the SRLG on secondary standby LSP feature is not supported with a PCE-controlled LSP. See Behavior of Secondary LSP Paths for information about the SRLG on secondary standby LSP feature.

  1. The PCC temporarily removes delegation by sending a PCRpt message for the corresponding path LSP-ID (PLSP-ID) with the delegation D-bit clear.
  2. For an LSP with pce-computation disabled, MPLS submits a path request to the local CSPF, which includes the updated path constraints.
  3. For an LSP with pce-computation enabled, the PCC issues a PCReq for the same PLSP-ID and includes the updated constraints in the metric, LSPA, or bandwidth objects.
    1. If the PCE successfully finds a path, it replies with a PCRep message with the ERO.
    2. If the PCE does not find a path, it replies with a PCRep message containing the No-Path object.
  4. If the local CSPF or the PCE returns a path, the PCC performs the following actions.
    1. The PCC signals the LSP with the RSVP control plane and moves traffic to the new MBB path. It then sends a PCRpt message with the delegation D-bit set to return delegation and containing the RRO and LSP objects, with the LSP-IDENTIFIERS TLV containing the LSP-ID of the new MBB path. The message includes the metric, LSPA, and bandwidth objects where the P-flag is clear, which indicates the operational values of these parameters. Unless the user disabled the report-path-constraints option under the pcc context, the PCC also includes a second set of metric, LSPA, or bandwidth objects with the P-flag set to convey to the PCE the constraints of the path.
    2. The PCC sends a PathTear message to delete the state of the older path in the network. The PCC then sends a PCRpt message to the PCE with the older path LSP (PLSP-ID) and the remove R-bit set to also have the PCE remove the state of that LSP from its database.
  5. If the local CSPF or the PCE returns no path or the RSVP-TE signaling of the returned path fails, the router makes no further requests. That is, there is no retry for the MBB.
    1. The PCC sends a PCErr message to the PCE with the LSP Error code field of the LSP-ERROR-CODE TLV set to a value of 8 (RSVP signaling error) if the MBB failed due to a RSVP-TE signaling error.
    2. The PCC sends a PCRpt message with the delegation D-bit set to return delegation and containing the RRO and LSP objects, with the LSP-IDENTIFIERS TLV containing the LSP-ID of the currently active path. The message includes the metric, LSPA, and bandwidth objects where the P-flag is clear to indicate the operational values of these parameters. Unless the user disabled the report-path-constraints option under the pcc context, the PCC also includes a second set of metric, LSPA, and bandwidth objects with the P-flag set to convey to the PCE the constraints of the path.
  6. The ingress LER takes no action in the case of a network event triggered MBB, such as FRR global revertive or TE graceful shutdown.
    1. The ingress PE keeps the information as required and sets the state of MBB to one of the FRR global revertive or TE graceful shutdown MBB values but does not perform the MBB action.
    2. The NRC-P computes a new path for the global revertive MBB due to a failure event. This computation uses the PCUpd message to update the path using the MBB procedure described in Behavior of the LSP Path Update. The activation of a bypass LSP by a point of local repair (PLR) in the network causes the PCC to issue an updated PCRpt message with the new RRO reflecting the PLR and RRO hops. The PCE will release the bandwidth on the links that are no longer used by the LSP path.
    3. The NRC-P computes a new path for the TE graceful shutdown MBB if the RSVP-TE is using the TE metric, because the TE metric of the link in TE graceful shutdown is set to infinity. This computation uses the PCUpd message to update the path using the MBB procedure described in Behavior of the LSP Path Update.
    4. The NRC-P does not act on the TE graceful shutdown MBB if the RSVP-TE is using the IGP metric; however, the user can perform a manual resignal of the LSP path from the NRC-P to force a new path computation, which accounts for the newly available bandwidth on the link that caused the MBB event. This computation uses the PCUpd message to update the path using the MBB procedure described in Behavior of the LSP Path Update.
    5. The user can perform a manual resignal of the LSP path from the ingress LER, which forces an MBB for the path as per the remove-delegation/MBB/return-delegation procedures described in this section.
    6. If the user performs no pce-control while the LSP still has the state for any of the network event triggered MBBs, the MBB is performed immediately by the PCC as described in the procedures in PCE-Computed LSPs for a PCE-computed LSP and as described in the procedures in PCC-Controlled LSPs for a PCC-controlled LSP.
  7. The timer-based manual resignal MBB behaves like the TE graceful shutdown MBB. The user can perform a manual resignal of the LSP path from the ingress LER or from the PCE.
  8. The path update MBB (tools>perform>router>mpls>update-path) fails, which results in no operation. This is true in all cases when the RSVP-TE LSP enables the pce-report option.

4.5.4. Behavior of Secondary LSP Paths

Each of the primary, secondary standby, and secondary non-standby paths of the same LSP must use a separate path LSP-ID (PLSP-ID). The PCE function of the NSP, the NRC-P, checks the LSP-IDENTIFIERS TLV in the LSP object and can identify which PLSP-IDs are associated with the same LSP or the same RSVP-TE session. The parameters are the IPv4 Tunnel Sender Address, the Tunnel ID, the Extended Tunnel ID, and the IPv4 Tunnel Endpoint Address. This approach allows the use of all the PCEP procedures for all three types of LSP paths.

The PCC indicates to the PCE the following states for the path in the LSP object: down, up (signaled but not carrying traffic), or active (signaled and carrying traffic).

The PCE tracks active paths and displays them in the NSP GUI. It also provides only the tunnel ID of an active PLSP-ID to a destination prefix when a request is made by a service or a steering application.

The PCE recomputes the paths of all PLSP-IDs that are affected by a network event. The user can select each path separately on the NSP GUI and trigger a manual resignal of one or more paths of the RSVP-TE LSP.

Note:

Enabling the srlg option on a secondary standby path results in no operation. The NRC-P supports link and SRLG disjointness using the PCE path profile. The user can apply the PCE path profile to the primary and secondary paths of the same LSP. See PCE Path Profile Support for more information.

4.5.5. PCE Path Profile Support

The PCE path profile ID and path group ID are configured at the LSP level (config>router>mpls>lsp>path-profile).

The NRC-P can enforce path disjointness and bidirectionality among a pair of forward and a pair of reverse LSP paths. Both pairs of LSP paths must use a unique path group ID along with the same path profile ID.

When the user wants to apply path disjointness and path bidirectionality constraints to RSVP-TE LSP paths, it is important to follow the following guidelines. The user can configure the following sets of LSP paths:

  1. a set consisting of a pair of forward RSVP-TE LSPs and a pair of reverse RSVP-TE LSPs, each with a single primary or secondary path. The pair of forward LSPs can originate and terminate on different routers. The pair of reverse LSPs must mirror the forward pair. In this case, the path profile ID and the path group ID configured for each LSP must match. Because each LSP has a single path, the bidirectionality constraint applies automatically to the forward and reverse LSPs, which share the same originating node and the same terminating routers.
  2. a pair consisting of a forward RSVP-TE LSP and a reverse RSVP-TE LSP, each with a primary path and a single secondary path, or each with two secondary paths. Because the two paths of each LSP inherit the same LSP level path profile ID and path group ID configuration, the NRC-P path computation algorithm cannot guarantee that the primary paths in both directions meet the bidirectionality constraint. That is, it is possible that the primary path for the forward LSP shares the same links as the secondary path of the reverse LSP and vice-versa.

4.6. LSP Path Diversity and Bidirectionality Constraints

The PCE path profile defined in draft-alvarez-pce-path-profiles is used to request path diversity or a disjoint for two or more LSPs originating on the same or different PE routers. It is also used to request that paths of two unidirectional LSPs between the same two routers use the same TE links. This is referred to as the bidirectionality constraint.

Path profiles are defined by the user directly on the NRC-P Policy Manager with a number of LSP path constraints, which are metrics with upper bounds specified, and with an objective, which are metrics optimized with no bounds specified. The NRC-P Policy Manager allows the following PCE constraints to be configured within each PCE path profile:

  1. path diversity, node-disjoint, link-disjoint
  2. path bidirectionality, symmetric reverse route preferred, symmetric reverse route required
  3. maximum path IGP metric (cost)
  4. maximum path TE metric
  5. maximum hop count

The user can also specify which PCE objective to use to optimize the path of the LSP in the PCE path profile, one of:

  1. IGP metric (cost)
  2. TE metric
  3. hops (span)

The CSPF algorithm will optimize the objective. If a constraint is provided for the same metric, the CSPF algorithm ensures that the selected path achieves a lower or equal value to the bound value specified in the constraint.

For hop-count metrics, if a constraint is sent in a metric object and is also specified in a PCE profile referenced by the LSP, the constraint in the metric object is used.

For IGP and TE metrics, if an objective is sent in a metric object and is also specified in a PCE profile referenced by the LSP, the objective in the path profile is used.

The constraints in the bandwidth object and the LSPA object, specifically the include and exclude admin-group constraints and setup and hold priorities, are not supported in the PCE profile.

In order to indicate the path diversity and bidirectionality constraints to the PCE, the user must configure the profile ID and path group ID of the PCE path that the LSP belongs to. The CLI commands for this are described in Configuring RSVP-TE LSPs with PCEP Using the CLI. The path group ID does not need to be defined in the PCE as part of the path profile configuration and identifies implicitly the set of paths that must have the path diversity constraint applied.

The user can only associate a single path group ID with a specific PCE path profile ID for an LSP. However, the same path group ID can be associated with multiple PCE profile IDs for the same LSP.

The path profiles are inferred using the path ID in the path request by the PCC. When the PE router acting as a PCC wants to request path diversity from a set of other LSPs belonging to a path group ID value, it adds a new PATH-PROFILE object in the PCReq message. The object contains the path profile ID and the path group ID as an extended ID field. In other words, the diversity metric is carried in an opaque way from the PCC to the PCE.

The bidirectionality constraint operates the same way as the diversity constraint. The user can configure a PCE profile with both the path diversity and bidirectionality constraints. The PCE will check if there is an LSP in the reverse direction that belongs to the same path group ID as an originating LSP it is computing the path for, and will enforce the constraint.

In order for the PCE to be aware of the path diversity and bidirectionality constraints for an LSP that is delegated but for which there is no prior state in the NRC-P LSP database, the PATH-PROFILE object is included in the PCRpt message with the P-flag set in the common header to indicate that the object must be processed. This is proprietary to Nokia.

Table 31 describes the new objects and TLVs introduced in the PCE path profile.

Table 31:  PCEP Path Profile Extension Objects and TLVs 

TLV, Object, or Message

Contained in Object

Contained in Message

PATH-PROFILE-CAPABILITY TLV

OPEN

OPEN

PATH-PROFILE Object

N/A

PCReq, PCRpt 1

    Note:

  1. Nokia proprietary

A PATH-PROFILE object can contain multiple TLVs containing each profile ID and extend ID, and should be processed properly. If multiple PATH-PROFILE objects are received, the first object is interpreted and the others are ignored. The PCC and the PCE support all PCEP capability TLVs defined in this chapter and will always advertise them. If the OPEN object received from a PCEP speaker does not contain one or more of the capabilities, the PCE or PCC will not use them during that PCEP session.