Tesis Marcos Unlocked

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

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
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
xi
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.
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.
xiii
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.
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.
xv
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.
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
xvii
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
xix
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

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
xxiii
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
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
xxix
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
Capítulo 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.
80
Porcentaje de viviendas
60
40
20 Con algún tipo de ordenador

Disponen de acceso a Internet
0
Con conexión de Banda Ancha
2004
2005
2006
2007
años 2008
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
1
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).
100
Porcentaje de empresas
80
60
40 Empresas que disponen de ordenador

Empresas con conexión a Internet
Empresas con acceso a Internet mediante banda ancha
20 Empresas que disponen de Red de Area Local (LAN)
Empresas que tienen sitio o página web por países
0 Empresas que han realizado compras por comercio …
Empresas que han realizado ventas por comercio electrónico
2003 2004 2005 2006 2007 2008
Años
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
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.
Administración
Seguridad Control
NSM
Monitorización Coordinación
Figura 3. Sistema de Gestión de Redes (NSM).

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.
Sistemas de
Gestión
Redes Equipos Aplicaciones Información
Infraestructuras Inventario Configuración Distribución
Sistemas
Protocolos Mantenimiento Replicación
Operativos
Copias de
Servicios
seguridad
Seguridad
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
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).
Modelo de
Organización
Modelo
Modelo
Funcional de gestión Modelo de
información
OSI
Modelo de
Comunicación
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
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.
MIB
NMS
Protocolo de
gestión (SNMP) Red de
comunicaciones
MIB MIB
Agente Agente
Dispositivo Dispositivo
Administrado Administrado
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).
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).
Trafico Global , Estimación 2008-2013

60000
50000
40000
Internet
PB/mes
Non-Internet IP
30000
Mobile Data
20000 Total
10000
0
2008 2009 2010 2011 2012 2013
Año
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
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).
Aplicación
de Gestión
Sistema de
Transferencia
Sistema de Gestión
Dispositivo Dispositivo Dispositivo

Administrado Administrado Administrado
Red de comunicaciones
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
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).
Aplicación
de Gestión
Sistema de
Sistema de Gestión Transferencia
Dispositivo Dispositivo Dispositivo

Administrado Administrado Administrado
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
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.
Capítulo 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.
17
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
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.
SNMP v.3
Aspectos de
SNMP v.2 seguridad
Trasferencia
de bloques
de datos
SNMP v.1
Operaciones
básicas de
gestión
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
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.
R R R
E E E
R R R
R R R
Unicast Broadcast Multicast
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.
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. Descarga de video.

Streaming de audio. Descarga de música.
Videoconferencia. Replicación de repositorios
multimedia.
Datos Distribución de Descarga de archivos.

noticias.
Bases de datos replicadas.
Juegos interactivos.
Distribución de software.
Mensajería
Redes de compartición de
instantánea.
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.
Emisor Receptor
Paquete 1
ACK 1
Paquete 2
(perdido)
Tiempo de
espera
aleatorio
Paquete 2
(reenvío)
ACK 2
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
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).
Emisor Receptor
Paquete 1
Paquete 2
Paquete 3
Paquete 4
Paquete 5
Paquete 6 Tiempo de espera
Paquete 7
Paquete 8
NACK
Paquete 9
Paquete 2 Recepción del paquete 5

antes de la finalización
Paquete 10 del tiempo de espera
Figura 13. Envío de NACK por 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.
E Emisor
R Receptor
R
R R R Router
R R
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
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.
Media streaming
Media streaming
(HTTP, FTP,…)
Colaborativa +
Protocolos de
Difusión por
tranferencia
(multicast)
Streaming
Característica
multicast
UDP
TCP
P2P
IP
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
Capítulo 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.
49
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.
Modelo de
Organización
Modelo de
Modelo Modelo de
Gestión de
Funcional Información
Redes
Modelo de
Comunicación
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
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
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.
Modelo de Organización
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 Entidad
Protocolo Descripción
activa pasiva
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.
Modelo de
Organización
(OM)
Entidades de
Entorno de Protocolos de
Administración
Administración Red (NP)
(SMAE)
Red de Protocolos de
Dispositivos de Entidad de
comunicaciones Información (I) Gestión de Red
Red (ND) Gestión (ME)
(N) (NMP)
Dispositivos a Entidad de Protocolos de

