Instituto Politécnico Nacional Centro de Investigación y Desarrollo de Tecnología Digital Maestría en Ciencias con Especialidad en Sistemas Digitales “Gestión de Desempeño de una Red ATM en Internet 2 utilizando la especificación MPLS” TESIS QUE PARA OBTENER EL GRADO DE: MAESTRO EN CIENCIAS P R E S E N T A: ING. GERARDO GARRIDO AGUILAR AGOSTO del 2003 Tijuana, B.C.México Tabla de Contenidos Resumen Abstract Capítulo 1. Introducción 1.1 Motivación de Esta Tesis 1 1.2. Objetivo General 2 1.3. Objetivos Particulares 2 1.4. Justificación 2 1.5 Estructura de la Memoria 3 Capítulo 2. Introducción Teórica del Modelo de Gestión de Redes de Telecomunicaciones 5 - 2.1 Introducción. Gestión de Redes 5 - 2.2 Funciones de Gestión de Redes 7 - 2.3 La Red de Gestión de las Telecomunicaciones (TMN) 9 o 2.3.1 Relación de un TMN a una red de telecomunicaciones 10 o 2.3.2 Campo del uso 11 o 2.3.3 Objetivos básicos para un TMN 12 o 2.3.4 Arquitectura funcional del modelo TMN 14 o 2.3.4.1 Componentes funcionales de TMN 15 2.3.4.2 Funcionalidad de la aplicación de la Gestión (MAF) 18 2.3.4.3 Sistemas de función de a gestión de TMN 19 2.3.4.4 Puntos de referencia de TMN 19 2.3.5. La Arquitectura Lógica por Capas (LLA) de TMN 23 2.3.5.1. Capas de la función de la gestión de abstracción 24 2.3.5.2. Capa de la gestión de elemento 25 2.3.5.3.Capa de Gestión de Red 25 2.3.5.4. Capa de Gestión de Servicio 26 2.3.5.5. Capa de Gestión de negocio 27 2.3.5.6. Principios de capas de información 28 2.3.5.7 Interacción funcional entre las capas de gestión 29 o 2.4. Arquitectura de la información de TMN 29 o 2.4.1 Principios 29 o 2.4.2. Modelo de la interacción 30 i o 2.4.3. Los modelos de gestión de información deTMN 31 o 2.4.4. Elementos de información de la gestión de TMN 31 o 2.4.5. Modelo de la información de un punto de referencia 32 o 2.4.6. Puntos de referencia 32 o 2.4.7. Arquitectura lógica por capas de TMN dentro de la arquitectura de la información de TMN o - 33 2.4.8. Arquitectura de la comprobación de TMN 2.5. Gestión de desempeño TMN 34 o 2.5.1. Introducción 34 o 2.5.2. Areas funcionales de TMN 35 o 2.5.3. Metas y Aspectos de gestión de desempeño 40 o 2.5.4 Caracterización de la red 40 o 2.5.5 Fijar objetivos de desempeño 41 o 2.5.6. Proceso de Gestión de desempeño 42 2.5.6.1. Monitoreo de desempeño. 43 2.5.6.2. Control de desempeño 43 2.5.7. Metodología 43 2.5.7.1. Consideraciones generales 45 2.5.7.2. Uso y estructura de la metodología 45 2.5.7.3. Metodología detallada 45 2.5.7.4. Requisitos 45 2.5.7.5. Análisis 46 2.5.7.6. Diseño 47 2.5.7.7. Especificaciones de interfaz de TMN 48 2.5.7.8 Metodología de especificación de servicios 49 Capítulo 3. Tecnologías de Redes Distribuidas de Banda Ancha ATM / MPLS - - - 34 3.1 Introducción 51 51 o 3.1.1 Internet 2 52 o 3.1.2 Surgimiento de Internet 2 52 o 3.1.3. Tecnologías de Internet 2 53 3.2 Integración ATM y MPLS 56 o 3.2.1 Introducción 56 o 3.2.2 Desarrollo de IP sobre ATM 57 o 3.2.3 Análisis de IP sobre ATM 57 o 3.2.4. Convergencia en Conmutación IP y MPLS 60 3.3 MPLS 62 ii o 3.3.1 Componentes MPLS 62 o 3.3.2 Enrutamiento y Conmutación 63 o 3.3.4 Descripción funcional del MPLS 65 o 3.3.5. Mecanismos de señalización 70 o 3.3.6 Protocolos para Distribución de Etiquetas 71 o 3.3.7. Ingeniería de tráfico para MPLS 74 o 3.3.8. Clases de servicio (CoS) 76 o 3.3.9 Integración de MPLS y ATM 76 o 3.3.10 Elementos MPLS en una red ATM WAN 77 o 3.3.11. Arquitectura de Redes MPLS 78 o 3.3.12 MPLS basada en paquetes 79 o 3.3.14 ATM MPLS 80 o 3.3.15 Mezcla de ATM MPLS y MPLS de paquetes 80 o 3.3.16 ATM MPLS con dispositivos IP+ATM 80 o 3.3.17 Escenarios de Migración 81 o 3.3.18 Aplicaciones de MPLS 82 Capítulo 4 Casos de Estudio en Escenarios de Gestión de Desempeño - 84 4.1 Escenario 1. Un sistema de TMN para VPC y Gestión de encaminamiento en redes ATM con Servicios de Internet 2 84 o 4.1.1 Introducción 84 o 4.1.2 Planteamiento del Problema en la Red ATM 84 o 4.1.3 Gestión de servicio 86 4.1.3.1 Ambiente 87 4.1.3.2 Indicaciones en el servicio de red 88 4.1.3.3 Indicaciones en el comportamiento del usuario 88 4.1.3.4 Indicaciones en la operación de la red 89 o o 4.1.4 Descomposición 90 4.1.4.1 El Análisis 90 4.1.4.2 MSCs y MFCs 90 4.1.4.3 El mapa de la arquitectura de TMN 94 4.1.5 Descripción de los componentes arquitectónicos 94 4.1.5.1 Diseño OSF de la Ruta 95 4.1.5.2 Distribución OSF De la Anchura de banda de VPC 95 4.1.5.3 Carga que balancea OSF 97 4.1.5.4 Verificación OSF del desempeño 98 4.1.5.5 Modelo Predicho OSF del Uso 98 iii o 4.1.5.6 Gestión de Configuración del OSF 99 4.1.5.7. Modelo Actual OSF De la Carga 99 4.1.5.8 Encargado OSF de CAC 100 4.1.6 Interacciones entre los componentes arquitectónicos 4.1.6.1 Relación del Encargado-Agente o - 4.1.7 Conclusiones y trabajo futuro 100 100 101 4.2 Escenario 2. El sistema TMN para LSP y Gestión de encaminamiento en redes MPLS con servicios de Internet 2 103 o 4.2.1 Introducción 103 o 4.2.2 Planteamiento del Problema en la Red MPLS 104 o 4.2.3 Gestión de servicio 107 o o o 4.2.3.1 Indicaciones en el servicio de red 108 4.2.3.2 Indicaciones en el comportamiento del usuario 109 4.2.3.3 Indicaciones en la operación de la red 109 4.2.4 Descomposición 109 4.2.4.1 El Análisis 109 4.2.4.2 MSCs y MFCs 110 4.2.4.3 El mapa de la arquitectura de TMN 111 4.2.5 Descripción de los componentes arquitectónicos 112 4.2.5.1 Diseño OSF de la Ruta 112 4.2.5.2 Distribución OSF de la Anchura de banda de LSP 115 4.2.5.3 Carga que balancea OSF 116 4.2.5.4 Verificación OSF Del desempeño 116 4.2.5.5 Modelo Predicho OSF del uso 116 4.2.5.6. Gestión de Configuración del OSF 117 4.2.5.7. Modelo Actual OSF de la Carga 117 4.2.5.8. Encargado OSF del FEC 117 4.2.6 Interacciones entre los componentes arquitectónicos 4.2.6.1 Relación del Gestor -Agente 118 118 Conclusiones 120 Glosario de términos y Acrónimos 121 Bibliografía 127 Iv Resumen El desarrollo de la metodología de gestión de desempeño en el control de tráfico de una red ATM que integra a Internet 2 y la arquitectura MPLS para los servicios de transmisión, permite considerar que a pesar que muchas empresas prestadoras de servicios de telecomunicaciones cuentan con una infraestructura para ofrecer servicios de banda ancha, ya sean por cable de cobre, fibra óptica, satélite o medios inalámbricos, su éxito de operación dependerá de diferentes factores. En este caso es necesario considerar el modelo de Red de Gestión de Telecomunicaciones (TMN, Telecommunications Management Network) representando, sin lugar a dudas, la mejor opción para estructurar una arquitectura que es el propósito del presente trabajo. Así pues el crecimiento de Internet y la aparición de aplicaciones innovadoras, demandan la creación de nuevas tecnologías para responder a este concepto: Desempeño. La metodología a desarrollar se basará en la Gestión de Desempeño para poder controlar el tráfico que sea registrado en una red ATM misma que tendrá como aplicación de servicios de Internet 2, orientándonos al uso de la arquitectura MPLS (Multiprotocol Label Switching), y el cual a su vez establece una política de funcionamiento para el mejoramiento de desempeño en la red ATM y la convergencia de los protocolos IP/ATM. Para llevar a cabo la metodología y comprobar que es la más adecuada, se estableció el proceso de identificación del funcionamiento de TMN, de acuerdo a las recomendaciones M.3010 y M.3020 de la ITU-T, para identificar la secuencia de las etapas seguir y conocer las funciones de desempeño que intervienen, tanto en una red ATM y después la migración a MPLS, considerando los elementos y funciones tanto operacionalmente con respecto a la conectividad de los tipos de redes (ATM, MPLS) ya expuestas y siendo que el enfoque esta en dar interpretación con el modelo TMN, interviniendo sobre el estudio el Servicios de Gestión y Configuración los cuales apoyan los pasos a seguir en las funciones de operación y componentes de las funciones que intervienen en el estudio de gestión de desempeño de una red, ya que lo que correspondió a las red ATM identificamos a la componente de función que es el VPC, parte esencial en el estudio del desempeño de la red y lo que corresponde a la red MPLS identificamos el componente de función LSP, correspondiente al VPC, pero en este sentido existe una ventaja el LSP trabaja en forma transparente y esto permite visualizar que tanto el encaminamiento de una red y el envío de información son integrados en una sola ruta controlada por etiquetas, usando el protocolo LDP y el intercambio de etiquetas y búsqueda de nuevas rutas por medio del LSR, de esta manera los resultados obtenidos usando esta metodología la cual identificamos como descomposición de funciones permitiendo dar pasos de estudio más completos y con mayor seguridad en la planeación y diseño de una red en los aspectos de Gestión en un propuesta de operación de OSF en estudio de balanceo y demostración en la intervención en tomar nuevos criterios de operación para propuestas de diseños futuros, y además permitiendo orientar nuevos trabajos de investigación. Palabras clave: Desempeño, ATM, MPLS, VPC, LSP Summary The development of the performance management methodology an MPLS drive ATMInternet 2 network allows us to state the necessity of its implementation in many telecommunications service providers that have an infrastructure offering wide band services, using cupper wiring, optical fiber, satellite or wireless. In this case it is necessary to consider the model of the Telecommunications Management Network (TMN), that represents, without any doubt, the best option to structure an architecture. Therefore, expansion of the internet 2 and the coming out of innovative applications, require the creation of new technologies to satisfy the requirements of Performance. The Methodology to develop will be based on Performance Managing, in order to have the ability to control the internet 2 traffic that will be transported over an ATM network, and this will guide us to use MPLS architecture (Multiprotocol Label Switching) as well as rule to improve the performance of the ATM network and the convergence of the IP/ATM protocol. In order to carry out the methodology and verify that it is the most fitted, the process of identification of the TMN operation, will be used according to the recommendations M.3010 and M.3020, to identify the sequence of the steps to follow in ATM and in the migration MPLS, considering the elements and functions with respect to the connectivity of the types of networks (ATM, MPLS). The objective is to apply the TMN modeler the Management and configuration Services, which support the functions of management of ATM network’s performance. VPC is identified as the essential part to analyze the networks performance, and its MPLS counterpart, the LSP. The operation of the LSP is transparent, allowing the routing and information transport functions to be integrated in a single route controlled by labels. The decomposition of functions methodology uses the LDP protocol, label exchange and new routes search by means of the LSR, yielding a better OSF operation, giving way to optimized future designs. Key words: Performance, ATM, MPLS, VPC, LSP Capítulo 1. 1. Introducción En los comienzos de los años 90 el auge de las redes distribuidas tuvo un crecimiento a la transmisión de datos, video y voz, lo cual ha estado en constante desarrollo. Las soluciones que se han estado desarrollando para la Gestión de Redes en el aspecto de función de desempeño de una red ha sido una variable en ingeniería de tráfico, en este caso nuestro trabajo es encontrar una metodología de operación de funciones de Gestión que permita identificar y planear las funciones de operación que intervienen en la Gestión de Desempeño, al existir diferentes modelos de Gestión para redes de comunicaciones nuestra propuesta de desarrollo esta en enfocarnos a la Recomendación del ITU-T de la Red de Gestión de Telecomunicaciones (TMN), y aplicar el concepto de Gestión de Red, donde se expondrá la gestión de desempeño usando los mecanismos de funciones y componentes de operación que interviene para identificar los factores de conectiva de una red de comunicaciones, en este caso sobre una red ATM, desarrollando e implementando los servicios básicos de Internet 2, y por último nos enfocamos a trazar un mapeo en el plano de control donde se identifica la gestión de desempeño por lo que además haremos un nuevo análisis de nuestra metodología migrándola a una red con arquitectura MPLS la cual proponemos como propuesta de mejoramiento en los servicios de internet 2 bajo la misma alternativa de gestión de red sobre el concepto de desempeño, y conoceremos como una solución en el desempeño de una red y establecer una metodología de análisis para de una red de banda ancha, y poder entablar los conceptos de diseño, planeación y desarrollo de una red que esté en función o que se vaya a desarrollar a futuro. 1.1. Motivación de la Tesis Los avances que se han registrado actualmente han continuado en un desarrollo extremadamente vertiginoso, por lo que las nuevas alternativas en los avances de IP/ATM se han reducido por lo que están sujetas a un desplazamiento paulatino, sobre la base de los servicios de internet, por la intervención en el incremento de bandas anchas, así como algoritmos de encaminamiento complejos, y esto va aunado a las discontinuidades de enlace de datos y el nivel de red, mismos que han sido difíciles de tratar ya que su gestión de red es en forma separada y discontinua, en nuestro estudio proponemos la 1 arquitectura de comunicaciones MPLS, siendo un protocolo de ingeniería de tráfico, es una propuesta que cuenta con componentes de control y envío de información en forma continua, sustituyendo las técnicas de enlace IP/ATM por elementos de identificación y encaminamiento llamados etiquetas, aunque ésta problemática de conectividad se ha estado desarrollando, también existe la además el poder Gestionar a una red en los niveles de desempeño, en cuanto a las clases de servicio que repercuten en las calidades de servicio en el envío de información, bajo este enfoque, damos una metodología basada en las recomendaciones de la ITU-T para cubrir las necesidades por las normas de la IETF que son las de MPLS para su funcionamiento y control de tráfico. Tendremos dos escenarios, en el primero hablamos sobre la aplicación de TMN en una red ATM, dando pauta a nuestro estudio de MPLS usando TMN para obtener los componentes de operación y funcionalidad así como proponer las interfaces y elementos a estudiar y poder concluir como gestionar una red MPLS bajo las recomendaciones de la ITU-T y sus modelos de guía. Posteriormente, establecer un plan de diseño y operación ya sea para una red funcional o una red a proponer a futuro. 1.2 Objetivo General de la Tesis: Desarrollar la una metodología de gestión de desempeño en el control de tráfico de una red ATM integrando la arquitectura Internet 2 y la arquitectura MPLS para servicios de transmisión. 1.3 Objetivos particulares de la Tesis: - Identificación de una metodología para aplicación de un modelo de gestión adecuado en el marco de servicio de internet 2 sobre una red integrada de MPLS y ATM - Planeación de una estrategia metodológica de control de desempeño bajo el modelo de Gestión de Redes TMN. - Proponer la Identificación de la convergencia de gestión de desempeño de una red IP/ATM y migración a MPLS bajo el modelo de gestión de redes TMN 1.4 Justificación La problemática expuesta en este trabajo, va ha existir la necesidad del mejoramiento en el ámbito de los servicios que ofrece el internet como sistema abierto y distribuido así como en ingeniería de tráfico y sobre todo para poder controlar los parámetros 2 necesarios en el desempeño de su operación, es por ello la importancia de implementar el modelo de la Red de Gestión de Telecomunicaciones (TMN) del la ITU-T y dar soluciones precisas a diseñar y controlar una red de alta velocidad, de acuerdo a los desarrollos de conectividad avanzada que se han estado desarrollando actualmente sobre las redes de transporte ATM, mismo que estableceremos una convergencia dirigida a MPLS como protocolo de ingeniería de tráfico, ya que parte de las recomendaciones de la ITU-T en TMN, adicionalmente nos permite ver un plano de análisis y diseño sobre gestión de redes, y que nos muestra con más precisión el comportamiento de la misma, así como un estudio preciso de la arquitectura MPLS y sus componentes funcionales y sistemas de operación, estableciendo parámetros para análisis de una red y futuros diseños de redes. Ya que la interpretación de las funciones de TMN sobre una red MPLS y ATM, son bajo el enfoque de funciones, sistemas de operación y componentes, sobre una arquitectura de gestión y su estudio de planeación, que como se menciono, nos dará una pauta precisa en la identificación de estos componentes y funciones arrojando los aspectos reales de funcionamiento de la red para así abocarnos a obtener un desarrollo de ingeniería de tráfico controlada y dispuesta a ser expandida con un grado de error bajo en cuanto a su operación de funciones de gestión, así como hacer diseños futuros de redes en voz y datos. 1.5 Estructura de la Memoria. Este trabajo de Tesis se divide en 5 capítulos: El Capítulo 1 es la introducción en el que se definen los motivos de la realización de esta Memoria tesis, sus objetivos, justificación y se da un da panorama de la Memoria de esta tesis. En el Capítulo 2 se analiza el estado de arte del Modelo conceptual de la ITU-T de la Red Gestión de las Telecomunicaciones (TMN). En este Capítulo se analizan los conceptos fundamentales del TMN, permitiéndonos además analizar el modelo propio de TMN que estará siempre tomado en cuenta para la realización del diseño de la metodología y su implementación en el Sistema de Gestión de Desempeño. En el capítulo 3 damos de igual manera una conceptualización con respecto a las tecnologías de banda ancha conmutadas que intervienen en este trabajo de tesis, mismas que podemos identificar las propuestas de conectividad de ATM Forum, así como el mejoramiento sobre IP/ATM de la arquitectura de comunicaciones propuesta por la IETF que es la MPLS, donde lo importante es poder identificar las diferencias de la arquitectura de funcionamiento pero 3 además de poder identificar lo que nos interesa en la participación de Internet 2 como parte de los servicios que ofrece y es nuestro interés solo conocer ello en función de nuestra red de comunicaciones. En el Capitulo 4, vemos la implementación del modelo TMN de la ITU-T con el primer escenario ATM como medio de transporte, identificando cuál es el componente que afecta a la Gestión de desempeño que estamos estudiando, mismo que es mapeada y descompuesta en componentes y funciones de operación, así pues identificando la metodología propuesta, iniciamos la intervención de otro nuevo escenario donde proponemos un mejoramiento bajo la arquitectura MPLS de la IETF, siguiendo los mismos pasos pero ahora idealmente intervienen en forma transparente IP/ATM sobre un dominio de red MPLS identificando las ventajas sobre llevar a cabo esta metodología de gestión de desempeño por TMN de la IETF, arrojando una nueva visión de planeación y diseño de una red distribuida. En el capítulo 5 se dan las conclusiones de este Trabajo de Tesis. 4 Capítulo 2. 2. Introducción Teórica del Modelo de Gestión de Redes de Telecomunicaciones 2.1 Introducción. Gestión de Redes La década de los noventa ha sido calificada como la “ década del proceso distribuido”. Lo cierto es que en el campo de las tecnologías de la información, la tendencia más importante en estos momentos la constituyen los sistemas distribuidos y las redes de computadores. Siendo así, la mayoría de sus organizaciones tienden a distribuir sus sistemas informáticos. A medida que aumenta la complejidad y la importancia de estos sistemas, su complejidad y la inversión realizada crece de forma paralela. Llega entonces el momento en que los sistemas se hacen demasiado complejos para ser administrados manualmente, y se hacen necesarias técnicas y herramientas que permitan llevar a cabo dicha gestión de manera controlada y automatizada, garantizando que los sistemas funcionen y, cuando no es así, minimizando el tiempo en el que el sistema está parado, es decir, optimizando la fiabilidad y la disponibilidad.[Alfang2000] La transmisión de información a través de estas redes de telecomunicación constituye hoy en día una estrategia vital para las corporaciones que las utilizan, razón por la cual se hace indispensable una gestión de red efectiva y fiable. Gestión de red significa utilizar y coordinar los recursos para planear, ejecutar, administrar, analizar, evaluar, diseñar y extender las redes de comunicaciones para adaptarse al nivel de servicio requerido en todo momento, a un costo razonable y con capacidad óptima [Alfang2000]. La evolución del sector de las telecomunicaciones viene marcada por el hecho de que, tanto el aprovisionamiento como la explotación de los servicios, estaba bajo el control de monopolios para-estatales. Pero es a partir de entonces cuando la intervención inmediata de la privatización, o transformación, de las empresas tradicionales en el sector, y el impulso de nuevos marcos logísticos, abre el mercado a competidores, de nuevos proveedores de servicios que, en definitiva, redundan en una inevitable presión por mejorar la calidad y variedad de la oferta. Este escenario de mercado, en combinación con el rápido desarrollo tecnológico de las redes de telecomunicaciones, de analógicas a digitales integradas e inteligentes, y hacia 5 el ambiente distribuido y de banda ancha del futuro próximo, que es la explosión de nuevos servicios que se ofrecen o planean ofrecerse, ha resaltado aún más la necesidad de una operación, administración, mantenimiento y aprovisionamiento (OAM&P) de redes y servicios más eficientes. En este contexto, si tradicionalmente los equipos de transmisión y conmutación han sido considerados los componentes principales de las redes de telecomunicaciones, ahora los sistemas de información y gestión de red son tan importantes como aquellos. [Alfang2000] En la actualidad existen, en el ámbito público, básicamente dos tipos de sistemas de gestión: productos de grandes fabricantes y sistemas confeccionados a la medida de las necesidades del operador. - El primer tipo de sistemas de gestión tiende a ser instalado cerca de los Elementos de Red (NE:Network element) y está ligado a la tecnología del fabricante. Por lo general proporciona una numerosa serie de funcionalidades dentro de las áreas de gestión de rendimiento y de fallos y de captación de datos en general, para su posterior procesado. El alcance de estos sistemas tiende a ser muy puntual a una parte determinada de la red. Las redes de telecomunicaciones (TN’s:Telecommnications Networks):, están siendo más inteligentes, distribuidas, y más grandes cada día y se espera que las redes de telecomunicaciones se desarrollen hacia redes basadas en software con el despliegue de millares de elementos inteligentes de la red (NEs) para apoyar una amplia gama de servicios en el establecimiento de una red de información, e ir generando el rédito nuevo, y para reducir operaciones de la red y coste de la gestión. - El segundo tipo de sistemas tiende a ser instalado en las capas más altas de la jerarquía de gestión, proporcionando, por lo general, soluciones dependientes de la estructura organizacional del operador. Éstos están dedicados a un conjunto limitado de funciones como facturación, planificación y supervisión general de rendimiento y calidad de servicio. El alcance de estos sistemas tiende a ser amplio, cubriendo la totalidad de la red. En este aspecto, las soluciones de técnicas abiertas están limitadas tanto por la tecnología propietaria del fabricante como por la estructura organizacional del operador. Por otro lado, dada la falta de normas completas de gestión, se identifican pocos de estos sistemas como “abiertos”. [Aida94] 6 Pero la gestión de red en un ámbito de múltiples proveedores resulta en una labor bastante compleja y difícil [Bern93], [Bjer94], [Bjer98], puesto que cada fabricante proporciona sistemas y protocolos de gestión propietarios que, aunque con conceptos similares, difieren en cuanto a semántica, caracterización y funcionalidad. Esto implica que, desde el punto de vista del operador, se requiera de expertos en cada uno de los diferentes sistemas de gestión que se tenga. Por otro lado, la gestión de una red heterogénea es muy complicada.[Alfang2000] Esta heterogeneidad o no-uniformidad de las redes de las organizaciones tanto en lo referente al hardware de sus equipos como a su arquitectura, se puede superar utilizando un sistema de Gestión de Red integrador basado en una normativa que sea independiente de los equipos, sistemas y de las arquitecturas propietarias [Grif95], [Lewis95], [Lewis97]. Tradicionalmente, el Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones (ITU-T), antes CCITT, ha enfocado sus actividades a la normalización de redes públicas de telecomunicación. Dentro de este proceso de normalización, en el año 1985 planteó la necesidad de proporcionar un sistema común de apoyo a la operación de redes, que permitiese integrar las áreas clásicas de operación, administración y mantenimiento (conocido también por las siglas OA&M). De aquí surgió la TMN (Telecommunication Management Network) [M3010], [Cohen94], [Sahi94]. Hasta este momento, el desempeño de los sistemas de gestión de red se centraba en la capacidad de operar redes grandes y complejas, enfocados a los aspectos básicos de OAM&P, como son: configurar la red, asegurar su disponibilidad y recolectar datos básicos de rendimiento y contabilidad. No obstante, sin desestimar éstos, actualmente deben considerarse otros aspectos, tales como: soporte al aprovisionamiento de servicio, debido al rápido despliegue de nuevos servicios; gestión de red por el cliente y automatización de sistemas de operación. [Alfang2000] 2.2 Funciones de Gestión de Redes La arquitectura y los sistemas de control son medios dominantes para el desarrollo de las redes de comunicaciones de hoy, limitando los sistemas de gestión de red para reunir los objetivos del mañana. Los clientes, como se muestra en la figura 2.1, han accesado a los proveedores de servicio de los sistemas de gestión de red y sus aplicaciones. Por la necesidad de colocar de nuevo las bases de datos de red y tomar un avance de elementos de redes inteligentes, proporcionando un alto nivel de interfaces estándar, 7 implementando protocolos estándares y mensajes, y compartiendo la funcionalidad de OAM&P a través de operaciones de sistemas y elementos inteligentes de red, la red envuelve la disponibilidad de proveedores de red y servicios para un rápido desarrollo de nuevos servicios, la implementación de innovación tecnológica, la reducción de costos, el realce de la competitividad y la solución de las demandas son cada vez mayores a los clientes. Servicio de pago Cliente Mantener la petición Servici de estado Informe de problemas Estado de Orden Planeando Gestión Configuración Pronóstico de Tiempo Gestión Fallas Pruebas Gestión Desempeño Alarmas Servicios de Datos Controles de Red Gestión Contabilidad Oms (Traffic) AMA A Material Estado de Requesitos Datos de Config. NE Interfaces Gestión Material Equipo de entrega & Instalación Falla de Gestion Gestión Mano de Obra Ordenes Surtidores Provisión de recurssos Servicio de provisión Red Envio Figura 2.1 Funciones de la Gestión de Red Las nuevas versiones de red inteligente serán últimamente realizadas en la Red de Gestión de las telecomunicaciones (TMN), concepto que define la relación entre los bloques de construcción funcionales de la red básica (sistemas de operación, redes de comunicación de datos, y elementos de red) en términos de interfaces estándares. La TMN también introduce el concepto de control de subred y esto desempeñará un papel importante en el desarrollo de hoy, que se encuentra limitado de sistemas de gestión de red para reunir futuros objetivos de negocios, Una subred es una agregación de un grupo de NE’s (supervisores de elemento) que junto se encuentra atado por un criterio común. (ej. Función, tecnología) y esta vista por la aplicación de gestión como una simple entidad. Un equipo que implementa funcionalidad de subredes OAM&P, se conoce como supervisor de elemento (EM), es un instrumento de construcción de bloque que simplificará la intercomunicación entre las operaciones de los sistemas y los elementos de red. De una perspectiva de una arquitectura EM que proporciona la flexibilidad de gestión entre los puntos de los sistemas de gestión de red y los proveedores de implementación de tecnología. Se utiliza el marco de trabajo de TMN para la gestión de 8 comunicaciones con sus modelos genéricos de información e interfaces estándares. [Aida94] 2.3 La Red de Gestión de las Telecomunicaciones (TMN) La arquitectura TMN está definida en la Recomendación M.3010 de la ITU-T [M3010]. En ésta, el concepto de TMN está definido como el aprovisionamiento de “…una arquitectura organizada para realizar la interconexión entre varios tipos de sistemas de operaciones y/o equipo de Telecomunicaciones para el intercambio de información de gestión usando…interfaces normalizadas…”. La arquitectura TMN consta de tres partes: funcional, de información y física. La arquitectura de información tiene que ver con los paradigmas de orientación a objetos y de Gestor - Agente, que más adelante se comentan en este trabajo. La arquitectura física tiene que ver principalmente con las interfaces físicas y protocolos. La arquitectura funcional de TMN identifica una serie de funciones y sus relaciones de intercambio de información, conocidos como puntos de referencia, que veremos más adelante. La TMN proporciona las funciones de la gestión para las redes y los servicios de telecomunicación y ofrece comunicaciones entre sí mismo y las redes de telecomunicación. En este contexto una red de telecomunicación se asume para trabajar en el equipo digital y análogo de las telecomunicaciones y el equipo asociado de soporte. Un servicio de telecomunicación en este contexto consiste en una gama de las capacidades proporcionadas a los clientes. El concepto básico detrás de un TMN es proporcionar una arquitectura organizada para alcanzar la interconexión entre los varios tipos de sistemas de las operaciones (OSs) y/o de equipo de las telecomunicaciones para el intercambio de la información de la gestión usando una arquitectura convenida con las interfaces ya estandardizadas, incluyendo protocolos y mensajes. El definir el concepto, se reconoce que muchos operadores públicos de la telecomunicación (PTOs) tienen una infraestructura grande de OSs (Sistemas Operacionales), de redes y del equipo de las telecomunicaciones ya instalados, y que se deben acomodar dentro de una arquitectura. La disposición también se hace para el acceso, y la exhibición, de la información de la gestión contenida dentro del TMN a los usuarios. 9 2.3.1 Relación de la TMN a una red de telecomunicaciones Un TMN puede variar en complejidad de una conexión muy simple entre un OS (Sistemas de Operación) y una pieza única del equipo de las telecomunicaciones a una red compleja que interconecta muchos tipos de OSs y de equipos de telecomunicaciones. Un TMN puede proporcionar funciones de gestión y ofrecer las comunicaciones entre los OSs de ellos mismos, y entre OSs y sus partes de la red de telecomunicaciones. Un TMN puede también proporcionar funciones de la gestión y ofrecer comunicaciones a otras entidades de TMN o similares a TMN para apoyar la gestión de redes de telecomunicaciones internacionales y nacionales. Una red de telecomunicaciones consiste en muchos tipos de equipo analógico y digital, además de equipo de ayuda asociado, tales como sistemas de la transmisión, sistemas que cambian, múltiplexajes, señalando las terminales, los procesadores de trabajo, los chasis, los reguladores de racimo, los servidores de archivo, etc. Por lo que su manejo es identificar un equipo genérico y se refieren como elementos de la red (NEs). La figura 2.2 demuestra la relación general entre un TMN y una red de telecomunicaciones a la cual maneja. Un TMN es un modelo conceptual a una red separada que se interconecta a una red de telecomunicaciones en varios puntos a la información envio/recepción, asía /de donde y al control de sus operaciones. Un TMN puede utilizar las partes de la red de telecomunicaciones para proporcionar sus propias comunicaciones. Una TMN puede ser una red muy simple para conectar un OS para un NE, o puede ser una red amplia interconectada con diferentes OSs, NEs y WSs. En la figura 2.2 ilustra la relación de un TMN para las redes de telecomunicaciones que esta manejada. TM N WS OS WS OS WS WS OS R e d d e C o m u n ic a c ió n d e D a t o s S w itc h S is te m a s d e T r a n s m is ió n S w itc h S is te m a s d e T r a n s m is ió n S w itc h R e d d e T e lc o m u n i c a c io n e s O S : S is t e m a O p e r a t iv o ; W S : E s t a c ió n d e t r a b a jo Figura 2.2 Relación de elementos en una TMN 10 Observese que el TMN es una red separada que permite la gestión telecomunicaciones. Sin embargo, esto puede usar partes de una red de de la red de telecomunicaciones para proveer enlaces de comunicaciones ( ejemplo usando el canal incrustado de las operaciones ECO: en señales digitales) En otras palabras, algunas partes de la TMN puede ser incrustado en una red lógica con la red de telecomunicaciones. [Aidarous94] 2.3.2 Campo del uso Los siguientes son los ejemplos del equipo, de las redes y de los servicios de las telecomunicaciones que se pueden manejar por un TMN: – Redes públicas y privadas, incluyendo ISDNs de banda ancha, redes móviles, redes privadas de la voz, redes privadas virtuales y redes inteligentes – Terminales de la transmisión (los multiplexores, conectores, equipo de conversión de canal, SADO: etc.); Sistemas digitales y analógicas de transmisión (cable, fibra, radio, satélite, etc.); – Sistemas de la restauración; – Sistemas de las operaciones y sus periféricos; – Chasis, procesadores anticipados, reguladores de racimo, servidores de archivo, etc.; – Conversión de sistemas digitales y analógicas; – Redes del área (WAN, MAN, LAN); – Circuito y redes de intercambio de paquetes; – Señalar los terminales y los sistemas incluyendo los puntos de la transferencia de la señal (STP) y las bases de datos en tiempo real; – Servicios de portador y teleservicios; – PBXs, accesos del PBX y terminales del usuario (cliente); – Terminales del usuario del ISDN; – Software proporcionado cerca o asociado a los servicios de telecomunicaciones, por ejemplo: software de la conmutación, directorios, bases de datos del mensaje, etc.; – Usos del software de TMN; – Sistemas de ayuda asociados (módulos de la prueba, sistemas de energía, unidades de aire acondicionado, sistemas de alarma constructivos, etc.). 11 Además, un TMN se puede utilizar para manejar: – Entidades distribuidas y servicios ofrecidos agrupando de los artículos en la lista antes dicha; – Recursos relacionados con los procesos que aplicaciones de un PTO en la operación del equipo, de las redes y de los servicios. Los ejemplos de tales recursos manejados son: orden del servicio de reparación de equipo, boletos generados por quejas del cliente, contrato del cliente para el aprovisionamiento del servicio, acuerdos del porcentaje de disponibilidad, datos históricos, etc. Parte de los usos referidos con anterioridad nos da la visión de conocer la existencia de la combinación de los servicios pertenecientes al ambiente de telecomunicaciones. 2.3.3 Objetivos básicos para un TMN El objetivo para las especificaciones de TMN es proporcionar un marco para la gestión de las telecomunicaciones. Introduciendo el concepto de los modelos genéricos de la red para la gestión, es posible realizar la gestión general del equipo, de la red y de servicios diversos, usando modelos genéricos de la información e interfaces estándares. Un TMN se crea para apoyar una variedad amplia de áreas de la gestión que cubran el planeamiento, la instalación, las operaciones, la administración, el mantenimiento y el aprovisionamiento de las redes y de los servicios de telecomunicaciones. La recomendación [M.3200] [ Recomendación ITU-T] describe el alcance de la gestión con los dos conceptos principales siguientes: Areas de Manejo de Telecomunicaciones (Telecommunications Managed Areas) y Servicios de Gestión TMN (TMN Management Services). La primera se relaciona con agrupar los recursos de las telecomunicaciones que son manejados y el último se relaciona con el sistema de procesos requeridos para alcanzar los objetivos de operación y saber las metas de la gestión de TMN. La especificación y el desarrollo de la gama de funcionalidades requeridas para apoyar las áreas antes dichas de la gestión es una cuestión local y no se considera dentro de estas recomendaciones. Una cierta dirección de la gestión es proporcionada por la ITU-T que ha categorizado a la gestión en cinco áreas funcionales de la gestión (recomendación X.700 ). Estas áreas funcionales apoyan el alcance de la gestión descrito por la Recomendación [M.3020]. Proporcionan un marco a través del cual los 12 servicios apropiados de la gestión apoyen los procesos del negocio de PTOs. Cinco áreas funcionales de la gestión son identificadas hasta la fecha como sigue: – Gestión de Desempeño; – Gestión de Falla; – Gestión de la configuración; – Gestión de contabilidad; – Gestión de la seguridad. La clasificación de la información intercambiada dentro del TMN es independiente del uso que será hecho de la información. El TMN necesita estar enterado de redes y de servicios de telecomunicaciones así como colecciones de sistemas de cooperación. La arquitectura se refiere a orquestar la gestión de sistemas individuales para tener un efecto coordinado sobre la red. La introducción de TMNs da a PTOs la posibilidad para alcanzar una gama de los objetivos de la gestión incluyendo de que: – Reducir al mínimo los tiempos de reacción de la gestión a los acontecimientos de la red; – Reducir al mínimo la carga causada por el tráfico de la gestión en donde la red de telecomunicaciones se utiliza para llevarla; – Tener en cuenta la dispersión geográfica del control sobre los aspectos de la operación de la red; – Proporcionar los mecanismos de aislamiento para reducir al mínimo riesgos de la seguridad; – Proporcionar los mecanismos de aislamiento para localizar y para contener averías de la red; – Mejorar la ayuda y la interacción del servicio con los clientes. Como se mencionó la arquitectura TMN está definida en la Recomendación M.3010 de la ITU-T [M3010]. Parte de las recomendaciones dadas por la ITU-T, que es definida para TMN, y que describiremos continuamente en el desarrollo de este trabajo, es importante denotar la ventaja de identificar cada una de las recomendaciones de la ITU-T para establecer un plan de trabajo en base a las estrategias proporcionadas por las mismas recomendaciones, a continuación se muestra en la figura 2.3, las recomendaciones establecidas y su relación en base a su funcionamiento y puesta en práctica así como su interrelación de cada posición de operación. 13 Titulo Resumen de las Recomendaciones TMN Objetivos para TMN Metodología de la especificación de la interface TMN Modelo de información de una red genérica Declaraciones de gestión de conformidad para la información genérica de la red modelada Catalogo de información de Gestión TMN Gestión de Servicio TMN: Resumen Gestión de Servicio TMN: Aspectos de mantenimiento de B-ISDN Gestión de Servicio TMN: Falla y desempeño del acceso ISDN Compatibilidad presentada por Gestión TMN de la Interface F Requerimientos de Marco de Gestión para la Interface TMN –X Funciones de Gestión TMN Resumen de Recomendaciones TMN M.3000 Principios para una TMN M.3010 Numero M.3000 M.3010 M.3020 M.3100 M.3101 Fecha 10/94 05/96 07/95 07/95 07/95 M.3180 M.3200 M.3207.1 M.3211.1 M.3300 M.3320 M.3400 10/92 10/92 05/96 05/96 10/92 04/97 04/97 Terminos y definiciones TMN M.6012 Interface TMN Especificaciones de Metodología M.3020 Modelo genérico de información de Red M.3100 Resumen de servicios De Gestión TMN M.3200 Compatibilidad de Gestión TMN de la interface F: M.3300 Interface X: M.3320 Servicio de Gestión “1” Servicio de Gestión “n” Catalogo de Gestion de Información de TMN M.3180 Funciones de Gestión TMN M.3400 Figura 2.3 Relación de normas de las recomendaciones de ITU-T para TMN 2.3.4 Arquitectura funcional del modelo TMN La funcionalidad de TMN proporciona el significado del transporte de información y la relación de procesos de información para gestión de redes de telecomunicaciones y servicios. (Figura 2.4) 14 Funciones TMN OSF= Funciones de sistemas de Operación MF= Funciones de Mediación WSF= Funciones de estación de trabajo NEF= Funciones de elemento de red QAF= Funciones del adaptador Q Figura 2.4 Funciones y puntos de referencia en TMN La arquitectura funcional de TMN se estructura de los elementos fundamentales siguientes: - Componentes funcionales; - Funciones de Aplicación de Gestión (MAFs); - Sistemas de la función de la gestión de TMN y funciones de la gestión TMN; - Puntos de referencia. La funcionalidad de la gestión de TMN se pondrá en ejecución y entonces se puede describir en términos de estos elementos fundamentales. 2.3.4.1 Componentes funcionales de TMN En la figura 2.4 se ilustran los diversos tipos de componentes de funciones las implicaciones con respecto a la conformación del modelo de gestión TMN. Algunos de las componentes de la función están en parte dentro y parte fuera del TMN; componentes de la función de TMN también éstos realizan funciones fuera de los límites funcionales de TMN según se discute y define en las subclases que a continuación describiremos. La componente de función de TMN es la unidad más pequeña de la funcionalidad de la gestión de TMN. A continuación se da una breve descripción de las funciones identificadas en la arquitectura funcional de TMN. [M3010], [P414D3], [P609D4] [Alfang2000]. 15 A) Función de Sistemas de Operaciones (OSF). - Una OSF representa la funcionalidad de los sistemas de apoyo operacional, la cual debe supervisar y/o controlar redes, servicios o parte de la misma TMN. B) Función de Elemento de Red (NEF). - Una NEF representa la funcionalidad del equipo de red que está supervisada y/o controlada por una TMN. • Componente de función de elemento-Red o Los NEFs (Network Element Function) de hoy se puede ver como redes de microprocesadores y/o de minicomputadoras. La inteligencia de los NEFs ha incrementado exponencialmente en las ultimas décadas. Por lo tanto, muchos de OSFs y MFs están integrados o están siendo integrados en NEF. Esto incluye conmutadores, sistemas de comunicación digital de conexión cruzada (DCSs), multiplexores, portadores de loop digital (DCL). Algunos ejemplos de los elementos de gestión de red (NE-NMF), son: - Protocolo de conversión - Dirección de mapeo - Mensaje de conversión - Encaminamiento - Colección de datos y almacenaje (desempeño, estatus de alarma) - Respaldo de datos - Autoreparación - Autoprueba - Autolocalización de fallas - NE nivel de análisis de alarma - Operaciones de transporte de datos vía EOCs C) Función de Estación de Trabajo (WSF). - Una WSF representa la funcionalidad de estación de trabajo (terminal) que traduce la información originada en la TMN de tal manera que pueda ser interpretada por un usuario (humano) de la estación de trabajo. • Componente de Función de estación de trabajo de red o La gestión de estación de trabajo de red (WS NMF) proporciona el significado para interpretar la gestión de información de la interface de formato F para el formato de la interface G. 16 D) Función de Mediación (MF). - Una MF representa la funcionalidad de adaptación de la información, que permite la comunicación entre una OSF y una NEF (o QAF), sin necesidad de una interfaz común. • Componentes funcionales de mediación • La función de la mediación del TMN permite que los componentes de función del TMN se comuniquen entre diversos puntos o interfaces de referencia. En otras palabras, proporciona el bloque TMN MF un lugar de puerta de enlace y/o relaciona las funciones. Si nosotros aceptamos la definición en M.30/M.3010, entonces el bloque de MF se convierte en un concepto muy confuso en el TMN. Desde la definición de MF en M.30/M3010 incluye información procesada y funciones de transporte de información, el limite entre las componentes de OSF y MF puede llegar a ser no tan claras. Algunos de los ejemplos de MF son: • Funciones de transporte de información (ITF) o Protocolo de conversión o Mensaje de conversión o Señal de conversión o Dirección de mapeo / traslación o Encaminamiento o Concentración • Funciones de procesamiento de información (IOF) o Ejecución o Investigación o Almacenaje o Filtrado E) Función de Adaptador Q (QAF). - Una QAF representa la funcionalidad de adaptación de información, la cual permite que entidades similares a OSF y NEF en un ámbito que no sea TMN, se comuniquen con una TMN. F) Función de Comunicaciones de Datos (DCF). - Una DCF representa la funcionalidad de red de datos, que es usada en una TMN como el mecanismo de transporte de información. 17 G) Función de Base de Información de Gestión (MIBF). - Una MIB representa un depósito conceptual de información de gestión en una entidad gestionada. Una función MIB forma parte de todas las funciones identificadas anteriormente, a excepción de la DCF. 2.3.4.2 Funcionalidad de la aplicación de la Gestión (MAF) La funcionalidad de la Aplicación de la Gestión (MAF) representa (parte de) la funcionalidad de unos o más servicios de la gestión de TMN. Las recomendaciones M.32xx-series de ITU-T enumeran el MAFs con respecto a las tecnologías y a los servicios apoyados por el TMN. La funcionalidad del Aplicación de la Gestión (MAF) se puede identificar con el tipo de bloque de la función de TMN en el cual se ponen en ejecución. El MAF siguiente puede ser identificado: – Funcionalidad de los Sistemas de las Operaciones; – Función del Uso de la Gestión (OSF-MAF); – Funcionalidad del Elemento de Red - Función de Aplicación de la Gestión (NEFMAF); – Funcionalidad de la Transformación; – Función del Uso de la Gestión (TF-MAF); – Funcionalidad de la Estación de Trabajo - Función del Uso de la Gestión (WSFMAF). Funcionalidad de Soporte Las funciones de soporte se pueden encontrar opcionalmente en un bloque de la función de TMN. La funcionalidad de soportes son comunes a más de un bloque, de la función de TMN dentro del mismo TMN puesto en ejecución. Una cierta ayuda de la funcionalidad de soporte de MAF dentro de un bloque de la función de TMN es en sus interacciones con otra componente de función. Ejemplos de tal funcionalidad incluyen lo siguiente: – funcionalidad de la comunicación de datos (DCF); – funcionalidad de la ayuda del sitio de trabajo; – funcionalidad del interfaz utilizador; – funcionalidad del sistema del directorio; – funcionalidad de la base de datos; 18 – funcionalidad de la seguridad; – funcionalidad de la comunicación del mensaje. 2.3.4.3 Sistemas de función de gestión de TMN Para realizar servicios de la gestión de TMN, las interacciones ocurren entre MAFs en diversos bloques de la función de TMN, con la ayuda de las funciones de soporte. Estas interacciones entre la cooperación MAFs se refieren como funciones de la gestión de TMN. La gestión de TMN funciona, colectivamente en todas las interacciones potenciales a que un solo MAF apoyará, se agrupan juntas y se orientan como un sistema de la función de la gestión de TMN. La función general de gestión de TMN se fija y sus miembros de las funciones de gestión de TMN pueden ser encontrados en la recomendación M.3400 de ITU-T. 2.3.4.4 Puntos de referencia de TMN Un punto de referencia de TMN define el límite del servicio de la función del componente. Esta vista externa de la funcionalidad se captura en el sistema de las funciones de la gestión de TMN que tendrán visibilidad del bloque de la función. Los puntos de referencia tienen significado en las especificaciones funcionales que conducen a una puesta en práctica. Un punto de referencia puede representar las interacciones entre un par particular de componentes de función. La tabla 1 demuestra las relaciones entre las componentes referencia entre ellos. de función en los términos de los puntos de El concepto del punto de referencia es importante porque representa el agregado de todas las capacidades que una componente particular de la función que busca de otro bloque particular de función, o componentes equivalentes de función. También representa el agregado de todas las operaciones y/o notificaciones (según lo definido en la recomendación X.703 de ITU-T) que una componente de función puede proporcionar a una componente de función de la petición. Un TMN funcionalmente desde el punto de referencia corresponde generalmente a una interfaz física a-ser-puesto en ejecución, en la arquitectura física, si y solamente si las componentes de función se ponen en ejecución en diversos bloques físicos. (ITU-T 3010) 19 Tabla 1. Relaciones de la tabla – 1/M.3010 entre los bloques de la función lógica expresado como puntos de referencia NEF NEF OSF QAF Q Q a) WSF OSF q q, x Q f TF q q Q f F F WSF non-TMN m c) non-TMN c) m b) g gb) a) el punto de referencia x se aplica solamente cuando cada OSF está en un diverso TMN. b) El punto de referencia de g esta entre el WSF y el usuario humano. c) El punto de referencia de m esta entre el QAF y la funcionalidad de la telecomunicación. Nota – cualquier función puede comunicarse en un punto de referencia de no-TMN. Estos puntos de referencia de no-TMN se pueden estandarizar por el otro grupos/organizaciones para los propósitos particulares. Clases de los puntos de referencia Tres clases de los puntos de referencia de TMN se definen, éstos son (ITU-T 3010): q se clasifica entre OSF, el QAF y NEF. f se clasifica entre OSF y un WSF. x se clasifica entre OSFs de dos TMNs o entre el OSF de un TMN y de la funcionalidad equivalente de OSF de otra red. La figura 2.5 ilustra las tres clases de los puntos de referencia. Además hay dos clases más de los puntos de referencia de modelos no TMN que son relevantes de considerar: g clase entre un WSF y los usuarios. m clase entre un QAF y entidades manejadas no TMN. Figura 2.5. Puntos de referencia en TMN 20 Los puntos de referencia definen los límites de servicio entre funciones. En [M3010] se definen cinco clases de puntos de referencia: q, f, x, y m. (Ver Figura 1.7). Para nuestros propósitos sólo consideraremos los puntos de referencia q y x. Puntos de Referencia q Los puntos de referencia q identifican intercambios de información entre bloques funcionales. Éstos se localizan entre: NEF y OSF, NEF y MF, MF y MF, QAF y MF, MF y OSF, QAF y OSF, y entre OSF y OSF. Dentro de esta clase se tienen: • qx Puntos de referencia ubicados entre NEF y MF, QAF y MF y entre MF y MF; • q3 Puntos de referencia ubicados entre NEF y OSF, QAF y OSF, MF y OSF, y entre OSF y OSF. Puntos de Referencia x Los puntos de referencia x se localizan entre las funciones OSF de diferentes TMNs. Las entidades que se localicen más allá del punto de referencia x podrán ser parte de una TMN (OSF) o de una red no-TMN (similar a OSF). Esta clasificación es transparente para estos puntos de referencia. Interfaces TMN En la mayoría de los casos, la interconexión entre bloques funcionales TMN es llevada a cabo por interfaces TMN. Las interfaces TMN son la realización de los puntos de referencia que están física y externamente visibles entre los sistemas.(Alfang 2000) La Interfaz Q3 Una Interfaz Q3 es una realización del punto de referencia q3. Está caracterizado por la información compartida entre la OSF y otras funciones TMN con las que interactúa directamente. Esta interfaz TMN es la que presenta un mayor grado de normalización [Q811], [Q812], [Q821] y [Q822]. En la práctica, una interfaz Q3 se identifica más bien como un requisito entre una OSF (un sistema de operaciones) y una NEF, o entre dos OSFs a diferentes niveles dentro de la jerarquía de gestión. Los protocolos de comunicación propuestos para esta interfaz son CMIP [X711] para intercambio de información de gestión, FTAM (File Transfer Access and Management), para transferencia de ficheros, y X.25 e IEEE 802.3, para capas inferiores de la pila OSI. En la actualidad se han especificado además interfaces Q3 para redes de tecnologías 21 SDH y ATM [Mdel3]. En la figura 2.6 se ilustra la pila de protocolos para la interfaz Q3 propuesta por el NMF y que funciona como una norma de facto [Villa94]. Proceso de Aplicación de Gestión ASE Específico de Gestión FTAM CMISE ROSE ACS ACS CCR Capa 7 Presentación OSI Sesión OSI Transporte OSI Subred 2 Subred 1 Subred 3 Capas 1 - 3 Figura 2.6 Pila de Protocolos para Q3 El modelo de información asociado a Q3 utiliza, para la definición de objetos gestionados, la sintaxis GDMO [X722] de la ITU-T. Haciendo una descripción a la funcionalidad de las interfaces, como se muestra en la figura 2.7. donde observamos las operaciones que intervienen a las NEFy la OSF con respecto a la conexión con otra red que no sea TMN, ya sea una componente funcional OSF o un NEF, usamos la componente funcional QAF, y se ilustra en la figura 2.7. Punto de Referencia m Punto de Referencia q Punto de Referencia q Punto de Referencia m Figura 2.7 Funciones de las interfases Q 22 Relación de los puntos de referencia a los bloques de la función La figura 2.8 ilustra un ejemplo de todos los pares posibles de los bloques de la función de TMN que pueden ser asociados vía un punto de referencia, también ilustra un flujo típico de la funcionalidad entre los bloques de la función de TMN en un arreglo jerárquico, así mismo la figura 2.8 ilustra un ejemplo de los puntos de referencia posibles entre los bloques de la función. (ITU.T-3010) g g W SF TM N W SF f f q TM N f OSF x OSF q q q OSF q q q q NEF NEF TF m T 0 4 1 3 0 10 -99 Figura 2.8 Ilustración de los puntos de referencia entre los bloques de la función de la gestión 2.3.5. La Arquitectura Lógica por Capas (LLA) de TMN Dentro de los aspectos de organización de gestión, una de las mayores aportaciones de TMN es la definición de una estructuración genérica en capas que permiten modelar las relaciones entre diferentes sistemas de gestión en la misma o en diferentes organizaciones [Sahi94]. Este modelo sigue una estructura jerárquica que permite proporcionar una panorámica lógica de las combinaciones entre componentes de gestión y entidades de control asociadas, así como ubicar a estos componentes de gestión, en base a su nivel de abstracción. Esta estructuración fue introducida por British Telecomm en su arquitectura ONA (Open Network Architecture), conocida actualmente como CNA (Cooperative Network Arquitecture) [Villa94]. Según esta arquitectura, los sistemas de 23 operación pueden dividirse en cuatro grandes grupos de gestión, en donde las capas superiores utilizan los servicios proporcionados por las capas inferiores, formando una estructura piramidal ver figura 2.9: Capa de Gestión de Negocio Función de Empresa y de Servicio de una Capa de Gestión de Servicio Capa de Gestión de Red Capa de Gestión de Elemento de Red Gestión, control y coordinación de los elementos de la red Capa de Elemento de Red Figura 2.9. Arquitectura Lógica por Capas de TMN 2.2.5.1. Capas de la función de la gestión de abstracción El agrupar de la funcionalidad de la gestión implica agrupar bloques de la función de OSF en capas. Una especialización de los bloques de la función de OSF basados sobre diversas capas de la abstracción como lo observamos en la figura es 2.10: Capa de Gestión de Negocio Capa de Gestión de Servicio Capa de Gestión de Red Capa de Gestión de Elemento Capa de Elemento de Red Figura 2.10 Relación de función entre los componentes funcionalidad y las capas la arquitectura lógica de TMN. 24 La gestión de TMN y las funciones de planeación definida en la sección 1.2 están proporcionadas para OSFs. Muchos tipos de OSFs son necesarios para manejar y planear redes y servicios de telecomunicaciones. Las organizaciones de estandarización son referidas para especificar el número de los diferentes servicios OSFs y sus implementaciones para sistemas físicos. En acuerdo para la ITU.T M.3010, existen 4 bloques de OSF para trabajar: La capa de gestión de negocios (BML), la capa de gestión de servicio (SML), la capa de gestión de red (NML), y la capa de gestión de elemento (NEML). La NEML es también llamada capa de gestión de subred (SNML) o simplemente capa de elemento de red (EML). Los detalles de estos puntos se ven más adelante.[Aida94] 2.3.5.2. Capa de la gestión de elemento La capa de la gestión de elemento tiene un o más elementos OSFs. La capa de la gestión de elemento tiene los tres principales papeles: 1) Control y coordinación de un subconjunto de elementos de la red sobre una base individual de NEF. En este papel, la interacción de la ayuda del elemento OSFs entre la capa de la dirección de la red y la capa del elemento de la red procesando la información de la gestión que es intercambiada entre la red individual OSFs y NEFs. El elemento OSFs debe proporcionar el acceso completo a la funcionalidad del NE. 2) La capa de la gestión del elemento puede también controlar y coordinar un subconjunto de elementos de la red sobre base colectiva. 3) Se mantiene el aspecto estadístico, registro y otros datos sobre elementos dentro de su alcance del control. OSFs en la capa de la gestión del elemento obran recíprocamente con OSFs en igual u otras capas dentro del mismo TMN a través de un punto de referencia q y en el otro TMNs a través de un punto de referencia x. 2.3.5.3.Capa de Gestión de Red La capa gestión de red tiene una responsabilidad de la gestión de una red según lo apoyado por la capa de la gestión de elemento. En esta capa, las funciones que se dirigen a gestionar una área geográfica amplia donde estén situadas. La visibilidad completa de la red entera es típica y, como objetivo, una 25 opinión independiente de la tecnología será proporcionada a la capa de la gestión de servicio. La capa de la red tiene cinco principales papeles: 1) El control y la coordinación de todos los elementos de la red dentro de su alcance o dominio. 2) La cesación o la modificación de las capacidades de la red para la ayuda del servicio a los clientes. 3) El mantenimiento de las capacidades de la red. 4) El mantener estadísticas, el registro y otros datos sobre la red que obran recíprocamente con la capa del encargado de servicio en funcionamiento, uso, disponibilidad, etc. 5) La red OSFs puede manejar las relaciones (por ejemplo: conectividad) entre NEFs. Así, la capa de gestión de red proporciona la funcionalidad para manejar una red coordinando la actividad a través de la red y apoya las demandas de la " red " hechas por la capa de la gestión de servicio. Se sabe qué recursos están disponibles en la red, se correlacionan y geográficamente se asignan éstos y cómo los recursos pueden ser controlados. Tiene una descripción de la red. Además, esta capa es responsable del funcionamiento técnico de la red real y controlará las capacidades y la capacidad disponibles de la red al dar la accesibilidad y la calidad apropiadas del servicio. OSF en la capa de la dirección de la red que obran recíprocamente con OSFs sobre otras capas dentro del mismo TMN a través de un punto de referencia de q y en el otro TMNs a través de un punto de referencia de x. 2.3.5.4. Capa de Gestión de Servicio La capa de gestión de servicio trata los aspectos contractuales de los servicios que se están proporcionando a los clientes o que es disponible a los nuevos clientes potenciales. Algunas de las funciones principales de esta capa son orden del servicio que dirige, y que factura. La capa de la gestión de servicio tiene los cuatro papeles principales siguientes: 1) Revestimientos del cliente (nota) e interconexión con el otro PTOs/ROAs; 2) Interacción con los abastecedores de servicio; 3) Datos estadísticos el mantener (por ejemplo: QoS); 4) Interacción entre los servicios. 26 NOTA los revestimientos del cliente proveen del punto básico del contacto los clientes para todas las transacciones del servicio incluyendo provisión/cesación del servicio, de cuentas, de QoS, de la divulgación de avería, etc. OSFs en la capa de la gestión de servicio obran recíprocamente con OSFs en igual u otras capas dentro del mismo TMN a través de un punto de referencia de q y en el otro TMNs a través de un punto de referencia de x. La capa de la gestión de servicio es responsable de todas las negociaciones y acuerdos contractuales que resultan entre el cliente (potencial) y el servicio(s) ofrecido a este cliente. 2.3.5.5. Capa de Gestión de negocio La capa de la gestión de negocio tiene la responsabilidad de la empresa total. La capa de la gestión de negocio abarca la funcionalidad propietaria. Para prevenir el acceso a su funcionalidad, el negocio de OSFs no apoya normalmente puntos de referencia de x. El acceso de la capa de gestión de negocio OSFs es la información y la funcionalidad en la otra gestión acordada. La capa de la gestión de negocio se incluye en la arquitectura de TMN para facilitar la especificación de la capacidad que requiere de las otras capas de la gestión. Esta capa realiza normalmente la meta que fija tareas, más bien que el logro de la meta, pero puede convertirse en el punto focal para la acción en los casos para donde la acción ejecutiva se llama. Esta capa es parte de la gestión total de la empresa y muchas interacciones son necesarias con otros sistemas de gestión. Mientras que las funciones principales de las capas de la dirección del servicio y de la red son la utilización óptima de los recursos existentes de las telecomunicaciones, las de la capa de la gestión de negocio están para la inversión y el uso óptimos de nuevos recursos. OSFs en la capa de la gestión de negocio que obran recíprocamente con OSFs en igual u otras capas dentro del mismo TMN a través de un punto de referencia de q. La capa de la gestión de negocio tiene los cuatro papeles principales siguientes: 1) Soporte del procedimiento de toma de decisión para la inversión y el uso óptimo de los nuevos recursos de telecomunicaciones; 2) Soporte de la gestión del presupuesto relacionado de OA&M; 3) Soporte de la fuente y de la demanda de la mano de obra relacionada de OA&M; 4) Datos agregados el mantener sobre la empresa total. 27 2.3.5.6. Principios de capas de información Los modelos de la información de la gestión se asocian a capas y se pueden utilizar para el intercambio de la información en las interfaces de la capa intermediaria. El figura 2.11 representa los puntos de referencia de una capa dada. El modelo de la información asociado al punto de referencia a la capa superior q n+1, n proporcionar a esa capa la opinión de la gestión de la capa " n ". tiene que Las mismas consideraciones se aplican a la interfaz de x. Los puntos de referencia a OSFs en la misma capa, q n,n deben tener un modelo de la información referente a funcionalidad de la capa " n ". El punto de referencia a la capa más baja q n,n –1 por la misma razón tiene que representar la vista de la capa " n –1 ". Para cualquier capa lógica, las relaciones se pueden establecer entre las funcionalidades básicas de la capa de OSF. Cualquier relación entre los modelos de la información de la gestión están asociadas a diversas capas se puede ser visibles en las interfaces, tales como esta descrito en el modelo general de la relación (GRM, recomendación X.725). El modelo general de LLA puede ser utilizado bajo varias condiciones para la creación de tantas capas como sean deseadas/apropriadas e imponer la restricción para simplificar las relaciones entre las capas. OSF Layer "n+1" qn+1,n OSF Layer "n" qn,n OSF Layer "n" qn,n–1 OSF Layer "n-1" T0405970-95 Figura 2.11 /M.3010 Los puntos de referencia en un OSF funcional dado acodan " n " 28 Entre cada capa existe una función de agente que representa a todos los objetos gestionados, además que entre cada capa y una función de gestor que controla y se coordina con el agente (y objetos gestionados) del siguiente nivel. 2.3.5.7 Interacción funcional entre las capas de gestión Mientras que OSF obrará recíprocamente con los componentes de función de TMN en capas adyacentes lógicas de la gestión las consideraciones operacionales y la gestión puede apoyar la necesidad de interacciones entre las capas no adyacentes. Por ejemplo, debido a las consideraciones del tráfico de TMN, la capa de gestión del servicio puede desear trabajar recíprocamente directamente con la capa de la gestión del elemento para el intercambio de los datos contables. 2.4. Arquitectura de la información de TMN 2.4.1 Principios La gestión de un ambiente de telecomunicaciones es un uso del tratamiento de la información. Para manejar con eficacia las redes complejas y para apoyar procesos de la capa de negocio del abastecedor de la red operador/servicio, es necesario intercambiar la información de la gestión entre los usos de la gestión puestos en ejecución en el manejo del múltiplo y los sistemas manejados. Así la gestión de telecomunicación es un uso distribuido. La arquitectura de información de TMN, para promover interoperabilidad, se basa en los paradigmas abiertos estandarizados de la gestión que apoyan a modelar la estandarización de la información que se comunicará. Las actividades de estandarización de TMN no desarrollarán un paradigma específico sino la estructura de la gestión sobre las soluciones reconocidas industrialmente, centrándose sobre todo en técnicas orientadas a objetos. La estandardización de TMN favorece la reutilidad de las definiciones estandarizadas de la información para reducir el esfuerzo total de la estandarización. Las técnicas orientadas al objeto tales como encapsulación, herencia, y especialización están referidas a la estandarización. Donde se espera que la información sea utilizada conjuntamente con más de un paradigma de la gestión, la información se debe primero definir de una manera de paradigma-neutral que utiliza técnicas de industria-reconocidas después sobre los formatos paradigma-específicos. 29 Debe ser observado en las técnicas, por ejemplo, orientado a objetos, aplicadas a definir la información que se intercambiará no deben obligar la puesta en práctica interna de la gestión de las telecomunicaciones o de los sistemas manejados. La información y las acciones de la gestión desempeñan los papeles cruciales de administraciones, las técnicas de la seguridad tienen que ser aplicadas en el ambiente de TMN para establecer la seguridad de la información intercambiada sobre las interfaces y residir en el uso de la gestión. Los principios y los mecanismos de seguridad también se relacionan con el control de los derechos de acceso de los usuarios de TMN a la información asociada a usos de TMN. La puesta en práctica de un sistema interno está fuera del alcance de la estandardización de TMN. Los principios arquitectónicos de la información de TMN se aplican a las especificaciones de interfaz usando la metodología y las técnicas especificadas en la recomendación [M.3020]. La arquitectura de información de TMN se estructura de los elementos fundamentales siguientes: puntos de referencia, modelos de la información, elementos de información, modelo de la información de un punto de referencia y modelos de la interacción. El intercambio de información de la gestión de TMN que se pondrá en ejecución y se puede entonces describir en términos de estos elementos fundamentales. 2.4.2. Modelo de la interacción Un modelo de la interacción de TMN proporciona las reglas y los patrones que gobiernan el flujo de la información entre los componentes de función de TMN en un punto de referencia. Los modelos posibles de la interacción incluyen manager/agent, client/server, invoker/responder, el par-a-par, publisher/subscriber, y consumer/producer y se asocian a un paradigma específico de la gestión. Para el intercambio de la información de gestión, los procesos de la gestión tomarán dos papeles posibles: • El papel manejado: un proceso que maneja los elementos de información de TMN se asocia a los recursos manejados. El actuar de proceso en este papel responde a los directorios publicados por el proceso que actúa en el papel del manejo. También reflejará al proceso que actúa en el papel de manejo a una vista de estos elementos de información y proporcionará el comportamiento de reflejo del recurso de la información (por ejemplo. fuente de información); 30 • El papel del manejo: un proceso que publica directorios de la operación de la gestión y recibe la información del proceso que actúa en el papel manejado (por ejemplo: usuario de la información). Es la responsabilidad del usuario de información en tratar la fuente de información de una manera que responderá a la fuente de información correctamente. Además, el usuario de la información es responsable de analizar lo que proporciona la fuente de información. Definen a un encargado de TMN para ser el actuar de proceso de la gestión en el papel del manejo, mientras que un agente de TMN se define para ser un proceso que actúa en un papel manejado. El modelo de la interacción relevante a un par de manager/agent es determinado por el paradigma de la gestión seleccionada. 2.4.3. Los modelos de gestión de información deTMN La arquitectura de la información de TMN contiene las construcciones llamadas los modelos de la información que son apoyados por los papeles manejados de los bloques de la función y el conocimiento compartido de la gestión que es sabido por la componente de función de papeles del manejo. Como ejemplos, los modelos de la información se pueden encontrar en recomendaciones de la serie de ITU-T: M.31xx [ 15 ], X.73x [ 16 ], G.85x [17 ], y Q.82x [ 18 ]. Un modelo de la información de gestión de TMN presenta una abstracción de los aspectos de la gestión de los recursos de la red y de las actividades relacionadas de la gestión de soporte. El modelo determina el alcance de la información que se puede exponer e intercambiar de una manera estandarizada. Esta actividad para apoyar el modelo de la información ocurre en el nivel del uso e implica una variedad de usos de la gestión tales como almacenar la información, de recuperación y de proceso. Los modelos múltiples de la información son necesarios para describir la gama de la información completa que se intercambiará para la gestión de la telecomunicación. 2.4.4. Elementos de información de la gestión de TMN Los modelos de la información de la gestión de TMN consisten en elementos de información de gestión de TMN. Los sistemas de gestión intercambian la información modelada en términos de los elementos de información de TMN. Los elementos de información de TMN pueden ser vistos conceptuales del tipo de recurso que se están manejando o pueden existir para apoyar ciertas funciones de la gestión (por ejemplo: expedición del 31 acontecimiento o acontecimiento que registra). Así, un elemento de información es la abstracción de tal recurso por el cual represente sus características según lo visto y para los propósitos de la gestión. En paradigmas orientados al objeto, los elementos de información de TMN se modelan como objetos. 2.4.5. Modelo de la información de un punto de referencia Un subconjunto de esta información expuesta, que se puede considerar el modelo de la información de un punto de referencia, seguido a cada punto de referencia, basado en las interacciones funcionales definidas para el punto de referencia. Este modelo de la información de un punto de referencia es el mínimo de la información expuesta de la gestión que se puede especificar en un bloque de la función de TMN. 2.4.6. Puntos de referencia Este punto de referencia de información-especificada de TMN define el concepto del punto de referencia (más allá de la definición funcional de la arquitectura de TMN); el concepto del punto de referencia se unifica en el TMN funcional y arquitecturas de la información. Los bloques de la función de TMN obran recíprocamente vía funciones de la gestión de TMN sobre un punto de referencia. Sobre el mismo punto de referencia, las componentes de función de TMN comunican la información apropiada de la gestión para realizar la funcionalidad especificada de la gestión de TMN. Los puntos de referencia tienen significado en lo funcional en el intercambio de información, las especificaciones que conducen a una puesta en práctica. Un punto de referencia representa las interacciones y el intercambio de información funcionales entre las componentes de la función. El concepto del punto de referencia es importante porque representa el agregado de todas las capacidades con el intercambio de información asociado que una componente particular de la función que busca de otra componente particular de la función, o las componentes equivalentes de la función. También representa el agregado de todas las operaciones y/o notificaciones (según lo definido en la recomendación X.703 de ITU-T) que una componente de la función puede proporcionar a una componente de la función de petición. El Punto Funcional especificado e Información-especificada de TMN de referencia generalmente a una interfaz física a ser puesta en ejecución, en la arquitectura física de 32 TMN, si las componentes de la función se ponen en ejecución en diversos componentes físicos. 2.4.7. Arquitectura lógica por capas de TMN dentro de la arquitectura de la información de TMN Según la cláusula 9 de la recomendación M.3010, la arquitectura lógica por capas (LLA) es un concepto para la estructuración de la funcionalidad de la gestión que organiza las funciones en las agrupaciones llamadas las " capas lógicas " y describe la relación entre las capas. Una capa lógica refleja los aspectos particulares de la gestión dispuestas por diversos niveles de abstracción. Las interacciones funcionales entre los bloques de la función de OSF dentro de diversas capas lógicas son descritas por el punto de referencia. Sobre el mismo punto de referencia, las componentes de función de TMN comunican la información apropiada de la gestión para realizar la funcionalidad especificada de la gestión de TMN. La relación de la arquitectura lógica por capas y la arquitectura de la información de TMN puede ser descrita proyectando la arquitectura de la información de TMN con una serie de opiniones. Cada visión representa los elementos de información de los modelos de la información que se pueden exponer o intercambiar en los puntos de referencia entre los bloques de la función en las capas del LLA. La visión abarca el nivel necesario de la abstracción necesaria para el intercambio de la información de la gestión en el nivel de la abstracción capturado en la capa. El intercambio de la información de la gestión entre las capas lógicas emplea los papeles de gestión de manejo que interactúan con el modelo de TMN. Esto permite que no se asocien las actividades de la gestión y sean relacionadas en capas por lo que los papeles manejados serán asociados a un sistema de elementos de información del modelo(s) de la información que expone una visión en el nivel de la capa de la abstracción (por ejemplo. equipo, elemento, red, servicio). Generalmente, el manejo y los papeles manejados se pueden poner en capas lógicas sin restricción. Un papel de manejo se puede asociar a un sistema de elementos de información de cualquier capa. Los papeles manejados pueden ser puestos en cualquier capa e invocar las operaciones asociadas a cualquier otro papel manejado. 33 2.4.8. Arquitectura de la comprobación de TMN La arquitectura física de TMN se estructura de los elementos fundamentales siguientes: componentes de comprobación e interfaces físicas. El figura 2.11 demuestra un ejemplo de una arquitectura física simplificada para un TMN. Este ejemplo se proporciona a la ayuda en entender los componentes s físicos de TMN descritos abajo. DCN Red de comunicación de datos NE Elemento de red OS Sistema de operaciones WS Estación de Trabajo Figura 2.11. Arquitectura física simplificada de un TMN 2.5. Gestión de desempeño TMN 2.5.1. Introducción Como parte de las expectativas del desarrollo de esta trabajo, en el que esta enfocado a cubrir los aspectos de gestión de desempeño, de una red, establecemos el uso de las 34 recomendaciones establecidas por la ITU-T (m.3010, m3020, X.7XX), donde ya se han explicado su definición, su composición y su funcionamiento; donde ahora en éste apartado, es en enfocarnos a establecer la planeación y metodología a llevar para la obtención de resultados en el modo de funcionamiento y operación de abstracción en el control de información que ayuda a poder prever la funcionalidad y desempeño de una red de telecomunicaciones, pero debemos hacer énfasis en que la función de desempeño esta íntimamente relacionada con la función de servicio, ya que partimos en obtener resultados en un mejoramiento que puede existir en el desarrollo, y que es en base a la Gestión de Redes de Telecomunicaciones que se nos es ofrecida, e intentamos adaptarla y descomponiéndola en sus diferentes componentes para la implementación e identificación de los sectores de interés de una red de telecomunicaciones. 2.5.2. Areas funcionales de TMN Dado a la necesidad de abarcar con más profundidad los aspectos relacionados al objetivo de la tesis, que nos orienta primeramente al estudio del modelo TMN, así como sus áreas funcionales, sus componentes, así como las capas de arquitectura lógica del TMN, es necesario abarcar la funcionalidad de TMN con todos los elementos estudiados el conocer la Gestión de Desempeño y esto lo haremos conforme a las áreas funcionales de TMN.Dentro de la función global de la TMN, y dada la compatibilidad con el modelo OSI, se observan las Areas Funcionales de Gestión Específica (Specifications Mannagement Functional Areas: SMFAs), a las cuales comúnmente se les refiere como FCAPS: Gestión de Fallos, de Configuración, de Contabilidad, de Comportamiento y de Seguridad (Figura 2.12). Q3 AGENTE Gesto Q3 F C A P S Q3 GESTOR Agente Q3 Figura 2.12. Areas Funcionales de la TMN 35 Las funciones TMN pueden ser agrupadas dentro de dos clases, Funciones Básicas (BF’s) y Funciones Avanzadas (EF’s). La BFs estarán siendo usadas como bloques de construcción para implementar EF tales como gestión de servicio, restauración de la red, clientes de control y re-configuración, gestión de ancho de banda, etc. Las funciones básicas pueden agruparse dentro de tres categorías.[Aida94] a. Gestión de funciones a. Gestión de configuración i. Provisionamiento ii. Estado iii. Instalación iv. Inicialización v. Inventario vi. Respaldo y restauración b. Gestión de fallos i. Alarma de seguridad (correlación, análisis, filtrado) ii. Localización de fallos iii. Pruebas c. Gestión de desempeño i. Recolección de datos ii. Filtrado de datos iii. Análisis de tendencias d. Gestión de contabilidad i. Contabilidad colecta de datos ii. Proceso y modificación de registros de contabilidad e. Gestión de seguridad i. Proporcione el acceso seguro para funciones y compatibilidades NE (elementos de red) ii. Proporciona el acceso seguro para componentes TMN ( sistemas de las operaciones (OS), controladores de subred (SNC), equipos de mediación (MD)). b. Función de comunicación 36 a. Comunicaciones OS/OS b. Comunicaciones OS/NE c. Comunicaciones NE/NE d. Comunicaciones OS/workstation (WS) e. Comunicaciones NE/WS c. Funciones de planeación Esta función no es especificada en la ITU-T recomendación M.30 y .3010. Esto es sin embargo, función importante en la gestión de red. - Planeación de la red ( incluye recursos físicos (fácilmente, equipamiento, etc), de planeación) - Planeación de fuerza de trabajo. En todos los casos existe una interfaz entre el gestor y el agente para la interconexión interoperabilidad y comunicaciones de los diferentes tipos de información, sistemas de gestión y equipo. Para comunicar estos elementos entre capas de gestión, o de un proveedor a otro, se usan interfaces abiertas tales como la Interfaz Q3, para comunicaciones “intra-red” (red de un solo proveedor) y la Interfaz X, para comunicaciones entre proveedores (Figura 2.13). INTERFAZ Q3 Gestión Interna de Red INTERFAZ X Comunicación y Gestión de Red entre Proveedores Figura 2.13. Comunicación y Gestión Intra/Inter TMNs La Gestión de desempeño de una red es la parte critica de una Gestión de Red de Telecomunicaciones (TMN) que asegura que esta operando eficientemente y con una 37 entrega de grado de prescripción de servicio. Las medidas operacionales de la gestión de desempeño tienen una entrada dominante a los ajustes de los procesos de planeamiento para el crecimiento de la demanda y para el aprovisionamiento de los recursos a los procesos en su punto de operación real o escases inminente en los recursos. La gestión de desempeño, como la gestión de fallos, asegura que los recursos operan de una manera sin problemas y sin error, dependiendo de la gestión de configuración y la gestión de servicios, el inventario del recurso da referencia a las medidas de monitoreo y direccionamiento de los mensajes de control de la red. La perspectiva se adopta aquí en las operaciones direccionadas de cómo pueden ser aplicables para una compañía de operación, de portador común, operador de red privada, o un proveedor de servicios avanzados. Aquí ellos serán colectivamente referidos a compañías de operación telefónica y sus servicios de red, y serán referidos a Telecomunicaciones de redes y servicios. La figura 2.13 muestra el mapeo entre las funciones de gestión de telecomunicaciones tradicionales (operaciones, administración, mantenimiento y provisionamiento (OAM&P siglas en ingles) junto con el planteamiento y las funciones de sistemas abiertos de interconexión ( OSI), parte que es utilizada por el sistema de Gestión TMN. T e le c o m u n ic a c io n e s t r a d ic io n a le s F u n c io n e s d e G e s t ió n ( O A M & P ) S is t e m a a b ie r to d e in t e r c o n e x ió n ( O S I ) F u n c io n e s O p e r a c io n e s F a c t u r a c ió n G e s tió n d e tr á f ic o A d m iis t r a c ió n G e s tió n d e r e d G e tió n d e T r a f ic o M a n t e n im ie n t o S e g u r id a d d e a la r m a L o c a liz a c ió n d e f a llo P r u e b a d e c ir c u it o M o n it o r e o d e d e s e m p e ñ o E s ta d o y c o n tro l G e s t ió n d e C o n t a b ilid a d G e s tió n d e d e s e m p e ñ o G e s t ió n d e F a llo s G e s t ió n d e s e g u r id a d P r o v ic io n a m ie n t o P la n e a c ió n G e s t ió n d e c o n f ig u r a c ió n Figura 2.13. Mapeo entre las funciones de gestión de telecomunicaciones tradicionales OAM&P vs.OSI La gestión de desempeño abarca las funciones de gestión de tráfico de operaciones así como las funciones de red y las funciones de gestión de tráfico en la administración y las 38 funciones de monitoreo de desempeño de mantenimiento. Ha habido muchos esfuerzos de estandarizaciones para la gestión de red y la gestión de monitoreo entre corporaciones de estándares. El cual provee un concepto funcional del marco de trabajo para la gestión de OSI incluyendo gestión de desempeño. Entre las 5 áreas funcionales vistas en la figura 2.13 bajo OSI, la gestión de desempeño esta disponible en el comportamiento para los recursos en el ambiente OSI y lo efectivo en las actividades de comunicación para ser evaluadas. La gestión de desempeño incluye funciones para información estadística, mantenimiento, y examina los registros del estado histórico del sistema; el sistema de desempeño se determina bajo condiciones naturales y artificiales, y son alterados los modos de sistema de operación para propósitos de conducción de actividades de gestión de desempeño. [Aida94] Esta sección inicia con una breve revisión del mapeo de las funciones tradicionales OAM&P dentro de las funciones OSI. Estas funciones OSI son usadas principalmente para manejar tres partes interrelacionadas de una red de telecomunicaciones, conmutación, facilidad de interoperación y distribución ( o loop local) como se muestra en la figura 2.14 Las actividades de la Gestión de Desempeño de estas partes pueden estar en tres diversos niveles 1. El nivel del diseño físico como en el caso de la transmisión inadecuada a través de instalaciones entre oficinas y del reenvío local. 2. El nivel de tráfico (Dirección no física) en conmutadores bloqueados 3. Análisis del nivel de falla, o el análisis de la falla debido a la carencia del mantenimiento Este capítulo trata de diferentes aspectos de gestión de desempeño; metas procesos, implementación, sistemas de operación de soporte, y futuro o evolución de la dirección de la gestión de desempeño que serán discutidas en orden cronológico. Sin embargo, los ejemplos de estos diferentes aspectos son derivados de tres diferentes partes en tres diferentes niveles para algo específico. 39 Conmutación Subcriptor Conmutación EO Interoperación TM Loop Interoperación Subcriptor Conmutación Loop EO EO; Fin de conmutación de operación TM: Conmutación Tandem Figura 2.14 Tres partes de una red de telecomunicaciones 2.5.3. Metas y Aspectos de gestión de desempeño La meta de la Gestión de desempeño es para el mantenimiento de la calidad de servicio (QoS) de una manera de costo-beneficio. El mantenimiento del QoS esta por el proceso del servicio de evaluación que inicia con la caracterización de la red seguida por la fijación de los objetivos de desempeño y medida. El control de los parámetros de la red se están ejercitando para improvisar el servicio y el desempeño. Un aspecto importante del QoS es que el tiempo para el servicio de provisionamiento que esta iniciado en QoS, así interviene el ambiente de la gestión de configuración y gestión de desempeño. Las próximas subsecciones describe la caracterización de la red, el fijar los objetivos de desempeño, la medida de desempeño y el control de QoS. 2.5.4 Caracterización de la red Este paso envuelve algunos subpasos que describe, el análisis, las medidas de clientes ingresados con las características de los servicios y su relación con los parámetros de desempeño de la red. Aquí la expectación del servicio que esta analizado en términos de la característica de la red para determinar el desarrollo del desempeño de la red y que se puede prever en términos actuales su mismo desarrollo. Esto es lo acostumbrado en los 40 estudios de la caracterización del desempeño de la red en redes existentes donde se fija el objetivo del desempeño, esto para determinar si el desempeño es adecuado y los nuevos servicios propuestos, y para indicar donde cambia los objetivos y el diseño de la red, que se podría permitir para improvisar el desempeño o establecer bajos costos. Por otra parte, los nuevos servicios y tecnologías, ejemplos como ISDN y las redes avanzadas inteligentes (AIN), necesitan tal caracterización para prever datos críticos en la fase introductoria. Las nuevas estructuras de red por ejemplo, separación de redes interLATA e intra-LATA o una red multicapa como el sistema de señalización / (SS7), necesita tal caracterización para establecer criterios de desempeño separados para diferentes partes de la red. La actual tendencia es mecanizar la caracterización del desempeño y reutilización de las componentes de caracterización. Figura 2.15 muestra un resumen de los procesos de caracterización que produce la documentación relacionada e incluye sistemas de monitorización. P la n e a c ió n d e l d e s e m p e ñ o -N u e v o s s e rv ic io s -N u e v a T e c n o lo g ia E s tu d io d e C a ra c te riz a c ió n d e D is e ñ o -T e c n o lo g ía A v a n z a d a d e m e d ic ió n -M e to d o s d e m u e s tre o y a n a lis is E s tu d io s d e C a ra c te riz a c ió n D o c u m e n to s R e la c io n a d o s a l D e s e m p e ñ o R e fe re n c ia D o c u m e n to s T é c n ic o s S e rv ic io d e R e d E s p e c ta tiv a s d e D esem peño D e s e m p e ñ o in te rn o S is te m a s d e v ig ila n c ia P la n e a c io n d e S is te m a s d e v ig ila n c ia C am paña de T a rific a c ió n Y M a rk e tin g M IB G e n e ra l de A d m in is ra c ió n In te rfa c e d e u s u a rio E q u ip o M e d ic ió n Base de D a to s Figura 2.15 Resumen del proceso del desempeño de planeación y caracterización. 2.5.5 Fijar objetivos de desempeño Los objetivos de desempeño aseguran un nivel de satisfacción de servicios para los clientes mientras sean rentables para los proveedores de servicio. Por otra parte los clientes necesitan sus percepciones con respecto al cambio de servicio con el tiempo. También, los cambios de la estructura del coste para ser abastecida con tecnología. Estos 41 factores dictaminan que los objetivos fijados para los elementos de desempeño de las redes de telecomunicaciones pueden ser un proceso interactivo. Los principales pasos para este proceso son: - Dividir la red dentro de los componentes del tamaño manejable y la descripción y la cuantificación de la operación o desempeño de cada elemento usando modelos matemáticos basados en medidas hechas durante el proceso de la caracterización. - Determinar la opinión y aceptar los niveles para pruebas subjetivas ( o pruebas de laboratorio si los usuarios son equipados tales como computadoras). - Determinando la distribución de calidad de servicio para los clientes - Formular objetivos de desempeño. La interacción en estos procesos de objetivo fijo son generalmente estimulados por la disponibilidad de una nueva tecnología, la cual es permitida para los propósitos de las nuevas tecnologías de costo-ahorro o cambios de redito-estimulo para la red. Un propósito de esto es primero que serán evaluados por estudios sensitivos de modelos al existir una red. Estos estudios desarrollados estiman la operación o efectos de desempeño de lo propuesto, el impacto sobre los servicios, y el costo de realización de estos efectos. La obtención de resultados aceptables, y estar integrados en el ensayo de una pequeña escala de la aplicación a los propósitos que pueden ser conducidos. Aquí, el grado de la calidad de servicio, se determina y los objetivos de desempeño son formulados. Si los resultados de las aplicaciones de ensayo son satisfactorios, el propósito puede ser implementado a través del sistema. Algunos de los cambios han estado incorporados a la red de telecomunicaciones, el desempeño o significancia operacional son caracterizados en su ganancia, los modelos matemáticos son redefinidos, un nuevo grado de servicio son determinados, y los objetivos son reformulados. En estas etapas, la integración de servicios estándares, los objetivos de servicio del componente, los objetivos de ingeniería, y el control administrativo toman lugar. 2.5.6 Proceso de gestión de desempeño Gestión de desempeño provee funciones para evaluar y hacer reportes en el comportamiento del equipamiento de telecomunicaciones y los efectivos de la red o NE. Hay dos aspectos primarios de gestión de desempeño: Monitoreo y Control. 42 2.5.6.1. Monitoreo de desempeño. Envuelve la colección continua de datos concerniente al desempeño de la NE. Muy baja tasa o error intermitente o condiciones de congestión en equipo de unidades de equipamiento múltiple pueden interactuar, resultando un servicio pobre de calidad. El monitoreo de desempeño esta diseñado para medir la calidad total de los parámetros monitoreados para detectar tales deterioros. Esto puede también ser diseñado para detectar características de formatos antes que la calidad de servicio ha caído bajo un nivel aceptable. La función básica de monitoreo de desempeño esta para una pista de sistema, una red, o actividades de servicio para trazar los datos apropiados para determinar el desempeño. 2.5.6.2. Control de desempeño. Involucra la administración de información que guía o soporta la función de gestión de la red y las aplicaciones o modificaciones de control de tráfico para ayudar a prever la gestión de red. y la aplicación o las modificaciones del control de tráfico para ayudar a proporcionar gestión de la red. Para ello se han desarrollado cierta cantidad de sistemas los cuales nos orientan en el control de amplitud que cubre una larga porción de una red local que proporcione la mayoría de la operaciones funcionales. La intervención de elementos de la red son distribuidos, tienen un control de amplitud limitado para ellos mismos, y tienen relativamente limitada una posición en las operaciones funcionales. En ello usamos interfaces que operan en un sistema TMN. Para elaborar en el futuro los dos aspectos del proceso de gestión de desempeño (monitoreo y desempeño), es importante discutir el propósito de la función operacional vista de las tres capas de la arquitectura de TMN: la capa de gestión de red (NML), la capa de gestión de elemento (EML), y la capa de elemento (EL), 2.5.7. Metodología La metodología que llevaremos a cabo será de acuerdo a las recomendaciones propuestas por la ITU-T (M.3020), Parte esencial de nuestro estudio, ya que el interés es enfocarnos en los aspectos de gestión de servicio y red, que mostrara la gestión de desempeño de acuerdo a nuestro objetivo. Esta recomendación de ITU-T describe la metodología UTRAD (requisitos unificados, análisis y diseño de la especificación de interfaz de TMN). Describe el proceso para derivar las especificaciones de interfaz basadas en las exigencias del consumidor, el 43 análisis y el diseño (RAD). Las pautas se dan para describir y usar del RAD unificado modelando la notación de la lengua (UML); sin embargo, otras técnicas de la especificación de interfaz son posibles. Las pautas para usar UML se describen en un alto nivel en esta recomendación de ITU-T. Recomendaciones más futuras de ITU-T en esta serie proporcionarán una definición más detallada del uso específico de la notación de UML dentro del TMN. Una especificación de interfaz trata los servicios de la gestión definida en la recomendación [M.3200]. De acuerdo a la ITU-T que es una especificación que puede apoyar la parte de o unos o más servicios de la gestión. Los servicios de la gestión abarcan de funciones de la gestión. Estas funciones pueden referirse a las definidas por la recomendación [M.3400] de ITU-T, estas se especializan para satisfacer un área manejada específica o las nuevas funciones y se pueden identificar como apropiadas. En la figura 2.16, se muestra la estructura de la metodología así como los conceptos que intervienen y que definiremos, cabe recordar que la definición de los conceptos puede que no exista relación con nuestro trabajo, pero en la sección de aplicación se tomarán y se descompondrán de acuerdo a nuestras necesidades de proyección y planeación de sistema. Cabe mencionar que de acuerdo a la figura 2.3 (Relación de normas de las recomendaciones de ITU-T para TMN), da una visión del cómo puede intervenir esta recomendación (M.3020), la cual es una especificación sobre las interfases TMN a la cual da una metodología y que llega siendo la parte clave y media entre las funciones de operación y servicio, así como su intervención en que si no existiera este apartado, no existiría relativamente Gestión de Red con TMN, y se apega al funcionamiento de ingeniería de tráfico y QoS, en términos de conectividad de Tecnologías. Transición en TMN : M.3020 Especificación de la metodogía de la Interface TMN Requerimientos Análisis Diseño Implementación Figura 2.16 Metodología Rec-ITU-T-M.3020 44 2.5.7.1. Consideraciones generales El propósito de esta metodología es proporcionar una descripción de los procesos que conducen hacia la definición de las interfaces de TMN. 2.5.7.2. Uso y estructura de la metodología La metodología unificada de los requisitos, del análisis y del diseño de TMN (UTRAD) especifica un proceso trifásico iterativo con las características que permiten rastrear a través de las tres fases. Las tres fases aplican técnicas aceptadas en la industria usando principios orientado a objeto del análisis y del diseño. Las tres fases son requisitos, análisis y diseño. Las técnicas deben permitir el uso o el desarrollo de los instrumentos de apoyo comercialmente disponibles. Diversas técnicas se pueden utilizar para las fases dependiendo de la naturaleza del problema. 2.5.7.3. Metodología detallada Los requisitos y las fases de análisis producen especificaciones de UML(Unified Modeling Language). La fase del diseño utiliza la notación del específico del paradigma de la dirección de la red. Las salidas de las 3 fases son: • Requisitos de la fase – de los requisitos. • Especificación independiente – de la puesta en práctica de la fase de análisis. • Especificación del específico – de la tecnología de la fase del diseño. Inicialmente, la fase del diseño será desarrollada usando un manual o un acercamiento modificado para requisitos particulares. Cuando el protocolo es interoperable la definición específica se puede generar por las herramientas, después la notación de UML se puede aplicar a la fase del diseño. Sin embargo algunos las definiciones específicas del protocolo, tales como jerarquía de la clase, se pueden representar usando la notación de UML. Las subclases abajo describen las tres fases. 2.5.7.4. Requisitos Los requisitos es una solución que se presenta en un problema de caída y da dos clases. La primera clase de requisitos se refiere aquí como requisitos del negocio. Un experto del tema podrá determinar que los requisitos representan adecuadamente las necesidades del problema de gestión que es solucionado. La segunda clase se refiere como requisitos de la especificación. Estos requisitos proporcionarán los suficientes detalles para poder desarrollar la definición de interfaz en la fase del análisis y del diseño. 45 Mientras que las definiciones de interfaz finales deben ser detectables a los requisitos, puede ser necesario tener un proceso iterativo entre las tres fases. Cualquier ambigüedad en los requisitos tendrá que ser resuelta por este proceso iterativo para asegurar que una especificación realizable puede ser desarrollada. Diversas técnicas se pueden utilizar para especificar las dos clases de requisito. Independiente de la técnica, la legibilidad de los requisitos es crítica. Los requisitos no se requieren para estar en una notación legible por la máquina mientras la legibilidad y el rastro estén dispuestos. La enumeración de requisitos es un acercamiento posible para delinear los diversos requisitos para el rastreo. La fase de los requisitos incluye identificar aspectos tales como política de seguridad, el alcance del dominio al problema en los términos de los usos, recursos, y papeles asumidos por los recursos. Los requisitos especifican papeles, responsabilidades, y las relaciones entre las entidades constitutivas para el espacio del problema. Diversas técnicas incluyendo la representación textual se pueden utilizar para especificar los requisitos del nivel del negocio. Para facilitar el rastreo de estos requisitos a las fases del diseño y de la puesta en práctica, enumerando requisitos recomendados. El problema se debe limitar con un alcance específico. Una forma para determinar el alcance está usando los servicios de gestión que son identificados en la recomendación M.3200 de ITU-T y los sistemas de la función identificados en M.3400. Los requerimientos se especifican usando los recursos que son manejados y las funciones de la gestión de TMN. Aumentar la recomendación M.3400 de ITU-T se puede requerir para resolver los requisitos del negocio del problema. Los casos y los panoramas del uso de UML se deben utilizar para obrar recíprocamente con los expertos del tema en capturar los requisitos del nivel del negocio. Los requisitos deben también identificar las condiciones de la falta visibles al proceso del negocio. Los requisitos producidos deben ser completos y detallados. La naturaleza recurrente de la metodología de UTRAD se utiliza para alcanzar por completo los requisitos de operación (claros y bien documentados) que conduce las fases del análisis y del diseño. 2.5.7.5. Análisis En la fase de análisis, se utilizan los requisitos para identificar las entidades que obran recíprocamente, sus características y las relaciones entre ellas. Esto permite las interfaces ofrecidas por las entidades que se definirán. En la notación de UML, estas entidades se convierten en clases. Las descripciones de la clase junto con las interfaces 46 expuestas deben ser detectables a los requisitos. La relación entre las clases, definidas en la especificación del análisis, y las clases en la especificación del diseño no es necesariamente una a una. Esta recomendación de ITU-T da la dirección de alto nivel en el uso de la notación de UML a la especificación de interfaz de la ayuda TMN. La fase de análisis debe ser independiente a los factores de diseño. Por ejemplo el análisis se puede documentar usando principios de OO (Orientación de objetos) aunque el diseño puede utilizar una tecnología orientada no-objeto. La información especificada en la fase de análisis incluye descripciones de la clase, definiciones de los datos, relaciones de la clase, diagramas de la interacción (los diagramas de secuencia y/o los diagramas de la colaboración), diagramas de la transición del estado y diagramas de la actividad. Las definiciones de la clase incluyen la especificación de operaciones, señalan (estímulo asincrónico tal como recibo de operaciones, de acontecimientos y de excepciones), las cualidades y comportamiento capturados como notas o descripción textual. 2.5.7.6. Diseño En la fase del diseño se produce una especificación de interfaz interoperable realizable. Las especificaciones de la fase del diseño son dependientes en el paradigma específico de la dirección de la red de TMN. La selección del paradigma específico de TMN se trata en otras recomendaciones de TMN. En el contexto del paradigma de TMN basado en la gestión de sistemas de OSI, la especificación del diseño es la especificación del modelo de información usando las plantillas de GDMO para las clases manejadas del objeto, cualidades, comportamiento, notificaciones, acciones, nombrando los casos de la clase, y las especificaciones de error / excepción. La sintaxis de la información se especifica usando la notación ASN.1. En GDMO, la jerarquía de la clase del objeto especifica las características de las clases del objeto que son necesarias para la gestión. Se especifican las clases del objeto usando las plantillas de la recomendación X.722, pautas de ITU-T – de la Estructura de la Gestión de Información para la definición de objetos manejados. Las plantillas que definen el modelo de la información se deben colocar (según las reglas de la recomendación X.722 de ITU-T) con un valor para el identificador del objeto ASN.1. Pues los paradigmas adicionales se agregan al TMN, el notations/languages definido por estos paradigmas será utilizado. 47 2.5.7.7. Especificaciones de interfaz TMN Una especificación de interfaz TMN incluye las especificaciones de los requisitos, del análisis y del diseño. Una estructura para especificar estas especificaciones se proporciona en el Guía de recomendaciones para la definición de la interfaz de la gestión (GDMI) y se encuentra en la Recomendación M.3020 de la ITU-T. Estas técnicas y notaciones de soporte son también aplicables al diseñar un sistema a las especificaciones de interfaz de TMN, aunque el diseño del sistema no se considera como parte de recomendaciones de TMN. Ayudan a describir cómo las especificaciones de interfaz se aplican en el manejo de los recursos dentro de un sistema tal como un NE. Esto lo podemos representar en la figura 2.17 que indica la relación de acuerdo a la relación de funciones de NE y OS en el diagrama de operación del OSF y el NEF y la intervención de la interfase. Donde observamos la interacción que existe entre una OSF y la NEF con el uso de interfaces TMN que es q3 representando las funciones de operación. Figura 2.17 Relación funcional entre la OSF y la NEF, con intervención del protocolo de gestión. Por otra parte de intervención de las componentes de función de TMN en este caso la MF, esta enfocada a ser la misma función de mediación en ambas operaciones de un sistema TMN o no-TMN. Así como las funciones de mediación intervienen de la siguiente manera en la figura 2.18 48 Figura 2.18. Funciones de Mediación 2.5.7.8 Metodología de especificación de servicios Parte de la aplicación de acuerdo a los servicios podemos enfocarnos a un ejemplo de descomposición de funciones de acuerdo a la recomendación M.3020, fundamentada en Gestión de Servicios: Un sistema EMIR (figura 2.19) proporciona un conjunto de servicios de gestión de telecomunicación que se concretan en los modos de trabajo de vigilancia, apoyo y atención. De acuerdo a la metodología establecida en la recomendación M.3020 y ampliada en los proyectos RACE (TERRACE y PRISM), estos servicios de gestión se estructuran en componentes de servicio (partes constituyentes de los servicios que agrupan requisitos de actuaciones sobre la red o el servicio gestionado, siendo, pues, un refinamiento de aquellos). La caracterización de los servicios y de los componentes del servicio se realiza considerando los aspectos relativos a la funcionalidad que se ofrece a los usuarios de la EMIR. El último refinamiento de los componentes de servicio de gestión de telecomunicación permite identificar Funciones de Gestión de Telecomunicación (FGTs) como el componente más pequeño de un servicio de gestión que puede ser percibido como tal por el usuario del servicio. Las funciones de gestión de telecomunicación proporcionan las funcionalidades (genéricas o especializadas) necesarias para las actividades de gestión. 49 V ig ila n c ia , A te n c ió n , A p o y o M FC G e s tió n C o n fig u r a c ió n - S e r v ic io s d e G e s tió n - C o m p o n e te s d e s e r v ic io s d e g s tió n S u p e r v is ió n a S O C ’s G e s tió n A la rm a M FC M FC G e s tió n re c a r g a s S u p e r v is ió n a S O C ’s -F u n c io n e s d e g e s tio n d e te le c o m u n ic a c io n e s s o b r e o b je tio s g e s tio n a d o s M FT M FC M FT M FC F u n c ió n d e G e s tió n d e C o m p o n e n te M FT O b je to s G e s tio n a d o s E n to rn o d e S is te m a R e a l M FT SM ASE M FS M FT SM ASE M FT M FS SM ASE M FT - E le m e n to s d e S e rv ic io d e A p lic a c ió n d e G e s tió n d e S is te m a s ( S M A S E s ) - F u n c io n e s d e G e s tió n d e S e rv ic io s M FS C M IS E /F T A M E n to rn o O S I Figura 2.19 Metodología de especificación y descomposición de servicios Estas FGTs actúan sobre los objetos gestionados, sea directamente (accediendo al servicio CMIS, por ejemplo), sea haciendo uso del servicio que proporcionan las funciones de gestión de sistemas abiertos agrupadas en los SMASEs. Las FGTs se encuentran dentro del entorno de sistema real, mientras que los SMASEs se encuentran dentro de entorno OSI. Los SMASEs, a su vez, se apoyan en otros elementos del servicio del nivel de aplicación (CMISE, FTAM, TP, ACSE, etc.). Los funciones de gestión de sistemas abiertos son funciones generales, como la gestión de alarmas (ISO 10164-4) ó gestión de pruebas (ISO 10164-12), que pueden ser empleadas por las FGTs. La metodología de la recomendación M.3020 de ITU-T se adopta. Según esto las recomendaciones de Gestión de Servicio esta compuesta por Componentes de Gestión de Servicio (MSCs) que alternadamente se construyen de los Componentes Funcionales de Gestión (MFCs). MFCs son construidos de los Sistemas de Función de Gestión (MFSs) de los cuales son los grupos de la gestión de funciones que pertenecen lógicamente juntas. 50 Capítulo 3. 3.Tecnologías de Redes Distribuidas de Banda Ancha ATM / MPLS 3.1 Introducción Dentro de las tecnologías de redes distribuidas de banda ancha, son construidas en base a los servicios que ofrecen y su necesidad para el manejo de grandes cantidades de información por lo que es importante considerar que los servicios son enfocados en el desarrollo de Internet que es un conjunto de redes, redes de computadoras y equipos físicamente unidos mediante cables que conectan puntos de todo el mundo. Estos cables se presentan en muchas formas: desde cables de red local (varias máquinas conectadas en una oficina o campus) a cables telefónicos convencionales, digitales y canales de fibra óptica que forman las "carreteras" principales. Esta gigantesca Red se difumina en ocasiones porque los datos pueden transmitirse vía satélite, o a través de servicios como la telefonía celular, o porque a veces no se sabe muy bien a dónde está conectada. Internet es una red de computadoras conectadas entre sí, con la característica de que se trata de una RED ABIERTA y de CARACTER MUNDIAL. Esto permite a los Usuarios intercambiar todo tipo de información desde cualquier punto, durante las 24 horas del día. Con respecto a lo enfocado a las necesidades del trabajo, el interés de mencionar una arquitectura de comunicaciones esta basado en su mejoramiento, pero parte de ello esta enfocado a establecer los servicios que ofrece internet y no es la base del estudio de su mejoramiento, por ello se plantea la búsqueda del mejoramiento de internet con los servicios propuestos por Internet 2. [Jimz2000] 51 3.1.1. Internet 2 Internet 2 es un consorcio no lucrativo, conducido por un gran número de universidades en conjunto con empresas y gobiernos de todo el mundo, desarrollando y desplegando aplicaciones avanzadas y tecnología de red, acelerando la creación del internet del futuro. Con la participación de varias compañías de vanguardia, internet 2 reconstruye la sociedad de la academia, la industria y del gobierno que ayudó al internet actual en su infancia. Lo hará así trabajando con la industria de la tecnología de información para desarrollar estándares y servicios de ayuda comunes para las nuevas clases de aplicaciones y para asegurar la disponibilidad de los servicios avanzados requeridos. Muchas de las tecnologías del servicio de las comunicaciones requeridas todavía están en las etapas pre-competitivas de desarrollo. [Jimz2000] 3.1.2 Surgimiento de Internet 2 Dentro y a través de muchas universidades está emergiendo un conjunto de aplicaciones avanzadas de red. Éstas enriquecerán ampliamente actividades como la enseñanza, el aprendizaje y la colaboración de la investigación. [Jimz2000] • La comunidad de investigación necesita una alta capacidad y calidad de servicio seleccionable, hacer un uso eficaz de los laboratorios nacionales, recursos de cómputo y de depósitos de datos masivos. • Los médicos investigadores necesitan ayuda para consulta y diagnósticos remotos altamente confiables y fiables en las comunicaciones. • Los científicos, físicos, especialmente los que ocupen hojas de datos astronómicas o geofísicas, masivas, tienen necesidades similares. • Como los datos comerciales de transacciones están en el foco de la investigación, los analistas financieros y económicos necesitarán el acceso en tiempo real a las bases de datos. APLICACIONES PERMITE MOTIVAN INGENIERIA Figura 3.1.- La ingeniería de Internet 2 es motivada por aplicaciones avanzadas. 52 Un impedimento importante a la realización de estas aplicaciones es la carencia de servicios avanzados de comunicaciones en el campo actual de Internet (figura 3.1). No hay todavía una “marco de prueba” en la cual demostrar su eficacia, mucho menos ponerlo en práctica a una escala amplia. En suma: Internet 2 busca permitir estas nuevas aplicaciones. Las necesidades para soportar aplicaciones avanzadas en redes han generado varias iniciativas de redes de alto rendimiento, que caminan paralelas y coinciden con Internet 2. Internet 2 en conjunto con estos otros esfuerzos irá ganando logros como la reducción de duplicación al mínimo, y la maximización de compatibilidad e inter-operabilidad entre redes y las aplicaciones resultantes. Podrá ser beneficiada un área amplia de prueba que abarca a la comunidad de la investigación y educativa. [Jimz2000] 3.1.3. Tecnologías de Internet 2 Internet 2 y sus miembros están desarrollando y probando tecnologías que permitirán que el Internet del futuro proporcione el desempeño confiable que es requerido por aplicaciones avanzadas. Es fundamental en el diseño de la infraestructura de Internet 2 el mantenimiento de un servicio de portador común para la comunicación entre aplicaciones de la red. Una de las fuerzas más grandes del Internet existente es la capacidad de cualquier nodo de comunicarse con cualquier otro nodo en un formato compatible de transporte. Se debe conservar esta fuerza en Internet 2. Internet 2 deberá permitir que las aplicaciones especifiquen a la red una "Calidad de Servicio" (QoS) a lo largo del enlace, incluyendo velocidad de la transmisión, retardo máximo, variación del retardo y rendimiento de procesamiento. Resolver estos requisitos lo más pronto posible es el desafío del diseño que se ha emprendido. Afortunadamente las tecnologías previstas para proporcionar estas capacidades han estado en desarrollo por varios años, y las versiones de la producción inicial están ya listas para pruebas reales en el campo. [Jimz2000]. Más allá de las mismas tecnologías, los participantes de Internet 2 requerirán servicios más rentables y con costos predecibles. Los servicios avanzados de salida y sistemas de ayuda no serán baratos. Mientras que estos servicios emigran al mercado comercial, debe asegurarse que haya un uso común. El diseño de ingeniería para la infraestructura del proyecto Internet 2 debe permitir el manejo del usuario final en costos así como de servicios. Un número de consideraciones técnicas y prácticas son la base de la 53 configuración total para la infraestructura de Internet 2. Uno de éstos es la necesidad de reducir al mínimo los costos totales a los campus participantes proveyendo acceso a ambos servicios, Internet y servicios avanzados, a través del mismo circuito local de conexión de gran capacidad. La configuración de referencia para Internet 2 se muestra en la figura 3.2. El nuevo elemento clave en esta configuración es el “GigaPoP”, un punto de interconexión de gran capacidad donde los participantes de Internet 2 pueden intercambiar tráfico de servicios avanzados con otros participantes de Internet 2. Los campus en una región geográfica se juntarán para adquirir una variedad de servicios de Internet en un GigaPoP regional. G ig a P o P 1 G ig a P o P 2 I n t e r n e t 2 R e d e s B a c k b o n e G ig a P o P 4 G ig a P o P 3 ( a ) ( b ) Figura 3.2 (a),(b).- Configuración para Internet 2. En Internet 2 se deben satisfacer ciertas características las cuales permiten el desarrollo de aplicaciones de gran utilidad práctica, en diversas áreas tales como: Telemedicina, Educación a Distancia, Colaboratorios, Sistemas de Información Geográfica, Predicción del Clima, Bibliotecas Digitales, Realidad Virtual, Telepresencia y Simulación de Procesos Complejos. Estas características son: Mayor ancho de banda: Una de las características fundamentales de Internet 2 es el manejo de un gran ancho de banda. En la actualidad, dependiendo de los recursos disponibles, se tienen en realidad velocidades del orden de los cientos de megabits por segundo, pero la tendencia es lograr llegar al rango de los gigabits por segundo. 54 Calidad de servicio (Quality of Service): En Internet, todos los paquetes de información tienen la misma prioridad, de tal forma que si alguien está enviando video por la red y otras personas están transfiriendo un archivo de datos, ambas aplicaciones compiten por el mismo canal, de tal forma que probablemente los cuadros de video no lleguen en forma continua, con lo cual se tendrá un congelamiento o al menos un deterioro en la calidad de la imagen. En cambio, en Internet 2 se le puede dar prioridad al video, de tal forma que se garantice que todos los cuadros lleguen a tiempo y solo en los espacios que el video deje libre se irán transmitiendo los paquetes del archivo de datos. Esta característica permite también mantener en un nivel adecuado el retardo de la información; esto es importante sobre todo para sistemas de control de dispositivos a distancia. [Jimz2000] Transmisión Multipunto (Multicast): Otro problema que se tiene en Internet consiste en que cuando se desea transmitir alguna información a un conjunto de usuarios, por ejemplo en la transmisión de un evento en vivo, se mandan los mismos paquetes de la señal de video a cada uno de los usuarios, con lo cual se multiplica el tráfico en la red. En cambio, en Internet 2 se está experimentando con una tecnología conocida como multicasting, en la cual se envía una sola vez cada paquete con la información necesaria para que les llegue a todos los usuarios que deben recibirlo. Retardo Reducido (Low Latency): En aplicaciones sensibles al retardo de la información es vital reducir este al mínimo posible; en Internet 2 con la combinación de un gran ancho de banda, la prioridad de los servicios y técnicas avanzadas de enrutamiento se logran retardos realmente muy pequeños en el orden de los milisegundos. Esto permite desarrollar sistemas de control a distancia de equipos muy sofisticados, en los cuales hay demasiado retardo de la información de control entre el equipo y el manipulador remoto que puede resultar fatal.[1] Seguridad y Privacía: Otro aspecto importante que se está experimentando en Internet 2 consiste en la mejora de la seguridad y privacía de la red, utilizando protocolos que permitan autentificar plenamente el origen de los datos y que asegure la integridad y confidencialidad de los mismos. El conjunto de áreas de aplicación implica un conjunto correspondiente de requisitos de comunicaciones para Internet 2. Aplicaciones futuras pueden requerir tipos de servicios adicionales. Es importante que el diseño de Internet 2 sea suficientemente flexible para acomodar los requisitos ya anticipados así como nuevos que puedan surgir. 55 En Internet 2 la convergencia de voz, datos y redes multimedia estará basada en protocolos basados en IP, surgiendo la necesidad de mejoras técnicas y operacionales. MPLS es una respuesta a esta necesidad mejorando la arquitectura TCP/IP original. Las redes IP necesitan evolucionar para soportar envío de paquetes en tiempo real, la integración de IP con ATM, redes privadas virtuales (VPN) y redes públicas mucho más grandes[1]. El número de usuarios que pueden conectarse, el número de rutas posibles y el ancho de banda disponible deben de ser en gran parte escalables. Mejora en eficiencia de la relación conmutador/precio y menores costos en toda la red son aspectos que también se pueden anticipar. La utilización de MPLS para proporcionar soporte de QoS y soporte de ingeniería de tráfico explícito es vista como parte de la solución. [Jimz2000] 3.2 Integración ATM y MPLS 3.2.1 Introducción MPLS es un estándar emergente del IETF que surgió para conciliar diferentes soluciones de conmutación multinivel, propuestas por distintos fabricantes a mitad de los 90. Como concepto, MPLS es a veces un tanto difícil de explicar. Como protocolo es bastante sencillo, pero las implicaciones que supone su implementación real son enormemente complejas. Según el énfasis (o interés) que se ponga a la hora de explicar sus características y utilidad, MPLS se puede presentar como un sustituto de la conocida arquitectura IP sobre ATM. También como un protocolo para hacer túneles (sustituyendo a las técnicas habituales de "tunneling"). O bien, como una técnica para acelerar el encaminamiento de paquetes. En realidad, MPLS hace un poco de todo eso, ya que integra sin discontinuidades los niveles 2 (transporte) y 3 (red), combinando eficazmente las funciones de control del encaminamiento con la simplicidad y rapidez de la conmutación de nivel 2. Pero, ante todo y sobre todo, debemos considerar MPLS como el avance más reciente en la evolución de las tecnologías de encaminamiento y envío en las redes IP, lo que implica una evolución en la manera de construir y gestionar estas redes y las redes IP que queremos ver en el próximo milenio. Los problemas que presentan las soluciones actuales de IP sobre ATM, tales como la expansión sobre una topología virtual superpuesta, así como la complejidad de gestión de dos redes separadas y tecnológicamente diferentes, quedan resueltos con MPLS. Al combinar en uno solo lo mejor de cada nivel (la inteligencia del encaminamiento con la rapidez de conmutación), 56 MPLS ofrece nuevas posibilidades en la gestión en las dorsales principales, así como en la provisión de nuevos servicios de valor añadido. Para poder entender mejor las ventajas de la solución MPLS, vale la pena revisar antes los esfuerzos anteriores de integración de los niveles 2 y 3 que han llevado finalmente a la adopción del estándar MPLS. [1] 3.2.2 Desarrollo de IP sobre ATM A mediados de los 90 IP fue ganando terreno como protocolo de red a otras arquitecturas en uso (SNA, IPX, AppleTalk, OSI). Por otro lado, hay que recordar que las dorsales de IP que los proveedores de servicio (NSP) habían empezado a desplegar en esos años estaban construidos a base de ruteadores conectados por líneas dedicadas T1/E1 y T3/E3. El crecimiento explosivo de la Internet había generado un déficit de ancho de banda en aquel esquema de enlaces individuales. La respuesta de los NSPs fue el incremento del número de enlaces y de la capacidad de los mismos. Del mismo modo, los NSPs se plantearon la necesidad de aprovechar mejor los recursos de red existentes, sobre todo la utilización eficaz del ancho de banda de todos los enlaces. Con los protocolos habituales de encaminamiento (basados en métricas del menor número de saltos), ese aprovechamiento del ancho de banda global no resultaba efectivo. Había que idear otras alternativas de ingeniería de tráfico. Como consecuencia, se impulsaron los esfuerzos para poder aumentar el rendimiento de los routers tradicionales. Estos esfuerzos trataban de combinar, de diversas maneras, la eficacia y la rentabilidad de los conmutadores ATM con las capacidades de control de los routers IP. A favor de integrar los niveles 2 y 3, al hecho de las infraestructuras de redes ATM estaban desplegando los operadores de telecomunicación. Estas redes ofrecían entonces (1995-97) una buena solución a los problemas de crecimiento de los NSPs. Por un lado, proporcionaba mayores velocidades (155 Mpbs) y, por otro, las características de respuesta determinísticas de los circuitos virtuales ATM posibilitaban la implementación de soluciones de ingeniería de tráfico. El modelo de red "IP sobre ATM" (IP/ATM) pronto ganó adeptos entre la comunidad de NSPs, a la vez que facilitó la entrada de los operadores telefónicos en la provisión de servicios IP y de conexión a la Internet al por mayor. [Pulley2000] [1] 3.2.3 Análisis de IP sobre ATM El funcionamiento IP/ATM supone la superposición de una topología virtual de ruteadores IP sobre una topología real de conmutadores ATM. La dorsal principal de ATM se 57 presenta como una nube central (el núcleo) rodeada por los ruteadores de la periferia. Cada ruteador se comunica con el resto mediante los circuitos virtuales permanentes (PVCs) que se establecen sobre la topología física de la red ATM. Los PVCs actúan como circuitos lógicos y proporcionan la conectividad necesaria entre los ruteadores de la periferia. Estos, sin embargo, desconocen la topología real de la infraestructura ATM que sustenta los PVCs. Los ruteadores ven los PVCs como enlaces punto a punto entre cada par. En la figura 3.3 se representa un ejemplo en el que se puede comparar la diferencia entre la topología física de una red ATM con la de la topología lógica IP superpuesta sobre la anterior.[1] Figura 3.3. Diferencia entre la topología física de una red ATM con la de la topología lógica IP superpuesta sobre la anterior La base del modelo IP/ATM está en la funcionalidad proporcionada por el nivel ATM, es decir, los controles de software (señalización y encaminamiento) y el envío de las celdas por hardware (conmutación). En realidad, los PVCs se establecen a base de intercambiar etiquetas en cada conmutador de la red, de modo que la asociación de etiquetas entre todos los elementos ATM determina los correspondientes PVCs. (Más adelante se verá que el intercambio de etiquetas es uno de los componentes fundamentales en la arquitectura MPLS). Las etiquetas tienen solamente significado local en los conmutadores y son la base de la rapidez en la conmutación de celdas. La potencia de esta solución de 58 topologías superpuestas está en la infraestructura ATM de la dorsal principal; el papel de los ruteadores IP queda relegado a la periferia, que, a mitad de los 90, tenían una calidad cuestionable, al estar basados en funcionamiento por software. En la figura 3.4 se representa el modelo IP/ATM con la separación de funciones entre lo que es routing IP en el nivel 3 (control y envío de paquetes) y lo que es conmutación en el nivel 2 (control/señalización y envío de celdas). Aunque se trata de una misma infraestructura física, en realidad existen dos redes separadas, con diferentes tecnologías, con diferente funcionamiento y, lo que quizás es más sorprendente, concebidas para dos finalidades totalmente distintas. [Pulley2000] [1]. La solución de superponer IP sobre ATM permite aprovechar la infraestructura ATM existente. Las ventajas inmediatas son el ancho de banda disponible a precios competitivos y la rapidez de transporte de datos que proporcionan los conmutadores. En los casos de NSPs de primer nivel ellos poseen y operan la dorsal principal ATM al servicio de sus redes IP. Los caminos físicos de los PVCs se calculan a partir de la necesidades del tráfico IP, utilizando la clase de servicio ATM UBR (Unspecified Bit Rate), ya que en este caso el ATM se utiliza solamente como infraestructura de transporte de alta velocidad (no hay necesidad de apoyarse en los mecanismos inherentes del ATM para control de la congestión y clases de servicio). La ingeniería de tráfico se hace a base de proporcionar a los ruteadores los PVCs necesarios, con una topología lógica entre ruteadores totalmente mallada. El "punto de encuentro" entre la red IP y la ATM está en el acoplamiento de los subinterfaces en los ruteadores con los PVCs, a través de los cuales se intercambian los ruteadores la información de encaminamiento correspondiente al protocolo interno IGP. Lo habitual es que, entre cada par de ruteadores, haya un PVC principal y otro de respaldo, que entra automáticamente en funcionamiento cuando falla el principal. [Pulley2000] [1] Figura 3.4 Modelo IP/ATM 59 La figura 3.4 representa el modelo IP/ATM con la separación de funciones entre lo que es encaminamiento IP en el nivel 3 (control y envío de paquetes) y lo que es conmutación en el nivel 2 (control/señalización y envío de celdas). Sin embargo, el modelo IP/ATM tiene también sus inconvenientes: hay que gestionar dos redes diferentes, una infraestructura ATM y una red lógica IP superpuesta, lo que supone a los proveedores de servicio unos mayores costes de gestión global de sus redes. Existe, además, lo que se llama la "tasa impuesta por la celda", un sobrepaso aproximado del 20% que causa el transporte de datagramas IP sobre las celdas ATM y que reduce en ese mismo porcentaje el ancho de banda disponible. Por otro lado, la solución IP/ATM presenta los típicos problemas de crecimiento exponencial n x (n-1) al aumentar el número de nodos IP sobre una topología completamente mallada. Considérese por ejemplo en una red con 5 ruteadores externos con una topología virtual totalmente mallada sobre una red ATM. Son necesarios 5 x 4 =20 PVCs (uno en cada sentido de transmisión). Si se añade un sexto ruteador se necesitan 10 PVCs más para mantener la misma estructura (6 x 5=30). Una pega adicional del crecimiento exponencial de rutas es el mayor esfuerzo que tiene que hacer el correspondiente protocolo IGP. [Pulley2000] [1] Como conclusión, podemos decir que el modelo IP/ATM, si bien presenta ventajas evidentes en la integración de los niveles 2 y 3, lo hace de modo discontinuo, a base de mantener dos redes separadas. El MPLS, tal como se verá en las secciones siguientes, logra esa integración de niveles sin discontinuidades. 3.2.4. Convergencia en Conmutación IP y MPLS La convergencia continuada hacia IP de todas las aplicaciones existentes, junto a los problemas de rendimiento derivados de la solución IP/ATM, llevaron posteriormente (1997-98) a que varios fabricantes desarrollasen técnicas para realizar la integración de niveles de forma efectiva, sin las discontinuidades señaladas anteriormente. Esas técnicas se conocieron como "conmutación IP" (IP switching) o "conmutación multinivel" (multilayer switching). Una serie de tecnologías privadas -entre las que merecen citarse: IP Switching de Ipsilon Networks, Tag Switching de Cisco, Aggregate Route-Base IP Switching (ARIS) de IBM, IP Navigator de Cascade/Ascend/Lucent y Cell Switching Router (CSR) de Toshiba-condujeron finalmente a la adopción del actual estándar MPLS del IETF. El problema que presentaban tales soluciones era la falta de interoperatividad, ya que usaban diferentes tecnologías privadas para combinar la conmutación de nivel 2 60 con el encaminamiento IP (nivel 3). Se resume a continuación los fundamentos de esas soluciones integradoras, ya que permitirá luego comprender mejor la esencia de la solución MPLS. [1] Todas las soluciones de conmutación multinivel (incluido MPLS) se basan en dos componentes básicos comunes: • La separación entre las funciones de la componente de control (tabla de encaminamiento) y la componente de envío (tabla de envío) • El paradigma de intercambio de etiquetas para el envío de datos En la figura 3.5 se representa la separación funcional de esas dos componentes, una de control y la otra de envío. La componente de control utiliza los protocolos estándar de encaminamiento (OSPF, IS-IS y BGP-4) para el intercambio de información con los otros ruteadores para la construcción y el mantenimiento de las tablas de encaminamiento. Al llegar los paquetes, la componente de envío busca en la tabla de envío, que mantiene la componente de control, para tomar la decisión de encaminamiento para cada paquete. En concreto, la componente de envío examina la información de la cabecera del paquete, busca en la tabla de envío la entrada correspondiente y dirige el paquete desde la interfaz de entrada al de salida a través del correspondiente hardware de conmutación. Figura 3.5. Representa la separación funcional de esas dos componentes, una de control y la otra de envío Al separar la componente de control (encaminamiento) de la componente de envío, cada una de ellas se puede implementar y modificar independientemente. El único requisito es 61 que la componente de encaminamiento mantenga la comunicación con la de envío mediante la tabla de envío de paquetes y actualice la información. El mecanismo de envío se implementa mediante el intercambio de etiquetas, similar a lo visto para ATM. La diferencia está en que ahora lo que se envía por la interfaz física de salida son paquetes "etiquetados". De este modo, se está integrando realmente en el mismo sistema las funciones de conmutación y de encaminamiento. [1] En cuanto a la etiqueta que marca cada paquete, que es un campo de unos pocos bits de longitud fija, que se añade a la cabecera del mismo y que identifica una "clase equivalente de envío" (Forwarding Equivalence Class, FEC). Una FEC es un conjunto de paquetes que se envían sobre el mismo camino a través de una red, aun cuando sus destinos finales sean diferentes. Por ejemplo, en el encaminamiento convencional IP por prefijos de red (longest-match) una FEC serían todos los paquetes unicast cuyas direcciones de destino tengan el mismo prefijo. Realmente, una etiqueta es similar a un identificador de conexión (como el VPI/VCI de ATM o el DLCI de Frame Relay). Tiene solamente significado local y, por consiguiente, no modifica la información de la cabecera de los paquetes; tan sólo los encapsula, asignando el tráfico a los correspondientes FEC. El algoritmo de intercambio de etiquetas permite así la creación de "caminos virtuales" conocidos como LSP (Label-Switched Paths), funcionalmente equivalente a los PVCs de ATM y Frame Relay. En el fondo, lo que hace es imponer una conectividad entre extremos a una red no conectiva por naturaleza, como son las redes IP, pero todo ello sin perder la visibilidad del nivel de red (de aquí los nombres de conmutación IP o conmutación multinivel). Esta es la diferencia básica con el modelo IP/ATM. Al hablar de MPLS con más detalle se entenderán mejor estas peculiaridades. 3.3 MPLS 3.3.1 Componentes MPLS MPLS es un grupo de trabajo perteneciente a la IETF (Internet Engineering Task Force), para llevar al cabo un diseño eficiente, decisiones de enrutamiento y de conmutación del flujo de tráfico a través de la red, combinando los atributos de las tecnologías de conmutación de capa 2 y de enrutamiento de capa 3. MPLS proporciona los siguientes beneficios: Es una solución basada en estándares lo cual promueve la interoperabilidad. 62 No hay necesidad del modelo de superposición de IP sobre ATM y las dificultades asociadas con su administración. Proporciona los medios para el mapeo de direcciones IP a simples etiquetas de longitud fija utilizadas por diferentes tecnologías de envío de paquete y conmutación de paquetes. Se conecta a protocolos existentes como son RSVP (Protocolo de Reservación de Recursos) y OSPF (Open Shortest Path First). Permite proporcionar servicios diferenciados (differentiated services), así como QoS e Ingeniería de tráfico. Como cualquier tecnología, MPLS tiene su terminología y acrónimos los cuales se describen a continuación, y haciendo referencia a la figura 3.6. Camino por Conmutación de Etiquetas (LSP) Figura 3.6 .- Componentes de una red MPLS 3.3.2 Enrutamiento y Conmutación La mayoría de los protocolos de enrutamiento desarrollados en la actualidad están basados en algoritmos diseñados para obtener el camino mas corto para el recorrido del paquete por la red y no toman en cuenta parámetros adicionales como son retardo, jitter, y congestión de tráfico, los cuales pueden afectar el desempeño de la red, por lo que la ingeniería de tráfico es un reto para los administradores de redes. Examinando el viaje de un paquete donde se utiliza IP convencional, el cual viaja de un enrutador al siguiente, cada enrutador toma una decisión independiente de envío para ese 63 paquete, lo que quiere decir que cada enrutador analiza el encabezado del paquete, asigna un FEC y corre un algoritmo de enrutamiento. [Rosen2000] En MPLS la asignación de un paquete particular a un FEC particular se hace solo una vez: cuando el paquete entra en la red MPLS. Se le asigna una etiqueta al FEC al cual es asignado el paquete. Los paquetes son etiquetados antes de ser enviados por el enrutador de entrada (LER) en la red MPLS; en enrutadores siguientes no hay un análisis del encabezado de la capa de red, y en lugar de esto la etiqueta es utilizada como un índice en una tabla para especificar el siguiente enrutador y una nueva etiqueta (en cada salto se sustituye la etiqueta, de aquí el término label switching). Esto trae una serie de ventajas en comparación con el enrutamiento convencional. Las principales diferencias entre enrutamiento convencional y conmutación de etiquetas son (Figura 3.7)[1]: Enrutamiento Convencional Se realiza en cada nodo Conmutación de Etiquetas Se realiza solo una vez en la periferia de la red cuando la etiqueta es asignada. Soporte de Unicast y Multicast Requiere múltiples algoritmos de envío complejos Se requiere solo un algoritmo de envío Decisiones de Enrutamiento Se basa solo en direcciones Se puede basar en otros parámetros como son QoS, membresía a VPN, etc. Análisis completo del encabezado IP. Figura 3.7 Diferencias entre enrutamiento convencional y conmutación de etiquetas La adición del envío de paquetes basado en etiquetas complementa el enrutamiento convencional pero no lo reemplaza. El término de multi-protocolo se le asigna a MPLS porque sus técnicas de enrutamiento son aplicables a cualquier protocolo de capa de red. Este análisis se enfoca al uso de IP como protocolo de capa de red. Ya que múltiples soluciones independientes para el desarrollo de tecnologías basadas en conmutación de etiquetas es claramente una dirección no aceptable, se reconoció la necesidad de desarrollar estándares y se creó el grupo de trabajo de la IETF para este propósito, el cual fue creado en abril del 1997; desde entonces MPLS se encuentra en proceso de estandarización. Ya han salido algunos productos al mercado, por lo que se 64 puede ver que MPLS se ha desarrollado rápidamente y de forma eficiente lo que demuestra la necesidad de una nueva técnica en la industria. El reto es evolucionar la arquitectura de redes IP permitiendo una transición suave de las instalaciones actuales, costos adecuados y que provea oportunidades empresariales para usuarios y distribuidores. Anteriormente se consideraba solo un factor: la creación de enrutadores más baratos, grandes y veloces, pero en la actualidad el crecimiento explosivo de Internet y la aparición de aplicaciones innovadoras demanda la creación de tecnologías para responder a la demanda mas requerida en la actualidad: desempeño. MPLS ha sido motivado por algo mas que tan solo la necesidad de velocidad. Dos de los aspectos más significativos son: Diferentes tipos de tráfico requieren diferentes características de servicio, las cuales deben de ser garantizadas a lo largo de todo el camino a través de la red. MPLS permite la creación de caminos LSP (Label Switched Paths) con características de servicios diferentes. Infraestructuras IP de tipo portadora (Carrier-class), las cuales requieren redes robustas con un manejo de recursos efectivo. Desde la perspectiva de las grandes empresas, la utilización eficiente de sus instalaciones caras es la clave para obtener grandes ganancias. La capacidad de MPLS para proporcionar calidad de servicio permite cierto grado de control sobre el comportamiento de la red a diferencia de IP convencional. Desde la perspectiva de los clientes se tiene un mejor servicio, por ejemplo al minimizarse la presencia de congestión. [Rosen2000] [Pulley2000] 3.3.4 Descripción funcional del MPLS La operación del MPLS se basa en las componentes funcionales de envío y control, estudiadas anteriormente, y que actúan ligadas íntimamente entre sí. a) Funcionamiento del envío de paquetes en MPLS La base del MPLS está en la asignación e intercambio de etiquetas ya expuesto, que permiten el establecimiento de los caminos LSP por la red. Los LSPs son simplex por naturaleza (se establecen para un sentido del tráfico en cada punto de entrada a la red); el tráfico dúplex requiere dos LSPs, uno en cada sentido. Cada LSP se crea a base de concatenar uno o más saltos (hops) en los que se intercambian las etiquetas, de modo que cada paquete se envía de un "conmutador de etiquetas" (Label-Swiching Router) a otro, a través del dominio 65 MPLS. Un LSR no es sino un ruteador especializado en el envío de paquetes etiquetados por MPLS. En la figura 3.8 se puede ver la funcionalidad del MPLS. Compárese con los esquemas vistos antes en las figuras 3.4 y 3.5 para observar las analogías y diferencias. Al igual que en las soluciones de conmutación multinivel, MPLS separa las dos componentes funcionales de control (routing) y de envío (forwarding). Del mismo modo, el envío se implementa mediante el intercambio de etiquetas en los LSPs. Sin embargo, MPLS no utiliza ninguno de los protocolos de señalización ni de encaminamiento definidos por el ATM Forum; en lugar de ello, en MPLS o bien se utiliza el protocolo RSVP o bien un nuevo estándar de señalización el Label Distribution Protocol, LDP, del que se tratará más adelante. Pero, de acuerdo con los requisitos del IETF, el transporte de datos puede ser cualquiera. Si éste fuera ATM, una red IP habilitada para MPLS es ahora mucho más sencilla de gestionar que la solución clásica IP/ATM. Ahora ya no hay que administrar dos arquitecturas diferentes a base de transformar las direcciones IP y las tablas de encaminamiento en las direcciones y el encaminamiento ATM: esto lo resuelve el procedimiento de intercambio de etiquetas MPLS. El papel de ATM queda restringido al mero transporte de datos a base de celdas. Para MPLS esto es indiferente, ya que puede utilizar otros transportes como Frame Relay, o directamente sobre líneas punto a punto. [1] LS R exterior (entrada al D O M IN IO M P LS ) LS R R ounting IP estándar C ontrol IP LS R R ounting IP estándar C ontrol IP Señalización (R SVP/LD P C ontrol IP Señalización (R SVP/LD P E nvío paquetes (forw arding) Transporte Nivel 2 A signación Inicial E tiq, M P LS Enlace datos (cualquiera) P aquetes IP Intercam bio E tiquetas M P LS Intercam bio E tiquetas M P LS Enlace datos (cualquiera) Enlace datos (cualquiera) P aquetes E tiquetados (sobre enlaces P P P , celdas A T M P aquetes E tiquetados (sobre enlaces P P P , celdas A T M Figura 3.8. Funcionalidad del MPLS 66 Un camino LSP es el circuito virtual que siguen por la red todos los paquetes asignados a la misma FEC. Al primer LSR que interviene en un LSP se le denomina de entrada o de cabecera y al último se le denomina de salida o de cola. Los dos están en el exterior del dominio MPLS. El resto, entre ambos, son LSRs interiores del dominio MPLS. Un LSR es como un ruteador que funciona a base de intercambiar etiquetas según una tabla de envío. Esta tabla se construye a partir de la información de encaminamiento que proporciona la componente de control (recuérdese el esquema de la figura 3.4), según se verá más adelante. Cada entrada de la tabla contiene un par de etiquetas entrada/salida correspondientes a cada interfaz de entrada, que se utilizan para acompañar a cada paquete que llega por ese interfaz y con la misma etiqueta (en los LSR exteriores sólo hay una etiqueta, de salida en el de cabecera y de entrada en el de cola). En la figura 3.9 se ilustra un ejemplo del funcionamiento de un LSR del núcleo MPLS. A un paquete que llega al LSR por la interfaz 3 de entrada con la etiqueta 45 el LSR le asigna la etiqueta 22 y lo envía por la interfaz 4 de salida al siguiente LSR, de acuerdo con la información de la tabla[1]. Figura 3.9. Asignación de etiquetamiento El algoritmo de intercambio de etiquetas requiere la clasificación de los paquetes a la entrada del dominio MPLS para poder hacer la asignación por el LSR de cabecera. En la figura 3.9 el LSR de entrada recibe un paquete normal (sin etiquetar) cuya dirección de destino es 212.95.193.1. El LSR consulta la tabla de encaminamiento y asigna el paquete a la clase FEC definida por el grupo 212.95/16. Asimismo, este LSR le asigna una etiqueta (con valor 5 en el ejemplo) y envía el paquete al siguiente LSR del LSP. Dentro del dominio MPLS los LSR ignoran la cabecera IP; solamente analizan la etiqueta de entrada, consultan la tabla correspondiente (tabla de conmutación de etiquetas) y la reemplazan por otra nueva, de acuerdo con el algoritmo de intercambio de etiquetas. Al llegar el 67 paquete al LSR de cola (salida), ve que el siguiente salto lo saca de la red MPLS; al consultar ahora la tabla de conmutación de etiquetas quita ésta y envía el paquete por encaminamiento convencional.[1] Dominio MPLS LSR cabecera (entrada al dominio MPLS) Prefijo 212.95/16 LSR cabecera (entrada al dominio MPLS) LSR Etiq. Sal. LSR 5 212.95/16 Etiq. Entr Etiq. Sal. Transporte Nivel 2 212.35.193.1 Prefijo 5 Asignación Etiqueta inicial 5 Etiq. Entr Etiq. Sal. 9 5 Intercambio etiquetas 5 Etiq. Sal. 9 Transporte Nivel 2 Intercambio etiquetas 9 2g Asignación Etiqueta inicial 212.35.193.1 LSP figura 3.10. Esquema de los campos de cabeceras genérica MPLS y su relación con las cabeceras de los otros niveles. Como se ve en la figura 3.10, la identidad del paquete original IP queda enmascarada durante el transporte por la red MPLS, que no "mira" sino las etiquetas que necesita para su envío por los diferentes saltos LSR que configuran los caminos LSP. Las etiquetas se insertan en cabeceras MPLS, entre los niveles 2 y 3. Según las especificaciones del IETF, MPLS debía funcionar sobre cualquier tipo de transporte: PPP, LAN, ATM, Frame Relay, etc. Por ello, si el protocolo de transporte de datos contiene ya un campo para etiquetas (como ocurre con los campos VPI/VCI de ATM y DLCI de Frame Relay), se utilizan esos campos nativos para las etiquetas. Sin embargo, si la tecnología de nivel 2 empleada no soporta un campo para etiquetas (por ejemplo: enlaces PPP o LAN), entonces se emplea una cabecera genérica MPLS de 4 octetos, que contiene un campo específico para la etiqueta y que se inserta entre la cabecera del nivel 2 y la del paquete (nivel 3). En la figura 3.10 se representa el esquema de los campos de la cabecera genérica MPLS y su relación con las cabeceras de los otros niveles. Según se muestra en la figura 3.11, los 32 bits de la cabecera MPLS se reparten en: 20 bits para la etiqueta MPLS, 3 bits para identificar la clase de servicio en el campo EXP 68 (experimental, anteriormente llamado CoS), 1 bit de stack para poder apilar etiquetas de forma jerárquica (S) y 8 bits para indicar el TTL (time-to-live) que sustenta la funcionalidad estándar TTL de las redes IP. De este modo, las cabeceras MPLS permiten cualquier tecnología o combinación de tecnologías de transporte, con la flexibilidad que esto supone para un proveedor IP a la hora de extender su red.[1] Figura 3.11. Control de la información en MPLS Hasta ahora se ha visto el mecanismo básico de envío de paquetes a través de los LSPs mediante el procedimiento de intercambio de etiquetas según las tablas de los LSRs. Pero queda por ver dos aspectos fundamentales: • Cómo se generan las tablas de envío que establecen los LSPs • Cómo se distribuye la información sobre las etiquetas a los LSRs El primero de ellos está relacionado con la información que se tiene sobre la red: topología, patrón de tráfico, características de los enlaces, etc. Es la información de control típica de los algoritmos de encaminamiento. MPLS necesita esta información de routing para establecer los caminos virtuales LSPs. Lo más lógico es utilizar la propia información de encaminamiento que manejan los protocolos internos IGP (OSPF, IS-IS, RIP...) para construir las tablas de encaminamiento (recuérdese que los LSR son routers con funcionalidad añadida). Esto es lo que hace MPLS precisamente: para cada "ruta IP" en la red se crea un "camino de etiquetas" a base de concatenar las de entrada/salida en cada tabla de los LSRs; el protocolo interno correspondiente se encarga de pasar la información necesaria. El segundo aspecto se refiere a la información de "señalización" las comillas se ponen por el impacto que puede suponer este término para los puristas del mundo IP, de naturaleza no conectiva. Pero siempre que se quiera establecer un circuito 69 virtual se necesita algún tipo de señalización para marcar el camino, es decir, para la distribución de etiquetas entre los nodos. Sin embargo, la arquitectura MPLS no asume un único protocolo de distribución de etiquetas; de hecho se están estandarizando algunos existentes con las correspondientes extensiones; unos de ellos es el protocolo RSVP del Modelo de Servicios Integrados del IETF (recuérdese que ése era uno de los requisitos). Pero, además, en el IETF se están definiendo otros nuevos, específicos para la distribución de etiquetas, el cual es el caso del Label Distribution Protocol (LDP). Consúltese las referencias correspondientes del IETF.[1] [Rosen2000] 3.3.5. Mecanismos de señalización Solicitud de etiqueta: Utilizando este mecanismo, un LSR solicita una etiqueta a su vecino, así puede atar una etiqueta a un FEC específico. Este mecanismo puede utilizarse desde la parte baja de la cadena hasta la parte final (el enrutador de salida, LER). Mapeo de etiqueta: En respuesta a la solicitud de etiqueta, un LSR enviará una etiqueta al LSR que la solicitó utilizando el mecanismo de mapeo. Los mecanismos de solicitud y mapeo de etiqueta se muestran en la figura 3.11: Solicitud de etiqueta (Destino C) Solicitud de etiqueta (Destino C) LER A Entrada LER C Salida Mapeo de Etiquetas (ej: utilizando Etiqueta 9) Mapeo de Etiquetas (ej: utilizando Etiqueta 5) Figura 3.11.- Señalización en MPLS MPLS define dos modos para la asignación de etiquetas a LSR vecinos: Independiente: En este modo un LSR reconoce un FEC particular y toma la decisión de atar una etiqueta a un FEC y de distribuir esta atadura a sus pares de distribución de etiqueta. Esto corresponde a la forma en la cual trabaja el enrutamiento de datagramas IP convencional, donde cada nodo toma la decisión independiente de como tratar cada paquete. 70 Ordenado: En este modo un LSR ata una etiqueta a un FEC particular si y solo si es el enrutador de salida o si ha recibido una atadura de etiqueta para el FEC de su brinco siguiente (LSR). Existe un mecanismo conocido como pila de etiquetas que permite la operación jerárquica en el dominio MPLS. Básicamente permite que MPLS sea utilizado simultáneamente para enrutar a un nivel fino (por ejemplo entre enrutadores de un ISP), y a un nivel mayor (de dominio a dominio). Cada nivel en una pila de etiquetas pertenece a algún nivel jerárquico, lo cual facilita el modo de operación de túnel en MPLS.[1] [Rosen2000] Ahora bien, un enrutador si recibe un paquete etiquetado con una etiqueta particular de entrada, pero no tiene ninguna atadura para esta etiqueta, es tentador pensar que la etiqueta puede ser removida y el paquete enviado como un paquete normal de IP. Al hacer esto podría provocar un ciclo si el enrutador ascendente (LSR) asume que la etiqueta está destinada a una ruta explícita, y el enrutador descendente no asume que la etiqueta está destinada a algo, y si el enrutamiento brinco a brinco del paquete IP no etiquetado trae de regreso el paquete al enrutador ascendente. Por lo tanto, cuando se recibe un paquete con una etiqueta inválida debe ser descartado.[1] 3.3.6 Protocolos para Distribución de Etiquetas La arquitectura MPLS no asigna un solo método de señalización para la distribución de etiquetas. Los protocolos existentes de enrutamiento, tales como el Border Gateway Protocol (BGP), se han mejorado para llevar la información de la etiqueta dentro del contenido del protocolo. El RSVP también se ha ampliado para soportar intercambio de etiquetas. La IETF también ha definido un nuevo protocolo conocido como Protocolo para Distribución de Etiquetas (LDP) para la señalización y el manejo explícito de etiquetas. Se han definido extensiones al protocolo base LDP para soportar enrutamiento explícito basado en requerimientos de QoS. Estas extensiones están en la definición del protocolo de enrutamiento basado en restricciones (CR-LDP). Un protocolo de distribución de etiquetas es un conjunto de procedimientos en los cuales un LSR informa a otro de las ataduras FEC- etiqueta que ha hecho. Dos LSR que utilizan un protocolo de distribución de etiqueta para intercambiar información sobre las ataduras FECetiqueta son conocidos como “pares de distribución de etiqueta”, con respecto a la información de atadura que estos intercambian. 71 LDP es un protocolo nuevo para la distribución de información de ataduras de etiqueta para LSR en una red MPLS. Es utilizado para mapear (relacionar) FECs a etiquetas, las cuales se utilizan para formar LSP (caminos de conmutación por etiquetas). Las sesiones de LDP se establecen entre LSR vecinos en la red MPLS (no necesariamente adyacentes) los cuales intercambian los distintos tipos de mensajes LDP: • Mensajes de descubrimiento: anuncian y mantienen la presencia de un LSR en una red. • Mensajes de anuncio: para crear, cambiar y borrar mapas de etiquetas para FEC. • Mensajes de notificación: proveen información de consulta y señales de error. El protocolo CR-LDP (LDP basado en restricciones) contiene extensiones para incrementar las funcionalidad de LDP, lo cual permite la configuración de caminos mas allá de lo que permite el protocolo de enrutamiento. Toma en cuenta parámetros como características de enlace (ancho de banda, retardo, etc.), conteo de brincos y QoS. Los LSP que se establecen pueden ser CR-LSP, donde las restricciones pueden ser brincos específicos o requerimientos de QoS. Los saltos específicos dictaminan que camino será tomado y los requerimientos de QoS dictaminan los mecanismos de enlace, almacenamiento o de calendarización que serán empleados para el flujo de datos. Cuando se utiliza CR es completamente posible que se seleccione un camino mas largo (en términos de costo) pero con menos carga de tráfico del que se tomaría con enrutamiento convencional, por lo que al mismo tiempo que CR incrementa la utilización de la red, agrega mayor complejidad a los cálculos de enrutamiento ya que el camino seleccionado debe satisfacer los requerimientos de QoS del LSP. Una colección de dispositivos habilitados para manejo de MPLS representa un dominio MPLS. Dentro de un dominio MPLS un camino es configurado para un paquete dado basándose en un FEC. El LSP es configurado antes de la transmisión de los datos. MPLS provee las siguientes 2 opciones para la selección de un LSP: Enrutamiento salto a salto: Cada LSR selecciona independientemente el brinco a seguir para un determinado FEC. Esta metodología es similar a aquella utilizada actualmente en redes IP. El LSR utiliza cualquier protocolo de enrutamiento disponible como son OSPF, PNNI. Enrutamiento explícito: El LER de entrada (donde se inicia el flujo de datos en la red) especifica la serie de nodos a través de los cuales el ER-LSP viajará. El camino trazado puede ser no del todo óptimo. A través del camino se pueden ir reservando recursos para 72 asegurar la calidad del servicio al tráfico de datos. Esto facilita la ingeniería de tráfico a través de la red y pueden proporcionarse servicios diferenciados utilizando flujos basados en políticas o métodos de administración de redes. En un camino explícito cada LSR no toma independientemente la decisión para escoger el siguiente brinco, en lugar de eso, un solo LSR, generalmente el de salida, especifica varios (o todos) los LSR en el LSP. Si un solo LSR especifica el LSP completo, al camino se le denomina LSP “estricto explícitamente enrutado”. Si un solo LSP especifica solo algunos LSR en el LSP se le denomina LSP “flexible explícitamente enrutado”. La secuencia seguida en un camino explícitamente enrutado puede ser escogida por configuración o puede ser seleccionada dinámicamente por un solo nodo (por ejemplo, el nodo de salida puede hacer uso de información de topología de la red obtenida de una base de datos de estados de enlace para calcular el camino completo para la finalización de árbol en el nodo de salida). El enrutamiento explícito puede ser útil para ciertos propósitos como son: políticas de enrutamiento e ingeniería de tráfico. En MPLS la ruta explícita debe de ser especificada en el momento que las etiquetas son asignadas, pero la ruta explícita completa no tiene que ser enviada con cada paquete IP. Esto hace al enrutamiento explícito en MPLS más eficiente que la alternativa de IP con enrutamiento de fuente (source routing). [1] [Rosen2000] La determinación de un LSP es por naturaleza unidireccional ya que el tráfico de retorno puede tomar otro LSP (aunque no necesariamente). b) Funcionamiento global MPLS Una vez vistos todos los componentes funcionales, el esquema global de funcionamiento es el que se muestra en la figura 3.12, donde quedan reflejadas las diversas funciones en cada uno de los elementos que integran la red MPLS. Es importante destacar que en el borde de la nube MPLS tenemos una red convencional de routers IP. El núcleo MPLS proporciona una arquitectura de transporte que hace aparecer a cada par de routers a una distancia de un sólo salto. Funcionalmente es como si estuvieran unidos todos en una topología mallada (directamente o por PVCs ATM). Ahora, esa unión a un solo salto se realiza por MPLS mediante los correspondientes LSPs (puede haber más de uno para cada par de ruteadores). La diferencia con topologías conectivas reales es que en MPLS la construcción de caminos virtuales es mucho más flexible y que no se pierde la visibilidad sobre los paquetes IP. Todo ello abre enormes 73 posibilidades a la hora de mejorar el rendimiento de las redes y de soportar nuevas aplicaciones de usuario, tal como se explica en la sección siguiente.[1] 1a. Construcción tablas de encaminamiento Mediante protocolos internos (OSPF, RIP) Creación de rutas LSPs mdiante tablas de Intercambio de etiquetas entre LSRs, adyacentes Distribución a los LSR por el LDP 2. LSR cabecera (entrada): examina el paquete, lo procesa (funciones de Servicio nivel 3) , lo etiqueta y Lo envía al backbone 4. LSR cola (salida) quita la etiqueta y entrega el paquete al destino 3. LSRs del backbone Conmuta los paquetes mediante Intercambio de etiquetas Figura 3.12. Funcionamiento global 3.3.7. Ingeniería de tráfico para MPLS En base a lo descrito por todo el capítulo podemos enfocarnos a establecer una propuesta de conectividad haciendo interpretación que la ingeniería de tráfico es adaptar los flujos de tráfico a los recursos físicos de la red. La idea es equilibrar de forma óptima la utilización de recursos de multimedios, de manera que no haya algunos que estén suprautilizados, con posibles puntos críticos y cuellos de botella, mientras otros puedan estar infrautilizados. A comienzos de los 90 los esquemas para adaptar de forma efectiva los flujos de tráfico a la topología física de las redes IP eran bastante rudimentarios. Los flujos de tráfico siguen el camino más corto calculado por el algoritmo IGP correspondiente. En casos de congestión de algunos enlaces, el problema se resolvía a base de añadir más capacidad a los enlaces. La ingeniería de tráfico consiste en trasladar determinados flujos seleccionados por el algoritmo IGP sobre enlaces más congestionados, a otros enlaces más descargados, aunque estén fuera de la ruta más 74 corta (con menos saltos). En el esquema de la figura 3.13 se comparan estos dos tipos de rutas para el mismo par de nodos origen-destino. El camino más corto entre A y B según la métrica normal IGP es el que tiene sólo dos saltos, pero puede que el exceso de tráfico sobre esos enlaces o el esfuerzo de los ruteadores correspondientes hagan aconsejable la utilización del camino alternativo indicado con un salto más. MPLS es una herramienta efectiva para esta aplicación en grandes dorsales, ya que: • Permite al administrador de la red el establecimiento de rutas explícitas, especificando el camino físico exacto de un LSP. • Permite obtener estadísticas de uso LSP, que se pueden utilizar en la planificación de la red y como herramientas de análisis de cuellos de botella y carga de los enlaces, lo que resulta bastante útil para planes de expansión futura. • Permite hacer "encaminamiento restringido" (Constraint-based Routing, CBR), de modo que el administrador de la red pueda seleccionar determinadas rutas para servicios especiales (distintos niveles de calidad). Por ejemplo, con garantías explícitas de retardo, ancho de banda, fluctuación, pérdida de paquetes, etc. La ventaja de la ingeniería de tráfico MPLS es que se puede hacer directamente sobre una red IP(IPV4 o IPV6), al margen de que haya o no una infraestructura ATM por debajo, todo ello de manera más flexible y con menores costes de planificación y gestión para el administrador, y con mayor calidad de servicio para los clientes.[1] Figura 3.13. Comparación de los dos tipos de rutas para el mismo par de nodos origendestino. 75 3.3.8. Clases de servicio (CoS) MPLS está diseñado para poder cursar servicios diferenciados, según el Modelo DiffServ (Servicios Diferenciado) del IETF. Este modelo define una variedad de mecanismos para poder clasificar el tráfico en un reducido número de clases de servicio, con diferentes prioridades. Según los requisitos de los usuarios, DiffServ permite diferenciar servicios tradicionales tales como el WWW, el correo electrónico o la transferencia de ficheros (para los que el retardo no es crítico), de otras aplicaciones mucho más dependientes del retardo y de la variación del mismo, como son las de vídeo y voz interactiva. Para ello se emplea el campo ToS (Type of Service), rebautizado en DiffServ como el octeto DS. (Véase más información sobre el modelo DiffServ en las referencias correspondientes a QoS). Esta es la técnica QoS de marcar los paquetes que se envían a la red.[1] MPLS se adapta perfectamente a ese modelo, ya que las etiquetas MPLS tienen el campo EXP para poder propagar la clase de servicio CoS en el correspondiente LSP. De este modo, una red MPLS puede transportar distintas clases de tráfico, ya que: • El tráfico que fluye a través de un determinado LSP se puede asignar a diferentes colas de salida en los diferentes saltos LSR, de acuerdo con la información contenida en los bits del campo EXP • Entre cada par de LSR exteriores se pueden pro-visionar múltiples LSPs, cada uno de ellos con distintas prestaciones y con diferentes garantías de ancho de banda. Por ejemplo un LSP puede ser para tráfico de máxima prioridad, otro para una prioridad media y un tercero para tráfico mejorado, tres niveles de servicio, primera, preferente y turista, que, lógicamente, tendrán distintos precios. [1] 3.3.9 Integración de MPLS y ATM MPLS resuelve el problema de tener que crear una nube ATM. Con MPLS los enlaces ATM son tratados como enlaces IP y cada conmutador se convierte en un par de enrutamiento IP (modelo integrado). Implementando la inteligencia IP en los conmutadores ATM, los diseñadores pueden eliminar la superposición de enlaces IP en ATM logrando una correspondencia uno a uno entre ellos, lo cual resuelve la mayoría de los problemas de escalabilidad IP. Además la integración de las capas permite un modelo que toma ventaja de las mejores características de cada capa. 76 Un concepto básico de MPLS es convertir el equipo de capa 2 en la red (por ejemplo, los conmutadores ATM) en ATM-LSRs, el cual puede ser visto como una combinación de un sistema de conmutación ATM y un enrutador tradicional, compuesto por la unidad de control y la unidad de envío como se muestra en la figura 3.14 siguiente: ó Enrutador Conmutador ATM Enrutador MPLS Enrutador ATM-MPLS Figura 3.14. Conmutadores MPLS 3..3.10 Elementos MPLS en una red ATM WAN. A continuación se hace una descripción de los elementos MPLS en una red ATM. • Label-Controlled ATM (LC-ATM) interface: Es una interfaz ATM controlada por el componente de control MPLS. Celdas que viajan por una interfaz llevan etiquetas en el campo VCI de un rango seleccionado de VPIs; el componente de control puede estar integrado en el conmutador o en un controlador externo. • ATM-LSR: Un LSR basado en un conmutador ATM el cual tiene interfaces LCATM. • LSR basado-en-paquetes (LSR-B-P): Es un LSR que envía paquetes completos entre interfaces. Puede tener cero o mas interfaces LC-ATM. LSRs B-P típicamente consisten en plataformas de enrutadores ordinarios corriendo programas MPLS. • ATM Edge LSR Es un LSR B-P conectado a la nube ATM-LSR vía interfaces LC-ATM. Tiene la función de agregar etiquetas y quitar etiquetas de los paquetes. En MPLS-ATM los componentes de control y envío consisten en: Componente de Envío En ATM la conmutación de etiquetas se lleva a cabo de la forma tradicional. La información necesaria para la conmutación por etiqueta se lleva en el campo VCI. 77 Componente de control En el componente de control sobre redes ATM se utilizan protocolos de distribución de etiquetas para atar VCIs a rutas IP. El enrutador debe participar en protocolos de enrutamiento como son OSPF, BGP y RSVP. 3.3.11 Control vía conmutadores ATM El componente de control de MPLS sobre ATM es similar al MPLS convencional basado en enrutamiento en donde un protocolo estándar IP como OSPF o IS-IS, funciona en la red junto con el protocolo de distribución de etiquetas (LDP). LDP es necesario para atar VCIs a rutas IP. Los ATM-LSRs mantienen una FIB (Forwarding Information Base), la cual contiene una lista de rutas IP que utiliza el ATM-LSR. Esta función de control es manejada por la herramienta de enrutamiento, la cual puede estar integrada o corre en un controlador externo. Para cada ruta en su FIB, el ATM LSR identifica el siguiente brinco para una ruta, entonces realiza una solicitud vía LDP al brinco siguiente para realizar una atadura para dicha ruta. [1] [Jimz2000 3.3.12. Arquitectura de Redes MPLS Una arquitectura típica para MPLS en una red de tipo “carrier- IP”, consiste en una serie de LER alrededor de un núcleo de conmutadores LSR. Los usuarios (sitios) se conectan a la red MPLS por medio de los LER. En la figura 3.15 se muestran 9 sitios de usuario y 6 LER, pero normalmente hay cientos de sitios por LER. El equipo local del cliente (ELC) corre IP convencional y normalmente no corre MPLS. Si el ELC corre MPLS lo hace de manera independiente del proveedor.[1] 78 Sitios utilizando IP ordinario ELC ELC Figura 3.15. Backbone MPLS (Dorsal) 3.3.1.3. MPLS basada en paquetes Es la topología más simple para la estructura de una red MPLS, la cual se aplica para estructuras de red con solo enrutadores, las cuales deben utilizar MPLS para soportar VPN o ingeniería de tráfico. En esta estructura los usuarios están conectados directamente a LERs basados en plataformas de enrutadores. Estos LER se conectan a otros LSR basados también en plataformas de enrutadores. Los enrutadores se interconectan virtualmente con cualquier tipo de enlace: serial, Ethernet, paquetes-sobre -SONET, etc. (ver figura 3.15a). Función: MPLS BasadoPaquetes ELC Dispositivo: Figura 3.15a.- Arquitectura típica de una red MPLS. 79 3.3.14 ATM MPLS La estructura de red MPLS-ATM más simple es la siguiente: los sitios se conectan directamente al LER, los cuales se conectan con el núcleo de la red con enlaces ATM. Los conmutadores ATM transportan paquetes con etiquetas ATM-MPLS (etiqueta VCI). (figura 15b) Dispositivo: ELC ELC Función: Fig.-15b Arquitectura MPLS-ATM 3.3.15 Mezcla de ATM MPLS y MPLS de paquetes Es posible mezclar ATM-MPLS y MPLS de paquetes en una red. Algunos enlaces corren ATM MPLS, y otros MPLS de paquetes. Los dispositivos que se conectan entre MPLS de paquetes y ATM MPLS son los mismos enrutadores que actúan como ATM-LER. (figura 3.16) Función: Dispositivo Figura 3.16. Mezcla de ATM MPLS y MPLS de paquetes. 3.3.16 ATM MPLS con dispositivos IP+ATM En esta configuración un solo dispositivo de acceso proporciona servicios MPLS y ATM (PVC ó SVC). (Figura 3.17) Figura 3.17. ATM MPLS con dispositivos IP+ATM 80 Como parte de la configuración inicial de la red el operador asigna recursos de la red ATM a PNNI y a MPLS (por ejemplo, ancho de banda en enlaces, espacios VPI/VCI en los enlaces, espacios de tabla de conexión de VC). Esta partición de recursos es algo flexible, con una división de recursos arbitraria entre los diferentes planos de control. Se pueden definir asignaciones fijas de recursos entre diferentes planos de control. Como la red puede utilizarse para proporcionar simultáneamente servicios MPLS y conmutación ATM tradicional, se le denomina “ship-in the-night” [1] [Jimz2000] 3.3.17 Escenarios de Migración MPLS puede ser introducido en una red ATM gradualmente, comenzando con un solo par de ATM-LER en una red puramente ATM. MPLS puede ser desplegado a través de conmutadores sin la capacidad de MPLS, utilizando conexiones VP a través de conmutadores ATM tradicionales; estas conexiones son llamadas túneles VP ya que permiten a MPLS “hacer un túnel” a través de conmutadores ATM tradicionales. La figura 3.18 muestra una estrategia posible de migración para introducir MPLS en una red existente ATM. La Figura 3.18(a) muestra la posición inicial con enrutadores conectados a través de PVPs a través de una nube ATM, lo cual tiene la mayoría de las desventajas de las redes IP-sobre-ATM tradicionales, un muy mal escalamiento y mala eficiencia de ancho de banda, sin embargo puede proporcionar los servicios MPLS-VPN. Desplegando algunos ATM-LSRs en la red como se muestra en la figura 18(b) y 18(c) mejora la escalabilidad: el número de PVPs a cada LER puede reducirse a uno (dos si hay conexión de respaldo), y en algunos casos a cero, si un LER es adyacente a un ATM-LSR. El ATM-LSR puede ser interconectado con conmutadores ATM ordinarios de varias formas. El despliegue cuidadoso de ATM-LSR y PVPs puede ser utilizado para que la malla de PVPs se asemeje lo mas posible a la topología de enlaces ATM y por lo tanto mejore la eficiencia de ancho de banda. Ya que un ATM-LSRs puede soportar servicios ATM, los conmutadores ATM ordinarios pueden ser retirados, permitiendo el despliegue completo de la red ATM-MPLS como se muestra en la figura 18(d), la utilización de PVP ya no es requerida. 81 ( a ) R e d A T M -M P L S u tiliz a n d o s o lo tú n e le s V P. (b ) A g re g a n d o u n A T M – L S R . E n la c e A T M - M P L S ( c ) S im p lific a c ió n a g r e g a n d o m a s A T M -L S R s . A T M L a b e l S w itc h R o u te r. E n la c e A T M -M P L S . ( d ) R e d c o m p le ta m e n te A T M -M P L S A T M E d g e R o u te r. R e d n o A T M -M P L S y tú n e le s V P . Figura 3.18.- Migrando de ATM a MPLS. 3.3.18 Aplicaciones de MPLS Las redes actuales hacen frente a los retos en las siguientes áreas y MPLS puede aplicarse para tratar de solucionarlas: a) Funcionalidad.- La conmutación de etiquetas proporciona nuevas funciones, las cuales no estuvieron disponibles en IP convencional o eran ineficientes en el enrutamiento convencional. Por ejemplo, enrutamiento explícito para seleccionar una ruta diferente la cual puede no ser el camino mas corto, seleccionando una ruta en base a ciertos atributos además de la dirección de destino, donde se requiere satisfacer cierta QoS. b) Escalabilidad.- Las redes del futuro deben de ser virtualmente ilimitadas en tamaño. La información de enrutamiento crece muy rápidamente cuando aumenta el tamaño de la red y eventualmente puede provocar una saturación sobrecargando el enrutador. Técnicas actuales de superponer redes con enrutamiento IP sobre redes ATM o en circuitos virtuales frame relay acrecientan este problema. MPLS requiere de dispositivos de capa 2 (conmutadores ATM, por ejemplo) que sean capaces de correr el plano de control de IP lo cual ayuda a solucionar el problema. La ingeniería de tráfico 82 permite un uso más eficiente de los recursos de la red lo cual ayuda en el escalamiento de la red. c) Evolucionabilidad.- Uno de los retos mayores será tener la capacidad de cambio y crecimiento sin que ocurran grandes alteraciones en la red. Servicios deterministicos necesitan ser superpuestos en una red IP no deterministica. d) Integración.- Convergencia de aplicaciones, por ejemplo telefonía por IP, es un ejemplo de integración de sistemas y la superposición de redes IP sobre ATM es un ejemplo de integración de redes. Una de las ventajas de MPLS es que permite la Ingeniería de Tráfico, que es el proceso que resalta en conjunto la utilización de la red intentando crear un tráfico uniforme o una distribución diferenciada de tráfico a través de la red. Un resultado importante de este proceso es que se evita la congestión de tráfico en cualquier camino. Es importante notar que la ingeniería de tráfico no necesariamente selecciona el camino mas corto entre 2 dispositivos; es posible que para el flujo de 2 paquetes de datos, deban tomar caminos diferentes aun si sus nodos de origen y destino son los mismos. De esta forma los segmentos de red menos utilizados pueden utilizarse y pueden proporcionarse servicios diferenciados. En MPLS la ingeniería de tráfico es proporcionada de forma inherente utilizando caminos enrutados explícitamente. Los LSP son creados de forma independiente, especificando diferentes caminos que están basados en políticas definidas de usuario, por lo tanto se puede requerir una gran intervención del operador. RSVP y CR-LDP son 2 posibles aproximaciones para proporcionar ingeniería de tráfico dinámica y QoS en MPLS. Para explicar la operación multicast en MPLS se puede utilizar la aproximación general siguiente: Una etiqueta de entrada se mapea a un conjunto de etiquetas de salida lo cual se puede lograr vía un árbol multicast. Un conjunto de puertos de salida es utilizado para la transmisión del paquete. Este tipo de operación está dirigido a infraestructuras de redes de área local (LAN). En un sistema orientado a conexión como es ATM, se pueden utilizar los caminos conmutados punto a multipunto para la distribución de tráfico multicast. Aunque MPLS trata de resolver una amplia gama de problemas, además de la integración de IP con ATM y las dificultades asociadas con los modelos de correspondencia entre IP y ATM, debe recalcarse que esto fue una gran motivación para el desarrollo de esta tecnología de conmutación de etiquetas. En el siguiente capítulo se describe la interacción e integración de ATM y MPLS, ya que actualmente una gran mayoría de las dorsales tipo WAN hacen uso de la primera de las tecnologías y se espera su migración a la segunda. 83 Capítulo 4. 4. Casos de Estudio en Escenarios de Gestión de Desempeño En base a los objetivos propuestos por esta trabajo, proponemos dos tipos de escenarios de estudio: ATM y MPLS 4.1 Escenario 1. Un sistema de TMN para VPC y Gestión de encaminamiento en redes ATM con Servicios de Internet 2 [Esta sección de transcribe de: D. Griffin, P. Georgatsos. “A TMN System for VPC and Routing Management in ATM Networks”. Integrated Network Management IV, pp. 356-369. Chapman & Hall. 1995] 4.1.1 Introducción En esta parte del trabajo presentamos el estudio que se realiza con respecto a una red ATM (figura 4.1) aplicando el modelo de Gestión TMN y se analiza el funcionamiento que se tiene en el VPC y el servicio de Gestión de encaminamiento para una red ATM con Servicios de Internet 2, como parte de la estrategia de abarcar las funciones que intervienen para establecer la metodología propuesta. En vista de los requisitos, descomponemos la Gestión de Servicio dentro de un número de distintos de componentes funcionales para la cooperación del mapeo de la arquitectura de TMN, como se indica en la recomendación [M.3020]. Describimos los componentes arquitectónicos y se analizan sus dependencias e intercambio de información operacionales dentro del contexto de la operación del sistema total de comunicaciones. El sistema propuesto ofrece las funciones genéricas de la supervisión de funcionamiento, así como supervisión de la carga y gestión de configuración en redes ATM. Además, proporciona las funciones específicas para Gestión de encaminamiento en el ancho de banda en una estructura jerárquica. [Grif95] 84 Clientes para Gestión de Red SNMP SNMP Red Privada ATM UNI Pública ILMI UNI Privada CMIP Red Pública ATM Capa interna para la Interface de gestión (ILMI) Figura 4.1. Gestión de Redes ATM 4.1.2 Planteamiento del Problema en la Red ATM La operación eficiente de una red depende de un número de parámetros de diseño y uno de ellos es el encaminamiento. El objetivo total de una política de encaminamiento es aumentar el rendimiento de procesamiento de la red, mientras que se debe garantizar el funcionamiento de la red dentro de niveles especificados en los servicios de Internet 2. La política del diseño del encaminamiento eficiente es de una enorme complejidad, puesto que depende de un número de variables y parámetros a veces inciertos. Esta complejidad es incluso mayor, considerando la diversidad de los requisitos del ancho de banda y de funcionamiento que la red debe apoyar. La política del encaminamiento es adaptar un abastecimiento de tráfico y de cambios topológicos. Donde podemos considerar los servicios que toma Internet 2 ya explicados en el capítulo 2. [Grif95] El encaminamiento en el Asynchronous Transfer Mode (ATM) (ITU I.150) se basa en la Trayectoria de Conexiones virtuales (VPCs). Una ruta se define como encadenamiento de VPCs, donde se define cada VPC como una secuencia de los acoplamientos que son asignados a una porción específica de la capacidad del acoplamiento. Ha estado extensamente aceptado que las características valiosas de la oferta de VPCs permiten la construcción económica de redes eficientes ATM, y se ha mostrado ser más importante en su flexibilidad en la gestión. Porque son VPCs definidas por parámetros que son configurables, y que posteriormente las rutas son basadas en su configuración en línea por un sistema de gestión según condiciones de la red. 85 Puesto que los cambios de comportamiento del usuario son dinámicos y está en peligro que la red puede convertirse ineficaz cuando el ancho de banda asignado a VPCs o las rutas existentes no estén de acuerdo con la cantidad de tráfico que requiere ser encaminado sobre ella. Para combatir esto, la topología de VPC, las rutas, y el ancho de banda asignado a VPCs deben ser configuradas de nuevo dinámicamente. Un VPC y el sistema de gestión de encaminamiento se requiere para aprovecharse de las características de VPCs mientras que se asegura que el funcionamiento de la red es tan alto como sea posible por condiciones del tráfico cambiante. La ITU-T se ha distinguido entre la gestión y el control de los planos en la operación de redes de comunicaciones (ITU I.320, I.321) a introducido la Red de Gestión de Telecomunicaciones (TMN) (ITU M.3010) como un medio gestión de aprovisionamiento de los componentes estándares interoperables según los estándares de la gestión de sistemas de la ISO. El TMN debe facilitar y realizar las funciones del plano del control configurando los parámetros operacionales. El TMN no debe substituir el plano del control y en general tiene menos requisitos rigurosos de respuesta en tiempo real. [Grif95] Aunque hay un interés significativo, en el área de la gestión de desempeño en ATM particularmente en el encaminamiento, en la asignación del ancho de banda y la gestión de VPC, el problema de VPC y encaminamiento, del resto de la gestión esta en gran parte abierto. La mayoría de los sistemas de gestión desplegados hoy en día son tratados en la supervisión de la configuración de red y a la inteligencia de la gestión que es proporcionada por los usuarios humanos de los sistemas de gestión. Hay una tendencia (Aspérula 1990, Wernic 1992, Geihs, 1992) para aumentar la inteligencia de la gestión, es en encapsular la inteligencia humana de la gestión en componentes para la toma de decisión en el movimiento de TMN hacia la automatización de la supervisión, de la toma de decisión y del lazo de la gestión de configuración. En el marco de la gestión de desempeño tiene el papel de investigar los requisitos de la Gestión de VPC y las funciones de gestión del encaminamiento para las redes basadas en ATM de B-ISDN y propone un sistema de TMN para la puesta en práctica. La terminología de ITU-T (ITU M.3020) es para describir a la Gestión de Servicio que adoptan los servicios. En detalle, la tesis propone una Gestión de Servicio que es adoptada como base principal para la obtención de la metodología de Gestión de desempeño. El particular propósito de este estudio conforme a la Gestión de Desempeño es para la gestión de VPC y la descomposición en un número de componentes. El 86 mapa de diseño de la arquitectura TMN es para la puesta en práctica de los principios de gestión de sistemas de TMN y de la OSI. Y estaremos basándonos en las propuestas de OSI para llevar a cabo la propuesta de esta metodología basada en la recomendación M.3020 y M.3010. 4.1.3 Gestión de Servicio Dentro de un ambiente de la red ATM de multi-clase el objetivo del VPC y la Gestión de servicio de encaminamiento garantiza la disponibilidad de la red mientras que la red resuelve los requisitos de funcionamiento de las diversas clases de servicio, establecidos por internet. La Gestión de Servicio es beneficiosa al operador de red, puesto que se asegura que los recursos de la red sean utilizados tan eficientemente como sea posible. La Gestión de Servicio en el encaminamiento y la VPC tienen aspectos estáticos y dinámicos. El aspecto estático se relaciona con el diseño de una red y de un plan de encaminamiento (el sistema de rutas VPC y de la selección de criterios para cada clase y del servicio de la fuente-destino) a la demanda predicha. En el hecho, el aspecto estático está de forma casi-estática en el sentido que se invoca y que siempre que las predicciones del tráfico cambian perceptiblemente. El aspecto dinámico maneja la red de VPC y el plan de encaminamiento para abastecer, el comportamiento imprevisible del usuario dentro de la época de las predicciones del tráfico. Esta Gestión de servicio pertenece a la gestión de desempeño y de la configuración de las áreas funcionales y cubren específicamente a la gestión del tráfico mientras que sus aspectos estáticos se relacionan con las funciones del planeamiento de red conforme la describe la planeación de una la red. [Grif95] La Figura 4.2 demuestra la relación de VPC y Gestión de encaminamiento con la red, encargados humanos (usuarios de TMN), otras funciones de gestión, clientes de la red y otros operadores de red. 87 Clientes y otros operadores de red Nuevos requisitos de QoS, VPN Políticas de negocio Funciones de Gestión de servicio Definicion de QoS Gestión de fallos Equipo fuera de servicio Estadisticas de desempeño VPC y Gestión de Invalidación manual encaminamiento Planeación de red, instalación, etc. Modelo de red Indicaciones bajo y sobre recursos Funciones de Gestión de negocios Topologia VPC, Ancho de banda VPC Red usada Topologia de red, red usada, gestión activa Condiciones de la interface Red usada Gestión de contabilidad Red Figura 4.1 opinión de la empresa VPC y la gestión de encaminamiento. Se adopta la metodología de la recomendación M.3020 de ITU-T. Según esto las recomendaciones de Gestión de Servicio esta compuesta por Componentes de Gestión de Servicio (MSCs) que alternadamente se construyen de los Componentes Funcionales de Gestión (MFCs). MFCs son ellos mismos construidos de los Funciones de Gestión de Sistemas (MFSs) de los cuales son los grupos de la gestión de funciones que pertenecen lógicamente juntas. En este papel descompondremos la Gestión de Servicio para identificar las componentes MSCs y MFCs para demostrar cómo éstos pueden ser Mapeados en la arquitectura lógica de TMN. 4.1.3.1 Ambiente Esta sección se describe el ambiente de la red bajo las perspectivas del VPC y de la Gestión de Servicio de encaminamiento. El ambiente manejado se asume para ser un ofrecimiento cambiante, ordenado de la red pública de ATM, servicios que se extienden de transferencias complejas de Internet y de archivos para conferencias multi-media. 4.1.3.2 Indicaciones en el servicio de red El servicio de enlaces se descomponen en un número de conexiones unidireccionales, se apoyan de una gran cantidad de tipos de conexión por ejemplo, los servicios de la 88 telefonía se pueden apoyar por un número tipos de conexión que ofrecen una gama de las calidades de servicio diferentes o llamadas que bloquean probabilidades. El termino de Clase de servicio (CoS) se utiliza para denotar un tipo de conexión particular. Los CoSs son servicios de portador proporcionados por la red. La definición de CoS caracteriza el tipo de conexión en los términos de los requisitos del ancho de banda y de su desempeño. Nuestro trabajo asume que los requisitos del ancho de banda se pueden caracterizar por medio de los valores pero que no son incluidos ya que nuestro trabajo esta enfocado a una metodología de funcionalidad de análisis y diseño, no bajo medición y análisis estadísticos. Los parámetros alternativos del ancho de banda se pueden utilizar según la conexión específica de algoritmos del control de la admisión de conexión (CAC) empleados en los conmutadores. Así mismo el seguimiento de los parámetros de desempeño: de probabilidad de pérdida de celdas; retraso; retraso del jitter y la probabilidad de bloqueo de la conexión (o disponibilidad). De hecho estos son los parámetros de desempeño para la Gestión de Servicio que se puede influenciar y es el interés directo para otro parámetro de desempeño que se puede incluir en la definición de CoS, por ejemplo el enlace de la conexión que se puede retrasar; pero éstos no pueden ser influenciados por la Gestión de Servicio por lo cual no se consideran en este trabajo. Nuestro trabajo se concentra en la gestión de los servicios de portador del punto de vista del operador de red. Aunque las propuestas de AAL se consideran en la perspectiva de los requisitos que se imponen ante los servicios del portador subyacentes, así como las aplicaciones de gestión end-to-end de la capa 4 y que no está mencionada la capa AAL en nuestro trabajo. [Grif95] 4.1.3.3 Indicaciones en el comportamiento del usuario El comportamiento del usuario no es constante y cambia dinámicamente. Hay dos fuentes de variación: tipo de usuario y la población de los usuarios. Hay potencialmente muchos tipos de usuarios caracterizados por los tipos de servicio que se utilizan y también por sus patrones de uso. El comportamiento de los usuarios individuales cambian en un cierto plazo con respecto a los servicios que utilizan. En virtud de la ley de los valores altos, las estimaciones del comportamiento del usuario agregado pueden ser hechas y las tendencias se puedan identificar en corto plazo (por ejemplo: negocio contra tráfico doméstico a través el día laborable) y a mediano y largo 89 plazo (por ejemplo: variaciones de estacionales, nuevo servicio introducción, competición). [Grif95] 4.1.3.4 Indicaciones en la operación de la red Las redes ATM son orientadas a conexión. Cada nodo proporciona básicamente la funcionalidad de la conmutación y el control de llamada (CC) que incluye además el control de la admisión y la selección así como el control de admisión de conexiones (CAC). La conmutación se hace en dos niveles: VP conexión-cruzada en las celdas del conmutador dentro de un VPC basado en el VPI; La conmutación VC cambian las celdas de un VCC particular entre VPCs basado en su VCI. VPCs son creados sobre una base semipermanente por acciones de la gestión mientras que se crean VCCs dinámicamente por el plano del control de la red vía señalización del UNI y de NNI. La selección de la ruta es referida a la selección de una ruta particular sobre una petición del establecimiento de la conexión por medio de un Algoritmo de la Selección de la Ruta (RSA). CAC se requiere en un orden para el nodo que determine si la conexión se puede acomodar en la ruta seleccionada. Esto se hace por medio del Algoritmo de CAC que controla el cargamento de la VPC en la región admisible es decir en la región donde el desbordamiento del almacenador intermediario está dentro de los límites de una probabilidad predefinida (pérdida de la celda del CAC). Las últimas dos funciones, selección de la ruta y CAC, son parte del plano del control. Al menos en su comportamiento se especifica según los parámetros operacionales que son definidos y manejados por TMN. Para lograr encaminar todas las rutas posibles hacia un destino dado y una particular CoS son almacenados localmente los conmutadores en una tabla de la selección de la ruta. Por un número de razones (crecientes de la disponibilidad, la vulnerabilidad reducida a las faltas, la adaptabilidad) más de una ruta puede existir en un destino para un CoS. El RSA en cada interruptor busca su tabla de la selección de la ruta para entradas satisfactorias a los destinos y CoS. 4.1.4 Descomposición 4.1.4.1 El Análisis El rechazo de una conexión es afectado por dos factores: el número de las rutas alternativas y de la capacidad disponible en los VPCs. Estos dos factores no se pueden tratar en el aislamiento y la gestión del sistema de VPC y del encaminamiento deben por 90 lo tanto asegurarse de que haya suficientes números de rutas y de ancho de banda en los VPCs que forman las rutas para garantizar funcionamiento y disponibilidad de la red. Según lo mencionado previamente la gestión de servicio debe proporcionar la adaptatividad a las condiciones al cambiar el tráfico. Hay dos niveles en los cuales el tráfico puede cambiar: variaciones principales en la celda dentro del alcance de una sola conexión; y las variaciones principales de la conexión como usuarios donde se establecen y enlazan llamadas. Lo anterior se considera ser tratado por el CAC y las funciones del plano de control del UPC ( Control de parámetros de uso: su función principal es proteger los recursos de la red ante la producción de una sobrecarga en una conexión) Las conexiones nunca pueden exceder los parámetros del ancho de banda definidos por el CoS debido al papel de las funciones del UPC. Si las conexiones no consumen por completo el ancho de banda, el déficit no se puede utilizar por otras conexiones debido al concepto de la reservación predefinida del ancho de banda en el tiempo de disposición de conexión que es pagado por los usuarios. Los siguientes puntos de la red son útiles para ofrecer diversos niveles de la abstracción para asistir a la tarea de formulación de los problemas hecha frente por el VPC y la Gestión de Servicio de encaminamiento: [Grif95] - Encaminamiento VPC o La red física que consiste en los nodos de red y los acoplamientos de la transmisión o La red de VPC que consiste en los interruptores VC interconectados por VPCs. - CoS o Las redes de ClassRoute. Para cada CoS, la red de ClassRoute es la sub- red de la red de VPC que consiste solamente en el VPCs que pertenece a las rutas de la CoS o Las redes de SDClassRoute. Para cada CoS y un par dado de la fuente- destino (s-d), la red de SDClassRoute es la sub-red de la red de ClassRoute que consiste solamente en los VPCs que pertenecen a las rutas del par dado (s-d). Al introducir la visión de la red antes dicha y la meta del VPC. Y la Gestión de Servicio del encaminamiento puede ser formulada como sigue: o Dado la red física y las predicciones del tráfico por el s-d y CoS, define las redes de VPC y de SDClassRoute para resolver las demandas del tráfico y 91 los niveles de funcionamiento especificados por la CoS que estén garantizados. La solución requiere respuestas a las preguntas siguientes: - ¿Cómo se construye y cambiaría su frecuencia de operación la red de VPC? - ¿Cómo se construyen y cambiaría la frecuencia de operación las redes de ClassRoute? - ¿Según qué criterios de encaminamiento será alcanzada en las redes de ClassRoute, es decir se dan las redes de VPC y de ClassRoute cómo los parámetros de la selección de la ruta asignados y cómo cambiaría la voluntad de ellos? La definición de las redes de VPC y de ClassRoute es un procedimiento iterativo que no puede separar las dos tareas implicadas. Las rutas se definen en términos de VPCs y el VPCs se ha definido para apoyar el encaminamiento. Se construyen los VPC y las redes de ClassRoute usando, como entrada, las estimaciones para el tráfico de la red por par del s-d (fuentes-destino) y CoS. La construcción de estas dos redes se relacionan con la actividad del planeamiento de red, por lo que la topología de la red física se definirá basándose en predicciones de tráfico de la red. El diseño del sistema de gestión de VPC y de encaminamiento debe por lo tanto abastecerse de cambios en las predicciones y las inexactitudes en las predicciones. Siempre que las predicciones del tráfico cambien, las redes de VPC y de ClassRoute necesitan ser reconstruidas. El nivel de la reconstrucción depende obviamente de los cambios significantes. Consecuentemente, los nuevos valores para VPC y el ancho de banda pueden ser dados, o puede cambiar la topología de la red de VPC (creando y suprimiendo VPCs) o la topología de las redes de ClassRoute que pueden cambiar (creando y suprimiendo las rutas). Cada una de estas reconfiguraciones se ocupa de un nivel diverso de abstracción según opiniones de operación de la red descritas arriba. Por otra parte pueden ser realizadas dentro de diversos escalamientos de tiempo y requieren diversos niveles de complejidad y por lo tanto del esfuerzo de cómputo. Consideramos que una manera eficiente de ocuparse de tales reconfiguraciones es a través de un sistema jerárquico. [Griffin 96] La esencia de la jerarquía que proponemos es como sigue: Primero el ancho de banda del VPC se configura de nuevo dentro de las redes existentes de SDClassRoute. Si no es posible acomodar las predicciones del tráfico dentro de las 92 redes de SDClassRoute, las redes de SDClassRoute se configuran de nuevo dentro de la red existente del VPC. Si se encuentra que la topología de VPC es deficiente para el tráfico predicho entonces finalmente se configura de nuevo la red de VPC. Puede ser considerada en última instancia que la red física no puede hacer frente al tráfico predicho y las funciones del planeamiento de red están informadas para solicitar que los recursos físicos adicionales estén dispuestos. Esto indica la necesidad de tener tres componentes de gestión: o Asignación del ancho de banda (para el ancho de banda de VPC pone al día las redes dadas de SDClassRoute), o Planeamiento de la ruta (para las actualizaciones de la ruta dadas la red de VPC) o Topología de VPC (para las actualizaciones de la topología de VPC). El antedicho asume que las predicciones del tráfico son exactas, pero como se menciono previamente, esto no se puede tomar por aceptado. Por esta razón introducimos un nivel inferior en la jerarquía que intenta hacer las estimaciones iniciales más exactas considerando el uso real de la red. La funcionalidad de nivel inferior funciona dentro de las redes de SDClassRoute y redefine los parámetros del ancho de banda de VPC y de la selección de la ruta que consideran la carga real de la red. La redefinición de las redes de SDClassRoute y de la topología de VPC no se hace a este nivel puesto que debe ser tan ligera como sea posible. Sin embargo este nivel proporcionará jitters al nivel más alto cuando se prueba que las primeras estimaciones del nivel que esta por debajo o encima de la estimación de una situación real y esto no se puede resolver a este nivel. Incluso si las predicciones son exactas, y pueden ser ligeramente exactas en el caso para las funciones de nivel inferior en las fluctuaciones del tráfico dentro de un cuadro de trabajo en tiempo de acuerdo a las predicciones. Esto indica la necesidad de dos componentes en el nivel inferior: - Distribución del ancho de banda (para poner al día el ancho de banda de VPC) - Balancear la carga (para poner al día parámetros de la selección de la ruta). El sistema jerárquico propuesto exhibe un comportamiento justo en la gestión por el que las decisiones de gestión iniciales tomadas con una perspectiva futura estén refinadas continuamente en la luz del desarrollo actual. Aparte de su imparcialidad, tal comportamiento proporciona un nivel deseable de la adaptabilidad a las condiciones de la red. [Grif95] 93 4.1.4.2 MSCs y MFCs La sección anterior indica la descomposición siguiente del VPC y la Gestión de Servicio de encaminamiento en MSCs: - Gestión de la topología de VPC que se pone en una topología MFC de VPC - Gestión del ancho de banda de VPC en la cual se descompone más a fondo: - o Una asignación MFC del ancho de banda de VPC o Una distribución MFC del ancho de banda de VPC Gestión del plan de encaminamiento que se pone en un planeamiento MFC de la ruta - El balancear la carga de la red que se pone en una carga que balancea el MFC - Verificación del funcionamiento que se pone en una verificación MFC del funcionamiento - Se requieren las predicciones del tráfico que se ponen en un modelo predicho MFC Del uso además, la ayuda siguiente MFCs: o Una gestión MFC de la configuración que incluye el modelo de la red o Un modelo MFC de la carga de la corriente para proporcionar la estadística requerida de la red o Un encargado MFC de CAC para que el TMN modele el comportamiento de CAC para los propósitos del dimensionar una CoS para el modelo MFC. 4.1.4.3 El mapa de la arquitectura de TMN La arquitectura funcional se basa en los principios de la recomendación M.3010. Figure 4.2 demostraciones de ITU-T la asignación de los MFCS a OSFs y también coloca el OSFs en las capas arquitectónicas. 94 Capa de Gestión de Servicio Predicción del Modelo Usado OSF Uso de predicción Topología VPC CoS Modelo OSF Supervisor CAC OSF Supervisor CAC Plan de Ruteo Capa de Gestión de Red Modelo de CoS Localización Balance de carga Balance de carga OSF Distribución VPC Distribución de ancho de banda OSF Verifiación de desempeño Verifiación de desempeño OSF Configuración del supervisor Carga actual Carga actual Capa de Gestión de Elemento de red Modelo OSF Configuración del supervisor OSF Figura 4.2. Arquitectura funcional Adoptando una arquitectura jerárquica de TMN nos aprovechamos de un acercamiento centralizado de la gestión en el sentido de reducir la colocación de la inteligencia en los elementos manejados así como en el diseño de la carga y su coste eventual. Pero al mismo tiempo utilizamos un sistema jerárquico para impulsar la inteligencia de la gestión y las funciones con frecuencia usadas tan cerca de la gestión como sea posible a los elementos de la red evitando las comunicaciones de gestión por encima de sistemas centralizados. [Griffin 95] 4.1.5 Descripción de los componente arquitectónicos La funcionalidad del OSFs identificada se discute brevemente en esta sección. Su descripción está en un alto nivel, como la parte principal en el papel de diseño público. Los problemas de OSF se asemejan a los problemas bien conocidos del diseño de red, capacidad que comparte, gestión del ancho de banda y encaminamiento. Sin embargo, estos problemas necesitan ser consolidados y poner en la perspectiva de la arquitectura propuesta. 4.1.5.1 Diseño OSF de la Ruta Este OSF tiene aspectos estáticos y dinámicos. El aspecto estático se relaciona con la actividad del planeamiento de red y se utiliza para configurar inicialmente la red en 95 términos de VPCs y de rutas. Esta parte se realiza en el tiempo del inicio de operación de la red. Los aspectos dinámicos de su operación abastecen sobre todo para los cambios en el tráfico predicho de la red y para las inexactitudes de la predicción que no se podrían resolver por el OSFs de nivel inferior. Consecuentemente, se configuran de nuevo los VPC y las redes de ClassRoute. La parte dinámica consiste en la funcionalidad de la topología de VPC, del planeamiento de la ruta y de la asignación MFCs del ancho de banda. La asignación MFC al ancho de banda es la primera función que se invocará siempre que el tráfico predicho cambie perceptiblemente. De acuerdo con el uso predicho, las predicciones del s-d (Fuente–Destino) y del mapa a VPCs dentro de las redes existentes de SDClassRoute, y la anchura de banda mínima requerida por cada VPC para resolver la demanda predicha es identificada. Si es imposible asignar la suficiente anchura de banda para el tráfico predicho dentro de los apremios de las redes actuales de SDClassRoute y de las capacidades del acoplamiento, se notifica el planeamiento MFC de la ruta. El planeamiento MFC de la ruta que procura reajustar las redes de SDClassRoute en la red existente de VPC, para quitar embotellamientos por ejemplo: se intenta aumentar el número de rutas alternativas, usando la topología actual de VPC. Este proceso también identifica los nuevos requisitos del ancho de banda en el VPCs. Para realzar el encaminamiento alternativo y compensar para las inexactitudes en las estimaciones del encaminamiento, el planeamiento de la ruta puede asignar un sistema de rutas de respaldo a cada CoS además del sistema primario de rutas. Para una CoS dada, el sistema de las rutas de respaldo consisten en las rutas asignadas al CoSs de alta calidad. Si el planeamiento MFC de la ruta no puede diseñar un nuevo sistema de las redes de SDClassRoute para acomodar el tráfico predicho debido a las limitaciones en la topología existente de la red de VPC, se invoca la topología MFC de VPC. La topología MFC de VPC reajusta la red de VPC para resolver los nuevos requisitos. Un VPCs nuevo se puede crear para coexistir con los actuales y las nuevas redes de SDClassRoute serán definidas para poder introducir la nueva topología de VPC gradualmente para las nuevas conexiones. Los requisitos de ancho de banda para el VPCs en la topología final de VPC se identifican y se pasan abajo a los MFCS más bajos. Si no es factible diseñar una red de VPC para satisfacer la demanda del tráfico debido a limitaciones en la red física subyacente, por ejemplo se notifican la insuficiencia de acoplamientos, en la función del planeamiento de red. El diseño OSF de la ruta debe proporcionar el diseño de la SDClassRoute de las redes, según los requisitos de CoS. Los puntos importantes de las pérdidas de celdas pueden ser resueltas ajustando los puntos de la pérdida de la celda 96 de CAC apropiadamente para asegurarse de que las pérdidas acumuladas de la célula sobre los acoplamientos de la red de SDClassRoute no excedan ya definidos para las garantías del CoS en un posible retraso para ser proporcionados e identificando el número máximo de almacenadores intermediarios y de interruptores así como asegurándose de que las redes de SDClassRoute no exceden estos valores. Finalmente la disponibilidad de CoS es garantizada siendo que en su totalidad es optimizar el procedimiento iterativo para poder definir las redes de VPC y de SDClassRoute que satisfacen su funcionamiento de la red. [Grif95] 4.1.5.2 Distribución OSF en el ancho de banda de VPC Tomando la carga actual en cuenta, la distribución OSF del ancho de banda de VPC pone en ejecución del ancho de banda a VPCs por requerimiento por el diseño OSF de la ruta. La carga actual se debe considerar para evitar situaciones donde está más bajo el ancho de banda necesaria para la esta misma carga actual y por lo tanto la nueva asignación del ancho de banda violaría las recomendaciones hechas por los algoritmos de CAC en la red y causaría posiblemente pérdidas excesivas de la celda. Además de poner las políticas en ejecución del diseño OSF de la ruta, las tentativas de la distribución OSF del ancho de banda de VPC de compensar para las inexactitudes en el modelo predicho del uso es distribuyendo cualquier ancho de banda no localizado del acoplamiento (vista como un punto común) entre el ancho de banda de VPCs. (ancho de banda asignada menos carga actual) en cada VPC con el criterio para que la redistribución evitando alguna situación donde algún VPCs sea utilizada (y por lo tanto hay poco ancho de banda disponible para las nuevas conexiones) mientras que los otros VPCs en los mismos acoplamientos se utiliza ligeramente. El ancho de banda se distribuye tan uniformemente como sea posible dentro de ciertas ventajas de operación de los VPCs. Por ejemplo los VPCs se pueden asignar a una clase o la a cualidad de la prioridad para indicar qué VPCs debe ganar ancho de banda a expensas de una prioridad más baja de VPCs. Los VPCs usadas para CoSs en un punto bajo de operación puede bloquear las probabilidades de asignación tendrán una prioridad más alta. Variando el intervalo de asignaciones de ancho de banda así como operando la distribución OSF del ancho de banda de VPC puede ser controlada en su uniformidad operación de las rutas. 97 4.1.5.3 Carga que balancea OSF La carga que balancea OSF funciona dentro del SDClassRoute y las redes de VPC definidas por el diseño de la ruta OSF. El diseño OSF de la ruta reserva los recursos de la red (VPCs) e indica su uso (por las rutas que definen). La carga que balancea OSF intenta hacer el mejor uso posible (la mayoría de la utilización eficiente) de los recursos reservados. Para alcanzar esto, la carga que balancea tomas de OSF con una visión de red-Amplia e intentos para influenciar las decisiones del encaminamiento de modo que las conexiones que llegan, utilicen las rutas con la disponibilidad más alta. La visión tomada es que las rutas en un nodo están dadas a la prioridad según su potencial siendo rutas adecuadas. Puesto que en nuestro caso nos ocupamos sobre todo de una red orientada a conexión, se hace referencia a la disponibilidad (capacidad de repuesto) de la ruta para acomodar conexiones, de esta manera la carga de la red se separa como sea posible y la disponibilidad de la red para las nuevas conexiones (por lo tanto la carga conocida que balancea). Observe que la visión antes dicha está de acuerdo con el propósito tradicional de encaminar según sobre qué esquemas de encaminamiento son variantes los algoritmos más cortos de la trayectoria que el ambiente de la multi-clase que la red funciona internamente y que deba ser considerado. La carga que balancea OSF no debe tener como objetivo solamente el optimizar el encaminamiento en las redes de ClassRoute sino también en la red de VPC. Este propósito justifica la necesidad de una componente central, como la carga que balancea OSF, de utilizar la información de una red-amplia sobre cada clase que intenta armonizar el encaminamiento dentro de cada clase y entre las clases. [Griffin 95] 4.1.5.4 Verificación OSF del desempeño La verificación de OSF del desempeño se refiere a asegurarse de que la red resuelve las fuentes de desempeño para diversos CoSs. Esto se hace en dos niveles: supervisando la red y aceptando las quejas de QoS del cliente vía la relación con el cliente de la Capa de servicio. Los cocientes del rechazamiento de la conexión por CoS y por pares de destinos de la fuente se recuperan del Modelo Actual de la Carga y se comparan a los destinos del rechazamiento especificado por las quejas de CoS. El cliente se analiza y si se justifica el diseño OSF de la ruta serán puestos en marcha por lo que si CoSs se utiliza para experimentar cocientes del rechazamiento de la conexión en el exceso del destino, una indicación se envía al diseño OSF de la ruta para encausar el número de rutas, o el ancho 98 de banda requerida por las rutas, para ser puesto en operación inmediata. La verificación de OSF cuantifica el funcionamiento del diseño de la ruta, la carga que balancea y la distribución OSFs del ancho de banda de VPC, siendo la medida incuestionable de su eficacia. 4.1.5.5 Modelo Predicho OSF del uso Este modelo de uso es predicho de la red en los términos de los números de conexiones de cada CoS requerido entre los pares del s-d (fuente-destino). Los detalles del modelo como el número de conexiones cambia: hora por hora durante el día; día por día durante la semana; y semana por semana durante el año que esto es configurada inicialmente por el porcentaje de disponibilidad del TMN pero es modificada por el uso real de la red vía el modelo actual de la carga. Esto es de modo que el modelo predicho llegue a ser más exacto mientras que se va ganando la experiencia del uso de la red. Siempre que el modelo predicho de la carga indique que el tráfico cambiará perceptiblemente al diseño OSF de la ruta que será proporcionando una predicción del tráfico para la próxima vez en su intervalo de asignación de alguna ruta. La definición exacta de un cambio significativo es una variable del diseño que se experimentará según el desempeño del sistema en su totalidad. 4.1.5.6 Gestión de Configuración del OSF El encargado de la configuración es responsable de mantener un modelo constante de la configuración física y lógica de la red. Recibirá acciones de la configuración del otro OSFs y será responsable de poner los cambios en ejecución en la red. Esta tarea puede implicar la coordinación de las acciones de la configuración sobre un número de elementos de la red, por ejemplo cuando se crea un VPC. El encargado de la configuración puede proporcionar informes del acontecimiento al otro OSFs siempre que una acción de la configuración haya tenido éxito 4.1.5.7. Modelo Actual OSF de la Carga El modelo actual de la carga supervisa el uso de la red y se calcula estadísticamente el uso según los requisitos del OSFs. El modelo actual de la carga es capaz de calcular el pico, el medio, la estadística de EWMA, etc. según las especificaciones de otros componentes. Identificará el número mínimo de las puntas de prueba y de las medidas de la red para resolver las demandas variadas de sus usuarios [Griffin 96] 99 4.1.5.8 Encargado OSF de CAC El encargado de CAC reproduce el algoritmo de CAC en la red. Cuando está provisto de una mezcla del tráfico en la forma de una lista del número de conexiones de cada CoS el encargado de CAC vuelve el ancho de banda eficaz de esa mezcla del tráfico. El cálculo tiene exactamente el mismo resultado que el algoritmo equivalente de CAC en la red. 4.1.6 Interacciones entre los componentes arquitectónicos 4.1.6.1 Relación del Encargado-Agente La figura 4.4 demuestra las relaciones del encargado-agente entre los componentes derivados. La distribución OSF y la carga del ancho de banda de VPC que balancea OSF son agentes del diseño OSF de la ruta. Sin embargo, su operación no es totalmente independiente, puesto que el efecto (en la red) de uno de ellos es considerado por el otro. La distribución OSF del ancho de banda de VPC mira la carga actual del VPCs, que es determinado por las decisiones del encaminamiento, y la carga que balancea OSF que mira la disponibilidad del VPCs que es determinado por la distribución OSF del ancho de banda del VPC. Esto indica que una cierta coordinación necesita existir entre ellas, para evitar contradicciones posibles. El diseño OSF y la distribución OSF de la ruta del ancho de banda del VPC maneja la red de VPC mientras que la carga que balancea el OSF se determina cómo optimizar su uso. Se puede discutir que la carga que balancea OSF complementa la distribución OSF del ancho de banda de VPC, en el sentido que se aprovecha el aumento del ancho de banda de VPC. Cuando la carga que balancea OSF se activa se asume una red estable de VPC. Esto implica que durante la operación de la carga que balancea OSF, la distribución OSF del ancho de banda de VPC y el diseño OSF de la ruta se debe prohibir tomar acciones. E inversamente cuando la distribución OSF o el diseño OSF del ancho de banda de VPC de la ruta es alrededor de cambiar el ancho de banda o topología de VPC, la carga que balancea OSF no debe ser activada hasta que se ha realizado el cambio. [Griffin 95] 100 Modelo CoS Uso de Modelo Gestor CAC Diseño de encaminamiento A B Verificación A es un gestor para B Carga Balanceada (1) Diastribución VPC B/w Gestor Configuración Modelo Corriene de Carga OAF MF o NEF Figura 4.4 (1) Relación del encargado-agente entre los componentes derivados. 4.1.7 Conclusiones y trabajo futuro En este estudio nos abocamos específicamente a un VPC y de un servicio de la gestión de encaminamiento para las redes de multi-clase sobre internet que son sistemas abiertos. El sistema propuesto ofrece las funciones genéricas de la supervisión de funcionamiento, de la supervisión de la carga (gestión de desempeño) y de la gestión de configuración. Además, proporciona las funciones específicas para la gestión de encaminamiento y del ancho de banda en una estructura jerárquica. Los componentes en la jerarquía diferencian en los términos del nivel de la abstracción y de la complejidad. Las funciones de la gestión que se invocarán son acerca de los NEs y estos nos permiten indirectamente reducir gastos de gestión. Las funciones más comprensivas se ponen en los niveles más altos de la jerarquía y se invocan solamente cuando los niveles más bajos no pueden resolver propuestas dentro del alcance de su funcionalidad y parámetros operacionales. Tal jerarquía preve el refinamiento continuo de las decisiones de gestión y evita los problemas de un acercamiento completamente centralizado. El sistema de gestión de VPC y del encaminamiento proporciona las ventajas siguientes al operador de red: [Griffin 95]. 101 Permite que la red sea utilizada tan eficientemente como sea posible dentro de las ventajas de los recursos físicos. Indicará cuando los recursos de la red son escasos para el tráfico y por lo tanto los recursos adicionales necesitan ser desplegados. Demostrará alternativamente cuando los recursos no son usados y puede tomarse el servicio para evitar la congestión a otra parte. Pone los requisitos en ejecución de la capa de la gestión de servicio para prever usuarios según la política de negocio del operador de red. Una gama calidades del servicio y los tipos pueden ser puestos en ejecución para los cuales la capa de la gestión de servicio puede practicar diversos costos de operación. Diseña el recubrimiento lógico VPC y las redes de encaminamiento de modo que los diversos tipos del servicio puedan existir en la misma red física. Distribuye la carga tan uniformemente como sea posible a través de la red al maximizar la disponibilidad de la red y reducir al mínimo interrupciones en el caso de fallas. Puede hacer configuraciones dinámicas para adaptar la configuración de red al tráfico que fluctúa y para realizar cambios antes de que sucedan realmente basado en un modelo predicho de uso. Por la propia inteligencia constructiva que cuenta el TMN los requisitos de operación de los NEs son simplificados. Las funciones de TMN substituyen la alternativa de algoritmos elaborados en los interruptores que deben obrar recíprocamente y señalar procedimientos para permitir que las condiciones de la red global influencien algoritmos locales. En un ambiente de los multiclass el intercambio de la información de encaminamiento es prohibitivo simplemente por la cantidad considerable de los CoSs. Por lo tanto al aumentar la capacidad crece exponencialmente el tráfico. Poniendo estas funciones en el TMN no se pone ningún requisito adicional en el NEs aparte del más básico de las interfaces de la gestión. El diseño es bastante flexible al incorporar diversos algoritmos o diversos niveles de la funcionalidad para adaptarse el CAC específico y RSAs en los elementos de la red. Los algoritmos estáticos en los elementos se pueden transformar a los algoritmos casi-estáticos por las acciones de TMN. El sistema propuesto se puede utilizar para poner servicios de red en ejecución privados y virtuales puesto que maneja la reservación del ancho de banda y encaminamiento dentro de los puntos específicos del funcionamiento. [Griffin 95] Se ha hecho la disposición de proporcionar una interfaz abstracta a las funciones de la gestión del servicio responsable de los servicios privados para poner sus peticiones en ejecución. El marco arquitectónico se puede utilizar como probar y validar a la gestión del ancho de banda, gestión de encaminando y los algoritmos que balancean la carga. El modelar la información de las interfaces se basa en los estándares existentes y que 102 emergen y cuando sea necesario, las definiciones del objeto fueron ampliadas y los nuevos objetos manejados fueron definidos. Seguido por las recomendaciones de la ITU-T M.3010, así como puesta en funcionamiento de la recomendación M.3020, el enfoque cubre las expectativas parte de su planeación y diseño para el reconocimiento de cada uno de los elementos en su participación primordial y que puede afectar al funcionamiento de la red con respecto al control de desempeño que es la parte fundamental de este trabajo y podemos establecer esta metodología como parte funcional en el desarrollo futuro de nuevas tecnologías que apremien el estudio del desempeño de una red, que aunque en este escenario, daremos el siguiente paso de hacer un estudio comparativo con respecto a este en una red ATM con unas red MPLS que da nuevas expectativas de funcionamiento óptimo y que es necesario su aplicación del modelo de Gestión TMN y dar la visión en el plano de funcionalidad propia basado en las mismas recomendaciones de la ITU-T y conoceremos su ventajas y ventajas en su funcionamiento. 4.2 Escenario 2. El sistema TMN para LSP y Gestión de encaminamiento en redes MPLS con Servicios de Internet 2 4.2.1 Introducción En esta parte del trabajo presentamos el estudio que se realiza con respecto a una red MPLS aplicando el modelo de Gestión TMN y nos enfocamos a analizar el funcionamiento de LSP y el servicio de Gestión de encaminamiento para una red MPLS con Servicios de Internet 2, como parte de la estrategia de abarcar las funciones que intervienen para establecer la metodología Como se realizo en los mecanismos de descomposición del escenario 1 se hará de igual manera así como al describir las componentes arquitectónicas y análisis, conforme a las recomendaciones de la ITU-T M.3010 y la metodología M.3020 El sistema propuesto ofrece las funciones genéricas de la supervisión de funcionamiento, así como supervisión de la carga y gestión de configuración en redes MPLS (figura 4.5). Además, proporciona las funciones específicas para Gestión de encaminamiento en el ancho de banda en una estructura jerárquica. 103 Camino por Conmutación de Etiquetas (LSP) Figura 4.5. Componentes de una red MPLS 4.2.2 Planteamiento del Problema en la Red MPLS La evolución de las tecnologías de las comunicaciones hacia redes de servicios integrados conlleva un aumento de complejidad en su gestión. Entendemos por redes de integración de servicios aquellas redes más dinámicas orientadas a la conexión con garantías de calidad de servicio, con un crecimiento en nodos, usuarios y sobre todo en tráfico. Los mecanismos existentes contemplan la gestión desde una óptica básicamente aislada en cuanto a asignación de anchos de banda, encaminamiento, establecimiento de circuitos y de rutas de respaldo, etc. Por otro lado, dichas gestiones suelen actuar de forma estática, como procesos activados de forma manual y esporádica. Así pues, nos encontramos ante un nuevo escenario donde se requieren nuevas estrategias que proporcionen a la red el control y el dinamismo que los nuevos servicios requieren. La propuesta del desarrollo del modulo de gestión de red orientado al encaminamiento con y a la gestión de los servicios de la red adaptándolos al estado de ésta y a las necesidades de calidad de servicio (QoS: quality of service) del tráfico. MPLS es la tecnología elegida para el desarrollo del sistema. El objetivo total de una política de encaminamiento es aumentar el rendimiento de procesamiento de la red, mientras que se debe garantizar el funcionamiento de la red dentro de niveles especificados en los servicios de Internet 2 ya explicado en el escenario 1. 104 El MPLS tiene como principal característica la división de los planos de control y de envío. El mecanismo de control se encarga de dos funciones: la creación de las rutas, que implica la construcción de las tablas de encaminamiento, y la señalización de las rutas. El módulo de envío se encarga de la conmutación de paquetes mediante el mecanismo de intercambio de etiquetas. Gracias a este intercambio de etiquetas se pueden crear los LSP (label switching paths), haciendo un paralelismo con ATM y sus VCI de operación. La distribución de la información entre los diferentes nodos (distribución de las etiquetas) se realiza mediante un algoritmo de señalización. Actualmente existen dos alternativas: variaciones a RSVP (reservation protocol) o el LDP (label distribution protocol). La arquitectura MPLS está pensada como protocolo en un entorno de red donde podemos encontrar ruteadores IP, conmutadores ATM, etc. Una red MPLS estará compuesta por ruteadores MPLS: LSR (label switch routers). Éstos se dividen en nodos de entrada (ingress nodes), nodos de salida (egress nodes) y nodos intermedios (core routers). Los primeros y los de salida se encargan de encapsular y desencapsular los paquetes, mientras que los intermedios únicamente realizan la conmutación de etiquetas. Dos conceptos fundamentales en MPLS lo diferencian de otros protocolos: son la posibilidad de agregar tráfico y la posibilidad de hacer encaminamiento explícito. MPLS clasifica en el nodo de entrada (ingress node) el tráfico de modo que le asigna, según el destino y la clase de tráfico, una FEC (forwarding equivalence class). Cada flujo de tráfico tendrá asociada una FEC que podrá asignarse a un LSP determinado. Además, tendremos la posibilidad de agregar flujos asignándolos a una FEC determinada. Por otro lado, podemos hacer un encaminamiento explícito, indicando cuáles son los nodos por los que queremos que pase un LSP. Esto nos permite, a diferencia de otros protocolos de encaminamiento que no ofrecen esta posibilidad (como el encaminamiento en IP), evitar situaciones de congestión. Por ejemplo, si el encaminamiento proporciona una ruta que ya está congestionada, debido a que sólo tiene en cuenta el destino y el número mínimo de saltos. Estas dos herramientas, la agregación de tráfico y el encaminamiento explícito, hacen de MPLS un protocolo adecuado para gestionar las redes actuales. O dicho de otro modo, para realizar lo que actualmente se conoce como ingeniería del tráfico. Uno de los problemas actuales en redes IP es la falta de “habilidad” para ajustar flujos de tráfico haciendo un uso adecuado del ancho de banda de la red. Tampoco se dispone de mecanismos para diferenciar clases de tráfico. Este problema es el que intenta solucionar la ingeniería del tráfico en entornos MPLS. Según define el IETF, un enlace troncal de tráfico (traffic trunk) es un agregado de todo el 105 tráfico entre un ingress node y un egress node. La idea de la ingeniería del tráfico es cómo se puede realizar el mapeo de traffic trunks sobre la red física optimizando el desempeño (uso de los recursos, balanceo de la carga, etc.). Parte de esta solución esta desarrollada por la implementación del modelo de Gestión. Como ya se explicó la base del MPLS está en la asignación e intercambio de etiquetas ya expuesto, que permiten el establecimiento de los caminos LSP por la red. Los LSPs son simplex por naturaleza (se establecen para un sentido del tráfico en cada punto de entrada a la red); el tráfico dúplex requiere dos LSPs, uno en cada sentido. Cada LSP se crea a base de concatenar uno o más saltos (hops) en los que se intercambian las etiquetas, de modo que cada paquete se envía de un "conmutador de etiquetas" (LabelSwiching Router) a otro, a través del dominio MPLS. Un LSR no es sino un ruteador especializado en el envío de paquetes etiquetados por MPLS y el LDP es un protocolo nuevo para la distribución de información de ataduras de etiqueta para LSR en una red MPLS. Es utilizado para mapear (relacionar) FECs a etiquetas, las cuales se utilizan para formar LSP (caminos de conmutación por etiquetas). Ya explicados en el capítulo 2. La ITU-T ha distinguido entre la gestión y el control de los planos en la operación de redes de comunicaciones (ITU I.320, I.321) a introducido la Red de Gestión de Telecomunicaciones (TMN) (ITU M.3010) como medios gestión del aprovisionamiento con los componentes estándares interoperables según los estándares de la gestión de sistemas de la ISO. Esto ya expuesto por el escenario anterior usamos la misma metodología. El TMN debe facilitar y realizar las funciones del plano del control y de envío configurando los parámetros operacionales. El TMN no debe substituir el plano del control y de envío. Aunque hay un interés significativo, existente en la s redes de comunicaciones en el área de la gestión de desempeño de MPLS particularmente de igual manera en el encaminamiento, que es llevado acabo por etiquetas. Aunque un aspecto importante con respecto en comparación con la red ATM es que además existe el servicio de IP, cabe mencionar que los requerimientos impuestos para su funcionamiento, nos arroja una cantidad de variables adicionales, y esto nos orienta en las redes ATM no incluyen el parámetro de IP como parte de su encaminamiento. La asignación del ancho de banda y la gestión en las LSP, puede provocar el problema de su encaminamiento, así como su conmutación ya que los servicios de internet son normalmente abiertos, esto como se explico en el escenario 1 nos da la indicación que la 106 toma de decisiones esta relacionada a TMN que se sigue orientando a la automatización de la supervisión, y el lazo con la gestión de configuración. En el marco de la gestión de desempeño tiene el papel de investigar los requisitos de la Gestión de LSP y las funciones de gestión del encaminamiento en el nivel 2 y 3 para las redes basadas en MPLS y proponemos de nueva cuenta el un sistema de TMN para la puesta en práctica. La terminología de ITU-T (ITU M.3020) es para describir a la Gestión de Servicio que adoptan los servicios. En detalle el papel propone una Gestión de Servicio que es adoptada como base principal para la obtención de la metodología de Gestión de desempeño. El particular propósito de este estudio conforme a la Gestión de Desempeño es para la gestión de LSP y la descomposición en un número de componentes. El mapa de diseño de la arquitectura TMN es para la puesta en práctica de los principios de gestión de sistemas de TMN y de la OSI. Y estaremos basándonos en las propuestas de OSI para llevar a cabo la propuesta de esta metodología basada en la recomendación M.3020 y M.3010. 4.2.3 Gestión de Servicio Dentro de un ambiente de la red MPLS de multi-clase el objetivo de la LSP y la Gestión de servicio de encaminamiento en el nivel 2 y 3 garantiza la disponibilidad de la red mientras que la red resuelve los requisitos de funcionamiento de las diversas clases del servicio establecidos por internet. La Gestión de servicio como se explico en el escenario 1, tiene similitudes en el funcionamiento de la LSP como sustitución del VPC , y su funcionamiento consta de igual manera en el aspecto estático y dinámico, dado que el aspecto estático se relaciona con el diseño de una red y de un plan de encaminamiento propuesto para la integración del nivel 2 y 3 (el sistema de rutas LSP y de la selección de criterios para cada clase y del servicio de la fuente-destino) a la demanda predicha. El aspecto dinámico maneja la red de LSP y el plan de encaminamiento sobre la componente de control y envío para abastecer, el comportamiento imprevisible del usuario dentro de la época de las predicciones del tráfico. La figura 4.6 demuestra la relación de LSP y Gestión de encaminamiento con la red, encargados humanos (usuarios de TMN), otras funciones de gestión, clientes de la red y otros operadores de red. 107 Clientes y otros operadores de red Políticas de negocio Nuevos requisitos de QoS, VPN Funciones de Gestión de servicio Definicion de QoS Gestión de fallos Planeación de red, instalación, etc. Equipo fuera de servicio Modelo de red Indicaciones bajo y sobre recursos Funciones de Gestión de negocios Estadisticas de desempeño LSP y Gestión de encaminami ento de nivel 2y3 Red usada Invalidación manual HCI Topologia de red, red usada, gestión activa Topologia Red usada LSPy ancho de banda LSP Gestión de contabilidad Red Figura 4.6 opinión de la empresa LSP y la gestión de encaminamiento en el nivel 2 y 3 De acuerdo a la metodología de la recomendación M.3020 de ITU-T se adopta y se enfoca la misma relación que se tiene con las recomendaciones de Gestión de Servicio tanto sus componentes como sus funciones. 4.2.3.1 Indicaciones en el servicio de red El servicio de enlaces se descompone en un número de conexiones unidireccionales y bidireccionales. Una gran cantidad de tipos de conexión que se llevan a cabo por Etiquetas por ejemplo al existir una aplicación en la cual los LSP hace rutas explicitas mismas que el administrador de red, toma una ruta real, que es tomada una corta distancia ya que MPLS justifica un sistema de ingeniería de tráfico apoyando una serie de aplicaciones estadísticas permitiendo planificar la red con rutas de mayor exactitud de enlace de datos. Nuestro trabajo asume que los requisitos del ancho de banda se pueden caracterizar por medio de los valores. Los parámetros alternativos del ancho de banda se pueden utilizar según la conexión específica de algoritmos del encaminamiento que son los LSR y que agrupan las etiquetas por medio del FEC, empleados por los conmutadores LSR. Así mismo el seguimiento de los parámetros de desempeño ya mencionados en el escenario 1 y se mantiene el trabajo concentrándose en la gestión de los servicios de portador del punto de vista del operador de red. 108 4.2.3.2 Indicaciones en el comportamiento del usuario Las indicaciones se mantienen de la misma manera en cuanto hay dos fuentes de variación: tipo de usuario y la población de los usuarios. 4.2.3.3 Indicaciones en la operación de la red Las redes MPLS son orientadas a conexión. Donde cada nodo proporciona la funcionalidad de conmutación en la periferia de la red por medio del LER, y que tiene la relación con el funcionamiento de la conmutación de los LSP y esto es indicado en el capítulo 2 en la sección de MPLS. 4.2.4 Descomposición 4.2.4.1 El Análisis MPLS permite establecer LSP y además establecer LSP de respaldo asociados a los de trabajo. El establecimiento de todos estos LSP se realiza usando algoritmos de encaminamiento con calidad de servicio que buscan la ruta óptima, tanto desde el punto de vista de la calidad de servicio requerida como desde el punto de vista del uso de los recursos de la red. A partir de este punto la gestión de recursos básicamente se encarga de ajustar los LSP establecidos en la red adaptándolos al uso real que se esté haciendo de ellos, de forma parecida a la realizada en ATM. Para conseguir esta adaptación al tráfico real de la red, los mecanismos de ingeniería del tráfico deben realizar tareas de monitorización. Por lo tanto, se puede afirmar que los mecanismos de gestión de recursos están constantemente pendientes del estado real de la red y fuertemente relacionados con el establecimiento de LSP de trabajo y de respaldo con algoritmos de encaminamiento con calidad de servicio. Por este motivo, la gestión de servicios también cubre la detección de las alarmas en el momento en que se produce un fallo en la red y la activación de los LSP de respaldo. Por lo tanto, la gestión de servicios cubre la monitorización del estado real de la red y procede a su adaptación (cambiando los LSP existentes) al tráfico real y a los posibles fallos que puedan surgir (activando los LSP de respaldo necesarios). Una vez establecidos los LSP, éstos tendrán una cierta vida, corta o larga, durante la cual pueden sufrir una serie de problemas. Se puede establecer un LSP con un cierto ancho de banda asignado para una cierta cantidad de tráfico y con una cierta calidad de servicio.[Calle99] Sobre este LSP puede suceder que, al cabo de un cierto tiempo, la demanda de tráfico supere la reserva inicial y se produzca un rechazo de tráfico de entrada. Este rechazo o 109 bloqueo se produce debido a algún tipo mecanismo de control de admisión necesario para garantizar la calidad de servicio de las distintas conexiones existentes, y puede cuantificarse calculando la probabilidad de bloqueo para cada LSP. Otro fenómeno que puede suceder en que, una vez reservada una cierta cantidad de ancho de banda para un cierto LSP, después de cierto tiempo este LSP esté poco utilizado y se estén desperdiciando los recursos de la red, cuando posiblemente otros LSP puedan estar congestionados y rechazando tráfico. [Calle99] 4.2.4.3 MSCs y MFCs La sección anterior indica la descomposición siguiente del LSP y la Gestión de Servicio de encaminamiento en MSCs, dado que nos enfocamos en el control de las funciones y componentes que atañen en la Gestión de Servicio proponemos de igual manera la relación entre ellas mismas de acuerdo las funciones del MPLS: - Gestión de la topología de LSP que se pone en una topología MFC de LSP - Gestión del ancho de banda de LSP en la cual se descompone más a fondo: - o Una asignación MFC de la anchura de banda de LSP o Una distribución MFC de la anchura de banda de LSP Gestión del plan de encaminamiento que se pone en un planeamiento MFC de la ruta - El balancear la carga de la red que se pone en una carga que balancea el MFC - Verificación del funcionamiento que se pone en una verificación MFC del funcionamiento - Se requieren las predicciones del tráfico que se ponen en un modelo predicho MFC Del uso además, la ayuda siguiente MFCs: o Una gestión MFC de la configuración que incluye el modelo de la red o Un modelo MFC de la carga de la corriente para proporcionar la estadística requerida de la red o un encargado MFC de FEC para que el TMN modele el comportamiento de FEC para los propósitos del dimensionar una CoS para el modelo MFC. 110 4.2.4.4 El mapa de la arquitectura de TMN La arquitectura funcional se basa en los principios de la recomendación M.3010. Figure 4.5 demostraciones de ITU-T, la asignación de los MFCS a OSFs y también coloca el OSFs en las capas arquitectónicas. C apa de G estión de Servicio Predicción del M odelo U sado O SF U so de predicción Plano de control Algoritm o de encam inam iento Plano de Envio C oS M odelo O SF Protocolo de Señalización LD P para IP C apa de G estión de R ed M odelo de C oS T opología LSP Supervisor FEC O SF Supervisor FEC Plan de R uteo Localización Balance de carga Balance de carga O SF LD P LSP D istribución de ancho de banda O SF Verifiación de desem peño C onfiguración del supervisor C arga actual C apa de G estión de Elem ento de red D istribución Verifiación de desem peño O SF C arga actual M odelo O SF C onfiguración del supervisor O SF Figura 4.5. Arquitectura funcional De acuerdo a la figura 4.5 observamos los cambios que se han tenido de acuerdo a la operación del MPLS y enfoca la distribución de operaciones dentro de la Capa de Gestión de Red, pero con la integración de los dos planos de operación de MPLS que tiene como característica especial, permitiéndonos identificar los planos de control y de envío, así como la asignación de los componentes de MPLS. Adoptando una arquitectura jerárquica de TMN nos aprovechamos de un acercamiento centralizado de la gestión en el sentido de reducir la colocación de la inteligencia en los elementos manejados así como en el diseño de la carga y su coste eventual. Pero en el mismo tiempo utilizamos un sistema jerárquico para impulsar la inteligencia de la gestión y las funciones con frecuencia usadas tan cerca de la gestión como sea posible a los elementos de la red evitando las comunicaciones de gestión por encima de sistemas centralizados. 111 4.2.5 Descripción de los componentes arquitectónicos La funcionalidad del OSFs identificada se discute brevemente en esta sección misma que es adoptada por el escenario 1. 4.2.5.1 Diseño OSF de la Ruta Este OSF tiene aspectos estáticos y dinámicos. El aspecto estático se relaciona con la actividad del planeamiento de red y se utiliza para configurar inicialmente la red en términos de LSPs y de rutas. Esta parte se realiza en el tiempo de operación inicial de la red. Los aspectos dinámicos de su operación abastecen sobre todo para los cambios en el tráfico predicho de la red y para las inexactitudes de la predicción que no se podrían resolver por el OSFs de nivel inferior. Consecuentemente, se configuran de nuevo los LSP y las redes de LDP. La parte dinámica consiste en la funcionalidad de la topología de LSP, del planeamiento de la ruta y de la asignación MFCs del ancho de banda. La asignación MFC al ancho de banda es la primera función que se invocará siempre que el tráfico predicho cambie perceptiblemente. De acuerdo con el uso predicho, las predicciones del s-d (Fuente –Destino) y del mapa a LSP dentro de las redes existentes de LDP, y la anchura de banda mínima requerida por cada LSP para resolver la demanda predicha se identifica. El planeamiento MFC de la ruta que procura reajustar las redes de LDP en la red existente de LSP, para quitar embotellamientos por ejemplo. Intenta asignar el número de rutas reales, usando la topología actual de LSP. Este proceso también identifica los nuevos requisitos del ancho de banda en el LSP El establecimiento de una ruta de origen a destino se puede hacer de varias maneras. La opción más sencilla es buscar un camino que sea lo más corto posible (familia SPR, shortest path routing). Si suponemos que se mide la distancia en número de saltos, el algoritmo más sencillo sería un MHA (minimun hop algorithm). Si consideramos algoritmos de encaminamiento con calidad de servicio, éstos tendrán en cuenta el hecho de maximizar la utilización de los recursos y la minimización de la carga (en términos de banda) de la red. Aquí entraríamos en otra familia de algoritmos como son los WSP (widest shortest path), SWP (shortest widest path), DAP (dynamic alternative path) En estos algoritmos los dos objetivos usados para la elección de la ruta son: el número de saltos (maximizar la utilización de los recursos) y el ancho de banda disponible (balancear la carga de la red). Estos algoritmos consiguen maximizar el número de peticiones de establecimiento de las rutas. Otra familia de algoritmos de encaminamiento con calidad de servicio, donde sí tenemos como objetivo la maximización de este parámetro, son los de 112 mínima interferencia. Se busca establecer rutas que maximicen el sumatorio de los máximos flujos de la red, con lo cual se permite el poder establecer un mayor número de peticiones. MIRA es una propuesta de encaminamiento con mínimas interferencias que además tiene en cuenta las características de una red MPLS (a priori podemos conocer el conjunto de ingress-egress nodes). Este tipo de algoritmos, a diferencia de los anteriores, realiza una fase de preproceso para crear un grafo con pesos donde posteriormente se aplica un SPR. Si en el MIRA se aplica el preproceso de cálculo de máximos flujos y enlaces críticos, hay otras propuestas donde el preproceso usa otro tipo de cálculo. Por ejemplo, en el preproceso se basa en un cálculo de flujos multiactivos. En otros el cálculo de las rutas se realiza usando métodos de programación entera. En la mayoría de estas propuestas el objetivo principal es establecer un camino de trabajo. Si bien algunas contemplan el establecimiento de caminos de respaldo, suele ser un tratamiento secundario. En algunas propuestas (como en MIRA) el establecimiento de rutas de respaldo se reduce al simple hecho de que el algoritmo permite un mejor aprovechamiento de la banda de la red, lo cual permite hacer reencaminamiento en caso de fallo. Otras propuestas como el PBR (obviamente propuestas anteriores como el WSP) no contemplan ningún esquema de protección. La mayoría, como mucho, dejan los esquemas de protección a tener un camino alternativo entre origen y destino para el caso de fallos. Una de las pocas propuestas donde se intenta ofrecer un camino de trabajo y un camino de respaldo con ciertas garantías de calidad de servicio es. En ella el algoritmo de encaminamiento intenta encaminar un camino de trabajo y una ruta de respaldo (global y disjunto al camino de trabajo); en caso de no ser posible, la petición es rechazada. Aunque este primer esquema sólo tiene en consideración el establecimiento de esquemas globales de protección, donde sí se contempla la posibilidad de establecer otros esquemas de protección (en concreto, protección local). En cualquier caso, pocas propuestas tienen en cuenta el hecho de que no sólo disponemos de un esquema de rutas de respaldo (globales) para ofrecer protección a nuestros caminos de trabajo (o segmentos del camino de trabajo), sino que existen otros esquemas: locales, inversos e híbridos de éstos para ofrecer protección. Además, pocos tienen en cuenta las ventajas y desventajas de utilizar uno u otro esquema. La aplicación de uno u otro esquema, como hemos visto en la sección anterior, tendrá asociada unos parámetros de velocidad de recuperación, pérdida de paquetes, consumo de recursos, 113 etc. que hay que tener en consideración. En definitiva, la aplicación de uno u otro esquema permite obtener una cierta QoS en el tráfico y optimizar el rendimiento global de la red. Estas características y cómo y dónde aplicar un esquema u otro de protección son un campo poco explorado en la literatura. En sí se hace mención de las ventajas de aplicar una protección local frente a una global. En se propone el uso de uno o más esquemas en función de las necesidades de protección de nuestra red. Si el planeamiento MFC de la ruta no puede diseñar un nuevo sistema de las redes de LDP para acomodar el tráfico predicho debido a las limitaciones en la topología existente de la red de LSP, se invoca la topología MFC de LSP. La topología MFC de LSP reajusta la red de LSP para resolver los nuevos requisitos. LSPs nuevo se puede crear para coexistir con los actuales y las nuevas redes de LDP que se generen y serán definidas para poder introducir la nueva topología de LSP gradualmente para las nuevas conexiones. Los requisitos de ancho de banda para el LSPs en la topología final de LSP se identifican y se pasan a los MFCS más bajos. Si no es factible diseñar una red de LSP para satisfacer la demanda del tráfico debido a limitaciones en la red física subyacente, por ejemplo el que no haya suficientes acoplamientos, la función del planeamiento de red. El diseño OSF de la ruta debe abastecer de diseñar las redes de LDP según los requisitos de CoS. A partir de la red física y de la definición de tráfico inicial, el módulo de encaminamiento con calidad de servicio configurará una topología de red lógica inicial. Para ello se deben utilizar algoritmos de encaminamiento que establezcan tanto la ruta de trabajo como la de respaldo; de esto se encargará el módulo de encaminamiento. Ambos caminos deben asegurar la calidad de servicio acordada con los usuarios. La obtención de estos caminos no es simple, y se debe establecer un compromiso entre la eficiencia en la utilización de los recursos de red y la velocidad de respuesta a las peticiones de conexión que impliquen la evaluación de nuevas rutas. Las técnicas conocidas que obtienen los mejores resultados son inapropiadas para respuestas dinámicas o bajo demanda (on-line). El establecimiento de ese equilibrio es uno de los objetivos de esta arquitectura en TMN. Básicamente se debe tomar en cuenta tanto los parámetros de calidad de servicio del encaminamiento de caminos de trabajo: maximización de los recursos, optimización del número de peticiones aceptadas y balanceo de la carga, como los de las rutas de respaldo: pérdidas de paquetes, tiempos de respuesta ante fallos y utilización de recursos. 114 La pérdida de paquetes se puede resolver en el uso eficiente del FEC y un reajuste ya que las pérdidas acumuladas de celdas etiquetadas sobre los acoplamientos de la red LSR no excedan, definidos por la CoS, Finalmente la disponibilidad del CoS es garantizada siendo una restricción total de la optimización que el procedimiento interativo pueda definir redes de LSP y LSR que deben satisfacer. 4.2.5.2 Distribución OSF del ancho de banda de LSP La distribución del OSF del ancho de banda de LSP, consta de la misma alternativa de operación para LSP y se describe de forma similar a la VPC, solamente considerando la técnica habitual para adaptar el ancho de banda de los LSP al tráfico real es la reasignación de banda de los mismos, incrementándola o decrementándola según sea el caso. Para poder incrementar la banda de un LSP es necesario que a lo largo del camino que sigue este LSP (los diferentes enlaces físicos que atraviesa) existan los suficientes recursos libres para ser asignados en el OSF. Si esto no sucede, existen dos posibles acciones a tener en cuenta. La primera es buscar en qué enlaces físicos no se cumple la condición de que no exista suficiente banda disponible, y posteriormente, en estos enlaces comprobar si existe algún otro LSP infrautilizado y del que se pueda tomar la banda necesaria. En otras palabras, consiste en traspasar banda de LSP poco usados a un LSP congestionado y que necesita incrementar su banda. La segunda posibilidad, en el caso de que la primera no sea posible, es reencaminar el LSP que necesita mayor ancho de banda a través de otro camino que pueda satisfacer sus necesidades. También en este caso, si no es posible reencaminar al LSP congestionado, también existe la posibilidad de reencaminar uno o varios de los demás LSP con los que comparte los mismos enlaces físicos, con lo cual se liberan recursos y permite incrementar su banda . En los casos en los que hay que reencaminar LSP se puede hacer uso de los algoritmos de encaminamiento dinámicos y con calidad de servicio. De ahí que estos mecanismos de gestión de servicios estén estrechamente relacionados con los mecanismos de establecimiento de LSP de trabajo y de respaldo con calidad de servicio(CoS), creando un entorno global de ingeniería del tráfico. Otro aspecto a tener en cuenta es el de qué mecanismos toman la decisión de adaptar la banda de los LSP y realizar las operaciones anteriormente descritas. Existen diferentes ejemplos en la literatura, y dependiendo de dónde se tome la decisión, se puede hablar de mecanismos centralizados o distribuidos. Estos mecanismos, por las tareas que realizan, se situarían dentro del plano de gestión. Tradicionalmente la gestión, en este caso de 115 servicios y de fallos, se ha realizado de forma centralizada, aplicando algoritmos de optimización que, disponiendo de los datos de monitorización de toda la red, calculan la distribución óptima de los LSP. En redes troncales relativamente grandes por las que circula gran cantidad de LSP es muy difícil disponer de todos los datos de monitorización de forma centralizada y calcular la distribución óptima a tiempo antes de que el estado de la red ya haya cambiado. Una de las opciones que aparecen en la literatura reciente es tratar de mantener la distribución de LSP lo más cercana posible a la óptima haciendo pequeños ajustes usando algoritmos distribuidos. La ventaja principal de los algoritmos distribuidos es que disponen de la información de forma local y permanentemente actualizada. Por el contrario, la desventaja está en que no se dispone de una visión global de la red. Por esta razón algunos algoritmos de este tipo se basan en distintas técnicas de inteligencia artificial y/o en distintas heurísticas para intentar realizar las mejores adaptaciones, aunque no se dispone de una completa información. 4.2.5.3 Carga que balancea OSF La carga que balancea OSF funciona dentro del LDP y la LSP definidas por el diseño de la ruta OSF, similar al escenario 1. 4.2.5.4 Verificación OSF del desempeño Los cocientes del rechazamiento de la conexión por CoS y por pares de destinos de la fuente se recuperan del Modelo Actual de la Carga y se comparan a los destinos del rechazamiento especificado por las quejas de CoS. El cliente se analiza y si se justifica el diseño OSF de la ruta serán puestos en marcha por lo que si CoSs se utiliza para experimentar cocientes del rechazamiento de la conexión en el exceso del destino, una indicación se envía al diseño OSF de la ruta para encausar el número de rutas, o el ancho de banda requerida por las rutas, para ser puesto en operación inmediata. La verificación de OSF cuantifica el funcionamiento del diseño de la ruta, la carga que balancea y la distribución OSFs del ancho de banda de LSP, siendo la medida incuestionable de su eficacia. 4.2.5.5 Modelo Predicho OSF del uso Este modelo su uso es predicho de la red en los términos de los números de conexiones de cada CoS requerido entre los pares del s-d. Los detalles del modelo cómo el número de conexiones cambia: hora por hora sobre el día; día por día sobre la semana; y semana 116 por semana sobre el año que esto es configurada inicialmente por el porcentaje de disponibilidad del TMN pero es modificada por el uso real de la red vía el modelo actual de la carga. Esto es de modo que el modelo predicho llegue a ser más exacto mientras que la experiencia del uso de la red se gana. Siempre que el modelo predicho de la carga indique que el tráfico cambiará perceptiblemente al diseño OSF de la ruta que es proporcionado por la predicción del tráfico en ciertos intervalos de operación. La definición exacta de un cambio significativo es una variable del diseño que se experimentará según el desempeño del sistema en su totalidad. 4.2.5.6. Gestión de Configuración del OSF El encargado de la configuración es responsable de mantener un modelo constante de la configuración física y lógica de la red. Recibirá acciones de la configuración del otro OSFs y será responsable de poner los cambios en ejecución en la red. Esta tarea puede implicar la coordinación de las acciones de la configuración sobre un número de elementos de la red, por ejemplo cuando se crea un LSP. El encargado de la configuración puede proporcionar informes del acontecimiento al otro OSFs siempre que una acción de la configuración haya tenido éxito 4.2.5.7. Modelo Actual OSF de la carga El modelo actual de la carga supervisa el uso de la red y calcula estadísticamente el uso según los requisitos del otro OSFs. El modelo actual de la carga es capaz de calcular el pico, el medio, la estadística, etc. según las especificaciones de los otros componentes. Identificará el número mínimo de las puntas de prueba y de las medidas de la red para resolver las demandas variadas de sus usuarios 4.2.5.8. Encargado OSF del FEC El encargado de FEC reproduce el algoritmo de FEC en la red. Cuando está provisto de una mezcla del tráfico en la forma de una lista del número de conexiones de cada CoS el encargado del FEC vuelve el ancho de banda eficaz de esa mezcla del tráfico. El cálculo tiene exactamente el mismo resultado que el algoritmo equivalente de FEC en la red. 117 4.2.6 Interacciones entre los componentes arquitectónicos 4.2.6.1 Relación del Gestor -Agente La figura 4.7 demuestra las relaciones del Gestor-agente entre los componentes derivadas. La distribución OSF y la carga del ancho de banda de LSP que balancea OSF son agentes del diseño OSF de la ruta. Sin embargo, su operación no es totalmente independiente, puesto que el efecto (en la red) de uno de ellos es considerado por el otro. La distribución OSF del ancho de banda de LSP mira la carga actual del LSPs, que es determinado por las decisiones del encaminamiento, y la carga que balancea OSF y mira la disponibilidad del LSPs que es determinado por la distribución OSF del ancho de banda de LSP. Esto indica que una cierta coordinación necesita existir entre ellas, para evitar contradicciones posibles. El diseño OSF y la distribución OSF de la ruta del ancho de banda de LSP maneja la red de LSP mientras que la carga que balancea OSF se determina cómo optimizar su uso. Se puede discutir que la carga que balancea OSF complementa la distribución OSF del ancho de banda de LSP, en el sentido que se aprovecha el aumento del ancho de banda de LSP. Cuando la carga que balancea OSF se activa se asume una red estable de LSP. Esto implica que durante la operación de la carga que balancea OSF, la distribución OSF del ancho de banda de LSP y el diseño OSF de la ruta se debe prohibir de tomar acciones. E inversamente cuando la distribución OSF o el diseño OSF del ancho de banda de LSP de la ruta cambia o la topología de LSP, la carga que balancea OSF no debe ser activada hasta que se ha realizado el cambio. Cabe mencionar que a lo largo del estudio establecido por el balanceo de carga por OSF, va implícito la participación de las etiquetas de LSR que son establecidas por el conjunto de labor con el componente de control y envío que es establecido como la técnica de MPLS para aprovechar su funcionamiento al doble es decir en vez de existir una doble función que puede tener un VPC por los servicios que trabaja, tanto en el manejo del empaquetamiento su encaminamiento y la relación con el componente de envío, va unido con una sola función de OSF y que será gestionada con los parámetros que intervienen para su aplicación. 118 Modelo CoS Uso de Modelo Gestor FEC Diseño de encaminamiento Verificación Carga Balanceada (1) Diastribución LSP Gestor Configuración Modelo Corriene de Carga OAF MF o NEF A B A es un gestor para B Figura 4.6 Relación del Gestor-agente entre los componentes derivadas 119 Conclusiones - El desarrollo para proponer una metodología de gestión de desempeño para dos escenarios de estudio (ATM y MPLS) aplicando las clases de servicios de internet 2, llego con éxito, basado en el modelo de gestión TMN, que da como propuesta denominada: descomposición de servicios por medio de la recomendación M.3020 de la ITU-T, además que éste modelo propone la identificación de las capas lógicas (LLA), ubicando estas capas con sus elementos y componentes de función. - La planeación estratégica tuvo lugar al conocer el funcionamiento operacional real de la red de telecomunicaciones además de la conmutación y el encaminamiento que opera ATM, con el servicio adicional del encaminamiento de IP por lo que se concluyó: la forma de trabajo es bidireccional en el enrutamiento de IP/ATM, conforme se demostró en el plano de gestión al mapeo de OSF y los elementos de funciones por medio de la metodología de descomposición de servicios. - La migración de IP/ATM a MPLS se llevo a cabo conforme a la metodología estudiada (ITU-T M.3020), la cual define un envío que es unidireccional, y que las funciones de control y envío son integradas por medio de una etiqueta, por lo que las operaciones de enlaces de IP serán por etiquetas, donde los paquetes de información se envían solo una vez, asegurando su destino. La aplicación de la descomposición de servicios, da como resultado que la gestión de red invoca la gestión de desempeño, se justifica la utilidad de la etiqueta con la cual es gestionada la red y la carga podrá ser balanceada adecuadamente por medio de este elemento operacional. - En la actualidad el desarrollo de nuevas alternativas de gestión de desempeño para grandes redes y los servicios proporcionados por éstas, se encuentran en una fase temprana de desarrollo para México como en el resto del mundo, por lo que la metodología propuesta sobre el modelo TMN nos da garantías de ser el camino más valido de gestionar una red, es por ello que siendo éste modelo y la metodología de descomposición de funciones, es considerar nuevos criterios y políticas para identificar las problemáticas de desempeño que puede tener una red internet sobre las clases de servicio de operación, lo que definimos de cómo implementar la Gestión de Red sobre soluciones reales y seguras. 120 Glosario de términos y Acrónimos A continuación se describen algunos conceptos básicos que se aplican a cualquier tecnología de conmutación, antes de proceder a describir el funcionamiento de MPLS: Enrutamiento.- Es un término utilizado para describir las acciones tomadas por una red para mover paquetes a través de ella (entre redes y subredes). El viaje de los paquetes se lleva a cabo a través de la red de máquina en máquina hasta llegar a su destino. Los protocolos de enrutamiento (ej: RIP, OSPF) permiten que cada maquina conozca cual máquina es el salto siguiente (next hop) para que el paquete llegue a su destino. Los enrutadores utilizan los protocolos de enrutamiento para construir tablas de envío. Conmutación (switching).- Es generalmente utilizado para describir la transferencia de datos de un puerto de entrada a un puerto de salida donde la selección del puerto de salida esta basado en información de la capa 2 (ej: VPI/VCI en ATM). Componente de control.- Construye y mantiene la tabla de envío para el nodo a utilizar. Trabaja junto con los componentes de control de otros nodos para distribuir información de enrutamiento de forma consistente, también asegura que se utilicen los procedimientos locales adecuados para la creación de la tabla de envío. Componente de envío (forwarding component) .- Lleva al cabo el envío del paquete basándose en información de la tabla de envío (mantenida por el enrutador). Tabla de envío.- Es un conjunto de campos en una tabla, los cuales proporcionan la información que ayuda al componente de envío a realizar su función de conmutación. La tabla de envío debe asociar cada paquete con un campo (tradicionalmente la dirección destino). Etiqueta.- Es un identificador corto de longitud fija de significado local el cual es utilizado para identificar un FEC. La etiqueta que se coloca en un paquete particular representa el FEC al cual el paquete es asignado. Conmutación de Etiqueta (Label Switching).- Es una forma avanzada de envío de paquetes la cual reemplaza el algoritmo de envío convencional por un algoritmo mas eficiente de intercambio de etiqueta. LSR (Label Switched Router): Es un enrutador de alta velocidad en el corazón de la red MPLS, el cual debe soportar los protocolos de enrutamiento IP y participa en el establecimiento de los LSP (Label Switched Paths) utilizando el protocolo de señalización de etiquetas adecuado. Permite conmutación de tráfico de datos a alta velocidad basado en los caminos establecidos, típicamente es un conmutador ATM modificado. 121 LER (Label Edge Router): Es un dispositivo que opera en la periferia de la red de acceso y la red MPLS, el cual se encarga de insertar las etiquetas en base a información de enrutamiento. Un LER soporta múltiples puertos conectados a redes distintas (como pueden ser ATM, Frame Relay y Ethernet) y envía este tráfico a través de la red MPLS después de haber establecido un LSP (camino) utilizando un protocolo de distribución de etiquetas. También se encarga de retirar las etiquetas y distribuir el tráfico a las redes de salida. FEC (Forward Equivalent Class): Es una representación de un grupo de paquetes que comparten los mismos requerimientos para su transporte. Todos los paquetes en un grupo determinado reciben el mismo trato, y siguen una misma ruta hacia su destino. En oposición al envío convencional por IP, en MPLS la asignación de un FEC particular a un paquete en particular se hace solo una vez, cuando el paquete entra a la red. Los FEC se basan en requerimientos de servicio para un conjunto dado de paquetes o simplemente para un prefijo de dirección. Cada LSR construye una tabla la cual especifica como será enviado cada paquete; a esta tabla se la llama LIB (Label Information Base). Acrónimos ABR ACSE ACTS AI AIP ANSA ANSI API APPS ASN.1 ATM BER B-ISDN BML CAF CBR CMIP Available Bit Rate (Tasa de Bits (Velocidad) Disponible) Association Control Service Element (Elemento de Servicio de Control de Asociación) Advanced Communication Technologies and Services (Tecnologías y Servicios de Comunicación Avanzada) Artificial Intelligence (Inteligencia Artificial) Advanced Information Processing (Procesamiento Avanzado de la Información) Advanced Networked Systems Architecture (Arquitectura de Sistemas de Red Avanzados) American National Standards Institute (Instituto Nacional de Normativas Americanas) Application Programming Interface (interfaz de Programación de Aplicación) ATM Path Provisioning Service (Servicio de Aprovisionamiento de Trayectoria ATM) Abstract Syntax Notation One (Notación de Sintaxis Abstracta Uno) Asynchronous Transfer Mode (Modo de Transferencia Asíncrono) Basic Encoding Rules (Reglas Básicas de Codificación); Block Error Ratio (Tasa de Error de Bloque) Broadband Integrated Services Digital Network (Red Digital de Servicios Integrados de Banda Ancha) Business Management Layer ( Capa de Gestión de Negocios de TMN) Call Acceptance Function (Función de Aceptación de Llamada) Constant Bit Rate (Tasa de Bits (Velocidad) Constante) Common Management Information Protocol (Protocolo de Información de Gestión Común) 122 CMIS Common Management Information Service (Servicio de Información de Gestión Común) CMISE Common Management Information Service Element (Elemento de Servicio de Información de Gestión Común) CMOL CMIP Over LLC (CMIP sobre LLC) CMOT CMIP Over TCP (CMIP sobre TCP) CPN Customer Premises Network (Red con Premisas de Cliente) CORBA Common Object Request Broker Architecture (Arquitectura Común de Intermediario de Solicitud de Objeto) CTP Connection Termination Point (Punto Terminal de Conexión) DCE Distributed Computing Environment (Ambito de Cómputo Distribuido) DCN Data Communications Network (Red de Comunicación de Datos) DCF Data Communications Function (Función de Comunicación de Datos) DME Distributed Management Environment (Ambito de Gestión Distribuida) DN Distinguished Name (Nombre de Distinción; igual a FDN) EML Element Management Layer (Capa de Gestión de Elemento de Red; igual a NEML) ETSI European Telecommunications Standard Institute (Instituto Europeo de Normatividad de las Telecomunicaciones) EURESCOM European Institute for Research and Strategic Studies in Telecommunications (Instituto europeo para la Investigación y Estudios Estratégicos en Telecomunicaciones) FCAPS Fault, Configuration, Accounting, Performance and Security Management Areas (Areas de Gestión de Fallos, Configuración, Contabilidad, Comportamiento y Seguridad) FDN Full Distinguished Name (Nombre de Distinción Completo; igual a DN) GBC Global Broadband Connectivity (Conectividad Global de Banda Ancha) GBCM Global Broadband Connectivity Management (Gestión de Conectividad de Banda Ancha Global) GDMO Guidelines for the Definition of Managed Objects (Directrices para la Definición de Objetos Gestionados) GUI Graphical User Interfaz (Interfaz Gráfica de Usuario) HCI Human – Computer Interaction (Interacción Humano – Computador) IBC Integrated Broadband Communications (Comunicaciones Integradas de Banda Ancha) ICM Integrated Communications Management (Gestión de Comunicaciones Integradas) IDL Interface Definition Language (Lenguaje de Definición de Interfaz) IETF Internet Engineering Task Force (Fuerza de Tareas de Ingeniería de Internet) IIMC ISO/ITU-T Internet Management Coexistence (Coexistencia de Gestión ISO/ITU-T Internet) IN Intelligent Network (Red Inteligente) IP Internet Protocol (Protocolo Internet) ISDN Integrated Services Digital Network (Red Digital de Servicios Integrados) IS&N Intelligence in Services and Networks (Inteligencia en Servicios y Redes) ISO International Standard Organisation (Organización Internacional de Normatividad) ITU-T International Telecommunications Union (Unión Internacional de las Telecomunicaciones) LAN Local Area Network (Red de Area Local) 123 LDN LDP LLA LLC LSP LSR MA MAF MD MF MFS MIB MIM MISA MIT MPLS MO MOC MOCS MS NE NEL NEML NNI NM NML NMF NMS N-OS OAM&P ODL ODP OID OMG OMNIPoint OMT ONP OO ORB OS OSF OSF OSI PDU Local Distinguished Name (Nombre de Distinción Local; igual a RDN) Label distribution protocol (Protocolo de distribución de etiquetas) Logical Layered Architecture (Arquitectura Lógica por Capas) Logical Link Control (Control de Enlace Lógico) Label switched path (Dirección de etiqueta conmutada) Label Switched router (Enrutador de etiquetas conmutadas) Management Application (Aplicación de Gestión) Management Application Function (Función de Aplicación de Gestión) Mediation Device (Dispositivo de Mediación) Mediation Function (Función de Mediación) Management Function Set (Conjunto de Funciones de Gestión) Management Information Base (Base de Información de Gestión) Management Information Model (Modelo de Información de Gestión) Management of Integrated SDH and ATM networks (Gestión de redes Integradas SDH y ATM) Management Information Tree (Arbol de Información de Gestión) Multiprotocol Label Switching ( Multiprotocolo de conmutación de etiquetas) Managed Object (Objeto Gestionado) Managed Object Class (Clase de Objeto Gestionado) Managed Object Conformance Statement (Declaración de Conformidad de Objeto Gestionado) Management Service (Servicio de Gestión) Network Element (Elemento de Red) Network Element Layer (Capa de Elemento de Red) Network Element Management Layer (Capa de Gestión de Elemento de Red; igual a EML) Network – Network Interface (Interfaz entre Sistemas de Operaciones de la Capa de Gestión de Red) Network Management (Gestión de Red) Network Management Layer (Capa de Gestión de Red) Network Management Forum (Foro de Gestión de Red; hoy TMF) Network Management System (Sistema de Gestión de Red) Network Management Level OS (OS de Capa de Gestión de Red) nrt-VBR Non-real-time VBR (VBR no en tiempo real) Operation, Administration, Maintenance and Provisioning (Operación, Administración, Mantenimiento y Aprovisionamiento) Object Definition Language (Lenguaje de Definición de Objeto) Object Distributed Processing (Procesado Distribuido de Objetos) Object Identifier (Identificador de Objeto) Object Management Group (Grupo de Gestión por Objeto) Open Management Interoperability Point (Punto de Interoperabilidad de Gestión Abierta) Object Modelling Technique (Técnica de Modelado por Objeto) Open Network Provisioning (Aprovisionamiento Abierto de Red) Object Orientation (Orientación a Objetos) Object Request Broker (Mediador de Solicitud de Objeto) Operations System (Sistema de Operaciones) Operations System Function (Función de Sistema de Operaciones) Open Software Foundation (Fundación de Software Abierto) Open Systems Interconnection (Interconexión de Sistemas Abiertos) Protocol Data Unit (Unidad de Datos de Protocolo) 124 PN PNO PPS PVC Qatm Public Network (Red Pública) Public Network Operator (Operador de Red Pública) Path Provisioning Service (Servicio de Aprovisionamiento de Trayectoria) Permanent Virtual Circuit (Circuito Virtual Permanente) Q3 Interface for management of ATM networks (Interfaz Q3 para la gestión de redes ATM) QA Q Adapter (Adaptador Q) QAF Q Adapter Function (Función de Adaptador Q) QoS Quality of Service (Calidad de Servicio) Qsdh Q3 Interface for management of SDH networks (Interfaz Q3 para la gestión de redes SDH) RACE Research in Advanced Communications for Europe (Investigación en Comunicaciones Avanzadas para Europa) RDN Relative Distinguished Name (Nombre de Distinción Relativo; igual a LDN) RFC Request For Comments (Solicitud de Comentarios de IETF) RMIB Remote MIB (MIB Remota) ROSE Remote Operations Service Element (Elemento de Servicio de Operaciones Remotas) RPC Remote Procedure Call (Llamado a Procedimiento Remoto) rt-VBR Real-time VBR (VBR en tiempo real) SAP Service Access Point (Punto de Acceso a Servicio) SDH Synchronous Digital Hierarchy (Jerarquía Digital Síncrona) SM Service Management (Gestión de Servicio) SMASE Service Management Application Service Element (Elemento de Servicio de Aplicación de Gestión de Sistemas) SMI Structure of Management Information (Estructura de la Información de Gestión) SML Service Management Layer (Capa de Gestión de Servicio) SNMP Simple Network Management Protocol (Protocolo Sencillo de Gestión de Red) S-OS Service Management Level OS (OS de Capa de Gestión de Servicio) SPPS SDH Path Provisioning Service (Servicio de Aprovisionamiento de Trayectoria SDH) TCP Transmission Control Protocol (Protocolo de Control de Transmisión) TINA Telecommunications Information Network Architecture (Arquitectura de Red de Información de las Telecomunicaciones) TMN Telecommunications Management Network (red de Gestión de las Telecomunicaciones) TP Termination Point (Punto Terminal) UBR Unspecified Bit Rate (Tasa de Bits (Velocidad) no Especificada) UML Unified Modeling Language (Lenguaje Unificado para Modelado) UNI User-Network Interface (Interfaz Usuario - Red) VASP Value Added Service Provider (Proveedor de Servicio de Valor Añadido) VBR Variable Bit Rate (Tasa de Bits (Velocidad) Variable) VCC Virtual Channel Connection (Conexión de Canal Virtual) VCI Virtual Channel Identifier (Identificador de Canal Virtual) VP Virtual Path (Trayectoria Virtual) VPC Virtual Path Connection (Conexión de Trayectoria Virtual) VPN Virtual Private Network (Red Privada Virtual) WS Workstation (Estación de Trabajo) WSF Workstation Function (Función de Estación de Trabajo) 125 WWW World Wide Web (Web Mundial de Internet) Xcoop Interfaz X entre dos dominios en el sistema MISA o EURESCOM XC-FM Xcoop - Fault Management (Gestión de Fallos de Xcoop) XC-CM-PPS Xcoop - Configuration Management - Path Provisioning Service (Gestión de Configuración de Xcoop – Servicio de Aprovisionamiento de Trayectoria) XC-IM Xcoop - Information Model (Modelo de Información de Xcoop) XMP X/Open Management Protocols (Protocolos de Gestión X/Open) XOM X/Open OSI-Abstract-Data Manipulation (Manejo de Datos Abstractos OSI en X/Open) Xuser Interfaz X entre un VASP y el OS del sistema MISA o EURESCOM XUSR-FM Xuser - Fault Management (Gestión de Fallos de Xuser) XUSR-CM-PPS Xuser - Configuration Management - Path Provisioning Service (Gestión de Configuración de Xuser – Servicio de Aprovisionamiento de Trayectoria) XUSR-IM Xuser - Information Model (Modelo de Información de Xuser) 126 Bibliografía [Aida94] S. Aidarous, T. Plevyak, “Telecommunications Network Management into the 21st Century: Techniques, Standards, Technologies and Applications”. IEEE Press. 1994 [Alfang2000] A.Angeles, “ Estudio de procedimientos de integración de sistemas de gestión de red mediante tecnologías orientadas a objetos”. Departamento de Teoría de señales y comunicaciones Universidad Politécnica de Cataluña 2000. [Bern93] L. Bernstein, C. Yuhas. “Managing Telecommunications Networks”. IEEE Network. November 1993 [Bjer94] L. H. Bjerring, M. Tschichholz: “Requirementes of Inter-Domain Management and their Implications for TMN Architecture”. Proceedings of the 2nd International Conference on Intelligence in Services and Networks (IS&N´94), pp. 193-206. Springer. 1994 [Bjer98] L. H. Bjerring, et al: “Experiences in Developing Multi-technology TMN Systems”. Proceedings of the NOMS´98 Conference, pp. 445-454. 1998 [Cohen94] R. Cohen. “The Telecommunications Management Network”, en [Slom94], pp 217-243. Addison-Wesley. 1994 [Calle99] E. Calle, P Vilà, J L Marzo, S Cots “Arquitectura del Sistema de Gestión del ancho de Banda y Protección (SGBP) para entornos de redes MPLS”. Instituto de Informática y Aplicaciones, Universitat de Girona [Sahi94] V. Sahin. “Telecommunications Management Network: Principles, Models and Applications”, in [Aida94], Chap. 3, pp. 72-121. IEEE Press. 1994 [Grif95] D. Griffin, P. Georgatsos. “A TMN System for VPC and Routing Management in ATM Networks”. Integrated Network Management IV, pp. 356-369. Chapman & Hall. 1995 [Jimz2000] L.Jiménez,” MPLS. Una nueva tecnología aplicada a Internet” 2 pp 4-5, UABC Ensenada 2000 [Lewis95] D. Lewis, S. O´Connell, W. Donnelly, L. Bjerring. “Experiences in MultiDomain Management System Development”. Integrated Network Management IV, pp. 494 - 505. Chapman & Hall. 1995 [Lewis97] D. Lewis, et al. “Inter-Domain Integration of Services and Service Management”. IS&N´97 Conference, Como Italy. 1997 [Rosen2000] E. C. Rosen,; A. Viswanathan ; R. Callon “Arquitectura de MPLS”, draftietf-mpls-arch-07.txt, , Julio del 2000. 127 [Pulley2000] R. Pulley “A Comparison of MPLS Traffic Enginering Initiatives”, , Netplanet, documento técnico, 1999-2000. [Villa94] Villagrá G., Víctor A. Contribución al Diseño de Arquitecturas de Gestión de Redes Privadas Virtuales Conformes a la Normativa TMN. Tesis Doctoral. Escuela Técnica de Ingenieros de Telecomunicación. Madrid. 1994. Normativas y Especificaciones ITU-T | ISO/IEC (http://itu.int/itudoc/itu-t/rec) [M3010] ITU-T Recommendation M.3010: Principles for a Telecommunications Management Network. 1996 [M3020] ITU-T Recommendation Methodology. 1995 [M3400] ITU-T Recommendation M.3400: TMN Management Functions. 1992 [X700] ITU-T Recommendation X.700: Management Framework for Open System Interconnection (OSI) for CCITT Applications. 1992 [X722] ITU-T Recommendation X.722 | ISO/IEC 10165-4: Information Technology – Open System Interconnection – Structure of Management Information: Gudelines for the Definition of Managed Objects. 1992 [Q811] ITU-T Recommendation Q.811: Low Layer Protocol Profiles for the Q3 Interface. 1993 [Q812] ITU-T Recommendation Q.812: Upper Layer Protocol Profiles for the Q3 Interface. 1993 [Q821] ITU-T Recommendation Q.821: Stage 2 and Stage 3 Description for the Q3 Interface – Alarm Surveillance. 1993 M.3020: TMN Interface Specification EURESCOM. (http://www.eurescom.de/public/deliverables) [P414D3] P414-TMN Guidelines: Deliverable 3: TMN Guidelines. 1996 [P609D4] P609-TMN Specification Support: Deliverable 4: TMN Guidelines 97. 1997 128 Documentos y Manuales Técnicos [1] IP over ATM”, Alcatel, International Engineering Consortium, Tutorial, Septiembre de 1999 MPLS: Análisis de la tecnología MPLS”, Trillum, documento técnico, Septiembre del 2000. ATM Fundamentals”, Nortel Networks, documento técnico, Septiembre de 1999. “Guía de ATM”, Cabletron Systems, Febrero de 1997. Los documentos de la IETF relacionados con el grupo de trabajo de MPLS, se encuentran en la página de Internet de dicho grupo, la cual es la siguiente: http://www.ietf.org/html.charters/mpls-charter.html. A continuación, se muestran algunos sitios de Internet utilizados: http://www.cudi.edu.mx/. Consorcio Universitario para el Desarrollo de Internet en México. http://www.cisco.com/univercd/cc/td/doc/product/wanbu/9_3/mpls/mpls01.htm . Análisis de la tecnología MPLS, y consideraciones para migrar a MPLS en una red ATM. http://www.protocols.com/pbook/mpls.htm . Descripción de MPLS y sus mecanismos de señalización. http://www.juniper.net/techcenter/techpapers/200001.pdf. Documento técnico sobre MPLS. http://www.internet2.edu/. Información sobre Internet 2 129