l Label Switching 2.0 Gbit/s Offered to F 10 Gbit/s 2.5 Gbit/s 10 Gbit/s 10 Gbit/s 10 Gbit/s 40 Gbit/s 8.2 Gbit/s Offered to F Fig. 13.13 Traffic-engineering problem with conventional IP routing. the 10.2 Gbit/s of traffic offered will not be accommodated by the 10-Gbit/s link between C and E. There are some solutions in IP that can help with traffic loading; however, they will have difficulty even with this simple scenario. For example, equal-cost multipath offered by OSPF could split the load evenly between the two paths C, D, E and C, E. However, this would clearly not be a satisfactory solution because, although the 5.2 Gbit/s being offered to C, E is accommodated, the 5.2 Gbit/s offered to C, D, E would overload the D, E link. The problem becomes harder to solve with larger networks. MPLS can solve this type of problem, and this is one of the key applications of MPLS in carrier networks that wish to replace existing circuit-switched systems such as SONET. MPLS can solve the example problem by the use of explicit routes. All of the discussion SO far has assumed that LSPs will follow the path that matches the hop-by-hop IP routing tables. However, RSVP-TE supports the inclusion of an Explicit Route Object (ERO). The ERO is a list of next hops that an LSP should take and is sent in the PATH message of RSVP- TE SO that the LSP is configured over the desired path. This operation is fairly straightfor- ward: A PATH message is transported through the network; rather than it being forwarded using the IP routing tables, it is transmitted to the next entry in the ERO until the LSP egress is reached. Each router records state (such as the ERO) from the PATH message SO that, as the RESV message is sent back from the LSP egress, each LSR can refer to the original ERO to work out the next upstream hop. Using the mechanism provided by RSVP-TE, it is possible to set up LSPs to meet traffic- engineering requirements that might not match the conventional IP forwarding path. Note that conventional IP forwarding and a dynamic r