Bandwidth Broker Implementation: Circa-Complete and Integrable Shaleeza Sohail, Khoi Ba Pham, Richmond Nguyen and Sanjay Jha School of Computer Science and Engineering University of New South Wales, Sydney, Australia Correspondence Author:
[email protected] July 10, 2003
Abstract
aggregate. SLAs are complex business related contracts that cover a wide range of issues, including network Keeping in mind the present network management re- availability guarantees, payment models and other lesearch trends, it can be safely stated that in the near fu- gal and business necessities. SLA contains a Service ture enterprise networks and Internet Service Providers Level Specification (SLS) that characterizes aggregate (ISPs) will need a network management entity to dy- traffic profile and Per Hop Behavior (PHB) to be apnamically manage QoS networks. DiffServ is one of the plied to each aggregate. To automate the process of SLS emerging QoS networks that introduces bandwidth bro- negotiation, admission control and configuration of netker as its logical network and policy management mod- work devices correctly to support the provisioned QoS, ule. Due to the complex and huge functionality pro- each DiffServ network may be added with a component vided by bandwidth broker, it has unfathomable num- called a Bandwidth Broker (BB) [4]. ber of semi explored research areas and numerous reOn the inter-domain level BB is responsible of negosearch groups are working on its implementation. The tiating QoS parameters and setting up bilateral agreepaper explains a bandwidth broker implementation that ments with neighboring domains. On intra-domain provides basic inter-domain and intra-domain functionlevel BB’s responsibilities include configuration of edge ality. More importantly, it contains general interfaces routers to enforce resource allocation and admission which enable resource managers, which lack the ability control. In order to perform these functions BB mainto manage network resources on their own, to integrate tains policies and negotiates SLAs with customers and with its functionality of robust management of network neighboring domains. BB is a main resource manager resources. in DiffServ domain so whenever a flow needs to enter that DiffServ domain or a local user wants to send some traffic, BB is requested to check related SLA. BB, 1 Introduction on the basis of previously negotiated SLAs, decides as In order to support Quality of Service (QoS) in the to allow the traffic or not. In case of a new flow BB network, new architecture such as Integrated Services might have to negotiate a new SLA with the neighbor(IntServ) and Differentiated Services (DiffServ) have ing domain depending upon the traffic requirements . been proposed in the IETF. These architectures support Once BB allows the traffic, the edge router or leaf router diverse service levels for multimedia and real-time ap- needs to be reconfigured by BB. The paper explains a plications. DiffServ architecture is capable of provid- bandwidth broker implementation [9] that contains esing well defined end-to-end service over concatenated sential intra-domain and inter-domain functionality to chains of separately administered domain by enforcing enable BB to work as resource manager in any Diffthe aggregate traffic contracts between domains [5]. At Serv domain with static SLA management. Moreover, the inter-domain boundaries, service level agreements the implementation contains a number of interfaces for (SLAs) specify the transit service to be given to each users, applications and network administrator to request 1
network resources from BB. A generalized XML/SOAP interface provides a mechanism for any other resource manager to integrate with BB for managing network resources. The rest of the paper is organized as follows. Section 2 identifies and briefly explains some of the research efforts in the field of BB. Section 3 explains the architecture of bandwidth broker. Section 4 explains the implementation of BB in detail. Section 5 concludes the paper and identifies some implementation aspects that need more work.
vides QoS to its border crossing traffic by maintaining bilateral SLAs. However their BB implementation [11] [13] provides only intra-domain functionality. The above mentioned implementations provide BB’s functionality to some extent. The main purpose behind the implementation discussed in this paper is to provide a freely available BB that contains complete intra and inter domain functionality. The implementation, which we will call here as BBBasic , is designed in a platform independent manner that can be merged with any other resource manager to extend the ability of that manager to manage network resources.
2 BB Research Efforts
3 Bandwidth Broker Architecture
Internet2 QBone Bandwidth Broker Advisory Council was one of the first group that has defined the BB’s requirements[1] in detail and the initial draft of Simple Inter Domain Bandwidth Broker Signaling (SIBBS) protocol [2]. The research group at Merit [15] has proposed a multi-domain bandwidth broker model in which, with the help of some BB functionalities the support for virtual leased lines (VLL) can be implemented. The model due to its narrow scope only focuses on the role of BB in authorizing and establishing one type of service i.e; VLL, which is actually expedited forwarding (EF) PHB in multi-domain scenario. Charging and Accounting Technology for Internet (CATI) [17] [16] project tries to implement a charging and accounting mechanism based on the currently available IP protocols. Secure interconnection between private networks was the reason for emergence of virtual private networks (VPN). CATI introduces QoS support in VPNs with the help of service broker. Service broker sells the services according to specific terms. Service broker has the ability to negotiate service cost with customers and setup the service on approval of agreement. The brokers are designed in a scalable hierarchal fashion. The objective of CANARIE ANA project [14] is to implement a basic BB that is capable of providing differentiated services for CA*net II. CA*net II is a new high speed network for research and educational institutions that makes possible to run and manipulate advance applications, such as multi-media conferencing. University of Kansas research group makes its bandwidth broker as in-charge of intra-domain as well as inter-domain affairs and its basic model is proposed in [12]. Intra-domain affairs means that it keeps track of user’s QoS requests and allocates resources considering domains policies. At the inter-domain level BB pro-
BB is a complex entity and the functionality provided by BB is huge. In order to make BB more understandable, BB’s basic functionality is divided in following four distinguishable parts, which are also shown in Figure 1: 1. Inter-domain 2. Intra-domain 3. Database 4. User/application
3.1 Inter-domain The functionality provided by BB at inter-domain level consists of its communication with neighboring BBs in order to reserve resources in other domains. BB needs this communication when the destination of the user’s flow for which resources are requested is in another DiffServ domain. There are number of protocols that fulfill bandwidth broker’s intra-domain needs, however when it comes to inter-domain level , there is no single protocol that fits into the requirement of BB. Due to this complication Internet2 QBone BB advisory council has proposed a simple inter domain bandwidth broker signaling protocol in [2]. Simple Inter domain Bandwidth Broker Signaling (SIBBS) protocol follows request-response model between peer BBs and is sender oriented [2]. BBs have long running TCP connections with one another, TCP provides the basic reliability and flow control for the protocol. Whenever BB receives a Resource Allocation Request (RAR) from another BB, it checks sender’s authentication, the route, egress router for the flow, SLA 2
DATABASE
DATABASE INTERFACE O W N R O D U O T M E A R I S N’ S
INTRA DOMAIN
BANDWIDTH BROKER
INTER DOMAIN TO NEIGHBORING BANDWIDTH BROKERS
USER/APP INTERFACE
OWN DOMAIN’S USERS
Figure 1: Bandwidth Broker related to user or flow and policies related to the flow. In case of acceptance of request, if the destination of the flow is not in BB’s domain then BB propagates RAR to its neighbor BB which lies on the path of the flow. In this manner RAR propagates to the BB which contains the destination host in its domain. The Resource Allocation Answer (RAA), which is the response of RAR is sent back from the destination BB to the source BB. In the situation when the request is to be rejected then BB sends the Resource allocation answer (RAA) back to the BB from which it has received the request.
IP traffic and implements policy based admission controls for data flows, whereas PDP has complete view of network and configures its PEPs according to the network policies. BB is supposed to have the functionality of PDP and all the edge routers are configured as PEPs. COPS is a client/server protocol, where server (PDP) has a TCP connection with all its clients (PEP), so there is no need of reliability mechanism in the protocol itself [3]. PEP maintains Policy Information Base (PIB), described in [7]. For support of policy provisioning a new client type COPS for provisioning (COPS-PR) is introduced in [8]. It is independent of the type of policy being provisioned as it can be QoS or security. COPS-PR has support for real time event driven communication mechanism. PEP has only one connection to PDP in one area of policy control, it supports large atomic transactions of data and efficient error reporting. It has state sharing/synchronization and exchange differential updates only. On the time of boot-up the PEP establishes a connection with PDP and sends all device relevant information. PDP replies with all provisioned policies that are relevant to the device. In case there is some change in policies at PDP then it sends update message and if there is some change at PEPs end then it sends the changes to PDP which can reply with new relevant policy provisioning elements.
3.2 Intra-domain On the Intra-domain level BB needs to communicate to edge as well as core routers to pass policy decisions, the routers are configured according to policy decisions to provide QoS. There are multiple intra-domain protocols that can fulfill this requirement like COPS, SNMP and Telnet, however intra-domain protocol used in the DiffServ domain is of local significance to the network administrator. Common Open Policy Services (COPS) is the protocol standardized by IETF Resource allocation protocol (RAP) working group [6]. COPS is used to send policy decisions from policy decision point (PDP) to policy enforcement point (PEP). PEP has the ability to handle 3
COPS has some features that makes it suitable for using with BB. COPS has keep alive mechanism by which PEP knows that its PDP is up or down. COPS has the option for PDP to redirect a client if it does not support that client type or for load balancing. As QoS enabled services are highly vulnerable to denial and theft of services, COPS uses IPSec and integrity objects to provide the required security.
SLAs and requests. Detailed implementation description and exact implementation mechanism of BBBasic is available in [9]. Some implementation details of BBBasic are briefly explained in the following subsections.
4.1 Inter-domain
The implementation of inter-domain protocol is embedded in the BBBasic which is designed on the specifica3.3 Database tions of SIBBS [2] which is addressed as SIBBSBasic BB has a database interface to gather information for here. The design specifications of SIBBS protocol [18] decision making processes. To provide QoS in the net- does not explicitly state the mechanism by which BB work, BB must have a comprehensive picture of com- gathers information about the neighboring BBs and deplete network. In general the areas about which BB tails about their domains. SIBBSBasic collects this needs information are policy, SLA, network manage- information from its database, the database contains ment and current resource allocation status [2]. Routers comprehensive network map which enables BBBasic can also be configured to provide monitoring data to to identify its neighbor which should be contacted to enhance the security of the network and optimal re- complete users RAR. Whenever user’s requested resources include resource usage. Router’s configuration data and information about BB’s own components is also maintained for sources from other domains then BBBasic gather inthe purpose of fault tolerance. Many database manage- formation about the neighboring BBs and contact them ment systems are available that can fulfill BB’s database with SIBBSBasic . The neighbor BB checks its resources and if the request is accepted then propagates requirements such as MySQL, Oracle etc. the request to the next BB which lies in the direction of the destination of flow. The process continues till the 3.4 User/application request reaches the BB containing the destination host There is a need for a protocol or interface for network in its domain. The replies propagate back in the reverse operator and user/application to interact with the band- manner. After sending the RAA, in case of request acwidth broker. The network operator may use this inter- ceptance BBBasic configures its edge routers via intraface to monitor or update the performance related fea- domain protocol to allocate network resources for the tures of BB. The user/application requires the interface accepted flow. or protocol to request or query the BB.
4.2 Intra-domain
4 BBBasic Implementation
COPS-PR is used as the intra-domain communication protocol for BBBasic . COPS-PR [10] is an indepenBBBasic implementation provides almost all the fea- dent implementation, which is linked with BBBasic . tures that are mentioned in section 3. It is implemented The COPS-PR and BBBasic is tested on Linux routers in Java and follows client/server model. BBBasic can and the results [10] [9] indicate that BBBasic manages configure Linux based router, whereas the Linux routers the network resources effectively by reconfiguring the need to have the DiffServ support enabled which is relevant routers with COPS-PR, when required. built-in in Linux kernel from version 2.4 on-wards. Java BBBasic functions as PDP which connects to its handles remote client/server functionality through TCP own domains routers (PEP), in order to configure them sockets. BBBasic server can handle multiple connec- according to a predefined domain policy. Whenever tions from the routers as well as clients simultaneously. BBBasic accepts a request, related core and edge Once a request is accepted by BBBasic , the tearing routers (if required) are contacted via COPS-PR. The down process for the request is automated. The im- core router needs reconfiguration when it is a first hop plementation provides a querying facility to the users router for the flow, the reconfiguration is required for as well as the network administrator about resources, marking and shaping the flow’s packets. Marking of 4
packets is required in order to classify the packet and the shaping is required to keep the flow under the agreed limits. The edge router is contacted by BB when the destination or source of the requested flow is in different DiffServ domain, in order to enable the edge router to filter/shape/schedule/mark the flows packet according to the SLA.
4.3 Database MySQL database is used to store the information that is critical for BB’s viability. At the top level, the stored information in the database is divided in three distinct parts; user, BB and network . User part of database consists of users SLAs, password and resource requests information. BB part contains relevant information about peer BBs and the SLAs with these BBs. The last part of the database contains all the information about the network which is essential in order to know the routers which needs reconfiguration when BB accepts a request. In addition to this network information is necessary to find the neighbor BB which should be contacted when the resource request includes resources from multiple domains.
Figure 2: Web Interface
4.4 User/application A very interesting and useful feature of BBBasic is its multiple interfaces that enable applications and users to access its network resource management ability. The reason for providing multiple interfaces is to give options to users and applications to chose the most suitable mechanism to interact with BBBasic . BBBasic contains three distinct user friendly interfaces for users, applications and resource managers . Each of these interface is explained briefly in the following subsections. Detailed description of these interfaces and information about their usage is available in [9].
Figure 3: Request Bandwidth Web Interface of the web based interface after user has selected to request for bandwidth ( Request BW in figure 2). Once the user provides the required parameters for the request, BB sends the response to the web based interface which is shown in figure 4.
4.4.1 Web Based Client 4.4.2 Java Client
A user friendly web based client is available for users to access the BBBasic remotely to request for network resources. The web based interface with graphical user interface provides flexibility and ease to users as well as network administrator to request and query BBBasic . The web based client shown in figure 2, shows the options that are given by BB, to the user, which are implemented as hyperlinks. Figure 3 shows the screen-shot
The Java based client is provided with BBBasic in order to facilitate applications to provide QoS support to their users. Applications can easily access BBBasic through this client and request for resources on behalf of their users. Integrating this client into any resource manager like a software that manages the processing resources of a super computer enables that software to reserve the 5
Figure 6: Java Network administrator Console Menu Figure 4: BB Reply On Web Interface
on translation of parameters across heterogeneous processing and operating environments. Simple Object Access Protocol (SOAP) is implemented at the client and BBBasic to exchange XML documents. The format of XML document used to request bandwidth from BBBasic is shown in figure 7.
5 Conclusion and Future Work BBBasic is a important step towards the implementation of fully functional bandwidth broker. BBBasic provides most of the intra and inter domain features of a bandwidth broker and tests have proved its ability to reserve network resources across multiple DiffServ domains successfully. Generalized interfaces to access BBBasic available for users and applications enhances its applicability and usage. There are few aspects of BBBasic that needs more research, the most important aspect is the ability to negotiate SLAs dynamically. Another interesting feature which needs to be the part of the BBBasic is the ability to dynamically and efficiently monitor network resources and identify the misbehaving sources if possible.
Figure 5: Java Client Console Menu network resources also for the users without changing its basic structure. A simple Java client can be easily used by the individual users also. Figure 5 shows the Java interface which contains simple menu in order to facilitate common users. Figure 6 shows extended Java interface with additional menu options for network administrator to control and manage BB.
References
4.4.3 General XML/SOAP Client The General XML/SOAP Client provides users and applications, access to BBBasic by sending XML documents. Extensible Markup Language (XML) is a platform independent data representation language which enables users and applications running different operating system and softwares to remotely request resources from BBBasic , without spending time and resources
[1] R. Neilson, J. Wheeler, F. Reichmeyer and S. Hsres. A discussion of Bandwidth Broker requirements for Internet2 Qbone deployment. at http://www.merit.edu/i2qbone-bb/doc. 1999 [2] B. Teitelbaum and P. Chimento. Qbone Bandwidth Broker architecture. Work in Progress. 6
5 sla005 2003−10−10 00:00:00 2003−11−11 00:00:00 500 127.1.1.0 127.1.1.1 −−
Figure 7: SOAP/XML Document RequestBW.xml at http://qbone.ctit.utwente.nl/deliverables/ [10] H. Halim and M. Darmadi. Implementation of 1999/d2/bboutline2.htm, 1999. Bandwidth Broker using COPS-PR. Honours thesis report, School of Computer Science and Engi[3] D Durham et al. The COPS (common open policy neering, UNSW, Nov 2000. service) protocol. Internet request for comments RFC2748, IETF, Jan 2000. [11] D. Sreekantan and D. Rao. Implementation of a Bandwidth Broker System for Resource [4] K. Nichols, V. Jacobson, and L. Zhang. A twoManagement in Differentiated Services at bit differentiated services architecture for the Inhttp://www.ittc.ukans.edu/ kdrao/845/ ternet. Internet request for comments RFC2638, IETF, Jul 1998. [12] Bandwidth broker implementation. University of Kansas. Sep 1999. http://www.ittc.ukans.edu/ kdrao/845/.
[5] M Fine et al. An architecture for differentiated services. Internet request for comments RFC2475, IETF, Dec 1998.
at
[13] Overview of bandwidth broker system. Slide show, http:// www.ittc. ukans.edu/ kdrao/845/intro.htm. [6] Resource allocation protocol (rap) at May, 2001. http://www.ietf.org/charters/ manet-charter.html, 2000. [14] CANARIE ANA bandwidth broker,final report 1. at www.gait .bcit.ca /projects/. [7] Y. Bernet et al. Differentiated services quality of service policy information base (PIB). Internet [15] D. Spence. Multidomain bandwidth broker draft, IETF, Jun 1999. model. at www.internet2.edu /qos /qbone/info /bb-model.doc. 1999 [8] K Chan et al. Cops usage of policy provisioning (COPS-PR). Internet request for comments [16] N. Foukia, Noria and D. Billard. Final Metrics RFC3084, IETF, Mar 2001. for CATI. Report number 0.3, Apr 2000 . CATI project Funded by Swiss National Science Foun[9] K. Pham and R. Nguyen. Implementation of Banddation SNF, Switzerland. width Broker in Java. Undergraduate thesis report, School of Electrical Engineering and Telecommunications, UNSW, Jun 2003. Source code at [17] Charging and Accounting Technologies for the Inwww.cse.unsw.edu.au/ nrl ternet (CATI) at http://www.tik.ee.ethz.ch/ cati/. 7
[18] QBone Signaling Design Team, Final Report at http://qos.internet2.edu/ wg/documentsinformational/ 20020709-chimento- etal-qbonesignaling/
8
