Interfase NML-EML par la gestión de redes IP, y MPLS.

Transcripción

1 Interfase NML-EML par la gestión de redes IP, y MPLS. Estudiaremos una interfaz NML-EML y las herramientas que utiliza para gestionar automáticamente redes MPLS utilizando un sistema de políticas. Lo novedoso (según sus autores) radica en que tanto la información sobre la red, como las políticas a utilizar se almacenan en una base de datos orientada a objetos (OODB). Introducción A medida que las redes IP se utilizan para brindar cada vez más servicios, donde aspectos tales como performance, confiabilidad, etc. son críticos, se hace necesario expandir las capacidades de la red y gestionar eficientemente los recursos disponibles. MPLS y DiffServ aumentan las capacidades de IP, gestionar automáticamente por medio de políticas permite un mejor aprovechamiento de los recursos y un aumento de la robustez de la red. Gestión Basada en Políticas La configuración manual de cada dispositivo específicamente es algo tedioso, complejo y propenso a errores. En general es posible encontrar una política general y simple que abarque a todas las configuraciones. Un administrador solo necesita configurar esas políticas y el software de gestión se encarga de configurar los elementos de la red de acorde a estas. Conceptos Generales de Políticas 1. Una política esta representada por un conjunto de reglas. 2. Cada regla consiste en una condición y una acción 3. La evaluación de la regla es disparada por un evento On <event(s)> if <condition> do <actions> - 1 -

2 Comunicación con los Elementos de la red (SNMP). En una red formada por dispositivos de distinta naturaleza, hechos por distintos fabricantes, es saludable que todos los elementos compartan un protocolo para intercambiar información sobre el estado de la red. En el RFC 1157 se define el SNMPv1. Este protocolo de capa de aplicación facilita el intercambio de información de gestión de la red. Existen cuatro comandos básicos que nos permiten monitorear y controlar a los dispositivos. Estos son: read, write, traps, traversal operations. Read: consulta información almacenada en el dispositivo Write: cambia el valor de variables almacenadas. Traps: este comando es utilizado por los elementos gestionados para dar alerta de algun suceso. Traversal Operations: Determina cuales variables son manejadas por el dispositivo. MIB Management Information Base La Management Information Base es una colección jerárquicamente organizada de información. Una MIB esta compuesta por objetos gestionados e identificada por un Object Identifier u OId. Una MIB es un objeto que representa una o más características del dispositivo gestionado. Un OId identifica a una única MIB. Por ejemplo la MIB rttmonlatestjitteropersense tiene un OId Los OId son asignados por distintas organizaciones, las mas cercanas a la raíz del árbol son la ITU y la CCIT

3 Representación de los datos en SNMP Para unificar el intercambio de datos y evitar incompatibilidades, SNMP utiliza un subconjunto del ASN.1 (abstract syntax notation versión one) ccitt (0) iso (1) iso-ccitt (2) standard (0) registration authority (1) memberbody (2) identifiedorganization (3) dod (6) internet (1) directory (1) mgmt (2) experimental (3) private (4) security(5) snmpv2 (6) mib2 (1) enterprise (1) cisco (9) temporary variables (3) DECnet (1) XNS (2) Apple Talk (3) Novell (3) VINES (4) Chassis (5) atinput (1) atlocal (2) atbcastin (3) atforward (4) Ilustración 1: Árbol jerárquico de MIB - 3 -

4 MPLS Multi Protocol Label Switching El aumento del ancho de banda, y de la popularidad de la Internet han hecho posible la creación de aplicaciones que demandan más especificaciones a la red. Estas aplicaciones son muy sensibles a ciertos parámetros de la comunicación tales como retardo, ancho de banda, jitter, etc. MPLS tiene una óptica orientada a conexión que permite otro panorama desde el punto de vista de la ingeniería de tráfico. Se puede priorizar el tráfico dependiendo de la aplicación, asegurar parámetros de calidad, gestionar las congestiones, etc. Las aplicaciones clásicas (correo, ftp, WWW, etc.) funcionan sin problema en una red de mejor esfuerzo, pero se necesita un mayor control sobre la red, de punta a punta para aplicaciones tales como voz y video sobre IP, transacciones de negocios, etc. Utilizando MPLS se evitan problemas de IP, y de los protocolos de ruteo como OSPF que solo toma las decisiones de ruteo salto a salto observando la dirección de destino, congestionando enlaces y subutilizando otros. La óptica de punta a punta de la red de MPLS, permite tomar decisiones de ruteo que utilicen todos los recursos de la red. Modelo de una red gestionada de telecomunicaciones (TMN) Una red gestionada de telecomunicaciones puede ser vista desde distintos niveles de abstracción. En un nivel muy alto, la gestión de la red significa tomar decisiones de negocios, poner metas, etc. En un nivel más bajo tenemos los servicios, que son el punto de contacto con los clientes, en el escalón siguiente: la red propiamente dicha, que le da soporte a los servicios, etc. Capa BML SML Involucrada en Bussines Management Layer: Planeamiento de alto nivel, decisiones ejecutivas, Negocios... Service Management Layer: Con la información obtenida de la NML gestiona los servicios con los clientes. Asegura la calidad de servicio, gestión de fallas, etc. NML Network Management Layer: Con la información que le brindad los elementos de la red, logra tener conocimiento de la misma en su totalidad. Se encarga de coordinar las actividades de los elementos y dar el soporte necesario a - 4 -

