Despite many advantages of Segment Routing, some networks still prefer to use RSVP for traffic engineering – and they can have good reasons for this. Is there any value of SDN controller with RSVP-TE, compared to configuring policies on each router?
Why RSVP-TE instead of SR
In the article Making Segment Routing user-friendly I pointed out some advantages of SR over RSVP, such as:
- Simplicity (no extra label distribution protocols), which leads to:
- Easier interoperability between vendors
- Lower barrier to entry for small vendors and open source routing
- Easier to deploy and troubleshoot
- Better scalability
- ECMP and anycast support
In fairness, there can be good reasons for some network operators to choose RSVP over SR, and not just for legacy networks that had RSVP deployed before SR became a thing.
- RSVP is supported by a lot of legacy equipment that doesn’t support SR. So if you’re building a network using old Cisco stuff from Ebay, SR is not an option
- Even though most newer vendors have better support for SR than RSVP, a notable exception is Mikrotik which is a very popular choice for small ISPs. Hopefully they’ll add SR support at some point
- Fast Reroute protection for MPLS-TE policies. SR has TI-LFA but there are some problems when an SR-TE policy with multiple labels has to be protected.
- Bandwidth reservations and auto-bandwidth adjustment
Current state of MPLS-TE
Configuration and visibility
Traditionally, network operators have been configuring MPLS-TE tunnels on routers using CLI or some sort of network automation system. So deploying new services often involves a lot of manual configuration. Introducing a new type of device from another vendor, besides all kinds of compatibility testings (which are inevitable), requires updating the network management system to support the new CLI.
Decentralized path computation
Because each router runs CSPF and provisions MPLS-TE tunnels independently from others, there are some interesting issues such as bandwidth reservation deadlock, lack of path diversity and suboptimal inter-domain LSP. I won’t go into much detail here, instead I will refer to this great article by Diptanshu Singh.
On the flip side, decentralized computation leads to more efficient usage of computing resources which may have mattered in the early 2000s but with modern CPU there is no problem doing as many SPF computations as you want on one controller.
Advanced traffic engineering features
Segment Routing introduces a number of TE features – such as Color steering, On-Demand Nexthop and Egress Peer Engineering. Technically, none of those require SR, just those features came along together with SR so most implementations support them only with SR, although there is some effort to bring color steering to RSVP-TE.
How RSVP-TE fits in the SDN approach
The idea behind Software-Defined Networking is that all advanced network functions are offloaded to a controller, so deploying a new feature or service requires just controller config or software upgrade rather than reconfiguring, upgrading or even replacing a lot of network devices.
In some extreme cases like Openflow, the network cannot work at all without a controller; in Segment Routing, a controller provides advanced traffic engineering features, but basic network connectivity doesn’t depend on it.
Controller-based RSVP-TE LSP operations
Similarly to SR, the controller gets network topology information using BGP Link-State, calculates policies and advertises them to the network. On the controller side, there is much less workload than in case of SR, because there is no need to build segment lists, just run CSPF once to get RSVP Explicit Route Object (ERO).
The only standard protocol to advertise RSVP-TE policies to the network is PCEP (while in SR you can choose between PCEP, BGP SR-TE and BGP Labeled Unicast).
The picture below illustrates provisioning of an RSVP-TE LSP from a controller using PCEP:
This example shows a PCE (controller) initiated LSP; there can be also a PCC (router) initiated LSP – in which case R1 would send PCRequest and Controller would respond with PCUpdate instead of PCInitiate.
PCEP is a very complex protocol with almost 50 RFC regulating it, but its advantage is that it’s stateful – i.e. the SDN controller receives updates with LSP status on the router.
Another advantage of PCEP statefulness is that routers can report used bandwidth to the controller which enables auto-bandwidth for PCE-controlled LSP.
Advantages of an SDN controller for RSVP-TE
Now let’s explore what is the point of using an SDN controller instead of just configuring LSP on each router using CLI or automation.
Centralized path computation
As I pointed out earlier, decentralized path computation with RSVP-TE comes with a number of issues. Centralizing it can help solve them.
Path diversity
A controller can make sure 2 LSP never use the same link/node/SRLG. Consider example below:
LSP2 is signaled with a constraint “disjoint from LSP1” – so it uses a different path even though R1-R2-R3 is the shortest path.
Deterministic LSP signaling
With decentralized computation, different routers try to signal LSP independently and the result can be different each time depending on the timing of events. Also there can be a situation where low priority LSP1 is signaled, then higher priority LSP2 kicks out LSP1 and LSP1 has to be signaled again.
A controller can just sort all LSP in order of setup priority before calculation – Traffic Dictator does that by default.
Multi-domain LSP
In hierarchical designs like Seamless MPLS, or inter-AS designs, a controller can calculate more optimal paths because it has full visibility of all IGP domains.
Single interface for LSP management
This is especially valuable in multi-vendor deployments. Instead of adapting the network automation system to handle all sorts of different CLI and API, configure it to use just one API – that of the SDN controller and let the controller provision LSP using an open-standard protocol (PCEP).
Network visibility
While not unique to a controller, there are many network management systems that can draw network diagrams from IGP topology, but it’s handy to see the state of your network and how much bandwidth has been provisioned on different links.
Picture below is from Traffic Dictator GUI (in development) – topology drawn from BGP-LS data, red links have <25% unprovisioned bandwidth left.
Color steering
One great feature of SR-TE is color steering that allows the operator to map different services on the same endpoint to different SR-TE policies. There is no such thing in RSVP-TE, although with [draft-ietf-pce-pcep-color] hopefully it will be possible in the future.
There is a workaround to achieve similar behaviour with service loopbacks that I described in Poor man’s Traffic Engineering. It is possible to achieve a similar behaviour with RSVP-TE with some routers.
Example Traffic Dictator config:
traffic-eng policies ! policy R1_R11_BLUE_ONLY headend 1.1.1.1 topology-id 101 endpoint 11.11.11.11 service-loopback 100.0.0.11 rsvp-te priority 7 7 install direct pcep 192.168.0.101 ! candidate-path preference 100 affinity-set BLUE_ONLY bandwidth 100 mbps
TD1#show traffic-eng policy R1_R11_BLUE_ONLY detail Detailed traffic-eng policy information: Traffic engineering policy "R1_R11_BLUE_ONLY" Valid config, Active This is an RSVP-TE policy Headend 1.1.1.1, topology-id 101 Endpoint 11.11.11.11, service-loopback 100.0.0.11 Endpoint type: Node, Topology-id: 101, Protocol: isis, Router-id: 0011.0011.0011.00 Setup priority: 7, Hold priority: 7 Reserved bandwidth bps: 100000000 Install direct, protocol pcep, peer 192.168.0.101 Policy index: 3, SR-TE distinguisher: 16777219 Candidate paths: Candidate-path preference 100 Path config valid Metric: igp Path-option: dynamic Affinity-set: BLUE_ONLY Constraint: include-all List: ['BLUE'] Value: 0x1 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.15.11'] Policy statistics: Last config update: 2025-02-11 10:45:37,106 Last recalculation: 2025-02-11 10:45:37.331 Policy calculation took 0 miliseconds
CSPF is calculated towards endpoint 11.11.11.11 but the LSP is signaled towards service loopback 100.0.0.11. Another LSP towards the same destination can be signaled with a different service loopback.
Unfortunately, whether this will work or not, depends on the PCC (router) implementation. From what I tested, it works with Juniper and IP Infusion, even if the service loopback is not advertised in IGP, but doesn’t work with Cisco IOS-XR because it requires RSVP LSP to be signaled strictly towards configured MPLS-TE router-ID and not any other loopback.
On-Demand Nexthop
Another innovation of SR-TE is ODN. Instead of provisioning SR-TE policies proactively, a router can request a controller to calculate a policy only when it receives a service route (e.g. MPLS VPN) with the relevant nexthop.
There is nothing strictly specific to SR here and it’s possible to implement the same solution with RSVP-TE. It’s especially powerful in conjunction with color steering.
Egress Peer Engineering with RSVP-TE
The nice thing about SR is that it organically integrates with EPE: the operator configures policy endpoint and the controller resolves it to either node or egress peer, depending on the BGP-LS topology. In case of EPE endpoint, just one extra label is added to the segment list.
With RSVP-TE this approach won’t work because an LSP must be signaled, and the EPE route can resolve over it. See the picture:
Strictly speaking, it’s possible to use EPE with any MPLS control plane including RSVP-TE. Traffic Dictator supports EPE-only policies and they can resolve over RSVP-TE LSP.
It is possible to automate this a bit further: allow the controller to resolve the endpoint of an RSVP-TE policy to an egress peer, and simultaneously advertise an RSVP-TE LSP via PCEP and an EPE route via BGP-LU.
I didn’t implement it yet in TD but it’s a fairly simple optimization.
SR and RSVP coexistence
This can be useful during a migration from RSVP to SR. Controller maintains a single bandwidth database for all policies, SR, RSVP and EPE. Therefore, it resolves all bandwidth reservation conflicts between SR and RSVP.
SR and RSVP interworking
This is more of a theoretical concept but it can be implemented if required. It’s not as easy as SR-LDP interworking, because RSVP signals a stateful point-to-point LSP and SR is stateless.
Consider the topology:
This requires a binding SID to be provisioned with an RSVP-TE policy1, and SR LSP adding this BSID to the label stack.
Now from RSVP to SR:
The controller provisions an SR LSP from R2 to R3 with BSID 1002, an RSVP LSP from R1 to R2 and a BGP-LU route that resolves via the RSVP LSP that steers traffic into the SR LSP.
Perhaps not the most intuitive setup but it can be useful as a temporary solution for migrations, and the controller can provision all these LSP as one, and react accordingly during topology changes.
Conclusion
An RSVP-TE network can benefit a lot from a good SDN controller: easier configuration and management, more optimal path computation and simplified migration to SR. Traffic Dictator supports PCE-initiated RSVP-TE LSP starting from version 1.3, so consider giving it a try.
References
- Traffic Dictator v1.3 Release Notes https://vegvisir.ie/2025/02/04/traffic-dictator-v1-3-release-notes/
- RSVP-TE policies – https://vegvisir.ie/rsvp-te-policies/
- PCE and PCEP Overview – https://packetpushers.net/blog/pce-pcep-overview/
- Path Computation Element (PCE) Communication Protocol (PCEP) – https://datatracker.ietf.org/doc/html/rfc5440
- Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE – https://datatracker.ietf.org/doc/html/rfc8231
- Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model – https://datatracker.ietf.org/doc/html/rfc8281
- Path Computation Element Protocol(PCEP) Extension for Color – https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-color
- Making Segment Routing user-friendly – https://routingcraft.net/making-segment-routing-user-friendly/
- Poor man’s Traffic Engineering – https://routingcraft.net/poor-mans-traffic-engineering
- Topology Dependent LFA – https://routingcraft.net/topology-dependent-lfa/
Notes
- ^An alternative would be a targeted LDP-over-RSVP session between R2 and R3, and Segment binding TLV advertised for R3 by an SRMS