loyed, and the first of these needs described here is traffic engineering. The architecture for traffic engineer- ing using MPLS is described in RFC 2702. Chapter 13 Multiprotocol Label Switching Traffic Engineering (TE) can be broken up into two tasks: Traffic-oriented TE forwards packets such that the QoS required by the end application can be controlled. Resource-oriented TE manages the resources in the network by sending traffic over appropriate paths such that the load is evenly spread through the network. Conventional IP has not been very successful at performing either of these tasks because of its inherent connectionless nature and the fact that the forwarding and control functions are closely bound together. There have been attempts at providing IP QoS mechanisms for traffic-oriented TE in the form of IP Integrated Services (IntServ) and IP Differentiated Services (DiffServ). While these (in particular DiffServ) have had some limited success, they have not achieved wide- spread adoption in the manner that was originally envisaged and have many problems with deployment. MPLS does not provide an alternative QoS model; instead, it can be said to support IntServ and DiffServ SO that they can be deployed in a more straightforward manner. Integrated Services IntServ is an IP QoS architecture described in RFC 1633 whereby application flows of real-time services (e.g., video and voice) can have state allocated in routers such that the committed datarate and/ or the delay through the routers is controlled within certain bounds. IntServ is a fine-grained approach to IP QoS because each individual flow has resources allocated on every router along the path from sender to receiver. To reserve the resources allocated in each router requires a signaling protocol, and for IntServ this is the Resource Reservation Protocol (RSVP), as defined in RFC 2205. RSVP operates as shown in Figure 13.10, which shows that there are two signaling mes- sages, termed PATH and RESV. Before a reservation of resources is performed, the tr