Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 1

Transcription

1 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 1 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement Manzoor Hashmani, Koichi Tajima, Junichiro Sueishi, Mikio Yoshida, Takeshi Ikenaga, and Yuji Oie Abstract-- Inter-Domain QoS routing (route selection from multiple available routes traversing multiple domains) simply on the basis of hop count does neither ensure optimal resource utilization nor SLA fulfillment. Although some schemes (BGP-4) provide policy based routing, they are not suitable in many cases, for example, in case of resource reservation. In this paper, we argue that these schemes alone are not suitable for Inter-Domain QoS routing and propose a solution in the form of a server based cost evaluation and decision enforcement mechanism. We show that our proposal provides a feasible solution, which is based on cost evaluation and SLA. We also briefly discuss the implementation of our proposal. Index Terms QoS, QoS Routing, Bandwidth Broker, Cost Evaluation. I. INTRODUCTION HE wide spread popularity of the Internet is a great Tmotivation for many businesses to use the Internet for their business transactions. However, the main hindrance in achieving this objective is the basic philosophy of the current Internet. That is, it tries to handle traffic from all applications in a fair manner and puts in its best effort to try to make it through to the destination. However, this is not acceptable to the mission critical applications of businesses, which want their traffic to be differentiated and given better treatment. In return these businesses are willing to pay some extra amount. In other words these businesses want assurances on the Quality of Service (QoS). A lot of research is going on in this field. A well-known QoS architecture proposed in the IETF (Internet Engineering Task Force) is the Differentiated Services (DiffServ) [1][2] architecture. This architecture is supposed to be better scalable than the other architectures of this field, e.g., Integrated Services (IntServ) [5] architecture, which was also proposed by the IETF but much before DiffServ. In DiffServ, a network is divided into manageable domains. The guarantee of end-to-end QoS can be provided by only taking necessary actions within a domain (Intra-Domain) and between domains (Inter-Domain). Manzoor Hashmani is with the NS Solutions Corporation, Fukushima, Osaka , Japan ( hashmani.manzoor@osk.ns-sol.co.jp). Koichi Tajima is with the NS Solutions Corporation, Fukushima, Osaka , Japan ( tajima.koichi@osk.ns-sol.co.jp). Junichiro Sueishi is with the NS Solutions Corporation, Fukushima, Osaka , Japan ( junichiro.sueishi@osk.ns-sol.co.jp). Mikio Yoshida is with the NS Solutions Corporation, Fukushima, Osaka , Japan ( yoshida.mikio@osk.ns-sol.co.jp). Takeshi Ikenaga is with the Kyushu Institute of Technology, Iizuka-shi , Japan ( ike@cse.kyutech.ac.jp). Yuji Oie is with the Kyushu Institute of Technology, Iizuka-shi , Japan ( oie@cse.kyutech.ac.jp). Since 1997, we are engaged in conducting research and experiments in this field [6][7][8][9]. Initially we proposed, designed, and implemented a Bandwidth Broker (BB) for the Intra-Domain purpose only to provide a Virtual Leased Line (VLL [1]) service over the Internet to the mission critical applications of the contents business. The experiments were performed over a wide area network in Japan [6]. Since its first inception, we have been constantly enhancing our model and implementation to cover all aspects of end-to-end QoS [7][8][9]. In this paper, we focus our attention on the issue of Inter-Domain QoS routing. We argue that the Inter-Domain QoS routing is an important issue and that the current schemes alone cannot fulfill the requirements of the Inter-Domain QoS routing to achieve the overall objective of assurance of end-to-end QoS. To provide a solution of this problem, we first of all analyze the basic functions required. As the next step we compare and contrast the models, which can satisfy our requirements. We make a tradeoff and select a suitable model. Based on this model we propose a two-tier architecture in which information collection and decision-making are performed in one tier (a server) and the decision implementation are performed in the second tier (network). The rest of the paper is structured as follows. In section II, we introduce the basic concepts of QoS and QoS routing to prepare for the understanding of the problems and issues described in section III. In this section, we also describe the motivation behind our research. In section 0, we compare and contrast two architectural models to meet our requirements. We also elaborate our proposed solution in this section. We provide detailed discussion of our proposed architecture in the next section (section V). In section VI, we describe the design and implementation of our proposed system and finally we conclude in section VII. II. BASIC CONCEPTS OF QOS AND QOS ROUTING In this section, we describe the general concepts related to QoS and QoS routing. It is not our intention to cover QoS in a broad sense but rather to write a short introduction of QoS related concepts in order to make the reader understand the problems identified in the next section. The general method of describing concepts is to take a top down approach. However, we are going to describe these in a bottom up manner because the same approach has been taken during their development in various standards organizations like IETF.

