Proyecto MONTE. Mpls ONline Traffic Engineering. Documentación de Proyecto de Grado

Transcripción

1 Proyecto MONTE Mpls ONline Traffic Engineering Documentación de Proyecto de Grado Ingeniería Eléctrica Isabel Amigo Fernández Bernardo Cabrera Maisonnave Juan Schandy Wood Tutores: Pablo Belzarena, Gabriel Gómez Facultad de Ingeniería Universidad de la República Montevideo, Uruguay Setiembre 2007

2

3 Agradecimientos A nuestras familias y amigos, por el apoyo brindado a lo largo de toda la carrera. A nuestros tutores, Pablo Belzarena y Gabriel Gómez, quienes nos propusieron un proyecto de trabajo interesante y depositaron su confianza en nosotros. A docentes y compañeros, especialmente a Andrés Ferragut cuyos aportes fueron de gran utilidad.

4

5 Tabla de contenidos I Planteo del Problema 1 1. Introducción Objetivos Motivación Contexto de trabajo Estructura del documento Conceptos fundamentales Ingeniería de Tráfico Objetivos Control de tráfico y recursos Ingeniería de Tráfico en línea y fuera de línea Medidas en la red MPLS: Multiprotocol Label Switching Generalidades Operaciones básicas Distribución de etiquetas Ingeniería de Tráfico en MPLS Gestión de redes MPLS Generalidades SNMP: Simple Network Management Protocol Soluciones propietarias de los fabricantes Conclusiones Estado del arte en Ingeniería de Tráfico Introducción

6 3.2. Relevamiento de la red Descubrimiento de la topología física Descubrimiento de la topología virtual Obtención de parámetros de performance Realización de medidas activas Consultas de parámetros locales a los nodos Conclusiones Reconfiguración en redes MPLS Utilización del protocolo SNMP Configuración manual del nodo Utilización de los protocolos PCEP o COPS Conclusiones Algoritmos de Ingeniería de Tráfico en línea Algoritmos de CBR Algoritmos de balance de carga Algoritmos de reenrutamiento Conclusiones Herramientas de Ingeniería de Tráfico en línea Sequin: An SNMP-Based MPLS Network Monitoring System RATES: Routing and Traffic Engineering Server RONDO Herramientas propietarias de los fabricantes Conclusiones Conclusiones II Solución Implementada Arquitectura RMA: Routing and Management Agent Conclusiones Módulo Topología Objetivo Solución implementada

7 Información recolectada Pre- configuración Algoritmo Notificaciones Conclusiones Módulo Monitorización Objetivos Solución implementada Descubrimiento de la topología virtual Obtención de asociaciones de FECs con LSPs Obtención de parámetros de performance Conclusiones Módulo TE Objetivos El algoritmo MATE Formulación matemática El método de proyección del gradiente El algoritmo asíncrono La versión para tráfico no constante y la elección de γ adaptativo Cálculo de la proyección Solución implementada El bloque detección El bloque acción Conclusiones Módulo Señalización Objetivos Solución Implementada Configuración y baja de LSPs Modificación de LSPs establecidos Asociación de tráfico a los LSPs Conclusiones

8 9. Almacenamiento e Intercambio de Información Introducción Modelo de información Solución implementada Módulo DB Solución implementada Protocolo GRMAP Conclusiones Interfaz de Gestión Objetivo El software Net-TE Solución Implementada Adaptación al modelo de información Adaptación a la arquitectura modular Mejoras en la interfaz gráfica Despliegue y procesamiento de la información de performance obtenida de la TED Integración de las distintas versiones Conclusiones Ingeniería de Software Introducción Análisis y diseño Módulo Topología Módulo Monitorización Módulo TE Otros Módulos Implementación Despliegue III Validación y Conclusiones Validación Introducción

9 12.2. Criterios de Éxito Módulo Topología Descubrimiento de la topología física Conclusiones Módulo Monitorización Descubrimiento de LSPs Obtención de parámetros de performance Conclusiones Módulo Señalización Alta de LSPs Baja y cambio de LSPs Funcionamiento como servidor Conclusiones Módulo TE Verificación de hipótesis Pruebas realizadas Resultados del algoritmo MATE Conclusiones Conclusiones y trabajo a futuro 149 Bibliografía 151 A. MIBs 155 A.1. MIBs Utilizadas A.2. MIB para la comunicación con Metronet B. Red de Pruebas 159 B.1. Red de pruebas C. Aspectos de gestión del proyecto 161 C.1. Plan de Proyecto C.2. Evaluación de planificación D. Contenido del CD 175

10

11 Índice de figuras 2.1. Proceso de Ingeniería de Tráfico Reenvío de paquetes MPLS. Penultimate Hop Popping Tablas de reenvío MPLS del LER A Tablas de reenvío MPLS del LSR Tablas de reenvío MPLS del LSR IP sin reparto de carga IP con reparto de carga MPLS con reparto de carga Ejemplo de un sistema de gestión Arquitectura del proyecto Sequin. Fuente: [22] Algoritmo del proyecto Sequín para detección de anomalías. Fuente: [22] Arquitectura RATES. Fuente: [24] Arquitectura RONDO. Fuente: [23] Arquitectura RMA. Fuente: [41] Arquitectura implementada OSPF-MIB MIB-II Ejemplo: descubrimiento de la topología física Algoritmo de Topología MPLS-TE-MIB Algoritmo de descubrimiento de LSPs Algoritmo de obtención de parámetros locales Algoritmo de obtención de parámetros de extremo a extremo

12 7.1. Algoritmo de Ingeniería de Tráfico MATE. Fuente: [37] Proceso de detección de congestión Diagrama de estados. Módulo TE Topologías para la simulación Resultados de la simulación XML PathResponse. Alta de caminos Flujo de mensajes en la configuración de un LSP Modelo de Información. Dominio Modelo de Información. Topología Modelo de Información. MPLS Modelo de Información. Tipo definido para modelar FECs Modelo de Información. Statistics Encabezado de un paquete del protocolo GRMAP Ventanas para la comunicación con otros módulos Algunas funcionalidades gráficas incorporadas Visualización de estadísticas Interfaz gráfica del software Net-TE Diagrama de casos de uso. Módulo Topología Modelo conceptual. Módulo Topología Diagrama de secuencia. Módulo Topología Diagrama de paquetes. Módulo Topología Diagrama de casos de uso. Módulo Monitorización Modelo conceptual. Módulo Monitorización Diagrama de interacción general. Módulo Monitorización Detalle 1 diagrama de interacción. Módulo Monitorización Detalle 2 diagrama de interacción. Módulo Monitorización Diagrama de paquetes. Módulo Monitorización Diagrama de Casos de Uso. Módulo TE Modelo conceptual. Módulo TE Diagrama de interacción. Módulo TE. Detección de Congestión Diagrama de paquetes. Módulo TE Paquetes comunes

13 11.16.Diagrama de despliegue Tiempos del Módulo Topología Tiempo de relevamiento de LSPs. Comparación implementación en serie y paralelo Tiempo de relevamiento de LSPs. Comparación de la implementación con y sin TFTP Tiempo de relevamiento de parámetros de performance. Impacto de las medidas extremo a extremo Prueba tipo realizada en la maqueta Relevamiento curva de Retardo en función de la carga Búsqueda del reparto de carga óptimo Histograma. Puntos de Convergencia algoritmo MATE Reparto de carga y retardos a lo largo de la actuación del algoritmo A.1. Metronet MIB I A.2. Metronet MIB II B.1. Maqueta utilizada para las pruebas C.1. Arquitectura RMA C.2. Topología C.3. Performance C.4. Algoritmo TE C.5. Reconfiguración C.6. Documentación C.7. Implementación C.8. Diagrama de Gannt

14

15 Índice de tablas 3.1. Comparación de las herramientas C.1. Cuantificación de riesgos C.2. Cronograma C.3. Entregable D.1. Estructura de carpetas del CD

16

17 Listado de Acrónimos y Sigloides ARP: Address Resolution Protocol ATM: Asynchronous Transfer Mode CBR: Constrained Based Routing CLI: Command Line Interface COPS: Common Open Policy Service CSPF: Constrained Shortest Path First DB: Data Base DIFFSERV: DIFFerentiated SERVices FEC: Forwarding Equivalence Class IANA: Internet Assigned Number Authority IETF: Internet Engineering Task Force IGP: Interior Gateway Protocol INTSERV: INTegrated SERvices IP: Internet Protocol LDP: Label Distribution Protocol LER: Label Edge Router LSP: Label Switched Path LSR: Label Switching Router MATE: Multipath Adaptive Traffic Engineering MIB: Management Information Base MPLS: MultiProtocol Label Switching OID: Object IDentifier OSPF: Open Shortest Path First PCC: Path Computation Client PCE: Path Computation Element PCEP: Path Computation Element Protocol QOS: Quality Of Service RFC: Request For Comments RMA: Routing and Management Agent RSVP: Resource-ReSerVation Protocol SMI: Structure of Managed Information SNMP: Simple Network Management Protocol SSH: Secure SHell TCP: Transmission Control Protocol TE: Traffic Engineering 17

18 TED: Traffic Engineering Database TFTP: Trivial File Transfer Protocol VPN: Virtual Private Network XML: extensible Markup Language

19 Resumen Desde hace algunos años los servicios brindados a través de redes de telecomunicaciones han ido creciendo y han surgido distintas ofertas, cada una con sus requerimientos. Los operadores están en la búsqueda continua de la integración de todos los servicios a una misma red, de manera de poder abaratar costos, simplificar el mantenimiento, la operación y gestión de las mismas, y aprovechar las ventajas del multiplexado estadístico. Las técnicas mayoritariamente utilizadas para cursar el tráfico correspondiente a los distintos servicios por una red, son aquellas basadas en algoritmos de optimización de camino más corto. Si bien esto es óptimo desde el punto de vista del camino atravesado, no lo es desde el punto de vista del aprovechamiento de los recursos existentes ni de la calidad que percibe el tráfico cursado. Es denominador común de las redes dorsales la existencia de redundancia en sus caminos, ya que los requerimientos de disponibilidad que tienen las mismas así lo exigen. Es por esto que se asegura que si el tráfico sobre una red está siguiendo el camino más corto no estará haciendo uso de todos los recursos disponibles en la red para llegar a un destino determinado. Se hace evidente, por lo tanto, que el uso actual que se le da a las redes de telecomunicaciones requiere trabajo en pos de mejorar dos grandes aspectos: la mejor utilización de los recursos disponibles y la calidad de servicio ofrecida al tráfico sobre ella cursante. Es en este contexto que toma protagonismo la Ingeniería de Tráfico; disciplina que estudia cómo mapear flujos de tráfico en una red, buscando distintos criterios de optimización. Surge también la tecnología Multiprotocol Label Switching como una de las más atractivas para que la Ingeniería de Tráfico sea una realidad. Esta tecnología permite controlar el camino que sigue un agregado de tráfico, realizar reparto de carga y presenta la gran ventaja de integrarse perfectamente a la tecnología dominante en redes dorsales: Internet Protocol (IP). Este trabajo trata del estudio de la Ingeniería de Tráfico en línea en redes Multiprotocol Label Switching. Se hace un estudio teórico de la temática, se recolectan, estudian y presentan herramientas que la abordan, y se hace una propuesta de solución al problema. Dicha solución fue implementada en software y comprende el ciclo completo de Ingeniería de Tráfico: descubrimiento y monitorización de la red, detección de congestión, un algoritmo correctivo y la señalización de los cambios calculados por el algoritmo, en la red. Toda la solución fue concebida e implementada buscando actuar en tiempo real. En este texto se presentan los detalles teóricos 19

20 de la solución y se da una descripción pormenorizada de la implementación de la misma. Se muestran también resultados que validan el correcto funcionamiento de la herramienta elaborada los cuales fueron obtenidos mediante pruebas en una red real. Palabras claves: Multiprotocol Label Switching, Ingeniería de Tráfico en Línea, Balance de Carga, Monitorización de performance de redes, Gestión de redes MPLS.

21 Parte I Planteo del Problema

22

23 Capítulo 1 Introducción En este capítulo se presentan los objetivos del proyecto, la motivación y el contexto de trabajo en el que se enmarca. Se presenta a su vez la estructura de todo el documento Objetivos El objetivo principal de este proyecto es el estudio de la Ingeniería de Tráfico en línea en redes MPLS. Se hace una presentación teórica del problema, estudia el estado del arte y realiza un software que presente soluciones al mismo. El mismo debe funcionar en una red real. Por otro lado, este proyecto se enmarca dentro del convenio entre la Facultad de Ingeniería de la Universidad de la República y la empresa ANTEL 1 denominado Red Metropolitana Multiservicio, que plantea la construcción de una red piloto multiservicio metropolitana con el objetivo de probar aplicaciones y servicios con garantías de calidad. Como consecuencia se utilizó la mencionada red para probar la aplicación desarrollada Motivación El constante crecimiento de las redes de telecomunicaciones y la aparición de nuevos servicios ha llevado a los operadores a pensar en redes convergentes. Hace algunos años un operador tenía su red telefónica cuyos requisitos eran poder transportar conversaciones de voz. Luego surgió la necesidad de brindar servicios de datos, video, y telefonía fija y móvil, por lo que los operadores comenzaron a instalar nuevas redes, con distintas características según el servicio que transportaban. Esto trajo la desventaja de que los operadores debieron comenzar a gestionar muchas tecnologías, además de desaprovechar el multiplexado estadístico en el agregado de tráfico. 1 Administración Nacional de Telecomunicaciones, empresa estatal que brinda servicios de telefonía fija y móvil y de acceso a Internet 3

24 4 Capítulo 1. Introducción Paralelamente la tecnología IP fue tomando protagonismo en el mundo de las telecomunicaciones, principalmente debido a su simplicidad y la economía de escala que logró alcanzar. Las redes IP fueron pensadas para funcionar en la modalidad de mejor esfuerzo, es decir se hace lo posible por que el mensaje llegue a destino pero a la vez se garantiza poco. Hubo muchos intentos por integrar todas las redes en nueva red convergente con nuevas tecnologías como por ejemplo ATM, pero ninguna logró alcanzar la economía de escala de IP. Como consecuencia, los operadores y el mundo académico comenzaron a estudiar maneras de transportar diversos servicios sobre el protocolo IP. Pero como se mencionó anteriormente, IP es un protocolo de mejor esfuerzo que si bien permite facilitar el ruteo y escalar grandes redes, no da garantías en cuanto a retardo, pérdida de paquetes ni ancho de banda. Así surge la Ingeniería de Tráfico, una disciplina que estudia cómo mapear la demanda de tráfico en una red permitiendo dar ciertas garantías a los distintos flujos. La simplicidad del protocolo IP tiene como contrapartida que hace muy difícil realizar Ingeniería de Tráfico. Prácticamente la única herramienta es modificar los pesos de los enlaces en el protocolo de ruteo, con lo que no se logra mucha versatilidad. Fue con la aparición de la tecnología MPLS, cuando comenzó a ser una realidad la idea de realizar Ingeniería de Tráfico y a la vez mantener las ventajas que habían popularizado al protocolo IP. La tecnología MPLS da la posibilidad de mapear el tráfico eficientemente en la topología de la red, lo que permite garantizar ciertos parámetros de calidad asociados al tráfico y un mejor aprovechamiento de los recursos. Esto permite dimensionar las redes eficientemente de acuerdo al tráfico que van a cursar. El problema es que si por razones inesperadas el comportamiento del tráfico cambia, pueden congestionarse ciertas zonas de la red degradando la calidad del servicio. Para abordar dicho problema, el presente proyecto pretende estudiar la manera de monitorizar una red, detectar cuándo aparecen situaciones de congestión e intentar eliminarlas. Esto se conoce como Ingeniería de Tráfico en línea, debido a que debe funcionar en tiempo real Contexto de trabajo Debido a que el presente proyecto no surgió ni se desarrolló de manera aislada, es interesante relatar en unas breves líneas el contexto del mismo y el impacto que tuvo en su desarrollo. El proyecto se enmarca en la subactividad 2 del convenio entre Facultad de Ingeniería y ANTEL, denominada Gestión de Calidad de Servicio en Redes Convergentes basadas en MPLS. En él trabaja un grupo conformado por docentes del IIE 2, docentes del INCO 3, y profesionales de ANTEL, en diversos temas dentro de los cuales 2 Instituto de Ingeniería Eléctrica, Facultad de Ingeniería, Universidad de la República. 3 Instituto de Computación, Facultad de Ingeniería, Universidad de la República.

25 1.4. Estructura del documento 5 se incluyen los tratados en este proyecto. El mencionado convenio tiene como antecedente un proyecto denominado Red Metropolitana Multiservicio que dejó como uno de sus resultados una maqueta de pruebas con equipos MPLS. El contacto con ese grupo de trabajo permitió que se conocieran otros proyectos de grado que se estaban desarrollando, tanto en el INCO como en el IIE, en el marco del mismo convenio. En particular, lo mencionado en los párrafos anteriores trajo dos grandes consecuencias al proyecto, las que se detallan a continuación. La primera fue la decisión de trabajar junto con el grupo RMA Control del INCO [41]. El trabajo en conjunto con un grupo de estudiantes de otra rama de la Ingeniería sin duda agregó un nuevo desafío al proyecto. La coordinación, la puesta en común y el tener que ajustarse al calendario previsto en todo momento, fueron nuevas dificultades que se tuvieron que enfrentar. No obstante, desde un principio se confió en que esto no sólo enriquecería los resultados obtenidos en el proyecto, sino que también tendría grandes aportes en la experiencia adquirida por todos los involucrados. La segunda fue contar con una red de pruebas. Esto permitió comprender el funcionamiento de diversos aspectos de las redes de datos, contrastar lo teórico con lo práctico y probar las herramientas implementadas Estructura del documento En la parte I se presenta el planteo del problema. Se estudian los conceptos teóricos fundamentales necesarios para comprender el resto del documento y el estado del arte en Ingeniería de Tráfico en línea en redes MPLS. Se exponen las distintas posibilidades estudiadas para la realización de la herramienta de software, así como una discusión de sus ventajas y desventajas aplicadas al problema en estudio. Luego, en la parte II se detalla la solución implementada. Se presenta la arquitectura elegida para construir la herramienta, la descripción detallada de la implementación de cada módulo que la compone y la ingeniería de software realizada. Finalmente en la parte III se presentan las conclusiones y pruebas realizadas. Se analiza el funcionamiento de la herramienta desarrollada, las pruebas de performance y el cumplimiento de los objetivos planteados. Por último se presentan los lineamientos para el trabajo futuro.

26

27 Capítulo 2 Conceptos fundamentales En este capítulo se presentan los conceptos fundamentales que permiten comprender el resto del documento. Se explican los conceptos de Ingeniería de Tráfico, MPLS y distintas alternativas para la gestión automática de redes Ingeniería de Tráfico La Ingeniería de Tráfico es un proceso de evaluación y optimización de la performance de una red. Comprende la medida, modelado, caracterización y control del tráfico, y la aplicación de técnicas para alcanzar determinados objetivos en cuanto a performance. Cuando se diseña o amplía una red se debe predecir la demanda de tráfico y en base a eso se realiza el dimensionamiento. Este proceso se conoce como ingeniería de red. El problema es que no siempre se conoce a priori el comportamiento que tendrá el tráfico y tampoco se puede sobredimensionar la red, por una razón económica. Esto lleva a que cuando la red entra en servicio, aparezcan zonas congestionadas y otras con capacidad ociosa. Es aquí donde se aplica la Ingeniería de Tráfico, que permite por ejemplo mover el tráfico de las zonas congestionada a las zonas con capacidad disponible Objetivos Los objetivos de la Ingeniería de Tráfico pueden clasificarse en dos grandes grupos: orientados a tráfico y orientados a recursos. Los objetivos orientados a tráfico buscan brindar calidad de servicio al tráfico de la red. El concepto de calidad de servicio puede involucrar, entre otros, minimizar la pérdida de paquetes, minimizar retardos o maximizar el flujo. Por ejemplo, para un tráfico de voz comprimida es importante minimizar el retardo y la pérdida de paquetes, mientras que para la transferencia de un archivo es importante maximizar el flujo de datos. Por otro lado, los objetivos orientados a recursos buscan principalmente el uso 7

28 8 Capítulo 2. Conceptos fundamentales racional de los mismos. Es importante que no haya zonas de la red congestionadas mientras que otras estén cursando poco tráfico. En general buscan el manejo eficiente del ancho de banda. Usualmente los objetivos que buscan los operadores son una mezcla de los dos tipos. Se busca cumplir con los requerimientos del tráfico utilizando los recursos de la red de manera económica y eficiente Control de tráfico y recursos La Ingeniería de Tráfico se puede ver como un proceso de control realimentado, como muestra la figura 2.1. Figura 2.1: Proceso de Ingeniería de Tráfico. El proceso consiste en que, dados ciertos requerimientos o políticas de tráfico, el bloque de control TE debe traducirlos en cambios a realizar en la red y el bloque de configuración debe reflejarlos en la misma. El lazo de realimentación es la monitorización del estado de la red. Las acciones típicas de control son: la modificación de los parámetros asociados al ruteo y la modificación de los parámetros y atributos asociados a los recursos Ingeniería de Tráfico en ĺınea y fuera de ĺınea Es posible identificar dos formas de abordar la Ingeniería de Tráfico: en línea y fuera de línea. La diferencia reside en que la Ingeniería de Tráfico en línea se realiza en tiempo real y en conexión con la red, mientras que la fuera de línea no presenta el requerimiento de tiempo y se puede realizar de manera aislada. La Ingeniería de Tráfico fuera de línea consiste en tomar estadísticas o predicciones del tráfico a cursar, y buscar soluciones óptimas para mapearlo en los recursos de la red. Generalmente se tiene en cuenta la optimización de toda la red e involucra complejos cálculos. Como resultado puede ser necesario cambiar la configuración de toda la red, lo que en general es costoso para los operadores.

29 2.1. Ingeniería de Tráfico 9 La Ingeniería de Tráfico en línea se realiza en tiempo real e involucra la monitorización permanente del estado de la red. Permite resolver problemas rápidamente, como la congestión inesperada en un enlace o la reasignación de tráfico cuando un enlace se cae. En general, los cálculos son más simples que fuera de línea, ya que no se busca un óptimo de toda la red. La Ingeniería de Tráfico en línea debe usar mecanismos que garanticen estabilidad. Además, se trata de hacer la menor cantidad de cambios posibles en la red para no distorsionar el tráfico que se está cursando. Las dos formas presentadas anteriormente en realidad son complementarias. Generalmente los operadores usan una combinación de ellas. Cada cierto tiempo calculan fuera de línea los caminos, y luego corren una herramienta en línea que los ajusta a las variaciones del tráfico. Además de en línea o fuera de línea, la Ingeniería de Tráfico se puede hacer desde un enfoque centralizado o distribuido. La Ingeniería de Tráfico fuera de línea se realiza típicamente en forma centralizada, es decir, hay un equipo fuera de la red que produce todos los cálculos y computa los caminos a configurar. Por otro lado la Ingeniería de Tráfico en línea puede ser tanto centralizada como distribuida. En el enfoque centralizado hay un nodo que de alguna manera monitoriza la red y decide los cambios a realizar, mientras que en el enfoque distribuido cada nodo, o un grupo de nodos estratégicos, se encarga de realizar los cambios Medidas en la red Las medidas del estado de la red son un elemento fundamental para realizar Ingeniería de Tráfico. Son importantes no sólo porque permiten conocer el estado de la red sino porque son el mecanismo de realimentación para la herramienta que realiza Ingeniería de Tráfico. También permiten determinar la calidad del servicio que se está brindando en la red, por ejemplo, para verificar un SLA (Service Level Agreement, Acuerdo de Nivel de Servicio) firmado con un cliente. A la hora de realizar las medidas surgen varias consideraciones a tener en cuenta. Se debe estudiar qué parámetros se deben medir, cómo se debe realizar la medida, cuándo y con qué frecuencia se debe ejecutar y qué grado de precisión es necesario. Existen dos formas de realizar medidas en una red: activas y pasivas. Las medidas activas son las que por el proceso de medida se afecta el objeto a medir. Un ejemplo de medida activa para medir el retardo sería inyectar en la red paquetes de prueba y medir su retardo. El hecho de inyectar tráfico en la red modifica su estado lo que hace que se deba ser muy cuidadoso a la hora de realizar estas medidas. En contraposición a éstas, las medidas pasivas son aquellas que no afectan el objeto a medir. Por ejemplo, consultar el valor de un contador de paquetes descartados por una interfaz. Además, las medidas pueden ser directas o indirectas. Las medidas indirectas son de utilidad cuando es difícil obtener el valor de un parámetro directamente, pero es sencillo estimarlo a partir de otro. Por ejemplo, el ancho de banda de un LSP se puede estimar como el ancho de banda del enlace de menor capacidad que atraviesa.

30 10 Capítulo 2. Conceptos fundamentales 2.2. MPLS: Multiprotocol Label Switching Generalidades La sigla MPLS significa Multiprotocol Label Switching, un protocolo de capa de enlace de la IETF definido en la RFC 3031 [5]. Entre sus principales ventajas se encuentran las siguientes: Facilita la implementación de redes privadas virtuales (VPNs). Permite realizar Ingeniería de Tráfico Permite independizar los protocolos de capas superiores de la tecnología de transporte utilizada. La idea central del protocolo es independizar la función de ruteo de la de reenvío. Por función de ruteo se entiende calcular el camino que va a seguir la información en la red, mientras que la función de reenvío se refiere a la manera en que se envían los paquetes, teniendo en cuenta el camino mencionado anteriormente. En IP cada enrutador corre un algoritmo para construir su tabla de ruteo y al recibir un paquete elige el próximo salto de acuerdo a lo indicado en ella. El ruteo es de tipo hop by hop, es decir que cada enrutador elige el próximo salto teniendo en cuenta sólo el destino del paquete y cuál es el camino más corto para llegar a él en términos de alguna métrica. En MPLS se intenta por un lado simplificar el reenvío de los paquetes en los enrutadores y por otro brindar la posibilidad de realizar ruteo explícito. Para eso se introduce el concepto de FEC, o clase de equivalencia de reenvío, que es una partición del conjunto de todos los paquetes posibles. Una FEC consiste en un grupo de paquetes que serán reenviados de la misma manera. La clasificación de paquetes en FECs se hace solamente en el enrutador de ingreso, quien coloca una etiqueta de tamaño fijo al paquete. El resto de los enrutadores solamente deben saber interpretar e intercambiar las etiquetas. Finalmente, el enrutador de salida debe quitar la etiqueta y reenviar el paquete de igual manera que un enrutador IP. Se denomina LSP al camino de etiquetas conmutadas o LSP por el que se reenvían paquetes Operaciones básicas Existen básicamente tres operaciones que puede realizar un enrutador de MPLS con las etiquetas: PUSH, POP, y SWAP. La operación SWAP es la más simple de todas y debe ser implementada por todos los enrutadores MPLS. Consiste en recibir un paquete etiquetado, examinar su etiqueta, cambiarla por otra y reenviarlo. La operación PUSH consiste en agregar una etiqueta al comienzo del paquete. Esta operación puede ser realizada por el enrutador de ingreso a la red para eti-

31 2.2. MPLS: Multiprotocol Label Switching 11 quetar un paquete IP, o por otro enrutador para producir una pila de etiquetas. La posibilidad de apilar etiquetas permite realizar ruteo jerárquico y agregación de LSPs. La operación POP consiste en quitar una etiqueta del paquete. En el caso más simple en que el paquete tiene una etiqueta, el enrutador de salida la quita dejándolo tal como estaba antes de ingresar a la red MPLS. Para evitar que el enrutador de salida deba inspeccionar tanto el encabezado de MPLS como el de IP, existe una funcionalidad llamada Penultimate Hop Popping. La misma consiste en que el penúltimo enrutador del camino quite la etiqueta y el último funcione como un enrutador de capa 3. Si hay una pila de etiquetas, se quita la etiqueta superior. Para decidir qué operación deben realizar, los enrutadores se valen de la etiqueta superior de la pila y de dos tablas: la NHLF (Next Hop Label Forwarding) y la ILM (Incoming Label Map). La ILM contiene para cada posible etiqueta de entrada un puntero a una entrada en la NHLF. Las entradas NHLF contienen el próximo salto, la operación a realizar, la etiqueta y la interfaz de salida. Además los enrutadores de ingreso poseen otra tabla llamada FTN (FEC to NHLFE) que mapea las distintas FECs a una entrada en la tabla NHLF. A continuación se presenta un ejemplo del mecanismo de reenvío de paquetes en MPLS y las tablas asociadas. LSR 2 LER A IP: FEC=F 32 LSR 1 LER B IP: FEC=F 200 IP: FEC=F LSR 3 Figura 2.2: Reenvío de paquetes MPLS. Penultimate Hop Popping En el proceso de encaminamiento de la figura 2.2 se puede ver que el nodo LER A analiza los paquetes entrantes y, luego de asignarle una FEC, realiza el encaminamiento según la información contenida en las tablas FTN y NHLF que se presentan en las figuras 2.3(a) y 2.3(b) respectivamente.

