00920862

8/2/2019 00920862

http://slidepdf.com/reader/full/00920862 1/9IEE E Communications Magazine • May 200190

Management ofQualit y of Service Enabled VPNs

0163-6804/01/$10.00 © 2001 IEEE

ABSTRACT

New emerging IP ser vices based on differen-tiated services and the IP security architectureoffer the level of communication support thatcorporate Internet applications need nowadays.However, these services add an additional degreeof complexity to I P ne tworks which will requiresophisticated management support. The manage-ment of enhanced IP services for their customersis thus an emerging important t ask for Internetservice providers. This article describes a poten-tial management architecture service pro viderswill need for that task, considering problemssuch as mult ipr ovider services and serviceautomation. We will focus on a quality-enhancedvirtual p rivate network service which is part icu-larly useful for corporate internetworking.

INTRODUCTION

The Internet’s global presence makes it attractiveas a universal communications infrastructure forbusinesses. With d istance-independent rates an dflat fees, the costs of corporate Interne t commu-nications become predictable and tend t o getcheaper. However, some Internet design princi-ples discourage the use of the Internet as a uni-versal communication platform. First, all Internettraffic shares the available resources and is for-warded in a best-effort manner. Such resourcesharing with all other Internet users makes itimpossible for In ternet service providers (ISPs)tooffer the service guarantees that some corporate

communication applications (e.g. IP telephony,videoconferencing, stock information services)need. In order to alleviate this problem, the Inter-net Engineering Task Force (IETF) defined qual-ity of service (Qo S) support m echanisms for theIntern et (discussed later). The second problemwith the Internet is its lack of built-in securitysupport. IP traffic is easy to eavesdrop on, and IPpackets can easily be manipulated (e.g., to appearto come from an arbitrary source address). Fur-thermore, the best-effort nature of the Internetinvites denial-of-service attacks based on excessivegeneration of traffic. Such security threats fuelthe trend to protect corporate network traffic on

the Internet.

A widely used approach is a virtual privatenetwork (VPN). A VPN is a private network ona public network infrastructure (Internet). TheVPN traffic is logically separated from othertraff ic by tunneling me chanisms (discussedlater). Furt hermore, th e traffic content is oftenprote cted by cryptographic means. A p articular-ly fruitful solution for corporate communica-tions is a QoS-enabled Internet VPN. Such asolution takes advantage of the cheap and ubiq-uitous Internet, but provides quality and securi-ty guarantees at the same time. However, QoSand V PN t echniques introduce new challenges.They need extensive configurat ions in therouters. The local configurations have to beconsistent across the network. Many companiesmay not have the knowledge and resources todeploy and manage enhanced Internet servicesby themselves. Rat her, t hey will outsource the

service management to their Int ernet serviceprovider. This is a win-win scenario because theprovider can profit from the economy of scaleby sharing of technical and hu man r esources.Further more, ISPs see management as a newproduct with greater potential service d ifferenti-ation than a pure connectivity service. However,mana gement of the p rovider network will getmuch more complex. As of today, no completeintegrated solution exists for a p rovider t hatwants to offer and man age enhanced IP ser-vices. Difficulties occur if t he customer is ableto or der a service online (service auto mation)and the service requires the collaborat ion of several providers.

In th is article we outline a gener ic architec-ture for the management and outsourcing of QoS-enhanced Internet VPNs. The applicationscenario is shown in Fig. 1. The service provideroperates an IP network with VPN-enabled edgerouters and a core network that support re sourcereservation mechanisms (e.g., multiprotocol labelswitching, MPLS). The customer s operat e stubnetworks and shall be enabled to ord er VPNconnectivity with guar ante ed ser vice qualitybetween those subnets.

We discuss IPSec, differen tiate d services(DiffServ), and other enabling technologies forQoS VPNs. We describe network management

techniques, then propose a service management

Torsten Braun, Manuel Guenter, and Ibrahim Khalil, University of Bern, Sw it zerland

IP-ORIENTED OPERATIONS AND MANAGEMENT

8/2/2019 00920862

http://slidepdf.com/reader/full/00920862 2/9IEE E Communications Magazine • May 2001 91

architecture. We present a prototype implemen-tation of that management architecture and con-clude the article.

VPN ENABLING TECHNOLOGIES

Tunneling (also called packet encapsulation) is ametho d of wrapping a packet in a new one byprepending a new header. The whole originalpacket becomes the payload of the new one. Atthe tunne l starting point the new header (con-taining the tunnel endpoint ad dress) is added.When the new packet arr ives at the tunnel end-point, the header is removed and the originalpacket forwarded. Tunneling is often used to

