Table Of Contents
Signaled QoS (using RSVP)
The Internet faces an ongoing debate over how to handle network congestion. There are two primary options:
•Option 1: Buy additional bandwidth and provision more circuits
•Option 2: Implement Quality of Service (QoS)
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 were flush with funds; secondly, the additional bandwidth was perceived as cheaper that QoS deployment.
The downfall of the Internet economy has a favorable byproduct for QoS. The veritable "gold rush" is over, and the Internet is now a mature industry. Profitability is key. Traffic load continues to double each year, regardless of the Wall Street warnings, the industry will and 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 myths.
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 - like data. For example, 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:
1. Strict bandwidth guarantee for Voice and Video traffic—Includes end-to-end maintenance, so a loss of bandwidth in the core is handled appropriately.
2. Admission Control—Admitting calls based on available resources must be accomplished on an end-to-end basis. A local mechanism will do the job for a short time period, but it fails when congestion occurs at any point along the call path. So rather than having 12 calls with bad voice quality, ensuring that at least 10 calls go through.
3. Failure notification needs to be communicated to the endpoints, so a call will proceed without ensuring adequate reservation. While this can function, voice quality is severely impacted when congestion occurs.
4. Emergency situations—Every voice or video implementation needs to have some mechanism to handle emergency situations. During such a period, there is a high likelihood of congestion due to the "panic factor". Only a Signaled mechanism can provide an adequate preemptive scheme that prevents a major disruption.
Many can perceive the aforementioned fundamental value-adds of Signaled QoS; however, several myths do still exist with regards to RSVP deployment. These include:
1. Scalability—RSVP is per-flow, but it cannot scale in the core
2. Admission Control—RSVP is not available to perform admission control on Voice Gateways
3. Call Setup Delays—Time taken to establish end-to-end reservations is extensive
The subsequent section of this paper addresses the above concerns.
If RSVP were perceived as an IntServ architecture as such, this would be a true statement. IntServ utilizes RSVP on a per-flow basis, which may cause scalability concerns; however, these fears are grossly 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. Rfc2961: Refresh Reduction is a mechanism that the 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 will support Refresh Reduction as of Q4 CY 2002 in the 5th release of 12.2T. (A Beta image of this feature is currently available for test purposes.)
The IETF has standardized a scheme to aggregate RSVP: rfc3175: Aggregate RSVP. This allows aggregator and deaggregator points to be defined in the end-to-end path, thus 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 Q2 CY 2003.
Contrary to the aforementioned myth, 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 Cisco IOS Software 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 that RSVP made admission control appropriately. This issue is being resolved, and RSVP will support IP header compression in the 6th release of Cisco IOS Software Release 12.2T. (A Beta image of this feature is currently available.)
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 will feature a Local version of Policy Control in the 5th release of 12.2T. (A Beta image of this feature is currently available.)
Admission Control using RSVP is available on the primary voice gateways that include Cisco 2600 series routers, Cisco 3600 series routers, Cisco AS5300 Universal access server, Cisco AS5350, AS5400 and AS5850 universal gateways.
Call Setup Delays
This issue is effectively dependent on the specific deployment. A litany of reasons can cause a delay in setting up end-to-end reservations, but there are usually two main causes:
•The RSVP control messages are not marked with a higher priority and/or
•There is a loss of RSVP control messages along the call path
Since Cisco IOS Software Release 12.2T, RSVP control messages can be marked with DiffServ Code Point (DSCP) marking, ensuring that RSVP control messages are treated at a 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 just described. Suppose that 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, thus 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 will be available in the 5th release of 12.2T. (A Beta image of this feature is currently available.)
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 Series and Cisco 7200 Series Routers), so 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".
What Does Cisco Think of Signaled QoS?
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 is in the process of rolling 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.