Model The needs of real-time applications,
such as remote video, multimedia conferencing, visualization,
and virtual reality, motivated the development of the IntServ
architecture model (RFC 1633, June 1994). Figure illustrates a
more detailed view of the operation of the IntServ
model.IntServ provides a way to deliver the end-to-end QoS that
real-time applications require by explicitly managing network
resources to provide QoS to specific user packet streams,
sometimes called microflows. IntServ uses resource reservation
and admission-control mechanisms as key building blocks to
establish and maintain QoS. This practice is similar to a
concept known as “hard QoS.” Hard QoS guarantees traffic
characteristics, such as bandwidth, delay, and packet-loss
rates, from end to end. Hard QoS ensures both predictable and
guaranteed service levels for mission-critical applications.
IntServ uses Resource Reservation Protocol (RSVP) explicitly to
signal the QoS needs of an application’s traffic along devices
in the end-to-end path through the network. If network devices
along the path can reserve the necessary bandwidth, the
originating application can begin transmitting. If the
requested reservation fails along the path, the originating
application does not send any data. IntServ is a
multiple-service model that can accommodate multiple QoS
requirements. IntServ inherits the connection-oriented approach
from telephony network design. Each individual communication
must explicitly specify its traffic descriptor and requested
resources to the network. The edge router performs admission
control to ensure that available resources are sufficient in
the network. The IntServ standard assumes that routers along a
path set and maintain the state for each individual
communication. In the IntServ model, the application requests a
specific kind of service from the network before sending data.
The application informs the network of its traffic profile and
requests a particular kind of service that can encompass its
bandwidth and delay requirements. The application sends data
only after it receives confirmation for bandwidth and delay
requirements from the network. The application also sends data
that lies within its described traffic profile. The network
performs admission control based on information from the
application and available network resources. The network
commits to meeting the QoS requirements of the application as
long as the traffic remains within the profile specifications.
The network fulfills its commitment by maintaining the per-flow
state and then performing packet classification, policing, and
intelligent queuing based on that state. The QoS feature set in
Cisco IOS software includes these features that provide
controlled traffic volume services: - RSVP, which can be
used by applications to signal their QoS requirements to the
router
- Intelligent queuing mechanisms, which can be
used with RSVP to provide these QoS service levels:
- Guaranteed-rate: Allows applications to reserve
bandwidth to meet their requirements. For example, a VoIP
application can reserve 32 Mbps end–to-end bandwidth using this
type of service. Cisco IOS QoS uses LLQ with RSVP to provide a
guaranteed-rate type of service.
- Controlled-load: Allows applications to have low
delay and high throughput, even during times of congestion. For
example, adaptive real-time applications, such as the playback
of a recorded conference, can use this service. Cisco IOS QoS
uses RSVP with WRED to provide a controlled-load type of
service.
IntServ Functions
As
a means of illustrating the function of the IntServ model,
Figure shows the control and data planes. Besides end-to-end
signaling, IntServ requires several functions in order to be
available on routers and switches along the network path. These
functions include the following: - Admission
control: Admission control determines whether a new flow
requested by users or systems can be granted the requested QoS
without affecting existing reservations in order to guarantee
end-to-end QoS. Admission control ensures that resources are
available before allowing a reservation.
- Classification: Entails using a traffic descriptor
to categorize a packet within a specific group to define that
packet and make it accessible for QoS handling on the network.
Classification is pivotal for policy techniques that select
packets for different types of QoS service.
- Policing: Takes action, including possibly dropping
packets, when traffic does not conform to its specified
characteristics. Policing is defined by rate and burst
parameters, as well as by actions for in-profile and
out-of-profile traffic.
- Queuing: Queuing
accommodates temporary congestion on an interface of a network
device by storing excess packets in buffers until access to the
bandwidth becomes available.
- Scheduling: A QoS
component, the QoS scheduler, negotiates simultaneous requests
for network access and determines which queue receives
priority. IntServ uses round robin scheduling. Round robin
scheduling is a time-sharing approach in which the scheduler
gives a short time slice to each job before moving on to the
next job, polling each task round and round. This way, all the
tasks advance, little by little, on a controlled basis. Packet
scheduling enforces the reservations by queuing and scheduling
packets for transmission.
Benefits and Drawbacks
of the IntServ Model
The IntServ model has several
benefits and some drawbacks as shown in Figure :
- Benefits:
- IntServ supports admission control
that allows a network to reject or downgrade new RSVP sessions
if one of the interfaces in the path has reached the limit
(that is, if all bandwidth that can be reserved is
booked).
- RSVP signals QoS requests for each individual
flow. In the request, the authorized user (authorization
object) and needed traffic policy (policy object) are sent. The
network can then provide guarantees to these individual
flows.
- RSVP informs network devices of flow parameters
(IP addresses and port numbers). Some applications use dynamic
port numbers, such as H.323-based applications, which can be
difficult for network devices to recognize. Network-Based
Application Recognition (NBAR) is a mechanism that complements
RSVP for applications that use dynamic port numbers but do not
use RSVP.
- Drawbacks:
- There
is continuous signaling because of the stateful RSVP
architecture that adds to the bandwidth overhead. RSVP
continues signaling for the entire duration of the flow. If the
network changes, or links fail and routing convergence occurs,
the network may no longer be able to support the
reservation.
- The flow-based approach is not scalable
to large implementations, such as the public Internet, because
RSVP has to track each individual flow. This circumstance makes
end-to-end signaling difficult. A possible solution is to
combine IntServ with elements from the DiffServ model to
provide the needed scalability.
Content 3.3 Selecting an Appropriate
QoS Policy Model 3.3.4 RSVP and the IntServ QoS
Model Cisco QoS architecture uses RSVP as one of several
methods for providing Call Admission Control (CAC) for voice in
a VoIP network. The RSVP method for CAC is the only method that
makes an actual bandwidth reservation for each allowed voice
call. Other CAC methods can only make a decision that is a
guess based on the state of the network at the initiation of
the call. The use of RSVP not only provides CAC, it also
guarantees QoS for the duration of the call regardless of
changing network conditions. RSVP is the method used by Cisco
Unified CallManager 5.0 to perform CAC. If resources are
available, RSVP accepts a reservation and installs a traffic
classifier to assign a temporary QoS class for that traffic
flow in the QoS forwarding path. The traffic classifier tells
the QoS forwarding path how to classify packets from a