Implementaci´on 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´ublica Montevideo - Uruguay.
I Documento principal
1. Introducci´on 1
1.1. Motivaci´on . . . 1
1.2. Objetivos del proyecto . . . 2
1.3. Descripci´on de lo realizado . . . 2
2. Introducci´on a MPLS 4 3. Ingenier´ıa de tr´afico en MPLS 8 3.1. Motivaci´on . . . 8
3.2. Un ejemplo: IP vs. ATM vs. MPLS . . . 9
3.3. Reparto de carga por varios LSPs hacia un mismo destino . . . 11
4. MPLS Adaptive Traffic Engineering - MATE 13 4.1. Introducci´on . . . 13
4.2. Caracter´ısticas b´asicas . . . 13
4.3. Algoritmo MATE . . . 15
4.3.1. Modelo . . . 15
4.3.2. Algoritmo as´ıncrono . . . 17
4.3.3. Ejemplo de una funci´on costo . . . 18
5. Implementaci´on te´orica 19 5.1. Elecci´on de la funci´on costo . . . 19
5.2. Proyecci´on . . . 21
5.3. Reparto de Carga . . . 24
5.4. Mejoras al algoritmo cuando el tr´afico no es constante . . . 26
5.4.1. Trabajamos con porcentajes y no tasas . . . 27
5.4.2. γ adaptativo . . . 28
5.4.3. Intervalo adaptativo entre actualizaciones . . . 34
6. Implementaci´on del algoritmo MATE en la pr´actica 46 6.1. Implementaci´on . . . 46
6.2. Caracter´ısticas generales de la implementaci´on . . . 46
6.3. Caracter´ısticas b´asicas de cada proceso . . . 48 i
6.3.1. Proceso repartidor . . . 48
6.3.2. Proceso mated . . . 48
6.3.3. Medici´on de retardos . . . 49
6.3.4. Medici´on de un retardo de ida y vuelta . . . 51
6.4. Estructura par y memoria compartida . . . 52
6.4.1. An´alisis de los datos asociados a un par de egreso . . . 52
6.4.2. Estructuras par, path lsp y nodo . . . 52
6.4.3. Memoria Compartida . . . 53
6.5. Funcionamiento de los procesos repartidor y mated . . . 54
6.5.1. repartidor . . . 54
6.5.2. mated . . . 56
6.5.3. mated3 . . . 58
7. Performance del algoritmo en diferentes escenarios 64 7.1. γ adaptativo vs. γ fijo: Prueba en VMWare . . . 64
7.1.1. Resultados obtenidos: . . . 65
7.2. γ adaptativo vs. γ fijo: prueba en el Laboratorio de Software . . . 67
7.2.1. Resultados obtenidos en esta prueba . . . 68
7.3. Evaluaci´on del intervalo adaptativo entre actualizaciones . . . 71
7.3.1. Resultados obtenidos: . . . 72
7.4. Repuesta al escal´on . . . 79
7.5. Evaluaci´on global de mated3 . . . 80
7.5.1. Etapa 1 . . . 80
7.5.2. Etapa 2 . . . 82
8. Conclusiones finales 86 8.1. Resumen de lo realizado . . . 86
8.2. Caracter´ısticas generales del algoritmo MATE . . . 87
8.3. Mejoras al algoritmo original . . . 88
8.4. Trabajos a futuro . . . 88
II Anexos A. Manual de usuario: Software mated 1 A.1. Instalaci´on . . . 1
A.2. Modo de uso . . . 2
A.3. Archivos de configuraci´on . . . 3
A.3.1. repartidor . . . 3
A.3.2. mated1 . . . 4
A.3.3. mated2 . . . 4
B. Programaci´on de Sockets 7
B.1. ¿Qu´e es un socket? . . . 7
B.2. Direcciones IP, ¿c´omo tratarlas? . . . 7
B.3. Sockets de Internet . . . 9
B.3.1. Dos tipos de sockets de internet . . . 9
B.4. Modelo cliente-servidor . . . 10
B.4.1. Un servidor sencillo . . . 10
B.4.2. Un cliente sencillo . . . 12
B.4.3. Sockets de datagramas . . . 14
C. Memoria compartida y sem´aforos 18 C.1. Conceptos fundamentales . . . 18
C.1.1. Identificadores IPC . . . 18
C.1.2. Claves IPC . . . 18
C.2. Sem´aforos . . . 19
C.2.1. Conceptos B´asicos . . . 19
C.2.2. Estructuras de datos internas . . . 20
C.2.3. semtool: Manipulador interactivo de sem´aforos . . . 33
C.3. Memoria Compartida . . . 41
C.3.1. Conceptos B´asicos . . . 41
C.3.2. Estructuras de Datos Internas y de Usuario . . . 42
C.3.3. shmtool: Manipulador de segmentos de memoria compartida . . . 47
D. Herramientas de software utilizadas en el Proyecto 51 D.1. Parche MPLS-LINUX . . . 51 D.1.1. Instalaci´on de mpls-linux. . . 52 D.1.2. Compilaci´on de mplsadm . . . 55 D.1.3. Instalaci´on de ldp-portable . . . 55 D.1.4. Parche a iproute2 . . . 57 D.1.5. Parche a pppd . . . 57
D.2. Modo de uso de mplsadm . . . 57
D.2.1. Ejemplo de configuraci´on de una red MPLS . . . 58
D.3. Generador de tr´afico MGEN . . . 61
´Indice de figuras
2.1. Intercambio de etiquetas . . . 5 2.2. Shim Header . . . 5 2.3. Etiqueta . . . 6 2.4. Label merging . . . 6 2.5. T´unel . . . 7 3.1. Caminos . . . 10 3.2. ATM . . . 10 3.3. MPLS . . . 11 4.1. Red MPLS . . . 144.2. Funci´on de los nodos de ingreso . . . 15
5.1. Funci´on retardo . . . 20
5.2. Reparto de carga con dos LSPs . . . 22
5.3. Reparto de carga con dos LSPs . . . 24
5.4. Reparto de carga con tres LSPs . . . 25
5.5. LSPs entre dos LERs . . . 26
5.6. Proyecci´on utilizando tasas . . . 27
5.7. Proyecci´on utilizando porcentajes . . . 28
5.8. Gr´afica de f(Z) . . . 32 5.9. Intervalos . . . 35 5.10. Gr´afico de at − ψ(t) . . . 38 5.11. Gr´afico de gξ . . . 41 5.12. Gr´afico de gξ . . . 42 5.13. Gr´afico de at − ψ(t) . . . 43
5.14. Retardo no est´atico en un intervalo de actualizaci´on . . . 43
6.1. Diagrama b´asico de los procesos . . . 47
6.2. Una vuelta de mediciones . . . 49
6.3. Retardo de un enlace . . . 50
6.4. Diagrama de flujo de los programas . . . 55
6.5. Diagrama de flujo de los programas . . . 61
6.6. Tr´afico creciente . . . 62 iv
7.1. Topolog´ıa de prueba . . . 65
7.2. Limitaci´on de los retardos . . . 66
7.3. Topolog´ıa de prueba . . . 68
7.4. Topolog´ıa real en el laboratorio . . . 69
7.5. Topolog´ıa de prueba . . . 71
7.6. Tr´afico entrante al par . . . 71
7.7. Tr´afico entrante al par: prueba 1 . . . 72
7.8. Valor de dt: prueba 1 . . . 73
7.9. Valores de k0 y de k: prueba 1 . . . 73
7.10. Tr´afico entrante al par: prueba 2 . . . 74
7.11. Valor de dt: prueba 2 . . . 75
7.12. Valores de k0 y de k: prueba 2 . . . 75
7.13. Tr´afico entrante al par: prueba 3 . . . 76
7.14. Valor de dt: prueba 3 . . . 76
7.15. Valores de k0 y de k: prueba 3 . . . 77
7.16. Tr´afico entrante al par: prueba 4 . . . 77
7.17. Valor de dt: prueba 4 . . . 78
7.18. Valores de k0 y de k: prueba 4 . . . 78
7.19. Tr´afico entrante al par . . . 79
7.20. Gr´afica de τ↓ . . . 80
7.21. Topolog´ıa de la red de prueba . . . 81
7.22. Tr´afico entrante por los LERs de ingreso 1 (rojo) y 2 (azul) . . . 82
7.23. Evoluci´on del tama˜no de intervalo entre actualizaciones . . . 83
7.24. Evoluci´on de k0 (azul) y k (verde) . . . 83
7.25. Mediciones efectivamente realizadas . . . 84
7.26. Porcentajes enviados por el LSP 1.1 (azul) y LSP 1.2 (verde) . . . 84
7.27. RTT medio por los LSP 1.1 (azul) y LSP 1.2 (verde) . . . 85
7.28. Varianza de los RTT de los LSP 1.1 (azul) y LSP 1.2 (verde) . . . 85
Agradecemos a nuestro tutor de Proyecto el Ing. Pablo Belzarena por haber confiado a nuestro grupo la realizaci´on del presente Proyecto y por su ayuda a lo largo de ´este.
Queremos destacar adem´as la ayuda brindada por el Ing. Eduardo Cota y el Ing. Gabriel G´omez que nos guiaron en varias etapas de aprendizaje a lo largo del mismo.
Agradecemos tambi´en a Rafael Grompone y al Ing. Ignacio Ram´ırez por sus aportes.
En este proyecto se instal´o en la red de computadoras del Laboratorio de Desarrollo de Software del Insitituto de Ingenier´ıa El´ectrica de la Facultad de Ingenier´ıa una versi´on del sistema operativo Linux modificada que agrega a su stack de protocolos de red la capa MPLS. Para ello se utiliz´o el paquete mpls-linux brindado por ‘Source Forge’. Posteriormente se implement´o el algortimo MATE de reparto de carga y se estudi´o su performance. Dicha implementaci´on fue programada en C para el sistema operativo Lin-ux. Se encontraron varias debilidades en el algoritmo original, algunas de las cuales fueron predichas te´oricamente y otras surgieron a la hora de la implementaci´on pr´acti-ca. 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´afico entrante permitiendo as´ı que el algoritmo MATE pensado inicialmente para trabajar con tr´afico constante lo pueda hacer cuando el tr´afico var´ıa con el tiempo. La segunda versi´on, adem´as de tener el paso adaptativo entre las actualizaciones, utiliza un tama˜no de intervalo entre actualizaciones variable que se adec´ua a las variaciones en el tr´afico. Esta versi´on calcula adem´as, en funci´on de las caracteristicas del tr´afico, cu´antas mediciones se deben realizar de manera que la estad´ıstica tomada del tr´afico mediante paquetes de prueba pueda ser considerada confiable.
Introducci´
on
1.1.
Motivaci´
on
El proyecto es generado debido a la creciente demanda de utilizaci´on 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´erdida y ancho de banda. Existe tambi´en un gran inter´es en poder realizar servicios diferenciados, donde aqu´el 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´a siendo estudiada y discutida, llamada MPLS (Multipro-tocol 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 ´esta realizar Ingenier´ıa de Tr´afico en una red de com-putadoras, en particular en Internet, y poder controlar los par´ametros de calidad de servicio antes mencionados.
De este modo surge el inter´es de tener en el Instituto de Ingenier´ıa El´ectrica (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´afico 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´ucleo (kernel) de Lin-ux 2.4.x, el cual consiste en una plataforma de reenv´ıo de paquetes y una implementaci´on del protocolo de distribuci´on de etiquetas (LDP) estandarizado en el RFC 3036. ‘MPLS for Linux’ es distribuido por ‘Source Forge’ y est´a compuesto por dos paquetes, mpls-linux y ldp-portable, disponibles en la p´agina web http://sourceforge.net/projects/mpls-linux/.
Por otro lado, se estudi´o y analiz´o el algoritmo MATE de reparto de carga, el cual es un algoritmo desarrollado en conjunto por Bell Labs Lucent Technologies, el departamen-to de Ingenier´ıa El´ectrica de la Universidad de Michigan Ann Arbor, el departamendepartamen-to de
Ingenier´ıa El´ectrica de Caltech, y por Fujitsu Network Communications Pearl River; el estudio de ´este surge de la necesidad de realizar reparto de carga en una red de computa-doras 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´actica y se introdujeron cambios en ´este de forma de superar estas debilidades.
1.2.
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 conclu-siones generales acerca de su funcionamiento y potencialidad para realizar inge-nier´ıa de tr´afico sobre ´este.
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´afico, 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´afico.
1.3.
Descripci´
on de lo realizado
El proyecto comenz´o con un estudio en profundidad del protocolo MPLS as´ı como un an´alisis y comparaci´on de este protocolo frente a otros. El an´alisis de este estudio dio lugar a una monograf´ıa que se puede leer en [1].
Posteriormente se estudi´o el funcionamiento del software VMWare, el cual nos per-miti´o que en un PC se crearan varias m´aquinas virtuales y se las pudieran conectar en red simulando una red real de computadoras. A cada una de estas m´aquinas virtuales se les instal´o el sistema operativo Linux con n´ucleo 2.4.18, y luego se modific´o este n´ucleo con el parche mpls-linux distribuido por ‘Source Forge’ para hacer que estas m´aquinas utilizaran el protocolo MPLS para el env´ıo de paquetes. Luego, se instal´o y se estudi´o el funcionamiento del software mplsadm que nos permite crear los diferentes LSPs de for-ma est´atica, y se instal´o el paquete ldp-portable que es un parche al software zebra que permite crear caminos dinamicamente utilizando el protocolo LDP.
Una vez hecho esto, ten´ıamos seis m´aquinas 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´es 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´orica, lo implementamos en la pr´actica 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´afico (tr´afico constante, Poisson y tipo Burst) y pruebas con diferentes topolog´ıas de la red dentro del entorno de VMWare. Posteriormente, se arm´o una red MPLS de computadoras en el Laboratorio de Desarrollo de Software del IIE donde tambi´en se prob´o el algoritmo en su versi´on 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 algo-ritmo ten´ıa graves problemas de convergencia cuando el tr´afico era variable y cuando la utilizaci´on 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´onde 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´alisis donde se estudiaron y propusieron diferentes formas de solucionar los problemas plantead-os; una vez propuestas estas soluciones se programaron las nuevas versiones del algoritmo que fueron posteriormente probadas y comparadas entre s´ı.
Introducci´
on a MPLS
MPLS significa Multiprotocol Label Switching. Multiprotocol porque puede ser uti-lizado 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´on de la ruta que este debe recorrer. MPLS es un protocolo orientado a conexi´on no confiable, orientado a conexi´on significa que antes de empezar a enviarse la informaci´on se traza el o los caminos por los cuales ser´an enviados los paquetes y no confiable porque no se env´ıa confirmaci´on acerca de la llegada de los paquetes.
En MPLS la transmisi´on 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´on que los diversos enrutadores van intercambiando a lo largo del LSP. Las etiquetas utilizadas en el o los caminos a seguir son elegidas uti-lizando protocolos de distribuci´on de etiquetas din´amicos 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´on ingresan al LSP y se les coloca una etiqueta y el ´ultimo en-rutador donde los paquetes emergen del LSP y se les extrae una etiqueta; estos tambi´en son llamados LER de ingreso y de egreso. Los LSRs son los enrutadores intermedios en-cargados de intercambiar las etiquetas de los paquetes y reenviar los paquetes a lo largo del LSP. Adem´as, dados dos enrutadores pertenecientes a un mismo LSP se denomina enrutador ’upstream’ a aquel que se encuentra m´as cercano al ingreso y enrutador ’down-stream’ a aquel que esta m´as lejos del ingreso. En la figura 2.1 se halla una ilustraci´on de estos conceptos.
La clase de equivalencia de reenv´ıo o FEC es la representaci´on 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´on de destino com´un) 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
LER 1 LSR LER 2 MPLS + IP INGRESO MPLS + IP Paquete IP Label #2 Label #1 EGRESO Paquete IP
Figura 2.1: Intercambio de etiquetas
FEC.
Por lo tanto la etiqueta definir´a el camino que seguir´an los datos a trav´es de la red. Una etiqueta es un valor de 20 bits que puede viajar con la informaci´on 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´on se muestra un diagrama de este encabezado.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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´on. Este modo es denominado modo celda. En este modo, la etiqueta est´a encapsulada en los encabezados VPI/VCI del encabezado de ATM. V´ease 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´on se llama ’label merging’ (union de
VPI
GFC 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´ease la figura 2.4.
LSR1
Label #1LER1
Label #4 Label #3 Label #2Figura 2.4: Label merging
Otra caracter´ıstica de MPLS es que es posible la existencia de m´as de una etiqueta simult´aneamente 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´o primero (y por consecuencia est´a despu´es del encabezado de capa de red), de nivel 2 a la que se coloc´o despu´es y as´ı sucesivamente hasta la ´ultima de nivel m. Cabe recalcar que la decisi´on de reenv´ıo se toma a partir del valor de la etiqueta de mayor nivel en el stack e independientemente de cu´al sea ese nivel.
Cuando un enrutador toma acci´on expl´ıcita para que un paquete particular sea en-tregado a otro enrutador, a´un cuando este ´ultimo no sea el siguiente salto en el camino ni el destino del paquete, se dice que se cre´o un t´unel entre ambos enrutadores. Existe la posibilidad de implementar t´uneles mediante LSPs y utilizar intercambio de etiquetas
para que el paquete recorra el t´unel. Estos t´uneles LSP pueden ser dentro de IP como t´uneles dentro de otros LSPs, en este caso se agrega un nuevo nivel al stack. Un ejemplo de t´unel LSP entre los enrutadores Ru y Rd dentro de un LSP se muestra en la figura 2.5. L2 L4 IP L3 L2 IP L1 IP L2 IP L5 IP
Ru
LSR2
LSR1
Rd
Figura 2.5: T´unelIngenier´ıa de tr´
afico en MPLS
3.1.
Motivaci´
on
Los proveedores de internet (ISP’s) est´an enfrentando un desaf´ıo con respecto al dise˜no 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 tam-bi´en confiabilidad y la posibilidad de poder tener servicios diferenciados. La ingenier´ıa de tr´afico 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´afico. 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´afico pueden ser dependi-entes del tiempo o dependidependi-entes del estado. En un mecanismo dependiente del tiempo, la informaci´on hist´orica basada en variaciones temporales en el tr´afico es usada para preprogramar los LSPs y la asignaci´on de tr´afico. Adicionalmente, se puede tener en cuenta una proyecci´on a futuro de los enlaces y de los posibles tr´aficos. Los mecanismos de ingenier´ıa de tr´afico dependientes del tiempo no est´an pensados para que respondan de forma r´apida ni traten de adaptarse a los cambios impredecibles ya sea en el tr´afico as´ı como en la topolog´ıa de la red.
Cuando tenemos variaciones apreciables e impredecibles en el tr´afico actual, un mecanismo dependiente del tiempo no nos va a poder prevenir de la sobrecarga de al-gunos enlaces ni de la congesti´on de algunas partes de la red. En estas situaciones es cuando necesitamos un mecanismo que pueda lidiar con tr´afico variable utilizando datos como son el retardo de los paquetes, porcentaje de p´erdida de paquetes u otro indicador. La ingenier´ıa de tr´afico consiste en manipular el tr´afico para que se ajuste a las caracter´ısticas de la red. Su prop´osito es mejorar la utilizaci´on de la red intentando distribuir uniformemente el tr´afico en ella o crear distribuci´on de tr´afico diferenciada, asegurando ciertos niveles de servicio o ciertos par´ametros de calidad de servicio. Debido
a esto, puede ser deseable que dos flujos de paquetes atraviesen caminos totalmente distintos a´un cuando sus nodos de origen y de destino sean los mismos.
Dentro de una subred MPLS la transmisi´on de paquetes sigue la ruta asignada a la FEC a la que pertenece el paquete. La determinaci´on de esta ruta, o sea la creaci´on del LSP, es previa a la transmisi´on del paquete. MPLS tiene dos formas de crear LSPs:
Ruteo Salto a Salto: Cada LSR selecciona independientemente el pr´oximo salto para una FEC dada . Este m´etodo es an´alogo 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´es del cual debe pasar el LSP. El camino elegido puede no ser el m´as corto. Esto facilita la ingenier´ıa de tr´afico 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´erdida de paquetes.
3.2.
Un ejemplo: IP vs. ATM vs. MPLS
En redes IP la ingenier´ıa de tr´afico se realiza principalmente cambiando el costo de los enlaces. No existe una manera razonable de controlar el camino que sigue el tr´afico bas´andose en su origen, solamente se lo puede controlar bas´andose en su destino. Debido a esto, existen algunos problemas que la ingenier´ıa de tr´afico en IP no puede solucionar. El hecho de que cada enrutador decida por su propia cuenta hacia d´onde reenviar un paquete bas´andose en la direcci´on de destino de ´este, hace muy dif´ıcil llevar un control sobre el servicio que se le est´a dando a los flujos.
Este control se vuelve m´as factible si se cuenta con un camino expl´ıcito desde el origen al destino. La creaci´on 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 manual-mente 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´afico 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´an 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´afico que env´ıan R1 y
R1 10 R7 R6 R5 R4 R3 R2 10 10 10 10 10 10 Figura 3.1: Caminos
R2 a R3 con destino R7, siendo el tr´afico que env´ıa R1 90 Mbps y el que env´ıa R2 60 Mbps. Entonces sucede que R3 intenta colocar 150 Mbps de tr´afico a trav´es de un enlace de 100 Mbps. Como resultado R3 termina descartando 50 Mbps que no pasan a trav´es 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´afico se desviar´a hacia ´el. 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´on 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´on si la cantidad de caminos es mayor que la cantidad de enlaces.
Una posible soluci´on a esto es utilizar switches ATM en el lugar de R4, R5 y R6 como se ve en la figura 3.2. R1 10 R7 SW6 SW5 SW4 R2 10 R3 PVC2 costo 10 PVC2 costo 10 Figura 3.2: ATM
En una red ATM el problema se resuelve f´acilmente insertando dos PVCs desde R3 a R7 y ajustando sus costos para que sean iguales. Esto resuelve el problema ya que
R3 va reenviar el tr´afico por los dos caminos. Construir dos caminos con el mismo costo es una mejor soluci´on que cambiar los costos de los enlaces en una red ATM ya que ning´un enrutador es afectado por el cambio de m´etrica. Esta raz´on es la que hace que la ingenier´ıa de tr´afico en ATM sea superior a la de IP.
Consideremos ahora la resoluci´on del problema con MPLS como se muestra en la figura 3.3. R1 10 R7 LSR6 LSR5 LSR4 LSR3 R2 10 10 10 10 10 10 Tunnel 1 Tunnel 2 Figura 3.3: MPLS
Utilizando MPLS la soluci´on es b´asicamente igual que con ATM. Se crean t´uneles con LSPs para controlar el camino que toma el tr´afico hacia un destino determinado. Luego, bas´andose en alg´un par´ametro medido en la red, como podr´ıa ser el retardo en cada LSP, la utilizaci´on 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´on del par´ametro de medici´on elegido. A este concepto se le denomina reparto de carga.
3.3.
Reparto de carga por varios LSPs hacia un mismo
des-tino
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´as prometedoras para realizar Ingenier´ıa de Tr´afico.
En primer lugar, el hecho de tener varios caminos creados hacia un mismo destino hace a la red mucho m´as 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´on de reparto de carga por varios caminos en tiempo real es menos proclive a oscilar que un algoritmo de elecci´on de un camino basado en mediciones de performance, como se vio en el ejemplo anterior.
El desaf´ıo actual es dise˜nar un algoritmo de reparto de carga que logre utilizar de la manera m´as 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´as de contar con un buen protocolo de creaci´on de caminos. Existen actualmente dos protocolos que resuelven la ´ultima 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 algorit-mo de reparto de carga, si bien se ha venido trabajando mucho al respecto a´un queda un largo trecho por recorrer. Las caracter´ısticas tan dispares de los tipos de tr´afico que conviven en la Internet hacen que encontrar un algoritmo de reparto que funcione efi-cientemente 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 Engi-neering (MATE) que aparece como un paso importante en el estudio y desarrollo de esta tem´atica. En los pr´oximos cap´ıtulos se realiza un an´alisis de ´este, se discuten sus debilidades y se proponen algunas mejoras.
MPLS Adaptive Traffic
Engineering - MATE
4.1.
Introducci´
on
En este algoritmo se asume que los LSPs est´an determinados y el objetivo es poder realizar reparto de carga utilizando las variaciones en los par´ametros de la red y en funci´on de estos datos decidir cu´al es la forma ´optima de repartir la carga.
4.2.
Caracter´ısticas b´
asicas
En este trabajo se propone realizar ingenier´ıa de tr´afico 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 inter-medios.
Que no se requiera tener conocimiento de la demanda de tr´afico a priori. Que la decisi´on est´e basada en las medidas de la congesti´on en los caminos. Que no se necesite sincronizaci´on con un reloj maestro entre dos nodos.
El algoritmo MATE requiere que los LSPs ya est´en 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´on 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
Red MPLS I1 I2 E1 E2 Figura 4.1: Red MPLS
de egreso pueden solaparse y compartir los mismos recursos. Sin embargo, este trabajo mostrar´a 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´a ubicado en los nodos de ingreso. El tr´afico entrante pasa por un filtro y por una funci´on de distribuci´on cuyo objetivo es facilitar el reparto de carga a trav´es 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´afico ni la informaci´on del estado de la red.
La funci´on de ingenier´ıa de tr´afico decide cu´ando y c´omo repartir el tr´afico en los diferentes LSPs. Esto est´a basado en las estad´ısticas de los LSPs las cuales son obtenidas a partir de mediciones utilizando paquetes de prueba. Esta funci´on 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´on y pasamos a la etapa de reparto de carga. En la etapa de reparto de carga, el algoritmo intenta medir la congesti´on 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´on y an´alisis es obtener las estad´ısticas de cada LSP como son el retardo y el porcentaje de p´erdida de paquetes. Esto es realizado enviando paquetes de prueba desde el nodo de ingreso de forma peri´odica. Medidas recientes en la Internet muestran que son peque˜nas las variaciones en el tr´afico cuando consideramos intervalos de medici´on de 5 minutos [2]; es decir, que podemos afirmar que el tr´afico en Internet es cuasiconstante en intervalos de 5 minutos. Esto facilita la ingenier´ıa de tr´afico y el reparto de carga basado en mediciones estad´ısticas del estado de los LSPs.
Filtrado y
Distribución
LSP 1
LSP 2
LSP 3
Ingeniería
de tráfico
Medida y
Análisis
Paquetes entrantes
Paqutes de
Datos
Paquetes de
Prueba
LSP’s a un nodo
de egreso
Figura 4.2: Funci´on de los nodos de ingreso
4.3.
Algoritmo MATE
En eta secci´on presentaremos el modelo anal´ıtico del algoritmo MATE y probaremos su estabilidad y optimalidad desde el punto de vista matem´atico.
4.3.1. 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 Ps de LSPs disponibles. Observar que con esta definici´on
no existen dos IE diferentes que compartan el mismo LSP, aunque los diferentes LSPs pueden compartir enlaces. Entonces los Ps son conjuntos disjuntos.
Cada par IE s tiene una tasa entrante rs y tasas xsp por cada uno de los LSPs del
par s. Entonces es trivial ver que se tiene que cumplir que: !
p∈Ps
xsp= rs para todo s ∈ S
Entonces definimos xs := (xsp, p ∈ Ps) el vector de los tasas del par s, y definimos
el vector x como:
x ="xs1, xs2, . . . , xsN
#
donde los si son todos los pares de la red. (4.1)
El flujo de tr´afico sobre un enlace l ∈ L al cual llamaremos xl, es la suma de todas
las tasas que pasan por ese enlace. Entonces xl=!
s
!
l∈p,p∈Ps
xsp
Asociado a cada enlace tenemos una funci´on costo Cl(xl) que depende del flujo que esta
pasando por el enlace. Este costo puede ser el retardo en cada enlace, el porcentaje de p´erdida de paquetes, alg´un otro par´ametro de la red o bien alguna combinaci´on de ellos. Asumiremos que para cada l ∈ L la funci´on Cl es convexa (y por lo tanto continua).
Nuestro objetivo es minimizar la funci´on de costo total C(x) que se define como C(x) := $l∈LCl(xl), es decir queremos minimizar la suma de los costos de todos los
enlaces repartiendo la carga de forma ´optima por cada LSP. Nuestro problema a resolver es: m´ın x C(x) = m´ınx ! l Cl(xl) (4.2)
condicionado al espacio de condiciones: %$
p∈Psxsp = rs para todo s ∈ S.
xsp≥ 0 para todo p ∈ Ps y para todo s ∈ S.
(4.3)
A todo vector x que satisfaga las condiciones anteriores lo llamaremos vector ´optimo. Aplicando la regla de la cadena obtenemos que:
∂C ∂xsp (x) = ∂ ∂xsp ! l∈L Cl(xl) = ! l∈L ∂Cl ∂xsp (xl) =! l∈L Cl#(xl) ∂x l ∂xsp =! l∈p Cl#(xl)
donde la ´ultima igualdad se debe a que: ∂xl
∂xsp
= %
1 si l ∈ p, o sea, si el enlace l pertenece al LSP p del par s. 0 en caso contrario.
Por lo tanto se cumple que:
∂C ∂xsp(x) =
!
l∈p
4.3.2. Algoritmo as´ıncrono
La forma que utilizaremos para resolver el problema de minimizar la funci´on costo total restringida a las condiciones antes impuestas es movernos en la direcci´on del gradi-ente y luego proyectar sobre el espacio de condiciones. Es decir, cada iteraci´on toma la forma:
x(t + 1) = [x(t)− γ∇C(t)]+ (4.5) donde γ es una constante positiva (adecuadamente elegida), la funci´on C(t) = C(x(t)) y [z]+ es la proyecci´on del vector z sobre el conjunto de las condiciones; esta proyecci´on
tiene sentido puesto que el conjunto de las condiciones es un conjunto convexo y es un resultado conocido de An´alisis Funcional que siempre existe y es ´unica la proyecci´on sobre un conjunto convexo independientemente de la dimensi´on del espacio vectorial ambiente (sea finita o infinita). El algoritmo termina cuando &x(t + 1) − x(t)& < % para alg´un % predefinido.
Convexo
P
Una observaci´on importante, que hace al algoritmo muy potente, es que la iteraci´on se puede hacer en cada par sin tener que coordinar entre s´ı los pares. ´Esto surge de descomponer el vector x de la manera indicada en la ecuaci´on 4.1. Entonces la iteraci´on se puede hacer de la siguiente manera:
xs(t + 1) = [xs(t) − γ∇Cs(t)]+ (4.6)
donde Cs es la suma de los costos de los enlaces que pertenecen al par s. Es m´as, dado
que ∇Cs(t) = & ∂C ∂xsp ' p∈Ps
y recordando la ecuaci´on 4.4, cada par s´olo 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´olo conociendo el estado de los enlaces que pertenecen a sus LSPs y actualizando sus por-centajes en funci´on de ello, cada LER de ingreso est´a contribuyendo a minimizar el costo preomedio de todos los enlaces de la red.
Los siguientes resultados establecen que el algoritmo converge a un punto ´optimo, si las siguientes condiciones se satisfacen:
C2- Las funciones derivadas del costo C!
l(z) son Lipschitz en cualquier conjunto
acotado Bl⊂ R; es decir que dado Blacotado existe cltal que ∀z, z# ∈ Blse cumple
que &C!
l(z) − C
!
l(z#)& ≤ cl&z − z#&.
C3- Para todo c el conjunto {z | Cl(z) ≤ c} es acotado.
C4- El intervalo de tiempo entre actualizaciones es acotado.
Teorema 4.3.1. Bajo las condiciones C1-C4, empezando en cualquier condici´on inicial x(0), existe γ suficientemente peque˜no tal que todo punto de acumulaci´on de la sucesi´on {x(t)} es un punto ´optimo.
Un an´alisis m´as detallado muestra qu´e tan peque˜no debe ser el valor de γ, y por lo tanto la velocidad de convergencia. Si asumimos que adem´as de cumplirse C2 se cumple que las cotas cl 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 4.3.2. Una cota superior de γ para que algoritmo converja es: γ < 1
L(1 + πhλ(2t0+ 1))
(4.7) donde
π es el n´umero total de LSPs en la red.
h es el n´umero de hops en el camino m´as largo.
λ es el m´aximo n´umero de LSPs que comparten el mismo enlace.
t0 es el grado de asincronismo en las actualizaciones de los distintos LER de
in-greso.
Observaci´on 4.3.3. El Teorema nos sugiere que cuanto mayor es el grado de asincro-nismo de la red menor debe ser γ y por lo tanto el tiempo de convergencia.
La demostraci´on de estos resultados se puede leer en [2].
4.3.3. Ejemplo de una funci´on costo
La elecci´on de la funci´on costo nos determina los par´ametros de la red que deben ser medidos y ecualizados por el algoritmo MATE. Una elecci´on natural de la funci´on costo de los enlaces es el retardo.
Si tomamos el costo como el retardo medio de una cola M/M/1 tendr´ıamos que Cl(xl) = 1
cl− xl
,
donde cl representa la capacidad del enlace l. El porcentaje de p´erdida tambi´en puede
ser incorporado a la funci´on costo tomando a cada paquete perdido como un retardo fijo y grande. Otra alternativa puede ser tomar la funci´on costo como el producto del retardo y el porcentaje de p´erdida. En resumen, el objetivo esencial es llevar a la red a que se comporte de forma ´optima basados en el elecci´on de una determinada funci´on de costo.
Implementaci´
on te´
orica
5.1.
Elecci´
on de la funci´
on costo
Una de las decisiones importantes que tuvimos que tomar a la hora de implementar el algoritmo en una red real es la elecci´on de la funci´on costo a utilizar. El costo que nosotros utilizamos es el retardo Rl(xl). Es claro, que el retardo depende del flujo xl
que est´a atravesando el enlace l, pero ¿de qu´e forma depende?. Podemos deducir que el retardo es una funci´on Rl: [0, cl) → [0, +∞) creciente donde cl es la capacidad del enlace
l. Adem´as, es claro que se debe cumplir que:
Rl(0) = rmin donde rmin es un retardo m´ınimo, que est´a dado por la velocidad de
transmisi´on del enlace y por la velocidad de procesamiento de los paquetes. l´ımxl→c
lRl(x
l) = +∞.
Entonces, independientemente del modelo de tr´afico que utilicemos, y de c´omo sean sus colas, la funci´on retardo medio tiene b´asicamente la forma mostrada en la figura 5.1.
En el caso que las colas sean del tipo M/M/1 la funci´on retardo satisface la siguiente ecuaci´on,
Rl(xl) =
1 cl− xl
como se demuestra en [3].
Un punto importante a tener en cuenta es que ´este es el modelo m´as simple de retardo en un enlace y que este modelo no toma en cuenta ni el tiempo de propagaci´on ni el tiempo de paquetizaci´on.
Entonces, nuestra funci´on costo es Cl = Rl y por lo tanto
δC δxsp (xl) =! l∈p Cl#(xl) =! l∈p R#l(xl) =! l∈p R2l(xl) puesto que se cumple que R#
l(xl) = R2l(xl).
Una observaci´on importante es que para calcular R#
l(xl) no es necesario medir xl,
sola-mente necesitamos medir el retardo del enlace y luego elevarlo al cuadrado. Si quisi´eramos 19
cl
xl Rmin
Rl (retardo)
Figura 5.1: Funci´on retardo
medir xl directamente habr´ıa que tener un protocolo de comunicaci´on donde cada LSR
midiera el tr´afico que va hacia cada nodo de egreso, y transmitiera la informaci´on 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 ´estos. Adem´as, se agregar´ıan paquetes adicionales en la red para la comunicaci´on de esta informaci´on. Lo mismo suceder´ıa si los enrutadores intermedios tuvieran que medir el tama˜no de sus colas y en funci´on de ello enviaran el valor estimado del retardo del enlace a los nodos de ingreso.
Entonces la ´unica alternativa viable transparenten a los enrutadores intermedios es medir los retardos directamente con paquetes de prueba. Esto tambi´en tiene un peque˜no inconveniente cuando la red no es s´ıncrona; en una red as´ıncrona es imposible medir el retardo unilateral de un enlace, lo ´unico que se puede hacer es medir el retardo de ida y vuelta.
Teorema 5.1.1. En una red as´ıncrona no se puede medir el retardo unilateral entre dos enlaces.
Demostraci´on. La red es as´ıncrona, as´ı que supongamos que entre el host A y el host B hay una diferencia en sus relojes de t0, con t0 desconocido. Es decir que Tiempo de
B=Tiempo de A + t0.
Si en un tiempo t1 (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´aquina B, que llamaremos t2, entonces el retardo rA= (t2− t1) − t0.
An´alogamente, la m´aquina B puede hacer lo mismo y tendr´ıamos otra ecuaci´on para rB.
A
B l
resolver el sistema y por lo tanto no podemos calcular el retardo unilateral ya que ´estos son los ´unicos datos que podemos obtener.
Por la proposici´on anterior sabemos que en una red as´ıncrona s´olo podemos medir el retardo de ida y vuelta en cada enlace, y como lo que nos interesa es el retardo unilateral introducimos un par´ametro configurable δ, donde δ ∈ [0, 1] (t´ıpicamente en una red sim´etrica tenemos que δ = 1
2). Entonces
runilateral = δRmedido (5.1)
5.2.
Proyecci´
on
Luego que tenemos determinada la funci´on costo Cl(xl) = Rl(xl) y que sabemos
calcular el gradiente de ´esta ya estamos en condiciones de hacer la iteraci´on del algoritmo: xs(t) = [xs(t − 1) − γ∇Cs(t − 1)]+ (5.2)
con la funci´on costo elegida la iteraci´on queda: xs(t) = (& xsp(t − 1) − γ ! l∈p R2l(xl) ' p∈Ps )+ (5.3) donde s denota el par, p el LSP, γ es una constante que tiene que ser elegida suficiente-mente peque˜na para garantizar la convergencia y [z]+ es la proyecci´on sobre el conjunto
convexo determinado por las siguientes condiciones: %$
p∈Psxsp = rs
xsp≥ 0 ∀p ∈ Ps
(5.4) Ahora bien, una pregunta natural es, ¿c´omo hacemos esta proyecci´on?. Para respon-der a esta pregunta supongamos que tenemos un par s IE con N LSPs y que debemos
repartir una carga de rs bits/segundo. Las tasas a repartir por cada LSP las llamaremos
xs1, . . . , xsN. Se debe cumplir que:
%
xs1+ . . . + xsN = rs
xsi≥ 0 ∀i.
(5.5) Sea z el vector z = xs(t − 1) − γ$l∈pR2l(xl), nuestro objetivo es calcular el vector x
donde x = [z]+. Para realizar esta proyecci´on, en primer lugar proyectamos el vector z
en el conjunto A1 = {y ∈ RN : y1+ . . . + yN = rs} y para esto minimizamos la funci´on
f (y1, . . . , yN) = [(z1− y1)2+ . . . + (zN− yN)2]
1 2
restringida al conjunto A1; es decir, estamos hallando el vector y ∈ A1 que minimiza la
distancia al vector z, ´esta es justamente la proyecci´on de z sobre A1.
A1
z
y
Figura 5.2: Reparto de carga con dos LSPs
Es evidente que minimizar la funci´on f es an´alogo a minimizar la funci´on h = f2.
Luego aplicando el m´etodo de los multiplicadores de Lagrange, obtenemos que el vector y que minimiza la funci´on h (y por lo tanto f) restringido al conjunto A1 debe satisfacer
que: % ∇h = λ∇g donde g(y1, . . . , yN) = y1+ . . . + yN g(y1, . . . , yN) = rs (5.6) Entonces, ∂h ∂yi = λ∂g ∂yi ⇒ yi = λ 2 + zi
por otro lado y1+ . . . + yN = N λ 2 + z1+ . . . + zN = rs ⇒ λ = 2 N & rs− N ! i=1 zi '
Entonces se cumple que,
yi = 1 N & rs− N ! i=1 zi ' + zi
Hasta ahora hemos hallado el vector y ∈ A1 que es la proyecci´on de z sobre A1, 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 yi1, yi2, . . . , yik
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 = %
yi si yi ≥ 0
0 en otro caso (5.7)
y proyectarlo sobre el subespacio A2 = {y ∈ RN : yi1 = . . . = yik = 0 , $
N
i=1yi = rs}.
Este proceso se repite hasta que en alguna proyecci´on, supongamos la j-´esima, se cumpla que y(j)
i ≥ 0 ∀i, ya que la otra condici´on que necesitamos se cumple en todas las
proyec-ciones por la forma en que realizamos ´estas.
Obs´ervese que siempre vamos a encontrar un j tal que y(j)
i ≥ 0 ∀i, ya que estamos
proyectando en subespacios de dimensi´on cada vez menor y estamos partiendo de un subespacio de dimensi´on finita.
0 50 100 150 0 50 100 150 x1 x2
Reparto de la carga por cada enlace
Figura 5.3: Reparto de carga con dos LSPs
5.3.
Reparto de Carga
Despu´es de haber calculado la carga ´optima a repartir por cada uno de los LSPs de cada par, tenemos que efectivamente repartir esta carga. Para ello tuvimos en cuenta diferentes posibilidades las cuales pasaremos a describir a continuaci´on:
1. Consideremos un par IE con N posibles LSPs para repartir la carga entrante al par (ver figura 5.5). Luego de ejecutar el algoritmo, ´este nos dice que tenemos que repartir la carga de la siguiente forma: ribits por segundo por el i-´esimo LSP, donde
obviamente se cumple que $N
i=1ri = r. Definimos xi = ri/r que es el porcentaje
que representa ri en el tasa total.
Por otro lado, guardamos en una variable bi los bytes que desde la ´ultima
actual-izaci´on fueron enviados por el i-´esimo LSP. Entonces cada vez que llega un nuevo paquete al host A con destino a B el algoritmo de decisi´on calcula el m´ınimo del siguiente conjunto R = m´ın % b1 x1 , . . . ,bn xn * (5.8) si este m´ınimo es R = bk
xk el algoritmo env´ıa el nuevo paquete por el k-´esimo LSP.
2. Una variante un poco m´as compleja del algoritmo anterior es la siguiente. Supong-amos que estSupong-amos en la situaci´on del item anterior y nos llega al nodo de ingreso del par s IE un paquete de tama˜no b bytes con destino al nodo de egreso. Tenemos que decidir por cu´al de los N posibles LSPs lo vamos a enviar.
Para hacer el reparto de carga de forma ´optima lo que tendr´ıa que ocurrir es que b1 x1 = b2 x2 = . . . = bN xN (5.9)
x1 x2 x3 (0,rs,0) (rs,0,0) (0,0,rs)
Figura 5.4: Reparto de carga con tres LSPs
Entonces lo que hacemos es definir un conjunto de vectores, uno por cada LSP, que nos den informaci´on sobre cu´an cerca estamos de que se cumpla lo anterior de haberlo enviado por ese LSP. Para esto definamos el vector Dif(k), que corresponde
al k-´esimo LSP, de la siguiente manera: Primero definimos sus coordenadas,
Difij(k)= bixj− bjxi si i, j ,= k (bk+ b)xj− bjxi si i = k bixj− (bk+ b)xi si j = k (5.10) Luego, Dif(k)= & Difij(k) : i, j = 1, . . . , N ; i ,= j ' (5.11) Observaci´on 5.3.1. Es f´acil ver que Dif(k) es un vector de dimensi´on N(N − 1).
Dado un vector x en Rn se define la norma p-´esima de x como:
&x&p = & n ! i=1 xpi '1 p (5.12) Luego que llega un paquete de tama˜no b bytes hallamos los vectores:
A B LSP 1
LSP 2
LSP N
Figura 5.5: LSPs entre dos LERs
para luego calcular el de menor norma & &p y por lo tanto el que est´a m´as cerca
de satisfacer 5.9. Es por ´este donde enviamos el paquete entrante.
Esta forma de realizar el reparto de carga si bien es mejor frente a la que imple-mentamos (´ıtem (1)), es mucho m´as costosa en tiempo de c´alculo y de cantidad de operaciones a realizar, por lo cual fue descartada, dado que nuestro objetivo es realizar el reparto de carga en tiempo real y no queremos que el tiempo que se demora en realizar las operaciones sea tal que afecte la performance del algoritmo. 3. Otra posibilidad es hacer el reparto de carga respetando los agregados de flujos. Esta forma de repartir el tr´afico nos garantiza que los paquetes no lleguen en desorden, siempre y cuando las colas sean FIFO. Para ello necesitamos de cada paquete la direcci´on origen, el puerto de origen, la direcci´on de destino y el puerto de destino; luego hacemos un XOR bit a bit con cada uno de estos valores y tomamos los ´ultimos n bits (puede ser cualquier conjunto de n bits). Con estos n bits tenemos 2n combinaciones posibles lo que nos permite hacer el reparto de
carga con granularidad de 1/2n. Esta forma de hacer el reparto de carga respetando
flujos si bien tiene muchas ventajas como son no separar los flujos, garantizar que los paquetes lleguen en orden, etc., tambi´en tiene el inconveniente de que no podemos garantizar a ciencia cierta que el reparto vaya a ser hecho con los porcentajes exactos que deseamos, ya que un cierto flujo puede tener mucha m´as demanda que los dem´as.
5.4.
Mejoras al algoritmo cuando el tr´
afico no es constante
Como ya se explic´o en la descripci´on del algoritmo, el algoritmo MATE fue pensado con la hip´otesis de que el tr´afico de cada par s IE es constante y tiene una tasa conocida rs.
En una red real esto no se cumple pues el tr´afico var´ıa considerablemente con el tiem-po. Esto hace que el problema a resolver cambie esencialmente puesto que pasamos de enfrentarnos a un problema de control de convergencia a un punto ´optimo fijo a un prob-lema de control de seguimiento de un ´optimo variable. Es por esta raz´on que sentimos la necesidad de mejorar el algoritmo MATE original para que pudiera funcionar sin la restricci´on antes mencionada.
B´asicamente tuvimos que mejorar tres puntos que desarrollaremos en las siguientes secciones.
5.4.1. Trabajamos con porcentajes y no tasas
El primer punto que mejoramos es que ya no podemos trabajar m´as con tasas sino que tenemos que trabajar con porcentajes de la tasa entrante a cada par.
Si en un par s IE tenemos N posibles LSPs con una tasa entrante de rs(t), tenemos que
repartir esta tasa por los diferentes caminos de la siguiente forma: rs(t) = xs1(t) + . . . + xsN(t)
donde xsi es la tasa a enviar por el i-´esimo LSP.
La raz´on por la que no trabajamos m´as con tasas es la siguiente, consideremos la situaci´on en que se cuenta con dos LSPs hacia un par de egreso s y estamos en un estado inicial x(t0) = (x1(t0), x2(t0)) con una tasa entrante de rs(t0), como muestra la figura 5.6.
Supongamos un caso en que por el camino dos el retardo fue despreciable frente al retardo por el camino uno; claramente el algoritmo deber´ıa aumentar el porcentaje x2y disminuir
x1. Al aplicar el paso de actualizaci´on antes de la proyecci´on a las restricciones nos
ubicamos en el punto (1) de la figura. Sin embargo, al haber disminuido la tasa entrante, la proyecci´on a la restricci´on 5.4 resulta en el vector final x(t0 + 1) = (0, rs(t0 + 1))
movi´endonos hacia el lado opuesto a lo deseado.
(1) (2) x(t0) x(t0+ 1) x1+ x2 = rs(t0) x1+ x2 = rs(t0+ 1) x1 x2
Figura 5.6: Proyecci´on utilizando tasas
inicial x(t0) se corresponde con x(t0)rs(t0+ 1)/rs(t0) en la nueva tasa y por lo tanto al
proyectar nos movemos en la direcci´on esperada como muestra la figura 5.7.
x(t0) x(t0)r(tr(t0+1)0) x(t0+ 1) x1+ x2 = rs(t0) x1+ x2 = rs(t0+ 1) x1 x2
Figura 5.7: Proyecci´on utilizando porcentajes
Por lo tanto, una vez calculado xsp(t) el valor guardado debe ser el porcentaje:
ψsp(t) =
xsp(t)
rs(t)
. (5.13)
En la siguiente proyecci´on ponderamos el porcentaje guardado con la nueva tasa entrante. Por lo tanto tenemos:
xsp(t + 1) = rs(t + 1)ψsp(t) − γ
!
l∈p
R2l(xl).
A su vez, xsp(t + 1) = rs(t + 1)ψsp(t + 1), por lo que sustituyendo en la ecuaci´on anterior
y dividiendo entre rs(t + 1) a ambos lados, obtenemos la ecuaci´on de actualizaci´on antes
de la proyecci´on: ψsp(t + 1) = ψsp(t) − γ rs(t + 1) ! l∈p R2l(xl). (5.14) 5.4.2. γ adaptativo
En esta secci´on veremos que tomando como funci´on costo de los enlaces el retardo medio Rl(xl) en ellos, y asumiendo que las colas en los enrutadores son del tipo M/M/1,
no es posible encontrar un valor de γ fijo que asegure la convergencia del algoritmo. Luego propondremos un algoritmo de c´alculo de un valor de γ adaptativo, actualizado en cada intervalo, y veremos sus ventajas frente a la utilizaci´on de un valor de γ fijo.
Problema de divergencia cuando γ es fijo
En el Teorema 4.3.2 se mostr´o una cota superior del valor que debe tomar γ para asegurar la convergencia del algoritmo. Llam´emosle γmaxa dicha cota; entonces podemos
reesrcribir la expresi´on mostrada en el Teorema de la siguiente manera: γ < γmax= φ L (5.15) donde φ = 1 1 + πhλ(2t0+ 1)
es una constante a nuestros efectos dependiente de varios factores de la red, seg´un lo explicado en el Teorema 4.3.2, y L es la constante de Lipschitz, la cual depende de la funci´on costo elegida.
Ahora bien, nuestra funci´on costo es: Rl(xl) =
1 cl− xl
donde cl es la capacidad del enlace.
Esta funci´on no es Lipschitz en el intervalo [0, cl] por lo que si no aseguramos que
todo tr´afico que pase por cualquiera de los enlaces es estrictamente menor en media a la capacidad del mismo enlace, no podemos asegurar la convergencia del algoritmo MATE. Para ver esto m´as claramente supongamos que podemos asegurar que el tr´afico que pasa por un enlace nunca es mayor en media que un cierto xl
max < cl. En ese dominio la
funci´on costo s´ı es Lipshitz, por lo que bajo la suposici´on antes mencionada podemos calcular L. Veamos entonces qu´e valor toma L y su dependencia con xl
max.
Queremos entonces encontrar:
L tal que &Rl#(x1) − R#l(x2)& ≤ L&x1− x2& ∀x1, x2 ∈ [0, xmax] (5.16)
Por lo tanto queremos encontrar un valor de L que cumpla: &R#l(x1) − R#l(x2)&
&x1− x2& ≤ L
Entonces,
L = sup R##l(x) con x ∈ [0, xlmax] Es f´acil ver que
R##l(x) = 2 (cl− x)3
por lo que se obtiene que
L = sup 2 (cl− x)3 con x ∈ [0, x l max] por lo tanto: L = 2 (cl− xlmax)3 (5.17) Entonces obtenemos la cota para γ dependiente de xl
max: γmax(xlmax) = φ L(xl max) = φ 2(cl− xlmax)3 (5.18)
Ahora bien, si no conocemos el valor de xl
max o no podemos asegurar que exista, no
tenemos m´as remedio que hacer tender xl
max a cl, y es claro ver que:
γmax = φ2(cl− xlmax)3 → 0 cuando xlmax → cl
Por lo tanto, no existe ning´un valor de γ que asegure la convergencia del algoritmo si no podemos asegurar que ning´un enlace ser´a utilizado en toda su capacidad y adem´as conocemos la cota al tr´afico que pasa por cada enlace.
Propuesta de elecci´on de γ adaptativo
Acabamos de mostrar en la secci´on anterior que dado un valor de γ fijo, podemos encontrar un tr´afico tal que no podamos asegurar que el algoritmo converja. Por lo tanto deber´ıamos buscar en cada iteraci´on un valor de γ que de alguna manera tome en cuenta el tr´afico que est´a pasando por los enlaces pertenecientes a los caminos hacia el LER de destino, y se adec´ue a estos datos. En particular, si en alg´un enlace, llam´emosle lc
(enlace cr´ıtico), sucede que xlc → c
l, entonces γ deber´ıa tender a 0 seg´un lo visto en
la secci´on anterior. A continuaci´on veremos una propuesta de c´alculo de γ, efectuando primero un an´alisis intuitivo de la elecci´on de este c´alculo, y verificando posteriormente que se cumple el requerimiento mencionado anteriormente.
Si analizamos el problema intuitivamente, lo que est´a ocurriendo es que en el caso en que se est´a intentando transmitir por un enlace a una tasa mayor de su capacidad, los retardos aumentan a tal punto que el t´ermino
Sp(γ, *Rp) = γ
!
l∈p,p∈Ps
R2l(xl) (5.19)
( *Rp es el vector de los retardos en el camino p) de la ecuaci´on 5.3 puede volverse del
orden o mayor que la tasa xptransmitida por ese camino. Esto posibilita cambios bruscos
en los porcentajes enviados por cada camino, por lo que es probable que el algoritmo oscile si se dan las condiciones de tr´afico entrante a la red necesarias. Por este motivo, lo ideal ser´ıa que su valor dependiera de la tasa entrante a la red y de los retardos medidos, que son los ´unicos datos que son conocidos por el algoritmo.
Nosotros proponemos el uso de un valor de γ que se calcula en cada paso, de modo tal que el promedio de los Sp(γ, *Rp) sea menor o igual a un cierto factor ρ del promedio
de las tasas xp enviadas por cada camino. Con un valor de ρ elegido (por ejemplo, entre
0.1 y 0.2), estamos logrando que los cambios en los porcentajes var´ıen en un factor menor a ρ, por lo que acotamos las variaciones de ´estos evitando as´ı oscilaciones bruscas.
Veamos entonces el c´alculo del valor de γ en la n-´esima actualizaci´on. Comencemos la deducci´on del c´alculo suponiendo que queremos que el promedio de los Sp(γ, *Rp) sea
igual a un factor ρ del promedio de las tasas xp transmitidas por cada camino. En primer
lugar, el promedio de los xp es igual a:
$
p∈Psxp
N =
rs
donde N es el n´umero de caminos establecidos para el par s y rs es la tasa entrante. El promedio de los Sp(γ, *Rp) es $ p∈PsSp(γ, *Rp) N = ρ rs N Definiendo Z = 1 γ ! p∈Ps Sp(γ, *Rp) = ! l∈p ! p∈Ps R2l(xl) obtenemos que γZ N = ρ rs N Por lo que obtenemos el valor de γ:
γ = ρrs
Z. (5.20)
Si utilizamos esta ecuaci´on para obtener el valor de γ a utilizar en la actualizaci´on, tenemos el problema de que cuando los retardos son peque˜nos y estamos cerca del punto ´optimo, los porcentajes pueden estar variando en un factor de ρ, cuando lo ideal ser´ıa que pr´acticamente no variaran. Para ser m´as claros, si los retardos tienden a 0, y por lo tanto Z tiende a 0, γ tiende a +∞. Esto har´ıa que el algoritmo tuviera un comportamiento ruidoso cerca del punto ´optimo. Para evitar esto, proponemos la siguiente modificaci´on al c´alculo de γ:
γ = ρ rs
f (Z) (5.21)
donde f(Z) deber´ıa tener el comportamiento mostrado en la figura 5.8. Para valores de Z grandes (retardos grandes) el comportamiento del valor de γ obtenido en 5.21 pr´acticamente no cambia frente al propuesto en 5.20 ya que si Z → +∞ ⇒ f(Z) - Z. La diferencia de comportamiento aparece cuando Z es peque˜no, ya que para Z → 0, Z
f (Z) → 0
por lo que las modificaciones en los porcentajes tienden a 0, que es lo que est´abamos buscando.
Nosotros utilizamos la siguiente funci´on: f (Z) = Z + 1
m(1 + mZ) (5.22)
Antes de explicar la raz´on del factor m, veamos que f(Z) cumple con las propiedades requeridas.
1. f(Z) - Z cuando Z → ∞ 2. f(Z) → 1
m > 0 cuando Z → 0 ⇒ f (Z)Z → 0 cuando Z → 0
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 0 1 2 3 4 5 6 Gráfica de f(Z) Z f(Z) Figura 5.8: Gr´afica de f(Z)
El coeficiente m es una variable de ajuste que se calcula a partir del retardo m´ınimo esperado en un enlace. La motivaci´on de agregar este par´ametro de ajuste es que siempre vamos a tener un retardo m´ınimo en cada enlace debido al tiempo de propagaci´on en el enlace y procesamiento del paquete. Esto hace que dada una cierta topolog´ıa, Z va a ser siempre mayor a un Zmin que se obtendr´ıa al tener todas las colas de todos los
enrutadores vac´ıas. El valor de m se calcula de manera que Zmin
f (Zmin)
= 0,1
por lo que en el caso de estar cerca de este valor, y por lo tanto cerca del mejor caso posible, las variaciones en las actualizaciones sean del orden de ρ
10. Calculemos ahora el
valor de m. Lo que queremos obtener es:
f (Zmin) = Zmin+ 1
m(1 + mZmin)
= 10Zmin
Despejando m obtenemos la siguiente ecuaci´on de segundo grado: (9Zmin2)m2+ (9Z min)m − 1 = 0 por lo tanto, m = √ 117 − 9 9 ∗ Zmin ∼ = 0,2 Zmin (5.23) Zmin es un dato para el algoritmo. En el caso de nuestra implementaci´on decidimos
que el par´ametro a configurar sea el retardo m´ınimo en los enlaces. Si los retardos m´ınimos son diferentes en los distintos enlaces de la red, se deber´ıa elegir un valor promedio de ellos. Se elige
en donde L es la suma de la cantidad de enlaces de cada camino, y Rmin es el retardo
m´ınimo que se ingresa como par´ametro.
Ahora bien, recordando el paso de actualizaci´on definido en 5.3, obtenemos que el paso a efectuar con el γ adaptativo es:
xp(t) = xp(t − 1) − ρrs(t)
$
l∈pR2l(xl)
f ($l∈p$p∈PsR2l(xl)), ∀p ∈ Ps (5.24)
Sustituyendo los valores de xp(t) y xp(t − 1) seg´un la ecuaci´on 5.14 obtenemos que la
tasa rs(t) se cancela a ambos lados de la igualdad anterior obteniendo la actualizaci´on
de porcentajes en cada camino: ψp(t) = ψp(t − 1) − ρ $ l∈pR2l(xl) f ($l∈p$p∈PsR2 l(xl)) , ∀p ∈ Ps (5.25)
Esto tiene la gran ventaja de que no es necesario saber, y por lo tanto medir, la tasa de entrada de paquetes que se enrutan hacia cada par de egreso.
An´alisis formal del comportamiento de γ en funci´on del tr´afico xl
Ahora veamos qu´e sucede con el valor de γ calculado seg´un lo expuesto en la secci´on anterior cuando un enlace se ve sobrecargado, llam´emosle a dicho enlace cr´ıtico lc. Para
ello, hagamos tender xlc a c
lc y veamos qu´e valor toma γ.
Si xlc → c
lc entonces Rlc(xlc) → +∞, por lo tanto
Z =! l∈p ! p∈Ps R2l(xl) - Rlc(x lc) = R2 c entonces f (Z) = Z + 1 m(1 + mZ) - R 2 c+ 1 m(1 + mR2 c) -R2c por lo que γ = ρ rs f (Z) - ρ rs R2 c → 0
que es lo que quer´ıamos lograr.
En el caso m´as general de N enlaces, llam´emosle li a los enlaces cr´ıticos; entonces,
por un razonamiento an´alogo al anterior es f´acil ver que γ → ρ$ rs
R2li(xli)
5.4.3. Intervalo adaptativo entre actualizaciones
El tercer punto a tomar en cuenta es que al no ser el tr´afico constante los intervalos de tiempo entre actualizaciones deben ser tales que se adapten a las caracter´ısticas del tr´afico entrante, es decir que si la variaci´on en el tr´afico aumenta, los intervalos de tiempo entre actualizaciones deber´ıan disminuir. Nuestro objetivo es lograr que las caracter´ısticas del tr´afico entrante sean cuasiconstantes en los intervalos de tiempo entre actualizaciones, de modo de no estar demasiado alejado de las hip´otesis del algoritmo MATE.
0 20 40 60 80 100 120 0.5 1 1.5 2 2.5 3 3.5 4 4.5
Gráfica del tráfico entrante en función del tiempo
Tiempo (t)
Tráfico entrante
Para lograr lo anterior tenemos b´asicamente dos alternativas.
La primera de ellas es elegir un dt suficientemente peque˜no (dt es el tiempo entre actualizaciones), ya sea por la experiencia que haya del tr´afico de la red o ya sea porque no tiene sentido actualizar cada intervalos menores. Esto quiere decir que variaciones en el tr´afico de duraci´on menor que dt ser´an consideradas ruido para nuestro modelo, por ejemplo, no tiene sentido actualizar cada intervalos de tiempo menores que 30 segundos, ya que en un intervalo de tiempo de tan corta duraci´on no se puede extraer informaci´on estad´ıstica confiable sobre el estado de la red.
La otra alternativa es que el intervalo de tiempo entre actualizaciones sea adaptativo en funci´on de las caracter´ısticas del tr´afico. En el intervalo entre actualizaciones, dt, nosotros tomamos k mediciones del retardo en los enlaces para conocer su estado. A el valor de los retardos en el enlace l en las diferentes mediciones los llamaremos Xl
1, . . . , Xkl.
Tenemos dos problemas a resolver, el primero es c´omo adaptar el intervalo de tiempo dt para que el tr´afico sea cuasiest´atico en este intervalo y el otro es determinar cu´antas mediciones deben realizarse en este intervalo para obtener una estad´ıstica confiable.
Suponiendo que realizamos k mediciones de los retardos en el intervalo dt, X1, . . . , Xk
que modelaremos como variables aleatorias independientes e id´enticamente distribuidas (iid) con funci´on de distribuci´on F y E(Xi) = µ, entonces por la Ley fuerte de los
grandes n´umeros sabemos que si definimos Sk:= X1+ . . . + Xk se cumple que:
P"Sk k → µ
#
Ahora bien, nosotros no vamos a poder contar con infinitas mediciones de los retardos por lo que deber´ıamos encontrar un valor finito de mediciones en la cual la probabilidad de que el promedio de estas mediciones est´e alejado de la media real sea menor a un cierto % dado. Es decir, queremos hallar k tal que:
P"///Sk k − µ
/ /
/ > ξ#< % (5.27) para un cierto % y ξ adecuadamente elegidos.
Para ello utilizamos la Teor´ıa de las grandes desviaciones y en particular el Teorema de Chernof [3]. Este Teorema nos garantiza que en las hip´otesis anteriores se cumple que:
P"///Sk
k − µ
/ /
/ > ξ#< e−kG(ξ) donde G es una funci´on que s´olo depende de F .
Luego, elegimos ξ y % con alg´un criterio y calculamos k para que se cumpla que: P"///Sk
k − µ / /
/ > ξ#< % (5.28) tenemos que tomar k tal que:
e−kG(ξ)≤ %
y por lo tanto se debe cumplir que
k≥ − ln(%)
G(ξ) (5.29)
Entonces, la probabilidad que el promedio de las k mediciones caiga fuera del intervalo Iµξ := [µ−ξ, µ+ξ], como muestra la figura 5.9, es menor que %. Adem´as, nosotros tomamos
un intervalo de confianza Iµν = (µ − ν, µ + ν) donde ν > ξ.
µ Iµν Iµξ
Figura 5.9: Intervalos
En el caso que el promedio de las mediciones, Sk/k, caiga fuera del intervalo Iµν
podemos afirmar con certeza que las caracter´ısticas del tr´afico est´an variando en el in-tervalo dt. Esto quiere decir que no estamos teniendo un tr´afico cuasiest´atico por lo que
