Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE

Support of Path Computation Element Protocol for RSVP-TE Overview

• Understanding MPLS RSVP-TE
• Current MPLS RSVP-TE Limitations
• Use of an External Path Computing Entity
• Components of External Path Computing
• Interaction Between a PCE and a PCC Using PCEP
• LSP Behavior with External Computing
• Configuration Statements Supported for External Computing
• PCE-Controlled LSP Protection
• Auto-Bandwidth and PCE-Controlled LSP
• Impact of Client-Side PCE Implementation on Network Performance

Understanding MPLS RSVP-TE

Traffic engineering (TE) deals with performance optimization of operational networks, mainly mapping traffic flows onto an existing physical topology. Traffic engineering provides the ability to move traffic flow away from the shortest path selected by the interior gateway protocol (IGP) and onto a potentially less congested physical path across a network.

For traffic engineering in large dense networks, MPLS capabilities can be implemented, because they potentially provide most of the functionality available from an overlay model, in an integrated manner, and at a lower cost than the currently competing alternatives. The primary reason for implementing MPLS traffic engineering is to control paths along which traffic flows through a network. The main advantage of implementing MPLS traffic engineering is that it provides a combination of ATM's traffic engineering capabilities along with the class-of-service (CoS) differentiation of IP.

In an MPLS network, data plane information is forwarded using label switching. A packet arriving on a provider edge (PE) router from the customer edge (CE) router is applied labels and forwarded to the egress PE router. The labels are removed at the egress router and forwarded out to the appropriate destination as an IP packet. The label switch routers (LSRs) in the MPLS domain use label distribution protocols to communicate the meaning of labels used to forward traffic between and through the LSRs. RSVP-TE is one such label distribution protocol that enables an LSR peer to learn about the other peer’s label mappings.

When both MPLS and RSVP are enabled on a router, MPLS becomes a client of RSVP. The primary purpose of the Junos OS RSVP software is to support dynamic signaling within label-switched paths (LSPs). RSVP reserves resources, such as for IP unicast and multicast flows, and requests quality-of-service (QoS) parameters for applications. The protocol was extended in MPLS traffic engineering to enable RSVP to set up LSPs that can be used for traffic engineering in MPLS networks.

When MPLS and RSVP are combined, labels are associated with RSVP flows. Once an LSP is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic is accomplished using different criteria. The set of packets that are assigned the same label value by a specific node belong to the same forwarding equivalence class (FEC), and effectively define the RSVP flow. When traffic is mapped onto an LSP in this way, the LSP is called an LSP tunnel.

LSP tunnels are a way to establish unidirectional label-switched paths. RSVP-TE builds on the RSVP core protocol by defining new objects and modifying existing objects used in the PATH and RESV objects for LSP establishment. The new objects—LABEL-REQUEST object (LRO), RECORD-ROUTE object (RRO), LABEL object, and EXPLICIT-ROUTE object (ERO)—are optional with respect to the RSVP protocol, except for the LRO and LABEL objects, which are both mandatory for establishing LSP tunnels.

• Possibility to establish a label-switched path using either a full or partial explicit route (RFC 3209).
• Constraint-based LSP establishment over links that fulfill requirements, such as bandwidth and link properties.
• End-point control, which is associated with establishing and managing LSP tunnels at the ingress and egress routers.
• Link management, which manages link resources to do resource-aware routing of TE LSPs and to program MPLS labels.
• MPLS fast reroute (FRR), which manages the LSPs that need protection and assigns backup tunnel information to these LSPs.

Current MPLS RSVP-TE Limitations

