Ingeniería de tráfico en tiempo real sobre MPLS. Implementación en un ambiente Linux.

Transcripción

1 Ingeniería de tráfico en tiempo real sobre MPLS. Implementación en un ambiente Linux. Miguel Griot Gayoso Santiago Remersaro Romaniello Gabriel Tucci Scuadroni Orientador: Ing. Pablo Belzarena 15 de mayo de 2003 Proyecto de fin de carrera. Facultad de Ingeniería Universidad de la República Montevideo - Uruguay.

2 Índice general I Documento principal 1. Introducción Motivación Objetivos del proyecto Descripción de lo realizado Introducción a MPLS 4 3. Ingeniería de tráfico en MPLS Motivación Un ejemplo: IP vs. ATM vs. MPLS Reparto de carga por varios LSPs hacia un mismo destino MPLS Adaptive Traffic Engineering - MATE Introducción Características básicas Algoritmo MATE Modelo Algoritmo asíncrono Ejemplo de una función costo Implementación teórica Elección de la función costo Proyección Reparto de Carga Mejoras al algoritmo cuando el tráfico no es constante Trabajamos con porcentajes y no tasas γ adaptativo Intervalo adaptativo entre actualizaciones Implementación del algoritmo MATE en la práctica Implementación Características generales de la implementación Características básicas de cada proceso i

3 Índice general II Proceso repartidor Proceso mated Medición de retardos Medición de un retardo de ida y vuelta Estructura par y memoria compartida Análisis de los datos asociados a un par de egreso Estructuras par, path lsp y nodo Memoria Compartida Funcionamiento de los procesos repartidor y mated repartidor mated mated Performance del algoritmo en diferentes escenarios γ adaptativo vs. γ fijo: Prueba en VMWare Resultados obtenidos: γ adaptativo vs. γ fijo: prueba en el Laboratorio de Software Resultados obtenidos en esta prueba Evaluación del intervalo adaptativo entre actualizaciones Resultados obtenidos: Repuesta al escalón Evaluación global de mated Etapa Etapa Conclusiones finales Resumen de lo realizado Características generales del algoritmo MATE Mejoras al algoritmo original Trabajos a futuro II Anexos A. Manual de usuario: Software mated 1 A.1. Instalación A.2. Modo de uso A.3. Archivos de configuración A.3.1. repartidor A.3.2. mated A.3.3. mated A.3.4. mated

4 Índice general III B. Programación de Sockets 7 B.1. Qué es un socket? B.2. Direcciones IP, cómo tratarlas? B.3. Sockets de Internet B.3.1. Dos tipos de sockets de internet B.4. Modelo cliente-servidor B.4.1. Un servidor sencillo B.4.2. Un cliente sencillo B.4.3. Sockets de datagramas C. Memoria compartida y semáforos 18 C.1. Conceptos fundamentales C.1.1. Identificadores IPC C.1.2. Claves IPC C.2. Semáforos C.2.1. Conceptos Básicos C.2.2. Estructuras de datos internas C.2.3. semtool: Manipulador interactivo de semáforos C.3. Memoria Compartida C.3.1. Conceptos Básicos C.3.2. Estructuras de Datos Internas y de Usuario C.3.3. shmtool: Manipulador de segmentos de memoria compartida D. Herramientas de software utilizadas en el Proyecto 51 D.1. Parche MPLS-LINUX D.1.1. Instalación de mpls-linux D.1.2. Compilación de mplsadm D.1.3. Instalación de ldp-portable D.1.4. Parche a iproute D.1.5. Parche a pppd D.2. Modo de uso de mplsadm D.2.1. Ejemplo de configuración de una red MPLS D.3. Generador de tráfico MGEN D.4. VMware Workstation

5 Índice de figuras 2.1. Intercambio de etiquetas Shim Header Etiqueta Label merging Túnel Caminos ATM MPLS Red MPLS Función de los nodos de ingreso Función retardo Reparto de carga con dos LSPs Reparto de carga con dos LSPs Reparto de carga con tres LSPs LSPs entre dos LERs Proyección utilizando tasas Proyección utilizando porcentajes Gráfica de f(z) Intervalos Gráfico de at ψ(t) Gráfico de g ξ Gráfico de g ξ Gráfico de at ψ(t) Retardo no estático en un intervalo de actualización Diagrama básico de los procesos Una vuelta de mediciones Retardo de un enlace Diagrama de flujo de los programas Diagrama de flujo de los programas Tráfico creciente iv

6 Índice de figuras V 7.1. Topología de prueba Limitación de los retardos Topología de prueba Topología real en el laboratorio Topología de prueba Tráfico entrante al par Tráfico entrante al par: prueba Valor de dt: prueba Valores de k 0 y de k: prueba Tráfico entrante al par: prueba Valor de dt: prueba Valores de k 0 y de k: prueba Tráfico entrante al par: prueba Valor de dt: prueba Valores de k 0 y de k: prueba Tráfico entrante al par: prueba Valor de dt: prueba Valores de k 0 y de k: prueba Tráfico entrante al par Gráfica de τ Topología de la red de prueba Tráfico entrante por los LERs de ingreso 1 (rojo) y 2 (azul) Evolución del tamaño de intervalo entre actualizaciones Evolución de k 0 (azul) y k (verde) Mediciones efectivamente realizadas Porcentajes enviados por el LSP 1.1 (azul) y LSP 1.2 (verde) RTT medio por los LSP 1.1 (azul) y LSP 1.2 (verde) Varianza de los RTT de los LSP 1.1 (azul) y LSP 1.2 (verde) D.1. Red MPLS

7 Agradecimientos Agradecemos a nuestro tutor de Proyecto el Ing. Pablo Belzarena por haber confiado a nuestro grupo la realización del presente Proyecto y por su ayuda a lo largo de éste. Queremos destacar además la ayuda brindada por el Ing. Eduardo Cota y el Ing. Gabriel Gómez que nos guiaron en varias etapas de aprendizaje a lo largo del mismo. Agradecemos también a Rafael Grompone y al Ing. Ignacio Ramírez por sus aportes. vi