5 los servicios (SML). EML NEL Element Management Layer: Gestiona cada elemento de la red. Es responsable de la información que hay en esos elementos. Monitorea la actividad, los accesos, etc. Network Element Layer: Es una interfase para presentar los datos propietarios de un elemento de la red de una manera manejable por las capas superiores. El software que estamos estudiando implementa una interfaz entre la capa de red (NML) y la capa de los elementos (EML) Arquitectura de la interfase EML-NML El software consta de 4 componentes básicos: 1. IPNM Gateway. Adapta las capas superiores, implementando una interfaz IPNM. 2. Abstract MPLS Object Repository. Es una representación orientada a objetos de los elementos gestionados. (clase router, que tiene clases túneles, que contiene clases IP, etc.) 3. The Policy Engine. Procesa la información proveniente de la capa superior(vía IPNM) y aplica las políticas a los elementos de la red. 4. Device Agent. Se encarga de traducir los mensajes abstractos en operaciones reales en los elementos. El protocolo que utiliza es el SMNP

6 . Ilustración 2: Arquitectura de la interfase NMS-EMS El corazón del software es el repositorio de objetos, que permite almacenar los elementos de la red y las políticas. Cada elemento de la red tiene sus métodos propios y generales, es posible expandir dinámicamente las capacidades del programa agregando objetos al repositorio. Si un router nuevo es incorporado a la red, sabemos que un router especifico tiene todos los características comunes a los router, (como una tabla de ruteo) mas métodos y atributos específicos de ese router. Además como las políticas son también objetos, la utilidad del programa es extensible y el sistema no necesita tener conocimiento a priori sobre las políticas y el hardware. Si el router nuevo tiene un método especial CreateTunnel(), para utilizar esta característica del router solo necesitamos incorporar una política que bajo alguna condición invoque a este método

7 Ilustración 3: Objeto Tipo - 7 -

8 Métodos Implementados Están implementados algunos métodos para monitorear y medir aspectos relacionados con la Performance. Se utilizan las MIBs RTTMon (Round Trip Time Monitor) de Cisco y la Rmon (Remote Monitoring) estándar. getcurrentthroughput(string source, String tunnel_id): devuelve el troughput accediendo a la MIB locifoutbitssec que almacena un promedio ponderado del troughput en los últimos 5 minutos. getcurrentdelay(string source, String tunnel_id): calcula el delay promedio, calculándolo como la suma de la latencia en un sentido dividido la cantidad de paquetes que efectivamente llegaron. getcurrentjitter(string source, String tunnel_id): jitter promedio, se calcula sumando todos los RTT de los paquetes y dividiéndolo por el numero de paquetes que llegaron. getcurrentloss(string source, String tunnel_id): devuelve el porcentaje de pérdida, haciendo el cociente entre los paquetes perdidos y los paquetes enviados. PaquetesPerdidos Porcentaje de perdidas = 100 PaqueteseEnviados EnableThroughputThresholdAlarm: este método recibe como parámetro los umbrales para el througput y activa una alarma almacenada en la MIB RMon. Ilustración 4 Cuando alguno de estos umbrales es cruzado se activa la alarma que dispara un evento, por ejemplo enviar un trap para tomar acciones. disablethroughputthresholdalarm : desactiva la alarma anterior

9 Conclusiones Existe todo un mundo alrededor de los servicios de telecomunicaciones y la gestión de estos. La Internet estaba ausente de estos temas debido a su naturaleza de mejor esfuerzo, ahora que la infraestructura permite dar servicios que eran reservados para las redes sincrónicas, hay que construir el framework necesario para su desarrollo. En este documento se intento ver el enfoque de redes gestionadas y las herramientas que permiten su desarrollo, analizando en particular un software que implementaba una interfaz de gestión. El software en cuestión no estaba implementado al 100%, pero se pudo observar que la idea central de tener un repositorio orientado a objetos para los elementos de la red y las políticas es muy interesante. Esto permite extender dinámicamente la funcionalidad del software, aspecto muy importante dada la velocidad con que ocurren los cambios en este sector