Searching the optimal sequence of system states using a

Una posible l´ınea de trabajo a seguir continuando este proyecto ser´ıa implementar el reparto de carga en capa 3, es decir modificar el parche mpls-linux de forma de repartir la carga de manera real y no simularlo en capa de aplicaci´on como se realiz´o en este trabajo. De esta manera se podr´ıa probar el algoritmo con tr´afico real y no simulado por

un generador de tr´afico. Adem´as en el reparto de carga en capa de red se puede realizar diferenciaci´on de flujos y realizar el reparto por flujos. De todas formas nuestras pruebas no se ven afectadas por el hecho de hacer el reparto de carga en capa de aplicaci´on ya que el tiempo de procesamiento de cada paquete desde capa 3 a capa 5 y viceversa es despreciable con respecto a los retardos en las colas y los retardos de propagaci´on.

Otra posible l´ınea de trabajo es la b´usqueda de una nueva funci´on costo m´as general que la elegida que nos permita eliminar la hip´otesis de que las colas son M/M/1. Otra posibilidad es elegir o dise˜nar una funci´on costo que optimice la red en otro aspecto diferente, por ejemplo privilegiar algunos enlaces de forma de poder ofrecer servicios diferenciados. Es evidente que hay un sin fin de otras posibilidades.

Un problema que no est´a resuelto en nuestro trabajo de manera robusta, es c´omo obtener la informaci´on del retardo unilateral de cada enlace de manera exacta en una red as´ıncrona. El hecho de medir los retardos de ida y vuelta con paquetes de eco hace que no podamos diferenciar un caso en que el retardo de ida sea peque˜no y el de vuelta grande del caso en que el retardo de ida sea grande y el de vuelta sea peque˜no. Asimetr´ıas grandes en estos valores pueden afectar la performance del algoritmo. Una posible soluci´on a ´esto ser´ıa que cada enrutador midiera el tama˜no de sus colas que es donde se produce el mayor retardo en un camino y en funci´on de ello estimara el retardo unilateral de sus enlaces y enviara esta informaci´on a los LERs de ingreso. Esta soluci´on tiene el problema de que se debe implementar un protocolo de comunicaci´on entre los enrutadores agregandole una complejidad significativa a los enrutadores intermedios de la red.

Un hecho a tener en cuenta es que el algoritmo por si s´olo no asegura ningun par´ametro de calidad de servicio, lo que si asegura es que dado un tr´afico espec´ıfico minimiza la funci´on costo elegida la forma de poder ofrecer una cierta calidad de servicio es acompa˜nar el algoritmo con alg´un cr´ıterio de control de los paquetes que ingresan a la red. Nosotros creemos que con el uso de estas dos herramientas se puede lograr una correcta performance de la red.

[1] Primer entregable de este Proyecto. Estado del arte en MPLS

[2] IEEE INFOCOM 2001 pag. 1300 MATE: MPLS Adaptative Traffic Engineering [3] James A. Bucklew Large Deviation Techniques in Decision, Simulation, and Estima-

tion.

[4] Nortel Networks, Using Constraint based routing to deliver new services. [5] AviciT M _{System Inc, Traffic Engieneering with MPLS.}

[6] Mentor Technologies, Introduction to MPLS. [7] Trillium, Multiprotocol Label Switching (MPLS). [8] Andrew S. Tanenbaum, Computer Networks.

[9] The Linux Documentation Project, www.tld.org Gu´ıa de administraci´on de redes Linux.

[10] The Linux Documentation Project, www.tld.org Kernel HOWTO. [11] The Linux Documentation Project, www.tld.org Linux kernel.

[12] The Linux Documentation Project, www.tld.org Linux: Instalaci´on y primeros pa- sos.

[13] Brian W. Kernighan, Dennis M. Ritchie, Prentice Hall. El lenguaje de programaci´on C.

[14] Eric Osborne, Ajay Simlia, Cisco Press. Traffic Engineering with MPLS. [15] W. Richard Stevens, Prentice Hall. UNIX Network Programming.

