MPLS-TE Basics, Pt. 1 (TED)
MPLS-TE (Traffic Engineering) is very deep topic. In this series of articles we will cover MPLS-TE’s basic operations. MPLS-TE is used to manually or dynamically determine LSPs based on criteria other than the IGP best path. With MPLS-TE you can manually specify every single hop an LSP should take, or you can have the LSP automatically determined based on criteria such as: the bandwidth required, link “colors” to avoid, interface metrics, and more. This automatic determination uses CSPF (Constrained Shortest Path First) which is just normal SPF but run on a pruned-down version of the topology. The pruning of links in the topology is based on the specified constraints. If an interface is the wrong “color”, cannot provide the bandwidth required, etc, it is pruned from the topology.
MPLS-TE uses RSVP with extensions, which is called RSVP-TE. You probably remember RSVP from the QoS series, in which it was used with IntServ. IntServ never took off, but RSVP had a few extensions added in order to support MPLS-TE, and has become a popular control plane for MPLS-TE. There are other options for MPLS-TE besides RSVP though, such as Segment Routing, but that will not be covered in this series. Just be aware that RSVP-TE is not the only way to accomplish MPLS traffic engineering.
RSVP reserves bandwidth along an LSP hop-by-hop. An RSVP PATH message is created by the headend (ingress PE) and contains the bandwidth required for this LSP along with an explicit hop list. The routers along the specified path reserve bandwidth on their interface for this LSP, but this bandwidth reservation is not related to QoS. RSVP itself does not police the bandwidth, is it simply an admistrative bandwidth reservation that prevents too many LSPs from using the interface.
When the tailend (egress PE) receives the RSVP PATH message, it generates an RSVP RESV message which takes the reverse path back to the headend. This message is used to advertise the label for this LSP (or “tunnel”) to each router. Since the RESV message takes the reverse path, a router will receive a RESV message with its next-hop neighbor’s label, and add this label to its LFIB.
In order for the ingress router to determine the path, it uses CSPF (Constrained Shortest Path First). The constraints could be that the interface needs to have 500M of bandwidth available, or that the “color” cannot be red, or that all links must be “blue,” or that Gi0/0/0/1 on R3 must be avoided. The possibilities are numberous. The main thing to understand is that only the ingress router runs CSPF. Running CSPF produces an ERO (explicit route object) which is a list of the hop-by-hop IPs the LSP will travel. RSVP then sets up the path based on this result. The RESV PATH message includes the ERO which forces the PATH message to go along the ERO that the headend router created.
RSVP reserves labels on a per-tunnel/per-LSP basis. In comparison, LDP reserves labels on a per-prefix basis. RSVP requires state in the network, as every router along the path of the LSP needs to “remember” and reserve bandwidth for this LSP. Additionaly, the LSP is refreshed every 30 seconds. In comparsion, Segment Routing requires no state at all, as the headend can simply pre-program a list of segments onto the packet.
Don’t worry if this is a little confusing right now. We will cover of all these points in much greater detail as we work through setting up MPLS-TE in our lab.
Lab
For this lab, we will re-use the ISIS Multi-topology lab. R1 will be the headend and XR5 will be the tailend. As you can see, the IGP shortest path is R1-R2-XR3-XR5. We will use MPLS-TE to force traffic to take the path R1-R2-R4-XR3-XR5.
In order to configure MPLS-TE, we have to configure the feature globally and on a per-interface basis. Additionally we need to configure the IGP (ISIS) to support MPSL-TE. This is necessary because ISIS advertises the bandwidth allocations of every RSVP-enabled interface in the area. ISIS also advertises the “colors” or link affinities that I mentioned earlier. ISIS and OSPF were extended to support MPLS-TE. ISIS adds TLVs or functionality to existing TLVs, and OSPF adds the Opaque LSAs. The ISIS TLVs require wide metrics, so we’ll need to change from normal to wide metrics in our lab as well.
Before we go any further, let’s verify that MPLS-TE is active and examine the R1.00-00 LSP.
We did not turn on LDP in this lab, so the “IP” column shows “No.” However you can see that MPLS is active on the interface for the “Tunnel” column. “Tunnel” indicates MPLS-TE.
mpls traffic-eng tunnels activates RSVP on the interface. However, no bandwidth has been reserved for RSVP, as seen by the i/f max and flow max columns showing 0.
Let’s define the reservable bandwidth for RSVP on the interface. By default if we simply execute ip rsvp bandwidth it will use 75% of the interface’s bandwidth for RSVP. We can optionally specify a bandwidth in kbps or percent.
Let’s look at the traffic-engineering database, also known as the TED. This is the database that is used to run CSPF. The ISIS TLVs and OSPF Opaque LSAs feed the TED with traffic-engineering information such as bandwidth availability, link affinities, etc.
So far we only see information about R1, but once we turn on MPLS-TE on all routers, we will see every router’s TE information in this database. Notice that there are 8 classes (0-7) for reservable bandwidth. This allows a tunnel to be given a priority and preempt other less important tunnels. More on this in a future article.
Also pay attention to the fact that there is both a TE metric and IGP metric, and both are 10. The TE metric by default is the IGP metric, and is used when running CSPF. However, you can manually specify the TE metric and keep the IGP metric as it is. This way your TE topology and IGP topology can have completely different metrics and best paths. You might let your IGP metric represent bandwidth and TE metric represent latency in msec. This gives you a lot of flexibility without messing with your actual IGP topology.
One interesting thing to note is that you can tell CSPF to use the IGP metric instead of TE metric with the command tunnel mpls traffic-eng path-selection metric igp. However you normally wouldn’t need to do this, as by default the TE metric is the IGP metric, so you would have to change the TE metrics purposefully, and then decided not to use them!
Next to the metrics, you can see the attribute flags, which is used for link color or affinity. We will take a closer look at this later.
Let’s now examine the R1.00-00 LSP. We need to use the verbose keyword instead of detail to see the information under the extended TLVs that enable MPLS traffic-engineering. Specifically these TLVs are 134 (TE router ID) and TLV 22 (Extended IS reachability)
Notice all the detail under the information about the reachability to R2. You can see all 8 priorities and the unreserved (available) bandwidth for each. We have no reservations yet, so all 8 priorities have 750M available. You see the TE weight and affinity as well.
Now that we have examined the TED and have seen how ISIS advertises TE information for a link, we’ll turn on MPLS-TE for all other routers:
As you might guess, enabling MPLS-TE in XR is done under separate configuration stanzas instead of under the interface.
On R1 let’s examine the TED again:
There is a single 5-line section for every interface in the topology. R1 can now calculate a bestpath that takes into account the TE metric, available bandwidth on all interfaces, etc.
In the next article we will begin building our TE tunnels and explore how RSVP works.
Last updated
