C. Inference Method
1. Simulation on Artificial Networks
Un requerimiento importante que ten´ıa el presente proyecto era el de lograr
resolver el mapeo de tr´afico en los t´uneles. Como se coment´o en la secci´on 3.4
las opciones para configurar dichas FECs son limitadas. Es por ello que para este objetivo tambi´en se debi´o recurrir a la opci´on de modificar el archivo de configuraci´on de los equipos.
Para poder realizar el mapeo de tr´afico a t´uneles se agreg´o a la plantilla XML
utilizada por este m´odulo informaci´on sobre FECs. La misma est´a incluida en el pedido de alta de caminos y en el pedido de cambio de atributos, pudiendo en este ´
ultimo caso indicarse que se agregue o elimine una FEC a un LSP. En ambos casos se utiliza un mismo tipo definido para estos fines, el que se puede ver en la figura 9.4. Este tipo coincide con el definido en el modelo de informaci´on explicado en el cap´ıtulo 9.
En la secci´on 3.4.2 se coment´o la manera de configurar la FEC en los nodos, advirti´endose que los equipos en general no manejan el concepto de FEC y que si bien es posible realizar una configuraci´on que contemple las distintas variables que incluye una FEC mediante filtros, estos son complicados. Es por ello que se decidi´o que
la soluci´on implementada soportara ´unicamente la configuraci´on de FECs definidas
como red de destino. Igualmente en la plantilla XML utilizada se incluy´o el concepto amplio de FEC, de manera de prever su futura utilizaci´on, por ejemplo cuando los equipos soporten la MPLS-FTN-MIB.
Adem´as de configurarse las FECs indicadas espec´ıficamente en el XML enviado
en el pedido de se˜nalizaci´on o en el pedido de cambio de atributos, este m´odulo
configura en el nodo ingreso una ruta est´atica al destino del t´unel. Este mapeo de
tr´afico se realiza previendo que el administrador desee configurar en los equipos
alguna opci´on de inclusi´on de los t´uneles MPLS en el c´alculo de rutas de IGP. Por
ejemplo, la opci´on autoroute de los equipos CISCO, cuyo detalle de funcionamiento puede verse en [18].
8.3.
Conclusiones
Se present´o la implementaci´on del m´odulo de se˜nalizaci´on. La misma consisti´o en
la adaptaci´on de una herramienta ya existente que permite dar de alta y de baja t´uneles, adem´as de realizar cambios en la configuraci´on y asociar tr´afico a los mismos. La soluci´on lograda funciona actualmente como un Element Manager que im-
plementa los comandos propietarios correspondientes a los t´uneles de Ingenier´ıa de
de mantener la misma arquitectura para otros fabricantes debiendo desarrollar un manejador para cada uno. Esto est´a previsto en el modelo de informaci´on descrito en el cap´ıtulo 9, mediante la inclusi´on del campo Element Manager en el que se puede especificar uno para cada nodo.
Si se permitiera en un futuro la escritura de las MIBs de MPLS por parte de los fabricantes, ser´ıa deseable desarrollar una aplicaci´on que funcionara por SNMP.
Sobresale como aporte importante el hecho de haber incluido en el M´odulo Se˜nali-
zaci´on la responsabilidad de realizar el mapeo de tr´afico, tarea que no estaba expl´ıci-
tamente asignada a ning´un m´odulo en la arquitectura tomada como base. Adem´as
de asignarse dicha responsabilidad al m´odulo, se implement´o y prob´o una soluci´on que maneja una noci´on de FEC simplificada, dadas las limitaciones mencionadas. No obstante, tambi´en est´a previsto en el modelo de informaci´on propuesto el manejo de FECs complejas que involucren varios par´ametros.
Contar con la implementaci´on de este m´odulo perfectamente adaptado a la he- rramienta se considera un gran aporte, ya que no s´olo es fundamental para realizar Ingenier´ıa de Tr´afico, sino que tambi´en es de gran utilidad para la gesti´on de una red MPLS. Con esto se logra adem´as, cumplir uno de los trabajos a futuro plan-
teados por el proyecto Net-TE: integrar a la herramienta gr´afica la se˜nalizaci´on de
los caminos que resultan de la actuaci´on de los algoritmos de Ingenier´ıa de Tr´afico fuera de l´ınea.
El el cap´ıtulo 12 se presentan las pruebas realizadas en la maqueta para la validaci´on de este m´odulo.
Cap´ıtulo 9
Almacenamiento e Intercambio de
Informaci´on
En este cap´ıtulo se presenta la soluci´on implementada para el almacenamiento de la informaci´on en la arquitectura y el intercambio de la misma entre los distintos m´odulos que la componen.
9.1.
Introducci´on
Debido a la arquitectura modular de la aplicaci´on surge la necesidad de transmitir informaci´on entre los distintos m´odulos. Adem´as es necesario que dicha informaci´on persista de manera que pueda ser consultada posteriormente.
La soluci´on presentada en la arquitectura RMA es tener una base de datos cen- tralizada y utilizar el protocolo GRMAP, propio de dicha arquitectura, para la comu- nicaci´on entre los m´odulos. Sin embargo, no se especifica qu´e informaci´on almacenar ni de qu´e manera, por lo que se debi´o adoptar un modelo de informaci´on para re- presentar la red.
En las siguientes secciones se presentan: Modelo de informaci´on
Base de datos Protocolo GRMAP