Configuración de Redes Privadas Virtuales bajo el concepto de Redes Programables mediante Java y Corba Edición Única

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY PROGRAMA DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. CONFIGURACIÓN DE REDES PRIVADAS VIRTUALES BAJO EL CONCEPTO DE REDES PROGRAMABLES MEDIANTE JAVA Y CORBA TESIS PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADÉMICO DE: MAESTRO EN CIENCIAS EN TECNOLOGÍA INFORMÁTICA POR: RAMÓN ALEJANDRO PERAZA SÁNCHEZ MONTERREY, N. L.. DICIEMBRE 2003.

(2) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY DIVISIÓN DE ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES PROGRAMAS DE GRADUADOS EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. Los miembros del comité de tesis recomendamos que la presente tesis del Ing. Ramón Alejandro Peraza Sánchez sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias en Tecnología Informática.. Comité de tesis:. ______________________________ José Raúl Pérez Cázares, PhD. Asesor ______________________________ Raúl Valente Ramírez Velarde, MC. Sinodal ______________________________ Mario Alberto Montoya Martínez, MC. Sinodal. ______________________________ David Alejandro Garza Salazar, PhD. Director del Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Diciembre 2003.

(3) CONFIGURACIÓN DE REDES PRIVADAS VIRTUALES BAJO EL CONCEPTO DE REDES PROGRAMABLES MEDIANTE JAVA Y CORBA. TESIS POR: RAMÓN ALEJANDRO PERAZA SÁNCHEZ Presentada al Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Este trabajo es requisito parcial para obtener el grado de Maestro en Ciencias en Tecnología Informática. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY Diciembre 2003.

(4) Dedicatoria. A Dios Por los caminos que me ha trazado en la vida, por esa fuerza interior que Él me provee y me impulsa a ir siempre hacia adelante para cumplir mis objetivos.. A mis padres y mis hermanas Por ser siempre partícipes de mis esfuerzos, porque con ellos comparto mis logros y sobre todo por ese apoyo incondicional que siempre me han mostrado.. i.

(5) Agradecimientos. Agradezco a mi asesor Dr. Raúl Pérez por sus conocimientos transmitidos tanto en las aulas de clase como en su guía durante el desarrollo de esta tesis.. A mis sinodales Ing. Raúl Ramírez, por sus acertados consejos y comentarios para desarrollar un mejor trabajo de investigación. Lic. Mario Montoya, por su compañerismo durante los estudios de la maestría y durante el desarrollo de esta tesis, pero sobre todo por su amistad.. A mis amigos A los amigos de siempre y a los amigos que conocí durante los estudios de maestría tanto dentro como fuera de las aulas. A todos aquellos que compartieron conmigo este esfuerzo les agradezco su apoyo y amistad en todo momento.. ii.

(6) Abstract. La presente tesis propone un modelo alterno de la arquitectura para redes programables. En particular, este modelo es aplicado a la construcción de redes privadas virtuales. Este trabajo de investigación se desarrolla en base al modelo de redes programables propuesto por la IEEE así como la documentación de los dispositivos enrutadores Cisco. Para lograr el objetivo de esta investigación se hizo un análisis del concepto arquitecturas de redes programables basado en artículos relacionados con este tema, así como marco de referencia P1520. Enseguida se procedió a analizar las áreas en las que el paradigma de redes programables es aplicable y las ventajas que en ellas proporciona. Se definió como área específica de estudio las redes privadas virtuales para delimitar un campo de aplicación de un modelo alterno propuesto en esta tesis. Es por ello que se parte del desarrollo de esta investigación se orientó a la explicación de las redes privadas virtuales, la importancia de esta tecnología, su funcionalidad, los tipos que existen, así como un ejemplo práctico de la construcción de este tipo de redes. Por otra parte se realizó una investigación de las herramientas tecnológicas necesarias que dan funcionalidad a las redes programables y conforma su infraestructura. En esta parte fue necesario enfocarse en el tema de Corba como herramienta orientada a objetos para dar soporte a aplicaciones distribuidas. Se analizó la arquitectura Corba, sus elementos y sus mejores prácticas. Teniendo como marco teórico los conceptos mencionados anteriormente se procedió a plantear un modelo alterno al marco de referencia propuesto por el proyecto 1520 de la IEEE para interfases de redes programables. El objetivo de este modelo consiste en tener la capacidad de desarrollar interfases para redes programables a pesar de la ausencia de una completa estandarización de las facilidades proporcionadas por los dispositivos de red. Una vez especificado este modelo se desarrolló una interfaz programable con fines de simulación para la construcción de una red privada virtual en un ambiente de intranet. Finalmente se plantearon las conclusiones de esta investigación y se sugirieron los trabajos futuros para continuar y mejorar el modelo propuesto y sus áreas de aplicación. En todo momento se buscó abordar los temas necesarios para la explicación y comprensión de los objetivos perseguidos en esta tesis. iii.

(7) Índice de contenido. Dedicatoria. I. Agradecimientos. Ii. Abstract. iii. Índice de contenido. iv. Índice de figuras Capítulo 1 – Introducción 1.1 Introducción 1.2 Objetivo 1.3 Definición del problema 1.4 Motivación 1.5 Organización de la tesis. Vii 1 2 3 3 4. Capítulo 2 – Redes Programables 2.1 Introducción 2.2 Redes programables 2.3 Dos arquitecturas programables 2.4 El OPENSIG y el IEEE P1520 2.5 Infraestructura y beneficios de las interfases programables 2.6 Interfases Programables y enrutadores IP 2.7 Una futura estandarización. 5 6 7 7 10 11 12. Capítulo 3 – Middleware y Corba 3.1 Introducción 3.2 Middleware 3.2.1 Ventajas 3.2.2 Campos de Aplicación 3.3 Definición de Corba 3.3.1 Independencia de la plataforma 3.3.2 Independencia de Lenguaje 3.4 La arquitectura OO y Corba 3.5 El Open Management Group 3.6 La Open Management Arquitecture 3.7 Componentes de Corba. 14 14 16 16 17 18 18 19 19 20 20. iv.

(8) Capítulo 4 – Redes Privadas Virtuales 4.1 Introducción a las RPV 4.2 Definición de RPV 4.3 La economía de las RPVs 4.4 Implementaciones de RPV 4.5 Actividades que participan en servicios de RPV 4.6 Protocolos para RPV 4.6.1 IPsec – IPSecurity 4.6.2 PPTP - Protocolo de túnel punto a punto 4.6.3 L2TP – Protocolo de túneles de capa 2 4.7 Tipos de RPV 4.7.1 RPV de capa de red 4.7.1.1 Controlled route leaking 4.7.1.2 Túneles 4.7.2 RPV de capa de enlace 4.7.2.1 Conexiones Virtuales ATM y Frame Relay 4.7.2.2 MPOA 4.7.2.3 MPLS 4.7.3 Encripción de capa de enlace 4.7.4 RPV de capa de transporte y aplicación 4.8 Productos RPV. 25 25 27 29 30 31 31 32 33 34 35 35 35 36 36 36 37 37 38 38. Capítulo 5 – Configuración de una RPV 5.1 Introducción 5.2 Configuración de una RPV sencilla. 41 41. Capítulo 6 – Modelo Propuesto 6.1 Introducción 6.2 Arquitectura del modelo. 46 46. Capítulo 7 – La implementación 7.1 Introducción 7.2 Escenario 7.3 IDLs 7.4 Las Clases 7.4.1 Cliente 7.4.2 Servidor de RPV 7.4.3 Envío de comandos al enrutador 7.4.4 Servidor de registro en la base de datos 7.4.5 Conectividad a la base de datos 7.5 La base de datos 7.6 Recursos Técnicos. 49 49 51 52 54 58 60 60 62 65 66. Capítulo 8 – Conclusiones 8.1 Introducción 8.2 Resultados. 67 67. v.

(9) 8.3 Aportaciones. 67. Capítulo 9 – Trabajos relacionados 9.1 Introducción 9.2 Recomendaciones. 69 69. Referencias. 70. Anexo A – Configuración de enrutadores. 73. Anexo B – Código fuente. 77. Vita. 97. vi.