Gestionar (MD) Control (CE) Transporte (TP)
Protocolos de
Dispositivos de Entidad de
descubrimiento
Soporte (SD) Información (IE)
(DP)
Entidad de
Registro (RE)
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.
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.
root
ccitt(0) iso(1) joint(2)
org(3)
dod(6)
internet(1)
directory(1) mgmt(2) experimental(3) private(4)
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.
mib-2(1)
system(1) interfaces(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) tranmission(10) snmp(11)
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).
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.
Entity
eid
type
name
description
ip
port
timeout
renew()
update()
topicSubscribe()
topicUnsuscribe()
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.

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

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.
Information
iid
size
description[]
url[]
priority
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
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).
InformationSet
informationList
publish()
delete()
search()
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.
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.
experimental
registry
management(0) entity(1) information(2)
publish(0) inquiry(1) publish(0) inquiry(1)
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.
registry
entity(1)
publish(0) inquiry(1)
action(0) entitiesNumber(0) entities(1) filter(2)
status(1) eid(0) eid(0)
eid(2) name(1) name(1)
type(3) description(2) description(2)
name(4) type(3) type(3)
description(5) ip(4) ip(4)
timeout(6) port(5) port(5)
topic(7) topic(6)
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.
Tabla 8. Operaciones de gestión de entidades.
Campos
description
Valor
timeout
Acción Descripción
name
topic
type
eid
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.
registry
information(2)
publish(0) inquiry(1)
action(0) informationNumber(0) information(1) filter(2)
iid(1) iid(0) iid(0)
size(2) size(2) description(1)
priority(3) priority(3) protocol(2)
description(4) description(4) eid(3)
url(5) url(5) topic(4)
topic(6)
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.
Tabla 10. Operaciones de gestión de información.
Campos
description
Valor
priority
Acción Descripción
topic
size
url
iid
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).
«objetivo» «abstracto»
Obtener un MIB
para la información MODELO SNMP
«control»
Objetos de Creación de MIB-

información Information
MIB-Information
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.
information(2)
informationNumber(0) information(1) filter(2)
iid(0) iid(0)
size(2) description(1)
priority(3) protocol(2)
description(4) eid(3)
url(5) topic(4)
Figura 42. Rama information.
Modelo de Comunicación
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.
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.
ds Message Transfer
srcEntity network dstEntity
sndMsg(msg)
transmit
rcvMsg
sndMsg(response)
transmit
rcvMsg
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
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.
ds Message Transfer
[1..n]
srcEntity network dstEntity
loop
sndMsg(msg)
[1..n]
alt transmit
transmit
rcvMsg
sndMsg(response)
transmit
alt
transmit
rcvMsg
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
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.
type length data
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.
SEQUENCE (0x30)
data
type length type length data type length data
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.
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).
Gestión de
Fallos
Gestión de la Gestión de la
seguridad configuración
Modelo
Funcional
Gestión del Gestión de