32 12 Capítulo 2. Conceptos fundamentales (a) FTN NH (1) LSR1 (2) LSR5 (3) LSR Oper. Push Push Push... Lbl. Interf. 32 ATM2/ GbitEth0 123 Atm2/ (b) NHLF Figura 2.3: Tablas de reenvío MPLS del LER A. Luego el nodo LSR 1 analiza la etiqueta de entrada y realiza el encaminamiento según las tablas ILM y NHLF presentadas en las figuras 2.4(a) y 2.4(b). Es importante destacar que en este punto el camino para los dos paquetes IP podría ser el mismo, no siendo así en MPLS ya que se asignan FECs, y por lo tanto etiquetas distintas. Lbl NHLFE (a) ILM NH (1) LSR3 (2) LSR2 (3) LSR Oper. Swap Swap Swap... Lbl. Interf. 200 ATM2/ GbitEth0 93 Atm2/ (b) NHLF Figura 2.4: Tablas de reenvío MPLS del LSR 1. El LSR 3 realiza Penultimate Hop Popping como lo indican sus tablas ILM (figura 2.5(a) y NHLF (figura 2.5(b)), enviando al LER B un paquete IP, que será encaminado por este último sin tener que analizar el encabezado de MPLS Distribución de etiquetas Para que pueda funcionar el intercambio de paquetes basado en etiquetas, los enrutadores deben conocer las etiquetas con que los paquetes pueden llegar. Una forma de realizar esto es que el administrador de la red asigne las etiquetas manualmente

33 2.2. MPLS: Multiprotocol Label Switching 13 Lbl NHLFE (a) ILM NH (1) LERB (2) LERC (3) LERB Oper. Pop Pop Pop... Lbl. Interf. -- GbitEth1 -- GbitEth1 -- Atm1/ (b) NHLF Figura 2.5: Tablas de reenvío MPLS del LSR 3. y las configure en cada enrutador. Esto generalmente se vuelve engorroso y poco escalable en redes grandes. La otra forma es utilizando protocolos de distribución de etiquetas. Un protocolo de distribución de etiquetas es un conjunto de procedimientos por los cuales un enrutador MPLS informa a otro las asociaciones FEC-etiqueta que ha realizado. La decisión de asociar una FEC a una etiqueta dada es hecha por el enrutador aguas abajo (el que está más cerca de la salida). Existen dos modos de distribución: Downstream-on-Demand y Unsolicited Downstream. En el primero un enrutador puede pedir explícitamente la etiqueta para una FEC al próximo salto. Por otro lado en la segundo, los enrutadores distribuyen las etiquetas correspondientes a las asociaciones, aunque no se las hayan pedido. Además existen dos modos de retención de etiquetas. Por un lado está el modo liberal, donde si un enrutador recibe dos etiquetas para llegar a un destino, conserva ambas teniendo caminos alternativos. También está el modo conservador, donde en la situación planteada anteriormente el enrutador elije uno de los dos caminos y conserva solamente esa etiqueta. Algunos protocolos propuestos por la IETF para la distribución de etiquetas en MPLS son LDP [10], CR-LDP [11] y RSVP-TE [9] Ingeniería de Tráfico en MPLS Una de las principales ventajas de MPLS es la posibilidad de realizar Ingeniería de Tráfico y viene dada por la posibilidad de realizar ruteo explícito. El ruteo explícito consiste en definir un camino especificando una secuencia de nodos entre el ingreso y el egreso. De esta manera se puede reenviar una determinada FEC por este camino que puede ser diferente a la ruta computada por un protocolo de ruteo interno. Además MPLS permite reserva de recursos en el plano de control. Esto significa

34 14 Capítulo 2. Conceptos fundamentales que se pueden especificar parámetros que caractericen a los caminos, como ancho de banda o ráfaga máxima, pero no se garantiza que estos se cumplan a la hora de que el enrutador realice el reenvío de paquetes. Como consecuencia para tener una red dorsal multiservicio, no alcanza con usar MPLS sino que se necesita además un mecanismo de reserva de recursos en el plano de datos. El protocolo más popular para realizar esto actualmente es DiffServ, que permite dividir el tráfico en ciertos conjuntos y tratarlo de manera diferente en cada nodo según al conjunto que pertenezca. Actualmente existen dos modelos planteados para manejar MPLS y DiffServ de forma conjunta: L-LSP (Label-Only-Inferred-LSPs) y E-LSP (EXP-inferred-LSPs). En L-LSP los LSPs transportan solamente un agregado de tráfico. La etiqueta MPLS determina a qué agregado pertenecen desde el punto de vista de Diffserv, mientras que el campo EXP del encabezado MPLS determina la precedencia de descarte. Por otro lado en E-LSP los LSPs transportan múltiples agregados de tráfico. En este caso se utiliza el campo EXP del encabezado MPLS para codificar el agregado de Diffserv tal cómo se haría en una arquitectura IP/DiffServ. Esto se explica en profundidad en [18]. Otra ventaja de la Ingeniería de Tráfico en MPLS es la posibilidad de hacer reparto de carga con distintos costos, como se explica en [3]. En IP por lo general se computa el camino más corto para un destino y se envía todo el tráfico por ahí. Esto no es lo más conveniente por ejemplo en la situación de la figura 2.6. Figura 2.6: IP sin reparto de carga. Si los costos de los caminos son distintos, todo el tráfico es encaminado por el camino de menor costo. Esto presenta el inconveniente de que no se aprovecha toda la capacidad de la red disponible. La solución en IP para este problema es hacer que los dos caminos tengan igual costo. De esta manera el tráfico puede ser repartido en partes iguales por los caminos de igual costo. Esta solución por un lado no es escalable, ya que cuando crece el número de nodos se hace prácticamente imposible igualar los costos de los caminos. Tampoco permite un aprovechamiento óptimo de los recursos de la red, aunque mejora respecto al caso en que todo el tráfico sigue la misma ruta. Como se observa en la figura 2.7, la red permitiría enviar 250 Mbps y

35 2.2. MPLS: Multiprotocol Label Switching 15 con la solución de igualar las métricas se puede enviar hasta un tráfico de 200 Mbps. 50% Tráfico IP RB BW=150Mbps Costo=10 BW=150Mbps Costo=10 RA BW=100Mbps Costo=20 RC 50% Tráfico IP Figura 2.7: IP con reparto de carga. Utilizando MPLS se puede realizar balance de carga entre rutas con diferentes costos. Simplemente se crea un túnel por cada camino entre dos enrutadores y luego el LER puede repartir la carga que va a un mismo destino a través de cada camino disponible en distintas proporciones. Como se observa en la figura 2.8, utilizando balance de carga en MPLS se puede aprovechar toda la capacidad de red disponible entre los dos enrutadores. Túnel A - 60% del tráfico RB BW=150Mbps Costo=10 BW=150Mbps Costo=10 RA BW=100Mbps Costo=20 RC Túnel B - 40% del tráfico Figura 2.8: MPLS con reparto de carga. Para realizar balance de carga hay que tener en cuenta que los caminos disponibles pueden tener distintos retardos y por lo tanto desordenar los paquetes. Por esta razón surgen dos modalidades de reparto de carga: por paquete y por flujo. El reparto de carga por paquete implica que los mismos se van asignando a los distintos túneles solamente teniendo en cuenta la fracción de tráfico asignada a cada túnel. Por otro lado el reparto de carga por flujo, también conocido como reparto de carga por pareja origen-destino, agrega la restricción que los paquetes que tienen igual origen y destino en el encabezado IP se consideran del mismo flujo y se envían siempre por el mismo túnel. Hay que tener en cuenta que si bien en general es recomendable

36 16 Capítulo 2. Conceptos fundamentales realizar balance de carga por flujo, cuando el tráfico involucra pocos flujos puede no ser posible respetar la fracción especificada para cada túnel Gestión de redes MPLS Generalidades La gestión de redes comprende la planificación, organización, supervisión y control de los elementos de telecomunicaciones para garantizar un nivel de servicio de acuerdo a un costo. Hay muchas razones por las que se deben gestionar las redes. Desde el punto de vista práctico, los elementos de la red deben ser monitorizados para comprobar su correcto funcionamiento. La configuración de equipos también es parte de la gestión de redes. Por ejemplo, si se detectan fallas, es deseable poder aislarlas o corregirlas. Otra razón para querer gestionar una red es para monitorizar los servicios ofrecidos, por ejemplo estudiando su performance y si se cumplen los contratos de servicio. En redes pequeñas, la gestión es sencilla por lo que una persona manualmente puede encargarse de la supervisión y configuración de los equipos. Pero a medida que las redes crecen se hace imposible que los operadores las gestionen manualmente. Esto hace que surja la necesidad de tener herramientas de gestión automática de redes. Un hecho importante a resaltar es que, si bien hay una conciencia general de la importancia de la gestión de redes, en la práctica muchas veces es dejada de lado por los fabricantes en la carrera por sacar las tecnologías al mercado. En general, cuando aparece una nueva tecnología, primero se estandariza, luego se implementa en los equipos y es comercializada. Recién después de implantada en el mercado se comienza a trabajar en los estándares de gestión, lo que hace que por un período de tiempo los operadores no cuenten con herramientas adecuadas o que las mismas sean pobres. Las herramientas de gestión permiten a los operadores acceder al control, configuración y estado de cada dispositivo de una red. En general se componen de dos partes: un protocolo que describe la comunicación entre el operador y el equipo, y el formato en que se intercambia la información en dicho protocolo. Existen muchas alternativas a la hora de elegir una herramienta de gestión con distintas características. Por ejemplo algunas son propias de un fabricante mientras que otras son estándar. También existen herramientas que soportan seguridad o transporte más o menos confiable. En la práctica es común que se integren muchas herramientas distintas en un mismo sistema de gestión como se muestra en la figura 2.9. En esta sección se estudian las distintas alternativas de gestión automática de redes MPLS.

37 2.3. Gestión de redes MPLS 17 Sistema Facturación GUI XML/ CORBA NMS HTTP DB SNMP/ XML Consultas SNMP Telnet Element Manager Traps Comandos Propietarios Figura 2.9: Ejemplo de un sistema de gestión SNMP: Simple Network Management Protocol SNMP, Simple Network Management Protocol, definido en [16], especifica una arquitectura para la administración de redes compuesta de cuatro elementos fundamentales. Estos elementos son los agentes (residen en los nodos manejados y contestan las consultas), el administrador (es quien realiza las consultas sobre los nodos a su cargo), la información de gestión y un protocolo para la comunicación entre el administrador y los agentes. La manera virtual en que se almacena la información de gestión es denominada Management Information Base (MIB). Las operaciones básicas de este protocolo son: GET y SET. Mediante consultas GET a los agentes se obtiene información almacenada en el formato definido por las MIBs. El contenido de las mismas también puede ser modificado vía operaciones SET para aquellas variables que las restricciones de acceso lo permitan. Para consultas más complejas como tablas completas, también existen las operaciones GET-NEXT y GET-BULK. Además SNMP provee un mecanismo de notificaciones llamadas TRAPS. Éstas permiten que los elementos de la red envíen información al operador, sin una solicitud previa. Como ejemplo puede configurarse en un nodo que envíe una notificación ante la caída de alguna de sus interfaces. La información almacenada en las MIBs se presenta como objetos ordenados jerárquicamente. La sintaxis de esos objetos está claramente definida de manera que pueda ser accesible desde distintas implementaciones independientemente del fabricante. Las MIBs son escritas y definidas en un lenguaje llamado SMI (Structure

38 18 Capítulo 2. Conceptos fundamentales of Management Information). Cada objeto es identificado por un número llamado OID asignado por la IANA. La principal ventaja del protocolo SNMP frente a otras herramientas de gestión es el hecho de ser un estándar abierto, lo que permite gestionar de la misma manera equipos de distintos fabricantes. Esta propiedad es muy importante en redes grandes, ya que los operadores en general compran en distintos momentos equipos de diferentes fabricantes y luego desean gestionarlos de manera uniforme. Otra ventaja que posee el protocolo SNMP es su popularidad. Prácticamente todos los fabricantes lo han adoptado en mayor o menor medida. El problema es que no siempre implementan todas las MIBs estandarizadas. Quizás la principal desventaja del protocolo SNMP es que como se comentó anteriormente, cuando aparecen nuevas tecnologías, por un tiempo no se cuenta con estándares de gestión. Por lo tanto no es posible utilizar el protocolo SNMP para gestionar esas tecnologías Soluciones propietarias de los fabricantes En los casos que no hay disponibles estándares de gestión para utilizar SNMP, los operadores aún necesitan gestionar sus redes, por lo que se ven obligados a utilizar las soluciones propietarias de los fabricantes. En general estas soluciones permiten gestionar todas las funcionalidades implementadas en los equipos, pero presentan como desventaja que la implementación de las herramientas de gestión debe ser específica para el fabricante. Esto se agrava cuando coexisten en una misma red equipos de distintos fabricantes y deben ser gestionados por la misma herramienta. A continuación se presentan dos soluciones propietarias para gestionar equipos de redes. A. CLI: Command line interface CLI se le llama a la interfaz de los equipos donde se pueden introducir comandos ya sea para configurar u obtener información de estado de los mismos. En general los fabricantes proveen una descripción de los comandos y su sintaxis. Si bien antiguamente para acceder al CLI de los equipos era necesario conectarse a un puerto serial, hoy en día es posible la conexión remota a través de protocolos como SSH o TELNET. Mediante el uso de estos protocolos el operador puede utilizar el CLI para gestionar sus equipos remotamente. Más aun, mediante la elaboración de secuencias de comandos (SCRIPTS) y su posterior procesamiento, es posible construir poderosas herramientas de gestión. Una desventaja de utilizar el CLI como herramienta de gestión es que puede resultar lenta en caso de que se deban aplicar muchos comandos.

39 2.4. Conclusiones 19 B. Bulk file transfer Algunos fabricantes proveen una funcionalidad denominada BULK FILE TRANS- FER por la que permiten transmitir o extraer gran cantidad de información de un equipo mediante el uso de un protocolo de transferencia de archivos. Esta funcionalidad es usada por ejemplo para hacer copias de seguridad de la configuración de los equipos o para restaurar la configuración a un estado determinado, pero también puede utilizarse como herramienta de gestión. En general puede indicarse por SNMP a un equipo que escriba o recoja su archivo de configuración en un servidor utilizando el protocolo TFTP. Esto permite la configuración remota de los equipos, ya que se puede obtener la configuración, cambiarla y luego cargarla nuevamente en el equipo. Una desventaja de este método es que generalmente no sirve para consultar información de estado ni de performance de los equipos ya que la misma no se encuentra en los archivos de configuración. Tiene como ventaja frente al uso del CLI que para realizar muchos cambios es más rápido. Además algunos fabricantes como CISCO permiten combinar la configuración nueva a la existente incorporando solo los cambios, lo que reduce el tráfico en la red. También presenta como ventaja que no es necesario que la herramienta de gestión conozca la clave de configuración del nodo. Alcanza con que tenga la community de SNMP Conclusiones En esta sección se presentaron la Ingeniería de Tráfico aplicada a redes de telecomunicaciones, MPLS como transporte de las mismas y la gestión de las redes que utilizan dicha tecnología. Sobre la Ingeniería de Tráfico, se repasaron los conceptos de en línea y fuera de línea, indicando que el presente proyecto pretende dar una solución en línea. Se resumió la arquitectura MPLS, incluyendo las operaciones básicas y las principales características que favorecen la Ingeniería de Tráfico sobre la misma. Se destacó el balance de carga y el ruteo explícito, por ser una de las funcionalidades más aprovechadas por la herramienta desarrollada. En cuanto a la gestión el protocolo SNMP se destaca, ya que permite gestionar equipos de cualquier fabricante en forma remota, pero no siempre está disponible para todas las funcionalidades de los equipos. Por otro lado hay herramientas propietarias de los fabricantes que permiten gestionar esas funcionalidades que no están disponibles por SNMP. Tienen la desventaja de que justamente son dependientes del fabricante. En muchas ocasiones la gestión termina realizándose utilizando una combinación de las herramientas mencionadas en este capítulo.

40

41 Capítulo 3 Estado del arte en Ingeniería de Tráfico Un objetivo del presente proyecto es estudiar qué alternativas existen para atacar el problema de Ingeniería de Tráfico. En este capítulo se presenta el estado del arte y algunas herramientas con objetivos similares a los que se plantean en este proyecto Introducción Antes de intentar resolver cualquier problema de ingeniería es necesario estudiar cuál es el estado del arte en la materia, si ya hay soluciones implementadas y cuales son sus ventajas y desventajas. En este capítulo se presenta el estudio realizado para este caso. En el capítulo 2 se estudiaron cuáles son los principales requerimientos para hacer Ingeniería de Tráfico en MPLS. Se identificaron cuatro grandes problemas: el descubrimiento de la red, su monitorización, la acción de Ingeniería de Tráfico y la reconfiguración de los equipos. En las siguientes secciones se estudian las alternativas que hoy día hay disponibles para resolver cada uno de ellos, así como una discusión de sus ventajas y desventajas. En este capítulo también se presentan ejemplos de aplicaciones que tienen los mismos objetivos, se comparan y se extraen sus principales fortalezas. En particular se estudia como resuelve cada una los problemas mencionados anteriormente Relevamiento de la red Como se comentó en la capítulo 2, para realizar Ingeniería de Tráfico es fundamental conocer el estado de la red. Para esto es imprescindible conocer la topología física (enrutadores y enlaces) y la topología virtual (LSPs establecidos, en el caso de la tecnología MPLS). Al buscarse desarrollar una herramienta de Ingeniería de Tráfico en línea, se agregan además otras restricciones para el relevamiento de los distintos componentes de la red. En particular debe ser: 21

42 22 Capítulo 3. Estado del arte en Ingeniería de Tráfico Automático: se debe minimizar la intervención del operador de la red. Rápido: se busca trabajar en línea, acercándose al tiempo real. Independiente del fabricante: es uno de los objetivos de la herramienta a desarrollar. A continuación se estudian distintas maneras de obtener esta información, sus ventajas y desventajas Descubrimiento de la topología física Por topología física se entiende la información sobre enrutadores, enlaces y las características de cada uno de ellos. Es deseable conocer direcciones IP, máscaras, nombres e identificación de enrutadores(router Id). Se analizaron las siguientes alternativas: Consultas SNMP a los nodos Participación del ruteo Comunicación a los nodos por SSH o TELNET Mensajes ICMP Si bien son presentadas de manera independiente, pueden usarse de manera combinada para lograr algoritmos de descubrimiento más robustos y completos. A. Utilización de SNMP En el capítulo 2 se presentó la herramienta de gestión SNMP. Ésta posibilita obtener información almacenada en las MIBs que permite deducir cual es la topología de la red. La efectividad de la técnica depende fuertemente de las MIBs que se consulten, ya que éstas almacenan distinta información y en distinta forma. A continuación se presentan ejemplos de la información que se puede obtener por SNMP para descubrir la topología física: ARP. La tabla de traducción de direcciones (ARP) de un nodo contiene todos los nodos directamente conectados a través de redes Ethernet. Es accesible por SNMP mediante la MIB-II [12], pero presenta la desventaja de que sólo sirve para redes Ethernet (no sirve por ejemplo para el caso de la maqueta de pruebas que se utiliza en este proyecto donde los enlaces son ATM). Tabla de rutas. Los nodos almacenan en su tabla de rutas IP, todas las direcciones IP de las redes a las que pueden llegar. Esta información es accesible por SNMP a través de la MIB-II. En particular se pueden filtrar las direcciones

43 3.2. Relevamiento de la red 23 que están directamente conectadas y así descubrir los vecinos. Esto puede ser peligroso en redes MPLS ya que un nodo puede aparecer como directamente conectado a través de un túnel MPLS, lo que daría una idea equivocada de la topología. Tablas del protocolo de ruteo. Es posible consultar la información del protocolo de ruteo. En general es fácil obtener la información de los nodos directamente conectados sin tener el problema de las tablas anteriores. Por ejemplo en OSPF existe una tabla de vecinos donde se encuentra dicha información. La desventaja es que el método queda dependiente del protocolo de ruteo y se descubren únicamente los nodos que participen del mismo. Como gran ventaja de utilizar esta técnica se destaca el hecho de que la implementación queda independiente del fabricante. A su vez es interesante el hecho de que las MIBs son actualizadas en cuanto ocurre algún cambio, por lo que la información que contienen será siempre consistente. Las notificaciones y TRAPS de SNMP permiten recibir reportes sobre la caída de nodos prácticamente en tiempo real, lo que también es una ventaja para este tipo de aplicación. La desventaja que se puede encontrar es que muchos administradores no permiten este tipo de tráfico por razones de seguridad. Por lo que para el caso de que se desee descubrir una red que atraviesa varias autoridades puede no ser una buena opción. B. Participación del ruteo Esta técnica consiste en escuchar los paquetes intercambiados por los enrutadores con información de ruteo. Permite reconstruir la topología a partir de esa información de manera similar a como lo realizan los mismos equipos. Es importante mencionar que este abordaje aplica a redes corriendo algún protocolo de ruteo de estado de enlace, ya que de otra manera no sería posible obtener información sobre toda la red de manera centralizada. Se destaca como ventaja de esta alternativa que los cambios que puedan ocurrir en la topología serán recibidos por la aplicación muy rápidamente y al mismo tiempo en que se entera la totalidad de la red. Una desventaja es que requiere la implementación en software del protocolo de ruteo que en general es muy complicada. Algunos autores proponen aprovechar el código de proyectos Open Source que implementan protocolo de ruteo como Quagga. Por más información sobre este tema se puede consultar [41] o [35]. Por otro lado hay que evitar que la herramienta modifique el comportamiento de los demás enrutadores. C. Comandos ICMP Una alternativa popular para descubrir topologías de redes es el uso de las herramientas PING y TRACEROUTE. El comando PING permite determinar si hay

44 24 Capítulo 3. Estado del arte en Ingeniería de Tráfico conectividad entre dos nodos, mientras que el TRACEROUTE permite averiguar qué equipos intermedios hay entre dos nodos. Ambos funcionan a nivel de capa de red. Existen aplicaciones que buscan en un cierto rango de direcciones IP, indicadas por el usuario, si existe respuesta al comando PING desde cada una de las direcciones en el rango. De esta manera se van descubriendo todos los equipos de la red. Otras alternativas incluyen detectar mediante el comando PING si los equipos existen y están activos y luego se utiliza el comando TRACEROUTE para conocer la ruta hacia los equipos. Estas técnicas presentan la gran desventaja de que el descubrimiento de la topología se hace lento, ya que se prueba con varias direcciones de red que no pertenecen a ningún equipo y para darse cuenta de esto hay que esperar a que expiren ciertos temporizadores. Otra desventaja es que algunos administradores de red deshabilitan estos protocolos por razones de seguridad. Además, la técnica permite descubrir qué direcciones están activas pero no cómo se distribuyen en los nodos. A pesar de esto muchas soluciones comerciales utilizan esta alternativa debido a que es universal, ya que prácticamente todos los nodos son compatibles con estos comandos. D. Conclusiones Luego de analizar distintos métodos para obtener la topología física se llegó a la conclusión de que los más adecuados para los requerimientos de la Ingeniería de Tráfico en línea son la utilización del protocolo SNMP y la participación del ruteo por ser los que permiten trabajar más cerca del tiempo real, son aplicables a cualquier red y a cualquier fabricante. Si bien hay estudios [35] que sugieren que la técnica de participación en el ruteo permite detectar cambios más rápidamente, su implementación es mucho más complicada. Además, en SNMP se pueden utilizar notificaciones (i) para detectar los cambios más rápidamente Descubrimiento de la topología virtual Por topología virtual se entiende el conjunto de LSPs señalizados en la red, junto con sus atributos. En el presente trabajo se excluyen del concepto topología virtual los parámetros de performance. Como se explicó en el capítulo 2, para realizar Ingeniería de Tráfico es deseable conocer los LSPs señalizados, cuáles son sus caminos y qué tráfico tienen asociado (FEC). Se considera importante repasar las características de los caminos de MPLS, base de la topología virtual en cuestión. Como se explicó en la sección 2.2, en esta tecnología el encaminamiento de los paquetes se realiza mediante el análisis e intercambio de etiquetas. Por lo tanto cualquier camino establecido de esta manera es considerado un LSP.

45 3.2. Relevamiento de la red 25 Con el objetivo de mapear la conectividad IP en MPLS, los protocolos de distribución pueden asignar etiquetas para cada entrada en la tabla de encaminamiento de IP, distribuirlas a sus vecinos y realizar el encaminamiento en esta tecnología. De esta manera se acelera el proceso, ya que el mecanismo de encaminamiento de MPLS es más rápido que el de IP. Por otro lado, se encuentran los caminos definidos en el estándar [5] como túneles de Ingeniería de Tráfico. Son LSPs que tienen especificado un camino explícito y que soportan atributos de Ingeniería de Tráfico. Es de interés por lo tanto para una herramienta de este tipo, conocer los caminos de Ingeniería de Tráfico. Por el contrario, como se detalla más adelante en el capítulo 6 correspondiente a la solución implementada, no se considera de interés el descubrimiento de los demás caminos. Las dos alternativas estudiadas para descubrir la topología virtual son utilizar el protocolo SNMP y leer la configuración de los nodos mediante alguna de las técnicas presentadas en el capítulo 2. Las ventajas y desventajas de ambos métodos también son discutidas en ese capítulo. La tarea puede descomponerse naturalmente en el descubrimiento de los LSPs y la obtención de FECs. A continuación se presentan las distintas opciones a la hora de obtener cada una. A. Descubrimiento de LSPs A través de SNMP, la información de los túneles señalizados se encuentra en la MPLS-TE-MIB. Es posible consultar el nombre, origen y destino del túnel entre otros atributos. Además es posible obtener el camino que utiliza el túnel, el camino óptimo computado por el LER de origen y el camino requerido por el operador. La misma información puede obtenerse interpretando la configuración propietaria de los nodos, por ejemplo por TELNET o SSH. Como se comenta en la sección 3.4, presenta la desventaja de que es dependiente del fabricante. B. Obtención de asociaciones FEC-LSP Si bien está prevista la MPLS-FTN-MIB para la obtención de esta información por SNMP, los fabricantes aún no la implementan. Por otro lado el concepto de FEC es muy general y algunos tipos, como por ejemplo la dirección de destino, pueden ser obtenidos de otras fuentes. En general los fabricantes implementan los túneles como una interfaz en el LER. Por lo tanto se puede, por ejemplo, consultar la tabla de rutas de un LER de la MIB-II, filtrar las rutas que salen por las interfaces túnel y asociar las redes de destino como FECs a esos túneles. Esto puede ser problemático en caso de que se haga balance de carga entre un grupo de LSPs ya que por lo general los fabricantes presentan una interfaz por destino.

46 26 Capítulo 3. Estado del arte en Ingeniería de Tráfico Interpretando la configuración de los nodos, por ejemplo utilizando TELNET o TFTP que se explican más adelante, se pueden obtener más parámetros asociados a las FECs. Por ejemplo en el caso del fabricante CISCO, si bien en su configuración no maneja el concepto de FEC, es posible definir el tráfico asociado a un túnel por red de destino, red de origen, rango de puertos de origen y destino y DiffServ Code Point. C. Conclusiones A partir del análisis presentado se puede concluir que no hay muchas alternativas para relevar la topología virtual de una red MPLS. Para el relevamiento de los LSPs establecidos la opción de utilizar SNMP parece la más razonable. Esto se debe a que permite independizarse del fabricante y se puede obtener toda la información necesaria. Por otro lado para la obtención de las asociaciones FEC-LSP por el momento la única opción es interpretar la configuración de los nodos u obtener, para el caso en que los equipos no realizan balance de carga entre LSPs, solamente la red de destino como información parcial de la FEC por SNMP Obtención de parámetros de performance Por parámetros de performance se entienden todos los parámetros que permiten caracterizar el desempeño actual de la red. Los parámetros de performace en general pueden ser clasificados en locales o de extremo a extremo. Algunos ejemplos de parámetros locales son el número de paquetes cursados por interfaz o uso de CPU. Por otro lado, ejemplos de parámetros de extremo a extremos son retardo, variación del retardo y flujo. En este capítulo se estudian: Realización de medidas activas Consultas de parámetros locales a los nodos Realización de medidas activas Como se explicó en el capítulo 2 las medidas activas son las que producen una modificación en el objeto a medir. El método más común para realizar medidas activas en una red es inyectar tráfico y observar su desempeño. A. Metronet Existen numerosas aplicaciones que permiten realizar medidas de performance en redes. Se analizó el software Metronet [34] que permite la obtención de parámetros de calidad de servicio para aplicaciones de voz y video en Internet. El mismo, mediante

47 3.3. Obtención de parámetros de performance 27 la inyección de paquetes de prueba y un flujo de tráfico breve, obtiene medidas de retardo, jitter y pérdidas de paquetes. Si bien el software Metronet no dispone de una interfaz para obtener los resultados en forma automática, está prevista la implementación de un agente SNMP. En este trabajo se propone una MIB para las consultas a Metronet, la misma se puede ver en el apéndice A.2. Una desventaja de las aplicaciones de medidas activas es que para tener medidas de extremo a extremo para cada camino se debe contar con el software correspondiente en ambas puntas, lo que puede traer inconvenientes a la hora de implementarlo en topologías complejas y de gran escala, donde los proveedores y consumidores de contenidos pueden estar ubicados en cualquier punto. B. RTTMON Algunos fabricantes incluyen aplicaciones de medida dentro de los propios enrutadores. Esto elimina la necesidad de colocar agentes de medida en todas las puntas de la red. Un ejemplo es la funcionalidad RTTMON de CISCO que permite realizar experimentos de extremo a extremo para obtener el retardo, jitter y pérdida de paquetes. Además, la información de las pruebas puede consultarse a través de SNMP en la RTTMON-MIB. La gran desventaja de esta herramienta es que aún no se encuentra integrada con el protocolo MPLS por lo que las medidas no se pueden asociar a los LSPs como sería deseable, sino a direcciones IP de destino. Una solución podría ser crear direcciones de loopback en los LER de salida para las medidas de cada túnel y así poder distinguir el tráfico de cada medida por dirección de destino. Luego podría asociarse el tráfico de cada medida al túnel correspondiente mediante una ruta estática a dicha dirección de loopback. Esto requiere un gran trabajo de configuración manual, se desperdician direcciones IP y por lo tanto no es escalable. C. MPLS PING MPLS PING, presentado en [14] es una herramienta pensada para verificar el estado activo de un LSP en el plano de datos. Funciona de manera similar al PING tradicional, con la salvedad de que se especifica el LSP a utilizar en lugar de la dirección de destino. Además, en lugar de utilizar el protocolo ICMP como el PING tradicional, utiliza el protocolo de transporte UDP. Debido a que los LSPs son unidireccionales, el camino de retorno del mensaje no queda especificado. En el encabezado del protocolo, está prevista la inclusión de una marca de tiempo de cuando se envía el mensaje y otra de cuando el LER de salida lo recibe. Como consecuencia si los nodos están sincronizados, por ejemplo con el protocolo NTP, se podría calcular el retardo de ida del LSP. Lamentablemente los fabricantes recién están incorporando esta funcionalidad y

48 28 Capítulo 3. Estado del arte en Ingeniería de Tráfico la implementación del estándar aún es parcial. Por ejemplo en la implementación del fabricante CISCO el valor de retardo obtenido es de ida y vuelta y no tiene mucho sentido en MPLS donde los LSPs son unidireccionales. Otra desventaja de utilizar MPLS PING como herramienta de medida es que los resultados no están disponibles por SNMP. Como consecuencia la única manera de automatizar el proceso de medida es realizando un SCRIPT con comandos propietarios en el nodo Consultas de parámetros locales a los nodos Para consultar los parámetros de performance locales de cada nodo puede utilizarse tanto SNMP como la conexión al nodo a través de TELNET. Como ya se mencionó anteriormente, es preferible utilizar SNMP siempre que sea posible debido a su interoperabilidad con cualquier fabricante. La información de performance para una red MPLS, disponible por SNMP, está en las siguientes MIBs: LSR. La MPLS-LSR-MIB [6] contiene información de las interfaces entrantes y salientes correspondientes a cada LSP que atraviesa el nodo en cuestión. Contiene tablas que especifican distintos parámetros de performance, como por ejemplo los paquetes descartados o los paquetes cursados por LSP. IF. La tabla de interfaces incluida en la MIB II contiene información de las interfaces de los nodos. Por ejemplo, en ella se encuentran disponibles contadores que incluyen paquetes cursados y descartados. Por otro lado se encuentran las MIBs propietarias que proveen información de los equipos y de aplicaciones que desarrollan los fabricantes. De estas últimas se puede obtener por ejemplo, el uso de CPU de los nodos, que no se encuentra disponible en ninguna MIB estándar Conclusiones Se analizaron las distintas alternativas disponibles para obtener parámetros de performance en redes MPLS. Como principal conclusión se pude resaltar que la obtención de parámetros de extremo a extremo es bastante complicada. Se requieren medidas activas, agentes de medida y en general es difícil obtener los resultados de manera automática. De todas maneras se puede concluir que la mejor opción sería utilizar un software de medidas especializado como Metronet. Con respecto a los parámetros locales la tarea es más sencilla. Hay información de tráfico cursado y descartes disponible por SNMP. Es posible obtener por ejemplo, qué porcentaje del tráfico de una interfaz corresponde a un LSP determinado. El único parámetro que no se encuentra en las MIB estándar y sería deseable obtener

49 3.4. Reconfiguración en redes MPLS 29 es el uso de CPU, ya que es un buen indicador de congestión. De todas maneras las mayoría de los fabricantes tienen este valor disponible por consultas SNMP en sus MIBs propietarias Reconfiguración en redes MPLS Toda herramienta de Ingeniería de Tráfico debe ser capaz de producir cambios en la red. En el caso de redes MPLS los cambios deseados son dar de alta, de baja y cambiar parámetros de túneles, y asociar FECs con túneles. Estas tareas permiten realizar la mayoría de las operaciones de Ingeniería de Tráfico. Además es deseable contar con la posibilidad de reenrutar túneles existentes de manera segura, entendiéndose por segura que no se pierda tráfico en el proceso. A su vez, se debe tener cuidado con el manejo de las reservas de recursos a la hora de reenrutar un LSP, debido a que se podrían duplicar las reservas causando efectos indeseados. Por ejemplo, si se quiere reenrutar un túnel con reserva de ancho de banda, puede ser que la red no tenga recursos suficientes para albergar el túnel anterior y el nuevo simultáneamente. Por lo tanto, se debe proveer un mecanismo para que la reserva no se cuente como nueva sino como una sustitución de la existente. Esto es implementado en el protocolo RSVP-TE por ejemplo con la funcionalidad SHARED EXPLICIT, que puede consultarse en [9]. A continuación se presentan las distintas técnicas estudiadas para señalización en redes MPLS Utilización del protocolo SNMP Una manera de cambiar la configuración de MPLS de una red es utilizando el protocolo SNMP. Las generalidades de este protocolo fueron discutidas en las secciones anteriores. Cómo se vio en la sección la información de los túneles señalizados se encuentra en la MPLS-TE-MIB. Lamentablemente los fabricante aún no permiten la escritura en esta MIB por lo que resulta imposible señalizar nuevos túneles o dar de baja los existentes por SNMP. Por otro lado la asociación de FECs con LSPs está prevista en la MPLS-FTN- MIB. Esta MIB tampoco se encuentra implementada aún por los fabricantes como se mencionó anteriormente, por lo que esta funcionalidad no se puede implementar actualmente por SNMP Configuración manual del nodo Una alternativa posible para reconfigurar una red es configurar manualmente cada nodo utilizando los comandos de cada fabricante.

50 30 Capítulo 3. Estado del arte en Ingeniería de Tráfico La configuración manual de los nodos es muy poderosa ya que permite utilizar todas las funcionalidades implementadas, pero como ya se mencionó la implementación queda dependiente de ese fabricante. En general en MPLS la configuración de túneles y asociación de tráfico se hace solamente en el LER de entrada o HEAD, que luego desencadena el proceso de señalización a los demás nodos. Esto simplifica el proceso de configuración ya que se debe cambiar únicamente la configuración de un nodo, a diferencia por ejemplo de ATM que se tendrían que configurar todos los nodos del camino. De todas formas los fabricantes aún no implementan todas las funcionalidades deseables para realizar Ingeniería de Tráfico. El reenrutamiento manual de un LSP de manera segura por ejemplo no es posible en el fabricante CISCO. Esto se debe a que si bien los LSPs soportan la definición de varias opciones de caminos con distintas prioridades, el propio nodo evalúa cuando debe cambiar la opción activa. Si se quiere, como es el caso cuando se realiza Ingeniería de Tráfico, indicarle manualmente que cambie el camino en uso, se debe dar de baja el camino actual y señalizar el nuevo perdiendo el tráfico durante el proceso. Otra tarea que no es sencilla aun utilizando la configuración de los nodos es la asociación de FECs con LSPs. En la industria el concepto de FEC está fuertemente asociado a la red de destino como en las redes IP. Sin embargo a la hora de realizar Ingeniería de Tráfico, muchas veces es necesario tener una caracterización más detallada de las FECs. Por ejemplo se puede querer separar un tráfico con calidad de servicio de uno best effort en distintos túneles aun cuando vayan al mismo destino. La solución que presentan muchos fabricantes a este problema es la utilización del ruteo basado en políticas. Esta funcionalidad ya existía para los enrutadores IP, y consiste en filtrar los paquetes de entrada de acuerdo a criterios establecidos y, en base a sus características, enviarlos por distintas interfaces (o hasta descartarlos). El ruteo basado en políticas se utiliza también para políticas de seguridad y administrativas. Uno de los problemas que presenta esta solución, es que a medida que crece el número de filtros se aumenta la carga en el procesador para filtrar los paquetes. Además las categorías de filtrado deben ser disjuntas, algo difícil de configurar automáticamente teniendo en cuenta que están mezcladas las políticas de Ingeniería de Tráfico, seguridad y administrativas. Cuando se utiliza Diffserv en conjunto con MPLS, la mayoría de los fabricantes ofrecen la posibilidad de establecer FECs de acuerdo al flujo de Diffserv. Si bien esta opción es muy útil, solo se aplica cuando se utiliza Diffserv Utilización de los protocolos PCEP o COPS A. PCEP El grupo de trabajo de la IETF PCE [42] tiene como objetivo la definición de una arquitectura para MPLS y GMPLS basada en un elemento de cómputos de caminos para dichas tecnologías. La idea se basa en que la tarea de cómputo de caminos

51 3.4. Reconfiguración en redes MPLS 31 en general es muy costosa computacionalmente y podría se realizada de una mejor manera por un elemento especializado y no necesariamente por un enrutador cuyas funciones, por definición, son otros. El PCE WG definió además un protocolo llamado PCEP [43] para la comunicación entre el nodo de ingreso y el computador de caminos (PCE, Path Computation Element). Este protocolo pude ser utilizado en el ciclo de Ingeniería de Tráfico, ya que permite comunicar caminos explícitos a los LERs. El escenario de aplicación de interés de este protocolo, tal cual se define en [43], es cuando llega al LER de entrada una solicitud para un nuevo LSP, ya que éste le solicita el cómputo del camino a la entidad especializada: el PCE. El resultado del cómputo es comunicado al PCC (Path Computation Client) quien reside físicamente en el propio LER. Luego la señalización propiamente dicha queda en manos del LER. Un inconveniente del uso de este protocolo para Ingeniería de Tráfico es que los pedidos son realizados por el enrutador, y no está contemplado en su versión actual, que la herramienta de TE le comunique un cambio al LER sin que esté precedido por una solicitud. Por otro lado esto sí es contemplado en la arquitectura PCE por lo que es de esperar que en un futuro se incorpore una solución. Es oportuno aclarar que tanto la versión de la arquitectura como la del protocolo están bajo revisión y aún no han sido estandarizados. Además es un protocolo muy nuevo y todavía no está implementado por ningún fabricante, aunque se espera que en un futuro no muy lejano lo sea. B. COPS El protocolo COPS (Common Open Policy Service), pretende posibilitar el intercambio de políticas entre un elemento de la red y un servidor de políticas. Si bien es un protocolo muy sencillo, está pensado para poder ser fácilmente extensible, lo que lo ha hecho muy popular. Una descripción detallada del mismo se puede encontrar en [15], y una aplicación a la Ingeniería de Tráfico en MPLS en [24]. Una característica interesante de este protocolo es que, si bien en general el elemento de red hace solicitudes al servidor, está previsto que el servidor dé instrucciones de forma no solicitada. Esto permite que si la herramienta de Ingeniería de Tráfico implementa un servidor COPS, pueda comunicarle decisiones a los enrutadores mediante estas instrucciones. Cabe aclarar que para esto hay que definir las extensiones necesarias y deben ser implementadas por los enrutadores. El problema de este protocolo es que si bien muchos fabricantes lo implementan para políticas de RSVP, todavía ninguno ha implementado extensiones para realizar Ingeniería de Tráfico en MPLS Conclusiones Actualmente la única forma de reconfigurar una red MPLS es utilizando la configuración manual de cada nodo. Por otro lado, el tema de la asociación de FECs

52 32 Capítulo 3. Estado del arte en Ingeniería de Tráfico con LSPs parece no estar muy maduro aún en las implementaciones de los fabricantes, por lo que su configuración es complicada incluso utilizando la configuración manual. En cuanto a la reconfiguración por SNMP, los estándares para que los fabricantes comiencen a soportar configuraciones por este protocolo están disponibles, por lo que es de esperar que en un futuro próximo queden implementados. El uso de SNMP permitiría realizar la reconfiguración de manera sencilla y uniforme para todos los fabricantes. Los protocolos como COPS y PCEP parecen tener un futuro muy prometedor para realizar Ingeniería de Tráfico en MPLS, aunque hoy en día no son una opción válida debido a que no hay equipos en el mercado que los implementen Algoritmos de Ingeniería de Tráfico en ĺınea En esta sección se presentan los algoritmos de Ingeniería de Tráfico en línea estudiados. Se hace una clasificación de los algoritmos, se comenta cada clase y las principales características de cada uno. Se clasificaron los algoritmos estudiados en 3 categorías, a saber: Algoritmos de CBR Algoritmos de balance carga Algoritmos de reenrutamiento Algoritmos de CBR Los algoritmos de CBR o ruteo basado en restricciones permiten, dada una topología de red y un conjunto de restricciones, calcular un camino que verifique dichas restricciones. Dentro de los más sencillos se encuentra CSPF (Constrained Shortest Past First) que calcula el camino más corto, según una métrica administrativa, que tenga además cierto ancho de banda disponible. Una implementación típica consiste en generar un árbol con todos los caminos posibles entre origen y destino, podar las ramas que no cumplan la restricción de ancho de banda y correr algún algoritmo de SPF sobre el árbol podado. La implementación real de un fabricante se puede consultar en [18]. Un grupo de algoritmos basados en restricciones son los algoritmos de mínima interferencia. Estos algoritmos buscan los distintos caminos entre origen y destino con determinado ancho de banda disponible. De entre ellos eligen el que, luego de haberse señalizado, maximice el ancho de banda disponible. Por ejemplo si un camino A pasa por enlaces en los que, luego de señalizarse, quedaría un cuello de botella de 10Mbps y otro camino B pasa por enlaces en los que quedaría un cuello de botella

53 3.5. Algoritmos de Ingeniería de Tráfico en ĺınea 33 de 20Mbps, el algoritmo de mínima interferencia elegiría el camino B. Esta clase de algoritmos busca aumentar la probabilidad de que los futuros pedidos de cómputo puedan completarse con éxito. Existen varias propuestas de implementación de esta clase de algoritmos como MIRA [25], LMIR [26] o RNLC [27]. El detalle de cómo se implementan estos algoritmos no es de interés para este trabajo Algoritmos de balance de carga Son algoritmos que permiten aprovechar esta gran funcionalidad de la tecnología MPLS descrita en el capítulo 2. En general consisten en, dado un flujo de entrada a un LER y varios LSPs para llegar a otro LER, encontrar la manera de repartir dicho flujo minimizando cierta función de costo que puede ser el retardo, pérdida de paquetes o ancho de banda residual. Un ejemplo de estos algoritmos es MATE [37], que toma como función de costo el retardo de los LSPs. Muchos autores han planteado mejoras a este algoritmo, por ejemplo en [38] plantean un par de modificaciones que permiten trabajar con flujo de entrada variable y adaptar el tiempo entre pasos. Otros autores en [40] proponen calcular la derivada de la función de costo utilizando el método estadístico SPSA (Simultaneous Perturbation Stochastic Aproximation). Un ejemplo de implementación de una variante de MATE junto con una descripción más detallada de las distintas versiones del algoritmo se presenta en el capítulo 7. Cabe aclarar que todos los algoritmos derivados de MATE son para túneles del tipo best-effort y no están pensados para túneles con reservas de ancho de banda. Otro ejemplo de algoritmo para balance de carga es el OPIATE (Optimization Integrated Adaptive Traffic Engineering [29]), donde los autores proponen una alternativa que, a diferencia de MATE, no realiza medidas activas que perturben el tráfico. La formulación de este problema es similar al MATE, se utiliza como función de costo también el retardo pero se estima utilizando el de una cadena de Markov M/M/1. La iteración es similar también a la de MATE pero con la diferencia de que, en vez de basarse en medidas, los LERs de ingreso se comunican mutuamente el tráfico que están cursando. Otro enfoque distinto es presentado en [39] donde los autores presentan un algoritmo de balance de carga en línea basado en la información de tasa de utilización de los enlaces. La consigna es cómo dividir el tráfico en los caminos existentes para minimizar la máxima utilización de enlaces en la red. El algoritmo es ejecutado por los propios LERs de entrada y los autores argumentan que los cambios que se deben realizar al hardware existente son muy pocos.

54 34 Capítulo 3. Estado del arte en Ingeniería de Tráfico Algoritmos de reenrutamiento Los algoritmos de reenrutamiento buscan detectar enlaces congestionados y reenrutar uno o varios LSPs que pasan por ellos a otro camino menos congestionado. En general buscan actuar rápido más que llegar a un óptimo, debido a que deben actuar en situaciones de congestión que deben ser eliminadas lo antes posible. El procedimiento general es, a través de una monitorización de la red, identificar cuándo un enlace supera cierto umbral de utilización, buscar todos los LSPs que pasan por ese enlace y elegir un LSP a reenrutar. El criterio puede ser por ejemplo reenrutar el LSP de mayor ancho de banda. Para reenrutar el túnel se puede correr cualquier algoritmo de CBR para encontrar el nuevo camino, con la restricción de que no pase por el enlace congestionado. Posibles implementaciones de esta clase de algoritmos se encuentran en [23] y [28] Conclusiones Se presentaron distintos algoritmos de Ingeniería de Tráfico en línea agrupados en tres categorías según su función. A su vez, se explicaron los fundamentos de cada uno y se presentaron referencias a las implementaciones detalladas Herramientas de Ingeniería de Tráfico en ĺınea Las numerosas ventajas que presenta el protocolo MPLS y su gran popularidad han hecho que muchos grupos se interesaran en su estudio. Muchas herramientas han sido desarrolladas para gestionar las redes por lo que se mostrarán aquí solo las que presentan características similares a las que se buscan en este proyecto. En esta sección se comentan estas herramientas y se muestra cómo resuelven los problemas presentados en las secciones anteriores de este capítulo Sequin: An SNMP-Based MPLS Network Monitoring System El proyecto Sequin [22], desarrollado por Bell Labs, es una herramienta de monitorización de redes que operan con los protocolos MPLS y Diffserv. El objetivo es crear una aplicación capaz de monitorizar tráficos con distintas clases de servicio para poder cumplir y controlar SLAs (Service Level Agreement). La herramienta consta de seis módulos: Netmon: Realiza consultas SNMP a los enrutadores de la red para obtener sus valores de performance. Nethealth: Este módulo, a partir de la información recolectada por Netmon, detecta situaciones de congestión y sobrecarga en la red. NodeQoS: Procesa la información recolectada por NetMon y calcula a partir

55 3.6. Herramientas de Ingeniería de Tráfico en ĺınea 35 Figura 3.1: Arquitectura del proyecto Sequin. Fuente: [22] de ella otros parámetros de calidad de servicios de interés. NetSyn: Sintetiza los parámetros de calidad de servicio del módulo NodeQos y los correlaciona para estimar características de extremo a extremo en la red. NetVis y Mirage: Proporcionan una interfaz gráfica y capacidad de graficar los distintos parámetros de performance respectivamente. La aplicación está desarrollada en JAVA y cada módulo corre en una máquina virtual independiente que a su vez pueden estar distribuidas en distintos equipos. Además de los módulos mencionados, la aplicación cuenta con bases de datos para almacenar la topología y parámetros de performance. Los autores aseguran también que está pensada para una fácil integración con otras aplicaciones como por ejemplo de facturación o aprovisionamiento a través del uso de la interfaz de programación de aplicaciones CORBA (Common Object Request Broker Application). Tanto para el descubrimiento de la topología como para la monitorización utiliza el protocolo SNMP. Una de las características más interesantes que presenta esta aplicación es el módulo NetHealth. Implementa métodos de aprendizaje en línea y provee indicadores del estado de salud de los nodos, con la posibilidad de caracterizar estadísticamente algunos tipos de fallas. En la figura 3.2 se puede ver su diagrama de bloques.

56 36 Capítulo 3. Estado del arte en Ingeniería de Tráfico Figura 3.2: Algoritmo del proyecto Sequín para detección de anomalías. Fuente: [22] El único punto que parece débil es que estima los parámetros de performance extremo a extremo a partir de los locales, ya que en general es muy difícil que las estimaciones sean correctas. Sería deseable contar con un módulo de medidas extremo a extremo. Vale la pena aclarar que esta herramienta implementa el descubrimiento de la topología y la monitorización de la red y no acciones de Ingeniería de Tráfico ni reconfiguración RATES: Routing and Traffic Engineering Server RATES [24] es una aplicación para realizar Ingeniería de Tráfico en línea en redes MPLS. El objetivo principal es el aprovisionamiento de conectividad, aunque también está pensado para atacar el problema de la recuperación de la red frente a fallas y la reoptimización de la misma. La arquitectura de la aplicación se presenta en la figura 3.3. Los módulos que la componen son: Graphical User Interface: Esta interfaz permite tener una visualización gráfica del estado de la red. Además permite definición de políticas administrativas, monitorización de la utilización de la red, creación de LSPs y visualización de alarmas. Explicit Route Computation: Este módulo toma en cuenta el estado de la red, políticas, restricciones y solicitudes de usuario para el cómputo de caminos. Implementa un algoritmo de mínima interferencia como los que se comentan el la sección 3.5. LSP Restoration: Permite reenrutar un LSP si detecta que se cayó, por ejemplo por la falla de un enlace. Además está pensado para soportar los mecanismos de fast restoration de MPLS. Debido a que utiliza un algoritmo de mínima interferencia para el aprovisionamiento, la probabilidad de que encuentre un camino para el reestablecimiento del LSP es máxima.

57 3.6. Herramientas de Ingeniería de Tráfico en ĺınea 37 Figura 3.3: Arquitectura RATES. Fuente: [24] Data Repository. Es un base de datos relacional para almacenar la información de los demás módulos como por ejemplo el estado de la red y las políticas administrativas. COPS Policy Server. Todas las decisiones de políticas de usuario o del módulo de Ingeniería de Tráfico son comunicadas a los elementos de la red utilizando el protocolo COPS. Para esto utiliza extensiones de dicho protocolo para soportar las funcionalidades de Ingeniería de Tráfico. Network Topology and State Discovery: Participa del protocolo de ruteo OSPF para descubrir la topología y estado de la red. Como conclusión se puede decir que es un herramienta centralizada de Ingeniería de Tráfico en línea. Obtiene la información de la red mediante la participación del ruteo, transmite cambios a la red utilizando el protocolo COPS e implementa un algoritmo de ruteo de mínima interferencia.

58 38 Capítulo 3. Estado del arte en Ingeniería de Tráfico RONDO Rondo es un sistema automático de control de congestión en tiempo real. Está pensado para utilizarse en redes dorsales MPLS. Figura 3.4: Arquitectura RONDO. Fuente: [23] La arquitectura de RONDO consiste en los siguientes elementos: Load Generators: Son PCs programados para generar cargas variables en el tiempo, similares a las que produciría el tráfico real. Data Collection System: Monitoriza el estado de la red. Incluye medidas tanto activas como pasivas que permiten obtener por ejemplo throughput, retardo y jitter. La información se almacena en una base de datos (Database). Database: Almacena la topología física y virtual, configuración y medidas de la red. Analysis and Rerouting Engine: Implementa técnicas para detectar congestión y alterar el tráfico para volver a una situación normal. MPLS Configuration and Control: Permite señalizar nuevos túneles, para reenrutar el tráfico cuando se genera congestión. El objetivo no es llevar la red a un estado óptimo sino reenrutar el tráfico lo más rápidamente posible. Para eso RONDO monitoriza periódicamente la red en busca de enlaces congestionados. Los enlaces cuyo tráfico sobrepasa un cierto umbral, son marcados como candidatos de reoptimización. Luego se reoptimizan los LSPs que pasan por los enlaces candidatos. La configuración de los enrutadores es realizada a través del CLI (Command Line Interface), aunque los autores aclaran que cuando esté disponible la MPLS-TE-MIB para configuración, la realizarán por SNMP.

59 3.7. Conclusiones 39 El algoritmo implementado por RONDO es del tipo de reenrutamiento, como los presentados en la sección Herramientas propietarias de los fabricantes Además de las herramientas presentadas anteriormente, cada fabricante tiene sus propias herramientas de gestión. En este trabajo no se estudian en detalle ya que en general no cumplen uno de los objetivos buscados: funcionar cualquiera sea el fabricante. Un ejemplo es el Cisco IP Solution Center, que permite entre otras cosas levantar la topología física y virtual, estadísticas y medidas de performance de la red además de señalizar túneles Conclusiones Se estudiaron distintas herramientas para Ingeniería de Tráfico en MPLS. En particular se buscaron arquitecturas que fueran pensadas para operar con cualquier fabricante y que permitieran realizar Ingeniería de Tráfico en línea. Un comparativo de las herramientas analizadas se muestra en la tabla 3.1. Si bien las arquitecturas tienen muchos aspectos en común, se obtuvieron muchas ideas de cada una que se ven reflejadas en la implementación realizada. Herramienta Topología SEQUIN SNMP Monitorización Reconfiguración Algoritmo TE y es- SNMP cálculos tadísticos RATES OSPF-TE OSPF-TE COPS RONDO SNMP SNMP y CIS- CO RTTMON - - Tabla 3.1: Comparación de las herramientas. Mínima Interferencia CLI Reentuamiento 3.7. Conclusiones En este capítulo se presentaron las alternativas existentes para atacar los principales procesos involucrados en la Ingeniería de Tráfico. También se presentaron algunas herramientas que tienen las características que se buscan en este proyecto y se explicó cómo resuelven los procesos mencionados. A partir del estudio presentado en este capítulo es que se comenzó a diagramar la aplicación de Ingeniería de Tráfico en línea implementada. Se tuvieron en cuenta para ello las ventajas y fortalezas de cada una de las herramientas estudiadas.

60

61 Parte II Solución Implementada

62

63 Capítulo 4 Arquitectura En este capítulo se presenta la arquitectura elegida para la herramienta. Esto da paso a, en los próximos capítulos, entrar en los detalles de la implementación de cada módulo que la compone RMA: Routing and Management Agent La arquitectura elegida para la implementación está basada en el RMA (Routing and Management Agent), propuesta por Eduardo Grampín en su tesis doctoral [30]. El objetivo principal de ésta es separar el cómputo de caminos del establecimiento de los mismos y el reenvío. En esta arquitectura los LSRs delegan el cálculo de caminos al RMA, ya que en general es una tarea muy costosa computacionalmente y para la cual no están preparados. En el trabajo realizado por el grupo RMA Control [41] se presentan algunas modificaciones a la arquitectura básica del RMA. A lo largo de este documento por RMA se entenderá la arquitectura del referido trabajo. En la figura 4.1 se muestra la arquitectura que consta de los siguientes módulos: Topology Interface: Es la encargada de descubrir la topología física de la red (enrutadores y enlaces). Monitoring Interface: Debe descubrir el estado de la red. Incluye los LSPs de MPLS y parámetros de performance. Signaling Interface: Debe desencadenar la señalización de los cambios computados por el RMA en la red. TED: Es una base de datos que guarda la información de topología y estado de la red. CBR: Es el motor de cómputo de LSPs basado en restricciones. 43

64 44 Capítulo 4. Arquitectura Figura 4.1: Arquitectura RMA. Fuente: [41]. Management Interface: Permite la visualización del estado de la red y acciones de gestión por parte del operador. Además de los módulos antes mencionados existe un protocolo para la comunicación entre los módulos llamado GRMAP (Generalized RMA Protocol) y un modelo de información utilizado en dicha comunicación. Si bien el protocolo GRMAP fue propuesto por el grupo RMA control, en el presente proyecto sugirieron algunas modificaciones que fueron incorporadas. A su vez, el modelo de información, fue desarrollado en conjunto con el grupo RMA control tomando como base el propuesto por el proyecto TOTEM [32]. Las razones para la elección de esta arquitectura fueron que cumple con todos los requerimientos estudiados en la parte I y que había otro grupo en la Facultad trabajando en ella. Los requerimientos básicos del presente proyecto eran la posibilidad de monitorizar la red, producir cambios en los túneles, crearlos, darlos de baja y asociarles tráfico. Los mismos también incluían la independencia del fabricante

65 4.1. RMA: Routing and Management Agent 45 y el actuar lo más cercano al tiempo real posible. Todos estos requerimientos son realizables con la arquitectura RMA, como se explicará en los siguientes capítulos. En este trabajo se sugiere agregar a la arquitectura RMA un módulo de Ingeniería de Tráfico llamado TE, que permite la detección de posibles situaciones de congestión en la red, la toma de decisiones y las acciones para evitarla o solucionarla. Además se propone la adaptación del software Net-TE [45], desarrollado en el IIE, como interfaz de gestión para que permita, además de visualizar gráficamente el contenido de la base de datos, la señalización de LSPs en forma manual por parte del operador. Otro agregado sugerido por el presente proyecto es el de asignar la responsabilidad del mapeo de tráfico a la interfaz de señalización. Esta responsabilidad no aparece explícitamente asignada a ningún módulo de la arquitectura RMA. No obstante la versatilidad de la arquitectura permite que la inclusión se pueda hacer de manera natural. La arquitectura modificada se puede ver en la figura 4.2. Vale la pena mencionar que las modificaciones son perfectamente compatibles con la arquitectura original, ya que está prevista la interfaz de gestión y el módulo TE se puede ver como una extensión del módulo CBR. Como consecuencia el cambio propuesto no implica cambios en los demás componentes. Figura 4.2: Arquitectura implementada. A los efectos de la implementación se coordinó con el grupo RMA una división

66 46 Capítulo 4. Arquitectura de tareas para lograr un beneficio en ambos grupos. En un principio el grupo RMA quedó responsable de la implementación de la base de datos con sus interfaces, la interfaz de señalización, el módulo de CBR y la interfaz de topología, mientras que el presente grupo de la interfaz de topología y la interfaz de monitorización. El motivo por el que se decidió que la interfaz de topología fuese implementada por ambos grupos fue para permitir que se utilizaran dos enfoques distintos y se compararan sus desempeños. Además de los módulos mencionados en el presente proyecto se desarrolló el módulo TE propuesto y se desarrolló una interfaz de gestión mediante la adaptación del software previo Net-TE. También se hicieron modificaciones sobre la interfaz de señalización implementada por el grupo MINA [44] del INCO Conclusiones Se presentó la arquitectura RMA, arquitectura elegida como base para la implementación de la aplicación. Esta cumple con todos los requerimientos del proyecto y el hecho de haber otro grupo en la Facultad trabajando en ella, permitió focalizar las distintas implementaciones de manera de obtener mejores resultados y potenciar el trabajo en equipo. Se propuso agregar un nuevo módulo de Ingeniería de Tráfico llamado TE, que no involucra modificaciones en el resto de los componentes y permite atacar la congestión en la red. A su vez, al tener definidas las interfaces en todos los módulos, es posible la sustitución de cada implementación por otra que realice las funciones de manera distinta y poder comparar los resultados de cada una.

67 Capítulo 5 Módulo Topología En este capítulo se presenta el Módulo Topología, se explica su objetivo y se detalla su implementación Objetivo La interfaz topología es la encargada de descubrir la topología de la red bajo estudio. Debe, por lo tanto, descubrir los enrutadores y enlaces existentes en la red automáticamente. Es también de utilidad, tanto para otros módulos como para una administración más simple de la red, que descubra direcciones IP de todas las interfaces, router id de los nodos y los nombres de los equipos. Este módulo considera la topología a nivel de la capa de red, sin tener en cuenta cual es el protocolo subyacente. Aclarado esto se hace evidente que toda información relativa a MPLS y los caminos establecidos no son competencia de este módulo. La recolección de esta información es realizada por otro: el módulo de monitorización. Tampoco está dentro del alcance de este módulo obtener parámetros de performance de la red ni de los enrutadores. Se debe tener en cuenta el factor tiempo, ya que este proyecto en su totalidad busca aproximarse al tiempo real. Existe una fuerte restricción en cuanto a mantener sincronizada la TED con el estado real de la red. Es por esto último que se deben buscar mecanismos para que la aplicación tome conocimiento de los cambios en la topología de la red, lo más próximo posible en el tiempo a su ocurrencia, y esta información sea transmitida a la TED con igual prontitud. En las próximas secciones de este capítulo se presenta la solución elegida e implementada, se analizan los resultados y se obtiene un número de conclusiones Solución implementada La solución implementada contempla que el caso de estudio es una red de la cual se tiene acceso a los nodos vía SNMP. 47

68 48 Capítulo 5. Módulo Topología Otro supuesto fuerte es que en la red está corriendo el protocolo de ruteo interno OSPF. La solución podría adaptarse a otro protocolo de ruteo de estado de enlace. Si bien el protocolo OSPF se clasifica dentro de los protocolos de ruteo de estado de enlace, es decir que cada nodo recibe información sobre los vecinos de todos los nodos de la red, esta información no es almacenada en la porción de MIB estándar correspondiente a OSPF. En cada nodo se guarda información sobre los vecinos de ese mismo nodo y no de los otros de la red. Por lo tanto, para obtener información global se debe ir consultando todos los nodos. La arquitectura elegida define la interacción de éste con los demás módulos a través, y sólo a través, de la base de datos (TED). Queda entonces la dependencia entre módulos basada únicamente en la información que se encuentra almacenada en dicha base de datos. De esta manera se garantiza el poder experimentar con distintas soluciones de este módulo de manera transparente a las otras componentes del proyecto. La implementación tomó como base una versión previa realizada como parte del software Net-TE [45]. La misma no había podido ser probada exhaustivamente por lo que se debieron hacer ajustes para que se comportase adecuadamente en todos los escenarios. Además como no fue concebida para trabajar en línea, algunos aspectos del algoritmo tuvieron que ser mejorados. Como consecuencia, se decidió reescribir el algoritmo de levantamiento de topología y el acceso a la información SNMP para optimizar el tiempo de ejecución. Además se agregaron otros parámetros que no eran recolectados por la aplicación original como las direcciones IP y nombre de los nodos Información recolectada Para comprender el funcionamiento del algoritmo es necesario primero detenerse en la descripción de la información que se consulta durante el desarrollo del mismo. La totalidad de la información necesaria para descubrir la topología de la red bajo estudio se obtiene de consultas a la MIB-II y sus extensiones [12] y en especial a la porción correspondiente a OSPF versión 2 [13]. La información almacenada en la MIB de OSPF que resulta de interés para la aplicación es la de la tabla de vecinos OSPF. Esta tabla cuenta con el router Id (identificador único), la dirección IP por la cual está conectado y otros datos de cada vecino. Para cada adyacencia OSPF hay una entrada en la tabla con los datos anteriormente mencionados. En la figura refospfmib puede observarse la estructura de la MIB de OSPF. El resto de la información necesaria se obtiene del modulo de IP de la MIB- II y del módulo de interfaces. Fundamentalmente la información obtenida de estos módulos es la necesaria para conocer la dirección IP por la cual se accede a cada uno de los vecinos y la velocidad de la interfaz. La estructura de la MIB-II puede verse en la figura 5.2. A continuación se muestra un ejemplo muy simple de cómo se puede realizar el

69 5.2. Solución implementada 49 (a) OSPF-GENERAL (b) OSPF-NBR Figura 5.1: OSPF-MIB. proceso, de manera que el lector pueda introducirse en la solución. La red en la que se basa el ejemplo luce en la figura 5.3. Al módulo topología se le brinda la información de una dirección IP de la red. Con esta información comienzan las consultas SNMP. La primera consulta se dirige a esa dirección y obtiene como respuesta la tabla resumida en la figura 5.3(b). Con esta información el módulo logra saber de la existencia de los nodos RB y RC. Tras verificar, con la información contenida en dicha tabla, que el nodo está activo, realiza una consulta SNMP al nodo RB obteniendo la información mostrada en la figura 5.3(c). Esta información le permite identificar al nodo RC y RA, que ya fueron descubiertos. Realiza entonces una consulta al nodo que conoce, pero aún no ha consultado, obteniendo la tabla mostrada en la figura 5.3(d). La información de esta tabla no proporciona nodos nuevos, sino que solo aporta información de enlaces y un nodo que no está activo, por lo que la iteración culmina Pre- configuración La herramienta desarrollada tiene como punto de partida la dirección IP de uno de los nodos de la red. Tiene también que cumplirse que el equipo en el cual corre la aplicación tenga conectividad con la red a descubrir. La configuración previa se hace a través de un archivo de configuración que reside en el mismo directorio que la aplicación. En dicho archivo debe explicitarse la dirección IP de uno de los equipos de la red a descubrir y los parámetros asociados al protocolo SNMP. Dentro de los parámetros asociados a SNMP existen algunos obligatorios (community, puerto TRAPS) y algunos opcionales (puerto, reintentos,

70 50 Capítulo 5. Módulo Topología (a) MIBII-GENERAL (b) MIBII-IF Figura 5.2: MIB-II. temporizador). También con carácter opcional se pueden incluir parámetros que definan el comportamiento de la aplicación incluyendo la frecuencia con la que se debe correr el algoritmo Algoritmo Se desarrolló un algoritmo en el cual, a partir de una dirección IP conocida, se itera consultando los sucesivos nodos hasta descubrir por completo la red. El algoritmo se puede representar con el diagrama de bloques mostrado en la figura 5.4. De esta manera siempre que se avanza en al lista nodosred el nodo al que se va consultar aún no fue consultado. Cuando se termina la lista se terminó de descubrir la red. La aplicación de descubrir la topología no implica únicamente el algoritmo ante-

71 5.2. Solución implementada 51 (a) Red de ejemplo (b) Tabla de vecinos OSPF RA (c) Tabla de vecinos OSPF RB (d) Tabla de vecinos OSPF RC Figura 5.3: Ejemplo: descubrimiento de la topología física. riormente descrito, sino que incluye también una lógica y temporizadores para que se logre mantener la base de datos TED con información certera sobre el estado de la red. La lógica implica que el algoritmo se corre cada determinado tiempo que puede ser definido por el usuario mediante el archivo de configuración. En caso de que no sea explicitado, existe un valor por defecto. Este valor supone que la red es algo estático cuya topología cambia por razones excepcionales, por lo que es de 60 minutos. Durante este tiempo la aplicación no corre el algoritmo pero si escucha notificaciones SNMP lo que le permite saber si hubo un cambio en la topología. Se soporta una notificación de OSPF que se describe con mayor detalle en la seccion siguiente. Al recibir este tipo de notificaciones la aplicación corre nuevamente el algoritmo, aun cuando no hayan transcurrido 60 minutos desde la última ejecución.

72 52 Capítulo 5. Módulo Topología Figura 5.4: Algoritmo de Topología Notificaciones Como se dijo antes en este capítulo, el Módulo Topología no sólo debe levantar la topología física sino también mantenerla actualizada en la base de datos TED. Si bien una manera de realizar esto podría ser levantar la topología cada un tiempo determinado, esto no es recomendable. La principal razón es que es difícil estimar el tiempo adecuado, ya que por un lado no se quiere hacer consultas muy seguidas para no inundar la red y congestionar los nodos, y por otro es deseable detectar los cambios lo más rápidamente posible. La opción elegida para atacar este problema fue utilizar TRAPS del protocolo SNMP. Se utilizan las notificaciones ospfnbrstatechange de la OSPF-TRAP-MIB para detectar las caídas de nodos o enlaces. El protocolo OSPF utiliza un mensaje HELLO para establecer y comprobar que siguen activas las adyacencias entre vecinos. El mismo se envía cada un intervalo de tiempo denominado HELLO-INTERVAL que por defecto es 10 segundos. Si un

73 5.2. Solución implementada 53 nodo no recibe el mensaje HELLO de un vecino en un tiempo que por defecto es 4 veces el HELLO-INTERVAL (40 segundos), considera que perdió la adyacencia y cambia el estado de ese vecino. Como consecuencia, el cambio en la topología se detecta aproximadamente 40 segundos después que ocurre. En la implementación realizada, cuando se recibe la TRAP ospfnbrstatechange, se corre el algoritmo de descubrimiento de topología nuevamente para obtener la nueva topología. Una alternativa podría ser modificar la topología en función de la información contenida en la TRAP. Si bien esto aceleraría la actualización de la topología, podría generar problemas en caso de cambios grandes de la misma además de ser más complicada su implementación. Sería interesante poder comparar el desempeño de la solución implementada respecto a una basada en la participación del ruteo. El objetivo sería determinar si el tiempo que se gana para descubrir los cambios participando en el ruteo amerita la implementación del protocolo de ruteo en software. Para realizar un estudio de tiempos es necesario tener en cuenta: el tiempo transcurrido entre el cambio en la topología y su incorporación por parte del protocolo de ruteo el tiempo transcurrido desde que el cambio es incorporado por el protocolo de ruteo y se descubre por la aplicación. El primero de los tiempos mencionados es igual en ambos enfoques ya que solamente depende de la configuración de la red. Para el segundo hay que tener en cuenta cuánto demora en llegar la TRAP o el mensaje de OSPF a la aplicación. Este tiempo es difícil de determinar sin realizar pruebas. Además los mensajes del protocolo de ruteo llegan por inundación, mientras que las TRAPS son enviadas una sola vez y no tienen confirmación de recepción. Esto hace que pueda ser que la notificación nunca llegue a la aplicación mientras que los mensajes del protocolo de ruteo generalmente llegan. En [35] se comparan ambos enfoques para distintas topologías, mostrando que en general los mensajes del protocolo llegan aproximadamente 2 segundos antes que las TRAPS. Además se muestra que en ciertas situaciones de alta congestión las TRAPS nunca llegan. Debido a que las notificaciones pueden no llegar en situaciones de alta congestión, podría ajustarse el intervalo en que se descubre la topología de acuerdo al estado general de congestión de la red detectado por el módulo de monitorización. Para la aplicación implementada, la solución adoptada para este problema es levantar la topología cada cierto tiempo especificado por el usuario. Asumiendo que los resultados presentados en [35] son extensibles a cualquier topología, no sería una ventaja considerable una ganancia de 2 segundos en un tiempo total del orden de 40 segundos por parte de la solución de participación del ruteo. El escenario antes descrito se da cuando un enrutador debe decidir si perdió la adyacencia por ausencia del mensaje de mantenimiento de estado (HELLO). Puede

74 54 Capítulo 5. Módulo Topología darse también el caso de que un enrutador detecte que una de sus interfaces ha sido dada de baja (ya sea administrativa u operativamente) por lo que en este escenario la TRAP será enviada inmediatamente. De todas maneras, como se menciona en el capítulo 12, lo ideal sería poder realizar pruebas del módulo implementado y uno que implementara la participación del ruteo. Será posible realizar esto cuando esté lista la solución del grupo RMA Control Conclusiones En este capítulo se presentó la implementación del módulo de topología. Se describió detalladamente el algoritmo de descubrimiento de la topología física, incluyendo sus entradas y sus salidas. Se desarrolló un módulo autónomo que permite obtener la información requerida para representar la topología física de una red dorsal IP. Si bien el módulo tiene como requisito el hecho de que en los nodos estén corriendo los protocolos OSPF y SNMP, estos protocolos son implementados por la gran mayoría de los fabricantes ya que se consideran dentro del modelo TCP/IP. Es por ello que este requisito no se considera restrictivo para la aplicación. El trabajo realizado redundó en una mejora notable de los tiempos consumidos por la aplicación, con respecto a la implementación anterior del software Net-TE. El tiempo de respuesta de la solución implementada para este módulo es analizado dentro del capítulo 12 junto con los demás módulos. Si bien, por no estar dentro de los objetivos principales del proyecto, no se realizó un estudio de los requerimientos computacionales y ni del impacto que tiene el tráfico introducido, se tuvo en cuenta siempre a la hora de realizar el diseño el minimizar ambos aspectos. En cuanto a los objetivos planteados sobre la información a recolectar, se cumplieron todos, incluso aquellos que no son fundamentales para la Ingeniería de Tráfico, como los nombres de los nodos. Esto es muy importante ya que el resto de los módulos se basan en la información de la topología recogida por éste. Las aplicaciones de este módulo pueden parecer en principio acotadas por la cantidad de información que recoge, pero son en realidad un espectro muy amplio, ya que es la base para cualquier acción que se desee llevar a cabo en la gestión de una red. Además no está acotada dentro del dominio MPLS, sino que se puede utilizar en el descubrimiento de cualquier red IP. Si bien actualmente se apoya en OSPF, la dinámica del algoritmo es perfectamente adaptable a otros protocolos de ruteo ya que se basa únicamente en el conocimiento de los vecinos por parte de cada nodo.

75 Capítulo 6 Módulo Monitorización En este capítulo se presenta el Módulo Monitorización, se repasan sus objetivos y se detalla la solución implementada Objetivos La interfaz de monitorización es la encargada del descubrimiento de la topología virtual y de la obtención de los parámetros de performance o desempeño. Por topología virtual se entiende el conjunto de caminos de la tecnología MPLS establecidos, llamados LSP, y el tráfico mapeado en ellos a través de FECs. Se parte de la base que la topología física es conocida y está disponible para consultarse en la base de datos TED, a través del protocolo GRMAP. Con respecto a los parámetros de desempeño, el objetivo fundamental es tener información acerca de cómo está siendo soportado por la red el tráfico cursado. Dado que la herramienta busca actuar en línea, lo más cercano al tiempo real posible, es deseable que los parámetros de desempeño sean recolectados rápidamente. Dado que la interacción con los demás módulos es a través de la mencionada TED, otro de los objetivos de este módulo es volcar la información recolectada a dicha base de datos. En las siguientes secciones se presenta la forma en que se atacó el problema, los resultados obtenidos, la solución final implementada y las conclusiones correspondientes Solución implementada La solución implementada contempla que el caso de estudio es una red de la cual se tiene acceso a los nodos vía SNMP, por lo que todos los nodos deben implementar este protocolo. A su vez es necesario, para obtener la totalidad de los parámetros de interés, 55

76 56 Capítulo 6. Módulo Monitorización contar con acceso a los nodos mediante TELNET. Si bien el objetivo principal del proyecto es el de implementar la comunicación con los nodos mediante SNMP, hay ciertos parámetros que no están disponibles y son de gran interés para la Ingeniería de Tráfico. Para obtener estos parámetros se desarrollaron interfaces que actúan de proxy hacia los nodos y que permiten separar las componentes que son específicas para cada fabricante. Para el caso de las consultas SNMP, se planteó como principal objetivo que la información se obtuviera de MIBs estándar. Este objetivo permite que la herramienta funcione cualquiera sea el fabricante de los equipos que componen la red, siempre y cuando se encuentren implementadas dichas MIBs. Existen casos en que las MIBs estándar no se encuentran implementadas, por lo que se debió recurrir a MIBs propietarias. El detalle de las MIBs consultadas se presenta más adelante en este capítulo. En búsqueda de una mayor robustez, y de manera de aprovechar el requisito de que la red soporte SNMP, se implementó la recepción de notificaciones. Estas notificaciones son generadas cuando hay cambios en la información contenida en las MIBs y el protocolo soporta la especificación de cuáles notificaciones se desean recibir. El detalle de las notificaciones soportadas se presenta más adelante en la siguiente sección Descubrimiento de la topología virtual El primer problema que busca solucionar el módulo de monitorización es el de obtener, de manera automática, los LSPs configurados en una red cuya topología física es conocida. Es necesario conocer los LSPs configurados, lo que implica conocer el nodo de ingreso, el nodo de egreso y todos los nodos intermedios. Es deseable conocer un identificador único para cada camino originado en un nodo, llamado LSP ID, aunque esta información no es fundamental para la caracterización de los LSPs. Es deseable también conocer las parámetros de Ingeniería de Tráfico asociados a cada LSP como ancho de banda reservado (en el plano de control), porcentaje de reparto de carga y tipo de tráfico que cursa (FEC). No está dentro del alcance de este módulo descubrir la topología física, sino que es un dato de entrada, y se puede obtener mediante la consulta a una base de datos. Esto hace que se deba estudiar cuidadosamente la frecuencia con que se levanta y actualiza la topología física, ya que esta aplicación solamente descubre LSP sobre nodos y enlaces existentes. La implementación debe ser robusta y tener en cuenta que si bien la topología física no debería cambiar, pueden resultar casos patológicos ya sea por caídas o apariciones de nodos o enlaces nuevos que requieran la actualización de la misma. Durante la etapa de diseño del módulo se planteó el descubrimiento de los caminos a través de la información presente en las tablas de de la MPLS-LSR-MIB. Entre ellas se encuentran la MplsInSegmentTable, la MplsXCTable y la MplsOutSeg-

77 6.2. Solución implementada 57 menttable. En dichas MIBs se especifica toda la información de encaminamiento, de la cual se puede deducir el mapeo entre interfaz de entrada-etiqueta de entrada e interfaz de salida-etiqueta de salida. A su vez se define que los nodos de ingreso o Head y los nodos de egreso o Tail presentan formatos especiales para las entradas de la tabla MplsInSegmentTable y MplsOutSegmentTable respectivamente. Se realizó un pre-diseño del algoritmo de descubrimiento que consistió en filtrar la información de las tablas mencionadas para determinar cuáles entradas corresponden a LSPs originados en el nodo que se consulta, determinar la interfaz de salida y la etiqueta de salida y pasar a consultar al siguiente nodo. Luego en el siguiente salto consultar las mismas tablas para determinar la información de encaminamiento correspondiente y así iterar hasta encontrar el correspondiente nodo de egreso. Al llevar este algoritmo a la práctica se encontraron casos en que la información en principio pareció incoherente. En primer lugar no se encontraron nodos que cumplieran la condición de Head dentro de la red de pruebas y en segundo lugar se encontraron asociaciones de una misma interfaz de salida-etiqueta de salida para varias interfaces de entrada-etiquetas de entrada distintas. Se realizaron una importante cantidad de pruebas, las que luego de un tiempo considerable arrojaron como conclusión que existían caminos que no tenían un nodo origen. Este tipo de caminos resultaron ser el mapeo de las rutas de la capa de red realizado por los protocolos de distribución de etiquetas, como se explicó en la sección Los mismos forman un árbol, cuya raíz es el nodo destino y cuyas ramas son todos los enlaces y nodos desde donde puede provenir el tráfico. Claramente, si se desea conocer este tipo de topología virtual, se encuentra la dificultad de que no hay un nodo de ingreso, nodos intermedios y un nodo de egreso que utilicen un conjunto de etiquetas único. Esto es así ya que cuando dos ramas se unen en un nodo, éste realiza agregación y reencamina los paquetes por la misma interfaz de salida y con la misma etiqueta. Si bien es deseable conocer todos los caminos establecidos en la red, dentro de los cuales se encuentran los correspondientes al referido mapeo, la complejidad del algoritmo que los descubra lo hace inviable para cualquier tipo de aplicación que busque aproximarse al tiempo real. Es razonable a su vez, considerar que el tráfico que cursen estos caminos no será el de preferencia para la aplicación de Ingeniería de Tráfico. Luego de haberse discutido con los clientes/tutores, se decidió descubrir solamente los túneles de Ingeniería de Tráfico. Este aspecto constituyó un punto de inflexión importante en la implementación de este módulo. En el resto de este documento estos caminos se llamarán indistintamente LSPs, túneles o caminos del ruteo explícito. A. Información recolectada Para comprender el funcionamiento de la implementación es necesario primero detenerse en la descripción de la información que se consulta durante el desarrollo del

78 58 Capítulo 6. Módulo Monitorización mismo. La totalidad de la información necesaria para descubrir los LSP configurados en la red se obtiene de consultas a la porción de MIB de MPLS-TE-STD (RFC 3812) y sus extensiones. Figura 6.1: MPLS-TE-MIB. La información almacenada en la MIB de MPLS-TE que resulta de interés para esta aplicación es la que se encuentra en la tabla de túneles, en la tabla de saltos computados y en la tabla de recursos MPLS. La primera cuenta con el nombre y las características generales del túnel, así como con los índices de búsqueda para las entradas correspondientes a este túnel en las demás tablas. La segunda cuenta con la información correspondiente a los restantes nodos que componen este túnel y la tercera cuenta con información de los recursos reservados para este túnel en el plano de control, como ancho de banda, ráfaga media, ráfaga de pico, y tamaño máximo de ráfaga. El coeficiente de reparto de carga entre los LSPs no se encuentra disponible a la fecha en ninguna MIB, por lo que, dado que era imprescindible para el funcionamiento del módulo de Ingeniería de Tráfico, se optó por obtenerlo mediante la interpretación de la configuración de los nodos. Se consideró la implementación de conexión directa al CLI del nodo y la obtención de la configuración utilizando SNMP y TFTP, ambas estudiadas en el capítulo 2. Se decidió utilizar la opción de TFTP ya que, como se explicó en el mencionado capítulo, es más rápida. Además con esta solución no es necesario que la herramienta posea la clave del nodo, solamente la community de SNMP. B. Pre- configuración La herramienta desarrollada tiene como punto de partida la conexión a la TED, de la cual se obtiene la información que representa la topología física de la red. Tiene

79 6.2. Solución implementada 59 también que cumplirse que el equipo en el cual corre la aplicación esté conectado a la red. La configuración previa se hace a través de un archivo que reside en el mismo directorio que la aplicación. La información de este archivo es similar a la presentada en el capítulo 5 para el Módulo Topología. C. Algoritmo de descubrimiento de LSPs El algoritmo que descubre cada LSP configurado en la red utiliza la información de la topología física obtenida de la base de datos para iniciar las consultas SNMP. Dichas consultas se realizan de manera simultánea para todos los nodos de la red. La iteración se puede representar con el diagrama de bloques mostrado en la figura 6.2. Allí se puede ver que se agregan todos los saltos de los LSPs verificando que pertenezcan a la topología física obtenida de la base datos. En caso de que algún salto no pertenezca a la misma igualmente se incorpora el LSP a la topología virtual pero se considera como destino la última dirección conocida. Se almacena también, además de toda la información necesaria para el descubrimiento de LSPs, la información útil para la obtención de los parámetros de performance que luego realiza este módulo. Esto tiene como objetivo reducir el número de consultas a cada nodo que, además de tiempo, consumen recursos de la propia red. Durante la iteración puede suceder que la topología virtual cambie, ya sea por una falla o por una modificación administrativa. Ante este escenario puede suceder que una consulta retorne información nula o diferente a lo esperado o que se reciba una notificación del protocolo SNMP indicando el cambio. Ante cualquiera de las dos situaciones el algoritmo es robusto y reinicia el descubrimiento de la topología virtual. Las notificaciones que son tenidas en cuenta por este módulo son las de túnel levantado, túnel caído y túnel reenrutado definidas en la MPLS-TE-MIB Obtención de asociaciones de FECs con LSPs Como se explicó en el capítulo 3, es importante para realizar Ingeniería de Tráfico conocer qué tráfico está siendo cursado por cada LSP. Esta información es imprescindible si se quiere reenrutar un túnel, ya que se le debe asociar al nuevo camino el mismo tráfico que cursaba el original. Además, como se explica a continuación, permite determinar entre qué LSPs se realiza balance de carga. La información de estas asociaciones está prevista por el estándar de gestión en la MPLS-FTN-MIB [8]. Lamentablemente, al momento ésta no es implementada por la mayoría de los fabricantes. De todas maneras, como se comentó en el capítulo 3, la generalidad del concepto de FEC permite obtener información de las asociaciones de tráfico a partir de otras fuentes. Por ejemplo se puede conocer, a través de la MIB-II, a qué interfaz virtual de MPLS está asociada una red de destino. Sin embargo, por la naturaleza de la tabla de rutas, si se realiza balance de carga sólo se presenta una interfaz en dicha tabla y la información recogida es incompleta.

80 60 Capítulo 6. Módulo Monitorización Figura 6.2: Algoritmo de descubrimiento de LSPs. En la implementación realizada se hace la hipótesis de que la FEC utilizada es simplemente la red de destino, y se obtiene la misma a través del archivo de configuración del nodo. De esta manera se puede interpretar correctamente qué túneles realizan balance de carga. Sería deseable poder manejar un concepto de FEC más general, como por ejemplo utilizando los puertos. De esta manera se podrían considerar situaciones más complejas como la separación de voz y datos en distintos túneles. Si bien se dejan

81 6.2. Solución implementada 61 de lado éstos y muchos casos interesantes desde el punto de vista de la Ingeniería de Tráfico, se optó por no realizar la interpretación de los filtros más específicos. Esto se debe a que los mismos son extremadamente difíciles de interpretar y a que no son orientados Ingeniería de Tráfico solamente, sino también a políticas de seguridad y administrativas. Por otro lado, toda esta información está contemplada en la MPLS-FTN-MIB y queda como trabajo a futuro su incorporación a la aplicación, cuando ésta esté disponible. El proceso implementado para obtener la FEC se basa en la hipótesis que las asociaciones de tráfico a los túneles se realizan mediante una ruta estática. Se interpreta entonces la configuración de los nodos, asociando para cada destino una FEC a los LSPs correspondientes. El hecho de que el aprovisionamiento de conectividad se realice dentro de la arquitectura RMA, permite manejar esta hipótesis sin que la misma conduzca a incoherencias Obtención de parámetros de performance Otro de los objetivos del módulo de monitorización es el de contar con parámetros representativos de la performance de la red. Existen parámetros locales que representan la performance individual de los componentes de la red (nodos y enlaces) y parámetros de extremo a extremo que representan la performance integral de todos los nodos y enlaces por los que pasa un LSP. Es deseable conocer el ancho de banda utilizado, la pérdida de paquetes y el uso de CPU como parámetros locales, y el retardo, el tráfico cursado o throughput, y la variación del retardo o jitter como parámetros de extremo a extremo. No está dentro del alcance de este módulo realizar las medidas, sino que se deben obtener a partir de consultas a otros agentes. La solución implementada tuvo como objetivo principal obtener parámetros representativos de la performance de la red que estuviesen disponibles vía consultas SNMP a MIBs estándar. En casos excepcionales se utilizaron otros métodos para obtener otros parámetros importantes pero no disponibles vía ese mecanismo, siempre priorizando el lograr una implementación funcional. Con respecto a los parámetros de extremo a extremo, el objetivo planteado por los clientes/tutores consistió en la definición de una interfaz para la interconexión con la herramienta Metronet y su posterior implementación. En ese sentido se decidió llevar a cabo el diseño e implementación de una MIB, que permitiera aprovechar el desarrollo en SNMP hecho para los demás módulos, y asumir que la implementación de la MIB estaría disponible. Se definió entonces la correspondiente MIB, estableciendo que mediante el protocolo SNMP se pudieran solicitar experimentos con determinadas características, para luego consultar los resultados de los mismos por la misma vía. Se incluyeron en

82 62 Capítulo 6. Módulo Monitorización ella los parámetros más relevantes y se comenzó a trabajar asumiendo que estaría disponible la implementación por parte de Metronet para el momento en que se precisara. El detalle de la MIB propuesta puede consultarse en el apéndice A.2. Por motivos ajenos a este proyecto no se pudo contar con dicha implementación, por lo que se buscaron otras alternativas que permitieran tener, por lo menos, una estimación de algún parámetro de extremo a extremo, como base para poder desarrollar algún algoritmo de TE y probarlo. Como se verá en las siguientes secciones, se decidió utilizar el comando MPLS PING, comentado en el capítulo 3 accediendo a los nodos vía el protocolo TELNET. A. Información recolectada A.1. Parámetros locales Se obtienen de la MIB-II los paquetes cursados y los descartados tanto entrantes como salientes por interfaz IP y de la MPLS-LSR-MIB los paquetes cursados por interfaz MPLS. Para poder luego calcular el ancho de banda a partir de los contadores de paquetes, de deben tener en cuenta los siguientes puntos: Pedir una marca de tiempo que refleje el momento en que se realizó la consulta Verificar la continuidad de los mismos, para evitar valores erróneos cuando se reinician Para el primer punto es necesario incluir, en la misma consulta en que se solicita el contador de paquetes, el valor que indica cuánto tiempo pasó desde la última vez que se reinició el nodo. Este valor se obtiene también por SNMP a través de un contador llamado SysUpTime. Es muy importante que ambos valores se pidan en el mismo momento, para poder calcular correctamente el ancho de banda. Para el segundo se debe considerar que cada cierto tiempo los contadores llegan a su valor máximo y son reiniciados por el enrutador. Si este hecho no es tenido en cuenta a la hora de calcular el ancho de banda, se tiene una discontinuidad. El enrutador guarda en la variable ifcounterdiscontinuitytime el valor de SysUpTime en que reinició los contadores por última vez. Para resolver esto, la aplicación desarrollada cuando detecta que se reiniciaron los contadores, borra el historial de medidas anteriores. Como consecuencia, cuando otro módulo toma los valores, siempre tiene valores correctos. Para detectar si se reiniciaron, se verifica que el valor ifcounter- DiscontinuityTime sea menor que el valor SysUpTime de la consulta anterior. Debido a que las velocidades de las interfaces llegan al orden de 1Gbps, se decidió utilizar contadores de 64bits. Usar contadores de 32bits hubiese significado que los mismos pudieran reiniciarse en tiempos menores a 1 minuto, aumentando la probabilidad de levantar medidas inválidas. Para el caso del uso de CPU de los nodos, por ser éste un parámetro fuertemente asociado al equipamiento utilizado, no se encuentra disponible en ninguna MIB estándar, por lo que se consideró razonable recurrir a la tabla de CPU Total de la Cisco Process MIB.

83 6.2. Solución implementada 63 A.2. Parámetros de extremo a extremo Como se comentó anteriormente, un supuesto de este proyecto era que los parámetros de extremo a extremo iban a estar disponibles vía SNMP. En el planteo del problema se manejó la interconexión con la herramienta Metronet, pero ésta no pudo ser llevada a cabo debido a que no se encontraba en actividad el grupo que desarrolla dicha aplicación. Esto derivó en que se debieran estudiar otras herramientas ya que los parámetros en cuestión son considerados de gran importancia. La primer herramienta que surgió de disponibilidad inmediata, por el hecho de contar con ella en los nodos, fue RTTMON. Se desarrolló una aplicación que agenda experimentos y consulta los resultados correspondientes por SNMP, obteniendo así el retardo, el jitter y la pérdida de paquetes entre dos nodos. Sin embargo, el camino por el que transitan estos experimentos no se puede asegurar ni determinar de manera sencilla por lo que se optó por tener en cuenta otras herramientas como el MPLS PING. Si bien el objetivo de MPLS PING es la verificación de conectividad y no el relevamiento de parámetros de extremo a extremo, se ajusta más al tipo de experimento con el cual se esperaba contar. Se buscaba que el LSP a relevar se pudiese especificar fácilmente y que no se debieran realizar grandes cambios en la red, por lo que se decidió tener en cuenta esta aplicación. Se debió realizar una actualización de versión de software en los nodos, debido a que la aplicación no estaba disponible en la versión que se encontraba en los equipos de la red. Una desventaja que tiene el uso de esta herramienta es que permite obtener valores de retardo de ida y vuelta en lugar de en un solo sentido. A pesar de que en la RFC 4379 [14] se propone un método para medir el retardo en un solo sentido, éste no está implementado por el fabricante CISCO. Es claro que el único retardo que tiene sentido en MPLS es el de una sola vía debido a la unidireccionalidad de sus caminos, por lo que en este proyecto se tuvo especial cuidado al utilizar esta medida como indicador del retardo de un LSP. En particular este indicador es utilizado por el módulo TE, por lo que en el capítulo 7 se profundiza sobre la validez del mismo. Para utilizar la herramienta MPLS-PING, se realizó una aplicación que se conecta por TELNET al CLI de un nodo y realiza dos medidas de PING inyectando tráficos de distinto ancho de banda en una lista de túneles especificada. Cada medida se repite 50 veces de manera de promediar las diferencias debido a fluctuaciones del tráfico. Esto si bien enlentece la aplicación, es necesario debido a que las limitaciones de la aplicación PING no permiten controlar la estadística de los paquetes de prueba. El Módulo Monitorización, para obtener el retardo, ejecuta un SCRIPT que se conecta a los nodos y retorna en una cadena de carácteres la salida del comando MPLS PING. Dicha cadena de carácteres es interpretada por una clase JAVA que se incluyó en el package RouterProxy junto a las demás funcionalidades dependientes del fabricante CISCO. De esta manera se logró aislar completamente las componentes dependientes del fabricante. Para realizar el SCRIPT se eligió el lenguaje interpretado EXPECT, que per-

84 64 Capítulo 6. Módulo Monitorización mite la ejecución de comandos en función de lo impreso en la salida estándar. Si bien se manejó la posibilidad de implementar una conexión TELNET en JAVA, se optó por utilizar EXPECT debido a que permitía un desarrollo más rápido. Vale la pena recordar que la aplicación desarrollada es una solución provisoria hasta que esté disponible un software de medición especializado como Metronet. La secuencia de comandos utilizada para hacer las medidas de un nodo se muestra en el código de ejemplo 1. Código de Ejemplo 1 SCRIPT para medir el retardo de los LSPs de un nodo spawn telnet [lindex $argv 0] set pass [lindex $argv 1] match_max expect "Password: " send -- "$pass\r" for {set x 3} {$x<$argc} {incr x} { expect ">" send -- "ping mpls tr tu [lindex $argv $x] size [lindex $argv 2] repeat 50\r" expect ">" send -- "ping mpls tr tu [lindex $argv $x] repeat 50\r" } expect ">" send -- "exit\r" expect eof El SCRIPT recibe como parámetros la IP del enrutador, la clave, el tamaño de los paquetes y los identificadores de todos los túneles de los que se quiere saber el retardo. En la salida estándar devuelve el resultado de los PING en crudo. El código de ejemplo 2 muestra la salida del SCRIPT cuando el identificador de LSP es 3007 y el tamaño de paquete es B. Pre- configuración La configuración es general al módulo de monitorización, y es descrita en la sección Dentro de los parámetros se destaca para este caso, la cantidad de veces que se relevan los parámetros de performance antes de descubrir nuevamente los LSP Túneles. Dado que los parámetros de performance están fuertemente vinculados a la topología virtual configurada en la red, la obtención de los mismos se realiza a continuación del algoritmo de descubrimiento de LSPs, una cierta cantidad de veces dada por ese parámetro. Para especificar dicho parámetro se debe tener precaución, ya que se deben cumplir dos condiciones a la vez: que la cantidad de medidas sea razonable para poder minimizar el efecto de las variaciones estadísticas, y que el período de una iteración completa del módulo de monitorización sea pequeño para que la TED refleje lo más rápido posible cualquier cambio en la red.

85 6.2. Solución implementada 65 Código de Ejemplo 2 Salida del SCRIPT para parámetros 3007 y pecord1>ping mpls tr tu 3007 size 1000 repeat 50 Sending 50, 1000-byte MPLS Echos to Tunnel3007, timeout is 2 seconds, send interval is 0 msec: Codes:! - success, Q - request not transmitted,. - timeout, U - unreachable, R - downstream router but not target, M - malformed request Type escape sequence to abort.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/12 ms pecord1>ping mpls tr tu 3007 repeat 50 Sending 50, 100-byte MPLS Echos to Tunnel3007, timeout is 2 seconds, send interval is 0 msec: Codes:! - success, Q - request not transmitted,. - timeout, U - unreachable, R - downstream router but not target, M - malformed request Type escape sequence to abort.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (50/50), round-trip min/avg/max = 2/3/6 ms Un procedimiento sugerido para determinar este parámetro consiste en: 1. Fijarlo en 1 y ejecutar la monitorización completa 2. Estudiar los períodos de ambos sub-módulos, el descubrimiento de LSPs y la obtención de parámetros. 3. Fijarlo tal que la iteración completa sea suficientemente rápida, según los requerimientos del algoritmo de TE. C. Algoritmo de obtención de parámetros de performance El algoritmo que obtiene los parámetros de desempeño utiliza la información de la topología física junto con la información de la topología virtual recogida durante el descubrimiento de LSPs para iniciar las consultas SNMP. Se realizan dos iteraciones independientes, una para los parámetros locales y otra para los parámetros de extremo a extremo. La primera realiza consultas de manera iterativa para todos nodos de la red, obteniendo de ellos los parámetros locales genéricos como el uso de CPU y los correspondientes a MPLS como los paquetes cursados por LSP. El diagrama de bloques del algoritmo implementado puede verse en la figura 6.3.

86 66 Capítulo 6. Módulo Monitorización Figura 6.3: Algoritmo de obtención de parámetros locales. La segunda realiza de manera iterativa experimentos que le permiten obtener los parámetros de extremo a extremo para todos los túneles de la red. El diagrama de bloques del algoritmo implementado puede verse en la figura 6.4. Todos los parámetros son almacenados con la marca de tiempo correspondiente para su posterior procesamiento por parte de los demás módulos Conclusiones En este capítulo se presentó la implementación del Módulo Monitorización. Se describieron en forma detallada los algoritmos de descubrimiento de la topología virtual y de obtención de los parámetros de performance, incluyendo las entradas y las salidas de cada uno. Además se explicó como se obtienen las asociaciones de FECs con LSPs y las fortalezas y debilidades de la solución implementada. En cuanto a información de la topología virtual se recoge toda la configuración de los LSPs, incluyendo el camino completo que atraviesan, el ancho de banda reservado en el plano de control y el coeficiente de reparto de carga, entre otras características. Contar con esta información es imprescindible a la hora de realizar Ingeniería de Tráfico en línea. A su vez es de gran utilidad para la gestión de una red, ya que

87 6.3. Conclusiones 67 Figura 6.4: Algoritmo de obtención de parámetros de extremo a extremo. permite entre otras cosas: Corroborar de manera centralizada que la configuración planificada se encuentra correctamente plasmada en la red. Verificar, luego de un cambio, que se señalizan correctamente los caminos y que no se generan inconvenientes en el resto de la red. Realizar un control en tiempo real de la conectividad en MPLS, ya que la herramienta descubre solamente túneles en funcionamiento. Llevar a cabo un control de cambios, mediante el almacenamiento periódico de la información recolectada. Para obtener las asociaciones de FECs con LSPs se adoptó una solución simplificada pero funcional. Queda como trabajo a futuro la incorporación de consultas a la MPLS-FTN-MIB, cuando esté implementada por los fabricantes, para contar con una especificación más rica de las FECs.

88 68 Capítulo 6. Módulo Monitorización Respecto a la obtención de parámetros de performance se obtuvieron parámetros tanto locales como de extremo a extremo. En cuanto a los parámetros de extremo a extremo, si bien se tiene una implementación que permite el funcionamiento completo de la herramienta y se recogen los parámetros imprescindibles para el algoritmo de TE, la misma es provisoria. En este caso se considera que no se está incurriendo en un incumplimiento ya que uno de los supuestos incluidos en el plan de proyecto (apéndice C) explicita que los parámetros de performance de la red de extremo a extremo estarían disponibles para consultar vía SNMP. Entre los parámetros locales se recogen los paquetes cursados que permiten calcular el tráfico servido por la red, prácticamente en tiempo real. No sólo se obtienen los de los LSPs, sino también los cursados por las interfaces físicas. Con estos datos se puede calcular el cross-traffic o tráfico de fondo. Esta información aporta valor no sólo para el control en tiempo real de la red sino también para la planificación de la misma, ya que cuenta con una granularidad importante que permite analizar el comportamiento del tráfico en cuanto a picos y variación estadística. El resto de los parámetros locales como el uso de CPU o los paquetes descartados también resulta muy útil a la hora de detectar situaciones en las que se pueda ver disminuida la performance de la red. El análisis del desempeño en cuanto a los tiempos insumidos en cada iteración del módulo se encuentra junto con el de los demás módulos en el capítulo 12. Comparando la solución implementada con las herramientas analizadas en el capítulo 3, encontramos por ejemplo que SEQUIN realiza el descubrimiento de la topología virtual consultando las mismas MIBs, obtiene parámetros de performance locales pero no recoge ningún parámetro de extremo a extremo. Por otro lado el módulo que monitoriza el estado de la red en RONDO es prácticamente igual al implementado, salvo porque realiza las medidas de extremo a extremo a través de RTTMON, la cual es una herramienta propietaria y su integración a la tecnología MPLS no es natural ni sencilla. Por último RATES implementa el descubrimiento de la topología por extensiones de OSPF. De esas mismas extensiones obtiene el ancho de banda disponible de las interfaces, mientras que no maneja otros parámetros de performance locales ni de extremo a extremo. Desde el punto de vista de la información recolectada y de la independencia del fabricante, la comparación con las demás herramientas permite concluir que la solución implementada está a la altura de las mismas, a la vez que logra integrar sus ventajas y evita las desventajas encontradas. Por lo mencionado anteriormente se considera que la implementación cumple satisfactoriamente los objetivos del módulo, recogiendo información que además de ser fundamental para la Ingeniería de Tráfico en línea, es muy útil para otras aplicaciones de gestión como la planificación, supervisión y control de redes MPLS.

89 Capítulo 7 Módulo TE En este capítulo se presenta el módulo Ingeniería de Tráfico, se repasan sus objetivos y se detalla la solución implementada Objetivos El módulo de TE tiene como objetivo detectar anomalías en el comportamiento de la red y solucionarlas. Para eso debe procesar la información del estado de la red que se encuentra en la TED y en caso de que sea necesario, tomar una acción correctiva. Vale la pena aclarar que el módulo de TE no es responsable del cómputo basado en restricciones de nuevos LSPs. Esta función en la arquitectura recae en el Módulo CBR El algoritmo MATE Para el desarrollo de este módulo se estudiaron distintos algoritmos de Ingeniería de Tráfico y se implementó uno llamado MATE: Multipath Adaptive Traffic Engineering. Cabe destacar que por el alcance del proyecto sólo fue implementado este algoritmo, pero toda la arquitectura del software fue pensada para que futuros proyectos puedan centrarse en el perfeccionamiento del Módulo TE. Como se vio en el capítulo 3, el algoritmo MATE permite, realizando balance de carga, minimizar el retardo total en una red MPLS. Este algoritmo supone que en la red hay establecidos varios LSPs entre las parejas de LERs origen y destino. También asume que el tráfico entre cada pareja es conocido y constante y que los LSPs son del tipo best-effort (sin reservas de ancho de banda). Como se ve en la figura 7.2, la idea es medir el retardo que sufre cada LSP periódicamente, estimar su derivada y, mediante modificaciones en el reparto de carga, minimizar el retardo total (u otra función de costo). La minimización se lleva a cabo aumentando el tráfico de los LSPs con menor derivada de retardo y 69

90 70 Capítulo 7. Módulo TE disminuyéndolo en los de mayor. Como se comenta en la sección que el mínimo del retardo total se da cuando las derivadas de los retardos de los LSPs son mínimas e iguales. Figura 7.1: Algoritmo de Ingeniería de Tráfico MATE. Fuente: [37] Formulación matemática Sea una red compuesta por un conjunto L de enlaces unidireccionales. La red es compartida por un conjunto S de parejas de LERs entrada-salida o ingresoegreso (IE). Cada pareja s S tiene disponibles P s LSPs. De esta definición se desprende que no se comparten LSPs entre parejas IE, aunque los distintos LSPs pueden compartir enlaces. Cada pareja s tiene una tasa de tráfico total de entrada r s y distribuye una fracción x sp del mismo en el LSP p de manera que se cumple: r s = p P s x sp, para todo s S (7.1) Sea x s = (x sp, p P s ) el vector de la tasa de tráfico de s, y sea x = (x sp, p P s, s S) el vector de todas las tasas de tráfico. La tasa de tráfico en un enlace l L es la suma de las tasas de todas las fuentes cuyos LSPs atraviesan el enlace l: x l = x sp (7.2) s S l L,p P s Se asocia a cada enlace l un costo C l (x l ) como función de la tasa x l que lo atraviesa. El objetivo es minimizar el costo total definido como C(x) = l C l(x l ) mediante la división óptima del tráfico r s en los LSPs:

91 7.2. El algoritmo MATE 71 min x C(x) = l C l (x l ) (7.3) sujeto a r s = p P s x sp, para todo s S (7.4) x sp 0, para todo p P s, s S (7.5) Se dice que un vector x es una solución factible si satisface las condiciones ( ). Se dice que una solución factible es óptima si es un mínimo del problema ( ). Se puede ver fácilmente en el capítulo 5 de [36] que la derivada parcial de la función de costo respecto a x sp es: C = x sp l p C l (xl ) (7.6) Se interpreta 7.6 como la derivada del costo de un LSP. Teorema 1 Un vector de tráficos x es óptimo si y solo si, para toda pareja s de IE, todos los LSPs p P s con tasa de tráfico positiva tienen la derivada del costo mínima (e igual). Este teorema es consecuencia del teorema de Kuhn-Tucker y una demostración se puede consultar en [36] El método de proyección del gradiente Una forma de resolver el problema ( ) es utilizando el método de proyección del gradiente. En este método el vector x se ajusta iterativamente en la dirección opuesta al gradiente de la función de costo. La descripción detallada de éste método también puede consultarse en [36]. La iteración es: x(t + 1) = [x(t) γ C(t)] + (7.7) donde: x(t) = (x sp (t), p P s, s S) ( ) C C(t) = (x(t)), p P s, s S x sp γ > 0 [z] + significa la proyección de z en la región factible. La condición de parada del algoritmo es cuando no hay un cambio apreciable entre dos iteraciones sucesivas: x(t + 1) x(t) < ǫ.

92 72 Capítulo 7. Módulo TE El algoritmo asíncrono Una de las principales ventajas del algoritmo MATE es que cada LER de entrada de las parejas IE puede correr el algoritmo en forma independiente, sin tener que coordinarse con los demás, siguiendo la siguiente iteración. x s (t + 1) = [x s (t) γ C s (t)] + (7.8) El teorema 2 muestra que este algoritmo converge a un ruteo óptimo si se cumple: C1- Las funciones de costo C l (z) son dos veces continuamente diferenciables y convexas. C2- Sus derivadas C l (z) son Lipschitz en cualquier conjunto acotado. C3- Para cualquier constante c los conjuntos z C l (z) c son acotados. C4- El intervalo de tiempo entre actualizaciones está acotado. Teorema 2 Bajo las condiciones (C1-C4), partiendo de cualquier condición inicial x(0), existe un γ suficientemente pequeño tal que cualquier punto de acumulación de la secuencia x(t) generado por el algoritmo asíncrono es óptima En [37] se presenta además una cota superior para γ en caso de que las funciones de costo sean uniforme y globalmente Lipschitz. Lo interesante del resultado es que a medida que crece el grado de asincronismo en la red, γ debe ser más pequeño para asegurar la convergencia La versión para tráfico no constante y la elección de γ adaptativo Como se vio anteriormente, el algoritmo supone que la tasa de entrada r s es dada para cada pareja s de IE. Esta hipótesis es muy limitante no sólo porque agrega una restricción en cuanto a cuándo se puede aplicar el algoritmo, sino también porque implica estimar r s. En [38] y en [36] se propone modificar ligeramente la iteración de MATE para que sea independiente de la tasa de entrada r s : ψ s (t + 1) = siendo ψ s (t) = x s(t) r s (t) [ ψ s (t) γ ] + r s (t) C s(t) (7.9) Además en [38] se propone una forma de tener γ adaptativo, que por un lado evita oscilaciones cuando la iteración se acerca al punto óptimo y por otro evita comportamientos indeseados si la tasa de un enlace se aproxima a su capacidad.

93 7.2. El algoritmo MATE 73 Cabe aclarar que en el mencionado trabajo se presenta el problema con la simplificación de que el retardo de los enlaces es igual al de una cadena de Markov M/M/1. Además se calcula el retardo de un LSP como la suma de los retardos de todos los enlaces. Esta hipótesis simplificadora es discutible en muchos casos como se puede ver en [36] ya que por más que los flujos a la entrada de la red tengan características de Poisson, esta propiedad se pierde luego del primer enlace. De todas maneras en la práctica muchas veces se toma que el resultado de la cadena M/M/1 se aplica para cualquier enlace cuando se está en régimen de muchos flujos y es conocida como Hipótesis de Independencia de Kleinrock. Debido a que esta hipótesis no siempre es válida, y el resultado presentado en [38] es fácilmente adaptable al caso en que la función de retardo sea cualquiera, se presentan los principales resultados de ese trabajo levemente modificados para el caso general. Se redefine la iteración 7.8 como: ψ s (t + 1) = [ ψ s (t) siendo f(z) = Z + m 0,1 Z min ρ f( p P s C 1 m(1 + mz) x sp ) C s(t) ] + (7.10) Se puede ver que con esta modificación cuando el algoritmo se acerca al mínimo de las derivadas, el paso entre iteraciones se reduce evitando oscilaciones. Para esto se elige el valor de m para que cerca del punto óptimo las variaciones del retardo con respecto a la carga sean del orden de ρ. Por otro lado si el tráfico por un 10 enlace se acerca a su capacidad produciendo una derivada muy grande, el paso entre iteraciones se mantiene acotado por ρ Cálculo de la proyección Como se vio anteriormente en todas las iteraciones del algoritmo MATE es necesario proyectar el resultado al espacio de soluciones factibles ( ). En [37] no se explicita cómo realizar dicha proyección, por lo que se adoptó una solución propuesta en [36]. La misma consiste en calcular para cada paso el LSP con derivada menor (p min ) y excluirlo de la iteración. Como consecuencia se realiza una iteración modificada con todos los demás LSPs y se define finalmente ψ spmin de manera que se cumplan ( ).

94 74 Capítulo 7. Módulo TE La iteración modificada queda: ψ sp (t + 1) = ψ sp (t) ρ ( C ) C x sp x sp C x spmin ) para todo p p min ( f p P s (7.11) ( ) ψ sp (t + 1) = max 0, ψ sp (t + 1) para todo p p min (7.12) ψ spmin (t + 1) = 1 ψ sp (t + 1) (7.13) p P s,p p min 7.3. Solución implementada Para el diseño del software se realizó un estudio de requerimientos. Se estableció que la solución debía ser totalmente automatizada, que no requiriera la intervención del operador. Como consecuencia se debió implementar tanto la detección de congestión como la aplicación del algoritmo. La solución implementada consta de dos bloques: detección y acción. El módulo de detección es el que permite, a partir de los datos de estado de la red, determinar si se debe correr el algoritmo de optimización. Por otro lado el bloque de acción consiste en una implementación del algoritmo MATE presentado anteriormente. Este módulo, así como los demás implementados, fue desarrollado en lenguaje JAVA. El desarrollo modular orientado a objetos permitió reutilizar la implementación de los elementos comunes a todos los módulos, como por ejemplo el manejo del protocolo GRMAP, acceso a la base de datos y manejo de XML descrito en el capítulo 9. La aplicación permite correr simultáneamente el algoritmo de optimización para varios grupos de LSPs gracias a su implementación en hilos (threads). Como se demostró en 7.2.3, la gran ventaja de este algoritmo es que cada hilo puede actuar de manera independiente llegando al óptimo global El bloque detección Para saber cuándo se debe aplicar el algoritmo de Ingeniería de Tráfico es necesario detectar de alguna manera cuándo hay congestión en la red. Si bien se podrían haber utilizado muchos de los parámetros relevados por la herramienta de monitorización como indicadores de congestión, se adoptó utilizar la derivada del retardo de los LSPs respecto a su carga. La decisión se basó en que es deseable que la medida de congestión esté vinculada a la función de costo que optimiza el algoritmo. Por ejemplo si se cuenta con un algoritmo que busca minimizar la utilización de ciertos enlaces y se usa como medida de detección de congestión que el retardo de un LSP supere cierto valor, se pueden obtener resultados indeseados.

95 7.3. Solución implementada 75 El proceso de detección de congestión se muestra en la figura 7.2. La aplicación detección continuamente pide información a la base de datos, separa los LSPs en grupos según su origen, destino y FEC, y luego analiza cada grupo. Figura 7.2: Proceso de detección de congestión. El proceso de considerar un grupo como desbalanceado es un proceso con memoria. Es decir que sólo si un grupo presenta cierta patología en análisis consecutivos se considerara que hay una situación que requiere ser corregida. La razón para no actuar inmediatamente cuando se detecta un desbalance en el grupo es que éste puede ser debido a un error de medida y no sería conveniente correr el algoritmo en este caso. En la figura 7.3 se puede observar el diagrama de estados correspondiente al Módulo TE. Concretamente, lo que se hace es, para cada grupo calcular la derivada del retardo de cada LSP respecto a la carga y comparar las derivadas de los LSPs del grupo. Si la diferencia entre la derivada máxima y mínima de un grupo (delta en el diagrama de

96 76 Capítulo 7. Módulo TE Figura 7.3: Diagrama de estados. Módulo TE. estados) supera cierto umbral (alfa en el diagrama), se marca el grupo de LSPs como desbalanceado. Si se detecta que un grupo está desbalanceado en un determinado número (dos veces en el diagrama) de relevamientos de la red se pone a correr el algoritmo MATE y se marca el grupo indicando que está siendo optimizado para no analizar su congestión hasta que finalice el algoritmo según la condición de parada del mismo (beta<epsilon en el diagrama). Cabe destacar que el algoritmo MATE corre en un hilo aparte del de la detección. Esto permite que la detección sea continua y que puedan correr muchas instancias de MATE simultáneamente. Por otro lado, requiere más inteligencia por parte del módulo de detección, ya que debe mantener el estado de si un grupo está en proceso de corrección o no. Los detalles de la implementación en software pueden consultarse en el capítulo El bloque acción El bloque acción es el que implementa los mecanismos correctivos ante situaciones de congestión. En este proyecto dicho módulo consiste en la implementación del ya presentado algoritmo MATE. A continuación se explica con un grado más de detalle la implementación del mismo. Para la implementación del algoritmo en software se utilizó la iteración ( ). Para estimar las derivadas se utilizan dos experimentos de medida de retardo inyectando distinto tráfico y se calcula la estimación como el cociente incremental. Cabe aclarar que esta estimación de la derivada parcial solamente es válida si los LSPs p P s no comparten enlaces. La razón es que para tener en realidad la derivada parcial habría que tener en cuenta también como influye en el retardo de un LSP p j la variación de tráfico en otro LSP p i. Obviamente si no comparten

97 7.3. Solución implementada 77 enlaces esta variación es 0. Actualmente no es posible calcular la derivada parcial correctamente debido a limitaciones en la herramienta de medidas. De todas formas la implementación de estas medidas sería muy complicada aun con una herramienta más sofisticada, por lo que no es de esperar que en un futuro se disponga de esta información. Por lo tanto será un supuesto del problema que, o bien los LSPs a los que se aplica el algoritmo no comparten enlaces, o los enlaces que comparten tienen poca influencia en la derivada del retardo. A. Simulación Antes de la integración del algoritmo a este módulo se simuló en el software de cómputo OCTAVE, obteniendo resultados acertados de acuerdo a la teoría de colas. Esta simulación primaria permitió familiarizarse con los detalles delicados de la implementación, corrigiendo errores y despejando dudas. Se simularon redes con topologías como las de las figuras 7.4(a) y 7.4(b), agregando un error aleatorio en el retardo teórico para tener un escenario más realista. (a) Topología 1 (b) Topología 2 Figura 7.4: Topologías para la simulación. En las figura 7.5 se pueden ver los resultados de las simulaciones para cada una de las topologías. B. Implementación final Luego de que se verificó la correcta implementación de distintos aspectos mediante las simulaciones, se procedió a implementar el bloque acción en el lenguaje de programación JAVA. Como se comentó anteriormente, la actuación de este bloque es disparada por el módulo detección, el que pasa como parámetros de entrada los identificadores de los enrutadores origen y destino, junto con la FEC del grupo. El ciclo básico consiste en pedir la red a la base de datos solicitando información sobre topología física, topología virtual y estadísticas. Con esta información se calculan las derivadas del retardo con respecto a la carga de cada LSP perteneciente al grupo en cuestión. El cálculo de las derivadas se realiza con la información de los distintos experimentos que involucran distinta carga en cada uno, obtenida de las

98 78 Capítulo 7. Módulo TE 0.65 Simulacion MATE trafico para topologia 1 LSP1 12Mbps LSP2 9Mbps 0.6 % Balance de carga n iteracion (a) MATE Simulacion MATE trafico para topologia 2 LSP1 12Mbps LSP2 9Mbps LSP3 7Mbps 0.45 % Balance de carga n iteracion (b) MATE 2 Figura 7.5: Resultados de la simulación. estadísticas pedidas a la base de datos. De esta manera se obtiene el gradiente con respecto a una variación de carga en cada LSP. Luego se calcula con la iteración ( ) el nuevo valor de coeficiente de reparto de carga para cada LSP del grupo, obteniendo un vector de coeficientes de reparto de carga. Se calcula la norma infinito de ese vector menos el vector correspondiente a la iteración anterior, y el resultado obtenido es comparado con la condición de parada. Si la mejora obtenida no supera dicha condición, la iteración culmina. En otro caso se interacciona con el Módulo Señalización para que éste configure en la red los nuevos valores de coeficiente de reparto de carga.

99 7.3. Solución implementada 79 Cumplido esto, se espera a tener una actualización de la base de datos, se verifica que efectivamente se hayan configurado los coeficientes de reparto de carga enviados a señalizar y se comienza el ciclo nuevamente. En el código de ejemplo 3 se puede ver la secuencia explicada anteriormente de manera más esquemática. Código de Ejemplo 3 Pseudocódigo de la implementación del algoritmo MATE. inicio mate (origen, destino, FEC) red=ted.obtenerred() mientras condicion < umbral LSPs=red.obtenerLSPs(origen, destino, FEC) para i =1 hasta i=#lsps loadshare_anterior[i]=loadshare del LSP i obtener dos valores de experimentos de retardo derivadas[i]=calcular la derivada del retardo respecto a la carga i=i+1 fin para gamma=calculargamma(suma(derivadas)) [dmin, indicedmin]=minimo(derivadas) para i = 1 hasta i=#lsps loadshare_actual[i]=loadshare_anterior[i]-gamma*(derivada[i]-dmin) i=i+1 fin para loadshare_actual = proyectar(loadshare_actual,indicedmin) condicion =norma(loadshare_anterior - loadshare_actual) loadshare_anterior=loadshare_actual Se~nalizar.modificar(LSPs,loadshare_actual) si no condicion mientras no actualizados // en este bucle se espera una red red=ted.obtenerred() // con los LSPs se~nalizados. actualizados =comparar(loadshare_actual,red) fin mientras fin si fin mientras fin mate A la hora de realizar la implementación, que luego iba a ser probada en los equipos disponibles detallados en el apéndice B, se tuvieron en cuenta las restricciones que los mismos imponen sobre el reparto de carga. Tras interiorizarse en los pormenores de la implementación del fabricante CISCO se detectaron los siguientes aspectos a tener en cuenta: Granularidad del coeficiente de reparto de carga Tiempo de actualización de la configuración de reparto de carga

100 80 Capítulo 7. Módulo TE Granularidad del coeficiente de reparto de carga El fabricante implementa el balance de carga como 16 compartimentos a repartir entre todos los caminos que comparten igual destino. Por lo tanto la mínima variación en los coeficientes de reparto de carga es de 1/16. La granularidad del coeficiente de reparto de carga se traduce en que no tiene sentido poner una condición de parada menor a la mínima variación implementable por el equipo. En la implementación del algoritmo que se hizo en este proyecto la condición de parada se fijó teniendo en cuenta esto, por lo que se debe decir que la misma tiene un grado de dependencia con el fabricante. Tiempo de actualización Además, la reasignación de cantidad de compartimentos a cada camino se refresca cada 30 segundos. En cuanto al tiempo de actualización, se asume que el tiempo insumido en el proceso de monitorización superará ese valor de actualización. Este aspecto es delicado, pero se hace difícil brindar una solución mejor ya que el fabricante no ofrece mecanismos estándar de gestión que permitan verificar como se está realizando el reparto de carga en el plano de datos en un momento dado. Se tuvo en cuenta la alternativa propietaria de interpretar la salida de un comando disponible a través de la CLI utilizando un método como el explicado en el capítulo 2 sección A. Se decidió que esto no era apropiado ya que es una solución muy dependiente del fabricante, incluso puede ser difícil adaptarla a otros casos ya que puede no existir el comando análogo. Se supone que el tiempo requerido para que se refleje en el plano de datos lo configurado se alcanzará entre corrida y corrida del Módulo Monitorización Conclusiones En este capítulo se presentó la implementación del Módulo TE. Se analizó el algoritmo MATE y sus distintas variantes y se optó por una implementación que es una combinación de ellas. Se discutieron los supuestos que tiene el algoritmo así como las limitaciones de la implementación realizada. Además se explicó cómo se detecta congestión y cuándo se corre el algoritmo. Se implementó el algoritmo y se pudo integrar satisfactoriamente a la arquitectura. Gracias a esto se pudo probar el funcionamiento completo de la aplicación en una red real. La modularidad de la aplicación permitió que la integración del algoritmo fuera muy sencilla, lo cual evidencia las ventajas de adoptar una arquitectura con dicha característica. Como consecuencia se presume que la integración futura de más algoritmos se podrá hacer de manera muy natural. Si bien el algoritmo implementado es limitado y relativamente sencillo, el objetivo del proyecto no era implementar un algoritmo complejo sino una arquitectura completa de Ingeniería de Tráfico. Por esta razón es que por ejemplo el módulo

101 7.4. Conclusiones 81 de monitorización fue pensado para obtener la mayor cantidad de información de performance posible sin tener en cuenta lo que precisaría un algoritmo determinado. Es importante a destacar que la implementación del algoritmo, así como del mecanismo de detección permitieron realizar todo el ciclo de Ingeniería de Tráfico. Esto comprende el descubrimiento de la topología de la red, la monitorización de su estado, la detección de una situación de congestión y su corrección. En la parte III se pueden ver análisis de los tiempos obtenidos en las pruebas realizadas.

102

103 Capítulo 8 Módulo Señalización En este capítulo se describe el módulo de señalización. Se explican sus funciones y aspectos de su implementación Objetivos El objetivo del módulo de señalización es realizar cambios en la configuración de los LSPs de la red. Debe ser capaz de dar de alta, de baja, asociar tráfico a los LSPs y cambiar parámetros de los mismos Solución Implementada Como se mostró en la parte I, las opciones estudiadas para señalizar en redes MPLS fueron SNMP y configuración manual de los nodos. En principio la mejor solución sería utilizar SNMP debido a que permite la interoperabilidad entre distintos fabricantes, pero esta opción no es posible de implementar actualmente porque la mayoría de ellos no permite escribir en las MIBs de MPLS. La solución planteada consiste en utilizar un Element Manager, o manejador de elementos, que se encarga de la configuración de los nodos, con los comandos propietarios, y se comunica con la arquitectura a través del protocolo GRMAP. La implementación de dicho manejador de elementos está basada en la herramienta IPEMSCOMM, creada por el grupo MINA [44] del INCO. La aplicación posee un servidor que atiende conexiones del protocolo GRMAP en un puerto determinado por configuración. A través de dicho protocolo se pude establecer la comunicación con el módulo y se utiliza el protocolo XML para solicitar el alta de un nuevo LSP o la baja o cambio de parámetros de uno existente. Cada conexión es atendida en un hilo distinto, lo que permite que la aplicación soporte muchas conexiones simultáneamente. Para lograr sus distintos objetivos este módulo necesita modificar la configuración de los nodos. Para esto, le indica al nodo en cuestión por SNMP que guarde su 83

104 84 Capítulo 8. Módulo Señalización configuración en un servidor TFTP. Luego modifica dicha configuración y le indica al nodo, nuevamente por SNMP, que levante la configuración del servidor. En lo que resta de este capítulo cuando se mencione que se modifica la configuración de un nodo se estará refiriendo a este mecanismo. Se decidió realizar algunos cambios a la herramienta IPEMSCOMM para que se ajustara mejor a los requerimientos del proyecto. Si bien se podría haber implementado una nueva herramienta, se decidió modificar la existente ya que gran parte era aprovechable y permitía ahorrar mucho tiempo en implementación. El principal cambio realizado fue la posibilidad de modificar la configuración de LSPs existentes. Éste era un requerimiento fundamental del proyecto, ya que por ejemplo se necesita variar los coeficientes de balance de carga o el ancho de banda reservado. Otro cambio realizado consiste en solamente enviar en el archivo de configuración la información que cambia. La herramienta original cambiaba del archivo de configuración sólo las líneas necesarias y luego reemplazaba la configuración del nodo por la modificada. Esto traía el problema de que el nodo interpretaba que se estaban señalizando nuevamente los túneles y refrescaba las MIBs, confundiendo a la herramienta de monitorización. No se ha podido verificar si esto además producía interrupción en el tráfico. Los cambios en la herramienta permiten que sólo se carguen en el nodo los comandos con la información que se cambia o se agrega, ya que el nodo después se encarga de incorporarla a la existente. La herramienta original utilizaba para la comunicación con los otros módulos de la arquitectura (módulo TE e interfaz de gestión) una plantilla XML definida especialmente para el pedido de señalización de un LSP. La misma soporta tres tipos distintos de pedidos: dar de alta, dar de baja y modificar un camino. El detalle de uno de los pedidos puede verse en la figura 8.1. Los cambios introducidos en la herramienta base, mencionados anteriormente en este capítulo, estuvieron acompañados de agregados en la plantilla XML necesarios para poder comunicar el cambio de atributos y las asociaciones de tráfico. Puede verse que el nombre de la jerarquía máxima de la plantilla XML es path- Response, respuesta de camino en español. Esto es así debido a que se pensó para que en un futuro se pudiese incorporar la solución de señalización implementada por el grupo RMA Control y se continuara usando la misma plantilla entre este módulo de señalización y un enrutador. En este contexto puede verse que el nombre adquiere significado ya que se utilizaría la plantilla para la respuesta al enrutador cuando este último solicita un pedido de cómputo de camino. Se recuerda que al momento no es posible realizar la interconexión ya que la solución propuesta por el mencionado grupo consiste en una implementación del PCEP, y como fue mencionado en la sección 3.4 éste no prevé un cambio originado desde el PCE. Cabe aclarar que la señalización funciona en bucle abierto, ya que este módulo no verifica que el LSP se señalice con éxito. Si bien podría pensarse en principio que esto es una desventaja, la razón de este comportamiento está en la separación de funciones

105 8.2. Solución Implementada 85 Figura 8.1: XML PathResponse. Alta de caminos. entre los módulos del RMA. No es deseable que el módulo de señalización descubra el LSP señalizado, ya que ésta es una función del módulo de monitorización. Por lo tanto la arquitectura en su totalidad tiene realimentación a través del funcionamiento conjunto de sus módulos Configuración y baja de LSPs Como ya fue explicado en la parte I, los LSPs que interesan a la hora de realizar Ingeniería de Tráfico son los túneles, por permitir realizar ruteo explícito. En la solución implementada se asume que el protocolo para señalizar túneles que implementan los LERs es RSVP-TE, debido a que es el más común en la industria y el implementado por los nodos de la maqueta. De todas formas el soporte del protocolo CR-LDP involucraría solamente modificaciones en el Element Manager. La herramienta permite configurar y dar de baja un túnel modificando la configuración del LER de entrada, el cual desencadena el proceso de señalización. En la figura 8.2 se puede ver el flujo de mensajes que se intercambian en el alta de un LSP. Los parámetros que soporta actualmente para señalizar túneles son: Ancho de banda: Es el ancho de banda reservado en el plano de control. Es utilizado por los enrutadores para controlar que no se reserve más ancho de

106 86 Capítulo 8. Módulo Señalización Figura 8.2: Flujo de mensajes en la configuración de un LSP. banda del disponible, pero no se controla que el tráfico que cursa el túnel respete este valor. Prioridad de preempción: Indica distintas prioridades para los túneles. Si se quiere señalizar un túnel y no hay capacidad, el enrutador da de baja a los túneles de menor prioridad para poder señalizar uno de mayor prioridad. Balance de carga: Es un coeficiente que indica en qué proporción el LER de entrada debe hacer balance de carga para un conjunto de túneles de la misma FEC. Cabe aclarar que el coeficiente se fija en forma independiente y es el LER de entrada quién calcula las proporciones. Para un grupo L de túneles que realizan balance de carga, si llamamos b i al coeficiente de reparto de carga b del túnel i, la porción de tráfico que se le asigna es i P j L b j. Ruta explícita o dinámica: Una ruta explícita es la que especifica todos los saltos del LSP, mientras que una dinámica es la que especifica solamente el nodo de ingreso y egreso, siendo el LER de entrada quien calcula los saltos. Mapeo de tráfico: Permite asociar una o varias FECs al túnel a señalizar. La FEC soportada al momento consiste en indicar una red de destino, es decir una dirección IP y una máscara Modificación de LSPs establecidos La funcionalidad de modificar características de los LSPs ya establecidos fue una incorporación hecha por el presente proyecto a la herramienta base. Actualmente se soporta el cambio de los siguientes parámetros: Ancho de banda Prioridad de preempción

107 8.3. Conclusiones 87 Coeficiente de balance de carga Mapeo de tráfico: Permite asociar una o varias FECs a un túnel o eliminar asociaciones existentes Asociación de tráfico a los LSPs Un requerimiento importante que tenía el presente proyecto era el de lograr resolver el mapeo de tráfico en los túneles. Como se comentó en la sección 3.4 las opciones para configurar dichas FECs son limitadas. Es por ello que para este objetivo también se debió recurrir a la opción de modificar el archivo de configuración de los equipos. Para poder realizar el mapeo de tráfico a túneles se agregó a la plantilla XML utilizada por este módulo información sobre FECs. La misma está incluida en el pedido de alta de caminos y en el pedido de cambio de atributos, pudiendo en este último caso indicarse que se agregue o elimine una FEC a un LSP. En ambos casos se utiliza un mismo tipo definido para estos fines, el que se puede ver en la figura 9.4. Este tipo coincide con el definido en el modelo de información explicado en el capítulo 9. En la sección se comentó la manera de configurar la FEC en los nodos, advirtiéndose que los equipos en general no manejan el concepto de FEC y que si bien es posible realizar una configuración que contemple las distintas variables que incluye una FEC mediante filtros, estos son complicados. Es por ello que se decidió que la solución implementada soportara únicamente la configuración de FECs definidas como red de destino. Igualmente en la plantilla XML utilizada se incluyó el concepto amplio de FEC, de manera de prever su futura utilización, por ejemplo cuando los equipos soporten la MPLS-FTN-MIB. Además de configurarse las FECs indicadas específicamente en el XML enviado en el pedido de señalización o en el pedido de cambio de atributos, este módulo configura en el nodo ingreso una ruta estática al destino del túnel. Este mapeo de tráfico se realiza previendo que el administrador desee configurar en los equipos alguna opción de inclusión de los túneles MPLS en el cálculo de rutas de IGP. Por ejemplo, la opción autoroute de los equipos CISCO, cuyo detalle de funcionamiento puede verse en [18] Conclusiones Se presentó la implementación del módulo de señalización. La misma consistió en la adaptación de una herramienta ya existente que permite dar de alta y de baja túneles, además de realizar cambios en la configuración y asociar tráfico a los mismos. La solución lograda funciona actualmente como un Element Manager que implementa los comandos propietarios correspondientes a los túneles de Ingeniería de Tráfico. Si bien la herramienta actual es dependiente del fabricante CISCO, se pue-

108 88 Capítulo 8. Módulo Señalización de mantener la misma arquitectura para otros fabricantes debiendo desarrollar un manejador para cada uno. Esto está previsto en el modelo de información descrito en el capítulo 9, mediante la inclusión del campo Element Manager en el que se puede especificar uno para cada nodo. Si se permitiera en un futuro la escritura de las MIBs de MPLS por parte de los fabricantes, sería deseable desarrollar una aplicación que funcionara por SNMP. Sobresale como aporte importante el hecho de haber incluido en el Módulo Señalización la responsabilidad de realizar el mapeo de tráfico, tarea que no estaba explícitamente asignada a ningún módulo en la arquitectura tomada como base. Además de asignarse dicha responsabilidad al módulo, se implementó y probó una solución que maneja una noción de FEC simplificada, dadas las limitaciones mencionadas. No obstante, también está previsto en el modelo de información propuesto el manejo de FECs complejas que involucren varios parámetros. Contar con la implementación de este módulo perfectamente adaptado a la herramienta se considera un gran aporte, ya que no sólo es fundamental para realizar Ingeniería de Tráfico, sino que también es de gran utilidad para la gestión de una red MPLS. Con esto se logra además, cumplir uno de los trabajos a futuro planteados por el proyecto Net-TE: integrar a la herramienta gráfica la señalización de los caminos que resultan de la actuación de los algoritmos de Ingeniería de Tráfico fuera de línea. El el capítulo 12 se presentan las pruebas realizadas en la maqueta para la validación de este módulo.

109 Capítulo 9 Almacenamiento e Intercambio de Información En este capítulo se presenta la solución implementada para el almacenamiento de la información en la arquitectura y el intercambio de la misma entre los distintos módulos que la componen Introducción Debido a la arquitectura modular de la aplicación surge la necesidad de transmitir información entre los distintos módulos. Además es necesario que dicha información persista de manera que pueda ser consultada posteriormente. La solución presentada en la arquitectura RMA es tener una base de datos centralizada y utilizar el protocolo GRMAP, propio de dicha arquitectura, para la comunicación entre los módulos. Sin embargo, no se especifica qué información almacenar ni de qué manera, por lo que se debió adoptar un modelo de información para representar la red. En las siguientes secciones se presentan: Modelo de información Base de datos Protocolo GRMAP 9.2. Modelo de información Para representar la información de la red se estudió la posibilidad de crear un modelo propio o adoptar el de algún proyecto. La creación de un modelo propio permitía una mayor flexibilidad, sin embargo, tenía la desventaja de ser una tarea complicada y en la que no se tenía experiencia. 89

110 90 Capítulo 9. Almacenamiento e Intercambio de Información Se decidió elaborar un conjunto de requerimientos para el modelo con la información básica requerida por cada módulo. Además se estableció que el modelo debía ser flexible para permitir agregar más información en caso de ser necesario. Luego de estudiar distintos proyectos se llegó a la conclusión que el modelo utilizado por TOTEM [32] contenía gran parte de la información que se quería almacenar. La solución adoptada fue utilizar como base el modelo TOTEM, agregando la información que éste no contemplaba. La elección y definición del modelo de información fue realizada en conjunto con el grupo RMA Control [41]. En el modelo implementado, la información se almacena en formato XML que presenta numerosas ventajas, entre ellas su carácter jerárquico que lo hace muy flexible, y su gran popularidad que hace que haya muchas herramientas para manejarlo Solución implementada Para definir el modelo se utilizó un esquema (XML SCHEMA) que permite, además de documentar la especificación del formato, validar información de acuerdo a dicha especificación. El modelo describe un dominio, caracterizado por un nombre y un identificador, y consta principalmente de las siguientes secciones: info topology mpls statistics La estructura general del modelo se puede ver en la figura 9.1. Figura 9.1: Modelo de Información. Dominio.

111 9.2. Modelo de información 91 La sección info contiene información general de la red como el título, fecha, descripción y unidades utilizadas en las otras secciones. La sección topology contiene la descripción de la topología física de la red compuesta por nodos (nodes) y enlaces (links). Cada nodo tiene asociados una serie de parámetros generales como nombre, RouterId, descripción y tipo (LER o LSR), y un conjunto de interfaces. A su vez, cada interfaz contiene datos como velocidad, dirección IP y máscara. Por otro lado los enlaces (links) están caracterizados por nodo e interfaz de origen y destino y el modo de funcionamiento (full-duplex o halfduplex). Además contienen otros parámetros como ancho de banda y retardo entre otros. Por otro lado la sección mpls contiene la información de dicho protocolo. Consta de un conjunto de LSPs caracterizados por su identificador LSPID. A su vez cada LSP contiene un camino (path) que es un conjunto ordenado de enlaces (links). Otros parámetros de los LSPs son los parámetros de la reserva de recursos como el ancho de banda, el flujo máximo (max-rate) y atributos de Diffserv. También incluye una secuencia de identificadores de FECs correspondientes a las asociadas al túnel. Estos identificadores refieren a las FECs definidas en otra sección del SCHEMA denominada traffic maps, cuyo detalle puede verse en la figura 9.4.

112 92 Capítulo 9. Almacenamiento e Intercambio de Información Figura 9.2: Modelo de Información. Topología.

113 9.2. Modelo de información 93 Figura 9.3: Modelo de Información. MPLS.

114 94 Capítulo 9. Almacenamiento e Intercambio de Información Figura 9.4: Modelo de Información. Tipo definido para modelar FECs. Por último la sección de statistics contiene la información acerca de estadísticas de performance de la red. Las estadísticas están divididas en locales (local-atributes) y de caminos (path-atributes). Las de caminos contienen la información del camino y medidas de delay, jitter y throughput. Las locales contienen información de los nodos y enlaces como por ejemplo uso de CPU, paquetes descartados y paquetes transmitidos.

115 9.2. Modelo de información 95 Figura 9.5: Modelo de Información. Statistics.

116 96 Capítulo 9. Almacenamiento e Intercambio de Información En el caso de la sección statistics, ésta fue desarrollada por completo por este grupo de proyecto ya que el modelo utilizado como base no contaba con información de este tipo. El resto de los módulos mencionados antes en esta sección surgieron como modificación al modelo base. Vale la pena mencionar además que todos los elementos del modelo de información están indexados para facilitar el pasaje a un modelo de base de datos Módulo DB El módulo DB es una base de datos cuya función es almacenar toda la información de la red para que pueda ser accedida por los distintos módulos. Para eso debe, no sólo tener un motor de base de datos, sino también implementar el protocolo de comunicación de la arquitectura y el modelo de información. Una vez definido el modelo de información quedó totalmente especificado el diseño de la base de datos. Como se mencionó en el capítulo 4 la implementación de la base de datos quedó en manos del grupo RMA Control. Debido a que no fue implementada a tiempo para las pruebas, se optó por desarrollar un software que simulara la base de datos y sus interfaces. Un concepto importante para tener en cuenta es que la interfaz de la base de datos tiene distintos clientes (los módulos) con distintos requerimientos. Algunos módulos pueden hacer una consulta esporádica de toda la información de la red mientras que otros pueden requerir frecuentemente información de cambios ocurridos. Esto se debe a que transmitir toda la información de la red puede ser una operación muy costosa en redes grandes y no es factible para los módulos que tienen que tener la información en tiempo real. Como se verá más adelante en la descripción del protocolo GRMAP, la DB puede identificar a los clientes según el puerto al que le hacen las consultas y mantener un registro de qué informó a cada uno, para poder luego informar la diferencia Solución implementada Como se especificó anteriormente la implementación de la base de datos no era responsabilidad de este proyecto, pero debido a su importancia en la arquitectura fue necesario desarrollar una solución provisoria hasta que esté lista la implementación definitiva. Se optó por desarrollar una aplicación en lenguaje JAVA que acepta conexiones en el puerto definido por el protocolo GRMAP. Esta aplicación soporta todos los mensajes del protocolo GRMAP, pero en vez de realizar consultas en una base de datos relacional mantiene la información en memoria. La implementación fue muy sencilla ya que el protocolo había sido implementado para los demás módulos y debido a la buena ingeniería de software se puedo reutilizar completamente. La aplicación desarrollada permite manejar múltiples conexiones simultáneas debido a que cada conexión se atiende en un hilo aparte.

117 9.4. Protocolo GRMAP 97 Las diferencias principales con la solución definitiva, en cuanto a funcionalidad, surgen de la manera de manejar la opción difference o diferencia. Esta opción refiere a solicitar por parte de cada módulo únicamente la información que cambió con respecto a la última vez que consultó. Esta funcionalidad hace que se presenten dos diferencias, a saber: Manejo del estado de cada cliente Manejo de las diferencias enviadas a la base de datos Manejo del Estado de Cada cliente En la solución definitiva se utilizarán puertos distintos para identificar a los distintos clientes que requieran mantener estados y un puerto común para los clientes que consulten la información completa. Los clientes que utilicen puertos especiales pueden solicitar la diferencia en la base de datos con respecto a su última consulta. En esta solución provisoria, la aplicación acepta conexiones en un solo puerto pero no se cierran las conexiones luego de cada consulta. De esta manera, cada cliente deja la conexión abierta y la aplicación puede identificar qué información le entregó a qué cliente. Manejo de las diferencias Debido a que esta funcionalidad es muy difícil de implementar sin tener una base de datos propiamente dicha, se optó por un mecanismo distinto para la solución provisoria. Este mecanismo consiste en considerar como diferencia si hubo una actualización de la base de datos o no. Como consecuencia los módulos como TE, que necesitan tener la información prácticamente en tiempo real, pueden hacer reiteradamente consultas en la misma conexión obteniendo una respuesta de no difference si ya tienen la última información disponible, o la totalidad de la información si cambió. Es importante mencionar que esta solución no es escalable en redes grandes porque requiere que se transmita toda la información de la base de datos al cliente con una frecuencia alta, lo que puede cargar la red de manera considerable. Si bien se consideró como una alternativa no soportar la opción difference, se valoró que era preferible una implementación rudimentaria de la misma ya que esto reduce considerablemente la carga en la red, especialmente durante la actuación del módulo TE Protocolo GRMAP Como se explicó en el capítulo 4 el protocolo GRMAP (Generalized RMA Protocol) surge por la necesidad de comunicar los distintos módulos que componen la arquitectura. La primera versión fue diseñada por el grupo RMA Control y las

118 98 Capítulo 9. Almacenamiento e Intercambio de Información sucesivas mejoras y correcciones se hicieron en conjunto. El objetivo de este protocolo de comunicación es hacer efectivo el desacople de los diferentes módulos del RMA, brindando un mecanismo único de comunicación y garantizando de esta manera la interoperabilidad de dichos componentes. El protocolo está compuesto por mensajes de consulta (request) y respuesta (reply) y utiliza como transporte al protocolo TCP. Todos los mensajes tienen un encabezado común donde se especifica la versión utilizada, el tipo de mensaje y el largo. El mismo puede verse en la figura 9.6. Los mensajes disponibles son: Cómputo de camino (GComp): Permite solicitar el cómputo de un camino con ciertas restricciones al módulo CBR. Señalización de camino (GSign): Permite solicitar al Módulo Señalización la creación de un nuevo LSP, o la baja o cambio de parámetros de uno existente. Consulta a la base de datos (GQuery): Permite a los distintos módulos de la arquitectura obtener la información disponible en la DB. Actualización de la base de datos (GUpdate): Permite a los módulos Topología y Monitorización actualizar la información almacenada en la DB. Figura 9.6: Encabezado de un paquete del protocolo GRMAP. Cada tipo de mensaje tiene su propio encabezado y además tiene una versión de consulta (request) y otra de respuesta (reply). La carga útil que es transportada por el protocolo corresponde a información en formato XML. El mismo sigue el modelo de información presentado anteriormente para las consultas y actualización de la base de datos, y un modelo similar para las transacciones de señalización. Éste último se encuentra especificado en el capítulo Conclusiones En este capítulo se presentó la forma de transmitir la información entre los distintos módulos de la arquitectura y de almacenarla de manera centralizada.

119 9.5. Conclusiones 99 Se definió un modelo de información basado en el lenguaje XML. El mismo presenta gran cantidad de información necesaria para los distintos módulos de la herramienta e incluso más de la necesaria, ya que se previó en su desarrollo contemplar futuras ampliaciones a la misma. El modelo de información tiene además la característica de ser fácilmente ampliable. En cuanto a la base de datos se cuenta con una solución provisoria implementada en software, la cual no limita ninguna funcionalidad hacia los demás módulos. Queda pendiente que el grupo RMA Control implemente la solución definitiva, aunque este hecho no generará funcionalidad adicional. Las principales ventajas residirán en el desempeño y escalabilidad. Con respecto a la transferencia de información, la misma se implementó a través del protocolo GRMAP. Gracias a ello se puede desacoplar la arquitectura en distintos módulos totalmente independientes que se comunican utilizando TCP, lo cual permite incluso que funcionen en equipos diferentes. También presenta la gran ventaja que pueden intercambiarse distintas implementaciones de un módulo para su comparación, teniendo solo que respetar la información enviada y el protocolo de comunicación.

120

121 Capítulo 10 Interfaz de Gestión En este capítulo se detallan los aspectos correspondientes a la Interfaz de Gestión. Se comentan los objetivos de la misma y se exponen los detalles de su implementación que incluyen la utilización de un software previo a este proyecto Objetivo El objetivo de este módulo es poder visualizar el estado de la red y permitir que su administrador pueda señalizar o dar de baja túneles. Como objetivo adicional, escapando a los objetivos definidos en la arquitectura RMA, se encuentra la posibilidad de incluir resultados de proyectos de grado anteriores, como ser componentes de Ingeniería de Tráfico fuera de línea o componentes de Multicast, que le dan valor agregado al resultado final. La discusión de la pertinencia de dichas componentes en este módulo se encuentra más adelante en este capítulo El software Net-TE La primera versión del software Net-TE es el resultado de un proyecto de fin de carrera realizado en el IIE cuya documentación final puede verse en [45]. El mismo implementa una serie de algoritmos de Ingeniería de Tráfico fuera de línea y una interfaz gráfica muy completa. Un segundo grupo de proyecto de grado trabajó con este software agregando funcionalidades de Multicast al mismo. Los resultados de este trabajo pueden verse en [46] Solución Implementada Sobre la implementación del software Net-TE se decidió agregar la funcionalidad de integrarse a la herramienta en línea como interfaz de gestión. Para ello se 101

122 102 Capítulo 10. Interfaz de Gestión procuró mantener la implementación de Net-TE incambiada y agregarle una componente independiente de las ya existentes, que permitiera la comunicación con la herramienta en línea. La componente de Ingeniería de Tráfico fuera de línea se decidió que debía conservarse como parte de la interfaz de gestión. Si bien esta decisión implica aumentar las responsabilidades de la interfaz de gestión tal cual está definida en [41], se valoró que era pertinente incluirlo en la herramienta desarrollada y en particular en este módulo. El vínculo de complementariedad que tienen la Ingeniería de Tráfico en línea y fuera de línea justifica la inclusión de esta última en la herramienta completa. Se introdujo en la interfaz de gestión ya que no viola la independencia de los módulos, reutiliza la implementación existente y cumple la función de asistir al administrador en la simulación de distintos escenarios. La componente Multicast también fue integrada a la versión final propuesta por este proyecto, con el fin de disponer de una herramienta única con todas las posibilidades de uso y no herramientas divergentes. Los cambios introducidos en el Net-TE pueden descomponerse en los siguientes: Adaptación al modelo de información Adaptación a la arquitectura modular Desacople de funciones Consultas a la base de datos Comunicación con el módulo señalización Implementación del protocolo de comunicación Mejoras en la interfaz gráfica Visualización de direcciones IP Visualización de router id de OSPF Posibilidad de editar los distintos elementos de red Despliegue y procesamiento de la información de performance obtenida de la TED Integración de las distintas versiones A continuación se comentan los aspectos recién mencionados Adaptación al modelo de información Se incluyó al software la habilidad de interpretar cadenas de carácteres que siguiesen el modelo de información descrito en el capítulo 9. Esto permitió agregar dos funcionalidades: el manejo de archivos en formato XML y el manejo de la información obtenida a través de la comunicación con la base de datos.

123 10.3. Solución Implementada 103 Los archivos ofrecen la gran ventaja de poder almacenar la información de la red obtenida a través de la base de datos en un cierto momento, y aun incluir a ésta, información de simulaciones fuera de línea. El software ya contemplaba la opción de guardar archivos y luego recuperarlos. Esto se hacía utilizando un formato propio definido por el proyecto Net-TE, que consiste en archivos de texto que utilizan ciertas etiquetas definidas para indicar comienzo y fin del archivo, y otras para indicar cada componente de la red. La acción de los módulos de topología y monitorización brindan información que no existía en el Net-TE y no hubiese sido fácil la adaptación para retenerla en los formatos previos, por lo que se decidió adoptar el formato XML mencionado Adaptación a la arquitectura modular Como se comentó en el capítulo 5, el software Net-TE contenía una opción para obtener la topología física de la red de manera automática. Se decidió desacoplar esta funcionalidad del software y ubicar la misma en el módulo de topología ya que de esta manera se lograba integrar coherentemente el Net-TE a la arquitectura propuesta. Si bien ésta era una funcionalidad del software, la misma no había sido probada extensamente en un ambiente real, por lo que se debieron hacer pruebas y mejoras para que funcionase en distintos escenarios. Además, la misma no había sido concebida para trabajar en línea por lo que se consideró oportuno el desacople. Por otro lado, para completar la adaptación a la arquitectura modular se debió incluir al software la funcionalidad de realizar consultas a la base de datos y enviar pedidos al módulo de señalización. Esto implicó algunas modificaciones en la interfaz gráfica y la implementación del protocolo GRMAP, detallado en el capítulo 9. La figura 10.1(a) muestra la ventana utilizada para solicitar la carga automática de la red. Como se puede apreciar en la misma, el único parámetro que el usuario debe ingresar es un identificador de la red. Esto es consecuencia de la adaptación a la arquitectura modular y hace mucho más sencillo el uso de la herramienta, ya que el usuario no debe conocer parámetros de SNMP. En la figura 10.1(b) se puede ver la ventana que permite señalizar caminos. A través de ellas se pueden configurar los LSPs creados en el Net-TE y eliminar de la red aquellos LSPs descubiertos. Estas dos funcionalidades pueden hacerse para un conjunto de LSPs en una misma operación. Por último se debió modificar levemente la lógica de los elementos de red que maneja el software Net-TE. A partir de la inclusión de información en línea surge la necesidad de que convivan los LSPs reales, es decir aquellos obtenidos de la red real, y los LSPs simulados con las funcionalidades fuera de línea del Net-TE, sin que éstos sean confundidos.

124 104 Capítulo 10. Interfaz de Gestión (a) Solicitar red a la base de datos. (b) Alta y baja de LSPs explícitos. Figura 10.1: Ventanas para la comunicación con otros módulos Mejoras en la interfaz gráfica Además de las modificaciones necesarias para la comunicación con los otros módulos de la arquitectura se hicieron algunas incorporaciones a la interfaz gráfica del software buscando el objetivo de hacerla más amigable y versátil. Se incluyeron en la interfaz gráfica opciones para visualizar o no, según comodidad del usuario, información de dirección IP de cada interfaz, router ID de OSPF, nombre de enrutadores y enlaces. Se incluyó también la posibilidad de cambiar el tipo de un enrutador de LSR a LER y viceversa e incluir al mismo una etiqueta definida por el usuario. (a) Editar un nodo. (b) Editar un LSP. Figura 10.2: Algunas funcionalidades gráficas incorporadas Despliegue y procesamiento de la información de performance obtenida de la TED La integración con la herramienta en línea hizo posible que se incorporara tanto información sobre los LSPs y sus reservas de ancho de banda en el plano de control, como distintos parámetros de performance locales y extremo a extremo. La herramienta Net-TE ya contaba con la posibilidad de visualizar estadísticas de los enlaces, mostrándolos en una lista ordenada según las reservas fuera de línea de

125 10.3. Solución Implementada 105 cada uno. El presente proyecto agregó a esta información datos del ancho de banda cursado por cada interfaz, y por cada LSP. De esta manera se puede visualizar el tráfico de cada LSP en el plano de datos y una comparación de éste con el ancho de banda reservado en el plano de control. La información de ancho de banda cursado también se muestra para cada enlace. Con respecto a los nodos, se agregó el despliegue de información relativa a la carga de CPU que tiene cada uno, su máximo y su promedio. Otra incorporación atractiva que el presente proyecto hizo al software Net-TE es la posibilidad de observar la evolución temporal del ancho de banda cursado por interfaz y por LSP, así como también la evolución en el tiempo de la carga de CPU de cada uno de los nodos que componen la topología. Un ejemplo de esto se muestra la figura 10.3(a), en la que se muestra el tráfico cursado por un LSP durante un intervalo de tiempo. Se incluyó también la opción de visualizar la utilización de cada enlace considerando LSPs simulados y reales simultáneamente. (a) Evolución temporal. (b) Promedios, máximos, reservas. Figura 10.3: Visualización de estadísticas. Los cálculos para poder contar con la información comentada en el párrafo anterior se realizaron a partir de los datos de estadísticas obtenidos de la base de datos. Estas estadísticas consisten en valores de contadores que indican bytes por interfaz, bytes por interfaz por LSP (referidas en este texto como interfaz virtual), pérdidas por interfaz y uso de CPU para cada nodo. Cada uno de estos valores con su respectiva estampa de tiempo de cuando fue obtenido. El ancho de banda por interfaz se calcula teniendo en cuenta si es FULL- DUPLEX o HALF-DUPLEX, información que se obtiene de la base de datos. Para el caso FULL-DUPLEX se calcula en el sentido entrante (BW entrante ) y saliente (BW saliente ) con la fórmula 10.1 y 10.2, donde ifinoctets representa la diferencia entre dos valores consecutivos de los bytes entrantes a la interfaz, y if OutOctets el valor análogo para el caso saliente. Por otro lado, para el caso HALF-DUPLEX

126 106 Capítulo 10. Interfaz de Gestión el ancho de banda cursado por la interfaz (BW) se calcula usando la fórmula BW entrante = ifinoctets 8 marcadetiempos BW saliente = ifoutoctets 8 marcadetiempos (10.1) (10.2) BW = ( ifoutoctets + ifinoctets) 8 marcadetiempos (10.3) Para el cálculo del tráfico en el plano de datos de cada LSP se realizaron cálculos similares a los de las ecuaciones 10.1 y 10.2 pero considerando los datos adecuados para los LSPs: los paquetes por interfaz virtual de MPLS. A su vez, luego se tomó el valor mínimo del ancho de banda cursado por cada interfaz virtual en el camino para obtener un valor del ancho de banda cursado por el LSP Integración de las distintas versiones Una tarea que consumió una parte importante del tiempo dedicado a la implementación de este módulo, fue la integración de las distintas versiones existentes. Si bien esta tarea no era imprescindible para que la interfaz de gestión cumpliese sus funciones, se consideró de orden presentar en la solución final una versión que incluyera las funcionalidades aportadas por el grupo Multicast mencionado en la sección 10.2 de este capítulo. De esta manera se piensa que se está haciendo un aporte importante para que futuros trabajos sobre el mismo software conduzcan a una solución mejor y no varias que ataquen distintos aspectos de esta temática. Una imagen de la ventana principal del software, luego de las inclusiones mencionadas previamente en este capítulo, puede verse en la figura 10.4 El software provee otras funcionalidades que pueden consultarse en [45] y no son descritas en esta sección por no ser parte de la solución implementada por este proyecto Conclusiones En este capítulo se presentó el software utilizado para cumplir las funciones de interfaz de gestión de la herramienta en línea. Se comentaron las distintas posibilidades que ésta brinda, haciendo especial énfasis en aquellos aspectos desarrollados por el presente proyecto. La interfaz de gestión con la que cuenta la herramienta permite que el usuario o administrador pueda tener una imagen del estado de la red bajo estudio y pueda configurar o dar de baja LSPs de manera sencilla. También permite combinar herramientas de cálculo fuera de línea sobre la red bajo estudio, para simular distintos casos de ampliación o de cambios en el tráfico sobre la misma.

127 10.4. Conclusiones 107 Figura 10.4: Interfaz gráfica del software Net-TE. El hecho de contar con una implementación ya muy avanzada de la parte gráfica y con una arquitectura modular con su mecanismo de comunicación definido, hizo que la adaptación del software Net-TE, para integrar la herramienta en línea, fuera posible. Esto permite concluir que la elección de la arquitectura fue exitosa en lo que a versatilidad refiere.

128

129 Capítulo 11 Ingeniería de Software Introducción En este capítulo se muestran resultados sobre los aspectos de análisis y de diseño que se contemplaron durante el desarrollo del software descrito en los capítulos anteriores. Se decidió implementar como módulos de software independientes a los distintos módulos de la arquitectura elegida, cuyo detalle se comentó en el capítulo 4. Prevaleció en todo momento como criterio de diseño el preservar la independencia de los módulos, por lo que se verá que cada módulo resuelve lo que le compete y se comunica con el resto de los módulos de la manera descrita en el capítulo 4. A continuación se describen las componentes de software de cada uno de los módulos Análisis y diseño Módulo Topología A. Casos de Uso Para este módulo se identificó como único caso de uso levantar la topología física de una red. Se identificaron como actores: la red, el administrador de la red y la base de datos. A continuación se describe el caso de uso. El diagrama del mismo se muestra en la figura Caso de uso: Descubrir la topología física de una red El administrador desea que se conozca la topología física de la red bajo estudio. Para ello ejecuta la operación de descubrir la topología en el sistema proveyendo los datos requeridos por el mismo: community SNMP, dirección IP de un nodo de la red y opcionalmente, otros parámetros del protocolo SNMP (por ejemplo tiempo de expiración, reintentos). El sistema realiza las consultas a la red utilizando el protocolo SNMP, comenzando por 109

130 110 Capítulo 11. Ingeniería de Software el nodo cuya identidad se conoce e iterativamente completa la información buscada; los nodos y enlaces presentes en la red, direcciones IP, nombres y velocidades nominales de las interfaces. El sistema persiste la información recolectada en la base de datos. No se incluye en esta sección una descripción en formato completo del caso de uso para permitir una lectura más ágil de la misma. No obstante, los escenarios alternativos se harán evidentes más adelante en esta sección. Figura 11.1: Diagrama de casos de uso. Módulo Topología. B. Modelo Conceptual El modelo conceptual de este módulo se puede ver en la figura C. Diagrama de secuencia El diagrama de secuencia de este módulo se puede ver en la figura D. Diagrama de paquetes El proceso de diseño llevó, luego de varias iteraciones, al diagrama de paquetes que se muestra en la figura Se puede advertir que se han omitido detalles en la documentación de las etapas de análisis con el fin de simplificar sus gráficos.

131 11.2. Análisis y diseño 111 Figura 11.2: Modelo conceptual. Módulo Topología. Figura 11.3: Diagrama de secuencia. Módulo Topología.

132 112 Capítulo 11. Ingeniería de Software Figura 11.4: Diagrama de paquetes. Módulo Topología.

133 11.2. Análisis y diseño Módulo Monitorización A. Casos de Uso Para el módulo de monitorización el análisis del problema llevó a la detección de un caso de uso complejo. Este caso de uso se descompuso en otros debido a su complejidad y a la posibilidad de que se quieran ejecutar los casos de uso por separado. Se identificaron como actores: la red, el administrador de la red y la base de datos. A continuación se describen los mismos en formato breve. El diagrama de casos de uso se puede observar en la figura Caso de uso: Monitorizar la red El administrador desea que se tenga disponible información dinámica de la red, esta información refiere a los LSPs establecidos en la misma y a parámetros de performance de la red. El administrador ejecuta la operación monitorizar red, el sistema consulta a la base de datos la red física disponible y ésta se la devuelve. Luego se ejecutan los casos de uso Descubrir topología virtual de la red y Recolectar parámetros de performance de la red. El sistema envía a la base de datos la nueva información obtenida. Caso de uso: Descubrir la topología virtual de la red El sistema comienza a consultar a cada uno de los nodos de la red, utilizando el protocolo SNMP, información disponible en la MPLS-TE-MIB. La red devuelve esta información al sistema, éste la procesa y almacena la información de los LSPs descubiertos. Caso de uso: Obtener parámetros de performance de la red El sistema consulta a cada nodo de la red, utilizando el protocolo SNMP, parámetros de performance disponibles en la MIB-II y en la MPLS-TE-MIB. Cada nodo que es consultado devuelve esta información. El sistema retiene internamente esta información. El sistema procede a obtener parámetros de performance de extremo a extremo para lo que establece una conexión mediante TELNET con cada nodo. Se consulta mediante TELNET el retardo de cada LSP. El sistema almacena internamente esta información. B. Modelo conceptual El modelo conceptual del módulo monitorización puede verse en la figura C. Diagrama de Interacción Para este módulo se presenta el diagrama de secuencia separado en tres diagramas ya que la complejidad de su única operación así lo amerita. En la figura 11.7 se muestra la secuencia sin desarrollar. En la figura 11.8 se muestra el detalle del manejo de los hilos. Por último, en la figura 11.9 se muestra el detalle de cada hilo de ejecución. La secuencia correspondiente a la recolección de parámetros de performance no se incluye paso por paso para no abrumar al lector.

134 114 Capítulo 11. Ingeniería de Software Figura 11.5: Diagrama de casos de uso. Módulo Monitorización. Figura 11.6: Modelo conceptual. Módulo Monitorización. D. Diagrama de paquetes El diagrama de paquetes se muestra en la figura

135 11.2. Análisis y diseño 115 Figura 11.7: Diagrama de interacción general. Módulo Monitorización. Figura 11.8: Detalle 1 diagrama de interacción. Módulo Monitorización.

136 116 Capítulo 11. Ingeniería de Software Figura 11.9: Detalle 2 diagrama de interacción. Módulo Monitorización.

137 11.2. Análisis y diseño 117 Figura 11.10: Diagrama de paquetes. Módulo Monitorización.

138 118 Capítulo 11. Ingeniería de Software Módulo TE A. Casos de Uso En este módulo se detectó el caso de uso evitar congestión, que fue descompuesto en dos casos de uso: detectar congestión y correr algoritmo correctivo. Se identificaron como actores, el administrador de la red, la red, la base de datos y el módulo señalización. A continuación se describen los casos de uso. Caso de uso: Evitar congestión El administrador de la red desea evitar situaciones de congestión de la red, y en caso de que existan corregirlas. Para ello ejecuta la operación del sistema realizar Ingeniería de Tráfico. El sistema procede a ejecutar el caso de uso detectar congestión. Caso de uso: Detectar congestión El sistema pide a la base de datos información sobre la red física, los LSPs sobre ella establecidos y estadísticas sobre los datos de performance asociados a ella. El sistema arma los grupos de LSPSs entre los que se balancea carga, y procede a analizar los parámetros de retardo en cada uno de los LSPs que componen los grupos. Calcula la diferencia entre la derivada del retardo respecto a la carga, máxima y mínima en cada grupo, y si esto supera un cierto umbral marca al grupo como posible grupo desbalanceado. El sistema pide a la base de datos nuevamente la red, con nuevos parámetros de performance, y actualiza la información de cada grupo. En caso de detectar nuevamente desbalanceo en algún grupo, considera que estos están desbalanceados. El sistema ejecuta el caso de uso correr algoritmo correctivo para los grupos desbalanceados, marca los mismos como en proceso de corrección y vuelve a cero el resto de los grupos. El sistema continúa realizando este proceso, consultando si el algoritmo terminó o no en aquellos casos en que se está en fase de corrección. Caso de uso: Correr algoritmo correctivo El sistema ejecuta el algoritmo MATE pasando como parámetros los LSPs desbalanceados. El sistema procede a realizar las iteraciones correspondientes. Al fin de cada iteración indica, utilizando el protocolo de comunicación GRMAP y el formato XML, al Módulo Señalización que haga los cambios correspondientes en cada LSP. Al comienzo de cada iteración el sistema pide una nueva red a la base de datos hasta constatar que los cambios efectivamente se hayan configurado en la red. Prosiguen estos pasos de pedido de red, iteración, y señalización hasta que converge el algoritmo y el sistema considera balanceado el grupo y no hace más nada con él. B. Modelo Conceptual El modelo conceptual de este módulo se puede ver en la figura

139 11.2. Análisis y diseño 119 Figura 11.11: Diagrama de Casos de Uso. Módulo TE. Figura 11.12: Modelo conceptual. Módulo TE. C. Diagrama de Interacción El diagrama de interacción de este módulo puede verse en la figura En el mismo se hace énfasis en el la secuencia de detección. La secuencia de corrección no se adjunta en este capítulo ya que si bien fue una etapa necesaria de la ingeniería de software el procedimiento fue claramente explicado en otros capítulos.

140 120 Capítulo 11. Ingeniería de Software Figura 11.13: Diagrama de interacción. Módulo TE. Detección de Congestión. D. Diagrama de paquetes El diagrama de paquetes se muestra en la figura

141 11.2. Análisis y diseño 121 Figura 11.14: Diagrama de paquetes. Módulo TE.

142 122 Capítulo 11. Ingeniería de Software Otros Módulos Como se pudo ver en las distintas secciones de este capítulo hay elementos que son comunes a la gran mayoría de los módulos. Es por eso que se decidió implementar un módulo que lleva el nombre de comunes y contiene todos los elementos de software que son comunes a los distintos módulos. El módulo comunes consta de las clases necesarias para implementar: El protocolo de comunicación (GRMAP) La comunicación con la base de datos Generar e interpretar las cadenas de caracteres del XML Los elementos que modelan la topología de una red La comunicación mediante SNMP con los nodos de la red real El manejo de los archivos de configuración Las excepciones de todo el software Funcionalidades de propósito general En la figura se puede observar algunos de los paquetes contenidos en este módulo Implementación Para la implementación del software se decidió utilizar el lenguaje orientado a objetos JAVA, debido a su gran versatilidad. Este lenguaje presenta numerosas ventajas entre las que se destacan que es independiente del fabricante y que, debido a su popularidad, existen muchas bibliotecas públicas que permiten ahorrar tiempo en la implementación de las funciones auxiliares. También se tuvo en cuenta para su elección que ya se contaba con experiencia en el mismo para el desarrollo de aplicaciones, lo que permitió ahorrar el estudio de un nuevo lenguaje. Se eligió utilizar la versión 1.5 debido a que algunas de las bibliotecas utilizadas así lo requerían. Los módulos fueron implementados como aplicaciones independientes, lo que permite que corran en distintos equipos. De todas maneras, como se comentó anteriormente en este capítulo, se agruparon todas las funcionalidades comunes en un package que es utilizado por todos los módulos. Esto por un lado, permite la reutilización del código, y por otro facilita su mantenimiento. Por ejemplo, en caso de que se realicen modificaciones en el protocolo GRMAP, sólo debe modificarse dicho package. Para los casos en que se quieren ejecutar diversas funciones simultáneamente en un mismo módulo, se utilizaron hilos o threads. Los mismos permiten correr

143 11.4. Despliegue 123 varios procesos simultáneamente en la misma máquina virtual. Son utilizados, por ejemplo, al realizar el descubrimiento de los LSPs para consultar todos los nodos simultáneamente y acelerar el proceso. Se tuvo especial cuidado en la elección de los tipos utilizados para almacenar información. En particular, se estudió en cada caso cuál era el contenedor más apropiado desde el punto de vista de la velocidad de acceso. El objetivo de esto es lograr la mayor rapidez en el acceso a los datos dado que la herramienta tiene fuertes requerimientos de tiempos. Algunas de las clases creadas para almacenar información pueden verse en la figura 11.15(e). La utilización de bibliotecas externas hizo que se simplificara sensiblemente el desarrollo de muchas de las funcionalidades del package comunes. En particular, se utilizaron las bibliotecas ADVENTNET SNMP API para el manejo del protocolo SNMP, y JDOM para el manejo del formato XML. Como conclusión general se puede decir que la elección del lenguaje fue acertada. Se lograron implementar todas las funcionalidades buscadas y a su vez se logró reutilizar una gran cantidad de clases lo que permitió ahorrar mucho tiempo de implementación Despliegue El objetivo de esta sección es mostrar cómo se deben utilizar los distintos módulos y dejar en claro las dependencias reales entre ellos. En la figura se puede ver un diagrama de despliegue. En él se indican los nodos locales, nodos intermedios y nodos remotos. Los nodos locales refieren a aquellos equipos que deben encontrarse en la misma red a controlar. Por otro lado, los nodos remotos son equipos que pueden encontrarse en cualquier sitio, teniendo únicamente que cumplir con la restricción de tener conectividad con el equipo donde se encuentre la base de datos. Por último, se hace referencia a nodos intermedios que son equipos que tienen que tener conexión con los equipos locales y los remotos.

144 124 Capítulo 11. Ingeniería de Software (a) Modelado de la topología (b) Manejo de conexiones SNMP (c) Manejo de XML (d) Manejo de Conexiones (e) Contenedores y Utilidades Figura 11.15: Paquetes comunes.

145 11.4. Despliegue 125 Figura 11.16: Diagrama de despliegue.

146

147 Parte III Validación y Conclusiones

148

149 Capítulo 12 Validación Introducción En este capítulo se repasan los criterios de éxito del proyecto, se describen las pruebas realizadas para la validación, se analizan los resultados y se presentan las conclusiones correspondientes. El objetivo principal de las pruebas fue la validación de la herramienta basándose en los criterios de éxito. No obstante, se buscó también validar la solución implementada frente a criterios generales, buenas prácticas en el desarrollo de herramientas de este tipo y comparación con soluciones similares Criterios de Éxito Los criterios de éxito fueron delineados en el plan de proyecto adjunto a este documento en el apéndice C. Los mismos especificaban: Una prueba de funcionamiento donde se constate la correcta obtención de la topología física y virtual. La prueba consistirá en realizar la obtención en una red con una topología conocida, verificar si es correcta, realizar un cambio en la topología y volver a realizar la obtención constatando que se haya detectado correctamente el cambio. Una segunda prueba consistente en generar tráfico de manera de tener escenarios de congestión y no congestión y verificar que se recogen correctamente los parámetros de desempeño de la red a partir de medidas colectadas a través de SNMP ( por ejemplo: retardos, ancho de banda utilizado, etc.) y de acuerdo con lo que fija la salida del algoritmo implementado, se reconfigura la red adecuadamente. Esto último quiere decir que es capaz de establecer un nuevo LSP y/o reenrutar parte del tráfico por otro LSP al que tenía asignado originalmente. Una prueba que valide el funcionamiento del algoritmo implementado. El 129

150 130 Capítulo 12. Validación detalle de dicha prueba será definido una vez definido el algoritmo a implementar. Como se describió en el capítulo 1.3, el desarrollo de la herramienta se apoyó en la red de pruebas existente. Sobre la misma se realizaron las pruebas tanto a lo largo del desarrollo del proyecto, una vez que se tuvo la implementación final de cada módulo, como las de carácter integral realizadas para la validación final. Es importante aclarar que no fue posible realizar pruebas de escalabilidad por el hecho de contar con una topología reducida y no poder ampliarla con más nodos como se explica en el apéndice B Módulo Topología Para validar la implementación del módulo de topología se realizaron una serie de pruebas en la red existente, contrastando los resultados del algoritmo con la información disponible en documentación y las terminales de los equipos Descubrimiento de la topología física Se comprobó que la implementación realiza el correcto descubrimiento de todos los nodos y enlaces de la red. Para validar el funcionamiento en situaciones anómalas, se simularon caídas de enlaces y enrutadores. Se deshabilitó el protocolo OSPF de algunos nodos, simulando caídas y constatando que eran eliminados de la topología recolectada. Lo mismo se hizo en algunas interfaces para simular caídas de enlaces, se deshabilitaron y se comprobó que no fueran descubiertas. También se verificó que reacciona correctamente si los cambios ocurren mientras el software está corriendo. Se comprobó que al recibir una notificación de SNMP se reinicia el algoritmo y descubre correctamente la nueva topología. Si la interfaz se da de baja manualmente, el reinicio del algoritmo es instantáneo ya que el vecino inmediatamente modifica la ospfnbrtable y envía una notificación. Por otro lado si se deshabilita OSPF en un nodo, el vecino tarda 4 HELLO-INTERVAL en enviar la notificación. Debido a que el módulo debe mantener la topología actualizada, prácticamente en tiempo real, es una variable fundamental a tener en cuenta el tiempo que insume el descubrimiento de la misma. Para especificarlo se corrió el algoritmo sucesivas veces registrando los tiempos de inicio y fin del proceso de reconocimiento. El tiempo insumido en descubrir la topología de la red de pruebas fue de aproximadamente 2 segundos y medio, como se muestra en la figura Es importante aclarar que los tiempos mostrados son para el caso de la red de pruebas con sus enlaces en un bajo porcentaje de utilización. Esto es debido a que la capacidad de los mismos supera ampliamente la capacidad de generación de tráfico disponible, lo que se presenta con mayor detalle en la sección Dado que la red

151 12.3. Módulo Topología Tiempo de descubrimiento de la topologia de la red de pruebas valores medidos media Tiempo(ms) n corrida Figura 12.1: Tiempos del Módulo Topología. de gestión coincide con la red de datos, los retardos producidos por una sobrecarga en los enlaces afectarán los tiempos insumidos en descubrir la topología. Al mismo tiempo se verificó que el módulo descubre correctamente los siguientes parámetros asociados a los nodos: RouterId Direcciones IP Velocidad de las interfaces Nombre Para esto se comparó la información recolectada por el algoritmo con la configuración de los nodos. Por último se hicieron pruebas para corroborar la correcta interacción con la base de datos, verificando que la misma es actualizada cuando se detectan cambios en la topología Conclusiones Se presentaron las pruebas realizadas para validar el funcionamiento del módulo de topología. Se explicaron las posibles situaciones que se pueden presentar en la práctica, cómo se comporta la herramienta ante ellas y los tiempos insumidos por el módulo de software desarrollado.

152 132 Capítulo 12. Validación Como primera conclusión se puede decir que la implementación realizada funciona correctamente, descubriendo la topología y los parámetros de los enrutadores. Teniendo en cuenta la cantidad de nodos y enlaces que tiene la red, el tiempo insumido en levantar la topología completa es considerado satisfactorio. Si bien se puede argumentar que aumente para topologías más grandes y complicadas que la de la red de pruebas, se debe considerar que el objetivo de este módulo es mantener actualizada la topología en la base de datos y no levantar continuamente distintas topologías. En este sentido se buscó acelerar la actualización frente a algún cambio con las notificaciones de SNMP, que si bien no aceleran el proceso de levantamiento de la topología, evitan que el cambio tarde en detectarse por encontrarse el algoritmo descubriendo otra parte de la red. Por lo tanto se minimiza el tiempo de actualización a un período de reconocimiento. Sería deseable cuando se cuente con una implementación que realice el descubrimiento de la topología participando del ruteo, como la que se prevé implemente el grupo RMA Control, comparar los desempeños de las dos implementaciones con la misma topología. Ésta posible comparación fue justamente una de las razones por las que se eligió resolver el descubrimiento de la topología por SNMP. En cuanto a robustez, el módulo se comportó correctamente durante todas las pruebas realizadas. Teniendo en cuenta que por ser el primer módulo en implementarse estuvo terminado 6 meses antes de la finalización del proyecto y se utilizó casi diariamente durante este período, se concluye que el módulo es muy robusto. Por otro lado, como se comentó anteriormente, sólo pudieron hacerse pruebas con topologías reducidas, lo que impide sacar conclusiones sobre el comportamiento del software en situaciones de carga. Sería deseable poder realizar estas pruebas para determinar fehacientemente los requerimientos del PC donde se corre el software. Teniendo en cuenta los objetivos planteados para este módulo y los resultados obtenidos se concluye que el módulo de topología cumple ampliamente con los criterios de éxito Módulo Monitorización Para la validación del Módulo Monitorización también se realizaron pruebas en la red descripta en el anexo B. Se presentan a continuación los resultados globales obtenidos tanto para el descubrimiento de LSPs como para la recolección de parámetros de performance Descubrimiento de LSPs Previo a las pruebas de descubrimiento de LSPs debieron configurarse distintos túneles distribuidos en los nodos de la red. Al principio se configuraron manualmente en la consola de los nodos, pero cuando se tuvieron prontas las herramientas de gestión y señalización el proceso se simplificó sensiblemente.

153 12.4. Módulo Monitorización 133 Se verificó que el módulo de monitorización descubre todos los LSPs establecidos en la red, comprobando que estén habilitados administrativamente y operativos. Para esto se comparó el resultado del algoritmo con la configuración establecida. También se configuraron LSPs erróneamente, por ejemplo con un camino incorrecto, para verificar que no fueran levantados. Además se comprobó que cuando ocurre un cambio en la topología virtual, ya sea por un nuevo túnel o la caída o reenrutamiento de uno existente, este cambio es descubierto correctamente. Si la aplicación se encuentra corriendo y descubre una incoherencia en las tablas, como las comentadas en la sección 6.2.1, se reinicia el algoritmo. Si ocurre un cambio y no detecta una incoherencia, al recibir la notificación de SNMP correspondiente se reinicia el descubrimiento. También se corroboró que al simular la caída de una interfaz, mediante la inhabilitación administrativa de la misma, el algoritmo se reinicia correctamente. En las pruebas también se comprobó que la aplicación obtiene correctamente los siguientes parámetros asociados a los túneles: Coeficiente de reparto de carga Reservas de recursos FEC Como se comentó en el capítulo 6, los coeficientes de balance de carga se levantan a través de la lectura del archivo de configuración de los nodos. Se debe tener presente que actualmente esta funcionalidad está disponible sólo para equipos CISCO. Con respecto a las FECs, las pruebas mostraron las limitaciones de la solución implementada, en la que se maneja como concepto de FEC la red de destino. También se realizaron pruebas que validaron las ventajas de la implementación en hilos (threads). Como se vio en el capítulo 6, el descubrimiento de la topología virtual se realiza en paralelo para todos los nodos donde se inician túneles. Esto trae como consecuencia que el tiempo de descubrimiento de LSPs depende principalmente de la cantidad de saltos del túnel más largo y de la cantidad de túneles del nodo con más túneles, aunque también depende del total de túneles de la red. Con respecto a los tiempos insumidos en el descubrimiento de la topología virtual, se hicieron muchas pruebas con distintas cantidades de túneles y distribuidos de diferentes maneras en los nodos de la red. A modo de referencia para una topología de 20 túneles distribuidos uniformemente en la red presentada en el anexo B, el tiempo total del relevamiento de los túneles es aproximadamente de 60 segundos cuando se realiza en paralelo. Para la misma topología si se realizara en serie (sin threads) el tiempo ascendería a 140 segundos como se puede ver en la figura El hecho de no estar disponible la obtención de los coeficientes de reparto de carga por SNMP llevó a tener que conocer los mismos mediante la interpretación del archivo de configuración de cada nodo, el cual es obtenido por TFTP. En un principio se consideró que esto constituiría el cuello de botella de todo el proceso. Sin embargo,

154 134 Capítulo 12. Validación Tiempo de levantamiento de 20 tuneles en serie media media en paralelo Tiempo(ms) Figura 12.2: Tiempo de relevamiento de LSPs. Comparación implementación en serie y paralelo. corrida tras estudiar los tiempos insumidos con y sin ese proceso se concluyó que esto no afecta de manera considerable el tiempo total del levantamiento de los túneles. En el ejemplo de una topología con 20 túneles el tiempo insumido por este proceso representa aproximadamente el 10 por ciento del total, como puede verse en la figura Este resultado se considera positivo, ya que en la actualidad no existen posibilidades de realizar la obtención de otra manera.

155 12.4. Módulo Monitorización Tiempo de levantamiento de tuneles en paralelo para 20 tuneles sin tftp media con tftp media Tiempo(ms) Figura 12.3: Tiempo de relevamiento de LSPs. Comparación de la implementación con y sin TFTP. corrida

156 136 Capítulo 12. Validación Obtención de parámetros de performance Para validar la obtención de parámetros de performance se realizaron pruebas inyectando tráfico en distintos túneles. Se verificó que al cursar tráfico en la red, el mismo se ve reflejado en los contadores de las interfaces físicas de los equipos y de las virtuales de MPLS. A su vez, se corroboró que el ancho de banda calculado a partir de estos valores y sus correspondientes marcas de tiempo coincide con el estimado por el enrutador en su consola. Para inyectar tráfico en la red se utilizaron los generadores de tráfico detallados en el apéndice B. Este punto fue considerado importante ya que de él dependía gran parte de la validación de la herramienta completa. Se eligió generar tráfico primero constante y luego con una distribución de Poisson. Se hicieron pruebas variando los parámetros de la distribución estadística del tráfico para contemplar el comportamiento frente a escenarios aleatorios que se pueden considerar aproximados a la realidad. Para controlar el camino del tráfico de pruebas se mapeó el mismo a LSPs que fueron establecidos utilizando la propia herramienta de gestión desarrollada. Luego mediante la misma herramienta de gestión se constató que el tráfico cursado se correspondiera con el especificado en la configuración del generador. Esto además de validar el funcionamiento del Módulo Monitorización, permitió demostrar la importancia de tener una herramienta gráfica de gestión incorporada a la arquitectura. La misma prueba realizada sin esta herramienta hubiese involucrado la configuración manual de nodos y consulta de la salida del módulo de monitorización en crudo. Por otro lado se corroboró el correcto funcionamiento de la herramienta de medida de retardos extremo a extremo desarrollada. Se realizaron pruebas variando la cantidad de tráfico inyectado para las medidas, observando resultados coherentes con la teoría: a más tráfico más retardo. Esto puede observarse en la figura 12.6 de la sección Debido a que la capacidad de la red supera ampliamente la capacidad de los generadores disponibles, se decidió simular una red de menor capacidad modificando la configuración de ATM que se utiliza como transporte de MPLS. Esto permitió trabajar en la zona donde el retardo es más sensible a las variaciones de carga. Por último se verificó el correcto funcionamiento ante errores en las mediciones. Por ejemplo si un nodo no responde a una medida de extremo a extremo, la herramienta no se bloquea y continúa, ignorando esa medida. En la figura 12.4 se puede ver el tiempo insumido en el proceso de levantamiento de parámetros de performance para una topología con 20 túneles. En la misma se muestra una comparación con y sin la obtención de retardo de cada túnel. En este caso se puede ver que los tiempos de actuación de esta parte de la herramienta descenderían drásticamente si se contara con otro método para levantar este tipo de parámetros. Se considera interesante la comparación ya que este punto es mejorable cuando se implemente la interconexión con la herramienta Metronet.

157 12.4. Módulo Monitorización Tiempo de levantamiento de parametros de performance para 20 tuneles relevando retardo media sin relevar retardo media Tiempo(ms) Figura 12.4: Tiempo de relevamiento de parámetros de performance. Impacto de las medidas extremo a extremo. corrida Conclusiones Se presentaron las pruebas realizadas para validar el correcto funcionamiento del módulo de monitorización. Se mostró por separado el análisis para el descubrimiento de la topología virtual y para los parámetros de performance. En el caso de la topología virtual la validación permite concluir que se cuenta con una herramienta robusta frente a los distintos escenarios posibles, incluyendo cambios externos a la aplicación y simulación de caídas de nodos. Se verificó que los LSPs se descubren de principio a fin, junto con un grupo de parámetros asociados entre los cuales se encuentra el reparto de carga e información correspondiente a la FEC. Estos últimos son recogidos con implementaciones provisorias, sobre las cuales se deberá continuar trabajando una vez que se cumplan ciertos supuestos, como la implementación de la MPLS-FTN-MIB por parte de los fabricantes. El mecanismo utilizado para la obtención del coeficiente de reparto de carga afectó el resultado en un aspecto de gran importancia: la no independencia del fabricante. No obstante, se demostró que el mecanismo no tiene un impacto significativo en el desempeño de la herramienta en cuanto a tiempos, otro de los requerimientos importantes del proyecto. Si bien no se logró tener independencia del fabricante, se priorizó ante ello la implementación de una herramienta completa. Esto quiere decir que, de mantenerse ese requisito no se hubiese podido implementar la obtención de dichos coeficientes. Además se corroboró que se mantiene actualizada la topología virtual almacenada en la base de datos en un tiempo razonable para el correcto funcionamiento

158 138 Capítulo 12. Validación de los demás módulos. Se comprobó que el cuello de botella del proceso está en la obtención de los parámetros de extremo a extremo, que es una implementación provisoria. Cuando esté disponible la aplicación de medidas Metronet se espera que el tiempo insumido para la recolección de parámetros de performance se reduzca drásticamente, reduciéndose el tiempo total insumido en el descubrimiento de la topología virtual. Se presentaron los tiempos insumidos en el relevamiento de los LSPs para una topología en particular, observándose que el tiempo promedio del ciclo son 60 segundos para descubrir una topología con 20 LSPs. Este tiempo es adecuado para el funcionamiento de la herramienta completa como se verá más adelante, pero lamentablemente no se cuenta con información sobre los tiempos de otras herramientas para comparar y sacar más conclusiones. Por otro lado se explicaron las pruebas realizadas en cuanto a la obtención de parámetros de performance. Se validó la recolección de parámetros locales frente a la información en los enrutadores y las medidas de extremo a extremo frente los modelos teóricos, constatando que los valores obtenidos en ambos casos son coherentes y muy representativos de la relación entre capacidad y tráfico cursado por la red. Como conclusión fundamental se puede afirmar que el módulo de monitorización realiza satisfactoriamente todas sus funciones y además se comporta correctamente en situaciones anómalas Módulo Señalización Para la validación del módulo encargado de la señalización se realizaron tres pruebas básicas, cada una con el objetivo de validar una funcionalidad distinta de este módulo. Las funcionalidades a evaluar fueron: Alta de LSPs Camino explícito Tráfico asociado Ancho de banda Coeficiente de reparto de carga Prioridad de preempción Baja de LSPs Cambio de LSPs Tráfico asociado Ancho de banda reservado Coeficiente de reparto de carga Prioridad de preempción.

159 12.5. Módulo Señalización 139 Además se debió evaluar la conectividad con el resto de los módulos. Es decir, que funcionase bien la implementación del servidor que recibe pedidos de conexión y que fuese correcto el funcionamiento del protocolo GRMAP, y la interpretación del XML Alta de LSPs Para la prueba de configuración de caminos se creó un archivo XML y se hizo que el proceso de señalización se desencadenara a partir de la lectura de dicho archivo. La prueba permitió constatar primero la correcta interpretación del archivo XML y luego la correcta configuración de los equipos. Con este tipo de pruebas se pudo comprobar la correcta configuración de todos los parámetros en un LSP nuevo Baja y cambio de LSPs En el caso de la baja de LSPs, se creó un archivo en formato XML con la plantilla de baja de caminos y para el cambio, con la plantilla correspondiente. El correcto funcionamiento se constató nuevamente observando vía TELNET la configuración de los equipos involucrados Funcionamiento como servidor Una vez corroboradas las funcionalidades de este módulo se pasó a comprobar el correcto funcionamiento del mismo como servidor. Se señalizaron, cambiaron y dieron de baja túneles desde la interfaz de gestión observando que el comportamiento fue satisfactorio en todos los casos. Otro resultado importante fue que se pudieron validar las mejoras introducidas respecto a la herramienta IPEMSCOMM original, que se explicaron en el capítulo 8. Se comprobó que cuando se señaliza un nuevo LSP en un LER, no se re-señalizan todos los otros LSPs existentes en el nodo como sucedía en la herramienta original Conclusiones Como conclusión se destaca que la totalidad de las funcionalidades de este módulo fueron probadas, demostrando un correcto funcionamiento en todos los casos. Además, como ocurrió en las pruebas de otros módulos, las mismas permitieron ir más allá de la prueba aislada del módulo e incluir pruebas integrales o parcialmente integrales de la herramienta. La secuencia con que se implementaron los módulos fue fundamental. El ya tener implementada la interconexión entre la interfaz de gestión y el módulo de señalización permitió probar sus funcionalidades exhaustivamente. A su vez, se pudo verificar que los LSPs se señalizaban correctamente dado que eran descubiertos por el módulo de monitorización y se visualizaban luego gráficamente en la interfaz de

160 140 Capítulo 12. Validación gestión. Con respecto a los tiempos involucrados en las operaciones de señalización, se puede decir que éstos son prácticamente despreciables en las pruebas realizadas. El único tiempo involucrado es el de la transferencia del archivo de configuración que es muy veloz. Si bien puede argumentarse que este tiempo aumentará en caso de que crezca el archivo de configuración, será de todas maneras inferior a los tiempos manejados por los otros módulos de la arquitectura. Se comprobaron las ventajas de los cambios introducidos respecto a la herramienta original. Sin estas mejoras hubiera sido prácticamente imposible utilizar TRAPS de SNMP, ya que cada nuevo LSP señalizado hubiese desencadenado la generación de muchos TRAPS, correspondientes a la re-señalización de los demás LSPs originados en el LER, lo que hubiera confundido a la herramienta Módulo TE El objetivo de esta sección es validar la implementación del bloque de TE desarrollado. Esto implica mostrar que la componente de detección reacciona ante una situación de desbalance y que la componente de acción realiza los pasos necesarios para revertir dicha situación convergiendo a una solución estable. Con respecto a la componente de detección alcanzó con realizar pruebas y observar el comportamiento de la herramienta. Para el caso de la componente de acción, previo a la realización de pruebas y observación de resultados se debió verificar que el escenario real en que se desempeña el algoritmo cumple con las hipótesis del mismo. En la figura 12.5 se puede ver una representación esquemática de la prueba tipo realizada. La misma se hizo de manera reiterada para constatar, además de la robustez, la repetición del punto de convergencia. Con la misma topología se hizo previamente la verificación de las hipótesis del algoritmo MATE. A continuación se presentan los resultados obtenidos en la verificación de las hipótesis y luego los de las pruebas realizadas.

161 12.6. Módulo TE 141 Figura 12.5: Prueba tipo realizada en la maqueta.

162 142 Capítulo 12. Validación Verificación de hipótesis Para validar el funcionamiento del algoritmo se realizó una etapa previa de verificación de sus hipótesis y búsqueda manual del óptimo. Se comprobó que la función retardo en función de la carga de los LSPs de la topología de la figura 12.5 es convexa. Para esto se relevó el retardo experimentado por paquetes de prueba con distinta carga de tráfico por el LSP. Se utilizó tráfico con una distribución Poisson variando la media del intervalo entre paquetes. Para cada carga se midió el retardo utilizando el comando MPLS PING con tamaños de paquete de 1000 y 100 bytes, como se muestra en la figura 12.6.

163 12.6. Módulo TE Curva delay=f(carga) LSP 1 Paquetes de prueba 1000bytes Paquetes de prueba 100bytes Delay(ms) Carga(Mbps) (a) LSP Curva delay=f(carga) LSP 2 Paquetes de prueba 1000bytes Paquetes de prueba 100bytes Delay(ms) Carga(Mbps) (b) LSP2 Figura 12.6: Relevamiento curva de Retardo en función de la carga.

164 144 Capítulo 12. Validación Utilizando el relevamiento de las curvas de retardo se estimó para qué reparto de carga se minimiza el retardo total, en la topología dada, cuando se quiere cursar un tráfico de 1.5Mbps. Se obtuvo como resultado 66% del tráfico por el LSP2, como muestra la figura Delay Total=f(%carga LSP 2) Delay(ms) % carga LSP2(Mbps) Figura 12.7: Búsqueda del reparto de carga óptimo Pruebas realizadas Para validar el funcionamiento de este módulo se realizó un mismo tipo de prueba reiteradas veces. La prueba consiste en establecer dos LSPs con mismo origen O y mismo destino D pero distintos saltos intermedios; generar tráfico, de ancho de banda medio conocido, entre O y D; configurar el coeficiente de reparto de carga de cada LSP de manera de que queden desbalanceados y poner en funcionamiento la herramienta completa. El coeficiente de reparto de carga se fija teniendo en cuenta la capacidad de los enlaces que componen cada LSP y el ancho de banda del tráfico total a cursar, buscando así que queden con un cierto desbalance. Este desbalance no pretende ser demasiado significativo, ya que en la práctica el objetivo de la herramienta será corregir pequeñas desviaciones del óptimo y no la búsqueda del mismo a partir de una situación totalmente inversa. Por ejemplo, para el caso de un óptimo en porcentajes se considera razonable partir de una situación con o 40-60, teniendo en cuenta por supuesto la relación entre la carga total y la capacidad de cada uno de los enlaces para no saturarlos. Igualmente se hicieron pruebas partiendo de situaciones inversas para observar el comportamiento de la herramienta en esos casos.

165 12.6. Módulo TE 145 Una vez puesta en marcha la herramienta completa se observa si la componente del módulo de detección reacciona habiendo introducido tráfico en la red y no habiéndolo hecho. Constatado el correcto funcionamiento de la componente de detección se pasa a repetir la prueba y observar el comportamiento de la componente de acción. Para el caso de MATE se hicieron repetidas pruebas de las relatadas anteriormente y se guardó registro de distintos datos en cada iteración del algoritmo. Se constató que el algoritmo converge. Los datos registrados en cada iteración de cada corrida fueron: Estampa de tiempo del comienzo y fin de cada iteración Retardo Derivada del retardo Coeficiente de reparto de carga Norma de la diferencia entre el resultado actual y el de la iteración anterior Valor del paso de iteración La figura 12.5 muestra la implementación de la prueba tipo descrita anteriormente, que se llevó a cabo en la maqueta disponible. El tráfico en la red se generó con la herramienta descrita en el apéndice B.1 y consistió en 1.5Mbps de tráfico Poisson. Para lograr el efecto de congestión en la red se configuraron los PVCs de las interfaces de ATM que atraviesa el LSP 2 con un valor de 1.5Mbps UBR (Unspecified Bit Rate) y las que atraviesa el LSP 1 con 1Mbps UBR. De esta manera la red se comporta como si tuviera la capacidad indicada en la figura Resultados del algoritmo MATE Como se mencionó anteriormente se repitieron las pruebas varias veces registrando los valores obtenidos. Se analizó la repetición del punto de convergencia para 20 corridas del algoritmo obteniendo la distribución mostrada en la figura Es importante mencionar que el punto de convergencia mostrado en el histograma 12.8 coincide con el óptimo relevado manualmente que se muestra en la figura En promedio la convergencia del algoritmo se produjo en entre 3 y 5 iteraciones, lo que significa un tiempo promedio de 10 minutos para el balanceo entre 2 túneles. La mayor parte de este tiempo corresponde a la realización de medidas de extremo a extremo. Se realizan medidas para todos los LSPs y además, como se mencionó anteriormente, la herramienta actual que las realiza es el cuello de botella del proceso de monitorización. Por lo tanto se concluye que cuando se disponga de una herramienta de medidas como Metronet, este tiempo se reducirá sensiblemente.

166 146 Capítulo 12. Validación Histograma de pruebas del algoritmo MATE LSP 1 LSP % muestras coef. de reparto de carga Figura 12.8: Histograma. Puntos de Convergencia algoritmo MATE. Como prueba adicional se partió de situaciones con un fuerte desbalance en el reparto de carga, con más tráfico hacia el LSP de menor ancho de banda. Para estas pruebas se decidió utilizar un tráfico de entrada menor, debido a que con el tráfico de 1.5Mbps se hubieran saturado los enlaces completamente si se volcaba la mayor parte del tráfico al LSP de menor capacidad. El resultado, como puede verse en la figura 12.9(a), también fue la convergencia del algoritmo. El punto óptimo fue distinto al mostrado en la figura 12.8 debido a que se cambió el tráfico cursado. En la figura 12.9 se muestra cómo efectivamente el algoritmo logra disminuir el retardo.

167 12.6. Módulo TE Iteraciones de una corrida del algoritmo MATE LSP 1 LSP % balance de carga n iteracion (a) Reparto de carga Evolucion del retardo de una corrida del algoritmo MATE LSP 1 LSP 2 total Delay (ms) n iteracion (b) Retardos Figura 12.9: Reparto de carga y retardos a lo largo de la actuación del algoritmo.

168 148 Capítulo 12. Validación Conclusiones Las pruebas del algoritmo realizadas mostraron que la implementación funciona correctamente. No sólo se detecta automáticamente la congestión, sino que también se toman medidas correctivas acertadas. Además se mostró que el punto de convergencia se repite incluso cuando las medidas realizadas no son las mejores, debido a que no se cuenta con la herramienta de medidas adecuada. Este hecho demuestra la robustez del algoritmo. Si bien hubiera sido interesante comparar el desempeño de la solución implementada con los del algoritmo MATE presentados en [37], esto no tiene sentido ya que los resultados presentados en dicho trabajo corresponden a simulaciones y no a pruebas en una red real. No es razonable comparar por ejemplo el tiempo de ejecución ya que el cuello de botella de la implementación realizada está en la monitorización de la red y el tiempo de actualización del reparto de carga por parte de los enrutadores (explicado en el capítulo 7), que no son tenidos en cuenta en las simulaciones. El módulo TE tiene una importancia alta en la herramienta y es por el hecho de que aplica las reglas de control relacionadas con la Ingeniería de Tráfico en línea. Sin embargo, su implementación no tiene sentido si no se cuenta con una implementación de los demás módulos correcta y precisa. Necesita conocer fehacientemente la topología física y virtual y los parámetros de desempeño, además de poder reflejar los cambios que indique la salida del algoritmo en la red. Esta característica se tuvo en cuenta desde el planteo de los objetivos del proyecto hasta la ejecución de las tareas, buscando siempre contar con los otros módulos funcionando correctamente antes de profundizar en la implementación de éste. De esta manera los resultados obtenidos en las pruebas presentadas en esta sección permiten concluir, no sólo que el módulo en cuestión cumple satisfactoriamente con los objetivos, sino también que la solución implementada funciona correctamente como herramienta completa de Ingeniería de Tráfico en línea. Teniendo en cuenta que la implementación de este módulo no era el objetivo principal del proyecto, se concluye que este resultado es sobresaliente.

169 Capítulo 13 Conclusiones y trabajo a futuro La conclusión de carácter fundamental es que se cumplieron satisfactoriamente los objetivos planteados al inicio del proyecto. En primer lugar se puede afirmar que se desarrolló exitosamente una herramienta completa de Ingeniería de Tráfico en línea para redes MPLS. Ésta realiza de manera automática todas las etapas del proceso, incluyendo el descubrimiento de la topología física y virtual, la recolección de parámetros de performance, un algoritmo de detección de congestión, otro de corrección y la reconfiguración de la red de acuerdo al resultado del mismo. En segundo lugar, por ser MPLS una tecnología aún en etapa de desarrollo en cuanto a gestión, se considera que el estudio del estado del arte realizado agrega valor al proyecto. Dicho estudio permitió adquirir los conocimientos necesarios para llevar a cabo la tarea, además de haber sido muy útil a la hora de comparar, durante la etapa de validación, los resultados obtenidos con los de otros proyectos similares. A su vez, este estudio podrá ser utilizado por futuros proyectos como base para saber qué estándares de gestión están implementados a la fecha y cuáles aún restan implementar por los fabricantes. Otro aporte importante constituye el haber previsto, tanto en el diseño como en la implementación de cada módulo, la expansión de la herramienta y la evolución a largo plazo. Como ejemplo puede considerarse la información recolectada en cuanto a parámetros de desempeño. La misma no se limita a la información necesaria para el algoritmo que se encuentra implementado actualmente, sino que se buscó obtener una cantidad suficiente para representar íntegramente la performance de la red. Esto significó a su vez, que durante el proceso final de selección del algoritmo no se tuviera como limitante los parámetros de entrada del mismo. Por este hecho se considera altamente probable que tampoco se presente esa limitante a la hora de realizar nuevas implementaciones del módulo de Ingeniería de Tráfico. A su vez, la arquitectura elegida permite comparar implementaciones distintas de cada módulo de manera transparente a las otras componentes de la herramienta. Esta característica facilita, y por lo tanto promueve, un aspecto que consideramos fundamental en cualquier proyecto de este tipo: el trabajo a futuro. 149

170 150 Capítulo 13. Conclusiones y trabajo a futuro Dentro de los logros obtenidos se destaca también la muy buena coordinación e integración del presente con otros proyectos dentro de la Facultad. Esto permitió potenciar, no sólo las herramientas propias, sino también las que proporcionaron otros grupos ya que se introdujeron considerables mejoras en las mismas. Se integraron y adaptaron los resultados de cuatro proyectos distintos para lograr una herramienta que incluye, además de los módulos que componen la solución principal, una interfaz gráfica de gestión que contiene herramientas de Multicast e Ingeniería de Tráfico fuera de línea. Paralelamente se compiló una MIB con formato estándar que permitirá la interconexión con herramientas que realicen medidas de extremo a extremo. Esta MIB tiene como objetivo principal la interconexión con Metronet, pero abarca todos los puntos necesarios para la interconexión con cualquier herramienta de este tipo. A su vez el hecho de ser abierta y haber sido diseñada basándose en la estructura de las MIBs estándar, facilitará la implementación de la misma por terceras partes, punto fundamental para que la integración pueda hacerse efectiva. El sistema fue exitosamente implementado y probado en una red real. Se trabajó en la validación de la herramienta completa y la dinámica de los procesos, pudiéndose concluir que la herramienta funciona de acuerdo a lo esperado, detectando y corrigiendo automáticamente la congestión. Además se concluye que el trabajo constituye un auspicioso paso en la integración de las distintas herramientas que atacan problemas particulares dentro del problema integral que es la Ingeniería de Tráfico en redes de Telecomunicaciones. Cabe destacar que el tema en cuestión es muy amplio y, como se vio en el capítulo de validación, los resultados no cuentan aún con información que permita determinar si la implementación es escalable a redes con topologías más grandes y complicadas que la de pruebas. No obstante, se considera que esto no altera el cumplimiento de los objetivos planteados para el proyecto, sino que encamina el trabajo a futuro en ese sentido. Como lineamiento general, también se considera importante plantear la implementación de nuevos algoritmos para incluir en el módulo de TE. De esta manera se podrán abarcar otros aspectos de la Ingeniería de Tráfico en línea, entre los cuales se consideran destacables los de detección de problemas, incluyendo el aprendizaje estadístico, los de optimización del ancho de banda utilizado y los de mínima interferencia. Se destaca como conclusión final la experiencia adquirida a lo largo del desarrollo del proyecto, durante el cual se estudió y trabajó en una amplia gama de disciplinas relacionadas con la profesión. Se logró una buena conjugación entre estudio académico, implementación y práctica de trabajo con las tecnologías actuales. Se resalta también la importancia de haber realizado un Plan de Proyecto y conocido la metodología de gestión. Esta metodología no se aprende en otros cursos de la facultad y fue fundamental para lograr un resultado exitoso y en fecha.

171 Bibliografía [1] Multiprotocol Label Switching (MPLS) Management Overview. RFC Internet Engineering Task Force. [2] Framework for IP Performance Metrics. RFC Internet Engineering Task Force. [3] Requirements for Traffic Engineering Over MPLS. RFC Internet Engineering Task Force. [4] Overview and Principles of Internet Traffic Engineering. RFC Internet Engineering Task Force. [5] Multiprotocol Label Switching Architecture. RFC Internet Engineering Task Force. [6] Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB). RFC Internet Engineering Task Force. [7] Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB). RFC Internet Engineering Task Force. [8] Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB). RFC Internet Engineering Task Force. [9] RSVP-TE: Extensions to RSVP for LSP Tunnels. RFC Internet Engineering Task Force. [10] LDP: Label Distribution Protocol Specification. RFC Internet Engineering Task Force. [11] CR-LDP: Constraint-Based LSP Setup using LDP. RFC Internet Engineering Task Force. [12] Management Information Base for Network Management of TCP/IPbased internets: MIB-II. RFC Internet Engineering Task Force. 151