[RFC-2702] D.Awduche,J.Malcolm,J.Agogbua,M.O’Dell,J.McManus. , Requirements for Traffic Engineering Over MPLS,

[RFC-3031] E. Rosen, Cisco Systems Inc., A. Viswanathan, Force10 Networks Inc., R. Callon Juniper Networks Inc., January 2001. Multiprotocol Label Switching Architec- ture

[RFC-3036] L. Andersson, Nortel Networks Inc., P. Doolan, Ennovate Networks, N. Feld- man, IBM Corp, A. Fredette, PhotonEx Corp, B. Thomas, Cisco Systems Inc., Jan- uary 2001. LDP Specification

[RFC-3037] B. Thomas, Cisco Systems Inc., E. Gray, Zaffire Inc., January 2001. LDP Applicability

[RFC-3209] D. Awduche, Movaz Networks Inc., L. Berger, D. Gan, Juniper Networks Inc., T. Li, Procket Networks Inc., V. Srinivasan, Cosine Communications Inc., G. Swallow, Cisco Systems Inc., December 2001. , RSVP-TE: Extensions to RSVP for LSP Tunnels,

[RFC-3212] B. Jamoussi, Editor, Nortel Networks, L. Andersson, Utfors AB, R. Callon, Juniper Networks, R. Dantu, Netrake Corporation, L. Wu, Cisco Systems, P. Doolan, OTB Consulting Corp., T. Worster, N. Feldman, IBM Corp., A. Fredette, ANF Con- sulting, M. Girish, Atoga Systems, E. Gray, Sandburst, J. Heinanen, Song Networks, Inc., T. Kilty, Newbridge Networks, Inc., A. Malis, Vivace Networks, January 2002. Constraint-Based LSP Setup using LDP

[RFC-3213] J. Ash, AT&T, M. Girish, Atoga Systems, E. Gray, Sandburst, B. Jamoussi, G. Wright, Nortel Networks Corp., January 2002. Applicability Statement for CR- LDP

Manual de usuario: Software

mated

A continuaci´on se detalla el modo de uso del software mated, c´omo instalarlo, los par´ametros a configurar en las diferentes versiones del algoritmo, c´omo configurarlos y los datos que se obtienen en una simulaci´on.

A.1.

Instalaci´on

La instalaci´on del software es muy sencilla, simplemente se siguen los siguientes pasos: 1. Descomprimir el archivo mate.tar.gz :

tar -zxvf mate.tar.gz

Al descomprimir el archivo quedar´a creado el directorio mate. 2. Entrar al directorio mate:

cd mate 3. Compilar:

make

Una vez realizados estos pasos quedar´an creados los siguientes archivos ejecutables en el directorio mate:

repartidor. Simulador de reparto de carga.

mated1. Demonio MATE versi´on 1: γ fijo, intervalo entre actualizaciones fijo. mated2. Demonio MATE versi´on 2: γ adaptativo, intervalo entre actualiza- ciones fijo.

mated3. Demonio MATE versi´on 3: γ adaptativo, intervalo entre actualiza- ciones adaptativo.

4. Opcionalmente se puede agregar la ruta donde est´an los ejecutables anteriormente mencionados a la variable PATH, de modo de poder ejecutarlos desde cualquier directorio. De lo contrario se debe ejecutarlos desde el directorio en donde est´an ubicados. Esto se puede hacer de las siguientes maneras:

Temporalmente, escribir la sentencia: PATH=$PATH:ruta/mate/

donde ruta es la ruta al directorio donde se descomprimieron los archivos. Esta configuraci´on se pierde al apagar el sistema.

Permanentemente, se puede agregar la ruta a la inicializaci´on de la variable PATH en:

• /root/.bash profile, en caso de ser el administrador del sistema (root). • /usr/nombre usuario/.profile, en caso de ser el usuario nombre usuario.