IntServ is a framework providing two service models, one approximating to lightly loaded network and another one providing actual service quality guarantees.. DiffServ, the alternative I
Trang 1Summary
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 via a handheld terminal or via a laptop
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
Trang 2300 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
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
Trang 3consist 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
Trang 4302 SUMMARY
PHBs are standardized at the moment, namely Expedited For-warding (EF) PHB and the Assured ForFor-warding (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 qualqual-ity 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
Trang 5domains In DiffServ environment, this element is called band-width broker A bandband-width 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
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
Trang 6304 SUMMARY
NE NE NE NE NE
Traffic engineering
SLA SLA SLA SLA SLA
Utility-based resource allocation assessment
SLA management
Implementation
of SLAs
Figure 10.1 Technologies associated with the layers of SLA management and implementation
allocations include utility-based methods Such schemes can be used in assessing different SLA assignment alternatives
Bandwidth brokers can be used with inter-domain SLAs in two ways: complementing the content of static SLAs with up-to-date resource availability on inter-domain links, and in implementing new inter-domain resource management models that assume the availability of dynamic resource information across domain boundaries
On the network level, SLA management process has a concep-tual counterpart, namely traffic engineering process, which is used
to manage the service level support in a multi-service IP domain This is our next topic
Traffic engineering in a multi-service domain is a process which optimizes the network resources for the service quality support configuration resulting from the SLA management process One aspect of traffic engineering is making the initial service quality support configuration of a network domain, and another one is the optimization of the use of resources in an operational network
To perform the first task, traffic engineering process takes SLA assignments and network service quality support resources as an input, and computes the required network element configuration
in the domain
Trang 7DiffServ
parameter
optimization
Modification
of service mapping
Service
instantiation
control policy
adjustment
SLA adjustment
Building of new transport capacity
Figure 10.2 The timescales of traffic engineering
For the optimization task, feedback from the network is needed Feedback can be obtained from the network in multiple different formats, including element level, domain level and service support aggregate level information An important measure from a multi-service aggregate network is the utilization level of links Service quality support aggregate measurements are typically also needed
by the SLA management process
From the viewpoint of SLA management, the traffic engineering process must also be able to provide an indication of its means
of optimization of the network behaviour becoming exhausted
In such a situation, SLA-level actions are needed Examples of possible actions include revision of the contents of SLAs towards end users, other network operators, or service providers Another possible consequence is updating of network capacity
The timescales associated with SLA management and traffic engineering are illustrated in Figure 10.2
IP-based Radio Access Network (RAN) was shown as a case study
of applying the concepts discussed earlier within this book It was
a suitable topic for this, since the service quality support classes are well defined, and the role of DiffServ and traffic engineering
Trang 8306 SUMMARY
can be readily outlined According to the aim of providing same services over any access technology, the need to apply the same techniques to other access networks can be expected to emerge in the near future From the viewpoint of DiffServ, the basic deploy-ment scenario, managedeploy-ment and application of traffic engineering
in such multi-access networks can be expected to be not unlike corresponding tasks in IP-based RAN The differences will most likely arise from user mobility, service quality instantiation con-trol, management and optimization of access technology specific details according to the needs of specific service usage
The application of novel end-to-end technologies such as signalled inter-bandwidth broker service quality instantiation control and service auctioning technologies is likely to be an interesting research area for the future The adoption of such technologies would allow for interesting new scenarios, for example, facilitating competition between service providers using the same transport provider
One of the most interesting areas of research is access networks
without static infrastructure, known as ad hoc networks The
imple-mentation of basic service quality support in such networks can
be expected to be topical in the coming years, and interfacing ad
hoc networks to engineered transport network will likely give rise
to interesting interoperability scenarios