transparen tly transport packets of one network protocol through a network running anotherprotocol. GRE (IETF RF C 1701), for example,is a multiprotocol carrier p rotocol for tunnelsthrough IP ne tworks. VPNs need tun neling toforward the encapsulated (private) packet (withprivate addresses) through the public network.Often, the private packet is also encrypted. TheSecurity Architecture for IP (IPSec; IETF R FC2401) provides protocols that support this styleof tunneling.

IPSec is an open an d widely supporte d archi-tecture for IP packet encryption and authentica-tion, that works on a per-packet basis. IPSecadds additional headers/trailers to an IP packet

and can encapsulate (tunnel) IP packets in newones. There are three main functionalities of IPSec separated in three p rotocols. One is theauthentication through an authentication header(AH ); another is the encryption through anencapsulating security payload ( ESP); an d final-ly, key management is automated t hrough theInternet key exchange (IKE) protocol. IPSeccan use any encryption algori thm to protectdata and any message digest a lgori thm toauthenticate data. However, for interoperabilitythere is a standard set of cryptographic opera-tions. Both AH an d ESP support a tunnelingmode. The tunneling mode also allows nesting

of IPSec proto cols. A common usage is , for

example, to protect an IP packet with ESP andencapsulate/tunnel the result within the AH (intunnel mode).

With IPSec-enabled access routers, a providercan set up VPN tunnels for customers. These tun-nels can provide integrity, authenticity, and confi-dentiality to the t raffic. However, to do so th eprovider has to perform a significant amount of configuration work at the tunnel end points (alsocalled security gateways). Security associations(SAs) need to be established to define which traf-fic will go through the tunnels, and which encryp-tion algorithms and secret keys will be used. TheIKE protocol helps to establish SAs automatical-ly. Ho wever, IKE depe nds on a security policy

dat abase which defines the guidelines for SAestablishment. These guidelines may also regulatethe interaction between the security gateways anda public key infrastructure such as a X.509 certifi-cate server. Th e security policy databa se is notspecified in IPSec. Furthermore, the discovery of security gateways is beyond the scope of IPSec. Aprovider that wants to offer VPN services thuscannot o nly rely on I PSec built-in managementmechanisms, but must integrate IPSec into a ser-vice management framework.

QOS SUPPORT FOR VPNS

DIFFERENTIATED SERVICES

DiffServ (IE TF R FC 2475) pro vides QoS in IPnetworks by traffic aggregation based on DiffServcode points (DSCPs). Packets are classified andprocessed by traffic conditioners at the edge of aDiffServ domain. DiffServ domains are typicallyequivalent to ad ministrative dom ains, that is, acustomer network or the n etwork of an ISP. Ser-vice level specifications ( SLSs) mu st be e stab-lished among the various DiffServ domains. TheseSLSs form t he basis for tra ffic conditioningactions such as shaping, policing, and remar kingat th e edge rout ers. DiffServ can provide Q oS toInte rnet VPNs. Both t echnologies fit well with

each other because of several commonalities:

Tunneling is a

method of

wrapping a

packet in a

new one by

prepending a

new header. The whole original

packet becomes

the payload of

the new one.

At the tunnel

starting point the

new header

(containing the

tunnel endpoint address) is added.

" Figu re 1. A VPN deployment scenario.

Physical linkVPN path

Customerstub

networkA

Customerstub

networkC

Customerstub

networkD

1D 1B

2B2D

Customerstub

networkB

1A

2A

ISPDS-domain

Edgerouter

Interiorrouter

1C

2C

3C

8/2/2019 00920862


• Both architectures logically separate servicetraffic from public traffic.

• Both classify IP packets.• Both are enforced in edge routers.• Both aggregate traffic flows.

For providing QoS guarantees similar to thosecustomers are used to from leased line services,the expedited forwarding (EF) p er-hop behavior(PHB) seems to be the appropriate choice (IETFRFC 2598). The EF PHB can be used to build alow-latency assured-bandwidth end-to-end service

through DiffServ domains. Such a service appearsto the endpoints like a point-to-point connectionor virtual lea sed line. A typical SLS for such aservice might include th e ingress and egresspoints of the D iffServ domain that shall providethe service and a peak rate which can be guaran-teed to the traffic stream.

The assured forwarding PHB group (IETFRFC 2597) is a means for a DiffServ provider tooffer different levels of forwarding assurancesfor IP p ackets received from a customer Diff-Serv domain. Four AF classes are defined withthree drop p recedences each. A typical SLSincludes rates for low and medium drop prioritypackets , and might a lso specify ingress andegress points. Although AF is considered m orecomplex to configure in DiffServ domains, wealso see great potential in AF for VPNs. In par-ticular, a customer might prefer to specify abandwidth ra nge [Y,Z] rather t han a single peak rate for a VPN tunnel. To support bandwidthranges, an SLS can be configured with Y as therate for low drop precedence and Z -Y as therate for medium drop precedence.

