Automatització de la configuració de dispositius de xarxa basat en mapeig de ontologies

Automatitzaci´ o de la Configuraci´ o de Dispositius de Xarxa basat en Mapeig de Ontologies AUTORA: JUDITH PEJUAN VOCKENROTH DIRECTOR: MARCELO YANNUZZI S´ ANCHEZ DEPARTAMENT D’ARQUITECTURA DE COMPUTADORS (DAC) EPSEVG 27 DE JUNY DEL 2011 PROJECTE FINAL DE CARRERA D’ENGINYERIA T` ECNICA EN INFORM ` ATICA DE GESTI ´ O 2 3 4 Agra¨ ıments Voldria mostrar el meu agra¨ ıment per Marcelo Yannuzzi, per haver-me donat suport i el seu temps durant la realitzaci´ o d’aquest projecte. Tamb´ e vull agrair la col·laboraci´ o de Wilson Ramirez, per haver-me ajudat amb la part f´ ısica d’aquest projecte, i pels seus scripts, que ben segur m’han ajudat a poder acabar aquest projecte. Finalment, voldria agrair a la gent que m’ha donat suport moral, i m’han animat a seguir endavant, especialment a Frederik Schwarzer, a la Cristina Paret, i tamb´ e a l’Oriol Gargallo. A tots, moltes gr` acies. 5 6 F¨ ur meine geliebte Katze Kleopatra. Sogar ein ganzes leben leben w¨ are zu kurz mit dir, und doch bist du von uns gegangen. 7 8 Resum Actualment, hi ha un problema dins del m´ on d’internet, concretament a la capa IP (capa 3). Qualsevol gesti´ o que es vulgui fer dins d’aquesta capa, s’ha de fer de forma manual, cosa que implica que l’encarregat de la gesti´ o hagi de con` eixer moltes comandes de configuraci´ o d’un router, i possiblement comandes equivalents per a routers diferents. Dins d’aquest projecte es vol millorar i simplificar la gesti´ o de routers. M´ es concretament, es crea una aplicaci´ o que permeti a l’usuari final executar una configuraci´ o havent d’introduir tan sols els valors d’entrada necessaris. Mentre que avui en dia per crear un link IP entre dos routers s’ha de primer configurar un router de forma manual, i despr´ es l’altre, amb aquest projecte es pot a partir dels valors introdu¨ ıts construir els arxius que permetin llanc¸ar la configuraci´ o de forma autom` atica i executar-los. Per a fer aix` o, s’utilitza per una banda una aplicaci´ o de gesti´ o de xarxes, l’OpenNMS, per a saber quins dispositius es t´ e disponibles, que es puguin veure, i que es puguin configurar. A m´ es, s’utilitzen una s` erie d’ontologies que guarden, entre d’altres, el conjunt de comandes disponibles de cara a la configuraci´ o. Finalment, es proposa una IA que permeti a partir d’una ordre, entendre el que es demana. A partir d’aix` o, es permetria convertir aquesta ordre en instruccions concretes amb les eines i amb la implementaci´ o ja mencionada. Aquest projecte est` a dins del marc de ONE, un projecte col·laboratiu a nivell internacional, format per diverses empreses i universitats, entre les quals hi ha la Universitat Polit` ecnica de Catalunya1. De fet, ja hi ha hagut una presentaci´ o dins d’aquest mateix marc mostrant aquest projecte, on els assistents han pogut veure la configuraci´ o autom` atica de dos routers per tal de crear un link IP. Paraules clau: ontologia, mapeig, mapping, prot´ eg´ e, configuraci´ o routers. 1Per a m´ es informaci´ o, es pot visitar http://www.ict-one.eu/ 9 1.3 Objectiu projecte ONE L’objectiu final dins del projecte ONE ´ es el disseny d’una arquitectura que permeti la coordinaci´ o automatitzada entre els sistemes de gesti´ o d’IP i transport. A m´ es, l’establiment dels requisits que l’arquitectura proposada ha de ser f` acil d’integrar en la gesti´ o dels ecosistemes existents i no dependre de cap aplicaci´ o NMS espec´ ıfica. A m´ es, es necessita que qualsevol arquitectura pugui explotar les interf´ ıcies i protocols normalitzats, incloent interf´ ıcies estandarditzades per als subsistemes de gesti´ o externa (per exemple, per al PCE i els subsistemes AAA). Finalment, la nova arquitectura ha de proporcionar funcions per a la coordinaci´ o de les interaccions multicapa que sigui f` acil d’implementar, de manera que a m´ es s’inclogui un sistema d’automatitzaci´ o controlada de les tasques de gesti´ o coordinada. Al seg¨ uent cap´ ıtol s’entrar` a m´ es en detall sobre el projecte ONE, i la seva proposta. 1.4 Motivacions Les raons darrere del desenvolupament de diferents ecosistemes administratiu i t` ecnic d’Internet i de les xarxes de transport, estan inclosos en la demanda de serveis d’ambdues tecnologies. La xarxa de transport ha estat dissenyada per oferir un nombre petit de serveis amb demandes forc¸a est` atiques en el funcionament de la xarxa. A la pr` actica, les xarxes de transport s´ on gestionades a trav´ es dels NMS, que defineixen els par` ametres de servei de la xarxa, mentre que la configuraci´ o dels equips de fabricant espec´ ıfic es facilita a trav´ es de l’´ us de EMS de propietat (vegeu, per exemple, [1]). Els NMS moderns donen suport a moltes funcions orientades als serveis mentre que s’utilitzen plataformes espec´ ıfiques d’un fabricant, cosa que redueix dr` asticament les despeses generals d’explotaci´ o de les companyies de telecomunicacions, i la complexitat de les tasques de gesti´ o involucrades. A m´ es, la demanda creixent de m´ es ample de banda ha portat a la ind´ ustria a invertir en R+D, per tal de fer front a l’augment de la capacitat de transmissi´ o i la magnitud de la xarxa, alhora de simplificar tant com sigui possible l’operaci´ o i el manteniment de les xarxes de transport. Les configuracions de xarxa IP, d’altra banda, s’han fet cada vegada m´ es complexes i espec´ ıfiques del venedor. En primer lloc, la din` amica canviant d’Internet ha impulsat el desplegament d’una ampla gamma d’equips IP habilitat per les companyies de telecomunicacions. En segon lloc, s’espera que la xarxa IP doni suport a gran nombre de serveis i que adopti r` apidament nous serveis futurs per tal de reduir el temps de comercialitzaci´ o. En l’actualitat, el control dels dispositius IP ´ es majorit` ariament gestionat pel protocol NMS [25], mentre que la seva configuraci´ o es realitza normalment a trav´ es de l’acc´ es directe a la l´ ınia de comandes del dispositiu espec´ ıfic. El proc´ es de configuraci´ o pot ser manual o assistit per mitj` a d’eines personalitzades que s´ on adaptades per a automatitzar les interaccions a trav´ es d’interf´ ıcies de dispositius espec´ ıfics, que generalment es basen en la interf´ ıcie de la Command Line Interface(CLI) o la interf´ ıcie NETCONF [9]. Com a conseq¨ u` encia, les companyies de telecomunicacions s’han vist obligades a combinar la complexitat i els costos associats de les operacions necess` aries a la capa 16 IP, amb la simplicitat i estalvi de costos de funcionament i configuraci´ o de l’equip en la capa de transport. Amb aquesta finalitat, s’han realitzat avenc¸os importants per al desenvolupament d’un marc de control unificat per suportar tant serveis de ”paquetc¸om de c¸ircuit”. Hi ha dos marcs que val la pena destacar: ASON i GMPLS. El marc Automated Switched Optical Network (ASON) ´ es un assoliment important de la ITU-T [19], mentre que Generalized Multiprotocol Label Switching (GMPLS) ´ es un assoliment similar dirigit per la IETF [13]. Tots dos apunten a la reducci´ o de la intervenci´ o humana en el proc´ es de prestaci´ o de serveis, aix´ ı com a proporcionar una soluci´ o est` andard per a la inter-tecnologia i les interaccions entre capes del pla de control que donen suport de paquets i commutaci´ o de circuits de xarxes. No obstant aix` o, cal assenyalar que el suport a les tecnologies de paquets de pl` anols de control s’est´ en a les tecnologies MPLS i Ethernet, i no proporciona suport inherent per les funcions especialitzades de routing i reenviament tradicionals. Per exemple, la pol´ ıtica basada en les funcions de routing no s´ on compatibles amb els plans de control estandarditzats com la seva aplicaci´ o difereix significativament entre els diferents prove¨ ıdors. A m´ es, des dels plans de control es poden abordar l’automatitzaci´ o de les funcions espec´ ıfiques de gesti´ o, per` o no es pot organitzar de forma autom` atica la gesti´ o actual i els procediments empresarials. Per exemple, millores en la capacitat de planificaci´ o de la xarxa s´ on orquestrats per l’operador com una s` erie de provisions individuals i les accions de configuraci´ o basada en l’estat actual de les xarxes, que no es pot facilitar per si pels plans de control. Finalment, les operadores de xarxa utilitzen cada vegada m´ es sistemes de tercers, com eines de planificaci´ o de la xarxa, PCE, eines de monitoritzaci´ o de xarxa, etc, per fer decisions basades en la pol´ ıtica sobre les operacions de xarxa. No obstant aix` o, els plans de control no permeten la integraci´ o amb els subsistemes externs, i necessiten una entitat externa per integrar la informaci´ o d’aquests i convertir-los en operacions de xarxa. En aquest context, sembla raonable buscar solucions a la converg` encia d’Internet i el NMS de transport que no requereixin la integraci´ o de tots els sistemes de gesti´ o diferents (a causa de la complexitat), i que incloguin la possibilitat de tenir un nivell de control manual en l’automatitzaci´ o de les tasques de gesti´ o (a causa dels procediments en els negocis). Un punt de partida en aquest sentit ´ es el de superar el seu a¨ ıllament actual per mitj` a d’un adaptador (un “middle-box“) que pot proporcionar un canal de comunicaci´ o simple, fiable i automatitzat entre els dos nivells de gesti´ o. L’objectiu ´ es permetre la coordinaci´ o per donar suport a un conjunt de tasques b` asiques de gesti´ o, com ara l’aprovisionament i la gesti´ o coordinada de fallades. La seg¨ uent figura mostra algunes de les conseq¨ u` encies de l’a¨ ıllament entre els sistemes de gesti´ o i la soluci´ o proposada. Val la pena assenyalar que fins i tot la provisi´ o d’un nou link IP A requereix comunicacions m´ ultiples entre els operadors humans de dos departaments diferents, cadasc´ u responsable de la configuraci´ o d’una capa. Aquestes operacions no nom´ es condueixen a temps llargs d’aprovisionament de serveis i a possibles incoher` encies de configuraci´ o, sin´ o que tamb´ e impedeixen la instrumentaci´ o de mecanismes m´ es avanc¸ats, com ara l’aprovisionament de recursos basats en pol´ ıtiques (per exemple, en resposta a la rotaci´ o de tr` afic B ), o qualsevol tipus de coordinaci´ o d’acci´ o per a l’auto-guariment C . Aix` o´ ultim ´ es especialment important, ja que l’` exit de la recuperaci´ o d’una fallada sovint requereix una gran quantitat d’interaccions i la coordinaci´ o entre els dos equips de gesti´ o de la xarxa abans 17 de l’ocurr` encia de la fallada. Les operadores tamb´ e desitgen una comunicaci´ o automatitzada amb control extern i subsistemes de gesti´ o, com el PCE D . L’enfocament per desenvolupar un adaptador que pugui complir amb aquestes exig` encies sembla essencial per a les operadores, facilitant les operacions i la interacci´ o efectiva en costos entre Internet i el NMS de transport. Figura 1 18 2 El projecte ONE En aquest cap´ ıtol s’exposar` a la proposta que es fa des del projecte ONE pel que fa a la arquitectura de gesti´ o de xarxes, aix´ ı com tamb´ e els seus components principals. Aquesta part resulta important de cara a entendre el perqu` e d’aquest projecte. La seg¨ uent figura mostra l’arquitectura de l’adaptador de la Network Management (NM) proposada. L’adaptador es comunica amb les capes IP i de gesti´ o del transport, i d´ ona suport a les seves interaccions coordinades. Tal com es mostra a la figura, l’adaptador es compon de tres m` oduls principals, que s´ on: el Front-end Management Module, un Ontology Mapper, i la Operation Workflow Database. Figura 2 2.1 Front-end Management Module Aquest m` odul ´ es l’encarregat de rebre les sol·licituds i de coordinar la comunicaci´ o entre els m` oduls de l’interior de l’adaptador, aix´ ı com facilitar la interacci´ o amb sistemes externs (com per exemple, IP-NMS, un NMS de transport, o PCE). Com es pot observar a la figura 2, la comunicaci´ o a trav´ es de l’adaptador ´ es compatible amb els serveis web, i en particular, a trav´ es de la interf´ ıcie del Multi-Technology Operations System Interface (MTOSI) envers el NMS de transport [?]. MTOSI ´ es un est` andard de TeleManagement F` orum cada vegada m´ es important que ofereix una interf´ ıcie de gesti´ o oberta entre els Element Management System (EMS), NMS, i/o un Service Management System (SMS). A causa de la seva senzillesa i la seva independ` encia de la plataforma, s’est` a convertint en un dels preferits entre els serveis web basats en est` andards en la ind´ ustria (veure, per exemple, [1]). A m´ es de les operacions iniciades a trav´ es de serveis web, l’adaptador tamb´ e proporciona suport a les accions coordinades provocades per un operador hum` a i les SNMP traps, que poden ser originades per l’NMS, directament pels elements de xarxa, o per qualsevol subsistema de gesti´ o extern. 19 En aquesta arquitectura, totes les operacions iniciades a trav´ es del Front-end Management Module s´ on dissenyades i processades com a workflows o fluxos de treball, que consisteixen en la seq¨ u` encia d’accions necess` aries per coordinar i automatitzar un conjunt d’operacions cross-layer. Cada flux de treball s’especifica com una pr` actica de les telecomunicacions i el procediment de gesti´ o. Un flux de treball pot ser utilitzat per a m´ ultiples sol·licituds; la difer` encia entre dues sol·licituds que es processen mitjanc¸ant el mateix flux de treball est` a en els par` ametres d’entrada. Per exemple, dues sol·licituds per a la dotaci´ o d’un link IP poden diferir en els punts finals, les adreces IP, i la capacitat necess` aria de la xarxa de transport, per` o el flux de treball utilitzat per organitzar l’aprovisionament del link ser` a el mateix en ambd´ os els casos. Val la pena assenyalar que aquest flux de treball reflecteix els actuals processos de negoci dins de l’organitzaci´ o de la companyia, que normalment no canvien amb el canvi de tecnologia. En aquest sentit, el paper de l’adaptador ´ es el de facilitar els processos de negoci de les telecomunicacions tal com s´ on, en lloc de modificar-los. Per simplificar les tasques de la operadora, el m` odul de gesti´ o Front-end proporciona un marc programable a trav´ es del qual les companyies poden crear i organitzar les seves pr` opies operacions. Es pot veure un exemple a la situaci´ o que es mostra a la figura 3, que il·lustra un operador que inicia la acci´ o d’aprovisionar un nou link IP entre les interf´ ıcies disponibles de dos routers de la xarxa IP, ´ es a dir, routers R2 i R3 A . Aquesta operaci´ o es veu facilitada per la interf´ ıcie gr` afica proporcionada pel Front-end Management Module, que permet a la operadora coordinar a la capa IP un conjunt d’operacions, una part de les quals requereixen la configuraci´ o dels recursos de la xarxa de transport. Una organitzaci´ o aix´ ı podria ser llanc¸ada com una petici´ o d’aprovisionament d’un temps, o pot ser registrada i emmagatzemada a la Operation Workflow Database com un nou flux de treball per a la seva re-utilitzaci´ o futura. La naturalesa programable de l’adaptador ´ es essencial, ja que permet a les operadores personalitzar els seus processos d’aprovisionament, aix´ ı com programar la seq¨ u` encia d’accions que s’hagin de dur a terme en determinats esdeveniments (per exemple, per coordinar el procediment posterior a la recuperaci´ o de les xarxes de grans dimensions). Un adaptador de gesti´ o de la xarxa dotada de capacitat de programaci´ o de flux de treball ´ es una potent eina de gesti´ o per a les operadores de telecomunicacions. 20 Figura 3: Exemple mostrant l’aprovisionament d’un link IP entre els routers R2 i R3. La coordinaci´ o es desencadena com una petici´ o que coincideix amb un flux de treball pre-configurat per al proc´ es intern i l’execuci´ o. El flux de treball corresponent es recupera de la Operation Workflow Database, mentre que l’Ontology Mapper ´ es el m` odul que s’encarrega de la interpretaci´ o sem` antica de les configuracions necess` aries i el seu mapeig corresponent al conjunt d’ordres espec´ ıfiques dels dispositius implicats. Despr´ es de les assignacions, el Front-end Management Module pot demanar les configuracions necess` aries per al NMS de IP de transport. Cal tenir en compte que aquest model d’interacci´ o preveu que la execuci´ o d’un flux de treball determinat pugui requerir l’aprovaci´ o d’un administrador de la capa de transport. 2.2 Ontology Mapper A causa de la difer` encia fonamental entre la interoperabilitat dels sistemes de gesti´ o d’IP i de transport, l’adaptador ha d’implementar les adaptacions sem` antiques corresponents. Aix` o´ es sempre necessari per als casos en qu` e en les operacions de gesti´ o s’inclou la configuraci´ o de dispositius heterogenis de forma coordinada, tant de les capes IP com les de transport. A la nostra arquitectura, la representaci´ o formal dels conceptes es basa en un conjunt d’ontologies, i la interpretaci´ o sem` antica de les configuracions necess` aries i la seva assignaci´ o corresponent al comandament conjunt dels dispositius involucrats es resol per mitj` a d’assignacions entre entitats en aquestes ontologies. Una ontologia es pot definir com un parell O= (V,A), on Vrepresenta una descripci´ o formal d’un vocabulari, i Arepresenta un conjunt d’axiomes que especifiquen la interpretaci´ o del vocabulari V en un determinat domini de coneixement. El vocabulari es modela freq¨ uentment com un conjunt ordenat de conceptes, cada un dels quals pot tenir un recull d’inst` ancies que estan connectats a trav´ es d’un conjunt de relacions en forma de graf jer` arquic. Qualsevol proc´ es de mapeig en aquest context requereix d’un mecanisme fiable on es pugui apreciar la similitud sem` antica entre les entitats que pertanyen a dos ontologies diferents. L’enfocament habitual ´ es utilitzar una funci´ o de similitud S, que b` asicament 21 quantifica la similitud del significat sem` antic codificat entre aquestes entitats [30]. M´ es concretament, suposem que eie0s´ on dues entitats en els vocabularis ViV0de dues ontologies, OiO0, respectivament. La similitud entre eie0pot ser representat per S(e,e0), amb 0 ≤S(e,e0)≤1, on S(e,e0) = 1 quan eie0s´ on sem` anticament id` entiques i 0 quan no hi ha contingut sem` antic en com´ u. Sobre aquesta base, el mapeig de e ae0es pot definir com una funci´ o de M:O→O0, tal que M(e) = e0⇔S(e,e0) = maxS(e,u)∀u∈V0iS(e,e0)>t, sent t un llindar. Aquest ´ ultim sol ser ajustat per tal d’augmentar la precisi´ o de les assignacions. Mentre que en un adaptador est` atic les interf´ ıcies i les definicions de dades utilitzades per a la interacci´ o amb els diferents actors segueixen sent els mateixos, els canvis tecnol` ogics poden afectar les interf´ ıcies, aix´ ı com el vocabulari per a la comunicaci´ o amb aquests actors. Per exemple, quan una companyia canvia de prove¨ ıdor de router a un altre, aix` o pot canviar considerablement el vocabulari utilitzat, aix´ ı com les configuracions necess` aries per dur a terme un conjunt d’operacions, tot i que les operacions en si mateixes romanen amb freq¨ u` encia sense canvis. Per abordar aquest desafiament, els fluxos de treball emmagatzemats a la Operation Workflow Database de l’adaptador de gesti´ o de xarxa han de ser independents de la tecnologia, i han d’utilitzar un est` andard de dades i model de proc´ es per descriure les operacions i les descripcions requerides. En l’arquitectura proposada, els fluxos de treball es basen en Business Process Execution Language (BPEL) [15], i les ontologies que participen en els fluxos de treball es normalitzen per a uniformar representacions, que anomenem Meta Ontologies (veure la part inferior i la part dreta de la figura 3, respectivament). Una Meta Ontology ofereix un marc com´ u i independent del dispositiu que no nom´ es normalitza les tasques de configuraci´ o necess` aries en les capes IP i de transport, sin´ o que tamb´ e facilita l’especificaci´ o de les comunicacions necess` aries entre l’adaptador i el NMS d’IP i de transport. Aix´ ı, l’adaptador, les assignacions es realitzen entre entitats d’una Meta Ontology i entitats en ontologies que conceptualitzen la configuraci´ o dels sistemes propietaris. Val la pena destacar que el mercat s’est` a movent visiblement cap aquesta direcci´ o. Per exemple, l’administrador de configuraci´ o de Tivoli Netcool d’IBM [23] proporciona un enfocament similar ocultant la complexitat de les configuracions de propietat de l’administrador. Aquesta eina utilitza l’esquema est` andard XML per proporcionar els mapejos entre els vocabularis espec´ ıfics del fabricant i XML. Tot i aquest punt fort, aquesta eina no ofereix suport per a la coordinaci´ o de les operacions en les configuracions de routers IP i la capa de transport EMS, com ara [1]. La Figura 3 mostra els mapejos necessaris per l’aprovisionament d’un nou link IP entre els routers R2 i R3. Suposem que R2 i R3 s´ on de diferents prove¨ ıdors -i per tant dos mapejos s´ on necessaris-, mentre que els nodes de transport i els seus corresponents NMS s´ on tots del mateix prove¨ ıdor (´ es a dir, un mapeig). Una descripci´ o d’alt nivell d’aquests processos de mapeig es mostren a la Figura 4. Les Meta Ontologies requerides a Internet i les capes de transport es denominen MOI, i OTM, respectivament. Una vegada que el flux de treball ´ es carregat i processat, un conjunt d’entitats ontol` ogiques eIde MOIieTde MOTs´ on identificats com aquells que han de ser mapejats. Les ontologies de destinaci´ o es pot inferir a partir dels par` ametres d’entrada que han desencadenat l’operaci´ o coordinada a trav´ es de l’adaptador. Per exemple, es requereixen dues ontologies destinaci´ o a la capa IP (R2 i R3), mentre que nom´ es es necessita una ontologia per administrar la configuraci´ o dels nodes de transport Zi 22 Z0a la figura 3. Es pot observar que els mapejos es basen en la maximitzaci´ o de la funci´ o de similitud entre les entitats ontol` ogiques (per simplificar, s’omet la restricci´ o imposada pel llindar t). Tamb´ e cal tenir en compte que els vocabularis relatius a les capes IP i de transport poden diferir considerablement. Aix` o significa que la representaci´ o ontol` ogica de les entitats i les seves similituds potencials podrien variar, aix´ ı que les funcions de similitud per a cada capa pot ser diferent. Els detalls de les funcions de similitud estan fora de l’abast d’aquest projecte, per` o per m´ es informaci´ o es pot consultar la gran quantitat de literatura sobre aquest tema (com per exemple, [30] i [12]). Figura 4: Els processos de mapeig d’ontologies. 2.3 Operation Workflow Database Aquesta base de dades s’utilitza per emmagatzemar els fluxos de treball que contenen la definici´ o d’un proc´ es multicapes. Aquestes definicions de flux de treball poden ser executades utilitzant un llenguatge d’execuci´ o est` andard de flux de treball, com ara BPEL [9], que ´ es molt utilitzat per a l’automatitzaci´ o de processos en les empreses. Les definicions de flux de treball tamb´ e es poden utilitzar com a definici´ o de petites funcions per a altres processos m´ es complexos, de manera que la definici´ o de processos complexos resulta m´ es f` acil i m´ es robusta, ja que es minimitzen els errors de programaci´ o. Com a exemple, el simple flux de treball d’aprovisionament d’un link IP podria ser utilitzat com un petit m` odul en un flux de treball de recuperaci´ o d’errors de configuraci´ o d’un nou link. L’´ us del m` odul permet reduir l’esforc¸ necessari de programaci´ o i la possibilitat d’errors durant el desenvolupament de nous fluxos de treball, ja que els fluxos de treball existents tendeixen a ser m´ es estables que els fluxos de treball nous. En oferir la capacitat d’emmagatzemar i recuperar un flux de treball, ens assegurem 23 que els triggers no necessitin portar definicions de processos complexes, i que utilitzin les definicions de proc´ es existents a l’interior de l’adaptador proposat per facilitar l’operaci´ o. Finalment, els fluxos de treball emmagatzemats tamb´ e es poden utilitzar com a plantilles per revertir una operaci´ o complexa executada per l’adaptador de gesti´ o de xarxa, que ´ es essencial per a facilitar les operacions de rollback. 2.4 Aplicacions En aquesta secci´ o es presenta una descripci´ o d’alt nivell d’un escenari d’exemple, on l’adaptador de gesti´ o de xarxes pot ser utilitzat per facilitar la coordinaci´ o d’operacions a traves de m´ ultiples capes. Agafem l’exemple de l’aprovisionament coordinat d’enllac¸os IP, que ´ es una activitat elemental de coordinaci´ o multicapa, i on es mostra el funcionament dels diferents components de l’arquitectura del gestor de xarxes. Aleshores es procedirem a exposar algunes aplicacions en xarxes comercials. 2.4.1 Aprovisionament coordinat d’enllac¸os IP L’establiment d’un enllac¸ IP es una operaci´ o prim` aria, i es fa servir com a il·lustraci´ o i base de pr` acticament totes les operacions complexes multicapa. Tot i que aquesta operaci´ o es considera simple, i pot ser f` acilment implementada amb les accions de control del pla, en realitat requereix m´ ultiples interaccions humanes i configuracions independents en els sistemes de control relatius a la IP aix´ ı com xarxes de transport. Aquesta ´ es precisament la ra´ o per la que per a l’aprovisionar una IP en xarxes modernes fan falta dies enlloc de segons, com seria d’esperar. Aprovisionar una IP requereix quatre passos b` asics: 1) Determinar el link-point disponible dels routers corresponents, 2) Determinar les interf´ ıcies de transport de clients connectades a les interf´ ıcies IP disponibles, 3) Aprovisionar un servei de circuit entre les interf´ ıcies de clients corresponents en la xarxa de transport amb adaptacions de framing adequades, i finalment, 4) Configurar les interf´ ıcies d’IP als dos punts finals per tal d’inicialitzar la connexi´ o IP. En aquest exemple, el trigger 1 per la operaci´ o´ es generada per la operadora, que inclou informaci´ o sobre els routers end-point a xarxa IP, les interf´ ıcies IP disponibles i les adreces IP que es faran servir per la connexi´ o requerida. El trigger ´ es identificat primer en l’Ontology Mapper Module 2 3 , i usant aquest, el Front-End Management Module selecciona la connexi´ o IP proveint flux de treball des de la Operation workflow database 4 5 . Basat en la definici´ o del flux de treball, el Front-End Management Module primer sol·licita un cam´ ı des del PCE entre els dos end-points 6 en la xarxa de transport. El PCE utilitza el TED multi-capa per determinar la correlaci´ o entre les interf´ ıcies IP i la corresponent interf´ ıcie de transport de clients en la xarxa de transport, i computa un cam´ ı entre ells a la xarxa de transport, retornant aquesta informaci´ o a l’adaptador 7 . Utilitzant aquesta informaci´ o, el Front-End Management Module primer sol·licita el transport NMS via MTOSI per establir un circuit a la xarxa de transport 8 9 10 , i quan aix` o te ` exit, sol·licita a l’IP NMS que reconfiguri les interf´ ıcies IP11 12 13 . Despr´ es de rebre confirmaci´ o de l’IP NMS de que la reconfiguraci´ o ha sigut efectuada, l’adaptador notifica a l’operadora que la connexi´ o IP ha sigut establerta. 24 Figura 5 Mentre que aquesta coordinaci´ o b` asica pot ser millorada mitjanc¸ant un bon nombre de procediments autom` atics, per exemple mitjanc¸ant el pla de control, la novetat del procediment proposat resta en la seva capacitat de desenvolupar i reutilitzar el flux de treball de forma flexible, i d’assegurar-se de que les definicions dels fluxos de treball no resulten afectades per canvis en els sistemes externs utilitzats (p.ex. IP NMS, Transport NMS). Per a aquesta finalitat, utilitzem una representaci´ o meta-ontol` ogica dins de l’adaptador, i cada interacci´ o que involucra l’adaptador i un sistema extern s’envia en primer lloc a l’Ontology Mapper. L’Ontology Mapper, com s’ha mostrat en l’anterior secci´ o, pot aleshores facilitar la transformaci´ o d’una operaci´ o sol·licitud/resposta en la representaci´ o meta-ontol` ogica utilitzada pels sistemes externs i viceversa, assegurantse de que un canvi en el sistema extern no canviar` a el flux de treball. Per tant, en aquest exemple, en un cas de transici´ o tecnol` ogica a un nou IP NMS, l’operadora hauria de crear nom´ es definicions ontol` ogiques basades en la nova interf´ ıcie per assegurar-se de que l’adaptador funciona amb la nova configuraci´ o. 2.4.2 Altres aplicacions Aquesta capacitat de crear, emmagatzemar, i reutilitzar flux de treball de forma senzilla facilita el desenvolupament d’un nombr´ os grup d’escenaris d’interacci´ o multicapa. Per tant, il·lustrarem un parell d’` arees d’inter` es pels prove¨ ıdors per facilitar la coordinaci´ o multi-capa que pot ser classificada com i) Optimitzaci´ o basada en pol´ ıtiques iii) Recuperaci´ o d’errors i optimitzaci´ o post-errors. La classe d’accions de coordinaci´ o basada en pol´ ıtiques tracta amb els escenaris on les operacions s’inicien de forma autom` atica en resposta a canvis en l’estat de la xarxa basant-se en una pol´ ıtica pr` eviament configurada. El paradigma de descarrega d’IP ´ es una d’aquestes aplicacions que est` a dissenyada per fer front a increments forts i sobtats de tr` afic a la xarxa d’IP. A la pr` actica, aix` o normalment passa perqu` e grans fluxos que atrav` essin diversos routers IP causen que els enllac¸os i routers intermedis estiguin molt carregats. En aquest escenari, la xarxa es podria beneficiar de la possibilitat de “descarregar“ part d’aquest tr` afic en circuits que poden ser din` amicament establerts en la xarxa de tr` afic per “derivar“ cap a routers i links intermediaris [5]. El proc´ es per 25 Figura 9: Mostra inici de proc´ es de mapeig. Noti’s les propostes que dona l’algorisme i que l’usuari pot confirmar (mapeig supervisat). Aix` o permet construir un mapeig amb menys temps, i dona la possibilitat a l’usuari de controlar que es faci correctament. 32 Figura 10: Mostra sobre representaci´ o del mapeig un cop s’han acceptat les propostes. 4.3 Definici´ o de les ontologies Per a aquest projecte han fet falta 4 ontologies, que podem classificar en tres categories, tal com es pot veure a la seg¨ uent figura: Figura 11 33 • general: En aquesta ontologia s’hi guarden possibles accions que es poden dur a terme, i els par` ametres que es necessitarien. • quagga/juniper: Primerament cal aclarar que tant quagga com juniper es tracten de dos marques de router. Aquests dos routers s´ on, tal com es veur` a m´ es endavant, els que s’han fet servir en aquest projecte. Tot i aix` o, en aquest cap´ ıtol, quan es parla de quagga i de juniper es refereix a les ontologies que contenen les dades necess` aries per a la seva configuraci´ o. En aquest cas, i a difer` encia de la ontologia general, a part de les possibles accions i els par` ametres necessaris per a dur-les a terme, a m´ es s’hi guarden les comandes (cas ontologia Quagga) o les l´ ınies en xml (cas ontologia Juniper) necess` aries per a dur a terme les accions. • map: Aquesta ontologia cont´ e el mapeig entre la ontologia general i les ontologies quagga i juniper. Arribats a aquest punt, s’entrar` a a exposar amb m´ es detall la estructura de les ontologies. 4.3.1 General Aquesta ontologia est` a formada per dues classes: input, i action. Aquesta ´ ultima ´ es la que s’utilitzar` a com a punt de partida per a trobar les instruccions que cal dur a terme per a configurar els routers. A m´ es, est` a relacionada amb la classe input a trav´ es de l’object property needsInput. Amb aquesta relaci´ o es deixa la estructura necess` aria preparada de cara a una futura possible implementaci´ o d’una funci´ o que permeti, donats els par` ametres d’entrada introdu¨ ıts per l’usuari final, calcular la acci´ o a realitzar. Figura 12: Esquema de la estructura de la ontologia general. 4.3.2 Quagga/Juniper Si b´ e aquestes dues ontologies presenten una estructura gaireb´ e equivalent a la de la ontologia general, estan formades per una classe extra, tal com es pot veure a la figura. Aquesta classe, command per a la ontologia quagga i tag per a la ontologia juniper, ´ es la que cont´ e les instruccions que cal dur a terme per a configurar els routers. En el cas de la ontologia quagga, es tracta de les instruccions que utilitzar´ ıem via terminal per a configurar aquest router. En canvi, a la ontologia juniper s’hi guarden els trossos de codi xml que es pot passar al router per a aconseguir que es configuri de la forma desitjada. La classe action cont´ e, a m´ es, l’object property uses, que l’enllac¸a amb la classe command otag. Tant en la versi´ o quagga com en la versi´ o juniper, la classe command otag cont´ e una datatype property que guarda la comanda o el tros de codi xml exactes, segons la ontologia. En cas de ser necessari un par` ametre, aquest s’indicaria amb la expressi´ o $+nom par` ametre dins de la comanda o el codi. A m´ es, tamb´ e cont´ e la datatype 34 property priority, que indica la prioritat d’un codi. A la relaci´ ouses, mencionada fa un moment, no s’hi pot guardar cap mena d’ordre, i aix` o fa que aquest ´ ultim par` ametre sigui necessari per a saber amb quin ordre hem d’executar les comandes o escriure el codi xml. Aix` o es pot fer d’aquesta manera ja que abans d’executar algunes comandes s’han d’executar unes altres, o dit d’una altra manera, si es dibuix´ es un arbre amb les comandes executades per a configurar un router es veuria que aquestes tendeixen a seguir un ordre. Finalment, la classe command otag est` a relacionada amb la classe input a trav´ es de l’object property needs. Aquesta relaci´ o´ es ´ util de cara a substituir les indicacions de par` ametre pel valor dels par` ametres que haur` a passat l’usuari, ja que permet incrementar la efici` encia d’aquesta passa. D’aquest fet se’n parlar` a m´ es endavant, al cap´ ıtol Treball realitzat. Figura 13: Diagrama de classes de la ontologia quagga. El diagrama de la ontologia juniper ´ es an` alog. 4.3.3 Map Finalment, ara s’exposar` a la ontologia que guarda el mapeig entre la ontologia general i les ontologies quagga ijuniper. Figura 14: Diagrama de classes de la ontologia map. 35 Tal com es pot observar a la figura, aquesta ontologia t´ e tres classes: Mapping Metadata, Mapping Component, i One to one mapping. Cal aclarir que aquesta ontologia ha sigut creada a trav´ es de Prompt, el plugin de Prot´ eg´ eque s’ha mencionat abans. La classe Mapping Metadata cont´ e dades sobre quan s’ha mapejat dos components, i qui n’´ es l’autor. La classe Mapping Component, en canvi, cont´ e informaci´ o sobre un element pertanyent a una ontologia aliena a aquesta. M´ es concretament cont´ e el nom de l’element que representa, la font d’aquest element -a quina ontologia pertany-, i quin tipus de component ´ es. Finalment, a la classe One to one mapping ´ es on s’hi guarden els mapejos entre elements de les diferents ontologies. L’object property source apunta a l’element origen del mapeig, mentre que L’object property target apunta a l’element de destinaci´ o. En el cas d’aquest projecte, com que nom´ es es necessita un mapeig entre les classes action de les diferents ontologies, s’ha optat per fer un mapeig parcial. 36 5 Treball realitzat En aquest cap´ ıtol, s’exposar` a la soluci´ o proposada en aquest projecte. Concretament, es donar` a primerament una visi´ o global d’aquesta. Es prosseguir` a amb les passes realitzades de cara a realitzar el projecte: passos previs, construcci´ o de la interf´ ıcie gr` afica, posada en marxa d’un servlet, programaci´ o del gestor d’ontologies, i finalment, llanc¸ament de la configuraci´ o. 5.1 Estructura del projecte Es pot dividir aquest projecte, tal com es pot veure a la seg¨ uent figura, en 4 grans parts. Figura 15 Per una banda hi ha la estructura f´ ısica (part 1), que en aquest cas cas consisteix d’una petita xarxa formada per un switch i dos routers connectats a aquest. Per a aquest projecte s’ha utilitzat un router Juniper, i un altre Quagga. El fet d’utilitzar dos routers diferents permet construir i mostrar el projecte de tal forma que quedi reflexada la seva capacitat per a treballar amb routers que utilitzin sintaxis diferents. Tenir aquesta estructura resulta indispensable no nom´ es de cara a provar el codi sin´ o que tamb´ e´ es 37 una gran ajuda a la hora de fer un disseny realista d’aquesta aplicaci´ o. A m´ es, hi ha connectat un ordinador amb l’OpenNMS instal·lat (part 2) i funcionant, que veu els components de la xarxa a la qual hi est` a connectat. L’OpenNMS ´ es una plataforma de gesti´ o de xarxes open source, desenvolupada a nivell empresarial [26]. Com interactua aquesta eina amb aquest projecte es veur` a m´ es endavant. A m´ es, a l’ordinador mencionat hi ha un servlet instal·lat que cont´ e, entre d’altres, la p` agina web que s’utilitza com a interf´ ıcie gr` afica en aquest projecte (part 3). S’ha triat fer una p` agina web per diversos motius: per una banda, la senzillesa de fer-ho aix´ ı, amb la conseq¨ uent reducci´ o d’errors possibles, per una altra banda perqu` e aix` o permet utilitzar el sistema sense que s’hagi de fer cap instal·laci´ o a la part del client, i finalment perqu` e aix` o permet la utilitzaci´ o del sistema amb independ` encia de sistema operatiu que es vulgui utilitzar a la part del client. Pel que fa al servlet, aquesta ´ es una eina que permet extendre la funcionalitat d’un servidor web. M´ es concretament, permet executar un programa escrit en java des d’una p` agina web, superant aix´ ı les limitacions del llenguatge javascript [17]. Aquest ´ es executat des de la part del servidor. Dins de l’ordinador amb l’OpenNMS i el servlet instal·lats tamb´ e hi ha les ontologies necess` aries per a extreure’n les comandes que es necessiten per a configurar els routers instal·lats a la part f´ ısica. Finalment, es disposa d’una classe, routerOntologyManager, que interactua amb el servlet i les ontologies, i ´ es la que s’utilitza per a extreure a partir dels par` ametres d’entrada la informaci´ o necess` aria de les ontologies per a poder configurar els routers de forma autom` atica (part 4). 5.2 Passos previs Per tal de poder comenc¸ar a fer la part codi del projecte, cal deixar preparada tant la interf´ ıcie f´ ısica amb els routers, com l’OpenNMS instal·lats. A m´ es, cal deixar l’ordinador preparat per a poder allotjar un servlet. Pel que fa a aix` o´ ultim, s’ha decidit instal·lar Tomcat (versi´ o 6), una implementaci´ o open source de les tecnologies Java Servlet i JavaServer Pages [2]. Un cop instal·lat, cal crear una carpeta, en el cas d’aquest projecte s’ha anomenat router management, a la adrec¸a: /var/lib/tomcat6/webapps/ Dins de la nova carpeta hi van els arxius necessaris per poder carregar la p` agina web. A m´ es, hi va una carpeta anomenada WEB-INF, que cont´ e l’arxiu web.xml i les carpetes classes ilib. L’arxiu web.xml cont´ e les propietats de la aplicaci´ o web. En canvi, la carpeta classes cont´ e les classes ja compilades necess` aries per a executar la aplicaci´ o, mentre que la carpeta lib cont´ e les biblioteques necess` aries per a les classes mencionades. 38 Pel que fa a altres arxius necessaris per a la execuci´ o del sistema, com les ontologies i els scripts, s’han posat a la carpeta router management. 5.3 Creaci´ o de la interf´ ıcie gr` afica Tot seguit s’exposar` a amb detall el funcionament de la interf´ ıcie gr` afica. Com que el codi d’aquest projecte est` a preparat per a un conjunt molt limitat d’opcions de configuraci´ o, no fa falta disposar d’una interf´ ıcie gr` afica, en aquest cas en forma de p` agina web, massa complicada. Com que el llenguatge html ´ es massa limitat per a la necessitat d’aquest projecte, s’ha optat per implementar una part en javascript. A m´ es, aix` o permet cridar el servlet un cop introdu¨ ıts i confirmats els par` ametres d’entrada. Es pot dividir la estructura de la p` agina web per funcionalitat en tres parts: 1. Interf´ ıcie gr` afica. 2. Inicialitzaci´ o. 3. Comprovaci´ o dels par` ametres d’entrada introdu¨ ıts i crida del servlet. 5.3.1 Interf´ ıcie gr` afica Aquest projecte permet poques opcions de configuraci´ o de routers, i per tant, s’ha decidit posar pocs camps a trav´ es dels quals es rebin els par` ametres d’entrada, tal com es pot veure a la seg¨ uent figura. Figura 16: Mostra de la p` agina web realitzada en aquest projecte. Tal com es pot veure, s’ha decidit posar tres camps per router a configurar: una llista de selecci´ o per a seleccionar el router que es vulgui configurar, una altra llista de selecci´ o per a seleccionar la interf´ ıcie, i finalment un camp per a introduir la nova adrec¸a IP que volem assignar. El bot´ ook ´ es l’encarregat de cridar la funci´ o que s’encarrega de comprovar els par` ametres d’entrada i de cridar el servlet. 5.3.2 Inicialitzaci´ o Aquest projecte est` a pensat de cara a la configuraci´ o de routers, amb independ` encia de la topologia de la xarxa que sest` a fent servir. Aix` o introdueix la necessitat de tenir alguna manera de llegir quins routers hi ha connectats i que estan disponibles per a ser configurats. 39 Per tal de mostrar quins s´ on els routers disponibles a la xarxa on estem connectats, i les seves interf´ ıcies, a la hora de carregar la p` agina es llegeix l’arxiu summary.xml. Aquest arxiu cont´ e una llista dels dispositius, juntament amb les seves interf´ ıcies, que es poden veure des de l’OpenNMS. Aquesta llista es pot descarregar i actualitzar amb la comanda: wget --http-user=admin --http-passwd=admin --auth-no-challenge -O summary.xml ’http://10.1.1.46:8980/opennms/summary/results.htm? listInterfaces=false&filterRule=ipaddr+iplike+*.*.*.*& startTime=1184173183&endTime=1185219010&attributeSieve=ifOutOctets’ Aquest proc´ es no es fa de forma autom` atica quan un usuari carrega la p` agina web. Per tal de compensar aquesta mancanc¸a es proposa executar aquesta comanda de forma autom` atica amb l’ajuda de cron, un daemon que permet executar comandes o scripts de forma autom` atica cada un cert temps [6] [29]. En la seg¨ uent figura, s’hi pot veure una mostra sobre com queda una llista de selecci´ o despr´ es d’haver llegit l’arxiu summary.xml. Figura 17: Mostra de llista de selecci´ o. Hi ha dues funcions encarregades de llegir l’arxiu summary.xml, una per als routers i l’altra per a les interf´ ıcies. El que fan ´ es crear una llista d’elements seleccionables a partir de l’arxiu xml: function setOptions(opt){ var i=0; opt.options.length = 0; opt.options[opt.options.length] = new Option("Select a router"); for(i=0; NodeList.length>i;i++){ opt.options[opt.options.length] = new Option(NodeList[i].getElementsByTagName("name")[0].childNodes[0].nodeValue); } } El primer element introdu¨ ıt, Select a router, serveix per tal d’indicar a l’usuari qu` e´ es el que s’hi selecciona en aquest camp. Despr´ es d’afegir aquest element, la funci´ o llegeix de l’arxiu summary.xml la s` erie de routers que es poden veure des de l’OpenNMS. 40 La funci´ o que s’encarrega d’inicialitzar la llista de selecci´ o per a les interf´ ıcies disponibles ´ es an` aloga a la llista de selecci´ o dels routers. Com que s’ha de fer una crida a les funcions per cada llista de selecci´ o a completar, per` o en el moment de carregar la p` agina web nom´ es ´ es perm´ es de cridar-ne una, s’ha decidit implementar una funci´ o auxiliar que s’encarrega d’inicialitzar-ho tot: function start(){ setOptions(document.form1.devices1); setOptions(document.form1.devices2); setInterfaces(document.form1.interfaces1); setInterfaces(document.form1.interfaces2); } 5.3.3 Comprovaci´ o dels par` ametres d’entrada introdu¨ ıts i crida del servlet El bot´ oOk executa una funci´ o que s’encarrega de dues coses: comprovar la correctesa dels par` ametres d’entrada introdu¨ ıts per l’usuari, i cridar al servlet. function executeConfiguration(){ //First, we need to check if the inputs are correct. //In other words, if the IP adresses are valid. if(!checkInputs()){ return; } //This calls the servlet. document.form1.submit(); } Pel que fa a la comprovaci´ o dels par` ametres d’entrada, es comprova per una banda que s’hagi seleccionat algun router i alguna interf´ ıcie, i que la adrec¸a IP introdu¨ ıda sigui correcta. function executeConfiguration(){ function checkInputs(){ if(!ipAddressIsValid(document.form1.ip1.value)|| !ipAddressIsValid(document.form1.ip2.value)){ alert("Error: Invalid IP adress."); return false; } else if (!selectIsValid(document.form1.devices1.value)){ alert("Error: First router not selected."); return false; } else if (!selectIsValid(document.form1.devices2.value)){ 41 Postcondicions La taula retornada contindr` a les instruccions que cal dur a terme per a realitzar la acci´ o entrada ordenades segons l’ordre d’execuci´ o. Passes internes 1. Obtenir la classe action de la ontologia juniper o quagga. 2. Obtenir la col·lecci´ o d’individuals de la classe obtinguda al pas 1. 3. Cercar l’individual que representi la acci´ o que es vol dur a terme. 4. Obtenir la col·lecci´ o d’instruccions associades a l’individual trobar al pas anterior. 5. Ordenar la col·lecci´ o d’instruccions per prioritat. Sortida Una taula de instrPrior. En cas de que es produeixi algun error, es tornar` a una taula sense elements. Figura 21 48 Completar les instruccions amb els par` ametres introdu¨ ıts per l’usuari Abans de prosseguir, cal aclarir que a difer` encia de la resta de passes excepte la ´ ultima, aquesta ´ es executada a la classe submitConf sense que hi intervingui la classe routerOntologyManager. Precondicions La taula de instrPrior ha de contenir com a m´ ınim un element. Postcondicions S’haur` a substitu¨ ıt l’indicador de par` ametre de les instruccions guardades a la taula pel valor donat per l’usuari. Passes internes Per cada instrucci´ o de la taula, fer: 1. Comprovar si cont´ e algun indicador de par` ametre. 2. Si ´ es el cas, substituir l’indicador pel valor de la variable correcta. En cas de que la taula no contingui elements, no es far` a res. Escriure fitxer En aquest projecte hi ha dos casos sobre com escriure el projecte, depenent de si el fitxer ´ es per al router juniper o per al router quagga. Operaci´ o writeJuniperScript(instrPrior instructSet[]); Precondicions La taula instructSet ha de contenir algun element. Postcondicions S’haur` a escrit un fitxer amb el codi xml necessari per a configurar el router tal com demana l’usuari. Passes internes 1. Obrir, o crear si s’escau, el fitxer newConfig.xml a la carpeta /var/lib/tomcat6/webapps/router management/. 2. Com que es possible que en un tros de codi xml s’hi hagi d’incrustar al mig un altre tros de codi guardat en una altra posici´ o de la taula, s’ha optat per implementar una funci´ o auxiliar que escrigui el fitxer de forma recursiva. S’ha optat per indicar el comportament d’aquesta funci´ o en pseudocodi per tal d’aconseguir m´ es claredat. En cas de que la taula no contingui elements, no es far` a res. Operaci´ o writeJuniperScriptAux(BufferedWriter output, instrPrior instructSet[], int i); Precondici´ o: output no pot valer nul. instructSet ha de contenir algun element, cada element no pot contenir “$MORECODE” dos o m´ es vegades, i l’´ ultim element no en pot contenir cap. iha de tenir un valor dins del rang de instructSet. Cas base: Si instructSet[i] no cont´ e el valor “$MORECODE” llavors Escriure instructSet[i] a trav´ es de output Cas recursiu: dins del codi actual cal incrustar codi d’altres elements. Altrament 49 Escriure instructSet[i] a trav´ es de output des del principi fins “$MORECODE”. Es crida la mateixa funci´ o, passant com a par` ametre i+1. Escriure instructSet[i] a trav´ es de output des de despr´ es de “$MORECODE” fins al final. Fi si Postcondici´ o: S’ha escrit en l’arxiu apuntat per output el codi xml guardat des de instructSet[i] fins instructSet[mida instructSet]. Per al cas d’escriure el script per a configurar el router quagga, s’utilitzen dues variables auxiliars la primera de les quals cont´ e la part comuna del principi del script , mentre que la segona cont´ e la part comuna del final del script. Per part comuna s’ent´ en part que estar` a sempre present en qualsevol script, siguin les que siguin les comandes que cal dur a terme. Operaci´ o writeQuaggaScript(instrPrior instructSet[]); Precondicions La taula instructSet ha de contenir algun element. Postcondicions S’haur` a escrit un script amb les instruccions a dur a terme. Passes internes 1. Obrir, o crear si s’escau, el fitxer quagga.py a la carpeta /var/lib/tomcat6/webapps/router management/. 2. Escriure la primera part del script al fitxer. 3. Rec´ orrer les comandes guardades a instructSet, i escriure-les al fitxer. 4. Escriure la part final del script al fitxer. 5. Tancar el fitxer quagga.py. En cas de que la taula no contingui elements, no es far` a res. 5.4.4 Llanc¸ament de la configuraci´ o Quan s’ha arribat a aquest punt, nom´ es queda llanc¸ar la configuraci´ o. De la mateixa manera que a la passa anterior, hi ha una petita difer` encia respecte de si es llanc¸a la configuraci´ o per al router juniper o si es fa per al quagga. Per al cas quagga, es pot executar directament el script quagga.py que ha estat escrit a la passa anterior. Des d’un programa escrit en llenguatge java amb la crida: pr = rt.exec("python quagga.py", null, dir); On pr ´ es el nou proc´ es que creem, rt la inst` ancia de la classe Runtime i que permet la interactuaci´ o amb l’entorn on s’est` a executant la classe que la utilitza [18], “python quagga.py” la ordre que volem executar, i dir el directori on volem executar l’ordre. El cas juniper ´ es molt semblant, tot i que hi ha una difer` encia important. Cal recordar que en comptes d’escriure un fitxer que contingui un script, s’ha escrit un fitxer contenint codi xml. Juniper t´ e la caracter´ ıstica que se li poden passar arxius xml per a configurar-lo, cosa que es pot fer a trav´ es d’un script. Per a aquest projecte es disposa d’un script, junoscript.py, que permet fer aix` o, de manera que per a llanc¸ar la configuraci´ o nom´ es cal executar aquest script. La crida ´ es an` aloga al cas quagga. 50 Un cop executat el script corresponent, cal, en els dos casos, esperar a que s’acabi d’executar. Un cop acabada la execuci´ o, es procedeix a informar l’usuari que la configuraci´ o ja est` a feta. 5.5 Funcionament intern de les classes Havent exposat l’estructura del servlet, les seves classes i la interacci´ o entre elles, s’entrar` a en aquesta secci´ o m´ es en detall sobre el funcionament intern de cada una d’elles. Es comenc¸ar` a per la classe instrPrior, ja que ´ es la m´ es senzilla, i la que no dep` en de cap altra. Tot seguit s’exposar` a la classe routerOntologyManager, i finalment la submitConf. 5.5.1 instrPrior Aquesta classe cont´ e tres variables globals on es guarden les dades respectives a una instrucci´ o: intruction: String priority: Enter varUsed: String Pel que fa als m` etodes, aquests s´ on: instrPrior(instr: String, prior: Enter, var: String) Pre: Cert Post: L’objecte implicit ha sigut inicialitzat amb les variables instr,prior ivar. instruction := instr priority := prior varUsed := var funci´ ogetInstruction() retorna instruction:String Pre: Cert Post: Es retorna la instrucci´ o guardat a l’objecte impl´ ıcit. ffunci´ o acci´ osetInstruction(entrada: newInstr: String) Pre: newInstr no pot ser nul. Post: S’assigna la nova instrucci´ o newInstr a l’objecte impl´ ıcit. si newInstr 6=nul llavors instruction := newInstr fsi facci´ o funci´ oisGreaterThan(x: instrPrior) retorna aux:boole` a 51 Pre: x no pot ser nul. Post: Es retorna cert si i nom´ es si l’objecte implicit t´ e m´ es prioritat que l’objecte explicit x,´ es a dir, si el valor priority de l’objecte implicit ´ es m´ es baix que el de l’objecte impl´ ıcit. aux := priority >x.priority retorna aux ffunci´ o funci´ oisLessThan(x: instrPrior) retorna aux:boole` a Pre: x no pot ser nul. Post: Es retorna cert si i nom´ es si l’objecte implicit t´ e menys prioritat que l’objecte explicit x,´ es a dir, si el valor priority de l’objecte implicit ´ es m´ es alt que el de l’objecte impl´ ıcit. aux := priority <x.priority retorna aux ffunci´ o funci´ ogetVariable() retorna varUsed:String Pre: Cert Post: Es retorna la instrucci´ o guardat a l’objecte impl´ ıcit. ffunci´ o 5.5.2 routerOntologyManager Aquesta classe cont´ e dues variables globals on es guarden uns Strings que contenen el nom de les ontologies que cal utilitzar. MAP ONT: String SPECIFIC ONT: String Els m` etodes implementats s´ on: routerOntologyManager(MapOnt: String, SpecificOnt: String) Pre: Cert Post: L’objecte implicit ha sigut inicialitzat amb les variables MapOnt, i SpecificOnt. MAP ONT := MapOnt SPECIFIC ONT := SpecificOnt funci´ oreplaceVariable(toChange: String, oldValue: String, newValue: String)retorna newString: String 52 Pre: toChange i oldValue no poden tenir valor nul, i toChange ha de contenir oldValue. Post: S’ha substitu¨ ıt el valor de oldValue de dins de toChange per newValue. i, x: Enter newString: String x := toChange.indexOf(oldValue) si x6=−1llavors newString := toChange[0..x] + newValue + toChange(x..llargada oldValue] altrament newString := nul fsi ffunci´ o funci´ ogetInstructions(action: String)retorna instructSet: taula[1..N] de instrPrior Pre: toChange i oldValue no poden tenir valor nul, i toChange ha de contenir oldValue. Post: S’ha substitu¨ ıt el valor de oldValue de dins de toChange per newValue. reader: FileReader owlModel: OWLModel instances: Collection instructSet: taula[1..N] de instrPrior i, auxPrior: Enter cls: OWLNamedClass individual, instrToDo, auxInstr: RDFIndividual uses: OWLObjectProperty cmd, priority, needs, name: RDFProperty auxCmd: String it: Iterador Inicialitzaci´ o de variables: reader := new FileReader(“/var/lib/tomcat6/webapps/router management/” + SPECIFIC ONT) owlModel := ProtegeOWL.createJenaOWLModelFromReader(reader) S’obt´ e la propietat de la ontologia que guarda les instruccions si SPECIFIC ONT pertany a Quagga llavors cmd := owlModel.getOWLProperty(“cmd”) 53 sino si SPECIFIC ONT pertany a Juniper llavors cmd := owlModel.getOWLProperty(“line”) altrament cmd := nul fsi priority := owlModel.getOWLProperty(“priority”) needs := owlModel.getOWLProperty(“needs”) uses := owlModel.getOWLObjectProperty(“uses”) name := owlModel.getOWLProperty(“name”) instructSet := nul Es comprova que les inicialitzacions han anat be si cmd = nul opriority = nul ouses = nul oneeds = nul oname = nul llavors retorna nul fsi Pas 1: buscar la classe necess` aria per a aconseguir les accions. cls := getClassByName(owlModel, nameClass) Pas 2: Trobar l’individual anomenat com a “action”. Es comprova el valor de cls per a assegurar que no hi hagin errors. si cls 6=nul llavors individual := trobarIndividualDe(cls, action) fsi Pas 3: Obtenir les instruccions necess` aries i guardar-les. si individual 6=nul llavors instances cont´ e una llista de les instruccions obtingudes. instances := individual.getPropertyValues(uses) La taula instructSet passa a tenir tantes posicions, N, com instruccions trobades. instructSet := new instrPrior[mida instances] i := 0 it := instances.iterator() Invariant: les primeres i instruccions trobades estan guardades a instructSet mentre it t´ e seg¨ uent i i<Nfer instrToDo := seg¨ uent it auxCmd := instrToDo.getPropertyValue(cmd) auxPrior := instrToDo.getPropertyValueLiteral(priority).getInt() auxInstr := instrToDo.getPropertyValue(needs) 54 si auxInstr 6=nul llavors auxName := auxInstr.getPropertyValue(name) altrament auxName := nul fsi instructSet[i] := new instrPrior(auxCmd, auxPrior, auxName) i:=i+1 fmentre fsi Acabament: a cada volta d’incrementa la i, i es passa al seg¨ uent element de la llista it. Per tant, arriba un moment en que s’acaba la llista, la condici´ o it te seg¨ uent i i <N es deixa de complir, i s’acaba. Pas 4: ordenar les instruccions per prioritat. si instructSet 6=nul instrSort(instructSet) fsi ffunci´ o funci´ ogetEquivalentAction(genAction: String)retorna action: String Pre: genAction no pot ser nul, i ha de contenir el nom d’una acci´ o existent a la ontologia general Post: Es retorna el nom de la acci´ o equivalent a genAction reader: FileReader owlModel: OWLModel component name, component source: RDFProperty generic, target: RDFIndividual action: String reader = new FileReader(“/var/lib/tomcat6/webapps/router management/map.owl”) owlModel = ProtegeOWL.createJenaOWLModelFromReader(reader) Pas 1: Obtenci´ o de les propietats que es necessitaran: component name := getOWLProperty(“component name”) component source := getOWLProperty(“component source”) Pas 2: Obtenci´ o de la classe objectiu. generic := getIndividualMCClass(owlModel, component name, component source, genAction, ”JenaOWLModel(generic)”) target := getIndividualOtomClass(owlModel, generic) Obtenci´ o del nom de la acci´ o 55 si target 6=nul action := target.getPropertyValue(component name) fsi ffunci´ o funci´ ogetIndividualMCClass(owlModel: OWLModel, component name component source: RDFProperty, name source String)retorna individual: RDFIndividual Pre: cap par` ametre d’entrada pot tenir valor nul, i name i source han de tenir el nom d’una propietat existent dins de owlModel Post: Es retorna un individual amb les propietats donades classes, instances: Collection it: Iterador cls: OWLNamedClass individual: RDFIndividual trobat: boole` a trobat := fals Pas 1: Obtenir la classe “Mapping Component” cls := getClassByName(owlModel, “Mapping Component”) Pas 2: Obtenir l’individual. Com que no sabem el nom, sin´ o nom´ es valors de les seves propietats, s’han de comprovar tots els individuals de la classe un a un manualment. si cls 6=nul llavors S’obt´ e la llista d’individuals pertanyents a la classe. instances := cls.getInstances(false) Invariant: No s’ha trobat l’individual el valor de les propietats donades sigui name i source. it := instances.iterator() mentre it t´ e seg¨ uent i trobat=fals fer individual := seg¨ uent it si individual.getPropertyValue(component name) = name i individual.getPropertyValue(component source) = source llavors trobat=cert fsi fmentre Acabament: A cada volta es passa al seg¨ uent element de la llista it, de manera que en el pitjor dels casos s’acaba quan la condici´ o “it t´ e seg¨ uent” ja no sigui certa. 56 ffunci´ o funci´ ogetIndividualOtomClass(owlModel: OWLModel, source RDFIndividual)retorna target: RDFIndividual Pre: owlModel i source no poden ser nuls, i source ha de ser un individual “font” dins de la ontologia ontModel. Post: Es retorna l’individual equivalent a source segons la ontologia que guarda el mapeig. classes, instances, objProp: Collection it, ij: Iterador cls: OWLNamedClass aux, target, auxaux: RDFIndividual prop: RDFProperty starget: String trobat: boolea Pas 1: obtenir la classe “One to one mapping” cls := getClassByName(owlModel, “One to one mapping”) Pas 2: Obtenir individual auxiliar que apunti com a “font” a source si cls 6=nul llavors prop := owlModel.getOWLObjectProperty(“source”) trobat := fals instances = cls.getInstances(false) it = instances.iterator() Invariant: No s’ha trobat l’individual de la classe One to one mapping que apunta com a “source” o “font” a source mentre it t´ e seg¨ uent i trobat = fals fer aux := seg¨ uent it si aux.getPropertyValue(prop) = source llavors trobat := cert fsi fmentre Acabament: a cada volta es passa al seg¨ uent element d’it, de manera que en el pitjor dels casos, s’acaba quan la condici´ o it t´ e seg¨ uent deixi de ser certa. En cas de que s’hagi trobat l’individual buscat, trobat passa a ser cert, trobat = fals es deixa de complir i es surt complint aix´ ı amb l’invariant. fsi Pas 3: obtenir l’individual “objectiu” o “target” apuntat per l’individual trobat al pas 2. 57 6.1.2 Missatge per configuraci´ o correcta En cas de que la configuraci´ o dels routers s’hagi dut a terme sense errors, s’informa l’usuari tal com es mostra a la figura: Figura 24: Missatge de configuraci´ o correcta dels routers. 6.2 Resultats en la part servlet Es mostrar` a el resultat d’aquest projecte a trav´ es d’un exemple. Concretament es mostrar` a la creaci´ o d’un link IP entre un router Juniper i un Quagga, el primer amb la IP 10.1.1.100, i el segon amb IP 10.1.1.200. Primer de tot, es comprova que els dos routers estan desconfigurats. Per comprovar l’estat del router juniper, s’hi accedeix a trav´ es de telnet, i un cop dins es pot comprovar la configuraci´ o de les interf´ ıcies amb la comanda: show configuration interfaces 64 El resultat ´ es el seg¨ uent: Figura 25 Amb el router Quagga es fa la mateixa passa. Un cop s’ha entrat dins del router, amb la comanda write terminal comprovem la configuraci´ o, amb el resultat seg¨ uent: Figura 26 65 Tal com es pot comprovar, els dos routers no tenen cap link IP entre s´ ı. Com a conseq¨ u` encia, quan es tiren un ping l’un a l’altre tampoc obtenen resposta: Figura 27: S’intenta fer ping de Juniper a Quagga sense cap resposta. Figura 28: S’intenta fer ping de Quagga a Juniper tamb´ e sense cap resposta. Aix´ ı doncs, a la p` agina web s’introdueixen els par` ametres per comenc¸ar la configuraci´ o. 66 Figura 29: Es seleccionen i s’introdueixen els par` ametres necessaris per a crear un link IP. Tal com ja s’ha exposat al cap´ ıtol anterior, abans de llanc¸ar les configuracions, es crea un arxiu per cada router a configurar a partir del qual es podr` a executar la configuraci´ o mateixa. Despr´ es d’haver fet clic a ok, s’hauran creat dos arxius a la carpeta /var/lib/tomcat6/webapps/router management de l’ordinador amb el servlet instal·lat. Pel que fa a l’arxiu que s’utilitza per a la configuraci´ o Juniper, anomenat newConfig.xml, el seu contingut ´ es el seg¨ uent: <rpc> <load-configuration action="merge"> <configuration> <interfaces> <interface> <name>fxp0.0 (10.1.1.43, 100 Mbps)</name> <unit> <name>0</name> <family> <inet> <address> <name>10.1.1.100/24</name> </address> </inet> </family> </unit> </interface> </interfaces> </configuration> </load-configuration> </rpc> 67 En canvi, per a la configuraci´ o del router Quagga, s’escriu un arxiu anomenat quagga.py, el contingut del qual despr´ es de llanc¸ar la configuraci´ o d’exemple ´ es: #! /usr/bin/python import telnetlib import sys newline="\n" class telnetscript: def __init__(self,host,port): try:self.telnet=telnetlib.Telnet(host,port)#creating a telnet connection object except : print "Can not connect to host" def read(self,read):# read until ?? x=self.telnet.read_until(read) print x def write(self,write):#write what?? x=self.telnet.write(write) print x def readall(self): self.telnet.read_all() objt=telnetscript("10.1.1.2","2601")#creating a object of telnetscript class x=objt.read("Password: ") objt.write("zebra"+newline) objt.read("> ") objt.write("ena"+newline) objt.read("Password: ") objt.write("zebra"+newline) objt.read("# ") objt.write("configure terminal"+newline) objt.read("# ") objt.write("interface eth0"+newline) objt.read("# ") objt.write("ip address 10.1.1.200/24"+newline) objt.read("# ") for x in range(0,2): objt.write("exit"+newline) objt.read("# ") objt.telnet.close() 68 Finalment, es pot comprovar que la configuraci´ o ha estat duta a terme correctament de forma similar a com s’ha mirat que els routers estaven desconfigurats. Figura 30: El router Juniper s’ha configurat correctament. Figura 31: El router Quagga s’ha configurat correctament. A les seg¨ uents figures, s’hi pot veure com ara els dos routers poden llanc¸ar-se un ping l’un a l’altre. 69 Figura 32: El router Quagga s’ha configurat correctament. Figura 33: El router Quagga s’ha configurat correctament. 70 7 Conclusions i treball futur 7.1 Conclusions Abans d’exposar les conclusions, ´ es convenient fer un recordatori sobre els objectius originals que s’havien plantejat en aquest projecte, que s´ on: 1. Construcci´ o d’una interf´ ıcie que s’encarregui de la comunicaci´ o entre l’usuari i el sistema. 2. Establiment de la comunicaci´ o entre la interf´ ıcie mencionada al punt 1 i el sistema que hi ha darrera. 3. Construcci´ o de les ontologies necess` aries per a aquest projecte. 4. Obtenci´ o del mapeig entre la ontologia general i les ontologies espec´ ıfiques. 5. Disseny del subsistema encarregat d’obtenir de la acci´ o a dur a terme. 6. Disseny del subsistema encarregat d’obtenir de les instruccions concretes necess` aries sabent quina ´ es la acci´ o que cal dur a terme. 7. Llanc¸ament de la configuraci´ o dels routers. Si b´ e en general aquests objectius s’han dut a terme satisfact` oriament, n’hi ha un que no s’ha pogut dur a terme de forma satisfact` oria. Concretament, la obtenci´ o de la acci´ o a dur a terme no s’ha pogut dissenyar i implementar tal com hagu´ es sigut desitjable, amb la conseq¨ u` encia d’haver d’implementar una funci´ o que retorna sempre la mateixa acci´ o per a cobrir aquesta mancanc¸a. Tot i aix` o, s’ha pogut fer una proposta sobre aquesta part, una possibilitat sobre com solucionar aquesta part del problema, de la qual se’n parla a l’ap` endix Interpretaci´ o de la acci´ o a realitzar a partir dels par` ametres d’entrada. Durant la realitzaci´ o d’aquest projecte hi ha hagut una s` erie de dificultats que han ajudat a no poder complir de forma satisfact` oria amb un dels objectius. Per comenc¸ar, hi ha hagut una falta d’expertesa pel que fa a la configuraci´ o dels routers, cosa que ha obligat a invertir una part del temps en aprendre a configurar de forma b` asica un router. Aquesta passa ha resultat ser imprescindible de cara a poder fer un disseny ´ util tant de les ontologies com de la classe que treballa directament amb elles. Tampoc no es disposava de cap tipus d’experi` encia creant i manipulant ontologies, amb la qual cosa tamb´ e s’ha hagut d’invertir temps a aprendre tant a dissenyar una ontologia com a treballar amb elles. Finalment, per diverses circumst` ancies s’ha disposat d’un temps molt just per tal d’acabar aquest PFC. Cal tenir en compte, per` o, que el motiu principal del no-enllestiment del subsistema encarregat d’obtenir de la acci´ o a dur a terme ´ es la seva dimensi´ o, prou gran com per poder cobrir un PFC a part. La resta d’objectius s’han pogut complir satisfact` oriament, i aix` o juntament amb la proposta de la part mancant, mostra que el cam´ ı seguit en aquest projecte ´ es un cam´ ı v` alid de cara a resoldre el problema ja exposat a la introducci´ o, cosa que mostra la seva idone¨ ıtat de cara a seguir explorant i desenvolupant en aquesta l´ ınia. 71 7.2 Treball futur A partir d’aquest projecte, hi ha diverses l´ ınies de treball possibles, ja siguin millores sobre aquest projecte mateix, o expansions sobre aquest. Aquestes diferents l´ ınies s´ on: 1. Fer una millora de la interf´ ıcie gr` afica per tal de permetre m´ es accions de configuraci´ o a part de crear un link IP. 2. Canviar la forma de comunicaci´ o entre la p` agina web dissenyada i la part del servlet: En comptes de que el servlet llegeixi els par` ametres d’entrada, pot ser interessant que des de la p` agina web es crei un arxiu en format xml contenint els par` ametres d’entrada, i que des del servlet es llegeixi aquest arxiu. 3. Implementar la part del sistema encarregada d’intrepretar la acci´ o a realitzar a partir dels par` ametres d’entrada donats per l’usuari. 4. Implementar un m` odul que permeti a partir de qualsevol tipus de format d’entrada, convertir aquest format en xml. 5. Trobar una manera de construir les ontologies contenint les instruccions espec´ ıfiques de cada router de forma autom` atica o semi-autom` atica. La majoria d’aquestes millores, formen part d’alguna de les parts que s’han quedat fora d’aquest projecte, i es poden veure reflexades en la seg¨ uent figura. Figura 34 72 7.2.1 Millora de la interf´ ıcie gr` afica Si b´ e a causa de les limitacions d’aquest projecte, des d’aquest ´ es tan sols perm` es crear un link IP entre dos routers, les estructures de les ontologies i de la classe routerOntologyManager estan preparades per a donar suport a altres accions de configuraci´ o. Per aix` o resultaria interessant una interf´ ıcie que permet´ es introduir, a part de les dades que ja es permeten, altres dades necess` aries per a configurar algun altre aspecte del router. Aquesta millora podria passar des d’introduir m´ es camps a la p` agina web ja feta, fins dissenyar una interf´ ıcie a l’estil a la figura exemple, o fins i tot hi cap la possibilitat de llegir les entrades via un micr` ofon, ´ es a dir, que l’usuari dicti el que vol que es faci. Figura 35: Exemple de com podria ser la interf´ ıcie futura, un com redissenyada. 7.2.2 Millora de la comunicaci´ o interf´ ıcie-servlet En aquest projecte, el servlet llegeix els par` ametres d’entrada introdu¨ ıts per l’usuari. Si b´ e aquest m` etode de comunicaci´ o´ es molt senzill, tamb´ e t´ e l’inconvenient que ´ es molt r´ ıgid respecte els par` ametres que es permeten introduir. A causa de la naturalesa del projecte, sembla convenient trobar una manera m´ es el` astica d’obtenir els par` ametres d’entrada, una manera que impliqui no estar lligat a haver de llegir una s` erie de par` ametres fixos. Cal tenir en compte que no sempre es necessitaran els mateixos par` ametres, ni la mateixa quantitat d’aquests, i aix` o fa que sigui especialment important poder gaudir d’aquesta elasticitat. Una possibilitat seria utilitzar un arxiu en format xml. A partir d’aquest arxiu es pot cobrir aquesta necessitat, ja que un arxiu xml no requereix de cap mida concreta, s’hi poden guardar par` ametres diferents segons convingui, i existeixen eines de tractament de format xml. Aix´ ı, doncs, caldria de cara a un desenvolupament futur trobar la forma m´ es convenient sobre com estructurar exactament aquest arxiu. Aquesta millora tindria com a conseq¨ u` encia un increment en la facilitat i la elasticitat de fer la seg¨ uent millora que ara es comentar` a. 73 Ap` endix - Vocabulari i acr` onims En aquest cap´ ıtol es presenta tant un aclariment sobre el vocabulari utilitzat en aquest projecte com una llista d’acr` onims utilitzats. Vocabulari Acci´ oConfiguraci´ o en termes generals que es vol dur a terme, com per exemple Assignar una IP al Router R. CapEx Despeses de capital. Inversions de capital que creen beneficis OpEx. Cron Programa que permet a un usuari la execuci´ o de comandes o scripts autom` aticament de forma peri` odica, o en una hora o data determinades. [6] Datatype property Propietat pertanyent a un objecte o individual d’una ontologia. Individual Objecte concret pertanyent a una ontologia. Instrucci´ oEs refereix tant a una comanda com a un tros de codi en format xml necessari per dur a terme una acci´ o. Juniper En aquest projecte s’anomena juniper als routers fabricats per la casa Juniper Networks. Mapeig ontol` ogic Anomenat ontologic mapping en angl` es, es refereix a la declaraci´ o d’elements equivalents entre diferents ontologies. Object property Dins d’una ontologia, relaci´ o entre dues classes. OpenNMS Plataforma de gesti´ o de xarxes open source, desenvolupada a nivell empresarial. Operaci´ o cross-layer Operaci´ o que afecta a m´ es d’una capa del model OSI. OpEx Despesa conseq¨ uent de dur a terme un negoci, o del llanc¸ament d’un producte. OWL Tamb´ e conegut com a Web Ontology Language OWL,´ es un llenguatge de marcat sem` antic per publicar i compartir ontologies a trav´ es d’internet. Tamb´ e representa una extensi´ o de vocabulari de RDF. [4] Quagga Suite de software lliure de routing desenvolupada per a plataformes Unix. [20] RDF Model est` andard que permet l’intercanvi de dades a trav´ es d’internet. Aquest model est` a basat en l’xml. [21] Servlet Eina que permet executar un programa escrit en java des d’una p` agina web. Usuari S’anomena usuari a qualsevol persona que interactui amb el sistema aqu´ ı dissenyat i implementat. 80 Acr` onims AAA Authentication, Authorization and Accounting. API Application Programming Interface. CapEx Capital Expenditure. CLI Command Line Interface. EMS Element management system. IP Internet Protocol. NETCONF Network Configuration Protocol. NMS Network Management System. MTOSI Multi-Technology Operations System Interface. OpEx Operating Expenditure. PCE Process Control Engineering. R+D Recerca i Desenvolupament. RDF Resource Description Framework. SNMP Simple Network Management Protocol. SMS Service Management System. UMLS Unified Medical Language System WDM Wavelength-division multiplexing. XML Extensible Markup Language 81 82 Refer` encies [1] ADVA Optical Networking, FSP Network Manager and FSP Service Manager, http://www.advaoptical.com/. [2] Apache Software Foundation, “Apache Tomcat”, http://tomcat.apache.org/, 2011. [3] A.R. Aronson, “MetaMap: Mapping Text to the UMLS Metathesaurus”, http://skr.nlm.nih.gov/papers/references/metamap06.pdf, July 2006. [4] S. Bechhofer, F. van Harmelen, J. Hendler, I. Horrocks, D.L. McGuinness, P.F. Patel-Schneider, L.A. Stein, “OWL Web Ontology Language”, http://www.w3.org/TR/owl-ref/, November 2009. [5] M. Chamania, A. Jukan, O. Gonzales de Dios, J. Jimenez Chico, ”Offloading Excess IP Traffic with Optical Bypass - A Simple Capacity Upgrade, or More?,”ONTC PRISM Newsletter, vol. 1, no. 3, Aug. 2010. [6] cogNiTioN, “Newbie: Intro to cron”, http://www.unixgeeks.org/security/newbie/unix/cron1.html, December 1999. [7] J. Davis, R. Studer, and P. Warren, “Semantic Web Technologies”, WILEY, 2006. [8] M. Ehrig and Y. Sure, “FOAM - A Framework for Ontology Alignment and Mapping”, Demo at ISWC2005, http://www.bibsonomy.org/bibtex/23e7351df47bfd33e21d688e1f50bb512/asalber, November 2005. [9] R. Enns, “NETCONF Configuration Protocol,” IETF RFC 4741, December 2006. [10] T.Gruber, “Toward Principles for the Design of Ontologies User for Knowledge Sharing”, International Journal Human-Computer Studies, Vol. 43, pp 907-928, http://tomgruber.org/writing/onto-design.htm, November 1995. [11] H. Knublauch and Protege staff members, “Protege-OWL API Programmer’s Guide”, http://protegewiki.stanford.edu/wiki/ProtegeOWL API Programmers Guide, June 2010. [12] S. Kaza and H. Chen, “Evaluating ontology mapping techniques: An experiment in public safety information sharing,” Decision Support Systems, Elsevier, Vol. 45, no. 4, pp. 714–728, 2008. [13] E. Mannie, “Generalized Multi-Protocol Label Switching (GMPLS) Architecture,” IETF RFC 3945, October 2004. [14] “Metadata discovery”, http://en.wikipedia.org/wiki/Metadata discovery, 2011. [15] Multi-Technology Operations System Interface (MTOSI), release 2.0, TeleManagement Forum, http://www.tmforum.org. [16] “ONE Project”, http://www.ict-one.eu/. [17] Oracle, “Java Servlet Technology”, http://www.oracle.com/technetwork/java/javaee/servlet/index.html, 2011. 83 [18] Oracle, “Runtime (Java 2 Platform SE v1.4.2)”, http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Runtime.html, 2010. [19] OTN ITU-T Recommendations on ASTN/ASON Control Plane, http:// www.itu.int/ITU-T/. [20] “Quagga Routing Suite”, Demo at ISWC2005, http://www.quagga.net/about.php, December 2009. [21] RDF Working Group, “RDF - Semantic Web Standards”, http://www.w3.org/RDF/, February 2004. [22] RDF Working Group, “The Prot´ eg´ e Ontology Editor and Knowledge Acquisition System”, http://protege.standford.edu/, 2011. [23] “Reducing complexity and minimizing mistakes in network configuration,” IBM Tivoli Netcool Configuration Manager, White paper, September 2010. [24] Stanford University, “Prot´ eg´ e-OWL 3.4.6”, http://protege.stanford.edu/protege/3.4/docs/api/owl/, 2011. [25] M. Subramanian, T. A. Gonsalves, and N. U. Rani, “Network Management: Principles and Practice,” Pearson, 2010. [26] “The OpenNMS Project”, Demo at ISWC2005, http://www.opennms.org/, 2011. [27] “UMLS Reference Manual”, U.S. National Library of Medicine, http://www.ncbi.nlm.nih.gov/books/NBK9684, 2009. [28] U.S. National Library of Medicine, “UMLS Quick Start Guide”, http://www.nlm.nih.gov/research/umls/quickstart.html, April 2011. [29] P. Vixie, “CRON”, Manual que es pot trobar sota linux. Per a consultar-lo, obrir una terminal i escriure ”man cron”, April 2010. [30] A. K. Y. Wong, P. Ray, N. Parameswaran, and J. Strassner, “Ontology Mapping for the Interoperability Problem in Network Management,” IEEE Journal on Selected Areas in Communications, Vol. 23, no. 10, pp. 2058–2068, October 2005. 84