QoS Signaling

Last Updated: August 2005

The Internet faces an ongoing debate regarding how to handle network congestion. There are two primary options:

Several years ago, two factors led to the overall view that option 1 was more viable. The Internet boom was peaking, with many Service Providers and Enterprises flush with funds; also the additional bandwidth was perceived as cheaper than QoS deployment.

The downfall of the Internet economy has a favorable byproduct for QoS. The "gold rush" is over and the Internet is now a mature industry. Profitability is essential. Traffic loads continue to double each year and regardless of the Wall Street warnings, the industry has a very sustainable future. Consequently, QoS deployment has become an increasingly attractive proposition, Service Providers offer QoS-based services while Enterprises leverage these services to reduce expenses.

Cisco IOS® Software supports two fundamental QoS architectures: Differentiated Services (DiffServ) and Integrated Services (IntServ). It is important to note that these approaches are complimentary in nature. DiffServ enables better QoS scalability, while IntServ provides a guaranteed traffic delivery. Together, they form a robust QoS deployment.

An IntServ approach utilizes Resource Reservation Protocol (RSVP) to signal a specific service. This makes it ideal for end-to-end, delay-and-jitter-sensitive applications, such as voice and video. The IntServ approach of using signaled QoS is one of the most misunderstood areas in the industry, and this paper will attempt to clarify some common misconceptions.

Signaled QoS is most appropriate for "intolerant" traffic, which does not like delay, jitter or packet loss (ie: voice and video). For corner cases, it may be applicable for tolerant traffic, for example, data. The pre-emption capabilities of RSVP could handle an extremely high-priority data burst (ie: executing a stock trade during a bear run).

Signaled QoS is irreplaceable for the following four reasons:

Many can perceive the previously mentioned fundamental value-adds of signaled QoS, however several misconceptions still exist with regards to RSVP deployment.

The next section of this paper addresses the concerns listed above.

If RSVP were perceived as an IntServ architecture, this would be a true statement-IntServ utilizes RSVP on a per-flow basis, which may cause scalability concerns. However, these fears are overstated. Cisco routers have demonstrated the ability to handle more than 10,000 RSVP flows with minimal CPU and memory impact. RSVP deployment does not pose a scalability problem for smaller networks.

For larger networks, Cisco recommends the implementation of a combination of the two QoS architectures: IntServ with DiffServ (as defined in Rfc2998). This is a very scalable solution. In this scenario, IntServ is used at the edge to provide per-flow treatment and admission control, while DiffServ is deployed at the core, which allows traffic to be handled at an aggregate level. Cisco IOS Software Release 12.2(2)T first introduced IntServ-DiffServ integration and it has been available since.

RSVP is a soft-state protocol. It maintains state on a per-flow basis and requires periodic refreshment. If it does not receive a refresh message within a given timeslot, it tears down the reservation. Sending refresh messages for each state (corresponding to a flow) is not scalable. Refresh reduction (Rfc2961) is a mechanism that the Internet Engineering Task Force (IETF) standardized to reduce refresh messages. This reduces the frequency of refresh messages from every flow to a single aggregated (summary) message. Cisco IOS Software supports refresh reduction and reliable messaging started in Release 12.2(13)T.

The IETF has also standardized a scheme to aggregate RSVP (Rfc3175) called aggregate RSVP. This allows aggregator and deaggregator points to be defined in the end-to-end path, creating a zone where multiple "parallel" per-flow states can be converted into a single state. Cisco is actively investigating the implementation of this functionality, which will likely be available in the near future.

Contrary to the previously mentioned misconception, RSVP is an ideal choice to handle admission control. It is the only known and industry-standardized mechanism to provide end-to-end admission control. RSVP has been an integral part of Cisco IOS Software since its invention in the mid `90s. Call synchronization for H.323 was added in Release 12.1(5)T and for SIP in Release 12.2(8)T.

IP Header Compression (cRTP) is a key voice functionality. RSVP did not account for the compressed bandwidth required to perform admission control, however, there was a workaround to "inflate" the bandwidth, so RSVP helps admission control perform appropriately. This issue is resolved and RSVP support for RTP header compression is available in Release 12.2(15)T and later.

Admission control implies the ability to have a policy mechanism, which can essentially provide for services such as "Subscriber A gets only 100Kbps", while "Subscriber B gets only 80Kbps". Cisco IOS Software supports Common Open Policy Service (COPS) as a policy mechanism for RSVP. While this requires an external network management application, Cisco IOS Software also has support for RSVP local policy in Release 12.2(13)T and later.

Admission control using RSVP is available on the primary voice gateways that include Cisco 2600XM and 3700 Series Routers, the Cisco AS5300 Universal Access Server, and Cisco AS5350, AS5400 and AS5850 Universal Gateways.

This issue is dependent on the specific deployment. Many reasons can cause a delay in setting up end-to-end reservations, but there are usually two main causes:

Since Release 12.2T, RSVP control messages can be marked with DiffServ Code Point (DSCP) marking, ensuring that RSVP control messages are treated with priority. This minimizes potential delays, which are caused by the scheduling treatment accorded to the RSVP control messages. (Please note that RSVP control messages are transmitted via User Datagram Protocol [UDP]).

The loss of RSVP control messages is related to the situation described previously. If the RSVP control message is not marked with a high priority, a mechanism like Weighted Random Early Detection (WRED) is likely to aggressively drop RSVP control messages, delaying end-to-end reservation setup time.

Rfc2961 also defines the concept of RSVP reliable messaging; the RSVP process continuously retransmits the messages until an explicit acknowledgement is received. RSVP reliable messaging is available starting in Release 12.2(13)T.

The latency caused by the RSVP process in each router as the control messages traverse them is extremely small. For example, it takes about 10ms per hop (tested routers: Cisco 3600 and 7200 Series Routers) and a 10-hop path would take about one-tenth of a second for call setup. This should not be confused with the latency involved during the duration of a call.

In conclusion, signaled QoS is a viable solution. It demonstrates a credible value-add and is currently being deployed globally.

In all likelihood, the classic Internet debate of additional bandwidth vs. QoS will continue for the foreseeable future. Note, however, this wise adage: "frugality is a necessity, not a luxury".

Cisco Systems Inc. is a global corporation with more than 35,000 employees across 128 countries. By any measure, the network needed to support such a diverse organization must be large. Its network is termed "Cisco All Packet Network" or "CAPNET".

CAPNET has rolled out IP based video-conferencing services for Cisco offices. The video-conferencing solution uses H.323 endpoints, and leverages signaled QoS (using RSVP) and DiffServ to provide a robust service.

To put it simply, not only is Cisco inventing the technology that enables new Internet services, but we believe in the value add of the technology, and use it to change the way we work, live, play and learn.