2 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 2 A. DiffServ Architecture The Differentiated Services working group of the IETF has proposed an architecture called Differentiated Services (in short DiffServ) to provide assurance of hop-by-hop guarantee of QoS [2]. In this architecture, a network is divided into manageable domains called Differentiated Services (DS) domains as shown in Fig. 1. criteria may depend on one or more parameters. For example, in the current Internet, generally speaking hop count (shortest path) is used to select a route to a destination. This is the simplest form of QoS routing. Recently usage (bandwidth-based) parameter is being considered in research community as another route selection criteria [14]. DS Domain DS Domain DS Domain DS Domain BB BB BB BB S R S R Router Link Router Link Fig. 1. The DiffServ Architecture Each node (router) in a DS domain is responsible for providing particular traffic treatment called Per Hop Behavior (PHB). Till today, DiffServ working group has proposed two PHB groups (other than default PHB and class selector PHB) for the use of applications, namely, EF (Expedited Forwarding) PHB [3] and AF (Assured Forwarding) PHB [4]. Note that the operations performed within a DS domain are called Intra-Domain operations and those that are performed between domains are called Inter-Domain operations. B. Bandwidth Brokering As described in the previous sub-section, DiffServ architecture provides guarantee of hop-by-hop QoS. In order to provide a guarantee of end-to-end QoS, resources (primarily bandwidth) in all nodes in each DS domain need to be managed by a server (Bandwidth Broker (BB)) as shown in Figure. In [6] we proposed to perform admission control by the BB on the basis of record keeping of bandwidth reservation. In addition to performing record keeping of bandwidth reservation in its domain, each BB requests its neighboring BBs to perform bandwidth reservation in their respective domains. This results in a chain reaction and thus enables an end-to-end bandwidth reservation. C. QoS Routing The QoS routing can be defined as the selection of a route from multiple available routes based on some criteria to achieve some predefined objectives [14]. The route selection Fig. 2. Bandwidth Broker Architecture Intra-Domain and Inter-Domain QoS Routing QoS routing (section 0) performed within a domain is termed as Intra-Domain QoS routing while among domains it is called Inter-Domain QoS routing. In case of Inter-Domain QoS routing, each domain acts like a closed box denoted by a set of attributes like available bandwidth, delay, latency, jitter etc. For example, in Fig. 3, route selection performed within DS Domain #1 from Router #1 to #4 based on some criteria (hop count and/or bandwidth availability) falls in the category of Intra-Domain QoS routing. Note that multiple routes exist between Router #1 and #4 via #2 and #3. On the other hand a similar topology exists in case of DS domains too. Route selection from DS Domain #1 to #4 (multiple routes exist via DS Domain #2 and #3) falls in the category of Inter-Domain QoS routing. In Inter-Domain perspective, topology in each domain is not taken into consideration and each domain acts as a node only. The Intra-Domain and Inter-Domain QoS routing can be performed on the basis of various parameters, for example, hop (domains) count, bandwidth availability, delay and SLA (Service Level Agreement). D. SLA and Policy When a network can differentiate on the basis of users and services, we need some policy to decide which users get which service. This type of policy may come directly from the network administrator or it may even come after translation from the SLA (Service Level Agreement) committed between