(10) Índice de figuras. 2.1 Modelo de referencia P1520. 8. 3.1 Arquitectura OMA 3.2 Desarrollo de aplicaciones con Corba 3.3 Paso de una petición de un cliente a una implementación de objetos 3.4 Estructura de Corba. 20 21 21. 4.1 Representación de una Red Privada Virtual 4.2 Roles involucrados en servicios de RPV 4.3 Modelo del protocolo TCP/IP. 26 30 34. 5.1 Configuración de una RPV. 42. 6.1 Modelo para redes programables. 47. 7.1 Caso de uso para la solicitud de una RPV 7.2 Diagrama de implementación de la red programable para servicios RPV 5.3 Diagrama de configuración de la red 5.4 Diagrama de clases 5.5 Interfaz para Servicios RPV en Demanda. 49 50. 22. 51 53 54. vii.

(11) Capítulo 1 Introducción. 1.1 Introducción Actualmente la administración de servicios de redes es un tanto inflexible debido a que cada día los requerimientos de servicios son más personalizados y complejos. La creación y administración de servicios de red es manual y con un alto costo en tiempo y en proceso. La habilidad de rápidamente crear y ofrecer nuevos y novedosos servicios de telecomunicaciones en respuesta a las demandas de los usuarios será un factor clave para determinar el éxito de los proveedores de servicios [Campbell, 1998]. La competitividad dependerá de la sofisticación y flexibilidad de los servicios que los proveedores puedan ofrecer. La separación del hardware de comunicaciones (por ejemplo, conmutadores, enrutadores, etc.) del software de control es fundamental para hacer la red más programable [Denazis, 2001]. Sin embargo esta separación es aún difícil de realizar hoy en día. Como solución a lo anterior ha surgido el concepto de Arquitecturas de Redes Programables, cuyo objetivo es simplificar la implementación de nuevos servicios de red, evitando de esta manera las configuraciones manuales, costo de tiempo y costo de procesos. Este concepto [Bjorkman, 2001] está basado en la intención de agregar capacidad computacional a los elementos de red. Esto está siendo posible gracias a las bondades de los lenguajes de programación orientados a objetos, así como a la programación distribuida y las capacidades de los sistemas operativos actuales. Existe un acuerdo general de que las arquitecturas de redes programables pueden ser personalizadas utilizando interfases programables abiertas claramente definidas. En base a esto, será posible proporcionar servicios de red en demanda según las necesidades del usuario. ¿De qué servicios estamos hablando?, estos se refieren a la configuración de dispositivos de red como conmutadores y enrutadores para proporcionar servicios que van desde configuración de listas de control de acceso, VLANs, calidad de servicio, ancho de banda, etcétera, hasta redes privadas virtuales, e incluso nuevos servicios de red que pudieran surgir posteriormente. De los servicios ya mencionados, el de las Redes Privadas Virtuales (VPN, por sus siglas en inglés) es de importancia para esta investigación, ya que se trata de 1.

(12) un servicio que cada vez está tomando más auge, y al igual que cualquier otro servicio de red, la configuración es complicada. Básicamente una RPV ofrece un medio de compartir una red de comunicaciones pública de una manera privada con el objeto de disminuir costos y ofrecer una comunicación más eficiente y segura. Una aparente limitante a la programabilidad de las redes es la heterogeneidad de los elementos involucrados en una red (dispositivos, sistemas operativos, etc.). Es aquí donde intervienen las tecnologías middleware y distribuidas. Los middleware permiten un rápido desarrollo de productos y aseguran la compatibilidad de los mismos, independientemente de las plataformas e incluso, lenguajes de programación. Al mismo tiempo, maneja y soporta los diferentes componentes de un sistema distribuido, el cual, es una colección de elementos de cómputo autónomo que se encuentran físicamente separados y no comparten una memoria común, sino que se comunican entre sí mediante el intercambio de mensajes utilizando un medio de comunicación. Más adelante se hablará de CORBA como herramienta para el desarrollo de aplicaciones distribuidas, y por supuesto, arquitecturas programables. De lograr hacer más flexible la administración de servicios de redes, se podrán ofrecer servicios de una manera rápida, confiable y de bajo costo. En este trabajo de investigación se pretende crear una interfaz abierta de redes programables basada en objetos, que facilite la administración de servicios de RPV en redes IP. Más adelante se explica con mayor detalle este tema de tesis y los conceptos involucrados en él.. 1.2 Objetivo El objetivo de este trabajo de tesis es proponer una interfaz que permita configurar una Red Privada Virtual en una Intranet de manera distribuida bajo el concepto de Redes Programables, usando Java como lenguaje de programación y Corba como middleware. A partir de lo anterior, se pretende contribuir al diseño de interfaces que permitan hacer programables los servicios de red en redes TCP/IP, de modo que estos servicios puedan ser administrados y personalizados de una manera más fácil y flexible.. 2.

(13) 1.3 Definición del problema En el primer punto se ha hablado de la búsqueda de una mayor flexibilidad en la administración de servicios de red. Y hemos mencionado también que existen tendencias de la tecnología para lograr este objetivo. En este trabajo de investigación se presenta una propuesta para analizar la factibilidad de la aplicación del concepto de arquitecturas programables, en la configuración de Redes Privadas Virtuales sobre redes IP, usando tecnologías como Corba, y Java. Lo que se propone es mostrar que es posible configurar una RPV en el ambiente antes mencionado, teniendo como hipótesis la idea de que es posible usar modelos de redes programables, para proporcionar flexibilidad en la administración de servicios en cualquier tipo de redes. Para esto se creará una interfase middleware, utilizando las bondades que Corba ofrece, que permitirá manipular los objetos relacionados con la configuración de una Red Privada Virtual. De este modo se tendrá la capacidad de configurar RPVs de una manera más rápida y flexible. Es un hecho que las necesidades de nuevos servicios – como servicios móviles generalizados, conferencias multimedia, redes privadas virtuales, etc – no tiene fin. La demanda de servicios de RPVs ofrece a los proveedores un gran mercado. El concepto de redes programables para proporcionar este servicio daría un valor agregado muy importante tanto para los clientes como para los proveedores.. 1.4 Motivación La motivación de este trabajo de investigación es aportar una propuesta de soluciones o mejoras a las implementaciones de los servicios de redes IP. Aunque el paradigma de arquitecturas programables no es nuevo, es un concepto que debe explotarse más para obtener beneficios aplicables a un sinnúmero de áreas. En este caso en particular, se aplicará este enfoque para la configuración de RPVs, con la propuesta de poder ser aplicado para muchos otros servicios, ofreciendo, flexibilidad, seguridad y bajos costos.. 3.

(14) 1.5 Organización de la tesis En el capítulo 2, se introducen conceptos acerca de las arquitecturas de redes programables, se hablará de la necesidad y el surgimiento de estas arquitecturas. En este apartado se explican también los dos modelos de arquitectura que existen, y veremos en cuál de ellas se basará esta investigación. Por otra parte, se hablará de la infraestructura necesaria para la creación de interfases programables. En el capítulo 3, se hablará de las tecnologías Middleware, su importancia, ventajas y aplicaciones. En este mismo capítulo nos centraremos principalmente en las características ofrecidas por CORBA. Se hablará de este modelo, su independencia de plataforma y lenguaje, así como de sus componentes. El capítulo 4 habla acerca de las Redes Privadas Virtuales, de sus ventajas, de cómo funcionan, de los diversos tipos de RPVs que hay, así como los protocolos y productos existentes para construir este tipo de redes. Continuando con el tema del capitulo 4, en el capítulo 5 se describe paso a paso un ejemplo de configuración de una Red Privada Virtual entre dos dispositivos enrutadores. En el capítulo 6 se plantea el modelo propuesto en este trabajo de investigación para una interfaz de arquitectura de red programable y se describirán los elementos que lo componen. En el capítulo 7, se presentará un escenario operacional y se explicará el desarrollo e implementación de la interfaz programable para configuración de RPVs en una Intranet. Es en esta parte donde se describe el IDL y el código propuestos para respaldar el objetivo de esta tesis. En el capítulo 8 se observarán las conclusiones de este trabajo de investigación y posteriormente se propondrán algunas recomendaciones de trabajos futuros en el capítulo 9. Finalmente se encontrará un apartado de anexos donde podrán ser consultadas las configuraciones de los dispositivos utilizados así como los listados completos del código de la aplicación.. 4.

