The protocol that has been devised to establish a reservation in the network for particular flow classes is called the Resource ReserVation Protocol, or RSVP [Zhang, 94]. It might be more accurate to describe it as a dual function protocol, that serves to install knowledge about classes of traffic in the network (a filter specification) as well as what particular type or quality of service that these flows will need (a flow specification). This separation is important, as the filter specification can be re-used in a number of ways. The simplest way that the filter specification is reusable is the fact that it can refer to a flow received by an application, rather than to one that is sent. This means that a sender can send video at a rat convenient to them, but that receivers can select the sub-band rates that are most convenient to each of them. This receiver based reservation is quite different from the telephony model of how to do things, and fits well with the multicast model described in some detail in the next chapter - it is a bit like the way people can choose what size TV screen they have independent of the TV transmitted signal (or choose whether the TV is color, or black & white, or has mono or stereo audio), The second way that the filter generalizes the idea of a reservation is that it can include a wild card, so that it can refer to groups of sources. For example, in an audio conference, there is no necessity to set aside resources for all the audio feeds at once, since humans are typically capable of organizing themselves in a conversation so that there is only one (or one and a bit!) person speaking at any one time. Hence, sources will ask for reservations that are only marginally more than a unicast audio reservation for a multi-way audio conference. Flow Specifications are cast in terms of the class of service, combined with the quantitative parameters as needed. For example, a mean rate combined with a burstiness (also known as Leaky Bucket parameters by analogy with a water bucket with a given volume and size of leak) suffice to characterize many applications. Future versions of the Internet Protocol will incorporate tags (known as Flow Identifiers) which may make the classification of packets by newer routers a more efficient task. Again, the Flow identifier has been designed with possible future bearer networks such as ATM in mind. Thus it is 24 bits in size, just as the VCI/VPI field is in ATM used for roughly the same function.
|