Tài liệu Thực hiện chất lượng dịch vụ trong các mạng IP (P10) ppt

10
Summary
It is time to summarize the topics discussed in previous chapters.
End users want to have access to different kind of information
access and entertainment-related services with as simple technical
means as possible and with as understandable a billing as pos-
sible. Such a goal not only brings economical benefits, but also
means that the customer has smaller number devices and inter-
faces to master and to maintain. Beneficially, all kinds of services
should be available to the end user using a single communication
channel only for each context of use. One such context of use is
home or corporate use, where high-bandwidth access is possible.
Another context is mobile use, where the services are provided
viaahandheldterminalorviaalaptop.
Communication media with per-user throughput allowing the
delivery of also real-time content is becoming widely available,
examples being fibre access to home or SOHO environments, xDSL,
IEEE 802.11, and 2.5G/3G radio interface technologies such as GPRS
and WCDMA. The mere existence of suitable medium is not suffi-
cient, but the interface to the applications should be made such that
achieving adequate service quality support for each service type
is possible. Equally, the service quality support interface from the
applications should be easy to use, easy to understand for the end
user, and as standard as possible across platforms.
The services differ with respect to their delivery requirements
according to their composition, containing at most general multiple
components with differing requirements. Data-type services such
Implementing Service Quality in IP Networks Vilho R
¨
ais
¨

anen
 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X
300 SUMMARY
as e-mail only require reliable delivery, whereas more interactive
services such as Internet browsing pose further limitations on the
underlying technical solution. Most demanding service types are
real-time services, with each service instance being made up of a
stream of data in the network. Streamed multimedia is an example
of this. Multimedia conferencing and remote control applications
have the strictest service quality support requirements. Due to the
dynamic nature of service creation made possible with IP-based net-
works, it is not possible to enumerate the service quality support
requirements of all possible services, but it is possible to construct a
framework classifying the required service quality support.
The easiest way of providing service quality support in a packet-
switched environment is to over-dimension the network. This is
not always economically feasible. Especially in the access net-
works, it is highly desirable to utilize the network capacity as
well as possible.
End-to-end service quality is also affected by other factors, which
have been discussed in Chapter 2. In what follows, we shall con-
centrate on network-side support for service quality.
10.1 IP AS THE CONVERGENCE NETWORK
During 1990s, Asynchronous Transfer Mode (ATM) held the prom-
ise of providing multi-service support to homes and offices. Despite
the advanced service quality support modes, ATM did not reach the
home user, except as link layer technology used in ADSL. ATM was
perceived as complex and expensive.
The common denominator turned out to be Internet Protocol
(IP). IP-based applications have been in wide-scale use since the

development of Transfer Control Protocol (TCP) in the 1980s.
The application programming interface (API) of TCP/IP has been
tested for a long time, and has a wide user base.
IP was originally developed for packet-switched services such
as data transfer and e-mail. TCP/IP has demonstrated its validity
for these purposes via worldwide deployment as the basis technol-
ogy for the Internet. All the basis protocol suites in IP have been
designed for packet-switched environment, being exemplified by
routing protocols such as Open Shortest Path First (OSPF).
Making IP the protocol basis also for real-time services requires
that new technologies be added to basic IP. The most demanding ser-
vices such as Voice over IP (VoIP)and streamed multimedia typically
10.2 DIFFSERV 301
consist of a periodic transmission of Protocol Data Units (PDUs) in
the network, and need low end-to-end delivery latency and bounded
PDU loss in the network. These needs are addressed by service qual-
ity support extensions to basic IP, and traffic engineering extensions.
Two service quality support frameworks have been defined
for IP, namely Integrated Services (IntServ) and Differentiated
Services (DiffServ). IntServ is a framework providing two service
models, one approximating to lightly loaded network and
another one providing actual service quality guarantees. Current
practical implementation of the IntServ framework make use
of the Resource Reservations Protocol (RSVP) between network
elements, and are perceived as having poor scalability properties
with network size. DiffServ, the alternative IP service quality
support framework, provides two standardized service models,
namely a low latency/low loss one and a statistical allocation of
services. Since DiffServ is based on prioritization of PDUs and
not requiring maintenance of per-flow state in the network, it is

