protocol and if it was installed at all per- ceived bottleneck nodes of the network. They could run the controlled-load level of service with RSVP messages tunneled through other parts of the network, but this situation turns out to be difficult to manage. Running IntServ imposes large computational (in central processing unit [CPU] cycles) and buffering loads (which are in proportion to the actual number of flows) to routers all over the network. This is one of its weak points. Since it is preoccupied by the flow's fate at the packet level, it neces- sarily splits traffic logically into numerous flows. However, without aggregating them into classes before launching the traffic into the network, the processing load is obviously commensurate with IntServ sessions. Therefore, it does not scale well into large core networks. Its undeniable capability to guarantee network performance and QoS levels by merely applying similar mechanisms to the ones used by circuit-switching networks when they decide, for example, on call admission has earned it friends for its abilities, and foes for delegating the advantages of packet switching to the proverbial second seat. DiffServ A different approach is taken by RFC 2475, which defines the Differentiated Services (DiffServ) pro- tocol. DiffServ is computationally a much more realistic approach than IntServ. Based on its wide- scale acceptance by vendors, it seems to represent a promising and major attempt to implement an acceptable base platform upon which elaborate QoS can run. DiffServ uses the previously defined TOS bits. Upon them, it builds a series of aggregate flows. We discussed multifield classification and the five-tuple lookup algorithm in previous chapters. The result of the classification process is that each packet is assigned to one of many flows. This is done by deriving a 6-bit value, which the DiffServ specification calls the DiffServ Code Point (DSCP). The DSCP is written into the DS field of the packet header. More specifically, it is the TOS octet in the IPv4