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

8 Mechanisms for Dynamic Service Quality Control The means of dynamically controlling service quality in IP net- works is our next topic. There are two primary uses for such methods: dynamic control of resources within an IP domain, and implementation of dynamic SLAs between domains. The generic element handling both of these tasks is often called the “band- width broker” (BB), and this convention is followed also within this book. Admission control or service quality instantiation control is not part of the basic DiffServ framework [RFC2475]. Subsequently, the need for IP service quality support mechanisms for DiffServ networks other than edge provisioning and per-hop prioritization mechanisms in core networks has been widely acknowledged [RFC2638, Sch98, THD + 99, TAP + 01, JC01, SAF + 01, TIPHON-3]. The basic reason for the need of dynamic per- domain service quality control mechanism is the following: up to a limit, service quality for critical service types can be provided by mapping them to a proper service quality support aggregate such as EF. This works because of the prioritization mechanism of DiffServ. Alas, when there is too much traffic within the EF PSC, the flows sharing the PHB begin to suffer. The effect of EF PHB to other PSCs within the router can be controlled by using rate limiters, but basic DiffServ framework does not provide tools for Implementing Service Quality in IP Networks Vilho R ¨ ais ¨ anen  2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X 252 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL dynamic control within the aggregate. Similarly, the quality in AF PSCs suffers from too many service instances trying to share them. Theend-userSLAsattheedgeofthenetworkareimposedby policing of traffic at the edge of the DiffServ domain. As we saw in Chapter 3, policing requires that adequate DiffServ classifier be placed at the edge of the network. With statically configured DiffServ classifiers only, it is not possible to perform dynamical resource control. Basically, two techniques can be used to improve on this: • Admission control to existing classifiers. In this case, the classi- fiercanbeperendpointIPaddress,perprefix,orpertraffic aggregate. This requires that there is an extra-DiffServ means of blocking flows. • Installment of Diffserv classifiers on demand. For the latter alternative, using of outsourced policy model is an enabling technology from the control architecture point of view [LV02]. Obviously, in addition to the machinery to distribute the classifiers, there has to be a policy existing as to when to limit service quality instantiation and intelligence to create the actual DiffServ classifiers. Per-domain Bandwidth Broker (BB) is a poten- tial tool for taking care of the former task, and for providing the data for the second task. Recent examples of application of band- width broker to manage the network resources in multi-service IP network domain can be found in [Lak02] and [MNV02]. In the former, the emphasis is on the algorithms used for controlling resources, whereas in the latter, also an architecture for manage- ment is needed. Between the domains, being limited solely to static SLAs limits the level of efficiency of network use that can be reached. This is basically due to statistical multiplexing of flows in traffic aggregates. If the SLA between two operator specifies that the delays and packet losses have to be within certain range, it may be beneficial for a transit network operator to make dimensioning based slightly on conservative multiplexing calculation. If the operator could indicate to the business parties of momentarily available extra capacity, this capacity could be utilized. This can be viewed as an enabling technology for the broker- type market models discussed shortly in Chapter 5. Another potential use of automated inter-domain communication between MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL 253 bandwidth brokers is implementing a transport transit service, which performs admission control in the access domain solely based on inter-domain bandwidth availability information. This is one of the models discussed in end-to-end ETSI EP TIPHON service quality support model [TIPHON-3], and has been analysed in detail by Schel ´ en [Sch98]. A bandwidth broker controlled DiffServ domain can also interface to a 3GPP domain with suitable interworking arrangements, as discussed in [MNV02]. The basic DiffServ framework is based on the edge provisioning principle, where policing and marking of traffic at the network edge are the determining components for per-flow quality sup- port. Using bandwidth brokers, per-flow service quality in Diff- Serv can be made more closely integrated with the resource avail- ability situation in the network domains relevant for the transport of individual service instances. The means that can be used to maintain up-to-date information about service quality support are discussed in Section 8.2.2. Policy-based management is one way of implementing control of service quality instantiation, others being discussed further below. On an architectural level, at least the following schemes are pos- sible to implement end-to-end support for service quality when multiple transport domains (ADs) are involved: • Oneormoreserviceproviderstakecareofprovidingtrans- port resources for their own services, where transport resources may be under control of separate transport operators. The trans- port operators may obviously be used by other parties as well. TheprovisioncanbeSLA-based.Thisisoneofthescenarios analysed in the ETSI EP TIPHON QoS control reference model [TIPHON-3]. • Separate per-element entities handle dynamic service quality con- trol based on transport service quality support resource availabil- ity. This is the bandwidth broker model analysed in [RFC2638, Sch98, THD99], to name but a few sources. • Hybrid model. In this approach, bandwidth brokers are used by providing up-to-date service quality support resource availabil- ity information to service providers. The two first models are illustrated in Figure 8.1 and Figure 8.2. Note that in the first case, the correspondence between service providers and transport domain does not need to be one-to-many. 254 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL Transport domain 1 Transport domain 2 Service domain End system End system Figure 8.1 An example of end-to-end provisioning on service layer Note : The media stream requiring service quality support is drawn in the thick line, signalling of end systems with service domain in the thin solid line, and interaction of service provider with transport domains in the dotted thin line Transport domain 1 Transport domain 2 End system End system BB BB Figure 8.2 An example of end-to-end provisioning performed by per-domain bandwidth brokers (BB) Note : The communication to bandwidth broker and between bandwidth brokers is drawn in solid thin lines, communication of BBs with transport domains in dotted thin lines, and user traffic in the thick black line Regarding the two basic scenarios, the present chapter is primar- ily concerned with service-independent resource management. As was mentioned in the previous chapter, it is also possible to make a link between bandwidth broker-type entity and service admission control. We shall discuss this topic further in Section 8.2.4. Let us next have a look at existing studies on bandwidth bro- kers, and then formulate a generic framework for application of bandwidthbrokerinthecontextof multi-service DiffServ network domains. The present chapter will be concluded with a summary. 8.1 PREVIOUS STUDIES Other bandwidth broker architecture models have been studied in the TEQUILA project [TAP + 01], the AQUILA project [MNV02], 8.1 PREVIOUS STUDIES 255 the GARA Application Programming Interface (API) model [SAF + 01] and other sources [JC01], to give examples. The technology repertoire analysed in these studies includes SLS negotiation, DiffServ, and MPLS. For the purposes of the present book, we will concentrate on intra-domain and inter-domain resource management in DiffServ specifically. MPLS is considered to be a traffic engineering technique that is used by the policy management to optimize the resource usage within a network domain, and as such is not directly related to bandwidth brokers. The information supplied by the bandwidth broker, of course, can be used by the policy management system as input in optimizing the domain resources. In what follows, the IETF two-bit DiffServ architecture, the QBone bandwidth broker architecture, and Schel ´ en’s funnel concept are discussed. 8.1.1 Two-bit DiffServ architecture The “two-bit” DiffServ architecture described in [RFC2638] has been designed to support two service models, namely the “assured service” and “premium service”. The two-bit architecture basically accommodates both EF PHB and AF PHB groups within the same DiffServ network domain. The assured service, akin to the AF PHB group, provides statistical guarantees for in-profile traffic. The second service model, EF-like, is based on prioritization of “premium” flows with respect to other traffic in the network. In accord with the DiffServ framework, both service models make use of traffic conditioning at the edge of the domain. Thus, the two services are not in contrast with the AF and EF PHBs reviewed in earlier chapters. Implementing both services requires configuration of appropri- ate filters at the edge of the network to correspond to the required services. Referring to a case of a company with multiple users, the authors of [RFC2638] propose a bandwidth broker as an entity into which organizational policies can be configured, and which can use these – together with the knowledge of existing connec- tions – to make classification decisions for service instantiations. The reference model is based on requesting the decision for new flows from the bandwidth broker. The function of a bandwidth broker – as defined in [RFC2638] – is twofold: 256 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL • Keep track of traffic allocations in the domain the resources of which it is responsible for; and configure edge routers ac- cordingly. • Manage resource allocation messages sent to other domains. Related to the first of these tasks, a bandwidth broker is responsi- ble for receiving and authenticating resource allocation requests, each consisting of service type, target rate, maximum burst size, and of time period for the service. For admitted requests, network elements may need to be configured in the domain the bandwidth broker is responsible for, or a bandwidth broker in another domain may need to be contacted. In [RFC2638], it is suggested that per- flow configurations in edge routers be of soft-state type – that is, they need to be refreshed periodically in order to stay valid. The bandwidth broker concept of [RFC2638] has been used in the QBone bandwidth broker architecture, which is our next topic. 8.1.2 Bandwidth broker in QBone architecture The QBone architecture [THD99, QBA02], aimed at being a basis for bringing service quality support to the Internet, has been dis- cussed several times in the previous chapters. The architecture is based on DiffServ, and subsequently the following goals and constraints for intra- and inter inter-domain QBone resource man- agement solution have been put forth: • Aggregation of flows into aggregates (basic DiffServ principle). • The minimum requirement for interoperation between operators is capability of making bilateral SLAs. • The flexibility for per-domain resource management should be maximized. The target has been to make the inter-domain resource manage- ment scheme of QBone consistent with the DiffServ approach. The QBone bandwidth broker, in general, can interface to different types of network elements, including other bandwidth brokers, routers, application servers, end systems, and network operators [QBB02]. The interfaces are illustrated in Figure 8.3. The second boundary condition for the QBone inter-domain solu- tion is the set of services provided. The flagship service is the QBone Premium Service (QPS). An instantiation of QPS requires a number 8.1 PREVIOUS STUDIES 257 Inter-domain Adjacent BBAdjacent BB Application server Network operator Edge router(s) Edge router(s) User/host Intra-domain User/App iface Data store Routing info NMS iface PM iface ‘‘Simple’’ policy services Figure 8.3 The interfaces and internal structure of a QBone bandwidth broker  Internet2 QBone Source : From [QBB02] of parameters to be specified between the service providers and the customers. The parameters are: • start and end times; • source and destination; • MTU size; • peak rate. The following unidirectional guarantees are provided to service instances using QPS service quality support: • No loss due to congestion. • No latency guarantees. • Worst-case jitter bounds (IPDV) except in the case of IP rout- ing changes. The above guarantees can be implemented by providing sufficient resources for all momentary QPS aggregate loading situations on all links, but allowing for queueing in routers. In the QBone parlance, a bandwidth broker is a recommended entity (“oracle”), responding to admission requests for network 258 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL resources in a QBone domain. These requests, called Resource Allocation Requests (RARs), may be made by an element from the domain under the control of the bandwidth broker in question, or by a peer bandwidth broker. The bandwidth broker responds to RARs with a Resource Allocation Answer (RAA), constituting either a confirmation or denial of the request. Specifically, it is the task of a QBone bandwidth broker to make sure that the SLSs with peering QBone domains are fulfilled. Track- ing the admitted connections and SLSs established with peering domains are identified as means of accomplishing this task. The possibility of involving policy decision and enforcing points in the process is mentioned. An admitted service instance may lead to a need to reconfigure policing rules in boundary routers of neighbouring domains. An example of allowing temporarily 10 Mbit/s of traffic instead of 1 Mbit/s is given. Further, the possibility of making traffic con- ditioning dependent on routing is mentioned. Presumably band- width broker is a seen of a technology enabler for dynamic polic- ing in this context. Three protocol interface classes are discussed: • User/application protocol. This interface carries the RAR and RAA messages. Requests can be performed by humans, or are carried between automatic systems using a protocol such as RSVP. • Intra-domain protocol. This is used for element configuration. COPS, Diameter, SNMP, and vendor-proprietary interfaces are listed as examples of protocols for this interface. • Inter-domain protocol. Bandwidth broker peering makes use of this interface. Relevant data interfaces include: • Interface to routing tables. The bandwidth broker needs to know the up-to-date routing topology of the DiffServ domain to be able to handle resource management. Routing may change for the reasons discussed in Chapter 4 and Chapter 5. • Interface to data repository. Data stored in the repository include SLS information, reservations, router configurations, service/service quality support aggregate mappings, NMS information, monitoring information, and other policy interface. In the draft QBone bandwidth broker architecture outline [QBB02], two implementation phases of bandwidth broker have been 8.1 PREVIOUS STUDIES 259 described: phase 0 and phase 1. These will be described in the following. 8.1.2.1 Phase 0 bandwidth broker End-to-end service level assurance in the architecture correspond- ing to Phase 0 is based on static SLSs between neighbouring QBone domains. A phase 0 bandwidth broker does not perform signalling to peer brokers in other QBone domains. Between the network elements and the bandwidth brokers of the source and destina- tion domain, a protocol for performing RAR/RAA signalling is assumed. This protocol can also be of non-automated form, for example, a telephone call to a human responsible for resource allocation of the domain. The end-to-end resource management is proposed to be handled by a Bandwidth Czar, to which/whom traffic demand matrix is communicated by per-domain bandwidth brokers – by their oper- ating system running on carbon or silicon hardware. The Czar makes appropriate requests for resources in transit domains. At minimum, phase 0 bandwidth broker does not differ very much from “statically” provisioned network domain with SLAs towards the end users and peer domains. Resource management can be taken care of with the basic assumption of static SLAs, and handling momentary bandwidth needs as special requests. There may be a direct protocol such as RSVP used between the communication endpoints, but it is not assumed to affect the transit domain along the path of the service instance. 8.1.2.2 Phase 1 bandwidth broker Phase 1 bandwidth broker addresses two new questions: that of automated communication between peer bandwidth brokers on the one hand, and that of performing automated end-to-end reservation set-up. The latter also includes the task of setting up adequate service quality support in access networks. In Phase 1, SLSs are assumed to be already established – pair- wise – between DiffServ domains that are participating in the phase 1 bandwidth broker scheme. Dynamic SLS negotiation was defined to be outside of the description of the functions of basic bandwidth broker. Bandwidth brokers are assumed to be able to 260 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL signal directly also to peer brokers in non-neighbouring domains. Further, globally known service types are assumed. The mapping of services to DSCP markings is defined separately for each domain. DiffServ interworking on DSCP marking level is not part of the QBone phase 1 scheme. Three different cases are analysed: 1. An end system requests service to a fully specified address. 2. End system or bandwidth broker requests service to a destina- tion prefix (domain). 3. Bandwidth broker receives a request for fully specified destina- tion and uses an aggregate for satisfying the request. In the first case, end-to-end signalling is implemented by pair- wise exchange of messages between logically adjacent entities. The actions taken by the bandwidth broker in the originating, transit, and destination domains is analysed in the QBone bandwidth bro- ker document. The full details are not reproduced here, and can be found in [QBB02]. The second case is essentially a request to establish a one-way tunnel between the originating and destination domains. Such an aggregate is called a core tunnel. Tunnels can be requested by end systems capable of aggregating their requests, or by a bandwidth broker. In both cases, intelligent aggregation policy can reduce resource reservation signalling considerably. This kind of aggregation is especially useful when there are many flows to a non-adjacent domain. By aggregating the flows in the tran- sit domain, the need to perform per-flow resource reservation in transit domains is avoided (see Figure 8.4). Only the bandwidth brokers at the end of the tunnels need to be concerned with the actual aggregation of flows. The bandwidth brokers of the interme- diate transit domains only deal with aggregated service requests. The mechanism for triggering the establishment of a tunnel is excluded from the discussion in the QBone document. The third case is actually a special use case of scenario 2. In this case, the bandwidth broker handles a fully specified endpoint request internally by performing admission control to an estab- lished core tunnel. The difference between doing admission to core tunnel and to an inter-domain SLS is that core tunnels can be set up according to need. The reason for a bandwidth broker setting up [...]... multiple “incoming” funnels can be merged into an outgoing funnel An example of end-to-end path consisting of funnels is shown in Figure 8.5 Traffic is assumed to be policed at least in the ingress of the network domains Per-flow policing can be performed in the access domain, and egress policing, when used, can be based on network destination QA IP domain Endpoint QA IP domain QA IP domain IP domain IP. .. the bandwidth broker as service quality support aggregates on individual links and on the domain level The bandwidth broker is aware of IP routing topology consisting of links between routers A link of the routing topology may actually a link layer tunnel spanning multiple routers In addition, the bandwidth broker is assumed to be aware of factors affecting service quality support capacity on individual... by an end system is of a Request Allocation Request (RAR) type, transferred using a suitable protocol In the general case, RARs include service quality support requested, flow descriptor, and endpoint identity information (IP addresses) In addition, the bandwidth broker may support the specification of an advance request starting and ending times From the viewpoint of signalling, service quality support... multiplexing gain may necessitate the use of measurements to complement bookkeeping This is more typical of access networks than of backbone networks, which is why any possible bandwidth brokers in transit backbone domains can be expected to mostly rely on bookkeeping Different kind of measurements can be used to obtain information about loading in the network In view of the target of maximizing multiplexing... to the Phase 0 of QBone bandwidth broker scenario Another scenario in which no direct inter-domain bandwidth broker signalling is needed is the ETSI EP TIPHON model in which end-to-end service quality allocation is performed on the service level [TIPHON-3] In this case, there would be end-to-end per-flow signalling “above” bandwidth brokers Per-flow requests between BBs correspond to the fully signalled... quality support instantiation control This task includes only connection admission control related functions • Domain control This task includes connecting of traffic engineering type optimizations of IP transport with the data available to the bandwidth broker • Inter-domain signalling Communication with peer bandwidth brokers in other domains is a further task of the generic bandwidth broker These... broker concept to service level admission control and traffic engineering are discussed The generic bandwidth broker discussed below is a logical function, and its function can be distributed into multiple actual network elements within a network domain Such distributed architectures can be made in many different ways In the next chapter, we shall encounter a specific example of a bandwidth broker responsible... Schel´ n’s reference model A QoS agent is aware of resource e availability in the domain under its control, as well towards other domains For the domain under its own control, the QoS agent is aware of IP topology A QoS agent can also delegate requests to other QoS agents as necessary A QoS agent learns the topology for its domain of control by querying the routing table from the routers within that... CONTROL or by peer bandwidth brokers Listing service domain as one possible user of bandwidth broker services makes it possible to implement the logical separation between service and transport domains [TIPHON-3] The request mechanism in the bandwidth broker supports at least immediate reservations made as part of service instantiation, but may also advance reservations [FG95, Sch98, LCH01] The latter... quality support is needed One technical detail relating to resource management under QoS agent’s “own” domain, the QoS agent can listen to OSPF routing messages to have up-to-date knowledge of logical IP topology Schel´ n’s model does not require all e the elements of the DiffServ framework to be in place, but 264 MECHANISMS FOR DYNAMIC SERVICE QUALITY CONTROL includes policing of traffic at the edge . policing, when used, can be based on network destination. IP domain IP domain IP domain IP domain IP domain Endpoint Endpoint QA QA QA QA Figure 8.5 Funnels. This is one of the models discussed in end-to-end ETSI EP TIPHON service quality support model [TIPHON-3], and has been analysed in detail by Schel ´ en [Sch98].