Arquitectura de Gestin de Red Hacia la Comunicacin Universal Traduccin por: Manuel Velasco Abstract: La ubicuidad de dispositivos conectados por

red es uno de los primeros pasos hacia el xito de los servicios de comunicaciones universales. Sin embargo, no se ha puesto mucha atencin hacia una arquitectura gestionada de los diversos servicios que se proveen entre los dominios en Internet. La ausencia de una arquitectura de gestin de red entre dominios y escalable restringe la disponibilidad y alcance del servicio. En este paper se propone el ambiente de trabajo Tambourine que define servicios web basados en un API de gestin de red. Tambourine tambin permite que aplicaciones accedan a informacin de administracin y control de dispositivos de red entre dominios. Palabras Clave: Gestin de Red, Red de nueva Generacin, Composicin de Servicios, Ambientes Inteligentes, Servicio Web INTRODUCCIN En ambientes ubicuos de red, todo est conectado a travs de la red. Aplicaciones conscientes de su contexto habilitadas por medio de coordinacin de varios dispositivos de red enriquecer la experiencia de usuario. Posterior a la introduccin del concepto de redes ubicuas han aparecido diversos dispositivos de red. Por ejemplo no solo en computadores pero en objetos de consumo electrnico como TVs digitales, consolas de videojuegos, proveen conectividad de red. Aadido a esto el concepto de computacin en la nube resulta en el nacimiento de diversos servicios web. La mezcla de tecnologas ha permitido la combinacin de distintos servicios web en un nuevo servicio. Este cambio de paradigma ha disparado problemas tcnicos nuevos en cuanto a la administracin de tales servicios diversos. Por ejemplo Eye-fi es una memoria SD en la red, al ser cargada a una cmara digital se comporta como una SD normal, pero a su vez detecta puntos de acceso WiFi preconfigurados y sube los contenidos a un servicio web de almacenamiento de fotos en lnea. Por otra parte, el portarretratos digital de Sony CP-1 se equipa con una interfaz WiFi y puede acceder al servicio de almacenamiento en lnea de fotos y mostrar las fotos. Al momento que un usuario combina ambos dispositivos en red y los servicios de almacenamiento, se puede crear un escenario shoot-and-show. A pesar de crearse dichos servicios aparecen problemas si el servicio opera por un largo tiempo. Por ejemplo, aparte de dichos dispositivos y un servicio web, el servicio se provee a travs de distintos dominios como son redes domsticas WiFi, la red de acceso del ISP y las redes de ncleo. Varios problemas en cada distinto dominio puede anular el servicio, y un usuario regular no podr

determinar la fuente del problema incluso en su red domstica y ms an en los dominios externos.

FIGURA 1 servicio shoot-and-show. Para combatir este problema se cree que el cambio innovador del concepto y arquitectura de la gestin de red es necesario. Las opciones de gestin de red se limitan a un dominio cerrado como intranets y redes de hogar. El protocolo ms representativo es el SNMP que provee informacin simple de equipos en la red. Si bien es una herramienta antigua y establecida pero no puede flexibilizarse para su uso en nuevos dispositivos. Adems solo se usa en ambientes de dominios cerrados por su ausencia de autenticacin rigurosa. Si bien se introduce dicho mecanismo en su versin 3, apenas algunos dispositivos lo toleran. Estos problemas en servicio se solapan detrs de dominios. En este paper se propone una arquitectura gestionada de red que permita que las aplicaciones obtengan informacin de la red y controlen los dispositivos mediante interfaces de servicios web. Al proporcionar suficiente informacin entre dominios, las aplicaciones automticamente pueden detectar y configurar equipos de red. Para la seccin 2, se plantean los principios de diseo e implementacin de la arquitectura de gestin de red, y luego se muestran algunas aplicaciones que utilizan este concepto. 2. Desafos y principios de diseo. En esta seccin se describe los requisitos para mecanismos de gestin de redes de nueva generacin. Se plantean ocho requisitos: /poaragraph