• Lack of visibility of individual per-LSP, per-device bandwidth demands—The ingress routers in an MPLS RSVP-TE network establish LSPs without having a global view of the bandwidth demand on the network. Information about network resource utilization is only available as total reserved capacity by traffic class on a per interface basis. Individual LSP state is available locally on each label edge router (LER) for its own LSPs only. As a result, a number of issues related to demand pattern arise, particularly within a common setup and hold priority.
• Asynchronous and independent nature of RSVP signaling—In RSVP-TE, the constraints for path establishment are controlled by an administrator. As such, bandwidth reserved for an LSP tunnel is set by the administrator and does not automatically imply any limit on the traffic sent over the tunnel. Therefore, bandwidth available on a traffic engineering link is the bandwidth configured for the link excluding the sum of all reservations made on the link. Thus, the unsignaled demands on an LSP tunnel lead to service degradation of the LSP requiring excess bandwidth, as well as the other LSPs that comply with the bandwidth requirements of the traffic engineering link.
• LSPs established based on dynamic or explicit path options in the order of preference—The ingress routers in an MPLS RSVP-TE network establish LSPs for demands based on the order of arrival. Because the ingress routers do not have a global view of the bandwidth demand on the network, using the order of preference to establish LSPs can cause traffic to be dropped or LSPs from not being established at all when there is an excess of bandwidth demand.

As an example, Figure 1 is configured with MPLS RSVP-TE, in which A and G are the label edge routers (LERs). These ingress routers establish LSPs independently based on the order of demands and have no knowledge or control over each other’s LSPs. Routers B, C, and D are intermediate or transit routers that connect to the egress routers E and F.

Figure 1: Example MPLS Traffic Engineering

The ingress routers establish LSPs based on the order in which the demands arrive. If Router G receives two demands of capacity 5 each for G-F, then G signals two LSPs – LSP1 and LSP2 – through G-B-D-F. In the same way, when Router A receives the third demand of capacity 10 for A-E, then it signals an LSP, LSP3, through A-B-C-E. However, if the demand on the A-E LSP increases from 10 to 15, Router A cannot signal LSP3 using the same (A-B-C-E) path, because the B-C link has a lower capacity.

Router A should have signaled the increased demand on LSP3 using the A-B-D-C-E path. Since, LSP1 and LSP2 have utilized the B-D link based on the order of demands received, LSP3 is not signaled.

Thus, although adequate max-flow bandwidth is available for all the LSPs, LSP3 is subject to potentially prolonged service degradation. This is due to Router A’s lack of global demand visibility and the lack of systemic coordination in demand placement by the ingress routers A and G.

Use of an External Path Computing Entity

As a solution to the current limitations found in the MPLS RSVP-TE path computation, an external path computing entity with a global view of per-LSP, per-device demand in the network independent of available capacity is required.

Currently, only online and real-time constraint-based routing path computation is provided in an MPLS RSVP-TE network. Each router performs constraint-based routing calculations independent of the other routers in the network. These calculations are based on currently available topology information—information that is usually recent, but not completely accurate. LSP placements are locally optimized, based on current network status. The MPLS RSVP-TE tunnels are set up using the CLI. An operator configures the TE LSP, which is then signaled by the ingress router.

In addition to the existing traffic engineering capabilities, the MPLS RSVP-TE functionality is extended to include an external path computing entity, called the Path Computation Element (PCE). The PCE computes path for the TE LSPs of ingress routers that have been configured for external control. The ingress router that connects to a PCE is called a Path Computation Client (PCC). The PCC is configured with the Path Computation Client Protocol (PCEP) to facilitate external path computing by a PCE.

For more information, see Components of External Path Computing.

To enable external path computing for a PCC’s TE LSPs, include the lsp-external-controller pccd statement at the [edit mpls] and [edit mpls lsp lsp-name] hierarchy levels.

Components of External Path Computing

The components that make up an external path computing system are:

• Path Computation Element
• Path Computation Client
• Path Computation Element Protocol

Path Computation Element

A Path Computation Element (PCE) can be any entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. However, a PCE can compute path for only those TE LSPs of a PCC that have been configured for external control.