8 Abstract En este proyecto se instaló en la red de computadoras del Laboratorio de Desarrollo de Software del Insitituto de Ingeniería Eléctrica de la Facultad de Ingeniería una versión del sistema operativo Linux modificada que agrega a su stack de protocolos de red la capa MPLS. Para ello se utilizó el paquete mpls-linux brindado por Source Forge. Posteriormente se implementó el algortimo MATE de reparto de carga y se estudió su performance. Dicha implementación fue programada en C para el sistema operativo Linux. Se encontraron varias debilidades en el algoritmo original, algunas de las cuales fueron predichas teóricamente y otras surgieron a la hora de la implementación práctica. Se planteron soluciones para superar estos problemas y luego se implementaron dos versiones mejoradas de este algoritmo las cuales fueron probadas y comparadas entre sí. La primera de las versiones tiene la variante de que el paso entre las actualizaciones no es fijo, sino que se adapta a las caracteristicas del tráfico entrante permitiendo así que el algoritmo MATE pensado inicialmente para trabajar con tráfico constante lo pueda hacer cuando el tráfico varía con el tiempo. La segunda versión, además de tener el paso adaptativo entre las actualizaciones, utiliza un tamaño de intervalo entre actualizaciones variable que se adecúa a las variaciones en el tráfico. Esta versión calcula además, en función de las caracteristicas del tráfico, cuántas mediciones se deben realizar de manera que la estadística tomada del tráfico mediante paquetes de prueba pueda ser considerada confiable. vii

9 Parte I Documento principal

10 Capítulo 1 Introducción 1.1. Motivación El proyecto es generado debido a la creciente demanda de utilización de Internet para aplicaciones en tiempo real tales como teleconferencias, juegos on-line, telefonía, etc., siendo necesario para esto lograr satisfacer requerimientos de retardo, probabilidad de pérdida y ancho de banda. Existe también un gran interés en poder realizar servicios diferenciados, donde aquél que quiera una mayor calidad de servicio pueda contratar el servicio que desea y tener prioridad sobre aquel que no lo contrate. En este marco surge una nueva tecnología, que está siendo estudiada y discutida, llamada MPLS (Multiprotocol Label Switching). Esta tecnología propone el agregado de una etiqueta en cada paquete (ubicada entre los encabezados de las capas de enlace y de red), de modo de permitir con el adecuado uso de ésta realizar Ingeniería de Tráfico en una red de computadoras, en particular en Internet, y poder controlar los parámetros de calidad de servicio antes mencionados. De este modo surge el interés de tener en el Instituto de Ingeniería Eléctrica (IIE) de la Facultad de Ingeniería una red de computadoras que funcionen como enrutadores MPLS que permita probar diferentes algoritmos de ruteo sobre este protocolo en diferentes topologías y diferentes tipos de tráfico y evaluar su performance. El proyecto consiste en implementar una red de enrutadores MPLS en el Laboratorio de Software del IIE, utilizando para ello un software distribuido por Source Forge, que hace que un PC funcione como un enrutador MPLS. Este software a utilizar proviene del proyecto MPLS for Linux que implementa un stack MPLS para el núcleo (kernel) de Linux 2.4.x, el cual consiste en una plataforma de reenvío de paquetes y una implementación del protocolo de distribución de etiquetas (LDP) estandarizado en el RFC MPLS for Linux es distribuido por Source Forge y está compuesto por dos paquetes, mpls-linux y ldp-portable, disponibles en la página web Por otro lado, se estudió y analizó el algoritmo MATE de reparto de carga, el cual es un algoritmo desarrollado en conjunto por Bell Labs Lucent Technologies, el departamento de Ingeniería Eléctrica de la Universidad de Michigan Ann Arbor, el departamento de 1

11 Capítulo 1. Introducción 2 Ingeniería Eléctrica de Caltech, y por Fujitsu Network Communications Pearl River; el estudio de éste surge de la necesidad de realizar reparto de carga en una red de computadoras en tiempo real, y MATE es uno de los primeros algoritmos prometedores en este tema. Posteriormente se implementaron varias versiones de este algoritmo comparando su performance. Se encontraron debilidades al algoritmo original al llevarlo a la práctica y se introdujeron cambios en éste de forma de superar estas debilidades Objetivos del proyecto 1. Conocer el estado del arte del protocolo MPLS. 2. Estudiar y familiarizarse con el software mpls-linux. 3. Crear una red de PC s que simule una red de enrutadores MPLS en el Laboratorio de Desarrollo de Software del IIE. 4. Concluir acerca del funcionamiento de MPLS, así como intentar obtener conclusiones generales acerca de su funcionamiento y potencialidad para realizar ingeniería de tráfico sobre éste. 5. Estudiar y analizar del algoritmo MATE de reparto de carga. 6. Implementar este algoritmo y testearlo en diferentes topologías y con diferentes tipos de tráfico, para descubrir sus debilidades. 7. Buscar mejoras al algoritmo de forma de superar las debilidades encontradas. 8. Analizar el algoritmo mejorado en diferentes topologías y con diferentes tipos de tráfico Descripción de lo realizado El proyecto comenzó con un estudio en profundidad del protocolo MPLS así como un análisis y comparación de este protocolo frente a otros. El análisis de este estudio dio lugar a una monografía que se puede leer en [1]. Posteriormente se estudió el funcionamiento del software VMWare, el cual nos permitió que en un PC se crearan varias máquinas virtuales y se las pudieran conectar en red simulando una red real de computadoras. A cada una de estas máquinas virtuales se les instaló el sistema operativo Linux con núcleo , y luego se modificó este núcleo con el parche mpls-linux distribuido por Source Forge para hacer que estas máquinas utilizaran el protocolo MPLS para el envío de paquetes. Luego, se instaló y se estudió el funcionamiento del software mplsadm que nos permite crear los diferentes LSPs de forma estática, y se instaló el paquete ldp-portable que es un parche al software zebra que permite crear caminos dinamicamente utilizando el protocolo LDP.