Requisito 1 Independencia de protocolo de transporte: El protocolo de gestin de red de prxima generacin debe ser capaz de manejar redes extremo a extremo hasta capa aplicacin. El principal protocolo actual, SNMP, tiene sus limitaciones en cuanto a manejo de capa aplicacin.

FIGURA 2 Vista de dominio y administracin Requisito 2 Flexibilidad de control As como para el servicio de red, varias entidades de negocios existen tanto en direccin horizontal como vertical. El dominio de administracin correspondiente si existe y se requiere para una cooperacin como la indicada en la figura 2, pues la cooperacin entre dominios de un mismo estrato entre dominios de administracin de red T1 y T2; por lo tanto se debe tener flexibilidad de control entre miembros de este estrato. Requisito 3 Plano de control uniforme La figura 2 simboliza que el control de la red se libera incluso hacia el usuario regular, por lo que el usuario debe ser capaz de manipular la gestin desde una capa fsica hacia aplicacin de manera flexible en un mismo plano de control con una herramienta de software con equipamiento familiar. Requisito 4 Evasin de investigaciones tediosas

El nmero de administradores (incluido el usuario) accediendo a informacin de gestin es creciente a tal punto que toda la escala de clientes internet acceden a dichos datos. El usuario por lo tanto necesita un mecanismo que aliviane la carga de procesamiento que resulte en sobrecarga en equipos de red innecesaria. Una funcin que evite peticiones reiterativas es necesaria. Requisito 5 Definicin descentralizada de objeto gestionado Debe ser posible proveer flexibilidad al definir objetos gestionados de modo que se adece una arquitectura de administracin descentralizada , ac se debe incluir a la aplicacin y protocolo de comunicacin, lo que debe permitir la diversificacin de objetos gestionados desde la arquitectura actual hacia una nueva. Requisito 6 Consideracin de sistemas embebidos Se debe tener la capacidad de considerar el sistema embebido como un componente fundamental de toda la red. Un sistema integrado puede residir dentro de la red principal o incluso en la red del cliente. Las redes antiguas pueden tener tambin sistemas embebidos. Requisito 7 Expansin del objeto gestionado La gestin de objetos en la red no solo se realiza sobre equipo de comunicaciones, se requiere para manejar todo objeto fsico o virtual para poder incorporarlo y adecuarlo a la evolucin futura de la red como tal. Requisito 8 Intercambiabilidad con sistemas existentes Cualquier tecnologa nueva no puede ser introducida por la tecnologa de gestin de red mientras no haya una tecnologa de transicin para la existencia de un sistema administrativo , la dificultad es mantener la interconectividad como requisito final y una continuidad de servicio en esta fase de mantenimiento. 3. implementacin /subsection 3.1 Estilos de arquitectura REST REST significa Representational state transfer y es un estilo de arquitectura de software para sistemas distribuidos de hipermedios como lo es WWW. Se refiere estrictamente a una coleccin de principios de arquitectura de red que estructuran como los recursos se definen y direccionan. El termino usualmente se usa de modo informal para describir interfaces simples que transmiten datos de un dominio especfico sobre HTTP sin una capa adicional de mensajes. La separacin cliente servidor simplifica la implementacin de componentes, reduce la complejidad de semntica de conectores, mejora la efectividad de cambios en desempeo y tambin incrementa la escalabilidad. Estas caractersticas ayudan a crear un plano de control de administracin de red.

FIGURA 3 Arquitectura de administracin de TAMBOURINE

FIGURA 4 Arquitectura de Software de TAMBOURINE La figura 3 muestra un ejemplo de gestin de red con Tambourine, para el ejemplo el servicio consiste de tres dominios distintos (Red de sensores, red IP, red Domstica) Cada dominio se gestiona independientemente. En esta arquitectura un Proxy activo se instala para cada dominio. Aunque los protocolos de transporte sopn distintos en cada dominio, se asume que el Proxy activo oculta el protocolo de gestin domstico y provee un API REST unificado para internet sobre HTTP. Un usuario o aplicacin que desea obtener la informacin gestionada primero accede al Proxy por