When providing DiffServ-to-VPN tunnels, spe-cial attention must be given to DSCP mapping atthe tunnel starting point. In outsourced VPNs theingress router of an ISP might perform DiffServclassification and tra ffic condition ing as well as

tunnel encapsulation. If encapsulation is per-formed first, the ingress router can select theappropriate DSCP for the corresponding tunnel;if DiffServ processing is done first, th e D SCP of the inner IP header must be copied to the DSCPfield of the outer IP header.

Management of a DiffServ domain can bedone using so-called bandwidth brokers (dis-cussed later ). A bandwidth br oker ma ps SLSs toconcrete configurations of D iffServ routers, inparticular to edge routers of a DiffServ domain.

TRAFFIC ENGINEERING

An importa nt issue for providing QoS in VPNsis traffic engineering. Traffic engineering is the

process of cont rolling how traffic flows thr ougha network in order to optimize resource utiliza-tion and network performance. The basic moti-vation for traffic engineering arises from thefact that shortest-path-based routing leads tocongestion on certain links while others remainrelatively unused. Th is leads to inefficient net -work resource usage and increases the pr obabil-ity that a VPN tunnel cannot be established dueto lacking resources a long the shortest pathbetween tunnel ingress and egress points. Traf-fic engineering in the past has been based onoverlay models, running IP over an un derlyingconnection-oriented network technology such as

asynchronous transfer mode (ATM) or frame

relay. In this case, meshes of connections havebeen established to inter connect IP router s of particular VPNs. In this case the overlay modelserved two purposes: providing a tunnelinginfrastructure to bu ild VPNs and for t ra ff icengineering, including QoS support. However,there are several problems with the overlaymodel. Most important is the management com-plexity with handling two kinds of network tech-nology — IP and the underlyingconnection-oriented network (ATM or frame

relay). Furthermore, mesh-like networks do notscale for large VPNs.

MULTIPROTOCOL LABEL SWITCHING (M PLS)MPLS (IETF RFC 3031) overcomes several lim-itations of t he overlay model concerning scalabil-ity and efficiency. Mainly, two MPLS featuresare responsible for that: MPLS allows tunnels tobe set up by appending a MPLS header in frontof the IP hea der . This 32-bit MPLS headeravoids the large overhead of another IP heade rrequired with IP-in-IP tunneling. The MPLSheader can therefore be used several times (i.e.,labels can be stacked).

Label stacking is in particular be ing usedwhen building MPLS/Border Gateway Protocol(BGP) -based VPNs. In such a case, a packet isclassified at an ingress router of an ISP basedon the interface belonging to a particular VPN .The ingress rou te r has lea rne d v ia BGP t owhich VPN it belongs, to which egress rou terthe p acket must be sent, and via which egressin te r face the des t ina t ion i s reachab le . Theingress rout er app ends two labels to a pa cketbelonging to a VPN. The inner label specifiesthe egress port at t he ISPs egress route r (i.e.,the link toward the d estination subnetwork of the VPN ). The oute r label is being used to for-ward the packet toward the egress router and

can be lear ned by MPLS signaling protocolssuch as (CR )-LDP or TE -RSVP. Both labelsa re popped by the egress rou te r . Note t ha tMPLS makes the private VPN addresses of acustomer tra nsparent to the routers of the ISP(tunneling).

Another issue with MPLS is QoS support.Again, DiffServ fits very nicely since, in bothconcepts, DiffServ and MPLS addition al intelli-gence (packet classification, MPLS labeling,DSCP marking, etc.) is required in edge rou ters,while interior routers just perform packet pro-cessing based on M PLS labels and D iffServDSCPs. Although MPLS is a scalable techniquefor VPN tunneling, provides traffic engineering

capabilities by its connection-oriented nature,and suppo rts DiffServ Qo S, it does not havebuilt-in security mechanisms.

TRADITIONAL IPNETWORK MANAGEMENT

Today, traditional IP network management con-sists mostly of manual n etwork monitoring an dconfiguration. The network administrator has toaccess each device, browse log files, and manual-ly install configuration param eters. In o rder toprovide QoS guarantees the administrator needs

to possess a significant amount of information

Management of a

DiffServ domain

can be done

using so-called

bandwidth

brokers.

A bandwidth broker maps SLSs

to concrete

configurations of

DiffServ routers,

in particular to

edge routers of a

DiffServ domain.

8/2/2019 00920862

http://slidepdf.com/reader/full/00920862 4/9

8/2/2019 00920862