12 Capítulo 1. Introducción 3 Una vez hecho esto, teníamos seis máquinas virtuales con sistema operativo Linux trabajando como enrutadores MPLS a las cuales les hicimos diferentes pruebas para analizar si el software instalado estaba funcionando de la forma esperada. Después de observar que el software estaba funcionado correctamente nos dedicamos a estudiar y analizar en profundidad el algoritmo MATE de reparto de carga; luego de entender el funcionamiento de este algoritmo el cual es presentado de forma totalmente teórica, lo implementamos en la práctica en una red real para poder observar su funcionamiento y obtener conclusiones acerca de su performance así como analizar sus debilidades. Para esto, hicimos varias pruebas con diferentes tipos de tráfico (tráfico constante, Poisson y tipo Burst) y pruebas con diferentes topologías de la red dentro del entorno de VMWare. Posteriormente, se armó una red MPLS de computadoras en el Laboratorio de Desarrollo de Software del IIE donde también se probó el algoritmo en su versión original. En las pruebas realizadas del algoritmo MATE tanto en topologías de red creadas en VMWare como en el Laboratorio de Desarrollo de Software encontramos que el algoritmo tenía graves problemas de convergencia cuando el tráfico era variable y cuando la utilización de los enlaces era cercana al 100 %. Luego de un estudio minucioso de las pruebas realizadas y de re-estudiar el algoritmo original encontramos dónde estaban sus falencias y propusimos diversas maneras de solucionar estos problemas, de donde surgieron diferentes versiones mejoradas por nosotros del algoritmo MATE original. Las distintas mejoras que le encontramos al algoritmo tuvieron una etapa de análisis donde se estudiaron y propusieron diferentes formas de solucionar los problemas planteados; una vez propuestas estas soluciones se programaron las nuevas versiones del algoritmo que fueron posteriormente probadas y comparadas entre sí.

13 Capítulo 2 Introducción a MPLS MPLS significa Multiprotocol Label Switching. Multiprotocol porque puede ser utilizado con cualquier protocolo de capa de red y de capa de enlace y Label Switching porque los enrutadores cambian etiquetas a los paquetes en función de la ruta que este debe recorrer. MPLS es un protocolo orientado a conexión no confiable, orientado a conexión significa que antes de empezar a enviarse la información se traza el o los caminos por los cuales serán enviados los paquetes y no confiable porque no se envía confirmación acerca de la llegada de los paquetes. En MPLS la transmisión de datos ocurre a lo largo de circuitos virtuales llamados LSPs (Label Switched Paths). Estos circuitos virtuales constan de una serie de etiquetas impuestas a los paquetes de información que los diversos enrutadores van intercambiando a lo largo del LSP. Las etiquetas utilizadas en el o los caminos a seguir son elegidas utilizando protocolos de distribución de etiquetas dinámicos como LDP (Label Distribution Protocol), CR-LDP, RSVP (Resource Reservation Protocol) o pueden ser configuradas explícitamente. Los nodos que intervienen en un LSP se pueden clasificar como LERs (Label Edge Routers) y LSRs (Label Switching Routers). Los LERs son el primer enrutador donde los paquetes de información ingresan al LSP y se les coloca una etiqueta y el último enrutador donde los paquetes emergen del LSP y se les extrae una etiqueta; estos también son llamados LER de ingreso y de egreso. Los LSRs son los enrutadores intermedios encargados de intercambiar las etiquetas de los paquetes y reenviar los paquetes a lo largo del LSP. Además, dados dos enrutadores pertenecientes a un mismo LSP se denomina enrutador upstream a aquel que se encuentra más cercano al ingreso y enrutador downstream a aquel que esta más lejos del ingreso. En la figura 2.1 se halla una ilustración de estos conceptos. La clase de equivalencia de reenvío o FEC es la representación de un grupo de paquetes que comparten los mismos requerimientos de reenvío. El concepto de FEC es local a cada enrutador, cuando un grupo de paquetes en un nodo comparten la subred de destino (prefijo de dirección de destino común) y requerimientos de servicio, pertenecen a la misma FEC. Cada FEC se mapea en un LSP o en un conjunto de ellos si se utiliza enrutamiento multi-camino. Aquí se asigna una etiqueta por cada LSP posible de la 4

14 Capítulo 2. Introducción a MPLS 5 LER 1 LSR LER 2 Label #1 Label #2 Paquete IP INGRESO MPLS + IP MPLS + IP Paquete IP EGRESO Figura 2.1: Intercambio de etiquetas FEC. Por lo tanto la etiqueta definirá el camino que seguirán los datos a través de la red. Una etiqueta es un valor de 20 bits que puede viajar con la información en dos formas posibles: Dentro de un encabezado adicional agregado a los paquetes llamado shim header. El shim header se coloca entre los encabezados de capa de red y de capa de enlace. Este funcionamiento es el que se utiliza en MPLS sobre IP y se llama modo trama. A continuación se muestra un diagrama de este encabezado Label Label Exp S TTL Stack Entry Label: Valor de la etiqueta, 20 bits Exp: Uso experimental, 3 bits S: Final del stack, 1 bit TTL: Tiempo de vida (Time to Live), 8 bits Figura 2.2: Shim Header El utilizado en MPLS sobre ATM que utiliza MPLS para intercambiar información. Este modo es denominado modo celda. En este modo, la etiqueta está encapsulada en los encabezados VPI/VCI del encabezado de ATM. Véase la figura 2.3. Supongamos el caso en que un LSR dado ha asignado un cierto conjunto de etiquetas entrantes a una FEC dada, sería deseable que al reenviar los paquetes de esa FEC les asignara a todos la misma etiqueta. Esta función se llama label merging (union de

