otocol, used by hosts and routers to signal QoS in the network. It also introduces flowspecs, which are definitions of traffic flow according to traffic and QoS characteristics. Finally, IntServ introduces traffic control, which delivers on QoS by controlling traffic flows within the hosts and routers. IntServ is a per-flow resource reservation model that requires RSVP. Its key building blocks include resource reservation and admission control. In IntServ, data transmissions are built around a flow, a unidirectional path with a single recip- ient. In routing, traditional routers examine packets and determine where to send them and then switch them to output ports. With IntServ, routers must also apply the appropriate queuing policy if packets are part of a flow. IntServ routers usually use first-in, first-out (FIFO) queuing. This is fast and easy, but it can make delay-sensitive applications wait behind long bursts of delay- insensitive data. IntServ uses Fair Queuing to ensure that a single flow does not use all the bandwidth and to provide minimal guarantees to different flows. The IntServ model involves a classifier. Packets are mapped to a service class, and they are forwarded by a packet scheduler, based on their service class (see Table 10.4). Admission control determines whether the requested QoS can be delivered, and, as mentioned earlier, the setup protocol is RSVP. RSVP relies on router-to-router signaling schemes, which allow IP applications to request priority delay and bandwidth guarantees. Connections are established link by link, and a connection can be denied if a router cannot accept the request (see Figure 10.12). RSVP is particularly well suited for real-time applications and delay-sensitive traf- fic. RSVP allows applications to reserve router bandwidth. RSVP-guaranteed ser- vice provides bandwidth guarantees and a reliable upper bound to packet delays. But the resource requirements for running RSVP on a router increase proportion- ately with the number of separate RSVP reservations. This scal