The mo del pro vides a way to t hink logicallyabout how the bu siness of a service pr ovider ismana ged. The mo del consists of five layers,starting from the network element layer followedby four mana gement layers: element mana ge-ment, network management, service manage-ment, an d business management ( Fig. 2, rightside). Each layer provides capabilities to t heupper layers and each layer imposes require-ments on the lower layers. The components of the lower layers are more distributed and techni-

cal. The h igher t he layer, the more informationis concentr ated int o high-level abstractions.Higher layers can thu s be more central ized,which eases pr eserving consistency. The businesslayer cont ains processes that de al with th eprovider’s corpora te stra tegy and customer re la-tions. The service layer deals with the productsoffered to customers, namely the network ser-vices. The network management layer incorpo-rates th e man agement pr ocesses necessary forthe p rovider’s overall net work infrastructure.The element management deals with processesconcerning single devices in the network ( servers,routers, switches, etc.). Finally, the element layerrepresents the heterogeneou s devices that con-stitute a network.

Traditionally, the processes at all layers gothrou gh a m ore or less similar life cycle consist-ing of four pha ses. After pla nning (e.g., whichequipment to buy or service to offer) and deploy-ment there is a third phase, consisting of opera-tion, maintenance, and monitoring. This phase issupposed to generate revenues for the provider.The cycle ends with an evolution/upgrade phase,which may lead to a new planning phase or with-drawal. The operat ion phase is ideally thelongest phase and is not directly related to strate-gic decisions. It includes man y repetitive tasks(monito ring, accounting, etc.). Therefor e, it

offers the greatest potential in automation. Therest of this article focuses on the managementautomation of the operation phase.

AUTOMATED QOS VPN SERVICE OPERATIONS

Today, the automation of network service man-agement has rea ched the ne twork layer of theTMN model. Our goal is to extend the automa -tion so that functionalities in the service andbusiness layers are covered, too. For automatedQoS VPN operations management we propose ageneric architecture. Th e functional componentsof the a rchitecture ar e shown in Fig . 2. Thearchitecture brings together the TMN model,SNMP, the D iffServ management architecture,

and policy based network management.The management a utomation too ls for sin-

gle devices vary with the devices’ har dwareand opera t ing sys tems . Never the less , thedevices should have a uniform interface towardthe upper management layers. The device driv-er is a functional component th at h ides thevendor-specific configuration procedures of anetwork device. A widely accepte d standa rdfor repr esenting device management informa-t ion is the SNMP MI B. However, for somedevices proprietary information models mustbe supported.

At the network layer several functional com-

ponen ts a re needed in o rder to o f fe r a QoS

VPN service. A basic component t o mana ge IPnetworks (e.g., routing) is required. Fu rther-more, network layer QoS support and IP securi-ty management components are needed. Thesecomponents ma nage the building blocks (securi-ty gateways, border routers) of a QoS VPN ser-vice according to requests of the servicemanagement layer. The information representa-tion depe nds on t he e nabling technology. Exam-ples for IPSec are SAs and for DiffServ theservice level specifications (SLSs).

The service layer includes a service bundlingcomponent to compose several network layermechanisms into end-to-end services for the cus-tomers. IPSec tunnels or MPLS paths are logi-cally bundled int o customer VPNs. The choiceof which network services are bundled is a mat-ter of the service planing phase and is not dis-cussed here . Nevertheless , the automatedmanagement system must know which network-ing mechanisms are involved, and how theyinteract or interfere with each other. This isreflected in th e service bun dling component ,which can support thre e of the most popu larVPN models: remot e access by individual user s,branch-office-to-branch-office intranet, and mul-tiparty extranets with buyers and suppliers. Con-sistency among the network configuration andrunning services is enforced throu gh a central-ized and intelligent software agent, also referredto as a service broker . The broker treats requestsaccording to service policies, which is a typicalfunction of a policy server (P DP) . It also pro-vides additional functionality such as capacityallocation for D iffServ (discussed late r). Thepredominant information models at the servicelayer are policies (e.g., IPSec security policies orDiffServ policies).

The bu siness layer comprises the customer care functionalities, which can be divided into

three subgroups [6]. The fulfillment componentrepr esents, for example, the process of salesnegotiation s, including the establishment of SLAs. The Web is the dominant medium toaccess this component. The assurance compo-nent p rovides service status information to thecustomer, since customers of a Q oS VPN ser-vice may want to m ake sure they get th e servicethey have paid for (e.g., security) [7]. The billingcomponent collects and sends the invoices. Thepredominant information representation at thebusiness layer is the SLA. In an aut omat edmanagement a rch i tec tu re an SLA is a fu l l -fledged electro nic cont ract with all its legalimplications. An SLA is established between the