rendimiento cuentas
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.
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.
Recepción
Correlación Localización Corrección Validación
Notificaciones
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.
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.
Capítulo 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
95
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.
Motor SNMP
Subsistema Subsistema
Distribuidor de Procesado de Seguridad
de Mensajes
Control de
Módulo Acceso
Módulo
Subsistema Procesado
odule
Security
Security
Seguridad
de Mensajes Module
Module
Transporte
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.

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.
Motor SNMP
de Mensajes
Control de
Módulo Acceso
Módulo
odule
Security
Security
Seguridad
de Mensajes Module
Module
Transporte
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 Mensajes
Control de
Módulo Acceso
Módulo
odule
Security
Security
Seguridad
de Mensajes Module
Module
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).
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.
Servicios SNMP
Generador de Respondedor Generador de Receptor de
Proxy
comandos de comandos Notificaciones Notificaciones
Motor SNMP
de Mensajes Subsistema
Módulo de Control
Módulo de Acceso
odule
Security
Security
Seguridad
de Mensajes Module
Module
Transporte
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
Receptor de Notificaciones
Proxy
A continuación se describen en profundidad cada uno de ellos.
Agentes
Servicios SNMP
Proxy
Motor SNMP
Módulo de Control
Módulo de Acceso
odule
Security
Security
Seguridad
de Mensajes Module
Module
Transporte
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).
Agentes
Servicios SNMP
Proxy
Motor SNMP
Módulo de Control
Módulo de Acceso
odule
Security
Security
Seguridad
de Mensajes Module
Module
Transporte
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).
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).
Generador de TRASH Receptor de

notificaciones notificaciones
Motor Mensajes Motor

SNMP SNMP SNMP
Protocolo Protocolo
Transferencia Transferencia
Protocolo de Protocolo de
Red Red
Figura 66. Esquema de envío y recepción de una notificcion.

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.
Servicios SNMP
Proxy
Motor SNMP
Módulo de Control
Módulo de Acceso
odule
Security
Security
Seguridad
de Mensajes Module
Module
Transporte
Figura 67. Servicio Proxy.

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.
Motor Transferencia
Servidores P2P Clientes
Subsistema de Almacenamiento
Figura 68. Motor de Transferencia.

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.
Servicios Transferencia Masiva

Servicio de Servicio de
Provisión Streaming
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).
Agentes

Motor Transferencia
Red de
comunicaciones
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).
Agentes

Motor Transferencia
Red de
comunicaciones
Figura 71. Streaming de datos utilizando protocolos P2P.
El servicio de provisión por su parte siempre almacena los datos

recibidos (figura 72).
Agentes

Motor Transferencia
Red de
comunicaciones
Figura 72. Almacenamiento de datos.

Agentes
Los agentes (figura 73) son las aplicaciones que se ejecutan sobre
el middleware y que caracterizan a cada una de las entidades del
Agentes
Fallos Gestión Configuración Gestión Cuentas Gestión Rendimiento Gestión Seguridad
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
Servicios Transferencia Masiva Servicios SNMP

Servicio de Servicio de Generador de Respondedor Generador de Receptor de
Proxy
Provisión Streaming comandos de comandos Notificaciones Notificaciones
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
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.
Capítulo 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
129
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.
NUBE DE PEERS
Aplicación P2P
Aplicación P2P
Aplicación P2P
A
B
C
ALMACENAMIENTO MASIVO
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
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).
APLICACIÓN
Protocolo de Aplicación
MDCTP
TRANSPORTE
TCP
UDP
RED
IP
ENLACE
Protocolo de Enlace
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
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.
Re-emite / Recupera /
Tipo Emite Recibe
Retransmite 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.
8 Nodo 1 Emisor principal

? Nodo no conectado 7 Emisor secundario
6 Nodo muerto 10 Receptor
4 Nodo de soporte
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.
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.
SESIÓN DE TRANSFERENCIA
Fase de Fase de Fase de

conexión transferencia cierre
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
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).
8
6
3
DIFUSIÓN ENVÍO DIRECTO
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
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.
Identificador
de la zona
1
4 Nodo fuera
1 de la zona
4
7
15
7
2 9
Vecino de
Ámbito de la zona
difusión
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.
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.
NODO NODO
PASIVO socket ACTIVO
bind
listen
accept connect
recv send
send recv
close
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
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.
EMISOR RECEPTORES
open
bind
listen
accept connect
connect
connect
send recv
recv
recv
close
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
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.
Árbol
secundario
Zonas Raíz
Zonas
Intermedias
Zonas Hoja
Árbol
secundario Árbol principal
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.
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.
Paquete IP
Paquete UDP
Paquete MDCTP
Cabecera Cabecera Cabecera