(15) Capítulo 2 Redes Programables. 2.1 Introducción La comunidad de investigadores de redes se ha dado cuenta de la necesidad de redes más flexibles y personalizables dinámicamente. Esta idea proviene del requerimiento de que las redes deben ser diseñadas de tal manera que faciliten y den soporte a una rápida creación e implementación de nuevos servicios. Encontrarse con este requisito ha conducido a un cambio del modelo de red unidimensional, tradicionalmente tomados por el modelo de procesamiento de encabezados de paquetes y envío, a un modelo bidimensional con la adición del modelo computacional. La combinación de los dos es lo que define a una red programable [Denazis, 2001]. La repercusión de las redes programables está en el surgimiento de nuevos modelos de negocios tales como que los vendedores y operadores deben abrir sus recursos a terceras partes, proveedores y usuarios, y en consecuencia incrementar nuevos roles de negocios y competencias. La importancia de lo anterior es que una nueva arquitectura de redes ha de ser definida basada en nuevo modelo de programación de redes que influencie nuevas tecnologías de red y adelantos en investigación del campo de los lenguajes de programación, sistemas operativos, orientación a objetos, sistemas distribuidos, etc. En la búsqueda de tales objetivos, dos escuelas de pensamiento han emergido. La primera escuela es representada por la comunidad OPENSIG1 (Open Signalling) y opera a través de seminarios internacionales, mientras que la segunda escuela de pensamiento está representada por la comunidad Active Network (Redes Activas), y opera a través de una serie de proyectos principalmente bajo el auspicio de DARPA. Ambas comunidades han investigado y experimentado con diferentes conceptos arquitectónicos, usando una variedad de tecnologías y enfocándose en diferentes objetivos. La comunidad OPENSIG defiende la idea de que la programabilidad puede ser lograda por medio de la definición de una serie de interfaces de red abiertas que representen los dispositivos físicos de red y los servicios de red como objetos distribuidos. Las interfaces programables permiten a las aplicaciones y los middleware manipular recursos de redes a bajo nivel para construir y administrar servicios. Los 1. OPENSIG, http://comet.columbia.edu/opensig 5.

(16) objetivos de las redes programables [Denazis, 2001] incluyen señalización abierta (open signaling), rápida creación de servicios y un control mejorado de los objetos de red para un mejor soporte de calidad de servicio. Para este fin, a los proveedores de servicios independientes se les permitiría entrar al mercado de las telecomunicaciones y competir con los grandes vendedores y operadores de redes mediante la implementación de sus propios valores agregados o servicios más eficientes. Estas ideas han sido formalizadas en la actividad de estandarización del proyecto IEEE 1520 sobre Interfaces Programables para redes. En contraste, la comunidad Active Networks ha optado por un concepto más dinámico por medio del cual, paquetes activos o "cápsulas" llevan código ejecutable junto con sus datos, siendo esto la base del control de la red. Las redes activas y programables buscan mejorar el uso de los últimos avances tecnológicos en las ciencias computacionales [Denazis, 2001]. La idea central es que esto puede ser logrado añadiendo programabilidad a las redes, reconociendo que las computadoras son muy útiles debido a que pueden ser programadas para diferentes propósitos. La perspectiva de nuevas aplicaciones explotando la programabilidad de las redes y sus implicaciones de largo alcance, son los estímulos para una amplia gama de intereses en las redes activas y programables. Para esta investigación, nos enfocaremos en el concepto de las redes programables, por ser el interés principal de este trabajo de tesis.. 2.2 Redes Programables En el paradigma de las redes, el cambio a un modelo bidimensional con la integración en la red del modelo computacional define lo que llamamos redes programables. El surgimiento de tecnologías activas en el área de los lenguajes de programación, orientación a objetos y programación distribuida y sistemas operativos, hacen posible encontrarse con constantes demandas de usuario para más funcionalidad de la red y personalización que va más allá del modelo de comunicación. La programabilidad en esta dimensión es ejercida por el tratamiento de elementos de red (enrutadores, firewalls, conmutadores, etc.) como un sitio donde cómputo avanzado puede tomar lugar.. 6.

(17) 2.3 Dos Arquitecturas Programables El concepto de Administración de Servicios fue descrito primero en el marco de referencia de la Red de Administración de Telecomunicaciones o TMN, por sus siglas en inglés (Telecommunications Management Network). TMN [Aurrecoechea, 2000] fue dirigido a las redes públicas que proporcionaban un pequeño y bien definido conjunto de servicios de telecomunicación. Sin embargo, esta vieja arquitectura no es adecuada para las demandas actuales dadas por la reciente explosión de aplicaciones y servicios multimedia distribuidos. Ya hemos mencionado las arquitecturas programables, que son las que han surgido para facilitar una rápida y flexible provisión de nuevos servicios con capacidades de QoS, y que además presentan nuevos retos para su administración. Las arquitecturas programables recaen en los conceptos orientados a objetos distribuidos y tecnologías para proveer la flexibilidad necesaria en la modelación y desarrollo de servicios para continuar con el paso de las necesidades de negocios. TINA y xbind [Aurrecoechea, 2000] son dos importantes representantes de las arquitecturas programables. TINA representa la dirección en la cual los operadores de comunicaciones se están moviendo, mientras que xbind es un ejemplo de una red abierta programable. TINA y xbind son ejemplos con diferentes conceptos, el concepto de xbind es abrir las interfases a los elementos de red para permitir sistemas de control personalizables que llevan a un entorno de creación de servicios más fácil. Por su parte, TINA se ha enfocado principalmente en la definición de un modelo de creación de servicios que podría interactuar con los mecanismos de señalización existentes. El concepto de administración en TINA ha sido confuso. Por un lado TINA mantiene los principios de TMN que son aplicados tanto en las arquitecturas de redes como en las arquitecturas de servicios. Pero por otro lado, las actividades de control y administración son indistinguibles. Esto ha sido una limitación más que un beneficio. La desigualdad ha llevado a dos arquitecturas, la de red y la de servicio, sin una visión/concepto para la administración de redes y servicios. En el núcleo de la filosofía xbind está la separación de actividades en un sistema de telecomunicaciones en tres: transporte, control, y administración. Estas actividades actúan sobre el estado del sistema en diferentes escalas de tiempo. La administración de servicios específicamente es considerada en xbind como la última etapa en su modelo de creación de servicios. 2.4 El OPENSIG y el IEEE P1520 La motivación detrás de las redes Opensig ha sido la observación que arquitecturas monolíticas y de control complejo son hechas de componentes básicos que pueden formar un conjunto de servicios de red elementales. Modelando estos servicios como objetos individuales empleando un lenguaje de 7.

(18) programación de alto nivel para la implementación y manipulación de los objetosservicios, resulta en una nueva generación de arquitecturas de redes con algunas nuevas características deseables: interoperabilidad entre diferentes tecnologías de red, programabilidad para la creación de nuevos servicios, e interfaces abiertas sobre el nivel de control. Eventualmente un número de resultados fuera de la comunidad Opensig fueron formalizados por el proyecto 1520 de la IEEE para la iniciativa de interfaces estándares de redes programables y su correspondiente modelo de referencia. El P15202 defiende la necesidad de interfaces abiertas como la base para la composición de servicios (creación). Las interfaces están estructuradas a manera de capas, ofreciendo sus servicios a las capas superiores. Cada capa define lo que es realizable en ese nivel. Cada nivel comprende un número de entidades en forma de algoritmos u objetos representando recursos lógicos o físicos dependiendo del alcance del nivel y la funcionalidad.. Fig. 2.1: Modelo de referencia P1520. El modelo de referencia (ver Fig. 2.1) 1520 distingue los siguientes cuatro niveles: - El nivel de elemento físico (PE), consistente de entidades tales como hardware y los dispositivos de arquitectura que realmente reflejan las capacidades soportadas.. 2. P1520, http://www.ieee-pin.org 8.