Internet y pide luego informacin en los dispositivos de red, entonces el proxy proveer las respuestas a nombre de los dispositivos de red. 3.2 Estructura de software del Proxy activo La estructura de software del proxy activo se muestra en la figura 4. El Administrador de URI gestiona la correspondencia con un recurso en el Proxy URI y distribuye la operacin definida en el URI aceptado. El procesador de solicitud es llamado y se ejecuta SNMP, quien proporciona un Respond apropiado. Diferentes protocolos de gestin subyacentes se implementan aqu en forma de Plug-ins. Actualmente se pueden enumerar SNMP v1, v2c, NETCONF, entre otros como pueden ser Plug-ins de redes de sensores inalmbricos. 4. Aplicaciones En esta seccin se introducen dos aplicaciones que se proveen bajo la arquitectura de red Tambourine 4.1 DAS Los SNS han atrado la atencin como la infraestructura de red ms til. Pero sus capacidades de servicios limitan la calidad y tiempo disponible para compartir contenido tal como video en HD. Se propone un sistema que fusiona Digital Living Network Alliance (DLNA) con SNS, para que el usuario pueda compartir contenido de alta calidad DLNA con otros usuarios por internet con facilidad y gran velocidad. La lnea gua de DLNA aplica para redes simples domsticas, se ha dificultado interconectar redes domsticas sobre internet. Se soluciona el problema constituyendo una conexin por VPN entre agentes DLNS para SNS y reenvo de contenido entre el dispositivo DLNA con un proxy reverso. En otras palabras el servicio web SNS acta como centro de control de distribucin de contenidos y configurar ruteadores de red domstica por una interfaz de administracin de red ofrecido por Tambourine. 4.1.1 Escenario de servicio Para ilustrar el sistema propuesto, el siguiente escenario se usa. Un usuario anfitrin comparte el contenido en un servidor de medios digitales DMS con un usuario invitado en una SNS. El DAS sube contenido DLNA a la pgina SNS del invitado. En el sistema DAS, el sitio web SNS controla permisos de acceso para acceder al contenido DLNA. El usuario invitado maneja la lista de contenido DLNA enviada desde el DAS a travs de la pgina de control de SNS. Luego este usuario invitado y su DAS reescriben la IP origen de la lista de contenido compartido para compatibilidad con la red del usuario proveedor del servicio. Finalmente el usuario anfitrin reproduce el contenido compartido usando su DMP. Para el sistema propuesto se usa DMP y SNS de cdigo abierto y no requiere modificaciones del DMS o el DMP. 4.1.2 Arquitectura del Sistema

DAS se compone de un servidor SNS agente DLNA y dispositivos DLNA, incluyendo DMP y DMS. Das accede tanto al servidor SNS como a los dispositivos DLNS. El servidor SNS incluye un servicio SNS provisto por un servidor, como Mixi. Cada usuario tiene una cuenta con el mismo servicio SNS. Con configuracin inicial, un usuario accede a una pgina de setup en el DAS e ingresa la identificacin SNS y contrasea. Das obtiene un token de autenticacin desde el servidor SNS usando su identificacin y contrasea. Para el siguiente escenario se asume que el usuario anfitrin comparte el contenido en el DMS con el anfitrin. En esta arquitectura los servidores DLNA y los dispositivos no se modifican y los equipos certificados para DLNA se pueden usar.