3 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 3 the network service provider and the service user. Therefore, SLA and policy are the driving force for QoS enabled network [9]. DS Domain #2 information may be restricted. And the other issue is that all concerned domains may not be speaking the same standard protocol for the purpose of disseminating this information automatically. On the other hand, if we try to collect this information through network operators, we face a lot of inter-human communications, which may be complex and erroneous. DS Domain #1 Router #1 Router #2 Router #3 Router #4 DS Domain #3 Fig. 3. Intra-Domain and Inter-Domain QoS Routing DS Domain #4 In the Intra-Domain perspective, the policy and SLA for VLL like service are simple because only bandwidth is important and the delay management may not be needed due to its small values. On the other hand in case of Inter-Domain, delay may substantially vary depending on the selection of routes (domains). III. RESEARCH MOTIVATION AND PROBLEM IDENTIFICATION In today s Internet, it is highly likely that multiple routes (intra-domain and inter-domain) exist between a sender and a receiver regardless of whether they lie in the same domain or in different domains as shown in Fig. 3. Finding a feasible route within a domain and between domains has similar as well as different kind of problems. The basic issues are listed and discussed below. We elaborate on our proposed solution to each one of these in section 0. B. Route Selection Criteria (Cost Evaluation) Once we have found or calculated (from topology map) all possible routes from a sender to a receiver, we need to find the most feasible route using some selection criteria. This criterion is called as cost evaluation criteria. The cost evaluation in the current Internet, at present, generally consists of hop count (minimize hops to find shortest path). Recently a new parameter (bandwidth availability) is also being considered as cost evaluation parameter. Like the topology information collection, the cost evaluation based on the bandwidth reservation is a simpler problem in Intra-Domain perspective. One BB accepts or rejects reservation requests, which is also called as admission control. It then updates its record of reserved bandwidth in the links in its domain. The centralization of reservation information eliminates the problems like collection and consistency of information. This, however, is achieved on the cost of robustness of the system in case of server failure. On the other hand if we look at this issue from the Inter-Domain perspective (consider Inter-Domain links only), we find that reservation information is distributed in many BBs. So we require a method to collect this information when we need to apply this criterion to select a feasible route from a sender to a receiver traversing multiple domains. In case of Inter-Domain route selection, the policy/sla becomes a very important parameter. Different SLAs may exist between different domains lying between a sender and a receiver. Some domains may not be available to a sender domain as transit. A sender domain may also prefer to transit through a particular set of domains. These need to be applied during route selection process. A. Topology Information Gathering The first step in order to find a feasible route from a sender to a receiver (Intra-Domain as well as Inter-Domain) is to create a topology map as shown in Fig. 3. This is necessary to find (calculate) all possible routes from a sender to a receiver. In the Intra-Domain case, this is a simpler problem because all network resources are managed by a single logical organization. So it is relatively easy to collect this information. The information may be collected automatically by analyzing routing tables in routers or it may be acquired through a network administrator. In case of Inter-Domain, collection of information to make Inter-Domain topology map is more complex. The policy of each domain regarding dissemination of reachability C. Decision Implementation or Route Pinning The final step in the QoS routing process is the enforcement of the decision (selection of a route). This is done using route pinning, a method of fixing the route (for a pair of sender(s) and receiver(s)). Many methods/protocols are available for this purpose, for example, static routing, source routing, MPLS [12], and BGP [10][11] etc. Each of these schemes has its advantages and disadvantages. Same one method/protocol may not be suitable for both the Intra-Domain and Inter-Domain route pinning. We consider this issue as part of our proposal in section 0. D. A Possible Overall Solution (BGP) Because BGP (latest version is BGP4) can be used to

