MPLS Traffic Engineering
As stated in Chapter 10,
MPLS traffic engineering
(MPLS-TE) addresses the following issues (also see Figure B-3):
-
Link congestion
Interior gateway protocol
(IGP) best paths might be
overused
while alternative paths are either
underutilized
or not used at all. For example, in Figure B-3, the link between C and D is never used to forward traffic from A to F. All the packets go through B, which is the path with fewer hops. You can make the IGP use a different
path
by including bandwidth as one of the link metrics for
shortest path first
(SPF) calculation, but this is an approximate science and one that has no notion of congestion.
-
Link protection
If a path or device failure occurs along the primary
link switched path
(LSP) in Figure B-3, routing protocols have to rerun the full SPF calculation before traffic can be forwarded again, which can take several seconds.
-
Load balancing
Standard IGPs allow traffic to be balanced equally across equal-cost paths only. Unequal paths are ignored because the IGP sees them as longer routes to the destination, which is why the C-to-D link in Figure B-3 is not used in the first place.
MPLS-TE calculates shortest paths through a network, but within a given set of constraints using
constraint-based routing
(CBR). The operation is as
follows
(with the final result shown in Figure B-4):
-
All routers in the network run a link-state routing protocol with an extension that uses reservable link bandwidth as a metric.
-
The tunnel headend, Router A in Figure B-4, determines the best path to Router F based on available bandwidth, using a variant of standard SPF called
constrained SPF
(CSPF). CSPF prunes candidate paths from the SPF tree that do not
satisfy
some constraint (in this case, available bandwidth). In Figure B-4, the tunnel needs 40 Mbps. Router A finds the path to be A to C to D to E to F (perhaps because of slow or
congested
links elsewhere). The path appears as a
dotted
line in Figure B-4. As link-utilization conditions change, the CSPF algorithm will give different results for the same destination, which is the intended result.
-
After the path is found, the headend
reserves
a path through the network. Reservation is done using the
Resource Reservation Protocol
(RSVP) to signal label values. The headend sends a PATH message to the far end of the tunnel. The RSVP message follows the intended path of the tunnel, as defined by the CBR calculation.
-
Each LSR along the path checks whether it can allocate the
requested
bandwidth to the tunnel and updates the RSVP payload
accordingly
.
-
The remote endpoint sends an RSVP RESV message back along the tunnel path.
-
When it receives the RESV message, each LSR along the path reserves the bandwidth and
allocates
a label for the tunnel. The label data is communicated to the upstream LSR in the RSVP message. In more informal terms, the PATH message asks routers "
please
reserve this amount of bandwidth to this destination?" The RESV reply says "yes, I did so and here is the label to use to access the bandwidth I just set aside." Remember, though, that RSVP is a control plane reservation mechanism. Standard interface QoS mechanisms are required to implement policy.
-
After they are built, the tunnels, which appear as an IOS interface, still need to be included in the routing tables before a router can use them. You can do this with simple static routes on the headend router or by announcing it through the IGP as a directly connected path. Policy routing is a third option.
-
The tunnel is ready for use, with the label values defined at each hop along the LSP.
|
