Cisco and Juniper Networks, the largest providers of network devices, chose to work with and extend an IETF standardized protocol, RSVP, rather than develop a new label distribution protocol. Developing a new protocol involves huge efforts in designing, standardizing, developing, deploying and debugging. Since RSVP is the only IETF standard for QoS signaling in IP networks, it was extended to support the establishment and maintenance of explicitly routed LSPs.
RSVP is used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver QoS requests to all nodes along the path(s) of the flows and to establish and maintain state to provide the requested service. RSVP is a control protocol that sets up a reservation, but enforcement of the reservation needs to be done by another component of the architecture.
The principle characteristics of RSVP are:
- It provides reservations for bandwidth in multicast trees (unicast is handled as a degenerate case of multicast).
- It is receiver-oriented i.e. the receiver of the data flow initiates and maintains the resource reservation used for that flow.
- It is a soft state protocol, hence providing support for dynamic membership and routing changes.
- RSVP requests resources for simplex flows, i.e., it requests resources in only one direction.
- RSVP provides reservation models for a variety of applications. The three reservation models/stylesare fixed filter style, wildcard filter style, shared explicit style.
- RSVP is routing protocol independent i.e. it uses underlying routing protocols to determine theroutes of the flows.
Each node capable of resource reservation has several modules that work together, as shown below:
An application requests a certain quality of service from the RSVP demon running on the host. The demon checks with a policy control module to see if the user has administrative permission to make a reservation. The RSVP demon also checks with an admission control module to find out whether the node has sufficient resources to supply the requested QoS. The classifier and packet scheduler modules on every node are responsible for the quality of service given to a flow for which a reservation has been made. The classifier looks at every data packet to determine whether the appropriate flow has a reservation and which QoS the flow should get.
The packet scheduler then makes the forwarding decision according to the QoS class. For example, the packet scheduler decides in which queue to put the packet. The packet scheduler is a key component of the architecture because it actually gives different services to different flows. To ensure that flows receive their requested quality of service, the packet schedulers on all nodes must support the distinction between different services.
Sudeep Goyal is into technology and loves the idea of sharing his knowledge through blog .