customer and t he pr ovider. In a multiproviderscenario a provider needs to access the ma nage-ment of peer p roviders . He re, one providerplays the ro le of an (outsourcing) customer.This can be expressed by setting up an SLAbetween providers. The service outsourcingbusiness management component incorporatesthis functionality.

Informa tion Flows: Two main informa tionflows go through the presented architectureduring operation: configuration requests andmeasurements. A stream of configuration com-mands descend from the top layer down to thedevices. High-level instructions are decomposed

into commands t o the next lower layer, until

At the network

layer several

functional

components are

needed in order

to offer

QoS VPN service.A basic

component to

manage IP

networks is

required.

Furthermore,

network layer

QoS support and

IP security management

components are

needed.

8/2/2019 00920862


finally device-specific configurations are activat-ed. The root of the bottom-up information flowconsists of mea surement s in net work devices.This measurement data is compressed into net-work status and usage information at the net -work layer. The service layer u ses the da ta t oensure correct service operation and to gener-ate accounting records tha t are f inal ly pro-cessed ( among o t her in fo rmat ion , se rv icebundling in the SLAs) by the billing compo-nen t . The fo l lowing QoS VPN ou tsourc ingexample illustrates cooperation between func-tional components. The successful setup of aQoS VPN goes through thr ee stages: request,admission control, and service activation.

Request — A customer wishes leased-line-likeIP conne ctivity between two subnets. The priva-

cy of the I P tra ffic shall be protected, and thecustomer desires throughput guarantees . Aprovider offers a QoS VPN service withselectable dedicated bandwidth and security fea-tures. Therefore, the customer requests an SLAfrom the outsourcing component of th isprovider. The outsourcing component contactsthe service broker.

Admission Con t r o l — The service bro kerlearns the semantics of the QoS VPN servicethrough inte ract ion with the service bundlecomponent. It therefore knows how differentnetwork service functionalities must be com-bined to provide the requested end-to-end ser-

vice. In this example th e re quest involves theDiffServ and IPSec components. The bro kercombines information pr ovided by the IP rout-ing component , the service bundle compon ent,and the customer re quest to calculate the net -work resources needed to support the service.The service broker contacts the appropriatenetwork management components to query if the r equired r esources are available given t heselected service param eter s. For example, itqueries the IPSec management component if the access routers are not overburdened withthe additional work imposed by IPSec given t heselected cryptographic me chanisms. Th e service

broker a lso verifies that the network can sup-

port the additional traffic load with the desiredPHB. It interacts with D iffServ management todo so. If the re quested Q oS VPN also involvespeering providers, the service bro ker contactsthe service outsourcing component of thoseproviders.

Service Activat ion — After the service brokeradmits the customer re quest , i t reserves theresources. The broker then triggers service acti-vation. The activation is performed by the IPSecand DiffServ management components. Thesecomponents delegate the configuration of thenetwork devices to the device drivers. The bro-ker no tifies the outsour cing componen t, whichthen commits to the SLA, thereby informing thecustomer that the VPN is ready.

The prototype described in the next section

implements the functionalities framed in Fig. 2.

A PROTOTYPE IMPLEMENTATION OF

A QOS VPN MANAGEMENT SYSTEM

Within the Charging and Accounting Technolo-gy for the Internet (CATI) [8] project we havedeveloped a prototype system [9, 10] to demon-strate d ynamic establishment o f QoS-enabledVPN tunnels that is also capable of generatinguser billing information. The central component,the service broker (SB), plays the role of the poli-cy server. It is the heart of our VPN manage-ment sys tem tha t a c ts a s a QoS manager to

optimally allocate network resources by perform-ing admission contr ol a t e dge devices . Theadmission decisions could take place with mini-mum user intervention with respect to specifyingthe u ser’s requiremen ts. Since the unde rlyingnetwork may provide different classes of serviceto satisfy various VPN customer s by identifyingthe generic functionali ty provided by anyresource, we present our SB with a standar dinterface (Fig. 3) to the network resources. Theinterface provides user-selectable p olicy optionsto make it easier for end users to create VPNsdynamically, almost in point-and-click fashion.The u ser can select a VPN service using authen-

tication o nly, encryption on ly, encryption with

" Figu re 3. Service broker components and the broker’s Web interface.

Servicebroker

Devicedriver

Netw ork elements

Charging repository

Netw ork interfacedatabase

Connectiondatabase

Pricingdatabase

Billingdatabase

SLAdatabase

Resourcedatabase

Service configurationrepository

Today, the

automation of

network service

management has

reached the

network layer of

the TMN model.Our goal is to

extend the

automation so

that functionali-

ties in the service

and business

layers are

covered, too.

8/2/2019 00920862


partial aut hentication, or e ncryption with fullauthentication. Furthermore, a set of dedicatedbandwidth classes are offered.