4 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 4 disseminate reachability information of a domain and at the same time it can also used to set the preference of a route using simple policy [10][11], we consider this protocol as one possible overall solution to construct a VLL across many domains. However, after careful consideration we find that BGP is not designed to evaluate (perform cost evaluation) and decide in favor of a particular route from multiple available routes. Rather the primary function of BGP is to disseminate reachability information after applying policy if necessary. If we try to use BGP for route selection purpose, we have to do it in a distributed environment. Note that no BGP node possesses the map (topology) of the domains. Therefore, someone in the sender s domain must at first trace all possible routes from this domain to the destination domain. This alone will result in a lot of communication between BGP nodes. As the next step of performing cost evaluation on the basis of policy, a protocol has to be designed to get and process policy information available in all BGP nodes. It is not possible for BGP nodes to perform cost evaluation on the basis of bandwidth (future) reservation because the current standard of BGP does not possess reservation data. From the discussion it is clear that BGP alone cannot provide overall solution to our identified requirements. However, we can use BGP as part of our overall system to do what it is supposed to do, that is, disseminate the reachability information and preference of the selected route. We evaluate the feasibility of BGP in section 0. IV. OUR PROPOSAL From the discussion (section III), we conclude that we need to do route selection (Inter-Domain) based on the following three parameters in order to construct a VLL like service over the Internet for the mission critical applications. Hop Count Bandwidth Availability SLA/Policy Based on these parameters, we basically need to perform the following three functions to achieve our objective. Topology Information Gathering Decision Making (Route Selection) Decision Implementation (Route Pinning) The above stated functions can be logically divided into two layers, the above layer performing decision-making and the lower layer responsible for implementing the decisions made in the above layer. Therefore we propose a two-tier system as shown in Fig. 4 and described below. Query: Need Routes up to DS4 BB1 DS1 Fig. 4. Two-Tier System For Inter-Domain QoS Routing A. Tier #1: Decision Making (DM) Tier The DM tier is responsible to take decisions regarding intra-domain and inter-domain route selection. To facilitate the decision-making the primary information available to DM tier is the topology information, reservation information and policy derived from SLA. Obviously, DM needs to perform cost evaluation, which is a calculation intensive process. From the above discussion, we conclude that the DM of our system must consist of two servers, i.e., Bandwidth Broker (BB) server and Inter-Domain Topology (IDT) server. 1) Bandwidth Broker (BB) Server The BB is responsible to perform all Intra-Domain actions and functions necessary to perform bandwidth reservation. A BB may also include SLA and policy management to facilitate bandwidth reservation. The BB shown in Fig. 4 is a logical component. In actual system, it may be implemented using multiple servers (see [6][7][8][9] for details). For example a separate server for policy management may be provided or it may be implemented as part of BB. 2) Inter-Domain Topology (IDT) Server This server possesses data regarding the following two items for all the DS (DiffServ) domains managed by it. Domain Reachability Bandwidth Availability in Inter-Domain Links a) Function DS1-DS2-DS4 DS1-DS3-DS2-DS4 SLA SLA Route Pinning Route Pinning Topology Server A SLA BB3 The primary function of IDT server is to possess the data regarding domain reachability and bandwidth availability in the inter-domain links and provide the same when requested primarily by BB servers when a route selection decision is to be made. BB2 Route Pinning DS3 DS2 SLA Route Pinning BB4 DS4 Topology Server B