15 Capítulo 2. Introducción a MPLS 6 GFC VPI VCI PTI CLP HEC DATA LABEL Figura 2.3: Etiqueta etiquetas). Para ilustrar esto supongamos que a un determinado LSR1 llegan paquetes desde distintas interfaces con distintas etiquetas dirigidos hacia el mismo destino, el enrutador LER1. Si LSR1 reenvía los paquetes con la misma etiqueta decimos que es capaz de hacer label merging. Véase la figura 2.4. Label #1 Label #2 LSR1 Label #4 LER1 Label #3 Figura 2.4: Label merging Otra característica de MPLS es que es posible la existencia de más de una etiqueta simultáneamente en cada paquete. Existe entonces un stack de etiquetas y una jerarquía asociada a ese stack. Si tenemos un stack de profundidad m se le llama etiqueta de nivel 1 a la que se colocó primero (y por consecuencia está después del encabezado de capa de red), de nivel 2 a la que se colocó después y así sucesivamente hasta la última de nivel m. Cabe recalcar que la decisión de reenvío se toma a partir del valor de la etiqueta de mayor nivel en el stack e independientemente de cuál sea ese nivel. Cuando un enrutador toma acción explícita para que un paquete particular sea entregado a otro enrutador, aún cuando este último no sea el siguiente salto en el camino ni el destino del paquete, se dice que se creó un túnel entre ambos enrutadores. Existe la posibilidad de implementar túneles mediante LSPs y utilizar intercambio de etiquetas

16 Capítulo 2. Introducción a MPLS 7 para que el paquete recorra el túnel. Estos túneles LSP pueden ser dentro de IP como túneles dentro de otros LSPs, en este caso se agrega un nuevo nivel al stack. Un ejemplo de túnel LSP entre los enrutadores Ru y Rd dentro de un LSP se muestra en la figura 2.5. L1 IP Ru Rd L5 IP L3 L2 IP LSR1 LSR2 L2 IP L4 L2 IP Figura 2.5: Túnel

17 Capítulo 3 Ingeniería de tráfico en MPLS 3.1. Motivación Los proveedores de internet (ISP s) están enfrentando un desafío con respecto al diseño de sus redes para poder satisfacer las demandas cada vez mayores de sus clientes. Estas demandas requieren mayores velocidades de transferencia de datos así como también confiabilidad y la posibilidad de poder tener servicios diferenciados. La ingeniería de tráfico resulta necesaria para alcanzar estos objetivos de una forma efectiva y poco costosa. El surgimiento de MPLS con su eficiencia para poder crear caminos explícitos entre dos nodos de una red es un mecanismo fundamental para poder realizar ingeniería de tráfico. El ruteo explícito nos permite que un flujo de datos específico vaya al destino por un camino predeterminado y no por un camino que se construye paso a paso (hop by hop) como ocurre con OSPF o IS-IS. En MPLS, los mecanismos para realizar ingeniería de tráfico pueden ser dependientes del tiempo o dependientes del estado. En un mecanismo dependiente del tiempo, la información histórica basada en variaciones temporales en el tráfico es usada para preprogramar los LSPs y la asignación de tráfico. Adicionalmente, se puede tener en cuenta una proyección a futuro de los enlaces y de los posibles tráficos. Los mecanismos de ingeniería de tráfico dependientes del tiempo no están pensados para que respondan de forma rápida ni traten de adaptarse a los cambios impredecibles ya sea en el tráfico así como en la topología de la red. Cuando tenemos variaciones apreciables e impredecibles en el tráfico actual, un mecanismo dependiente del tiempo no nos va a poder prevenir de la sobrecarga de algunos enlaces ni de la congestión de algunas partes de la red. En estas situaciones es cuando necesitamos un mecanismo que pueda lidiar con tráfico variable utilizando datos como son el retardo de los paquetes, porcentaje de pérdida de paquetes u otro indicador. La ingeniería de tráfico consiste en manipular el tráfico para que se ajuste a las características de la red. Su propósito es mejorar la utilización de la red intentando distribuir uniformemente el tráfico en ella o crear distribución de tráfico diferenciada, asegurando ciertos niveles de servicio o ciertos parámetros de calidad de servicio. Debido 8

18 Capítulo 3. Ingeniería de tráfico en MPLS 9 a esto, puede ser deseable que dos flujos de paquetes atraviesen caminos totalmente distintos aún cuando sus nodos de origen y de destino sean los mismos. Dentro de una subred MPLS la transmisión de paquetes sigue la ruta asignada a la FEC a la que pertenece el paquete. La determinación de esta ruta, o sea la creación del LSP, es previa a la transmisión del paquete. MPLS tiene dos formas de crear LSPs: Ruteo Salto a Salto: Cada LSR selecciona independientemente el próximo salto para una FEC dada. Este método es análogo al usado en redes IP y se utilizan para ello los protocolos de ruteo disponibles. Ruteo Explícito: En el ruteo explícito el enrutador de ingreso elige los nodos a través del cual debe pasar el LSP. El camino elegido puede no ser el más corto. Esto facilita la ingeniería de tráfico ya que puede elegirse los LSPs para poder brindar una determinada calidad de servicio, descongestionar ciertos nodos, reducir los retardos o bien minimizar la probabilidad de pérdida de paquetes Un ejemplo: IP vs. ATM vs. MPLS En redes IP la ingeniería de tráfico se realiza principalmente cambiando el costo de los enlaces. No existe una manera razonable de controlar el camino que sigue el tráfico basándose en su origen, solamente se lo puede controlar basándose en su destino. Debido a esto, existen algunos problemas que la ingeniería de tráfico en IP no puede solucionar. El hecho de que cada enrutador decida por su propia cuenta hacia dónde reenviar un paquete basándose en la dirección de destino de éste, hace muy difícil llevar un control sobre el servicio que se le está dando a los flujos. Este control se vuelve más factible si se cuenta con un camino explícito desde el origen al destino. La creación de caminos permite realizar reservas de ancho de banda a cada camino creado, o al menos permite ofrecerle a cada camino creado un cierto grado de servicio. Es este el caso de ATM por ejemplo, que permite crear circuitos virtuales manualmente o utilizando el protocolo RSVP (Resource Reservation Protocol) para ello. Este protocolo permite reservar recursos en todos los enrutadores pertenecientes al camino creado colocando PVCs (permanent virtual circuits) a lo largo de la red desde un ingreso de tráfico a un egreso. Tomemos el caso de la figura 3.1. En esta figura hay dos caminos para ir de R3 a R7: Camino 1:R3 R4 R7 Camino 2:R3 R5 R6 R7 Como todos los enlaces tienen el mismo costo (10), utilizando IP para reenviar los paquetes, todos los paquetes provenientes de R1 y R2 seguirán el camino 1 debido a que tiene un costo menor. Esto presenta algunas desventajas. Asumamos que cada uno de los enlaces de la figura es de 100 Mbps y que conocemos de antemano la cantidad de tráfico que envían R1 y

