Policy Creation Model for Policy-Based Management in Telecommunications Networks

Policy Cr eation Model for Policy-Based M anagement in Telec ommunications Networ ks Carlos A. Astudillo, Graduate Student Membe r , IEEE, Adriana M. Gustin, Gradu ate Student Member , IEEE and Oscar J. Calderón, Member , IEEE New Technolo gies in T elecommunicatio ns R&D Group Faculty of Electr onic and Teleco mmunication E ngineeri ng, Universit y of Cauca Pop ayán (Cauca), Colo mbia {castudillo, a mgustin, oca lderon}@ieee. org Abstract — Policy-based m anage men t (PBM) is b eing u sed as technological solution on the managing and controlling complex networks and syste ms. One of the most important issues i nvolved in the life-cycle of PB M is the policies creation because the future decisions made by the management syste m depend on this, and therefore, the netw ork behavi or. In this paper w e present a novel model for creating management policies in t elecommunications networks. We p ropose a mode l w hich includes a Policy Crea tion Process, Actors, Policy Abstraction Le vels and a Proced ure for Creating Policies. An implementation of the pro posed model over the Technology Division at Uni versity of Cauca is included. Keywords-Policy Based Management, Policy Creation Pro cess, Telecommunica tions Networks Management. I. I NTRODUCTION The idea of autonomic man agem ent has been proposed as the future of several areas such as Security, Quality of Services (QoS), Resources Allocation b ut at this mom ent, it is not a reality yet. So we need som e benchmarks for creating policies in current netw orks wh ich use early PBM solutions for managin g traditional netw ork elements. Those elements can be routers, sw itches, fi rewalls, PCs, etc . The currents solutions of PBM sy stems in academic field use some formals techniques for translating high level policies into the low level ones [1],[2]. T hose also use policy languages like Ponder [3]. However, they w ere created in experimen tal scenarios and they are not being used by service provi ders to manage their netw orks. Now adays, the early PBM solutions are being used y et, so we proposed a model that can help to create policies in both c urrent and f uture c ommercial man agement system s based on PBM. This work introduc es a model that c an be used in a manual way but it is inspir ed in experi mental works where the policies are generate d in automatic w ay, using different techniques and formal languages. It would a llow o ur model to be autom atic in the future. The structu re of the paper is as follow s. Section 2 introduces Policy Based Management an d the principal components o f its architectur e, Section 3 develops the policy creation model , in Section 4 the m odel is used in a r eal scena rio and finally , the conc lusions a re present ed. II. P OLICY -B ASED M ANAGEMENT The architectu re defined by IETF [4] is at this mom ent the most popular architecture of Po licy Based Management (PBM) for researchers, academics and industries . IETF defines four functional elemen ts. The Fig. 1 shows that architecture and the components ar e describe d in th e followin g: • Policy Management Tool (PMT): Entity used by policy administrato rs for specif ying the policies t o be applie d in the network. • Policy Repository (PR): th e policies g enerated from PMT are stored in this ent ity. • Policy Enf orcement Point (PE P): Element wh ere the policies a re applied an d enforc ement. • Policy D ecision Point (PD P): T his is the most important element of the architectu re because it makes dec isions based on policies sto red in PR and commu nicates them to PEPs. Protocols as LDAP, SNMP and COPS are used to communicate t he entities in th e architectur e [5]. The policies are introducing into P MT through policy rules that follow the p aradigm If “ Conditions” th en “Actions” From IETF. Policy would have others c omponents such as sub ject, target and trigger events, also a managem ent system could support only some type of policy; it depends on the PBM implem entation [6]. Figure 1 . IETF PBM Architecture III. P OLICY C REATION M ODEL We propose a Policy Creation Model in the context of telecommu nications network s which includes P olicy Abstraction levels, Policy Creati on Process, Actors, and a Procedure f or Creating Policie s. It is developed in this w ay: A. Policy Ab straction Le vels The policies in a man agement system can be r epresent ed and specifie d in diffe rent w ays, providing s calability and flexibility to management sys tems. The following are the levels proposed by the authors in [7]. 1) High-Level Abstrac t Policy: These policies are d efined by policy ma kers. T his type of po licies includes : • The business objectives of the company or organizati on. • The SLAs defined be tween providers, providers a nd their custom ers, or int ernally in an organizati on. • The nee ds o f those involved in th e network, among which are: users/custom ers, applic ations, servic es, providers and netw ork operators. Such polici es are defined in natu ral language and represen t the aims of n etwork behavior and th e w ishes o f the part ies involved on it. Policies at this level are not display ed in the m anagemen t system and must be refine d to Mid-L evel P olicies to enable them to ente r it. 2) Mid-Level Policy: T hese policies are applyed by the administrator in t he P MT through polic y r ules b y usi ng Poli cy Specificatio n La nguage, Console or Graphical User Interface (GUI). Policy rule specifies a set of conditions wh ether they are true, th e r esult is one or more actions. Each rule has a logical statement of the way If “Conditions” T hen “ Actions”, with o r without a t rigger event , it de pends on the PBM implemen tation. 3) Low-Level Policy: Those policies are defined for a particular device, with a specific config uration and repre sent the lowest le vel of a polic y because t hey are applied directl y to the network e lement in volved in p olicies (i.e. PEP). Those policies are built in an understan dable and unique format for each device and are co nvert ed to this format throug h the PDP. Usually at this level polici es should not be specified because it loses the objective of policy-base d managem ent witch seeks to provide high-lev el management to a large number of dev ices at onc e. B. Policy Creatio n Proce ss In the following we describe the phases in a policy life- cycle that m ade up the policy creation pr ocess: 1) High-Level A bstract P olicies Definition: In this phase the m anageme nt ob jectives are extracted. those are the require ments for the ma nagement syste m. At this p hase is also taked into acco unt the feedback of the cycle which co uld co me from p olicy monitori ng and maintenance. Finally, the High- Level Abstract Policies a re writen i n a docu ment. 2) Policy Refinement: In order to achieve the manageme nt objectives, we u se a a ppro ach based on go als which is insp irated in [1] to create o peratio nal policies ( mid- level po licies) in manual way. I n our approac h, first is defined high-level goals (based on High-Level Abstract Polic y) and then are generated sub-goal s (oper ational goals) that can achieve the objectives pro posed initially. This refinement makes use of requirements analysis, applications deployed on the network, users of thes e applications, and resources available. 3) Definition a nd Sp ecifiction of P olicy Rules: In this phase is defin ed the policies that sho uld be deployed into th e manageme nt syste m in or der to achieve the m anage ment objectives. they are based on low-level goals, conditions and others factors. Those policies can be expressed in a policy specificatio n lang uage ( e.g. P onder, XACM L, etc.) , o r thro ugh an informatio n model b y using a Gr aphic User I nterface. C. Actors We also identify the actors in volved in the policy creation process, th ese are: 1) Policy Makers This group o f p eople has the ta sk o f des igning and specifying t he High-Level Abstract Polic ies. This grou p is integrated b y: a) Managers: They kno w the rules, business o bjectives and organizatio nal struct ure. b) Netw ork Specia lists: They know the underlay technologies that network can use ( e.g. Q uality o f Servi ce Mechani ms, Securit y and Networki ng T echnologies, etc .). c) Administrato rs: The y Kno w ho w to define t he manageme nt obje ctives and what the p olicy s ystem supp ort. 2) Policy Administrato rs They are responsib le for imple menting policies on th e policy-based management system, to m ake t hem m aintena nce and if req uired, also carr y out maintena nce of t he nece ssar y mechanis ms to e nforce these po licies. T hey s hould also ma ke repor ts to managers and security, networking and Qo S specialists. 3) Users/Customers They are involved in the cap ture of requirements because they use telec ommu nications infrastr ucture, demandi ng some services or ap plications. D. Procedu re for Creating Policies Identify a generic procedur e for the Policy Creation Process in the context of telecomm unications networks is essential, because it ex pedites the process and also ensures the desired results wh en the policies are implem ented to meet the needs for they w ere created. The auth ors h ave a lso proposed ste ps in order to create policies in telecommun ications networks managem ent, they are developed in as follow s: 1) Define High-Level Abstract Po licies The first thing to do in the policy life-cycle is to acquire the needs or managem ent requirements wh ich are captured b y Policy Makers. These inv olve: • Service Lev el Agreem ents (SLA 's). • Business O bjectives. • Users/Custom ers Requirem ents. Taking int o account the needs i dentified an d defin ed previously , the Po licy Makers write the high-level abstr act policies. They are written in natural langu age and define the desired behavior o f the n etwork in term s understan dable by anyone. 2) Specify High-Le vel Goals It e xpresses the aim s to b e achieved b y the management system in general w ay (abstract level). Sin ce we use a goal approach for creating policies , w e need t o define h igh-le vel goals that fulfill the necessiti es and requir ements defined in to the High- Level Abstract Policies. 3) Define Sub-Goa ls Each high-lev el goal can be refined in to low -level ones (sub-goals or operational g oals), the decomposition goals can be either conjunctiv e ( ٨ , AND) or disjunctive ( ٧ , OR). Fr om this, it forms a refinement hierarchy in which the dependencies among the goals of different levels of refinem ent are based on the manner w ith which it was de composed. The low- level goals should be defined to p erform a specific task. T herefore, the refinement process should be done until this conditi on is g otten. 4) Generate Strategie s Strategy is calle d to th e sequence of sub-g oals tha t sh ould be implem ented to obtain the high-level goal in the managem ent system. The strategy c an be encoded in one or more mid-level policies depending exclusivel y o n the particula r applicati on domain. 5) Identify Conditio ns The con ditions are circumstances that occur in networks. If these conditions are val idated true, trigge r a s et of actions that affect the netw ork and allow reaching the d esired state of it. Therefore, the administrator should iden tify the conditi ons th at must be consi dered for the spe cificati on of a p olicy. In this step shoul d be identifie d all conditi ons that help each Sub Goal to b e achieved in the system taking into account the functionality that the system supports, determ ining the source and destinati on of traffic, the type of service and time in w hich each Sub Goal is execute d. 6) Identify the Sub ject and Ta rget It is necessary to identify the subject and target that will be specified in the final policy rules. The Subject refers to the entity responsible for implem enting the actions involved in the policy or the objects that are permitted or prohibited in the actions. The Target refers t o the elem ents affected by the policy actions. 7) Define the Policies which will be Deployed by the System In order to deploy a policy in a m anagemen t system, it is necessary t o defin e this in a mi d-level policy format (see part A). For this , i t uses all the elem ents obtained in the previo us steps (e.g. sub goals, condition s, target , and sub ject). The policy a dministrat or n eeds to def ine the w ay in w hich policies will be specified, this depends on the PBM System. The specif ication could b e do ne th rough policy specifi cation languages and GUI, ena bling policy information to be share d with o ther entities su ch as PDPs and PEPs. T he following are the main a dvantages and disadv antages of b oth options: The languages provide a consistent definiti on of policies which facilitates the interpretati on of the elements that run them. Some languages are unique to particula r implem entations, while others may be used independent ly of the implementati on and theref ore not tied to a specific framework. GUIs a re the most c ommon ways to ex press po licies in IETF policy fram ework because they have not a defined language to specif y policies. It m akes use of g raphical user interfaces in which policies are ex pressed in the form if conditions then ac ti ons, an d t he managed o bjects, actions that are executed on these objects and the conditions under actions which they apply, are defined by th e info rmation m odel. T his way of expressing policy is simpler and less experienc e is required by administrat ors, but its problem is that the identificati on of conf licts is m ore difficu lt. There are proposals to use the two types of policy specificati on previously app ointed toge ther, taking advanta ge of each one, like in [8]. IV. A PPLICATION OF THE P ROPOSED M ODEL We used the proposed m odel over a real scenario at the University o f Cauca in o rder to obt ain the policies th at should be im plemented in the managem ent system for achieving all managem ent objectives. In the following we develop the model in this particula r scenario a nd as a result o f this is obtaine d the policies that will be depl oyed by the system. W e used a commercial PBM solution, called Allot Communications NetPolicy , it allows us to manage the netw ork traffic a nd som e routers with p olicies that are specified in the PMT (called NetXplorer) an d enforc ed in the PE P (called NetEnf orcer). A. Actors Descr iption 1) Policy Makers This group of players is made up of: • Chief of Se rvers and Services of Internet Area. • Chief of Inf rastructur e Area. • Support Engin eer, Inf rastructu re Area. 2) Policy Administrato rs This group is made up o f Servers and Services Admin istrators of Int ernet Are a, University of Cauca . 3) Users This group o f players is made u p o f the se rvice users (e.g. Admin istrative People, Stude nts, Profess ors, etc.). they at any time may require a particular network behavior, for any applicati on or servic e. B. Define Hig h-Level A bstract Polic ies The aim of the Technology Division is to create p olicies to manage the inte rnet traffic , because it is necessa ry to use effectively the I nternet link s according to the services that it offers. In this sens e, the Policy Makers captur e the f ollowing needs/requir ements: • Web serve rs, internet ac cess, w eb applicati ons, mail server and downloads of specia l hosts must be available at any tim e and have assigned a h igh priori ty. • VoIP, videoconf erencing and stream ing services should be prioritiz ed and mu st ensure adequate bandwidth fo r their p roper fun ctioning. • Access to sites o f institutional interest must always be guaranted. • Services n on-instituti onal interesting should have low priority and be restri cted durin g w orking hours. • Hosts that have s pecial permits should be having limited ban dwidth. Taking into accoun t the ne eds d escribed a bove, it is necessary that the system implements policies to manage its main re source: th e b andwidth. The P olicy Makers iden tify the follow ing high-level abstract policies: • Web servers must be access ed at a ny time and at a good speed, rega rdless of th e am ount of traff ic which they arise. • Mails m ust arrive an d depart in a short peri od of tim e. • Access to websites that are related to administrative and academic work of the university will be prioritize d and must ensure a bandwidth (e.g. Banks, others Universities and Governmental S ites (i.e. ICE TEX, COLCIENCIAS and ICF ES). • Ensure that the FTP serv er can always be accessed. However, because it is a n additional service and n ot a principal, th e traffic sh ould have a m edium priority that allows people quickly download files . • Access to P2P applications sh ould be restricted d uring working hours. • The low est p riority shoul d be pr ovided t o al l accesses with no institu tional use (e.g. vi deo and music downloads, et c). • Guarantee a ccess to the VoIP serve r w ith high QoS. • The vi deoconfe rence e quipmen ts and som e videoconferenc e software servers must be guaranteed bandwidth t o enable them to f unction pr operly. • Hosts that h ave special services (i.e. those with public address or NAT) m ust have a limited bandwi dth, w ith a lower prio rity th an other im portant se rvices. • The Internet surfing th rough the l ess import ant w eb sites for th e university shoul d have a low priority. C. Specify H igh-Leve l Goals Based on the previ ous ste p that describes th e m anagement needs/requir ements of Techn ology Division, n ow the Pol icy Makers de fine the h igh-le vel g oal G 1- 1: "B andw idth optimized for both incoming and outgoing interne t traffic" which represents the main objective that should be achieved by the managem ent sy stem. D. Define S ub-Goals In this step, the Po licy Makers begin to extract the sub- goals (SG), generating a refinement hierarchy. This is done taking into account the management needs/requirem ents, available resources and information about the m anagement environm ent. It is necessary to take into account the services, the resources consum ed b y each service and the priority to be given to each of these resources, according to the role in the instituti onal miss ion at the uni versity . The figu re 2 show s the refinem ent hierarchy gen erated for our particu lar case, where: SG 2-1 : Allow access to th e Serv ices and/or Applications. SG 2-2 : Set a Bandwidth f or Services an d/or applica tions by defining th resholds (Min imum - M aximum ). SG 2-3 : Ensure a Bandw idth for Servic es and/o r Applicati ons. SG 3-1 : Ensure a ban dwidth of 256Kb ps per incom ing connection t o mail se rvers. SG 3-2 : Set the maxim um bandwidth allow ed per outgoing connections fr om m ail servers. SG 3-3 : Set a minim um bandwidth of 500Kbps for incoming and outgoing connections o f computers that have urgent downloads. SG 3-4 : Ensure a bandwidth of 64Kbps for incomin g and outgoing conn ections t o VoIP Serve r. SG 3-5 : Ensure a bandwidth o f 384Kbps per connection for incoming and outgoing tr affic of vi deoconfe rence equipm ents. SG 3-6 : Ensure a b andw idth of 512Kbps for incoming connection t o the Web S erver. SG 3-7 : Set the maxim um b andwidth allow ed per connection for outgoing t raffic fr om Web Servers. SG 3-8 : Deny access to Ra pidShare dur ing w orking hours. SG 3-9 : Deny access to P 2P applica tions during working h ours. SG 3-10 : Allow access to P2P applications during non-w orking hours. SG 3-11 : Set a m inimum bandw idth of 400kbps to inte rnet access for equipm ent with pu blic IP a ddress. SG 3-12 : Set a maximum bandwidth of 512Kbps for outgoi ng traffic fr om FTP server . SG 3-13 : Set a minim um bandwidth of 1024Kbps for outgoing traffic t o important web sites. SG 3-14 : Ensu re a bandw idth of 300Kbps per connect ion for outgoing t raffic fr om stream ing servers. SG 3-15 : Set a minimum b andwidth of 5Mbps for incoming traffic t o proxy servers. SG 3-16 : Set a m inimum bandwidth of 300Kbps f or outgoing traffic fr om proxy se rvers. Note that Sub Goals SG 2-X include a sys tem f unctionality and the Su b G oals SG 3-X d efine a s pecific action based on the functions su pported by the manag ement sy stem. E. Generate S trategies Since the scenario is not complex enoug h (has one PEP), the goal gra ph has only one possibi lity to a chieve the high-le vel goals ( all leads are con junctive). Therefore, it must meet all low-level goa ls in order to achieve the high- level ones. The generated str ategy is called S1 . S1=SG 3-1 ٨ SG 3-2 ٨ SG 3-3 ٨ SG 3-4 ٨ SG 3-5 ٨ SG 3-6 ٨ SG 3-7 ٨ SG 3-8 ٨ SG 3-9 ٨ SG 3-10 ٨ SG 3- 11 ٨ SG 3-12 ٨ SG 3-13 ٨ SG 3-14 ٨ SG 3-15 ٨ SG 3-16 F. Iden tify Conditio ns Table I summ arizes the condi tions identified for each sub goal. G. Identify Subject an d Target For this particular case, th e s ubject and t arget refe rs to NetEnforcer AC404 because it is th e only equipment allowe d in the m anaged domain to enforc e policies . TABLE I . C ONDITIONS FOR EACH S UB G OAL Sub Goal Conditions Source Destination Service Time SG 3-1 Mail Servers Any Mail Any SG 3-2 Any Mail Server Mail Any SG 3-3 Hosts with Important Dowloads Any All IP Any SG 3-4 VoIP Serve r A ny VoIP Any SG 3-5 Videoconference Equiments Any All IP Any SG 3-6 Web Servers A ny All IP Any SG 3-7 Any Web Server All IP Any SG 3-8 Any RapidShare Servers Web Applications Working Hours SG 3-9 Any Any P2P Applications Working Hours SG 3-10 Any Any P2P Applications Non Working Hours SG 3-11 Host with NAT or Public IP Any Al l IP Any SG 3-12 FTP Server Any FTP An y SG 3-13 Any Important Web Sites Web Applications Any SG 3-14 Streaming Servers Any All IP Any SG 3-15 Any Proxy Servers All IP Any SG 3-16 Proxy Servers Any All IP Any H. Define the Policies whic h will b e Spec ified in the S ystem As previously men tioned, these polici es are d efined in the way If “conditions” T hen “actions”. T hey are the rul es that must f inally b e im plemented at a policy -based m anagement system to meet the est ablished m anagement re quirements. The foll owing are the defined policies that m ake up the strategy S1: P1 (Based on SG 3-1 ): If “The Servic e is email, the Source Address are mail servers, Destination Address is wh ichever, anytim e” T hen “Ensure a bandw idth of 256Kbps to m ail servers, an d assign a m edium priori ty (6)”. P2 (Based on SG 3-2 ): If “The Servic e is email, the Source Address is w hichever, th e Destination Address b elongs to one of the m ail servers, an ytim e” T hen “Assign a medium priority (6) and give the m aximum available capacity to service” . P3 (Based on SG 3-3 ): If “ The Source Ad dress belongs to any host of urgent dow nloads g roup, Destinati on Address is whichever, any time” Then “A ssign a minimum bandwidth of 500 Kbps for both inbound and outbound connection to that computer, an d give a hig h prio rity (9)” . P4 (Base d on SG 3-4 ): If “The So urce Address and Destin ation Address is the VoIP s erver, any time” T hen “Ensure a bandwidth o f 64 Kbps for both inbound and o utbound connection t o that serve r, and assign a high prio rity (9)”. P5 (Based on SG 3-5 ): If “The Source Address or Destination Address belongs to any video confe rence equipm ents, any time” Then “Ens ure a b andw idth of 384 Kbps f or both inboun d a nd Figure 2. Refinement Hierarc hy AND decomposition outbound connections to these hosts and assign a medium priority (6)”. P6 (Based on SG 3-6 ): I f “The So urce Address is w hichever, the Destinati on Address belongs to on e of th e w eb servers , anytim e” Then “Ensure a bandwidth o f 512 Kbps for incoming connection t o these s ervers an d assign a m iddle prio rity (7)” . P7 (Based on SG 3-7 ): I f “The Source Address belongs to one of the web servers, Destination Address is w hichever, anytim e” Then “Give the maxim um available bandwidth for outgoing connection fr om these se rvers and assign a low priority (4)”. P8 (Based on SG 3-8 ): I f “The So urce Address is w hichever, the Destinati on Address is one of the RapidShare servers, the Service is a w eb application, anytim e” T hen “Discard traffic from and t o those serve rs”. P9 (Based on SG 3-9 ): If “ The source address is w hichever , the Application is P2P, at working hours” Then “Deny Access to those appli cations”. P10 (Based on SG 3-10 ): If “The Source A ddress and Destin ation Address is w hichever, th e Appli cation is P2 P, at non-w orking hours” Then “ Accept traf fic to an d from thos e applicati ons”. P11 (Based on SG 3-11 ): If “The Source Address belongs to one host with NAT or Public IP, Destina tion Address is which ever, anytim e” T hen “Assign a maximum b andwidth of 400 Kbps to these hosts and assign a middl e priority (7)”. P12 (Based on SG 3-12 ): If “The Source Address belongs to one of the FTP servers, Destination Address is whichever, anytim e” T hen “Set a maximum bandwi dth of 512 K bps for outgoing traffic from FTP servers and assign a l ow priority (4)”. P13 (Based on SG 3-13 ): If “ The Sourc e Address is whichever, Destinati on Address is one of t he important web sites , any time” Then “Set a minimum bandwidth of 10 24 Kbps”. P14 (Based o n SG 3-14 ): If “ The Source Address is o ne of the streamin g ser vers, Destination Address is whichever, anytim e” Then “Ensure a bandw idth of 300 Kbps per connecti on and assign a m iddle priority (6)”. P15 (Based on S G 3-15 ): If “ The Source Address is w hichever, the Desti nation A ddress is one of th e proxy serve rs, any time” Then “Set a minimum ba ndwidth of 5 Mbp s and assign a middle prio rity(7)”. P16 (Based o n SG 3-16 ): If “ The Source Address is o ne of the proxy serve rs, Destin ation Address is which ever, any time” Then “Set a min imum ba ndwidth o f 500 Kbps and assign a middle prio rity (5)” . Those policies are introduced in the managem ent system, mapping the entities involved on them. For example, the group of hosts with urgent do wn loads is represented in the system by its IPs a nd the w orking hours are from 8:00 A.M to 6:00 P.M. Since policies above were created with the system functionality , it can be introduced in the system . T he ranges established to determine the priority assigned to each policy are like follow : f rom 1 to 4, l ow priority , from 5 t o 7, middle priority and fin ally from 8 to 9, high priority . The ranges are provided by PBM implem entation. V. C O NCLUSION Policy- Based Management is considered of great interest within the academics, business and researchers becaus e it allows greater flexibility in management o perations, regarding the translat ion of busin ess r equirements into specif ic pol icy rules. We identify individ uals or actors that are involved in the policy creation process and w e clarifie d the roles of them. We could make an a ppropriate con struction of policies if w e had qualified hum an resources (adm inistrativ e and technical support) and an effec tive interaction b etween them ( roles well defined fo r all act ors involve d in the pol icy creati on process ). The proposed abstracti on levels to manage telecommu nications networks exposed that policies can not be seen as a single entity or statically , as in these new environm ents of dynamic netw orks and specif ic requirements for each ne twork use r, the p olicies must be created and implem ented at d iffe rent lev els within the management plane of the netw ork. One of the most important r esults of this work is the procedure for creating policies , which allows d evelopin g through steps each phases involved in this process. Additionally , this proc edure is linked w ith policy ab stract ion levels an d actors, an d an appli cation exam ple is d eveloped. A CKNOWL EDGMENT The authors would like to thanks Technology Division, University o f Cauca for providing the faciliti es for implem enting the Policy Creation Model a s well as its staff for their help and advices in special to J aime Gaviria, J aim e Martinez, Andres Zúñig a, Fabio Fuertes and Eivar Armero. We would als o like to thanks Carlos Silva from Cam bridge Language Centres and anonym ous reviewers for their usefu ll comments. R EFERENCES [1] A. Bandara, E. Lupu, J. Moffet and A. Russo, “A goal-based approach to policy refin ement,” In Proceedings of 5 th IEE E Worksho p on Policies for Distributed Systems a nd Ne tworks (P olicy 2004), N ew York, USA , Ju ne 2004. [2] J. Rubio-Loyola, J. Serrat, M Charalambides, P. Flegkas and G. Pavlou, “A methodolog ical approach toward the refinement problem in policy-based management sy stems,” IEEE Communication s Magazine, Oc tober 2006. [3] N. Damianou, N. Dulay , E. Lupu and M. Sloman, “The ponder p olicy specification language,” Lecture Notes in Com puter Science, Springer, Vol. 1995, 2001, p.p. 18-39. [4] R. Yava tkar et al., “A Framework for policy based admi ssion control,” IETF RFC 2753, Ja nuary 2000. [5] D. Kosiur, Understand ing policy-based ne tworking, Wiley Computer Publishing, 20 01. [6] A. Band ara, N. Damianou, E. Lupu, M. Sloman and N. Dulay, “Policy- Based Management” in H andbook o f Network a nd System Management , J. B ergstra and M Burges s, Elsevier, 2007 , p.p. 501. [7] C. Astudillo , A. Gustin and O. Cal derón, “N iveles de abstracción de la s políticas p ara la gestión d e redes de telecomun icaciones,” In Proceed ings of Simposium IEEE Monterrey - SIEEEM'08, Monterrey, M exico, October 2008. [8] J. Strassner, Poli cy based network ma nagement: s olution s for the n ext generation, Elsev ier, 2003.