Integrated Services / Resource Reservation Protocol

Resource-Based CAC 607

described traffic profile. The network fulfills its commitment by maintaining per-flow state and then performing packet classification, policing, and intelligent queuing based on that state.

The Resource Reservation Protocol (RSVP) defines the messages used to signal resource admission control and resource reservations conforming to IntServ. When the application signals the required level of service, if resources are available, the network devices accept the RSVP reservation.

To provide the committed service levels, the networking devices must identify packets that are part of the reserved flows, and provide appropriate queuing treatment. When committing service to a new flow, Cisco IOS installs a traffic classifier in the packet-forwarding path, allowing the network devices to identify packets for which a reservation has been made. To provide the required service level, Cisco IOS uses existing QoS tools.

Most networks that use RSVP and IntServ also use DiffServ features as well. For instance, the same queuing tool that provides minimum bandwidth commitments for DiffServ can also be used to dynamically reserve bandwidth for IntServ and RSVP. As noted in Chapter 2, DiffServ does scale much better than IntServ. Cisco has a relatively new feature called RSVP aggregation, which integrates resource-based admission control with DiffServ, which allows for better scalability, but with strict QoS guarantees for prioritized traffic, such as VoIP calls.

RSVP Levels of Service

To request a level of service from the network, the acceptable levels of service must be defined. Currently RSVP defines three distinct levels of service:

The guaranteed QoS level of service is used to guarantee that the required bandwidth can be provided to a flow with a fixed delay. This service makes it possible to provide a service that guarantees both delay and bandwidth. This type of RSVP service is used by voice gateways when reserving bandwidth for voice flows.

The controlled-load level of service tightly approximates the behavior visible to applications receiving best-effort service under uncongested conditions from the same series of network elements. So, if the application can work well when the network is uncongested, the controlled load level of RSVP service can work well. If the network is functioning correctly with controlled-load service, applications may assume the following:

•Very low loss—If the network is not congested, queues will not fill, so no drops occur in queues. The only packet loss occurs due to transmission errors.

•Very low delay and jitter—If the network is not congested, queues will not fill, and queuing delay is the largest variable component of both delay and jitter.

Resource-Based CAC 609

Path messages describe the level of service required for a particular flow through the use of the Sender_Tspec object within the message. The Sender_TSpec object is defined by the sending application and remains in tact as the path message moves through the network to the receiving application. Also included in the path message is the ADSpec object. The ADSpec object is modified by each intermediary router as the RSVP path message travels from the sending application to the receiving application. The ADSpec object carries traffic information generated by the intermediary routers. The traffic information describes the properties of the data path, such as the availability of the specified level of service. If a level of service described in the ADSpec object is not implemented in the router, a flag is set to alert the receiving application.

Effectively, the Sender_Tspec states what the application needs, and the ADSpec allows each successive router to comment on the level of service it can and cannot support. The receiving application can look at both settings and decide whether to accept or reject the reservation request. Figure 8-30 shows the Sending_TSpec and ADSpec objects sent in a path message from a sending application.

Figure 8-30 Path Messages Sending_TSpec and ADSpec Objects

610 Chapter 8: Call Admission Control and QoS Signaling

In Figure 8-30 the Sending_TSpec is advertising the required level of service for this application as guaranteed. Because intermediary routers do not modify the Sending_TSpec, this value is passed through the network to the receiving application. The ADSpec lists the level of service available at each intermediate router along the data path. As the path message reaches router R3, the ADSpec object is modified to indicate that router R3 can only provide a controlled-load level of service. Essentially, the sending application has asked for guaranteed RSVP service, and the ADSpec implies that at least one router can only support a controlled-load service for this request.

The receiver of the path message replies with an resv message. Resv messages request a reservation for a specific flow through the use of a FlowSpec object. The FlowSpec object provides a description of the desired flow and indicates the desired level of service for the flow to the intermediary routers, based on the information received from the path message in the ADSpec object. A single level of service must be used for all nodes in the network—in other words, it can be controlled-load or guaranteed service, but not both. Because the sending application requires either guaranteed or controlled-load level of service to begin the flow, and router R3 can only provide controlled-load level of service, the receiving application can only request a reservation specifying controlled-load level of service. Example 8-31 shows the FlowSpec object sent in a resv message from a receiving application.

Figure 8-31 Resv Messages FlowSpec Objects