19 Capítulo 3. Ingeniería de tráfico en MPLS 10 R1 R4 10 R R7 R R5 10 R6 10 Figura 3.1: Caminos R2 a R3 con destino R7, siendo el tráfico que envía R1 90 Mbps y el que envía R2 60 Mbps. Entonces sucede que R3 intenta colocar 150 Mbps de tráfico a través de un enlace de 100 Mbps. Como resultado R3 termina descartando 50 Mbps que no pasan a través del enlace. Para solucionar esto utilizando reenvío IP hay que cambiar los costos de los enlaces. Pero si se hace que el costo del camino 2 sea menor, todo el tráfico se desviará hacia él. Es claro que en este caso se pueden ajustar los costos de los enlaces para que los costos de los caminos sean iguales, pero esta solución funciona solamente para redes sencillas. A medida que la cantidad de enrutadores de ingreso y egreso aumentan el problema se vuelve mas complejo, puede incluso llegar a no tener solución si la cantidad de caminos es mayor que la cantidad de enlaces. Una posible solución a esto es utilizar switches ATM en el lugar de R4, R5 y R6 como se ve en la figura 3.2. R1 PVC2 costo 10 SW4 10 R3 R7 R2 10 SW5 SW6 PVC2 costo 10 Figura 3.2: ATM En una red ATM el problema se resuelve fácilmente insertando dos PVCs desde R3 a R7 y ajustando sus costos para que sean iguales. Esto resuelve el problema ya que

20 Capítulo 3. Ingeniería de tráfico en MPLS 11 R3 va reenviar el tráfico por los dos caminos. Construir dos caminos con el mismo costo es una mejor solución que cambiar los costos de los enlaces en una red ATM ya que ningún enrutador es afectado por el cambio de métrica. Esta razón es la que hace que la ingeniería de tráfico en ATM sea superior a la de IP. Consideremos ahora la resolución del problema con MPLS como se muestra en la figura 3.3. R1 Tunnel 1 LSR4 10 LSR R7 R LSR5 10 LSR6 10 Tunnel 2 Figura 3.3: MPLS Utilizando MPLS la solución es básicamente igual que con ATM. Se crean túneles con LSPs para controlar el camino que toma el tráfico hacia un destino determinado. Luego, basándose en algún parámetro medido en la red, como podría ser el retardo en cada LSP, la utilización de cada camino o el porcentaje de paquetes perdidos, se puede transmitir un cierto porcentaje de los paquetes recibidos por un LSP y el resto por el otro de manera de optimizar la performance de la red en función del parámetro de medición elegido. A este concepto se le denomina reparto de carga Reparto de carga por varios LSPs hacia un mismo destino El concepto de reparto de carga por varios LSPs hacia un mismo destino o LER de egreso introducido en el ejemplo anterior es una de las herramientas más prometedoras para realizar Ingeniería de Tráfico. En primer lugar, el hecho de tener varios caminos creados hacia un mismo destino hace a la red mucho más robusta frente a caídas de enlaces o de enrutadores, ya que simplemente una vez detectado el fallo se deja de enviar por ese camino y se envía por los otros, no hay necesidad de crear uno nuevo. En segundo lugar, un algoritmo de decisión de reparto de carga por varios caminos en tiempo real es menos proclive a oscilar que un algoritmo de elección de un camino basado en mediciones de performance, como se vio en el ejemplo anterior.

21 Capítulo 3. Ingeniería de tráfico en MPLS 12 El desafío actual es diseñar un algoritmo de reparto de carga que logre utilizar de la manera más eficiente posible los recursos de la red a modo de optimizar su performance y poder cumplir con la demanda de calidad de servicio existente, además de contar con un buen protocolo de creación de caminos. Existen actualmente dos protocolos que resuelven la última necesidad, que son: RSVP-TE. Extensiones a RSVP para MPLS. CR-LDP. Constraint Route Label Distribution Protocol. de los cuales hablamos en mayor detalle en [1]. Sin embargo, con respecto al algoritmo de reparto de carga, si bien se ha venido trabajando mucho al respecto aún queda un largo trecho por recorrer. Las características tan dispares de los tipos de tráfico que conviven en la Internet hacen que encontrar un algoritmo de reparto que funcione eficientemente en todos los posibles casos sea realmente difícil. Es en este marco que en [2] se propone un algoritmo de reparto de carga llamado MPLS Adaptive Traffic Engineering (MATE) que aparece como un paso importante en el estudio y desarrollo de esta temática. En los próximos capítulos se realiza un análisis de éste, se discuten sus debilidades y se proponen algunas mejoras.