SB STRUCTURE AND SYSTEM COMPONENTS

Our SB interacts with a specialized intelligentdevice driver when a certain user request arrivesto se t up a t unne l and the SB has to dec idewhether i t can al locate enough resources tomeet the demand of that tunnel. Device driversare intelligent provisioning agents that are ableto tran slate user r equests and SB-generatedpseudo rules into device-specific rules to config-ure the routers/switches since we might haveseveral o f those devices from various vendor s

that need to be configured in different ways.The SB uses a service configuration and a charg-ing repository (Fig. 3). These are collections of various da tabases nee ded for dynamic serviceactivation.

SLA Database — The SLA database not onlycontains the user’s identification, but also speci-fies the maximum am ount and type of tr affiche/she can send and/or receive for a tunnel.The SLA also contains the boun dary of thevalid VPN area. Referring to Fig. 1. where stubnetworks A, B, and C might belong to the sameorganization and be located at different remotelocations, one can ea sily see th at t hey form a

mesh environment, and any site may want toestablish a connection with another under t hesame contract. Therefore, this boundary definesthe perimeter of the VPN area and is enteredin th is da tabase as source and remote s tubaddresses. The user authentication process pro-hibits malicious users from setting up unautho-r ized tunne l an d access ne twork resour cesillegally. The SLA, however, allows users to addnew VPN areas to their current contracted listof valid VPN areas. It contains the followingtuple:

< User ID, Password, Maximum BW in Mb/s, Source Stub Address, Remote Stub

Address>

Resou rce Datab ase — The resource databasecontains resour ces available between a ny twoedge routers. This means that this database hasresource information for all the routers in a cer-tain domain. In our implementation, dynamicallyestablished tunnels traverse through pinned paths(e.g., MPLS label switched paths, LSPs) that canbe established statically. We assume that thosepaths are able to protect the traffic marked as EFat VPN edges by using appropriate queuing mech-anisms. We allocate tunnel IDs to the tunnels in

order t o keep tr ack of resource usage. For eachtunne l, however, we also need to know its ingressrouter’s IP address, ingress outbound, egressroute r’s IP add ress, egress outbound (this mightas well be the same as the e gress router’s IPaddress) , and the capacity of the tunnel inmegabits per second. While ingress and egressrouter addresses are necessary for identifying theedge routers, the outbound addr esses are need-ed to define tunnel endpoints, and in fact, for asingle router there might be several outboundinterfaces. Also, in the database we need to keept rack o f the s ta tus o f the tunne l in te rms o f availability. Therefore, the tuples are:

< tunnel id, ingress router, ingress outbound,egress router, egress ou tboun d, ban dwidth,

status>

However, it should be clarified tha t a tunnelmight originate from an ingress router to severalpossible egress routers. Referring to Fig. 4, usersresiding in stub network A might want to estab-lish tunn els between ro uters e1 and e2, or e1and e3, or e1 and e4 to communicate with otherstub networks. Assume that an ISP has decidedto a llocate a maximum 10 Mb/s capacity to tra f-fic stemming from e1 and destined t oward otheredge po ints. The I SP might, however, allow 1Mb/s tunnel, two 2 Mb/s tunnels, and one 3 Mb/s

tunnel to be created between e1 and e2, and alsoallow two 2 Mb/s tunnels from e1 to e3 and onlyone 2 Mb/s tunnel from e1 to e4.

It is clear that if all the tunnels were activesimultaneously, router e1 would need to support14 Mb/s. The edge admission control of the ser-vice broker ensures that the allocated resourcesalways stay below the m aximum capa city (10Mb/s in this example).

Connec t io n Da tabase — The connectiondatabase contains a list of currently active VPNconnections. Here a connection always means aVPN tunnel and is identified by source-destina-tion pairs. It has various functions:

• When a new request arrives for connectionactivation or termination, th e SB can check whether o r not that connection alreadyexists and then make its decision.

• It indicates how many resources have beenconsumed by VPN users.

• It provides records to the pricing mecha-nism.

Its tuples are:< user id, source address, destination

address, bandwidth, tunn el id, activationtime>

Int erface Database — The interface database

contains necessary records of edge r outers th at

" Figu re 4. Mapping of resources to various tunnels.

e4

e3

e2

e1

1 Mb/s

Tunnel ID 1

2 Mb/s

Tunnel ID 7

2 Mb/s

Tunnel ID 5

2 Mb/s

Tunnel ID 6

2 Mb/s

Tunnel ID 2

2 Mb/s

Tunnel ID 3

3 Mb/s

Tunnel ID 4Stubnetwork

A

Stubnetwork

D

Stubnetwork

C

Stubnetwork

B

8/2/2019 00920862