5 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 5 b) Scope The minimum number of DS domains whose topology map is possessed by an IDT server is two. We assume that the maps possessed by two IDT servers are mutually exclusive to eliminate the need of providing consistency of maps. Typically one IDT server would possess map of all or some DS domains of an organization. For example, large countries (in terms of number of Internet users) may have one IDT server. On the other hand small countries may form regions each having one IDT. The size and scope of an IDT server is a scalability and political issue, which needs more study and experimentation. a) Static Routing In case of static routing, the BB servers of all domains of the selected route have to send configuration (route information) to all routers in their respective domains. This ensures robust enforcement of decision but at the same time tremendously increases the amount of the operations performed by the BB. The amount of operations becomes directly proportional to the size and number of domains. However, the support of static routing is available in all routers. Therefore, this method of route pinning though robust may not be scalable. c) Data Collection Method The data regarding domain reachability can be collected using many methods. For example, BGP4 can be used to get this data or a network administrator may provide it. On the other hand, only BBs can provide the bandwidth availability information in Inter-Domain links. In case of BB failure, the network administrator provides this data. But when the BB becomes active again, the data must be updated so as not to create conflict with either SLA/Policy and/or status of bandwidth availability. d) Location An IDT server may be physically located in any one of the domains included in its scope. However, it must be reachable by BBs of all domains in its scope. In the current implementation BBs find out about an IDT server through static configuration provided by the network operator. B. Tier #2: Decision Implementation (DI) Tier Decision regarding route selection taken in the DM tier of our system must be implemented in the DI tier so that the traffic travels the selected route. DI tier consists of the network nodes (routers and hosts). The decision implementation means fixation of the route (route pinning) at the necessary points (nodes). Obviously, the choice before us is to either choose one of the available protocols for this purpose or propose a new protocol in case if the available protocols are not suitable to fulfill our requirements. Contrary to the DM tier, DI tier is operation intensive. By operation, we mean the operation of connecting to the network device and then sending configuration information for implementation. 1) Route Pinning (Static Routing, Source Routing, MPLS BGP) As available methods of route pinning we consider static routing, source routing, MPLS and BGP. Let us now consider the advantages and disadvantage of each of these schemes. b) Source Routing In source routing, the route (selected) information is inserted in each transmitted packet by the sender. The support for source routing is available in all routers. This makes source routing a very robust method of route pinning like static routing. However, there is a great concern regarding security. Misbehaving senders can insert false routes in their packet to chock specific routers thereby creating Denial of Service (DoS) attacks. c) MPLS MPLS can be used to created fixed pipes within a domain. These pipes can be created before reservations are made and then the flows can be mapped to these pipes. The mapping requires that only the ingress routers (where traffic enters in a domain) insert a label corresponding to the selected route in each packet of the flow. This method of using MPLS for route pinning requires communication of BB with only ingress router for each route pinning decision and also eliminates the need of complex label distribution and management. On the other hand, one can also fix routes dynamically when flows are generated. This requires real time distribution of labels to routers using protocols like LDP (Label Distribution Protocol) [13], which in turn reduces the scalability of the system. A better scalable and robust idea would be to create fixed pipes (main routes in the domain) beforehand and then use dynamic route pinning for those routes which are less likely to be used for Premium service. In fact this is the approach that we are planning to implement in our proposed system. d) BGP The inherent capability of BGP to propagate reachability information and also set the preference of a route as a policy can be used to perform route pinning. However, this method of route pinning may not be very robust because the BGP routers propagate routing information on a neighbor-by-neighbor basis based on the policy provided by the administrator. If one of the domains could not enforce route pinning due to conflicting policy, it would be very difficult for the BB, which initiated route pinning to find out about the problem.

