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 304 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. Bandwidthbrokerscanbeusedwithinter-domainSLAsintwo 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. 10.4 TRAFFIC ENGINEERING 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. 10.5 POTENTIAL FUTURE DEVELOPMENT DIRECTIONS 305 Timescale DiffServ 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 10.5 POTENTIAL FUTURE DEVELOPMENT DIRECTIONS 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 306 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, management 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. . 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. 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