172 152 BIBLIOGRAFÍA [13] OSPF Version 2 Management Information Base. RFC Internet Engineering Task Force. [14] Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. RFC Internet Engineering Task Force. [15] The COPS (Common Open Policy Service) Protocol. RFC Internet Engineering Task Force. [16] An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. RFC Internet Engineering Task Force. [17] Integrated Services Management Information Base using SMIv2. RFC Internet Engineering Task Force. [18] Traffic Engineering with MPLS. Eric Osborne y Ajay Simha. Cisco Press. 17/07/2002. ISBN: [19] Applying UML and Patterns. Craig Larman. Prentice Hall. 30/10/1997. ISBN: [20] Network Management, MIBs and MPLS: Principles, Design and Implementation. Stephen B. Morris. Prentice Hall. 20/06/2003. ISBN: [21] MPLS Network Management: MIBs, Tools, and Techniques. Thomas D. Nadeau. Morgan Kaufmann. 19/12/2002. ISBN: [22] SEQUIN: An SNMP-Based MPLS Network Monitoring System. Marina K. Thottan, George K. Swanson, Michael Cantone, Tin Kam Ho, Jennifer Ren y Sanjoy Paul. Lucent Technologies Inc, [23] Using Real-Time Measurements in Support of Real-Time Network Management. James L. Alberi, Ta Chen, Sumit Khurana, Allen Mcintosh, Marc Pucci and Ravichander Vaidyanathan. PAM2001: A workshop on Passive and Active Measurements, [24] RATES: A Server for MPLS Traffic Engineering. IEEE Network Magazine, pp , Marzo/Abril [25] MIRA: Minimum Interference Routing of Bandwidth Guaranteed Tunnels with MPLS Traffic Engineering Applications. Koushik Kar Murali Kodialam T. V. Lakshman. ECE Department University of Maryland, Bell Labs Lucent Technologies. Diciembre 2000.