• Stateful PCE—A stateful PCE maintains strict synchronization between the PCE and network states (in terms of topology and resource information), along with the set of computed paths and reserved resources in use in the network. In other words, a stateful PCE utilizes information from the traffic engineering database as well as information about existing paths (for example, TE LSPs) in the network when processing new requests from the PCC.

  A stateful PCE is of two types:

  • Passive stateful PCE—Maintains synchronization with the PCC and learns the PCC LSP states to better optimize path calculations, but does not have control over them.
  • Active stateful PCE—Actively modifies the PCC LSPs, in addition to learning about the PCC LSP states.

    Note: In a redundant configuration with main and backup active stateful PCEs, the backup active stateful PCE cannot modify the attributes of delegated LSPs until it becomes the main PCE at the time of a failover. There is no preempting of PCEs in the case of a switchover. The main PCE is backed by a backup PCE, and when the main PCE goes down, the backup PCE assumes the role of the main PCE and remains as the main PCE even though the previously main PCE comes up again.

  A stateful PCE provides the following functions:

  • Offers offline LSP path computation.
  • Triggers LSP re-route when there is a need to re-optimize the network.
  • Changes LSP bandwidth when there is an increase in bandwidth demand from an application.
  • Modifies other LSP attributes on the router, such as ERO, setup priority, and hold priority.

  A PCE has a global view of the bandwidth demand in the network and maintains a traffic engineered database to perform path computations. It performs statistics collection from all the routers in the MPLS domain using SNMP and NETCONF. This provides a mechanism for offline control of PCC’s TE LSPs. Although an offline LSP path computation system can be embedded in a network controller, the PCE acts like a full-fledged network controller that provides control over the PCC’s TE LSPs, in addition to computing paths.

  Although a stateful PCE allows for optimal path computation and increased path computation success, it requires reliable state synchronization mechanisms, with potentially significant control plane overhead and the maintenance of a large amount of data in terms of states, as in the case of a full mesh of TE LSPs.

• Stateless PCE—A stateless PCE does not remember any computed path, and each set of requests is processed independently of each other (RFC 5440).

Path Computation Client

A Path Computation Client (PCC) is any client application requesting a path computation to be performed by a PCE.

A PCC can connect to a maximum of 10 PCEs at one time. The PCC to PCE connection can be a configured static route or a TCP connection that establishes reachability. The PCC assigns each connected PCE a priority number. It sends a message to all the connected PCEs with information about its current LSPs, in a process called LSP state synchronization. For the TE LSPs that have external control enabled, the PCC delegates those LSPs to the main PCE. The PCC elects as the main PCE a PCE with the lowest priority number, or the PCE that it connects to first in the absence of priority number.

The PCC re-signals an LSP based on the computed path it receives from a PCE. When the PCEP session with the main PCE is terminated, the PCC elects a new main PCE, and all delegated LSPs to the previously main PCE are delegated to the newly available main PCE.

Path Computation Element Protocol

Path Computation Element Protocol (PCEP) is used for communication between PCC and PCE (as well as between two PCEs) (RFC 5440). PCEP is a TCP-based protocol defined by the IETF PCE Working Group, and defines a set of messages and objects used to manage PCEP sessions and to request and send paths for multidomain TE LSPs. The PCEP interactions include PCC messages as well as notifications of specific states related to the use of a PCE in the context of MPLS RSVP-TE. When PCEP is used for PCE-to-PCE communication, the requesting PCE assumes the role of a PCC.

• LSP tunnel state synchronization between PCC and a stateful PCE.
• Delegation of control over LSP tunnels to a stateful PCE.

Interaction Between a PCE and a PCC Using PCEP

Figure 2 illustrates the relationship between a PCE, PCC, and the role of PCEP in the context of MPLS RSVP-TE.

Figure 2: PCC and RSVP-TE

The PCE to PCC communication is enabled by the TCP-based PCEP. The PCC initiates the PCEP session and stays connected to a PCE for the duration of the PCEP session.

1. LSP state synchronization—The PCC sends information about all the LSPs (local and external) to all connected PCEs. For external LSPs, the PCC sends information about any configuration change, RRO change, state change, and so on, to the PCE.
2. LSP delegation—The PCC then delegates the external LSPs to one PCE, which is the main active stateful PCE. It is only the main PCE that can set parameters for the external LSP. The parameters that the main PCE modifies include bandwidth, path (ERO), and priority (setup and hold). The parameters specified in the local configuration are overridden by the parameters that are set by the main PCE.

   Note: When the PCEP session with the main PCE is terminated, the PCC elects a new main PCE, and all delegated LSPs to the previously main PCE are delegated to the newly available main PCE.

