DIFUSIÓN MASIVA DE INFORMACIÓN EN LOS MODELOS DE … · difusiÓn masiva de informaciÓn en los modelos de gestiÓn de redes aplicaciÓn a los servicios de alta disponibilidad sobre

DIFUSIÓN MASIVA DE INFORMACIÓN EN LOS MODELOS DE GESTIÓN DE REDES

APLICACIÓN A LOS SERVICIOS DE ALTA DISPONIBILIDAD SOBRE INTERNET

Diego Marcos Jorquera

www.ua.es

www.eltallerdigital.com

TESIS DOCTORAL

DIFUSIÓN MASIVA DE INFORMACIÓN

EN LOS MODELOS DE GESTIÓN DE REDES

APLICACIÓN A LOS SERVICIOS DE ALTA DISPONIBILIDAD SOBRE INTERNET

UNIVERSIDAD DE ALICANTE

TESIS DOCTORAL

DIFUSIÓN MASIVA DE

INFORMACIÓN EN LOS

MODELOS DE GESTIÓN DE REDES

APLICACIÓN A LOS SERVICIOS DE ALTA

DISPONIBILIDAD SOBRE INTERNET

Presentada por

DIEGO MARCOS JORQUERA

Dirigida por

DR. FRANCISCO MACIÁ PÉREZ

DEPARTAMENTO DE TECNOLOGÍA INFORMÁTICA Y COMPUTACIÓN

MAYO 2010

Para Alicia.

Gracias por ayudarme a cruzar al otro lado del espejo.

"Si supiese qué es lo que estoy haciendo, no lo llamaría investigación, ¿verdad?"

Albert Einstein.

ix

xi

Resumen

En la presente tesis se propone un modelo de gestión de redes que incorpora en su definición la gestión y difusión masiva de la información sobre redes no propietarias como Internet. Este modelo viene a solucionar uno de los problemas más comunes para cualquier aplicación, tanto de gestión como de usuario, proporcionando un mecanismo sencillo, intuitivo y normalizado para transferir grandes volúmenes de información, con independencia de su localización o los protocolos de acceso.

Algunas de las características más notables del modelo se pueden sintetizar en las siguientes ideas.

La creación de herramientas siguiendo el modelo permite que los desarrolladores de aplicaciones puedan centrarse en la lógica de la aplicación, en lugar de tener que resolver, generalmente a medida, el problema de la transferencia de grandes volúmenes de información.

El modelo se ha concebido para ser compatible con los estándares existentes, tomando como base el marco de trabajo definido por ISO/IEC para sistemas OSI.

Para que la difusión de la información se realice de forma escalable y con el menor impacto posible sobre la red de comunicaciones se ha propuesto un método de difusión fundamentando en técnicas colaborativas y de multicast.

Las principales áreas de aplicaciones del modelo se encuentran en: los sistemas de gestión como las copias de seguridad en red, sistemas para la continuidad en el negocio y alta disponibilidad o los sistemas de mantenimiento de redes de computadoras; aplicaciones de usuario como las aplicaciones eBusiness, sistemas de compartición de archivos o sistemas multimedia; y, en general, cualquier tipo de aplicación que conlleve la

xii Difusión Masiva de Información en los Modelos de Gestión

transferencia de importantes volúmenes de información a través de redes de área amplia como Internet.

Los principales resultados de la investigación son: un modelo de gestión de redes, un mecanismo de difusión de la información concretado en un protocolo de transporte y otro de usuario y una librería que implementa los protocolos propuestos.

Para validar la propuesta se ha construido un escenario de pruebas real y se ha implementado el prototipo de un sistema de recuperación integral de nodos basado en el modelo y utilizando las librerías creadas.

Las pruebas de escalabilidad, carga y tiempos de transferencia realizados sobre el prototipo han permitido verificar la validez e idoneidad de la propuesta comprobando que su aplicación es escalable respecto del tamaño del sistema gestionado, sencillo de implantar y compatible con los sistemas existentes.

xiii

Resum

En la present tesi es proposa un model de gestió de xarxes que incorpora en la seva definició la gestió i difusió massiva de la informació sobre xarxes no propietàries com a Internet. Aquest model ve a solucionar un dels problemes més comuns per a qualsevol aplicació, tant de gestió com d'usuari, proporcionant un mecanisme senzill, intuïtiu i normalitzat per transferir grans volums d'informació, amb independència de la seva localització o els protocols d'accés.

Algunes de les característiques més notables del model es poden sintetitzar en les següents idees.

La creació d'eines seguint el model permet que els desenvolupadors d'aplicacions puguin centrar-se en la lògica de l'aplicació, en lloc d'haver de resoldre, generalment a mesura, el problema de la transferència de grans volums d'informació.

El model s'ha concebut per ser compatible amb els estàndards existents, prenent com a base el marc de treball definit per ISO/IEC per a sistemes OSI.

Perquè la difusió de la informació es realitzi de forma escalable i amb el menor impacte possible sobre la xarxa de comunicacions s'ha proposat un mètode de difusió fonamentant en tècniques col·laboratives i de multicast.

Les principals àrees d'aplicacions del model es troben en: els sistemes de gestió com les còpies de seguretat en xarxa, sistemes per a la continuïtat en el negoci i alta disponibilitat o els sistemes de manteniment de xarxes de computadores; aplicacions d'usuari com les aplicacions eBusiness, sistemes de compartició d'arxius o sistemes multimèdia; i, en general, qualsevol tipus d'aplicació que comporti la transferència d'importants volums d'informació a través de xarxes d'àrea àmplia com a Internet.

xiv Difusión Masiva de Información en los Modelos de Gestión

Els principals resultats de la investigació són: un model de gestió de xarxes, un mecanisme de difusió de la informació concretat en un protocol de transport i un altre d'usuari i una llibreria que implementa els protocols proposats.

Per validar la proposta s'ha construït un escenari de proves real i s'ha implementat el prototip d'un sistema de recuperació integral de nodes basat en el model i utilitzant les llibreries creades.

Les proves de escalabilitat, càrrega i temps de transferència realitzats sobre el prototip han permès verificar la validesa i idoneïtat de la proposta comprovant que la seva aplicació és escalable respecte de la grandària del sistema gestionat, senzill d'implantar i compatible amb els sistemes existents.

xv

Abstract

In this thesis a network management model is proposed that include in its definition the management and mass diffusion of information on non-proprietary networks like Internet. The aim of this model is to solve one of the most common problems for any application, both management and user, providing a simple mechanism, intuitive and normalized in order to transfer large volumes of information, independently of its location or access protocols.

Some of the main features of the model can be synthesized in the following ideas.

The creation of tools based on the proposed model allows that application developers can focus on their efforts on the application logic, instead of having to solve the problem of the transfer of large volumes of information, generally by means of ad-hoc solutions.

The model has been created with the aim of be compatible with existents standards, taking as base the framework defined by ISO/IEC for OSI systems.

A diffusion method based on collaborative and multicast techniques has been proposed achieving the diffusion of information is made on a scalable way and the least possible impact on communication network.

The main application fields of the proposed model are located in: management systems such as network backups, business continuity and high availability systems or computer network maintenance systems; user applications such as e-Business applications, file sharing systems or multimedia systems; and, in general, any type of application that involve transferring of large volumes of information through wide area networks like Internet.

xvi Difusión Masiva de Información en los Modelos de Gestión

The main results of the research are: a model of network management, a mechanism of diffusion of information materialized through a transport protocol, a user protocol and a library that implements the proposed protocols.

In order to validate the proposal has been built a real test scenario and has been implemented a prototype of an integral recovery system of nodes based on the model and using the libraries created.

The scalability, load and transfer time testing achieved on the prototype have allowed verifying the validity and the suitability of the proposal checking that its implementation is scalable in respect of the size of the managed system, easy to implement and compatible with existing systems.

xvii

Resumen del Contenido

INTRODUCCIÓN 1

ANTECEDENTES Y ESTADO DEL ARTE 17

MODELO DE GESTIÓN DE REDES 49

ARQUITECTURA DEL SISTEMA 95

MECANISMO DE DIFUSIÓN MASIVA DE INFORMACIÓN 129

IMPLEMENTACIÓN Y VALIDACIÓN 207

CONCLUSIONES 224

REFERENCIAS BIBLIOGRÁFICAS 229

xix

Contenido

INTRODUCCIÓN 1

PROBLEMA, HIPÓTESIS Y PROPUESTA DE SOLUCIÓN 10

OBJETIVOS, METODOLOGÍA Y PLAN DE TRABAJO 12

ANTECEDENTES Y ESTADO DEL ARTE 17

GESTIÓN DE REDES 17

Estándares 18 Tecnologías y Protocolos 20

TRANSMISIÓN DE LA INFORMACIÓN 23

Difusión de información 23 Sistemas Colaborativos 45 Streaming de archivos 46

CONCLUSIONES 46

MODELO DE GESTIÓN DE REDES 49

MODELO DE ORGANIZACIÓN 52

Entorno de Gestión 53 Entidades 55 Protocolos 61

MODELO DE INFORMACIÓN 63

Objetos de Gestión 64 Base de Información de Gestión 65 Estructura de la Información de Gestión 66 Descubrimiento 69 Modelo de Distribución de la Información 74

xx Difusión Masiva de Información en los Modelos de Gestión

Información 83

MODELO DE COMUNICACIÓN 84

Protocolo de Gestión 85 Protocolo de Gestión SNMP 86

MODELO FUNCIONAL 90

Gestión de Fallos 90 Gestión de la Configuración 91 Gestión de Cuentas 92 Gestión del Rendimiento 92 Gestión de la Seguridad 93

ARQUITECTURA DEL SISTEMA 95

MIDDLEWARE DEL SISTEMA DE GESTIÓN 98

Área de Gestión 99 Área de Transferencia 113

AGENTES 118

Agentes de Utilería 118 Agentes Especializados 126

MECANISMO DE DIFUSIÓN MASIVA DE INFORMACIÓN 129

PROTOCOLO DE TRANSPORTE MDCTP 132

Descripción General 133 Paquetes MDCTP 144 Operaciones 150 Fase de Conexión 165 Fase de Transferencia 178 Fase de Cierre 201

SIMPLE DATA TRANSFER PROTOCOL 202

Comandos SDTP 203

IMPLEMENTACIÓN Y VALIDACIÓN 207

IMPLEMENTACIÓN DEL PROTOTIPO 207

VALIDACIÓN 209

Contenido xxi

Escenarios de Pruebas 211

PRUEBAS Y EXPERIMENTOS 213

CONCLUSIONES 224

APORTACIONES 225

Publicaciones 226

PROBLEMAS ABIERTOS 227

LÍNEAS FUTURAS 228

REFERENCIAS BIBLIOGRÁFICAS 229

xxiii

Figuras

FIGURA 1. EVOLUCIÓN DEL EQUIPAMIENTO TIC EN LAS VIVIENDAS. AÑOS 2004-2008. ESPAÑA. ................................................................................................... 1

FIGURA 2. ENCUESTA SOBRE EL USO DE TIC Y COMERCIO ELECTRÓNICO EN LAS EMPRESAS. AÑOS

2003-2008. ESPAÑA.................................................................................. 2 FIGURA 3. SISTEMA DE GESTIÓN DE REDES (NSM). ..................................................... 3 FIGURA 4. ELEMENTOS SUSCEPTIBLES DE SER GESTIONADOS............................................ 4 FIGURA 5. COMPONENTES DEL MODELO DE GESTIÓN OSI. ............................................. 6 FIGURA 6. ARQUITECTURA DE SNMP. ...................................................................... 7 FIGURA 7. ESTIMACIÓN DEL TRÁFICO GLOBAL EN INTERNET 2008-2013. .......................... 8 FIGURA 8. DIFUSIÓN DE LA INFORMACIÓN NO INTEGRADA EN EL SISTEMA DE GESTIÓN. ........ 11 FIGURA 9. SISTEMA DE GESTIÓN INCORPORANDO LA DIFUSIÓN DE LA INFORMACIÓN. .......... 12 FIGURA 10. EVOLUCIÓN DE SNMP. ....................................................................... 22 FIGURA 11. COMPARATIVA DEL ENVÍO DE UN MISMO PAQUETE A VARIOS RECEPTORES USANDO

TÉCNICAS DE UNICAST, BROADCAST Y MULTICAST............................................... 25 FIGURA 12. ESQUEMA DE RETRANSMISIÓN POR PAQUETE PERDIDO BASADO EN ACK’S. ...... 29 FIGURA 13. ENVÍO DE NACK POR FINALIZACIÓN DEL TIEMPO DE ESPERA. ......................... 32 FIGURA 14. REDUCCIÓN DEL TRÁFICO DE CONTROL EN LOS ROUTERS. .............................. 39 FIGURA 15. SUB-MODELOS DEL MODELO DE GESTIÓN DE REDES..................................... 50 FIGURA 16. DIAGRAMA DE AGREGACIÓN DEL MODELO DE GESTIÓN. ............................... 51 FIGURA 17. PROCESO DE CREACIÓN DEL MODELO DE GESTIÓN. .................................... 52 FIGURA 18. DIAGRAMA DE AGREGACIÓN DEL MODELO DE ORGANIZACIÓN....................... 53

xxiv Difusión Masiva de Información en los Modelos de Gestión

FIGURA 19. DIAGRAMA DE HERENCIA DEL MODELO DE ORGANIZACIÓN. .......................... 54 FIGURA 20. DIAGRAMA DE RELACIÓN DE LA RED DE COMPUTADORES. ............................. 55 FIGURA 21. RELACIÓN ENTRE ENTIDADES DE CONTROL Y DE GESTIÓN. ............................. 57 FIGURA 22. ACCESO A LA INFORMACIÓN EN UN SISTEMA DE GESTIÓN TRADICIONAL. ........... 58 FIGURA 23. ACCESO A LA INFORMACIÓN CON LA INTEGRACIÓN DE LA INFORMACIÓN EN EL

SISTEMA DE GESTIÓN. ................................................................................ 60 FIGURA 24. ENTIDAD DE REGISTRO. ....................................................................... 61 FIGURA 25. DIAGRAMA DE CLASES DE LAS ENTIDADES DEL SISTEMA. ............................... 61 FIGURA 26. ESQUEMA GENERAL DEL MODELO DE ORGANIZACIÓN. ................................ 63 FIGURA 27. BASE DE INFORMACIÓN DE GESTIÓN. ...................................................... 64 FIGURA 28. MIB DE LAS ENTIDADES DEL SISTEMA DE GESTIÓN. ..................................... 65 FIGURA 29. ESQUEMA GENERAL DEL MIB DE SNMP.................................................. 67 FIGURA 30. ESQUEMA GENERAL DEL MIB-II DE SNMP. ............................................. 68 FIGURA 31. DEFINICIÓN DE LA CLASE ENTITY. ........................................................... 70 FIGURA 32. DEFINICIÓN DE LA CASE ENTITYSET. ........................................................ 71 FIGURA 33. DEFINICIÓN DE LA CLASE INFORMATION. .................................................. 72 FIGURA 34. DEFINICIÓN DE LA CLASE INFORMATIONSET. ............................................. 73 FIGURA 35. RELACIÓN ENTRE LAS DISTINTAS CLASES DEL REGISTRO. ................................ 75 FIGURA 36. ESQUEMA DE LA RELACIÓN ENTRE ENTIDADES, INFORMACIÓN Y CATEGORÍAS. .... 75 FIGURA 37. PROCESO DE CREACIÓN DEL MIB-REGISTRY. ............................................. 76 FIGURA 38. ESQUEMA GENERAL DEL MIB-DISCOVERY. ............................................... 77 FIGURA 39. RAMA ENTITY DEL SUBÁRBOL REGISTRY. ................................................... 78 FIGURA 40. RAMA INFORMATION DEL SUBÁRBOL REGISTRY. ......................................... 81 FIGURA 41. PROCESO DE CREACIÓN DEL MIB-INFORMATION. ....................................... 83 FIGURA 42. RAMA INFORMATION. ......................................................................... 84 FIGURA 43. PASO DE MENSAJES ENTRE ENTIDADES. .................................................... 85 FIGURA 44. PASO DE MENSAJES CON CONFIABILIDAD. ................................................. 86 FIGURA 45. CODIFICACIÓN DE UN CAMPO EN SNMP. ................................................. 88 FIGURA 46. CODIFICACIÓN DE UN CAMPO COMPLEJO EN SNMP. .................................. 88 FIGURA 47. ÁREAS DEL MODELO FUNCIONAL ............................................................ 90 FIGURA 48. FASES DE LA GESTIÓN DE FALLOS. ........................................................... 91 FIGURA 49. ESQUEMA DE USO DE UN MIDDLEWARE. .................................................. 96 FIGURA 50. USO DE CONTENEDORES. ..................................................................... 97 FIGURA 51. ARQUITECTURA DE UNA ENTIDAD. .......................................................... 98 FIGURA 52. MIDDLEWARE DEL SISTEMA DE GESTIÓN................................................... 99 FIGURA 53. MOTOR SNMP. ...............................................................................100 FIGURA 54. SUBSISTEMA DE TRANSPORTE DEL MOTOR SNMP. ...................................100 FIGURA 55. DIAGRAMA DE ACTIVIDAD DEL MÉTODO RECIBIRMENSAJE. ..........................101 FIGURA 56. DISTRIBUIDOR DEL MOTOR SNMP........................................................102 FIGURA 57. SUBSISTEMA DE PROCESADO DE MENSAJES DEL MOTOR SNMP. ..................104 FIGURA 58. SUBSISTEMA DE SEGURIDAD DEL MOTOR SNMP. .....................................105

Figuras xxv

FIGURA 59. SUBSISTEMA DE CONTROL DE ACCESO DEL MOTOR SNMP. .........................106 FIGURA 60. SERVICIOS SNMP. ............................................................................107 FIGURA 61. GENERADOR Y RESPONDEDOR DE COMANDOS. .........................................108 FIGURA 62. RELACIÓN ENTRE EL GENERADOR Y EL RESPONDEDOR DE COMANDOS. ...........108 FIGURA 63. ESQUEMA DE LA SOLICITUD Y RESPUESTA DE UN COMANDO. ........................109 FIGURA 64. ESQUEMA DE LA RECEPCIÓN Y RESPUESTA DE UN COMANDO. .......................110 FIGURA 65. GENERADOR Y RECEPTOR DE NOTIFICACIONES. .........................................111 FIGURA 66. ESQUEMA DE ENVÍO Y RECEPCIÓN DE UNA NOTIFICCION. .............................111 FIGURA 67. SERVICIO PROXY. ..............................................................................112 FIGURA 68. MOTOR DE TRANSFERENCIA. ...............................................................113 FIGURA 69. SERVICIOS DE TRANSFERENCIA MASIVA. .................................................115 FIGURA 70. STREAMING DE DATOS UTILIZANDO PROTOCOLOS CLIENTE. ..........................116 FIGURA 71. STREAMING DE DATOS UTILIZANDO PROTOCOLOS P2P................................117 FIGURA 72. ALMACENAMIENTO DE DATOS. .............................................................117 FIGURA 73. AGENTES DEL SISTEMA DE GESTIÓN. .......................................................118 FIGURA 74. ESQUEMA DE LA BASE DE DATOS DE REGISTRO. .........................................122 FIGURA 75. SISTEMA P2P. .................................................................................131 FIGURA 76. PILA DE PROTOCOLOS .........................................................................133 FIGURA 77. SÍMBOLOS REPRESENTANDO LOS TIPOS DE NODOS. ....................................135 FIGURA 78. FASES DE UNA SESIÓN DE TRANSFERENCIA. ..............................................136 FIGURA 79. TIPOS DE COMUNICACIÓN ENTRE NODOS. ................................................137 FIGURA 80. ZONA DE NODOS. ..............................................................................138 FIGURA 81. ESQUEMA DE FUNCIONAMIENTO DE UN PROTOCOLO ORIENTADO A CONEXIÓN. .140 FIGURA 82. ESQUEMA DE FUNCIONAMIENTO DE MDCTP. ..........................................141 FIGURA 83. BOSQUE DE ZONAS. ...........................................................................143 FIGURA 84. ENCAPSULAMIENTO DE LOS PAQUETES MDCTP. ......................................144 FIGURA 85. CABECERA MDCTP. ..........................................................................145 FIGURA 86. PETICIÓN Y RESPUESTA DE UN COMANDO. ...............................................151 FIGURA 87. CONFIABILIDAD PARA SOLICITUDES POR DIFUSIÓN......................................152 FIGURA 88. ENVÍO DE SOLICITUDES A ZONAS EXTERNAS. .............................................153 FIGURA 89. BLOQUE DE DEFINICIÓN DE ZONA. .........................................................154 FIGURA 90. BLOQUE DE DEFINICIÓN DE NODO..........................................................154 FIGURA 91. CUERPO DE LA OPERACIÓN PEER. .........................................................155 FIGURA 92. CUERPO DE LA SOLICITUD DE LA OPERACIÓN DEL. .....................................158 FIGURA 93. CUERPO DE LA SOLICITUD INFO. ...........................................................159 FIGURA 94. CUERPO DE LA RESPUESTA DE LA OPERACIÓN PING. ..................................160 FIGURA 95. ESQUEMA DE FUNCIONAMIENTO DE LA OPERACIÓN PING. .........................161 FIGURA 96. CUERPO DE LA SOLICITUD DE LA OPERACIÓN DPING. .................................161 FIGURA 97. CUERPO DE LA RESPUESTA DE LA OPERACIÓN DPING. ................................162 FIGURA 98. CUERPO DE LA OPERACIÓN DATA. ........................................................162 FIGURA 99. CUERPO DEL MENSAJE ACK EN PAQUETES INTRA-ZONA. .............................164

xxvi Difusión Masiva de Información en los Modelos de Gestión

FIGURA 100. ESCENARIO DEL EMISOR AL INICIAR. .....................................................167 FIGURA 101. PROCESO DE INCORPORACIÓN DE UN NODO A LA SESIÓN. ..........................169 FIGURA 102. ESCENARIO TRAS LA INCORPORACIÓN DE VARIOS NODOS. ..........................169 FIGURA 103. CREACIÓN DE UNA ZONA NUEVA. ........................................................170 FIGURA 104. INCLUSIÓN EN UNA ZONA EXISTENTE. ...................................................171 FIGURA 105. INCORPORACIÓN DE UN NODO DE SOPORTE. ..........................................173 FIGURA 106. TABLA DE DISTANCIAS ENTRE ZONAS.....................................................175 FIGURA 107. TABLA DE DISTANCIAS ENTRE ZONAS RESUMIDA. .....................................175 FIGURA 108. CREACIÓN DE UNA ÁRBOL DE ZONAS. ...................................................176 FIGURA 109. ESQUEMA DE USO DEL BUFFER DE TRANSFERENCIA. ..................................180 FIGURA 110. EJEMPLO DE BUFFER DE TRANSFERENCIA. ..............................................180 FIGURA 111. ESTRUCTURA DEL BUFFER DE TRANSFERENCIA. ........................................182 FIGURA 112. INFORMACIÓN SOBRE VECINOS. ..........................................................184 FIGURA 113. VENTANAS ESTIMADAS DE VECINO. ......................................................184 FIGURA 114. CÁLCULO DE LAS VENTANAS DE ZONA. ..................................................185 FIGURA 115. FLUJOS DE DATOS Y CONFIRMACIONES EN EL ÁRBOL DE ZONAS. ...................187 FIGURA 116. DIFUSIÓN DE UN BLOQUE DE DATOS POR PARTE DEL EMISOR. .....................189 FIGURA 117. ESCENARIO DE RECEPCIÓN DE DATOS EXTERNOS. .....................................191 FIGURA 118. DIFUSIÓN DE LOS DATOS. ..................................................................191 FIGURA 119. RETRANSMISIÓN DE DATOS. ...............................................................192 FIGURA 120. CONFIRMACIÓN DE RECEPCIÓN DE DATOS. .............................................193 FIGURA 121. DIFUSIÓN DE UN PAQUETE ACK. .........................................................194 FIGURA 122. USO DE LA PRIMITIVA XOR PARA EL CÁLCULO DE BLOQUES DE RECUPERACIÓN.

...........................................................................................................198 FIGURA 123. BLOQUES DE RECUPERACIÓN. .............................................................199 FIGURA 124. DISTRIBUCIÓN DE LOS BLOQUES DE RECUPERACIÓN VERTICAL. ....................200 FIGURA 125. PILA DE PROTOCOLOS PARA SDTP. ......................................................202 FIGURA 126. DIAGRAMA DE SECUENCIA DEL ESQUEMA GENERAL DE SDTP......................203 FIGURA 127. EJECUCIÓN DE LA AYUDA DEL COMANDO SDTPD. .....................................209 FIGURA 128. ESCENARIO DE DESARROLLO DEL SISTEMA DE REGENERACIÓN DE NODOS. .....210 FIGURA 129. ESCENARIO DE PRUEBAS. ...................................................................212 FIGURA 130. LABORATORIOS DE LA ESCUELA POLITÉCNICA SUPERIOR. ...........................213 FIGURA 131. DISTRIBUCIÓN DE LOS NODOS EN LAS PRUEBAS DE MDCTP. ......................214 FIGURA 132. TRAFICO TOTAL ENVIADO POR EL EMISOR. .............................................214 FIGURA 133. TRÁFICO TOTAL ENVIADO POR EL EMISOR. DETALLE ENTRE 1 Y 2 GB. ...........215 FIGURA 134. TRÁFICO MEDIO ENVIADO POR EL EMISOR POR CADA NODO RECEPTOR. .........216 FIGURA 135. TRÁFICO RECIBIDO POR EL EMISOR. ......................................................216 FIGURA 136. TRÁFICO MEDIO ENVIADO POR CADA NODO RECEPTOR. .............................217 FIGURA 137. TRÁFICO MEDIO RECIBIDO POR CADA NODO RECEPTOR. .............................218 FIGURA 138. TRÁFICO TOTAL ENVIADO POR TODOS LOS NODOS. ...................................218 FIGURA 139. TRÁFICO TOTAL RECIBIDO POR TODOS LOS NODOS. ..................................219

Figuras xxvii

FIGURA 140. TRÁFICO MEDIO ENVIADO POR CADA NODO. ..........................................219 FIGURA 141. TRÁFICO MEDIO RECIBIDO POR CADA NODO. ..........................................220 FIGURA 142. TIEMPO MEDIO DE TRANSFERENCIA......................................................220 FIGURA 143. EVOLUCIÓN DE LAS VENTANAS DE TRANSFERENCIA. ..................................221 FIGURA 144. TRÁFICO TRANSFERIDO. ....................................................................222

xxix

Tablas

TABLA 1. TIPOS DE APLICACIONES MULTICAST. .......................................................... 26 TABLA 2. DISTRIBUCIÓN DE DIRECCIONES IP. ............................................................ 27 TABLA 3. CARACTERÍSTICAS DE LOS SISTEMAS DEL DIFUSIÓN DE INFORMACIÓN. ................. 48 TABLA 4. ROLES DE LAS ENTIDADES EN FUNCIÓN DEL PROTOCOLO. ................................. 62 TABLA 5. TIPOS DE DATOS EN SNMP...................................................................... 68 TABLA 6. DEFINICIÓN DE LOS CAMPO DE UNA ENTIDAD EN EL REGISTRO. .......................... 70 TABLA 7. DEFINICIÓN DE LOS CAMPOS DE UN PAQUETE DE INFORMACIÓN EN EL REGISTRO. ... 72 TABLA 8. OPERACIONES DE GESTIÓN DE ENTIDADES. ................................................... 79 TABLA 9. CÓDIGOS DE RESULTADO DE LAS OPERACIONES SOBRE ENTIDADES. ..................... 80 TABLA 10. OPERACIONES DE GESTIÓN DE INFORMACIÓN.............................................. 82 TABLA 11. CAMPOS DE LA CABECERA SNMP. ........................................................... 87 TABLA 12. MENSAJES DE SNMP. .......................................................................... 89 TABLA 13. OPERACIONES DE SNMP. ..................................................................... 89 TABLA 14. API DEL SUBSISTEMA DE TRANSPORTE. ....................................................101 TABLA 15. API DEL DISTRIBUIDOR. .......................................................................103 TABLA 16. API DEL SUBSISTEMA DE PROCESADO DE MENSAJES. ...................................104 TABLA 17. API DEL SUBSISTEMA DE SEGURIDAD. ......................................................105 TABLA 18. API DEL SUBSISTEMA DE SEGURIDAD. ......................................................106 TABLA 19. API DEL GENERADOR DE COMANDOS. .....................................................109 TABLA 20. API DEL RESPONDEDOR DE COMANDOS. ..................................................110 TABLA 21. API DEL GENERADOR DE NOTIFICACIONES. ...............................................112 TABLA 22. API DEL RECEPTOR DE NOTIFICACIONES. ..................................................112 TABLA 23. API DEL SUBSISTEMA DE ALMACENAMIENTO. ............................................114 TABLA 24. API DEL AGENTE DE PUBLICACIÓN. .........................................................120 TABLA 25. API DEL AGENTE DE DESCUBRIMIENTO. ...................................................121 TABLA 26. REGISTRO DE ENTIDADES. .....................................................................123 TABLA 27. REGISTRO DE INFORMACIÓN. .................................................................123 TABLA 28. REGISTRO DE RELACIÓN ENTIDAD-INFORMACIÓN. .......................................124 TABLA 29. REGISTRO DE RELACIÓN INFORMACIÓN-DESCRIPCIÓN. ..................................124 TABLA 30. REGISTRO DE RELACIÓN INFORMACIÓN-CATEGORÍA. ....................................125 TABLA 31. REGISTRO DE RELACIÓN ENTIDAD-CATEGORÍA. ...........................................125 TABLA 32. API DEL AGENTE DE TRANSFERENCIA. ......................................................126 TABLA 33. TIPOS DE NODOS Y FUNCIONALIDADES. ....................................................134 TABLA 34. PRINCIPALES MÉTODOS DEL API DE SOCKETS. ............................................139

xxx Difusión Masiva de Información en los Modelos de Gestión

TABLA 35. TIPOS DE ZONAS. ................................................................................142 TABLA 36. FLAGS DE LOS PAQUETES MDCTP. .........................................................146 TABLA 37. TIPOS DE NODOS. ...............................................................................147 TABLA 38. OPERACIONES DE MDCTP. ..................................................................147 TABLA 39. ESTADOS DE LAS OPERACIONES MDCTP. .................................................149 TABLA 40. SIGNIFICADO DE LOS CAMPOS ACK, NEXT Y OUT ..........................................150 TABLA 41. VALORES DE LA SOLICITUD Y RESPUESTA DE LA OPERACIÓN PEER. ...................156 TABLA 42. VALORES DE LA SOLICITUD Y RESPUESTA DE LA OPERACIÓN ZONE. ..................157 TABLA 43. OPCIONES DE CONEXIÓN. .....................................................................166 TABLA 44. COMANDO DE SDTP. ..........................................................................204 TABLA 45. RESPUESTAS DEL COMANDO GET EN FUNCIÓN DEL PROTOCOLO. ....................205 TABLA 46. CÓDIGOS DE ERROR DEL COMANDO GET. .................................................205

1

C a p í t u l o 1

Introducción

La comunicación y el uso de redes de computadores, así como su rápida y amplia expansión en la sociedad actual, han revolucionado la forma en la que nos relacionamos, trabajamos o nos divertimos. La aceptación de las nuevas tecnologías es cada vez mayor y su uso se ha incrementado de manera notable en los últimos años. Prueba de ello es la evolución del equipamiento TIC de los hogares españoles y del uso de Internet en los últimos años (INE, 2008) como puede verse en la figura 1.

Figura 1. Evolución del equipamiento TIC en las viviendas. Años 2004-2008. España.

Cada vez son más los servicios electrónicos que se ofertan, tanto en número como en variedad y las tecnologías e infraestructuras

Con conexión de Banda Ancha

Disponen de acceso a Internet

Con algún tipo de ordenador

0

20

40

60

80

20042005

20062007

2008

Po

rce

nta

je d

e v

ivie

nd

as

años

2 Difusión Masiva de Información en los Modelos de Gestión

que hacen posible su uso han tenido que sufrir los efectos de este escalado, adaptándose en la medida de lo posible a las nuevas necesidades y volúmenes de trabajo.

En este sentido cada vez existe un mayor número de dispositivos inteligentes, que incorporan capacidad de computación y comunicación con un grado de heterogeneidad cada vez más patente tanto en el tipo de dispositivos (PC‟s, portátiles, PDA‟s. handhelds, teléfonos móviles, sistemas de entretenimiento para hogar, sistemas domóticos, auto-radios, etc.) como en los sistemas de comunicación que permiten su acceso a redes corporativas o a Internet.

En la actualidad esta expansión de las tecnologías de la información en todos los ámbitos (socio-cultural, científico, tecnológico, etc.) ha derivado en una alta dependencia de los usuarios y organizaciones hacia los sistemas informáticos que utilizan. La informática e Internet han pasado de ser meras herramientas de soporte para convertirse en el principal medio con el que desarrollar nuestras actividades laborales y personales. Prueba de ello es el incremento de las nuevas tecnologías y el uso del comercio electrónico en las empresas como se puede ver en la figura 2 (INE, 2009).

Figura 2. Encuesta sobre el uso de TIC y comercio electrónico en las

empresas. Años 2003-2008. España.

En este entorno se hace totalmente imprescindible asegurar en todo momento el correcto funcionamiento de todas estas tecnologías tanto en el sentido de asegurar su operatividad (o al menos minimizar el impacto de una caída parcial o total de un sistema) como asegurar unos mínimos en la calidad de los

Empresas que han realizado ventas por comercio electrónicoEmpresas que han realizado compras por comercio …

Empresas que tienen sitio o página web por paísesEmpresas que disponen de Red de Area Local (LAN)

Empresas con acceso a Internet mediante banda anchaEmpresas con conexión a InternetEmpresas que disponen de ordenador

0

20

40

60

80

100

2003 2004 2005 2006 2007 2008

Po

rce

nta

je d

e e

mp

resa

s

Años

Capítulo 1. Introducción 3

servicios prestados, independientemente de las circunstancias puntuales y coyunturales que se puedan presentar. Es en este ámbito donde se hacen patentes conceptos como los de Alta Disponibilidad, Tolerancia a Fallos o Continuidad en el Negocio

(Helms et al., 2006) (Hairong et al., 2003).

La expansión de las redes de computadores tiene asociada un conjunto de problemas tanto en su gestión diaria como con en la planificación de su crecimiento. La introducción de nuevos elementos en la red puede suponer la incorporación de nuevos expertos o el replanteamiento de las estrategias de gestión del sistema que se venían siguiendo. A su vez todos estos cambios deben realizarse sin mermar los niveles de accesibilidad, rendimiento y calidad a los que los usuarios están acostumbrados. Sin embargo estos cambios tienen un coste más allá de la inversión en infraestructuras. Cuanto más transparente es para el usuario el escalado de las redes, más compleja se vuelve la gestión que realizan los administradores que, en la mayoría de los casos, alcanza un nivel de complejidad tan alto que se hace inviable su gestión sin el uso de herramientas automatizadas.

Figura 3. Sistema de Gestión de Redes (NSM).

NSM

Administración

Control

CoordinaciónMonitorización

Seguridad


Para facilitar o asistir las labores de administración surge el concepto de Sistemas de Gestión de Redes (Network Management System – NMS) con el objetivo primordial de asegurar un nivel aceptable en los servicios y sistemas implantados en la red con el mínimo coste temporal, humano y material posible. El concepto de gestión de redes (ver figura 3) aglutina al conjunto de aplicaciones, herramientas, protocolos y sistemas informáticos que ayudan a los administradores a realizar tareas de gestión, monitorización o implantación de dispositivos, servicios, aplicaciones o, en general, cualquier componente informático de una red (Voruganti, 1994).

Si bien en un primer momento los primeros sistemas y estándares para la gestión de redes se responsabilizaba básicamente de la gestión de los elementos de networking (enrutadores, concentradores, servidores,…) cada vez son más los elementos que se gestionan, incorporando tanto las estaciones de trabajo y los dispositivos móviles que se conectan a la red (figura 4), como los servicios y aplicaciones que se ejecutan en éstos.

Figura 4. Elementos susceptibles de ser gestionados.

En la actualidad la gestión y distribución de la información dentro de las redes es uno de los problemas a los que se

Sistemas de Gestión

Redes

Infraestructuras

Protocolos

Servicios

Seguridad

Equipos

Inventario

Sistemas Operativos

Aplicaciones

Configuración

Mantenimiento

Información

Distribución

Replicación

Copias de seguridad


enfrentan los administradores de sistemas. Realizar copias de seguridad, replicas de archivos y bases de datos o gestionar los sistemas NAS son algunos de las múltiples tareas asociadas a la información que en la actualidad deben ser contempladas en la gestión.

En general, con el incremento del número y complejidad de las redes de computadores, las tareas de administración se vuelven también más complejas. Es en estos entornos donde los sistemas de gestión de redes juegan un importante papel, facilitando las labores de los administradores mediante soluciones que permitan o simplifiquen el creciente conjunto de tareas asociadas a la administración. En este sentido los sistemas de mantenimiento intentan paliar esta complejidad aportando soluciones con características de automatización, desatención y proactividad.

Analizando la literatura relacionada con la gestión de redes encontramos dos tipos de enfoques a la hora de plantear estos sistemas. Por una parte tendríamos los sistemas de gestión específicos que aportan una solución parcial a determinados dispositivos o entornos (Alon et al., 2004) (Barba, 2006) y por otra sistemas basados en modelos genéricos que aportan una solución global al problema de la gestión, normalmente propuesto por organizaciones con ánimo de estandarización (IEEE, 2000) (ISO/IEC, 1989).

Los sistemas de gestión específicos están pensados para un único dispositivo, servicio o aplicación o, como mucho, para un conjunto de éstos con características comunes. Estos sistemas suelen dar una solución completa pero no son transportables a otros entornos ya que son muy dependientes de las características intrínsecas del sistema que administran. En muchas ocasiones estos sistemas son aportados por los propios fabricantes y su nivel de integración suele ser alto con otras soluciones de dicho fabricante pero bajo con el resto (Barba, 2006).

En el otro extremo, los modelos de gestión genéricos intentan aportar una solución de carácter global a la administración de sistemas complejos. Estas soluciones suelen ser sistemas que, buscando la generalidad, no recogen todos los requerimientos de los servicios y suelen estar basadas en estándares que facilitan la integración de diferentes sistemas de gestión para lograr una administración integral (Voruganti, 1994).


En la mayoría de los casos los sistemas de gestión están basados en el paradigma Gestor-Agente, donde los gestores son los elementos que interactúan con el administrador y desencadenan las acciones pertinentes para llevar a cabo las tereas solicitadas o planificadas y los agentes, asociados a los elementos a administrar, responsables de llevar a cabo las acciones solicitadas por los gestores (Barba, 2006).

Figura 5. Componentes del modelo de gestión OSI.

La principal organización responsable de los procesos de estandarización es la Organización Internacional para la Estandarización (International Organization for Standardization – ISO). En el ámbito de las redes de computadores su principal propuesta es el Modelo de referencia de Interconexión de Sistemas Abiertos (Open System Interconnection – OSI), propuesto en 1984 junto con la Comisión Electrotécnica Internacional (International Electrotechnical Commission – IEC) y que establece un marco de referencia para la definición de arquitecturas de interconexión de sistemas de comunicaciones (ISO/IEC, 1994). La cuarta parte de este documento (ISO/IEC, 1989) establece un marco de trabajo para la propuesta de sistemas de gestión de redes conocido como el Modelo de gestión de redes OSI/ISO (OSI/ISO Network Management Model). Este modelo está compuesto por cuatro sub-modelos perfectamente diferenciados: un modelo de organización donde se describen los componentes que conforman el sistema (los

Modelo de gestión

OSI

Modelo de Organización

Modelo de información

Modelo de Comunicación

Modelo Funcional


elementos a administrar, el conjunto de gestores y agentes de gestión y la relación entre éstos); un modelo de información que define los datos asociados a la gestión de redes (Management Information Base – MIB) así como su estructura (Structure of Management Information – SMI); un modelo de comunicación que define la forma de comunicarse entre los gestores y los agentes de gestión; y un modelo funcional que establece las tareas a realizar por parte del sistema de gestión (ver figura 5).

El sistema de gestión de redes de carácter general más extendido actualmente es Simple Network Management Protocol (SNMP), sistema pensado originalmente para redes TCP/IP (Case et al., 1990). Si bien el nombre de SNMP hace referencia al protocolo de comunicación utilizado por este sistema, en realidad se trata de un sistema de gestión completo basado en los principios del modelo de gestión de redes OSI, definiéndose además de un modelo de comunicación basado en este protocolo, los modelos de organización, de información y funcional, este último concretado en un conjunto muy reducido de operaciones, de ahí el nombre de „Simple‟. En la actualidad la mayoría de los dispositivos de networking integran algún agente SNMP para su gestión y existen también multitud de implementaciones de agentes y gestores para diversas plataformas software (Mauro & Schmidt, 2005) convirtiendo a SNMP en el sistema de gestión más extendido en la actualidad.

Figura 6. Arquitectura de SNMP.

Estas propuestas han sido ampliamente utilizadas en el pasado y en general han cubierto las necesidades para las que fueron concebidas. Además se ha demostrado que las soluciones genéricas han sido una buena alternativa para la gestión de grandes redes facilitando su escalado y evolución (Barba, 2006).

NMSMIB

DispositivoAdministrado

Agente

Protocolo de

gestión (SNMP)

MIB


AgenteMIB

Red de

comunicaciones


Sin embargo, debido a las necesidades impuestas por los usuarios y fabricantes, las tecnologías y su uso cambian muy rápidamente, de forma que aspectos que antes eran secundarios ahora son genéricos y de primer orden. Si bien estos cambios se reflejan aspectos muy diversos de los sistemas TI, una de las características comunes que se puede observar es el hecho de que los volúmenes de información que son almacenados, transferidos y gestionados por estos sistemas es cada vez mayor. Este incremento ha sido tan rápido que en muchos casos está información es gestionada mediante protocolos y aplicaciones que originariamente no fueron pensados para estos requerimientos. En otros casos, para algunas aplicaciones específicas como el streaming multimedia, el intercambio de archivos en redes P2P, VoIP o eol datamining se están planteando sistemas específicos que aportan una solución concreta a estos problemas.

Según un estudio de la empresa Cisco del año 2009 (Cisco, 2009) se prevé que el tráfico IP mundial se incrementará cinco veces para el año 2013 respecto del 2008, superando los 40 exabytes mensuales (ver figura 7).

Figura 7. Estimación del tráfico global en Internet 2008-2013.

Otra característica relevante de los nuevos servicios electrónicos es que en muchas ocasiones la información es enviada de forma simultánea a más de un destinatario, como es el caso de la distribución de software o la replicación de contenidos

0

10000

20000

30000

40000

50000

60000

2008 2009 2010 2011 2012 2013

PB

/me

s

Año

Trafico Global , Estimación 2008-2013

Internet

Non-Internet IP

Mobile Data

Total


multimedia o de bases de datos. En estos casos los sistemas tradicionales, basados en las comunicaciones punto a punto, producen saturaciones en la red de comunicaciones debido a la necesaria retransmisión de la información por cada destinatario.

En la actualidad los sistemas de gestión tampoco contemplan estos nuevos requerimientos y los administradores tienen que recurrir a sistemas complementarios para realizar labores hoy en día tan usuales como la instalación de software a través de la red.

En el caso concreto de SNMP, éste fue concebido para la transmisión de pequeñas cantidades de información (direcciones IP, nombres de equipos, número de bytes transmitidos por una interfaz, etc.), con el objetivo de que la administración y monitorización de la red no tuviera un gran impacto sobre la propia red administrada. Si bien desde la versión 2 se han incorporado operaciones específicas para la transmisión de información de mayor tamaño, en general tanto el protocolo como el sistema de información no están pensados para la transmisión de información de gran tamaño, especialmente si ésta es transmitida a más de un destinatario (Mauro & Schmidt, 2005).

Los actuales avances en la computación grid y las técnicas de streaming, multicasting y P2P aportan soluciones que permiten realizar aplicaciones que requieren la transmisión de grandes volúmenes de información entre múltiples destinatarios de forma mucho más eficiente y escalable.

La definición de sistemas de gestión de redes con características de autogestión y que contemplen la difusión de información masiva se considera en estos momentos un problema abierto que debe ser resuelto de forma ad hoc. El problema es de carácter técnico y científico, ya que hay determinados aspectos aun sin resolver, y tiene un especial interés socio-económico por la alta dependencia de la sociedad en los sistemas informáticos y los altos niveles de inversión en la gestión de dichos sistemas.

Existe un alto interés en la investigación dentro del ámbito las redes de computadores y su gestión. Prueba de ello es la alta inversión que se realiza en proyectos asociados a estos sistemas. En el año 2007 se invirtió 171 millones de euros en este área dentro del Séptimo Programa Marco de Investigación y Desarrollo (7PM, 2007). También existen diversos comités específicos para la investigación en gestión de redes como el Committee on Network Operation and Management de IEEE y diversos congresos de


ámbito internacional como el IFIP/IEEE International Symposium on Integrated Network Management y publicaciones de relevancia como Journal of Network and Systems Management o IEEE Transactions on Network and Service Management.

El , grupo de investigación de redes y middleware del Departamento de Tecnología Informática y Computación de la Universidad de Alicante, centra gran parte de su actividad en el estudio y realización de sistemas que faciliten la gestión y el mantenimiento de las redes de computadores. En este ámbito, el grupo ha desarrollado un sistema, denominado Gaia, concebido como un sistema de mantenimiento de redes desatendido, y que ha supuesto un gran avance en los sistemas de gestión de redes,

siendo un punto de partida para este trabajo. (Marcos et al.,

2007)

El presente trabajo de investigación se ha desarrollando en el marco de dos proyectos de investigación. Uno, financiado por el Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica 2004-2007, Programa Tecnologías de la Información (TIN) denominado „Phoenix Computing. Modelos de gestión semántica de las TIC‟ (TIN2006-04081), tiene como principal objetivo el estudio de un modelo integral e integrado para la gestión proactiva y la autogestión de sistemas, servicios y aplicaciones en red. Otro, financiado por la Generalitat Valenciana en el marco de las Ayudas para la Realización de Proyectos de I+D+I para Equipos de Investigación Emergentes de Creación Reciente, con título „Dispositivos de red embebidos para la gestión a través de Internet del inicio de nodos de red. Dispositivo WoLI‟ (GV/2007175) tiene como principal objetivo la propuesta de servicios de red autónomos embebidos en dispositivos de red de tamaño reducido.

Problema, Hipótesis y Propuesta de Solución

El ámbito en el que se enmarca la presente investigación es el de la redes de computadores, concretamente en la propuesta de modelos de gestión generales con características de autogestión y transferencia masiva de información.


El incremento de los volúmenes de información que manejan actualmente las aplicaciones imposibilita que en campos de la informática tan importantes como la multimedia, los sistemas de almacenamiento distribuido o la gestión de redes se pueda seguir avanzando en tiempos y con costes aceptables. Los problemas para transferir grandes volúmenes de información entre los distintos nodos que conforman la red es una de las principales causa que provoca esta situación.

Si bien es cierto que se están aplicando soluciones parciales a este problema, el hecho de que la difusión de información no esté contemplada desde la propia concepción de los sistemas imposibilita que se pueda afrontar el problema de una forma global (figura 8).

Figura 8. Difusión de la información no integrada en el sistema de gestión.

Dentro de todas estas aplicaciones, la propia gestión de redes también se mueve en la actualidad con estos volúmenes de información y es uno de los primeros problemas a resolver a la hora de abordar los nuevos retos que la informática plantea. Con los actuales sistemas de gestión de redes no se pueden asegurar los niveles de confiabilidad y continuidad en el negocio que requieren estos sistemas. En concreto tareas de mantenimiento que requieran la transferencia de grandes volúmenes de información no se pueden realizar de forma integrada en el sistema de gestión y que éstas se realicen de forma eficiente y en tiempos acotados. Es por ello que el ámbito donde se centra el

Aplicaciónde Gestión


Red de comunicaciones



Sistema de Transferencia

Sistema de Gestión


presente trabajo es el de de la gestión de redes, donde se pretende aportar soluciones que permitan resolver la transmisión de grandes volúmenes de información.

Como hipótesis de partida de esta investigación se propone la incorporación de mecanismos para la gestión de la difusión masiva de información en los modelos de gestión de redes posibilitará la propuesta, de manera sistemática, de arquitecturas y sistemas de gestión viables con los requerimientos actuales (figura 9).

Figura 9. Sistema de gestión incorporando la difusión de la información.

A partir de las técnicas actuales usadas en grid computing para la autogestión o gestión colaborativa y las usadas en los procesos de streaming de archivos y multicast para la difusión de información, que resuelven parcialmente el problema, se puede componer un modelo de difusión de información masiva a un conjunto hipotéticamente alto de destinatarios y que ésta se realice de forma eficiente y en tiempos acotados, a la vez que aporte escalabilidad al sistema y un bajo impacto sobre la red que administra.

Objetivos, Metodología y Plan de Trabajo

El objetivo global de este trabajo consiste en la propuesta de un modelo general de gestión de redes compatible con los estándares

Aplicaciónde Gestión





Sistema de Gestión Sistema de Transferencia


y que incorpore la difusión masiva de información. El proceso de difusión deberá realizarse de forma eficiente y en tiempos acotados. El modelo tiene que ser escalable y la difusión de la información tiene que tener un bajo impacto sobre la red a gestionar. Además, la propuesta tendrá que ser compatible con el modelo de gestión OSI/ISO de forma que se facilite su integración y compatibilidad con otros sistemas de gestión.

Como objetivos parciales del trabajo se proponen los siguientes:

Realizar un estudio previo de las tecnologías, métodos y paradigmas utilizados en la gestión de redes así como de los utilizados en la difusión de información, entendida ésta como la transmisión de información a más de un destinatario.

Crear, en función del estudio realizado, un modelo de gestión de redes que conformará el eje central del trabajo a realizar y que incorporará un modelo de difusión masiva de información.

Diseñar una arquitectura del sistema de gestión que lo haga viable bajo las condiciones que imponen las actuales infraestructuras de comunicaciones: redes de área amplia, dispositivos de networking sobre los que no se tiene control, canales de comunicación variables, anchos de banda cambiantes, imposibilidad de fijar parámetros los de la comunicación a lo largo de todo el canal de comunicación y mientras dure toda la sesión de difusión, altos niveles de heterogeneidad en las plataformas tanto hardware como software, baja confiabilidad y seguridad, y un largo etcétera de condicionantes que impiden que los actuales sistemas de gestión sean suficientes.

Realizar una herramienta de gestión que junto con un escenario de aplicación real permitirá validar la viabilidad de la propuesta y extraer las pertinentes conclusiones.

Una vez finalizado el trabajo y se hayan cumplido los objetivos propuestos tendremos los siguientes resultados esperados:

Un modelo general de gestión de redes que incorpore la difusión de información masiva en su concepción.

Un protocolo de gestión de redes con capacidad de autogestión y configuración cero.


Un protocolo de transporte de red escalable que permita la transferencia de información masiva de forma confiable y a múltiples destinatarios a la vez.

Una herramienta de gestión de redes capaz de incorporar la gestión de diversos elementos de la red.

El sistema de gestión podrá aplicarse a multitud de ámbitos, si bien su uso en la gestión de redes de equipos informáticos es evidente. Dentro de este ámbito, una de las principales aportaciones del sistema será la instalación o recuperación integral de equipos donde se hace patente la necesidad de difundir grandes cantidades de información.

Los sistemas de gestión también podrán ser utilizados como base para la implantación y mantenimiento de otras aplicaciones que requieran la difusión masiva de información, delegado esta tarea al sistema de gestión de redes subyacente. De esta forma estas tareas serán llevadas a cabo de un forma mucho más eficiente y con unos determinados niveles de calidad.

La realización del trabajo estará fundamentada en el método científico, principalmente en el método hipotético-deductivo, partiendo de la hipótesis propuesta anteriormente y realizando finalmente la experimentación apropiada que la valide. En la parte más teórica, dado que el planteamiento del modelo está fundamentado en otros modelos existentes se utilizará el método sintético que nos permite formular una teoría que unifique diversos elementos. Complementariamente el método analítico nos permitirá realizar un estudio sistemático que facilite el estudio de las distintas partes del sistema y la relación entre ellas. Para la demostración se utilizarán métodos empíricos como la experimentación científica, donde se reproducirán diversas condiciones particulares que representen el modelo general para su validación.

El resto del documento se ha estructurado en una serie de capítulos que son un reflejo bastante fiel del plan de trabajo seguido durante la investigación, de forma que facilite la comprensión del mismo.

De esta forma, en el capítulo 2 se realiza un estudio previo de los antecedentes y el estado del arte relacionado con el trabajo de investigación, recogiendo todos aquellos aspectos relevantes relacionados con la gestión de redes y la transferencia de información.


En el capítulo 3, y partiendo del modelo de gestión OSI, se describe el modelo de gestión de redes propuesto donde se ha incorporado un modelo de distribución de la información de forma integrada.

En el capítulo 4 se analiza la arquitectura propuesta que hace viable el modelo de gestión utilizando SNMP como base de la propuesta.

El capitulo 5 describe un sistema de difusión sustentado en un protocolo de transporte colaborativo y un protocolo de aplicación que en conjunción permite realizar la transferencia de información e forma eficiente y escalable.

En el capítulo 6 se describe el escenario de prueba y el prototipo implementado, así como las pruebas realizadas sobre el mismo.

Por último, en el capítulo 6 se exponen las principales conclusiones del trabajo y se plantean las líneas futuras de investigación que se desprenden del mismo.

17

C a p í t u l o 2

Antecedentes y Estado del Arte

En el primer capítulo se ha establecido como objetivo general del trabajo la propuesta de un modelo de gestión de redes que incorpore la gestión y distribución de la información. Es por ello que el estudio del estado del conocimiento se ha centrado en dos áreas fundamentales, por una parte la gestión de redes de computadores y por otra la difusión de información.

Gestión de Redes

La gestión de red trata sobre la planificación, la organización, la supervisión y el control de los elementos que componen una red de comunicaciones. Los objetivos principales de la gestión de red consisten en garantizar la disponibilidad y mejorar el rendimiento de los elementos del sistema, así como incrementar su efectividad.

Debido al éxito que han tenido las redes de computadores en los últimos tiempos en la actualidad son consideradas una parte importante y estratégica de las empresas, industrias u otros tipos de organizaciones.

Como consecuencia de las cada vez mayores dimensiones que están adoptando, resulta aun más importante su control y gestión con el fin de obtener la mejor calidad de servicio posible.


Estándares

Uno de los principales problemas a los que se ha enfrentado la gestión de redes es la alta heterogeneidad de los elementos que componen las redes de computadores: dispositivos de networking, nodos de red, servicios, aplicaciones, etc., cada uno a demás de fabricantes distintos. Esto ha promovido la aparición de estándares abiertos con el fin de compatibilizar protocolos e información. De esta forma, durante la década de los noventa, se han ido desarrollando diversas iniciativas con el objetivo de ofrecer recomendaciones y estándares abiertos para tratar de dar solución a estas nuevas problemáticas, como es el caso de los protocolos de gestión SNMP o el CMIP (Nakamura et al., 1995).

Sin embargo hasta la aceptación de los actuales estándares surgieron multitud de propuestas para sistemas de gestión de redes promovidas por diversos fabricantes. Estas soluciones propietarias aportaban arquitecturas de gestión que eran adecuadas para los productos de dichos fabricantes pero con un bajo grado de interoperabilidad con otros sistemas, lo cual, unido a la creciente complejidad de las actuales redes de comunicaciones, los convirtió en sistemas en desuso (Barba, 2006).

Algunos de estos sistemas fueron propuestos por las principales empresas del sector como son el caso de Open Network Management (ONA) de IBM, el módulo de gestión de Netware de Novell, o Unified Network Management Architecture (UNMA) de AT&T.

Como alternativa a estos sistemas propietarios los estándares para la gestión de redes, fundamentalmente propuestas derivadas del estándar OSI propuesto por ISO. Aportan una solución mucho más interoperable en las actuales complejas y heterogéneas redes de computadores.

Estándar para la gestión ISO/OSI

A mediados de los 80 la Organización Internacional para la Estandarización (ISO) en colaboración con Comisión Electrotécnica Internacional (IEC) propusieron un modelo de red descriptivo denominado Open System Interconnection (OSI), como un marco de referencia para la definición de arquitecturas de interconexión de sistemas de comunicaciones (ISO/IEC, 1994).

Capítulo 2. Estado del Arte 19

El modelo establecía una estructuración de los protocolos de red en siete capas diferentes que permitió la propuesta de multitud de sistemas y protocolos de red. Sin embargo con el paso del tiempo otras propuestas, con una distribución entre capas más reducida y flexible, como es el caso de TCP/IP, consiguieron imponerse como una mejor solución.

Sin embargo muchos de los conceptos e ideas expuestas en el modelo OSI siguen vigentes en la actualidad y se aplican en multitud de sistemas basados en redes de computadores.

Formando parte de la definición del modelo de referencia ISO, en su parte 4, se define un marco de trabajo para la gestión (ISO/IEC, 1984). El estándar de gestión para OSI no define una especificación de un sistema de gestión, sino un marco que permite proponer sistemas de gestión de forma sistemática.

El modelo de gestión está compuesto por cuatro sub-modelos perfectamente diferenciados: un modelo de organización donde se describen los componentes que conforman el sistema (los elementos a administrar, el conjunto de gestores y agentes de gestión y la relación entre éstos); un modelo de información que define los datos asociados a la gestión de redes (Management Information Base – MIB) así como su estructura (Structure of Management Information – SMI); un modelo de comunicación que define la forma de comunicarse entre los gestores y los agentes de gestión; y un modelo funcional que establece las tareas a realizar por parte del sistema de gestión.

CIM

Distributed Management Task Force (DMTF), una organización conformada por las más importantes compañías de la industria (AMD, Cisco, Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Novell, Oracle, Sun Microsystems,…), propuso Common Information Model (CIM), un esquema conceptual que permite modelar los elementos que componen un sistema TI. Este modelo representa los elementos como un conjunto de objetos y sus relaciones y usa para su definición UML (Britton y deVos, 2005). CIM, además, permite integrarse con la información de otros modelos, como es el caso de SNMP.

El objetivo de CIM es ser la base de información para otras tecnologías que se sustentan en él (Debusmann et al., 2003), como es el caso de los estándares WBEM, SMASH o SMI-S.


Diversos proveedores han desarrollado implementaciones de CIM para varias plataformas como es el caso de Windows Management Instrumentation para entornos Microsoft Windows o el proyecto libre SBLIM para plataforma Linux.

WS-Management

Web Services for Management o WS-Magement es un estándar abierto que utiliza un protocolo basado en SOAP para la gestión de sistemas TIC (DMTF, 2008). En la actualidad el estándar está gestionado por el DTMF.

Además de realizar tareas de gestión como la lectura o escritura de objetos de gestión como base para la administración de un elemento, WS-Management permite la ejecución de métodos específicos para la gestión, permitiendo realizar tareas más sofisticadas que otras propuetas. Además el hecho de estar basado en Web Services permite su integración con otros sistemas y su composición con otros servicios (Lu et al., 2009)

DMF

Distributed Management Environment (DMF) es una propuesta de Open Software Foundation (OSF) para la gestión de sistemas distribuidos. El objetivo principal de DMF es la unificación de la gestión de sistemas heterogéneos. Por ello los tres pilares básicos de su propuesta son la consistencia (aportando un único interfaz de alto nivel para la gestión), la interoperabilidad (integrando diversos protocolos de gestión como SNMP o CIMP) y la escalabilidad.

Tecnologías y Protocolos

WBEM

Web-Based Enterprise Management (WBEM) es un conjunto de tecnologías estándares para la gestión en Internet desarrollado para unificar la gestión de entornos distribuidos, facilitando el intercambio de información a través de plataformas heterogéneas.

WBEM está fundamentado en CIM y utiliza como protocolos una implementación de CIM en XML (CIM-XML) y WS-Management.

En la actualidad están surgiendo muchas propuestas para el uso

de WBEM en la gestión de sistemas (Park et al., 2006) (Sundaram


et al., 2006), incluido la gestión de dispositivos embebidos (Hutter et al., 2009).

CMIP

Common Management Information Protocol (CMIP) es un protocolo de gestión de red fundamentado en el modelo OSI. Este protocolo ofrece un mecanismo de transporte que sustenta un conjunto de servicios implementados con el esquema petición-respuesta.

El protocolo proporciona una comunicación entre las aplicaciones de gestión y los agentes situados en los dispositivos a gestionar. El MIB que utiliza CMIP está basado en objetos de gestión complejos que se relacionan para describir los elementos que son gestionados.

CIMP aporta un conjunto amplio de operaciones de gestión y así como mecanismos de seguridad, autorización y control de acceso.

SNMP

Propuesto por el ITEF, Simple Network Management Protocol (SNMP) es el protocolo de gestión de redes más extendido en la actualidad y se ha convertido en el estándar más utilizado en Internet.

Las primeras propuestas para la gestión de red en Internet aparecieron en 1987 con una serie de protocolos como el SGMP (Simple Gateway Monitoring Protocol), el HEMS (High-Level Entity Management System) y el CMOT (versión de CMIP sobre TCP). Estos protocolos de gestión se ocupaban básicamente de la gestión de los dispositivos de internetworking como routers.

Posteriormente, en 1988, se produjeron una serie de revisiones para actualizar el protocolo SGMP que dieron lugar a un incipiente SNMP, con las iniciales propuestas de su SMI y MIB, una base de información basada en un árbol de objetos. Este árbol de objetos modelaba de forma sencilla los elementos e los dispositivos a gestionar.

SNMP se fundamenta en la distribución de un conjunto de agentes en los dispositivos a gestionar y unos elementos gestores o NMS (Network Management Systems) que solicitan a los agentes la realización de las tareas de gestión.


El protocolo utilizado entre estas dos entidades es un protocolo relativamente sencillo (de ahí el nombre de simple) y con pocas operaciones, básicamente una operación de lectura de objetos (GET), otra de escritura (SET) y otra de notificación (TRAP). El protocolo utiliza una serie de mensajes que si bien están fueron pensados para trabajar sobre UDP por su concepción pueden integrarse sobre otros protocolos, lo cual permitió la expansión de SNMP.

Desde el principio el protocolo SNMP tuvo mucho éxito, si bien no dejaba de ser un protocolo de monitorización esencialmente simple. Hubo en marzo de 1991 nuevas revisiones del entorno, que dieron lugar a una nueva especificación de base de datos denominada MIB II. Fue a partir de ahí que diversos fabricantes se dedicaron a la creación de MIBs particulares que extendían el árbol de objetos, dado que SNMP es esencialmente un protocolo abierto.

Posteriormente, en 1993, el grupo IETF sacó una nueva versión más completa del protocolo, denominada SNMPv2, que incorporó nuevas operaciones incluyendo una que ya permitía transferir información algo más voluminosa.

Figura 10. Evolución de SNMP.

Finalmente, en 1998, se anunciaban los primeros documentos relacionados con una nueva versión SNMPv3. Esta versión estuvo principalmente centrada en la incorporación de mecanismos de

SNMP v.1Operaciones básicas de gestión

SNMP v.2Trasferencia de bloques de datos

SNMP v.3Aspectos de seguridad


seguridad al protocolo, algo que a SNMP se le había criticado mucho hasta el momento (ver figura 10).

Transmisión de la información

La transmisión de información en redes de computadores ha sido uno de los campos de estudio más activos en los últimos años, principalmente tras el éxito y expansión de las redes e Internet.

La transmisión de información de forma optima y el aprovechamiento de las tecnologías e infraestructuras de red a sido uno de los objetivos planteados en muchas de las propuestas de sistemas para la difusión de información. En ese sentido tecnologías como multicast, sistemas P2P o los sistemas colaborativos han sido utilizados para incorporar características de escalabilidad en la transmisión o disponibilidad de la información.

Difusión de información

La mayoría de los procesos y tecnologías de transferencia de información entre equipos utilizando redes de computadores han estado marcados por el uso de protocolos fundamentados, principalmente, en técnicas unicast, donde la transferencia de la información se realiza entre dos únicos nodos. En estos protocolos los dos nodos pueden establecer comunicaciones ya sea en un único sentido o bidireccionales pero, en cualquier caso, cada nodo actúa puntualmente como nodo origen en caso de que sea el que envía la información o como nodo destino en caso de que la reciba (Tanenbaum, 1997).

Otros protocolos, principalmente destinados a procesos de control de la red (Forouzan, 2002) (Halsall, 1998) (García, 1989), utilizan técnicas de broadcast donde la información es enviada por un único nodo origen, siendo su destino todos los nodos de la red (normalmente en el ámbito de las redes locales). Estas tecnologías aprovechan las características que algunos medios tienen para la difusión de información, de manera que la información es enviada una sola vez, pudiendo llegar en una misma transacción a todos los componentes de la red y reduciendo así el trafico de red.


Protocolos como TCP/IP (Comer, 1996) basan su filosofía de trabajo en estas técnicas, proporcionando a las aplicaciones una capa de servicios mediante la cual poder establecer transferencia de información entre nodos, con un esquema orientado a conexión (TCP) o no (UDP). Mediante estos protocolos se puede satisfacer la mayoría de los requerimientos de las aplicaciones que necesitan una comunicación bidireccional entre equipos.

Sin embargo y motivado principalmente por la aparición e incremento del uso de los recursos multimedia, que comenzó a afianzarse en los años 90, surgen una serie de nuevos requerimientos en las comunicaciones que precisan de un cambio filosófico en la manera de transmitir la información (Mack, 2002).

Las características de estos nuevos sistemas de trasferencia son, por una parte, la gran cantidad de información a transmitir y, por otra, el elevado número de equipos a los que va destinada dicha información, en algunos casos del orden de miles o incluso millones de receptores. Mediante una transferencia unicast clásica obtendríamos resultados desfavorables ya que habría que repetir la transferencia de la información por cada uno de los destinatarios, con lo que el resultado sería un proceso global lento y sobre todo poco escalable. Se hace necesario pues introducir nuevos modelos de trabajo que permitan aprovechar mejor el uso de la red.

Multicast

Multicast es una tecnología que nos permite transferir la información desde un emisor a un conjunto determinado de destinatarios (ver Figura 11). El uso de técnicas multicast para la transmisión de archivos a más de un cliente mejora sustancialmente el rendimiento ya que el equipo origen emite la información una única vez, evitando la repetición de la información a transmitir. Estas técnicas son mucho más escalables a la hora de distribuir la información ya que el envío de los datos no es dependiente del número de destinatarios. (Stallings, 2000)

Una utilización clara del uso del multicast, y precursora en cierta manera de su desarrollo, es el streaming de audio o video. En este tipo de aplicaciones un servidor emite de manera continua un flujo de paquetes conteniendo la información multimedia que los clientes deben presentar. Los clientes, según van recibiendo estos paquetes, van reproduciendo la información en tiempo real en


función de su tipo y el dispositivo final en el que se está presentando. En caso de que se pierda uno o más paquetes de la secuencia, el cliente lo refleja mediante una pausa puntual en la reproducción o un decremento de la calidad, resolución o frecuencia del contenido. Esto es posible ya que existen codificaciones de contenidos multimedia que nos permiten realizar su reproducción en condiciones de pérdida de información. En cualquier caso el cliente normalmente no necesita comunicarse con el equipo origen para informar de la pérdida de datos, es decir, se trata de una comunicación unidireccional y no confiable. Usando este tipo de comunicación el sistema es altamente escalable ya que la transmisión se realiza de manera independiente al número de destinatarios.

Figura 11. Comparativa del envío de un mismo paquete a varios receptores usando técnicas de unicast, broadcast y multicast.

Sin embargo, en otros escenarios necesitamos que la transfernecia sea confiable, es decir, tenemos que asegurar la total recepción de la información por parte de los destinatarios. Pongamos como ejemplo un servidor de software que necesita enviar la instalación de una aplicación a cientos o miles de clientes. Al final de la transmisión tenemos que asegurar que todos los clientes han recibido la totalidad del paquete software. En estos casos la escalabilidad del sistema está más cuestionada, ya que la simple confirmación de la recepción de la información se multiplica por el número de clientes, por lo que se pude saturar la red con los paquetes de control.

E

R

R

R

E

R

R

R

E

R

R

R

Unicast Broadcast Multicast


La tabla 1 muestra una distribución de los diferentes tipos de aplicaciones que nos podemos encontrar en función del tipo de datos y el tipo de transmisión.

Tabla 1. Tipos de aplicaciones multicast.

En tiempo real Sin tiempo real

Multimedia Streaming de video.

Streaming de audio.

Videoconferencia.

Descarga de video.

Descarga de música.

Replicación de repositorios multimedia.

Datos Distribución de noticias.

Juegos interactivos.

Mensajería instantánea.

Descarga de archivos.

Bases de datos replicadas.

Distribución de software.

Redes de compartición de archivos.

Multicast sobre IP

En el caso del protocolo IP el soporte para multicast fue implementado por primera vez en el año 1993 mediante una ampliación de dicho protocolo.

El funcionamiento del multicast sobre IP está fundamentado en la suscripción a grupos de difusión (Deering, 1986). Cada grupo de difusión está asociado a una dirección IP que lo identifica. Para ello se reservaron un conjunto de direcciones IP denominadas de „clase D‟ destinadas a las comunicaciones en multicast. En concreto, estas direcciones son aquéllas que empiezan con el prefijo „1110‟, es decir, las comprendidas en el rango de 224.0.0.0 a 239.255.255.255 (ver tabla 2). De este conjunto, las comprendidas entre la dirección 224.0.0.0 y la 224.0.0.255 están reservadas para tareas administrativas y de mantenimiento multicast.

Un equipo que desea recibir paquetes difundidos por otro equipo se suscribe a una determinada dirección IP de multicast. A partir de ese momento el protocolo de red se encargará no sólo de hacer llegar a las aplicaciones del equipo los paquetes destinados a la propia dirección IP del equipo, sino que también hará llegar los


paquetes destinados a las direcciones IP multicast a las que el equipo se ha suscrito. En cualquier momento el equipo podrá darse de baja de un grupo de difusión, con lo que dejaría de recibir los paquetes enviados a la dirección IP asociada.

Tabla 2. Distribución de direcciones IP.

Clase Prefijo Dirección inicial Dirección final

A 0 0.0.0.0 127.255.255.255

B 10 128.0.0.0 191.255.255.255

C 110 192.0.0.0 223.255.255.255

D 1110 224.0.0.0 239.255.255.255

Por otra parte el equipo que desee enviar un paquete al grupo de difusión simplemente tendrá que enviar el paquete a la dirección IP asociada al grupo, como si la dirección se correspondiera a un nodo más de la red.

El multicast para IP está disponible tanto para el envío de paquetes IP como para paquetes UDP. Evidentemente con TCP no se puede realizar multicast ya que se trata de un protocolo confiable orientado a la conexión entre dos nodos. Con el uso de UDP obtenemos principalmente dos ventajas respecto a usar simplemente IP: conseguimos una multiplexación por aplicación mediante el uso de los puertos de comunicaciones y podemos establecer un código de detección de errores (checksum) para los datos.

Para que los paquetes enviados por un equipo a la dirección multicast puedan llegar a los suscritos a esta dirección y que se encuentran en una red diferente a la del emisor, los routers que se encuentran en su camino deberán reconocer la IP destino como dirección multicast y difundirla por las rutas necesarias para que el paquete pueda llegar a todos los posibles destinatarios. Por lo tanto, para poder realizar una comunicación multicast entre equipos situados en diferentes segmentos de red, no sólo los equipos tienen que soportar el multicast para IP, los routers también tienen que soportarlo.


Sin embargo en la actualidad ni todos los equipos ni todos los routers soportan multicast ya que no es obligatorio en la especificación IPv4 (en IPv6 sí es obligatorio), con lo que en un principio esto impediría el uso de esta tecnología entre algunos equipos. Para solucionarlo pude utilizarse MBONE (Multicast Backbone).

Mediante MBONE (Handley, 1997), cuando un paquete multicast debe traspasar un router que no soporta multicast, el paquete es encapsulado en un paquete unicast (IP dentro de IP) de manera que puede transportarse sin problemas por cualquier ruta. Posteriormente, en el router destino, el paquete será recompuesto para obtener el paquete original. Los dos extremos que convierten de multicast a unicast y de nuevo a multicast definen lo que se denomina un túnel multicast.

Para conseguir que los paquetes emitidos desde un nodo lleguen a todos los nodos suscritos al grupo multicast, los nodos y routers que soportan multicast se comunican mediante un protocolo denominado Internet Group Management Protocol - IGMP (Comer, 1996). Mediante IGMP se actualizan las tablas de enrutamiento de los routers, de manera que durante la transmisión multicast éstos pueden tener la información necesaria para difundir la información adecuadamente. Cada vez que un nodo se incorpora o abandona un grupo informa mediante este protocolo su interés o no en recibir paquetes destinados a la dirección IP asociada.

Confiabilidad

En comunicación, la confiabilidad hace referencia a las transferencias en las que la información debe llegar de manera completa al destinatario para ser útil (Floyd et al, 1996). Cuando por cualquier motivo la información no ha sido entregada completamente, debe informarse del fallo a los componentes de la comunicación (normalmente al emisor). Si en el proceso de comunicación no se puede garantizar la entrega de la información, se considera que es una transmisión no confiable. Si nos fijamos en tabla 1 solamente la cuadrícula superior izquierda corresponde a aplicaciones no confiables.


Figura 12. Esquema de retransmisión por paquete perdido basado en ACK’s.

En una transmisión confiable clásica, para asegurar la recepción de la información, una de las técnicas más utilizadas es el uso de los paquetes de confirmación. El nodo emisor fragmenta la información a enviar en unidades denominadas paquetes, enviándolos al receptor de manera secuencial y ordenada. El receptor, según va recibiendo cada paquete de información, envía al emisor un paquete de confirmación (ACK) indicando que la recepción ha sido correcta. El envío de estos paquetes de confirmación se pude realizar por cada paquete de datos recibido o por un conjunto de paquetes para optimizar así la comunicación. El emisor espera a recibir el paquete de confirmación adecuado antes de seguir enviando el siguiente paquete de datos. Si el emisor, tras haber enviado un paquete de datos, no recibe el paquete de confirmación antes de un tiempo determinado, asume que el paquete de datos no ha sido recibido y realiza un reenvío del mismo. Si en este esquema el receptor sí que recibe el paquete de datos y es el ACK el que se ha perdido, el emisor también reenvía el paquete de datos ya que asume que el cliente no lo ha recibido. El cliente pues puede recibir más de una vez un paquete de datos. En caso de que el receptor haya caído o esté temporalmente ocupado, el emisor podría estar

Emisor Receptor

Paquete 1

Paquete 2

(perdido)

ACK 1

ACK 2

Paquete 2 (reenvío)

Tiempo de

espera aleatorio


saturando la red de forma continua con reenvíos de paquetes de datos. Para evitarlo, los protocolos de comunicación normalmente implementan algoritmos en los que los tiempos de espera entre reenvíos se van incrementando con cada nuevo intento y, en caso de superar un número determinado de reenvíos, se da por cancelada la comunicación.

En este esquema el emisor es el responsable de realizar la corrección de errores (ver figura 12).

Mediante el uso de los ACK‟s no sólo conseguimos una transmisión confiable, también conseguimos una sincronización entre el emisor y el receptor, dado que el emisor no envía un nuevo paquete hasta que no ha confirmado la recepción del anterior. Si no fuera así, el emisor podría estar enviando paquetes a una velocidad superior a la que el receptor puede soportar, con lo que muchos de los paquetes se perderían. Es decir, mediante el uso de ACK‟s también conseguimos un control de flujo en la comunicación.

El uso de estas técnicas basadas en los paquetes de confirmación para conseguir una comunicación confiable trasladado al caso del multicast conlleva un gran problema: la falta de escalabilidad. Supongamos que un emisor envía un paquete a un conjunto de N receptores por mulsticast. Cuando el paquete es recibido por los receptores se generan N ACK‟s informando al emisor de su correcta recepción. Esto, para un número de receptores elevado, provocaría que tanto la red como el emisor se saturasen con los paquetes de control. Es más, posiblemente, el alto número de paquetes haría que muchos de ellos se perdieran o fueran descartados por el emisor debido dicha saturación, con lo que se generarían más reenvíos de paquetes, empeorando aún más, si cabe, la situación.

Es necesario, pues, aplicar otro tipo de técnicas que aporten soluciones más escalables a la hora de transmitir información de forma confiable mediante multicast.

Protocolo genérico vs protocolo específico

A la hora de resolver un problema mediante el uso de técnicas multicast confiable, los diseñadores optan por realizar una de las dos siguientes estrategias: crear una capa de transporte general que resuelva de manera general el problema de la comunicación


multicast o crear un protocolo que resuelva las necesidades particulares que requiere cada aplicación (Miller, 1997).

Con la primera opción se pretende conseguir un protocolo lo suficientemente abierto como para poder ser utilizado por cualquier aplicación que requiera una comunicación multicast y confiable, de igual manera que TCP proporciona análogas características en unicast. Si TCP nos ofrece una capa de transporte que realiza una corrección de errores y una ordenación de los paquetes enviados, las características que debería aportar un protocolo genérico de multicast confiable serían:

Sincronización en la comunicación: control del ratio de envío en función de la velocidad de lectura de los receptores y la saturación de la red.

Escalabilidad: independencia respecto del número de receptores.

Corrección de errores: control de paquetes perdidos en la comunicación.

Ordenación de paquetes: mantenimiento en el destino del orden secuencial de los paquetes.

Independencia de la red: transparencia ante las diferentes topologías y arquitecturas de red.

Con la segunda estrategia conseguimos un protocolo que, si bien no pude ser usado por cualquier aplicación, sí nos aporta una solución optimizada para cada problema. Se puede dar el caso de aplicaciones que, por ejemplo, no requieran una ordenación de paquetes, o que necesiten funcionar solamente para una determinada topología. En estos casos un protocolo específico podría dar mejores resultados que con una estrategia de carácter general. En otros casos se hace necesaria la utilización de protocolos específicos, ya que se dan condiciones determinantes para su uso, como podría ser el caso de comunicaciones donde no existe un canal de retorno.

Escalabilidad

Como hemos visto, la principal causa de la falta de escalabilidad en la transmisión multicast confiable es el problema con la información de vuelta, es decir, de los paquetes de control que envían los receptores al emisor. Por muy poca que sea esta información, si el número de receptores llega a ser muy alto, el


emisor terminaría por saturarse, con lo que no se podría garantizar la escalabilidad de la comunicación (Bolot et al., 1994).

Para evitar esta saturación en el canal de retorno, una de las técnicas que suelen aplicarse es cambiar las confirmaciones (paquetes ACK) por paquetes de información de pérdidas (paquetes NACK). En este caso el emisor también suele realizar un envío de los paquetes de información de manera secuencial y ordenada, mientras que los receptores, en este caso, no envían ninguna información según van recibiendo correctamente los datos. Cuando un receptor detecta un hueco en la secuencia de recepción de datos, es decir, cuando un paquete se ha perdido, envía un NACK al emisor indicando su pérdida para que éste reenvíe el paquete de datos indicado. El emisor, pues, podría intercalar reenvíos de paquetes en la secuencia normal de datos a medida que vaya recibiendo los NACK‟s de los receptores (Floyd et al, 1996).

Figura 13. Envío de NACK por finalización del tiempo de espera.

Emisor Receptor

Paquete 1

NACK

Paquete 2

Paquete 3

Paquete 4

Paquete 5

Paquete 6

Paquete 7

Paquete 8

Paquete 9

Paquete 2

Paquete 10

Tiempo de espera

Recepción del paquete 5 antes de la finalización

del tiempo de espera


El receptor, para detectar un hueco en la secuencia de datos que recibe, deberá esperar a recibir uno o varios paquetes posteriores al paquete perdido o bien esperar un tiempo margen para determinar que el paquete ha sido realmente perdido. Si no lo hiciera así podría confundirse la pérdida de un paquete con un desorden en la secuencia de recepción de los paquetes, ya que es posible que paquetes posteriores utilicen caminos más rápidos y que, por lo tanto, lleguen antes a un receptor (ver figura 13).

Si un destinatario no recibe un paquete solicitado por pérdida antes de un determinado tiempo, reenviará el paquete NACK adecuado asumiendo que o bien el NACK anterior o bien el paquete de datos reenviado se han perdido. Mientras el receptor espera el paquete perdido deberá ir almacenando el resto de paquetes que vaya recibiendo a falta de completar los huecos que se vayan produciendo. Esto implica el uso de un buffer de almacenamiento temporal donde alojar los paquetes que aun no se pueden suministrar a la aplicación que lo requiere.

En casos de pocas pérdidas en la comunicación, esta técnica reduce drásticamente la información de control en la comunicación e incluso, en casos óptimos, podría evitarse totalmente.

Sin embargo la falta de confirmación por parte de los receptores produce una serie de inconvenientes. En el caso de que por ejemplo en todo el proceso de transmisión no se produzca la recepción por parte del emisor de ningún paquete NACK, no significa que todos los paquetes de datos hayan sido recibidos por todos los receptores; puede existir algún problema en el canal de vuelta que evite la recepción de dichos paquetes. Por lo tanto, con el simple uso de los paquetes NACK no se puede garantizar la confiabilidad de la comunicación. Una posible solución a este problema sería el envío de un único paquete de confirmación al final de toda la transmisión, de manera que el servidor tuviera la seguridad de la correcta recepción de la información. Esto implicaría una pérdida de escalabilidad por la dependencia que volveríamos a tener del número de receptores, si bien este envío sería único y localizado siempre al final de la transmisión.

Control de flujo

Otro de los problemas que se plantea con el cambio de ACK‟s por NACK‟s es la pérdida de la sincronización en la comunicación. Si bien mediante el uso de las confirmaciones el emisor y el receptor


se encuentran siempre acompasados en el flujo de la transmisión ya que el emisor no envía el siguiente paquete hasta no tener confirmado el anterior, con el uso de NACK‟s esto no puede realizarse. Mientras el emisor difunde los paquetes de datos no tiene información sobre el estado ni la cantidad de paquetes recibidos por cada receptor. El principal problema que se deriva de esta situación es una falta en el control de flujo o ratio de transmisión, es decir, el emisor podría estar difundiendo los paquetes a una velocidad superior a la que algunos receptores podrían estar leyendo, o por el contrario, el canal podría estar desaprovechado al usar un ratio muy bajo. Este inconveniente también ocurriría si alguno de los routers intermedios sufriera un problema parecido y descartara algunos de los paquetes de datos por falta de capacidad. Las consecuencias de estas pérdidas (ya sea en el destino como en los routers intermedios) son nefastas: algunos destinatarios detectarían de manera sistemática huecos en la secuencia de recepción y saturarían al servidor con paquetes NACK. Este ciclo de continuas pérdidas y solicitudes de reenvío producirían una clara inestabilidad en la comunicación (Mankin et al, 1998).

Utilizando ratios de envío muy bajos o al menos tan bajo como el ratio de recepción del destinatario más lento tampoco solucionaría el problema. Tengamos en cuenta que la red por la que viajan los paquetes es un medio variable con periodos de mucho uso o saturación y donde normalmente no se puede garantizar un determinado ancho de banda. Por lo tanto es necesario plantear técnicas que se adapten a las necesidades puntuales de la red, en las que el emisor ajuste automáticamente el ratio de envío según las circunstancias y las características de los destinatarios.

Seguridad

La seguridad en la comunicación es un aspecto que se complica aún más con el uso de las técnicas multicast. En una comunicación unicast donde los paquetes tienen un origen y un único destino, para que un tercer elemento pueda tener acceso a la información, se requiere el uso de técnicas de espionaje como pueden ser la suplantación de identidad (suplantación IP) o la escucha promiscua del medio físico (sniffer). Sin embargo, con multicast, esto mismo se puede realizar de manera mucho más sencilla ya que bastaría con incorporarse al grupo de difusión para tener acceso a los paquetes enviados por el emisor. Se trata


pues de una transmisión pública donde el emisor no establece los receptores de sus paquetes. Para establecer seguridad (transmisión de información segura), necesitamos aplicar algoritmos de codificación de la señal transmitida (procesos de cifrado de los datos) (Stallings, 2000).

Para el establecimiento de unos niveles de seguridad adecuados en la transmisión multicast se debe contemplar principalmente los siguientes aspectos:

Cifrado: la información emitida debe de protegerse con mecanismos de cifrado que eviten su tratamiento por destinatarios no permitidos.

Autenticidad: evitar que elementos externos o no permitidos de la comunicación puedan sustituir parte de la información emitida sin que los miembros de la transmisión lo detecten.

Autenticación: los miembros de la comunicación tienen que ser debidamente identificados para evitar su suplantación

Tipos de distribuciones

Uno de los aspectos que más condicionan el modelo de comunicación tiene que ver con el rol con el que actúa cada uno de sus miembros. Algunas de las configuraciones que se pueden dar son:

Un emisor y varios receptores. En estos casos el papel de emisor y de receptor está totalmente definido. Hay un único origen de datos que se centraliza en el emisor y los receptores simplemente tienen capacidad de enviar paquetes de control.

Varios emisores y varios receptores. En este modelo son varios los elementos capaces de emitir información. Normalmente existe un emisor principal que manda inicialmente la información y un conjunto de nodos con capacidad de re-emitirla para, por ejemplo, realizar labores de corrección de errores.

Todos emiten y reciben. Se trata de redes de cooperación donde todos los miembros son capaces de actuar como emisor y receptor. La función de corrección de errores está distribuida al conjunto total de los miembros. (Floyd et al, 1996)


Conocimiento de los destinatarios

Según la información que tiene el emisor sobre los receptores a los que van destinados los paquetes de datos, podríamos clasificar las comunicaciones multicast en tres grupos diferentes (Miller et al, 1997):

Grupo de destinatarios indeterminado. En este primer modelo el emisor no conocería ni el número ni la identidad de los destinatarios a los que va dirigida la información que está emitiendo. Un ejemplo claro de este tipo de comunicación sería la transmisión de audio o vídeo por internet, donde el emisor difundiría los paquetes de información sin tener en cuenta los destinatarios de los mismos. A su vez, los receptores, podrían incorporarse y abandonar el grupo de difusión sin tener que informar ni realizar ningún tipo de proceso de conexión con el emisor. Suele tratarse de comunicaciones donde no se requiere un canal de retorno, situaciones éstas comunes en caso de infraestructuras altamente asimétricas, como por ejemplo, la transmisión vía satélite, donde el canal de bajada tiene un ancho de banda muy superior al de subida y una latencia muy alta (Tunpan y Corson, 2000).

Grupo de destinatarios abierto. En este tipo de comunicación el emisor dispone de información sobre los receptores a los que está dando cobertura, si bien este grupo no está determinado antes del inicio de la comunicación. Según se va desarrollando el proceso de comunicación, el emisor va actualizando la lista de receptores, bien al recibir un primer paquete de un receptor (por ejemplo un NACK), bien mediante el uso de procesos de control, como los de conexión y desconexión, que utilizarían los receptores para informar al emisor. En este último caso se pueden realizar también operaciones de validación para permitir el acceso o no al grupo. Para evitar que equipos no validados tengan acceso a la información, en el proceso de conexión el emisor podría aportar elementos como claves de cifrado o filtros de datos, sin los cuales no sería posible procesar los datos emitidos por el servidor.

Grupo de destinatarios cerrado. Por último, en este modelo, el emisor conoce a priori los receptores de los datos, y solamente permitiría la comunicación con estos receptores, ignorando cualquier paquete enviado por otros equipos. Durante todo el proceso de comunicación el conjunto de receptores no varía, de manera que el emisor puede utilizar esta información para


prefijar algunos parámetros del proceso de transferencia en función de la cantidad o características de los destinatarios: ratio de envío, tamaño de los paquetes, etc.

Corrección preventiva

Como hemos visto, el principal problema que se plantea en la comunicación multicast es la falta de escalabilidad: cuanto mayor es el número de receptores más alto es el volumen de paquetes de control. Para conseguir que el modelo de transmisión sea escalable, la solución más evidente que se puede plantear es la reducción, idealmente la eliminación total, de los paquetes de control. Para ello se utilizan técnicas de corrección preventiva (Forward Error Correction – FEC).

La idea principal de estas técnicas es la siguiente. Supongamos que el total de la información a trasmitir se fragmenta en n paquetes de datos. En función de esos paquetes se generan r paquetes de recuperación, conteniendo información redundante de los paquetes de datos originales. El emisor manda tanto los paquetes de datos como los paquetes redundantes. Si un destinatario no recibe uno de los paquetes de datos enviados, podrá regenerarlo a partir de uno o más paquetes de recuperación, sin tener así que solicitar el reenvío del paquete perdido.

Idealmente la codificación de los paquetes de recuperación se realizaría de manera que, para regenerar un conjunto de paquetes perdidos, se necesiten la misma cantidad de paquetes correctores. Una de las codificaciones más utilizadas y que cumple esta última característica es la de Reed-Solomon (Floyd et al, 1996). Sin embargo estas codificaciones conllevan un alta complejidad temporal para su cálculo (aumenta exponencialmente con el número de paquetes), con lo que se penaliza su uso en la mayoría de los casos. Para evitarlo, la información se agrupa en bloques de paquetes de datos sobre los que se computan localmente los paquetes de recuperación. Por lo tanto los paquetes generados solamente sirven para recuperar pérdidas dentro del bloque de paquetes de datos que se utilizó para su generación. El tamaño de los bloques se decide en función de los límites que se quieran establecer, dependiendo de la capacidad de cómputo que se disponga.

En la actualidad también se están aplicando FEC‟s basados en la primitiva XOR, donde los tiempos de cómputo de los paquetes de


recuperación son bajos y de de coste lineal. Por contra, con estas técnicas se requieren más paquetes de recuperación para regenerar un paquete de datos, con lo que se incrementa el volumen de información trasmitida.

Incorporando FEC a la comunicación se logra una disminución, tanto en la cantidad de retransmisión de paquetes, como en la cantidad de paquetes de control, con lo que se suele justificar el ancho de banda extra que se utiliza en la emisión de los paquetes de recuperación y, en el caso de las trasmisiones multicast, se consigue una mayor escalabilidad.

Otra de las ventajas que aporta estas técnicas es la reducción de reenvíos en el caso de pérdidas simultáneas en diversos destinos. Si por ejemplo un receptor pierde un paquete de datos p1 y otro equipo pierde un segundo paquete p2 el emisor solamente tendría que retransmitir un único paquete r1 con el que ambos destinatarios podrían recuperarse de su pérdida. En el caso de un esquema basado en XOR tendríamos que el paquete de recuperación sería r1 = p1 XOR p2, con lo que el primer receptor calcularía p1 con r1 XOR p2 y el segundo realizaría r1 XOR p1 para calcular p2.

Además del tiempo de computo necesario, el uso de FEC‟s también conlleva normalmente la utilización de un buffer de trabajo sobre el que se van componiendo los paquetes redundantes.

Uso de representantes

Otra de las técnicas utilizadas para la disminución del tráfico de control y conseguir de esta manera una mayor escalabilidad es el uso de nodos representantes (DeLucia y Obraczka, 1997). Un representante es un componente de la comunicación, normalmente uno de los destinatarios, que se encarga de centralizar la información de vuelta de un conjunto de receptores, agrupándola en un bloque de información compacto, normalmente un único paquete, y reduciendo así la cantidad de paquetes que recibiría el emisor.

Estas técnicas se aprovechan de la jerarquía establecida por la topología de red, de manera que la información de vuelta se va agrupando según se acerca al emisor; facilitando, de esta forma, la escalabilidad.


Figura 14. Reducción del tráfico de control en los routers.

En algunos casos interesa que el nodo representativo pueda realizar también labores de corrección de errores, con lo que se reduciría aun más el envío de paquetes de control hacía el emisor, pudiendo incluso llegar a evitarse. En estos casos el nodo designado almacena la información recibida para poder actuar como un emisor secundario.

Si bien el nodo representante suele ser uno de los destinatarios de la información, en algunos casos se pude utilizar nodos habilitados explícitamente para esta función o bien se delega a los routers (ver figura 14), ya que estos se sitúan en los puntos de confluencia de los paquetes de control.

El problema que se suele plantear con el uso de representativos es su designación. Se pueden distinguir varios mecanismos de designación:

Designación manual. Antes del comienzo de la comunicación se decide el conjunto de equipos representativos. Normalmente esta tarea corresponde a un administrador de red con conocimiento sobre la distribución y características de los receptores

Designación automática al inicio. Durante el comienzo de la comunicación se realizan las operaciones necesarias para

E

R R R

R R

R

R

E

R

Emisor

Receptor

Router


determinar un conjunto de representativos en función de los destinatarios. Para ello se puede aprovechar los procesos de conexión de los receptores en caso de existir.

Designación automática adaptable. Durante todo el proceso de la comunicación se van determinando los mejores representativos en cada momento. Esta modalidad es recomendable en los casos de comunicaciones con un número de destinatarios variable ya que la distribución de los receptores varía según estos se incorporan o abandonan el grupo.

Trabajos relacionados

SRM

En (Floyd et al, 1996) se define Scalable Reliable Multicast Framework (SRM) como un marco de trabajo en multicast orientado a la distribución compartida de información dentro de un grupo de participantes. En este marco todos los componentes del grupo son a la vez emisores y receptores de información. Si un miembro tiene información que distribuir, la emite en forma de paquetes a la dirección de multicast. El resto de miembros del grupo tienen la responsabilidad de realizar la corrección de errores, detectando huecos en la secuencia recibida y solicitando los paquetes perdidos. Los mensajes de control, como la solicitud de paquetes perdidos, también se envían a todo el grupo usando la misma dirección de multicast.

Cuando se pierde un paquete, para evitar la saturación de la red con la información de control, se toma la siguiente medida: antes de enviar una solicitud de paquete perdido se espera un tiempo aleatorio, de manera que se reduzca la probabilidad de que varios miembros soliciten simultáneamente un mismo paquete. Si durante este tiempo de espera se recibe la solicitud de ese mismo paquete por parte de otro miembro, se anula el envío de la solicitud para evitar la repetición de solicitudes.

Por otra parte, cuando un miembro recibe una solicitud de paquete y dispone de una copia de dicho paquete, se espera un tiempo determinado y se reenvía el paquete solicitado de nuevo a la dirección multicast. El tiempo de espera es aleatorio y dependiente de la distancia al equipo emisor de la solicitud.

Para calcular las distancias entre los diferentes miembros del grupo se utilizan mensajes de sesión. Estos mensajes son


mandados periódicamente por cada miembro y permiten además conocer el número y estado del resto de los participantes. Para no saturar la red con los mensajes de sesión, se limita su uso a un determinado porcentaje del ancho de banda, por ejemplo un 5%. El cálculo de distancias se realiza de la siguiente manera:

Un equipo A manda un mensaje de sesión en el tiempo t1

Un segundo equipo B recibe dicho paquete en t2

Pasado un tiempo, en t3, B manda un mensaje de sesión incluyendo el tiempo de espera (t3 – t2)

Una vez A recibe el mensaje de B, en t4, calcula la distancia a B de la siguiente manera: (t4 – t1 – (t3 – t2)) / 2.

Este proceso no requiere una sincronización de los relojes de los participantes, pero sí que asume una comunicación simétrica, lo cual es un problema en comunicaciones como las basadas en transferencia vía satélite.

SRM no proporciona una entrega ordenada de los paquetes. Si una aplicación que use SMR requiere dicha ordenación, deberá gestionarla en una capa superior.

Para evitar la saturación del canal de distribución con mensajes de control SRM incorpora la recuperación local, contemplando únicamente aquellos participantes que se encuentran más cerca. Mediante esta reparación local se gana en escalabilidad.

Fundamentado en el uso de SRM se ha desarrollado wb, una utilidad que permite a varios usuarios compartir los dibujos que van realizando sobre una pizarra. Cuando un usuario sitúa un objeto en su pizarra, la aplicación envía la información necesaria para que el objeto se muestre al resto de usuarios.

MTFP

Multicast File Transfer Protocol (MFTP) (Miller et al, 1997) es un protocolo de transporte multicast que centra su objetivos en conseguir una comunicación altamente escalable y con un soporte universal para todo tipo de redes, incluyendo las altamente asimétricas.

El protocolo está basado en el envío de un paquete NACK por bloque de información. Para ello, el total de la información a emitir se fragmenta en un conjunto de bloques de un tamaño determinado; cada bloque, a su vez, se divide en una serie de


paquetes que se envían de forma individual a la dirección multicast. Por cada bloque enviado, cada receptor mandará, en caso de ser necesario, un único paquete NACK indicando los paquetes que no ha recibido. El NACK es esencialmente un bitmap donde se marca con un 1 las posiciones de los paquetes perdidos. Por lo tanto, el tamaño del bloque de información vendrá dado por el tamaño del bitmap que se envía, el cual estará limitado la unidad máxima de trasnferencia (MTU) de la comunicación. Con esta técnica se reduce el número de NACK‟s enviados por los receptores. Una vez el emisor a recibido un conjunto de NACK‟s de los destinatarios, realiza una operación OR entre ellos, obteniendo como resultado un bitmap que describe la lista del conjunto de paquetes perdidos y que por lo tanto tiene que reenviar. El emisor, una vez ha emitido inicialmente toda la información, va realizando reenvíos de paquetes mientras vaya recibiendo NACK‟s o hasta que se cumpla un tiempo determinado.

Este protocolo no realiza una ordenación de paquetes ni opera en tiempo real. Tampoco realiza un control del ratio de envío de los paquetes, simplemente se determina un ratio al comienzo y se mantiene durante toda la comunicación, es decir, no tiene un control adaptable del flujo.

En la fase de reenvío de paquetes MFTP utiliza una técnica de FEC para reducir el número de paquetes reenviados, pudiendo servir un único reenvío para la recuperación de más de un paquete perdido por diversos destinatarios. Esto penaliza a los destinatarios más lentos ya que se requiere un tiempo de cómputo extra para analizar dichos paquetes.

MFTP no realiza control de la congestión. Al inicio de la comunicación el emisor manda unos paquetes de aviso indicando el número máximo de paquetes perdidos que puede tener cada destinatario. Aquellos que superen ese límite tendrán que abandonar la comunicación para no penalizar al resto de componentes. Estos paquetes de envio también se utilizan para publicar otros parámetros como son el tamaño de los paquetes de datos o el ratio de envío.

Al final de la transmisión, los receptores mandan un paquete de confirmación informando de la correcta recepción de todos los paquetes, con lo que se asegura la confiabilidad.


Para ganar en escalabilidad, el protocolo utiliza una técnica de designación de concentradores del canal de vuelta, consistente en una serie de equipos que reciben los paquetes de control de un conjunto de receptores y se encargan de unificarlos en un solo paquete, con lo que se reduce la información que llega al emisor.

El protocolo también implementa tres tipos de grupos de comunicación:

Grupo cerrado. El emisor conoce el total de los destinatarios. En los paquetes de inicio de comunicación invita a estos equipos a unirse a la transmisión.

Grupo abierto limitado. Cualquier equipo puede unirse a la comunicación pero tiene que informar al emisor de su incorporación y de la correcta recepción de la información.

Grupo abierto ilimitado. Cualquier equipo puede unirse a la comunicación sin informar de ello al emisor ni informar de la correcta finalización. Se trata de una comunicación no confiable.

Existe un producto comercial, StarBurst Multicast, basado MFTP.

BMTP

El Bulk Multicast Transport Protocol (BMTP) (Morris, 1997) aporta un solución basada en IP multicast para una comunicación multicast confiable con control del ratio y soporte para un gran número de receptores.

Este protocolo se fundamenta en el uso de paquetes de estado que envían los receptores al emisor, con lo que se realiza tanto el control del ratio, como la corrección de errores. En cada paquete de estado el destinatario informa del ratio de recepción de manera que el emisor pueda ajustar su propio ratio de envío. El paquete también hace las veces de NACK informando de los paquetes perdidos.

En cada paquete de datos el emisor incluye un número N que comienza siendo una estimación del número de destinatarios. Cuando un destinatario recibe un paquete de datos responde con un paquete de estado con una probabilidad de 1/N. El emisor, en función del número de paquetes de estado que va recibiendo, reajusta el valor de N para incrementar o disminuir la cantidad de información de vuelta que tiene que recibir, de manera que la cantidad de paquetes emitidos y la cantidad recibida sea del mismo orden. De esta forma el emisor no se satura con los


paquetes de control independientemente del número de destinatarios.

Para minimizar el número de paquetes reenviados, se utiliza un FEC basado en el algoritmo IDA (Information Dispersal Algorithm) (Rabin, 1989).

Fuente Digital

En (Byers y Luby, 1998) se describe el concepto de fuente digital, un protocolo totalmente escalable para la distribución de información masiva a múltiples destinatarios. En el emisor la información se fragmenta en un conjunto de paquetes que son codificados un un FEC orientado a XOR denominado Tornado Codes (Luby et al, 1997). Con esta codificación todos los paquetes emitidos son paquetes de recuperación, de manera que en la secuencia de emisión no se repite en ningún momento ningún paquete. Cada destinatario va recibiendo los paquetes codificados hasta que tiene un conjunto suficiente como para recomponer el total del archivo original. Al no tener que solicitar ningún paquete perdido, la escalabilidad de la solución es total.

El principal problema de este modelo radica en que los destinatario tienen que tener un buffer de almacenamiento intermedio lo suficientemente grande como para guardar los paquetes recibidos, ya que hasta que no se disponen de todos ellos no es posible regenerar completamente el archivo original.

NORM

El protocolo NACK Oriented Reliable Multicast (NORM) es posiblemente una de las principales propuestas de un protocolo de transporte basado en multicast (Adamson et al., 2009).

Ha sido propuesto por Reliable Multicast Transport (RMT) un grupo de trabajo del IETF.

Este protocolo puede proporciona una capa de transporte confiable de datos masivos utilizando IP multicast como base.

NORM utiliza un mecanismo basado en NACK para garantizar la confiabilidad y la sincronización entre emisores y receptores. El protocolo utiliza mecanismos de FEC para optimizar el proceso de trasnferencia.


Sistemas Colaborativos

Computación Grid

La computación grid o grid computing hace referencia a las tecnologías que permite utilizar de forma coordinada todo tipo de recursos (cómputo, almacenamiento y aplicaciones) que no están sujetos a un control centralizado.

La computación grid es un tipo de computación distribuida, en la cual y al contrario que en los clusters los recursos pueden ser heterogéneos y se encuentran conectados mediante redes de área extensa (por ejemplo Internet).

El uso de grids para la transferencia de datos también ha sido caso de estudio y de diversas propuestas (Zhao et al., 2009) (Wu

et al., 2006) (Radic et al., 2007).

Las principales aportaciones de los sistemas grid para la transferencia de información son la escalabilidad y tolerancia a fallos, dada la distribución de las tareas asociadas a la comunicación.

Comunicación Igual a Igual (P2P)

Los sistemas entre-iguales o peer-to-peer (P2P) hace referencia a redes de nodos que actúan entre ellos con un rol común, sin establecer diferencia entre clientes y servidores de los recursos.

El uso principal que se le ha dado a las redes P2P es la del intercambio de información donde todos los nodos (peers) que conforman la red ofertan al resto la información que disponen.

Las principales características que aportan las redes P2P son: escalabilidad, ya que el proceso de transferencia se reparte entre todos los peers, robustez, la caída de algunos nodos no detiene la difusión de la información, y descentralización, no existen nodos especiales que actúen de punto crítico del sistema, si bien esta última características no es cumplida por todos los sistemas P2P.

Además otras importantes características pueden ser incorporadas a estos sistemas como la seguridad o el control de acceso, aspectos fundamentales en los procesos de transmisión de información.


Las redes P2P surgieron a mediados de los años 90 y en la actualidad su uso está altamente extendido. De hecho multitud de estudios aportan que el tráfico generado por los sistemas P2P supera ampliamente al tráfico generado por otros servicios como la WEB o el correo. Sin embargo en la actualidad se está produciendo un descenso en el ancho de banda global consumido por los sistemas P2P (un 20,4%) así como un incremento en el consumo realizado por los sistemas de streaming multimedia (un 26,6%) (Sandvine, 2009).

Existen multitud de redes P2P e implementaciones. Las más extendidas con la red eDonkey o eD2K (Hawa, 2008), la red Kademlia (Wu & Wang, 2009) y la BitTorrent (Guo et al., 2007).

Streaming de archivos

El streaming es una tecnología de distribución de información normalmente asociada a contenidos multimedia, principalmente audio y video. El streaming se fundamente en un flujo de información vista como una corriente continua que va desde proveedor de la información hasta los consumidores de la misma.

El streaming en oposición a la descarga tradicional permite que el destinatario de la información pueda ir procesando la información según se va recibiendo, sin necesidad de tener que tener el archivo completo.

Si bien estas características hacen que el proceso de comunicación del streaming esté muy condicionado también lo hace atractivo en otras ocasiones porque requiere de pocos recursos de memoria para la comunicación, ya que la información se procesa según se recibe. Esto lo hace muy propicio en entornos con poca disponibilidad de recursos.

En la actualidad han surgidos enfoques mixtos entre streaming y P2P donde se utilizan las técnicas colaborativas del P2P para generar un flujo de información global a todos los miembros de la red. El uso más extendido de estos sistemas es el P2PTV que permite la difusión de video mediante streaming colaborativo.

Conclusiones

Como se ha visto el uso de estándares en la gestión de redes aporta grandes beneficios en la definición sistemática de


aplicaciones de gestión. De entre ellas el marco de referencia para la gestión de OSI es un buen punto de partida para la definición de un modelo de gestión ya que estructura y dirige la formalización del modelo de gestión, dando libertad en las decisiones de diseño.

Además SNMP por su gran extensión, su bajo impacto sobre la red administrada y su flexibilidad y extensibilidad es un buen protocolo de gestión como punto de partida para la propuesta del modelo de gestión.

En cuanto a la difusión de información, existen multitud de sistemas y protocolos cada uno con características interesantes en función de los requerimientos de las aplicaciones de gestión (ver tabla 3).

Sin embargo algunas aplicaciones de gestión tienen requerimientos no cubiertos completamente por los sistemas actuales (última columna de la tabla 3). Sería necesario proponer un sistema de transferencia de información que aglutine las técnicas de multicas con sistemas colaborativos y P2P.


Tabla 3. Características de los sistemas del difusión de información.

Característica

IP

UD

P

TC

P

Pro

toc

olo

s d

e

tran

fere

nc

ia

(HT

TP

, F

TP

,…)

Me

dia

str

eam

ing

Me

dia

str

eam

ing

(m

ult

icast)

P2P

Dif

us

ión

po

r

mu

ltic

ast

Co

lab

ora

tiva +

Str

eam

ing

Multiplexación por aplicación

Detección errores

Corrección errores (confiabilidad)

Control de flujo

Ordenación de paquetes

Mecanismos de conexión

Mecanismos de validación

Orígenes 1 1 1 1 1-n 1-n n 1 n

Destinatarios 1 1 1 1 n n n n n

Escalabilidad

Memoria intermedia

Tiempos acotados

Uso ancho de banda en transmisiones mulidestinatario

Saturación del emisor en transmisiones multidestinatario

Velocidad de transmisión

Consumo de CPU

No soportado Soportado Nivel bajo Nivel medio Nivel alto

49

C a p í t u l o 3

Modelo de Gestión de Redes

La gestión de redes hace referencia a todas las actividades, bien sean realizadas por un administrador bien automatizadas por algún sistema, que están relacionadas con el control, coordinación o la monitorización de los elementos que componen una red, entendiendo éstos como elementos capaces de almacenar y procesar información y, fundamentalmente, comunicarse entre sí.

Como punto de partida para la propuesta de un modelo de gestión se ha utilizado el marco de trabajo propuesto en el modelo de referencia básica de OSI (ISO/IEC, 1989) (ISO/IEC, 1994), marco utilizado por la mayoría de los sistemas de gestión de redes actuales. En esta propuesta se consideran diversos aspectos relacionados con la gestión de redes, incluyendo la gestión elementos tan dispares como dispositivos de red, aplicaciones, servicios, protocolos o los propios usuarios y administradores del sistema. Todos estos elementos conforman el Entorno de Red (OSI Enviroment – OSIE). Si bien este marco de trabajo ha sido utilizado en muchas propuestas de sistemas de gestión la principal novedad del presente trabajo es el hecho de contemplar no solo los elementos tradicionales de gestión de redes, sino también la información que se almacena y transfiere en el sistema, permitiendo realizar una gestión de la misma de forma integrada con el resto del sistema de gestión. Su inclusión en la propia definición del modelo permitirá que actividades de gestión que necesiten la difusión de información masiva puedan realizarse de forma integrada y eficiente al poder contemplar el resto de elementos que componen el sistema.


A lo largo de esta sección, y siempre que se haga referencia a términos descritos en el estándar OSI, se utilizará la nomenclatura utilizada por el ISO para clarificar los conceptos que se describen.

Como herramienta a la hora de formalizar las ideas que se irán planteando se utilizará formulación matemática, principalmente teoría de conjuntos, lógica de primer orden y teoría de grafos. De forma complementaria también se utilizará el Lenguaje Unificado de Modelado (UML) para representar gráficamente dichos conceptos.

El objetivo principal de este capítulo es proponer un modelo de gestión de redes (Network Management Model – NMM) con capacidad de gestión de la información que denominaremos NMMINF.

Figura 15. Sub-modelos del modelo de gestión de redes.

Dentro del modelo de gestión, como se indica en el modelo OSI, se pueden distinguir cuatro sub-modelos bien diferenciados que ayudan a desarrollar de forma separada y ordenada un sistema

Modelo de Gestión de

Redes


Modelo de Información


Modelo Funcional

Capítulo 3. Modelo de Gestión 51

de gestión (ver figura 15): un Modelo de Organización (Organizational model – OM) donde se describen los componentes que conforman la red (los elementos a administrar, el conjunto de gestores y agentes de gestión y la relación entre éstos; un Modelo de Información (Information Model – IM) que define la información asociada a la gestión de redes (Management Information Base – MIB) así como su estructura (Structure of Management Information – SMI); un Modelo de Comunicación (Communication Model – CM) que define la forma de comunicarse entre los gestores y los agentes de gestión; y un modelo funcional (FM) que establece las tareas a realizar por parte del sistema de gestión.

Esta separación hace que la descripción del modelo esté mucho más estructurada y permita su formalización de forma más clara y sistemática.

De manera formal podríamos definir nuestro modelo de gestión como la siguiente tupla:

[1]

La figura 16 representa el diagrama de agregación para el modelo de gestión.

Figura 16. Diagrama de agregación del modelo de gestión.

De manera formal, mediante la Extensión de Eriksson y Penker para UML podríamos definir el proceso de creación del Modelo de Gestión propuesto como se describe en la figura 17.


Figura 17. Proceso de creación del Modelo de Gestión.

En ciertos momentos, donde se requiera tomar decisiones de diseño, el modelo será instanciado en el protocolo SNMP ya que, como se vio en el capítulo 2, es el sistema de gestión actual más extendido y que además tiene las características de extensibilidad y flexibilidad necesarias para adaptarlo a nuestras necesidades.

A continuación se describen en profundidad cada uno de los cuatro sub-modelos presentados.


En un entorno distribuido como las redes de computadores los procesos de gestión también se distribuyen entre los elementos del entorno.

Siguiendo el estándar OSI de gestión de redes se pueden diferenciar los siguientes elementos: un Entorno de Gestión (OSI Enviroment – OSIE), compuesto por el conjunto de dispositivos que conforman el sistema y la red de comunicaciones que los interconecta, un conjunto de Entidades (System Management Application-Entity – SMAE), responsables de la gestión del sistema, y un conjunto de protocolos de red (Network Protocols – NP)

[2]

En la figura 18 se muestra un diagrama de agregación reflejando la composición del modelo de organización.


Figura 18. Diagrama de agregación del Modelo de Organización.

Entorno de Gestión

El entorno de gestión refleja la parte más física y tangible del modelo de organización. Principalmente está compuesto por el conjunto heterogéneo de Dispositivos a Gestionar (Management Devices – MD) que aglutina los distintos elementos que conforman una red de computadores: servidores, computadoras personales, dispositivos móviles, routers o cualquier otro dispositivo con capacidad de comunicación. En nuestro sistema estos dispositivos son el objetivo final de las tareas de gestión.

[3]

En el sistema también se distinguen otros dispositivos que no están sujetos a ningún tipo de mantenimiento, o que al menos no están contemplados como objeto de gestión en nuestro sistema. Sin embargo estos dispositivos también forman parte del entorno de gestión, bien porque dan soporte a algún elemento del mismo bien porque facilitan alguna de las tareas del sistema de gestión como es el caso de routers, firewalls o cualquier otro dispositivo de networking. A estos dispositivos los denominaremos Dispositivo de Soporte (Support Device – SD).

[4]

Al conjunto total de dispositivos que conforman el entorno de gestión lo denominaremos Dispositivos de Red (Network Devices – ND).

[5]

La figura 19 representa el diagrama de clases donde se refleja la relación de herencia entre los distintos tipos de dispositivos.


Figura 19. Diagrama de herencia del Modelo de Organización.

Evidentemente también existen otros elementos que interactúan con los dispositivos de red: usuarios, aplicaciones externas, administradores, etc. Estos elementos son considerados externos al sistema de gestión y no forman parte en si del entorno de gestión.

Para interconectar todos los elementos del sistema existirá una red de comunicaciones que denominaremos Red de Computadores (Network – N). La red la formalizaremos como un pseudografo dirigido (un grado dirigido que acepta bucles en un nodo) y etiquetado compuesto por un conjunto de nodos que conformarán los Dispositivos de Red (ND), un conjunto de Aristas (E) que unirán estos nodos, el conjunto de Etiquetas posibles (C) y una Función de Etiquetado (p).

[6]

[7]

Las aristas del grafo no tienen por qué corresponderse con interconexiones físicas entre los nodos. Una arista representa que es posible comunicar los dos extremos de la misma en una dirección determinada independientemente de la infraestructura de red que exista por debajo.

La ponderación del grafo establece las características que cumplen cada una de las aristas, es decir, propiedades como ancho de banda, velocidad de transferencia, latencia, etc. Cada una de esas características se definirá como:

[8]


Por lo tanto las propiedades de cada arista del grafo vendrán definidas por el producto cartesiano de las características.

[9]

De esta forma la ponderación es una función que asocia cada arista con un conjunto de características (figura 20).

[10]

Figura 20. Diagrama de relación de la red de computadores.

Entidades

Para llevar a cabo la administración del sistema existirá un conjunto de Entidades que trabajarán en conjunción para realizar las tareas de administración. Las Entidades conforman un sistema distribuido que es la base fundamental del modelo de gestión. A continuación se describen los diferentes tipos de entidades que se distinguen en nuestro modelo.

Cada uno de los dispositivos a gestionar tendrá asociado un agente específico para su gestión que llamaremos Entidad de Gestión (Management Entity – ME). Las Entidades de Gestión son las responsables finales de llevar a cabo las tareas de mantenimiento dentro de cada uno de los dispositivos que gestionan, así como de recabar la información necesaria del dispositivo y, en caso de ser necesario, lanzar alertas cuando se identifica un problema.

[11]

[12]


Si bien se podría considerar la posibilidad de que en un mismo dispositivo existieran varias Entidades de Gestión, cada una de ellas llevando a cabo tareas de gestión específicas, para simplificar el sistema vamos a considerar que conceptualmente ambos se comportan como una única entidad que aglutina la suma de todas las tareas.

El comportamiento de las Entidades de Gestión es principalmente reactivo, es decir, reciben peticiones de otras entidades, llevan a cabo la tarea de gestión encomendada y devuelven el resultado de la misma. Complementariamente también pueden estar monitorizando alguna variable del dispositivo a gestionar y, cuando se cumple alguna circunstancia determinada, emite una alerta a alguna otra entidad.

Por otro lado en el sistema también cuenta con gestores o Entidades de control (Control Entity – CE) que se encarga de solicitar a las diferentes Entidades de Gestión del sistema que lleven a cabo las tareas de mantenimiento. Es en este elemento donde se suelen centrar las labores de coordinación y planificación del mantenimiento y suele ser el punto de accedo al sistema de gestión para los administradores.

[13]

Para su funcionamiento la Entidad de Control residirá en un Dispositivo de Soporte que le aporte un adecuado entorno de ejecución.

[14]

Una Entidad de Control solicitará realizar tareas de gestión a las Entidades de Gestión que se encuentran distribuidas por el sistema. Estas operaciones son iniciadas siempre por la Entidad de Control (parte activa) y son servidas por las Entidades de Gestión (parte pasiva). Las Entidades de Control también son las responsables de recibir y procesar las alertas emitidas por las Entidades de Gestión. En este caso el rol es distinto, siendo la Entidad de Gestión la parte activa de la operación). Si bien este es el esquema general de operación del sistema de gestión también puede existir algún tipo de delegación tanto a nivel de Entidad de Gestión como de Entidad de Control (ver figura 21). Esto permitiría la concepción de sistemas de gestión más sofisticados donde podría darse algún tipo de relación jerárquica entre las diferentes entidades que lo componen.


Figura 21. Relación entre entidades de control y de gestión.

Esta distribución del sistema de gestión, donde tenemos entidades de gestión situadas en los dispositivos a gestionar y entidades de control que supervisan y controlan a las primeras es una arquitectura muy extendida en los sistemas de gestión actuales. Por ejemplo SNMP utiliza este modelo llamando Agentes de Gestión a las Entidades de Gestión y Sistemas Administradores de Red (NMS) a las Entidades de Control (Douglas & Schmidt, 2005).

Dado que el modelo de gestión que se propone tiene que contemplar la gestión no solo de los dispositivos, aplicaciones y servicios que conforman un sistema, sino también la información que estos utilizan, incorporaremos el concepto de Información (Information – I) dentro del modelo de organización. Para ello definiremos la información como el conjunto de los diferentes paquetes de datos que pueden existir en el sistema. Estos paquetes pueden ser archivos, recursos de información, paquetes software, paquetes de configuración y, en general, cualquier


elemento de información que puede ser gestionado, transferido y almacenado de forma independiente.

[15]

Tradicionalmente las entidades del sistema de gestión no contemplaban la gestión y transferencia de la información en su concepción, de forma que si en el desarrollo de una tarea de gestión se necesitaba un paquete de información determinado, se utilizaba un sistema de trasporte externo al sistema de gestión para obtener dicho paquete (ver figura 22). Además el sistema de gestión debía conocer a priori dónde residía la información y con qué protocolo podía ser accedido.

Figura 22. Acceso a la información en un sistema de gestión tradicional.

En nuestro modelo daremos a las Entidades de Gestión y Control la posibilidad de poder transferir de forma integrada en el sistema de gestión esta información. Es en este punto donde radica la principal aportación del modelo ya que al hacer esta transferencia de forma integrada conseguiremos las siguientes ventajas.

Al realizar la transferencia de la información a nivel de gestión no será necesario realizar esta tarea a nivel de aplicación. Por ejemplo si necesitamos replicar la información que utiliza un servidor web no será necesario utilizar ninguna aplicación de réplica adicional, el propio sistema de gestión podrá realizar esta tarea.


Al tener las entidades de gestión distribuidas en nuestro

entorno de gestión permite potencialmente el acceso a la información que se encuentre en cualquier parte del sistema. Gracias a esto una entidad podrá obtener un paquete de información siempre que se encuentre accesible por otra entidad de gestión.

El carácter distribuido del sistema de gestión hace que la transferencia de la información pueda realizarse de forma colaborativa. Con ello todas las entidades que soliciten la información podrán colaborar para optimizar el proceso de transferencia, es más, incluso elementos que no requieran dicha información podrán colaborar en la propia transferencia.

Por lo tanto en nuestro sistema de gestión tanto las entidades de gestión como las de control tienen la capacidad de solicitar la transferencia de estos paquetes de información. Dado que es posible que existan nodos en el sistema que contengan información pero que no tengan asociado una entidad de gestión, definiremos las Entidades de Información (Information Entity – IE) que serán las responsables de gestionar y suministrar la información en estos casos. Se trataría de entidades asociadas a: servidores web, servidores ftp, servidores de ficheros, servidores de contenido multimedia, etc.

Si bien las Entidades de Información dentro de nuestro modelo tienen como única labor la de gestionar la información, está también podrá ser gestionada por las Entidades de Gestión y las Entidades de Control. Por lo tanto un paquete de información podrá estar accesible y podrá ser suministrado por cualquiera de estas entidades o, incluso, por más de una si existen réplicas de este paquete.

Las Entidades de Información no tienen por qué residir en el mismo dispositivo donde se almacenan los paquetes de información. Podrán estar sustentadas por Dispositivos de Soporte y gestionar la información que reside físicamente en otros dispositivos.

En este sistema distribuido donde pueden existir multitud de Entidades y de Paquetes de Información se hace necesario incluir algún tipo de sistema de descubrimiento que permita conocer a cada uno de las entidades cuales son las otras entidades del sistema, así como que paquetes de información existen, donde se


ubican y mediante qué protocolo puede descargarse. De esta forma se podría desacoplar todas las partes del sistema dando una visión unificada de las Entidades y los Paquetes de Información a todos los elementos.

Figura 23. Acceso a la información con la integración de la información en el sistema de gestión.

Para llevar a cabo el descubrimiento en nuestro modelo utilizaremos unas Entidades de Registro (Registry Entity – RE) que nos permitan llevar a cabo las labores de registro y de búsqueda de entidades e información.

[16]

Las Entidades de Registro actúan básicamente como repositorios donde el resto de entidades son responsables de registrarse con la información necesaria para su localización. Así mismo, las entidades que tengan información disponible, incluidas las Entidades de Información, también registraran dicha información con su localización y la información necesaria para su acceso. Si bien el registro puede ser visto como un lugar centralizado donde almacenar información de localización de los elementos del sistema, para ganar en escalabilidad y tolerancia este registro puede ser replicado o distribuido entre diferentes entidades de registro (ver figura 24).


Figura 24. Entidad de Registro.

Por lo tanto el conjunto total de entidades que conforman el sistema serán:

[17]

En la figura 25 se puede ver el diagrama de clases para las entidades del sistema.

Figura 25. Diagrama de clases de las entidades del sistema.

Protocolos

La comunicación entre las distintas entidades del sistema se realizará mediante el uso de diversos Protocolos de Red (Network Protocols – NP). Una vez vistos los diferentes tipos de entidades del sistema y la relación entre ellos en el modelo se distinguirán tres tipos distintos de protocolos: Protocolos de Gestión de Redes (Network Management Protocols – NMP),


Protocolos de Transporte o transmisión de datos (Transport Protocols – TP) y Protocolos de Descubrimiento (Discovery Protocols – DP). Los protocolos serán descritos posteriormente en el Modelo de Comunicación.

[18]

[19]

[20]

[21]

A modo de resumen en la tabla 4 podemos ver los distintos roles que toman las entidades en función del protocolo que pueden utilizar.

Tabla 4. Roles de las entidades en función del protocolo.

Entidad activa

Entidad pasiva

Protocolo Descripción

CE ME NMP Solicitar actividad de gestión

CE CE NMP Delegar actividad de gestión

ME CE, ME NMP Informar de un aviso

ME ME NMP Delegar actividad de gestión

ME, CE, IE ME, CE, IE TP Transferir información

ME, CE, IE RE DP Registrar / Localizar

En la figura 26 se muestra un diagrama resumen con el esquema general del Modelo de Organización. Se ha destacado aquellos elementos fundamentales que caracterizan al modelo por su capacidad de gestión de la información.


Figura 26. Esquema general del Modelo de Organización.

Modelo de Información

Dado que el propio sistema de gestión de redes es en sí un sistema distribuido la información que gestiona también se distribuye entre los distintos elementos que conforman el sistema.

Para ello cada una de las entidades que conforman el sistema tendrá asociada una Base de Información de Gestión (Management Information Base – MIB). En los MIB se representa la información referente a la gestión que cada uno de las entidades necesita.


(OM)

Entorno de Administración

Dispositivos de Red (ND)

Dispositivos a Gestionar (MD)

Dispositivos de Soporte (SD)


(N)Información (I)

Entidades de Administración

(SMAE)

Entidad de Gestión (ME)

Entidad de Control (CE)

Entidad de Información (IE)

Entidad de Registro (RE)

Protocolos de Red (NP)

Protocolos de Gestión de Red

(NMP)

Protocolos de Transporte (TP)

Protocolos de descubrimiento

(DP)


Figura 27. Base de Información de Gestión.

Objetos de Gestión

Dentro de cada Dispositivo a Gestionar se pueden distinguir diferentes Objetos de Gestión (Management Objetct – MO). Cada uno de estos objetos representa un elemento de la realidad. Además de los propios dispositivos de red que el agente está gestionando el MIB estaría compuesto por todo tipo de objetos como:

Aplicaciones

Servicios

Usuarios

Equipos

NIC‟s

Unidades de almacenamiento

Sistemas de archivo

Datos

Dominios

De esta manera se podría realizar una gestión integral de la red contemplando cualquier elemento. Es importante destacar que en nuestra propuesta los datos en sí (archivos, flujos de información, configuraciones, etc.) también van a ser contemplados como objetos a gestionar. Esto, a diferencia de los modelos de gestión tradicionales, nos permitirá incluir la propia


gestión de la información (almacenamiento, transporte, tratamiento o difusión) como parte de la gestión de la red.

Los Objetos de Gestión son elementos fundamentales en el Sistema de Gestión. Nos permiten modelar los Dispositivos a Gestionar de forma que las entidades del sistema ven a estos como una colección de Objetos de Gestión. Una vez modelados los dispositivos, aplicaciones, servicios y la información, las tareas de gestión se resumen en realizar acciones sobre los Objetos de Gestión. De esta manera los Objetos de Gestión nos abstraen de los detalles reales que existen en los sistemas que gestionamos, ofreciendo una visión unificada de los objetos reales que hay por detrás. Por ejemplo un objeto puede modelar una NIC de un dispositivo, de forma que el Objeto de Gestión que lo modela refleje información referente a estadísticas de paquetes enviados y recibidos por esta NIC, sin importar que modelo de NIC sea.

Base de Información de Gestión

La agrupación de todos los Objetos de Gestión conforma el MIB de la entidad. El MIB para cada Dispositivo a Gestionar encapsula y actúa como interfaz para realizar las tareas de gestión sobre él, como se puede ver en la Figura 28.

Figura 28. MIB de las entidades del sistema de gestión.

El MIB no es una base de datos al uso, que almacena y gestiona los datos que contiene, es una representación formal de los datos


de gestión que virtualmente asocia un objeto del MIB a un objeto de la realidad. De esta forma un objeto del MIB podría ser el estado de un dispositivo, por ejemplo si está apagado o encendido, y cambiando dicho estado podríamos apagar el dispositivo.

Para conseguir la compatibilidad con SNMP que indicamos anteriormente partiremos de la definición realizada en este estándar del MIB. Este MIB es lo suficientemente flexible para incorporar los elementos nuevos que deseamos integrar en nuestro modelo.

La forma en que se formaliza el MIB viene definida por la Estructura de la Información de Gestión (Structure of Management Information – SMI).

Estructura de la Información de Gestión

En SNMP el MIB sigue una estructura de directorio organizado en forma de un árbol jerárquico donde los nodos de este árbol son los Objetos de Gestión. Cada uno de estos objetos tendrá asociado un nombre único que lo identificará dentro de cada subárbol, es decir no podrán existir dos objetos con el mismo nombre que cuelguen del mismo objeto padre. En SNMP el nombrado de cada objeto puede ser textual o numérico, siendo el primer hijo de cada padre el objeto 0. De esta manera los objetos se podrán identificar indistintamente por su nombre o por su número.

El árbol que conforma el MIB de SNMP es extensible, es decir, cada entidad tiene la capacidad de expandir alguna de las ramas del árbol con nueva información.


Figura 29. Esquema general del MIB de SNMP.

En la figura 29 se muestra la estructura raíz básica del MIB estándar utilizado por SNMP (Case et al., 1996). Normalmente se utiliza el nodo mgmt para extender el MIB base con información sobre gestión. El nombre completo de este nodo sería iso.org.dod.internet.mgmt usando una notación donde se nombran todos los nodos del camino, separándolos por puntos. Alternatimanente el nodo mgmt también se puede nombrar como 1.3.6.1.2, usando la notación numérica. A este nombre único de cada objeto se le conoce como Identificador de Objeto (Object Identification – OID).

Otras zonas del árbol normalmente utilizada en SNMP son la rama experimental (1.3.6.1.3) donde se sitúan propuestas no estándares que están aún en proceso de validación y la rama prívate (1.3.6.1.4) de donde cuelgan los MIBs propuestos por diversas empresas privadas para dar soluciones de gestión específicas para sus productos.

Dentro de la rama mgmt, donde se recogen los estándares, destaca el MIB más utilizado en la actualidad por la mayoría de los sistemas que incorporan SNMP. Se trata del subárbol definido como el estándar MIB-II (McCloghrie & Rose, 1991). Sus principales ramas se pueden ver en la figura 30.

root

ccitt(0) iso(1)

org(3)

dod(6)

internet(1)

directory(1) mgmt(2) experimental(3) private(4)

joint(2)


Figura 30. Esquema general del MIB-II de SNMP.

El estándar MIB-II está soportado por la mayoría de los dispositivos que incluyen SNMP y recoge datos referentes a interfaces, protocolos, sistema, etc., datos que normalmente son comunes a todos los Dispositivos a Gestionar.

Tipos de elementos

En el MIB cada objeto es de un tipo determinado. El tipo indica la sintaxis que se aplica a dicho objeto. Los tipos de datos que incluirá nuestro modelo son los soportados por SNMP y que se describen en la tabla 5. Estos tipos son un subconjunto de los definidos en el estándar ASN.1 (Rose & McCloghrie, 1990).

Los objetos definidos en el MIB pueden ser de lectura, si solamente pueden ser consultados o de lectura/escritura si estos pueden ser además modificados. Además cada atributo puede ser opcional u obligatorio en función de si siempre es requerido o no.

Según lo que hemos visto en el Modelo de Organización se han analizado un conjunto de nuevas características y funcionalidades que se han incorporado a nuestro Modelo de Gestión para que el sistema pueda incorporar la gestión y transferencia de la información. Para poder reflejar esto dentro del modelo de información de SNMP a continuación se van a definir un conjunto de extensiones en forma de MIBs donde se refleje la información asociada al registro y a los paquetes de información.

Tabla 5. Tipos de datos en SNMP.

Tipo Descripción

INTEGER Un número de 32 bits que representa cualquier valor que se pueda expresar numéricamente. El valor 0 no debe ser utilizado (RFC 1155).

mib-2(1)

system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) tranmission(10) snmp(11)


OCTET STRING Una cadena de 0 o más bytes. Se utiliza para

representar cadenas de texto.

Counter Un número de 32 bits que representa un valor incremental, como por ejemplo un contador de bytes emitidos por una NIC. Cuan el contador llega a su máximo valor (232-1) vuelve a 0.

OBJECT IDENTIFIER Una cadena de números separados por puntos que representa un OID.

NULL Tipo nulo o sin tipo. Actualmente no es utilizado en SNMP

SEQUENCE Una secuencia que contiene cero o más tipos de datos. Permite realizar listas de elementos. Normalmente se utiliza en los nodos interiores del árbol.

SEQUENCE OF Una secuencia que contiene cero o más datos de un mismo tipo. Permite realizar vectores de elementos.

IpAddress Dirección IP4 (4 bytes).

Descubrimiento

Para gestionar el descubrimiento se propone la creación de un MIB específico que denominaremos MIB-Registry. Este MIB que será expuesto por las Entidades de Descubrimiento, tiene como objetivo representar los datos necesarios para realizar la publicación y descubrimiento de entidades e información.

Objetos de Descubrimiento

Formalmente y de forma independiente del sistema de gestión seleccionado para el modelo, definimos el MIB de descubrimiento como un conjunto de objetos que nos van a permitir gestionar el registro de entidades e información.

En la figura 31 observamos la definición en UML de la clase Entity. En ella se recogen los campos y operaciones que componen cada una de estas entidades.


Figura 31. Definición de la clase Entity.

En la tabla 6 se puede ver los diferentes campos que componen una entidad en el sistema de registro.

Cada entidad estará identificada de forma única por un Identificador de Entidad (Entity ID – EID). Además por cada entidad se podrá establecer un nombre y una descripción de la misma. Para su localización también se registrará la información de la dirección IP y el puerto en el que estará trabajando la entidad en cuestión. Por último cada entidad tendrá asociada un timeout de registro, cumplido el cual la entidad será eliminada del mismo. Con esto evitamos que entidades que desaparecen de forma anómala del sistema, por ejemplo debido a un apagado del equipo donde residen, no permanezcan indefinidamente registrados en el sistema. La entidad por lo tanto es responsable, no sólo de registrarse en una entidad de registro, sino también de renovar periódicamente dicho registro. En cualquier caso, antes del cumplimiento del timeout, si la entidad de registro está configurado para ello, podrá enviar una alerta a la entidad en cuestión para que está renueve su timeout.

Tabla 6. Definición de los campo de una entidad en el registro.

Nombre Tipo Descripción

eid INTEGER Identificador único de entidad.

Entity

eid

type

name

description

ip

port

timeout

renew()

update()

topicSubscribe()

topicUnsuscribe()


type INTEGER Tipo de entidad:

1 – Entidad de gestión

2 – Entidad de control

4 – Entidad de información

8 – Entidad de registro

name OCTET STRING Nombre de la entidad.

description OCTET STRING Descripción de la entidad.

ip IpAddress Dirección IP de la entidad.

port INTEGER Puerto de la entidad donde reside el sistema de gestión.

timeout INTEGER Segundos pendientes para la permanencia de la entidad en el registro.

El valor 0 indica que no caduca nunca.

En la figura 32 se puede ver la definición de la clase EntitySet, que representa el conjunto de entidades registradas. Se trata básicamente de una lista de entidades sobre las que podemos operar para publicar o consultar.

Figura 32. Definición de la case EntitySet.

De forma similar en el registro se gestionan los objetos que representan a los paquetes de información del sistema. La figura 33 ilustra la clase4 Information.


Figura 33. Definición de la clase Information.

De cada información del sistema tendremos registrados los datos identificados en la tabla 7.

Tabla 7. Definición de los campos de un paquete de información en el

registro.


iid INTEGER Identificador único de paquete de información

size INTEGER Tamaño del paquete. Si no se conoce 0.

description OCTET STRING Descripción de la información. Pueden existir varias.

url OCTET STRING URL para el acceso a la información. Pueden existir varias.

priority INTEGER Prioridad o importancia del paquete.

Cada paquete de información tendrá un identificador de información (Information ID – IID). Dado que este identificador tiene que ser único para cada paquete, éste podrá ser calculado a partir de una función resumen de los datos contenidos en el paquete. De esta forma dos entidades que tengan el mismo paquete de datos lo identificarán con el mismo IID independientemente de si la información es un archivo, un registro almacenado en una base de datos o un flujo de información emitido por un servidor de broadcasting. De esta forma dos paquetes de información serán iguales si y solo si el

Information

iid

size

description[]

url[]

priority


contenido de los mismos es exactamente iguales. Para garantizar esto muchas propuestas utilizan funciones de resumen que, a partir del contendido de los datos, obtiene un identificador asociado de forma que la función resumen asegura que la probabilidad de que dos Paquetes de Información distintos tengan el mismo resumen sea prácticamente nula.

La descripción de la información (campo description) son textos que ayudan a identificar el contenido de la información. Diversas entidades pueden aportar descripciones distintas y complementarias de una misma información, por lo que descripción será un vector de múltiples descripciones. Las descripciones podrían ser, por ejemplo, los distintos nombres de archivo que puede tener una misma información en cada equipo donde reside.

De forma similar tendremos un vector de URLs que nos indicará los distintos protocolos y direcciones de acceso que podemos tener para una misma información. La URL especifica la información necesaria (protocolo, direcciones, puertos, rutas, nombres, etc.) para que una entidad pueda localizar y transferir una información determinada.

El conjunto de Paquetes de Información registrados estará reflejado en la clase InformationSet (ver figura 34).

Figura 34. Definición de la clase InformationSet.

Cada entidad es responsable de mantener el conjunto de paquetes de administración que gestiona. Por lo tanto cada paquete de información estará asociado a todas las entidades que lo gestionan y será dado de baja del sistema cuando todas estas entidades se hayan dado de baja en el sistema.

InformationSet

informationList

publish()

delete()

search()


Modelo de Distribución de la Información

Una de las principales características que se quiere dotar al sistema es que en el propio modelo de gestión se recoja la distribución de la información en el sistema, de forma que la información se pueda replicar, mover o eliminar en función de las necesidades cambiantes del sistema.

En este sentido, cuando una entidad registra un paquete de información éste puede ser interesante a otras entidades. Para conseguir esto se proponen dos enfoques diferentes. En uno de estos enfoques, basado en polling o consulta, las entidades estarían continuamente consultando el registro de información para determinar cuándo hay una nueva entrada de interés. Este enfoque es poco escalable y podría saturar el sistema de registro cuando tenemos un alto número de entidades consultando o un gran número de paquetes de información en el sistema. Otro enfoque, mucho más adecuado para nuestra propuesta, es un modelo basado en eventos en el cual cuando una entidad registra un nuevo paquete de información, el propio registro es responsable de avisar mediante avisos a las entidades interesadas en recibir notificaciones.

En ambos enfoques una de las cuestiones que hay que determinar, principalmente si se quiere ganar en escalabilidad, es acotar tanto las consultas como los avisos generados definiendo de alguna forma cual es el interés de las entidades en la información.

En nuestro caso vamos a modelar estos intereses mediante un conjunto de temas o categorías (topics). Cada paquete de información podrá estar asociado a un conjunto ilimitado de categorías, de forma que cada categoría representa un área de interés para las entidades. Por ejemplo un paquete de actualización para el sistema operativo Microsoft Windows XP podría estar suscrito a las categorías: software, actualización y windowsxp. En este caso los administradores serían los responsables de asociar la información a las categorías adecuadas.

Esta categorización de la información haría que las entidades pudieran localizar de forma más eficiente la información que buscan. De esta manera en sus consultas las entidades podrán filtrar la información en función de las categorías que requieran. Por ejemplo los equipos con sistema operativo Windows podrían


estar interesados en toda información etiquetada en la categoría windows, y un repositorio de software en toda información etiquetada con software.

Figura 35. Relación entre las distintas clases del registro.

Para el caso de un modelo basado en eventos las entidades, al registrarse, tendrían que subscribirse a las categorías en las que tengan algún interés. De esta forma, cuando se registra un nuevo paquete de información en el registro, el propio registro enviaría un aviso a todas las entidades suscritas a alguna categoría a la que perteneciera dicho paquete de información (figura 35).

En este esquema las categorías actúan como un eje central que permite relacionar entidades e información en función de sus intereses (ver figura 36).

Figura 36. Esquema de la relación entre entidades, información y categorías.

En algunos casos existirán entidades que estarán interesadas en todos los paquetes de información, por ejemplo repositorios


generales de información o una entidad de registro secundaria. Para estos casos existirá una categoría virtual que denominaremos global y que estará asociada de forma automática a todos los Paquetes de Información. De esta forma, cuando una entidad se suscriba a la categoría global recibirá un aviso con la publicación de todos los paquetes de información. El uso de la suscripción a esta categoría deberá ser utilizado con medida ya que podría comprometer la escalabilidad del sistema de registro.

En el modelo de distribución de la información, el otro aspecto que permite guiar la gestión de los Paquetes de Información es la prioridad. Al registrar una entidad un Paquete de Información indica cuál es la prioridad de dicho paquete. Mediante este valor otra entidad puede decidir si transfiere o no dicho paquete. Por ejemplo un repositorio de software, al detectar la presencia de un nuevo Paquete de Información de interés, decidirá que lo transfiere sólo en el caso de que la prioridad supere un determinado umbral. En otros casos la prioridad también podrá ser utilizada para que, en caso de no disponer de más espacio de almacenamiento, un repositorio descarte los paquetes cuyo prioridad sea inferior, y así poder obtener y almacenar paquetes de prioridad más alta.

MIB-Registry

Dado que vamos a instanciar nuestro modelo utilizando el MIB de SNMP hemos realizado un proceso de adaptación de los objetos de registro para conformar el MIB-Registry. El proceso puede verse ilustrado en la figura 37.

Figura 37. Proceso de creación del MIB-Registry.

Básicamente tendrá tres ramas una donde residirán objetos que permitirán la gestión de la propia entidad de descubrimiento


(management), otra donde se gestionaran las entidades (entity) y una última donde se gestionaran los paquetes de información (information). Dentro de las dos últimas ramas cada uno de ellas se desglosará en dos ramas, una para la publicación (publish) y otra para la consulta (inquiry). Este esquema se desglosa en la figura 38. El subárbol de descubrimiento estará referenciado en el MIB-II de SNMP dentro de la rama experimental.

Figura 38. Esquema general del MIB-Discovery.

En la rama entity (figura 39) encontraremos la información necesaria para gestionar la publicación y consulta de las diferentes entidades que se encuentran en el sistema.

Dentro de la rama entity, la rama publish aporta los objetos necesarios para realizar la publicación de una entidad. Para ello la entidad que desea publicarse deberá establecer los datos de registro en los diversos objetos que se encuentran en la rama publish. Una vez establecido dichos valores se establecerá el valor del objeto action a 1, lo cual materializará la publicación de la entidad. Al ser la propia entidad la que se auto-registra, no será nexesario indicar la dirección IP y el puerto que se utilizará para la publicación ya que estos datos podrán ser obtenidos del mismo proceso de comunicación.

experimental

registry

management(0) entity(1)

publish(0) inquiry(1)

information(2)

publish(0) inquiry(1)


Figura 39. Rama entity del subárbol registry.

El campo action nos permite además realizar otras operaciones sobre el registro: eliminar entradas, actualizarlas o renovar timeout. La tabla 8 resume estas acciones. En la tabla se indica qué campos son obligatorios y cuales son optativos o ignorados.

registry

entity(1)

publish(0)

action(0)

status(1)

eid(2)

type(3)

name(4)

description(5)

timeout(6)

topic(7)

inquiry(1)

entitiesNumber(0) entities(1)

eid(0)

name(1)

description(2)

type(3)

ip(4)

port(5)

filter(2)

eid(0)

name(1)

description(2)

type(3)

ip(4)

port(5)

topic(6)


Tabla 8. Operaciones de gestión de entidades.

Acción

Valo

r

Descripción

Campos

eid

type

nam

e

descrip

tion

tim

eout

topic

None 0 Sin acción. ▬ ▬ ▬ ▬ ▬ ▬

New 1 Nueva entrada. ■ ■ ■ □ □ ▬

Delete 2 Elimina una entrada. La entrada es identificada por el EID.

■ ▬ ▬ ▬ ▬ ▬

Update 3 Actualiza una entrada. La entrada es identificada por el EID.

■ ▬ □ □ □ ▬

Renew 4 Renueva el timeout de una entrada. La entrada es identificada por el EID.

■ ▬ ▬ ▬ ■ ▬

TopicAdd 5 Subscribe la entidad a una categoría de información.

■ ▬ ▬ ▬ ▬ ■

TopicDel 6 Quita la subscripción de la entidad a una categoría de información.

■ ▬ ▬ ▬ ▬ ■

■ Campo obligatorio □ Campo opcional ▬ Campo ignorado

Una vez se establezca el campo action a un valor la acción correspondiente será realizada y posteriormente el valor status podrá ser consultado para comprobar el resultado de la acción. Un valor 0 indicará que la operación ha sido realizada con éxito. Cualquier otro valor indicará un error en la misma. En la tabla 9


se puede ver los diferentes valores que puede tomar status, en función de la acción que se realiza.

Tabla 9. Códigos de resultado de las operaciones sobre entidades.

Valor Descripción

0 Acción realizada correctamente

1 Código de acción incorrecto

2 Error general

3 No existe la entidad

4 Error en un campo

Dado que para hacer una acción será necesario realizar varias operaciones, y para evitar que acciones paralelas interfieran entre si, por ejemplo dos altas simultáneas, la Entidad de Registro gestionará cada una de las acciones en un contexto distinto, de forma que se puedan realizar acciones en paralelo sin interferirse.

Posteriormente, una vez registradas las entidades, cualquier entidad podrá consultar que entidades están presentes en el sistema. Para ello en la rama inquiry contiene un objeto entities que es una vector de entidades con los datos de sólo lectura descritos en la tabla 6. El número de entidades que hay en el vector está disponible en el objeto entitiesNumber.

Para facilitar las labores de búsqueda en la rama entity también existe un objeto filter que me permite filtrar los datos de entidades a consultar. Cuando se establece algún valor en un objeto de filter el vector de entidades así como el entitiesNumber se actualiza en función del resultado del filtro. Si establezco más de un criterio de filtrado se combinan para obtener las entidades que cumplen todos los criterios.

De forma similar a las entidades podemos registrar y localizar los paquetes de información accesibles en nuestro sistema. Para ello en la rama discovery también tenemos una rama information con una funcionalidad similar a la de entity y que se muestra en la figura 40.


Figura 40. Rama Information del subárbol registry.

En este caso las acciones que se pueden realizar en la rama publish son las que se muestran en la tabla 10. Su funcionamiento es similar al de las acciones descritas para el caso de las entidades, actuando el campo action como identificador de la acción que se quiere realizar.

registry

information(2)

publish(0)

action(0)

iid(1)

size(2)

priority(3)

description(4)

url(5)

topic(6)

inquiry(1)

informationNumber(0) information(1)

iid(0)

size(2)

priority(3)

description(4)

url(5)

filter(2)

iid(0)

description(1)

protocol(2)

eid(3)

topic(4)


Tabla 10. Operaciones de gestión de información.

Acción

Valo

r

Descripción

Campos

iid

siz

e

prio

rit

y

descrip

tion

url

topic

None 0 Sin acción. ▬ ▬ ▬ ▬ ▬ ▬

New 1 Nueva entrada. ■ ■ ■ □ □ □

Delete 2 Elimina una entrada. La

entrada es identificada por

el IID.

■ ▬ ▬ ▬ ▬ ▬

Update 3 Actualiza una entrada. La

entrada es identificada por

el EID.

■ ▬ □ □ □ ▬

DescrAdd 4 Añade una descripción a la

información.

■ ▬ ▬ ■ ▬ ▬

DescrDel 5 Elimina una descripción a

la información. Si description está vacía borra

todas las descripciones.

■ ▬ ▬ □ ▬ ▬

UrlAdd 4 Añade una URL a la información.

■ ▬ ▬ ▬ ■ ▬

UrlDel 5 Elimina una descripción a

la información. Si url está

vacía borra todas las URLs.

■ ▬ ▬ ▬ □ ▬

TopicAdd 5 Añade una categoría a la

información.

■ ▬ ▬ ▬ ▬ ■

TopicDel 6 Elimina una categoría a la información. Si topic está

vacía borra todas las

categorías.

■ ▬ ▬ ▬ ▬ □

■ Campo obligatorio □ Campo opcional ▬ Campo ignorado


Información

Hemos visto como nuestro modelo refleja en el MIB-Registry la información necesaria para publicar y descubrir Paquetes de Información así como Entidades. Dado que el registro es una pieza opcional de nuestro sistema, también es necesario proponer algún mecanismo que permita a una entidad exponer a otra entidad que Paquetes de Información gestiona, sin necesidad de usar un registro. Para ello toda entidad que gestione información extenderá su MIB con un subárbol específico para tal efecto que denominaremos MIB-Information.

MIB-Information

La extensión del MIB para la información reflejará los objetos necesarios para que se pueda consultar los Paquetes de Información que una entidad gestiona. El proceso de creación de este MIB, al igual que el del MIB-Registry, partirá de los objetos, en este caso los relacionados con la información, y siguiendo el estándar SNMP se confeccionara el MIB-Information (ver figura 41).

Figura 41. Proceso de creación del MIB-Information.

En este caso el MIB-Information sólo tendrá una interfaz de consulta, ya que no será necesario ofertar un interfaz de publicación al tratarse de registros internos.

El resultado del proceso puede verse en la figura 42. Su funcionamiento es similar al de la rama inquiry de la rama information del MIB-Registry.

Creación deMIB-Information

Objetos de información

MIB-Information

«objetivo»Obtener un MIB

para la información

«abstracto»

MODELO SNMP

«control»


Figura 42. Rama information.


En el modelo de comunicaciones definen los procesos y protocolos de comunicación utilizados por las entidades del sistema.

Como se indicó en el Modelo de Organización existen tres tipos de protocolos: el de gestión, el de descubrimiento y los de transporte. En nuestro caso y dado que hemos reflejado el descubrimiento dentro del propio MIB de SNMP, tanto el protocolo de gestión como el protocolo de descubrimiento coincidirán en SNMP. En cuanto a los protocolos de transporte estos serán tratados en profundidad en los capítulos 4 y 5.

information(2)

informationNumber(0) information(1)

iid(0)

size(2)

priority(3)

description(4)

url(5)

filter(2)

iid(0)

description(1)

protocol(2)

eid(3)

topic(4)


Protocolo de Gestión

Conceptualmente la comunicación entre las distintas entidades se realiza mediante el paso de mensajes, actividad que es realizada a través de la red de comunicaciones.

Formalizaremos el paso de mensajes mediante dos funciones: una para enviar mensajes a la red, sndMsg, y otra para recibir mensajes desde la red. Cuando una entidad, conocida como emisor o srcEntity, envía un mensaje establece cual es la entidad destinataria del mismo, conocida como destinatario o dstEntity.

Figura 43. Paso de mensajes entre entidades.

En el modelo, el paso de mensajes es no confiable, es decir, el hecho de que una entidad envíe un mensaje a otra entidad no implica que esta reciba el mensaje. Esto refleja la conducta normal de las redes de comunicaciones donde la transferencia de información no siempre puede ser garantizada. En caso de pérdida tanto la entidad origen como la destino no son conscientes de esta pérdida. Por ello las entidades destinatarias, ante la recepción de un mensaje, deberán contestar con otro mensaje de confirmación o asentimiento (ACK) o bien con un mensaje de respuesta, cuando se quiere garantizar la confiabilidad. El control de errores, por tanto, deberá ser gestionado por la entidad origen. Si un mensaje se pierde en la red o se pierde el mensaje de confirmación o respuesta, el emisor del mensaje será responsable de, pasado un tiempo sin recibir confirmación alguna, reenviar el mensaje asumiendo que éste ha

srcEntity network dstEntity

sndMsg(msg)transmit

rcvMsg

transmitsndMsg(response)

rcvMsg

ds Message Transfer


sido perdido. En este esquema clásico de la comunicación entre procesos es posible que un destinatario reciba por duplicado un mismo mensaje, ya que los retardos en la comunicación pueden producir un retraso en la contestación que puede ser interpretado por el emisor como un error de comunicación.

Figura 44. Paso de mensajes con confiabilidad.

Protocolo de Gestión SNMP

El protocolo SNMP está fundamentado en el envío de mensajes, normalmente encapsulados en un paquete UDP. Cada mensaje o paquete SNMP está compuesto por dos partes básicas, una cabecera y un cuerpo o DPU.

Cada cabecera es dependiente de la versión del protocolo que se está utilizando. En este capítulo vamos a describir la versión 3 del protocolo que es la más reciente hasta la actualidad.

Cabecera SNMP

El protocolo SNMP en su versión 3 define una cabecera común para todos mensajes que se envían. Esta cabecera precede a la

srcEntity network dstEntity

sndMsg(msg)

transmit

rcvMsg

transmit

sndMsg(response)

rcvMsg

loop

[1..n]

transmit

alt

alttransmit

ds Message Transfer

[1..n]


unidad de Datos de Protocolo (Protocol Data Units – DPU) donde se codifican los datos del mensaje SNMP. [RFC 2572]

Tabla 11. Campos de la cabecera SNMP.

Campo Tipo Descripción

version ENTERO Versión del protocolo.

idMensaje ENTERO Identificador del mensaje. Se utiliza para coordinar los mensajes de respuestas con los de petición. Un mensaje de respuesta tendrá el mismo msgID

que su solicitud. Los valores de msgID deben ser generados de forma que se intente evitar la reutilización de valores usados, por ejemplo mediante el uso de valores incrementales.

tamMaximo ENTERO Tamaño de mensaje máximo soportado. Indica al receptor del mensaje el tamaño máximo de mensaje que puede utilizar para la respuesta.

opciones BYTE Contiene algunas opciones en formato de flag para el procesado del mensaje. Mediante los flags se establece si el mensaje incluye autorización (primer bit) y/o cifrado de datos (segundo bit).

modeloSeguridad ENTERO Especifica el modelo de seguridad que se utiliza.

parametrosSeguridad BYTE[] Parámetros de seguridad dependientes del modelo de seguridad seleccionado.

idMotor BYTE[] Identificador del motor, en la práctica identifica la entidad.

contexto BYTE[] Nombre del contexto utilizado.


La cabecera de SNMP v.3 consta de los campos descritos en la tabla 11.

Cuerpo del Mensaje

El cuerpo del mensaje en SNMP básicamente contiene una serie de campos. Cada campo en el protocolo se codifica como se ilustra en la figura 45.

Figura 45. Codificación de un campo en SNMP.

El campo type indica el tipo de campo (entero, cadena, OID, etc.)

y el campo length el tamaño de los datos. Por último en data se encuentra el contenido en si del campo. Mediante un tipo de

datos SEQUENCE podemos indicar que en el campo data hay una lista de otros campos. Usando este esquema recursivo se pueden definir datos complejos.

Figura 46. Codificación de un campo complejo en SNMP.

Mensajes

El protocolo de gestión utiliza un conjunto de mensajes que permiten la realización de las tareas de gestión y que se codifican en la PDU de los paquetes.

Los mensajes utilizado por SNMP están resumidos en la tabla 12 (Presuhn et al., 2002).

Mediante los mensajes el sistema puede llevar a cabo las distintas operaciones que se definen para el protocolo de gestión

Operaciones

Mediante los mensajes las entidades del sistema de gestión puede realizar operaciones entre ellas.

type length data

type length

data

type length data type length data

SEQUENCE (0x30)


Tabla 12. Mensajes de SNMP.

Mensaje Descripción GetRequest Solicita leer un valor del MIB de la entidad

destino. GetNextRequest Solicita el siguiente valor del MIB. Permite realizar

una consulta de recorrido en el árbol. GetBulkRequest Solicita un conjunto de valores del MIB. SetRequest Solicita modificar valor del MIB de la entidad

destino Response Respuesta de una petición. Trap Envía un aviso a una entidad que no requiere

respuesta. InformRequest Envía un aviso a una entidad que requiere

respuesta.

Las operaciones pueden ser de dos tipos: comandos que son operaciones que tienen respuesta o notificaciones, que no tienen respuesta. El tipo de cada operación está en función de la naturaleza de la misma.

En la tabla 13 se describen las operaciones que se pueden realizar indicando cuál es el mensajes de solicitud y cuál el de respuesta.

Tabla 13. Operaciones de SNMP.

Operación Solicitud Respuesta

GET GetRequest Response

SET SetRequest Response

GETNEXT GetNextRequest Response

GETBULK GetBulkRequest Response

TRAP Trap

INFORM Inform Response

Básicamente el protocolo permite leer (GET) o modificar (SET) un

objeto de gestión o bien enviar notificaciones síncronas (INFORM) o

asíncronas (TRAP). Las operaciones GETNEXT y GETBULK permiten optimizar la lectura secuencial de varios objetos de gestión.


Modelo funcional

El modelo funcional describe las cinco áreas en las que tradicionalmente se ha dividido la gestión de red: gestión de fallos, gestión de la configuración, gestión de prestaciones, gestión de contabilidad y gestión de seguridad (figura 47). A este modelo se le conoce normalmente por el acrónimo de FCAPS (Fault, Configuration, Accounting, Performance, Security).

Figura 47. Áreas del modelo funcional

Gestión de Fallos

El objetivo de la gestión de fallos es la detección, aislamiento, corrección y registro de operaciones anormales que ocurren en el sistema.

Determinar el máximo de información posible sobre los fallos es un elemento fundamental para su buena gestión. Por ello el sistema de gestión de fallos está muy asociado con la monitorización de los elementos del sistema, para detectar un cambio en el estado de alguno de ellos.

Otro aspecto importante a contemplar es el análisis de tendencias para poder predecir errores e intentar garantizar que la red siempre está disponible.

Modelo Funcional

Gestión de Fallos

Gestión de la configuración

Gestión de cuentas

Gestión del rendimiento

Gestión de la seguridad


Cuando una entidad de gestión detecta un fallo en un componente está enviará una notificación a una entidad de control para que, en la medida de lo posible, realice las acciones pertinentes que solventen dicho fallo.

En función de la notificación recibida la entidad de control identificará el fallo producido. Es posible que un mismo fallo produzca múltiples notificaciones, incluso notificaciones provenientes de entidades de gestión distintas. Es por ello que la entidad de control deberá realizar un proceso de correlación que permita asociar notificaciones relacionadas con un mismo fallo.

Una vez correlacionadas las notificaciones la entidad de control podrá tener una hipótesis del fallo producido. A partir de ese momento podrá realizar pruebas de localización para obtener más información sobre el fallo.

Finalmente, una vez localizado el fallo, la entidad de control podrá realizar las acciones correctivas pertinentes y posteriormente validar el corrección.

Figura 48. Fases de la gestión de fallos.

La figura 48 ilustra el proceso de gestión de fallos.

Gestión de la Configuración

La gestión de configuración es un conjunto de facilidades que permiten controlar, identificar, recoger y proporcionar datos de configuración a elementos gestionados. Entre las tareas relacionadas se puede destacar la definición de información de configuración en los recursos, la modificación de las propiedades de los recursos, la definición y modificación de relaciones entre los recursos, la inicialización y terminación de servicios de red o bien la distribución de software.

Todos los cambios de hardware y de software son coordinados a través de este proceso incluido la instalación de nuevas aplicaciones o equipamiento, la modificación de sistemas existentes y la eliminación de sistemas y programas obsoletos.

Recepción Notificaciones

Correlación Localización Corrección Validación


Según las redes incrementan su tamaño, una terea importante es la configuración automatizada. Mediante la automatización se intenta minimizar la relación del sistema de gestión con los administradores, de forma que las tareas de administración se realicen con altos grados de autogestión.

Gestión de Cuentas

La gestión de cuentas o tarificación son un conjunto de procedimientos que permiten medir y gestionar el uso de determinados elementos e identificar costes por el uso de éstos

El objetivo es reunir estadísticas sobre usuarios y otros elementos del sistema y su relación que el consumo de recursos que realizan: utilización de disco, consumo de memoria, tiempo de CPU, conexiones, etc.

En esta área se engloban también las operaciones de gestión de usuarios (usuarios, contraseñas y permisos) operaciones sobre equipos y servicios como realizar copias de seguridad y la sincronización y también labores de inventario.

Gestión del Rendimiento

La gestión del Rendimiento hace referencia al conjunto de procedimientos dedicadas a evaluar el comportamiento de elementos gestionados y la efectividad de determinadas actividades. Entre los indicadores de prestaciones se pueden definir los que están orientados al servicio, como la disponibilidad, el tiempo de respuesta, y la fiabilidad. En cambio, otros indicadores están orientados a la eficiencia o al grado de utilización.

La gestión del rendimiento permite los administradores planificar la red para el futuro, así como a determinar la eficiencia de la red actual, por ejemplo, en relación con las inversiones realizadas para establecerla.

Algunos parámetros de red que se miden en la gestión del rendimiento son el porcentaje de utilización, las tasas de error y los tiempos de respuesta. Recolectando y analizando estos datos se pueden detectar problemas o tendencias de capacidad o fiabilidad y a que servicios está afectando.


Se pueden establecer umbrales de rendimiento que serán utilizados lanzar una alarma. La alarma sería notificada y gestionada por el proceso de gestión de fallos

Gestión de la Seguridad

La gestión de seguridad está relacionada con todos los elementos asociados a la seguridad en los recursos de la red: generación, distribución y almacenamiento de claves de cifrado, información de usuarios y contraseñas, control de acceso y autorización. La gestión de seguridad no hace referencia a la propia seguridad del sistema de gestión, si no a la seguridad de los sistemas que gestiona.

En este área se proporcionan facilidades para incorporar mecanismos de seguridad contra los ataques a las comunicaciones, como protección contra interrupción del servicio, captura no autorizada de información, modificación de información o suplantación de entidad.

95

C a p í t u l o 4

Arquitectura del Sistema

En el capitulo anterior se ha desarrollado un modelo de gestión que define conceptual y formalmente la metodología empleada para posibilitar que múltiples entidades de gestión puedan funcionar de forma integrada para llevar a cabo las tareas de gestión.

El presente capítulo se dedica a la propuesta de una arquitectura de sistema de gestión de redes que permita la viabilidad del modelo propuesto utilizando la tecnología existente. Se realiza una justificación de la conveniencia de utilizar enfoques distribuidos y se describen los módulos funcionales junto con su estructura organizativa y los mecanismos de comunicación que emplean.

Como se vio en el Modelo de Organización del capítulo anterior el sistema de gestión es un sistema distribuido donde existen un conjunto de entidades repartidas por toda la red a gestionar que trabajan de forma colaborativa para realizar las tareas de gestión. Todas estas entidades de gestión tienen muchas características en común: protocolos de comunicación, sistemas de seguridad, tratamiento de la información.

Cuando se afronta un problema de sistemas distribuidos una de las soluciones más exitosas que existen en la actualidad es el uso de Middlewares. El Middleware nos proporciona una capa de abstracción intermedia entre las aplicaciones, en nuestro caso aplicaciones de gestión, y los dispositivos, en nuestro caso los


dispositivos a gestionar y los dispositivos de soporte. El Middleware nos abstrae de la heterogeneidad de los distintos dispositivos, sistemas operativos y redes de comunicaciones y nos da una visión unificada de todos ellos mediante un API común (ver figura 49).

Figura 49. Esquema de uso de un middleware.

En un entorno realista, para llevar a cabo el Middleware de nuestro sistema de gestión es necesario incorporar en cada uno de los dispositivos que conforman la Capa Física los servicios necesarios del Middleware y el entorno de ejecución pertinente para dar soporte al ciclo de vida de las aplicaciones de la Capa de Aplicación. Para ello proponemos la creación de un contenedor de aplicaciones de gestión que implemente el Middleware para cada uno de los dispositivos del sistema. Existirá una implementación del contenedor para cada tipo de dispositivo que tengamos: por ejemplo implementaciones para sistemas Linux e implementaciones para sistemas Windows.

Capítulo 4. Arquitectura del Sistema 97

Figura 50. Uso de contenedores.

La definición de una arquitectura para el sistema propuesta pasa pues por establecer un contenedor que implemente los servicios de nuestro Middleware, así como definir que aplicaciones conformarán nuestro sistema (figura 50). Dado que el Middleware será común para todas las entidades del sistema, si bien en algunos casos algunos servicios pueden no estar presentes, lo que caracterizará a cada una de las entidades serán las aplicaciones que se ejecuten en su contenedor.

Definiremos cada aplicación que conforma la capa de aplicación como un componente software independiente y, en algunos casos, con capacidad de acción proactiva, por lo que a nivel formal las denominaremos Agentes de Gestión. Si bien la palabra agente en otros entornos tiene determinadas connotaciones, en nuestro caso utilizamos el término agente en su definición más general, es decir, una entidad software con un cierto grado de autonomía que interactúa con otros agentes para llevar a cabo sus tareas.

En la figura 51 podemos ver la propuesta de arquitectura para cada una de las entidades de gestión.


Figura 51. Arquitectura de una entidad.

La Capa Física, situada en la parte inferior de la imagen, la compone la plataforma que sustenta todo el sistema de gestión. Dicha capa puede ser vista desde dos puntos de vista diferentes. Desde el punto de vista del contenedor, es la capa que da soporte de ejecución a las capas superiores de Middleware y Aplicación. Desde el punto de vista de la entidad de gestión es la capa donde reside los elementos que tiene que gestionar: dispositivos hardware, sistemas operativos, aplicaciones, servicios o la información.

Como punto de partida para la arquitectura nos basaremos en la arquitectura propuesta en SNMP versión 3. En esta especiación se describe la arquitectura básica de cada entidad del sistema de gestión de forma que ayuda a separa las diferentes partes de las entidades y facilita la implementación de sistemas basados en ellos (Harrington et al., 2002).

Middleware del sistema de gestión

El Middleware del Sistema de Gestión estará compuesto por dos áreas bien diferenciadas (ver figura 52). Por una parte los


relacionados con el sistema de gestión en sí compuesto por un Motor SNMP y por un conjunto de Servicios SNMP. Estos dos bloques aportarán a los agentes la capacidad de interactuar con otros agentes mediante el protocolo SNMP. La otra área del Middleware es responsable de realizar la transferencia de información y estará compuesto por un Motor de Transferencia y los Servicios de Transferencia Masiva.

Figura 52. Middleware del sistema de gestión.

A continuación se describen los diferentes bloques que componen el Middleware y la relación entre ellos.

Área de Gestión

Motor SNMP

El Motor SNMP es el núcleo principal para la gestión de los mensajes del protocolo de gestión.

El motor está compuesto por cinco módulos fundamentales de la arquitectura de gestión propuesta y que pueden verse en la figura 53.

Subsistema de Transporte: responsable de enviar y recibir los mensajes.

Distribuidor: encargado de gestionar la entrada y salida de mensajes.

Subsistema de Procesado de Mensajes: para el procesado de los mensajes.


Subsistema de Seguridad: donde se aglutinan las operaciones de seguridad.

Control de Acceso: responsable de gestionar el acceso al MIB.

Figura 53. Motor SNMP.

A continuación describiremos cada uno de estos elementos.

Subsistema de Transporte

Los mensajes SNMP que utilizaremos podrán ser enviados utilizando diversos protocolos de transporte como UDP o TCP, incluso protocolos seguros con cifrado de datos como SSH o TSL. El Subsistema de Transporte es el encargado de gestionar esta tarea, encapsulando los mensajes SNMP en el protocolo que las aplicaciones de gestión decidan (ver figura 54). El subsistema incluirá los diferentes módulos necesarios para el trabajo con los distintos protocolos de transporte utilizados.

Figura 54. Subsistema de Transporte del Motor SNMP.

Motor SNMP

DistribuidorSubsistema

de Procesado

de Mensajes

odule

Módulo Procesado

Mensajes

Subsistema

de Seguridad

Security Module

Security Module

Módulo Seguridad

Control de

AccesoSubsistema

de

Transporte


Si bien algunos protocolos de transporte permitidos son orientados a conexión, esto no afectará al uso de SNMP, que está orientado a paso de mensajes, es decir, que en cualquier caso a nivel de SNMP no se gestionará ninguna sesión, a excepción de la relación entre una petición y su respuesta.

El interfaz aportado por el Subsistema de Transporte se puede ver en la tabla 14.

Tabla 14. API del Subsistema de Transporte.

Nombre Descripción / Sintaxis

enviarMensaje Envía un mensaje a por la red. Se encarga de codificar el mensaje según el protocolo de transporte.

recibirMensaje Recibe un mensaje de la red. Extrae el mensaje SNMP del protocolo de transporte.

En método enviarMensaje manda un mensaje mediante el protocolo de transferencia establecido.

Figura 55. Diagrama de actividad del método recibirMensaje.


El método recibirMensaje lee un mensaje de la red mediante el protocolo de transferencia establecido.

La figura 55 representa un diagrama de actividad con la

estructura básica del método recibirMensaje.

El Subsistema de Transporte enviará bajo demanda los mensajes que le indique el Distribuidor y estará continuamente leyendo mensajes de la red y pasándoselos al distribuidor para que coordine su análisis y entrega final a la aplicación adecuada.

Distribuidor

El Distribuidor actúa como punto central del sistema coordinando el flujo de mensajes en el motor de gestión. El Distribuidor es el punto de entrada al Motor SNMP para los Servicios SNMP. Las actividades que lleva a cabo el distribuidor son:

Enviar mensajes de gestión hacia la red (a través del Subsistema de Transporte) con otra entidad del sistema como destinatario. Para ello proporciona una interfaz abstracta a las aplicaciones de gestión.

Recibir mensajes de gestión desde la red (a través del Subsistema de Transporte) de comunicaciones provenientes de otra entidad del sistema. Para ello proporciona una interfaz abstracta a las aplicaciones de gestión para obtener mensajes.

Determinar la versión del protocolo indicada en el mensaje e interactuar con el correspondiente Módulo de Procesado de Mensajes para esa versión.

Figura 56. Distribuidor del Motor SNMP.


Dado que es el elemento coordinador de la entidad existirá un único Distribuidor por cada motor (ver figura 56).

El Distribuidor mientras envía y recibe mensajes de gestión, recolecta estadísticas sobre los mensajes y el comportamiento del propio motor. Esta información puede ser ofertada en el MIB de forma que otra entidad podría acceder a dicha información.

El Distribuidor tendrá la interfaz descrita en la tabla 15 para llevar a cabo su labor.

Tabla 15. API del Distribuidor.

Método Descripción

enviarPDU Envía un mensaje a una entidad.

registrarServicio Asocia un servicio a un tipo de mensaje.

analizarMensaje Analiza un mensaje recibido.

Para el envío de mensajes el Distribuidor cuenta con el método

enviarPDU que a partir de una PDU genera un mensaje completo. Para ello previamente le indica al Subsistema de Procesado de Mensajes que cree el mensaje indicando la versión del protocolo y el tipo de seguridad. Posteriormente envía el mismo con el

método enviarMensaje del Subsistema de Transporte.

Cuando se recibe un mensaje el Subsistema de Transporte invoca

el método analizarMensaje del Distribuidor. El Distribuidor extra la PDU mediante el Subsistema de Procesado de Mensajes e invoca al servicio adecuado. Para ello los servicios registran que tipo de mensajes pueden procesar mediante el método

registrarServicio.

Subsistema de Procesado de Mensajes

El Subsistema de Procesado de Mensaje (figura 57) es el responsable de componer los diferentes mensajes del protocolo de gestión, así como de extraer los datos del mismo una vez son recibidos por la entidad.


Figura 57. Subsistema de Procesado de Mensajes del Motor SNMP.

Este subsistema engloba un conjunto de al menos un Módulo de Procesado de Mensajes, normalmente uno por cada versión del protocolo que soporte la entidad. Cada módulo por lo tanto conoce las peculiaridades de cada versión del protocolo.

El API de este subsistema se puede ver en la tabla 16.

Tabla 16. API del Subsistema de Procesado de Mensajes.


crearMensaje Crea un mensaje a partir de su PDU y una versión.

obtenerPDU Extrae el PDU de un mensaje en función de la versión.

Básicamente tenemos el método crearMensaje que dado una PDU

y una versión crea el mensaje adecuado y obtenerPDU que realiza la operación contraria, coge un mensaje y extrae su PDU.

Subsistema de Seguridad

En el Subsistema de Seguridad se encuentran los diferentes servicios asociados con la autenticación y privacidad en el envió de mensajes (Figura 58).

Motor SNMP


de Procesado

de Mensajes

odule

Módulo Procesado

Mensajes

Subsistema

de Seguridad

Security Module

Security Module

Módulo Seguridad

Control de

AccesoSubsistema

de

Transporte


Figura 58. Subsistema de Seguridad del Motor SNMP.

El subsistema puede estar compuesto por diversos Módulos de Seguridad. Cada Módulo de Seguridad especifica las amenazas contra los que protege, los objetivos de sus servicios, y los Protocolos de Seguridad que se utilizan para proporcionar servicios de seguridad como la autenticación y la privacidad.

Los Protocolos de Seguridad especifican los mecanismos, procedimientos y objetos del MIB usados para proveer servicios de seguridad como los de autenticación y privacidad.

Para el servicio de autenticación se utiliza un sistema basado en usuarios y contraseñas. Para evitar el envío de la contraseña en abierto se pueden utilizar algoritmos como MD5 o SHA.

Para la privacidad se pueden utilizar algoritmos de cifrado como DES que permiten enviar los mensajes de forma segura.

Tabla 17. API del Subsistema de Seguridad.


aplicarSeguridad Aplica un tipo seguridad en un mensaje.

resolverSeguridad Resuelve (descifra) la seguridad aplicada en un mensaje.

El API de este bloque (Tabla 17) está compuesto por dos métodos

uno que aplica la seguridad cifrando los datos (aplicarSeguridad) y otra de descifra en función del tipo de seguridad

(resolverSeguridad).

Motor SNMP


de Procesado

de Mensajes

odule

Módulo Procesado

Mensajes

Subsistema

de Seguridad

Security Module

Security Module

Módulo Seguridad

Control de

AccesoSubsistema

de

Transporte


Subsistema de Control de Acceso

El Subsistema de Control de Acceso proporciona servicios de autorización que indica a los Servicios SNMP si data una operación y unos credenciales se puede acceder o no a un aparte del MIB.

Figura 59. Subsistema de Control de Acceso del Motor SNMP.

El subsistema se define como una función de decisión para el acceso con el fin de apoyar las decisiones con respecto a los derechos de acceso (ver tabla 18).

Tabla 18. API del Subsistema de Seguridad.


validar Valida el acceso o no de un tipo de operación a una zona del MIB.

Servicios SNMP

Los Servicios SNMP son módulos que interrelacionan los agentes con el Motor SNMP (figura 60). Los cinco servicios que utiliza el protocolo de gestión son:

Generador de Comandos

Respondedor de Comandos

Generador de Notificaciones

Servicios SNMP

Motor SNMP


de Procesado

de Mensajes

odule

Módulo Procesado

Mensajes

Subsistema

de Seguridad

Security Module

Security Module

Módulo Seguridad

Subsistema

de Control

de Acceso

Generador de

comandos

Respondedor

de comandos

Generador de

Notificaciones

Receptor de

NotificacionesProxy

Subsistema

de

Transporte


Receptor de Notificaciones

Proxy

A continuación se describen en profundidad cada uno de ellos.

Figura 60. Servicios SNMP.

Generador y Receptor de Comandos

El Generador de Comandos gestiona el envío de solicitudes y la recepción de respuestas de operaciones de tipo comando (confiables) mientras que en el Receptor de Comandos se reciben dichas solicitudes y se emiten las respuestas (figura 61).

Servicios SNMP

Motor SNMP


de Procesado

de Mensajes

odule

Módulo Procesado

Mensajes

Subsistema

de Seguridad

Security Module

Security Module

Módulo Seguridad

Subsistema

de Control

de Acceso

Generador de

comandos

Respondedor

de comandos

Generador de

Notificaciones

Receptor de

NotificacionesProxy

Subsistema

de

Transporte

Agentes


Figura 61. Generador y Respondedor de Comandos.

Es en Generador de Comandos es donde se genera la PDU de la solicitud y donde se gestiona el reenvío de la petición en caso de no recibir la respuesta en un tiempo determinado (figura 62).

Figura 62. Relación entre el Generador y el Respondedor de Comandos.

El API del Generador de Comandos tendrá una función por cada operación de tipo comando que existe (tabla 19).

Servicios SNMP

Motor SNMP


de Procesado

de Mensajes

odule

Módulo Procesado

Mensajes

Subsistema

de Seguridad

Security Module

Security Module

Módulo Seguridad

Subsistema

de Control

de Acceso

Generador de

comandos

Respondedor

de comandos

Generador de

Notificaciones

Receptor de

NotificacionesProxy

Subsistema

de

Transporte

Agentes


Tabla 19. API del Generador de Comandos.


get Realiza el comando petición/respuesta GET.

set Realiza el comando petición/respuesta SET.

getnext Realiza el comando petición/respuesta GETNEXT.

getbulk Realiza el comando petición/respuesta GETBULK.

inform Realiza el comando petición/respuesta INFORM.

El Generador de comandos también contempla una configuración para establecer el número de reintentos y los tiempos de espera a la hora conseguir confiabilidad (figura 63).

Figura 63. Esquema de la solicitud y respuesta de un comando.

El Respondedor de Comandos interactúa con el Generador de Comandos para llevar a cabo una operación de tipo comando.


Tabla 20. API del Respondedor de Comandos.


subscribir Suscribe una aplicación para gestionar un subárbol del MIB.

responder Responde a una petición.

El API del Respondedor de Comandos módulo (tabla 20) tiene un método subscribir que permite a una aplicación registrar un árbol del MIB, de forma que le indica al Respondedor de Comandos que esa aplicación gestiona esa rama del subárbol (figura 64).

Figura 64. Esquema de la recepción y respuesta de un comando.

Generador y Receptor de Notificaciones

De forma similar a los anteriores el Generador de Notificaciones es el responsable de enviar operaciones de tipo notificación (no


confiables) que serán recibidas por el Receptor de Notificaciones (figura 65).

Figura 65. Generador y Receptor de Notificaciones.

En este caso ya que son operaciones no confiables no es necesario gestionar la respuesta (figura 66).

Figura 66. Esquema de envío y recepción de una notificcion.

Generador de

notificaciones

Receptor de

notificaciones

Motor

SNMP

Motor

SNMP

Protocolo

Transferencia

Protocolo de

Red

Protocolo

Transferencia

Protocolo de

Red

Mensajes

SNMP

TRASH


El API del Generador de Notificaciones tendrá una función por cada operación de tipo notificación que existe (tabla 21).

Tabla 21. API del Generador de Notificaciones.


trash Realiza el comando TRASH.

Por su parte el Receptor de Notificaciones interactúa con la aplicación que haya suscrito el árbol donde se sitúa el objeto del mensaje.

Tabla 22. API del Receptor de Notificaciones.


subscribir Suscribe una aplicación para gestionar un subárbol del MIB.

Proxy

Dado que en SNMP soporta el uso de agentes de gestión como proxy para la retransmisión de tramas SNMP en los servicios también se incluye uno que realiza estas labores.

Figura 67. Servicio Proxy.

Servicios SNMP

Motor SNMP


de Procesado

de Mensajes

odule

Módulo Procesado

Mensajes

Subsistema

de Seguridad

Security Module

Security Module

Módulo Seguridad

Subsistema

de Control

de Acceso

Generador de

comandos

Respondedor

de comandos

Generador de

Notificaciones

Receptor de

NotificacionesProxy

Subsistema

de

Transporte


El uso de un proxy puede ser útil en el caso de que tengamos dos redes gestionadas por versiones distintas de SNMP o que utilizan protocolos de transporte distintos. El agente proxy realizaría las traducciones necesarias entre ambas redes para que se pueda realizar la integración entre ambas redes.

El servicio proxy es independiente y no se comunica con ningún agente por lo que no requiere de ningún API.

Área de Transferencia

Motor de Transferencia

El Motor de Transferencia permite a la entidad de gestión realizar la transferencia de información desde o hacia otra entidad. El Motor de Transferencia soporta diversos protocolos de transferencia mediante los cuales se materializa el transporte de la información. Los diferentes protocolos soportados se clasifican en las siguientes áreas:

Clientes: Implementaciones de clientes de protocolos específicos.

Servidores: Implementaciones de servidores de protocolos específicos.

P2P: Implementaciones de sistemas basados en protocolos de tipo P2P.

Las implementaciones de tipo Servidores y P2P utilizan el Subsistema de Almacenamiento para obtener y/o almacenar la información a gestionar.

Figura 68. Motor de Transferencia.

Motor Transferencia

ClientesP2PServidores

Subsistema de Almacenamiento


El Subsistema de Almacenamiento actúa como un repositorio donde la información que gestiona una entidad puede almacenarse o accederse.

En si el Subsistema de Almacenamiento no es el lugar físico donde se almacena la información sino que trabaja como un interfaz que nos permite acceder a la información masiva que gestiona la entidad, haciendo transparente al resto del motor la manera en la que esta información es realmente almacenada (archivos, bases de datos, directorios, etc.).

El interfaz que aporta el Subsistema de Almacenamiento (Tabla 23) nos permite abrir y cerrar un recurso de almacenamiento, y leer o escribir sobre el.

Tabla 23. API del Subsistema de Almacenamiento.


leer Lee datos de un recurso.

escribir Escribe datos en un recurso.

Los módulos Clientes, Servidores y P2P implementan todos los protocolos de difusión de información soportados por la entidad.

Los Clientes podrán ser clientes de protocolos de aplicación como HTTP, FTP, SMTP o cualquier otro cliente que permita la transferencia de un flujo de información, incluido un cliente de SDTP (Simple Data Transfer Procotol) un protocolo especifico que será descrito en el siguiente capítulo.

Los Servidores serán implementaciones de servidores de protocolos de difusión como servidores HTTP, FTP o SMTP. Permiten a una entidad proporcionar la transferencia de paquetes de información. También es posible incorporar un servidor SDTP para la difusión optimizada de la información. Los módulos de Servidores son totalmente opcionales en la entidad y compatibles con otros servicios de transferencia del equipo, por ejemplo, se puede incorporar un módulo de HTTP en una entidad que gestiona un servidor web que a su vez tendrá su propio servidor HTTP. Los módulos incorporados no tendrán que implementar los protocolos al completo, sólo aquellas partes necesarias para la


difusión de información, por ejemplo, en el caso de HTTP la operación GET.

Por último también es posible incorporar protocolos basados en sistemas P2P que permitan a un agente obtener y compartir otros paquetes de información.

Tanto los módulos de Servidores como los de P2P utilizan el Subsistema de Almacenamiento para acceder a la información.

Servicios de Transferencia Masiva

Los Servicios de Transferencia Masiva (figura 69) permiten a los agentes obtener un paquete de información del sistema de gestión.

Figura 69. Servicios de Transferencia Masiva.

Dentro de este bloque encontramos dos únicos servicios: el Serviciode Provisión y el Servicio de Streaming. El objetivo de ambos es el mismo, dado una URL transferir dicha información hasta la entidad. Lo que los diferencia es que el Servicios de Provisión almacena el paquete de información mediante el Subsistema de Almacenamiento y el Servicio de Streaming devuelve un flujo con la información al agente que lo solicitó para que lo vaya procesando.

El Servicio de Streaming utilizará normalmente algún módulo cliente ya que estos normalmente trabajan transfiriendo un flujo de datos (Figura 70).

Servicio de

Provisión

Servicio de

Streaming

Servicios Transferencia Masiva


Figura 70. Streaming de datos utilizando protocolos cliente.

En el caso de utilizar un protocolo no orientado a streaming como protocolos P2P utilizará temporalmente el Subsistema de Almacenamiento para luego devolverlo como un flujo de información (figura 71).

Motor Transferencia

Servicio de

Provisión

Servicio de

Streaming

ClientesP2PServidores



Agentes



Figura 71. Streaming de datos utilizando protocolos P2P.

El servicio de provisión por su parte siempre almacena los datos recibidos (figura 72).

Figura 72. Almacenamiento de datos.

Servicio de

Provisión

Servicio de

Streaming

P2PServidores


Agentes



Motor Transferencia

Clientes


Servicio de

Provisión

Servicio de

Streaming

P2PServidores


Agentes


Motor Transferencia

Clientes


Agentes

Los agentes (figura 73) son las aplicaciones que se ejecutan sobre el middleware y que caracterizan a cada una de las entidades del sistema de gestión.

Figura 73. Agentes del sistema de gestión.

Dentro de cada entidad distinguiremos dos tipos de agentes, los Agentes de Utilería, comunes a todas las entidades y que realizan operaciones básicas sobre el sistema, dando apoyo a los Agentes Especializados que implementan las propias tareas de gestión. Por lo tanto los agentes específicos llevarán a cabo las labores de las 5 áreas definidas en el Modelo Funcional del capítulo 2.

De cada una de las 5 áreas del Modelo Funcional vamos a describir a modo de ejemplo un agente representativo, que además ilustre el uso de la difusión de la información dentro del sistema.

Agentes de Utilería

Los Agentes de Utilería que se incluyen en las entidades de gestión son:

Agente de Inicio

Agente de Configuración

Fallos Gestión Configuración Gestión Cuentas Gestión Rendimiento Gestión Seguridad

Servicios SNMP

Servicio de

Provisión

Servicio de

Streaming

Generador de

comandos

Respondedor

de comandos

Generador de

Notificaciones

Receptor de

NotificacionesProxy


Agentes

Ag. Supervisor Ag. Regeneración Ag. Inventario Ag. Monitorización Ag. Seguridad

Agentes Utilería

Ag. Inicio Ag. Configuración Ag. Transferencia Ag. Difusión Ag. Registro Ag. Publicación Ag. Descubrimiento


Agente de Transferencia

Agente de Difusión

Agente de Registro

Agente de Publicación

Agente de Descubrimiento

Estos agentes son la base de la entidad de gestión y podrán estar presente en todas las entidades, si bien algunos de ellos son opcionales.

A continuación vamos a ver en detalle cada uno de estos agentes.

Agente de Inicio

El Agente de Inicio es el responsable de inicializar la entidad. El agente interactúa primeramente con el Agente de Configuración, para configurar la entidad, y con el Agente de Publicación, para registrar el propio agente y su información en el sistema.

Este agente actúa como punto de entrada inicial de la entidad y coordina las labores asociadas con la puesta en marcha del servicio de gestión.

Agente de Configuración

El Agente de Configuración es el responsable de establecer la configuración inicial de la entidad. Este agente es el que decide, a partir de algún registro de configuración (posiblemente un archivo) datos como: puertos de comunicación, tipo de entidad, localización del registro de publicación, versión de SNMP a utilizar, tipo de protocolo de transporte, parámetros de seguridad, y cualquier otro valor de configuración.

Agente de Difusión

El Agente de Difusión es el responsable de registrar y habilitar el acceso a los paquetes de información que dispone la entidad. Para ello se comunica con los servidores implementados (tanto módulos de servicio estándar como de P2P) para que estos estén disponibles para otras entidades.


Agente de Publicación

El Agente de Publicación permite a las entidades registrarse a sí mismas en una entidad de registro, así como la información que puede suministrar. Para ello se pone en contacto con el Agente de Registro de una Entidad de Registro.

El Agente de Publicación es un agente activo que utiliza el Generador de Comandos para enviar comandos a la entidad de registro. Ofrece un API de publicación a otros agentes de la entidad que consta de los siguientes métodos recogidos en la tabla 24.

Tabla 24. API del Agente de Publicación.


entidadRegistrar Registra una entidad

entidadBorrar Borrar el registro de una entidad

entidadRenovar Renueva el registro de una entidad

informacionRegistrar Registra un paquete de información.

informacionBorrar Borra del registro una entrada de información

Para gestionar el registro de entidades tenemos dos métodos

principales: entidadRegistrar que registra una nueva entidad indicado su EID, un nombre, una descripción y su tipo, y

entidadBorrar que elimina dicho registro.

Cuando una entidad se inicia es responsable de auto-registrarse en una entidad de registro. Al finalizar, está también deberá borrar su registro para que el resto de entidades sepa que ya no está en el sistema. Para evitar que entidades que finalicen sin borrar su registro (por ejemplo porque han tenido una apagado inesperado o han perdido su conectividad de red), cada entidad es responsable de renovar su registro. Para ello agente de

publicación aporta el método entidadRenovar que permite renovar el registro del mismo. El Agente de Registro es responsable de borrar los registros que no hayan sido renovados en un periodo determinado de tiempo.


El método informaciónRegistrar permite registrar un paquete de información identificado mediante su IDD. Se indica un conjunto de URL desde donde se podrá acceder a la información y un conjunto de descripciones (nombre de archivos, comentarios, aclaraciones, etc.) que permitirán a otro usuario poder buscar dicha información.

El método informacionBorrar elimina la entrada de registro asociada al paquete de información indicado mediante su IID. Las entradas del registro estarán asociadas a la entidad que registro, de forma que si dos entidades registran un mismo paquete de información solo cuando las dos hayan realizado el borrado se borrará totalmente la referencia a dicho paquete. Cuando se elimina una entidad todas las entradas de información que tiene asociadas también se eliminan automáticamente.

Agente de Descubrimiento

Si el Agente de Publicación permite registrar datos en el Agente de Registro, el Agente de Descubrimiento permite tener acceso a dichos registros. Se trata también de un agente activo que aporta un API para el descubrimiento de entidades e información y que resumimos en la tabla 25.

Tabla 25. API del Agente de Descubrimiento.


entidadBuscar Busca entidades.

entidadObtener Obtiene información sobre una entidad.

informacionBuscarDes Busca información por descripción.

informacionBuscarCat Busca información por categoría.

informacionBuscarEnt Busca información por entidad.

informacionObtener Obtiene datos referentes a la información.

informacionAcceso Obtiene los datos de acceso (entidad y URL) para una determinada información.


Básicamente tenemos dos tipos de métodos. Unos para realizar búsquedas en función de algún criterio, que devuelven una matriz de identificadores, ya sea de entidades como de información. Otros dado un identificador nos obtiene los datos de la entidad o de la información registrada.

Agente de Registro

El Agente de Registro reside exclusivamente en las entidades de registro. Se trata de un agente pasivo que se encarga de recibir las peticiones de los Agentes de Publicación y los Agentes de Descubrimiento de otras entidades y servirlas adecuadamente.

El Agente de Registro gestiona el subárbol de registro del MIB, donde expone los datos del registro tanto de los nodos como de la información que estos gestionan.

Internamente el Agente de Registro almacena la información en una serie de tablas relacionadas que conforman una base de datos relacional. En la figura 74 podemos ver un diagrama de relación de dicha base de datos.

Figura 74. Esquema de la base de datos de registro.

Las principales tablas para la gestión de los registros son las tablas de entidades e información.

En el registro de entidades se almacena la información relacionada con las entidades del sistema. En ella se almacena información como su nombre y descripción, o su tipo donde se indica el tipo de entidad que es. En la tabla se almacena también


la fecha de expiración que indica la fecha máxima de permanencia del registro en la tabla. Si se sobrepasa dicha fecha sin que el registro haya sido renovado está es borrada automáticamente del sistema de registro.

En el campo acceso se codifica la información referente a como se puede acceder a la entidad: direcciones/puertos, mecanismos de autenticación o cifrado, etc.

Tabla 26. Registro de entidades.


eid Entero Identificador de entidad.

tipo Entero Tipo de la entidad.

nombre Cadena Nombre de la entidad.

descripcion Cadena Descripción de la entidad.

expiracion Fecha/Hora Fecha de expiración de la entrada.

acceso Cadena Datos de acceso (dirección, protocolo, cifrado,…)

En la tabla información se almacenan entradas referentes a la información existente en el sistema. Existirá una única entrada por cada paquete de información, aunque ésta sea gestionada por más de una entidad.

Tabla 27. Registro de información.


iid Entero Identificador de información.

tamanyo Entero Tamaño de la información.

prioridad Entero Prioridad de la información.

Por cada paquete de información almacenaremos su tamaño (en caso de conocerlo) y su prioridad. La prioridad establece la


importancia relativa dentro del sistema. A mayor valor en este campo más alta es la prioridad. Mediante la prioridad podemos indicar a algunas entidades que información es más adecuada para ser almacenada en pro de otra.

Cada paquete de información podrá estar asociado a un conjunto de entidades. Para establecer esta relación en la tabla entidad-información se realiza un cruce entre ambos. Este cruce tendrá como campo adicional la URL con la que se puede acceder a dicha información. Un mismo paquete de información puede ser accedido dentro de una entidad mediante más de una URL, por ejemplo con protocolos de acceso distintos.

Tabla 28. Registro de relación entidad-información.




url Cadena URL de acceso a la información.

A la hora de localizar la información se asocia a cada una de ellas un conjunto de descripciones. Las descripciones son textuales y puede ser cualquier descripción asociada a la información, incluyendo nombres de archivo (si la información es almacenada como tal). Las descripciones son almacenadas en la tabla información-descripción.

Tabla 29. Registro de relación información-descripción.



descripcion Cadena Descripción de la información.

Para ayudar a la distribución de la información dentro del sistema, tal como se vio en el modelo, se utiliza un mecanismo basado en la suscripción a categorías. De esta manera cada paquete de información tendrá asociada un conjunto de categorías, almacenado en la tabla información-categoría, y las


entidades se podrán suscribir a algunas de estas categorías, almacenado en la tabla entidad-categoría.

Tabla 30. Registro de relación información-categoría.



categoría Cadena Categoría de la información.

De esta manera cuando se va a transferir un paquete de información, otras entidades suscritas a cualquiera de las categorías a las que pertenece el paquete serán informadas.

Tabla 31. Registro de relación entidad-categoría.



categoría Cadena Categoría de la información.

Las categorías por lo tanto permiten relacionar entidades e información para guiar la difusión de dicha información. En el sistema las categorías con modeladas como cadenas de texto.

Agente de Transferencia

El Agente de Transferencia es el responsable de obtener un paquete de información. Su interfaz básica permite, a partir de un IID, localizar donde se encuentra la información y transferirla hasta la entidad para su uso. El agente tiene dos formas básicas de funcionamiento. En la primera según va transfiriendo la información la va almacenando mediante el Subsistema de Almacenamiento. En una segunda forma de funcionamiento el agente solicita la información y la transfiere como un flujo de información a otro agente. Esta segunda forma no requiere el uso de un sistema de almacenaje masivo ya que la información puede ir procesándose según se va recibiendo. Este modelo es importante ya que usualmente las entidades de gestión no pueden o no tienen acceso a los sistemas de almacenamiento del


equipo donde reside. En este modo el Agente de Transferencia utiliza el Servicio de Streaming.

Por lo tanto el Agente de Transferencia es un agente de utilería que otros agentes invocan cuando necesitan obtener un paquete de información. El interfaz del Agente de Transferencia tiene dos métodos, uno para el almacén de la información y otro para su recepción como flujo. En la tabla 32 se puede ver la interfaz detallada.

Tabla 32. API del Agente de Transferencia.


informacionAlmacenar Obtiene y almacena un paquete de información.

informacionFlujo Obtiene un paquete de información como flujo de datos.

Agentes Especializados

Los Agentes Especializados son los que implementan las tareas de gestión de alto nivel. Éstos contemplan los requerimientos de los sistemas de gestión y son programados específicamente para realizar las acciones indicadas por los administradores.

Estos agentes son los que caracterizan cada una de las entidades de nuestro sistema, llevando a cabo tareas más pasivas como en el caso de las entidades de gestión o tareas más activas como las entidades de control.

El funcionamiento de estos agentes por lo tanto es dependiente de la aplicación de gestión que se quiera realizar con el modelo. A modo de ejemplo vamos a describir cinco agentes distintos, uno por cada área del Modelo Funcional. Además destacaremos de cada uno de estos agentes el uso que realiza del sistema de transferencia de información. En este ejemplo los agentes descritos cooperarán entre ellos para mantener una red de computadores operativa el máximo tiempo posible, incorporando características de alta disponibilidad en el sistema.

El Agentes Supervisor es un agente que se encarga de controlar el correcto funcionamiento de los distintos elementos de la red.


Su labor consiste en monitorizar determinados puntos de control de los distintos elementos de la red para detectar posibles fallos y corregirlos. Entre otras variables comprobará que determinados servicios de red estén operativos continuamente. Si detecta un mal funcionamiento en alguno de ellos invocara al Agente de Regeneración para que realice una reinstalación parcial o total del nodo.

El Agente de Regeneración permite dado un nodo, reinstalar parte o la totalidad de su sistema. Esto incluye la reinstalación integral de todo el nodo, incluyendo su sistema operativo. De esta manera el Agente de Regeneración permite volver operativo un nodo con fallos graves, incluso de su software más básico. Para realizar estas labores el agente necesita trasportar al nodo o nodos afectados grandes cantidades de información.

El Agente de Inventario es capaz de realizar una recopilación exhaustiva de la información de los diferentes componentes de la red. Con esta información otros agentes pueden analizar las posibilidades de la red, haciendo un mejor uso de los recursos al tener una visión global del sistema. El Agente de Inventario, además de almacenar las características de los distintos elementos de la red, también es capaz de almacenar la información que reside en estos (configuración, software, datos, etc.) por si en algún momento fallará y hubiera que regenerarlo mediante el Agente de Regeneración. Por lo tanto el Agente de Inventario también transfiere grandes cantidades de información.

El Agente de Monitorización por su parte se encarga de monitorizar y analizar el uso que se hace de la red y de los distintos servicios que se ofertan. Por ejemplo es capaz de detectar que un servidor web está siendo saturado por un elevado número de peticiones, por lo que informaría al Agente Supervisor de ello. En este caso el Agente Supervisor podría, por ejemplo, indicar al Agente de Regeneración que reinstalara un equipo que no está siendo usado en ese momento, con una copia idéntica del servidor web, de forma que la carga se podría repartir entre ambos servidores.

Por último el Agente de Seguridad estaría gestionando los distintos aspectos de seguridad del sistema, validando las credenciales de los nuevos equipos puestos en marcha o por ejemplo activando el acceso de nuevos servidores web a datos proporcionados por servidores NAS.


Como se puede ver estos cinco agentes podrían conformar un sistema de gestión integral de redes de computadores que permitirá mantener operativo el sistema completo, y garantizar determinados niveles de calidad utilizando el modelo propuesto.

Además el uso del middleware propuesto favorecería que los administradores se centraran en la realización de la lógica del sistema de gestión, evitando tener que desarrollar las labores dependientes del modelo de gestión o de la transferencia de información.

129

C a p í t u l o 5

Mecanismo de Difusión Masiva de Información

Como se ha visto en el capítulo 3 la integración de la gestión y transmisión de la información en el sistema de gestión aporta una serie de características muy beneficiosas.

Mediante el registro de la información las entidades de gestión pueden tener una visión global de cuáles son los paquetes de información que se encuentran disponibles en el sistema, dónde se encuentran copias de estos y mediante qué protocolos pueden ser transferidos.

Así mismo, en el capítulo 4, se propone una arquitectura que permite a una entidad de gestión integrar módulos de transferencia para obtener la información, módulos que implementan protocolos estándares de transferencia como HTTP o FTP.

Sin embargo estos protocolos no explotan todo el potencial de la red de comunicaciones a la hora de distribuir la información. Su principal problema radica en que son protocolos uno-a-uno, es decir establecen comunicaciones, normalmente bidireccionales, entre dos únicos nodos, normalmente basadas en protocolos de aplicación fundamentados en TCP.

En la actualidad muchos de los procesos de transmisión de información suelen estar marcados por dos características diferenciadoras: se transmiten grandes volúmenes de información y se transmite a un elevado número de destinatarios. El uso de


protocolos basados en comunicaciones uno-a-uno en estos casos produce varios problemas:

La red se satura ya que la información masiva debe ser transmitida tantas veces como destinatarios existan.

Los emisores de la información, por ejemplo los servidores de datos, también se saturan debido a que son el origen común de la información.

El sistema de transferencia no es escalable, cuanto más grande sea la información o más destinatarios existan más problemas de rendimiento tendremos.

Es difícil acotar el tiempo de transferencia.

En el modelo de gestión propuesto este problema se acentúa aun más ya que en el modelo de distribución propuesto las entidades informan cuando hay un paquete de información nuevo y en el caso de que existan múltiples entidades que requieran este paquete, se produciría un problema de saturación.

En los últimos años han surgido multitud de protocolos y aplicaciones basados en sistemas colaborativos que realizan transferencia masiva de información. Es el caso de los sistemas P2P o las aplicaciones denominadas Grid Computing. La filosofía que siguen estos sistemas está fundamentada en la colaboración como medio para conseguir una transmisión de la información más eficiente.

En estos sistemas de transmisión de información la escalabilidad es uno de los puntos fuertes respecto a los enfoques tradicionales. El hecho de que el proceso de transmisión esté distribuido entre todos los participantes del sistema hace que el sistema soporte transferencia a conjuntos grandes de destinatarios. De hecho en muchos de estos sistemas el rendimiento relativo es mayor cuando más participantes existen.

La arquitectura propuesta en el capítulo 4 también contempla la posibilidad de utilizar protocolos P2P en el motor de transferencia. Sin embargo en muchas ocasiones el uso de estos protocolos no es posible. Esto es debido a que las aplicaciones P2P se fundamentan en el hecho de fraccionar la información en bloques de datos que se transmiten de forma independiente en la nube de participantes. De esta manera la información va llegando a cada destinatario de forma fraccionada y no ordenada, en función de la disponibilidad en cada momento de un bloque. Este

Capítulo 5. Mecanismo de Difusión Masiva de Información 131

hecho fuerza a que el destinatario de la información, durante el proceso de transmisión, tenga un espacio de almacenamiento al menos tan grande como el tamaño de la información a recibir, ya que los fragmentos de información pueden llegar desordenados y hay que reconstruir el paquete de información original al final del proceso, cuando se tienen todos los bloques.

En la figura 75 podemos ver como un conjunto de peers transfieren bloques de datos para transferir paquetes de información (usualmente archivos). El la figura se ilustra cómo uno de los peers tiene tres paquetes de información, uno de ellos completo. El volumen de información intermedia suele ser tan alto que su gestión se suele realizar en algún tipo de almacenamiento masivo como discos de almacenamiento.

Figura 75. Sistema P2P.

Este esquema suele ser un problema dentro del sistema de gestión ya que en la mayoría de los casos las entidades de gestión actúan como sistemas auxiliares que gestionan un dispositivo de red con el menor impacto sobre este, por lo que hacer uso de grandes cantidades de memoria o de almacenamiento no suele ser compatible con esta filosofía. En otros casos el uso de estos recursos es incluso imposible, como es el caso del Agente de Regeneración que se analizó en el capítulo 4.

Estas restricciones hacen que enfoques basados en streaming de datos sean mucho más adecuados para la transmisión de

NUBE DE PEERS

ALMACENAMIENTO MASIVO

Aplicación P2P

A

B

C

Aplicación P2P

Aplicación P2P


información en los sistemas de gestión. Los sistemas de streaming aportan las siguientes características en el proceso de transporte:

La información puede ir procesándose según se va recibiendo.

No necesitan gran cantidad de memoria o almacenamiento para el transporte, y ésta no es dependiente del tamaño total de la información transmitida.

Permite, de forma sencilla, continuar la transmisión en caso de parada temporal de la misma.

El proceso de transmisión está en todo momento sincronizado entre emisores y receptores.

Es por ello que en este capítulo se propone la realización de un protocolo de transporte para la difusión de información, de tipo streaming y que además incluya características de los protocolos P2P, los sistemas colaborativos y técnicas de multicast para conseguir la transferencia de la información de forma eficiente en nuestro sistema de gestión.

Adicionalmente también se ha desarrollado un protocolo de aplicación que utiliza el protocolo de transporte para difundir la información entre nodos de red.

Protocolo de Transporte MDCTP

El Multi-Destination Collaborative Transfer Protocol (MDCTP) consiste en un protocolo de transporte para la trasferencia de información al estilo de TCP que permite a las aplicaciones el streaming de información, entendida como la comunicación basada en un flujo de datos unidireccional y confiable, desde un origen hasta múltiples destinatarios.

Al contrario que en TCP el hecho de que la comunicación sea unidireccional hace que dentro del proceso de comunicación se diferencie claramente los emisores de la información de los destinatarios de la misma.


Descripción General

MDCTP está concebido como un protocolo de transporte basado en IP, al igual que TCP y UDP. Sin embargo, dado que en su base utiliza el envío y la recepción de datagramas, también podría ser implementado sobre UDP. El uso de UDP además nos aportaría dos características interesantes: la multiplexación por aplicación mediante los puertos UDP y un control de errores en datos mediante el checksum que incorpora. En cualquier caso el protocolo está pensado para poder ser implementado tanto sobre UDP como sobre IP (ver figura 76).

Figura 76. Pila de protocolos

Miembros de la comunicación

En una comunicación basada en MDCTP existirán un conjunto de 2 o más miembros entendidos como procesos de usuario que utilizan el protocolo para intercambiar información entre ellos. En el protocolo cada uno de esos miembros será denominado a partir de ahora nodo.

En las comunicaciones P2P no existe diferenciación entre nodos emisores y destinatarios ya que todos los miembros de la

IP

TCP

Protocolo de Aplicación

UDP

MDCTP

AP

LIC

AC

IÓN

TR

AN

SP

OR

TE

RE

D

Protocolo de Enlace

EN

LA

CE


comunicación (denominados peers en este entorno) actúan con el mismo rol, independientemente de que al inicio es posible que algunos peers tengan toda la información, similar a los emisores, y otros no tengan nada de la información, similar a los receptores.

Como se comento anteriormente en estos sistemas la información se fracciona en bloques y puntualmente, para la transmisión de cada bloque, uno de los dos extremos actúa como origen y otro como destino, rol que se puede intercambiar perfectamente para otro bloque.

Nuestra propuesta realiza un enfoque mixto en el sentido de que, al tratarse de un streaming, siempre existirá al menos un nodo que actuará con el rol de emisor y otros que actuaran como receptores, si bien internamente un receptor podrá retransmitir un bloque de datos a otro receptor, al estilo de los sistemas P2P.

En el proceso de comunicación existirá un emisor que actuará como coordinador principal de todo el proceso. A este nodo lo denominaremos emisor principal. A los otros nodos que contienen la información a transmitir y que también participan en el proceso los denominaremos emisores secundarios. Los emisores secundarios juegan un papel fundamental en la escalabilidad del sistema ya que permiten optimizar el proceso emitiendo la información desde lugares más cercanos a determinados destinatarios que el emisor principal.

Tabla 33. Tipos de nodos y funcionalidades.

Tipo Emite Recibe Re-emite / Retransmite

Recupera / Corrige

Emisor principal

Emisor secundario

Receptor

Soporte

Además de emisores y receptores existirán otro tipo de nodos, que denominaremos nodos de soporte, que permitirán ayudar en el proceso de transmisión reenviando datos o recuperando paquetes


perdidos. Los nodos de soporte son nodos que no tienen un interés en la información a transferir pero que se unen al proceso de transporte para que este gane en eficiencia y escalabilidad.

En la tabla 33 vemos un resumen de los diferentes tipos de nodos que podemos tener y las funciones que puede realizar.

Durante el proceso de comunicación cada nodo tendrá asociado

un identificador (peerID). Este identificador será único para cada nodo implicado en la comunicación y sólo tendrá sentido dentro del proceso de comunicación. El identificador es un entero de dos bytes sin signo que no puede ser 0 (de 1 a 65,535). El identificador 1 está reservado para el emisor principal.

Figura 77. Símbolos representando los tipos de nodos.

A partir de este momento en las siguientes figuras de este capítulo utilizaremos una serie de símbolos que representa a los nodos implicados en el proceso de comunicación. Cada nodo estará representado por un circulo que en su interior contiene el

identificador de nodo (peerID). Si se quiere explicitar el tipo de nodo que se está utilizando se utilizarán los símbolos descritos en la figura 77.

Sesiones

Al igual que en TCP y al contrario que los protocolos P2P el proceso de transmisión está contextualizado en una sesión de transferencia (a partir de ahora sesión). Durante la sesión se establece un flujo virtual y unidireccional entre emisores y receptores para la transmisión de la información. Cada sesión es un proceso de comunicación independiente. Por ejemplo un mismo emisor podría estar emitiendo datos distintos a dos conjuntos de receptores de forma simultánea, cada uno de estos procesos de transferencia estaría contextualizado en una sesión distinta.

10

8

7

1

4

?

6

Emisor principal

Emisor secundario

Receptor

Nodo de soporte

Nodo

Nodo no conectado

Nodo muerto


La sesión estará identificada por un identificador único

(sessionID). El identificador será constante durante todo el proceso y será la referencia única que asocie todos los nodos que interactúan en cada proceso de transferencia. En el protocolo el

sessionID será un valor entero positivo representado por 2 bytes (de 1 a 65,535).

Cada sesión está estructurada en tres fases consecutivas:

Conexión: Los participantes se pondrán en contacto con el emisor principal para unirse a la comunicación.

Transferencia: La información será difundida desde los emisores hasta los receptores.

Cierre: La transferencia será finalizada y todos los participantes abandonarán la sesión.

Las fases de conexión y cierre inician y terminan el proceso de comunicación y durante la fase de transferencia se transmiten los datos (ver figura 78). Posteriormente se describirán cada una de estas fases.

Figura 78. Fases de una sesión de transferencia.

Zonas

Cuando tenemos muchos participantes en una misma sesión de transferencia la red se suele saturar con la retrasmisión de los bloques.

Las técnicas de multicast y broadcast permiten realizar un envió de tramas eficiente en el caso de múltiples destinatarios. Tanto IP como UDP permiten el uso de estas técnicas en el envío de tramas por lo que es posible integrarlas dentro de nuestro protocolo.

En el caso de broadcast, cuando se envía una trama a la dirección de broadcast, ésta es recibida potencialmente (no hay confiabilidad) por todos los nodos de la red local. Esto permitiría enviar simultáneamente un paquete de datos a varios receptores

S E S I Ó N D E T R A N S F E R E N C I A

Fase deconexión

Fase detransferencia

Fase decierre


de una misma red, sin tener que enviar por duplicado la trama en cuestión. Los principales problemas de esta técnica son:

Es válido sólo para redes de área local. En caso de querer extender el broadcasting a otras redes se necesitaría configurar los elementos de internetworking como routers para tal efecto.

Las tramas enviadas llegan a todos los nodos de la red local, estén interesados o no en dicha información. Esto satura las NICs de otros equipos con tramas inecesarias para ellos.

Las técnicas de multicast permiten solucionar estos dos problemas. Por una parte ofrecen la posibilidad de enviar tramas a múltiples destinatarios aunque estos se encuentren en redes locales distintas. Además los paquetes enviados a una dirección de multicast sólo llegan a los equipos que estén interesados, es decir, que se hayan suscrito a la dirección multicast.

Nuestro protocolo va a utilizar, además de unicast, ambas técnicas, multicast y broadcast, para el envío de tramas entre nodos. Cuando usemos una de estas dos técnicas multi-destinatarias hablaremos de difusión de los datos.

De forma grafica la difusión se representará con una serie de círculos concéntricos con centro en el nodo emisor, en contraposición con la comunicación punto a punto representada con una flecha desde el nodo origen al nodo destino (ver figura 79).

Figura 79. Tipos de comunicación entre nodos.

En cualquier caso independientemente del protocolo de difusión utilizado, definiremos el concepto de zona. Una zona es el ámbito de acción de un determinado conjunto de nodos de forma que un nodo de una zona puede enviar (difundir) una trama que llegue a

8

6

3

DIFUSIÓN ENVÍO DIRECTO


el resto de nodos de esa misma zona. Por ejemplo, en el caso de broadcast, los nodos de una zona están compuestos por los nodos de la red local y, en el caso de multicast, la zona está compuesta por nodos suscritos a una misma dirección de multicast.

A lo largo de una sesión de comunicación se identificarán diversas zonas donde se distribuyen los participantes en la comunicación. Podrá existir una única zona que agrupe a todos los nodos o tantas zonas como nodos implicados, en el caso de que cada uno de ellos conforme una zona independiente. Evidentemente el proceso de comunicación será más eficiente cuanto más alto sea el nivel de agrupación de los nodos en zonas.

La comunicación dentro de las zonas se realizará fundamentalmente mediante difusión (multicast y broadcast) y la comunicación entre zonas siempre en unicast.

Cada zona estará identificada por un código único (zoneID). Los zoneID también son códigos enteros positivos de dos bytes.

En la figura 80 se puede ver una representación de una zona en una sesión. La zona se representa como un área cerrada que engloba a todos los vecinos de la zona. El identificador de la zona se indicará con un hexágono en algún lugar de la frontera de la zona.

Figura 80. Zona de nodos.

Dentro de una sesión cada nodo pertenecerá a una única zona. A los nodos que componen una misma zona se les denominará vecinos de la zona.

1

72

15

47

4

9

Ámbito de difusión

Vecino de la zona

Nodo fuera de la zona

1

Identificador de la zona


API de Comunicaciones

Cuando las aplicaciones utilizan un determinado protocolo para comunicarse utilizan un API que les da acceso a las funcionalidades de dicho protocolo.

El API de bajo nivel más extendido dentro del entorno TCP/IP es el API de sockets. El API de sockets describe como las aplicaciones pueden intercambiar datos. En la actualidad existen multitud de implementaciones de sockets para diversas plataformas y lenguajes de programación.

Tabla 34. Principales métodos del API de sockets.


socket Abre un socket del tipo especificado. socket devuelve un

descriptor del socket abierto utilizado en el resto de métodos.

close Cierra un socket abierto. Finaliza la comunicación.

bind Asocia a un socket una dirección de red. La dirección es dependiente del tipo de socket.

listen Prepara un socket orientado a conexión para recibir conexiones.

accept Espera una conexión en un socket preparado para ello.

connect Inicia una conexión con otro socket en espera.

send/write Envía información.

recv/read Recibe información.

getsockopt Lee una opción de un socket.

setsockopt Establece una opción de un socket.

Vamos a utilizar este API ya que de esta manera se puede realizar una asociación directa entre el protocolo propuesto y otros protocolos de la familia TCP/IP. De esta forma sería relativamente


sencillo adaptar una aplicación que utiliza sockets en la distribución de información para trabajar con MDCTP.

Los principales métodos del API están descritos en la tabla 34.

El funcionamiento básico del API es el siguiente: los extremos de

la comunicación crean un socket (soket), le asocian una dirección

(bind), envían (send) o reciben (recv) datos las veces que necesiten

y finalmente cierran la conexión (close).

En el caso de protocolos orientados a conexión como TCP, antes del envío y recepción de información existe un proceso de conexión. En este proceso una de las partes actúa de forma pasiva y otra de forma activa. El extremo pasivo prepara el socket

para recibir conexiones (listen) y se queda a la espera de una

conexión (accept). Por otra parte el extremo activo es el

responsable de iniciar la conexión (connect). En la figura 81 se puede ver un esquema del funcionamiento.

Figura 81. Esquema de funcionamiento de un protocolo orientado a

conexión.

MDCTP utilizará este mismo esquema donde tendremos para la conexión un único nodo pasivo, el emisor principal, y diversos nodos activos, los receptores, emisores secundarios y nodos de soporte. Otra diferencia es que al ser unidireccional sólo los

NODO

ACTIVO

NODO

PASIVO socket

bind

listen

accept

recv

send

connect

send

recv

close


emisores envían información y sólo los receptores la reciben. La figura 82 muestra el esquema para el caso de un emisor y varios receptores.

Figura 82. Esquema de funcionamiento de MDCTP.

Antes de invocar al método connect los nodos establecerán que tipo de nodo son: receptores, emisores secundarios o nodos de soporte.

Dado que todos los nodos realizan el proceso de conexión contra el emisor principal, éste conocerá cuales son todos los participantes en el proceso de comunicación.

Organización del Sistema de Transmisión

Como hemos visto los distintos nodos que componen una sesión se agrupan en diversas zonas. La comunicación dentro de cada zona se realizará por difusión transmitiendo de forma eficiente la información dentro de la zona y con una estructura totalmente plana, es decir, no hay ninguna jerarquía preestablecida entre los vecinos de la zona.

La comunicación entre zonas se realizará mediante unicast y en este caso es importante describir como se estructuran estas zonas para realizar la transferencia.

Las zonas se estructurarán en forma de árbol de manera que una determinada zona recibe información sólo de su zona padre y

RECEPTORESEMISORopen

bind

listen

accept

send

close

connectconnectconnect

recvrecvrecv


retransmite la información a todas sus zonas hijas. Además cada zona será responsable de reenviar información perdida a sus zonas hijas, es decir, el control de errores se produce desde las zonas padre hacia sus hijas.

El origen del árbol, la zona raíz, será aquella donde resida un emisor. Dado que en el proceso de transferencia podemos tener más de un emisor distinguiremos un árbol por cada zona que contenga un emisor. Por lo tanto la configuración global del sistema será un bosque conformado por distintos árboles, cada uno de ellos teniendo una zona emisora como zona raíz (ver figura 83).

En la tabla 35 se muestra un resumen de los diferentes términos que utilizaremos para nombrar las distintas zonas que hay en una sesión.

Tabla 35. Tipos de zonas.

Tipo de zona Descripción

Zona raíz Zona origen de un árbol. Son las zonas que tienen algún nodo de tipo emisor.

Zona raíz principal Zona donde reside el emisor principal. Su identificador es 1.

Zona hoja Zona que no tiene ninguna zona hija.

Zona intermedia Zona que tiene al menos una zona hija.

El protocolo no limita ni el número de árboles del bosque, ni la profundidad de cada árbol ni el número de hijos de cada zona.


Figura 83. Bosque de zonas.

En el proceso de transmisión se producirá un flujo principal de la información que nacerá de las zonas raíz y pasará por todas las zonas llegando a las zonas hoja. El hecho de que la transmisión de la información ser realice por delegación, es decir, cada padre sólo retransmite a sus hijos, confiere un alto grado de escalabilidad al sistema.

Durante el proceso de transferencia las zonas podrán cambiar de posición, bien por cuestiones de rendimiento, acercándose a zonas más cercanas o menos saturadas, bien por problemas puntuales, como la desaparición de una zona.

Dado que cada emisor (situados en las zonas raíz) tiene toda de la información a transmitir los flujos de transmisión podrían ser totalmente independientes por cada árbol, es decir, cada emisor podría ir emitiendo a una velocidad distinta, en función del estado de la red y la respuesta del resto de zonas de su árbol. Sin embargo en este tipo de esquema con árboles independientes el proceso de transferencia no está totalmente sincronizado y si por ejemplo un emisor secundario fallara el emisor principal no podría integrar las zonas de ese árbol en el suyo propio ya que un proceso de transferencia podía estar mucho más avanzado que otro.

El protocolo soporta ambos modos de funcionamientos, es decir, una sincronización global a todo el bosque, lo cual requiere de cierta comunicación entre los emisores, o una sincronización por árbol, que actuarían de forma independiente.

Zonas Hoja

ZonasIntermedias

ZonasRaíz

Árbol principalÁrbol

secundario

Árbol

secundario


Paquetes MDCTP

Como se comentó anteriormente todo paquete enviado en el protocolo MDCTP irá encapsulado dentro de un paquete IP o un paquete UDP. Para simplificar las explicaciones a partir de ahora asumiremos que encapsulamos los paquetes mediante UDP. En la figura 84 se puede ver como un paquete MDCTP es encapsulado en un paquete UDP que a su vez se encapsula en un paquete IP.

Figura 84. Encapsulamiento de los paquetes MDCTP.

Cabecera MDCTP

Todo paquete MDCTP comenzará con una cabecera donde se indican los datos generales del protocolo. Los campos de la cabecera pueden verse en la figura 85.

CabeceraIP

CabeceraUDP

CabeceraMDCTP

Cuerpo MDCTP

Paquete MDCTP

Paquete UDP

Paquete IP


Figura 85. Cabecera MDCTP.

La cabecera MDCTP está compuesta por 11 campos y ocupan los 18 primeros bytes de cada paquete.

Campo sessionID

El primer campo de la cabecera llamado sessionID ocupa los

primeros 2 bytes de la misma. En el campo sessionID todos los nodos indican la sesión en la que están trabajando. Esto actúa como un multiplexor que permite a un nodo gestionar varias sesiones en paralelo sin que se interfieran los procesos de comunicación.

Si un nodo recibe un paquete de una sesión a la que no pertenece, el paquete será descartado.

Campo flags

En el campo flags, que ocupa el tercer byte de la cabecera, se indican una serie de opciones binarias combinables que

Byte / Bit 0 2 3 7

0sessionID

1

2 flags

3 peerType operation

4srcPeerID

5

6dstPeerID

7

8zoneID

9

10pktID

11

12ack

13

14next

15

16out

17


establecen opciones del paquete. En la tabla 36 se describen los distintos flags que existen en MDCTP.

Tabla 36. Flags de los paquetes MDCTP.

Flag Valor Descripción

RELIABLE 0x01 Indica que el paquete es una solicitud que debe contestarse por el destinatario

RESPONSE 0x02 Indica que el paquete es una respuesta de un comando.

ZONE 0x04 Indica si el paquete es enviado dentro de la zona (0) o entre zonas (1).

END 0x08 Indica que se ha llegado al final de la transferencia.

En muchas ocasiones los nodos envían paquetes de control que deben ser contestados por el destinatario del paquete, es decir, que requieren confiabilidad. Para estos casos, donde existirá un paquete de solicitud y otro de respuesta, se utilizará el flag

RELIABLE que estará activo en la solicitud, indicando que debe

contestarse, y el flag RESPONSE que se activará en el paquete de respuesta. Para enlazar una petición con su respuesta en la solicitud se indicará un identificador de paquete en el campo

pktID que coincidirá con el pktID de la respuesta.

Para garantizar la confiabilidad cuando se envía un paquete con

el flag RELIABLE activo, si no se recibe respuesta en un determinado tiempo se vuelve a reenviar asumiendo que se ha producido una pérdida de la solicitud o de la respuesta. El número de reintentos es configurable y el tiempo de espera se puede alargar en cada solicitud para evitar problemas de saturación. Por defecto el tiempo de espera es de 2 segundos iniciales que se duplican por cada reintento hasta un máximo de 3 reintentos.

Cumplido el tiempo de espera del último reintento se asume que hay un problema en la red o que el destino no está disponible o no es alcanzable.


El flag ZONE indica si el paquete es enviado de forma interna a la zona (paquete intra-zona) o se transmite entre dos zonas distintas (paquete inter-zonas).

Por último el flag END indica que se va a finalizar la transmisión y que no van a ser enviados más datos.

Campo peerType

El campo peerType indica el tipo del peer que envía el paquete. El campo ocupa los 3 primeros bits del cuarto byte de la cabecera.

En la tabla 37 podemos ver una lista de los valores que puede

tomar el campo peerType.

Tabla 37. Tipos de nodos.

Tipo Valor Descripción

NONE 0x00 Tipo indeterminado.

ROOT 0x01 Emisor primario.

SENDER 0x02 Emisor secundario.

RECEIVER 0x03 Nodo receptor.

SUPPORT 0x04 Nodo de soporte.

Campo operation

El campo operation ocupa los 5 últimos bits del cuarto byte e indica la operación que está realizando el paquete en cuestión. Las distintas operaciones que usa la versión 1 de MDCTP se describen en la tabla 38.

Tabla 38. Operaciones de MDCTP.

Operación Valor Descripción

NULL 0 Sin operación. No utilizado.

PEER 1 Agrega un nodo a la sesión o actualiza sus datos.


ZONE 2 Agrega un nodo a una zona.

DEL 3 Informa de la eliminación de un nodo o zona.

INFO 4 Envía información topológica a un nodo.

PING 5 Envía un paquete básico que requiere la confirmación del destinatario.

DPING 6 Realiza un PING delegado.

DATA 7 Envía un paquete de datos a un nodo.

HDATA 8 Envía un paquete de recuperación preventiva horizontal.

VDATA 9 Envía un paquete de recuperación preventiva vertical.

ACK 10 Confirma la recepción de datos.

STATUS 11 Informa sobre la existencia de un nodo.

Si en la solicitud el campo operation indica la operación a

realizar, en las respuestas (paquetes con el flag RESPONSE activo)

el campo operation indica el estado producido por la ejecución de la operación. En ese caso un 0 indica siempre que la operación se realizó con éxito y otro valor indica un error específico de cada operación.

Los estados del 0 al 127 son estados comunes a todas las operaciones. Los estados dependientes de la operación comienzan a partir del valor 128. En la tabla 39 se muestra un listado de los estados comunes.

Campos srcPeerID y dstPeerID

Los siguientes campos srcPeerID y dstPeerID indican los identificadores de nodo del emisor y receptor del paquete respectivamente. Ambos son campos de 2 bytes y ocupan los bytes del quinto al octavo de la cabecera.

El campo dstPeerID podrá ser ALL (0xFFFFFFFF) cuando se quiere difundir un paquete, indicando que el destinatario son todos. El


caso de difusión el destino también podrá ser 0 indicando que sólo queremos respuesta de uno de los vecinos de la zona. El

campo srcPeerID podrá ser 0 al inicio de la conexión, cuando un peer aun no tiene asociado un identificador.

Tabla 39. Estados de las operaciones MDCTP.

Valor Descripción

0 Comando realizado correctamente.

1 Tamaño de paquete incorrecto

2 Identificador de sesión incorrecto.

3 Flag incorrecto.

4 Tipo de nodo incorrecto.

5 Operación no soportada.

6 Peer origen incorrecto

7 Peer destino incorrecto

8 Identificador de zona incorrecto

9 Campo ack incorrecto

10 Campo next incorrecto

11 Campo out incorrecto

127 Error general

Campo pktID

El campo pktID es un identificador de paquete. Permite al resto de nodos identificar de forma única un paquete recibido. Cuando un nodo vuelve a emitir un mismo paquete el identificador es el mismo, indicando que ha sido una reemisión.


Cada nodo puede gestionar el identificador de paquetes de forma aleatoria o secuencialmente, de forma que cada vez que envía un

paquete nuevo incrementa el valor de pktID. Dos paquetes

distintos pueden tener el mismo pktID siempre que sean enviados por nodos distintos, es decir, la secuencia de identificador es propia de cada nodo.

En el caso de una respuesta (flag RESPONSE activo) esta campo indica el identificador de la solicitud.

Campos ack, next y out

Los 3 últimos campos de la cabecera, ack, next y out, cada uno de ellos de 2 bytes, indican los límites de las ventanas de transferencia del nodo origen del paquete.

Estos campos permiten la sincronización del proceso de transferencia y su significado dependerá del tipo de paquete. En la tabla 40 se puede ver el significado de dichos campos.

Tabla 40. Significado de los campos ack, next y out

Paquetes intra-zona Paquetes inter-zonas

ack Todos los bloques de datos

antes de ack han sido

recibidos por el nodo origen.

Todos los bloques de datos

antes de ack han sido

recibidos por todos los nodos del subárbol origen.

next Siguiente bloque de datos esperado por el nodo origen.

Siguiente bloque de datos esperado en la zona origen.

out Sólo se pueden recibir bloques

menores que out en el nodo

origen.

En la zona origen sólo se pueden recibir bloques de

datos menores que out.

Más adelante, cuando se detalle el proceso de transferencia se explicará en profundidad el uso de estos campos.

Operaciones

Mediante los paquetes los participantes ejecutan operaciones sobre otro nodo. En el protocolo se distinguen dos tipos de operaciones: comandos y notificaciones.


Los comandos son operaciones confiables compuestas por una

solicitud identificada mediante el flag RELIABLE activo y una

respuesta identificada por el flag RESONSE activo. El emisor del

comando especifica un pktID que el nodo que responde incluirá

en el pktID del paquete respuesta para asociarla con la petición.

En la figura 86 se puede ver un ejemplo de una petición y respuesta entre dos nodos.

Figura 86. Petición y respuesta de un comando.

Cuando la solicitud de un comando se envía por difusión todos los vecinos de su zona reciben la solicitud, por lo que, en teoría, todos responderían. En zonas con muchos vecinos esto produciría un problema de saturación, y a que todas las respuestas llegarían en un mismo instante de tiempo al origen de la solicitud.

Para evitar este problema de saturación por las respuestas se establecen 3 mecanismos distintos, diferenciados por el valor del

campo dstPeerID:

Si indicamos en dstPeerID el identificador de un nodo vecino, aunque la solicitud haya sido enviado por difusión, sólo dicho nodo será el responsable de contestar.

Si indicamos en dstPeerID el valor ALL todos los nodos de la zona responderán al origen de la solicitud por unicast. Para evitar la confluencia de respuestas cada uno de ellos esperará un tiempo aleatorio antes de responder, lo cual escalará la llegada de las respuestas. En este caso el nodo origen de la solicitud esperará la respuesta de todos los vecinos, si no tiene la respuesta de alguno de ellos realizará los correspondientes reenvíos de la solicitud hasta que tenga respuesta de todos.

8

3RQST

RSPNflags=RELIABLE

srcPeerID=8

dstPeerID=3

pktID=78

flags=RESPONSE

srcPeerID=3

dstPeerID=8

pktID=78


Si indicamos en dstPeerID el valor 0 sólo uno de los vecinos contestará. Para ello todos los vecinos esperarán un tiempo aleatorio tras el cual enviarán una respuesta por difusión. De esta manera si uno de los vecinos recibe la respuesta cancela el envío de la suya propia. También es posible que dos vecinos contesten a la misma vez, el origen de la solicitud dará prioridad a la primera respuesta recibida.

En la figura 87 podemos ver una ilustración de los tres mecanismos de confiabilidad para el caso de solicitudes por difusión.

Figura 87. Confiabilidad para solicitudes por difusión.

En algunas ocasiones un nodo externo a la zona querrá enviar un comando a todos los vecinos de la zona. En ese caso enviará la solicitud a un nodo cualquiera de la zona indicando en el campo

dstPeerID, no el identificador del nodo, si no el valor ALL o 0, en función de si quiere que contesten todos los vecinos o sólo uno. El nodo que recibe el paquete del origen externo rebotará el paquete difundiéndolo en la zona y esperará la o las respuestas. Después contestará a su vez al nodo externo que realizó la solicitud. De esta manera actúa como un nodo intermedio encargado de gestionar la confiabilidad en la zona.

En la figura 88 podemos ver un ejemplo de cómo un nodo (el 20) envía un comando a todos los nodos de la zona 4. El nodo seleccionado para realizar la difusión es el nodo 7.

flags=RESPONSE

srcPeerID=4

dstPeerID=6

pktID=78

flags=RESPONSE

srcPeerID=4

dstPeerID=6

pktID=78

flags=RELIABLE

srcPeerID=6

dstPeerID=4

pktID=78

flags=RESPONSE

srcPeerID=4

dstPeerID=6

pktID=78

6

715

4

4RQST

RSPN

flags=RELIABLE

srcPeerID=6

dstPeerID=ALL

pktID=78

flags=RESPONSE

srcPeerID=7

dstPeerID=6

pktID=78

6

715

4

4RQST

RSPN

flags=RELIABLE

srcPeerID=6

dstPeerID=4

pktID=78

flags=RESPONSE

srcPeerID=15

dstPeerID=6

pktID=78

6

715

4RQST

RSPN

RSPNRSPN

4

C O N T E S TA U N N O D O C O N T E S TA N T O D O S C O N T E S TA E L P R I M E R O


Figura 88. Envío de solicitudes a zonas externas.

Las notificaciones son operaciones que no requieren ninguna respuesta y no requieren confiabilidad. No tienen activo ni el flag

RELIABLE ni el RESPONSE.

En varios de los comandos que utiliza MDCTP en el cuerpo de los mensajes se indican información sobre varios nodos o zonas. En estos casos de utilizaran bloques de definición de nodo o zona para incluir estos datos. Los bloques de definición incluyen la información necesaria para informar sobre los datos relevantes de un nodo o zona determinada.

El bloque de definición de zona se puede ver en la figura 89.

flags=RESPONSE

srcPeerID=4

dstPeerID=6

pktID=342

flags=RESPONSE

srcPeerID=4

dstPeerID=6

pktID=342

flags=RELIABLE

srcPeerID=20

dstPeerID=ALL

pktID=125

flags=RESPONSE

srcPeerID=2

dstPeerID=7

pktID=342

7

49

2

2

RQST

20

3

3

7

49

2

2

RQST

7

49

2

2

RSPN

RSPN

RSPN

7

49

2

220

3

3

RSPN

flags=RELIABLE

srcPeerID=7

dstPeerID=ALL

pktID=342

flags=RESPONSE

srcPeerID=7

dstPeerID=20

pktID=125

1 2

34


Figura 89. Bloque de definición de zona.

Los bloques de definición de zona ocupan 6 bytes y están

compuestos por 3 campos: el identificador de la zona (zoneID) el

identificador de su zona padre (parentID) y el número de nodos

que componen esa zona (neighbors).

Los bloques de definición de nodo siguen la estructura de la figura 90.

Figura 90. Bloque de definición de nodo.

Cada bloque ocupa 11 bytes y está compuesto por 5 campos: el

identificador del nodo (peerID), la zona a la que pertenece

(zoneID), el tipo del nodo (peerType), su dirección IP (ip) y su

puerto (port).

Byte / Bit 0 8

0zoneID

1

2parentID

3

4neighbor s

5

Byte / Bit 0 7

0peerID

1

2zoneID

3

4 peerType

5

ip6

7

8

9port

10


A continuación vamos a ver cada uno de las operaciones posibles.

En todo momento llamaremos peerA al peer que envía la

solicitud, peerB al peer que responde y sid al identificador de sesión.

Operación PEER

La operación PEER es de tipo comando y permite a un nodo:

Incorporarse a una sesión cuando es un nodo nuevo (aun

no tiene peerID).

Actualizar los datos de un peer, por ejemplo indicar a que zona pertenece.

La operación siempre es confiable e inter-zonas.

Sólo el emisor principal puede realizar las altas en la sesión, si otro nodo recibe este tipo de paquete contestará con un error de operación no soportada (código 5).

Si el emisor principal recibiera una solicitud de un nodo cuyo tipo también es emisor principal contestaría con un error de tipo de nodo incorrecto (código 4).

Tanto la solicitud como la respuesta tienen un mismo cuerpo tras la cabecera que se puede ver en la figura 91.

Figura 91. Cuerpo de la operación PEER.

El primer campo del cuerpo, version, es la versión de MDCTP utilizada. Si el emisor principal no soporta la versión indicada en la solicitud contestará con un error versión de MDCTP no soportada (código 128).

Los siguientes campos hr y vr son utilizados sólo en la respuesta e indican los valores de recuperación horizontal y vertical utilizado por el módulo de corrección preventiva del emisor. Más adelante se explica estos valores.

Byte / Bit 0 7

0 version

1 hr

2 vr


En la tabla 41 podemos ver qué valores deben de tener los paquetes de solicitud y respuesta para esta operación en caso de que no se produzca ningún error.

Tabla 41. Valores de la solicitud y respuesta de la operación PEER.

Campo Solicitud Respuesta

sessionID sid

flags RELIABLE | ZONE RESPONSE | ZONE

peerType peerA.type (≠ 1) 1

operation 1 (PEER) 0

srcPeerID peerA.peerID (≥ 0) 1

dstPeerID 1 peerA.peerID

zoneID peerA.zoneID (≥ 0) 1

pktID peerA.pktID

ack 0 0

next 0 0

out peerA.bufferSize (> 0) peerB.bufferSize (> 0)

version 1

hr 0 peerB.hr (≥ 0)

vr 0 peerB.vr (≥ 0)

Ésta es la única operación que soporta que un paquete sea enviado con el identificador de nodo origen a 0, en el caso de que el nodo aun no esté suscrito a la sesión. En la solicitud también

puede ir el campo zoneID a 0 cuando el nodo aun no conoce cuál es su zona.


Operación ZONE

La operación ZONE permite a los nodos unirse a una zona. La operación es de tipo comando e intra-zona.

Uno nodo utiliza la operación ZONE para determinar en qué zona se encuentra y descubrir que vecinos tiene. La solicitud

normalmente se envía por difusión y con dstPeerID=0 para que responda algún miembro de la zona (si existe).

Tanto en la solicitud como en la respuesta el paquete va con el cuerpo vacio.

En la tabla 42 se muestra los valores de los campos de la cabecera en la solicitud y la respuesta en el funcionamiento normal del comando.

Tabla 42. Valores de la solicitud y respuesta de la operación ZONE.

Campo Solicitud Respuesta

sessionID sid

flags RELIABLE RESPONSE

peerType peerA.type peerB.type

operation 2 (ZONE) 0

srcPeerID peerA.peerID (≥0) peerB.peerID (≥0)

dstPeerID ALL peerA.peerID

zoneID 0 peerB.zoneID

pktID peerA.pktID

ack 0 0

next 0 0

out peerA.bufferSize (>0) peerB.bufferSize (>0)

En el cuerpo de la solicitud el nodo que envía el paquete incluye un bloque de definición de nodo (ver figura 90). En ese bloque se


incluirán los datos del emisor principal, necesario para la incorporación de nodos de soporte de la zona que quieran unirse a la sesión. Más adelante se explicará en detalle su funcionamiento.

En el cuerpo de la respuesta el nodo incluirá información sobre otros vecinos de la zona (en bloques de definición de nodo) que ya conozca, de forma que los receptores de la respuesta puedan ir completando la información sobre la zona. El número de nodos definidos dependerá del tamaño máximo del paquete.

Operación DEL

La operación DEL informa de la salida de un nodo de la sesión. Es utilizado normalmente cuando un nodo detecta la caída de un nodo para informar a otros nodos de la sesión que el nodo caído ya no participa en el proceso de comunicación.

También es posible utilizar el comando para indicar la desaparición de una zona completa.

La operación es de tipo comando y puede ser utilizada en intra-zona y en inter-zonas.

En el cuerpo del paquete se incluye los identificadores de los nodos que abandonan la sesión así como de la zona a la que pertenece. El número de bloques de nodo-zona vendrá determinado por el tamaño máximo del paquete. Si en el

identificador de nodo aparece el valor ALL significará que desaparece la zona completa a la que está relacionada.

La figura 92 ilustra el cuerpo de la solicitud de la operación.

Figura 92. Cuerpo de la solicitud de la operación DEL.

Byte / Bit 0 7

0peerID

1

2zoneID

3

x N


Operación INFO

La operación INFO permite a un nodo informar sobre datos de otras zonas y nodos de la sesión. Suele ser utilizado por el emisor principal para indicar a otros nodos en que zona del bosque se sitúan.

La operación puede ser de tipo intra-zona o inter-zonas.

El cuerpo del mensaje, que sigue a las cabeceras, tiene la estructura que se muestra en la figura 93.

Figura 93. Cuerpo de la solicitud INFO.

Hay dos campos iniciales numZones y numPeers que indica el número de zonas y nodos que van a definirse en este paquete. A continuación le siguen tantos bloques de definición de zona y de nodo como se haya indicado en los primeros campos. El tamaño del cuerpo es variable y dependiente del número de zonas y nodos descritos.

Después de los campos iniciales se incluirán tantos bloques de

definición de zona como se haya indicado en numZones. Notar que el número de zonas puede ser 0. Cada bloque de definición de zona sigue la estructura de la figura 89.

Tras los bloques de definición de zona aparecen los bloques de definición de nodos (descritos en la figura 90), tantos como se

indique en el campo numPeers, que también puede ser 0.

El nodo generador de la solicitud será quien decida cuantas zonas y nodos definir, limitado siempre por el tamaño máximo del paquete.

El paquete de respuesta tiene el cuerpo vacio.

Byte / Bit 0 7

0 numZones

1 numPeers

2 zoneDefinition

…

peerDefinition

…

x numZones

x numPeers


Operación PING

La operación PING permite a un nodo identificar si otro nodo esta accesible mediante una solicitud de eco. El comando es confiable y puede ser intra-zona o inter-zonas.

Adicionalmente la operación PING permite a un nodo calcular la distancia a otro nodo, entendida como el tiempo en microsegundos que tarda el paquete de solicitud en ir al destino más el tiempo que tarda en llegar el paquete de respuesta.

Para el cálculo el nodo origen de la solicitud anota el

microsegundo en el que emitió la solicitud (A1) y posteriormente

registra el momento en el que llega la respuesta (A2). El tiempo

total de la operación sería A2-A1. Sin embargo en este tiempo, además del tiempo de transferencia, también está incluido el tiempo de procesado perdido en el destino. Si la solicitud llegó al

destino en B1 y la respuesta fue enviada en B2 el tiempo de

procesado será B2-B1. Para que el emisor pueda descontar el tiempo de procesado el destino incluye en la respuesta dicho tiempo. De esta manera el origen del comando calculará el tiempo

de procesado como (A2-A1)-(B2-B1).

Por lo tanto el cuerpo de la respuesta de la operación PING

incluirá el campo processTime de 4 bytes ilustrado en la figura 94

que es el tiempo de procesado (B2-B1) expresado en microsegundos.

Figura 94. Cuerpo de la respuesta de la operación PING.

Dado que la información mandada por el destino de la operación es un lapso de tiempo y no tiempos globales no es necesaria ninguna sincronización de relojes entre los nodos.

La figura 95 se ilustra el funcionamiento de la operación ping.

Byte / Bit 0 7

0

processTime1

2

3


Figura 95. Esquema de funcionamiento de la operación PING.

Operación DPING

La operación DPING permite a un nodo conocer las distancias entre un segundo nodo y un conjunto de nodos.

Esta operación es utilizada por el emisor principal para conocer las distancias entre las distintas zonas de que conforman los nodos de una sesión.

Figura 96. Cuerpo de la solicitud de la operación DPING.

En el cuerpo de la solicitud se incluirá una lista de nodos a los

que el nodo receptor del comando DPING tendrá que realizar un

PING. Dado que es posible que el nodo destino no conozca los

A1

B1

B2

A2

PING-RQST

PING-RSPN(B2-B1)

Byte / Bit 0 7

0

peerDefinition

1

2

3

4

5

6

7

8

9

10

x N


nodos a los que tiene que enviar un PING la dirección de los mismos será incluida en la solicitud.

El cuerpo de la solicitud tendrá por lo tanto una secuencia de definición de nodos tal cual se ilustró en la figura 90.

En la figura 96 podemos ver como quedaría el cuerpo de la

solicitud de la operación DPING.

La respuesta de la operación contendrá en el cuerpo una lista de

bloques donde se indica el identificador de nodo (peerID) y la

distancia en microsegundos (distance) tal cual se puede ver en la figura 97.

Figura 97. Cuerpo de la respuesta de la operación DPING.

Operación DATA

La operación DATA permite a un nodo enviar un bloque de datos a otro. Esta operación es de tipo notificación (sin respuesta) y puede enviarse en modo intra-zona o inter-zonas.

En el cuerpo del mensaje aparecerán los campos reflejados en la figura 98.

Figura 98. Cuerpo de la operación DATA.

Byte / Bit 0 7

0peerID

1

2

distance3

4

5

x N

Byte / Bit 0 7

0dataID

1

2dataSize

3

4 dataContent

… …


Cada bloque de datos tendrá un identificador de datos (dataID) que representa su posición dentro del flujo de datos. El primer bloque de datos es el bloque 0. El identificador es cíclico de forma que cuando llegue a su máximo valor volverá a comenzar de 0.

El identificador de datos permitirá a los nodos ordenar correctamente el flujo de información y permitirá a estos identificar bloques de datos perdidos.

En dataSize se indica el tamaño del bloque enviado. Todos los bloques tendrán el mismo tamaño excepto el último que podrá ser un bloque incompleto. En la versión 1 del protocolo se estables un tamaño de bloque de 1024 bytes.

Por último en dataContent tendremos tantos bytes de datos como

indica el campo dataSize.

Operación HDATA

La operación HDATA se corresponde con el envío de un bloque de corrección preventiva de tipo horizontal. La operación es de tipo notificación y el funcionamiento y cuerpo del mensaje son

idénticos al del comando DATA.

En este caso el identificador del bloque de datos (campo dataID de la figura 98) indica que el contenido del bloque (campo

dataContent) es el XOR de todos los bloques desde 0 hasta el

dataID.

Operación VDATA

La operación VDATA es similar a la HDATA pero se corresponde con un campo de recuperación vertical.

El contenido del bloque (campo dataContent de la figura 98) es el

XOR de todos los bloques hasta el indicado en dataID cuyo

módulo respecto a HR se corresponda con el módulo respecto HR

del campo dataID.

Posteriormente se explicará en detalle los bloqeus de recuperación preventiva.


Operación ACK

La operación ACK permite a un nodo confirmar la recepción de datos. La operación es de tipo notificación y puede ser intra-zona o inter-zonas.

En el caso de que sea un paquete inter-zonas el cuerpo irá vacio. Sin embargo en los paquetes intra-zona en el paquete se incorporará el cuerpo indicado en la figura 99.

Figura 99. Cuerpo del mensaje ACK en paquetes intra-zona.

Los paquetes ACK intra-zonas son paquetes que un nodo, al

recibir un ACK de una zona hija, difunde dentro de su zona. En el cuerpo del mensaje indica el identificador de zona de la zona hija

de la que le llegó el paquete (en el campo childZoneID) así como

sus datos de ack (campo childAck), next (campo childNext) y out

(campo childOut).

Operación STATUS

La operación STATUS es de tipo notificación y sirve a los nodos para indicar que siguen presentes en el sistema. Permite a los miembros de una sesión detectar que un nodo a caído al no

recibir en un tiempo determinado un paquete de tipo STATUS.

La operación puede ser inter-zonas o intra-zona y no tiene cuerpo.

Byte / Bit 0 8

0childZoneID

1

2childAck

3

4childNext

5

6childOut

7


Fase de Conexión

Durante la fase de conexión todos los participantes de la comunicación se ponen en contacto con el emisor para obtener los datos necesarios y sincronizar el proceso de transferencia.

A nivel de conexión básicamente existen dos tipos de nodos: el emisor principal (parte pasiva en la conexión) y el resto de nodos (partes activas). Durante el proceso de conexión dichas partes se comportarán de forma distinta. El único punto en común de

todas las partes será el sessionID que coincidirá en todos los paquetes enviados durante la transmisión.

En los sistemas donde sólo existen dos participantes el proceso de conexión básicamente se reduce a un proceso de sincronización inicial entre ambos extremos. En este caso, al existir más de dos participantes, el proceso es algo más complejo.

Hemos centralizado las labores de sincronización en el lado del emisor, de forma que sea este elemento el que controle el proceso de sincronización.

Inicialmente los nodos no tendrán información sobre el resto de componentes y, según avance el proceso de comunicación, los nodos irán descubriendo información sobre otros nodos de la sesión. Para ello gestionarán una serie de conjuntos (de nodos, de vecinos y de zonas) donde irán incorporando esta información

La fase de conexión está dividida en dos sub-fases. En la primera, la sub-fase de incorporación, se reciben las peticiones para incorporar nuevos nodos en la sesión. En la segunda, sub-fase de conformación, se genera el bosque de zonas y se informa a los nodos.

Sub-fase de incorporación

Una de las cosas que hay que decidir es cuál es la ventana de conexión, es decir, durante que periodo el emisor está esperando la incorporación de otros nodos a sesión de transferencia. Las principales opciones que se barajan en estos casos es, bien por número de participantes (si es algo que se conoce a priori), bien por límite de tiempo.

En nuestro caso hemos decidido un enfoque mixto. El emisor puede determinar un número máximo de participantes de forma que una vez se llega a este número la sub-fase de incorporación


ésta finaliza y comienza la sub-fase de conformación. Además el emisor podrá establecer un tiempo de espera, cumplido el cual la fase de finalización también acaba. Complementariamente se podrá indicar un tiempo de prórroga de forma que se irá incrementando el tiempo de finalización de la conexión por cada nueva conexión realizada. Para evitar que el tiempo se vaya prorrogando indefinidamente debido a numerosas conexiones también se podrá indicar el tiempo máximo de espera. De esta manera el emisor indicará mediante unas opciones del socket los parámetros del proceso de conexióbn. Estos parámetros están resumidos en la tabla 43.

Tabla 43. Opciones de conexión.

Opción Descripción

MaxNumberPeer Número máximo de nodos que se pueden conectar. Un valor 0 indica que no se contempla este argumento.

MaxTime Tiempo máximo de espera en segundos del proceso de comunicación. Un valor 0 indica que no se contempla un tiempo de espera.

ExtensionTime Tiempo a extender el tiempo máximo de espera por

cada nodo nuevo que se conecte.

TotalTime Tiempo máximo total de espera del proceso de conexión. El tiempo máximo más las prorrogas no pueden superar este valor.

Evidentemente es necesario establecer al menos un criterio temporal o de número de nodos para que el proceso de conexión pueda acabar en algún momento.

Durante esta sub-fase los nodos realizarán dos procesos consecutivos: uno de identificación, donde los nodos se dan de

alta en la sesión y determinan cual es su peerID y luego uno de agrupación donde determinan a que zona pertenecen y por lo

tanto su zoneID.


Proceso de Identificación

Durante este proceso los nodos conformarán el conjunto de

nodos de la sesión y cada uno determinará cuál es su peerID.

Para este proceso el emisor principal, única parte pasiva en la conexión, realizará los siguientes pasos:

1. Inicialización de temporizadores. Si se ha indicado un

valor no nulo en MaxTime establece un temporizador con su valor.

2. Creación del nodo emisor. El emisor principal se dará de

alta en el conjunto de nodos con el peerID=1.

3. Creación de la zona principal. Crea la una zona con

zoneID=1 e incorpora al emisor en dicha zona.

4. Esperar conexiones. El emisor principal queda a la espera de conexiones o del cumplimiento del temporizador.

En la figura 100 podemos ver un esquema del escenario configurado por el emisor.

Figura 100. Escenario del emisor al iniciar.

Además, durante el proceso de identificación el emisor principal atenderá a los siguientes mensajes:

Solicitud de conexión. Recibirá paquetes con

operation=PEER, flags=RELIABLE|ZONE. Si srcPeerID=0 añadirá el peer a la lista de peer. El tipo del peer vendrá

indicado en peerType. El emisor registrará el peer asignándole el siguiente identificador libre. Contestará

con un mensaje indicando en dstPeerID el identificador asignado. Si el número de nodos supera el argumento

1

1


maxNumberPeers se finaliza la sub-fase de incorporación. Si

se estableció un valor en extensionTime se incrementará

connectionTime sin que supere totalTime. Si srcPeerID≠0 se actualizan los datos del nodo.

Actualización de información. Recibirá paquetes con

operation=UPDATE y flags=RELIABLE|ZONE. Se actualizará los datos del peer. Principalmente utilizado para que un nuevo peer indique cual es su zona. Más adelante se explica con detalle.

Solicitud de incorporación a la zona. Recibirá paquetes de incorporación a la zona de otros vecinos de la zona. Esta función la realiza igual que otros integrantes de la sesión y se explica a continuación.

Para determinar cuál es el peerID que tendrá otro nodo que desee incorporarse a la sesión, éste se deberá poner en contacto con el emisor primario. Los pasos que realizará son:

1. Solicitar la entrada a la sesión. El nodo enviará un

paquete con los siguientes datos: flags=RELIABLE|ZONE,

operation=PEER, srcPeerID=0, dstPeerID=1. El nodo

indicara el tipo de peer que es en peerType de forma que el

emisor pueda registrarlo y con un 0 en srcPeerID indicará que aun no tiene un identificador asignado.

2. El nuevo nodo recibe la contestación. En la respuesta

que el emisor le da al nuevo nodo en el campo dstPeerID se encuentra el identificador del nuevo nodo.

3. El nuevo nodo no recibe contestación. Si no se recibe contestación del emisor tras varios intentos se aborta la conexión y se informa a la capa de usuario del fallo.

En la figura 101 podemos ver un ejemplo de cómo se incorpora un nuevo nodo a la sesión donde se ilustra el escenario y el paquete al enviar la solicitud y al recibir la respuesta de la

operación PEER.


Figura 101. Proceso de incorporación de un nodo a la sesión.

Según se van añadiendo nodos a la sesión el emisor va conformando un escenario como el que se puede ver en la Figura 102.

Figura 102. Escenario tras la incorporación de varios nodos.

Finalizado este proceso, una vez se cumple el tiempo de espera o se llega al máximo de nodos permitidos, tendremos lo siguiente: el emisor principal conocerá la existencia de todos los nodos de la sesión (su identificador, dirección, tipo y ventana de transferencia) y el resto de nodos conocerán al emisor principal

(con los datos de su buffer) y cuál es su peerID.

Proceso de agrupación

Una vez obtenido el identificador del nodo el nodo determinará en que zona se encuentra (si ya hay algún otro nodo) o creará una nueva (si es el primero).

?

1

1

sessionID=7983

flags=RELIABLE | ZONE

peerType=RECEIVER

operation=PEER

srcPeerID=0

dstPeerID=1

zoneID=0

pktID=1

ack=0

next=0

out=32

1

1

2

sessionID=7983

flags=RESPONSE | ZONE

peerType=ROOT

operation=0

srcPeerID=1

dstPeerID=2

zoneID=0

pktID=1

ack=0

next=0

out=64

SOLICITUD RESPUESTA

21

13

4


Para ello el nodo difunde por multicast o broadcast un paquete

sonda de solicitud de zona con operation=ZONE, flags=RELIABLE,

dstPeerID=0 y en zoneID=0. También se rellenarán los campos de ventana.

Si tras varios intentos no se recibe ninguna respuesta se asume que es el primero de la zona y se asigna automáticamente como identificador de zona el propio identificador de peer:

zoneID=peerID. Con esto el identificador de la zona se corresponde con el identificador del primer nodo de esa zona (el que tiene el identificador más bajo).

En la figura 103 se puede ver el escenario al difundir la sonda y una vez no se ha recibido respuesta alguna.

Figura 103. Creación de una zona nueva.

Si recibe un paquete de respuesta (pueden ser varios) se asigna

como zona la indicada en zoneID y se añade este nodo como vecino de la zona. Si se recibiera más de un paquete con distintas zonas se dará prioridad a la zona con el valor inferior. Con las respuestas el nodo podrá registrar cuáles son sus vecinos.

Para conformar la zona con el resto de nodos vecinos, son los propios vecinos los que responden a las solicitudes de zona (incluido el emisor principal que contestará a los vecinos de la zona 1). Si, una vez está establecida la zona, se recibe una solicitud de zona de algún nodo se contestará indicando la zona

en zoneID para que el solicitante se pueda unir a dicha zona.

1

1

1

1

22 2

sessionID=7983

flags=RELIABLE

peerType=RECEIVER

operation=ZONE

srcPeerID=2

dstPeerID=0

zoneID=0

pktID=2

ack=0

next=0

out=32

SOLICITUD SIN RESPUESTA


En el caso de que existan muchos vecinos en la zona el nuevo nodo se saturaría con la respuesta de todos. Por ello la solicitud

la realizará con dstPeerID=0 para que todos esperen un tiempo aleatorio y contesten por difusión. El primero que conteste anulará la respuesta de los demás. En la respuesta el nodo incluirá en el cuerpo del mensaje la definición de un conjunto aleatorio de vecinos de la zona, tantos como permita el tamaño máximo del paquete.

Sólo se contestará a peticiones que tengan la misma dirección de difusión.

En la figura 104 se ilustra la incorporación de un nuevo nodo (el 3) en la zona 2.

Figura 104. Inclusión en una zona existente.

Cada vez que se reciba una solicitud o una respuesta los nodos irán incorporando a estos como vecinos de su zona, completando la información de la zona que va teniendo cada uno.

Si antes de recibir respuesta se recibe un paquete de solicitud de

zona (con operation=ZONE y flags=RELIABLE) estaremos ante una solicitud cruzada, es decir, dos nodos de la misma zona se conectan a la vez y envían simultáneamente un mensaje de solicitud de zona. En estos casos, para resolver el conflicto, se dará prioridad al identificador con valor más bajo, es decir el

valor de srcPeerID inferior. Ambos nodos asignarán este valor

como su zona y contestarán con dicho valor en el zoneID de la respuesta.

1

1

1

122

3

22

3sessionID=7983

flags=RELIABLE

peerType=RECEIVER

operation=ZONE

srcPeerID=3

dstPeerID=0

zoneID=0

pktID=2

ack=0

next=0

out=32

sessionID=7983

flags=RESPONSE

peerType=RECEIVER

operation=0

srcPeerID=2

dstPeerID=3

zoneID=2

pktID=2

ack=0

next=0

out=32

SOLICITUD RESPUESTA


Según avance la conexión los nodos irán conociendo cuáles son sus vecinos. Es posible que se dé el caso de que un nodo no conozca a alguno de sus vecinos, posiblemente porque no recibió el paquete de solicitud. Esto no es un problema ya que durante la fase de transferencia se irá completando la información referente a los vecinos.

Una vez determinada cual es la zona, el nodo deberá informar de

ello al emisor principal. Para ello envía otro mensaje de tipo PEER

para actualizar los datos, esta vez estableciendo en srcZoneID cual es la zona. Los vecinos de la zona 1 no deberán realizar este proceso ya que el emisor principal ya les conoce.

Incorporación de Nodos de Soporte

En este proceso ya que las solicitudes se realizan por difusión el paquete puede llegar a nodos suscritos a la dirección de difusión pero que no participan en un principio en la sesión. Si el nodo está configurado para ello puede decidir incorporarse a la sesión como nodo de soporte, ya que en un principio no está interesado en la información en sí. Esto amplia la capacidad colaborativa del sistema, ya que permite incorporar nodos en la sesión de forma no explícita.

Así pues cuando un nodo recibe un paquete con operation=ZONE asume que en su campo de difusión hay un nodo que quiere integrarse en una zona y puede decidir unirse a la sesión. El

sessionID lo extraerá de la cabecera del protocolo.

Para realizar la incorporación del nodo de soporte a la sesión éste necesitará conocer cuál es la dirección del emisor principal. Esto lo obtendrá del cuerpo de la solicitud de zona.

En la figura 105 se ilustra como un nodo de soporte detecta la sonda del nodo 7 y se une a la sesión dentro de la zona 7.


Figura 105. Incorporación de un nodo de soporte.

Sub-fase de Conformación

Como se ha visto, la sub-fase de incorporación permite a todos los

nodos conocer cuál es su peerID y cuál es la zona a la que pertenece, así como también conocer algunos de los vecinos, potencialmente todos.

En el caso particular del emisor principal además sirve para conocer a todos los participantes en la comunicación.

A partir de este momento el emisor no admite mas altas en la sesión, quedando cerrado el número de nodos de la misma.

Llegados a este punto el emisor principal debe determinar cuál es el bosque completo de zonas del sistema. Para ello previamente debe asegurarse que tiene completada la información referente a todos los nodos.

El emisor principal revisará el conjunto de los distintos nodos de la sesión. Si encuentra alguno que no tienen zona puede ser debido a que, bien porque no recibió la actualización de los datos, bien porque el nodo abandonó la sesión (sin informar de ello) antes de completar la conexión.

En cualquier caso si algún nodo no tiene aun asignado un identificador de zona el emisor principal le manda un paquete

1

1

77

sessionID=7983

flags=RELIABLE

peerType=RECEIVER

operation=ZONE

srcPeerID=7

dstPeerID=0

zoneID=0

pktID=2

ack=0

next=0

out=32

SOLICITUD ZONE

?

1

1

7

sessionID=7983

flags=RELIABLE | ZONE

peerType=SUPPORT

operation=PEER

srcPeerID=0

dstPeerID=1

zoneID=7

pktID=1

ack=0

next=0

out=64

SOLICITUD PEER

?7

1

1

7

sessionID=7983

flags=RESPONSE

peerType=ROOT

operation=0

srcPeerID=1

dstPeerID=10

zoneID=1

pktID=24

ack=0

next=0

out=64

RESPUESTA PEER

10


PING al nodo para averiguarlo. El ping será un paquete con

operation=PING y flags=RELIABLE|ZONE.

Si el nodo contesta al ping el emisor principal obtiene la zona del

campo zoneID del la respuesta.

Si no hay respuesta elimina al nodo de la lista de nodos asumiendo que ya no está en la sesión. Si el nodo tenia vecinos

informar a estos mediante el comando DEL.

Si se detecta más de un emisor por zona se deja sólo uno de ellos, ya que sólo un emisor puede coordinar cada árbol. El emisor con preferencia será siempre el de identificador más bajo.

Una vez el emisor principal conoce la situación de todos los nodos revisa las zonas. Si encuentra zonas vacías, es decir, zonas sin nodos, elimina dichas zonas de la lista de zonas. Si alguna de las zonas no está vacía pero solo tiene nodos de soporte también es eliminada ya que estos nodos no pueden colaborar directamente con ningún nodo.

Proceso de Creación del Bosque

Una vez el emisor tiene la lista de zonas activas en la transmisión procede a crear los árboles de transmisión. Existirá una zona raíz por cada zona que tenga un emisor. La forma en la que se conforman los árboles dependerá de varios parámetros. El emisor principal podrá tener configurado un máximo de zonas hijas por cada zona, que determinará la anchura máxima del árbol. A la hora de asignar las zonas hijas podrá hacerlo desde aleatoriamente hasta basándose en funciones de distancia entre zonas.

Calcular las distancias entre zonas permitiría al emisor conocer cuáles son las mejores zonas hijas para una determinada zona, de forma que los árboles se ajusten lo máximo posible a la topología real de la red.

En nuestro caso, para calcular la distancia entre dos zonas vamos a utilizar el tiempo de transferencia de ida y vuelta de un paquete entre zonas. Para ello un nodo de una zona enviará un

comando PING a un nodo de otra zona.

Para conocer los tiempos de transferencia entre zona el emisor

principal utilizará comandos PING delegados (DPING). Mediante un ping delegado el emisor principal de dice a un nodo de otra zona


que realice un ping con nodos de otras zonas. Al realizar esos pings el nodo determinará que distancias tiene con las otras zonas, información que suministrará al emisor principal en el paquete de respuesta.

Con ello el emisor principal rellenará una tabla de distancias entre zonas que será la entrada de la función que conformará el bosque de zonas (ver figura 106).

Figura 106. Tabla de distancias entre zonas.

Dado que tendremos calculado las distancias entre dos zonas partiendo desde una o desde otra, crearemos una tabla resumida donde se refleja la media de estas distancias (figura 107).

Figura 107. Tabla de distancias entre zonas resumida.

Una vez determinada la tabla de distancias el proceso de conformación del árbol dará prioridad a las distancias más pequeñas. El algoritmo de creación del árbol va creando aristas

38 34 34 40

38 44 54 42

38 46 3 60

34 54 5 45

40 42 68 45

1 2 95 12

1

2

5

9

12

38 36 34 40

45 54 42

4 64

45

1 2 95 12

1

2

5

9

12


entre las distintas zonas. El algoritmo realiza un bucle mientras queden valores en la tabla y en cada iteración realiza lo siguiente:

Selecciona el valor de distancia más pequeño de la tabla.

Crea una arista en el grafo uniendo las dos zonas que indica el valor.

Si el número de aristas de cada uno de los dos nodos supera el máximo de hijos mas uno (el padre) se descarta la arista. En el caso de las zonas de emisión no se contará con la arista extra del padre, ya que no tienen.

Si al crear la arista se detecta un bucle cerrado en el grafo descartar la arista, ya que un árbol es un grafo sin ciclos.

Si al crear la arista se detecta un camino entre dos emisores se descarga la arista, ya que los árboles de cada emisor deben de ser grafos independientes.

Borrar la distancia del grafo y continuar con la siguiente iteración mientras queden distancias.

Figura 108. Creación de una árbol de zonas.

38 36 34 40

45 54 42

4 64

45

1 2 95 12

1

2

5

9

12

1

9 2

125

Paso Acción

1 Crear arista 5-9 (valor 4)


3 Descartar arista 1-5 (valor 36) por crear un ciclo


5 Descartar arista 1-12 (valor 40) por superar el numero de aristas


… El resto de aristas se descartan por crear bucles


Como ejemplo se puede ver en la figura 108 la traza de ejecución para una configuración con un solo emisor.

Tras el proceso de conformación del bosque tendremos la distribución final de las zonas. El tamaño y profundidad de los árboles podrá diferir, ya que la conformación de los mismos se realiza por distancias locales entre zonas, no por distribución equitativa entre árboles.

Proceso de Información al Bosque

Una vez tiene claro donde se sitúa cada zona el emisor principal deberá indicar a los miembros de cada zona donde se encuentran dentro del bosque. Para ello realizará lo siguiente:

1. Informar a los vecinos. El emisor indicará a sus vecinos (si existen) la configuración de la zona 1. Esto se realizará mediante un proceso similar a la del punto 3.

2. Informar de su posición en el árbol a cada zona. Por cada zona el emisor enviará un mensaje de tipo INFO a los miembros de la zona. Para ello enviará un mensaje a uno

de los miembros de la zona con los datos: operation=INFO,

flags=RELIABLE|ZONE y dstPeerID=ALL. En el contenido del mensaje aparecerán la información sobre distintas zonas:

La zona emisora. Es la zona que aparece con un

valor de parentID igual a 0. Es la zona raíz del árbol asignado.

La zona del peer. Es la zona cuyo zoneID coincide

con el zoneID del nodo. En ella se indica quien es el padre y cuantos vecinos de zona hay.

Las zonas hijas. Son las zonas cuyo parentID

coincide con el zoneID del nodo.

Además, de la zona emisora, de la zona padre y de las zonas hijas se definirá al menos un nodo representativo de cada zona.

3. Difusión de la información en la zona. El miembro que reciba el mensaje (así como el emisor principal en su zona) difundirá el mismo en su zona y recogerá el asentimiento del resto de vecinos. Cuando todos hayan confirmado la lectura se enviará una contestación al emisor.


Fase de Transferencia

Terminada la fase de conexión cada nodo conoce los siguientes datos:

Cuál es su peerID.

Cuál es su zoneID.

Quién es el emisor principal.

Quién es el emisor de su zona.

Cuántos vecinos de zona tengo.

Los datos de varios de sus vecinos (potencialmente todos).

Cuál es mi zona padre y al menos un nodo de esa zona.

Cuáles son mis zonas hijas y al menos un nodo de cada zona.

Para la transmisión los datos son fraccionados en bloques de tamaño fijo. Todos los bloques tendrán el mismo tamaño excepto el último que podrá ser menor. El tamaño de bloque definido para datos es de 1024 bytes.

Cada bloque de datos irá identificado por su número de secuencia (dataID) que empezará en 0.

La transferencia funciona básicamente a dos niveles: la transferencia entre zonas (protocolo inter-zona) y la difusión entre vecinos de una zona (protocolo intra-zona).

El protocolo inter-zonas establece cómo distribuir la información entre zonas, desde el emisor hasta las zonas hoja. A grandes rasgos el protocolo actúa de la siguiente forma:

Cuando hay un bloque de datos disponible en el emisor este lo difunde en su zona y posteriormente selecciona un nodo de cada zona hija y le envía una copia de los datos.

Cuando un nodo recibe un paquete de datos de un nodo de otra zona lo difunde en su zona y lo retransmite también a las zonas hijas.

Los miembros de cada zona envían paquetes de confirmación a la zona padre indicando la información recibida.


En caso de considerarlo necesario una zona puede reenviar un paquete de datos a una zona hija asumiendo que esta no ha recibido un paquete.

En el protocolo inter-zonas la individualidad de los componentes de la zona no es importante. Cuando una zona envía datos a otra zona decide a que nodo de la zona se lo envía. El criterio de selección dependerá de la implementación y podría ser desde aleatorio hasta basado en el rendimiento de cada nodo.

El protocolo intra-zona define como se realiza la difusión de la información dentro de una zona. Es aquí donde reside una de las principales ventajas del protocolo ya que esta difusión se realiza mediante multicast o broadcast. La difusión solo tiene un par de excepciones: si sólo hay un nodo en la zona no se realiza la difusión y si sólo hay un vecino más los datos se envían directamente por unicast

Buffer de Transferencia

Para realizar la transferencia cada nodo utilizará un buffer de bloques de datos o buffer de transferencia. El protocolo no establece el tamaño del buffer, de forma que cada nodo decidirá el tamaño del buffer, en función de los recursos de cada dispositivo. En el buffer de transferencia se gestiona la ordenación de los bloques de datos y también se utiliza de almacén temporal de la información hasta que las aplicaciones de usuario lean el contenido del flujo de información (ver figura 109). Evidentemente cuanto mayor sea el buffer de transferencia más se favorece el proceso de transmisión.


Figura 109. Esquema de uso del buffer de transferencia.

El buffer actúa como una ventana deslizante que recorre todos los bloques del flujo de información. En todo momento vendrá

caracterizado por el primer bloque del buffer (buffer.first) y su

tamaño (buffer.size). Al primer bloque que se encuentra fuera del buffer lo definiremos como

buffer.out=buffer.first+buffer.size. En la figura 110 el buffer

que se muestra tiene como datos: buffer.first=13,

buffer.size=10 y buffer.out=23. Según avance la comunicación el buffer se irá despazando hacia la derecha, incrementando el

valor de buffer.first y por lo tanto de buffer.out.

Figura 110. Ejemplo de buffer de transferencia.

Dentro del buffer de transferencia podremos tener bloques que ya hemos recibido y huecos donde aun no se ha recibido ningún bloque.

RECEPTOREMISOR

Buffer de Transferencia Buffer de Transferencia

Proceso de usuario


Proceso de usuario

Leer

Proceso de transferencia

Proceso de transferencia

Escribir


10 11 12 13 14 15 16 17 18 19 20 21 22 24 25... ...

Flujo de información

first out

23

size


Las aplicaciones actuarán de dos únicas maneras con el buffer: los emisores escribirán sobre él y los receptores leerán de él (ver figura 109). El siguiente bloque sobre el que se va a leer o escribir

lo denominaremos buffer.process. Por lo tanto todos los bloques

antes de buffer.process ya han sido escritos (emisor) o leídos (receptor). Los nodos de soporte no gestionan ningún

buffer.process. Antes de buffer.process no existirá ningún hueco en el buffer. Evidentemente siempre se cumple que:

buffer.first <= buffer.process <= buffer.out

El emisor solo podrá escribir en el buffer si el bloque que indica

buffer.process está dentro del buffer (< buffer.out) y es un bloque vacío y un receptor solo podrá leer de un bloque cuando en este existan datos. Las operaciones de lectura y escritura son destructivas, es decir, una vez realizado se incrementa

buffer.process y la aplicación ya no se tiene acceso al bloque anterior. Cuando una aplicación no puede escribir o leer quedará a la espera de que se actualice el buffer al igual que en TCP.

A un nodo irán llegando diversos bloques de datos de forma que en un momento dado tendremos una combinación de datos y huecos en el mismo. De todos los bloques hay dos que nos

interesan principalmente: buffer.recovery que es el primer

hueco del buffer y buffer.next que es el último hueco del buffer que no tiene a su izquierda otro hueco. Todos los bloques antes

de ack han sido recibidos y next es el bloque posterior al mayor

bloque almacenado en el buffer. En el caso de un emisor ack y

next siempre son iguales a process.

Estos dos bloques separan el buffer en tres zonas que denominaremos: ventana de envío y procesado, ventana de recuperación y reordenación y ventana de recepción. Las ventanas se ilustran en la figura 111.

La ventana de envío y procesado, delimitada entre buffer.first y

buffer.recovery, es la zona primera de la ventana donde sólo existen bloques con dato. Es en esta ventana donde se realiza el envío o reenvió de bloques de información y donde se realiza el procesado de los datos (escritura en el caso de los emisores y

lectura en el caso de los receptores), es decir que buffer.process siempre se mueve a lo largo de esta ventana. La ventana de envío y procesado puede tener un tamaño cero o ser tan grande como el buffer de transferencia.


Figura 111. Estructura del buffer de transferencia.

La ventana de recuperación y reordenación es la zona del buffer donde tenemos alternancia entre bloques de datos y huecos. Está

delimitada por buffer.ack y por buffer.next. Los huecos que presenta esta ventana son debidos, bien a la llegada de paquetes desordenados, bien a la pérdida de algunos paquetes. Según se

van completando estos huecos el valor de buffer.ack avanza haciendo crecer la ventana de envío y procesado y decrecer la ventana de recuperación y reordenación. Esta ventana también puede tener un tamaño que va desde cero al total del buffer de transferencia.

Por último encontramos la ventana de recepción. Esta ventana es la zona del buffer donde el nodo espera y puede recibir datos. La

ventana de recepción comienza pues en buffer.next y finaliza en

buffer.out. Según se van recibiendo datos en el buffer

buffer.next va avanzando hacia la derecha, siempre detrás del mayor paquete recibido. Con ello la ventana de recepción se va acortando, permitiendo recibir menos bloques de datos. La única manera de expandir la ventana de recepción es por la derecha,

incrementando el valor de buffer.out al deslizar todo el buffer. Por lo tanto, dado que el tamaño del buffer es fijo, la única manera de incrementar la ventana de recepción es hacer avanzar

el propio buffer (incrementar buffer.first).

Así pues la ventana de recepción de un nodo dependerá del tamaño del buffer y de su situación cambiante. Si el buffer se va llenando pero su inicio no avanza la ventana de recepción se irá acortando.

Llegados a este punto hay que decidir como avanza el buffer de transferencia. Un nodo sólo podrá descartar un bloque de datos


10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25... ...

Bloques procesados y

descartados

Bloques recibidos

Zona de recuperación y

reordenación

Ventana de recepción

Bloques fuera de la transferencia

ackfirst next out

Bloque sin datos Bloque con datos


del buffer (avanzando buffer.first) si el bloque cumple las siguientes dos condiciones:

El bloque ya ha sido procesado (leído) por el módulo de aplicación, es decir que el bloque está por detrás de

buffer.process. Esto sólo es aplicable a nodos que no sean emisores.

Nos hemos asegurado que todos los miembros del subárbol ya tienen ese bloque y que, por lo tanto, ya no es necesario recuperarlo reenviándoselo a ningún otro nodo del subárbol. Para ello definiremos el concepto de

subtreeAck. Todo bloque de datos por debajo de

subtreeAck serán bloques que un nodo sabe a ciencia cierta que todos los miembros de su subárbol (incluido él) ya lo han recibido.

Por lo tanto cada vez que se modifique el valor de buffer.process

(al leer un paquete) o subtreeAck se podrá actualizar

buffer.first mediante la fórmula:

buffer.first = min(buffer.process, subtreeAck)

Los valores de buffer.process y subtreeAck siempre se moverán

en la ventana de envío y procesado. El valor de buffer.process se incrementará según la aplicación vaya leyendo información y el

valor de subtreeAck se calculará en función de los datos recibidos por otros nodos.

Cada nodo informará a otros nodos vecinos de su zona del estado de su buffer de transferencia. Para ello con cada paquete intra-

zona en la cabecera MDCTP se incluirán los datos de buffer.ack,

buffer.next y buffer.out en los campos ack, next y out respectivamente. Con ello el nodo indicará que paquetes ya tiene

(ack), cual es el siguiente que espera recibir (next) y hasta donde

puede recibir (out).

Para gestionar esto cada nodo tendrá una ficha por cada vecino de su zona donde se reflejan los datos de la figura 112.


Figura 112. Información sobre vecinos.

Esto permitirá a un nodo tener una estimación (dado que sólo recibe un paquete de un vecino cada cierto tiempo) de la situación del buffer de transferencia de todos sus vecinos.

Figura 113. Ventanas estimadas de vecino.

En la figura 113 vemos un ejemplo de cómo un nodo interpreta la ventana de un vecino en función de los datos recibidos. Al recibir un paquete con los datos ack=20, next=25 y out=30, el nodo sabrá que el vecino:

Tiene todos los paquetes antes del 20.

Que espera el 25 luego tiene el 24.

Del 21 al 23 no sabe si son huecos o bloques recibidos.

Que puede recibir bloques del 25 al 29 ya que el 30 ya estaría fuera del buffer.

Según vaya completando la información que tiene un nodo sobre

los distintos valores ack de sus vecinos podrá hacerse una idea

Información por vecino

• out. Primer bloque fuera de la ventana de recepción

• next. Siguiente bloque que se espera.• ack. Todos los bloques anteriores están

confirmados. Si ack < next entonces ack es un bloque a recuperar.

Ventana de recuperación y reordenación

17 18 19 20 ? ? ? 24 25 26 27 28 29 30 31 32... ...

ack next out

Bloque sin datos Bloque con datos


? Bloque indeterminado


de que paquetes han sido recibidos por todos los miembros de la

zona. Llamaremos a este valor zoneAck y será el mínimo ack de

todos los vecinos. El valor de zoneAck también es una estimación y se irá recalculando según un nodo va recibiendo paquetes de

sus vecinos. La estimación de zoneAck de dos vecinos distintos puede no coincidir si estos no han recibido los mismos paquetes.

De la misma manera un nodo podría calcular que paquetes se pueden aceptar dentro de la zona, es decir que paquetes están dentro de la ventana de recepción de todos los miembros de la zona. Esta ventana de recepción de la zona empezaría en

zoneNext (el valor next máximo de todos los vecinos) y acabaría

con zoneOut (el valor mínimo de todos los out de los vecinos).

En la figura 114 se puede ver como un nodo calcula los datos de las ventanas de zona en función de la información que tiene de los vecinos (incluido él mismo).

Figura 114. Cálculo de las ventanas de zona.

Las ventanas de la zona estarán limitadas pues por zoneAck,

zoneNext y zoneOut.

Dado que una zona recibe bloques de datos de la zona padre es importante que los nodos de la zona hija informen a los nodos de

la zona padre de cuál es su zoneOut, de forma que no se envíen paquetes que no se puedan almacenar.

Además, para que pueda avanzar el ack de la zona padre, las zonas hijas también deben informar a la zona padre que paquetes ya han sido recibidos en todos los nodos del subárbol

(subtreeAck).







4

11



7

4

47

11

4


Por ello en los paquetes inter-zonas se envía la información de

subtreeAck, zoneNext y zoneOut en los campos ack, next y out respectivamente. Con ello los nodos de una zona pueden calcular

su propio subtreeAck que será el mínimo entre su zoneAck y los

subtreeAck recibidos de sus zonas hijas.

De esta manera todos los nodos tienen la información de sus propias ventanas y una estimación de:

Las ventanas de sus vecinos.

Las ventanas de su zona.

Las ventanas de sus zonas hijas.

Los límites de las ventanas estimadas siempre serán menores que los límites reales.

Para un nodo el cálculo de su subtreeAck es importante ya que como vimos es uno de los parámetros que permite desplazar el buffer de transferencia.

Proceso de Transferencia

Cuando un nodo tiene un nuevo bloque de datos para transmitir, bien porque lo ha recibido de un nodo de su zona padre, bien porque es el emisor y desde la capa de aplicación se ha enviado información, el nodo tiene que coordinar los siguientes tres pasos:

Difundir la información en su zona.

Retransmitir la información a las zonas hijas.

Confirmar la recepción al padre.

La transferencia del bloque de datos dentro de cada zona se realiza mandando un paquete de datos intra-zona mediante difusión.

Una vez difundido el paquete se enviará una copia del mismo a cada una de las zonas hijas de su zona. Para realizar esto se seleccionará aleatoriamente un nodo de cada zona hija y se le reenvía el paquete de datos.

Cuando los nodos seleccionados de las zonas hijas reciban los paquetes estos volverán a realizar el mismo proceso de difundir el paquete en la zona y de reenviarlo a sus zonas hijas.


Cuando en una zona se recibe un paquete de datos de otra zona

se contesta mediante un ACK al padre para confirmar su recepción.

De esta manera en el árbol se producirán dos flujos de información: uno que va del emisor a las zonas hoja de paquetes

tipo DATA y otro flujo de confirmación con paquetes ACK que va de las hojas al emisor (ver figura 115).

Figura 115. Flujos de datos y confirmaciones en el árbol de zonas.

Vamos a ver paso a paso como se comportaría un nodo cada vez que reciba un paquete.

En estos casos consideraremos que el nodo que envía el paquete

que desencadena la acción es peerA y el que recibe el paquete es

peerB.

Acciones comunes en la recepción de paquetes

Siempre que se recibe un paquete de un nodo lo primero que se realiza es comprobar si el nodo está en la lista de nodos. Si no es

así peerB registra a peerA en su conjunto de nodos, ampliando la información que tiene sobre el resto de nodos de la sesión.

Si el paquete enviado es de tipo intra-zona lo que se hace es

actualizar las estimaciones almacenadas del vecino peerA. Para

ello se utilizan los campos ack, next y out del paquete. Si alguno de estos valores cambia también se recalcula las estimaciones de

ventanas para la zona. Si cambia zoneAck también se recalcula

subtreeAck.

DATA

ACK


Si el paquete enviado es de tipo inter-zonas el nodo peerB

actualiza la información de subtreeAck (en el campo ack) de

zoneOut (en el campo out) y de zoneNext (en el campo next), para la zona de la que proviene el paquete.

Emisión de datos

Durante el proceso de transferencia, en un momento dado, un nodo podrá disponer de un nuevo bloque de datos. Esto puede ocurrir por dos cosas: es el nodo emisor y la aplicación ha escrito datos hasta completar un bloque, se han recibido datos de la zona padre (un reenvió).

En el caso de que sea el emisor el que tiene el bloque de datos los pasos que debe realizar son los siguientes:

1. Seleccionar un vecino como responsable del bloque. El emisor seleccionará al azar entre todos los miembros de la zona quien será el nodo responsable del bloque de datos. El propio emisor será uno de los posibles candidatos a responsable del bloque. Con ello la responsabilidad de los bloques, y por lo tanto su corrección en caso de error, se reparte entre todos los vecinos de la zona. El emisor registrará en su buffer de transferencia al nodo responsable del bloque a emitir.

2. Difundir el bloque en la zona. El emisor difundirá en la

zona el bloque de datos indicando en dstPeerID el identificador del nodo responsable seleccionado.

Cuando los vecinos de la zona de emisión reciban dicho paquete

(lo detectarán porque es un paquete con la operación DATA, el flag

ZONE desactivado y enviado por el emisor) realizarán los siguientes pasos:

1. Almacenar el paquete. Si el paquete está dentro del buffer de transferencia del nodo será almacenado indicando como responsable del mismo el peer indicado

en dstPeerID.

2. Reenviar el paquete (sólo el nodo responsable). Si el nodo que recibe el paquete es el nodo asignado como nodo responsable este reenviará el paquete a las zonas hijas, seleccionando para ello un nodo aleatorio de cada zona.


En la figura 116 se puede ver un ejemplo de cómo el nodo 1 envía el nuevo bloque de datos 37. En el ejemplo el nodo 20 recibe el bloque pero el 25 por error no lo recibe. En la figura se muestra como estaría el buffer de transferencia de cada nodo, indicando quien es el responsable de cada bloque.

Figura 116. Difusión de un bloque de datos por parte del emisor.

Reenvío de datos entre zonas

Una vez el dato ha sido difundido dentro de la zona raíz el nodo

responsable (peerA) será el encargado de reenviarlo a las zonas hijas. Cuando el dato llega a un nodo de una zona hija (el

paquete tendrá la operación DATA y el flag ZONE activo) el nodo que

recibe el dato (peerB) realizará los siguientes pasos:

1. Almacenar el paquete. Si el paquete está dentro del

buffer de transferencia de peerB se almacena, si no se descarta.

2. Registrar responsabilidad del paquete. El nodo peerB anota en el buffer de transferencia que es el nodo responsable del paquete recibido. El nodo responsable será el encargado natural de la recuperación de este paquete en caso de que un vecino no lo haya recibido.

120


3934 35 36 37 38

1

RSP

sessionID=7983

flags=0

peerType=ROOT

operation=DATA

srcPeerID=1

dstPeerID=20

zoneID=1

pktID=168

ack=38

next=38

out=64

dataID=37

dataSize=1024

dataContent=…

2012025

... ...

1


3934 35 36 37 38

20

RSP 20125

... ...

25


3934 35 36 37 38

25

RSP 12025

... ...

DATA(37)


3. Seleccionar un nodo delegado. De entre todos los

vecinos (a no ser que sea miembro único de la zona) peerB

seleccionará aleatoriamente un vecino (peerC). Este vecino será el responsable de contestar a la zona padre en vez del

peerB y se denominará nodo delegado. De esta forma los miembros de la zona padre podrán ir descubriendo a los miembros de sus zonas hijas.

4. Difundir el paquete de datos en la zona (si hay

vecinos). Si peerB tiene vecinos en la zona difundirá a todos los vecinos el paquete de datos recibido, indicando además las ventanas actuales del nodo. Como destinatario

en dstPeerID no se indicará ALL sino el identificador del

nodo delegado (peerC), de forma que éste sepa que ha sido seleccionado para confirmar al padre.

5. Contestar a la zona padre (si es miembro único de la

zona). Si peerB es el único miembro de la zona este será el encargado de confirmar la recepción del paquete a la zona

padre. La confirmación será un paquete ACK mandado a un miembro aleatorio de la zona padre.

6. Reenviar los datos a las zonas hijas. Por último peerB reenviará el bloque de datos a cada zona hija (si se tiene). Antes del envío comprobará que el paquete esté dentro de la ventana del subárbol, si no esperará a que avance. Para realizar el reenvío se selecciona aleatoriamente un nodo de dicha zona. Cuando este nodo reciba dicho dato realizará estos mismos pasos para seguir distribuyendo la información hacia abajo en el árbol.

En la figura 117 se puede ver un ejemplo (continuación del anterior) donde el nodo 20, tras ser designado nodo responsable, reenvía el dato a una zona hija (la zona 2). El nodo seleccionado para ello es el nodo 6 que será el nodo responsable del bloque 37 dentro de la zona 2.


Figura 117. Escenario de recepción de datos externos.

El nodo 6, tras recibir el bloque de datos difundirá el mismo en la zona 2 (ver figura 118) siendo el nodo 2 el nodo delegado.

Figura 118. Difusión de los datos.

Posteriormente el nodo 6 reenvía los datos a sus zonas hijas: zona 5 (nodo 3) y zona 8 (nodo 8). Los flujos de datos se reflejan en la figura 119.

6

72

15

4

sessionID=7983

flags=ZONE

peerType=RECEIVER

operation=DATA

srcPeerID=20

dstPeerID=6

zoneID=1

pktID=102

ack=38

next=38

out=45

dataID=37

dataSize=1024

dataContent=…

2

120

1

25

DATA(37)


3934 35 36 37 38

6

RSP 6427

... ...

64

2

72

DATA(37) 15

sessionID=7983

flags=0

peerType=RECEIVER

operation=DATA

srcPeerID=6

dstPeerID=4

zoneID=2

pktID=156

ack=38

next=38

out=52

dataID=37

dataSize=1024

dataContent=…

Nodo responsable

Nodo delegado


Figura 119. Retransmisión de datos.

Procesado de datos de un vecino de la zona

Cuando se recibe un paquete de un nodo peerA (nodo que

posiblemente difunde la información en la zona) en el nodo peerB

con la operación DATA y el flag ZONE desactivado (peerA y peerB son vecinos de zona) se realizan los siguientes pasos:

1. Almacenar el bloque de datos. El nodo peerB almacena el bloque de datos en su buffer de transferencia.

2. Registrar nodo responsable. En el buffer se indicará

como nodo responsable a peerA, excepto en el caso de que el que envía el dato sea el emisor, que el responsable del

paquete será peerB.

3. Comprobar nodo seleccionado. Se analiza el campo

peerDstID. Si dicho campo no coincide con el identificador

del peerB se termina el proceso, si no continuamos.

4. Confirmar a la zona padre (sólo si soy el nodo

seleccionado). El nodo peerB envía una paquetea ACK a la zona padre. Para ello selecciona aleatoriamente un

miembro de dicha zona y le envía el paquete ACK por unicast.

15

4

2

7

85

DATA(37)

DATA(37)

2

5

38 13

6

sessionID=7983

flags=ZONE

peerType=RECEIVER

operation=DATA

srcPeerID=6

dstPeerID=3

zoneID=2

pktID=157

ack=38

next=38

out=52

dataID=37

dataSize=1024

dataContent=…

sessionID=7983

flags=ZONE

peerType=RECEIVER

operation=DATA

srcPeerID=6

dstPeerID=8

zoneID=2

pktID=158

ack=38

next=38

out=52

dataID=37

dataSize=1024

dataContent=…


En la figura 120 podemos ver una escenario del funcionamiento de este proceso. En este caso el nodo 4 (nodo delegado) envía un paquete ACK a la zona padre (zona 1), en concreto al nodo 25.

Figura 120. Confirmación de recepción de datos.

Al igual que con los paquetes de datos los paquetes ACK también son difundidos en la zona, de forma que la información aportada por la zona hija esté disponible a todos los vecinos de la zona

padre. En concreto el nodo que recibe el paquete ACK de de la zona hija indica en el cuerpo del paquete el identificador de dicha

zona y los datos que ha obtenido en ack, next y out.

En la figura 121 se ve como el nodo 25 difunde el ACK a sus vecinos.

6

72

15

4

sessionID=7983

flags=ZONE

peerType=RECEIVER

operation=DATA

srcPeerID=4

dstPeerID=25

zoneID=2

pktID=78

ack=38

next=38

out=52

2

120

1

25

ACK


Figura 121. Difusión de un paquete ACK.

Detección de nodos y zonas desaparecidas

Uno de los aspectos importantes a tener en cuenta en el proceso de transferencia es determinar cuando un nodo de la sesión desaparece inesperadamente de la misma.

Si el resto de los nodos de la sesión no detectaran que un nodo a

caído, no irán actualizando su ACK y por lo tanto no avanzará el

ACK de la zona (zoneAck) ni del subárbol (subtreeAck), por lo que se llenarían los buffers y se detendría la comunicación.

Para evitar que esto ocurra los nodos de la sesión tienen que garantizar el envío de al menos un paquete de información cada cierto tiempo (tiempo máximo de envío). Cada nodo almacena el momento en el que difundió un paquete en la zona, si se sobrepasa el tiempo máximo de envío sin mandar otro paquete el

nodo difundirá un paquete STATUS en la zona. El tiempo máximo de envío está establecido por defecto en un segundo.

Los paquetes de estado (con el campo operaction a STATUS) son paquetes sin cuerpo que simplemente revalidan la permanencia del nodo en la zona.

Por otra parte todos los nodos registrarán cuando fue la última vez que recibieron un paquete de cada vecino. Si el tiempo pasado desde la recepción del último paquete supera un

20

1

25ACK

1

sessionID=7983

flags=0

peerType=RECEIVER

operation=DATA

srcPeerID=25

dstPeerID=ALL

zoneID=2

pktID=78

ack=38

next=38

out=49

childZoneID=2

childAck=38

childNext=38

childOut=52


determinado umbral (tiempo máximo de espera) se asume que el nodo está muerto y se elimina de la lista de vecinos, recalculando las ventanas de zona. El tiempo de espera está establecido por defecto en 5 veces el tiempo de envío (5 segundos) lo cual permite a un nodo perder hasta 4 paquetes de un vecino sin que ello provoque una falsa muerte. El nodo que detecta un

vecino muerto informa al resto mediante la operación DEL, que se envía de forma confiable a los vecinos, a la zona padre, a las zonas hijas y al emisor principal.

Además de permitir la detección de muertes inesperadas los paquetes de estado permiten a los vecinos de la zona actualizar los datos de ventana del resto de nodos, agilizando el desplazamiento de las ventanas de zona.

Otra circunstancia que puede ocurrir durante el proceso de transmisión es que una zona desparezca completamente, es decir, que mueran todos los nodos de dicha zona.

Para detectar estas situaciones los nodos también mantienen unos tiempos máximos de espera para las zonas padre e hijas. Si se cumplen uno de estos umbrales se asume que la zona al completo ha fallado.

Para renovar la vida de las zonas cuando un nodo va a enviar un

paquete STATUS envía también un paquete STATUS a las zonas padre e hijas. Esto lo realiza con una probabilidad inversamente proporcional al número de vecinos de forma que no se saturen las otras zonas. Por ejemplo un nodo de una zona con 5 vecinos sólo

mandará el paquete STATUS un 20% de las veces (1/5).

El primer nodo que detecte la muerte de una zona informa a sus vecinos de ello y posteriormente le indica al emisor principal el

error mediante paquetes de tipo ZONEDEL. El emisor principal elimina la zona indicada y realoja las zonas en el árbol mediante

operaciones INFO a las zonas implicadas.

El emisor principal reordena el árbol de la siguiente manera:

Si la zona caída es una zona hoja simplemente se elimina.

Si la zona caída es una zona intermedia se localiza la zona hoja de esa zona con menor distancia al padre de la zona caída y se sustituye por esta.

Evidentemente si la zona caído es la raíz el proceso de comunicación termina para todos los nodos.


Corrección local

Uno de los aspectos claves en el proceso de comunicación, principalmente en el caso de sistemas con múltiples nodos implicados es detectar y corregir los bloques de datos perdidos.

En el protocolo se realizan labores de corrección tanto a nivel local de una zona como entre zonas.

Cuando un nodo (peerB) recibe un paquete cualquiera de un

vecino (peerA) de su zona (paquete con flag ZONE desactivado)

intenta detectar fallos en la recepción de paquetes de peerA para realizar una corrección de dichas pérdidas.

Para ello peerA consulta los datos de ack y next del paquete. Si

son distintos significa que ack apunta a un hueco en su secuencia.

Si peerB es el nodo responsable del paquete perdido lo reenviará inmediatamente por difusión, de forma que si hay más de un

nodo que no lo recibió lo pueda recuperar. En ese paquete DATA no se indicará ningún nodo responsable ya que es una

recuperación local y no hay que confirmar con una ACK al padre.

Si no es el responsable del paquete pero sí que dispone del mismo no lo reenvía, asumiendo que será el responsable de bloque el que realizará el reenvío. Llegados a este punto cabe la posibilidad de que el nodo responsable del bloque no pueda contestar en ese momento (está ocupado, caído o simplemente no recibió el

paquete donde peerA indicaba su hueco). Para que otro nodo pueda recuperar el dato perdido se actúa como se indica a continuación. Cuando los vecinos de una zona reciben un paquete donde detectan un hueco en la secuencia (next > ack) incrementan un contador de recuperación local asociado al paquete perdido. Si en algún momento se recibe un bloque de datos (posiblemente por parte del responsable del bloque) se inicializa a 0 el contador de recuperación local. Posteriormente, cuando un nodo tiene el testigo (un nodo tiene el testigo cuando

recibe un paquete dirigido a el, es decir dstPeerID es su identificador) comprueba si el contador supera un determinado valor y si es así lo reenvía. El umbral por defecto es 5.

En otros casos es posible que ningún vecino de la zona tenga ese bloque por lo que no se podrá realizar una corrección local del mismo.


Corrección inter-zonas

Cuando un nodo (el nodo responsable) envía un bloque de datos a una zona hija es posible que dicho bloque no llegue a la zona, bien porque no llegue al nodo destinatario, bien porque llegue al nodo pero éste muera antes de poder reenviarlo.

En esos casos es la zona padre la responsable de corregir el bloque perdido. Para ello cuando un nodo va a mandar un paquete al bloque padre, en el caso de que el contador de recuperación local haya superado el umbral el nodo no tenga el

paquete indicará en el campo next del paquete el valor de dicho

bloque perdido. En otro caso next será igual a ack, indicando que no se espera ninguna corrección.

Cuando el nodo que recibe el paquete de la zona hija observa que

next es mayor que ack, asume que en la zona hija nadie tiene el

bloque indicado en next.

Corrección preventiva

El uso de técnicas de corrección preventiva en los sistemas basados en difusión es una de las técnicas más utilizadas para mejorar el proceso general de transferencia, permitiendo a los miembros de la transferencia recuperar un paquete perdido sin necesidad de solicitarlo.

Para ello el nodo emisor de la información envía cada cierto tiempo determinados paquetes que permiten recuperar bloques de datos perdidos.

Estas técnicas se basan en el siguiente procedimiento:

El emisor de la información selecciona n bloques de datos.

Sobre ese conjunto confecciona un total de p bloques de recuperación preventiva.

El emisor emite tanto los bloques de datos como los

bloques de recuperación es decir n+p bloques en total.

Si el receptor (o receptores) de la información se pierden

algunos bloques de datos, llegando solo m de los n bloques

iniciales (m<n) se podrán recomponer un máximo de r

bloques, donde r<=p.


La técnica ideal en estos casos es aquella en la que r=p, es decir podemos recuperar tantos bloques de datos como bloques correctores hayamos creado. La codificación de Reed-Solomon es una técnica que permite realizar un FEC con estas características, si bien tiene el inconveniente de que su alta complejidad de cómputo.

En contraposición el uso de la primitiva XOR para el cálculo de bloques de recuperación tiene un coste computacional mucho más aceptable, si bien el número de bloques de recuperación que se pueden crear por conjunto de bloques de datos es de sólo 1. En nuestro caso vamos a utilizar la primitiva XOR combinando los bloques de datos de cálculo para proporcionar un nivel de recuperación aceptable con un coste computacional bajo.

Para ello determinaremos un valor que denominaremos HR (Horizontal Recovery) que indicará cada cuantos bloques de datos consecutivos se enviará un bloque de recuperación. En nuestro caso el valor por defecto será 8, si bien este dato es configurable.

Figura 122. Uso de la primitiva XOR para el cálculo de bloques de

recuperación.

Con ello tendremos un bloque de recuperación que corrige la pérdida de un bloque del 0 al 7, otro para los bloques del 8 al 15 y así sucesivamente. Si al recibir los datos un nodo ha perdido el bloque 1 podrá generarlo realizando un XOR de los otros bloques y el bloque de recuperación. Así mismo si otro nodo hubiese

0 1 2 3 4 5 6 7

XOR

0 12 3 4 5 6 7

XOR

0 1 2 3 4 5 67

XOR

1

Bloques enviados

Bloques recibidos

4

Bloques recibidos

9


perdido el bloque 6 también podría recuperarlo realizando la misma operación (ver figura 122).

Sin embargo si se perdieran dos bloques no se tendría la posibilidad de recuperarlos, se tendría que reenviar uno de los datos perdidos y el otro ya se podría calcular.

Evidentemente los bloques de recuperación también son susceptibles de perderse.

Para mejorar el proceso de recuperación también vamos a realizar una recuperación que denominaremos vertical, ilustrado en la

figura 123, y parametrizado por el valor VR (Vertical Recovery).

Figura 123. Bloques de recuperación.

Los bloques de recuperación horizontal se enviarían después de los bloques de datos 7, 15, 23 y 31, y se calcularían con el XOR de los datos de una fila. Los bloques de recuperación vertical se enviarían después de los bloques del 24 al 31. Todos los bloques de recuperación vertical están en la cuarta fila y se volverían a

emitir en la octava, es decir en los múltiplos de VR. Después del bloque 31 se emitirían dos bloques de recuperación, uno vertical y otro horizontal.

Si bien los bloques de recuperación horizontal se emiten de forma escalada cada HR bloques de datos, los bloques de recuperación vertical se acumulan siempre y se emiten de forma consecutiva. Para evitar este efecto se han distribuido estos bloques entre

0 1 2 3 4 5 6

8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23

24 25 26 27 28 29 30 31

7

Bloque de datos Bloque de recuperación

31 31 ...

XOR(8,9,10,11,12,13,14,15)VR=4

HR=8

XOR(4,12,20,28)


distintas filas. En la figura 124 se ilustra la distribución de los bloques de recuperación.

Figura 124. Distribución de los bloques de recuperación vertical.

Para cubrir el máximo rango de bloques de datos posibles los bloques de recuperación se realizarán de forma acumulativa. Por ejemplo el bloque de recuperación horizontal que se emite después del bloque 23 es un XOR de los bloques del 0 al 23, y el bloque de recuperación vertical que se emite después del bloque 31 recupera los bloques 0, 8, 16, 24 o 31.

Para calcular los bloques de recuperación horizontal el emisor tendrá un bloque de cálculo donde acumula con un XOR todos los bloques que va emitiendo. Cuando el bloque que emite es

múltiplo de HR emite el valor del bloque general.

Para calcular los bloques de recuperación vertical el emisor

tendrá tantos bloques de cálculo como se indique en HR. Cuando se emite un nuevo bloque se acumula en el bloque asociado a la columna de dicho bloque.

Por el otro lado el receptor ira tendrá los mismos bloques de cálculo e irá almacenando los bloques de recuperación que reciba. Si detecta un hueco en la secuencia y tiene un bloque de recuperación que cubra el hueco podrá generar el bloque de datos perdido.

0 1 2 3 4 5 6

8 9 10 11 12 13 14 15

16 17 18 19 20 21 22 23

24 25 26 27 28 29 30 31

7

Bloque de datos Bloque de recuperación

31 31 ...

XOR(8,9,10,11,12,13,14,15)VR=4

HR=8

XOR(3,11,19,27)


Fase de Cierre

Durante el proceso de comunicación cualquiera de los nodos podrá dar por finalizada la transferencia. La finalización de la

transferencia se realiza mediante la función close del API. En este sentido el cierre de la comunicación será interpretado de distinta manera en función de si el cierre lo realiza un emisor u otro nodo.

Cierre por parte del emisor

Dado que el emisor es el único que dispone de la información a

transmitir estará realizando llamadas a write mientras tenga información disponible. En el momento que ya no se disponga de

más información invocará a la función close para indicar que la

transmisión finaliza. Internamente la función close garantizará que toda la información llega al resto de nodos de forma que se garantice la confiabilidad.

Una vez la información es cerrada, y se hayan emitido todos los bloques de datos en resto de paquetes que se manden tendremos

el flag CLOSE activo. Según el resto de nodos vayan recibiendo

estos paquetes, al detectar el flag CLOSE activo asumirán que ya no hay más bloques de datos a partir del indicado en el campo

next del paquete.

A partir de ese momento el emisor quedará a la espera de que los paquetes confirmados para su subárbol (el valor de su

subtreeACK) sea igual al del número de bloques enviados.

Cierre por parte de un nodo no emisor

Si el cierre (la llamada a close) es realizada por un nodo que no es el emisor, asumimos que dicho nodo quiere abandonar la comunicación, sin que ello suponga la finalización del proceso general, es decir, el nodo abandona la sesión y el resto de miembros continúan con el proceso.

En este caso cuando un nodo invoca a close las tareas que se realizan son similares a las realizadas por un nodo cuando detecta que un vecino ha muerto, pero de forma controlada. De esta manera el nodo que cierra la conexión avisaría al resto de vecinos, a las zonas padre e hijas y al emisor principal de su

salida mediante una operación PEERDEL. En caso de que fuera el

único vecino de su zona realizaría una operación ZONEDEL.


Simple Data Transfer Protocol

El Simple Data Transfer Protocol (SDTP) es un protocolo de capa de aplicación que permite de forma sencilla transportar un paquete de datos.

Su funcionamiento en general es similar al de otros protocolos de aplicación como HTTP, FTP o SMTP y permite a un nodo de red (nodo cliente) transmitir un flujo de datos desde otro nodo de red (nodo servidor). Al contrario que otros protocolos SDTP es un protocolo de características simples: tiene muy pocas operaciones y su funcionamiento se fundamenta casi exclusivamente en el transporte de datos. En general se podría decir que SDTP es simplemente una encapsulación de protocolos de transporte como TCP o MDCTP (ver Figura 125).

Figura 125. Pila de protocolos para SDTP.

Al soportar protocolos de transporte como MDCTP el sistema permite el transporte simultáneo de un dato a múltiples destinatarios en una misma sesión de transporte.

Al contrario que HTTP o FTP que identifican el dato a transmitir por el nombre de un archivo (o al menos el nombre de un recurso) en SDTP los datos se identifican por su IID tal cual se describió en el modelo de organización del sistema de gestión. De esta forma un cliente que implementa el protocolo SDTP simplemente tiene que realizar una solicitud de transferencia de un paquete de información identificado por su IID e indicar

IP

TCP

SDTP

AP

LIC

AC

IÓN

TR

AN

SP

OR

TE

RE

D

Protocolo de Enlace

EN

LA

CE

MDCTP


mediante que protocolo de transporte desea realizarlo (TCP o MDCTP). El servidor al recibir la petición creará una sesión de transferencia del protocolo indicado para el recurso solicitado.

SDTP es un protocolo basado en texto y sin conexión. Existirá una comunicación principal entre el cliente y el servidor, donde se realiza la petición del recurso y que será siempre una comunicación TCP. Esta conexión será utilizada exclusivamente para las peticiones, si se solicitará un dato por TCP el servidor abriría una nueva conexión para su transporte, al estilo de cómo funciona FTP. Este esquema se releja en la figura 126.

Figura 126. Diagrama de secuencia del esquema general de SDTP.

Comandos SDTP

La solicitud realizada por el cliente consistirá en una única línea de texto donde se indica el comando a realizar.

Los comandos soportados por SDTP se pueden ver en la tabla 44.

La respuesta a un comando será siempre una única línea donde se indica el estado de la respuesta un espacio y los datos asociados a la respuesta. El estado será un código numérico donde 0 siempre indica que la operación se ha realizado

SDTP

srvTCP socket

SDTP

srvTCP socket TCP socket

SDTP

cln

open()

bind()

accept()

tcp

bind()

connect()

TCP: connect

fork()

loop

read(request) write(request)

tcp

write(response

)

read(response

)

close()

close()

close()


correctamente y otro valor indica un código de error asociado a la solicitud.

Tabla 44. Comando de SDTP.

Comando Descripción

VERSION Obtiene la versión del protocolo soportada por el servidor.

PROTOCOLS Indica los protocolos de transporte soportados por el servidor

GET <protocol> <iid>

[options] Obtiene un nuevo paquete de información.

Comando VERSION

El comando VERSION permite a un cliente solicitar la versión soportada por el servidor.

La respuesta al comando siempre será 0 seguida de la versión del protocolo soportada.

Comando PROTOCOLS

El comando PROTOCOLS permite a un cliente averiguar que protocolos de transporte puede utilizar el servidor.

La respuesta del comando siempre será 0 seguida de una lista separada por comas de los protocolos soportados.

Comando GET

El comando GET permite a un cliente solicitar la transferencia de un flujo de información. La solicitud sigue el siguiente formato:

GET <protocol> <iid> [options]

Donde protocol es el protocolo seleccionado para realizar la

transferencia, iid es el identificador de la información a transferir

y option es una lista separada por espacios de opciones

siguiendo el formato name=value donde name es el nombre de la

opción y value el valor. Opcionalmente value puede ir etrecomillado para definir exactamente el contenido del mismo.


La respuesta correcta al comando será una línea donde se indica 0 seguido de el nombre del protocolo y los datos de conexión para que el cliente pueda inicar la transferencia. Los datos que aparecen dependerá del protocolo utilizado. En la tabla 45 podemos ver los datos para los protocolos TCP y MDCTP.

Tabla 45. Respuestas del comando GET en función del protocolo.

Protocolo Sitaxis

tcp 0 tcp <ip>:<port>

mdctp 0 mdctp <ip>:<port> <sessionID>

Con la información recibida en la respuesta el cliente podrá abrir una nueva conexión para transferir la información.

Otros valores de estado que se pueden dar en la respuesta son los descritos en la tabla 46.

Tabla 46. Códigos de error del comando GET.

Código de error Significado

1 Protocolo no soportado.

2 Información no encontrada.

3 Opción incorrecta.

207

C a p í t u l o 6

Implementación y Validación

En el primer capítulo se describió el marco metodológico científico utilizado para llevar a cabo el presente trabajo, siendo el método hipotético-deductivo el procedimiento general que ha guiado todo el proceso de investigación. La última etapa del método tiene como objetivo la validación de la hipótesis a través de la experimentación (método científico). Para ello es necesario definir un conjunto de experimentos derivados de la hipótesis que sirvan para validar la propuesta y diseñar e implementar un escenario en un entorno realista que permita llevar a cabo estos experimentos.

El presente capítulo se centra en tres aspectos: la implementación de un prototipo de un sistema de gestión que incluya el sistema de difusión de información, el diseño del escenario de pruebas que permita validar la propuesta y, a partir de la definición del escenario, en la descripción de los experimentos que se han llevado a cabo para validar la propuesta junto con los resultados y conclusiones obtenidos tras la experimentación.

Implementación del Prototipo

Para la implementación de la arquitectura propuesta en el capítulo 4 se han desarrollado los diversos módulos necesarios para crear las entidades de gestión.


La implementación se ha realizado fundamentalmente en entorno Linux, si bien se han seleccionado herramientas y librerías que puedan ser utilizados en otras plataformas como Microsoft Windows.

Los módulos que han sido implementados, como los protocolos MDCTP y SDTP han sido desarrollados en C++.

A continuación se describen cada uno de los módulos integrados o implementados.

Para el Motor SNMP y los Servicios SNMP al ser módulos que utilizan el protocolo SNMP estándar se ha optado por utilizar una librería estándar.

En nuestro caso hemos utilizado Net-SNMP un conjunto de aplicaciones y librerías para trabajar con SNMP en sus versiones 1, 2 o 3 y sobre IP4 o IP6. Las librerías de Net-SNMP permiten desarrollar entidades de gestión en C o en perl lo cual dota de más flexibilidad a la hora de desarrollar los distintos agentes del sistema.

Para el Motor de Trasnferencia se han utilizado diversos módulos y aplicaciones que puedan ser integrados en una entidad de gestión.

Los servidores de transferencia que se han utilizado se describen a continuación.

Servidor HTTP: Apache Web Server versión 2.2.

Servidor FTP: ftpd versión 2.6.

Aplicaciones P2P

Clientes

Cliente HTTP: Wget versión 1.20.2.

Cliente FTP: wget versión 1.20.2.

Adicionalmente se ha imprentado en C++ una librería para el desarrollo de aplicaciones utilizando el protocolo de transporte MDCTP propuesto en el capítulo 5.

También se han creado un servidor del protocolo SDTP llamado

sdtpd y un cliente llamado sdtpc, ambos en C++ y disponibles para plataformas Linux y Windows. En la figura 127 podemos ver

la ejecución de la ayuda del comando sdtpd.

Capítulo 6. Implementación y Validación 209

Figura 127. Ejecución de la ayuda del comando sdtpd.

Validación

El entorno de pruebas que va a servir como marco general de las pruebas y en el que se va a poner en marcha tanto el sistema de gestión como el sistema de transferencia masiva que se propone es un sistema de mantenimiento de redes de computadores que

llamamos .

El objetivo principal de es automatizar muchas de las tareas de mantenimiento de las redes de computadores, para conseguir una gestión desatendida de dicha red e incluye labores de gestión que requieren transferencia masiva de información como la regeneración de equipos que permite restaurar completamente la información contenida en los equipos que componen una red.

=======================================================

= SDTPd - Simple Data Transfer Protocol (SDTP) Daemon =

= --------------------------------------------------- =

= Version 1.0 =

= (c) 2010, grupoM www.dtic.ua.es/grupoM =

=======================================================

Use: ./sdtpd [options]

SDTPd Options

-h Show this help

-n <num> Number of clients. Def 1.

-t <KB> Test size in KB. Def 1024.

General Options

-a <ip>[:port] Set the binding address. Def: *.

-v <level> Set the debug level. Def: 3.

MDCTP Options

-b <address> Set the broadcast address. Def: NONE.

-m <address> Set the multicast address. Def:

224.1.1.1:4000.

-s <level> Set the send level error (0-1). Def:

0.00.

-r <level> Set the recv level error (0-1). Def:

0.00.

-u <size> Set buffer size. Def: 128.

Supported Protocols

TCP

MDCTP

http://www.dtic.ua.es/grupoM/productos/gaia







Este sistema nació en el seno del Departamento de Tecnología Informática y Computación de la Universidad de Alicante y en la actualidad se utiliza para gestionar los laboratorios docentes de la Escuela Politécnica Superior de dicha universidad.

Figura 128. Escenario de desarrollo del Sistema de Regeneración de Nodos.

El proceso de regeneración se gestiona mediante un sistema que opera en el equipo de manera independiente al hardware y software instalado, y que de manera automatizada y desatendida realiza básicamente los siguientes procesos:

Analizar el hardware del equipo, examinando principalmente los diferentes discos y particiones con los que cuenta

Obtener la configuración establecida para ese equipo, la cual reside en un sistema de inventario que gestiona el administrador. En él se indica las particiones que debe tener el equipo tras la reinstalación, los sistemas de archivos que debe contener, así como los sistemas operativos, aplicaciones y otros datos que deben residir en estos sistemas de archivos.

Preparar el equipo física y lógicamente para recibir la información a instalar.

Router/ Proxy/ Firewall

Internet

Cliente

Regeneración

Agente

Regeneración

Cliente ubicuo de

regeneración

(PDA, portátil,

Móvil, ...)

Servidor de

Autenticación

Dir

Directorio,

Perfiles y Certificados

Entorno de

Almacenamiento y

repositorio software

DB

DB

DB

DB

Sistema de

Información

Servidor de

Aplicaciones

Lógica de Negocio

Servidor

Web HTML

Interfaz

Control de acceso mediante tarjetas inteligentes (Smart Card)

Navegador

Web

Agente Regeneración

Cliente

Administración


Obtener y almacenar los datos que deben residir en el equipo de un repositorio previamente configurado por el administrador. La información se ofrece en forma de paquetes software de instalación, como podrían ser de sistemas operativos, de aplicaciones, de datos, etc. La información almacenada en los paquetes esta comprimida para optimizar el espacio de almacenamiento y agilizar su transmisión por la red.

Por lo tanto con este sistema para mantener una red de computadores simplemente hay que indicar la secuencia ordenada de paquetes que hay que instalar por cada equipo, agilizando de esta manera las costosas tareas de instalación y configuración del software.

En algunos casos, cuando la información que hay que instalar en un equipo no pueda fraccionarse en diversos paquetes, existirá un único paquete que describe la totalidad del contenido del equipo, es decir el paquete es una copia exacta del contenido físico de las unidades de dicho equipo. Este modo de trabajo se utiliza cuando el sistema de reinstalación no entiende la estructura interna del sistema de archivos del equipo.

Por norma general, el mantenimiento de los equipo se puede agrupar en grupos que comparten una misma configuración. Estos grupos estarían formados por equipos de características similares que comparten un mismo perfil software, como suele ocurrir en aulas o laboratorios informáticos. Mediante el uso de un sistema de transferencia tradicional de información, cuando un paquete va dirigido a más de un equipo, la transmisión se realiza de manera individual entre el repositorio y los equipos, repitiéndose esta operación tantas veces como destinatarios diferentes tenga el paquete. Esto produce una disminución en el rendimiento global del proceso, ya que se satura tanto el repositorio con solicitudes repetidas de paquetes, como la red con la transferencia de dichos paquetes.

Escenarios de Pruebas

El prototipo implementado va ha ser probado en dos escenarios distintos.

Por una parte tendremos un escenario controlado donde hemos realizado los experimentos que requerían de un control sobre la infraestructura de trabajo.


Para ello se ha confeccionado un escenario de pruebas compuesto por 8 PC‟s que actuaran como receptores de información y un servidor que actuará como emisor de la misma (figura 129).

Los equipos son dispositivos Asus EEE Box B202, un PC de propósito general y reducidas dimensiones con un procesador Intel Atom, una de memoria de 1GB, 80 Gb de almacenamiento, una interfaz de comunicación Ethernet y otra inalámbrica.

Figura 129. Escenario de pruebas.

Además se ha utilizado un hub como medio de conexión en vez de un switch para evaluar el comportamiento del sistema en el caso de redes con bajos niveles de calidad.

El otro escenario de pruebas es un entorno de trabajo real donde

actualmente se está utilizando el sistema . Se trata de los laboratorios informáticos de la Escuela Politécnica Superior de la

Universidad de Alicante. En estos laboratorios se utiliza para mantener operativos los ordenadores utilizados en las prácticas de laboratorio (ver figura 130).








Figura 130. Laboratorios de la Escuela Politécnica Superior.

Pruebas y experimentos

Se han llevado una serie de experimentos para probar el funcionamiento del prototipo implementado.

Para evaluar el rendimiento de MDCTP se han difundido bloques de información e 1GB de tamaño desde el emisor hacia los destinatarios. Para observar la escalabilidad del protocolo se han realizado las pruebas variando el número de destinatarios, desde 1 hasta 8, manteniendo constante el tamaño de la información a enviar (1GB). La difusión se ha realizado mediante SDTP y con diversos protocolos de transporte TCP y MDCTP y mediante el protocolo P2P eD2K (eDonkey 2000).

Dado que el funcionamiento del protocolo MDCTP depende del nivel de agrupación de los nodos, es decir, del número de zonas conformadas, hemos estudiado el protocolo con tres distribuciones distintas: una con todos los nodos en una misma zona que llamaremos MDCTP(1), otra con tres zonas MDCTP(3) y


una última con nueve zonas, una por cada nodo, MDCTP(9). En la figura 131 se puede ver estas tres distribuciones. Los nodos se irán incorporando a las pruebas según la numeración de la figura.

Figura 131. Distribución de los nodos en las pruebas de MDCTP.

En la figura 132 podemos ver que la información enviada por el emisor es dependiente del número de destinatarios en el caso de TCP. Esto es debido a que con los protocolos orientados a punto-a-punto hay que reenviar la información por cada destinatario.

Figura 132. Trafico total enviado por el emisor.

El resto de protocolos se encuentran situados más o menos en el rango de 1 y 2 GB. La figura 133 muestra una ampliación de esta zona para que se pueda estudiar con más detalle.

1

MDCTP(1)

2

5

4

96

3

8 7

1

MDCTP(3)

2 5

4

96

3

8

7

1

2 3

4 5 6 7

89

MDCTP(9)

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5 6 7 8

GB

Número de nodos receptores

Tráfico enviado por el emisor

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K


Figura 133. Tráfico total enviado por el emisor. Detalle entre 1 y 2 GB.

Se puede apreciar como la propuesta que menos satura al emisor es MDCTP(1) ya que la información solo tiene que ser enviada una única vez. En el caso de MDCTP(3) y MDCTP(9) el emisor tiene que realizar el envió a las dos zonas hijas por lo que MDCTP(9) se mantiene constante en esa franja de los 2GB y MDCTP3 se reduce una vez incorporamos el receptor 6 que ayuda en la distribución de la información desde la zona raíz. Cuanto más nodos se incorporaran a la zona raíz menos información tendría que emitir el nodo emisor. En el caso de la red eD2K la información enviada por el emisor también se encuentra situada entre 1 y 2 GB.

Si observamos la información media enviada por el emisor a cada uno de los receptores (figura 134) se observa claramente que el caso de MDCTP(1) es el mejor y el de TCP el peor.

0,8

1

1,2

1,4

1,6

1,8

2

2,2

1 2 3 4 5 6 7 8

GB


Tráfico enviado por el emisor

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K


Figura 134. Tráfico medio enviado por el emisor por cada nodo receptor.

De forma similar el tráfico recibido por el emisor, derivado de las confirmaciones de los receptores sigue un esquema similar al del tráfico enviado, pero con volúmenes mucho menores (figura 135). El único que representa un comportamiento no escalable vuelve a ser TCP.

Figura 135. Tráfico recibido por el emisor.

0

0,2

0,4

0,6

0,8

1

1,2

1 2 3 4 5 6 7 8

GB


Tráfico enviado por el emisor por cada nodo receptor

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K

0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8

MB


Tráfico recibido por el emisor

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K


Respecto a los datos medios recibidos en cada emisor (figura 136) los resultados muestran valores constantes y muy bajos en TCP y MDCTP(1) y unos valores crecientes en el resto pero que no superan 1GB.

En el caso de MDCTP según se van poblando las zonas se va reduciendo el tráfico medio por receptor, ya que las labores de retransmisión se distribuyen.

Figura 136. Tráfico medio enviado por cada nodo receptor.

En cuanto al tráfico recibido en cada receptor (figura 137) en todos los casos se mantiene bastante constante siendo el peor eD2K2. Los de MDCTP se incrementan ligeramente.

0

100

200

300

400

500

600

700

800

900

1 2 3 4 5 6 7 8

MB


Tráfico enviado por los nodos receptores

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K


Figura 137. Tráfico medio recibido por cada nodo receptor.

En cuanto al tráfico total enviado por todos los nodos en la figura 138 se puede ver como los mejores comportamientos se dan donde se utiliza multicast: MDCTP(3) y principalmente MDCTP(1).

En el resto el volumen de información enviado es del mismo orden, siendo ligeramente mejor TCP y peor eD2K.

Figura 138. Tráfico total enviado por todos los nodos.

1,01

1,02

1,03

1,04

1,05

1,06

1,07

1,08

1 2 3 4 5 6 7 8

GB


Tráfico recibido por los nodos receptores

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5 6 7 8

GB


Tráfico total enviado

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K


En el caso del tráfico total recibido todos se mantienen en el mismo orden de transferencia (figura 139).

Figura 139. Tráfico total recibido por todos los nodos.

De forma similar, las figura 140 y figura 141muestran la información media enviada y recibida por cada nodo.

Figura 140. Tráfico medio enviado por cada nodo.

0

1

2

3

4

5

6

7

8

9

1 2 3 4 5 6 7 8

GB


Tráfico total recibido

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

1 2 3 4 5 6 7 8

GB


Tráfico medio enviado por nodo

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K


Figura 141. Tráfico medio recibido por cada nodo.

Debido a las diferencias en el volumen de información transmitido los tiempos de transferencia también se ven afectados en función del número de receptores.

Figura 142. Tiempo medio de transferencia.

0,5

0,55

0,6

0,65

0,7

0,75

0,8

0,85

0,9

0,95

1

1 2 3 4 5 6 7 8

GB


Tráfico medio recibido por nodo

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K

0

100

200

300

400

500

600

700

800

1 2 3 4 5 6 7 8

segu

nd

os


Tiempo total de transmisión

MDCTP(1)

MDCTP(3)

MDCTP(9)

TCP

eD2K


Para el caso de TCP con un solo receptor es el protocolo más rápido pero, el tiempo se incrementa de forma directamente proporcional al número de receptores. El resto de protocolos se mantienen de forma escalable en una franja de tiempos, siendo MDCTP(1) la mejor opción.

Para comprobar el funcionamiento del protocolo MDCTP ante las pérdidas de datos se ha realizado un experimento forzando la pérdida de paquetes. Con una pérdida de paquetes del 10% y en el entorno de MDCPT(3) y con un tamaño de buffer de 16 bloques (16KB) se observa el comportamiento de la figura 143.

Figura 143. Evolución de las ventanas de transferencia.

La figura muestra cómo evolucionan las ventanas de

transferencia (out – ack) local, de zona y de subárbol en un periodo de 3 ms en un receptor de la información. Se observa cómo debido a las pedidas en algunas ocasiones las ventanas disminuyen, no llegando en ningún momento a un tamaño de ventana 0, lo cual produciría un parón temporal en la transferencia.

Esto valida la propuesta para entornos con apreciables niveles de pérdida ya que, aun tratándose de tamaños de buffer pequeños el sistema de recuperación funciona con la suficiente antelación

0

2

4

6

8

10

12

14

16

18

Ve

nta

na

de

tra

nsf

ere

nci

a (o

ut

-ac

k)

Tiempo (3ms)

Evolución de las ventanas de transferencia

Local

Subárbol

Zona


para evitar parones. Esto valida además el uso de este protocolo para sistemas con bajas prestaciones de memoria como dispositivos embebidos.

En la figura 144 podemos ver cómo evoluciona el sistema en cuanto a bytes enviados y recibidos, observándose como el comportamiento es bastante estable.

Figura 144. Tráfico transferido.

Además de las pruebas en el entorno controlado se ha realizado una batería de pruebas en un entorno real. Se trata de un laboratorio de prácticas computesto por 25 ordenadores.

Los puestos de trabajo han sido reinstalados completamente utilizando el sistema de regeneración. Cada equipo tiene dos sistemas operativos completos: Microsoft Windows XP y la distribución Ubuntu de Linux. En total la información instalada en cada equipo es de 6,8 GB.

Primeramente se ha realizado una instalación simultanea de todos los equipos utilizando el sistema tradicional que utiliza conexiones TCP para transportar la información a los puestos de trabajo. El tiempo total obtenido en este caso es de 32 minutos para reinstalar el laboratorio completo.

0

10000

20000

30000

40000

50000

60000

Byt

es

en

viad

os

y re

cib

ido

s

Tiempo (3ms)

Transferencia de datos

Recibido

Enviado


Posteriormente se ha realizado una instalación simultánea utilizando MDCTP para el transporte. Dado que todos los equipos pertenecen a la misma red solo se conforma una única zona de difusión.

El tiempo total resultante con el uso de MDCTP es de 21 minutos obteniéndose un 65% de reducción en el proceso global de instalación.

224

C a p í t u l o 7

Conclusiones

En esta investigación se ha creado un modelo general de gestión de redes compatible con los estándares basado en la incorporación de mecanismos para la gestión de la difusión masiva de información a partir de técnicas de grid computing, multicast y streaming de información, lo cual posibilita la propuesta, de manera sistemática, de arquitecturas y sistemas de gestión viables con los requerimientos actuales

Los resultados obtenidos tras la aplicación del modelo en un sistema de gestión de red real demuestran que mediante la integración de la gestión y transferencia de la información dentro de dicho sistema de gestión se consigue:

Que se puedan construir aplicaciones de gestión sin la necesidad de solucionar los problemas de transferencia de información, ya que ésta ya está contemplada en el propio sistema de gestión.

Que las aplicaciones de gestión accedan a la información presente en la red de forma transparente, sin importar la ubicación o los protocolos de acceso utilizados para ello.

Que la información se distribuya de forma automática en función de la importancia de dicha información y de las necesidades de los elementos integrados en el sistema de gestión, aportando mayores niveles de rendimiento y tolerancia a fallos.

Capítulo 7. Conclusiones 225

Además el hecho de incorporar un protocolo de transporte basado en mecanismos de transferencia colaborativa aporta las siguientes características:

Que la transmisión de la información se realice de forma escalable, sin importar el tamaño de la información o el número de destinatarios de la misma.

Evitar saturaciones en la red, haciendo que el sistema de gestión tenga un bajo impacto sobre la red que gestiona.

Aprovechar al máximo los recursos de la red, incorporando al proceso de transferencia elementos de soporte que faciliten la transmisión y aumenten los ratios de escalabilidad y tolerancia a fallos.

Aportaciones

El trabajo de investigación ha tenido dos claros enfoques: por una parte la integración de la difusión de la información en los sistemas de gestión y por otra la transmisión de la información mediante técnicas colaborativas.

Así pues las principales aportaciones que se desprenden del trabajo realizado son:

La creación de un modelo general de gestión de redes que incorpore la difusión de información masiva en su concepción y con características de autogestión.

La creación de un protocolo de transporte de red para el streaming de información a múltiples destinatarios mediantes técnicas colaborativas y con características de confiabilidad y escalabilidad.

Otras aportaciones del trabajo de investigación son:

La creación de un modelo de distribución de la información que permite difundir la información de la información en función de las necesidades y prioridades del sistema gestionado.

La instanciación del modelo de gestión para un protocolo de gestión real y ampliamente aceptado como SNMP


La creación de un protocolo de aplicación para la difusión de información.

La creación de una herramienta de gestión de red que implementa el modelo propuesto.

Publicaciones

A partir de la investigación realizada en este trabajo se ha obtenido un conjunto de publicaciones en revistas internacionales y congresos de ámbito nacional e internacional. En total se han generado dos publicaciones en revistas internacionales y más de 30 publicaciones en congresos internacionales relacionados con el ámbito de la propuesta.

A continuación se recogen las cinco publicaciones tanto en revistas como en congresos que se han considerado más relevantes, junto con un breve análisis de sus indicios de calidad que permiten avalar dicha relevancia en el ámbito de la investigación. También se presenta un extracto con las principales contribuciones.

Revistas

“Wake on LAN over Internet as Web Service System on Chip” (Maciá et al., 2010a), aceptado y pendiente de publicación.

Indicios de calidad: índice de impacto JCR 2008: 5,468. Posición 1/52 dentro de la categoría “Automation & Control Systems”

“Network Intrusion Detection System Embedded on a Smart Sensor” (Maciá et al., 2010b), aceptado y pendiente de publicación.

Indicios de calidad: índice de impacto JCR 2008: 5,468. Posición 1/52 dentro de la categoría “Automation & Control Systems”

“Industrial TCP/IP Services Monitoring through Embedded Web Services” (Maciá et al., 2008).

Congresos

“Management system for manufacturing components aligned with the organisation IT systems” (Marcos et al., 2009).

Capítulo 7. Conclusiones 227

Indicios de calidad: Situado entre sesenta y cinco congresos más importantes en el ámbito de la inteligencia artificial, aprendizaje de máquinas, robótica e interacción hombre-máquina según el Computer Science Conference Ranking (posición 52 con un índice de 0,56 sobre 1).

“Energy Management System as a Embedded Service: Saving Energy Consumption of ICT” (Maciá et al., 2009).

Otras Publicaciones

Otras investigaciones de relevancia relacionadas con el trabajo de investigación son: (Gilart et al., 2007), (Maciá et al., 2007), (Marcos et al., 2007), (Gilart et al., 2006), (Marcos et al., 2006a), (Marcos et al., 2006b), (Gil et al., 2006), (Maciá et al., 2006) y (Marcos et al., 2006c)

Problemas Abiertos

A lo largo de la investigación han surgido diversos problemas pero tanto por su temática como por los intereses del grupo de investigación se ha considerado que pueden ser especialmente relevantes para investigaciones futuras. A continuación se sintetizan los más relevantes.

Uno de los principales problemas no resueltos son los derivados por la falta de seguridad en los MDCTP y SDTP. En ese sentido el protocolo trabaja de forma similar a TCP, sin incorporara ningún mecanismo que aporte seguridad en ninguna de las cuatro áreas principales de la seguridad en redes: autenticación, autorización, integridad y confidencialidad.

El control de flujo en MDCTP también ha sido una cuestión no tratada en el presente trabajo. Su uso es importante, principalmente, para casos de redes saturadas o con mucha latencia en la transferencia.

Otro de los problemas no tratados en MDCTP es que, al ser un streaming sincronizado entre todos, cuando alguno de los nodos trabaja con bajas velocidades de transferencia, la velocidad global viene condicionada por la mínima de estas velocidades. En futuros trabajos se


podría estudiar la creación de árboles distribuidos en función de las velocidades de los nodos que lo componen.

Líneas Futuras

El trabajo de investigación se ha realizado al amparo de un grupo

de investigación ( ) cuya principal línea de investigación son las redes de computadores.

En este sentido el grupo ha realizado numerosos trabajos relacionados las redes de computadores y, en concreto, con la gestión de redes, área que ya había sido objeto de una tesis anterior (Maciá, 2001).

En el grupo se está trabajando en la actualidad en diversas líneas de investigación que pretenden ser una continuación de los trabajos anteriores. En concreto las dos principales líneas de continuación son:

Incorporación de semántica a la gestión de redes para conseguir altos niveles en la automatización de la gestión.

Incorporación de sistemas basados en algoritmos epidémicos que mejoren el modelo de distribución de la información y el proceso de difusión.

Estas líneas están siendo desarrolladas en la actualidad en el ámbito de dos nuevas tesis doctorales.

Como trabajo de continuación directa del presente trabajo de investigación se pretende realizar los siguientes trabajos:

Estudiar la instanciación del modelo de gestión y del modelo de distribución de información con otros protocolos de gestión como WS-Management.

Incorporar seguridad a los protocolo MDCTP y SDTP.

Incorporar nuevos mecanismos de creación del árbol de zonas en el protocolo MDCTP.

229

Referencias Bibliográficas

(7PM, 2007) Séptimo Programa Marco de Investigación y Desarrollo. http://cordis.europa.eu/fp7/home_es.html.

(Adamson et al., 2009) B. Adamson, C. Bormann, M. Handley, J. Macker (2009). NACK-Oriented Reliable Multicast (NORM) Transport Protocol. Request for Comments 5740. IETF.

(Alon et al., 2004) Alon Y. Halevy, Zachary G. Ives, Jayant Madhavan, Peter Mork, Dan Suciu, and Igor Tatarinov (2004). The Piazza Peer Data Management System. IEEE Transactions on Knowledge and Data Engineering. ISSN: 1041-4347, pp: 787- 798. EEUU.

(Barba, 2006) Antoni Barba Martí (2006). Gestión de Red. Editorial Ataraxiainc.

(Bolot et al, 1994) J. Bolot, T. Turletti, I. Wakeman (1994). Scalable Feedback Control for Multicast video Distribution in the Internet. ACM SIGCOMM Computer Communication Review. Vol 24, pp. 58-67.

(Britton y deVos, 2005)

Britton, J.P., deVos, A.N. (2005). CIM-based standards and CIM evolution. IEEE Transactions on Power Systems. Vol. 10, Issue 2, pp: 758-764.

(Byers & Luby, 1998) J. W. Byers y M. Luby (1998). A Digital Fountain Approach to Reliable Distribution of Bulk Data. Proceedings of ACM SIGCOMM’98. pp. 56–67.

(Case et al., 1990) J. Case, M. Fedor, M. Schoffstall, J. Davin (1990). A Simple Network Management Protocol (SNMP). Request for Comments 1157. Network Working Group.

(Case et al., 1996) J. Case, K. McCloghrie, M. Rose, S. Waldbusser (1996). Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). Request for Comments 1907. Network Working Group.


(Cisco, 2009) Cisco Systems, Inc (2009). Cisco Visual Networking Index:Forecast and Methodology, 2008–2013. White Paper. Online: http://www.cisco.com

(Clark & Tennenhouse, 1996)

D. Clark y D. Tennenhouse (1990). Architectural Considerations of a New Generation of Protocols. Proceedings of ACM SIGCOMM ’90.

(Comer, 1996) Douglas E. Comer (1996). Redes globales de información con internet y TCP/IP. Principios básicos, protocolos y arquitectura. Tercera Edición. Prentice-Hall Hispanoamericana.

(Debusmann et al., 2003)

Debusmann, M., Schmidt, M., Schmid, M., Kroeger, R. (2003). Unified service level monitoring using CIM. Enterprise Distributed Object Computing Conference, 2003. Proceedings. Seventh IEEE International. pp: 75-86.

(Deering, 1986) S. E. Deering (1986). Host Extensions for IP Multicasting. Request for Comments (RFC) 988.

(DeLucia & Obraczka, 1997)

Dante DeLucia y Katia Obraczka (1997). Multicast Feedback Suppression Using Representatives. Proceedings of the IEEE INFOCOM 1997. pp. 463-470.

(DMTF, 2008) DMTF (2008). Web Services for Management (WS-Management) Specification. Version: 1.0.0. Document Number: DSP0226.

(Douglas & Schmidt, 2005)

Douglas Mauro y Kevin Schmidt (2005). Essential SNMP, 2nd Edition. O'Reilly

(Floyd et al, 1996) Sally Floyd, Van Jacobson, Ching-Gung Liu, Steven McCanne y Lixia Zhang (1996). A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing. IEEE/ACM Transactions on Networking.

(Forouzan, 2002) Behrouz A. Forouzan (2002). Transmisión de datos y redes de comunicaciones. Segunda edición. McGraw-Hill.

(García, 1989) Jesús García Tomas (1989). Sistemas y redes teleinformáticas. Sociedad para Estudios Pedagógicos Argentinos (SEPA).

(Gil et al., 2006) J.A. Gil Martínez-Abarca, F. Maciá Pérez, D. Marcos Jorquera, V. Gilart Iglesias (2006). Wake on LAN over Internet as Web Service. Proceedings of the 11th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA'06).

(Gilart et al., 2006) V. Gilart Iglesias, F. Maciá Pérez, J.A. Gil Martínez-Abarca, D. Marcos Jorquera (2006).Services and networks management through embedded devices and SOA. Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference EDOC 2006.

Referencias 231

(Gilart et al., 2007) V. Gilart Iglesias, F. Maciá Pérez, D. Marcos Jorquera, F.J. Mora Gimeno (20007). Industrial Machines as a Service: Modelling industrial machinery processes. 5th IEEE International Conference on Industrial Informatics. Conference Proceedings. 2007.

(Guo et al., 2007) Lei Guo, Songqing Chen, Zhen Xiao, Enhua Tan, Xiaoning Ding, Xiaodong Zhang (2007). A performance study of BitTorrent-like peer-to-peer systems. IEEE Journal on Selected Areas in Communications. Vol. 25, isuue 1, pp. 155 – 169.

(Hairong et al., 2003) Hairong Sun ; Han, J.J. ; Levendel, H. (2003). Availability requirement for a fault-management server in high-availability communication systems. IEEE Transactions on Reliability. Vol. 52 pp. 238–244.

(Halsall, 1998) Fred Halsall (1998). Comunicación de datos, redes de computadores y sistemas abiertos. Cuarta edición. Addison Wesley Longman.

(Handley, 1997) M. Handley (1997). An Examination of Mbone Performance. Technical Report RR-97-450, USC/ISI.

(Harrington et al., 2002)

D. Harrington, R. Presuhn, B. Wijnen (2002). An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks. Request for Comments 3416. Network Working Group.

(Hawa, 2008) Hawa, M (2008). A measurement study of shared content on peer-to-peer networks. International Symposium on Performance Evaluation of Computer and Telecommunication Systems, SPECTS 2008. pp 277 – 284.

(Helms et al., 2006) Helms, R.W. ; van Oorschot, S. ; Herweijer, J. ; Plas, M. (2006). An integral IT continuity framework for undisrupted business operations. The First International Conference on Availability, Reliability and Security, 2006. ARES 2006.

(Hutter et al., 2009) Hutter, M., Szekely, A., Wolkerstorfer, J. (2009). Embedded system management using WBEM. IFIP/IEEE International Symposium on Integrated Network Management, 2009. IM '09. pp. 390-397.

(IEEE, 2000) IEEE (2000). IEEE Standard for Media Management System (MMS) Architecture. The Institute of Electrical and Electronics Engineers, Inc. ISBN 0-7381-2506-7. EEUU.

(INE, 2008) Instituto Nacional de Estadística (2008). Encuesta sobre Equipamiento y Uso de Tecnologías de la Información y Comunicación en los hogares. Años 2004-2008. España.

(INE, 2009) Instituto Nacional de Estadística (2009). Encuesta sobre el uso de TIC y comercio electrónico en las empresas. Años 2003-2008. España.


(ISO/IEC, 1989) ISO/IEC (1989). Information processing Systems – Open Systems Interconnection – Basic Reference Model – Part 4: Management framawork. ISO/IEC 7498-4 (E).

(ISO/IEC, 1994) ISO/IEC (1994). Information technology – Open Systems Interconnection – Basic Reference Model: The basic model. ISO/IEC 7498-1:1994(E).

(Lin y Paul, 1996) J.C. Lin y S. Paul. (1996). RMTP: A Reliable Multicast Transport Protocol. Proceedings of IEEE INFOCOM ’96. pp. 1414-1424.

(Lu et al., 2009) ZhiHui Lu, JiaJun Wang, Yu Wu, Jie Wu, YiPing Zhong (2009). MWS-MCS: A Novel Multi-agent-assisted and WS-Management-based Composite Service Management Scheme. IEEE International Conference on Web Services, 2009. ICWS 2009. pp. 1041-1042.

(Luby et al., 1997) M. Luby, M. Mitzenmacher, M. A. Shokrollahi, D. A. Spielman y V. Stemann (1997). Practical loss-resilient codes. Proceedings of the twenty-ninth annual ACM symposium on Theory of computing. pp. 150-159.

(Maciá et al., 2006) F. Maciá Pérez, V. Gilart Iglesias, D. Marcos Jorquera, J.A. Gil Martínez-Abarca (2006). Network Service Providing by means of Embedded Systems. 2006 IEEE International Conference on Industrial Informatics.

(Maciá et al., 2007) F. Maciá Pérez, D. Marcos Jorquera, V. Gilart Iglesias (2007). Embedded Web Services for Industrial TCP/IP Services Monitoring. Proceedings of the 12th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA'07).

(Maciá et al., 2008) F. Maciá Pérez, D. Marcos Jorquera, V. Gilart Iglesias (2008). Industrial TCP/IP Services Monitoring through Embedded Web Services. EURASIP Journal on Embedded Systems.

(Maciá et al., 2009) F. Maciá Pérez, D. Marcos Jorquera, V. Gilart Iglesias (2009). Energy Management System as a Embedded Service: Saving Energy Consumption of ICT. Architecture of Computing Systems - ARCS 2009. 22nd International Conference. Delft, The Netherlands, March 2009. Proceedings. Lecture Notes in Computer Science 5455.

(Maciá et al., 2010a) F. Maciá Pérez, J.A. Gil Martínez Abarca, H. Ramos Morillo, F. Mora Gimeno, D. Marcos Jorquera, V. Gilart Iglesias (Aceptado y pendiente de publicación). Wake on LAN over Internet as Web Service System on Chip. IEEE Transactions on Industrial Electronics.

(Maciá et al., 2010b) F. Maciá Pérez, F. Mora Gimeno, D. Marcos Jorquera, J.A. Gil Martínez-Abarca, H. Ramos Morillo, I. Lorenzo Fonseca (Aceptado y pendiente de publicación). Network Intrusion Detection System Embedded on a Smart Sensor. IEEE Transactions on Industrial Electronics.

Referencias 233

(Maciá, 2001) Francisco Maciá Pérez (2001). Modelos de Administración de Redes Heterogéneas de Computadores. Sistema de Regeneración de Nodos de Red. Tesis doctoral.

(Mack, 2002) Steve Mack. Streaming Media Bible. Hungry Minds.

(Mankin et al., 1998) A. Mankin, A. Romanow, S. Bradner y V. Paxson (1998). IETF Criteria For Evaluating Reliable Multicast Transport and Application Protocols. Request for Comments 2357.

(Marcos et al., 2006a) D. Marcos Jorquera, F. Maciá Pérez, V. Gilart Iglesias, J.V. Berná Martínez (2006). Business Continuity Model. Regeneration System for Manufacturing Components. Proceedings of the 10th IEEE International Enterprise Distributed Object Computing Conference EDOC 2006.

(Marcos et al., 2006b) D. Marcos Jorquera, F. Maciá Pérez, V. Gilart Iglesias, A. Capella D'alton (2006). Fault Tolerance for Manufacturing Components. Proceedings of the 11th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA'06).

(Marcos et al., 2006c) D. Marcos Jorquera, F. Maciá Pérez, V. Gilart Iglesias, J.A. Gil Martínez-Abarca (2006). High Availability for Manufacturing Components. 2006 IEEE International Conference on Industrial Informatics. 2006.

(Marcos et al., 2007) D. Marcos Jorquera; F. Maciá Pérez; V. Gilart Iglesias; J.A. Gil Martínez-Abarca (2007). Service model for the management of industrial environments. Dynamic reconfiguration of production elements. 5th IEEE International Conference on Industrial Informatics. Conference Proceedings. Vol. 1. pp 249-254.

(Marcos et al., 2007) D. Marcos Jorquera, F. Maciá Pérez, V. Gilart Iglesias, J.A. Gil Martínez-Abarca. Service model for the management of industrial environments. Dynamic reconfiguration of production elements. 5th IEEE International Conference on Industrial Informatics. Conference Proceedings.

(Marcos et al., 2009) D. Marcos Jorquera, F. Maciá Pérez, V. Gilart Iglesias, J. Gea Martínez, A. Ferrándiz Colmeiro (2009). Management system for manufacturing components aligned with the organisation IT systems. 7th International Conference on Practical Application of Agents and Multi-Agents Systems (PAAMS 2009). Advances in Intelligent and Soft Computing 55.

(McCloghrie & Rose, 1991)

K. McCloghrie, M. Rose (1991). Management Information Base for Network Management of TCP/IP-based internets: MIB-II. Request for Comments 1213. Network Working Group.

(Miller et al., 1997) K. Miller, K. Robertson, A. Tweedly, M. White (1997). StarBusrt Multicast File Transfer Protocol (MFTP) Specification. Internet Draft.

(Miller, 1997) K. Miller (1997). Reliable Multicast Protocols: A Practical View. Proceedings of the 22nd IEEE Conference on Local Computer Networks (LCN’97).


(Morris, 1997) R. Morris (1997). Bulk Multicast Transport Protocol. Procedings of INFOCOM’97.

(Nakamura et al., 1995)

Nakamura, N. ; Kashimura, N. ; Motomura, K. (1995) CMIP to SNMP translation technique based on rule description. Fourth International Conference on Computer Communications and Networks, 1995. Proceedings. pp. 266–271.

(Nonnenmacher et al, 1997)

J. Nonnenmacher, E. Biersack y D. Towsley (1997). Paity-Based Loss Recovery for Reliable Multicast Transmission. Technical Report 97-17, Department of Computer Science, University of Massachusetts.

(Park et al., 2006) Jong-Geun Park, Chang-Won Ahn, Hee-Nam Ch,o Il-Soo Byun, F. Desmons, Seong-Woon Kim (2006). A method for representing and transporting CIM operations using binary XML in the WBEM architecture. The 8th International Conference Advanced Communication Technology, 2006. ICACT 2006. pp. 2049-2053.

(Presuhn et al., 2002) R. Presuhn, J. Case, K. McCloghrie, M. Rose, S. Waldbusser (2002). Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP). Request for Comments 3416. Network Working Group.

(Radic et al., 2007) Radic, B., Kajic, V., Imamagic, E. (2007). Optimization of Data Transfer for Grid Using GridFTP. 29th International Conference on Information Technology Interfaces, 2007. ITI 2007. pp. 709-715.

(Rose & McCloghrie, 1990)

M. Rose, K. McCloghrie (1990). Structure and Identification of Management Information for TCP/IP-based Internets. Request for Comments 1155. Network Working Group.

(Sandvine, 2009) Sandvine (2009). 2009 Global Broadband Phenomena. Documento Online “http://www.sandvine.com/downloads/documents/2009 Global Broadband Phenomena - Executive Summary.pdf”.

(Stallings, 2000) William Stallings (2000). Comunicaciones y redes de computadores. Sexta edición. Prentice Hall.

(Sundaram et al., 2006)

Sundaram, S., Jong-Cheol Seo, Abdurakhmanov, A., Young-Tak Kim (2006). Design and Implementation of WBEM-based Network Management System for Inter-AS Traffic Engineering. Fourth International Conference on Software Engineering Research, Management and Applications, 2006.

(Tanenbaum, 1997) Andrew S. Tanenbaum (1997). Redes de computadoras. Tercera edición. Prentice Hall

(Tunpan y Corson, 2000)

A. Tunpan y M. S. Corson (2000). Bulk Data Multicast Rate Scheduling For Hybrid Heterogeneous Satellite-Terrestrial Networks. Proceedings of the Fifth IEEE Symposium on Computers and Communications (ISCC 2000). pp. 238.

Referencias 235

(Voruganti, 1994) Voruganti, R.R. (1994). A global network management framework for the '90s. IEEE Communications Magazine. Vol. 32 issue 8 pp. 74-83.

(Wu & Wang, 2009) Tai-Ting Wu; Kuochen Wang (2009). An efficient load balancing scheme for resilient search in KAD peer to peer networks. IEEE 9th Malaysia International Conference on Communications (MICC).pp. 759 - 764.

(Wu et al., 2006) Song Wu, Hai Jin, Kang He, Zongwei Luo (2006). A Data Transfer Scheme of Grid Workflow Based on Weighted Directed Graph. Fifth International Conference on Grid and Cooperative Computing Workshops, 2006. GCCW '06. pp. 491-495.

(Zhao et al., 2009) Guanghui Zhao, Chunli Wang, Dan Liu, Chengming Zou (2009). Research and Implementation of Data Transfer in Grid. International Conference on Future Computer and Communication, 2009. FCC '09. pp. 12-15.

Documents

DIFUSIÓN MASIVA DE INFORMACIÓN EN LOS MODELOS DE … · difusiÓn masiva de informaciÓn en los modelos de gestiÓn de redes aplicaciÓn a los servicios de alta disponibilidad sobre