173 BIBLIOGRAFÍA 153 [26] LMIR: Ligth Minimum Interference Routing Algorithm. Gustavo B. Figueiredo, Nelson L. S. da Fonseca, Jose A. S. Monteiro. Institute of Computing, State University of Campinas, Brazil - NUPERC, Salvador University, Brazil. 14/07/05 [27] RNLC: Residual Network and Link Capacity Weighting for Efficient Traffic Engineering in MPLS Networks. K. Hendling, G. Franzi, B. Statovci-Halimi and A. Halimi. Proceedings of ITC, 2003, pp [28] DYLBA: Dynamic Load Balancing Algorithm. Roberto Battiti, Elio Salvadori. Università di Trento, Dipartimento di Informatica e Telecomunicazioni. 11/2002 [29] OPIATE: Optimization Integrated Adaptive Traffic Engineering. Kaushik Sinha and Stephen D. Patek, Department of Systems and Information Engineering, University of Virginia. Noviembre [30] Cooperation of Control and Management Plane for the Dynamic Provisioning of Connectivity Services on MPLS Networks. Eduardo Grampin Castro. A thesis submitted for the degree of Doctor per la Universitat Politécnica de Catalunya. [31] Ingeniería de Tráfico en Línea en Redes MPLS Aplicando la Teoría de Grandes Desviaciones. Pablo Belzarena. Tesis de Maestría en Ingeniería Eléctrica, IIE, [32] Totem project: TOolbox for Traffic Engineering Methods. totem.info.ucl.ac.be. Última visita: 9/2007. [33] Cisco 7200 Series Router MIB Specifications Guide. ftp://ftp-sj.cisco.com/pub/mibs/supportlists/c7200/ c7200-supportlist.html products/hw/routers/ps341/products technical reference chapter09186a db9.html. Última visita a ambas páginas: 9/2007. [34] Metronet: Software para medición de calidad de servicio en voz y video. Pablo Belzarena, Víctor González Barbone, Federico Larroca, Pedro Casas. CITA [35] An OSPF Topology Server: Design and Evaluation. Aman Shaikh, Mukul Goyal, Albert Greenberg, Raju Rajan, K.K. Ramakrishnan. IEEE Journal on Selected Areas in Communications, 05/2002. [36] Data Networks. Dimitri P. Bertsekas y Gallager. Longman Higher Education, ISBN:

174 154 BIBLIOGRAFÍA [37] MATE: Multipath Adaptive Traffic Engineering. Anwar Elwalid, Cheng Jin, Steven Low y Indra Widjaja. Computer Networks, Vol. 40, No. 6, 2002, pp [38] Analysis and improvements to MATE algorithm. Miguel Griot, Gabriel Tucci, Pablo Belzarena y Santiago Remersaro. 23rd IEEE International Performance, Computing and Communications Conference, Phoenix, Arizona, page /2004. [39] Walking the Tightrope: Responsive Yet Stable Traffic Engineering [PS] Srikanth Kandula, Dina Katabi, Bruce Davie y Anna Charny ACM SIGCOMM, Aug 2005, Philadelphia. [40] Measurement Based Optimal Multi-path Routing. Guven, T. Kommareddy, C. La, R.J. Shayman, M.A. Bhattacharjee, B. University of Maryland. INFOCOM 2004, 03/2004. [41] Aprovisionamiento de Conectividad en redes MPLS: Interfaz de Control. Alberto Castro y Martín Germán. Documentación de Proyecto de Grado, [42] Path Computation Element Working Group, html.charters/pce-charter.html. Última visita: 9/2007. [43] Path Computation Element (PCE) communication Protocol (PCEP), JP. Vasseur, JL. Le Roux. internet-drafts/draft-ietf-pce-pcep-08.txt. Última visita: 9/2007. [44] Grupo de investigación MINA del Instituto de Computación, Facultad de Ingeniería, Universidad de la República, edu.uy/inco/grupos/mina/. Última visita: 9/2007. [45] Ingeniería de Tráfico en Redes MPLS. Adrián Delfino, Sebastián Rivero, Marcelo San Martín. Proyecto Final de Carrera, 08/2005. [46] Ingeniería de tráfico para tráfico multicast con MPLS. A. Lombide, I. Hernández, J. Sanguinetti. Proyecto Final de Carrera, 12/2006.

