Summary

This chapter describes the configuration of RSVP-TE policies. RSVP-TE (or MPLS-TE) is an old-school way of doing traffic engineering that existed long before Segment Routing. Despite all advantages that Segment Routing provides, some network operators prefer to run RSVP-TE for a variety of reasons.

This can be also useful for networks looking to move from RSVP-TE to SR-TE – using a centralized controller to provision both types of policies allows for a more smooth migration.

Requirements

Traffic Dictator supports RSVP-TE policies starting from version 1.3.

PCEP must be configured as an installation protocol for RSVP-TE policies. TD must also receive topology information via BGP-LS, but there is no requirement for Segment Routing extensions to be advertised.

RSVP-TE policy example

Consider the following topology:

TD has BGP-LS and PCEP sessions with R1.

Policy config:

traffic-eng policies
   !
   policy R1_R9_EP_STRICT_IPV4
      headend 1.1.1.1 topology-id 101
      endpoint 9.9.9.9 service-loopback 9.9.9.9
      rsvp-te
      priority 7 7
      install direct pcep 192.168.0.101
      !
      candidate-path preference 100
         explicit-path R5_R8_R10
         bandwidth 100 mbps
!
traffic-eng explicit-paths
   !
   explicit-path R5_R8_R10
      index 10 strict 10.100.3.5
      index 20 strict 10.100.9.8
      index 30 strict 10.100.12.10

Verify an RSVP-TE policy

TD1#show traffic-eng policy R1_R9_EP_STRICT_IPV4
Traffic-eng policy information
Status codes: * valid, > active, r - RSVP-TE, e - EPE only, s - admin down, m - multi-topology
Endpoint codes: * active override
        Policy name                             Headend             Endpoint            Color/Service loopback   Protocol             Reserved bandwidth        Priority   Status/Reason
   r*>  R1_R9_EP_STRICT_IPV4                    1.1.1.1             9.9.9.9             9.9.9.9                  PCEP/direct          100000000                 7/7        Active

TD1#show traffic-eng policy R1_R9_EP_STRICT_IPV4 detail 
Detailed traffic-eng policy information:

Traffic engineering policy "R1_R9_EP_STRICT_IPV4"

    Valid config, Active
    This is an RSVP-TE policy
    Headend 1.1.1.1, topology-id 101
    Endpoint 9.9.9.9, service-loopback 9.9.9.9
        Endpoint type: Node, Topology-id: 101, Protocol: isis, Router-id: 0009.0009.0009.00

    Setup priority: 7, Hold priority: 7
    Reserved bandwidth bps: 100000000
    Install direct, protocol pcep, peer 192.168.0.101
    Policy index: 18, SR-TE distinguisher: 16777234
    Binding-SID: 15008

    Candidate paths:
        Candidate-path preference 100
            Path config valid
            Metric: igp
            Path-option: explicit
                Explicit path name: R5_R8_R10
            This path is currently active

    Calculation results:
        Aggregate metric: 40
        Topologies: ['101']
        RSVP ERO: ['10.100.3.5', '10.100.9.8', '10.100.12.10', '10.100.21.9']

    Policy statistics:
        Last config update: 2025-02-04 17:04:58,797
        Last recalculation: 2025-02-04 17:04:59.105
        Policy calculation took 0 miliseconds5
        Policy calculation took 0 miliseconds

Instead of segment list like with SR-TE policies, TD advertises RSVP ERO.

Check PCEP route:

TD1#show pcep ipv4 rsvp-te 
PCEP RSVP-TE routing table information
Status codes: * acked, > up/active, + - inserted, z - zombie

          NLRI                                      PLSP-ID    Oper status
*>+       [16777234][9.9.9.9]                             3    Active (2)    
TD1#show pcep ipv4 rsvp-te detail 
PCEP RSVP-TE routing table information

PCEP routing table entry for [16777234][9.9.9.9]
    Policy name: R1_R9_EP_STRICT_IPV4
    Headend: 1.1.1.1
    Endpoint: 9.9.9.9
    Install peer: 192.168.0.101
    Last modified: February 04, 2025 17:04:59
      Route acked by PCC, PLSP-ID 3
        LSP-ID     Oper status
             0        Down (0)
             2      Active (2)
      Metric type igp, metric 40
      RSVP ERO: ['10.100.3.5', '10.100.9.8', '10.100.12.10', '10.100.21.9']

Service-loopback for RSVP-TE policies

Similar to Segment Routing policies installed with BGP-LU, RSVP-TE policies are configured with a service loopback instead of a color. You can configure it to the same value as endpoint to emulate classical MPLS-TE, but configuring it to a different value allows for more flexibility when different services on the same endpoint node have different traffic engineering requirements.

Bandwidth reservation and priority

TD keeps internal database of bandwidth for all SR-TE, RSVP-TE and EPE policies. Provisioning RSVP-TE LSP with bandwidth would lead to a lot of churn in IGP and possible double-reservations. Therefore, RSVP-TE policies are always advertised with bandwidth 0. Likewise, setup and hold priority configured under policy is an internal setting TD uses to compare different policies in case there is a bandwidth reservation conflict, but on the router policies will always be installed with priority 7.