ure 8.16. This routing is based on the knowledge of the whole traffic request, that in reality the control plane does not have, and achieve a lesser overall cost by using two times the link DC even if it is the most expensive of the network, and obtaining in return the possibility to better distribute the weights of all the GLSPs. This example shows that if the traffic is completely known, routing solutions better, and sometimes much better, then the routing produced by protocols like OSPF-TE or IS-IS can be produced. As a consequence, generally a traffic engineering tool is incorporated into the network manager. It has the scope to route the traffic that the network is managing in an optimized way with respect to OSPF. Telecommunication Networks Length (variable) Class (20) Class-type (1) Length Sub-object content FIGURE 8.17 Length Sub-object content RSVP-TEmessagestructure. From time to time, the deviation of the real routing achieved by OSPF-TE or IS-IS from the solution found through the traffic engineering tool becomes important and it is man- datory to reroute a certain number of GLSPs to optimize the network and avoid waste of resources. In order do that is must be possible to force the routing of a GLSP along a predeter- mined route. Using RSVP-TE this can be done introducing in the Path and Resv mes- sages exchanged during GLSP state installation the EXPLICIT_ROUTE object (ERO, see Figure 8.17). When used in Path messages, the ERO describes the next and previous hop for any GLSR along the explicit route. When signaling paths explicitly use an ERO, path state is not needed to indicate a reverse route, since returning Resv messages can instead be routed based upon the ERO. In practice, when dealing with large networks composed by many layers and a huge number of paths, the use of automatic routing protocols to route GLSPs is SO inefficient and explicit routing would be SO frequent that there is a proposal to use rout- ing protocols to route packets in the control plane and adopting explicit routing throug