6 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 6 Moreover, BGP is used to propagate relatively static routes. Hence, it is not suitable for enforcement of real time route pinning decisions. C. Overall Operation In this sub-section, we describe the overall operation of creating a virtual leased line between a sender S and a receiver R using Fig. 5 and Fig. 6. We assume that the topology of DS domains creates multiple routes from the sender S to the receiver R. The portion of the algorithm implemented in BB concerned with the selection of route in the Inter-Domain perspective is shown in Fig. 6. The overall operation consists of the following steps. Inter-Domain Topology (IDT) Server from S to R. Thus the route selection decision is made. 5. The selected route is used by the decision implementation tier to perform route pinning using a combination of static routing, MPLS and possibly BGP. Source routing is not used at present due to security concerns. The route and reservation information are also sent to the relevant neighboring BB to take proper actions in its domain. Is Inter-Domain Route Selection Required? Yes No Topology is downloaded from Inter-Domain Topology (IDT) Server. IDT may in turn request relevant neighboring IDT to provide relevant topology. Note that topology objects also contain reservation information. BB of the domain of sender selects a route and requests relevant neighboring domain(s) to make reservations. Intra-Domain modules of BB are activated BB BB BB BB BB of the domain of sender sends reachability information of the selected route to the BGP4 node and lets BGP4 disseminate this information. Hence the selected route becomes established. End S R Fig. 6: Algorithm of Inter-Domain QoS Routing Implemented in BB Router Fig. 5. Inter-Domain QoS Routing Link 1. S sends a request to the BB of its domain to create a VLL up to R. 2. BB checks the destination IP address to see if R lies in its own domain. If the R lies in its own domain, the concerned Intra-Domain modules are activated to admit or reject the request based on the SLA/Policy and/or bandwidth availability. If the R lies beyond this domain, and sufficient resources are available in this domain, then we proceed to step 3 otherwise the process is ended. 3. The concerned IDT server is contacted to provide reachability information of the destination domain (domain in which R lies). If the destination domain is beyond the scope of this IDT server, it is the responsibility of this IDT server to contact relevant neighbor IDT server and make the same request. This makes a chain and as a result the BB of the sender s domain gets the overall reachability information (in the form of a set of the feasible routes) from IDT server to which it initially sent the request (Fig. 4 and Fig. 5). 4. The BB then applies relevant policy rules, SLA and/or bandwidth availability state to the routes obtained from the IDT server in order to find a unique feasible route V. DISCUSSION Due to the huge size and heterogeneity (underlying technologies) of the current Internet, any new system, which attempts to provide a service over the Internet needs to be scalable. Otherwise it will die its natural death. Therefore, in this section we evaluate (through arguments) the scalability of our system in terms of the following topics. Distributed v/s Central Management Information Gathering & Dissemination A. Distributed v/s Central Management The level of distribution results in the level of scalability at the cost of efficiency. For example, high level of distribution results in high level of scalability with low efficiency (processing time, resource utilization etc). Only infinite amount of resources can allow us to neglect efficiency as a factor, which is not available in any case. Absolute centralization or distribution will probably not lead to desirable results in a complex system like that of the Internet. As the Internet is supposed to and prepared to provide more complex services like that of QoS, routers will become overburdened. Routers cannot and may not provide all of these services. Hence, we need to make a tradeoff between centralization and distribution of data and processing in order to maximize scalability and efficiency.