Cuerpo MDCTP
IP UDP MDCTP
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.
Byte / Bit 0 2 3 7
0
sessionID
1
2 flags
3 peerType operation
4
srcPeerID
5
6
dstPeerID
7
8
zoneID
9
10
pktID
11
12
ack
13
14
next
15
16
out
17
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
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 Todos los bloques de datos

antes de ack han sido antes de ack han sido
recibidos por el nodo origen. recibidos por todos los nodos
del subárbol origen.
next Siguiente bloque de datos Siguiente bloque de datos

esperado por el nodo origen. esperado en la zona origen.
out Sólo se pueden recibir bloques En la zona origen sólo se

menores que out en el nodo pueden recibir bloques de
origen. 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.
flags=RESPONSE
srcPeerID=3
8
RSPN dstPeerID=8
flags=RELIABLE
pktID=78
srcPeerID=8
RQST
dstPeerID=3 3
pktID=78
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.
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.
RQST RQST RQST
4 4 4
6 RSPN 6 RSPN 6
4 RSPN 4 4
RSPN
7 7 7
15 15 15 RSPN
flags=RELIABLE flags=RESPONSE flags=RELIABLE flags=RESPONSE flags=RELIABLE flags=RESPONSE

flags=RESPONSE
srcPeerID=6 srcPeerID=4 srcPeerID=6 srcPeerID=7 srcPeerID=6 srcPeerID=15
flags=RESPONSE
srcPeerID=4
dstPeerID=4 dstPeerID=6 dstPeerID=ALL dstPeerID=6 dstPeerID=4 dstPeerID=6
srcPeerID=4
dstPeerID=6
pktID=78 pktID=78 pktID=78 pktID=78 pktID=78 pktID=78
dstPeerID=6
pktID=78
pktID=78
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 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.
3 flags=RELIABLE
RQST
srcPeerID=7
20
dstPeerID=ALL
2 2
3 pktID=342
7 7 RQST
flags=RELIABLE
srcPeerID=20
2 2
dstPeerID=ALL
4 4
9 9
pktID=125
1 2
3 4 3
flags=RESPONSE
20 flags=RESPONSE
srcPeerID=2
2 flags=RESPONSE
srcPeerID=4
3 RSPN dstPeerID=7
srcPeerID=4 2
7 dstPeerID=6
pktID=342
dstPeerID=6
flags=RESPONSE pktID=342 7 RSPN
srcPeerID=7
2 pktID=342
RSPN
dstPeerID=20
4 2
9 RSPN
pktID=125
4
9
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.
Byte / Bit 0 8
0
zoneID
1
2
parentID
3
4
neighbor s
5
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.
Byte / Bit 0 7
0
peerID
1
2
zoneID
3
4 peerType
5
6
ip
7
8
9
port
10
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).
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.
Byte / Bit 0 7
0 version
1 hr
2 vr
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.
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.
Byte / Bit 0 7
0
peerID
1
xN
2
zoneID
3
Figura 92. Cuerpo de la solicitud de la operación DEL.

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.
Byte / Bit 0 7
0 numZones
1 numPeers
2 zoneDefinition
x numZones
…
peerDefinition
x numPeers
…
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.
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.
Byte / Bit 0 7
0
1
processTime
2
3
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.
A1 PING-RQST
B1
PING-RSPN(B2-B1) B2
A2
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.
Byte / Bit 0 7
0
1
2
3
4
5 peerDefinition xN
6
7
8
9
10
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
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.
Byte / Bit 0 7
0
peerID
1
2 xN
3
distance
4
5
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.
Byte / Bit 0 7
0
dataID
1
2
dataSize
3
4 dataContent
… …
Figura 98. Cuerpo de la operación DATA.

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.
Byte / Bit 0 8
0
childZoneID
1
2
childAck
3
4
childNext
5
6
childOut
7
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.
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
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.
1 1
? 2
sessionID=7983 sessionID=7983
1 flags=RELIABLE | ZONE
1 flags=RESPONSE | ZONE
peerType=RECEIVER peerType=ROOT
operation=PEER operation=0
srcPeerID=0 srcPeerID=1
dstPeerID=1 dstPeerID=2
zoneID=0 zoneID=0
SOLICITUD RESPUESTA
pktID=1 pktID=1
ack=0 ack=0
next=0 next=0
out=32 out=64
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.
1
3
1 2
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).
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.
1 2 1 2
2
sessionID=7983
1 1
flags=RELIABLE
peerType=RECEIVER
operation=ZONE
srcPeerID=2
dstPeerID=0
SOLICITUD zoneID=0 SIN RESPUESTA
pktID=2
ack=0
next=0
out=32
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.
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.
2 2
1 2 1 2
flags=RELIABLE flags=RESPONSE
3
1 3 1
peerType=RECEIVER peerType=RECEIVER
operation=ZONE operation=0
dstPeerID=0 SOLICITUD dstPeerID=3 RESPUESTA