are used as tunnel endpoints for the outsourced

VPN model. In such a model, since customerstub networks are connected to t he ISP edgerouter, we need to specify which stub networksa r e c o n n e c t e d t o a p a r t i cu l a r e d g e r o u t e r .Also, an edge router might have one or moreinbound and outboun d interfaces which alsoneed t o be spec i fied fo r each s tub ne t work connected t o a particular inbound interface of a rout er. This is important because normally atthe inbound inter face tunnels are policed onan individual basis, and at the outbound inter-face they are shaped o n an a ggregate ba sis. Atthe same t ime, outbound interfaces are a lsoused as the tunnel endpoints. Finally, a tunnelmap to which all defined tunnels are attached

is also part of this database which is activatedat the outbound interface of the router . Thetuples are:

< stub network, edge router, generic router nam e, inbound interface, outbound interface, tunnel map name>

Pricing and Billin g Database — The pricingdatabase contains pricing information on vari-ous tunnels. Its only interaction with the SB iswhen a connection (tun nel) is terminated andthe SB needs to know the price of it by makinga quer y to i t . The bi l l ing data base containsdetai ls of terminat ed connections and their

computed prices.

Operati onal Details — Figure 5 sho ws all the

communications involved in setting up a VPNconnection between two stub networks or simplybetween an originating host and a re mote host.We will describe the operational details by refer-ring to the communications marked on F ig. 5,considering each communication in turn.

