 that are an aggregate for the traffic trunk, and thus LSRs along the path only need to maintain state for one resource reservation, which is directly inferred from the packet label rather than from a complex lookup on the packet header, which was the case with IntServ. It should be pointed out that deploying RSVP-TE to set up traffic-engineered trunks is not the same as deploying IntServ; it is just that the RSVP protocol has been used for a dif- ferent application. Of course, using RSVP-TE does not preclude the use of IntServ (using standard RSVP) in the networks attached to the MPLS core (or in the core itself); in fact, it helps to support it. For example, there might be many RSVP sessions in a customer's edge network that need to pass through an operator's MPLS core to get to another of the cus- tomer's networks. Using IntServ, the customer needs to negotiate every RSVP session with the operator's network. This is clearly problematic and makes it hard for the operator to audit requests for resource allocation; in fact, it makes it SO hard that this is never used in practice. However, if the customer requests just one traffic trunk from the operator, then this is a scalable solu- tion and it is then up to the customer to decide how many RSVP sessions it wishes to pass through this traffic trunk. This effectively forms an overlay for the RSVP sessions. However, we will see when we consider MPLS VPNs that it is possible to still maintain peering at the IP layer. Differentiated Services DiffServ was proposed in RFC 2475 as a scalable alternative to IntServ. Rather than using a fine-grained signaling of resources, as used in IntServ, DiffServ marks packets with a broad class of service. As IP packet definitions did not originally contain a DiffServ field, DiffServ architects chose to redefine the rarely used IP type of service field and use 6 bits for the DiffServ Code Point (DSCP), as specified in RFC 2474. Each DSCP is mapped to a unique class of service that routers should observe through a predefined Per-Hop 