175 Apéndice A MIBs A.1. MIBs Utilizadas En esta sección se presentan las MIBs consultadas por los distintos módulos de la aplicación implementada. MIBs de MPLS MPLS-TE-MIB. Se consulta la información de los túneles originados en el nodo. En particular se obtiene la lista de saltos, las reservas de recursos y los punteros para consultar la MPLS-LSR-MIB. Está definida en [6]. MPLS-LSR-MIB. Se consultan los contadores de paquetes de los túneles utilizando los punteros obtenidos de la MPLS-TE-MIB para todos los saltos menos el primero. Está definida en [7]. MIB-II OSPF-MIB. Se consulta la tabla de vecinos de OSPF de cada nodo para descubrir la topología física. Además se obtiene el identificador de los enrutadores (RouterId). Está definida en [13]. INTEGRATED-SERVICES-MIB. Se consulta la información del ancho de banda máximo reservable de RSVP por flujo y por interfaz. Está definida en [17]. RFC Se consultan las direcciones IP de las interfaces físicas de cada nodo, sus anchos de banda nominales y los contadores de paquetes cursados y descartados. Además se obtienen los contadores de paquetes para el primer salto de los LSPs. Está definida en [12]. 155

176 156 Apéndice A. MIBs Otras MIBs CISCO-PROCESS-MIB. Se consulta el uso de CPU de los enrutadores. Es una MIB propietaria del fabricante CISCO. CISCO-RTTMON-MIB. Se implementó un módulo que la utiliza para configurar y obtener los resultados de experimentos de extremo a extremo. En la implementación final del proyecto este módulo no se utiliza para dichas medidas. Es una MIB propietaria del fabricante CISCO. A.2. MIB para la comunicación con Metronet En esta sección se presenta una propuesta de MIB para la comunicación con la aplicación de medidas Metronet. Como se explicó en el capítulo 6, un fuerte supuesto del presente proyecto era contar con una aplicación que realizara medidas de extremo a extremo en la red. Se acordó con los clientes/tutores que la aplicación a utilizar sería Metronet y que la comunicación se realizaría mediante el protocolo SNMP. Los experimentos previstos son para medir retardo y su variación con la carga, jitter y throughput. (a) Metronet MIB General (b) Metronet MIB Control Figura A.1: Metronet MIB I La MIB propuesta consta básicamente de una parte de control de experimentos y otra de presentación de resultados. Para el control de experimentos, se utiliza una tabla donde se especifica el tipo de experimento, los parámetros relacionados al mismo e información de cuándo y con qué frecuencia debe realizarse. Debido a que el cliente de la aplicación de medidas debe especificar qué experimento debe realizarse, los permisos de esta tabla son de lectura y escritura.

