4. PCEP

4.1. In This Chapter

This chapter provides information to configure MPLS and RSVP.

  1. Introduction to the Path Computation Element Protocol (PCEP)
    1. PCC and PCE Configuration
    2. Base Implementation of Path Computation Elements (PCE)
    3. PCEP Session Establishment and Maintenance
    4. PCEP Parameters
  2. PCEP Configuration Command Reference

4.2. Introduction to the Path Computation Element Protocol (PCEP)

The Path Computation Element Protocol (PCEP) is one of several protocols used for communication between a Wide-Area Network (WAN) Software-Define Networking (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 implements a common set of standards-based south-bound interfaces to the network elements for both topology discovery and tunnel and flow programming. It is a virtual SR OS (vSROS) image which applies the south-bound interfaces to the network elements and the adaptation layer to the applications. The south-bound interfaces include IGP and BGP-LS 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 which can be used together or separately as illustrated in Figure 53.

Figure 53:  NSP Functional Modules 

The two main features of the NSP are as follows:

  1. Network Services Director (NSD) — The NSD is a programmable and multi-vendor service provisioning tool exposing a single and simple API to the user and OSS. It implements service model abstraction and adapts to each vendor-specific service model. It supports provisioning services such as ELINE, ELAN, ETREE, L3 VPN, traffic steering, and service chaining.
  2. Network Resource Controller (NRC) — The NRC implements a separate module 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 NRC-P implements the stateful Path Computation Element (PCE) for packet networks. Figure 54 illustrates the NRC-P architecture and its main components.

Figure 54:  Packet Network Resource Controller (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 vSROS 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++ (vSROS side) and Java (Java-VM side) code generation to process the exchanged message content.
  3. a single VM running a vSROS image handles the functions of topology discovery of multiple IGP instances and areas via IGP or BGP-LS and the PCE PCEP functions
  4. for larger network domains, one VM running the vSROS image can be dedicated to a specific function

The PCE module uses PCEP to communicate with its clients, such as the PCE Client (PCC). It also uses the 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 or RSVP LSPs, the PCE owns the path updating and periodic re-optimization of the LSP. In this case, the PCE acts in an active stateful role. The PCE can also act in a stateful passive role for other LSPs on the router by discovering them 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, per RFC 5440
  2. active and passive stateful PCE LSP update, as per draft-ietf-pce-stateful-pce
  3. delegation of LSP control to PCE
  4. synchronization of the LSP database with network elements for PCE-controlled LSPs and network element-controlled LSPs
  5. support for the SR-TE P2P LSP type, as per draft-ietf-pce-segment-routing
  6. support for PCC-initiated LSPs, as per draft-ietf-pce-stateful-pce
  7. support for LSP path diversity across different LERs using extensions to the PCE path profile, as per draft-alvarez-pce-path-profiles
  8. support for LSP path bi-directionality constraints using extensions to the PCE path profile, as per draft-alvarez-pce-path-profiles

4.2.1. PCC and PCE Configuration

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

  1. local-address
  2. keepalive
  3. dead-timer

The unknown-message-rate PCE parameter can be modified while the PCEP session is operational.

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)

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

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

4.2.2. Base Implementation of Path Computation Elements (PCE)

The base implementation of PCE uses the PCEP extensions defined in RFC 5440 [pce-pcep].

The main functions of the 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 PCC or path computation cancellation by 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 34 lists the messages and objects that are supported in SR OS Release 14.0.

Table 34:  Base PCEP Message Objects and TLVs 

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 34 are as follows:

  1. 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. PCE returns the computed value in PCRep with flags set identically to PCReq.
  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. PCE returns the computed value in PCRep with flags set identically to PCReq.
  4. The IRO and LOAD-BALANCING objects are not in 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. LSP path setup and hold priorities will be configurable during SR-TE LSP configuration on the router, and PCC will pass the configurations on in an LSPA object. However, PCE does not implement LSP pre-emption.
  6. 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 in the SR OS:

  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 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 PCE. This is not specific to PCE controlling an SR-TE LSP, but also to controlling an RSVP LSP.
  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.2.3. PCEP Session Establishment and Maintenance

The PCEP protocol operates over TCP using destination TCP port 4189. The PCC always initiates the connection. Once the user configures the PCEP local address and the peer address on the PCC, the PCC initiates a TCP connection to the PCE. Once 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 if the remote PCE address is reachable out-of-band via the management port. If not, it 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 keep-alive 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 DeadTimer, and one or more PCEP capabilities such as support of Stateful PCE and the SR-TE LSP Path type.

The PCEP session initialization steps are illustrated in Figure 55.

Figure 55:  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.2.4. PCEP Parameters

The following PCEP parameters are user-configurable on both the PCC and PCE. On the PCE, the configured parameter values are used on sessions to all PCCs.

  1. Keep-alive timer — A PCEP speaker (PCC or PCE) must send a keep-alive 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 keep-alive message is sent.
    The keep-alive mechanism is asymmetric, meaning that each peer can use a different keep-alive timer value.
    The range of this parameter is 1 to 255 seconds, and the default value is 30 seconds. The no version returns to the default value.
  2. Dead timer — This timer tracks the amount of time a PCEP speaker (PCC or PCE) 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 parameter is 1 to 255 seconds, and the default value is 120 seconds. The no version returns to the default value.
  3. Maximum rate of unknown messages — When the rate of received unrecognized or unknown messages reaches this limit, the PCEP speaker closes the session to the peer.
  4. Session re-delegation 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 will continue to try re-establishing the PCEP session. When the PCEP session is re-established, the LSP database is synchronized with the PCE, and any LSP which went down since the last time the PCEP session was up will have its path updated by the PCE.

4.2.4.1. 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 re-optimization and updating of the LSP paths.

Table 35 describes the messages and objects supported by stateful PCE in the SR OS.

Table 35:  PCEP Stateful PCE Extension Objects and TLVs 

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 objects in Table 35 are as follows:

  1. 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 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 which are signaled by the routers but are not synchronized up 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 PCE will be able to bring the PCEP session up, the LSP database will not be updated, since stateless PCC does not support the PCRpt message. As such, PCE path computation will not accurately take into account the bandwidth used by these LSPs in the network.
  4. PCE ignores the R-flag (re-optimize flag) in the PCReq message when acting in stateful-passive mode for a given LSP, and will always return the new computed path, regardless if it is link-by-link identical or has the same metric as the current path. The decision whether or not to initiate the new path in the network belongs to the PCC.
  5. The SVEC object is not supported in the SR OS 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 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. 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. SR OS PCC does not support putting a bound 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 contains a single set. If the PCRpt contains a duplicate set, PCE path computation must use the constraints in the duplicate set.
    4. For interoperability, implementations compliant to PCEP standards should be able to accept the first metric object and ignore the second object without additional error handling. Since 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.

In a future release, when the stateful PCE supports LSP initiation, the extensions described in Table 36 are required.

Table 36:  PCEP PCE-Initiated LSP Extension Objects and TLVs 

TLV, Object, or Message

Contained in Object

Contained in Message

PCE LSP Initiate Message (PCInitiate)

N/A

New message

PCC LSP Create Flag (C-flag)

LSP

PCRpt 1

    Note:

  1. Nokia proprietary

4.2.4.2. PCEP Extensions in Support of SR-TE LSPs

In order for the PCE and PCC to manage the path of an SR-TE LSP, they both implement the following extensions to PCEP in support of segment routing.

  1. A new Segment Routing capability TLV in the OPEN object to indicate support of segment routing tunnels by the PCE and the PCC during PCEP session initialization. This TLV is referred to as the SR-PCE-CAPABILITY TLV.
  2. The PCC and 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 the PCC will not use them during that specific PCEP session.
  3. A new Path Setup Type TLV for SR-TE LSPs to be included in the Stateful PCE Request Parameters (SRP) Object during path report (PCRpt) messages by the PCC.
    A Path Setup Type TLV with a value of 1 identifies an SR-TE LSP.
  4. A new Segment Routing ERO and RRO with sub-objects, referred to as SR-ERO and SR-RRO sub-objects, which encode the SID information in PCRpt messages.
  5. The PCE implementation supports the Segment-ID (SID) Depth value in the METRIC object. This is always signaled by the PCC in the PCEP Open object as part of the as SR-PCE-CAPABILITY TLV. It is referred to as the Maximum Stack Depth (MSD). In addition, the per-LSP value for the max-sr-labels option, if configured, is signaled by the PCC to the PCE in the Segment-ID (SID) Depth value in a METRIC object for both a PCE-computed LSP and a PCE-controlled LSP. PCE will compute and provide the full explicit path with TE-links specified. If there is no path with the number of hops lower than the MSD value, or the Segment-ID (SID) Depth value if signaled, a reply with no path will be returned to the PCC.For a PCC controlled LSP, if the label stack returned by the TE-DB’s hop-to-label translation exceeds the per LSP maximum SR label stack size, the LSP is brought down.
  6. If the Path Setup Type (PST) TLV is not included in the PCReq message, the PCE or PCC must assume it is for an RSVP-TE LSP.

Table 37 describes the segment routing extention objects and TLVs supported in the SR OS.

Table 37:  PCEP Segment Routing Extension Objects and TLVs 

TLV, Object, or Message

Contained in Object

Contained in Message

SR PCE CAPABILITY TLV

OPEN

OPEN

Path Setup Type (PST) TLV

SRP

PCReq, PCRep, PCRpt 1

SR-ERO Sub-object

ERO

PCRep, PCRpt 1

SR-RRO Sub-object

RRO

PCReq, PCRpt 1

Segment-ID (SID) Depth Value in METRIC Object

METRIC

PCReq, PCRpt 1

    Note:

  1. Nokia proprietary

4.2.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 SR OS support three different modes of operations for PCC-initiated LSPs which are configurable on a per-LSP basis.

  1. 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 SR-TE 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 can not be updated by the PCE. In other words, the control of the LSP is maintained by the PCC.
  2. 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 user must enable the pce-computation option for the LSP so that the PCE can perform path computation at the request of the PCC only. 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. 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 user must enable the pce-control option for the LSP so that the PCE can perform path updates following a network event without an explicit request from the PCC. PCC delegates full control.
    2. The user must enable the pce-report option for LSPs that cannot be delegated to the PCE. The PCE acts in active stateful mode for this LSP.

4.2.4.3.1. PCC-Initiated and PCE-Computed/Controlled LSPs

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

  1. The LSP configuration is created on the PE router via CLI or via the OSS/5620 SAM.
    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 SR 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 re-optimization, 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 re-optimization. At that point, the prior procedure is followed.

4.2.4.3.2. LSP Path Diversity and Bi-Directionality 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 bi-directionality 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 bound 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 bi-directionality, symmetric reverse route preferred, symmetric reverse route required
  3. maximum path IGP metric (cost)
  4. maximum path TE metric
  5. maximum hop count

In addition, the user can specify in the PCE Path Profile which PCE objective to use to optimize the path of the LSP.

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

The CSPF algorithm will optimize this objective. If a constraint is provided for the same metric, then the CSPF algorithm makes sure that the selected path achieves a lower or equal value to the bound 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/exclude admin-group constraints and setup and hold priorities, are not supported in the PCE profile.

In order to indicate the path diversity and bi-directionality 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 for this is described in the Configuring and Operating SR-TE section. 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 which 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 a given 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 into 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 PCC to PCE.

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

In order to for PCE to be aware of the path diversity and bi-directionality constraints for an LSP which 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 38 describes the new objects introduced in the PCE path profile.

Table 38:  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.