zoneID=0 zoneID=2
pktID=2 pktID=2
ack=0 ack=0
next=0 next=0
out=32 out=32
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.
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.
SOLICITUD ZONE SOLICITUD PEER RESPUESTA PEER
7
1 ? 1 ? 1 10
1 1 7 1
7 7 7
sessionID=7983 sessionID=7983 sessionID=7983
flags=RELIABLE flags=RELIABLE | ZONE flags=RESPONSE
peerType=RECEIVER peerType=SUPPORT peerType=ROOT
operation=ZONE operation=PEER operation=0
srcPeerID=7 srcPeerID=0 srcPeerID=1
dstPeerID=0 dstPeerID=1 dstPeerID=10
zoneID=0 zoneID=7 zoneID=1
pktID=2 pktID=1 pktID=24
ack=0 ack=0 ack=0
next=0 next=0 next=0
out=32 out=64 out=64
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
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).
1 2 5 9 12
1 38 34 34 40
2 38 44 54 42
5 38 46 3 60
9 34 54 5 45
12 40 42 68 45
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).
1 2 5 9 12
1 38 36 34 40
2 45 54 42
5 4 64
9 45
12
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
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.
1
1 2 5 9 12
1 38 36 34 40
2 45 54 42 9 2
5 4 64
9 45
5 12
12
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
Figura 108. Creación de una árbol de zonas.

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.
EMISOR RECEPTOR
Proceso de Proceso de
usuario usuario
Escribir Leer
Buffer de Transferencia Buffer de Transferencia
Proceso de Proceso de
transferencia transferencia
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.
size
first out
... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ...
Flujo de información
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.
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.
first ack next out
... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ...
Bloques Bloques Zona de Ventana de Bloques fuera de