(19) - El nivel de dispositivo de red virtual (VNDL), representa lógicamente recursos en forma de objetos (entidades); aislando las capas superiores de las dependencias hardware u otras interfaces propietarias. - El nivel de servicios genéricos de red (NGSL), consiste de entidades en forma de algoritmos distribuidos que ligan (interconectan) entre sí los objetos del nivel VNDL de acuerdo a la funcionalidad específica de la red, por ejemplo, ruteo, establecimiento de conexiones, etc. - El nivel de servicios de valor agregado (VASL), incluye entidades en forma de algoritmos end-to-end, que refuerzan los servicios genéricos del nivel NGSL, proporcionando características orientadas al usuario y capacidades en las aplicaciones. Los cuatro niveles dan lugar a cuatro interfases llamadas CCM (Connection Control and Management), L (Lower), U (Upper), y V (value-added). La interfaz CCM es realmente una colección de protocolos que permiten el intercambio de información de estado y control a muy bajo nivel entre los dispositivos y un agente externo. La interfaz L define una API que consiste de métodos para manipular recursos de red locales, abstraídos como objetos. Las interfaces CCM y L caen dentro de la categoría de interfaces nodo. La interfaz U proporciona principalmente una API que trata con los problemas de establecimiento de conexiones. Como en el caso de la interfaz L, la interfaz U aísla la diversidad de requerimientos de establecimientos de conexiones de los algoritmos actuales que los representan. Finalmente, la interfaz V (no mostrada en la figura) proporciona un rico conjunto de APIS para escribir software altamente personalizable, generalmente en forma de servicios de valor agregado. Adicionalmente, las interfaces U y V constituyen las interfaces a lo largo de la red. Actualmente están siendo examinadas interfases L y CCM apropiadas para enrutadores y conmutadores IP [Biswas, 1998]. Haciendo una comparación [P1520/TS/IP-001, 1998], la principal diferencia entre el concepto de la comunidad de Internet y el concepto del P1520 de es que se intenta estandarizar interfases programables en lugar de especificar algoritmos o semánticas de protocolos. El modelo de referencia P1520 proporciona un marco de referencia general para el mapeo de interfaces de programación y operaciones de redes, sobre cualquier tecnología de red dada. Mapear diversas tecnologías de red y su correspondiente funcionalidad para el P1520 es esencial. Como se menciona en [Bjorkman, 2001] la meta es hacer la red tan programable como la PC a través de un conjunto de APIs estandarizadas, mientras se mantiene extensibilidad y flexibilidad para acomodar futuras funcionalidades y diferenciación propietaria. Esfuerzos iniciales se enfocaron en redes de telecomunicaciones basadas en ATM e introdujeron programabilidad a nivel de control, más tarde extendieron esos principios a las redes IP y enrutadores. El lado derecho de la figura ilustra un mapeo del modelo de referencia P1520 para los enrutadores IP. Hoy en día hay un esfuerzo para crear un marco de referencia para diseñar interfases no solamente para enrutadores, sino que también para cualquier elemento de red 9.

(20) como un enrutador, o un conmutador óptico, etc. que participe en el envío de tráfico.. 2.5 Infraestructura y beneficios de las interfases programables Para el soporte de los elementos de red (enrutadores, conmutadores, etc.) se necesitan consensos con la industria y una estandarización en forma de APIs. Estas APIs deben ser expresadas [P1520/TS/IP-001, 1998] en un marco de referencia orientado a objetos distribuidos en forma, por ejemplo, de interfases IDL CORBA. A estas interfases se les llama Bases de Interfases de Enlace (Binding Interface Bases). Las tecnologías existentes de plataformas distribuidas como JAVA, RMI, CORBA, DCOM, o combinaciones de estas pueden ser la infraestructura subyacente para la incorporación de esas interfases. Los principales beneficios [P1520/TS/IP-001, 1998] de tener tales interfases programables para los elementos de redes son: a) Separación del negocio de servicios. El estado de la red es ahora visible a entidades externas y pueden ser manipuladas de manera controlada. Esto significa que en el backbone, tanto como en los ISP, se tiene la flexibilidad de emplear la tercera parte de los proveedores de servicio de señalización para implementar servicios de señalización que tienen acceso a sus recursos mediante interfaces abiertas. b) Separación del negocio de provisión. Una API abierta permite emerger a proveedores independientes de software de señalización y sistemas. Ellos no están estrechamente integrados con los proveedores de hardware subyacente. Es posible tener una industria de software de señalización en el negocio de provisión de aplicaciones con QoS que tengan la habilidad de accesar abstracciones software de elementos de red. c) Proceso de estandarización más rápido. Es más fácil lograr un consenso en un conjunto de objetos genéricos presentando una abstracción de un dispositivo de red, en lugar de algoritmos específicos y protocolos. Abriendo la señalización y control de la red, las APIs eliminan la necesidad de estandarizar algoritmos de señalización y semánticas. d) Extensibilidad. Los beneficios de la tecnología de diseño de software orientado a objetos proporcionan maneras flexibles y extensibles de incorporar funcionalidades adicionales, protegiendo a los dispositivos de ser afectados por extensiones o modificaciones de los protocolos.. 10.

(21) e) Semánticas más ricas. Los beneficios del cómputo distribuido, ubicación transparente, acceso remoto, enlace dinámico y la capacidad de programación completamente fuerte serán usados. Como cualquier nuevo cambio de paradigma, existen preocupaciones sobre desempeño y seguridad relacionadas con este tema. Sin embargo, debemos enfatizar que la apertura no significa un acceso sin restricciones a todas las interfases de red. En otras palabras, el control de acceso debe ser fortalecido mediante técnicas apropiadas de modo que solo las partes autorizadas y confiables tienen acceso a las interfases abiertas. De hecho, esta es una razón para adoptar un marco de referencia orientado a objetos distribuidos, por ejemplo CORBA, que se analizará en otro capítulo y que presupone las características de seguridad como una necesidad arquitectónica. Está claro que las interfases abiertas programables para los elementos de redes IP presentan muchas ventajas. En vista del rápido desarrollo de soluciones de Internet con QoS, como los Servicios Diferenciados y MPLS, y el incremento del número de protocolos propuestos relacionados con señalización, el hecho de introducir el modelo de referencia P1520 a Internet proporcionaría un medio para explotar las características comunes a esos modelos y propuestas, y facilitar la integración de esas soluciones.. 2.6 Interfases Programables y enrutadores IP Aún cuando las interfaces programables están más asociadas con el control de redes ATM que con el control de redes IP, la necesidad de modificaciones dinámicas de políticas y configuraciones en enrutadores IP están emergiendo. Las aplicaciones pueden incluir lo siguiente [P1520/TS/IP-003, 1998]: 1) Ajustes de localización de recursos por clase de servicios diferenciados. El tratamiento preferencial de prioridad de clases puede ser establecido o modificado mediante una interfaz P1520 según lo requieran operadores públicos, empresariales y de redes privadas virtuales (operadores de red enfocados en servicios RPV), ISPs y otras entidades de administración, responsables de grandes volúmenes de tráfico. Por ejemplo, el tratamiento preferencial de colas de control y prioridad de tráfico pueden ser mejorado en situaciones de emergencia, o para la distribución de notificaciones excepcionalmente importantes. 2) La preparación de tráfico por la dirección fuente y/o destino. El enrutamiento basado en políticas, agregación basada en dirección, y otras funciones basadas en direcciones fuente y/o destino pueden ser dinámicamente invocadas, modificadas, o terminadas mediante una interfaz P1520. Por ejemplo, un ISP con un gran número de clientes accesando a través de un enrutador de red en. 11.

