t any one time. If each of these has to have state allocated individually for each VoIP call (as is required by IntServ), then the routers are likely to be severely over- loaded with the work needed to classify each packet and check that it has the necessary resources allocated on each output buffer to handle the packet flow. RSVP-TE Although IntServ itself is not a practical solution for IP QoS in a core network, the RSVP protocol was identified as suitable for distributing labels in an MPLS network that requires traffic engineering. To support MPLS, RSVP was extended and the scope of operation was changed to form RSVP-TE, as defined in RFC 3209. The main extension incorporated in RSVP-TE is that a label request object was added to the PATH message and a label- mapping message was added to the RESV message. Because LSRs using RSVP-TE request labels to be sent, and the label bindings are sent from downstream node to upstream node, RSVP-TE is said to use downstream on-demand label distribution mode with ordered LSP control. The other significant change in RSVP-TE, compared to RSVP for IntServ, is that the scope of the messages is no longer from application sender to application receiver; instead, it is from LSP ingress to LSP egress, as shown in Figure 13.11, where the LSP is set up by RSVP-TE. By specifying that the RSVP-TE signaling only apply to the LSP and not to every Traffic Source Egress Ingress Traffic (label = 32) (label = 91) RSVP Signaling Not Used Here Fig. 13.11 PATH and RESV messages in RSVP-TE. Chapter 13 Multiprotocol Label Switching application flow, the problem of scalability found with RSVP used in IntServ is removed. This can be demonstrated by repeating the example of 100,000 VoIP calls through a path in the network discussed earlier with IntServ. With RSVP-TE, instead of allocating resources for each voice call, a single LSP can be set up that is dimensioned to carry the required number of voice calls. This LSP is often termed a traffic trunk. By using RSVP-TE, the LSP can have QoS parameters