177 A.2. MIB para la comunicación con Metronet 157 En la parte de presentación de resultados se utilizan dos tipos de tablas. Por un lado están las tablas que contienen la última información de cada tipo de experimento y por otro tablas que presentan el historial de experimentos. (a) Delay Actual (b) Jitter Histórico Figura A.2: Metronet MIB II

178

179 Apéndice B Red de Pruebas B.1. Red de pruebas La red de pruebas utilizada durante el desarrollo del proyecto fue la implantada durante la ejecución del PDT 17/03. La misma puede verse en la figura B Mbps 33Mbps GbE Tx/Rx de trafico RMS / /24 Tx/Rx de trafico RMS /24 PECV1 PEAGU1 Red de Gestión / / / PECEN1 PECORD /24.2 Tx/Rx de trafico RMS / Video Server / /24 PEFING / / /30 Tx/Rx de trafico RMS /30 CEIBO Testbed INCO /16 Testbed IIE /16 Servidor MetroNet Figura B.1: Maqueta utilizada para las pruebas. La red consiste en 5 enrutadores Cisco 7200, 4 ubicados en los sitios Centro, Cordón, Aguada y Ciudad Vieja de ANTEL, y 1 en Facultad de Ingeniería. Los cuatro enrutadores que se encuentran en los sitios de ANTEL forman una malla con conectividad ATM STM-1 (155 Mbps). Las conexiones con el nodo de la Facultad son a través de los nodos PECEN1 y PECORD1 mediante enlaces de 33 Mbps. 159

