outing protocol are still needed SO that the MPLS signaling protocols, and other control and management messages, can be transported using IP. Consider a solution to the problem set in Figure 13.13 using MPLS with RSVP-TE and using explicit routes. The traffic offered to A can be sent over A, C, D, E, F, while the traffic offered to B can be sent over B, C, E, F. Simple inspection shows that the traffic offered matches network capability. This would not be possible using conventional, destination address-based IP forwarding. The MPLS standards do not state how these explicit routes are planned. While there are schemes that allow a distributed approach to automatic traffic engineering, most network operators prefer to take a centralized, planning-based approach for the configuration of traffic trunks as supported by MPLS. Consequently, it is likely that an MPLS network using traffic engineering to control QoS will have a centralized path allocation system that links with billing and service-level systems. The path allocation Traffic Engineering system will use SNMP to initiate the RSVP-TE signaling that provisions LSPs, as described in RFC 3812. A discussion of path allocation systems for QoS in MPLS is given by Marzo (2003). It was earlier stated that MPLS provides the notion of hierarchical LSP tunnels. The main mechanism for provisioning these tunnels is RSVP-TE, and they are often simply termed "TE tunnels." These tunnels can be configured only edge to edge. Alternatively, they can be placed in certain parts of the network to aggregate traffic into trunks that can be used to route traffic around points of congestion. In this latter case, hierarchical LSP tunnels can be created as shown simplistically in Figure 13.7; this figure will be used to explain the sig- naling requirements for these tunnels. In the case where an LSP tunnel is used, it should be noted that the LSRs at the ingress and egress of the tunnel (W, X, Y, and Z) are members of both levels of the hierarchy. This means that for the purposes of sig