(22) particular empresarial o público puede desear usar una ruta especial con la que el ISP ha impuesto o acordado ciertas políticas. 3) Configuración de interfases físicas o recursos. Un enrutador puede soportar una variedad de mecanismos de acceso de capa 1 y capa 2 (como ISDN, frame relay, PPP, etc.), los cuales requieren configuraciones para nuevos usuarios, o cambios en los equipos de los usuarios. Esta administración de configuración, incluyendo módulos de código descargables o ejecutables, podría ser manejada a través de una interfaz P1520, disponible para múltiples entidades administrativas tales como ISPs y operadores de redes virtuales tanto como operadores de redes públicas. 4) Facilitar políticas de redes activas. Podría no ser suficiente realizar funciones de "redes activas" a través de la transferencia de código ejecutable en el tráfico de información exclusivamente. Políticas para la asignación de recursos de procesamiento en escalas de tiempo cortas o largas, serán facilitadas por una interfaz P1520.. 2.7 Una futura estandarización Existen tres tecnologías sobre las cuales se está trabajando bajo el concepto de interfaces programables. Las redes ATM, redes de conmutación de circuitos basadas en SS7 y finalmente, las redes IP de enrutadores y conmutadores. Estas tecnologías difieren no solamente en su orientación y contenido técnico, sino que también en la magnitud de su presencia en el mercado. ATM es una tecnología que se ha posicionado en los backbones y troncales de las redes. Por su parte, la tecnología IP sigue creciendo rápidamente y se expande hacia varios tipos de redes, desde datos hasta voz, e incluso en las redes inalámbricas. La tecnología SS7 está bien posicionada en el mercado de las telecomunicaciones, principalmente para aplicaciones de telefonía. Estas tres tecnologías son técnicamente muy divergentes y se espera que sigan coexistiendo en el futuro, por lo tanto ninguna de ellas puede ser ignorada. Desde la perspectiva de las interfaces abiertas programables, la primera prioridad [Biswas, 1998] es rediseñar cada una de esas tecnologías separadamente, de ninguna manera debe pensarse en un mapeo unificado de las tres como una meta inmediata, ni permitir la interoperabilidad de las tres tecnologías en esta etapa. Los protocolos de señalización para el manejo de tráfico multimedia en Internet, por ejemplo, deben ser reexaminados desde el punto de vista de las garantías de QoS. Si se desean interfases programables para este tipo de protocolos, deben ser especificados claramente. Algo similar ocurre con las redes ATM y SS7. Así que se debe iniciar con cada tecnología, definiendo los detalles y proponiendo. 12.

(23) interfases, motivadas por el modelo de referencia. En los productos Cisco3 ya están disponibles implementaciones de redes programables. Una vez que esas interfaces hayan sido especificadas, implementadas y usadas, podremos estar en una mejor posición para integrar o interoperar entre las diferentes tecnologías.. 3. http://www.cisco.com 13.

(24) Capítulo 3 Middleware y Corba. 3.1 Introducción El desarrollo de esta investigación se basa en el uso de un middleware, por lo que es necesario hacer una breve descripción de estos conceptos para comprender más a fondo los objetivos de esta tesis. El middleware es un software intermedio entre clientes y servidores, y utilizado en ambientes distribuidos, es decir, en ambientes formados por una colección de hardware y software situados en equipos de cómputo autónomos unidos por una red, que se coordinan mediante el paso de mensajes. Un ejemplo de lo anterior es Corba el cual es una tecnología de middleware orientada a objetos, es una especificación que debido a sus características y beneficios es utilizada en muchas implementaciones distribuidas.. 3.2 Middleware Algunas definiciones de Middleware son [ITU]: • Software que soporta interacciones de procesos. • Software que oculta protocolos de comunicación. • Software que reemplaza protocolos de comunicación. • Software que oculta plataformas de cómputo. • Software que proporciona una tecnología independiente del ambiente de programación. • Software que soporta interacciones de sistemas abiertos. Básicamente, el Middleware es un software de comunicaciones que reside físicamente en el cliente remoto y en un servidor de comunicaciones, localizado entre el cliente y el servidor de aplicaciones. Es el software que actúa como un traductor universal entre distintas tecnologías y protocolos [GIST]. Es el software de conectividad que consiste en un conjunto de servicios, que permiten interactuar a múltiples procesos que se ejecutan en distintas máquinas a través de la red. El middleware es considerado una lógica de mediación que proporciona: -. Un modelo de programación de alto nivel Transparencia de ubicación. 14.

(25) -. Independencia de protocolos, sistemas operativos y hardware. Desde un punto de vista amplio una solución basada en productos de Middleware debe permitir conectar entre sí a una variedad de productos procedentes de diferentes proveedores. De esta forma se puede separar la estrategia de sistemas de información de soluciones propietarias de un sólo proveedor. El concepto de middleware no es nuevo. Los primeros monitores de teleproceso de los grandes sistemas basados en tecnología cliente servidor ya se basaban en él, pero es con el nacimiento de la tecnología basada en sistemas abiertos que el concepto de Middleware toma su máxima importancia. Middleware ha existido en varias formas por muchos años [Vinoski, 2002] en sistemas como el IBM Customer Information Control System (CICS), numerosos sistemas de colas de mensajes como las series MQ de IBM, el Common Object Request Broquer Arquitecture (CORBA), Java 2 Enterprise Edition (J2EE) y más recientemente, Web Services. Virtualmente cada forma de aplicación, lenguaje de programación, sistema operativo y hardware ha sido un blanco de un esfuerzo de integración envolviendo esos sistemas middleware. Middleware está en todos lados. Las categorías del Middleware podríamos definirlas de la siguiente forma: -. -. -. Monitores de proceso de transacciones distribuidos (DTPM's Distributed Transaction Processing Monitors). Herederos de la tecnología mainframe, son ampliamente demandados para intercomunicar distintos sistemas en distintos entornos. Llamadas a procedimientos remotos (RPC's Remote procedure Call) Diseñado como servicios síncronos para permitir gestión remota de redes. Middleware orientado a mensajes (MOM Messaging Oriented Middleware) Diseñado para servicios de mensajes con tecnología asíncrona. (ORB Objects Request Broker) Middleware para tecnologías orientadas a objetos. Objetos piden servicios de objetos que se encuentran en la red. El estándar más conocido de esta tecnología es CORBA Common Object Request Broker Arquitecture. Middleware de acceso a Bases de Datos (Data Base Access Middleware). Para acceso estándar a bases de datos. Permite desarrollar sistemas independizándolo de la base de datos que lo soporte. En la actualidad representa el 50% del mercado del middleware.. Algunas áreas donde actualmente se puede encontrar aplicaciones Middleware son: • Educación a distancia • Aplicaciones móviles • Comercio electrónico • Aplicaciones basadas en Web. 15.

(26) 3.2.1 Ventajas -. Simplifica el proceso de desarrollo de aplicaciones al independizar los entornos propietarios. Permite la interconectividad de los sistemas de información de la organización. Proporciona mayor control del negocio al poder contar con información procedente de distintas plataformas sobre el mismo soporte. Facilita el desarrollo de sistemas complejos con diferentes tecnologías y arquitecturas.. Dentro de los inconvenientes más importantes destacan la mayor carga de máquina necesaria para que puedan funcionar. 3.2.2 Campos de Aplicación - Migración de los Sistemas Host. Reingeniería de Aplicaciones La aplicación debería diseñarse en base a módulos intermedios middleware encargados de la comunicación entre el ordenador personal y el host. Esto permite desarrollar hoy la aplicación, sin tener en cuenta los futuros cambios tecnológicos que puedan sufrir los sistemas host. Si el sistema host cambia, o las aplicaciones de host se migran a plataformas de ordenadores personales, todo lo que se necesita es un nuevo módulo middleware. La interfaz de usuario, la lógica y el código interno permanecen sin cambios. Por ejemplo, si el equipo lógico del sistema host se traslada desde el mainframe a una base de datos de plataforma PC ejecutándose en un servidor de ficheros, sólo hay que sustituir el módulo de middleware de forma que realice llamadas SQL. - Interconectividad Uno de los usos más importantes de las herramientas de middleware es la de facilitar la interconectividad de los diferentes sistemas de un organismo integrando las diferentes islas de información departamentales. - Arquitectura orientada a objetos distribuidos El concepto de middleware permite también independizar los servicios proporcionados por diferentes objetos que se encuentran en una red proporcionando una red de objetos independientes e interconectados entre sí. - Arquitectura cliente/servidor La utilización de Middleware permite desarrollar aplicaciones en arquitectura cliente servidor independizando los servidores y clientes, facilitando la interrelación entre ellos y evitando dependencias de tecnologías propietarias.. 16.