180 160 Apéndice B. Red de Pruebas Estos enrutadores soportan MPLS y DiffServ, en particular permiten establecer TE-LSPs (túneles con extensiones de Ingeniería de Tráfico). La red también tiene integrados dos equipos Linux con core MPLS. Los mismos si bien forman parte de la red de pruebas no son tenidos en cuenta por este proyecto debido a la no implementación de túneles MPLS ni de algunas MIBs necesarias de SNMP. Todas las ejecuciones del software desarrollado se hicieron en el equipo CEIBO mostrado en la figura B.1. El mismo tiene las siguientes características: Linux Fedora Core 2 - Versión de kernel _fc2mpls_1_946 Memoria RAM 1GB JAVA 1.5.0_12_v04 Generadores de tráfico La red cuenta con una serie de generadores y receptores de tráfico distribuidos en distintas posiciones como se observa en la figura B.1. Los mismos son PCs equipados con el sistema operativo LINUX y los softwares de generación y recepción de tráfico: JTG Jugi s Traffic Generator Poisson Traffic Generator Se utilizó el JTG para tráfico constante y el PTG para tráfico variable. Ambos softwares permiten generar tráfico con diferentes anchos de banda y características estadísticas. Para su funcionamiento requiere que haya un equipo en el destino con el mismo software corriendo, debiéndose configurar en modo receptor. Dadas las características de los equipos donde los generadores y receptores de tráfico están instalados, la capacidad máxima de tráfico que se puede generar es 100Mbps. Se estudiaron distintas formas de saturar los enlaces de la red, tarea complicada debido a que los enlaces entre los enrutadores son STM-1(155Mbps). Debido a que estos enlaces son de la tecnología ATM que soporta shaping de acuerdo a descriptores de tráfico especificados, se decidió utilizar esta solución para simular enlaces de capacidad inferior.

181 Apéndice C Aspectos de gestión del proyecto Previo al comienzo del presente proyecto se elaboró un Plan de Proyecto, aprobado por los clientes/tutores, donde se establecían objetivos, alcance, cronograma y criterios de éxito. Se realizaron revisiones del mismo en los meses de Febrero y Julio de 2007 para las presentaciones de avance. Durante las mismas, el documento no sufrió modificaciones debido a que se esperaba poder cumplir con lo planificado, a pesar de los pequeños atrasos constatados en las fechas mencionadas. Como observación general se puede decir que el Plan de Proyecto se siguió fielmente y prácticamente no hubo desvíos. A continuación se muestra el documento original y la confrontación con la ejecución del mismo. C.1. Plan de Proyecto Descripción general La idea general del proyecto es estudiar Ingeniería de Tráfico en línea en una red que funciona bajo el protocolo MPLS y generar una herramienta de software capaz de reconfigurar el mapeo de dicho tráfico en caso de detectar problemas. Para lograr este objetivo la herramienta deberá, por un lado ser capaz de recolectar la topología y estado de la red, pero también procesar los datos mediante algoritmos rápidos y estables debido a los requerimientos de procesamiento en línea. Se realizarán pruebas de esta herramienta en la Red Piloto Metropolitana Multiservicio, proyecto conjunto de ANTEL y Facultad de Ingeniería. El proyecto deberá contemplar: Estudio de cómo recolectar la información de la red y cómo transmitir los cambios de configuración. Estudio de las diferentes alternativas en cuanto a algoritmos de Ingeniería de Tráfico en línea. Elaboración del software. 161

182 162 Apéndice C. Aspectos de gestión del proyecto Para el primer punto, se deberá recolectar la topología física y virtual y el estado de la red, principalmente consultando vía SNMP los distintos enrutadores de la red. La topología física se obtendrá en principio a partir de las MIBs (Management Information Base) de OSPF. Se tomará como punto de partida otro proyecto de fin de carrera llamado NET-TE que trabaja sobre estos aspectos. Para conocer la topología virtual, se consultarán las MIBs de OSPF-TE y MPLS. Finalmente se evaluará qué tipo de medidas se realizarán para conocer el estado de la red. Se estudiarán medidas activas (Software METRONET ), como la inyección de muestras de tráfico combinada con herramientas estadísticas, o pasivas como pueden ser contadores consultados vía SNMP. Para transmitir los cambios de configuración se usará el protocolo RSVP-TE y eventualmente la configuración manual mediante SNMP. Se estudiarán algoritmos que, a partir de la información recolectada, decidan re-mapear el tráfico en caso de detectar problemas como congestión. Al ser una herramienta que trabaja en línea, se deberá hacer especial énfasis tanto en la velocidad como en la estabilidad de estos algoritmos. En principio no se fijarán objetivos en cuanto a la complejidad de los algoritmos a implementar, sino que estos serán definidos sobre la marcha del proyecto. Finalmente se elaborará un software que implementará las tareas ya mencionadas. Se deberá tener en cuenta que la herramienta será inicialmente destinada para usarse en la Red Metropolitana Multiservicio, que funciona con tecnología Cisco y que puede tener algunas diferencias con los estándares de MPLS. Por lo tanto se deberán separar cuidadosamente en la implementación del software los módulos generales de los particulares que se usen para trabajar con este fabricante. De esta manera se podrá adaptar fácilmente en un futuro la herramienta para trabajar con otros equipos de otros fabricantes. En principio el software será escrito en lenguaje JAVA, aunque si la performance lo requiere algunas rutinas podrán ser escritas en C++. Objetivos El qué del proyecto Diseño e implementación de un software para Ingeniería de Tráfico en línea en una red MPLS. El para qué del proyecto Poder detectar situaciones de congestión en la red y tomar acciones para corregirlas.

183 C.1. Plan de Proyecto 163 Criterios de éxito: Una prueba de funcionamiento donde se constate la correcta obtención de la topología física y virtual. La prueba consistirá en realizar la obtención en una red con una topología conocida, verificar si es correcta, realizar un cambio en la topología y volver a realizar la obtención constatando que se haya detectado correctamente el cambio. Una segunda prueba consistente en generar tráfico de manera de tener escenarios de congestión y no congestión y verificar que se estiman correctamente los parámetros de performance de la red a partir de medidas colectadas a través de SNMP ( por ejemplo: retardos, ancho de banda utilizado, etc.) y de acuerdo con lo que fija la salida del algoritmo implementado, se reconfigura la red adecuadamente. Esto último quiere decir que es capaz de establecer un nuevo LSP y/o reenrutar parte del tráfico por otro LSP al que tenía asignado originalmente. Como se verá más adelante, la capacidad de generar dicho tráfico es complicada y es un supuesto que toma este proyecto. Una prueba que valide el funcionamiento del algoritmo implementado. El detalle de dicha prueba será definido una vez definido el algoritmo a implementar. En todos los casos se verificará que la aplicación cumpla con el requerimiento de trabajar en tiempo real. Prioridades: Es prioridad del cliente que la herramienta desarrollada resuelva los siguientes ítems: 1. Obtención de la topología física y virtual. 2. Obtención de los parámetros de performance de la red 3. Definición de un umbral que permita decidir, a partir de los datos obtenidos en 1 y 2, si se debe actuar sobre la configuración de la red. 4. Estudio e implementación de un algoritmo de Ingeniería de Tráfico en línea que determine los cambios a realizar. 5. Configuración de los distintos nodos de la red según los resultados del algoritmo. Se deberá poder integrar esta aplicación a las herramientas que actualmente utiliza el cliente y otras futuras que se puedan desarrollar(metronet, NET-TE). La aplicación deberá ser desarrollada en forma modular de manera de poder cumplir con el punto anterior y que sea sencillo adaptarla a otros fabricantes de equipos.

184 164 Apéndice C. Aspectos de gestión del proyecto Es importante destacar que no es una prioridad del cliente que el algoritmo implementado sea óptimo, sino que funcione bien y que permita que un futuro proyecto se centre en la implementación y estudio del mismo. Actores, Supuestos y Restricciones Actores: Cliente: IIE. Tutores: Pablo Belzarena, Gabriel Gómez. Dueño de los equipos de pruebas: ANTEL. Fabricante de equipos: CISCO. Integrantes del proyecto: Isabel Amigo, Bernardo Cabrera y Juan Schandy. Grupo RMA-Control: Alberto Castro, Martín Germán. Restricciones La disponibilidad de la red de pruebas depende de ANTEL. Esto deberá ser tenido en cuenta a la hora de realizar el cronograma de pruebas. Asimismo la topología es simple y no muy flexible por lo que restringe el escenario de pruebas. Dado que se trabajará con una tecnología cuyos estándares no están maduros, no todas las funcionalidades están igualmente implementadas por todos los fabricantes. Por lo tanto, en caso de tener que usar funcionalidades fuera de los estándares, se usarán las de CISCO. El proyecto deberá estar terminado antes del 30 de setiembre de Los recursos para la realización del proyecto son 560 horas de dedicación por parte de cada uno de los estudiantes, distribuidas en el plazo del proyecto. Supuestos La red de pruebas existente se mantendrá sin cambios sustanciales durante toda la realización del proyecto. Los parámetros de performance de la red de extremo a extremo estarán disponibles para consultar vía SNMP. La generación de tráfico para pruebas estará resuelta. Las funcionalidades que implementan los equipos Cisco de la red están correctamente documentadas y son accesibles.

185 C.1. Plan de Proyecto 165 Especificación funcional del proyecto y prediseño Debido a la gran similitud que existe entre este proyecto y el proyecto RMA- Control del INCO, se decidió adoptar una arquitectura común para ambos de manera de poder intercambiar los distintos módulos que conforman la solución. La arquitectura comprende la definición de los distintos módulos y sus funciones y los protocolos e interfaces para la comunicación entre ellos. Este enfoque permite no solo la interoperabilidad de los módulos sino también comparar el desempeño del sistema completo intercambiando los distintos módulos. A continuación se muestra un esquema de la arquitectura propuesta. Figura C.1: Arquitectura RMA. Topology Interface Este módulo se encarga de descubrir los routers y enlaces existentes en la red. Será implementado por ambos grupos de maneras distintas. El enfoque de este proyecto se basará en consultas SNMP a los distintos nodos de manera iterativa, mientras que el enfoque del grupo del INCO se basará en participar del ruteo y con la información recibida construir el grafo de la red. La salida de este bloque llenará la base de datos TED.

186 166 Apéndice C. Aspectos de gestión del proyecto Monitoring Interface Se encargará de monitorizar el estado de los distintos LSPs y enrutadores con el fin de obtener parámetros de estado y performance de la red. En este caso, ambos proyectos se basarán en una misma implementación. Esta implementación será desarrollada por este grupo y utilizará un enfoque basado en consultas a las MIBS de MPLS vía SNMP. Este módulo también almacenará la información recolectada en la TED. Signalling Interface La función principal de este módulo será modificar la configuración de la red de acuerdo a los resultados del algoritmo CBR. Por ejemplo, será el encargado de crear y modificar caminos. En principio será desarrollado por el grupo del INCO y se basará en utilizar RSVP-TE. Traffic Engineering Database (TED) Esta base de datos guardará toda la información del estado de la red. Será completada con los resultados de las interfaces de monitorización y de topología y será consultada por el módulo CBR y por la interfaz de gestión. Será definida e implementada por los dos grupos en conjunto. Además, no será accedida mediante lenguaje de consulta directamente sino que a través de interfaces. CBR Este módulo consistirá en un algoritmo que, en función de las solicitudes y el estado de la red, computará nuevos caminos o cambiará los existentes. En caso de congestión deberá tomar decisiones que permitan eliminarla. El grupo del INCO tomará una solución externa desarrollada por Pablo Gainza, mientras que éste grupo desarrollará su propio algoritmo que en principio no está definida su complejidad ni su alcance. Management Interface Se adaptará el software NET-TE para consultar la TED en vez de recolectar por sí solo la topología. De esta manera se aprovechará su interfaz gráfica para visualizar el estado de la red y sus algoritmos para el cálculo de rutas fuera de linea. Especificación de los Objetivos Específicos y principales entregables del proyecto Descomposición del proyecto El objetivo general del proyecto puede descomponerse en los siguientes objetivos específicos: Tener el descubrimiento de la topología resuelto Tener los parámetros de performance de la red Tener un algoritmo de TE en línea implementado

187 C.1. Plan de Proyecto 167 Re-configuración de los routers resuelta Tener documentado el proyecto Tener el software implementado en Java A su vez cada uno de los objetivos específicos puede descomponerse en entregable y para eso a continuación se presenta su WBS. Work Breakdown Structure Figura C.2: Topología. Figura C.3: Performance.

188 168 Apéndice C. Aspectos de gestión del proyecto Figura C.4: Algoritmo TE. Figura C.5: Reconfiguración. Figura C.6: Documentación.

189 C.1. Plan de Proyecto 169 Figura C.7: Implementación.

190 170 Apéndice C. Aspectos de gestión del proyecto Análisis de riesgos Identificación de riesgos El no cumplimiento de los supuestos es un riesgo del proyecto. Entre ellos se pueden destacar: 1. Cambios sustanciales en la tecnología de la red de pruebas. 2. No poder generar escenarios de congestión que permitan evaluar la performance del software. 3. Limitaciones de performance del software debido al lenguaje de programación. (JAVA) 4. Problemas de coordinación con el grupo RMA que lleven a alteraciones en el cronograma. 5. Problemas de coordinación con ANTEL para realizar las pruebas, que lleven a alteraciones en el cronograma. 6. Desaparición de la red de pruebas. Cuantificación de riesgos IMPACTO/PROBABILIDAD BAJA MODERADA ALTA BAJO 3 MEDIO 4 2 ALTO 5 EXTREMO 6 1 Tabla C.1: Cuantificación de riesgos. Planificación y control 1. Para minimizar el impacto de este riesgo se desarrollará el software de manera modular de forma de aislar todo aquello que sea dependiente del fabricante de los equipos de red. 2. En caso de no contar con una herramienta generadora de tráfico se crearán escenarios de pruebas mediante simulación. 3. Debido a la baja probabilidad de ocurrencia de este suceso no se prevé una acción correctiva para este riesgo. 4. Se intentará minimizar la probabilidad de ocurrencia de este riesgo mediante la coordinación, a priori, de una reunión quincenal con dicho grupo.

191 C.1. Plan de Proyecto Se prevé un buffer de tiempo de manera que dichas alteraciones no sean de tal impacto. Cronograma detallado del proyecto Cronograma Figura C.8: Diagrama de Gannt.