3. LSP signaling—On receiving one or more LSP parameters from the main active stateful PCE, the PCC re-signals the TE LSP based on the PCE provided path. If the PCC fails to set up the LSP, it notifies the PCE of the setup failure and waits for the main PCE to provide new parameters for that LSP, and then re-signals it.

   When the PCE specifies a path that is incomplete or has loose hops where only the path end-points are specified, the PCC does not perform local constraint-based routing to find out the complete set of hops. Instead, the PCC provides RSVP with the PCE provided path, as it is, for signaling, and the path gets set up using IGP hop by hop routing.

Considering the topology used in Figure 1, Figure 3 illustrates the partial client-side PCE implementation in the MPLS RSVP-TE enabled network. The ingress routers A and G are the PCCs that are configured to connect to the external stateful PCE through a TCP connection.

The PCE has a global view of the bandwidth demand in the network and performs external path computations after looking up the traffic engineering database. The active stateful PCE then modifies one or more LSP attributes and sends an update to the PCC. The PCC uses the parameters it receives from the PCE to re-signal the LSP.

Figure 3: Example PCE for MPLS RSVP-TE

This way, the stateful PCE provides a cooperative operation of distributed functionality used to address specific challenges of a shortest interdomain constrained path computation. It eliminates congestion scenarios in which traffic streams are inefficiently mapped onto available resources causing over utilization of some subsets of network resources, while other resources remain under utilized.

LSP Behavior with External Computing

• LSP Types
• LSP Control Mode

LSP Types

• CLI-controlled LSPs—The LSPs that do not have the lsp-external-controller pccd statement configured are called CLI-controlled LSPs. Although these LSPs are under local control, the PCC updates the connected PCEs with information about the CLI-controlled LSPs during the initial LSP synchronization process. After the initial LSP synchronization, the PCC informs the PCE of any new and deleted LSPs as well.
• PCE-controlled LSPs—The LSPs that have the lsp-external-controller pccd statement configured are called PCE-controlled LSPs. The PCC delegates the PCE-controlled LSPs to the main PCE for external path computation.

  The PCC informs the PCE about the configured parameters of a PCE-controlled LSP, such as bandwidth, ERO, and priorities. It also informs the PCE about the actual values used for these parameters to set up the LSP including the RRO, when available.

  The PCC sends such LSP status reports to the PCE only when a re-configuration has occurred or when there is a change in the ERO, RRO, or status of the PCE-controlled LSPs under external control.

  There are two types of parameters that come from the CLI configuration of an LSP for a PCE:

  • Parameters that are not overridden by a PCE, and that are applied immediately.
  • Parameters that are overridden by a PCE. These parameters include bandwidth, path, and priority (setup and hold values). When the control mode switches from external to local, the CLI configured values for these parameters are applied at the next opportunity to re-signal the LSP. The values are not applied immediately.

The CLI-controlled LSPs coexist with the PCE-controlled LSPs on a PCC.

LSP Control Mode

• External—By default, all PCE-controlled LSPs are under external control. When an LSP is under external control, the PCC uses the PCE-provided parameters to set up the LSP.
• Local—A PCE-controlled LSP can come under local control. When the LSP switches from external control to local control, path computation is done using the CLI-configured parameters and constraint-based routing. Such a switchover happens only when there is a trigger to re-signal the LSP. Until then, the PCC uses the PCE-provided parameters to signal the PCE-controlled LSP, although the LSP remains under local control.

A PCE-controlled LSP switches to local control from its default external control mode in cases such as no connectivity to a PCE or when a PCE returns delegation of LSPs back to the PCC.

For more information about CLI-controlled LSPs and PCE-controlled LSPs, see LSP Types.

Configuration Statements Supported for External Computing

Table 1 lists the MPLS and existing LSP configuration statements that apply to a PCE-controlled LSP.

The rest of the LSP configuration statements are applicable in the same way as for existing LSPs. On configuring any of the above configuration statements for a PCE-controlled LSP, an mpls log message is generated to indicate when the configured parameters take effect.

PCE-Controlled LSP Protection

The protection paths, including fast reroute and bypass LSPs, are locally computed by the PCC using constraint-based routing. A stateful PCE specifies the primary path (ERO) only. A PCE can also trigger a non-standby secondary path, even if the local configuration does not have a non-standby secondary path for LSP protection.

Auto-Bandwidth and PCE-Controlled LSP

