Traffic Engineering · Topic 2 of 3
RSVP, Static Paths and Dynamic Paths with CSPF
Learn how RSVP signals a TE tunnel with Path and Resv messages, and how static explicit paths differ from dynamic paths calculated by CSPF with OSPF.
- 5 min
- Includes a diagram
- RSVP signals TE tunnels using Path and Resv messages.
- Path travels toward the tail end, and Resv returns toward the head end.
- RSVP is soft state, so refreshes keep the tunnel alive.
What it is
RSVP sets up a TE tunnel hop by hop, and the path it follows is either listed by hand or calculated by CSPF.
A static path is an explicit list of routers that you write. A dynamic path is worked out by the head end using CSPF, which stands for constrained shortest path first.
Both kinds of path are then signalled in the same way, using RSVP.
How it works
The head end chooses a path, then RSVP walks it forward with a Path message and back with a Resv message.
RSVP signalling
RSVP for traffic engineering uses two main messages.
| Message | Direction | Job |
|---|---|---|
| Path | Head end toward tail end | Describes the tunnel and the route it should follow |
| Resv | Tail end toward head end | Confirms the tunnel, reserves bandwidth and passes labels |
The Path message travels along the chosen route, one router at a time. Each router remembers the previous hop.
The tail end answers with a Resv message, which returns along the same route. Each router in turn picks a label and tells the router before it.
When the Resv reaches the head end, the tunnel is up and carries labels from end to end. RSVP is a soft state protocol, so the routers keep the tunnel alive by exchanging refresh messages. If they stop, the tunnel is removed.
If a router cannot meet the request, for example because it has no spare bandwidth, it sends an error message back and the tunnel does not come up on that route.
Enabling TE on the links
Each interface that takes part is listed under the TE interface menu, which is also where the bandwidth of the link is stated.
/mpls traffic-eng interface add interface=ether1
/mpls traffic-eng interface add interface=ether2
/mpls traffic-eng interface printStatic path
A static path lists the routers the tunnel must cross. The head end does not calculate anything. It sends the Path message along exactly that route.
/mpls traffic-eng tunnel-path add name=via-r2 use-cspf=no hops=10.0.1.2,10.0.2.2
/interface traffic-eng add name=te1 to-address=10.255.255.3 primary-path=via-r2Hops can be strict or loose in the general MPLS model. A strict hop must be the next router.
A loose hop may have other routers in between. Check the console help for the exact way RouterOS writes the hop type.
The advantage is full control. The disadvantage is that nothing adapts. If a listed link fails, the tunnel is down until the path is changed or a secondary path takes over.
Dynamic path and CSPF
With a dynamic path, the head end calculates the route. CSPF is a shortest path calculation that first removes links that do not meet the constraints, such as not enough free bandwidth.
CSPF needs to know the topology and the free bandwidth on every link. The interior protocol provides this. On RouterOS, OSPF is used, and the OSPF instance has settings for the TE area and the TE router ID.
/routing ospf instance set default mpls-te-area=backbone mpls-te-router-id=lo
/mpls traffic-eng tunnel-path add name=auto use-cspf=yes
/interface traffic-eng add name=te1 to-address=10.255.255.3 primary-path=autouse-cspf=yesmakes the head end calculate the route.mpls-te-areaandmpls-te-router-idallow OSPF to share TE information.- If the topology changes, the tunnel can be recalculated onto another route.
Comparing static and dynamic
| Point | Static path | Dynamic path with CSPF |
|---|---|---|
| Who chooses the route | The administrator | The head end |
| Needs OSPF TE data | No | Yes |
| Reacts to a failure | No, unless a secondary path exists | Yes, a new route can be found |
| Takes bandwidth into account | Only when RSVP checks it | Yes, as a constraint |
A tunnel can have both a primary path and one or more secondary paths. The secondary path takes over if the primary fails.
If a dynamic tunnel will not come up, check OSPF TE settings first. CSPF cannot calculate without link information.
What to remember for the exam
Seven facts cover most questions here.
- RSVP signals TE tunnels using Path and Resv messages.
- Path travels toward the tail end, and Resv returns toward the head end.
- RSVP is soft state, so refreshes keep the tunnel alive.
- A static path is an explicit hop list, with
use-cspf=no. - A dynamic path is calculated by CSPF, with
use-cspf=yes. - CSPF removes links that do not meet the constraints and then runs shortest path.
- CSPF needs TE information from OSPF, using the MPLS TE settings on the instance.
A static path never recalculates. If a listed hop fails, the tunnel stays down until a secondary path or an edit fixes it.
Common mistakes
These four errors are common.
Expecting CSPF to work without OSPF TE data. There is no topology for it to use.
Forgetting to list the interfaces under TE. Only enabled interfaces can carry the tunnel.
Writing a static hop list with a wrong address. The Path message cannot follow the route and the tunnel does not come up.
Assuming a static path adapts. It does not change unless you change it.
Check yourself
Work through these three questions.
What do the RSVP Path and Resv messages do?
Path travels from the head end to the tail end and describes the tunnel. Resv returns the other way, reserves bandwidth and passes labels.
How does a dynamic path differ from a static path?
A dynamic path is calculated by the head end with CSPF, set with
use-cspf=yes. A static path is a hop list you write, withuse-cspf=no.What does CSPF need from OSPF?
It needs the topology and the free bandwidth on each link. The OSPF instance shares this through its TE settings.
Topic 2 of 3 in Traffic Engineering
Test yourself on Traffic Engineering
The full MikroTik MTCINE question bank has 475 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by MikroTik. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.