FIGURA 5 Vista General del Sistema 4.1.3 Flujo de Llamadas de Servicio DAS obtiene certificados desde el servidor SNS usando la ID SNS y contrasea. El proxy DLNA en DAS obtiene listas de contenido almacenado desde una base de datos de contenidos en el DMS. El DMS hace dicha base usando el Content Directory Service (CDS) que es un servicio de UPnP. CDS contiene metadatos del contenido, tal como ttulo, formato de video, duracin y URL. Cuando el DMS responde a CDS:Browse que se solicita desde el DMP, retorna el resultado de browse en formato XML para la definicin de DLNA. El proxy DLNA en DAS1 recolecta el contenido en DMS usando CDS:Browse y pide y concatena cada entrada en un solo archivo XML. Entonces enva el archivo XML a la pgina SNS del anfitrin. Adems, el servidor VPN de DAS1 tiene informacin para acceso al servidor VPN desde un cliente remoto. Al unirse DAS1 a la red el servidor VPN en DAS1 enva informacin VPN a la pgina SNS del usuario anfitrin. Un servidor SNS maneja cuentas de usuario, la base de datos de listas de amigos, listas de contenidos compartidos e informacin de VPN. Cuando un usuario accede a las listas de contenido compartido el servidor SNS genera una pgina de administracin de listas de contenido compartido usando la lista de contenido del proxy DLNA en DAS1 y la lista de amigos del anfitrin

en el servidor SNS. En esta pgina encontramos ttulos de contenido, nombre de amigo y botn de enviado. Para nuestro escenario el usuario anfitrin accede a la pgina de administracin de listas de contenido compartido en el servidor SNS y escoge un usuario invitado y su contraparte para la comparticin. Cuando el botn de envo se presiona, el servidor SNS en va el contenido seleccionado e informacin de la VPN a la pgina SNS del usuario invitado, cuando el usuario invitado selecciona el contenido compartido y presiona el botn de envo, el servidor SNS enva la lista de contenido seleccionada e informacin de la VPN hacia DAS2 en la red domstica del usuario invitado, a DAS2. El proxy DLNA en DAS2 obtiene la lista de contenido seleccionado desde el SNS. Usando esta lista, el proxy DLNA en DAS2 establece una DMS virtual en s mismo. Sin embargo las URLs de la lista tienen direccin de la subred domstica del anfitrin. El proxy DLNA entonces cambia en DAS2 la URL de contenido para ser compatible con dicha subred. Entonces el DMS virtual enva en broadcast notificaciones de ID de acuerdo a las guas de DLNA, dicha notificacin informa a DMP existentes que un nuevo DMS se ha aadido y est disponible para acceso. El servidor VPN en DAS1 tiene informacin de VPN para acceder a este servidor desde un cliente remoto de VPN. Cuando DAS1 se une a la red el servidor VPN en Das1 enva informacin de VPN a la pgina de usuarios SNS del usuario anfitrin. La informacin de VPN consiste en una llave VPN y una direccin IP global de DAS1, el cliente en DAS2 obtiene la informacin de VPN desde el servidor SNS y establece la VPN con este servidor. La puerta de enlace del anfitrin reenva esta informacin a DAS1 quien por su servidor VPN verifica la llave y establece la VPN con DAS2. Por esto Das1 y Das2 tienen una IP adicional de VPN como tambin su respectiva IP de red local. El usuario invitado accede a un DMS virtual en DAS2 por medio de DMP, el cual tiene CDS que consiste en una lista de contenidos DMS. DMP enva una peticin HTTP a la IP local de DAS2 (ejemplo la 10.10.20.2) basado en la URL de la lista, se usa el proxy reverso para reenviar dicha peticin a la direccin IP de VPN (ejemplo la 10.8.0.1) en DAS1. Para el propsito se usa un proxy reverso, para direccionar trfico DLNA de un DAS a otro, cuando DAS2 obtiene una peticin de reproduccin desde el DMP del usuario invitado, el proxy reverso en DAS2 lo transfiere a DAS1 y al ser esto direccionado a la IP local (ejemplo 10.10.10.3) el DMS recibe la peticin de reproduccin desde DMP. Sin embargo el DMS reconoce la peticin de reproduccin desde DAS1 y enva a la IP local de DAS1 (ejemplo la 10.10.10.2) el proxy reverso en DAS1 reenva el flujo de contenido a la direccin IP de VPN en DAS2 (por ejemplo 10.8.0.2) 4.2 Sistema TIARA Como se muestra en las anteriores secciones un servicio en la sociedad de comunicaciones universales consiste de diferentes tecnologas por debajo. Es entonces ms complicado encontrar el motivo de fallas. Es ms factible que la fuente del problema exista dentro de los ambientes de