considered to be scalable to large networks.
At the moment, DiffServ-based IP service quality control means
for single domains have reached a mature phase, and are being
deployed in the transport infrastructure of packet-based mobile
networks. The use of DiffServ as the basis of future general-
purpose multi-service network is being studied in multiple fora,
such as the QBone/Internet2.
The other part of the story is interface between services and the
service quality support-enabled transport network. The interface
can be based on Service Level Agreements (SLAs), and can also
use dynamical means of service quality control.
Let us next take a brief look at the capabilities of a DiffServ-based
multi-service network.
10.2 DIFFSERV
One of the reasons for the favoured position of DiffServ in this
book is the combination of reference architecture and service qual-
ity support model, the latter consisting of a small number of
service quality support classes, the Per-Hop Behaviours. Core net-
work routers handle only IP packets marked with a DiffServ Code
Point (DSCP) corresponding to one of the PHBs. Two classes of
302 SUMMARY
PHBs are standardized at the moment, namely Expedited For-
warding (EF) PHB and the Assured Forwarding (AF) PHB group.
Domain-wide, the service quality support level provided by traffic
aggregates in a DiffServ network can be defined using the con-
cept of Per-Domain Behaviours (PDBs), detailing characteristics
such as delays between reference points in the network. Since Diff-
Serv is based on traffic aggregates, it has the potential to achieve
high multiplexing gains, depending on the combination of services
transported within the domain.

Another part of the service quality support framework in Diff-
Serv is traffic conditioning at the edge of the network. Incoming
packets are classified and marked with a DSCP. The allowable
bandwidth and burstiness of incoming flows or traffic aggregates
can be defined in a SLA between the network operator and the
customer. Based on the SLA, incoming traffic can be policed to
avoid degradation of the service quality support in the respec-
tive traffic aggregate. Because per-flow operations are performed
at the edge of the network, DiffServ is sometimes known as the
edge provisioning model.
Basic DiffServ does not include means of limiting the number of
service instances within one traffic aggregate in a domain, which is
why DiffServ needs to be supplanted by a service quality instan-
tiation control in order that high network utilization levels can
be reached. A protocol interface between the end systems and
service quality instantiation is needed to achieve this. For this
purpose, the service quality signalling part of RSVP can be used.
Alternatively, a suitable protocol interface based on service qual-
ity support aggregates can be used. In addition, service quality
support instantiation functionality is needed.
Another area not addressed by the basic DiffServ framework is
routing control. For this purpose, suitable link layer technology or
IP routing protocol based means can be used. Such routing control
means are seen to be part of the traffic engineering framework
discussed in Section 10.4 below.
10.2.1 Complementary technologies for DiffServ
Basic service quality support instantiation control of a DiffServ do-
main can be complemented by a service quality instantiation con-
troller handling admission requests from end systems and other
10.3 SERVICE LEVEL MANAGEMENT 303

domains. In DiffServ environment, this element is called band-
width broker. A bandwidth broker can perform admission con-
trol to network resources based on bookkeeping, measurements,
or a combination of both. Use of measurements is advantageous
in making service quality instantiation coupled with the actual
resource usage status. Using measurements in service quality in-
stantiation control is especially useful in a multi-service environ-
ment with the goal of high network utilization levels.
Bandwidth brokers can also be used in end-to-end service
quality control across domain boundaries. In this mode, a
single bandwidth broker may be responsible for a single
IP domain and the bandwidth brokers in different domains
can exchange information about resource availability. Different
scenarios for inter-domain bandwidth broker communication have
been discussed in Chapter 8. Dynamic inter-domain resource
signalling can be used as a supplementary technology in inter-
domain SLA agreements. In addition, it has the potential to be an
enabling technology for market-oriented service broker models.
10.3 SERVICE LEVEL MANAGEMENT
Service Level Agreements (SLAs) are used in telecommunications
and datacommunications for defining the responsibilities and
rights of operators when they are using each other’s services.
In general, SLAs can also be used between operators and
end users, between service providers and network operators,
and between service providers. A SLA makes it possible to
achieve engineered end-to-end performance without end-to-end
signalling. Traditionally, SLAs have been used in a single-service
environment such as telephony or data delivery in the Internet.
Extending the area of applicability of SLAs to multi-service
networks brings with it new challenges.

SLA management can be viewed as a higher layer making use
of per-domain resources (see Figure 10.1). Individual SLAs, con-
cerning either actual services, or service quality support for exter-
nal parties, can be processed on a SLA management layer by
each operator or service provider. Inputs to the SLA manage-
ment come from the business goals of the operator, as well as
from the per-domain resource availability and existing SLA base.
Potential new technologies that can be used for evaluating SLA