(27) 3.3 Definición de CORBA El tema de la administración de la creación de objetos distribuidos, métodos de invocación remota, persistencia de objetos y terminación de objetos es común a todos los sistemas middleware distribuidos. Conforme a esto, la aplicación de middleware es apropiado sin importar donde sea requerida una funcionalidad distribuida compleja. Corba es una especificación normativa de un conjunto de industrias informáticas asociadas con el nombre de OMG4. Esta norma cubre todos los ámbitos de los sistemas de objetos distribuidos. Las aplicaciones distribuidas consisten de varios programas comunicándose, escritos en diferentes lenguajes y corriendo sobre diferentes sistemas operativos. El estándar CORBA define un entorno para el desarrollo de aplicaciones distribuidas. Corba es una especificación la cual define una infraestructura para la arquitectura OMA (Object Management Arquitecture) de OMG (Object Management Group), especificando los estándares necesarios para la invocación de métodos sobre objetos en entornos heterogéneos. Es un estándar creado con la idea de una distribución de los sistemas basada en objetos. Con Corba se pretende definir una arquitectura que especifique cómo se crean los objetos y cómo se accede a sus funcionalidades. Lo anterior se consigue de forma transparente para los clientes y servidores. Los clientes simplemente invocan un método de un objeto servidor y no tienen que preocuparse de la localización de dicho objeto. Además, la petición se realiza en el lenguaje de programación en que esta codificado el cliente aunque el servidor este realizado en otro distinto. Corba es el resultado de muchos años de trabajo de varias compañías para definir un estándar que satisfaga a todos los lenguajes de todos los sistemas operativos. Corba nos abre las puertas a la posibilidad de usar e implementar interfases en Unix, Linux, Mainframes de IBM, Solaris, Sillicon Graphics, Windows, etcétera, en lenguajes tan dispares como Java, C, Delphi, COBOL, SmallTalk, FORTRAN, LISP y muchos otros. Parte del éxito de Corba se debe a la clara separación entre la interfaz de los objetos y la implementación de los mismos. Las interfaces se definen utilizando el lenguaje IDL, cuya principal característica es su alto nivel de abstracción, lo que le separa de cualquier entorno de desarrollo específico. Para la implementación de los objetos se puede utilizar cualquier lenguaje de programación que proporcione enlaces con el lenguaje IDL. Para que un lenguaje de programación se pueda utilizar desde Corba, debe tener definida la forma de enlazarse con IDL. 4. Object Management Group http://www.omg.org 17.

(28) •. Corba NO ES un producto Corba es una especificación de como debe funcionar un set de librerías específicas para llamarse un ORB. Visigenics e IONA son dos productos que implementan la tecnología Corba. Los productos que implementan Corba se llaman ORBs. •. Corba NO ES un lenguaje De la misma manera, Visigenics (un ORB) está disponible para varios lenguajes bajo varias plataformas (Visigenics for C++/Linux, Visigenics for C++/Windows, Visigenics for Java). Pero CORBA en sí mismo no es un lenguaje, sino una serie de librerías y servicios.. Las capacidades de Corba no paran acá. Dos características que Corba ofrece [Rosenberger, 1998] son la independencia del lenguaje y la independencia de la plataforma. 3.3.1 Independencia de la plataforma La independencia de la plataforma significa que los objetos Corba pueden ser usados en cualquier plataforma para la cual exista una implementación ORB de Corba (esto incluye virtualmente todos los sistemas operativos modernos y algunos otros no tan modernos) Como ORB no es dominado por una sola compañía sino por un grupo, mientras se pueda compilar un programa para un sistema operativo X y pueda comprar unas librerías ORB para el mismo sistema operativo (y que funcionen con el lenguaje), es posible comunicarse con cualquier otro servicio en la red que exponga un ORB, sin importar qué sistema operativo o qué marca de ORB está ejecutándose en la máquina que expone el ORB. 3.3.2 Independencia de Lenguaje La independencia del lenguaje se refiere a que los objetos Corba y los clientes pueden der implementados en cualquier lenguaje de programación. Además los objetos Corba no necesitan saber qué lenguaje fué usado para implementar otros objetos Corba con los que se tienen que comunicar. ¿Cómo se logra la independencia entre lenguajes? Las interfases Corba se representan en un Lenguaje unificado llamado IDL (Interface Definition Language). Cada lenguaje (Delphi, Java, C, etc.) cuenta con un traductor (también llamado "compilador") de IDL, que traduce las sentencias de la definición de la interfase al lenguaje adecuado. Cuando usted compra librerías de Corba (también llamadas ORBs) para su lenguaje, las librerías normalmente vienen con programas llamados "idl2XXX", donde "XXX" es el nombre de su lenguaje. De esta manera, un ORB para java. 18.

(29) viene con un compilador de IDL llamado "idl2java", mientras que C++ vendría con un compilador llamado "idl2cpp".. 3.4 La arquitectura OO y Corba En el paradigma de la arquitectura orientado a objetos existen tres elementos: la arquitectura orientada a objetos, las interfases, y la implementación. La arquitectura orientada a objetos es una descripción simplificada del software, en otras palabras, una abstracción. La arquitectura OO [Mowbray, 1997] identifica cómo el SW es diseñado para facilitar el manejo de los cambios y la complejidad, entre otras cosas. La arquitectura juega un papel importante definiendo varios límites: categorías de objetos, divisiones, interacciones y demás. Las interfases son las definiciones detalladas de los límites arquitectónicos. A los niveles de sistema y empresarial, las interfases deben ser especificadas en IDL Corba. A escalas más pequeñas, las interfases podrían usar IDL Corba o ser independientes del lenguaje, según sea apropiado a su escala de reuso e impacto. El tercer elemento en el paradigma, la implementación, son los módulos de software encapsulados por las interfases que proporcionan funcionalidad y desempeño.. 3.5 El Open Management Group En 1989, los altos ejecutivos de varias compañías (desde compañías de Software hasta Bancos, entre ellas American Airlines, Canon, Data General, HP, Philips Telecomunicaciones, Sun, 3Com y Unisys) se reunieron para hablar acerca de interfases, y de la importancia que éstas tendrían en el futuro. Estas empresas, que forman el llamado Open Management Group decidieron que, dada la enorme importancia que las interfases tendrían, sería muy útil especificar un estándar para que todos los lenguajes de programación pudieran exponer interfases, sin importar el lenguaje, el sistema operativo o el vendedor de servicios de objetos. Su objetivo [Zahabi, 2000] era crear y adoptar mercado de software basado en componentes a través de la estandarización y la promoción del software orientado a objetos. Para lograr esta meta, el OMG especifica estándares abiertos para cada aspecto del cómputo de objetos distribuidos desde el análisis y diseño, a través de la infraestructura, hasta los objetos y componentes de aplicaciones.. 19.

(30) 3.6 La Open Management Arquitecture La arquitectura OMA – Object Management Architecture – definida por el OMG para intentar conseguir una compatibilidad completa de los sistemas de objetos distribuidos, clasifica los objetos en cuatro categorías: • • • •. CORBAservices CORBAfacilities CORBAdomain objects Application Objects.. OMA es la visión de alto nivel de un ambiente computacional distribuido [OMG]. Application Objects. Vertical Domain Facilities. Common Facilities. Object Request Broker. Object Services. Fig 3.1 Arquitectura OMA. 3.7 Componentes de Corba Las aplicaciones Corba están compuestas de objetos, unidades individuales de software en ejecución que combinan funcionalidad y datos, y que frecuentemente (pero no siempre) representan algo en el mundo real. Estos objetos puede vivir en cualquier lugar en una red. Son empacados como componentes binarios que los clientes remotos pueden accesar vía invocaciones a métodos La parte fundamental del Common Object Request Broker Architecture es precisamente el Object Request Broker. El ORB es un componente de software cuyo propósito es facilitar la comunicación entre objetos. El ORB es un "bus de objetos" que permite a los objetos hacer llamadas a otros de forma transparente, independientemente de su localización, del sistema operativo donde se ejecuten y del lenguaje en el que están implementados. Esto lo logra proporcionando un número de capacidades, una de las cuales es localizar un objeto remoto, dado un objeto de referencia.. 20.