procesados y recibidos recuperación y recepción la transferencia
descartados reordenación
Bloque sin datos Bloque con datos
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
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.
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.
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.
ack next out
... 17 18 19 20 ? ? ? 24 25 26 27 28 29 30 31 32 ...
Ventana de recuperación y Ventana de recepción
reordenación
Bloque sin datos Bloque con datos ? Bloque indeterminado
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
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).
4
Ventana de recuperación y
Ventana de recepción
reordenación
7 4
reordenación 4
7
11
Ventana de recuperación y 11
reordenación
4
reordenación
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).
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).
DATA
ACK
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.
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.
DATA(37) 1
sessionID=7983
20 1
flags=0
peerType=ROOT
25
operation=DATA
srcPeerID=1 1
dstPeerID=20
zoneID=1 ... 34 35 36 37 38 39 ...
pktID=168 RSP 25 20 1 20
ack=38
next=38 20
out=64
dataID=37 ... 34 35 36 37 38 39 ...
dataSize=1024 RSP 25 1 20
dataContent=…
25
... 34 35 36 37 38 39 ...
RSP 25 20 1
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.
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.
1
sessionID=7983
flags=ZONE 20 1
peerType=RECEIVER
operation=DATA
25
srcPeerID=20 DATA(37)
dstPeerID=6 2
zoneID=1
pktID=102
6
ack=38
4
next=38
15
out=45
7
dataID=37
2
dataSize=1024
6
dataContent=… Buffer de Transferencia
... 34 35 36 37 38 39 ...
RSP 7 2 4 6
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.
sessionID=7983
flags=0
peerType=RECEIVER
operation=DATA Nodo
srcPeerID=6
responsable
dstPeerID=4 2
zoneID=2
pktID=156
6
ack=38
4
next=38 DATA(37)
15
out=52
7
dataID=37
2
dataSize=1024
dataContent=…
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.
flags=ZONE flags=ZONE
peerType=RECEIVER peerType=RECEIVER
operation=DATA 2 operation=DATA
dstPeerID=3
6 dstPeerID=8
zoneID=2
4 zoneID=2
pktID=157 pktID=158
15
ack=38 ack=38
7
next=38 next=38
2
out=52 out=52
DATA(37)
dataID=37 dataID=37
DATA(37)
dataSize=1024 5 8 dataSize=1024
dataContent=… 5 dataContent=…
8 13
3
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.
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.
1
sessionID=7983
20 1 flags=ZONE
peerType=RECEIVER
25 operation=DATA
srcPeerID=4
2 ACK dstPeerID=25
zoneID=2
6 pktID=78
4 ack=38
next=38
15
out=52
7
2
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.
sessionID=7983
flags=0
peerType=RECEIVER
operation=DATA
1 srcPeerID=25
20 1 dstPeerID=ALL
zoneID=2
ACK
25 pktID=78
ack=38
next=38
out=49
childZoneID=2
childAck=38
childNext=38
childOut=52
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
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.
1
XOR
0 1 2 3 4 5 6 7
Bloques enviados
4
XOR
0 2 3 4 5 6 7 1
Bloques recibidos
9
XOR
0 1 2 3 4 5 7 6
Bloques recibidos
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
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).
HR=8
0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
XOR(8,9,10,11,12,13,14,15)
VR=4
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
31 31 ...
XOR(4,12,20,28)
Bloque de datos Bloque de recuperación
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
distintas filas. En la figura 124 se ilustra la distribución de los

bloques de recuperación.
HR=8
0 1 2 3 4 5 6 7
8 9 10 11 12 13 14 15
XOR(8,9,10,11,12,13,14,15)
VR=4
16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
31 31 ...
XOR(3,11,19,27)
Bloque de datos Bloque 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.
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).
TRANSPORTE APLICACIÓN
SDTP
TCP MDCTP
RED
IP
ENLACE
Protocolo de Enlace
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
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.
SDTP SDTP SDTP
TCP socket TCP socket TCP socket
srv srv cln
open()
bind() bind()
loop accept() connect()

TCP: connect
fork()
close() read(request) write(request)

tcp
write(response read(response
) tcp )
close() close()
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
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> Obtiene un nuevo paquete de información.

[options]
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.
Capítulo 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.
207
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
=======================================================
= 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
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.
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.
Servidor de
Autenticación
Control de acceso
mediante tarjetas
Entorno de
inteligentes (Smart Card) Almacenamiento y
Directorio, repositorio software
Cliente
Perfiles y Dir
Administración
Certificados
DB
Router/ Proxy/ Firewall
Navegador DB
Web DB
Cliente DB
Regeneración
Servidor
Web HTML
Internet Sistema de
Información
Interfaz
Agente Lógica de
Servidor de
Regeneración Negocio
Aplicaciones
Cliente ubicuo de
regeneración
(PDA, portátil,
Móvil, ...) Agente
Regeneración
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.
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.
1
1
7
1 2 3
4
3
2
4
6 3 4 5 6 7
5 9 2 5
6 9
8 7 8 9
8
MDCTP(1) MDCTP(3) MDCTP(9)
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.
Tráfico enviado por el emisor
9
8
7
6
MDCTP(1)
5
GB
4 MDCTP(3)
3 MDCTP(9)
2 TCP
1
eD2K
0
1 2 3 4 5 6 7 8
Número de nodos receptores
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.
Tráfico enviado por el emisor