7 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 7 We have taken an approach that we call as distributed-centralization (in upper tier). The level of distribution in case of the lower tier is as good as that of the Internet. The BB servers in the upper tier are data and processing intensive, we therefore suggest that these may manage small domains typically that of an ISP. On the other hand, the IDT server has very little processing to do and has little amount of data to manage. Therefore, it can manage large number of domains. Typically one IDT may be sufficient to handle a large country (in terms of Internet users). We therefore, expect that our system would scale well over the current Internet in terms of distribution of data and processing. B. Information Gathering & Dissemination Information gathering is done in order to facilitate the decision making of route selection and information dissemination is used to facilitate the enforcement of the decision. The main concern in information gathering and dissemination process is the scalability. As described in the previous sections, the information gathering is done through already available protocols or through network administrators and its dissemination is performed through a combination of existing methods (Static Routing, Source Routing, MPLS, BGP) only. In case of network administrators, the reliability and consistency of the provided data becomes questionable. In case of large systems this method may not be scalable. On the other hand, if we use existing protocols for information gathering and dissemination the scalability of overall system is directly proportional to the scalability of these protocols. Since, we use these algorithms in a way, which is the primary purpose of these algorithms, these do not reduce the overall scalability of our proposed system. VI. SYSTEM DESIGN At present, we are preparing a system design in order to check if our system is realizable and that it would in fact fulfill our objective of performing Inter-Domain QoS routing. We are following a step-by-step or phased approach. A brief description of each step or phase is given below. A. Framework Design: A framework has already been finished whose main features have been described in section 0. B. Inter-Domain SLA An SLA based on the business needs and in the Inter-Domain perspective would be designed. This SLA would be implemented using the VLL like service provided by our proposed system. This SLA will also enable ISPs to select or exclude specific domain from the selection of routes to reach specific destinations. C. Module Design: Module design consists of designing modules of BB server and IDT server. During this phase, we decide the functionality contained in each module and the interaction of each module with other modules. Since we already have a functioning BB available, we need to modify its design (Fig. 7) to include Inter-Domain route selection functionality only. The module design of the IDT server has to be done from the scratch. BB TA RTK BC DC End User Application Application Manager AC RSC RT Router Fig. 7. Module Design of BB Scheduler event Network Operator Policy Manager AC: Admission Controller PF: Path Finder RTK: Resource Tracker BC: Bandwidth Calculator DC: Delay Calculator RSC: Router Setting Controller RT: Router Translator TA: Traffic Analyzer Inter-Domain Manager Directory VII. SUMMARY & CONCLUSION Businesses can benefit from the wide spread use of the Internet only if they can get services like a VLL for their mission critical applications. A VLL can be constructed if the Internet can provide a guarantee of end-to-end QoS. Generally speaking multiple routes from one end to the other are available (traversing many domain or autonomous systems). To realize the guarantee of QoS, one feasible route has to be determined and pinned using cost evaluation. Cost evaluation requires information gathering and record keeping at some central point for efficiency. This is complex functionality and is not available in the current Internet. Nor can it be created by the available protocols like BGP alone. We have discussed these issues in our paper and proposed one solution after analysis. We propose a two-tier scalable system in this paper in which the upper tier is responsible to take a route selection decision based on cost evaluation (hop count, bandwidth reservation and SLA/Policy) and the lower tier is used to implement the decision in the form of route pinning using available methods (static routing, source routing, MPLS and BGP). PF

8 Server-Based Inter-Domain QoS Routing: Cost Evaluation and Decision Enforcement 8 ACKNOWLEDGMENT This work was partly supported by the Telecommunications Advancement Organization (TAO) of Japan. We thank Professor Shinji Shimojo of Osaka University, Japan for his valuable comments and continuous feedback. REFERENCES [1] K. Nichols, V. Jacobson and L. Zhang, A Two-bit Differentiated Services Architecture for the Internet, RFC2638, July [2] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss, An Architecture for Differentiated Services, RFC2475, December [3] V. Jacobson, K. Nichols and K. Poduri, An Expedited Forwarding PHB, RFC2598, June [4] J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, Assured Forwarding PHB Group, RFC2597, June [5] J. Wroclawski, The Use of RSVP with IETF Integrated Services, RFC 2210, September [6] Akira Shirahase, Manzoor Hashmani, Mikio Yoshida, et al., "Design and Deployment of QoS Enabled Network for Contents Businesses," International Conference on Computer Communication 1999, Tokyo Japan, September 14-16, [7] Koichi Tajima, Manzoor Hashmani and Mikio Yoshida, A Resource Management Architecture over Differentiated Services Domains for Guarantee of Bandwidth, Delay and Jitter, Information Systems for Enhanced Public Safety & Security (EuroComm2000), Munich Germany, May [8] Manzoor Hashmani and Mikio Yoshida "ENICOM's Bandwidth Broker," Saint 2001 Workshops, pp , San Diego USA, Jan 8-12, [9] Manzoor Hashmani, Mikio Yoshida, Takeshi Ikenaga, and Yuji Oie, Management and Realization of SLA for Providing Network QoS, to appear in proceedings of International Conference on Networking ICN 01, Colmar France, July 9-13, [10] Y. Rekhter and T. Li, A Border Gateway Protocol 4 (BGP-4), RFC1771 March [11] Y. Rekhter and P. Gross, Application of the Border Gateway Protocol in the Internet, RFC 1772, [12] E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching Architecture, RFC3031, January [13] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, LDP Specification, RFC3036, January [14] E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, A Framework for QoS-based Routing in the Internet, RFC2386, August 1998.