The auto-bandwidth option does not apply to PCE-controlled LSPs, although LSPs under the control of auto-bandwdith and constraint-based routing can coexist with PCE-controlled LSPs. The statistics collection for auto-bandwidth takes effect only when the control mode of a PCE-controlled LSP changes from external to local. This can happen in cases such as no connectivity to a PCE or when a PCE returns delegation of LSPs back to the PCC.

Impact of Client-Side PCE Implementation on Network Performance

• Any reliable synchronization mechanism results in significant control plane overhead. PCEs might synchronize state by communicating with each other, but when TE LSPs are set up using distributed computation performed among several PCEs, the problems of synchronization and race condition avoidance become larger and more complex.
• Out-of-band traffic engineering database synchronization can be complex with multiple PCEs set up in a distributed PCE computation model, and can be prone to race conditions, scalability concerns, and so on.
• Path calculations incorporating total network state is highly complex, even if the PCE has detailed information on all paths, priorities, and layers.

In spite of the above concerns, the partial client-side implementation of the stateful PCE is extremely effective in large traffic engineering systems. It provides rapid convergence and significant benefits in terms of optimal resource usage, by providing the requirement for global visibility of a TE LSP state and for ordered control of path reservations across devices within the system being controlled.

Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE

This example shows how to enable external path computing by a Path Computation Element (PCE) for traffic engineered label-switched paths (TE LSPs) on a Path Computation Client (PCC). It also shows how to configure the Path Computation Element Protocol (PCEP) on the PCC to enable PCE to PCC communication.

• Requirements
• Overview
• Configuration
• Verification

Requirements

• Three routers that can be a combination of M Series, MX Series, or T Series routers, one of which is configured as a PCC.
• A TCP connection to an external stateful PCE from the PCC.
• Junos OS Release 12.3 or later running on the ingress router.

1. Configure the device interfaces.
2. Configure MPLS and RSVP-TE.
3. Configure IS-IS or any other IGP protocol.

Overview

Starting with Junos OS Release 12.3, the MPLS RSVP-TE functionality is extended to provide a partial client-side implementation of the stateful PCE architecture (draft-ietf-pce-stateful-pce) on a PCC.

To enable external path computing by a PCE, include the lsp-external-controller statement on the PCC at the [edit mpls] and [edit mpls lsp lsp-name] hierarchy levels.

An LSP configured with the lsp-external-controller statement is referred to as a PCE-controlled LSP and is under the external control of a PCE by default. An active stateful PCE can override the parameters set from the CLI, such as bandwidth, path (ERO), and priority, for such PCE-controlled LSPs of the PCC.

To enable PCE to PCC communication, configure PCEP on the PCC at the [edit protocols] hierarchy level.

• Junos OS Release 12.3 supports only stateful PCEs.
• A PCC can connect to a maximum of 10 stateful PCEs. At any given point in time, there can be only one main PCE (the PCE with the lowest priority value, or the PCE that connects to the PCC first in the absence of a PCE priority) to which the PCC delegates LSPs for path computation.
• For Junos OS Release 12.3, the PCC always initiates the PCEP sessions. PCEP sessions initiated by remote PCEs are not accepted by the PCC.
• Existing LSP features, such as LSP protection and make-before-break, work for PCE-controlled LSPs.
• The auto-bandwidth option is turned off for PCE-controlled LSPs, although LSPs under the control of auto-bandwdith and constraint-based routing can coexist with PCE-controlled LSPs.
• PCE-controlled LSPs can be referred to by other CLI configurations, such as lsp-nexthop to routes, forwarding adjacencies, CCC connections, and logical tunnels.
• PCE-controlled LSPs do not support GRES.
• PCE-controlled LSPs under logical-systems are not supported.
• PCE-controlled LSPs cannot be point-to-multipoint LSPs.
• Bidirectional LSPs are not supported.
• PCE-controlled LSPs cannot have secondary paths without a primary path.
• PCE-controlled LSPs depend on external path computation, which impacts overall setup time, reroutes, and make-before-break features.
• Setup time and convergence time (reroute, MBB) for exisiting LSPs is the same as in previous releases, in the absence of PCE-controlled LSPs. However, a small impact is seen in the presence of PCE-controlled LSPs.
• ERO computation time is expected to be significantly higher than local-CSPF.