A user sends a VPN connection request con-ta in ing use r ID, use r password , source andremote address for the tunnel, amount of band-width, an d en cryption/tunneling method (forexample, policy # 1 on the webpage of Fig. 3).The SB con tac ts the SLA da tabase tha t i sresponsible for validating the user and his/herrequest. If the u ser has been identified correct-ly, his/her source a nd re mote a ddress conforms

to the contract, and also the bandwidth request-ed is less than or equ al to the a greed traff iccontract, it sends a po sitive respon se (steps 2and 3). After this validation the SB sends a sig-nal to the d evice driver t o check its status. Thestatus can be busy, available, or d own. Only inthe case of availability can the user request beprocessed further (steps 4 and 5). The SB thencontacts the connection database to check theexisten ce of a similar tunn el. This is becausebetween a source and destination, only one tun-nel can remain active (steps 6 and 7). Beforeedge ad mission contro l the SB finds which ed gerout ers should be configured by checking the

interface database. Du ring the a dmission con-

" Figu re 5. The VPN setup procedure or possible rejection (D-x: denial).

Invalid user ID/password! ! Your user ID or passwordor both are invalid! Please provide correct ID and password!!

The device driver is busy!

Please t ry lat er.The device driver has been shut down!

Contact your System Administrator or ISP

A tunnel already exists betweenthis source and t he destinat ion!

The tunnel that you have requestedis not available! Please try later.

The tunnel that you have requestedhas been provisioned.

You are asking for wrong amount of bandwidth.Pls provide appropriate bandw idth request.

Invalid source address! ! Your SLA doesn't permi t t his.Please provide correct data.

Invalid destination address!! Your SLA doesn't permit this.Please provide correct data.

R e q u e s t

A d mi s s i on c on t r ol

S er v i c e a c t i v a t i on

User Service broker

SLA database

Connectiondatabase

Resourcedatabase

Device driver Router/switch

1

D-1

D-2

D-3

D-4

2

4

5

6

7

8

9

10

11

1213

14

3

8/2/2019 00920862


trol process the resource database responds tothe SB and e i the r a l loca tes the r esource o rdenies it based on resource availability (steps 8and 9). A positive adm ission contro l decisionprom pts the SB to signal the de vice driver tocreate appr opriate configuration scripts (step10). In the mean time, the resource and connec-tion databases update their records. The newconnection request data is appended to the con-nection database, and the tu nnel that ha s justbeen allocated from the re source database is

marked as used . In the remain ing steps therouters are configured, and the SB sends notifi-cation to the user.

A connection request is rejected if:• The SLA profile doesn’t match (case D-1).• The driver is found busy (case D-2).• The connection already exists (case D-3), or

not enough resources are available (case D-4).The various stages where a connection creationprocess might get refused are shown in Fig. 5. Aconnection termination process releases reservedresources by updating records in the resourcedata base. It a lso invokes pricing and billingdatabases to generate user billing at the end of tunnel termination.

CONCLUSION

Internet-based QoS VPNs have become a feasi-ble and econ omically inter esting solution fordeploying wide area corporate networks. How-ever, the QoS and VPN e nabling technologiesincrease network management complexity sig-nificantly. In this article we propose a TMN-based a rch i tec tu re tha t enab les se rv iceproviders to oper ate Q oS VPNs for their cus-tomers. The architecture is compatible withemerging IP network management techniques.We then present an implementation instance of

the architecture. The implementation supportsWeb access by customers and enables them toset up IPSec VPN tunnels with QoS guarantees.The system is a step toward solving the problemof automated and integrated management of QoS VPNs.

ACKNOWLEDGMENTS

The work described in this article is part of t hework done in the CATI project (nos. 5003-054559/1 and 5003-054560/1) and its continuation,Advanced Ne twork and Agent Infrastructure forthe Support of Federa tions of Workflow TradingSystems (ANAISOFT) ( SPP ICS ElCom Project5003-057753), both funded by the Swiss National

Science Foundation ( SNF). The implementat ionplatform has been funded by SNF R’Equip project no . 2160-053299.98/1 and Foe rde run g der

wissenschaftlichen Forschung an der UniversitaetBern. The authors want to thank the anonymousreviewers, Dr. J. Schneider, and Silvia Bechter fortheir helpful comments.

REFERENCES

[1] R. Rajan et al., “ A Policy Framework for Int egrated andDifferentiat ed Services in th e Internet,” IEEE Netw ork ,vol. 13, no. 5, Sept./Oct. 1999, pp. 36–41.

[2] S. J. Baek, J. W. Baek, and J. T. Park, “ Poli cy-based Man-agement Archit ecture fo r Int ernet VPN Using DEN,”IEEE IPOM , Sept. 2000.

[3] P. Aukia et al., “ RATES: A Server f or MPLS Traff ic Engi-neering,” IEEE Network , vol. 14, no. 2, Mar./Apr. 2000.

[4] A. Terzis et al., “ A Two -t ier Resource Manag ementModel for the Internet,” IEEE Global Internet ’99 , Dec.1999.

[5] ITU-T Rec. M-3400, ” TMN Management Functions.”[6] TM Forum, Telecom operations map, http ://www .tmf o-

rum.org,Mar. 2000.[7] M. Guent er and T. Braun, “ Internet Service Delivery

Cont rol w ith Mob ile Code,” H. R. van As, Ed., Telecom- munication Network Intelligence , IFIP, Kluwer, Sept.2000, pp. 3–19.

[8] B. Stiller et al., “ Charging and Accounting Technologyfor the Internet,” ECMAST ’99 , LNCS 1629, Springer-Verlag, May 1998, pp. 281–96.

[9] I. Khalil, T. Braun, and M. Guenter, “ Implementation ofa Service Broker f or M anagement of QoS EnabledVPNs, “ IEEE IPOM 2000 , Sept. 2000.

[10] I. Khalil and T. Braun, “ Implement ation of a Band-width Broker for Dynamic End-to-End Resource Reser-vation in Outsourced Virtual Private Networks,” 25th Annual IEEE LCN , Nov. 9–10, 2000.

BIOGRAPHIES

TORSTEN BRAUN ([email protected]) got his degree andPh.D. fro m t he University of Karlsruhe, Germany, in 1990and 1993, respectively. From 1994 to 1995 he was a guestscientist at INRIA Sophia-Antipolis,France. From 1995 to1997 he w orked at t he IBM European Networking Center,Heidelberg, Germany, at the end as a project leader andsenior consultant. Since 1998 he has been a full professorof computer science at the Institute of Computer Scienceand Applied Mathematics at t he University of Bern, Swit zer-land, where he is heading the Computer Networks and Dis-tributed Systems research group. He was elected a member

of the Swiss Academic Research Network (SWITCH) com-mittee in 2000.

MANUEL GUENTER ([email protected]) got his degreefrom the University of Bern, Switzerland, in 1998. He isnow a research assistant and Ph.D. student in the group ofProf. T. Braun. His research interests are new IP services,interdomain collaboration, network and service monitoring,and mobile agents.

IBRAHIM KHALIL (ikhalil@pont e.com) h as an M .S. degree incomputer engineering from University Putra Malaysia and aB.S. in electrical engineering from BIT Rajshahi, Bangladesh.He was a graduat e research assistant wit h t he ATMresearch group in electronics and computer engineering,University Putra Malaysia between 1993 and 1996. Prior to joining the group of Prof. Braun in 1998 as research assis-tant and Ph.D. student, he briefly worked with the LTS and

C3i groups of EPFL, Switzerland. His research interests aredynamic network provisioning, QoS issues of VPN, MPLS,and network pricing. He is currently w orking wit h Moun-tain View, California based Ponte Communications, USA.

The implementa-

tion presented

here supports

Web access by

customers and

enables them to

set up IPSec VPN tunnels with QoS

guarantees. The

system is a step

toward solving

the problem of

automated and

integrated

management of

QoS VPNs.

00920862

Documents