22 Capítulo 4 MPLS Adaptive Traffic Engineering - MATE 4.1. Introducción En este algoritmo se asume que los LSPs están determinados y el objetivo es poder realizar reparto de carga utilizando las variaciones en los parámetros de la red y en función de estos datos decidir cuál es la forma óptima de repartir la carga Características básicas En este trabajo se propone realizar ingeniería de tráfico con un mecanismo que es dependiente del estado de la red llamado MPLS Adaptive Traffic Engineering (MATE). Algunas de las cualidades que queremos que este algoritmo satisfaga son las siguientes: Un algoritmo de reparto de carga distribuido. Que el control lo lleven a cabo los nodos de ingreso y de egreso. Que no se requiera de nuevo hardware o protocolos diferentes en los nodos intermedios. Que no se requiera tener conocimiento de la demanda de tráfico a priori. Que la decisión esté basada en las medidas de la congestión en los caminos. Que no se necesite sincronización con un reloj maestro entre dos nodos. El algoritmo MATE requiere que los LSPs ya estén construídos en la red ya sea manualmente o utilizando CR-LDP o RSVP-TE. El objetivo de los nodos de ingreso es repartir la carga por los diferentes LSPs de forma de minimizar la congestión en la red. La figura 4.1 muestra el ejemplo de una red donde hay dos nodos de ingreso y dos de egreso en un ambiente MPLS. Los LSPs que conectan estos nodos de ingreso y 13

23 Capítulo 4. MPLS Adaptive Traffic Engineering - MATE 14 I1 E1 Red MPLS I2 E2 Figura 4.1: Red MPLS de egreso pueden solaparse y compartir los mismos recursos. Sin embargo, este trabajo mostrará que la estabilidad puede ser alcanzada incluso en el caso que los pares operen de forma asíncrona. La figura 4.2 muestra un diagrama de un bloque funcional del algoritmo MATE que está ubicado en los nodos de ingreso. El tráfico entrante pasa por un filtro y por una función de distribución cuyo objetivo es facilitar el reparto de carga a través de los LSPs de forma que se reduzcan las posibilidades de que los paquetes lleguen a destino fuera de orden. Este mecanismo no necesita conocer las estadísticas de las demandas de tráfico ni la información del estado de la red. La función de ingeniería de tráfico decide cuándo y cómo repartir el tráfico en los diferentes LSPs. Esto está basado en las estadísticas de los LSPs las cuales son obtenidas a partir de mediciones utilizando paquetes de prueba. Esta función consiste de dos etapas: una etapa de monitoreo y otra etapa de reparto de carga. En la etapa de monitoreo, si un cambio apreciable y persistente es detectado en el estado de la red, se produce una transición y pasamos a la etapa de reparto de carga. En la etapa de reparto de carga, el algoritmo intenta medir la congestión de cada uno de los LSPs. Una vez que actualiza el reparto de la carga se vuelve a la etapa de monitoreo y el proceso entero se repite. El rol del bloque de medición y análisis es obtener las estadísticas de cada LSP como son el retardo y el porcentaje de pérdida de paquetes. Esto es realizado enviando paquetes de prueba desde el nodo de ingreso de forma periódica. Medidas recientes en la Internet muestran que son pequeñas las variaciones en el tráfico cuando consideramos intervalos de medición de 5 minutos [2]; es decir, que podemos afirmar que el tráfico en Internet es cuasiconstante en intervalos de 5 minutos. Esto facilita la ingeniería de tráfico y el reparto de carga basado en mediciones estadísticas del estado de los LSPs.

24 Capítulo 4. MPLS Adaptive Traffic Engineering - MATE 15 LSP s a un nodo de egreso Medida y Análisis Paquetes de Prueba LSP 1 LSP 2 Paquetes entrantes Filtrado y Distribución Ingeniería de tráfico Paqutes de Datos LSP 3 Figura 4.2: Función de los nodos de ingreso 4.3. Algoritmo MATE En eta sección presentaremos el modelo analítico del algoritmo MATE y probaremos su estabilidad y optimalidad desde el punto de vista matemático Modelo Nuestro modelo de la red es un conjunto de L enlaces unidireccionales. Esta red es compartida por un conjunto de S pares de ingreso-egreso (IE). Cada uno de estos pares IE tiene un conjunto P s de LSPs disponibles. Observar que con esta definición no existen dos IE diferentes que compartan el mismo LSP, aunque los diferentes LSPs pueden compartir enlaces. Entonces los P s son conjuntos disjuntos. Cada par IE s tiene una tasa entrante r s y tasas x sp por cada uno de los LSPs del par s. Entonces es trivial ver que se tiene que cumplir que: p P s x sp = r s para todo s S Entonces definimos x s := (x sp,p P s ) el vector de los tasas del par s, y definimos x := (x sp,p P s,s S) el vector de todas las tasas. Por lo tanto podríamos representar