2,2
2
1,8
MDCTP(1)
1,6
GB
MDCTP(3)
1,4
MDCTP(9)
1,2
TCP
1
eD2K
0,8
1 2 3 4 5 6 7 8
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.
Tráfico enviado por el emisor por cada nodo receptor

1,2
0,8
MDCTP(1)
GB
0,6 MDCTP(3)
0,4 MDCTP(9)
0,2 TCP
eD2K
0
1 2 3 4 5 6 7 8
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.
Tráfico recibido por el emisor
100
90
80
70
60 MDCTP(1)
MB
50 MDCTP(3)
40
30 MDCTP(9)
20 TCP
10
eD2K
0
1 2 3 4 5 6 7 8
Figura 135. Tráfico recibido por el emisor.

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.
Tráfico enviado por los nodos receptores

900
800
700
600
MDCTP(1)
500
MB
400 MDCTP(3)
300 MDCTP(9)
200 TCP
100
eD2K
0
1 2 3 4 5 6 7 8
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.
Tráfico recibido por los nodos receptores

1,08
1,07
1,06
MDCTP(1)
1,05
GB
MDCTP(3)
1,04
MDCTP(9)
1,03
TCP
1,02
eD2K
1,01
1 2 3 4 5 6 7 8
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.
Tráfico total enviado

9
8
7
6
MDCTP(1)
5
GB
4 MDCTP(3)
3 MDCTP(9)
2 TCP
1
eD2K
0
1 2 3 4 5 6 7 8
Figura 138. Tráfico total enviado por todos los nodos.

En el caso del tráfico total recibido todos se mantienen en el

mismo orden de transferencia (figura 139).
Tráfico total recibido

9
8
7
6
MDCTP(1)
5
GB
4 MDCTP(3)
3 MDCTP(9)
2 TCP
1
eD2K
0
1 2 3 4 5 6 7 8
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.
Tráfico medio enviado por nodo

1
0,9
0,8
0,7
0,6 MDCTP(1)
GB
0,5 MDCTP(3)
0,4
0,3 MDCTP(9)
0,2 TCP
0,1
eD2K
0
1 2 3 4 5 6 7 8
Figura 140. Tráfico medio enviado por cada nodo.

Tráfico medio recibido por nodo

1
0,95
0,9
0,85
0,8 MDCTP(1)
GB
0,75 MDCTP(3)
0,7
0,65 MDCTP(9)
0,6 TCP
0,55
eD2K
0,5
1 2 3 4 5 6 7 8
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.
Tiempo total de transmisión

800
700
600
500 MDCTP(1)
segundos
400 MDCTP(3)
300
MDCTP(9)
200
TCP
100
eD2K
0
1 2 3 4 5 6 7 8
Figura 142. Tiempo medio de transferencia.

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.
Evolución de las ventanas de transferencia

18
Ventana de transferencia (out - ack)
16
14
12
10 Local
8 Subárbol
6 Zona
4
2
0
Tiempo (3ms)
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
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.
Transferencia de datos
60000
50000
Bytes enviados y recibidos
40000
30000 Recibido
Enviado
20000
10000
0
Tiempo (3ms)
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.
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.
Capítulo 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
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.
224
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.
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, Britton, J.P., deVos, A.N. (2005). CIM-based standards and CIM
2005) 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.
229
(Cisco, 2009) Cisco Systems, Inc (2009). Cisco Visual Networking Index:Forecast and
Methodology, 2008–2013. White Paper. Online: http://www.cisco.com
(Clark & D. Clark y D. Tennenhouse (1990). Architectural Considerations of a New

Tennenhouse, 1996) 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., Debusmann, M., Schmidt, M., Schmid, M., Kroeger, R. (2003). Unified
2003) 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 & Dante DeLucia y Katia Obraczka (1997). Multicast Feedback Suppression
Obraczka, 1997) 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, Douglas Mauro y Kevin Schmidt (2005). Essential SNMP, 2nd Edition.
2005) 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., D. Harrington, R. Presuhn, B. Wijnen (2002). An Architecture for Describing

