affic source sends out a PATH message, which defines the parameters of the traffic flow in terms of its mean datarate and peak datarate (specified using a token bucket). This PATH message passes from source to sink, and each router along the path notes it but does not reserve router resources at this stage. When the traffic sink receives the PATH message it knows parameters of the traffic and can then determine what resources should be reserved. The reservation in terms of delay and traffic rate requirements is specified in a RESV message, which originates at the traffic sink and passes back toward the traffic source. Traffic Source 1: PATH Traffic 2: RESV Fig. 13.10 RSVP signaling protocol for IntServ. Traffic Engineering The RESV message is processed by each router along the path, and the routers reserve buffer resources to meet the demands of the service (assuming that the traffic sink is autho- rized to do so). Both the PATH and RESV messages use datagram transport (rather than TCP) and SO cannot be transmitted reliably. Consequently, RSVP uses a soft-state mechanism whereby the PATH and RESV messages are repeated periodically (30 seconds by default). If a set number of messages are missed (typically three), then it is assumed either that there is a problem or that the reservation is no longer needed; in either case the routers will remove the resource allocations. IntServ with RSVP was seen as a highly positive contribution to IP QoS in the 1990s when it was introduced. However, there are difficulties with practical deployment. The main difficulty is that IntServ is not scalable for use in core networks and thus, because resources cannot be allocated from end to end, it has limited practical use. The scalability problem can be seen if it is imagined that IntServ was used to control the quality of voice over IP (VoIP). If a 10-Gbit/s backbone is used to carry predominantly VoIP for a national voice carrier network, it is likely that there could be on the order of 100,000 voice calls passing through a router a