(31) Código de implementación del servidor. Definiciones IDL. Compilador. Repositorio de implementación. Repositorio de Interfaz. Stubs. Skeletons. Servidor. Cliente. Fig 3.2 Desarrollo de aplicaciones con Corba Cuando un componente de una aplicación desea usar un servicio proporcionado por otro componente, primero debe obtener una referencia de objeto para el objeto que proporciona ese servicio. Después de que la referencia de objeto se ha obtenido, el componente puede llamar métodos en ese objeto, y entonces accesar los servicios deseados proporcionados por ese objeto. La principal responsabilidad del ORB es resolver peticiones para las referencias de objeto, habilitando componentes de aplicación para establecer conectividad entre los objetos.. Client. Object Implementation. IDL Stub. IDL Skeleton Request. Object Request Broker Fig. 3.3 Paso de una petición de un cliente a una implementación de objetos Tanto el cliente como la implementación de objetos están aislados del ORB mediante una interfaz IDL. Los clientes ven solamente la interfaz de objetos, nunca el los detalles de implementación. Esto garantiza las sustituibilidad de la. 21.

(32) implementación detrás de la interfaz, esto es, un entorno de componentes de software plug-and-play. Como podemos observar en la figura anterior (Fig. 3.3), las peticiones no pasan directamente del cliente a la implementación o servidor, en su lugar, las peticiones son siempre manejadas por el ORB; la forma de invocación es la misma si el objeto es local o es remoto [Siegel, 1996]. Generalmente, los métodos que se invocan toman parámetros como entradas y devuelven otros parámetros como salidas. Otra responsabilidad del ORB es recibir los parámetros de entrada del componente que está llamando al método y ordenar esos parámetros. Esto significa que el ORB traduce los parámetros a un formato que puede ser transmitido a través de la red hasta los objetos remotos. Lo anterior se consigue gracias al lenguaje IDL (Interface Definition Language). Mediante IDL se especifican interfaces, consistentes en conjuntos de operaciones que los objetos que actúan como servidores proporcionan a los clientes. Usando un compilador de IDL, se genera el código necesario en un lenguaje de programación determinado para el lado cliente (los stubs) y el lado servidor (skeletons). En el lado cliente, el código generado se usa en la implementación del cliente como cualquier librería convencional, que hace ver al cliente el objeto(s) servidor y sus servicios. En la parte servidora se genera código que recibe las peticiones locales o vía red de los clientes y se encarga de llamar a las funciones del servidor que proporciona la interfaz IDL, cuyas cabeceras/esqueletos también se han generado, de forma que el código de los métodos existentes en la interfaz debe ser implementado por el programador.. Object Implementation. Client. Interface Repository. Dynamic Invocation. Client IDL Stubs. ORB Interface. Static Skeletons. Dynamic Skeleton Invocation. Object Adapter. Implementation Repository. Object Request Broker (IIOP) Fig 3.4 Estructura de Corba. 22.

(33) De la estructura de Corba (Fig 3.4) se observan los siguientes componentes: - Client Stub El stub del cliente es una pequeña pieza de código generada por el compilador IDL, hace que una interfaz de servidor Corba puede estar disponible al cliente. De cierto modo, hace parecer al cliente que los objetos se encuentran localizados localmente. - Dynamic Invocation Interface (DII) Eventualmente es posible construir clientes Corba sin usar algún stub de cliente gracias a la Interfaz de Invocación Dinámica. En lugar de estar siendo enlazados estáticamente, los clientes pueden descubrir interfases de servidor dinámicamente y usar los servicios aún no concebidos al momento que los clientes fueron construidos. Sin embargo, el uso de DII incrementa de manera significativa la complejidad de una aplicación cliente. - Implementation Skeleton Un skeleton es también generado por el compilador IDL, es una pieza de código que proporciona el marco de referencia en el cual es construido el código de implementación servidor para una interfaz en particular. Para cada método de una interfaz, el compilador IDL genera un método vacío en el skeleton del servidor. Entonces, el desarrollador proporciona una implementación para cada uno de esos métodos. - Portable Object Adapter (POA) El adaptador de objetos portable es el elemento del ORB que administra los recursos del lado del servidor para ofrecer escalabilidad. Su propósito principal es crear una interfaz entre la implementación de un objeto con su ORB. Arquitecturalmente el POA es un pieza separada del ORB, sin embargo es parte de la misma especificación CORBA. El POA pone a disposición unas políticas que permiten a los programadores la asignación y desasignación de patrones de recursos. Dichas políticas son Servicio, Sesión, Proceso y Entidad. - ORB Interface Se encarga de algunos servicios, como poner orden en los parámetros y valores de retorno hacia y desde invocaciones de métodos remotas. Otra responsabilidad es traducir los parámetros a un formato que pueda ser transmitido a través de la red hasta el objeto remoto, y traducir de vuelta los parámetros retornados. - Repositorio de interfaces Almacena información de los IDL definidos. - Repositorio de Implementación Almacena información de las clases que un servidor soporta y los objetos que se han instanciado.. 23.

(34) - Dynamic Skeleton Interface (DSI) Usada para dar mecanismos de Binding. - Bus ORB (IIOP) Utilizado para localizar servicios. Este protocolo, conocido como el Internet Inter-ORB Protocol es requerido para ser implementado por todos los fabricantes quienes quieren hacer sus productos conforme a los estándares Corba. Esencialmente, IIOP asegura la verdadera interoperabilidad entre productos de numerosos fabricantes, de este modo permite a las aplicaciones Corba ser más independientes de los fabricantes.. 24.

(35) CAPÍTULO 4 REDES PRIVADAS VIRTUALES. 4.1 Introducción a las RPV Una “red” consiste en varios dispositivos los cuales se comunican entre ellos mediante algún medio para intercambiar información. Los dispositivos de esta naturaleza incluyen computadoras, impresoras, enrutadores y demás, y que pueden estar localizados en diversos puntos geográficos. En otras palabras, una red es una colección de dispositivos que pueden comunicarse de alguna manera y pueden transmitir y recibir datos exitosamente entre ellos. En las definiciones más simples, el término “privado” se refiere a que la comunicación entre dos o más dispositivos es, de alguna manera, secreta. De acuerdo con lo anterior, la privacidad y seguridad de los datos (integridad de los datos) son también aspectos importantes a considerar en cualquier implementación de RPV. Tratando de definir el término “virtual”, se puede decir que es lo opuesto a lo real, un objeto simulado que desempeña funciones de algo que en realidad no existe. Básicamente una Red Privada Virtual es una red construida para uso privado de una empresa o institución, sobre una infraestructura pública compartida. Una Red Privada Virtual usa la infraestructura Internet como mecanismo de transporte, manteniendo la seguridad de los datos en la RPV. Una RPV hace referencia más al método para lograr un vínculo con socios comerciales, en lugar de la infraestructura física para lograr este fin. Es una manera de extender una red interna (intranet), similar a una extranet para permitir conectividad a usuarios móviles equipos interdisciplinarios geográficamente dispersos, conectividad de oficina-sucursal, etc.. 4.2 Definición de RPV Steven Brown [Brown, 2000] define una RPV como: Un proceso de comunicación cifrado o encapsulado que transfiere datos desde un punto hacia otro de manera segura; la seguridad de los datos se logra gracias a una tecnología robusta de cifrado, y los datos que se transfieren pasan a través de una red abierta, insegura y enrutada.. 25.