redes de usuarios domsticas. El sistema TIARA provee informacin de gestin al usar herramientas de Realidad Aumentada. Los usuarios pueden usar su porttil para ver la informacin sobre el equipo de red real. Toda la informacin de gestin de red se provee desde una interfaz de trabajo Tambourine.

FIGURA 6 Imagen sobrepuesta

FIGURA 7 Arquitectura del Sistema Como se muestra en la figura 7 Tiara se compone de un PC, un servidor y dispositivos a monitorear. Un cdigo 2D se aade a los dispositivos. La identificacin nica como el URI se imprime en cdigo 2D. El terminal de usuario decodifica el 2D y obtiene un URI de dispositivo para el servidor TIARA. Cuando el cliente accede a este servidor, gestin en tiempo real se retorna en formato XML. Este mensaje XML incluye informacin de gestin y datos descriptivos como color, forma y tamao de mensaje. Esta informacin se sintetiza por parte del cliente encima de la imagen capturada. La arquitectura del sistema TIARA es escalable y fcilmente extensible. Aunque pareciese un cuello de botella , el rol de este servidor comprende extraer la informacin pura de gestin a un formato XML de descripcin. Por tanto se pueden preparar mltiples servidores TIARA con fines de offloading utilizando tcnicas tradicionales de escala horizontal que a su vez se utilizan en los servicios web. Adems, como se identifica cada dispositivo de red mediante el uso de cdigos 2D,

el mecanismo de descubrimiento del servidor TIARA puede ser eliminado. El prototipo de aplicacin actual en el lado del cliente se ha llevado a cabo en la parte superior de la plataforma basada en Linux y tambin fcilmente puede ser portada hacia una plataforma de ejecucin de telfonos mviles. 5. Conclusiones En este paper, se presenta un arquitectura de gestin de red interdominios y escalable orientada a una comunicacin universal. Como prueba de este concepto se implementa el framework de Tambourine que define un servicio web de tipo RESTful basado en una API de gestin de red. Tambourine permite a las aplicaciones acceder a informacin de gestin y control de dispositivos interconectados entre dominios distintos. Dos aplicaciones que explotan este tipo de arquitectura se exponen, como son DAS que permiten comparticin de contenidos interconectando redes domsticas. La configuracin de VPN entre ambientes domsticos y su negociacin automtica por medio de servicios web SNS. Y por ltimo TIARA que superpone informacin de gestin de red en objetos del mundo real usando la tecnologia reciente AR. 6. Referencias REFERENCES [1] RFC3584 : Coexistence between Version 1, Version 2, and Version 3 of the Internet standard Network Management Framework, http://www.ietf.org/rfc/rfc3584.txt. [2] R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures, University of California, Irvine, 2000 [3] NETCONF, http://www.ops.ietf.org/netconf/ [4] Digital Living Network Alliance: DLNA Networked Device Interoperability Guidelines Expanded, http://www.dlna.org/ [5] Ahmad Kamil Abdul Hamid, Yoshihiro Kawahara, Tohru Asami, Performance Analysis of RESTbased Active Proxy in Network Management, Workshop of Internet Technology, Furano, Hokkaido, June 2009. [6] T. Y. Song, Y. Kawahara, and T. Asami: Using SNS as Access Control Mechanism for DLNA Content Sharing System In Proceedings of CCNC 2009, Las Vegas, Nevada, USA, Jan. 2009. (Demo) [7] K. Wada, Y. Kawahara, and T. Asami: A Design of XML Schema for Information Presentation System using Augmented Reality in New Generation Network Management,