Topology

Figure 4: Configuring PCEP for RSVP-TE

In this example, PCC is the ingress router that connects to the external active stateful PCE.

1. PCC receives the LSP tunnel configuration that was set up using the CLI. Assuming that the received configuration is enabled with external path computing, PCC becomes aware that some of the LSP attributes – bandwidth, path, and priority – are under the control of the stateful PCE and delegates the LSP to the PCE.

   In this example, the external LSP is called PCC-to-R2 and it is being set up from PCC to Router R2 . The CLI-configured ERO for PCC-to-R2 is PCC-R0-R1-R2. The bandwidth for PCC-to-R2 is 10m, and both the setup and hold priority values are 4.

2. PCC tries to retrieve the PCE-controlled LSP attributes. To do this, PCC sends out a PCRpt to the stateful PCE stating that the LSP has been configured. The PCRpt communicates the status of the LSP and contains the local configuration parameters of the LSP.
3. The stateful PCE modifies one or more of the delegated LSP attributes and sends the new LSP parameters to the PCC through the PCUpd message.
4. On receiving the new LSP parameters, PCC sets up a new LSP and re-signals it using the PCE-provided path.

   In this example, the PCE-provided ERO for PCC-to-R2 is PCC-R3-R2. The bandwidth for PCC-to-R2 is 8m, and both the setup and hold priority values are 3.

5. PCC sends a PCRpt with the new RRO to the stateful PCE.

Configuration

• Configuring PCEP
• Results

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configuring PCEP

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.

To configure the PCC router:

Note: Repeat this procedure for every Juniper Networks ingress router in the MPLS domain, after modifying the appropriate interface names, addresses, and any other parameters for each router.

1. Configure the interfaces.

   To enable MPLS, include the protocol family on the interface so that the interface does not discard incoming MPLS traffic.

   [edit interfaces]user@PCC# set ge-1/0/1 unit 0 family inet address 20.31.4.1/24user@PCC# set ge-1/0/1 unit 0 family isouser@PCC# set ge-1/0/1 unit 0 family mpls
   user@PCC# set ge-1/1/1 unit 0 family inet address 20.31.1.1/24user@PCC# set ge-1/1/1 unit 0 family isouser@PCC# set ge-1/1/1 unit 0 family mpls
   user@PCC# set lo0 unit 0 family inet address 10.255.179.95/32
2. Enable RSVP on all interfaces of the PCC, excluding the management interface.
   [edit protocols]user@PCC# set rsvp interface alluser@PCC# set rsvp interface fxp0.0 disable
3. Configure the label-switched path (LSP) from the PCC to Router R2 and enable external control of LSPs by the PCE.
   [edit protocols]user@PCC# set mpls lsp-external-controller pccduser@PCC# set mpls label-switched-path PCC-to-R2 to 10.255.179.98/32user@PCC# set mpls label-switched-path PCC-to-R2 bandwidth 10muser@PCC# set protocols mpls label-switched-path PCC-to-R2 priority 4 4user@PCC# set protocols mpls label-switched-path PCC-to-R2 primary to-R2-pathuser@PCC# set protocols mpls label-switched-path PCC-to-R2 lsp-external-controller pccd
4. Configure the LSP from the PCC to Router R2, which has local control and is overridden by the PCE- provided LSP parameters.
   [edit protocols]user@PCC# set mpls path to-R2-path 20.31.1.2/30 strictuser@PCC# set mpls path to-R2-path 20.31.2.2/30 strict
5. Enable MPLS on all interfaces of the PCC, excluding the management interface.
   [edit protocols]user@PCC# set mpls interface alluser@PCC# set mpls interface fxp0.0 disable
6. Configure IS-IS on all interfaces of the PCC, excluding the management interface.
   [edit protocols]user@PCC# set isis level 1 disableuser@PCC# set isis interface alluser@PCC# set isis interface fxp0.0 disableuser@PCC# set isis interface lo0.0
7. Define the PCE that the PCC connects to, and configure the IP address of the PCE.
   [edit protocols]user@PCC# set pcep pce pce1 destination-ipv4-address 10.209.57.166
8. Configure the destination port for the PCC that connects to a PCE using the TCP-based PCEP.
   [edit protocols]user@PCC# set pcep pce pce1 destination-port 4189
