6.7 Integrated Services
In the previous sections, we identified both the principles and the mechanisms
used to provide Quality of Service in the Internet. In this section
we consider how these ideas are exploited in a particular architecture
for providing quality of service in the Internet - the so-called intserv
(Integrated Services) Internet architecture . Intserv is a framework
developed within the IETF to provide individualized quality of service
guarantees to individual application sessions. Two key features lie
at the heart of intserv architecture:
-
Reserved Resources. A router is required to know what amounts of
its resources (buffers, link bandwidth) are already reserved for on-going
sessions.
-
Call Setup. A session requiring QoS guarantees must first
be able to reserve sufficient resources at each network router on its source-to-destination
path to ensure that its end-to-end QoS requirement is met. This call
setup (also known as call admission) process requires the participation
of each router on the path. Each router must determine the local
resources required by the session, consider the amounts of its resources
that are already committed to other on-going sessions, and determine whether
it has sufficient resources to satisfy the per-hop QoS requirement of the
session at this router without violating QoS local QoS guarantees
made to already admitted session.
Figure 6.7-1: The call setup process
Figure 6.7-1 depicts the call setup process. Let us now consider
the steps involved in call admission in more detail:
-
Traffic characterization and specification of the desired QoS.
In order for a router to determine whether or not its resources are sufficient
to meet the QoS requirements of a session, that session must first
declare its QoS requirement, as well as characterize the traffic that it
will be sending into the network, and for which it requires a QoS guarantee.
In the Intserv architecture, the so-called Rspec (R for reserved) defines
the specific QoS being requested by a connection; the so-called Tspec (T
for traffic) characterizes the traffic the sender will be sending into
the network, or the receiver will be receiving from the network. The specific
form of the Rspec and Tspec will vary, depending on the service requested,
as discussed below. The Tspec and Rspec are defined in part in [RFC2210],
[RFC
2215].
-
Signaling for call setup. A session's Tspec and Rspec must
be carried to the routers at which resources will be reserved for the session.
In the Internet, the RSVP protocol, which is discussed in detail in the
next section, is currently the signaling protocol of choice.
[RFC 2210] describes the use of the RSVP resource
reservation protocol with the Intserv architecture.
-
Per-element call admission. Once a router receives the Tspec and
Rspec for a session requesting a QoS guarantee, it can determine
whether or not it can admit the call. This call admission decision will
depend on the traffic specification, the requested type of service, and
the existing resource commitments already made by the router to on-going
sessions. Per-element call admission is shown in Figure 6.7-2.
Figure 6.7-2: Per-element call behavior
The Intserv architecture defines two major classes of service: Guaranteed
Service and Controlled-Load service. We will see shortly that each
provides a very different form of a quality of service guarantee.
6.7.1 Guaranteed Quality of Service
The Guaranteed Service definition, defined in [RFC
2212] provides firm (mathematically provable) bounds on the queuing
delays that a packet will experience in a router. While the details
behind Guaranteed Service are rather complicated, the basic idea is really
quite simple. To a first approximation, a source's traffic characterization
is given by a leaky bucket (see Section 6.6) with parameters (r,b)
and the requested service is characterized by a transmission rate, R,
at which packets will be transmitted. In essence, a session requesting
Guaranteed Service is requiring that the bits in its packet be guaranteed
a forwarding rate of R bits/sec. Given that traffic
is specified using a leaky bucket characterization, and a guaranteed rate
of R is being requested, it is also possible to bound the maximum
queuing delay at the router. Recall that with a leaky
bucket traffic characterization, the amount of traffic (in bits) generated
over any interval of length t
is bounded by rt+b. Recall
also from Section 6.6, that when a leaky bucket source is fed into a queue
which guarantees that queued traffic will be serviced at least at a rate
of R bits per second, then the maximum queuing delay experienced
by any packet will be bounded by
b/R, as long as R is greater
than r. The actual delay bound guaranteed under the
Guaranteed Service definition is slightly more complicated, due to packetization
effects (the simple b/R bound assumes that data is in the forms
of a fluid-like flow rather than discrete packets), the fact that the traffic
arrival process is subject to the peak rate limitation of the input link
(the simple b/R bound assumes that a burst of b bits can arrive in zero
time, and possible additional variations in a packet's transmission time.
6.7.2 Controlled Load Network Service
A session receiving Controlled-Load service will receive "a quality of
service closely approximating the QoS that same flow would receive from
an unloaded network element." [RFC 2211].
In other words, the session may assume that a "very high percentage" of
its packets will successfully pass through the router without being dropped
and will experience a queuing delay in the router that is close to zero.
Interestingly, Controlled Load service makes no quantitative guarantees
about performance - it does not specify what constitutes a "very high percentage"
of packets nor what quality of service closely approximates that of an
unloaded network element.
The Controlled Load service targets real-time multimedia applications
that have been developed for today's Internet. These applications
perform quite well when the network is unloaded, but rapidly degrade in
performance as the network becomes more loaded.
References
[RFC 1633] R. Braden, D. Clark & S.
Shenker,"Integrated Services in the Internet Architecture: an Overview,"
RFC
1633, June 1994.
[RFC 2210] J. Wroclawski,
"The Use of RSVP with IETF Integrated Services," RFC
2210, Sept. 1997.
[RFC 2211] J. Wroclawski, "Specification
of the Controlled-Load Network Element Service," RFC
2211, Sept. 1997.
[RFC 2212] S. Shenker, C. Partridge,
R. Guerin, "Specification of Guaranteed Quality of Service," RFC
2212, September 1997.
[RFC 2215] S. Shenker,
J. Wroclawski, "General Characterization Parameters for Integrated Service
Network Elements," RFC
2215, Sept. 1997.
Return to
Table Of Contents
Copyright James F. Kurose and Leith
W. Ross 1996-2000