Bandwidth Broker Implementation Circa-Complete and Integrable

Bandwidth Broker Implementation:Circa-Complete and Integrable Shaleeza Sohail,Khoi Ba Pham,Richmond Nguyen and Sanjay Jha School of Computer Science and EngineeringUniversity of New South Wales,Sydney,AustraliaCorrespondence Author:sohails@.auJuly10,2003AbstractKeeping in mind the present network management re-search trends,it can be safely stated that in the near fu-ture enterprise networks and Internet Service Providers (ISPs)will need a network management entity to dy-namically manage QoS networks.DiffServ is one of the emerging QoS networks that introduces bandwidth bro-ker as its logical network and policy management mod-ule.Due to the complex and huge functionality pro-vided by bandwidth broker,it has unfathomable num-ber of semi explored research areas and numerous re-search groups are working on its implementation.The paper explains a bandwidth broker implementation that provides basic inter-domain and intra-domain function-ality.More importantly,it contains general interfaces which enable resource managers,which lack the ability to manage network resources on their own,to integrate with its functionality of robust management of network resources.1IntroductionIn order to support Quality of Service(QoS)in the network,new architecture such as Integrated Services (IntServ)and Differentiated Services(DiffServ)have been proposed in the IETF.These architectures support diverse service levels for multimedia and real-time ap-plications.DiffServ architecture is capable of provid-ing well defined end-to-end service over concatenated chains of separately administered domain by enforcing the aggregate traffic contracts between domains[5].At the inter-domain boundaries,service level agreements (SLAs)specify the transit service to be given to eachaggregate.SLAs are complex business related contracts that cover a wide range of issues,including network availability guarantees,payment models and other le-gal and business necessities.SLA contains a Service Level Specification(SLS)that characterizes aggregate traffic profile and Per Hop Behavior(PHB)to be ap-plied to each aggregate.To automate the process of SLS negotiation,admission control and configuration of net-work devices correctly to support the provisioned QoS, each DiffServ network may be added with a component called a Bandwidth Broker(BB)[4].On the inter-domain level BB is responsible of nego-tiating QoS parameters and setting up bilateral agree-ments with neighboring domains.On intra-domain level BB’s responsibilities include configuration of edge routers to enforce resource allocation and admission control.In order to perform these functions BB main-tains policies and negotiates SLAs with customers and neighboring domains.BB is a main resource manager in DiffServ domain so whenever aflow needs to en-ter that DiffServ domain or a local user wants to send some traffic,BB is requested to check related SLA.BB, on the basis of previously negotiated SLAs,decides as to allow the traffic or not.In case of a newflow BB might have to negotiate a new SLA with the neighbor-ing domain depending upon the traffic requirements. Once BB allows the traffic,the edge router or leaf router needs to be reconfigured by BB.The paper explains a bandwidth broker implementation[9]that contains es-sential intra-domain and inter-domain functionality to enable BB to work as resource manager in any Diff-Serv domain with static SLA management.Moreover, the implementation contains a number of interfaces for users,applications and network administrator to request 1network resources from BB.A generalized XML/SOAP interface provides a mechanism for any other resource manager to integrate with BB for managing network re-sources.The rest of the paper is organized as follows.Section 2identifies and briefly explains some of the research efforts in thefield of BB.Section3explains the archi-tecture of bandwidth broker.Section4explains the im-plementation of BB in detail.Section5concludes the paper and identifies some implementation aspects that need more work.2BB Research EffortsInternet2QBone Bandwidth Broker Advisory Council was one of thefirst group that has defined the BB’s requirements[1]in detail and the initial draft of Sim-ple 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 sup-port 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 forward-ing(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 proto-cols.Secure interconnection between private networks was the reason for emergence of virtual private net-works(VPN).CATI introduces QoS support in VPNs with the help of service broker.Service broker sells the services according to specific terms.Service bro-ker has the ability to negotiate service cost with cus-tomers and setup the service on approval of agreement. The brokers are designed in a scalable hierarchal fash-ion.The objective of CANARIE ANA project[14]is to implement a basic BB that is capable of providing dif-ferentiated services for CA*net II.CA*net II is a new high speed network for research and educational insti-tutions that makes possible to run and manipulate ad-vance applications,such as multi-media conferencing. University of Kansas research group makes its band-width 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-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 BB Basic,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.3Bandwidth Broker Architecture BB is a complex entity and the functionality provided by BB is huge.In order to make BB more understand-able,BB’s basic functionality is divided in following four distinguishable parts,which are also shown in Fig-ure1:1.Inter-domain2.Intra-domain3.Databaseer/application3.1Inter-domainThe 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 thatfits into the requirement of BB.Due to this complication Internet2QBone BB advisory council has proposed a simple inter domain bandwidth broker sig-naling protocol in[2].Simple Inter domain Bandwidth Broker Signaling (SIBBS)protocol follows request-response model be-tween peer BBs and is sender oriented[2].BBs have long running TCP connections with one another,TCP provides the basic reliability andflow control for the protocol.Whenever BB receives a Resource Allocation Request(RAR)from another BB,it checks sender’s au-thentication,the route,egress router for theflow,SLA 2OFigure1:Bandwidth Brokerrelated to user orflow and policies related to theflow. 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 theflow.In this manner RAR propagates to the BB which contains the destination host in its domain.The Resource Allo-cation 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.3.2Intra-domainOn 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 proto-cols 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 proto-col 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 handleIP traffic and implements policy based admission con-trols for dataflows,whereas PDP has complete view of network and configures its PEPs according to the net-work 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 it-self[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 shar-ing/synchronization and exchange differential updates only.On the time of boot-up the PEP establishes a con-nection with PDP and sends all device relevant infor-mation.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 pol-icy provisioning elements.3COPS has some features that makes it suitable for us-ing 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 ser-vices,COPS uses IPSec and integrity objects to provide the required security.3.3DatabaseBB has a database interface to gather information for decision making processes.To provide QoS in the net-work,BB must have a comprehensive picture of com-plete network.In general the areas about which BB needs information are policy,SLA,network manage-ment and current resource allocation status[2].Routers can also be configured to provide monitoring data to enhance the security of the network and optimal re-source usage.Router’s configuration data and informa-tion about BB’s own components is also maintained for the purpose of fault tolerance.Many database manage-ment systems are available that can fulfill BB’s database requirements such as MySQL,Oracle etc.3.4User/applicationThere is a need for a protocol or interface for network operator and user/application to interact with the band-width broker.The network operator may use this inter-face to monitor or update the performance related fea-tures of BB.The user/application requires the interface or protocol to request or query the BB.4BB Basic ImplementationBB Basic implementation provides almost all the fea-tures that are mentioned in section3.It is implemented in Java and follows client/server model.BB Basic can configure Linux based router,whereas the Linux routers need to have the DiffServ support enabled which is built-in in Linux kernel from version2.4on-wards.Java handles remote client/server functionality through TCP sockets.BB Basic server can handle multiple connec-tions from the routers as well as clients simultaneously. Once a request is accepted by BB Basic,the tearing down process for the request is automated.The im-plementation provides a querying facility to the users as well as the network administrator about resources,SLAs and requests.Detailed implementation descrip-tion and exact implementation mechanism of BB Basic is available in[9].Some implementation details of BB Basic are briefly explained in the following subsec-tions.4.1Inter-domainThe implementation of inter-domain protocol is embed-ded in the BB Basic which is designed on the specifica-tions of SIBBS[2]which is addressed as SIBBS Basic here.The design specifications of SIBBS protocol[18] does not explicitly state the mechanism by which BB gathers information about the neighboring BBs and de-tails about their domains.SIBBS Basic collects this information from its database,the database contains comprehensive network map which enables BB Basic to identify its neighbor which should be contacted to complete users RAR.Whenever user’s requested resources include re-sources from other domains then BB Basic gather in-formation about the neighboring BBs and contact them with SIBBS Basic.The neighbor BB checks its re-sources and if the request is accepted then propagates the request to the next BB which lies in the direction of the destination offlow.The process continues till the request reaches the BB containing the destination host in its domain.The replies propagate back in the reverse manner.After sending the RAA,in case of request ac-ceptance BB Basic configures its edge routers via intra-domain protocol to allocate network resources for the acceptedflow.4.2Intra-domainCOPS-PR is used as the intra-domain communication protocol for BB Basic.COPS-PR[10]is an indepen-dent implementation,which is linked with BB Basic. The COPS-PR and BB Basic is tested on Linux routers and the results[10][9]indicate that BB Basic manages the network resources effectively by reconfiguring the relevant routers with COPS-PR,when required.BB Basic functions as PDP which connects to its own domains routers(PEP),in order to configure them according to a predefined domain policy.Whenever BB Basic accepts a request,related core and edge routers(if required)are contacted via COPS-PR.The core router needs reconfiguration when it is afirst hop router for theflow,the reconfiguration is required for marking and shaping theflow’s packets.Marking of 4packets is required in order to classify the packet and the shaping is required to keep theflow under the agreed limits.The edge router is contacted by BB when the destination or source of the requestedflow is in differ-ent DiffServ domain,in order to enable the edge router tofilter/shape/schedule/mark theflows packet accord-ing to the SLA.4.3DatabaseMySQL 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 er part of database con-sists of users SLAs,password and resource requests in-formation.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 re-quest.In addition to this network information is neces-sary tofind the neighbor BB which should be contacted when the resource request includes resources from mul-tiple domains.4.4User/applicationA very interesting and useful feature of BB Basic 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 op-tions to users and applications to chose the most suit-able mechanism to interact with BB Basic.BB Basic contains three distinct user friendly interfaces for users, applications and resource managers.Each of these in-terface is explained briefly in the following subsections. Detailed description of these interfaces and information about their usage is available in[9].4.4.1Web Based ClientA user friendly web based client is available for users to access the BB Basic remotely to request for network resources.The web based interface with graphical user interface providesflexibility and ease to users as well as network administrator to request and query BB Basic. The web based client shown infigure2,shows the op-tions that are given by BB,to the user,which are imple-mented as hyperlinks.Figure3shows thescreen-shotFigure2:WebInterfaceFigure3:Request Bandwidth Web Interfaceof the web based interface after user has selected to re-quest for bandwidth(Request BW infigure2).Once the user provides the required parameters for the re-quest,BB sends the response to the web based interface which is shown infigure4.4.4.2Java ClientThe Java based client is provided with BB Basic in order to facilitate applications to provide QoS support to their users.Applications can easily access BB Basic 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 5Figure 4:BB Reply On WebInterface 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 5shows the Java interface which contains simple menu in order to facilitate common users.Figure 6shows extended Java interface with additional menu options for network ad-ministrator to control and manage BB.4.4.3General XML/SOAP ClientThe General XML/SOAP Client provides users and ap-plications,access to BB Basic by sending XML docu-ments.Extensible Markup Language (XML)is a plat-form independent data representation language whichenables users and applications running different operat-ing system and softwares to remotely request resourcesfrom BB Basic ,without spending time andresourcesFigure 6:Java Network administrator Console Menuon translation of parameters across heterogeneous pro-cessing and operating environments.Simple ObjectAccess Protocol (SOAP)is implemented at the clientand BB Basic to exchange XML documents.The for-mat of XML document used to request bandwidth fromBB Basic is shown in figure 7.5Conclusion and Future WorkBB Basic is a important step towards the implementa-tion of fully functional bandwidth broker.BB Basicprovides most of the intra and inter domain featuresof a bandwidth broker and tests have proved its abilityto reserve network resources across multiple DiffServdomains successfully.Generalized interfaces to accessBB Basic available for users and applications enhancesits applicability and usage.There are few aspects ofBB Basic that needs more research,the most importantaspect is the ability to negotiate SLAs dynamically.An-other interesting feature which needs to be the part ofthe BB Basic is the ability to dynamically and efficientlymonitor network resources and identify the misbehav-ing sources if possible.References [1]R.Neilson,J.Wheeler, F.Reichmeyer and S.Hsres.A discussion of Bandwidth Broker re-quirements for Internet2Qbone deployment .at /i2qbone-bb/doc.1999[2]B.Teitelbaum and P.Chimento.Qbone Band-width Broker architecture .Work in Progress.6<?xml version="1.0" encoding="UTF−8"?><!−− REQUEST BW. Note that the order in which the values appear must not change −−> <SOAP−ENV:Envelope xmlns:SOAP−ENV="/soap/envelope/"> <SOAP−ENV:Body><slaNumber>5</slaNumber><passWord>sla005</passWord><startDate>2003−10−10</startDate><startTime>00:00:00</startTime><endDate>2003−11−11</endDate><endTime>00:00:00</endTime><bandwidth>500</bandwidth><sourceIP>127.1.1.0</sourceIP><destIP>127.1.1.1</destIP></SOAP−ENV:Body></SOAP−ENV:Envelope>−−Figure7:SOAP/XML Document RequestBW.xmlat http://qbone.ctit.utwente.nl/deliverables/ 1999/d2/bboutline2.htm,1999.[3]D Durham et al.The COPS(common open policyservice)protocol.Internet request for comments RFC2748,IETF,Jan2000.[4]K.Nichols,V.Jacobson,and L.Zhang.A two-bit differentiated services architecture for the In-ternet.Internet request for comments RFC2638, IETF,Jul1998.[5]M Fine et al.An architecture for differentiatedservices.Internet request for comments RFC2475, IETF,Dec1998.[6]Resource allocation protocol(rap)at/charters/manet-charter.html, 2000.[7]Y.Bernet et al.Differentiated services quality ofservice policy information base(PIB).Internet draft,IETF,Jun1999.[8]K Chan et al.Cops usage of policy provision-ing(COPS-PR).Internet request for comments RFC3084,IETF,Mar2001.[9]K.Pham and R.Nguyen.Implementation of Band-width Broker in Java.Undergraduate thesis report, School of Electrical Engineering and Telecom-munications,UNSW,Jun2003.Source code at .au/nrl[10]H.Halim and M.Darmadi.Implementation ofBandwidth Broker using COPS-PR.Honours the-sis report,School of Computer Science and Engi-neering,UNSW,Nov2000.[11]D.Sreekantan and D.Rao.Implementationof a Bandwidth Broker System for ResourceManagement in Differentiated Services at/kdrao/845/[12]Bandwidth broker implementation.University of Kansas.Sep1999.at/kdrao/845/.[13]Overview of bandwidth broker system.Slide show,/kdrao/845/intro.htm.May,2001.[14]CANARIE ANA bandwidth broker,final report1.atwww.gait.bcit.ca/projects/.[15]D.Spence.Multidomain bandwidth brokermodel.at /qos/qbone/info/bb-model.doc.1999[16]N.Foukia,Noria and D.Billard.Final Metricsfor CATI.Report number0.3,Apr2000.CATIproject Funded by Swiss National Science Foun-dation SNF,Switzerland.[17]Charging and Accounting Technologies for the In-ternet(CATI)at http://www.tik.ee.ethz.ch/cati/. 7[18]QBone Signaling Design Team,Final Re-port at /wg/documents-informational/20020709-chimento-etal-qbone-signaling/8。