(36) Por su parte en [Ferguson, 1998] la definición de Red Privada Virtual es: Una RPV es un entorno de comunicaciones en el cual el acceso es controlado para permitir conexiones en capas pares (peer) solamente dentro de una comunidad de interés definida, y es construida pensada de alguna forma de dividir un medio de comunicación común, donde este medio de comunicaciones provee servicios a la red sobre una base no exclusiva.. túnel. Internet. túnel. Fig. 4.1: Representación de una Red Privada Virtual Como ya se mencionó anteriormente, este tipo de redes son construidas sobre una infraestructura pública como la Internet. Básicamente una RPV funciona estableciendo un túnel seguro entre dos redes y se usa tráfico IP a través de ellos para transferir la información. Los datos que pasan por estos túneles son encriptados y protegidos de accesos no autorizados. Además, los datos sobre las RPV son autenticados o validados para asegurarse de que no fueron alterados durante la transmisión. A continuación se detallan un poco más las tecnologías clave para realizar las RPV basadas en Internet: - Autenticación y Encripción La autenticación es utilizada para asegurar que todos los usuarios pueden identificarse para auditorias o permisos de acceso. Es un método para verificar que el emisor y el receptor sean realmente quienes pretenden ser, y desde luego, que estén autorizados. Por su parte, la encripción provee confidencialidad de la información. Es el resultado de la utilización de algoritmos matemáticos para convertir información legible en información ilegible o cifrada. Quienes están involucrados en una comunicación segura tienen que ser autenticados al principio de su sesión con el objeto de establecer una relación de confianza entre ellos. Como parte de este proceso, las llaves de encripción/desencripción son generadas e intercambiadas. Esas llaves son usadas por los puntos de comunicación finales para transmitir mensajes sobre el ambiente o equipo no confiable.. 26.

(37) - Túneles Las RPVs enfatizan la seguridad por medio de la encripción, desencripción y autorización, sin embargo estas características no son suficientes para asegurar una comunicación confiable y segura. La creación de túneles es una de las principales características de las RPV. Se refiere a que una RPV proporciona un "túnel" o "tubería" a través de Internet entre el origen y el destino, por donde se transmiten paquetes IP que son enrutados hasta el destino. Un túnel es lo que hace a una red privada virtual “virtualmente privada” (ver figura 4.1). Aunque la palabra túnel pudiera parecer que describe una ruta fija a través de Internet, este no es el caso. Los paquetes IP pueden tomar diversas rutas entre los dos puntos finales. Lo que hace a una transmisión por una RPV un túnel es el hecho de que únicamente el receptor al otro extremo de la transmisión puede ver dentro del “campo de encripción protector”. Una RPV no requiere cableado adicional, tampoco comprar nuevo hardware. En lugar de esto, usa la Internet para ampliar las distancias requeridas. Es un método de usar Internet para conectar dos redes separadas entre sí. El túnel IP es el equivalente a un cable físico. Por este túnel pueden ser enviados no solo paquetes IP, sino también tramas o paquetes IPX u otras unidades de transmisión de las capas 2 o 3. Además, ya que el túnel proporciona una conexión directa, las dos redes interconectadas no tienen que mantener información de enrutamiento para la parte de Internet. En un sentido, las RPVs son semejantes a redes de área ancha (WAN), o igual a un túnel encriptado, pero la característica clave de una RPV es que es capaz de usar las redes públicas como el Internet en lugar de las líneas arrendadas, privadas y costosas. Las RPVs se definen por un grupo de políticas administrativas. Estas políticas determinan la conectividad y la calidad de servicio (QOS) entre los sitios. Las políticas se pueden establecer por el cliente o por el proveedor de servicios de RPV. Las redes privadas virtuales son necesarias para evitar, por un lado, el costo y la complejidad de proveer una red física dedicada para cada clasificación de tráfico, y por otro lado, construir una red muy compleja de "todos los servicios" [Redlich, 1999].. 4.3 La economía de las RPVs Las RPVs pueden ofrecer flexibilidad, escalabilidad y ahorro de costos importantes cuando las empresas extienden su red para incluir clientes relevantes, socios comerciales estratégicos y empleados remotos. Estas son las tres razones. 27.

(38) principales por las que una compañía quisiera arriesgar la transmisión de datos importantes a través de la Internet, razones que justifican construir RPVs. El costo es un sustento para cualquier decisión en la temática de las redes, pueden obtenerse ahorros significativos al utilizar la Internet como medio de comunicación en lugar de usar comunicación telefónica o líneas dedicadas. Los estudios indican que el cambio hacia una RPV, ya sea desde Frame Relay o líneas dedicadas, puede generar un 50% de ahorro en el costo de comunicaciones. Estos ahorros hacen a una RPV una decisión estratégica para los negocios de la corporación. Sin embargo, la seguridad debe ser implementada correctamente o los ahorros en costos de comunicación serán contrarrestados por el mayor costo potencial de la seguridad ineficiente. Las RPV utilizan Internet como su medio de transporte, siendo este, un medio propicio tanto para clientes comerciales como para privados. Esta es una gran ventaja ya que Internet se extiende por todo el mundo. La conductividad en Internet es extremadamente eficiente en el mercado actual [Brown, 2000]. La Internet, mayormente, es cotizada con base en la velocidad de acceso. Esto significa que el costo es el mismo al enviar información desde Nueva York a Boston como si lo hace desde Nueva York a Tokyo. Este hecho es uno de los principales sustentos detrás de las finanzas de las RPVs. Como ya mencionamos, las corporaciones no solo están interesadas en conectarse con sus propias operaciones a través de una red corporativa, ellas están también preocupadas en conectarse con socios y clientes como ampliaciones de su red corporativa, es por esto que las RPV son tomadas en cuenta al momento de considerar esta conectividad. Además de flexibles, las RPV son dinámicas y escalables. En algunos casos, las RPV pueden utilizar la inversión que la compañía haya hecho en hardware. La característica más importante de estos puntos, es que la tecnología base de las RPV es el conjunto de protocolos TCP/IP de Internet, lo cual la hace más fácil de comprender e implementar que una tecnología completamente nueva. Una red virtual, en cualquiera de sus tecnologías de implementación, cuenta con un alto grado de seguridad. La información transmitida a través de los "túneles" virtuales en Internet está en todo momento resguardada bajo algoritmos de codificación y las más novedosas políticas de seguridad. La integridad de la información, así como su confidencialidad, está asegurada dentro de una RPV [Kosiur, 1998]. Los pronósticos de la industria muestran que cada vez más organizaciones están planeando conectar sus aplicaciones de misión crítica a Internet para capitalizar su ubicuidad y costo relativamente bajo. La privacidad en una RPV era el crítico 28.

(39) vínculo ausente para tener confianza. Como espectadores, las instituciones financieras, las industrias del cuidado de la salud y los gobiernos federales han observado los desarrollos con vivo interés. Dada la facilidad de implantación y accesibilidad de las RPVs, a las pequeñas y medianas organizaciones les debe resultar irresistible el señuelo de Internet para conectar aplicaciones comunes de redes de datos [Leon, 2000].. 4.4 Implementaciones de RPV Existen cuatro áreas o implementaciones comunes de RPV [Brown, 2000]. Las RPV no son nuevas, pero añaden un nivel de tecnología de cifrado a los servicios de Internet subyacentes. • Intranet Una RPV de Intranet se crea entre la oficina central corporativa y una oficina de ventas remota, o entre las oficinas centrales y las oficinas dependientes. La única diferencia es que se tiene acceso a la Intranet desde fuera de la red, lo que significa que el acceso viene desde el exterior. Normalmente, solo se utiliza dentro de la red de una compañía y únicamente acceden los empleados de la misma. A una RPV de Intranet sólo acceden los empleados, pero el acceso viene desde el exterior y no del interior. • Acceso remoto Una RPV de acceso remoto se crea entre las oficinas centrales y los usuarios móviles remotos. Con el software de cifrado cargado en una computadora portátil, un individuo establecerá un túnel cifrado al dispositivo de la RPV en las oficinas centrales corporativas. • Extranet Una RPV de extranet se crea entre la empresa y sus clientes o proveedores. Aquí es donde el comercio electrónico tiene su mayor impacto. Esta configuración le dará a la empresa la capacidad para realizar transacciones de manera segura y efectiva con sus principales socios comerciales y con clientes que generan ingresos. • RPV interna Una cuarta área o implementación es una RPV interna. Algunos motivos por los que una compañía utilizaría este tipo de RPV son los estudios sobre seguridad que indican que los ataques por empleados internos ocupan el primer lugar. Con esta RPV interna, es posible que dentro de los límites de la empresa se pueda crear un túnel. Todo el tráfico que una compañía considere crítico puede pasar por un cable cifrado y almacenarse de manera segura sin que sea manipulado indebidamente. Los registros financieros, las reuniones ejecutivas y demás,. 29.