particular flow and what forwarding treatment to provide. RSVP is a network control protocol that enables applications to obtain prescriptive QoS for the application data flows. Such a capability recognizes that different applications have different network performance requirements. Some applications, including the more traditional interactive and batch applications, require reliable delivery of data but do not impose any stringent requirements for the timeliness of delivery. Newer application types, including videoconferencing, IP telephony, and other forms of multimedia communication require the opposite: Data delivery must be timely but not necessarily reliable. Thus, RSVP was intended to provide IP networks with the ability to support the divergent performance requirements of differing application types. Figure lists the characteristics of RSVP. RSVP is an IP protocol that uses IP protocol ID 46 and TCP and UDP port 3455. It is important to note that RSVP is not a routing protocol. RSVP works in conjunction with routing protocols and installs the equivalent of dynamic access control lists (ACLs) along the routes that routing protocols calculate. Thus, implementing RSVP in an existing network does not require migration to a new routing protocol. In RSVP, a data flow is a sequence of datagrams that have the same source, destination (regardless of whether that destination is one or more physical machines), and QoS requirements. QoS requirements are communicated through a network via a flow specification, which is a data structure that is used by internetwork hosts to request special services from the internetwork. A flow specification describes the level of service that is required for that data flow. RSVP focuses on the following two main traffic types:

• Rate-sensitive traffic: Traffic that requires a guaranteed and constant (or nearly constant) transmission rate from its source to its destination. An example of such an application is H.323 videoconferencing. RSVP enables constant-bit-rate service in packet-switched networks via its rate-sensitive level of service. This service is sometimes referred to as guaranteed-bit-rate service.
• Delay-sensitive traffic: Traffic that requires timeliness of delivery and that varies its rate accordingly. MPEG-II video, for example, averages about 3 to 7 Mbps, depending on the rate at which the picture is changing. RSVP services supporting delay-sensitive traffic are referred to as controlled-delay service (non-real-time service) and predictive service (real-time service).

---

Content 3.3 Selecting an Appropriate QoS Policy Model 3.3.5 RSVP Operation Unlike routing protocols, RSVP manages flows of data rather than making decisions for individual datagrams. Data flows consist of discrete sessions between specific source and destination machines. The definition of a session is a simplex flow of datagrams to a particular destination and transport layer protocol. The following data identifies the sessions: destination address, protocol ID, and destination port. RSVP supports both unicast and multicast simplex sessions. In the context of RSVP, QoS is an attribute specified in flow specifications that determine how participating entities (routers, receivers, and senders) handle data interchanges. RSVP specifies the QoS used by both hosts and routers. Hosts use RSVP to request a QoS level from the network on behalf of an application data stream. Routers use RSVP to deliver QoS requests to other routers along the path(s) of the data stream. In doing so, RSVP maintains the router and host state to provide the requested service. To initiate an RSVP multicast session, a receiver first joins the multicast group specified by an IP destination address by using the Internet Group Membership Protocol (IGMP). After the receiver joins a group, a potential sender starts sending RSVP path messages to the IP destination address. The receiver application receives a path message and starts sending appropriate reservation-request messages specifying the desired flow descriptors using RSVP. After the sender application receives a reservation-request message, the sender starts sending data packets. How does RSVP work?
Figure illustrates the RSVP daemon found in each node capable of resource reservation. Each node that uses RSVP has two local decision modules:

• Admission control: Admission control keeps track of the system resources and determines whether the node has sufficient resources to supply the requested QoS. The RSVP daemon monitors both of these checking actions. If either check fails, the RSVP program returns an error message to the application that originated the request. If both checks succeed, the RSVP daemon sets parameters in the packet classifier and packet scheduler to obtain the requested QoS.
• Policy control: Policy control determines whether the user has administrative permission to make the reservation.

If both Admission control and Policy control succeed, the daemon then sets parameters in two entities, packet classifier and packet scheduler.

• Packet classifier: The RSVP packet classifier determines the route and QoS class for each packet.
• Packet scheduler: The RSVP packet scheduler orders packet transmission to achieve the promised QoS for each stream. The scheduler allocates resources for transmission on the particular data link layer medium used by each interface.
• Routing Process: The RSVP daemon also communicates with the routing process to determine the path to send its reservation requests and to handle changing memberships and routes. Each router participating in resource reservation passes incoming data packets to a packet classifier and then queues the packets as necessary in a packet scheduler.

Once the packet classifier determines the route and QoS class for each packet, and the scheduler allocates resources for transmission, RSVP passes the request to all the nodes (routers and hosts) along the reverse data paths to the data sources. At each node, the RSVP program applies a local decision procedure called admission control to determine whether that node can supply the requested QoS. If admission control succeeds in providing the required QoS, the RSVP program sets the parameters of the packet classifier and scheduler to obtain the desired QoS. If admission control fails at any node, the RSVP program returns an error indication to the application that originated the request. Routers along the reverse data stream path repeat this reservation until the reservation merges with another reservation for the same source stream. RSVP is not a routing protocol, but rather an internet control protocol. RSVP relies on the underlying routing protocols to find where it should deliver reservation requests. When an RSVP-managed flow changes its path, the routing module will notify the RSVP module of the route changes. In this way, RSVP can quickly adjust the resource reservation to new routes. Reservation Merging
When a potential receiver initiates a reservation request, the request does not need to travel all the way to the source of the sender. Instead, it travels upstream until it meets another reservation request for the same source stream. The request then merges with that reservation. Figure shows how the reservation requests merge as they progress up the multicast tree. Reservation merging leads to the primary advantage of RSVP, scalability. This allows a large number of users to join a multicast group without significantly increasing the data traffic. RSVP scales to large multicast groups. The average protocol overhead decreases as the number of participants increases. Note
Practical issues of latency and propagation make it impossible to deploy RSVP or any new protocol at the same moment to all points throughout the entire Internet. Indeed, RSVP can never be deployed everywhere. To support the connection of RSVP networks through non-RSVP networks, RSVP supports tunneling, which occurs automatically