2002) 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
(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
(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, K. McCloghrie, M. Rose (1991). Management Information Base for Network
1991) 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., Nakamura, N. ; Kashimura, N. ; Motomura, K. (1995) CMIP to SNMP

1995) translation technique based on rule description. Fourth International Conference
on Computer Communications and Networks, 1995. Proceedings. pp.
266–271.
(Nonnenmacher et al, J. Nonnenmacher, E. Biersack y D. Towsley (1997). Paity-Based Loss

1997) 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, M. Rose, K. McCloghrie (1990). Structure and Identification of Management
1990) 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., Sundaram, S., Jong-Cheol Seo, Abdurakhmanov, A., Young-Tak Kim
2006) (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, A. Tunpan y M. S. Corson (2000). Bulk Data Multicast Rate Scheduling For
2000) 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.

Tesis Marcos Unlocked

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tesis Marcos Unlocked

Hochgeladen von

Copyright:

Verfügbare Formate

DIFUSIÓN MASIVA DE INFORMACIÓN EN

LOS MODELOS DE GESTIÓN DE REDES

Diego Marcos Jorquera

DIFUSIÓN MASIVA DE INFORMACIÓN

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

En la presente tesis se propone un modelo de gestión de redes

transferencia de importantes volúmenes de información a través

En la present tesi es proposa un model de gestió de xarxes que

Els principals resultats de la investigació són: un model de gestió

In this thesis a network management model is proposed that

The main results of the research are: a model of network

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

REFERENCIAS BIBLIOGRÁFICAS 229

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

Escenarios de Pruebas 211

REFERENCIAS BIBLIOGRÁFICAS 229

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

FIGURA 19. DIAGRAMA DE HERENCIA DEL MODELO DE ORGANIZACIÓN. .......................... 54

FIGURA 59. SUBSISTEMA DE CONTROL DE ACCESO DEL MOTOR SNMP. .........................106

FIGURA 100. ESCENARIO DEL EMISOR AL INICIAR. .....................................................167

FIGURA 140. TRÁFICO MEDIO ENVIADO POR CADA NODO. ..........................................219

TABLA 1. TIPOS DE APLICACIONES MULTICAST. .......................................................... 26

TABLA 35. TIPOS DE ZONAS. ................................................................................142

La comunicación y el uso de redes de computadores, así como su

20 Con algún tipo de ordenador

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

40 Empresas que disponen de ordenador

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

En este entorno se hace totalmente imprescindible asegurar en

servicios prestados, independientemente de las circunstancias

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

Para facilitar o asistir las labores de administración surge el

Redes Equipos Aplicaciones Información

Infraestructuras Inventario Configuración Distribución

Figura 4. Elementos susceptibles de ser gestionados.

En la actualidad la gestión y distribución de la información

enfrentan los administradores de sistemas. Realizar copias de

En la mayoría de los casos los sistemas de gestión están basados

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

La principal organización responsable de los procesos de

elementos a administrar, el conjunto de gestores y agentes de

Figura 6. Arquitectura de SNMP.

Estas propuestas han sido ampliamente utilizadas en el pasado y

Sin embargo, debido a las necesidades impuestas por los

Trafico Global , Estimación 2008-2013

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

Otra característica relevante de los nuevos servicios electrónicos

multimedia o de bases de datos. En estos casos los sistemas

ámbito internacional como el IFIP/IEEE International Symposium

El , grupo de investigación de redes y middleware del

Problema, Hipótesis y Propuesta de

El incremento de los volúmenes de información que manejan

Dispositivo Dispositivo Dispositivo

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

presente trabajo es el de de la gestión de redes, donde se