9. Configure the PCE type.
   [edit protocols]user@PCC# set pcep pce pce1 pce-type activeuser@PCC# set pcep pce pce1 pce-type stateful

Results

From configuration mode, confirm your configuration by entering the show interfaces and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

• Verifying the PCEP Session Status
• Verifying the PCE-Controlled LSP Status When LSP Control Is External
• Verifying the PCE-Controlled LSP Status When LSP Control Is Local

Verifying the PCEP Session Status

Purpose

Verify the PCEP session status between the PCE and the PCC when the PCE status is up.

Action

PCE pce1
General
    IP address              : 10.209.57.166
    Priority                : 0
    PCE status              : PCE_STATE_UP
    Session type            : PCE_TYPE_STATEFULACTIVE
    PCE-mastership          : main

Counters
    PCReqs              Total: 0            last 5min: 0            last hour: 0        
    PCReps              Total: 0            last 5min: 0            last hour: 0        
    PCRpts              Total: 5            last 5min: 5            last hour: 5        
    PCUpdates           Total: 1            last 5min: 1            last hour: 1        

Timers
    Local             Keepalive timer:        30 [s]   Dead timer:       120 [s]
    Remote            Keepalive timer:        30 [s]   Dead timer:       120 [s]

Errors
    PCErr-recv
    PCErr-sent
    PCE-PCC-NTFS
    PCC-PCE-NTFS

Meaning

The output displays information about the current active stateful PCE that the PCC is connected to. The PCE status output field indicates the current status of the PCEP session between a PCE and PCC.

For pce1, the status of the PCEP session is PCE_STATE_UP, which indicates that the PCEP session has been established between the PCEP peers.

The statistics of PCRpts indicate the number of messages sent by the PCC to the PCE to report the current status of LSPs. The PCUpdates statistics indicate the number of messages received by the PCC from the PCE. The PCUpdates messages include the PCE modified parameters for the PCE-controlled LSPs.

Verifying the PCE-Controlled LSP Status When LSP Control Is External

Purpose

Verify the status of the PCE-controlled LSP from the PCC to Router R2 when the LSP is under external control.

Action

From operational mode, run the show mpls lsp name PCC-to-R2 extensive command.

Ingress LSP: 1 sessions

10.255.179.98
  From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
  ActivePath: to-R2-path (primary)
  LSPtype: Externally controlled, Penultimate hop popping
  LSP Control Status: Externally controlled
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   to-R2-path     State: Up
    Priorities: 3 3
    Bandwidth: 8Mbps
    SmartOptimizeTimer: 180
        No computed ERO.
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          20.31.4.2 20.31.5.2
   21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
   20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   19 Mar 11 05:00:56.735 Selected as active path
   18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
   17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   16 Mar 11 05:00:56.734 Record Route:  20.31.4.2 20.31.5.2
   15 Mar 11 05:00:56.734 Up
   14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
   13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   12 Mar 11 05:00:56.712 Originate Call
   11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters :  20.31.4.2 20.31.5.2
   10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
    9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
    6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
    4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
    3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
    2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
  Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Meaning

In the output, the LSPtype and LSP Control Status output fields show that the LSP is externally controlled. The output also shows a log of the PCEP messages sent between the PCC and the PCE.

• ERO (path)—20.31.4.2 and 20.31.5.2
• Bandwidth—8Mbps
• Priorities—3 3 (setup and hold values)

Verifying the PCE-Controlled LSP Status When LSP Control Is Local

Purpose

Verify the status of the PCE-controlled LSP from the PCC to Router R2 when the LSP control becomes local.

Action

From operational mode, run the show mpls lsp name PCC-to-R2 extensive command.

Ingress LSP: 1 sessions