25 Capítulo 4. MPLS Adaptive Traffic Engineering - MATE 16 el vector x como: ) x = (x s1,x s2,...,x sn donde los s i son todos los pares de la red. (4.1) El flujo de tráfico sobre un enlace l L al cual llamaremos x l, es la suma de todas las tasas que pasan por ese enlace. Entonces x l = s l p,p P s x sp Asociado a cada enlace tenemos una función costo C l (x l ) que depende del flujo que esta pasando por el enlace. Este costo puede ser el retardo en cada enlace, el porcentaje de pérdida de paquetes, algún otro parámetro de la red o bien alguna combinación de ellos. Asumiremos que para cada l L la función C l es convexa (y por lo tanto continua). Nuestro objetivo es minimizar la función de costo total C(x) que se define como C(x) := l L C l(x l ), es decir queremos minimizar la suma de los costos de todos los enlaces repartiendo la carga de forma óptima por cada LSP. Nuestro problema a resolver es: mín x condicionado al espacio de condiciones: C(x) = mín x C l (x l ) (4.2) l { p P s x sp = r s para todo s S. x sp 0 para todo p P s y para todo s S. (4.3) A todo vector x que satisfaga las condiciones anteriores lo llamaremos vector óptimo. Aplicando la regla de la cadena obtenemos que: C x sp (x) = x sp l L C l (x l )= l L donde la última igualdad se debe a que: C l (x l )= C l x (xl ) xl = C l sp x (xl ) sp l L l p { x l 1 si l p, o sea, si el enlace l pertenece al LSP p del par s. = x sp 0 en caso contrario. Por lo tanto se cumple que: C (x) = C l x (xl ) (4.4) sp l p

26 Capítulo 4. MPLS Adaptive Traffic Engineering - MATE Algoritmo asíncrono La forma que utilizaremos para resolver el problema de minimizar la función costo total restringida a las condiciones antes impuestas es movernos en la dirección del gradiente y luego proyectar sobre el espacio de condiciones. Es decir, cada iteración toma la forma: x(t + 1) = [x(t) γ C(t)] + (4.5) donde γ es una constante positiva (adecuadamente elegida), la función C(t) = C(x(t)) y[z] + es la proyección del vector z sobre el conjunto de las condiciones; esta proyección tiene sentido puesto que el conjunto de las condiciones es un conjunto convexo y es un resultado conocido de Análisis Funcional que siempre existe y es única la proyección sobre un conjunto convexo independientemente de la dimensión del espacio vectorial ambiente (sea finita o infinita). El algoritmo termina cuando x(t + 1) x(t) < ɛ para algún ɛ predefinido. Convexo P Una observación importante, que hace al algoritmo muy potente, es que la iteración se puede hacer en cada par sin tener que coordinar entre sí los pares. Ésto surge de descomponer el vector x de la manera indicada en la ecuación 4.1. Entonces la iteración se puede hacer de la siguiente manera: x s (t + 1) = [x s (t) γ C s (t)] + (4.6) donde C s es la suma de los costos de los enlaces que pertenecen al par s. Es más, dado que ( ) C C s (t) = y recordando la ecuación 4.4, cada par sólo necesita conocer el estado de los enlaces pertenecientes a sus LSPs y no el estado de todos los enlaces de la red. Es decir, sólo conociendo el estado de los enlaces que pertenecen a sus LSPs y actualizando sus porcentajes en función de ello, cada LER de ingreso está contribuyendo a minimizar el costo preomedio de todos los enlaces de la red. Los siguientes resultados establecen que el algoritmo converge a un punto óptimo, si las siguientes condiciones se satisfacen: x sp p P s C1- Las funciones costo C l (z) deben ser dos veces diferenciables y convexas.

27 Capítulo 4. MPLS Adaptive Traffic Engineering - MATE 18 C2- Las funciones derivadas del costo C l (z) son Lipschitz en cualquier conjunto acotado B l R; es decir que dado B l acotado existe c l tal que z, z B l se cumple que C l (z) C l (z ) c l z z. C3- Para todo c el conjunto {z C l (z) c} es acotado. C4- El intervalo de tiempo entre actualizaciones es acotado. Teorema Bajo las condiciones C1-C4, empezando en cualquier condición inicial x(0), existe γ suficientemente pequeño tal que todo punto de acumulación de la sucesión {x(t)} es un punto óptimo. Un análisis más detallado muestra qué tan pequeño debe ser el valor de γ, y por lo tanto la velocidad de convergencia. Si asumimos que además de cumplirse C2 se cumple que las cotas c l son uniformes, es decir que: l enlace de la red y z, z R se satisface que C l (z) C l (z ) L z z. Entonces se cumple que: Teorema Una cota superior de γ para que algoritmo converja es: donde γ< π es el número total de LSPs en la red. 1 L(1 + πhλ(2t 0 + 1)) (4.7) h es el número de hops en el camino más largo. λ es el máximo número de LSPs que comparten el mismo enlace. t 0 es el grado de asincronismo en las actualizaciones de los distintos LER de ingreso. Observación El Teorema nos sugiere que cuanto mayor es el grado de asincronismo de la red menor debe ser γ y por lo tanto el tiempo de convergencia. La demostración de estos resultados se puede leer en [2] Ejemplo de una función costo La elección de la función costo nos determina los parámetros de la red que deben ser medidos y ecualizados por el algoritmo MATE. Una elección natural de la función costo de los enlaces es el retardo. Si tomamos el costo como el retardo medio de una cola M/M/1 tendríamos que C l (x l )= 1 c l x l, donde c l representa la capacidad del enlace l. El porcentaje de pérdida también puede ser incorporado a la función costo tomando a cada paquete perdido como un retardo fijo y grande. Otra alternativa puede ser tomar la función costo como el producto del retardo y el porcentaje de pérdida. En resumen, el objetivo esencial es llevar a la red a que se comporte de forma óptima basados en el elección de una determinada función de costo.

28 Capítulo 5 Implementación teórica 5.1. Elección de la función costo Una de las decisiones importantes que tuvimos que tomar a la hora de implementar el algoritmo en una red real es la elección de la función costo a utilizar. El costo que nosotros utilizamos es el retardo R l (x l ). Es claro, que el retardo depende del flujo x l que está atravesando el enlace l, pero de qué forma depende?. Podemos deducir que el retardo es una función R l : [0,c l ) [0, + ) creciente donde c l es la capacidad del enlace l. Además, es claro que se debe cumplir que: R l (0) = r min donde r min es un retardo mínimo, que está dado por la velocidad de transmisión del enlace y por la velocidad de procesamiento de los paquetes. lím x l c l R l (x l )=+. Entonces, independientemente del modelo de tráfico que utilicemos, y de cómo sean sus colas, la función retardo medio tiene básicamente la forma mostrada en la figura 5.1. En el caso que las colas sean del tipo M/M/1 la función retardo satisface la siguiente ecuación, R l (x l )= 1 c l x l como se demuestra en [3]. Un punto importante a tener en cuenta es que éste es el modelo más simple de retardo en un enlace y que este modelo no toma en cuenta ni el tiempo de propagación ni el tiempo de paquetización. Entonces, nuestra función costo es C l = R l y por lo tanto δc (x l )= C l δx (xl )= R l (xl )= Rl 2 (xl ) sp l p l p l p puesto que se cumple que R l (xl )=R 2 l (xl ). Una observación importante es que para calcular R l (xl ) no es necesario medir x l, solamente necesitamos medir el retardo del enlace y luego elevarlo al cuadrado. Si quisiéramos 19

29 Capítulo 5. Implementación teórica 20 R l (retardo) R min c l Figura 5.1: Función retardo x l medir x l directamente habría que tener un protocolo de comunicación donde cada LSR midiera el tráfico que va hacia cada nodo de egreso, y transmitiera la información a los nodos de ingreso de la red. Esto agregaría bastante complejidad innecesaria al algoritmo y sobre todo habría que agregarle software adicional a los enrutadores intermedios. El agregarle software adicional a los router intermedios va en contra de uno de los objetivos esenciales del algoritmo MATE que es no tener que modificar en nada a éstos. Además, se agregarían paquetes adicionales en la red para la comunicación de esta información. Lo mismo sucedería si los enrutadores intermedios tuvieran que medir el tamaño de sus colas y en función de ello enviaran el valor estimado del retardo del enlace a los nodos de ingreso. Entonces la única alternativa viable transparenten a los enrutadores intermedios es medir los retardos directamente con paquetes de prueba. Esto también tiene un pequeño inconveniente cuando la red no es síncrona; en una red asíncrona es imposible medir el retardo unilateral de un enlace, lo único que se puede hacer es medir el retardo de ida y vuelta. Teorema En una red asíncrona no se puede medir el retardo unilateral entre dos enlaces. Demostración. La red es asíncrona, así que supongamos que entre el host A y el host B hay una diferencia en sus relojes de t 0, con t 0 desconocido. Es decir que Tiempo de B=Tiempo de A + t 0. Si en un tiempo t 1 (tiempo reloj de A) el host A manda un paquete de prueba con destino B y cuando este paquete llega a su destino el host B le fija un time-stamp de la hora actual de la máquina B, que llamaremos t 2, entonces el retardo r A =(t 2 t 1 ) t 0. Análogamente, la máquina B puede hacer lo mismo y tendríamos otra ecuación para r B. Tenemos dos ecuaciones y tres incógnitas r A,r B y t 0, con lo cual es claro que no podemos

30 Capítulo 5. Implementación teórica 21 A l B resolver el sistema y por lo tanto no podemos calcular el retardo unilateral ya que éstos son los únicos datos que podemos obtener. Por la proposición anterior sabemos que en una red asíncrona sólo podemos medir el retardo de ida y vuelta en cada enlace, y como lo que nos interesa es el retardo unilateral introducimos un parámetro configurable δ, donde δ [0, 1] (típicamente en una red simétrica tenemos que δ = 1 2 ). Entonces 5.2. Proyección r unilateral = δr medido (5.1) Luego que tenemos determinada la función costo C l (x l )=R l (x l ) y que sabemos calcular el gradiente de ésta ya estamos en condiciones de hacer la iteración del algoritmo: x s (t) =[x s (t 1) γ C s (t 1)] + (5.2) con la función costo elegida la iteración queda: [( x s (t) = x sp (t 1) γ ) Rl 2 (xl ) l p ] + (5.3) donde s denota el par, p el LSP, γ es una constante que tiene que ser elegida suficientemente pequeña para garantizar la convergencia y [z] + es la proyección sobre el conjunto convexo determinado por las siguientes condiciones: { p P s x sp = r s x sp 0 p P s (5.4) Ahora bien, una pregunta natural es, cómo hacemos esta proyección?. Para responder a esta pregunta supongamos que tenemos un par s IE con N LSPs y que debemos p P s

31 Capítulo 5. Implementación teórica 22 repartir una carga de r s bits/segundo. Las tasas a repartir por cada LSP las llamaremos x s1,...,x sn. Se debe cumplir que: { x s x sn = r s (5.5) x si 0 i. Sea z el vector z = x s (t 1) γ l p R2 l (xl ), nuestro objetivo es calcular el vector x donde x =[z] +. Para realizar esta proyección, en primer lugar proyectamos el vector z en el conjunto A 1 = {y R N : y y N = r s } y para esto minimizamos la función f(y 1,...,y N ) = [(z 1 y 1 ) (z N y N ) 2 ] 1 2 restringida al conjunto A 1 ; es decir, estamos hallando el vector y A 1 que minimiza la distancia al vector z, ésta es justamente la proyección de z sobre A 1. z y A 1 Figura 5.2: Reparto de carga con dos LSPs Es evidente que minimizar la función f es análogo a minimizar la función h = f 2. Luego aplicando el método de los multiplicadores de Lagrange, obtenemos que el vector y que minimiza la función h (y por lo tanto f) restringido al conjunto A 1 debe satisfacer que: { h = λ g donde g(y 1,...,y N )=y y N (5.6) g(y 1,...,y N )=r s Entonces, h = λ g y i y i y i = λ 2 + z i

32 Capítulo 5. Implementación teórica 23 por otro lado y y N = N λ 2 + z z N = r s ( λ = 2 r s N ) N z i i=1 Entonces se cumple que, y i = 1 N ( r s ) N z i + z i Hasta ahora hemos hallado el vector y A 1 que es la proyección de z sobre A 1, pero nada nos asegura que las coordenadas del vector y sean todas positivas como queremos. Podría ocurrir que algunas de estas coordenadas fueran negativas. Sean y i1,y i2,...,y ik las coordenadas de y que son negativas. En este caso, lo que hacemos es definir un nuevo vector y (1) de la siguiente manera y (1) i = i=1 { y i si y i 0 0 en otro caso (5.7) y proyectarlo sobre el subespacio A 2 = {y R N : y i1 =...= y ik =0, N i=1 y i = r s }. Este proceso se repite hasta que en alguna proyección, supongamos la j-ésima, se cumpla que y (j) i 0 i, ya que la otra condición que necesitamos se cumple en todas las proyecciones por la forma en que realizamos éstas. Obsérvese que siempre vamos a encontrar un j tal que y (j) i 0 i, ya que estamos proyectando en subespacios de dimensión cada vez menor y estamos partiendo de un subespacio de dimensión finita.