10.255.179.98
  From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
  ActivePath: to-R2-path (primary)
  LSPtype: Externally controlled, Penultimate hop popping
  LSP Control Status: Locally controlled
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   to-R2-path     State: Up
    Priorities: 4 4 (ActualPriorities 3 3)
    Bandwidth: 10Mbps (ActualBandwidth: 8Mbps)
    SmartOptimizeTimer: 180
        No computed ERO.
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          20.31.4.2 20.31.5.2
   22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
   21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
   20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   19 Mar 11 05:00:56.735 Selected as active path
   18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
   17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   16 Mar 11 05:00:56.734 Record Route:  20.31.4.2 20.31.5.2
   15 Mar 11 05:00:56.734 Up
   14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
   13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   12 Mar 11 05:00:56.712 Originate Call
   11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters :  20.31.4.2 20.31.5.2
   10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
    9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
    6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
    4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
    3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
    2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
  Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0

Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Meaning

In the output, the LSP Control Status output field shows that the LSP is under local control. Although the PCE-controlled LSP is under local control, the PCC continues to use the PCE-provided parameters, until the next opportunity to re-signal the LSP.

• Bandwidth—10Mbps (ActualBandwidth: 8Mbps)
• Priorities—4 4 (ActualPriorities 3 3)

On the trigger to re-signal the LSP, the PCC uses the local configuration parameters to establish the PCE-controlled LSP.

Ingress LSP: 1 sessions

10.255.179.98
  From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2
  ActivePath: to-R2-path (primary)
  LSPtype: Externally controlled, Penultimate hop popping
  LSP Control Status: Locally controlled
  LoadBalance: Random
  Encoding type: Packet, Switching type: Packet, GPID: IPv4
 *Primary   to-R2-path     State: Up
    Priorities: 4 4
    Bandwidth: 10Mbps
    SmartOptimizeTimer: 180
    Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30)
 20.31.1.2 S 20.31.2.2 S 20.31.8.2 S 
    Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 20=Node-ID):
          20.31.1.2 20.31.2.2 20.31.8.2
   28 Mar 11 05:02:51.787 Record Route:  20.31.1.2 20.31.2.2 20.31.8.2
   27 Mar 11 05:02:51.787 Up
   26 Mar 11 05:02:51.697 EXTCTRL_LSP: Applying local parameters with this signalling attempt
   25 Mar 11 05:02:51.697 Originate Call
   24 Mar 11 05:02:51.696 Clear Call
   23 Mar 11 05:02:51.696 CSPF: computation result accepted  20.31.1.2 20.31.2.2 20.31.8.2
   22 Mar 11 05:02:09.618 EXTCTRL_LSP: Control status became local
   21 Mar 11 05:00:56.736 EXTCTRL LSP: Sent Path computation request and LSP status
   20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   19 Mar 11 05:00:56.735 Selected as active path
   18 Mar 11 05:00:56.734 EXTCTRL LSP: Sent Path computation request and LSP status
   17 Mar 11 05:00:56.734 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   16 Mar 11 05:00:56.734 Record Route:  20.31.4.2 20.31.5.2
   15 Mar 11 05:00:56.734 Up
   14 Mar 11 05:00:56.713 EXTCTRL LSP: Sent Path computation request and LSP status
   13 Mar 11 05:00:56.713 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
   12 Mar 11 05:00:56.712 Originate Call
   11 Mar 11 05:00:56.712 EXTCTRL_LSP: Received setup parameters :  20.31.4.2 20.31.5.2
   10 Mar 11 05:00:49.283 EXTCTRL LSP: Sent Path computation request and LSP status
    9 Mar 11 05:00:49.283 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    8 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    7 Mar 11 05:00:20.581 EXTCTRL LSP: Sent Path computation request and LSP status
    6 Mar 11 05:00:20.581 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    5 Mar 11 05:00:20.580 EXTCTRL_LSP: Control status became external
    4 Mar 11 05:00:03.716 EXTCTRL_LSP: Control status became local
    3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status
    2 Mar 11 05:00:03.714 EXTCTRL_LSP: Computation request/lsp status contains:  bandwidth 10000000 priority - setup 4 hold 4 hops:  20.31.1.2 20.31.2.2
    1 Mar 11 05:00:00.279 EXTCTRL LSP: Awaiting external controller connection
  Created: Mon Mar 11 05:00:00 2013
Total 1 displayed, Up 1, Down 0
                                        
Egress LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

Transit LSP: 0 sessions
Total 0 displayed, Up 0, Down 0

The Computed ERO is 20.31.1.2, 20.31.2.2, and 20.31.8.2. The PCE-controlled LSP is established using the local configuration parameters.