Control de Congestión con OPNET - Departamento de Ingeniería de

Control de Congestión con OPNET
Universidad de Valladolid
E. T. S. DE INGENIERÍA INFORMÁTICA
Ingeniería Técnica en Informática de Sistemas
Control de Congestión con
OPNET
Alumna: Lourdes Nicolás Fernández
Tutora: Mª Teresa Álvarez Álvarez
1
Control de Congestión con OPNET
AGRADECIMIENTOS
En primer lugar quisiera agradecer a mi tutora, Teresa, por su trato cercano. Su ayuda y su
optimismo me han dado ánimo en aquellos momentos en los que no sabía cómo seguir adelante
con el proyecto, o pensaba que no iba a terminar a tiempo.
A mis padres y mi a hermano, las personas más importantes para mí, que me han dado su cariño y
su apoyo incondicional durante todos estos años de la carrera. Muchas veces he descargado mi
frustración con vosotros injustamente. Gracias por ser pacientes conmigo. Por supuesto también
debo agradecer al resto de mi familia: mis tíos y primos, y especialmente a mis abuelos, que
siempre están pendientes de mí. Es una suerte poder seguir contando con ellos.
A Pablo, por ser mi punto de apoyo del día a día y por sacar siempre tiempo y paciencia para
escucharme. Tus consejos y tu compañía me hacen recuperar la fuerza cuando más débil me siento
y la estabilidad cuando todo se derrumba a mi alrededor .
Se dice que un amigo es una persona con la que se puede pensar en voz alta. Muchas gracias a
vosotras, Rocío y Virginia, por “pensar” conmigo tantas veces a lo largo de todos estos años de
universidad, en los momentos buenos y en los malos. Que sepáis que os tocará seguir
escuchándome por unos cuantos años más…
También debo agradecer a la gente de fuera de la universidad: a Luis, Tatiana, Pedro y los
demás… por los momentos inolvidables que hemos pasado juntos, y lo que todavía nos queda.
Debo dedicar un agradecimiento especial a Rubén, un gran amigo que siempre está ahí, y una de
las personas que más me ha ayudado durante toda la carrera. Sin tu consejo y tu ayuda este
camino habría sido mucho menos llevadero.
Por todo ello, muchas gracias a todos,
Lourdes.
3
Control de Congestión con OPNET
Índice general
ÍNDICE DE ILUSTRACIONES.................................................................................................... 11
CAPÍTULO 1.
INTRODUCCIÓN ........................................................................................ 15
1.1 MOTIVACIÓN ........................................................................................................................... 15
1.1.1 Simuladores de red ......................................................................................................... 16
1.1.2 Simulador OPNET Modeler ........................................................................................... 18
1.2 OBJETIVO DEL PROYECTO........................................................................................................ 19
1.3 RECOPILACIÓN DE INFORMACIÓN ............................................................................................ 19
1.4 ESTRUCTURA DE LA MEMORIA ................................................................................................ 20
CAPÍTULO 2.
CONCEPTOS TEÓRICOS .......................................................................... 23
2.1 INTRODUCCIÓN ....................................................................................................................... 23
2.1.1 Situación de las redes actuales...................................................................................... 23
El control de congestión..................................................................................................................... 24
2.2 CALIDAD DE SERVICIO ............................................................................................................ 25
2.2.1 Introducción .................................................................................................................. 25
2.2.2 Mecanismos de QoS ....................................................................................................... 25
2.2.2.1 Servicio Best Effort................................................................................................................ 25
2.2.2.2 Servicios Integrados (IntServ) ................................................................................................ 25
2.2.2.3 Servicios Diferenciados (DiffServ)......................................................................................... 26
2.2.3 Elementos que deterioran la QoS percibida por el usuario ........................................... 27
2.2.3.1 Retardo extremo-a-extremo.................................................................................................... 27
2.2.3.2 Pérdida de paquetes y corrupción de datos............................................................................. 27
2.3 PROTOCOLOS EXTREMO A EXTREMO ...................................................................................... 28
2.3.1 Protocolos de Transporte TCP y UDP ........................................................................... 28
2.3.2
Control de congestión en TCP .................................................................................. 29
2.3.2.1 Arranque lento y prevención de la congestión........................................................................ 29
2.3.2.2 Retransmisión Rápida y Recuperación Rápida....................................................................... 30
2.3.2.3 Versiones de TCP................................................................................................................... 31
•
Tahoe.................................................................................................................................. 31
•
Reno ................................................................................................................................... 31
•
New Reno........................................................................................................................... 31
•
Vegas.................................................................................................................................. 31
2.4 QOS DENTRO DE LOS ROUTERS ............................................................................................... 32
2.4.1 Clasificación................................................................................................................... 32
2.4.2 Gestión de colas ............................................................................................................. 32
2.4.3 Planificación de colas .................................................................................................... 33
2.4.3.1 FIFO (First In First Out)......................................................................................................... 33
2.4.3.2 Colas de prioridad ( PQ, Priority Queueing).......................................................................... 33
2.4.3.3 FQ (Fair Queueing) ............................................................................................................... 34
2.4.3.4 WFQ (Weighted Fair Queueing) ............................................................................................ 34
2.5 GESTIÓN ACTIVA DE COLAS.................................................................................................... 35
5
Indice
2.5.1 Introducción y fundamentos de los AQM ........................................................................35
2.5.1.1 Notificación Explícita de la Congestión (ECN) ..................................................................... 36
2.5.2 Random Early Detection (RED)......................................................................................36
2.5.2.1 Gentle-RED............................................................................................................................ 38
CAPÍTULO 3.
INTRODUCCIÓN TEÓRICA AL SIMULADOR OPNET .......................41
3.1 INTRODUCCIÓN ........................................................................................................................41
3.2 DOMINIO DE RED (NETWORK DOMAIN).....................................................................................43
3.3 DOMINIO DE NODOS (NODE DOMAIN).......................................................................................44
3.3.1 Módulos...........................................................................................................................45
3.3.1.1 Procesador.............................................................................................................................. 45
3.3.1.2 Cola ........................................................................................................................................ 45
3.3.1.3 Transmisor: ............................................................................................................................ 46
3.3.1.4 Receptor: ................................................................................................................................ 47
3.3.2 Conexiones......................................................................................................................47
3.3.2.1 Packet Streams ....................................................................................................................... 47
3.3.2.2 Statistic Wires ........................................................................................................................ 47
3.3.2.3 Logical Associations .............................................................................................................. 48
3.3.3 Atributos..........................................................................................................................48
3.4 DOMINIO DE PROCESOS ............................................................................................................48
3.4.1 Entorno de un Proceso....................................................................................................49
3.4.1.1 Ejecución basada en interrupciones........................................................................................ 49
3.4.1.2 Procesos Dinámicos ............................................................................................................... 49
•
Jerarquía de procesos ......................................................................................................... 49
•
Memoria compartida .......................................................................................................... 50
•
Operaciones con Procesos Dinámicos ................................................................................ 51
•
Control de interrupciones ................................................................................................... 52
3.4.1.3 Recursos de un proceso .......................................................................................................... 52
•
Canales de entrada/salida (Input and Output Streams)....................................................... 52
•
Estadísticas (Input Statistics y Local Output Statistics)...................................................... 53
•
Estadísticas Globales.......................................................................................................... 55
•
Subcolas ............................................................................................................................. 55
•
Atributos............................................................................................................................. 55
3.4.2 Componentes de un modelo de proceso ..........................................................................56
3.4.2.1 Proto-C: el lenguaje de los modelos de proceso ..................................................................... 56
3.4.2.2 Diagramas de Transición de Estados...................................................................................... 56
•
Estados Forzados y No forzados ........................................................................................ 57
•
Estado Inicial...................................................................................................................... 60
•
Transiciones ....................................................................................................................... 60
3.4.2.3 Macros.................................................................................................................................... 61
3.4.2.4 Variables ................................................................................................................................ 62
•
Variables de estado (State variables) ................................................................................. 63
•
Variables temporales (Temporary variables) ..................................................................... 63
•
Variables Globales (Global variables) ............................................................................... 64
3.4.2.5 Uso de funciones .................................................................................................................... 64
•
Function Block ................................................................................................................... 64
•
External Object Files (Ficheros externos).......................................................................... 65
3.4.2.6 Atributos del modelo de procesos .......................................................................................... 65
•
Attribute Interfaces............................................................................................................. 66
3.5 SIMULACIÓN ............................................................................................................................67
3.5.1 Construcción de un modelo de simulación......................................................................67
3.5.2 Simulación de eventos discretos......................................................................................68
3.5.2.1 Eventos y simulation time ...................................................................................................... 68
3.5.2.2 Planificación y Lista de eventos ............................................................................................. 69
6
Control de Congestión con OPNET
3.5.2.3 Eventos................................................................................................................................... 70
•
Atributos de los Eventos..................................................................................................... 70
•
Tipos de Eventos ................................................................................................................ 71
•
Procesamiento de Eventos - Interrupciones........................................................................ 71
CAPÍTULO 4.
IMPLEMENTACIÓN DEL ALGORITMO RED EN OPNET................ 73
4.1 INTRODUCCIÓN ....................................................................................................................... 73
4.1.1 Requisitos previos a la instalación y uso........................................................................ 73
4.1.2 Obtención y Gestión de licencias ................................................................................... 74
4.1.3 Instalación ...................................................................................................................... 74
4.1.4 Configuración................................................................................................................. 75
•
Comprobar las preferencias de OPNET:.................................................................................. 75
4.2 MODELADO A NIVEL DE TOPOLOGÍA ....................................................................................... 76
4.2.1 Descripción de la topología ........................................................................................... 76
4.2.2 Construcción paso a paso .............................................................................................. 76
4.2.2.1 Creación de un proyecto nuevo: ............................................................................................. 76
4.2.2.2 Creación de la red: ................................................................................................................. 77
4.2.2.3 Configuración del Nodo de Aplicaciones............................................................................... 79
4.2.2.4 Configuración del Nodo de Perfiles ...................................................................................... 79
4.2.2.5 Configuración de Clientes y Servidores ................................................................................. 80
4.2.3 Configuración de Atributos QoS .................................................................................... 83
4.2.4 Elección de estadísticas.................................................................................................. 84
4.2.5 Duplicar escenarios........................................................................................................ 85
4.2.5.1 Operaciones del menú Scenarios............................................................................................ 86
4.2.5.2 Creación y configuración del escenario RED......................................................................... 87
4.2.5.3 Creación y configuración del escenario GRED...................................................................... 88
4.2.6 Simulación de los escenarios.......................................................................................... 89
4.2.6.1 Simular un solo escenario....................................................................................................... 90
4.2.7 Comparación y visualización de resultados ................................................................... 91
4.3 ESTUDIO DEL NODO QOS......................................................................................................... 93
4.3.1 Acceso al editor de nodos............................................................................................... 93
4.3.2 Modelo de nodos del nodo QoS...................................................................................... 93
4.3.3 Modelo de procesos del módulo “attribute_definer”..................................................... 95
•
•
•
•
•
Header Block .......................................................................................................................... 95
Variables de Estado ................................................................................................................ 96
Variables Temporales ............................................................................................................. 96
Enter Executives ..................................................................................................................... 96
Function Block ....................................................................................................................... 97
4.3.4 Modificación de atributos............................................................................................. 100
4.3.4.1 Acceso a la tabla de atributos ............................................................................................... 101
4.3.4.2 Añadir un nuevo atributo...................................................................................................... 102
4.3.4.3 Añadir valores a un atributo ya creado ................................................................................. 104
4.4 ESTUDIO DE UN NODO ROUTER .............................................................................................. 107
4.4.1 Modelo de nodos del nodo router1............................................................................... 108
4.4.2 Modelo de procesos del módulo ip ............................................................................... 109
4.4.2.1 Análisis de ip_dispatch......................................................................................................... 110
4.4.2.2 Análisis de ip_output_iface .................................................................................................. 121
4.5 ESQUEMA-RESUMEN PARA LA IMPLEMENTACIÓN DE GRED ................................................. 140
4.5.1 Modificación de código en ficheros externos ............................................................... 140
4.5.1.1 oms_qm.h............................................................................................................................. 140
4.5.1.2 oms_qm.ex.c ........................................................................................................................ 140
4.5.2 Modificación del modelo de procesos ip_output_iface ................................................ 141
7
Indice
4.5.3. Modificación de atributos del nodo QoS......................................................................142
CAPÍTULO 5. EXPERIMENTOS...............................................................................................143
5.1 INTRODUCCIÓN ......................................................................................................................143
5.2 TOPOLOGÍAS UTILIZADAS ......................................................................................................143
5.2.1 CuelloBotella ................................................................................................................143
5.2.1.1 Escenarios ............................................................................................................................ 144
5.2.2 CuelloBotella2 ..............................................................................................................145
5.2.2.1 Escenarios ............................................................................................................................ 145
5.3 REGLAS DE AJUSTE DE PARÁMETROS DE RED .......................................................................146
5.3.1 Configuración de los parámetros en general...............................................................146
5.3.2 Umbral Mínimo.............................................................................................................146
5.3.3 Umbral Máximo ............................................................................................................146
5.3.4 Exponential Weight Factor (wq) ...................................................................................147
5.3.5 Probabilidad Máxima ...................................................................................................147
5.3.6 Ajuste de parámetros GRED .........................................................................................147
5.4 RESULTADOS CON LA TOPOLOGÍA CUELLOBOTELLA .............................................................148
5.4.1 Especificación de parámetros para los experimentos...................................................148
5.4.1.1 Nodo Aplicaciones: .............................................................................................................. 148
5.4.1.2 Nodo Perfiles........................................................................................................................ 148
5.4.1.3 Nodo QoS............................................................................................................................. 148
5.4.1.4 Otros parámetros .................................................................................................................. 149
5.4.2 Gráficas.........................................................................................................................150
5.4.2.1 Tráfico descartado globalmente ........................................................................................... 150
5.4.2.2 Retardo global de la red ....................................................................................................... 152
5.4.2.3 Utilización del buffer en Router1 ......................................................................................... 154
5.4.2.4 Variación en el retardo o jitter en Router1 ........................................................................... 156
5.4.2.5 Retardo en Router1 o Delay ................................................................................................. 158
5.4.2.6 Comparación entre RED y GRED........................................................................................ 160
5.4.2.7 Utilización del enlace entre Router1 y Router2.................................................................... 162
5.5 RESULTADOS CON LA TOPOLOGÍA CUELLOBOTELLA2 ...........................................................164
5.5.1 Especificación de parámetros para los experimentos...................................................164
5.5.1.1 Nodo Aplicaciones: .............................................................................................................. 164
5.5.1.2 Nodo Perfiles........................................................................................................................ 164
5.5.1.3 Nodo QoS............................................................................................................................. 164
5.5.2 Gráficas.........................................................................................................................166
5.5.2.1 Tráfico descartado globalmente ........................................................................................... 166
5.5.2.2 Retardo global en la red ....................................................................................................... 166
5.5.2.3 Utilización del buffer en Router1 ......................................................................................... 167
5.5.2.4 Retardo en Router1............................................................................................................... 167
5.5.2.5 Comparación entre RED y GRED........................................................................................ 168
5.5.2.6 Utilización del enlace entre Router1 y Router2.................................................................... 168
CAPÍTULO 6: CONCLUSIONES Y LÍNEAS FUTURAS........................................................169
6.1 CONCLUSIONES ......................................................................................................................169
6.2 POSIBLES AMPLIACIONES ......................................................................................................170
BIBLIOGRAFÍA ...........................................................................................................................171
A. PUBLICACIONES CIENTÍFICAS .................................................................................................171
B. PÁGINAS WEB .........................................................................................................................172
GLOSARIO....................................................................................................................................173
ANEXO A. CONTENIDO DEL CD ............................................................................................175
8
Control de Congestión con OPNET
ANEXO B. GUIA PARA INTEGRAR EL ALGORITMO GRED EN OPNET ..................... 177
ANEXO C. ESTRUCTURAS Y VARIABLES IMPORTANTES ............................................ 179
C.1 IQ_QOS_SUPPORT.H .............................................................................................................. 179
C.2. IP_RTE_SUPPORT.H .............................................................................................................. 182
C.3. OMS_QM.H ........................................................................................................................... 184
ANEXO D. PAUTAS PARA LA MODIFICACIÓN DEL FUNCIONAMIENTO DEL
ALGORITMO RED ..................................................................................................................... 189
ANEXO E. HERRAMIENTAS UTILIZADAS.......................................................................... 191
D.1 VISUALC ++......................................................................................................................... 191
D.2 OPNET MODELER ............................................................................................................... 191
D.3 NOTEPAD ++ ........................................................................................................................ 191
9
Indice
10
Control de Congestión con OPNET
Índice de ilustraciones
Ilustración 1. Vista de la sección de clientes de la página de OPNET ............................................. 18
Ilustración 2. Fragmento del árbol de contenidos de la documentación de OPNET utilizada para
éste proyecto ..................................................................................................................................... 20
Ilustración 3. Ejemplo de un caso de congestión.............................................................................. 24
Ilustración 4. Estructura de un segmento TCP ................................................................................. 28
Ilustración 5. Ventana de congestión y cola en TCP ........................................................................ 30
Ilustración 6. Planificación de Colas FIFO...................................................................................... 33
Ilustración 7. Funcionamiento de FQ............................................................................................... 34
Ilustración 8. Comparación entre el tamaño real de cola y el valor que toma Qavg ....................... 37
Ilustración 10. Probabilidad de descarte de RED y de GRED ......................................................... 39
Ilustración 11. Pantalla de inicio del Simulador OPNET................................................................. 41
Ilustración 12. Vista de varios editores en OPNET .......................................................................... 42
Ilustración 13. Interacción de un módulo transmisor con el modelo de nodos y el de red............... 46
Ilustración 14. Jerarquía de procesos en OPNET ............................................................................ 50
Ilustración 15. Memoria padre-hijo en una jerarquía de procesos .................................................. 51
Ilustración 16. Esquema de input streams en un QP. ....................................................................... 53
Ilustración 17. Estadísticas locales en el modelo de proceso ip_output_iface ................................. 54
Ilustración 18. Ejemplo de STD: ip_output_iface............................................................................. 57
Ilustración 19. Flujo de ejecución a través de unforced states......................................................... 59
Ilustración 20. Modelado con forced states ...................................................................................... 60
Ilustración 21. Representación de transiciones en un STD .............................................................. 61
Ilustración 22. Declaración de variables de estado en ip_output_iface........................................... 63
Ilustración 23. Declaración de variables temporales en ip_output_iface ........................................ 64
Ilustración 24. Dos tramos de la lista de ficheros externos en ip_dispatch...................................... 65
Ilustración 25. Acceso a los atributos del modelo de procesos qos_attribute_definer ..................... 66
Ilustración 26. Distribución típica de eventos durante el tiempo de simulación .............................. 69
Ilustración 27. Organización de una lista de eventos durante el tiempo de ejecución ..................... 70
Ilustración 28. Ventana de preferencias en OPNET......................................................................... 75
Ilustración 29. Paleta de objetos ...................................................................................................... 77
Ilustración 30. Nodos en el espacio de trabajo del editor de proyectos ........................................... 78
Ilustración 31. Atributos del nodo Perfiles ....................................................................................... 80
Ilustración 32. Un paso en la configuración de un Cliente .............................................................. 81
Ilustración 33. Tabla para elegir destino de Cliente1 ...................................................................... 82
Ilustración 34. Elección de la disciplina FIFO en las interfaces de los routers conectados............ 83
Ilustración 35. Unión entre routers con las interfaces configuradas ............................................... 84
Ilustración 36. Menú para elegir estadísticas................................................................................... 84
Ilustración 37. Ventana de elección de estadísticas sin desglosar ................................................... 84
11
Indice
Ilustración 38. Parte de la interfaz de visualización de las estadísticas disponibles para la interfaz
IP de “Router1” ................................................................................................................................85
Ilustración 39. Vista de algunas de las operaciones del menú “Scenarios”.....................................86
Ilustración 40. Lista de los escenarios dentro del proyecto CuelloBotella .......................................87
Ilustración 41. Configuración de parámetros del algoritmo RED en el nodo QoS...........................87
Ilustración 42. Configuración de parámetros del algoritmo RED en el nodo QoS...........................89
Ilustración 43. Dos instantes de simulación: antes y después de la simulación................................90
Ilustración 45. Ventana del editor de simulaciones...........................................................................91
Ilustración 46. Ventana de visualización de resultados. ...................................................................92
Ilustración 47. El nodo QoS y su modelo de nodos. ..........................................................................94
Ilustración 48. Acceso al modelo de procesos de attribute_definer ....................................95
Ilustración 49. Atributo recogido por attr_def_fifo_profiles_info_parse..........................................97
Ilustración 50. Parámetros recogidos mediante attr_def_red_parameters_get................................99
Ilustración 51. Ventana Model Attributes del modelo de proceso del nodo QoS ............................101
Ilustración 52. Atributos de FIFO Profiles .....................................................................................102
Ilustración 53. Añadir un nuevo atributo ........................................................................................103
Ilustración 54. Atributos dentro del atributo compuesto RED Parameters.....................................103
Ilustración 55. Symbol map de RED Parameters ............................................................................104
Ilustración 56. Correspondencia con Symbol map..........................................................................105
Ilustración 57. Propiedades del atributo RED Parameters.............................................................105
Ilustración 58. Añadiendo un valor a Symbol Map .........................................................................106
Ilustración 59. Asignación de valor a nuevo símbolo......................................................................106
Ilustración 60. Nuevo fichero de propiedades públicas de un atributo...........................................107
Ilustración 61. Modelo de nodos de Router1, ethernet4_slip8_gtwy_adv.......................................108
Ilustración 62. Modelo padre del módulo ip: ip_dispatch...............................................................109
Ilustración 63. Especificación de ip_dispatch como proceso raíz en el módulo ip .........................109
Ilustración 64. Árbol de atributos IP, Interface Information en un router, recorrido por la función
ip_qos_info_process ........................................................................................................................115
Ilustración 65. Esquema de llamadas desde ip_dispatch ................................................................120
Ilustración 66. Ver los procesos hijos de ip_dispatch .....................................................................121
Ilustración 67. Variables de estado de ip_output_iface ..................................................................122
Ilustración 68. STD del modelo de proceso ip_output_iface...........................................................123
Ilustración 69. Esquema de llamadas desde ip_output_iface..........................................................138
Ilustración 70. Topología CuelloBotella .........................................................................................144
Ilustración 71. Topología CuelloBotella2 .......................................................................................145
Ilustración 72. E1 y E2. Tráfico descartado en la red.....................................................................150
Ilustración 73. E3, E4. Tráfico descartado en la red. .....................................................................151
Ilustración 74. E1, E2. Valores medios del retardo en la red. ........................................................152
Ilustración 75.E3, E4. Valores medios del retardo en la red. .........................................................153
Ilustración 76. E1, E2. Utilización del buffer en Router1. ..............................................................154
Ilustración 77 E3, E4. Utilización del buffer en Router1. ...............................................................155
Ilustración 78. E1, E2. Jitter en Router1, valores medios. ..............................................................156
Ilustración 79.E3, E4. Jitter en Router1, valores medios. ...............................................................157
Ilustración 80. E1, E2. Retardo en Router1, valores medios...........................................................158
Ilustración 81. E3, E4. Retardo en Router1, valores medios...........................................................159
Ilustración 82. E1, E2. Tamaño de cola medio con el algoritmo RED (rojo) y GRED (azul).........160
Ilustración 83. E3, E4. Tamaño de cola medio con el algoritmo RED y GRED. ...........................161
Ilustración 84. E1, E2. Utilización del enlace entre los routers......................................................162
Ilustración 85. E3, E4. Utilización del enlace entre los routers......................................................163
Ilustración 86. Tráfico registrado para CuelloBotella y CuelloBotella2 ........................................165
Ilustración 87. E5, Retardo global para la topología CuelloBotella2 ............................................166
12
Control de Congestión con OPNET
Ilustración 88. E5, Retardo global en la red, valores medios......................................................... 166
Ilustración 89. E5, Utilización del buffer en el Router1. ................................................................ 167
Ilustración 90. E5, Retardo en el Router1, valores medios. ........................................................... 167
Ilustración 91. Tamaño medio de cola de GRED (azul) y RED (rojo) ........................................... 168
Ilustración 92. E5, Utilización del enlace....................................................................................... 168
13
Indice
14
Control de Congestión con OPNET
Capítulo 1. Introducción
1.1 Motivación
Hoy en día, las tecnologías de comunicación y las redes de ordenadores avanzan rápidamente,
incrementándose el número de usuarios, la carga de tráfico y la complejidad total.
Probablemente uno de los mayores problemas con que se enfrenta la ciencia en este campo es el del
rápido crecimiento del volumen de datos (mayor tamaño, con mayor velocidad), y la incapacidad
de aumentar suficientemente la velocidad de procesamiento de esos datos en los routers y demás
nodos intermedios en la red. Esto lleva a situaciones de congestión (llegan más datos de los que el
sistema tiene capacidad de procesar), produciendo una importante pérdida de paquetes y retraso en
la entrega de información y finalmente, deteriorando la calidad de servicio o QoS demandada por el
usuario.
La congestión de redes es un problema inevitable, pero gracias a diversas técnicas se pueden paliar
sus efectos en gran medida. Entre esas técnicas, se encuentran mecanismos de control de flujo
como el que proporcionan las ventanas deslizantes del protocolo TCP, o algoritmos de control de
congestión como son las disciplinas de cola (FIFO, PQ…) y la gestión de colas activa o AQM. La
idea básica de los algoritmos AQM es anticiparse a situaciones de congestión estableciendo reglas
para el descarte controlado de paquetes cuando la situación así lo requiere. Esto permite maximizar
la capacidad del enlace del router, con el fin de obtener una tasa alta de envío de paquetes y
mantener un tiempo de espera en la cola lo más pequeño posible.
Entre los AQM, destaca el algoritmo RED por ser la primera propuesta que surgió y por estar su
uso ampliamente difundido, debido a que la mayor parte de los fabricantes lo han incluido en sus
routers. No obstante, aunque RED evita la congestión, es un algoritmo muy sensible a la
configuración que el usuario da a sus parámetros y al tipo de datos que fluyen por la red, por lo que
no tiene un comportamiento eficaz en todas las ocasiones. Por consiguiente, entender el
comportamiento y ajuste de los parámetros de RED ha demostrado ser un trabajo difícil. Por ello,
con los años el estudio de este tipo de algoritmos ha sido objeto de diversas investigaciones,
obteniendo soluciones que se adaptan mejor a la carga de tráfico de las redes modernas.
Los simuladores de redes son una herramienta idónea para llevar a cabo investigaciones sobre
nuevos métodos de control de congestión, pues proporcionan al investigador un entorno fiable
15
Capítulo1. Introducción
donde reproducir las características reales de una red específica diseñada para tal propósito,
pudiendo configurarla fácilmente según la situación que se quiera analizar.
Otra ventaja de utilizar simuladores de red, además de cómo herramienta de investigación de
protocolos, es que se pueden hacer diversas pruebas sobre el diseño de la futura red sin gasto
económico (sólo cambiando ciertos atributos o componentes dentro de la interfaz ofrecida por el
simulador), de forma que su correcto funcionamiento queda garantizando antes de implementarla
de forma física.
1.1.1 Simuladores de red
Antes de crear una red física real, es conveniente planificar su estructura, protocolos y otros
parámetros, para asegurarse que el diseño sea una solución adecuada a la necesidad que se quiere
satisfacer mediante la red. Construir directamente una red física podría significar una importante
pérdida de dinero y tiempo si una vez puesta en marcha no cumple las condiciones especificadas
inicialmente. De ahí surge la utilidad de usar simuladores de redes.
Un simulador de red es una aplicación que permite al usuario diseñar un sistema de redes de
comunicación a través de una interfaz gráfica en la que puede elegir los distintos componentes que
formarán la red y configurarlos individualmente. El objetivo que busca todo simulador es recrear
un modelo lo más fiable posible a la realidad, al menos en cuanto a las características a estudiar,
para poder extrapolar los resultados obtenidos mediante la simulación.
Los simuladores de redes han madurado desde que aparecieron por primera vez como herramientas
de desarrollo, administración y predicción. Hoy en día se les suele utilizar también para estudios de
calidad de servicio, además de ser de gran aplicación en el ámbito de la ingeniería. Gracias a la
simulación se puede observar la evolución de un sistema de comunicación específico, sus
características, propiedades… utilizando como recurso sólo la memoria de un ordenador.
Existe un número considerable de herramientas de simulación disponibles. Las características
principales que generalmente las describen e influyen a la hora de elegir una u otra son: precisión,
rapidez, facilidad de uso y costo. A continuación se cita alguno de éstos simuladores.
•
Packet Tracer
Es una herramienta de aprendizaje y simulación gratuita desarrollada por la empresa CISCO
Systems con fines académicos. Esta herramienta permite a los usuarios crear topologías de red,
configurar dispositivos, insertar paquetes y simular una red con múltiples representaciones visuales.
Una ventaja que tiene este simulador es que ofrece el análisis de cada proceso que se ejecuta en el
programa de acuerdo a la capa del modelo de referencia OSI que interviene en dicho proceso, por
ello es muy adecuado para el estudio y aprendizaje del funcionamiento y configuración de las redes
de comunicaciones y aplicaciones.
Soporta una gran variedad de switches y routers, así como protocolos del tipo HTTP, DNS, TFTP,
Telnet, OSPF, VTP y STP.
16
Control de Congestión con OPNET
•
AdventNet
La herramienta de simulación AdventNet comprende un simulador de agente y red con una sencilla
interfaz gráfica para el testeo, entrenamiento y demostración de aplicaciones de gestión de redes.
Brinda además el editor de topologías para establecer interconexiones a través de routers, switches
y otros componentes de red y ver la relación topológica entre ellos.
A esto se añade un modelo avanzado de conducta de agentes y redes, generación de trampas,
gestión de desperfectos y configuración de los componentes, siendo este simulador especialmente
eficaz en la simulación de la conducta de redes en escenarios realistas o negativos.
•
Shunra VE Desktop
Es una herramienta de simulación de redes ideal para probar el impacto de una red en el desempeño
de aplicaciones, permitiendo probar éstas bajo una gran variedad de condiciones de red
directamente desde el escritorio del ordenador.
Es una de las aplicaciones de este tipo más fáciles de usar y de integrar con el ambiente de trabajo
existente. Permite configurar los parámetros de red manualmente o simplemente descargar archivos
de escenarios de red predefinidos.
•
NS
ns (más conocido como ns-2 por su versión actual) es una herramienta muy potente dentro del
campo de los simuladores de redes de eventos discretos. Es utilizado principalmente en ambientes
académicos debido a que está escrito en código abierto y a la abundancia de documentación
existente. De hecho, probablemente es el simulador de redes de código abierto más extendido tanto
en investigación como para propósitos docentes. Puede simular una amplia gama de protocolos
tanto para redes cableadas o redes wireless, así como mixtas. Existen en ns-2 diferentes niveles de
configuración, al ser, como se dijo antes, software de tipo open source.
ns-2 fue construido en C++ y proporciona una interfaz de simulación a través de un lenguaje de
script llamado Tcl que permite ir generando el modelo. El usuario describe una topología de red
escribiendo los citados scripts Tcl y a continuación el programa principal de ns simula la topología
con los parámetros especificados.
También proporciona una interfaz gráfica llamada nam que permite visualizar las simulaciones e
incluso crear y editar modelos a simular.
Entre los usos más habituales que se le dan a este simulador son: simular estructuras y protocolos
de redes de todo tipo, desarrollar nuevos algoritmos, comprobar su funcionamiento y comparar
distintos protocolos en cuanto a prestaciones se refiere.
• Por último, en el siguiente apartado se aporta una pequeña introducción a OPNET
Modeler, el simulador utilizado para éste proyecto.
17
Capítulo1. Introducción
1.1.2 Simulador OPNET Modeler
Es un simulador híbrido, basado en simulación de eventos discretos en combinación con un modelo
analítico (uso de modelos matemáticos). Utiliza máquinas de estado finitas para modelar el
comportamiento de sus diferentes componentes. Puede modelar protocolos, componentes y
comportamiento de redes, con alrededor de cuatrocientos modelos de funciones de propósito
específico.
Hay disponibles varios editores durante el diseño de la simulación, cada uno con sus
funcionalidades y su interfaz, siendo los más importantes: proyecto, nodo y proceso, a través de los
cuales se puede modificar la configuración de la red, equipo, protocolos y aplicaciones a diferentes
niveles. Además, si se dispone de la versión adecuada, como ha sido en nuestro caso, se
proporciona acceso al código fuente de las librerías y modelos, siendo esto una gran ventaja a la
hora de desarrollar nuevos protocolos o aplicaciones.
OPNET es utilizado en el ámbito profesional en todo el mundo. Es utilizado por grandes empresas
de telecomunicaciones para desarrollar proyectos de distinta índole. Podríamos citar por ejemplo
empresas como Telefonica International, Motorola Inc., Emirates Airlines, Thales, Ericsson etc.
como se muestra en la siguiente imagen sacada de la página web oficial de OPNET,
http://www.opnet.com
Ilustración 1. Vista de la sección de clientes de la página de OPNET
Aparte de sus aplicaciones comerciales, es destacable remarcar que mientras se ha realizado este
proyecto, se ha observado que hay un gran número de universidades españolas (por ejemplo la
Universidad Politécnica de Cataluña, Universidad de Oviedo, Universidad Politécnica de Madrid,
Universidad Politécnica de Valencia, Universidad de Alicante) que usan este programa como
herramienta de docencia, por la facilidad con la que se puede mostrar a los estudiantes el
comportamiento de una red gracias al realismo de los resultados obtenidos en sus simulaciones.
18
Control de Congestión con OPNET
1.2 Objetivo del proyecto
Uno de los puntos principales de este proyecto es estudiar el funcionamiento y la técnica de
modelado utilizada por el simulador OPNET, centrándose en concreto en cómo se trata la
implementación del algoritmo RED con vista a extender la funcionalidad del simulador. Mediante
este trabajo se trata, por tanto, de aportar a futuros usuarios ideas que sirvan como punto de inicio o
referencia para la extensión del programa si se quieren añadir algoritmos de gestión activa de colas.
El estudio del programa se hará primero desde el punto de vista teórico y general, describiendo
cómo funcionan sus diferentes niveles de implementación, y después mediante un desarrollo
detallado de cómo y dónde se pueden hacer modificaciones en el código para añadir algoritmos de
gestión activa de colas.
También se mostrará cómo se ha añadido el algoritmo GRED al simulador, qué ficheros se han
modificado y cómo se ha configurado una nueva interfaz de atributos para que dicho algoritmo sea
accesible al usuario.
Para complementar todo lo anterior, se realizan al final varios experimentos para estudiar el
comportamiento de distintos AQM presentes en las librerías de modelos de OPNET: Drop Tail,
RED y la extensión de éste último que hemos implementado, Gentle-RED.
1.3 Recopilación de información
El principal problema con el que nos hemos encontrado a la hora de realizar éste proyecto ha sido
comprender de manera más específica e interna la herramienta OPNET ya que, a pesar de la gran
cantidad de prácticas y tutoriales que hay por la red, y referencias al programa, en realidad todos se
centran en aspectos muy básicos de OPNET, sin meterse en temas más complejos como son la
implementación del comportamiento de los modelos de nodos, los modelos de procesos, los tipos
de datos, o el funcionamiento interno del programa. Esto se traduce en que cuando se quiere hacer
algo más complejo, como implementar redes con parámetros y componentes más específicos, o
incluso extender la funcionalidad, añadiendo nuevos protocolos o algoritmos, el usuario se
encuentra con que la información que hay es muy escasa e insuficiente.
No queda entonces más remedio que explorar todo el sistema de librerías (incluyendo los modelos
de proceso del programa, ficheros de cabeceras y ficheros externos) que proporciona el programa
para comprender exactamente dónde y cómo extender la funcionalidad.
Una ayuda valiosa han sido los artículos científicos sobre el tema, en su mayoría estudios
realizados por colectivos de profesores y alumnos de universidades, que aunque poco extensos, han
servido como guía para recortar los posibles caminos que iban surgiendo. El problema es que
muchos de estos artículos son relativamente modernos (puesto que la propia herramienta OPNET lo
es), por lo que es difícil disponer de ellos gratuitamente. Todos los artículos o estudios científicos
sobre OPNET citados en la bibliografía han sido obtenidos de páginas y enlaces gratuitos, siendo
de dominio público.
19
Capítulo1. Introducción
Otra valiosa referencia, para entender en sí el funcionamiento de OPNET, ha sido la
documentación accesible desde los editores del propio programa, en el menú Help › Product
Documentation. Una vez en la ventana de la documentación, a la izquierda se encuentra el árbol
de contenidos, o si se prefiere, se puede acceder a los contenidos mediante un índice o un buscador.
Los apartados de la ayuda más utilizados, y de los que se ha sacado parte de la información y
gráficos del Capítulo 3 de esta memoria son los contenidos dentro de Modeler Reference, como se
muestra en la siguiente figura
Ilustración 2. Fragmento del árbol de contenidos de la documentación de OPNET utilizada para éste proyecto
Otro apartado valioso dentro de la ayuda de OPNET, sobre todo a la hora de entender el código
fuente en el que están implementados los modelos, ha sido Programmers Reference › Discrete
Event Simulation, en el que se describen todos los procedimientos o Kernel Procedures (KP) que
proporciona el Simulation Kernel, ordenados por paquetes, y que forman parte del lenguaje de
programación Proto-C.
1.4 Estructura de la memoria
Esta memoria está estructurada en los 6 capítulos descritos a continuación:
Capítulo 1. Introducción
En este capítulo se especifica el marco de realización y la motivación del proyecto, incluyendo
introducción, objetivo y búsqueda de información.
20
Control de Congestión con OPNET
Capítulo 2. Conceptos Teóricos
En este capítulo se explica contenido teórico relacionado con las redes de ordenadores, necesario
para entender claramente el funcionamiento de los algoritmos de gestión activa de colas,
específicamente el algoritmo RED.
Capítulo 3. Introducción Teórica al simulador OPNET
En este capítulo se describirán aspectos teóricos necesarios para entender el comportamiento de
OPNET, como son los distintos entornos de modelado o los fundamentos de la simulación por
eventos. Los conceptos se irán enlazando con los casos particulares de estudio en éste proyecto,
para ir centrando en todo momento el ámbito del mismo.
Capítulo 4. Modelado de AQM en el OPNET
En este capítulo se explica paso a paso el modelado de una red, empezando por la creación de una
topología, configuración de sus parámetros, estudio del modelo de nodos tanto del nodo de
configuración de QoS como del router, terminando con el estudio de tres modelos de proceso y los
ficheros externos con los que están relacionados. En todo momento nos centraremos en los
componentes que forman parte de la implementación del AQM RED en OPNET.
Capítulo 5. Experimentos
En este capítulo se muestran los experimentos realizados junto con las gráficas que muestran los
resultados obtenidos.
Capítulo 6. Conclusiones y líneas futuras
En este capítulo se exponen las conclusiones obtenidas tras la realización de este proyecto y se
proponen algunas ideas para continuar con futuras líneas de investigación.
Por último, se incluye la bibliografía utilizada como referencia en este proyecto, y un glosario de
términos básicos.
Además de lo anterior, se incluyen cinco Anexos:
• Contenido del CD
• Guía para la utilización de los archivos del CD
• Estructuras de datos importantes en OPNET
• Pautas para la modificación del algoritmos RED
• Herramientas utilizadas
21
Capítulo1. Introducción
22
Control de Congestión con OPNET
Capítulo 2. Conceptos Teóricos
2.1 Introducción
En este bloque se irán explicando desde las ideas más generales de la congestión de redes, hasta los
mecanismos específicos para prevenirla, o solucionar la situación una vez se ha llegado a ella. Así,
será necesario hablar de términos como los protocolos extremo-a-extremo, Calidad de Servicio o la
labor de los routers dentro de una red, terminando por hablar de los Algoritmos de Gestión Activa
de Colas, donde nos centraremos en especial en RED y alguna de sus variantes.
2.1.1 Situación de las redes actuales
Las redes de ordenadores han crecido vertiginosamente desde sus orígenes tanto en número de
usuarios como en prestaciones y servicios ofrecidos. Internet se apoya en el protocolo IP. Éste
protocolo es muy simple, se basa en permitir que los paquetes de datos (datagramas) atraviesen
routers desde un nodo fuente a uno destino sin la ayuda del emisor ni del receptor. Gracias a la
simplicidad que aporta IP a las redes de ordenadores, el tráfico de datos no sólo se ha incrementado
(debido al creciente número de usuarios), sino también ha cambiado su naturaleza, apareciendo
nuevas aplicaciones que imponen nuevos requisitos en el servicio.
El buen funcionamiento de las aplicaciones se puede ver afectado al no poder garantizar los
servicios solicitados, su deterioro puede causar problemas significativos a los usuarios, lo que se
materializa en una pobre calidad de servicio.
La calidad de servicio (QoS, Quality of Service) es un concepto multidimensional que se
caracteriza por el retardo extremo-a-extremo introducido, su fluctuación (o jitter), por la pérdida de
paquetes y por su disponibilidad. El servicio que ofrece el protocolo IP, no orientado a conexión y
best effort, no siempre satisface la calidad de servicio demandada por todas las aplicaciones,
especialmente por aquellas con requerimientos de tiempo real.
Los recursos disponibles (ancho de banda y capacidad de almacenamiento en routers) son siempre
limitados, mientras que la demanda continúa creciendo. Así, en ciertas condiciones de pico, nada
impide que localmente la entrada de datos sea superior a la disponibilidad. Para paliar estos
problemas, desde sus inicios, se incorporaron medidas para el control de congestión. Entre ellas, los
23
Capítulo 2. Conceptos Teóricos
mecanismos de gestión activa de colas (AQM, Active Queue Management). Estos mecanismos
consisten en la detección temprana de la congestión reaccionando en base a criterios
probabilísticos.
La mayoría de las aplicaciones de Internet sin requisitos de tiempo real utilizan el protocolo TCP
para recuperar los paquetes perdidos en situaciones de congestión, así como para adoptar medidas
reactivas regulando el volumen de tráfico generado. La severidad del problema de la congestión
crece en magnitud al crecer el volumen de las demandas de tráfico.
Con el protocolo IP y best effort, el intento de entrega al nodo destino puede converger desde uno
hasta miles de flujos de paquetes. Si la razón de llegadas de tráfico en un router es superior a la
razón de salidas (impuesta por el ancho de banda disponible en el correspondiente enlace), los
paquetes recibidos son almacenados en la cola de salida. Dichos paquetes en la memoria de la
interfaz de salida (de naturaleza FIFO) serán posteriormente reenviados a su IP destino
correspondiente de acuerdo con la tabla de encaminamiento.
Una vez que un determinado router sufre congestión, la calidad del servicio de transporte se
deteriora, aunque exista exceso de ancho de banda en todo el resto de la ruta.
La técnica tradicional para controlar el tamaño de las colas en routers denominada Drop tail, se ha
ido sustituyendo por la gestión Activa de Colas, que proporciona un mejor rendimiento en la red en
términos de utilización de las líneas, probabilidad de pérdida de paquetes y retardo extremo a
extremo.
El control de congestión
El control de congestión es el esfuerzo hecho por los nodos de la red para prevenir o responder
a sobrecargas de la red que desembocan en congestión y, por tanto, conducen a perdidas de
paquetes y deterioro de la Calidad de Servicio. Durante los siguientes apartados se hablará
sobre los mecanismos que contribuyen a ésta tarea y su entorno de aplicación.
Ilustración 3. Ejemplo de un caso de congestión.
24
Control de Congestión con OPNET
2.2 Calidad de Servicio
2.2.1 Introducción
Calidad de Servicio es un concepto que caracteriza las prestaciones y el funcionamiento de una
comunicación extremo-a-extremo entre dos puntos finales de una red. Otra forma de explicar este
concepto sería como la habilidad de un elemento de red (aplicación, host o router) de ofrecer cierto
nivel de garantía para que los requisitos del servicio sean satisfechos.
En Internet la tecnología dominante proporciona el servicio denominado best effort. Por lo general,
cada vez que se requiere información en la red, ésta tiene que transmitirse a través de varias redes,
por tanto, la calidad de servicio extremo-a-extremo depende principalmente de las características de
QoS de los enlaces y routers por los que tiene que atravesar a su paso. En consecuencia, varias
herramientas son imprescindibles para conseguir la QoS necesaria según el tipo de aplicación y
usuario.
Para sustentar la QoS extremo-a-extremo es importante conocer más acerca del comportamiento
dinámico de las redes. Esto es posible lograrlo mediante algunos parámetros que pueden ser
medidos y monitoreados en la red. Entre los parámetros más importantes se encuentran: el ancho de
banda, el retardo, el jitter y la probabilidad de pérdida de paquetes.
Además del popular best effort se han propuesto otros mecanismos, que satisfacen mejor las
demandas de nuevas aplicaciones: Servicios Integrados y Servicios Diferenciados.
La implementación de QoS puede estar formada por uno de los mecanismos nombrados, o una
combinación de los tres. Sin embargo estos mecanismos no son independientes: necesitan cooperar
con otros mecanismos menos complejos, como son protocolos extremo-a-extremo y el
procesamiento en los routers intermedios, los cuales se discutirán en secciones posteriores.
2.2.2 Mecanismos de QoS
2.2.2.1 Servicio Best Effort
Este servicio no aporta ninguna característica QoS. De hecho, no garantiza cuándo ni cómo se
entregarán los datos. Las redes IP tradicionales usan este servicio por ser conveniente para
aplicaciones sin restricciones de tiempo, o de baja prioridad como son FTP y SMTP.
2.2.2.2 Servicios Integrados (IntServ)
Definen un modelo que se basa en garantizar QoS a las aplicaciones a través de reservar
recursos extremo-a-extremo de la red para cada flujo antes de ser transmitido. Esta reserva se
25
Capítulo 2. Conceptos Teóricos
realiza a través de RSVP, que trabaja en paralelo con TCP o UDP. Las aplicaciones solicitan el
nivel de servicio necesario para poder trabajar apropiadamente y las reservas son mantenidas
hasta que la aplicación termina o mientras cumpla con las demandas solicitadas. Dentro de este
modelo se definen dos clases de servicios: servicios de carga controlada y servicios
garantizados.
- Servicios de Carga Controlada: Proporcionan al flujo de datos una calidad de servicio lo
más cercana posible a la calidad que el mismo flujo recibiría en una red best effort sin
cargas. Para ello se utiliza un procedimiento de control de admisión en cada nodo para
asegurarse que hay recursos para el flujo y supervisión a pesar de haber sobrecarga. Está
especialmente indicado para implementaciones altamente simples que no tengan
demandas precisas de QoS, y no proporciona ninguna garantía cuantitativa respecto a
retardo y ancho de banda.
- Servicios Garantizados: Este tipo de reserva proporciona un retardo controlado extremoa-extremo de la red y garantiza un ancho de banda para el tráfico conformado con las
especificaciones prefijadas. Para ello se necesita conocer las especificaciones del tráfico y
las especificaciones de requerimiento de servicio como el ancho de banda y el retardo
solicitado. Este servicio está sujeto a un procedimiento de control de admisión en cada
nodo.
Ésta arquitectura, si bien garantiza QoS, no es lo suficientemente escalable debido a que el
tratamiento por flujos puede dificultar su despliegue en escenarios de grandes demandas. Es
muy costoso mantener en cada nodo una tabla de estados y reservas por cada flujo para el
control de admisión. Esto conduce a un considerable tráfico de señalización (por el protocolo
RSVP) a lo largo del camino, y ocupación de recursos en cada router.
2.2.2.3 Servicios Diferenciados (DiffServ)
Para solucionar el problema de escalabilidad de IntServ se desarrolla la arquitectura de
servicios diferenciados o DiffServ. En contraste a la orientación por flujo de RSVP, este
modelo se basa en considerar el tráfico en diferentes clases de servicios (Class of Service,
CoS), controlar la cantidad de tráfico de cada clase que un cliente envía a la red y asegurar los
requerimientos de QoS de varios tipos de aplicaciones utilizando mecanismos de colas en cada
nodo con políticas claramente definidas (y dependientes del contrato o compromiso adquirido
con el usuario) de scheduling y dropping.
El modelo de servicios diferenciados no utiliza la comunicación extremo-a-extremo para la
reserva de recursos como lo hace IntServ. Este modelo se aplica a una región de la red y usa un
criterio de clasificación agregado basado en reglas predefinidas para agrupar a los paquetes en
clases. Para aplicar los parámetros de QoS a las clases, los paquetes son clasificados con algún
criterio, marcándolos usando la clave de servicios diferenciados (DSCP, Differentiated
Services Code Point), utilizando para ello el campo tipo de servicio (Type of Service, ToS),
establecido en la cabecera del paquete IP.
El término PHB (Per-Hop Behavior) describe en este modelo el tratamiento específico de
envío que recibirá un paquete en el interior de la red después de ser clasificado en una clase
dada. Este tratamiento proporciona al paquete un apropiado retardo, ancho de banda jitter, etc.
26
Control de Congestión con OPNET
de tal manera que todos aquellos paquetes que contengan igual DSCP recibirán idéntico
tratamiento durante su envío.
Esta arquitectura logra dar servicios diferenciados a tráfico agregado, es decir, se proporciona
un tratamiento por clase, no por flujos; sin embargo se requiere la consideración de
mecanismos complicados para negociar los acuerdos del nivel de servicio. Todo ello, además
de requerir supervisión de tráfico, clasificación, conformación, marcado y, posiblemente,
descarte de paquetes.
2.2.3 Elementos que deterioran la QoS percibida por el
usuario
2.2.3.1 Retardo extremo-a-extremo
Dividido en los siguientes:
- Retardo de propagación: Ésta es una fuente de retardo ineludible y se define como el tiempo
que se produce durante la transmisión de los datos desde su origen hasta su destino final,
directamente relacionada con la velocidad de la luz. Por lo tanto, es función de la distancia que
tiene que recorrer. El retardo total de la propagación vendrá dado por Retardo total =
distancia/velocidad de la luz.
- Retardo de procesamiento: Este retardo es consecuencia de los sucesivos procesos que tiene
que pasar el paquete durante su trayecto desde el envío hasta que es recibido por el usuario
final. Estos procesos son codificación y empaquetado, que se llevan a cabo en el emisor, y
decodificación y desempaquetado que se realizan en el receptor. Por otra parte existen otros
factores que contribuyen a este retardo, como pueden ser el retardo de encolamiento y el de
conmutación introducidos por los routers como resultado de la clasificación, almacenamiento
temporal (colas de entrada y salida) y conmutación.
- Retardo de transmisión: Es el tiempo que se tarda en transmitir un paquete. Este retardo está
en función de la velocidad de la línea de transmisión y la longitud del paquete.
Sumado a todos los retrasos especificados, el retardo extremo-a-extremo se ve afectado
además por otro factor: fluctuación o jitter. El transmisor envía cada paquete de una aplicación
a un mismo ritmo de salida pero la red (debido a la naturaleza de encolado de los routers IP)
puede provocar que el ritmo de llegada en el receptor no sea constante (fluctuaciones en los
retardos). La medida de la variación del retardo al llegar al receptor entre paquetes
consecutivos de un flujo transmitido se denomina jitter.
2.2.3.2 Pérdida de paquetes y corrupción de datos
Cuanto mayor sea el número de paquetes consecutivos (o longitud de la ráfaga) que se pierdan
o se dañen, mayor será la degradación de la calidad suscitada. Las pérdidas de paquetes pueden
27
Capítulo 2. Conceptos Teóricos
ocurrir por el descarte generado en una situación de congestión en un router intermedio o
como consecuencia de errores provocados por el medio físico de transmisión.
2.3 Protocolos Extremo a Extremo
2.3.1 Protocolos de Transporte TCP y UDP
En la arquitectura de Internet sobre el protocolo IP, entre las aplicaciones y el nivel de red se
prevén dos protocolos de transporte: TCP (Transmission Control Protocol) y UDP (User Datagram
Protocol), ambos operando extremo-a-extremo, es decir, involucrando a sistemas finales.
TCP es el protocolo de transporte predominante en Internet que acarrea la mayor parte del volumen
total del tráfico. Este protocolo orientado a conexión es utilizado por un rango de diferentes
aplicaciones como son HTTP/HTTPS (WWW), FTP (transferencia de archivos) y
SMTP/POP3/IMAP (correo electrónico) entre otras.
Ilustración 4. Estructura de un segmento TCP
Una serie de mecanismos claves determinan la fiabilidad y robustez del protocolo TCP. Los
segmentos TCP son transportados en paquetes IP y con el fin de asegurar la entrega de cada
segmento, cada paquete contiene 16 bits de datos de información del contenido de la cabecera y del
segmento TCP, con los cuales el receptor puede verificar si el dato recibido es correcto o no.
Además, los segmentos pueden perderse como consecuencia de errores o por la congestión en la
red. Si el paquete es recibido con éxito el receptor envía un paquete de confirmación (segmento con
el bit ACK activado) a la fuente. En caso de recibir un dato defectuoso, será descartado por el
receptor. Para compensar errores, paquetes perdidos o retrasos, la fuente retransmite cada paquete
que no ha sido confirmado después de un tiempo apropiado (se cumple un time-out o expiración de
temporizadores).
28
Control de Congestión con OPNET
Alternativamente a TCP, otro protocolo de transporte utilizado en Internet es UDP. Éste está
especialmente indicado para las aplicaciones multimedia (audio y vídeo), las cuales prefieren pocos
retardos, aún asumiendo que la capa de transporte no proporcione fiabilidad ninguna. Es decir,
UDP no ofrece control de congestión ni de errores, lo cual puede ser indicado para aplicaciones
sencillas que no pueden implementar toda la complejidad que implica el protocolo TCP. Al ser
enviados de esta manera, los segmentos UDP no tienen garantía alguna de fiabilidad en la entrega,
por lo que no van protegidos frente a las pérdidas en la red durante la congestión. Esto se puede
traducir en una posible degradación de la calidad.
2.3.2 Control de congestión en TCP
A diferencia de UDP, el protocolo TCP garantiza la transmisión fiable de los paquetes. Para ello,
además de mecanismos que proporcionan control de errores, incorpora mecanismos para el control
de congestión con el propósito de lograr que TCP reaccione rápidamente en condiciones de alta
congestión, lo cual lo convierte en un importante mecanismo a tener en cuenta también a la hora de
proveer QoS. Si una fuente de información TCP detecta que en la transmisión de sus paquetes
empieza a haber problemas, (es decir, detecta pérdidas mediante la expiración de los
temporizadores arbitrados para la recepción de las correspondientes confirmaciones), asume que
dichas pérdidas son siempre debidas a problemas de congestión. Como medida reactiva, en ese
caso TCP reduce drásticamente la tasa de transferencia con la esperanza de reducir el número de
paquetes perdidos o descartados.
2.3.2.1 Arranque lento y prevención de la congestión
Arranque lento (slow start) y prevención de la congestión (congestión avoidance) son dos de los
algoritmos incorporados a TCP utilizados para controlar la tasa de transferencia de paquetes
generados, monitorizando permenantemente las prestaciones de la red y determinando la capacidad
disponible, para así evitar la congestión incluso cuando se generen grandes ráfagas de paquetes.
Estos mecanismos de control tienen objetivos diferentes pero son implementados en conjunto. Para
su operación requieren la definición de dos variables por cada conexión TCP: la ventana de
congestión cwnd, que determina la cantidad de bytes que el remitente puede transmitir sin
necesidad de ser confirmados, y la ventana de recepción, rwnd que especifica el número de bytes
que el receptor tiene capacidad para recibir.
Para una conexión dada, la cantidad máxima a transmitir estará acotada por el valor mínimo de
cwnd y rwnd. Al establecerse la conexión TCP, el transmisor asigna a cwnd el tamaño máximo de
segmento para la conexión y por lo tanto envía un paquete con ese tamaño. Al mismo tiempo,
mantiene un temporizador de retransmisión que se activa al enviar cada segmento.
El algoritmo Slow Start es implementado de la siguiente forma: un segmento es enviado si un ACK
es recibido (antes de la expiración del temporizador), el valor de cwnd es incrementado en un
segmento. Por lo que ahora, dos segmentos pueden ser enviados y causar dos ACKs. Por cada uno
de esos ACKs, cwnd es incrementada en un segmento, de ahí que ahora permite que cuatro
segmentos sean enviados. Este proceso de crecimiento exponencial de la ventana de congestión
permanece con ese ritmo de crecimiento hasta que ocurre una de las dos posibles alternativas: se
alcance el valor acotado de rwnd o se alcance un umbral establecido de antemano denominado
ssthresh.
29
Capítulo 2. Conceptos Teóricos
Cuando la ventana alcanza el valor ssthresh, TCP pasa a la fase de Prevención de la Congestión,
donde en lugar de incrementar cwnd en un segmento adicional por cada ACK recibido, ahora la
ventana será incrementada en un segmento por cada RTT. Se está en fase de Prevención de la
Congestión hasta que se detecta la pérdida de paquetes (se asume por expiración del temporizador)
y es entonces cuando la fuente TCP regresa a la fase de arranque lento, estableciendo cwnd a un
segmento y ssthresh a la mitad del tamaño actual de la ventana. En definitiva, lo que se pretende
con el arranque lento y la prevención de la congestión es incrementar la tasa de generación de
tráfico, mientras no haya problemas y la capacidad de salida lo permita.
Ilustración 5. Ventana de congestión y cola en TCP
2.3.2.2 Retransmisión Rápida y Recuperación Rápida
Además de los anteriores, en TCP se añaden los algoritmos denominados Fast Retransmit y Fast
Recovery para detectar y reparar paquetes perdidos. TCP adopta estos algoritmos de control cuando
se reciben consecutivamente tres segmentos con el bit ACK activado, que pueden ser provocados
por diversos problemas en la red, como la congestión.
Tras esta eventualidad, TCP infiere que ha habido una pérdida y reacciona (entra en fase de
retransmisión rápida) transmitiendo nuevamente el que parece ser el segmento perdido, sin esperar
a que el correspondiente temporizador de transmisión expire. Tras realizar el procedimiento
Retransmisión Rápida, la entidad TCP emisora entra en la fase denominada Recuperación Rápida,
que es ahora quien controla la retransmisión de nuevos segmentos hasta que llega un ACK que no
sea duplicado. Durante éste intervalo, por cada paquete ACK duplicado, (DupAck) que llegue al
emisor, la ventana cwnd es incrementada en un segmento. En el instante en que TCP detecta la
llegada de un nuevo ACK, asume que la transferencia de paquetes ya es normal, y establece cwnd
al umbral establecido al inicio de la transmisión. En caso de que nunca llegue un nuevo ACK, el
emisor permanecerá en la fase de recuperación rápida hasta que ocurra la expiración de un
30
Control de Congestión con OPNET
temporizador. Estos algoritmos permiten la recuperación rápida de paquetes que se han perdido
esporádicamente, sin embargo suele haber problemas para recuperar cuando múltiples paquetes son
descartados.
2.3.2.3 Versiones de TCP
•
Tahoe
Usa los algoritmos Slow Start y Congestion Avoidance para detectar estado de la red y el
control de flujo para disminuir la pérdida de segmentos. Se incluye Fast Retransmit para poder
hacer la retransmisión de segmentos perdidos lo más rápidamente posible sin esperar a que
expire el time-out.
•
Reno
La ventana de congestión crece según Slow Start hasta llegar a un umbral previamente
definido a partir del cual comienza fase de prevención de la congestión creciendo la ventana de
forma lineal. Es Tahoe con Fast Recovery que evita, en lo posible, que el tamaño de la ventana
llegue a dos y se inicie la fase Slow Start en redes que presentan una determinada congestión
con picos de gran congestión. El inconveniente más destacado es que, en caso de tener
múltiples pérdidas por ventana, el protocolo de Rapid Retransmit no puede recuperar de forma
rápida más que la primera pérdida.
•
New Reno
Intenta solventar los inconvenientes de Slow Start y Congestion Avoidance en relación al
tamaño del ssthresh. Intenta buscar un valor de umbral inicial óptimo para el estado de la red
mediante el algoritmo Packet-Pair. La fuente envía series de dos paquetes conociendo el
intervalo de tiempo entre ambos. Según llegan los ACK se va conociendo el retardo y por tanto
el estado de la red, la situación de congestión, etc. También propone una modificación del
algoritmo Fast Recovery de forma que en caso de existir varias pérdidas por ventana se
soluciona el problema de TCP Reno.
•
Vegas
Modifica algunos aspectos de los algoritmos de Fast Recovery y Fast Retransmit, así y como
del de Slow Start. Como aspecto más relevante, no obstante, es la propuesta a actuar contra la
congestión antes de que ésta se detecte por la expiración del temporizador de retransmisión.
TCP Vegas introduce un algoritmo para la predicción de la cantidad de datos que el enlace
puede cursar sin congestión, e inyecta en el enlace dicha cantidad. Esta predicción se basa en
medidas de caudal.
31
Capítulo 2. Conceptos Teóricos
2.4 QoS dentro de los Routers
Los mecanismos de control de congestión incorporados a TCP funcionan en los extremos finales y
pueden llegar a ser insuficientes para proporcionar un buen servicio en todo tipo de circunstancias.
De forma complementaria, en los puntos intermedios de la red o routers, pueden ser incorporados
mecanismos de prevención de la congestión.
La tarea principal de un router es interconectar redes y encaminar paquetes entre ellas. Cuando un
transmisor envía un paquete IP a un destino situado en una red remota, éste siempre pasará al
menos por un router o nodo intermedio antes de llegar al receptor. En orden de proporcionar
cualquier clase de servicio a los paquetes, éstos deben ser primeramente clasificados. Después,
dependiendo de varios parámetros, el router debe tomar la decisión de si los paquetes deben
enviarse, almacenarse en colas, descartarse o marcarse, y de qué manera debe hacerse para evitar
excesivos descartes y en definitiva, pérdidas de paquetes. Los routers que soportan QoS tienen las
funciones definidas en los siguientes apartados
2.4.1 Clasificación
La clasificación de paquetes se puede hacer basándose sólo en el campo ToS de la cabecera de un
paquete IP ó en campos adicionales como la dirección IP y el número de puerto de la fuente y
destino o en el tipo de aplicación. La clasificación es útil para determinar la interfaz de salida de los
paquetes entrantes, además del búfer particular necesario para el almacenamiento, o la reserva de
un ancho de banda de salida.
2.4.2 Gestión de colas
Sólo el control de flujo y congestión extremo-a-extremo TCP, como se ha dicho, no es suficiente,.
Puede ser que la congestión ocurra también cuando la magnitud del tráfico excede la capacidad de
transmisión y procesamiento de los nodos intermedios. Los buffers son usados para absorber éste
exceso de tráfico. Sin embargo, por razones de espacio (el tamaño de un búfer es limitado), los
routers tienen que marcar o descartar el exceso de tráfico para que así TCP detecte congestión y
reduzca su tasa de transmisión. Los routers no pueden dejar todo el control de congestión a TCP,
pues sin los algoritmos de gestión de colas, al producir descarte de paquetes, se incrementaría la
tasa de retransmisión por parte de TCP, incrementando aún más la congestión.
Los algoritmos de gestión de cola se dividen en dos categorías:
32
•
Gestión Pasiva de Colas (PQM, Passive Queue Management), descartan paquetes sólo
cuando la cola alcanza su capacidad, o algún valor específico. Dentro de éste tipo está el
tradicional Drop Tail.
•
Gestión Activa de Colas (AQM, Active Queue Management), descartan paquetes
preventivamente antes de que la cola alcance su capacidad máxima. Este tipo de
algoritmos se explicarán con mayor detalle en la próxima sección.
Control de Congestión con OPNET
2.4.3 Planificación de colas
Las disciplinas gestión y planificación de colas trabajan conjuntamente para controlar el tráfico de
la red a nivel de router. Se ha explicado que la gestión de colas intenta evitar la congestión
descartando los paquetes apropiados. Sin embargo, si los paquetes están esperando mucho tiempo
para su transmisión, y llegan a mayor ritmo del que son enviados, entonces aumenta el retraso en la
cola (queuing delay), provocando congestión. Para evitar esta situación, los algoritmos de
planificación de colas trabajan seleccionando el siguiente paquete a ser transmitido de entre todos
los paquetes que están esperando.
Existen varios mecanismos de planificación, entre ellos se ha considerado oportuno citar los
siguientes:
2.4.3.1 FIFO (First In First Out)
Es la disciplina de planificación por defecto, y la más utilizada. Los paquetes se envían en el
mismo orden en que van llegando al buffer. La ventaja de éste esquema es su simplicidad a la
hora de implementarlo y la posibilidad de predecir el máximo valor de queuing delay a partir
de la capacidad del buffer. De ahí se deduce que el retraso será pequeño si la cola tiene poca
capacidad, y aumentará si el tamaño de ésta se hace mayor. FIFO trata de igual
manera a las diferentes clases de tráfico, y a los distintos flujos.
Ilustración 6. Planificación de Colas FIFO
2.4.3.2 Colas de prioridad ( PQ, Priority Queueing)
Se clasifica el tráfico en diferentes clases. Cada clase es asociada a una cola particular
dependiendo de su prioridad. Cada cola individualmente se comporta de acuerdo al algoritmo
FIFO. Se envía un paquete sólo si no hay paquetes en colas con prioridades superiores.
Es un esquema útil en situaciones en que se produce tráfico de alta prioridad, como ocurre en
casos de aplicaciones de tiempo real o VoIP. Sin embargo, si la proporción de éste tipo de
tráfico es muy grande, el tráfico con menor prioridad puede sufrir demasiado retardo, al igual
que una alta tasa de pérdida de paquetes, desembocando en una situación de inanición.
33
Capítulo 2. Conceptos Teóricos
Incluso en caso de tráfico de alta prioridad compartiendo la misma cola de prioridad, un flujo
de tráfico con una tasa muy alta puede deteriorar la QoS, ya que puede provocar un alto retraso
y jitter en esa cola.
2.4.3.3 FQ (Fair Queueing)
Es una disciplina de colas basada en flujo, diseñada para obtener un reparto equitativo de los
recursos de la red y prevenir que haya flujos dominantes que se apropien de todo el ancho de
banda. A cada paquete que llega se le clasifica dentro de una clase acorde con el flujo de
tráfico al que pertenece, y se asigna a una cola dedicada a ese flujo. Se va eligiendo el paquete
situado en la cabeza de cada cola según el algoritmo Round Robin.
Ilustración 7. Funcionamiento de FQ
La ventaja de este algoritmo es que da la misma oportunidad de transmitir a todos los flujos,
independientemente si hay algunos más dominantes que otros, solucionando el problema que
tenía PQ. Una desventaja es que no se pueden satisfacer los requisitos de ancho de banda de
los diferentes flujos. De hecho, FQ debe reservar el mismo ancho de banda para cada uno de
ellos. Sin embargo, el ancho de banda recibido por cada flujo depende del tamaño de los
paquetes, y paquetes mayores necesitarían más ancho de banda.
2.4.3.4 WFQ (Weighted Fair Queueing)
Ésta disciplina fue diseñada para mejorar FQ, especialmente ofreciendo diferenciación de
servicio en términos de ancho de banda, satisfaciendo las demandas de las diferentes
aplicaciones. WFQ reparte los recursos de la red entre los distintos flujos basándose en sus
necesidades de ancho de banda, dando preferencia a los que menos consumen para reducir el
retraso en el buffer, y repartiendo equitativamente el resto de ancho de banda entre los demás.
34
Control de Congestión con OPNET
2.5 Gestión Activa de Colas
Este capítulo intenta proporcionar una visión general de cómo trabajan los algoritmos de gestión
activa de colas, centrándonos después en el algoritmo RED, por ser uno de los puntos centrales de
estudio de éste proyecto en cuanto al análisis de OPNET se refiere, y por ser considerado en
muchas publicaciones como punto de partida o esquema de referencia para posteriores algoritmos
de gestión activa de colas. Por último, se describirá otro algoritmo basado en RED con el que se ha
trabajado en este proyecto.
2.5.1 Introducción y fundamentos de los AQM
La Gestión Activa de Colas es una clase de algoritmos que intentan prevenir la congestión
descartando paquetes o marcando paquetes en el router comprometido. Estos utilizan una
aproximación probabilística para reaccionar a las condiciones de congestión.
Por lo general, para amortiguar las diferencias entre la razón de llegadas y la de salidas, las
interfaces de salida de los routers disponen de un buffer o memoria temporal donde los paquetes
serán almacenados para ser enviados posteriormente. Esta cola puede estar constituida por paquetes
de distintos tipos de flujos, los cuales pueden haber seguido rutas diferentes. En situaciones de
congestión, es decir, cuando la cola se llena, si el router sigue una estrategia no diferenciada, los
paquetes son descartados o marcados sin importar a qué tipo de flujo pertenecen.
Tradicionalmente, la técnica de gestión de colas más habitual utilizada en los routers de Internet es
el drop tail. En los routers que adoptan esta técnica, los paquetes que van llegando son
temporalmente aceptados y almacenados hasta que un determinado tamaño máximo de la cola,
especificado en número de paquetes, sea alcanzado. Cuando la cola se llena, los siguientes
paquetes que llegan serán descartados mientras que la ocupación de la cola no decrezca. Drop tail,
si así lo permite el tráfico de llegada, tiende a mantener la cola al máximo nivel de ocupación
durante largos períodos de tiempo, ya que el descarte se inicia cuando la cola esté llena. No
obstante, como desventaja, puede que el descarte se inicie demasiado tarde, implicando una merma
significativa en las prestaciones.
Con el fin de mitigar estas limitaciones de funcionamiento se desarrolla la gestión activa de colas.
En AQM, cuando un router detecta una incipiente congestión, los paquetes son descartados para
notificar a las fuentes que deben reducir la carga en la red y con ello poder controlar la velocidad de
llegada de los paquetes. Si el paquete es descartado tempranamente, la longitud de la cola crecerá
más despacio, evitando colas sobresaturadas, de tal forma que AQM es capaz de soportar mayores
ráfagas de tráfico. Esto no es posible lograrlo si se utiliza drop tail, que mantiene casi al máximo la
capacidad de la cola y no deja espacio suficiente para albergar rápidos crecimientos de tráfico o
ráfagas. Aunque los mecanismos implementados en TCP restringen la tasa de envío, no son
capaces de recuperar tan fácilmente los paquetes descartados cuando ocurre una ráfaga, es menos
costoso cuando se trata de recuperar un solo paquete descartado.
Por otra parte, operar con una baja ocupación en los routers reduce el retardo de transmisión
extremo-a-extremo, dado que cuando la ocupación media de las colas de salida tienda a cero, el
retardo introducido tenderá a su vez a cero también.
35
Capítulo 2. Conceptos Teóricos
En resumen, la idea esencial de la implementación de AQMs consiste en reemplazar la técnica
tradicional de gestión pasiva de colas drop tail con el fin de proporcionar un mejor rendimiento en
la red en términos de utilización de las líneas, probabilidad de pérdida de paquetes y del retardo
extremo-a-extremo.
2.5.1.1 Notificación Explícita de la Congestión (ECN)
Para el control de congestión, junto con AQM se incorpora la así denominada Notificación
Explícita de la Congestión (ECN, Explicit Congestion Notification). Esto se resume en que los
paquetes pueden ser marcados (en lugar de descartados) si se sufre congestión utilizando un bit
ECN en la cabecera IP de cada uno de ellos (si éste bit tiene el valor 1, indica congestión), y ser
enviados a los nodos. Con esta alternativa, se está notificando a los siguientes routers que ese
paquete ha sufrido congestión. El número y selección de paquetes que son marcados durante una
congestión dependen de las políticas AQM que se establezcan.
2.5.2 Random Early Detection (RED)
El algoritmo Random Early Detection (Detección Temprana Aleatoria) fue desarrollado en 1993
por Floyd y Jacobson. Es uno de los primeros y más relevantes esquemas para evitar la congestión
en la arquitectura de Internet. RED detecta la congestión estimando la ocupación media de la cola
siempre que llega un paquete a ella. Este algoritmo pretende evitar el descarte y posterior pérdida
de paquetes IP en los routers sin disminuir con ello las prestaciones de la red.
Cada vez que llega un paquete y siempre que la ocupación media de la cola exceda un umbral
predeterminado, el mecanismo provoca que se descarte o marque con una cierta probabilidad,
donde la probabilidad está en función del tamaño medio de la cola del router. Con RED, un router
puede realizar un descarte antes que la cola se sature. La idea por tanto es situar al algoritmo en un
punto de funcionamiento óptimo que involucre un compromiso adecuado entre la utilización del
ancho de banda de salida de la cola y la reacción temprana o prevención de la congestión.
Una vez terminada la necesidad de notificar la congestión (esto es cuando la cola supera una
ocupación determinada) RED selecciona con algún criterio una fuente emisora (de entre las que
tienen paquetes en la cola) y le notifica la congestión para que ésta pueda bajar su tasa de
transmisión. RED es independiente del mecanismo de notificación adoptado, el cual puede ser tanto
marcando como descartando el paquete). RED logra mantener un bajo nivel de ocupación medio de
la cola mientras permite ocasionalmente ráfagas de paquetes. Téngase en cuenta que el objetivo
último de todo algoritmo de gestión activa de colas es mantener la ocupación media de la cola
siempre al menor valor posible, ya que así el retardo que sufra cada paquete será menor.
Estudiemos con más detalle el funcionamiento de RED: para su operación, se designan dos
umbrales, un umbral mínimo (Minth) y un umbral máximo (Maxth). Estos son comparados con una
estimación de la ocupación media de la cola (Qavg), que se calcula mediante un filtrado paso bajo
(utilizando el parámetro wq) del tamaño instantáneo de la cola.
En las siguientes figuras se muestra un ejemplo de curva que caracteriza el comportamiento de
RED, representándose para cada valor del tamaño medio de cola (Qavg) la correspondiente
36
Control de Congestión con OPNET
probabilidad de notificación (Pd). Nótese, que en general cuanto mayor es la ocupación media
mayor será la probabilidad de notificación. En la otra, se aprecia el valor que va tomando el tamaño
medio de cola con respecto al tamaño instantáneo (real) de la cola del router.
Ilustración 8. Comparación entre el tamaño real de cola y el valor que toma Qavg
El tamaño de cola medio se estima cada vez que llega un paquete. El cálculo se realiza de la
siguiente manera:
Qavg = (1 − ωq) Qavg + ωq Q
Hay un caso especial en el cálculo del parámetro Qavg, cuando el paquete llega a una cola que está
vacía. En ese caso, RED calculará este parámetro teniendo en cuenta cuando fue la última vez que
la cola estuvo vacía.
RED establece tres estados de operación que se determinan haciendo la comparación entre los dos
umbrales y la Qavg estimada. El comportamiento de RED dependerá del resultado obtenido:
•
Cuando la ocupación media de la cola (Qavg) es menor que Minth .
Esta situación es considerada como el estado normal de operación. Aquí, ningún paquete es
marcado o descartado, simplemente se encola.
•
Cuando la ocupación media de la cola esté entre Minth y Maxth .(Minth<Qavg<Maxth)
Se pone en marcha el mecanismo de prevención de congestión. Los paquetes que lleguen serán
notificados con una probabilidad Pd .
•
Cuando la ocupación media de la cola sea mayor que Maxth.
El paquete se descarta directamente, por ser considerado un nivel de riesgo de congestión.
37
Capítulo 2. Conceptos Teóricos
La probabilidad de descarte de paquetes se calcula de la siguiente forma:
Pd = Maxp (Qavg − Minth) / (Maxth− Minth )
Siedo
Maxp la máxima probabilidad de descarte de paquetes.
La ejecución del algoritmo RED depende por lo tanto de dos procedimientos diferentes: de cómo se
estime el tamaño medio de cola (Qavg) y de la probabilidad de descartes.
En RED, tanto la probabilidad de descartes como el descarte forzado no dependerán en ningún
momento del tipo de flujo al que pertenezca el paquete en cuestión, sino que sólo está determinado
por el nivel de congestión que se experimente en el router en ese momento.
Uno de los problemas de este algoritmo está relacionado con la configuración de sus parámetros, ya
que una mala configuración puede significar un mal funcionamiento del algoritmo. Otro problema
es que el parámetro Average Queue Size permanece estable dependiendo de la cantidad de
conexiones TCP de la red.
De ahí que se hayan propuesto varias variantes de RED como pueden ser GRED, SRED, DRED,
ARED, etc. para resolver estos problemas.
2.5.2.1 Gentle-RED
GRED es una modificación del algoritmo RED propuesto también por Floyd y Jacobson. En RED,
cuando el tamaño de cola medio es alto, la probabilidad de descarte aumenta drásticamente de
max_p a 1. De ahí se deduce que el tamaño medio de cola se vuelve inestable a medida que su valor
aumenta. Gentle RED soluciona este problema moderando la variación de la probabilidad de
pérdida en esas ocasiones, es decir, cuando el tamaño medio de cola supera el umbral máximo.
Aunque se ha estudiado detalladamente el algoritmo RED, no pasa lo mismo con GRED, no se ha
podido encontrar mucha información acerca del mismo y de su comportamiento en distintas
circunstancias. A continuación se explica brevemente el funcionamiento de este algoritmo.
38
Control de Congestión con OPNET
El algoritmo GRED es básicamente el mismo que se ha explicado en RED, con alguna
modificación como veremos más adelante.
Para el cálculo del tamaño de cola medio o Average Queue Size se mantiene el mecanismo de RED,
es decir, por cada paquete que llega se actualiza el parámetro de la siguiente manera:
Qavg = (1 − ωq) Qavg + ωq Q
donde Qavg es el tamaño medio de cola, wq un parámetro de control y
cola del router en cada instante.
Q es el tamaño real de la
En cuanto a la función para calcular la probabilidad de descarte, está también basada en la
ocupación media de la cola, pero en GRED la probabilidad de descarte se incrementa lentamente
entre Maxp y 1, mientras que la ocupación media de la cola varía entre Maxth y 2*Maxth:
Pd_gred = Maxp (Qavg − Minth) / (Maxth− Minth)
Pd_gred =(1- Maxp)(Qavg − Maxth) / (Maxth) + Maxp
Si Minth<Qavg<Maxth
Si Maxth<Qavg<2*Maxth
Es decir, GRED no descarta paquetes de manera tan agresiva cuando se llega al umbral máximo,
sólo aumenta la velocidad a la que crece la probabilidad de descarte.
Una vez calculada Pd_gred se descartará un paquete aleatoriamente con dicha probabilidad, que
como se ve en las gráficas, es cada vez mayor.
En las dos gráficas siguientes se muestra la diferencia en la probabilidad de descarte en ambos
algoritmos:
Ilustración 10. Probabilidad de descarte de RED y de GRED
GRED tiene una gran ventaja, ya que, como se ve en el gráfico, descarta paquetes de forma menos
agresiva que su antecesor RED. Veremos la desmostración de esto en el capítulo 5.
39
Capítulo 2. Conceptos Teóricos
40
Control de Congestión con OPNET
Capítulo 3.Introducción Teórica al
Simulador OPNET
3.1 Introducción
OPNET Modeler es un programa ampliamente utilizado en la industria para modelar y simular
sistemas de comunicaciones. El nombre corresponde a las siglas de OPtimized Network
Engineering Tool. La compañía que lo comercializa fue fundada en 1986 y se introdujo en el
mercado en el año 2000. Permite diseñar y estudiar redes, dispositivos, protocolos y aplicaciones.
Está basado en la teoría de redes de colas e incorpora las librerías para facilitar el modelado de las
topologías de red. Soporta un amplio rango de tecnologías tipo LAN, MAN y WAN.
Ilustración 11. Pantalla de inicio del Simulador OPNET
41
Capítulo 4. Implementación del algoritmo RED en OPNET
OPNET Modeler utiliza distintos niveles de modelado o paradigmas para representar los diferentes
componentes de una red. Cada nivel está asociado a un dominio y a un editor. Para hacer el
desarrollo más intuitivo al usuario, los editores se organizan jerárquicamente, de forma que los
modelos desarrollados en el Editor de Proyectos (Project Editor) dependen de elementos
desarrollados en el Editor de Nodos (Node Editor). Éste a su vez usa modelos definidos Editor de
Procesos (Process Editor). Éstos son los tres principales editores de OPNET, pero existen también
otros complementarios como son Link Model Editor (para crear, editar y ver modelos de link),
Packet Format Editor (sirve para desarrollar paquetes con un formato determinado) o Probe Editor
(para configuración de las estadísticas que se quieren obtener durante una simulación).
Ilustración 12. Vista de varios editores en OPNET
Hay dos conceptos fundamentales para describir un sistema: objetos y procedimientos. Los objetos
representan la estructura del sistema y los procedimientos su comportamiento. Ambos trabajan
conjuntamente.
Para explicarlo más detalladamente, los objetos aportan una forma natural de describir la estructura
de las redes de comunicaciones. Además de capturar las características físicas de los componentes
del sistema, los objetos pueden ser usados para representar su descomposición e interconexión
interna. Ejemplos de objetos físicos de las redes usadas para éste proyecto serían: router, switch,
servidor, cliente y links, en definitiva, los componentes que forman las redes, y a los que se tiene
acceso a través de la paleta de objetos del Project Editor. También existen objetos abstractos como
42
Control de Congestión con OPNET
procesos (se hablará más tarde de ellos) o contadores, pero son dinámicos, y no forman parte de la
estructura del sistema.
Los términos objeto y modelo en OPNET están muy unidos. Cada vez que se crea en la red un
objeto, en realidad, se crea una instancia del modelo que define a ese objeto, podríamos decir que
ese modelo es una clase. Esto es porque OPNET está fuertemente unido a la programación
orientada a objetos, ya que así se proporciona una forma centralizada de controlar un gran número
de objetos: hacer cambios en un modelo implica que todos los objetos creados a partir de él
incorporarán ese cambio.
Un modelo incluye la información común a todas sus instancias. Esto incluye especificaciones de
interfaz de los objetos, comportamiento, y estructura interna. La interfaz describe cómo un objeto
interactúa con su entorno, incluyendo especificaciones relacionadas con interconexiones físicas y
mecanismos de comunicación con otros objetos.
Además de las interfaces de los objetos, los modelos describen su comportamiento. Es decir, cómo
reaccionan a estímulos externos y cómo actúan. Por ejemplo, un cliente, es un objeto que en algún
momento actuará generando tráfico. El comportamiento de un objeto suele depender de varias
variables, como información de estado, estímulos externos, tiempo o variables aleatorias. Esto se
implementará mayoritariamente mediante un modelo de procesos, que se explicará en otro
apartado.
Finalmente, entre la información del modelo está, como se ha dicho antes, la estructura interna del
objeto. Esto se representa con la descomposición del objeto en otros componentes, que a su vez
pueden ser objetos con su propio modelo. Un ejemplo de esto son los modelos de nodos, que están
especificados en términos de objetos llamados módulos y conexiones. Un ejemplo de modelo de
nodos sería el que define el comportamiento de un router, dentro del cual se encuentra el módulo
IP. En un apartado posterior se hará referencia a estos modelos.
Por último queda explicar un concepto importante: los atributos. Cuando se representa un objeto,
hay características de éste que se consideran privadas y permanecen escondidas en su interior.
Otras, se consideran útiles para mostrar al usuario. Esas características públicas que tiene un objeto
son las llamadas atributos. Estos pueden estar asociados con clases de objetos, o con un objeto
particular. Suelen tener dos objetivos: informar al usuario de las características seleccionadas de un
objeto y permitir que esas características sean modificadas por el usuario para una aplicación
específica.
Para éste proyecto el concepto de atributo ha sido muy importante, pues, por poner un ejemplo de
aplicación, la forma de seleccionar los distintos AQM en una red es modificando uno de los
atributos del objeto IP QoS Attribute Definition. En otras secciones se verá cómo modificar o crear
o configurar los atributos.
3.2 Dominio de Red (Network Domain)
El papel del Dominio de Red es definir la topología de una red de comunicaciones. Las entidades
de comunicación se llaman nodos y las capacidades de cada nodo están definidas mediante su
43
Capítulo 4. Implementación del algoritmo RED en OPNET
modelo de nodos asociado. Los modelos de nodos se desarrollan utilizando el editor de nodos.
Dentro de un modelo de red, puede haber varios nodos basados en el mismo modelo de nodos.
Una topología podrá contener tantos nodos y modelos de nodos como el usuario crea conveniente.
Los usuarios pueden desarrollar su propia librería de modelos de nodo, implementando la
funcionalidad requerida para cada caso.
El editor de proyectos (Project Editor) aporta un contexto geográfico para el desarrollo de un
modelo de red. Se pueden elegir localizaciones en el mapa del mundo o en el de un país para redes
de área extensa o WANs, y áreas dimensionadas para redes de área local o LANs. Ésta
característica, además de ayudar a crear un entorno intuitivo a la hora de modelar, añade a la red
una noción de distancia, útil para después calcular retardos de comunicación entre nodos.
La mayoría de los nodos necesitan la habilidad de comunicarse con otros para llevar a cabo su
función dentro de la red. Hay varios tipos de links para cumplir esa tarea: simplex (unidireccional) y
duplex (bidireccional) para conectar una pareja de nodos, y bus link para emisión de datos a un
conjunto de nodos. Además cada tipo de link se puede adaptar a las necesidades del usuario
editando sus atributos o mediante el editor de links.
Para quitar un poco de complejidad a los modelos de red, a la hora de crear una topología se usan
subredes. Una subred es una agrupación de dispositivos que forma una red en sí misma, y
pertenece a una red principal. Las subredes pueden estar conectadas por distintos tipos de links,
dependiendo del tipo de subred. Se pueden anidar unas subredes dentro de otras, estableciendo una
jerarquía en la que el nivel más bajo está compuesto sólo por nodos y links.
3.3 Dominio de nodos (Node Domain)
El dominio de nodos proporciona el comportamiento de los dispositivos de comunicación o nodos
que se usan e interconectan en un modelo de redes. La estructura interna de los nodos que forman
los modelos de redes (Network Models) en OPNET no es visible a nivel de red (o los que es lo
mismo, desde el Project Editor). En este apartado se explican los componentes de esa estructura
interna.
Un modelo de nodos está compuesto por una serie de bloques conectados llamados módulos. Cada
uno de ellos contiene un conjunto de entradas y salidas, memoria de estado, y un método para
obtener las salidas a partir de las entradas y la información en la memoria. El procesamiento
depende del tipo de módulo. Algunos tienen un comportamiento predefinido con algún propósito
específico, mientras que otros pueden ser definidos por el usuario.
La forma de unir las entradas y salidas de los distintos módulos en un modelo de nodos es mediante
unos objetos llamados conexiones (connections). Hay dos tipos de conexiones: una para transportar
paquetes de datos y otra para transmitir valores individuales. Un módulo puede enviar paquetes a
través de sus output packet streams (canales de salida de paquetes) y recibirlos de sus input packet
streams. Por otro lado, puede enviar valores individuales a través de output statistics y recibirlos de
input statistics. También existen las asociaciones lógicas entre módulos, pero no tienen interés a
nivel de modelado, salvo por simplificar la comprensión del modelo de nodos.
44
Control de Congestión con OPNET
3.3.1 Módulos
Los módulos representan aquellas partes del modelo en que se genera, consume o procesan datos.
Hay varios tipos de módulos, dependiendo de su función dentro de un nodo: procesadores
(processors), colas (queues), receptores (receivers) y transmisores (transmitters). Algunos de ellos
(procesadores y colas) poseen funciones estrictamente internas del nodo, mientras que otros
(receptores y transmisores) tienen conexiones externas con los links de transmisión del dominio de
redes. El comportamiento de los procesadores y colas viene dado por modelos de procesos que
puede modificar el usuario, como pasa con el módulo IP, definido mediante el modelo de procesos
ip_dispatch y sus hijos. Sin embargo, otros módulos tienen un comportamiento ya predefinido, sólo
modificable cambiando el valor de sus atributos.
El algoritmo interno de un módulo se invoca cuando se produce un evento externo que afecta al
estado de ese módulo. Esto es a consecuencia del método de simulación por eventos que emplea
OPNET.
A continuación se describen los módulos que se han considerado más relevantes en éste proyecto.
3.3.1.1 Procesador
Icono de un procesador en el editor de nodos
Este tipo de módulos es el más importante. Se suele usar para procesamiento general de
paquetes. Su comportamiento viene dado por su atributo “process model”, que especifica el
modelo de proceso que va a ser ejecutado en el módulo. Éste puede responder a eventos
externos o interrupciones según el comportamiento que esté implementando. Los procesadores
se pueden conectar a otros módulos para intercambiar paquetes a través de packet streams.
Un procesador también se puede usar como controlador dentro de un modelo de nodos. En ese
caso se comunicará con otros módulos a través de cables estadísticos o interrupciones remotas.
Como todos los objetos, un procesador tiene atributos para configurar su comportamiento, y
pueden ser especificados usando la interfaz gráfica del editor de nodos. Sin embargo, cuando
se selecciona un modelo de proceso, los atributos pueden cambiar. Esto depende de los
atributos declarados en el modelo de proceso asociado y en sus interfaces. Los atributos de un
modelo de proceso permiten añadir nuevos atributos, que automáticamente serán heredados
por el módulo procesador.
3.3.1.2 Cola
Icono de una cola en el editor de nodos
Al igual que los módulos procesador, un módulo cola puede ejecutar un modelo de proceso
que describe el comportamiento de un determinado protocolo, y puede estar conectado a otros
45
Capítulo 4. Implementación del algoritmo RED en OPNET
módulos a través de packet streams, pudiendo enviar y recibir paquetes. El modelo de proceso
también afectará en éste caso a la lista de atributos que posea el módulo.
La mayor diferencia entre un procesador y una cola es que las colas contienen recursos
internos adicionales llamados subcolas (subqueues). Las subcolas facilitan las tareas de
almacenamiento y de gestión de la colección de paquetes guardada en ellas. Así se proporciona
al usuario una manera más sencilla para implementar disciplinas de cola.
Cada cola contiene un número definido de subcolas subordinadas a ella, con sus propios
atributos. Al poder controlar el comportamiento del módulo mediante un modelo de proceso,
se puede modelar cualquier tipo de protocolo de cola definiendo la manera en que se accede y
controla la subcolas.
3.3.1.3 Transmisor:
Iconos de transmisores punto a punto y bus en el editor de nodos
Los módulos transmisores actúan de interfaz de salida del modelo de nodos con el modelo de
red al que el nodo pertenece. Hay dos tipos de nodos, correspondientes a los dos tipos de links
de comunicación: punto a punto y bus. Ambos se diferencian en sus mecanismos de
comunicación.
Dentro de un modelo de nodo, los transmisores son considerados sumideros de datos. Desde el
punto de vista del modelo de red, éstos módulos actúan como puertos de salida del nodo a los
que conectar los links. En la siguiente ilustración se aprecia el papel de éstos módulos en una
red:
Ilustración 13. Interacción de un módulo transmisor con el modelo de nodos y el de red
46
Control de Congestión con OPNET
3.3.1.4 Receptor:
Iconos de receptores punto a punto y bus en el editor de nodos
Un módulo receptor sirve como interfaz entre los links externos al nodo y los packet streams
dentro del nodo. Como en los transmisores, hay dos tipos de módulos receptores: punto a
punto y bus. Los receptores pueden distribuir los paquetes ente uno o varios output packet
streams después de obtenerlos del link.
Dentro de un modelo de nodos, los receptores son considerados fuentes de tráfico, y desde el
punto de vista de la red, un puerto de entrada al nodo.
3.3.2 Conexiones
Las conexiones representan los caminos y asociaciones entre los distintos módulos de un nodo. En
un modelo de nodos se pueden encontrar tres tipos de conexiones.
3.3.2.1 Packet Streams
Transportan los paquetes desde un módulo destino hasta uno fuente. Representan el flujo de
datos a través de las interfaces hardware y software dentro de un nodo de comunicaciones. No
tienen errores de transmisión ni retrasos, ni límite de ancho de banda. De hecho, tienen
capacidad ilimitada para almacenar los paquetes en orden de llegada al módulo destino.
OPNET proporciona tres métodos para transferir un paquete a través de un stream y notificar
al módulo de su llegada: planificado, forzado y silencioso. Con la versión planificada, llega
una “interrupción de canal” o stream interrupt y se espera hasta que llegue el turno de recoger
el paquete. Con la forzada, cuando la interrupción ocurre, el paquete es procesado
inmediatamente, sin ejecutar los evento que hubiera antes. Con la última forma, no hay
interrupción: el paquete se almacena en el buffer hasta que el módulo lo solicite.
3.3.2.2 Statistic Wires
Transportan datos desde un módulo fuente hasta uno destino. Cada statistic wire transporta un
valor individual. Se usan generalmente como interfaces en las que el módulo fuente comparte
ciertos valores con el destino, incluida información de estado. También son usados como
mecanismos de señalización, permitiendo que el módulo origen informe al destino cuando una
condición particular de interés se ha cumplido.
Cada módulo dentro de un nodo tiene un conjunto de local output statistics cuyos valores son
actualizados durante la simulación. Este conjunto de estadísticas es el que actúa como fuente
de los statistic wire. En concreto, los procesadores y colas tienen estadísticas cuya
manipulación e interpretación está definida por el modelo de proceso, y cuya actualización se
47
Capítulo 4. Implementación del algoritmo RED en OPNET
produce cuando dentro de éste se llama a un procedimiento predefinido en OPNET,
op_stat_write(). Otros módulos sin embargo tienen unas estadísticas predeterminadas que son
actualizadas automáticamente por el Simulation Kernel cuando es conveniente.
Los statistic wires se suelen utilizar de dos formas. Primero, pueden ser empleadas para
monitorizar el estado de algún otro componente dentro de un nodo. Segundo, permiten que un
módulo avise a otro (procesados o cola) para que cambie de estado, enviando valores que
comprueba el proceso asociado.
3.3.2.3 Logical Associations
Son conexiones especiales que no transportan datos, ni existen durante la simulación.
Simplemente sirven como mecanismos de especificación: indican que hay relación entre dos
módulos de un nodo. Son ayudas para interpretar la estructura de un modelo de nodo.
3.3.3 Atributos
Se pueden crear nuevos atributos y asociarlos a un modelo de nodos. Esos atributos no
pertenecerán a un objeto en particular del dominio de nodos, sino al modelo en general. Cuando se
crea un objeto nodo en el Project Editor, heredará esos atributos. Cada instancia de un modelo
hereda su propia copia de los atributos. Por ello se dice que los atributos del modelo de nodos
proporcionan una forma de aumentar el conjunto de atributos de un nodo u objeto de la red.
Haciendo públicas ciertas características del modelo de nodos y permitiendo que se modifiquen, los
modelos se hacen más aptos para la reutilización en diferentes situaciones de modelado. Lo mismo
ocurre con los atributos de los modelos de proceso, que permiten que se introduzcan nuevos
atributos en los módulos del modelo de nodos. Por esto, dependiendo del ámbito de utilización de
los atributos, se declaran en el modelo de procesos (si se van a necesitar a nivel de implementación
de nodos) o en el de nodos (en caso de que interese que sean visibles en el Network Domain).
3.4 Dominio de procesos
Los modelos de proceso se utilizan para definir el comportamiento de los módulos de tipo
procesador y cola existentes en el Dominio de Nodos, como se ha explicado en el anterior punto.
Implementan una gran variedad de subsistemas tanto hardware como software, incluyendo
protocolos de comunicación, algoritmos, recursos compartidos como discos o memoria, disciplinas
de cola, y en general todo tipo de comportamiento que se pueda necesitar en un modelo de redes de
comunicación.
A partir de este punto, para facilitar la lectura, se llamará a los procesadores o colas con las
abreviaturas QP. Para proporcionar una funcionalidad particular dentro de un QP, se pueden definir
48
Control de Congestión con OPNET
uno o varios procesos. Un proceso es una instancia de un modelo de proceso, definido mediante el
Editor de Procesos.
3.4.1 Entorno de un Proceso
En este apartado se describe el contexto en el que trabajan los procesos en OPNET.
3.4.1.1 Ejecución basada en interrupciones
Como el resto de elementos en OPNET, los procesos trabajan en base a eventos. Cuando un evento
afecta a un proceso, lo hace en forma de interrupción. Una de las primeras acciones que realiza un
proceso al recibir una interrupción es determinar su tipo.
Siempre que empieza la ejecución de un proceso, éste está en modo de reposo o bloqueado,
esperando a ser invocado. Una invocación por tanto permitirá al proceso reanudar su ejecución y
hacer nuevas tareas. Cuando acaba, el proceso se vuelve a bloquear, devolviendo el control a
Simulation Kernel para que otros procesos puedan ser ejecutados.
El tiempo de simulación al principio y al final de una invocación no varía, es decir, una invocación
no consume tiempo.
3.4.1.2 Procesos Dinámicos
Cuando comienza la simulación, cada QP aloja sólo un proceso, que es automáticamente creado
por Simulation Kernel. Este proceso es una instancia del modelo de proceso designado en el
atributo “process model” del QP correspondiente. A éste proceso se le denominará proceso raíz, y
puede crear durante la simulación otros procesos que cooperan para hacer la tarea designada. A los
procesos que son creados por otros procesos se les denomina procesos dinámicos.
•
Jerarquía de procesos
Debido a la metodología de creación de procesos dentro de un QP se puede establecer una
jerarquía en la cual el proceso raíz es el padre y los procesos que éste crea los hijos, los cuales,
a su vez, podrían crear otros y así sucesivamente, creando una estructura de árbol, como se
puede ver en la figura de la siguiente página. No hay límite en el número de generaciones.
Además de crear procesos, se pueden borrar también, con los que la jerarquía de procesos
dentro de un QP varía dinámicamente durante la simulación. El único proceso que no se puede
borrar es el proceso padre, que será el responsable de transferir las interrupciones al resto de
procesos de la jerarquía.
En la siguiente figura se muestra un esquema con éste tipo de jerarquía.
49
Capítulo 4. Implementación del algoritmo RED en OPNET
Ilustración 14. Jerarquía de procesos en OPNET
Un detalle curioso del dominio de procesos es que se puede borrar un proceso padre sin que
desaparezcan sus hijos (excepto, como se ha dicho, el proceso padre de cada QP). Además,
podrá crear hijos basados en cualquier modelo de proceso, incluyendo el suyo propio, o el del
proceso padre, siempre y cuando sus modelos de proceso correspondientes estén declarados en
una lista.
Esa lista forma parte de la implementación de cada modelo de proceso y debe ser declarada
antes de la simulación e instanciación del proceso. La forma de acceder a ésta lista es desde el
Editor de Procesos, dentro del menú File: Declare Child Process Model para permitir nuevos
hijos y Open Child Process Model para acceder a la lista.
•
Memoria compartida
Cuando dentro de un QP se ejecutan varios procesos para implementar su funcionalidad, éstos
requieren comunicarse entre ellos para compartir información. Hay tres mecanismos de
comunicación:
- Memoria compartida a nivel QP (module memory): los procesos de la jerarquía
comparten la información guardándola en un área común definida por el QP, en forma de
estructura de datos . Los procesos asignan y obtienen la dirección de ese área mediante las
operaciones del KP op_pro_modem_install() y op_pro_modem_access(). Para asegurarse
que todos los procesos usan de forma consistente esa estructura compartida, todos tienen
una definición de ella en su bloque de cabecera o header block, accesible desde el editor
de procesos.
- Memoria compartida padre-hijo: Es un área privada que se crea a la vez que el proceso
hijo con el que se comparte. Otros procesos no tienen acceso a ella (cada uno tiene su
propia memoria con su proceso padre). El Kernel mantiene por lo tanto un bloque de
memoria para cada par padre-hijo del sistema.
50
Control de Congestión con OPNET
Ilustración 15. Memoria padre-hijo en una jerarquía de procesos
Un proceso hijo obtiene la dirección de la memoria que comparte con su padre mediante la
rutina op_pro_parmem_access().
- Paso por argumento: Mediante la primitiva op_pro_invoke(), se pasa al otro proceso la
dirección de un bloque de memoria. Así, el proceso invocado obtiene parámetros que
pueden afectar a su comportamiento, o modifica la memoria para devolver su status al
proceso que lo invocó. En este tipo de mecanismo, a diferencia de los dos anteriores, la
memoria no es persistente. Es decir, en cada invocación se debe pasar una dirección de
memoria.
•
Operaciones con Procesos Dinámicos
Como se dijo antes, un proceso raíz puede crear varios procesos hijos. Esto lo hace mediante la
función op_pro_create(). Cuando esto sucede, el nuevo proceso se añade automáticamente a la
jerarquía del padre. Como resultado de ésta operación se devuelve un valor, el process handle,
que es el identificador del nuevo proceso dentro de todo el sistema (no sólo en la jerarquía).
Este es un número único para cada proceso, y se puede acceder a él mediante op_pro_id().
Ciertos procesos dinámicos tienen un tiempo de vida reducido al tiempo que tarden en realizar
la tarea encomendada. En cuanto acaban, se le elimina de la jerarquía para no consumir
recursos mediante la función op_pro_destroy, que puede ser empleada por otros procesos, o
por ellos mismos.
Sólo puede haber un proceso ejecutándose a la vez. Se considera que un proceso está en
ejecución cuando progresa a través de las instrucciones que forman parte de su modelo.
Cuando un proceso necesita invocar a otro (anteriormente creado), lo hace mediante la función
op_pro_invoke(). A partir de ésta llamada, el proceso invocador se bloquea, cediendo el
control del hilo de ejecución al proceso invocado, el cual realiza su tarea y cuando acaba
devuelve el control al proceso que lo llamó, que continúa ejecutándose donde lo había dejado.
Nótese que cuando un proceso invoca a otro, ése a su vez puede invocar a otro… y así
sucesivamente, comportándose como un mecanismo de llamadas orientado a pila, con lo cual,
no soporta recursividad (porque los procesos, una vez van invocando a otro, permanecen
51
Capítulo 4. Implementación del algoritmo RED en OPNET
bloqueados hasta que acaba la llamada). Sí que podría existir no obstante entre distintas
instancias de un mismo proceso de modelo, invocándose una a la otra.
Durante la invocación, el proceso invocado puede acceder a cualquiera de los recursos del QP
como por ejemplo paquetes o estadísticas. Por ello, hay que tener en cuenta que después de una
invocación, ciertos valores pueden haber cambiado.
Todas las operaciones aquí citadas para manejar los procesos dinámicos y otras muchas
forman parte del llamado Process Package, uno de los paquetes de operaciones existentes
dentro de los Kernel Procedures o KP. Estas funciones están ya definidas y se pueden usar
directamente en el código de los modelos de proceso, lo cual facilita mucho la tarea de
implementación de nuevos protocolos o aplicaciones dentro de OPNET. Hay información muy
extensa sobre estos procedimientos en la documentación del programa que conviene estudiar
antes de entrar en detalles de código.
•
Control de interrupciones
Una interrupción indica que ha ocurrido un evento de interés en el sistema, como puede ser la
expiración de un temporizador o la llegada de un paquete. Cuando un proceso recibe una
interrupción, realiza una acción como respuesta y se bloquea, esperando una nueva
interrupción.
Los modelos de proceso usan procedimientos predefinidos para obtener la información acerca
del tipo y origen de la interrupción. En la mayor parte de los casos, las interrupciones poseen
información adicional a la que los procesos acceden para determinar qué acción llevar a cabo.
Por ejemplo, una interrupción causada por la llegada de un paquete hace que el proceso tenga
que obtener el paquete y procesarlo.
Por defecto, todas las interrupciones que llegan a un QP son dirigidas al proceso raíz, el cual
luego elige a quién invocar para que realice las operaciones debidas. Sin embargo,
determinados procesos pueden solicitar recibir ciertos eventos, basándose en el tipo de evento,
o su procedencia.
3.4.1.3 Recursos de un proceso
Los procesos siempre operan dentro del contexto de un QP. Por ello, el objeto QP proporciona a
sus procesos ciertos recursos que implícitamente forman parte del entorno de cada proceso.
Éstos son:
•
Canales de entrada/salida (Input and Output Streams)
Los packet streams son objetos que existen en el modelo de nodos y conectan unos módulos
con otros, como hemos visto. Concretamente, comunican estructuras dinámicas en los nodos
fuente y emisor llamadas output e input streams respectivamente.
52
Control de Congestión con OPNET
Un input stream dentro de un QP recibe paquetes de fuentes externas. Los paquetes son
automáticamente almacenados dentro del stream, siguiendo un orden FIFO, y desde ahí
pueden ser accedidos por los procesos del QP que lo soliciten.
Los input streams son reservados dinámicamente según sean necesarios para soportar las
entregas, pues Simulation Kernel no sabe de antemano el rango de canales que serán utilizados.
Cuando se recibe un paquete en un input stream, se invoca uno de los procesos del QP
mediante una interrupción de canal (stream interrupt). El proceso determinará por qué canal
llega el paquete llamando a la función op_intrpt_strm(), que devuelve el índice asociado a un
stream. Una vez conocido el canal, se recogerá el primer paquete que llegó mediante
op_pk_get().
Ilustración 16. Esquema de input streams en un QP.
El lado opuesto al anterior de un packet stream es el output stream. Estos canales efectúan la
comunicación de paquetes mediante las funciones del tipo op_pk_send(). Los output streams
también tienen un índice asociado, pero sólo serán válidos aquellos que estén asociados a un
objeto físico packet stream.
•
Estadísticas (Input Statistics y Local Output Statistics)
Ambos tipos de estadísticas forman los extremos de los statistic wires, vistos en el modelo de
nodos.
53
Capítulo 4. Implementación del algoritmo RED en OPNET
Las input statistics son construcciones internas que aceptan valores numéricos enviados por
otros módulos dentro del mismo nodo. Estas construcciones están identificadas por un entero,
y sólo retienen el último valor que ha llegado desde statistic wire (no hay buffer, al contrario
de como ocurría en los output/input streams). Cuando hay varios statistic wire conectados a un
mismo input statistic, el último valor de la última estadística que se haya actualizado es el que
prevalece. Ese valor es accesible para cualquier proceso del módulo mediante
op_stat_local_read().
Las local output statistics son el otro extremo del cable, y se denominan local para
diferenciarlas de las estadísticas globales, que pueden ser compartidas por varios QP dentro de
un modelo de nodos. Éste tipo de recursos permiten enviar estadísticas definidas por el usuario
que son privadas para cada QP. Los procesos actualizan las local output statistics llamando a
op_stat_write(). Una sola de éstas puede enviar datos a través de varios statistic wires a la vez .
Para acceder a una estadística de éste tipo, los procesos primero tienen que saber su
identificador, mediante op_stat_reg().
Los procesos dentro de un QP comparten las local output statistic existentes, cualquiera de
ellos puede actualizarlas. Eso sí, los procesos deben declarar cuales van a utilizar, mediante la
operación del editor “Edit local statistics” como se ve a continuación.
Ilustración 17. Estadísticas locales en el modelo de proceso ip_output_iface
54
Control de Congestión con OPNET
•
Estadísticas Globales
Las estadísticas globales recogen la actividad de todo el sistema de comunicaciones. Suelen ser
la media de los valores de las estadísticas locales de los distintos componentes del sistema.
Dentro de este tipo de estadísticas nos encontramos por ejemplo con el retardo extremo a
extremo, jitter o rendimiento de la red.
Como pasa con las estadísticas locales, cada modelo de proceso debe declarar las estadísticas
globales que va a actualizar durante la simulación mediante la operación “Global Statistics”
del editor de procesos.
Para acceder a una estadística global, un proceso primero debe obtener su identificación y
mediante op_stat_reg(), y después actualizarla mediante op_stat_write().
•
Subcolas
Los módulos cola pueden ser configurados para contener cualquier número de subcolas que
permiten almacenar paquetes de una manera determinada. Todos los procesos dentro de una
cola tienen el mismo derecho a acceder a las subcolas y pueden insertar y extraer paquetes
cuando lo requieran para implementar una determinada disciplina de cola (FIFO,PQ,WFQ … ).
•
Atributos
Los QP tienen un conjunto de atributos que especifican algunas de sus características
fundamentales. Todos los procesos dentro de un QP pueden modificar y obtener los valores de
estos atributos utilizando respectivamente las funciones op_ima_obj_attr_set() y
op_ima_obj_attr_get().
Esos atributos que definen el comportamiento de un módulo están declarados en el modelo de
proceso, y el usuario puede declarar nuevos para obtener características específicas para un
tipo de aplicación específica. Esto se hace en el editor de procesos, con la opción “Interfaces ›
Model Attributes” (de hecho este paso es una de las cosas que se ha tenido que hacer en este
proyecto para añadir nuevos AQM).
Para ser vistos en otros niveles de modelado, los atributos se heredan en los QP que alojan esos
modelos de proceso. Por lo tanto, los atributos de un QP serán el conjunto de atributos del
proceso raíz y de sus hijos. Para evitar conflictos en los nombres de los atributos, cada uno de
ellos lleva como prefijo el nombre del modelo de proceso del que proviene, excepto los del
proceso raíz.
El ámbito de los atributos es sólo el módulo al que pertenecen, cada QP tiene una copia
privada de los atributos, por lo que los cambios en uno de ellos no tienen efecto en los
atributos de los demás objetos.
También existen atributos de ámbito global: los llamados atributos de simulación o simulation
attributes. Son declarados también en el modelo de procesos y compartidos por varias
entidades del sistema.
55
Capítulo 4. Implementación del algoritmo RED en OPNET
3.4.2 Componentes de un modelo de proceso
Un modelo de proceso especifica el comportamiento dinámico de un proceso. Para ser completo,
un modelo de proceso debe describir las acciones que el proceso implementará en todas las
circunstancias posibles.
Además, un modelo de proceso suele representar protocolos o algoritmos existentes en la vida real,
por lo que su implementación debe ajustarse a las especificaciones y estándares oficiales de dichos
protocolos o algoritmos. Por ejemplo, la implementación del protocolo TCP/IP está definida según
los documentos RFC.
3.4.2.1 Proto-C: el lenguaje de los modelos de proceso
OPNET Modeler utiliza Proto-C, un lenguaje especial basado en C y C ++ para desarrollar
modelos de proceso eficiente para describir el comportamiento de sistemas discretos de eventos.
Este lenguaje tiene las siguientes características:
- Basado en Diagramas de Transición de Estados (STD) o Maquinas de estado Finitas (FSM).
Proto-C utiliza STD por ser el método idóneo para describir la evolución de sistemas de eventos
discretos y mantener la información de estado.
- Combina la representación visual y textual. Utiliza la representación visual para la transición de
estados, y para la información detallada o toma de decisiones la textual. La especificación textual
está contenida dentro de los estados y transiciones representados gráficamente. Además, se incluye
una amplia librería de procedimientos (las funciones citadas hasta ahora forman parte de éstos
procedimientos).
- Representación de la información de estado. La información de estado es un conjunto de datos
proporcionado o generado por el proceso. Esa información es guardada en forma de variables, que
serán utilizadas durante la ejecución.
- Creación de procesos dinámicos. Ya se ha hablado de ello. Los procesos crearán otros según
exigencias de ejecución.
las
- La estructura del lenguaje Proto-C garantiza una ejecución eficiente.
3.4.2.2 Diagramas de Transición de Estados
Los diagramas de transición de estados construidos en Proto-C consisten en dos tipos básicos de
componentes: estados y transiciones (de ahí su nombre). Los estados generalmente representan las
situaciones en las que un proceso puede entrar. Las transiciones especifican los cambios de estado
posibles en un proceso. Además hay otros elementos como declaración de variables, atributos y
acciones asociadas a cada estado, que no se ven gráficamente en el diagrama de estados.
56
Control de Congestión con OPNET
Ilustración 18. Ejemplo de STD: ip_output_iface
•
Estados Forzados y No forzados
La información de estado está continuamente actualizandose conforme van sucediendo los
eventos. En términos de un STD, la palabra estado se refiere a un objeto que está en uno de los
modos o situaciones en que se puede encontrar un proceso. Los estados son mutuamente
excluyentes y complementarios, es decir, que un proceso siempre estará exactamente en un
estado, nunca habrá más de un estado ocupado en un instante determinado en un modelo de
proceso. Las transiciones que parten de un estado indican qué estado se ocupará después y las
condiciones que cada cambio requiere.
La especificación de acciones en Proto-C está asociada con cada estado, y reciben el nombre
de executives. Las executives en cada estado se dividen en enter executives y exit executives.
Como su nombre indica, las primeras se realizan cuando un proceso entra en el estado, y las
últimas, antes de abandonarlo para ejecutar una de las transiciones posibles.
Proto-C define dos tipos de estados: forced y unforced, que difieren en su tiempo de ejecución.
En un diagrama, se pueden distinguir unos de otros por el color: los forced están representados
por círculos de color verde, y los unforced, rojo, como muestra el dibujo de la siguiente
página:
57
Capítulo 4. Implementación del algoritmo RED en OPNET
- Unforced States: permiten una pausa entre el enter y el exit executive y, por lo tanto,
pueden modelar estados reales del sistema. Después de completar el enter executive de un
estado, el proceso se bloquea y devuelve el control al hilo de ejecución en el que fue invocado.
Ese contexto podría ser, por ejemplo, otro proceso que le invocó mediante la función de KP
op_pro_invoke(), o si el proceso fue invocado por el Simulation Kernel, bloquearse significaría
el final del evento, y entonces el Kernel podría elegir el siguiente evento para comenzar su
ejecución. En este punto, el proceso permanece suspendido hasta que una nueva invocación lo
haga progresar y continuar con el exit executive del estado en el que se encuentra. El siguiente
diagrama describe el flujo de ejecución de un STD a través de estados no forzados.
En la página siguiente se muestra el flujo de ejecución de eventos a través de estados no
forzados, es decir, cómo se empieza ejecutando los exit executives de un estado, a continuación
ejecutando la transición, el enter executive del siguiente estado, y finalmente bloquearse.
58
Control de Congestión con OPNET
Ilustración 19. Flujo de ejecución a través de unforced states
- Forced states: No permiten esperar al proceso, es decir, cuando un proceso entra en un estado
de éste tipo, ejecuta las enter executives y seguidamente las exit executives. Por lo tanto, éstas
últimas se suelen dejar en blanco en este tipo de estados. Aunque no sean útiles para modelar
sistemas reales, sí que lo son en ciertos casos para separar acciones gráficamente, o para
controlar decisiones de flujo comunes a varios unforced states. Separando gráficamente las
acciones a ejecutar ayuda a la modularidad, a la vez que se obtiene un STD más informativo.
59
Capítulo 4. Implementación del algoritmo RED en OPNET
Ilustración 20. Modelado con forced states
•
Estado Inicial
Es un estado especial que debe estar en todo modelo de proceso. Se puede convertir un estado
existente en inicial mediante la opción “set initial state” en el editor de nodos. Gráficamente,
se puede identificar el estado inicial porque tiene una flecha a su izquierda.
El estado inicial es el punto en el que comienza la ejecución cuando el proceso es invocado.
En realidad puede jugar el papel de un estado normal, pero suele contener inicializaciones y
otras sentencias que deberían ocurrir solamente una vez, por lo que la mayor parte de los
modelos de proceso no incluyen transiciones de vuelta a él.
•
Transiciones
Las transiciones describen el posible movimiento de un proceso entre un estado y otro, y las
condiciones bajo las cuales ese cambio puede ocurrir. Hay cuatro componentes en la
especificación de una transición: el estado fuente, el estado destino, la condición, y la acción o
executive. La especificación de la transición se lee de la siguiente forma: si la condición es
cierta, ejecutar lo indicado en el executive y transferir el control al estado destino.
En el editor de procesos las transiciones se representan gráficamente. Cada estado puede ser
origen o destino de varias transiciones, dibujadas como arcos con la punta de la flecha
apuntando al nodo destino. La condición y el executive aparecen en forma de etiqueta al lado
del arco. Siempre que se crea una transición, el editor de Procesos automáticamente encierra la
condición entre paréntesis seguida de la barra “/” y el executive. Las transiciones que tienen
condición tienen el arco formado por una línea discontinua, y las que no tienen condición, su
arco es una línea continua. A continuación se muestra un gráfico en el que se ven los distintos
tipos de transiciones:
60
Control de Congestión con OPNET
Ilustración 21. Representación de transiciones en un STD
Las condiciones de las transiciones se evalúan para decidir si se debe pasar al siguiente estado
o no. Un proceso evalúa las transiciones de salida una vez ha completado la ejecución de las
exit executives del estado en el que está.
El manejo de las condiciones de una transición es muy flexible: pueden ser muy simples, o
formar una expresión compleja que involucran variables de estado, atributos y otra
información almacenada en la memoria local o global. También puede ser que involucren
llamadas a procedimientos definidos por el usuario que devuelvan un valor booleano que si se
cumple o no la condición. Alternativamente, también se pueden evaluar las condiciones de
transición en el propio estado orígen, al final del exit executives.
Existe una condición especial (default), que asegura que aunque no se cumplan las condiciones
de transición, siempre se pueda transitar a otro estado. La transición default se cumple sólo
cuando las otras transiciones no lo hacen.
Las transiciones que están configuradas con una condición vacía son equivalentes a
transiciones en las que su condición siempre es true. En el modelo de procesos, a estas
transiciones se las llama transiciones incondicionales. Un estado que tenga una transición
incondicional, no tiene condicionales saliendo de él.
Cada transición incorpora un atributo que especifica una acción o executive, que es ejecutada
en el momento en que el proceso decide atravesar esa transición. En otras palabras, después de
evaluar las posibles transiciones, el proceso elige una de ellas, ejecuta su executive y pasa a las
enter executives del siguiente estado.
3.4.2.3 Macros
Casi todas las macros usadas en un modelo de proceso se definen en su Header Block o HB.
61
Capítulo 4. Implementación del algoritmo RED en OPNET
Extracto del header block del modelo de proceso ip_output_iface en el que se ve la inclusión de ficheros
externos .h y definición de condiciones y constantes
Header Block o Bloque de cabecera es un área de código C y C++, similar a la cabecera de un
fichero en C o C++. Las macros generalmente se usan para representar constantes, condiciones de
transición, transition executives, u operaciones comunes. En el bloque de cabecera, las macros se
reconocen por empezar con la directiva #define.
También se pueden encontrar macros en ficheros de definición externa (con el sufijo .h, del tipo
oms_qm.h o ip_qos_support.h), que se incluyen en el header block con la directiva
#include. Este método es útil cuando varios modelos de proceso deben compartir un conjunto de
definiciones, favorece la reutilización.
3.4.2.4 Variables
Los procesos en Proto-C tienen acceso a varias formas de memoria para almacenar información,
cada una con las características necesarias para usos particulares. Algunas de éstas formas,
denominadas variables permiten ser referenciadas y manipuladas mediante nombres ordinarios, y
no direcciones de memoria. En los modelos de proceso hay tres tipos de variables: de estado,
temporales y globales.
A continuación se presenta una tabla con los tipos de variables existentes y su ámbito o visibilidad.
Tipo de Variable \ Visibilidad
Temporal
Estado
Global (como las definidas en
ficheros externos o en HB)
62
State
Executives
Function
Block
X
X
X
X
X
Funciones en ficheros
Externos
(extensión .ex.c)
X
(Usando extern)
Control de Congestión con OPNET
La declaración de cada uno de los tres tipos de variables utiliza un mecanismo distinto, para indicar
al compilador qué categoría aplicar. En los siguientes puntos se describe detalladamente las
características de cada uno de los tipos.
•
Variables de estado (State variables)
Son variables utilizadas para representar la información acumulada y retenida por un proceso. Se
las llama de estado porque, junto con la posición que ocupa el proceso dentro del STD, representan
el estado completo de un proceso en cualquier instante. Son persistentes, es decir, desde la
perspectiva de cada proceso, mantienen su valor a través del tiempo. Sólo pueden ser modificadas
mediante las acciones ejecutadas por el propio proceso. Esto implica que los valores de las
variables de estado permanecen inalterados mientras el proceso está bloqueado, y cuando éste
continúa su ejecución, todo está como lo había dejado.
Una característica de las variables de estado es que, a pesar de su persistencia, son privadas para
cada proceso. Esto implica que aunque haya dos instancias del mismo modelo de proceso existentes
en el mismo módulo, sus variables de estado guardarán la información independientemente sin
conflictos, aunque el nombre de las variables sea el mismo.
Las variables de estado se declaran en un área específica del modelo llamada state variables block,
accesible desde el editor de procesos (menú Code Blocks › State Variables), en el cual se pueden
crear nuevas, o modificar las ya existentes. No tienen valores iniciales particulares cuando el
proceso es invocado por primera vez (no se las puede dar valores durante su declaración), es
responsabilidad del propio proceso asignar esos valores de manera consistente. De hecho, esa suele
ser una de las principales actividades que se realizan en las executives del estado inicial.
Ilustración 22. Declaración de variables de estado en ip_output_iface
•
Variables temporales (Temporary variables)
Almacenan información que no requiere persistencia por lo tanto, es posible que entre una
invocación y otra del mismo proceso hayan cambiado. Debido a esto, se las suele utilizar como
instrumentos auxiliares para facilitar la ejecución de expresiones complejas en un instante de
tiempo. Por ejemplo, variables de este tipo pueden ser el índice de un bucle o un paquete recién
extraído de un stream.
63
Capítulo 4. Implementación del algoritmo RED en OPNET
Las variables temporales se declaran en una ventana que aparece al seleccionar Code Blocks ›
Temporary Variables. Se puede dar valores iniciales a las variables incorporando una asignación en
su declaración. Como se ve a continuación
Ilustración 23. Declaración de variables temporales en ip_output_iface
•
Variables Globales (Global variables)
Las variables globales proporcionan un método para que diferentes procesos guarden información
en un área común. Pueden ser de cualquier tipo predefinido en C o OPNET, incluyendo también
tipos de datos definidos por el usuario. Cuando un proceso modifica una variable global puede
afectar en las operaciones de otros procesos.
Este tipo de variables se define en el header block. Cada una de ellas debe tener una declaración
principal en el header block del modelo de proceso con el que más asociado esté. Si otros procesos
comparten acceso a ella, su bloque de cabecera incluirá una declaración externa. Puede haber
muchos procesos que tengan declaraciones externas de una variable, pero sólo uno tendrá una
declaración principal. Las declaraciones externas se definen con extern.
Como en el caso de las variables temporales, se puede inicializar las variables globales en el
momento de su declaración mediante la asignación de una valor, pero sólo en la declaración
principal. La inicialización se ejecutará antes del comienzo de la simulación.
3.4.2.5 Uso de funciones
Para hacer los modelos de proceso más modulares y sencillos, una de las técnicas que se ha dicho
anteriormente es utilizar forced states en el diagrama de estados, para así mostrar de forma más
intuitiva el flujo de ejecución de un proceso. La otra forma es el uso de funciones.
Las funciones son especificaciones de una aplicabilidad determinada que pueden aceptar
argumentos. Podemos usar funciones dentro de un modelo de proceso mediante dos mecanismos:
•
Function Block
Dentro de un modelo de proceso, las funciones se pueden definir dentro de una sección
llamada function block o FB. El contenido de FB se puede editar mediante el Editor de
64
Control de Congestión con OPNET
Procesos, haciendo clic en el botón
. El texto escrito en éste bloque aparecerá también en
el header block, permitiendo usar tipos de datos y macros definidas en él.
Cada función representa un “paquete” de funcionalidad que cualquier elemento de los STD
puede usar. Así, se simplifica la apariencia de los diagramas de transición y también se
fomenta la reutilización en distintas partes del código. Las funciones especificadas dentro de
éste bloque en general van dirigidas a los modelos de proceso con los que van asociadas.
•
External Object Files (Ficheros externos)
Como alternativa al anterior método, se pueden utilizar funciones definidas en ficheros
externos, que se unen al modelo de proceso durante la simulación. Esto permite desarrollar y
mantener funciones de manera centralizada y compartirlas por varios modelos de proceso.
Estos ficheros se encuentran físicamente en la carpeta OPNET\14.5.A\Models\std, y se
apellidan .ex.c.
OPNET permite al usuario especificar y declarar la lista de ficheros externos que un modelo de
proceso necesita. Esto se puede hacer desde el menú “File › Declare External Files…“,
marcando los ficheros deseados en la lista como se ve a continuación:
…
Ilustración 24. Dos tramos de la lista de ficheros externos en ip_dispatch
En la imagen se ve cómo están seleccionados dos de los ficheros externos más relevantes para
éste proyecto, por contener funciones relacionadas con IP y QoS.
3.4.2.6 Atributos del modelo de procesos
OPNET Modeler proporciona atributos con el propósito de permitir desarrollar modelos
parametrizados. Los modelos de proceso son los que generalmente usan este mecanismo, porque es
el modelador el que crea el código y elige qué valores deben ser interpretados como atributos para
controlar el comportamiento de un proceso.
Los atributos pueden ser declarados dentro del editor utilizando la operación Interfaces > Model
Attributes. Cada atributo se define especificando un nombre único y unas propiedades, como se ve
a continuación.
65
Capítulo 4. Implementación del algoritmo RED en OPNET
Ilustración 25. Acceso a los atributos del modelo de procesos qos_attribute_definer
Durante la simulación, los atributos aparecen como atributos de QP. Se accede a ellos para
modificarlos u obtener su valor respectivamente mediante las primitivas op_ima_obj_attr_set() y
op_ima_obj_attr_get(). Sin embargo, en la mayoría de los casos, los atributos no son modificados
durante su simulación, sirven sólo como parámetros que el proceso utiliza para configurarse a sí
mismo al inicio. Como ejemplo, a continuación se muestra cómo el proceso qos_attribute_definer
accede al atributo FIFO Profiles en el código situado dentro de Function Block:
•
Attribute Interfaces
Cada proceso mantiene un conjunto de interfaces de atributos o attribute interfaces distinto de
los de su modelo. Generalmente contiene atributos promocionados desde objetos dentro del
modelo, así como especificaciones para atributos que usará el modelo. En el caso de los
modelos de proceso, ninguno de los objetos (por ejemplo estados, transiciones) puede
promocionarlos. Por lo tanto, attribute interfaces consistirá simplemente en atributos de QP.
Utilizando este mecanismo, el usuario puede especificar por adelantado los valores y
propiedades del QP que usará este modelo.
Los Attribute Interface también proporcionan la capacidad de asociar comentarios al para guiar
e informar al usuario acerca del modelo de proceso.
66
Control de Congestión con OPNET
3.5 Simulación
En los siguientes apartados se describen primero los componentes que hacen falta para la
simulación de un sistema. Posteriormente se verá cómo se lleva a cabo la simulación desde el punto
de vista del tiempo, eventos e interrupciones.
Definimos simulación como una técnica que imita el comportamiento de un sistema del mundo real
conforme evoluciona en el tiempo. De esta manera, se puede analizar y observar características sin
necesidad de acudir al sistema real.
Se denomina modelo de simulación discreto a la representación de un sistema donde su
comportamiento cambia únicamente en instantes de tiempo concreto. OPNET es un simulador de
redes basado en un tipo concreto de simulación discreta: la simulación de eventos discretos.
Para entender los siguientes apartados, es necesario conocer los siguientes conceptos:
•
Modelo de simulación: conjunto de hipótesis acerca del funcionamiento del sistema
expresado como relaciones matemáticas y/o lógicas entre los elementos del sistema. Es
decir, hace referencia a la representación del sistema real que va a ser analizado, sus
condiciones de funcionamiento y las variables que emplea.
•
Proceso de simulación: ejecución del modelo de simulación a través del tiempo en un
ordenador para generar representaciones de comportamiento del sistema.
3.5.1 Construcción de un modelo de simulación
Antes de la simulación de un sistema, se debe obtener un programa de simulación compilado,
compuesto por instrucciones en código máquina que el ordenador puede ejecutar directamente. Un
programa de simulación consiste en partes separadas de código objeto. Cada una de esas partes
tiene un papel diferente durante la simulación. Algunos de los ficheros objeto son proporcionados
por OPNET, mientras que otros provienen de las especificaciones del usuario.
A continuación se citan los distintos tipos de componentes que forman parte de un programa de
simulación en OPNET:
- Simulation Kernel: Es una librería de código objeto que contiene los algoritmos de simulación
y otros servicios usados para la simulación. Puede ser de varias categorías. Proporciona el marco
para todas las simulaciones, incluyendo servicios básicos como carga de modelos, planificación y
gestión de eventos, recolección de estadísticas, reservas de memoria, etc. Contiene todos los Kernel
Procedures (KP) llamados por los modelos de proceso.
- Process Models: Cada modelo de proceso incluido en la simulación se traduce en un fichero
en C, teniendo una extensión .pr.c. Cada uno de estos ficheros, inmediatamente antes de la
simulación se compila mediante un compilador instalado en el ordenador (en éste caso, Visual
C++), que genera un fichero objeto con la extensión .pr.o.
67
Capítulo 4. Implementación del algoritmo RED en OPNET
- Pipeline Stages: Son la referencia a los links del sistema, e implementan operaciones
modulares y actividades relacionadas con la transmisión de paquetes entre los módulos
transmisores y los receptores. Tienen extensión .ps.c.
- External Object Files: Contienen funciones de apoyo a los modelos de proceso y pipeline
stages durante la simulación. Pueden estar desarrollados en C o en cualquier otro lenguaje que se
pueda llamar desde C. Tienen extensión .ex.c. Para ser usados, deben estar declarados en una lista
en los modelos de proceso correspondientes.
- External Archives: similares a los external Object Files, pero empaquetados, en forma de
archivo, conteniendo múltiples ficheros objeto.
Una vez obtenidos todos los componentes de simulación mencionados, OPNET proporciona un
programa ejecutable, apto para simular.
3.5.2 Simulación de eventos discretos
3.5.2.1 Eventos y simulation time
Generalmente, la simulación de eventos discretos general una secuencia de estados para un sistema.
Éste evoluciona a través de los estados en función del tiempo, basándose en las especificaciones de
comportamiento de sus componentes y en la interacción entre ellos. La noción de tiempo en una
simulación no está relacionada con el tiempo real que se emplea en efectuar dicha simulación: es
una variable mantenida por el programa, y permite especificar cuánto tiempo vamos a suponer que
el sistema está en funcionamiento. A ésta variable se la llama simulation time para distinguirla del
tiempo real.
Gracias a la noción de la variable simulation time y a los eventos, que se explican a continuación,
es posible estudiar el comportamiento que tendría un sistema durante un largo periodo de tiempo
empleando para ello un tiempo considerablemente menor.
En la simulación de eventos discretos, la progresión del modelo durante el simulation time se
descompone en instantes individuales o eventos en los cuales se producen cambios. Cada evento
representa la necesidad para el modelo de realizar algún cambio que afecte a su estado, o a realizar
alguna decisión. Ejemplo de eventos serían: recepción de un paquete, expiración de un
temporizador, la terminación de alguna tarea, fallo, etc.
Cada vez que se produce un nuevo evento, se dice que es ejecutado por la simulación. Es posible
que ocurran varios para el mismo valor de simulation time. Los eventos no se reparten de manera
uniforme durante el tiempo de simulación. De hecho, es común que su densidad varíe
significativamente a medida que progresa la simulación, como se ve a continuación:
68
Control de Congestión con OPNET
Ilustración 26. Distribución típica de eventos durante el tiempo de simulación
El tiempo de simulación sólo avanza entre eventos, durante la ejecución de un evento el tiempo no
puede cambiar(todos los eventos tienen duración 0).
3.5.2.2 Planificación y Lista de eventos
Una simulación en progreso puede ser vista tanto como generadora como consumidora de eventos.
Los componentes van generando eventos para planificar futuras acciones, basándose en el
comportamiento descrito por los distintos modelos. Esos eventos, por otro lado se irán
consumiendo según progresa el tiempo de simulación.
La simulación de eventos discretos maneja los eventos mediante una denominada lista de eventos.
El propósito de mantener semejante lista es el de asegurarse que todos los eventos se ejecutan en el
correcto orden de tiempo.
Cada evento tiene un tiempo asociado en el que se espera que ocurra. La solicitud de nuevos
eventos es denominada event scheduling, y se pueden solicitar para un instante futuro o para el
instante actual, pero nunca para uno pasado, puesto que le tiempo siempre progresa hacia delante, y
así lo hace también la variable simulation time. Es muy común que los eventos se planifiquen para
el tiempo actual como consecuencia de una reacción en cadena, es decir, un evento causa otro, y
ése a su vez otro, y asi, sin que el tiempo de simulación progrese.
La lista de eventos mantiene todos los eventos ordenados por orden de tiempo, así el siguiente
evento se ejecutará una vez el evento actual ha completado su ejecución. El evento más cercano al
tiempo de simulación actual es la cabeza de la lista, y el que está planificado para un instante más
lejano, la cola. Durante la simulación, el Kernel irá añadiendo eventos a esta lista en cualquiera de
sus posiciones, por lo que la cabeza y la cola pueden estar cambiando constantemente, así como el
tamaño de la lista. Por otro lado, el propio Kernel será también el encargado de sacarlos y
ejecutarlos.
Hay un grupo de procedimientos (Ev package) dentro de los Kernel Procedures dedicado a manejar
esta lista y todo lo relacionado a la planificación y análisis de los eventos durante la simulación.
Durante la simulación, la lista puede estar continuamente aumentando (conforme nuevos procesos
son planificados) y disminuyendo (cuando dichos eventos son ejecutados o cancelados) . Cada
simulación tendrá su propio patrón de crecimiento de la lista de eventos, dependiendo de las
actividades modeladas.
Una simulación continúa sólo cuando tiene nuevos eventos que ejecutar. Por lo tanto, si la lista se
vacía como resultado de ejecutar el último evento, la simulación termina, incluso si no se ha
alcanzado el tiempo final convenido.
69
Capítulo 4. Implementación del algoritmo RED en OPNET
Ilustración 27. Organización de una lista de eventos durante el tiempo de ejecución
Al inicio de la simulación, la lista de eventos debe recibir como mínimo un evento para que la
ejecución comience. Hay un tipo especial de evento (begin simulation) que los procesos alojados en
los QP (módulos de tipo cola o procesador) pueden lanzar si tienen un atributo específico habilitado
(begsim intrpt). Además los módulos procesador pueden elegir automáticamente cuándo enviarán
su primer paquete. Eventos de éste tipo son los que se suelen ver en la lista de eventos en cuanto la
simulación comienza.
3.5.2.3 Eventos
•
Atributos de los Eventos
Anteriormente se ha mencionado que un evento tiene un tiempo definido en el que debe ocurrir.
Pero ésta no es la única propiedad que posee. Cada evento tiene un conjunto de atributos que
almacenan información describiéndolo. Parte de esta información es usada por el Simulation Kernel
a la hora de ejecutarlo. La información también puede ser usada para procesar el evento según haya
definido el usuario dependiendo de unas circunstancias u otras . Algunos de esos atributos son:
70
Control de Congestión con OPNET
- time: instante de la simulación en que el evento debe ocurrir.
- execution ID: identificador de la orden de ejecución del evento.
- module: módulo en el que el evento ocurrirá.
- process: proceso que recibe el evento.
- type: tipo de evento, según la actividad con la que está relacionado.
-…
•
Tipos de Eventos
En OPNET hay trece tipos de eventos que soportan varias actividades de modelado. Algunos de
ellos servirán sólo para propósitos muy específicos, mientras que otros son más generales y están
relacionados con actividades más variadas. Entre ellos, cabe citar:
- self: para contadores y modelado de delays.
- stream: comunicación de paquetes entre módulos de un modelo de nodos.
- statistic: notificación asíncrona de cambios en estadísticas y señales.
- begin simulation: notificación de comienzo de simulación, permitiendo a los procesos inicializar
su estado.
- end simulation: notificación de fin de simulación, permitiendo a los procesos registrar
información final, por ejemplo estadísticas.
- process: invocación directa de un proceso dentro de un módulo.
•
Procesamiento de Eventos - Interrupciones
Cuando un modelo de proceso recibe un evento, necesita analizar ciertos atributos del mismo,
como por ejemplo el tipo, para determinar las acciones a realizar. Una de las llamadas más usadas
es op_intrpt_type(), para determinar el tipo de evento producido.
Las interrupciones son las invocaciones que resultan de la ejecución de eventos por el Simulation
Kernel. Ocurren cuando un evento alcanza la cabeza de la lista y es ejecutado. Tienen los mismos
atributos que los eventos que las generan. De hecho, al ser las manifestaciones de los eventos, se
accede a ellas obteniendo el control del evento en curso, utilizando los procedimientos de KP del
paquete Ev.
Una vez que se recibe una interrupción y se determina su tipo, procedencia y otra información que
se considere relevante, el modelo de proceso es el que elige cómo será tratada y las acciones a
realizar, dependiendo de las especificaciones dadas por el usuario.
71
Capítulo 4. Implementación del algoritmo RED en OPNET
72
Control de Congestión con OPNET
Capítulo 4. Implementación del
algoritmo RED en OPNET
4.1 Introducción
Una vez comprendido el marco teórico de la Gestión Activa de Colas en el Capítulo 2 y el
funcionamiento de los principales mecanismos de OPNET en el Capítulo 3, el usuario ya tiene los
conocimientos necesarios para hacerse una idea de cómo modelar un sistema de comunicaciones y
cómo moverse por los diferentes dominios del programa.
Este capítulo se centra en la utilización del programa de manera específica, describiendo cómo se
implementa la Gestión Activa de Colas dentro de los router, desde la creación de la red donde se va
a aplicar y configuración de la misma a través de los atributos, hasta el estudio de los External File
Objetcs donde se implementa un algoritmo AQM concreto como es el RED.
Una buena forma de comenzar la explicación es a través de la obtención de licencias del programa
e instalación, lo cual se hace en los siguientes puntos de este apartado.
4.1.1 Requisitos previos a la instalación y uso
OPNET Modeler ha sido instalado en un ordenador personal con el sistema operativo Microsoft
Windows XP Home Edition versión 2002.
En este ordenador se instaló previamente un compilador de código C y C++ (Microsoft Visual C++
6.0), necesario para compilar las distintas partes de código que componen los programas de
simulación y crear el ejecutable.
El siguiente paso ha sido revisar las variables de entorno locales del sistema operativo include, lib
y path, que tengan los valores asociados correctamente, de manera que OPNET pueda detectar el
compilador de manera automática. Dependiendo del sistema operativo y del compilador, tras la
instalación estas variables pueden tener ya el valor correcto, o el usuario tendrá que modificar su
contenido. Si hay problemas en este paso, en la página de OPNET, http://www.opnet.com hay
una sección (FAQ) que puede dar respuesta a los problemas más usuales.
73
Capítulo 4.Implementación del algoritmo RED en OPNET
4.1.2 Obtención y Gestión de licencias
La versión del programa usada para éste proyecto ha necesitado de la concesión de licencias
académicas para poderlo usar gratuitamente. Actualmente hay una versión gratuita del programa,
OPNET IT Guru Academic Edition, pero la funcionalidad que permite es muy limitada (sólo la de
un simulador de redes normal y corriente, sin posibilidad de extender su código) y no era suficiente
para desarrollar los objetivos del proyecto. Por lo tanto, hemos tenido que solicitar una versión más
completa del programa (OPNET Modeler 14.5), acogiéndonos a la opción que OPNET propone a
las Universidades (OPNET University Program), cumpliendo las siguientes condiciones:
•
Que la persona que solicita las licencias sea personal de docencia en la Universidad. En
este caso, ha sido la tutora del proyecto la solicitante de esas licencias.
•
Que el uso del programa será exclusivamente académico y no con fin comercial o
empresarial. Este requisito se cumple en nuestro caso, al solicitarse la aplicación para la
realización de un proyecto de fin de carrera.
•
Que todo resultado obtenido a través del uso del programa se debe poner a disposición del
público y su uso será gratuito.
•
Las licencias de uso del programa sólo son válidas por período de seis meses, tras los
cuales hay que renovarlas.
•
Se debe crear una página web describiendo cómo se está utilizando el programa y para qué
fin.
•
Para renovar las licencias una vez transcurrido el período de seis meses, es requisito
imprescindible actualizar la página creada antes de cada renovación, incluyendo los
avances que se van obteniendo en ese período de tiempo.
Tras completar estas condiciones, la tutora obtuvo los ficheros de instalación del programa, y el
nombre de usuario y contraseña para la autentificación y renovación de las licencias.
4.1.3 Instalación
En la instalación del programa se utilizan tres ficheros ejecutables, que instalan distintos
componentes del programa, y se han ejecutado en el siguiente orden:
•
•
•
modeler_145_PL8_7808_win
models_145_PL8_24Sep08_win
modeler_docs_02-Sep-2008_win
y que corresponden con modelador (el programa en sí) , modelos o librerías (modelos
predeterminados de comportamiento de los componentes) y documentación.
Una vez instalados los tres ficheros, y comprobadas las licencias, ya se puede empezar a utilizar el
programa.
74
Control de Congestión con OPNET
4.1.4 Configuración
Para poder utilizar el programa, hay que familiarizarse con su entorno. Previamente se han
explicado conceptos necesarios para entender el programa, pero a la hora de la práctica, es
complicado moverse por los diferentes menús de los editores y entender las opciones posibles.
Antes de comenzar, es necesario configurar correctamente el programa para evitar posteriores
problemas en su uso. La mejor forma de hacer esto es comprobando las preferencias del programa,
que determinan cual es la configuración predeterminada del programa.
•
Comprobar las preferencias de OPNET:
Hacer clic en Edit › Preferences desde la ventana de inicio del programa o desde la ventana del
Editor de Proyectos .
Aparecerá la ventana Preferences Editor, que permite visualizar y editar atributos de entorno que
controlan las operaciones del programa.
Ilustración 28. Ventana de preferencias en OPNET
La lista de atributos está ordenada alfabéticamente, según su nombre. Se pueden localizar atributos
de manera más rápida tecleando parte del nombre dentro del campo Find. Algunos de los atributos
que se han considerado interesantes son:
- License Server Name (license_server), que debe corresponderse con el nombre del host desde
el que se obtiene la licencia.
75
Capítulo 4.Implementación del algoritmo RED en OPNET
- Standalone License Server (license_server_standalone), que especifica si el programa
actúa como su propio servidor de licencias. Por defecto está a FALSE, pero en nuestro caso se ha
establecido a TRUE.
- Model Directories (mod_dir), es un directorio que contiene los ficheros de modelos de OPNET.
Si existe el atributo mod_dirs, OPNET usará los modelos que se encuentren en ese directorio. El
primer directorio de la lista indica dónde se guardarán los modelos del propio usuario. Haciendo
doble clic en la columna Values al lado del nombre de este atributo aparece una ventana en la que
podemos insertar y eliminar directorios en cualquier momento.
4.2 Modelado a nivel de topología
Para el estudio de comportamiento de los algoritmos AQM en OPNET, se han realizado varias
topologías, variando el número de usuarios. En este capítulo se describirá cómo crear la topología
más sencilla utilizada y a configurar sus componentes, todo ello mediante el Editor de Proyectos de
OPNET.
4.2.1 Descripción de la topología
A continuación se presenta una topología típica en forma de “cuello de botella”, con cinco Clientes
y cinco Servidores Ethernet, dos switch y dos routers. Los clientes actúan como fuentes TCP,
enviando tráfico de tipo FTP. La capacidad del enlace entre los dos router será muy inferior
comparada con la del resto de enlaces, para crear la situación de control de congestión y
experimentar descarte de paquetes y otros efectos.
Se utilizarán tres componentes de configuración de parámetros globales de tres tipos: configuración
de aplicaciones, configuración de perfiles y configuración de QoS.
4.2.2 Construcción paso a paso
4.2.2.1 Creación de un proyecto nuevo:
Ejecuta OPNET Modeler 14.5 Selecciona menú File › New.
1.
Selecciona Project y pulsa OK Nombra al proyecto CuelloBotella y al escenario DropTail
Pulsa OK.
2.
Aparecerá el cuadro de diálogo Startup Wizard: Initial Topology, seleccionar la opción Create
Empty Scenario Pulsa Next En la lista Network Scale elige Enterprise Pulsa Next
tres veces más Por último pulsa OK.
76
Control de Congestión con OPNET
4.2.2.2 Creación de la red:
Después de los anteriores pasos, se abrirá el editor de proyectos junto con la paleta de objetos.
Vamos a elegir los elementos que formarán la topología:
1.
Pincha en el icono
que hay a la izquierda de la ventana Search By Name. Así tendremos
una visualización más sencilla de los objetos de la paleta:
Ilustración 29. Paleta de objetos
2.
Haz clic con el botón izquierdo del ratón en el nodo Application Config y haz lo mismo en el
espacio de trabajo Acto seguido haz clic con el botón derecho para dejar de crear nodos de
este tipo.
77
Capítulo 4.Implementación del algoritmo RED en OPNET
3.
Repite la operación con los nodos de la paleta hasta tener en el espacio de trabajo los
siguientes nodos: Profile Config, QoS Attribute Config, ethernet_server, ethernet_wkstn, dos
nodos ethernet4_slip8_gtwy y otros dos ethernet16_switch. Cierra Object Palette.
4.
Cambia el nombre al nodo Application Config de la siguiente forma: clic derecho en el nodo
Set Name En la ventana Enter Value escribir Aplicaciones Pulsa OK.
5.
Cambiar el nombre a los nodos restantes hasta conseguir lo mostrado en el gráfico:
Ilustración 30. Nodos en el espacio de trabajo del editor de proyectos
6.
Ahora vamos a unir los nodos: abrir la paleta de Objetos pinchando en el botón
de la
barra de herramientas Clic con el botón izquierdo sobre el nodo 100BaseT Pincha sobre
Cliente1 y después sobre Switch1. Quedarán unidas por una línea que es el link.
7.
Repetir la operación para unir Switch1 con Router1, Router2 con Switch2 y éste con
Servidor1.
8.
Ente ambos routers se establece un link mucho más lento, para así crear el cuello de botella.
Pinchar en la paleta de objetos en el nodo PPP_DS1 Pinchar en el Router1 y después en
Router2.
9.
Guarda tu proyecto seleccionando en File › Save.
Ahora ya hemos tenemos los nodos básicos de la red en el espacio de trabajo. Los siguientes pasos
serán configurar el tipo de tráfico que circulará por la red, configurar tanto el cliente como el
servidor, y por último añadir más clientes y servidores copiando los ya configurados.
78
Control de Congestión con OPNET
4.2.2.3 Configuración del Nodo de Aplicaciones
1.
Haz clic con el botón derecho del ratón en el nodo Aplicaciones › Edit Attributes. Se abrirá la
ventana de atributos (Aplicaciones) Attributes.
2.
En el atributo Application Definitions establecer Number of Rows a 1. Desplegar Enter
Application Name y en la columna Value del atributo Name escribir Aplicación_FTP.
3.
Desplegar Description y dar doble clic en la columna Value de Ftp Aparece el cuadro de
texto (Ftp) Table. Aquí establecemos las características que tendrá nuestra aplicación FTP.
Cambiar los valores de forma que quede como en la gráfica :
4.
Pulsa OK tres veces para terminar con la configuración de éste nodo.
4.2.2.4 Configuración del Nodo de Perfiles
1.
Haz clic con el botón derecho del ratón en el nodo Perfiles › Edit Attributes. Se abrirá la
ventana de atributos (Perfiles) Attributes.
2.
Desplegar Profile Configuration y poner Number of Rows a uno Desplegar Enter Profile
Name y nombrarlo Perfil_FTP. En Applications, establecer Number of Rows a 1 En Enter
Application Name seleccionar el nombre de la aplicación creada anteriormente, que aparecerá
al hacer clic izquierdo en la casilla de Value, Aplicación_FTP.
3.
Rellenar el resto de atributos como se muestra en la siguiente figura:
79
Capítulo 4.Implementación del algoritmo RED en OPNET
Ilustración 31. Atributos del nodo Perfiles
4.
Pulsa OK para guardar los datos y cerrar la ventana y guarda tu proyecto.
4.2.2.5 Configuración de Clientes y Servidores
Configurar Cliente1:
1.
Click derecho en el nodo Cliente1 › Edit Attributes.
2.
Despliega Applications y da doble click en la casilla adyacente a Application: Supported
Profiles En la nueva ventana, poner a uno la casilla Rows En Profile Name elegir
Perfil_FTP y pulsar OK.
3.
Da doble click ahora en la casilla de al lado de Application: Destination Preferences Volver a poner Rows a uno Debajo de Application elegir Aplicación_FTP, y debajo de
Symbolic Name elegir FTP Server (establecido en el nodo Aplicaciones ). Más adelante
volveremos a ésta tabla a modificar el contenido de Actual Name, cuando hayamos
incorporado a la red todos los clientes y servidores.
80
Control de Congestión con OPNET
Ilustración 32. Un paso en la configuración de un Cliente
4.
Pulsa OK dos veces para terminar con la configuración del nodo Cliente1.
Ahora añadiremos los cuatro clientes restantes con sus links correspondientes. Para facilitar la
tarea, copiamos Cliente1 y lo pegamos cuatro veces:
5.
Selecciona el nodo Cliente1 Teclear Ctrl+C para copiar el nodo Teclear Ctrl+V para
pegar: vemos que aparece un cuadrado debajo del cursor donde se va a emplazar el nuevo
nodo. Pinchar una vez en el espacio de trabajo para fijarlo.
6.
Una vez fijado el nodo Cliente2, unirlo con el Switch1 a través del link que automáticamente
parte desde el nodo cliente.
Repetir la operación hasta tener los 5 clientes.
7.
Si miramos los atributos de cualquiera de ellos, vemos que se conservan los definidos para
Cliente1. Esa fue la razón de emplear Copiar/Pegar. Así ya no es necesario volver a configurar esos
atributos.
Configurar Servidor1:
1.
Clic derecho en el nodo Servidor1 › Edit Attributes.
2.
Despliega Applications y da doble clic en la casilla adyacente a Application: Supported
Services En la nueva ventana, poner a 1 la casilla Rows En Name elegir
Aplicacion_FTP y pulsar OK. Así establecemos que el tráfico que va a aceptar éste servidor es
el definido en el nodo Aplicaciones.
3.
De vuelta en el menú general de atributos, localiza el atributo Server Address. Vemos que está
a Auto Assigned Cambiarlo a Servidor1. Éste atributo es la identificación de éste servidor
dentro de la red. Cada servidor necesitará uno distinto. Necesitamos definirlo para más
adelante.
4.
Pulsar OK para cerrar la edición de atributos. Guarda el proyecto.
Ahora, como en el caso de los clientes, añadiremos los servidores restantes.
81
Capítulo 4.Implementación del algoritmo RED en OPNET
5.
Repetir el procedimiento de copia de los clientes con Ctrl+C y Ctrl+V, uniendo los
servidores con el Switch2.
6.
Entra en el menú Edit Attributes de cada nuevo servidor y cambia el valor del atributo Server
Address como se hizo para Servidor1, de forma que un ServidorN tendrá como Server Address
el valor ServidorN (se podría elegir el nombre que se quiera, siempre y cuando nunca se
repita).
Lo último que queda por hacer en este ámbito es asignar a qué servidor envía datos cada cliente.
Eso lo haremos mediante un atributo mencionado al configurar Cliente1, asignándole los diferentes
Server Address dependiendo del cliente, de la siguiente manera:
7.
Seleccionar Cliente1 Edit Attributes Editar Application: Destination Preferences Editar Actual Name.
8.
Aparece una nueva tabla. Establece Rows a 1 Pincha en la casilla debajo de Name, donde
pone None: aparecen las direcciones de todos los nodos de la red Pinchar en Servidor1.
9.
Así queda establecido que Cliente1 envía datos a Servidor1. Pulsa OK tres veces.
Ya tenemos configurado del todo el Cliente1. Repetir el proceso para el resto de clientes, de
manera que a cada ClienteN le sea asignado el ServidorN en la tabla mostrada. Cuando acabes
guarda tu proyecto.
Ilustración 33. Tabla para elegir destino de Cliente1
82
Control de Congestión con OPNET
A éstas alturas ya tendríamos una red válida, pero para estudiar el comportamiento de los
mecanismos de control de congestión hay añadir otro apartado:
4.2.3 Configuración de Atributos QoS
1.
Selecciona el nodo QoS › Edit Attributes
2.
Desplegar FIFO Profiles Desplegar FIFO Profile Desplegar Details y cambiar el
atributo Maximum Queue Size a 70 Pulsa OK dos veces para cerrar la ventana de atributos
del nodo QoS.
3.
Selecciona el link entre los dos routers en el espacio de trabajo. En la barra de tareas del editor
de proyectos, desplegar el menú Protocols › IP › QoS › Configure QoS…
4.
Asegurarse que la ventana tiene la siguiente forma:
Ilustración 34. Elección de la disciplina FIFO en las interfaces de los routers conectados
83
Capítulo 4.Implementación del algoritmo RED en OPNET
5.
Pulsa OK. Verás que el link seleccionado ha cambiado de color.
Ilustración 35. Unión entre routers con las interfaces configuradas
6.
Guarda tu proyecto.
4.2.4 Elección de estadísticas
En éste apartado se muestra cómo elegir las estadísticas que queremos que el programa registre
durante la simulación.
1.
Elegimos primero las estadísticas globales: haz clic con el botón derecho en cualquier punto
del espacio de trabajo que no sea un nodo en el menú escoger Choose Individual Statistics:
sale una ventana con todas las estadísticas disponibles.
Ilustración 36. Menú para elegir estadísticas
Ilustración 37. Ventana de elección de estadísticas sin desglosar
2.
84
Desglosa el menú Global Statistics › IP. Pincha en la casilla de al lado de Traffic
Dropped(packets/sec).
Control de Congestión con OPNET
3.
Sin salir de Global Statistics, desglosa TCP, y pincha en la casilla Delay(secs).
4.
Sal de Global Statistics, y expande ahora Link Statistics › point-to-point › utilization →
5.
Pulsa OK para salir de ésta ventana.
Es decir, hemos elegido registrar la tasa de paquetes perdidos en toda la red, el retraso en la entrega
de los paquetes, y la utilización en todos los links de la red (nos permite hacernos una idea de cómo
está aprovechando cada nodo sus conexiones).
6.
Ahora elegimos las estadísticas locales, las miramos en el router: haz clic con el botón
derecho en Router1 Choose Individual Statistics Expande Node Statistics Expande IP
Interface
Ilustración 38. Parte de la interfaz de visualización de las estadísticas disponibles para la interfaz IP de
“Router1”
7.
Activa las casillas Buffer Usage(packets), Queue Delay Variation(secs), Queuing Delay(secs)
Con esto sabremos lo lleno que está el buffer del router en cada momento, la variación en el retraso
o jitter experimentado en el router (el obtenido en las estadísticas globales será a nivel de la red
entera), y el tiempo que tienen que esperar los paquetes antes de ser procesados y enviados.
8.
Pincha OK para terminar.
9.
Guarda tu proyecto.
4.2.5 Duplicar escenarios
85
Capítulo 4.Implementación del algoritmo RED en OPNET
Ahora sí que está configurada la red. Al no haber escogido ningún algoritmo, el control de
congestión de ésta red se hará mediante Drop Tail, que es el implementado por defecto en los
routers de todos los fabricantes. El siguiente paso es duplicar este escenario para crear otros en los
que podamos cambiar el método de control de congestión, cambiando el tipo de AQM utilizado en
los routers.
4.2.5.1 Operaciones del menú Scenarios
Antes de duplicar escenarios, es útil conocer cómo manejar y moverse en el entorno de los
escenarios, para luego modificarlos, cambiar de uno a otro, hacer simulaciones, comparaciones, etc.
En el editor de proyectos de OPNET hay un menú en la ventana principal, Scenarios, que aporta al
usuario operaciones útiles para gestionar los escenarios que contiene un proyecto.
Ilustración 39. Vista de algunas de las operaciones del menú “Scenarios”
Algunas de las funciones de este menú que se han utilizado en éste estudio son:
- New
Scenario: Crear un nuevo escenario dentro del proyecto
- Duplicate Scenario: Crear una copia del escenario seleccionado dentro del proyecto actual.
Esta operación duplica todos los elementos del escenario original excepto los resultados de
simulación.
- Manage Scenarios: Es una operación muy potente y útil, ya que permite acceder a una lista de
todos los escenarios del proyecto actual y su estatus. En esta lista se puede, de forma centralizada,
renombrar, añadir, duplicar y borrar uno o varios escenarios. Además, se puede seleccionar qué
escenarios simular, cambiar la duración de la simulación, y reordenar los escenarios en la lista.
86
Control de Congestión con OPNET
Ilustración 40. Lista de los escenarios dentro del proyecto CuelloBotella
- Switch To Scenario: Operación que permite cambiar de escenario, mediante un menú
emergente formado por los escenarios existentes en el proyecto. En la práctica, en vez de usar éste
menú, es más rápido teclear ctrl.+NumEscenario, que te lleva directamente al escenario
solicitado, sin necesidad de desplegar ningún menú.
4.2.5.2 Creación y configuración del escenario RED
1.
Selecciona Scenarios › Duplicate Scenario Aparece un cuadro de diálogo con un nombre
por defecto. Llama al nuevo escenario RED Pulsa OK. Automáticamente pasamos a estar
editando el nuevo escenario, que es una copia exacta del anterior.
Vamos a cambiar el método de control de congestión, en vez de Drop Tail, esta vez usaremos el
algoritmo RED. Para cambiar esta configuración, hacer lo siguiente:
2.
Pinchar en el nodo QoS › Edit Attributes Expandir FIFO Profiles › FIFO Profile › Details
Expandir RED Parameters.
3.
Cambiamos los parámetros del algoritmo RED como se muestra en la figura:
Ilustración 41. Configuración de parámetros del algoritmo RED en el nodo QoS
87
Capítulo 4.Implementación del algoritmo RED en OPNET
4.
Pulsa OK.
Los parámetros de RED son los siguientes:
- RED Status: estatus de RED, si está habilitado, deshabilitado, o el tipo de versión. Así
configurado, estamos estableciendo la versión normal de RED.
- CE Marking: Uso del bit ECN. Si está deshabilitado (disabled), RED descartará los paquetes en
caso de congestión. En caso contrario, marcará los paquetes con el bit ECN en vez de descartarlos.
- Maximum Threshold: Parámetro Umbral máximo del algoritmo RED. Una vez el parámetro
avgq sobrepasa éste valor, la probabilidad de descarte es 1.
- Minimum Threshold: Parámetro Umbral mínimo del algoritmo RED. Si avgq es menor que éste
valor, ningún paquete es descartado o marcado.
- Mark Probability Denominator: Fracción de paquetes descartados cuando la probabilidad
de
descarte es máxima. Tal y como está configurado, se descarta 1 de cada 40 paquetes cuando la
probabilidad es máxima.
- Exponential Weight Factor: filtro pasa-bajo aplicado para calcular el parámetro tamaño medio de
cola o avgq.
Ahora sólo falta añadir una estadística específica del RED (el resto de estadísticas ya se
configuraron en el anterior escenario, por lo que no hace falta repetir el proceso al haber duplicado
el escenario), que será útil para futuras comparaciones:
5.
Haz clic con el botón derecho en Router1 Choose Individual Statistics Node Statistics
IP Interface Activa una nueva casilla: RED Average Queue Size
6.
Pincha OK para terminar y guarda el proyecto.
4.2.5.3 Creación y configuración del escenario GRED
Este escenario será igual que el anterior, excepto que se ha cambiado la versión utilizada de RED
por la de GRED, una modificación del algoritmo incorporada en los ficheros proporcionados por
OPNET y que se explicará posteriormente.
1.
Duplicar el escenario RED como se hizo en el anterior apartado. Llamar al nuevo escenario
GRED.
Una vez creado el nuevo escenario sólo tenemos que configurar el nodo QoS para establecer como
AQM el algoritmo GRED.
2.
Pinchar en el nodo QoS › Edit Attributes Expandir FIFO Profiles › FIFO Profile › Details
Expandir RED Parameters.
3.
Establecer el parámetro RED Status a GRED Enabled, quedando los parámetros como la
siguiente figura.
88
Control de Congestión con OPNET
Ilustración 42. Configuración de parámetros del algoritmo RED en el nodo QoS
4.2.6 Simulación de los escenarios
Vamos a simular todos los escenarios de manera secuencial. Para ello, usaremos la operación
Manage Scenarios del menú Scenarios explicada en el apartado anterior.:
1.
2.
Pincha en la barra de herramientas del editor de proyectos el botón Scenarios › Manage
Scenarios
En la lista que aparece con los escenarios, pincha en las casillas debajo de la columna Results.
Aparecerán varias opciones. Escoge la opción disponible <collect> o <recollect>,
dependiendo de si es la primera vez que se simulan los escenarios o no. En Sim Duration
(duración de la simulación) poner 1500, y en unidades o Time Units, segundos.
Al pinchar en el botón OK, aparecerá la ventana DES Execution Manager: Cuello Botella, y en el
apartado de la derecha, se verá el estado de la simulación para cada escenario. Dependiendo de
varios factores como la velocidad del procesador, o los procesos que se estén ejecutando en el
ordenador en ese momento, etc la simulación tardará más o menos.
Cuando el status de todas las simulaciones sea Completed, pulsa en el botón Close. Ahora sólo nos
queda ver los resultados obtenidos y compararlos.
A continuación se muestra el cuadro de simulaciones en dos momentos distintos.
89
Capítulo 4.Implementación del algoritmo RED en OPNET
Ilustración 43. Dos instantes de simulación: en el primer gráfico, se ha completado la simulación del primer
escenario, y el segundo va a empezar a simularse. El tercer escenario está a la espera. En el segundo gráfico,
ya se han completado las tres simulaciones.
4.2.6.1 Simular un solo escenario
En caso de querer simular sólo un escenario, se puede recurrir al menú DES (Discrete Event
Simulation) del editor de Proyectos: DES › Configure/Run Discrete Event Simulación…
Al pinchar en la opción Configure/Run Discrete Event Simulación… , aparece la ventana del
editor de simulaciones completa, que presenta este aspecto:
90
Control de Congestión con OPNET
Ilustración 45. Ventana del editor de simulaciones
A continuación se da una breve explicación de los campos presentes en esta ventana:
- Duration: Duración del tiempo de la simulación. En el campo adyacente se especifican las
unidades de tiempo que se da la duración.
- Seed: valor inicial para la secuencia de números aleatorios, necesario para la simulación
secuencial.
- Values per statistic: máximo número de valores recogidos para cada estadística.
- Update interval: intervalo de actualización de las estadísticas.
- Simulation Kernel: tipo de núcleo que se quiere utilizar para la simulación.
- Simulation set name: nombre del conjunto de simulación (valores de configuración de la
simulación)
4.2.7 Comparación y visualización de resultados
En la ventana del editor de Proyectos, pulsa en el botón
, que es para ver los resultados de las
últimas simulaciones. en el cual si dejamos el ratón sobre él, vemos que sale la nota “View
Results”. Al pulsar sobre él, aparece la pantalla Results Browser, que tiene el siguiente aspecto:
91
Capítulo 4.Implementación del algoritmo RED en OPNET
Ilustración 46. Ventana de visualización de resultados.
1.
En el campo Results for: desplegar el menú y elegir Current Project para ver todos los
escenarios de los que consta el proyecto.
2.
En el cuadro inferior, vemos dos menús desplegables: Global Statistics y Object Statistics. En
ellos, se pueden habilitar para ver en la pantalla Preview las estadísticas globales y locales
elegidas antes, respectivamente. En el ejemplo, está habilitada la estadística global de descarte
de paquetes en la red para los tres escenarios.
El primer campo del apartado Presentation está para elegir cómo mostrar varias gráficas:
- Overlaid Statistics: todas las gráficas se superponen
- Stacked Statistics: todas las gráficas se muestran por separado
En el segundo campo se elige cómo se quieren representar los valores o en qué tipo de escala. Por
poner un ejemplo:
- As Is: Se representar los valores tal y como se han obtenido, sin ninguna transformación
matemática.
- Average: Se hace representa en la gráfica valores medios
- Con ejes logarítmicos, distribución de probabilidades, ...
A partir de aquí sólo es cuestión de probar a elegir distintas estadísticas y efectuar las
comparaciones mediante las gráficas que salen. La interfaz que ofrece OPNET para la visualización
92
Control de Congestión con OPNET
de resultados es bastante cómoda e intuitiva. Basta con elegir las casillas, tanto de los escenarios
como de las estadísticas, y luego ver las gráficas de la forma que se crea más adecuada.
4.3 Estudio del nodo QoS
En este apartado se describe la estructura interna del nodo QoS, que es el que recoge globalmente
los atributos relacionados con la Calidad de Servicio aplicada en la red.
Primero se detalla la estructura a través del modelo de nodos, y luego el comportamiento a través
del de procesos. Como los conceptos teóricos de ambos modelos ya se conocen, este capítulo se
centrará directamente en explicar su estructura y funcionamiento.
Además, se indicará cómo acceder a los editores de ambos modelos.
4.3.1 Acceso al editor de nodos
El modelado a nivel de nodos se realiza desde el editor de Nodos. Para acceder a un modelo de
nodos y a su correspondiente editor, se puede hacer de varias maneras, dependiendo de la situación:
•
Si se quiere crear un modelo nuevo, elegir en una ventana de inicio de OPNET o en la
cualquiera de sus editores: File › New… en el cuadro de texto que aparece, elegir Node
Model del menú desplegable Pulsar OK. Aparecerá una ventana nueva del Editor de
Nodos.
•
Si se quiere acceder a un modelo existente, se puede acceder de dos maneras:
- A través del menú File › Open: aparece una ventana con un explorador, en la que se debe buscar
ficheros del tipo Node Model Files(*.nd.m). Cuando se encuentre el modelo de nodos
buscado, hacer doble clic y se abrirá una ventana del editor de nodos con el modelo concreto.
- A través del editor de procesos, haciendo doble clic en el nodo del que se desea abrir su modelo,
recordando que un modelo de nodos es el que describe el comportamiento del nodo en que reside.
Es el método utilizado en este proyecto, puesto que los nodos que se han estudiado más a fondo
para los algoritmos AQM son los routers y el nodo de configuración QoS, ambos presentes en la
topología. Por ello lo más sencillo es acceder a los modelos de nodos directamente desde la
topología.
4.3.2 Modelo de nodos del nodo QoS
Este nodo se utiliza para crear y configurar de manera global perfiles de QoS, que luego se aplican
a nodos (routers) e interfaces específicas dentro de toda la red. Ya se ha visto que es donde se elige
93
Capítulo 4.Implementación del algoritmo RED en OPNET
el AQM que después utiliza Router1 para el control y prevención de la congestión y descarte de
paquetes.
•
Para acceder al modelo de nodos, abrir el proyecto CuelloBotella, cualquiera de sus
escenarios.
•
Hacer doble clic en el nodo QoS, aparecerá el siguiente modelo de nodos:
Ilustración 47. El nodo QoS y su modelo de nodos.
Como se aprecia en el dibujo, el modelo de nodos asociado al nodo QoS se denomina QoS
Attribute Config, y consta de un solo módulo de tipo procesador denominado
attribute_definer.
Este modelo de nodos es tan simple porque en realidad su única labor es la configuración de
parámetros que otros modelos de nodos utilizarán en el momento de la simulación. No tiene
ninguna función equivalente a ningún dispositivo físico. Por ello, sólo consiste en un módulo que
contendrá un modelo de procesos encargado de recoger los atributos elegidos por el usuario . Si se
miran otros componentes que proporciona OPNET para configuración de parámetros como pueden
ser los del tipo Aplicaciones y Perfiles, se ve un esquema similar.
Para ver los atributos que ofrece este modelo de nodos al usuario, visibles desde el modelo de
redes, se debería mirar en el menú Interfaces › Model Attributes, pero la tabla emergente está vacía,
lo que significa que esos atributos en realidad son heredados del modelo de procesos. Con lo cual,
no hay nada más que mostrar a este nivel.
94
Control de Congestión con OPNET
4.3.3 Modelo de procesos del módulo “attribute_definer”
El modelo de procesos residente en el módulo attribute_definer será el real encargado de
obtener los datos de configuración introducidos por el usuario mediante la operación Edit Attributes
efectuada sobre el nodo QoS de nuestro sistema.
Los modelos de procesos en general se pueden ver y editar mediante el editor de procesos que
proporciona OPNET. La forma de acceder a éste editor es similar al editor de Nodos: mediante el
menú File › New… y eligiendo Process Model, si se quiere crear uno nuevo. Si lo que se quiere es
editar uno existente, mediante el menú File › Open, eligiendo en la ventana del explorador ficheros
de tipo Process Model Files (*.pr.m), o si ya se tiene el modelo de nodos, haciendo doble
clic en el módulo de interés.
Ilustración 48. Acceso al modelo de procesos de attribute_definer
Como se ve en la figura, el modelo de procesos se denomina qos_attribute_definer.
Gráficamente, el STD de este modelo de proceso está formado por el estado parse, que además es
el inicial. No hay ninguna transición. Por el color rojo del estado, se trata de un unforced state, y su
enter executive está compuesto de 56 líneas de código, mientras que el exit executive estará vacío.
Comprobemos la definición de variables y otros elementos dentro de los bloques de código:
•
Header Block
Entre los ficheros de cabecera que incluye, cabe destacar :
oms_qm.h es un fichero con estructuras asociadas al manejo de colas (queue management). Las
estructuras definidas aquí serán usadas dentro del external file oms_qm.ex.c, el cual contiene
funciones para el manejo de colas, entre ellos, funciones específicas del algoritmo RED.
95
Capítulo 4.Implementación del algoritmo RED en OPNET
En el apartado de predefinición de funciones, nos fijamos en attr_def_fifo_profiles_info_parse,
que recoge los atributos guardados en el atributo compuesto “FIFO Profiles”, y en
attr_def_red_parameters_get, que recoge los valores almacenados en el atributo “RED
Parameters”. Ambas funciones están implementadas en el function block, y se verán más adelante.
•
Variables de Estado
Destaca la variable:
que servirá como referencia para acceder a los distintos atributos.
•
Variables Temporales
Sólo se usan dentro del STD:
Y sirven sobre todo para el manejo de objetos e identificación.
•
Enter Executives
Para acceder al código de las enter executives, basta con hacer doble clic en la mitad superior del
estado en cuestión. Las acciones realizadas son:
- Inicializar variables de estado y temporales, inicialización de ciertas estructuras
- Registrar la existencia del modelo de proceso, para ser visible para otros procesos (por ejemplo,
ip_dispatch, dentro del módulo ip del nodo router), mediante la función oms_pr_process_register.
- Llamada a la función attr_def_fifo_profiles_info_parse () para recoger los atributos del tipo
FIFO, si están configurados.
También llama a otras funciones para recoger los atributos de otras disciplinas de cola como WFQ,
PQ y los de otros mecanismos de QoS como CAR y RSVP. Es decir, recoge la información
correspondiente a la ventana siguiente:
96
Control de Congestión con OPNET
Ilustración 49. Atributo recogido por attr_def_fifo_profiles_info_parse
En este proyecto nos hemos centrado en FIFO, por lo que no se contemplarán el resto de opciones.
Para ver exactamente cómo se comporta attr_def_fifo_profiles_info_parse, abrir la ventana del
function block:
•
Function Block
A continuación se muestran fragmentos importantes y sus comentarios del código de la función
citada:
static voidattr_def_fifo_profiles_info_parse (void)
{
OmsT_Qm_Attributes*qm_attr_ptr = OPC_NIL;
OmsT_Qm_IP_Queue_Configuration*qconfig_ptr = OPC_NIL;
op_ima_obj_attr_get(my_objid,"FIFO Profiles", &qc_information_objid);
…
/*Obtener el nombre del perfil FIFO*/
op_ima_obj_attr_get (queuing_type_objid, "Profile Name",prof_name);
/*Reservar memoria para almacenar el atributo QoS usado por la interfaz IP*/
qm_attr_ptr = ip_qos_attributes_create (IpT_Fifo_Pool, 1,
(int)OmsC_Buffer_Parent_Limit, OPC_TRUE);
qconfig_ptr = (OmsT_Qm_IP_Queue_Configuration*)
qm_attr_ptr->queue_configuration[0];
op_ima_obj_attr_get(queuing_type_objid,"Details",&(queue_configuration_objid));
…
op_ima_obj_attr_get (queue_configuration_child_objid, "Maximum Queue Size",
&max_queue_size);
qconfig_ptr->max_size = (double) max_queue_size;
…
97
Capítulo 4.Implementación del algoritmo RED en OPNET
/* Recoger los parámetros RED, si existen, y guardarlos en una estructura*/
attr_def_red_parameters_get (prof_name, qconfig_ptr, 0,
queue_configuration_child_objid);
/* Registrar los datos del atributo FIFO Profiles en una base de datos
global pasando el puntero a la estructura qm_attr_ptr. Así la información
es accesible para todos los objetos de la red, por ejemplo, los routers IP*/
oms_data_def_entry_insert ("FIFO Profiles", prof_name, qm_attr_ptr);
FOUT;
}
Y los atributos que recoge, para que se vea la correspondencia:
La estructura qm_attr_ptr, de tipo OmsT_Qm_Attributes es importante, pues guarda información
sobre colas del tipo número máximo de paquetes, número de colas por defecto, y contiene a otras
estructuras para almacenar parámetros de cada una de las colas en particular, como es el parámetro
qm_attr_ptr->queue_configuration , que como se ve en el código, se le hace una asignación de
tipo OmsT_Qm_IP_Queue_Configuration, la otra estructura importante, que mantiene parámetros IP
específicos de las colas, entre ellos, parámetros relativos al AQM RED.
En la anterior función, para recoger los parámetros de RED y rellenar la estructura de tipo
OmsT_Qm_IP_Queue_Configuration, se llama a otra función que también está definida en el bloque
de funciones: attr_def_red_parameters_get, y que se muestra a continuación (observar que no está
el código completo, sólo las partes más relevantes):
static void attr_def_red_parameters_get
{
OmsT_Qm_RED_Queue_Params* red_queue_params_ptr = OPC_NIL;
OmsT_Qm_RED_Class_Params* red_class_params_ptr = OPC_NIL;
/* Get the RED attribute object identifier.*/
op_ima_obj_attr_get (queue_configuration_child_objid, "RED Parameters",
&red_parameters_objid);
/* Accede al siguiente nivel en el árbol de atributos */
red_parameters_child_objid = op_topo_child (red_parameters_objid,
OPC_OBJTYPE_GENERIC, 0);
/* Comprobar que RED esté habilitado.*/
op_ima_obj_attr_get (red_parameters_child_objid, "RED Status",
&(qconfig_ptr->red_status));
if (qconfig_ptr->red_status == OMSC_NO_RED)FOUT;
/* Reservar memoria para los parámetros RED */
red_queue_params_ptr = ip_qos_red_queue_params_mem_alloc ();
98
Control de Congestión con OPNET
/* A continuación recoge los parámetros de RED */
op_ima_obj_attr_get (red_parameters_child_objid, "Exponential Weight Factor",
&(red_queue_params_ptr->exponential_weight_factor));
op_ima_obj_attr_get (red_parameters_child_objid, "CE Marking",
&red_queue_params_ptr->ce_marking);
op_ima_obj_attr_get (red_parameters_child_objid, "Minimum Threshold",
&minimum_threshold);
op_ima_obj_attr_get (red_parameters_child_objid, "Maximum Threshold",
&maximum_threshold);
…
op_ima_obj_attr_get (red_parameters_child_objid, "Mark Probability
Denominator", &mark_prob_string);
…
/* Reservar memoria para el perfil RED. */
red_class_params_ptr = ip_qos_red_class_params_mem_alloc ();
/* Set the tresholds. */
red_class_params_ptr->minimum_threshold = minimum_threshold;
red_class_params_ptr->maximum_threshold = maximum_threshold;
/* Match best effort traffic. (No aplicaremos ningún método de QoS)
red_class_params_ptr->match_value = OmsC_Qm_Best_Effort;
*/
/* Insert the RED class ptr into the RED queue ptr list */
op_prg_list_insert (red_queue_params_ptr->red_class_params_lptr,
red_class_params_ptr, OPC_LISTPOS_TAIL);
…
}
/* Asignar los parámetros obtenidos a la estructura con la que ha sido
llamada la función. */
qconfig_ptr->red_queue_params_ptr = red_queue_params_ptr;
Ilustración 50. Parámetros recogidos mediante attr_def_red_parameters_get.
Es interesante en esta última función saber que cuando recoge el parámetro “RED Status”, puede
encontrarse con diferentes valores, definidos como constantes en el fichero de cabecera antes
incluído, oms_qm.h:
#define
#define
#define
OMSC_NO_RED
OMSC_RED
OMSC_WRED
0
1
2
o con nuestro valor definido para la extensión de RED:
#define
OMSC_GRED
3
99
Capítulo 4.Implementación del algoritmo RED en OPNET
Éste valor se quedará guardado en la estructura:
qm_attr_ptrqconfig_ptrred_status
Y se utilizará en una función posterior para saber qué tipo de cálculo aplicar a la hora de obtener la
probabilidad de descartes, y si un paquete debe ser descartado o no.
•
Funcion para recoger parámetros:
Un punto importante que explicar, es la función que recoge los parámetros, que ya se ha visto en
otras ocasiones, pero no ha sido explicada. Veámoslo con un ejemplo:
op_ima_obj_attr_get (id_objeto, "Nombre Param", &variable );
Ésta función, perteneciente a los Kernel Procedures (KP) aportados por Simulation Kernel, recoge
el parámetro de nombre "Nombre Param" del objeto con identificador id_objeto, y lo guarda en
una variable llamada variable.
Otras funciones destacadas son:
ip_qos_attributes_create,
ip_qos_red_queue_params_mem_alloc,
ip_qos_red_class_params_mem_alloc
De
momento, se debe saber que las tres están definidas en el fichero externo
dependiente de oms_qm.h, fichero incluído a través del header block.
ip_qos_support.ex.c,
4.3.4 Modificación de atributos
Como se ha dicho anteriormente, los atributos proporcionan al usuario la manera de configurar un
nodo conforme a las especificaciones que necesite a través de una interfaz gráfica, sin adentrarse en
la complejidad de la implementación del nodo. En el caso del nodo QoS, el usuario puede elegir
distintos mecanismos para proporcionar a la red cierta Calidad de Servicio a partir de los nodos
intermedios, como son las disciplinas de cola, los algoritmos de Gestión Activa de colas, o el
protocolo RSVP.
Se puede modificar o extender esa interfaz de acceso a los atributos tanto desde el editor de nodos
como desde el de procesos para especializar los nodos que utilicemos en nuestro sistema. En este
caso nos interesa modificar esa interfaz desde el modelo de procesos, ya que así, el modelo de
nodos heredará el nuevo conjunto de atributos, y a la vez está más accesible a los procesos para
hacer sus cálculos, como hemos visto que pasaba en el anterior capítulo con la recolección de los
atributos FIFO Profiles y RED Parameters.
A continuación se mostrará cómo extender el conjunto de atributos del nodo QoS para tener acceso
al nuevo algoritmo GRED.
100
Control de Congestión con OPNET
4.3.4.1 Acceso a la tabla de atributos
En la barra de tareas del editor de proyectos, acceder al menú Interfaces › Model Attributes.
Aparecerá la siguiente ventana:
Ilustración 51. Ventana Model Attributes del modelo de proceso del nodo QoS
Como se ve, son los mismos atributos existentes al elegir Edit Attributes sobre el nodo QoS en el
editor de proyectos.
Analizando esta ventana, vemos que en realidad es una tabla con varias columnas. Veamos cada
una de ellas, y a la vez veamos qué significan los valores asignados al atributo FIFO en concreto:
•
Attribute Name: indica el nombre del atributo
•
Group: grupo al que pertenece el atributo (no hemos hecho ninguna clase de agrupación
de atributos, por lo que ésta columna no tendrá valor para nosotros).
•
Type: tipo de información que guarda el atributo. Un atributo puede ser de tipo integer,
double, compound, string, … El valor compound significa que el atributo guardará
información de tipo Objid, es decir, que contendrá otros objetos atributo anidados, y que
en el nivel de redes aparece como (…).
•
Units: unidades en que estará expresado el atributo. Vemos que ésta columna permanece
vacía para toda la tabla por ser todos atributos compuestos.
•
Default Value: valor por defecto proporcionado por el sistema cuando el atributo es
requerido y no ha sido configurado por el usuario. También se usa para sugerir un valor al
usuario.
101
Capítulo 4.Implementación del algoritmo RED en OPNET
•
Tags: palabras claves para identificar el atributo dentro del menú Edit Attributes a la hora
de realizar una búsqueda.
Ahora vamos a analizar lo que contiene el atributo FIFO Profiles. Para ello, señalar en la tabla este
atributo y pulsar con el ratón en el botón
atributos de los que está compuesto el atributo.
. Aparece la siguiente ventana, que son los
Ilustración 52. Atributos de FIFO Profiles
Que equivale al siguiente nivel en la jerarquía de atributos (se puede observar en figuras anteriores
que muestran el atributo FIFO Profiles desplegado). Vemos que el segundo atributo, Details es a su
vez compuesto, por lo que volvemos a editarlo como en el caso anterior, obteniendo los atributos:
Esta vez vemos como ya se le da a uno de los atributos, Maximum Queue Size, un valor por defecto
(500) y una unidad (pkts). Esto significa que si el usuario no configura este atributo, por defecto, el
tamaño de buffer en una cola FIFO va a ser de 500 paquetes.
4.3.4.2 Añadir un nuevo atributo
Si se necesita añadir un nuevo atributo correspondiente a la configuración de un nuevo AQM
diferente de RED se podría hacer escribiendo su nombre en el campo New attribute y pulsando el
botón Add, con lo que el atributo aparecería en una tabla, y habría configurar el resto de los
campos. En la tabla siguiente, se muestra un ejemplo en el que se ha añadido un atributo compuesto
que pueda guardar los parámetros de configuración PID:
102
Control de Congestión con OPNET
Ilustración 53. Añadir un nuevo atributo
Observar que a diferencia de la primera tabla, en estas dos últimas ha desaparecido la columna
Group (sólo se pueden agrupar atributos del primer nivel de la jerarquía) y han aparecido dos
nuevas columnas:
•
Primary Key: designa el atributo como clave primaria. El nombre del atributo designado
de esta manera aparece en la columna de la caja de diálogo del atributo compuesto. Ayuda
a la comprensión del atributo compuesto.
•
Prominent: para miembros de un atributo compuesto, incluye el atributo en las búsquedas
con filtro.
A partir de tener el nuevo atributo, sólo quedaría crear y configurar su árbol de atributos (se ha
definido de tipo compuesto por necesitar varios parámetros). No nos vamos a detener en cómo
crear toda la jerarquía del atributo PID, pues eso formará parte de posteriores trabajos.
Seguimos estudiando el árbol de atributos, para ello, editamos esta vez el atributo compuesto RED
Parameters. Obtenemos la siguiente tabla, en la que ya todos los atributos son simples, y se ven los
valores por defecto que aparecen al editar los atributos desde el editor de proyectos por primera vez
(hemos llegado al último nivel de estructura del atributo):
Ilustración 54. Atributos dentro del atributo compuesto RED Parameters
103
Capítulo 4.Implementación del algoritmo RED en OPNET
Se ha añadido la nueva versión de RED, GRED, como un nuevo tipo de RED, por lo que tendrá un
tratamiento parecido al de la versión de RED, WRED. Es decir, se debe añadir una nueva opción al
valor del atributo RED Status. Para editar este atributo ya definido, primero debemos tener acceso a
él, pero es privado (no podemos utilizar la opción Edit Properties como en los casos anteriores).
4.3.4.3 Añadir valores a un atributo ya creado
Para modificar un atributo, debemos hacer público su conjunto de valores. Para ello, señalamos
dicho atributo y damos a la opción Edit Compound Attributes Properties (como se ve, la opción de
las anteriores ventanas no está habilitada).
Aparece una nueva ventana (se muestra a continuación), con los atributos de RED Parameters,
incluido el del atributo GRED añadido anteriormente.
Ilustración 55. Symbol map de RED Parameters
Vamos a describir los campos de ésta ventana:
104
•
Data Type: Nos dice el tipo de atributo que estamos editando (que compuesto).
•
Default Value: Valor que aparecerá por defecto en el atributo.
•
Units: Unidades en que está expresado el valor (vacío, al ser atributo compuesto).
•
Comments: Comentarios explicando el significado del atributo o cualquier otra
información que se considere oportuna.
Control de Congestión con OPNET
•
Symbol map: Conjunto de valores posibles del atributo. Vemos que las opciones posibles
son las que saldrían al editar los atributos. La correspondencia de esto con la
configuración de parámetros sería los siguiente:
Ilustración 56. Correspondencia con Symbol map
Para el conjunto de valores del symbol map, debemos entrar en el modo privado (el no
accesible por el público): nos fijamos en el campo de la ventana que falta por explicar:
• Attribute Properties: Las propiedades de los atributos se guardan en un fichero llamado
RED_Parameters, como se ve. Para modificarlos, seleccionar Private, y pasaremos a editar
un nuevo fichero (desaparece el nombre anterior).
Ilustración 57. Propiedades del atributo RED Parameters
105
Capítulo 4.Implementación del algoritmo RED en OPNET
Los campos que antes estaban deshabilitados se habilitarán ahora. Por poner un ejemplo, vamos a
añadir un nuevo valor al Symbol map, como si fuéramos a añadir un nuevo algoritmo, CRED:
escribirlo en el campo donde pone New Symbol:
Ilustración 58. Añadiendo un valor a Symbol Map
Ahora pulsar OK para salir de las propiedades y volver a la pantalla anterior, recordando que
seguimos en modo privado. Ahora, al seleccionar RED Status, sí que podemos elegir Edit
Properties (a diferencia de antes en el modo público). Lo seleccionamos y sale una nueva ventana
con un nuevo Symbol map, que debemos cambiar para añadir el nuevo valor. Lo añadimos y le
damos el valor 4 (luego habría que declararlo en oms_qm.h como constante con valor 4, como se
hizo con GRED y el valor 3, como se ha visto antes, para que el valor se asocie correctamente con
el código).
Ilustración 59. Asignación de valor a nuevo símbolo
Pulsar OK para volver a la ventana anterior, y volvemos a pulsar Edit Attribute Properties. Ya en
la ventana, volver al dominio público habilitando la casilla Public. Al lado, aparecerá la palabra
unnamed, indicando que se ha creado un nuevo fichero de propiedades. Pulsar ahora el botón Save
106
Control de Congestión con OPNET
Public. Aparece una ventana que nos deja elegir dónde grabar el nuevo fichero. Grabarlo con el
nombre RED_Parameters3 y pulsar OK.
Ilustración 60. Nuevo fichero de propiedades públicas de un atributo.
En este punto, ya hemos terminado de trabajar con el modelo de procesos del nodo QoS, centrado
en recoger los atributos que configuran la Calidad de Servicio de una red de forma global. Por
hacer un resumen, primero se han analizado las variables implicadas en el modelo de proceso, tanto
temporales como globales y de estado, luego el STD asociado, y en cómo en el function block están
implementadas las funciones para recoger los atributos configurados a partir del menú Interfaces ›
Model Attributes, centrándonos en FIFO y RED. Finalmente se ha visto la necesidad de modificar
una de las librerías, oms_qm.h, para declarar una variable que se corresponda con el valor añadido
(versión de RED, GRED) para el atributo RED Status.
Como ejemplo para la modificación de atributos, se ha explicado cómo añadir un nuevo valor,
CRED, incluyéndolo en el symbol map del atributo, entrando antes en el dominio privado para
crear un nuevo fichero con las propiedades del atributo.
El siguiente apartado se centrará en el funcionamiento de un router, en el que se implementa la
gestión de paquetes mediante el protocolo IP, y los algoritmos de control de congestión.
4.4 Estudio de un nodo router
En este apartado se describe la estructura interna de uno de los nodos router existentes en las
topologías utilizadas en este proyecto. El router es el encargado, entre otras cosas, de aplicar las
disciplinas de cola y de control de congestión bajo el protocolo IP, por lo que en este tipo de nodos
es donde se encuentra implementada la funcionalidad de los AQM, y su modelo de nodos es, por
tanto, el más importante de los analizados para este proyecto.
Primero se describirá su estructura a través del modelo de nodos, y luego su comportamiento a
través del de procesos. Tanto el modelo de nodos como el de procesos son más complejos que los
del nodo QoS, pues en este caso sí que estamos ante un nodo que simula el desempeño de una tarea
real dentro de una red. Estudiaremos esos modelos a continuación.
En el apartado anterior ya se ha descrito cómo acceder tanto al editor de nodos como al de
procesos, por lo que si se necesita explicación sobre lo que se va a hacer en los puntos siguientes,
se puede recurrir a dicho apartado.
107
Capítulo 4.Implementación del algoritmo RED en OPNET
4.4.1 Modelo de nodos del nodo router1
Es importante saber que si tenemos varios nodos router del mismo tipo en la red, daría igual sobre
cual de ellos pinchar, porque al usar los mismos modelos para describir su comportamiento, los
cambios que hagamos en uno se actualizan en todos.
Abrir el proyecto CuelloBotella y dar doble clic sobre el nodo Router1. Se abrirá una ventana con
el modelo de nodos residente.
Ilustración 61. Modelo de nodos de Router1, ethernet4_slip8_gtwy_adv
Como se ve en la ilustración, en el modelo de nodos de un router hay varios módulos de tipo
procesador que implementan diferentes protocolos o mecanismos de comunicación como son ip,
tcp, udp, tpal, dhcp, ARP, etc. que cooperan enviándose datos a través de packet streams (en color
rojo y azul en el dibujo) y datos estadísticos (entre los módulos de tipo transmisor/receptor y los de
tipo cola).
Una vez analizados varios de esos módulos, se ha visto que el manejo de los mecanismos de
gestión de colas en éste modelo de nodos se hace a partir del módulo ip, no es necesario analizar
los demás. Por lo tanto, es en el que nos centraremos a partir de ahora.
108
Control de Congestión con OPNET
4.4.2 Modelo de procesos del módulo ip
Para acceder al modelo de procesos del módulo ip, utilizar el mismo procedimiento que se ha
venido explicando en el resto del documento: dar doble clic en el módulo ip.
Ilustración 62. Modelo padre del módulo ip: ip_dispatch
Aparece la ventana del editor de procesos con el modelo de proceso ip_dispatch, que es el
proceso padre o raíz del módulo, es decir, el modelo de procesos de ip que se va a activar nada más
empiece la simulación. El modelo de procesos raíz se especifica en el atributo process model del
módulo:
Ilustración 63. Especificación de ip_dispatch como proceso raíz en el módulo ip
109
Capítulo 4.Implementación del algoritmo RED en OPNET
4.4.2.1 Análisis de ip_dispatch
La función de ip_dispatch es sobre todo repartir las interrupciones que le llegan al módulo desde
otros puntos entre los distintos procesos hijos, que se dedican ya a tareas concretas.
•
Variables de estado
Destaca la variable module_data, de tipo IpT_Rte_Module_Data.
Es la variable que almacena los datos compartidos por toda la jerarquía de procesos del módulo por
lo que es una de las más importantes. La estructura IpT_Rte_Module_Data está definida en el
fichero de cabecera ip_rte_support.h
•
Variables temporales
En éste bloque declara variables útiles para el procesamiento y selección de las transiciones dentro
del STD.
•
Header Block
Sentencias para incluir ficheros de cabecera, como ip_rte_support.h nombrado antes y oms_qm.h
y ip_qos_support.h, utilizados también en el modelo de proceso del nodo QoS. También hay
definición de macros para las condiciones de las transiciones, y definiciones de constantes. Por
último, declara estructuras globales y funciones implementadas en function block.
•
Declaración de ficheros externos
Para ver los ficheros externos a los que se hará referencia desde este modelo de proceso, ir al menú
File › Declare External Files. Ahí se ven declarados tanto ip_qos_support.ex.c como
oms_qm.ex.c. Posteriormente se escribirá más sobre ellos.
•
STD
Como se ve en la ilustración 62, está formado por varios estados. Algo curioso es ver que en todos
los estados, en las exit executives aparecerá la sentencia
intrpt_type = op_intrpt_type ();
que asigna a la variable temporal intrpt_type el código del tipo de interrupción producida, para
comprobar si se cumple la transición para pasar al siguiente estado.
- init: llama a la función ip_dispatch_do_init(), la cual registra el puntero a la variable que se
utilizará como memoria compartida con otros procesos:
110
Control de Congestión con OPNET
op_pro_modmem_install (&module_data);
e inicializa campos de esta variable y paquetes de datos concernientes a IP. inicializa tablas y
variables referentes a flujo IP, y captura el tipo de interrupción para usar posteriormente.
•
En la transición, se ejecuta la función ip_dispatch_wait_for_registrations(),
que se asegura que antes de proseguir estén registrados en el Registro de
Procesos todos los procesos relacionados con IP, para evitar incoherencias
durante el resto de la simulación.
- wait, wait_1, wait_2: transita de estado a estado planificando auto-interrupciones, teniendo en
cuenta los tiempos de simulación a la hora de interrumpir.
•
En la transición, se ejecuta la función ip_dispatch_init_phase_2(), que
prosigue con la inicialización de variables efectuada en el estado init.
- cmn_rte_tbl: plantea dos posibilidades de transición: estado inactive (si todas las interfaces IP
del nodo están inactivas) y estado init_too(hay alguna interfaz activa). Nos centraremos en este
último estado.
•
Durante la transición al siguiente estado, init_too, se ejecuta la función
ip_dispatch_distribute_routing_info(), que activa los distintos protocolos
de enrutamiento configurados en el router.
- init_too: en este estado se finaliza la inicialización del módulo, a partir de lo cual crea diversos
hijos que ejecutan tareas específicas. En los exit executives encontramos la llamada a la función:
ip_dispatch_cleanup_and_create_child_processes ();[1]
Esta función es muy importante porque es la que desencadena el procesamiento de las interfaces IP.
A partir de aquí, dejamos de analizar la máquina de estados, y nos centramos en la ejecución de
ésta función definida, como todas las demás con el prefijo ip_dispatch, en el function block.
•
Llamadas a funciones desde el function block. Estudio del código fuente.
Seguiremos la trayectoria de llamadas a partir de la función anterior:
1. ip_dispatch_cleanup_and_create_child_processes() [definida en FB]
static void ip_dispatch_cleanup_and_create_child_processes (void)
{
List*proc_record_handle_list_ptr;
…
/* Lista para guardar los procesos registrados */
proc_record_handle_list_ptr = op_prg_list_create ();
/* Determina la disciplina de cola: FIFO, WFQ,... El proceso IP delegará sus
tareas en un proceso hijo para cada interfaz que envía datos. */
ip_rte_qos_information_process (); [2]
111
Capítulo 4.Implementación del algoritmo RED en OPNET
...
FOUT;
}
2. ip_rte_qos_information_process (); [FB]
static voidip_rte_qos_information_process (void)
{
List
qos_ifaces_list;
IpT_Qos_Info*intf_qos_info;
IpT_QoS_Iface_Config
* qos_iface_config_ptr;
IpT_Rte_Iface_QoS_Data * interface_qos_data_ptr;
…
/** Crea los procesos hijos para procesar paquetes en la cola de salida. Se
genera un proceso hijo por cada interfaz. Cada uno modela un mecanismo de
encolado como FIFO, WFQ o PQ, además de mecanismos de control de congestión
como RED/WRED. **/
/* Guarda en la memoria compartida informacion acerca de cada interfaz*/
module_data.shared_mem.iprmd_ptr = &module_data;
/* Almacena en memoria compartida handles para paquetes enviados y descartados.
Tambien se comparten otras variables de estado con el modelo de proceso de la
interfaz de salida para tener en cuenta el trafico background en las
estadisticas de esa interfaz de salida.*/
module_data.shared_mem.locl_pk_dropped_hdl_ptr =
&module_data.locl_num_pkts_dropped_hndl;
module_data.shared_mem.globl_pk_dropped_hdl_ptr =
&module_data.globl_num_pkts_dropped_hndl;
module_data.shared_mem.locl_num_pkts_sent_hdl_ptr =
&module_data.locl_tot_pkts_sent_hndl;
…
/* Obtener num de interfaces.*/
iface_table_size = inet_rte_num_interfaces_get (&module_data);
/* Inicializar la lista QoS iface. */
op_prg_list_init (&qos_ifaces_list);
/*Comprobar la existencia del objeto QoS Attributes Config. Si no existe o no
está configurado,crea perfiles por defecto.*/
ip_rte_qos_attr_config_info ();[3]
/* Obtener y preprocesar la informacion de la IP QoS local */
ip_qos_info_process ((void *) &module_data, &qos_ifaces_list);[4]
/* Obtener el numero de interfaces con QoS activa */
total_num_of_qos_ifaces = op_prg_list_size (&qos_ifaces_list);
/* Reservar memoria para el array de datos de la interfaz QoS */
module_data.interface_qos_data_pptr =
(IpT_Rte_Iface_QoS_Data**)op_prg_mem_alloc(iface_table_size *
sizeof(IpT_Rte_Iface_QoS_Data *));
…
/* Crear una tabla para buscar el objid de cada interfaz*/
intf_objid_lookup_table =
ip_rte_proto_intf_attr_objid_table_build (module_data.ip_parameters_objid);
/* Recorrer todas las QoS active interfaces para inicializar parametros
relacionados con QoS como queuing schemes, CAR y RED/WRED. */
for (qos_iface_index = 0; qos_iface_index < total_num_of_qos_ifaces;
qos_iface_index ++)
{
112
Control de Congestión con OPNET
qos_iface_config_ptr = (IpT_QoS_Iface_Config *) op_prg_list_remove
(&qos_ifaces_list, OPC_LISTPOS_HEAD);
/* Obtener iface_info_ptr desde el nombre de la interfaz */
if (inet_rte_is_local_intf_name (qos_iface_config_ptr->iface_name,
&module_data,&iface_id,&iface_info_ptr, InetC_Addr_Family_Unknown))
{
…
/* Habilitar Queuing en esta Interfaz */
if (qos_iface_config_ptr->qm_attr_ptr != OPC_NIL)
{
iface_info_ptr->queuing_scheme =
qos_iface_config_ptr->queuing_scheme;
/* Crear una estructura para pasar objid del qos_information_attribute al
modelo de proceso ip_output_iface*/
intf_qos_info = (IpT_Qos_Info*)
op_prg_mem_alloc (sizeof (IpT_Qos_Info)); …
intf_qos_info->bandwidth_type
= qos_iface_config_ptr->bandwidth_type;
intf_qos_info->q_profile_name
= qos_iface_config_ptr->q_profile_name;
intf_qos_info->buffer_size
= qos_iface_config_ptr->buffer_size;
intf_qos_info->attribs_ptr
= qos_iface_config_ptr->qm_attr_ptr;
/* Crear y generar proceso hijo ip_output_iface para la interfaz.*/
iface_info_ptr->output_iface_prohandle =
op_pro_create ("ip_output_iface", &module_data.shared_mem);
module_data.shared_mem.iface_index = iface_id;
op_pro_invoke(iface_info_ptr->output_iface_prohandle, intf_qos_info);
}//Aquí acaba lo que nos concierne en el estudio de ip_dispatch.
...
}
A partir de este punto, se explican funciones implementadas en los ficheros externos declarados
mediante el menú File, a los que el modelo de proceso accede a través de las definiciones en el
Header Block. A continuación del nombre de cada función se detalla el fichero al que pertenecen:
3. ip_rte_qos_attr_config_info ();[ip_qos_attr_def_support.ex.c]
ip_rte_qos_attr_config_info ()
{
/** Comprueba la existencia de ip attribute object. **/
if (ip_attribute_object_exists == OPC_FALSE)
{
/* Comprueba la existencia del objeto mediante el registro de procesos. */
op_prg_list_init (&proc_record_handle_list);
oms_pr_process_discover (OPC_OBJID_INVALID, &proc_record_handle_list,
"protocol", OMSC_PR_STRING, "ip_qos_attribute_object", OPC_NIL);
if (op_prg_list_size (&proc_record_handle_list) == 0)
{/* Si no existe el nodo QoS, crea los valores por defecto. */
oms_qm_package_init ();
ip_rte_queuing_profiles_defaults_register ();}
}
113
Capítulo 4.Implementación del algoritmo RED en OPNET
FOUT;
}
Observar en esta función la llamada a oms_pr_process_discover, que es la que realmente detecta si
hay un atributo QoS global. Recordar que anteriormente, en el modelo de proceso estudiado en el
nodo QoS, se había registrado el nodo mediante oms_pr_process_register. Contando que dicho
nodo va a existir en todas las topologías utilizadas en este proyecto, el programa no llega a llamar a
las funciones oms_qm_package_init ni ip_rte_queuing_profiles_defaults_register en este punto.
Sólo tener en cuenta que dichas funciones son las que dan los valores QoS globales por defecto, en
caso que el usuario no haya añadido ese nodo a su red.
4. ip_qos_info_process ();
[ip_qos_support.ex.c]
OMSC_EXPORT void ip_qos_info_process (void * data_ptr, List * qos_ifaces_lptr)
{
Compcode status;
Objid attr_objid, iface_info_objid, sub_iface_info_objid, ith_attr_objid,
h_subiface_objid;
int
num_rows, num_sub_ifaces, i, j;
List
policies_list;
IpT_Rte_Module_Data
* module_data_ptr;
IpT_QoS_Profiles_Dbase * profiles_dbase_ptr;
/** Procesamiento de la información de las interfaces IP. **/
FIN (ip_qos_info_process (Objid attr_objid, qos_ifaces_lptr, ...));
/* Notificaciones */
ip_qos_notif_log_handles_init();
/* Hacer un cast para una variable local equivalente a module_data */
module_data_ptr = (IpT_Rte_Module_Data *) data_ptr;
/* Variable para guardar atributos IP QoS.*/
attr_objid = module_data_ptr->ip_qos_params_objid;
/* Acceso al atributos Interface Information del router, que guardará
información QoS pero esta vez de forma local, en el router. */
status = op_ima_obj_attr_get (attr_objid, "Interface Information" ,
&iface_info_objid);
/* Obtener el número de interfaces configuradas en el router. */
num_rows = op_topo_child_count (iface_info_objid, OPC_OBJTYPE_GENERIC);
/* Salir de ésta función si no hay interfaces configuradas. */
if (num_rows == 0)FOUT;
oms_qm_package_init ();/* Inicializa ciertos valores QoS */
op_prg_list_init (&policies_list);
/* Creación de base de datos para almacenar perfiles QoS locales. */
profiles_dbase_ptr = ip_qos_profiles_database_create (module_data_ptr);
/* Recorrer todas las interfaces IP del router. */
for (i = 0; i < num_rows; i++)
{
/* Recoger identificador del atributo interfaz */
ith_attr_objid = op_topo_child (iface_info_objid, OPC_OBJTYPE_GENERIC, i);
114
Control de Congestión con OPNET
/* Procesar la información en esta interfaz. */
ip_qos_iface_info_process (attr_objid, ith_attr_objid, qos_ifaces_lptr,
profiles_dbase_ptr, &policies_list, OPC_FALSE); [5]
/* Obtener información de subinterfaces. En nuestro caso está vacío*/
op_ima_obj_attr_get (ith_attr_objid, "Subinterface Information" ,
&sub_iface_info_objid);
/*Aquí hay procesamiento de subinterfaces, pero lo omitimos por no haber
configurado esa información. */
…
}
/* Liberar memoria */
ip_qos_local_profiles_memory_free (profiles_dbase_ptr, &policies_list);
FOUT;
}
En esta función se recorre el atributo compuesto Interface Information del nodo router . Como se
ve, en el atributo Subinterface Information, el valor es None, por eso no se ha tenido en cuenta su
procesamiento. No obstante, tener en cuenta como referencia para futuros análisis, que en caso de
querer configurar un router con subinterfaces distintas, una subinterfaz en realidad tiene idéntica
estructura a una interfaz, por lo que su procesamiento a la hora de recolectar parámetros QoS
también idéntico.
Ilustración 64. Árbol de atributos IP, Interface Information en un router, recorrido por la función
ip_qos_info_process
Las funciones resaltadas son interesantes por inicializar y reservar memoria para varios parámetros
relativos a QoS. No nos detendremos en ellas. Seguimos analizando la última función resaltada,
ip_qos_iface_info_process, que recorrerá el sub-atributo compuesto QoS Scheme, como veremos a
continuación.
115
Capítulo 4.Implementación del algoritmo RED en OPNET
5. ip_qos_iface_info_process ();
[ip_qos_support.ex.c]
static void ip_qos_iface_info_process (Objid qos_attr_objid, Objid iface_objid,
List * qos_ifaces_lptr,IpT_QoS_Profiles_Dbase * profiles_dbase_ptr, List *
policies_lptr, Boolean is_subiface)
{
Compcode status;
Objid qos_scheme_objid, hold_q_objid;
int
hold_q_capacity = -1, bandwidth;
char
iface_name [256];
IpT_QoS_Bandwidth_Type bw_type;
IpT_QoS_Iface_Info
* iface_qos_info_ptr;
IpT_QoS_Iface_Config * qos_iface_config_ptr = OPC_NIL;
/* Función que procesa la información de cada interfaz, incluyendo QoS. */
FIN (ip_qos_iface_info_process (Objid iface_objid, List * qos_ifaces_lptr,…));
/* Reservar memoria para la estructura QoS. */
iface_qos_info_ptr
= (IpT_QoS_Iface_Info *) op_prg_mem_alloc (sizeof (IpT_QoS_Iface_Info));
…
/* Initializar la estructura con valores
iface_qos_info_ptr->hold_q_capacity
=
iface_qos_info_ptr->reserved_bandwidth =
iface_qos_info_ptr->bandwidth_type
=
iface_qos_info_ptr->buffer_size
=
iface_qos_info_ptr->scheduling_info
=
iface_qos_info_ptr->red_info
=
iface_qos_info_ptr->in_shaping_info
=
iface_qos_info_ptr->out_shaping_info
=
por defecto. */
(int) OmsC_Buffer_Parent_Limit;
1.0;
IpC_QoS_Relative_Bandwidth;
1000000;
OPC_NIL;
OPC_NIL;
OPC_NIL;
OPC_NIL;
/* Obtención de varios atributos de la interfaz. */
op_ima_obj_attr_get (iface_objid, "Name" , iface_name);
op_ima_obj_attr_get (iface_objid, "Maximum Reserved Bandwidth" , &bandwidth);
op_ima_obj_attr_get (iface_objid, "Reserved Bandwidth Type" , &bw_type);
…
op_ima_obj_attr_get (iface_objid, "Buffer Size" ,
&iface_qos_info_ptr->buffer_size);
op_ima_obj_attr_get (iface_objid, "Hold Queue Capacity", &hold_q_objid);
op_ima_obj_attr_get (hold_q_objid, "Outbound", &hold_q_capacity);
…
/* Obtener el atributo QoS. */
status = op_ima_obj_attr_get (iface_objid, "QoS Scheme", &qos_scheme_objid);
/* Ordenar la información QoS para la interfaz. */
ip_qos_iface_attribute_sort (profiles_dbase_ptr, iface_qos_info_ptr,
qos_attr_objid,qos_scheme_objid, policies_lptr); [6]
/* Crear perfiles QoS para esta interfaz. */
ip_qos_iface_profiles_create (profiles_dbase_ptr, &qos_iface_config_ptr,
iface_qos_info_ptr, qos_attr_objid); [7]
…
FOUT;
}
116
Control de Congestión con OPNET
En la Ilustración 64 se ven los atributos recogidos por ésta función. Al ser QoS Scheme un atributo
compuesto, se utiliza la función resaltada ip_qos_iface_attribute_sort para registrarlo.
6. ip_qos_iface_attribute_sort ();
[ip_qos_support.ex.c]
static void ip_qos_iface_attribute_sort (IpT_QoS_Profiles_Dbase *
profiles_dbase_ptr, IpT_QoS_Iface_Info * iface_qos_info_ptr, Objid
qos_attr_objid, Objid qos_scheme_objid, List * policies_lptr)
{
Compcode status;
Objid
jth_attr_objid;
int
j, num_entries;
char
scheme_name [256];
IpT_QoS_Scheme_Type
scheme_type;
IpT_QoS_Mechanism_Info * qos_mechanism_info_ptr;
/* Esta función clasifica la información QoS configurada desntro de la interfaz
en una de las siguientes categorías: scheduling,in/out CAR y RED. Sólo se
muestra el código perteneciente al caso que nosotros tenemos: FIFO y AQM
(RED,WRED,GRED o cualquier otro algoritmo que se implemente)
*/
FIN (ip_qos_iface_attribute_sort (iface_qos_info_ptr,... ));
num_entries = op_topo_child_count (qos_scheme_objid, OPC_OBJTYPE_GENERIC);
for (j = 0; j < num_entries; j++)
{
jth_attr_objid = op_topo_child (qos_scheme_objid, OPC_OBJTYPE_GENERIC, j);
/* Recoge los atributos Type y Name*/
op_ima_obj_attr_get (jth_attr_objid, "Type", &scheme_type);
op_ima_obj_attr_get (jth_attr_objid, "Name", scheme_name);
/* Obtiene scheme_type para las condiciones de despues y lo guarda en la
estructura qos_mechanism_info_prt */
…
strcpy (qos_mechanism_info_ptr->profile_name, scheme_name);
qos_mechanism_info_ptr->type = scheme_type;
if ((scheme_type==IpC_QoS_In_Traffic_Policy) ||
(scheme_type==IpC_QoS_Out_Traffic_Policy))
{/* No es nuestro caso. */}
else
{
if ((scheme_type == IpC_QoS_DWFQ_Class_Based) ||
(scheme_type == IpC_QoS_FIFO) ||…
{/* This is a scheduling mechanism. */
if (iface_qos_info_ptr->scheduling_info == OPC_NIL)
{/*Nuestro caso, valor dado en
ip_qos_iface_info_process*/
iface_qos_info_ptr->scheduling_info =
qos_mechanism_info_ptr;
profile_not_used = OPC_FALSE;
}
else
{…}
}
…
FOUT;
}
En estas funciones en general no estamos asignando muchos valores porque ya se han configurado
de manera global. Por eso, parte del código se ha omitido.
117
Capítulo 4.Implementación del algoritmo RED en OPNET
7. ip_qos_iface_profiles_create ();
[ip_qos_support.ex.c]
static void
ip_qos_iface_profiles_create (IpT_QoS_Profiles_Dbase * profiles_dbase_ptr,
IpT_QoS_Iface_Config ** qos_iface_config_pptr,
IpT_QoS_Iface_Info * iface_qos_info_ptr, Objid qos_attr_objid)
{
char *
profile_name;
IpT_Queuing_Scheme
queuing_scheme;
IpT_QoS_Mechanism_Info *qos_mechanism_ptr, *red_info_ptr;
OmsT_Qm_Attributes
*qm_attr_ptr = OPC_NIL;
IpT_QoS_Iface_Config
qos_iface_config, *qos_iface_config_ptr = OPC_NIL;
Boolean
is_config_needed = OPC_FALSE;
/* Esta función crea perfiles QoS para las interfaces IP */
/* basada en la infomación contenida en iface_qos_info_ptr.*/
FIN (ip_qos_iface_profiles_create (profiles_dbase_ptr, qos_iface_config_ptr,
...));
/* Asignar el nombre de la interfaz. */
qos_iface_config.iface_name = iface_qos_info_ptr->iface_name;
qos_iface_config.qm_attr_ptr = OPC_NIL;
/* Ver si hay configuración de QoS scheduling en la interfaz. */
if (iface_qos_info_ptr->scheduling_info != OPC_NIL)
{
qos_mechanism_ptr = iface_qos_info_ptr->scheduling_info;
/* Coger la información RED. */
red_info_ptr = iface_qos_info_ptr->red_info;
profile_name = qos_mechanism_ptr->profile_name;
/* Obtener queuing scheme basándose en el tipo de perfil configurado. .*/
switch (qos_mechanism_ptr->type)
{…
case IpC_QoS_FIFO:
queuing_scheme = IpC_FIFO_Queuing;
qm_attr_ptr = ip_qos_fifo_profile_get (profiles_dbase_ptr,
iface_qos_info_ptr->hold_q_capacity,
qos_mechanism_ptr,red_info_ptr,qos_attr_objid); [8]
break;
…}
/* Guardar varios valores en la estructura qos_iface_config*/
qos_iface_config.queuing_scheme = queuing_scheme;
qos_iface_config.bandwidth_type = iface_qos_info_ptr->bandwidth_type;
qos_iface_config.reserved_bandwidth=iface_qos_info_ptr->reserved_bandwidth;
qos_iface_config.buffer_size = iface_qos_info_ptr->buffer_size;
qos_iface_config.qm_attr_ptr = qm_attr_ptr;
/* Guardar el nombre del perfil */
qos_iface_config.q_profile_name = (char *) op_prg_mem_alloc
(sizeof (char) * (strlen (profile_name) + 1));
strcpy (qos_iface_config.q_profile_name, profile_name);
is_config_needed = OPC_TRUE;
}
}
if (is_config_needed)
{
/* Reservar memoria para configuración de interfaz QoS. */
qos_iface_config_ptr = (IpT_QoS_Iface_Config *)
118
Control de Congestión con OPNET
op_prg_mem_alloc (sizeof (IpT_QoS_Iface_Config));
*qos_iface_config_ptr = qos_iface_config;
*qos_iface_config_pptr = qos_iface_config_ptr;
}
…
FOUT;
}
8. ip_qos_fifo_profile_get ();
[ip_qos_support.ex.c]
Esta función comprueba la existencia perfiles FIFO. Si ya existe (se ha configurado globalmente
mediante el atributo QoS), como es el caso, lo agrega a la interfaz del router de forma local. Si no,
crea uno por defecto.
static OmsT_Qm_Attributes * ip_qos_fifo_profile_get (IpT_QoS_Profiles_Dbase *
profiles_dbase_ptr,int hold_q_capacity, IpT_QoS_Mechanism_Info * qos_mechanism_ptr,
IpT_QoS_Mechanism_Info * red_info_ptr, Objid qos_attr_objid)
{
void *
tmp_ptr;
char *
profile_name;
Boolean
red_from_policy = OPC_FALSE;
OmsT_Qm_Attributes *
IpT_QoS_Profile_Entry *
OmsT_Qm_IP_Queue_Configuration *
OmsT_Qm_RED_Queue_Params *
qm_attr_ptr = OPC_NIL ;
profile_entry_ptr;
qconfig_ptr = OPC_NIL;
red_params_ptr = OPC_NIL;
/* Obtener el nombre del perfil. */
profile_name = qos_mechanism_ptr->profile_name;
/* Comprobar si el perfil ya existe en la base de datos local mediante la
función resaltada. Si es así, salir de la función. Si es default, crear perfil
por defecto */
profile_entry_ptr = (IpT_QoS_Profile_Entry *) ip_qos_profile_dbase_access
(profile_name, profiles_dbase_ptr, IpC_QoS_Scheduling_Profile,IpC_FIFO_Queuing,
OPC_NIL);
…
/* Veamos directamente el caso de un perfil configurado globalmente en la base
de datos, pero todavía no está en la local. Primero accedemos a la base de
datos global en busca del perfil*/
qm_attr_ptr = (OmsT_Qm_Attributes *)
oms_data_def_entry_access ("FIFO Profiles", profile_name);
/* Una vez encontrado, añade el perfil global al local del router desde la base
de datos mediante la siguiente función: */
ip_qos_profile_dbase_entry_add (profile_name, (void *) qm_attr_ptr, OPC_NIL,
profiles_dbase_ptr, IpC_QoS_Scheduling_Profile, IpC_FIFO_Queuing, OPC_NIL);
FRET (qm_attr_ptr);
}
Una vez realizadas todas estas llamadas (se ha podido seguir su secuencia gracias a los números
indicados entre corchetes), el control vuelve a la función ip_rte_qos_information_process, que crea
e invoca el modelo de procesos ip_output_iface. A continuación de muestra un esquema-resumen
de lo explicado en este apartado.
119
Capítulo 4.Implementación del algoritmo RED en OPNET
Ilustración 65. Esquema de llamadas desde ip_dispatch
Las funciones explicadas anteriormente se utilizan sobre todo para inicializar los valores referentes
a las interfaces y a establecer su configuración. Una vez que esto está hecho, se crea un hijo o
instancia del modelo de proceso ip_output_iface por cada interfaz IP detectada en el nodo router.
En cada uno de esos hijos se lleva a cabo la gestión de los paquetes que llegan a cada interfaz.
Por último, queda explicar dónde se declaran los procesos hijos, entre ellos ip_output_iface.
•
Declaración de procesos hijo
Para ver seleccionar los procesos que ip_dispatch puede crear, ir al menú File › Declare Child
Process Model Aparecerá una ventana con los distintos modelos de proceso y unas casillas al lado
que se pueden activar o desactivar dependiendo si queremos incluir o no instancias de ese modelo
en la jerarquía.
Sin embargo, si sólo queremos ver la lista de procesos hijo que puede crear y no modificarla, ir al
menú File › Open Child Process Model. Se desplegará una ventana en la que aparecen los procesos
hijos declarados:
120
Control de Congestión con OPNET
Ilustración 66. Ver los procesos hijos de ip_dispatch
Basta con seleccionar uno de ellos y aparecerá la correspondiente ventana del editor de procesos.
4.4.2.2 Análisis de ip_output_iface
Pinchar en el menú anterior en el ip_output_iface.
Aparecerá una nueva ventana del editor de procesos con el modelo de proceso ip_output_iface.
• Variables de estado
Viendo las variables de estado, se observan varias estructuras importantes, como OmsT_Qm_Info, o
IpT_Interface_Info. Más adelante se estudiarán con más detalle.
Estas variables son importantes porque, como se ha dicho en el Capítulo 3 serán las que vayan
guardando los valores que harán transitar el proceso de un estado a otro del STD. No se explicará
ninguna en concreto, pero se puede ver cómo van tomando valores a medida que se hacen llamadas
a las funciones tanto del function block como de los ficheros externos de tipo .ex.c.
121
Capítulo 4.Implementación del algoritmo RED en OPNET
Ilustración 67. Variables de estado de ip_output_iface
•
Variables temporales
Hay que mencionar la variable invocation_mode, que el proceso utiliza para saber de qué manera
está siendo invocado.
•
Header Block
Incluye el fichero de cabecera ip_qos_support.h, que a su vez incluye oms_qm.h.
Es importante el siguiente macro:
#define RECEIVE_PACKET
((invocation_mode == OPC_PROINV_INDIRECT) && (rsvp_call_type == RsvpC_Invalid))
Que dispara una interrupción ante cada llegada de un paquete.
•
Declaración de ficheros externos
Desde el menú File, como se indicó para el anterior modelo de proceso, se accede a la lista de
ficheros externos, entre los cuales cabe destacar de nuevo ip_qos_support.ex.c y oms_qm.ex.c.
122
Control de Congestión con OPNET
•
STD
Ilustración 68. STD del modelo de proceso ip_output_iface
- init: es el estado inicial y como se puede ver por su color verde, es un estado forzado, es decir, en
cuanto el proceso entra en este estado, ejecuta el estado (que no tiene ningún executive), y la
transición, para la cual no se necesita cumplir ninguna condición, bloqueándose en init2.
•
En la transición se produce la llamada a do_init, función definida en el bloque
de funciones o function block. Esta función inicializa variables, destacando la
variable de estado qm_info, de tipo OmsT_Qm_Info. Esta variable se configura
para cada interfaz. Contiene información general como el máximo número de
paquetes en cada cola, funcionamiento del procesador o lista de paquetes.
- init2: Estado que no tiene ningún executive.
•
En la transición, que al igual que la anterior no tiene condiciones, se llama a la
función allocate_buffers, definida en el function block. Lleva a cabo la
segunda fase de inicialización de las variables del proceso, que sólo se puede
efectuar cuando se ha completado la llamada do_init. A continuación se
presenta un extracto de dicha función.
static void allocate_buffers (void)
{
IpT_Rte_Iface_QoS_Data* iface_qos_data_ptr;
OmsT_Buffer_Pool_Handlebuffer_pool_handle;
charnew_name [200], intf_name[128];
doubleprocessing_rate;
123
Capítulo 4.Implementación del algoritmo RED en OPNET
FIN (allocate_buffers ());
buffer_pool_handle = (OmsT_Buffer_Pool_Handle) op_pro_argmem_access ();
/* Registro de funciones en una tabla global */
ip_qos_sup_functions_register (); [1]
/* Obtener los datos qos de la interfaz. */
iface_qos_data_ptr = shared_mem_ptr->iprmd_ptr->interface_qos_data_pptr
[interface_index];
…
/* Initializa la estructura qm_info.*/
qm_info = Oms_Qm_Info_Create [2](ip_rte_intf_index_get (interface_info_ptr),
processing_rate, ip_qos_info_assign [3],buffer_pool_handle,
queuing_processing_scheme, op_pro_self (), OmsC_Qm_IP, (void*)
intf_qos_info_ptr);
…
FOUT;
}
[1] La función ip_qos_sup_functions_register, implementada en ip_qos_support.ex.c,
OMSC_EXPORT void ip_qos_sup_functions_register (void)
{
…
OmsI_Arch_Specific_Func_Table [OmsC_Qm_IP][OmsC_Qm_Enqueue_Test_Func]
=(OmsT_Qm_Arch_Void_Func ) ip_qos_packet_enqueue_test;
OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Create_Func]
=(OmsT_Qm_Arch_Void_Func ) oms_qm_red_vars_create;
OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Update_Func]
=(OmsT_Qm_Arch_Void_Func ) oms_qm_red_variables_update;
OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Delete_Func]
=(OmsT_Qm_Arch_Void_Func ) oms_qm_red_variables_delete;
…
}
Es una función en la que se registran en la tabla global OmsI_Arch_Specific_Func_Table las
funciones que se ejecutan, estando las diferentes posiciones de la tabla asociadas a macros.
¡Atención. No se están invocando, sólo registrando. Su invocación vendrá más tarde! .
En el fichero oms_qm.h la tabla está definida de la siguiente forma:
extern OmsT_Qm_Arch_Void_Func OmsI_Arch_Specific_Func_Table
[OmsC_Qm_Max_Arch_Types] [OmsC_Qm_Max_Arch_Func_Types];
Observar que delante de la declaración está la palabra reservada extern, que como decíamos, hace
que una variable sea accesible desde todas las funciones.
También se definen las macros asociadas de ésta manera (el ejemplo corresponde a la primera de
las asignaciones mostradas en la función de arriba):
#define OMS_ENQ_TEST_FUNC (arch_type)
124
((OmsT_Qm_Enqueue_Test_Func)\
Control de Congestión con OPNET
OmsI_Arch_Specific_Func_Table [arch_type] [OmsC_Qm_Enqueue_Test_Func])
De esta forma, se crea un acceso de forma unificada a las funciones, por si hubiera distintas
arquitecturas con sus correspondientes funciones. Así, en vez de cambiar la invocación, se hacen
nuevas asignaciones a la tabla, pero la forma de acceder a ellas sigue siendo mediante la misma
macro.
[2] La función Oms_Qm_Info_create, definida en oms_qm.ex.c inicializa al principio la
estructura OmsT_Qm_Info. En ella se guardan atributos globales como el número máximo de
paquetes. También crea una estructura para guardar los paquetes.
OMSC_EXPORT OmsT_Qm_Info * Oms_Qm_Info_Create (int interface_index, double speed,
OmsT_Qm_Info_Assign_Func_Ptr assign_function_ptr,
OmsT_Buffer_Pool_Handle buffer_pool, OmsT_Qm_Queuing_Scheme q_scheme,
Prohandle qm_invoker_prohandle, OmsT_Qm_Arch_Type qm_client_type,
void* arch_info)
{
static Pmohandleqm_info_pmh = OPC_PMO_INVALID;
OmsT_Qm_Info *qm_info = OPC_NIL;
charintf_name [64];
…
oms_qm_qscheme_specific_functions_register ();
sprintf (intf_name, "Interface #%d", interface_index);
/* Inicialización y reserva de memoria para la estructura OmsT_Qm_Info.*/
qm_info = (OmsT_Qm_Info *) op_prg_pmo_alloc (qm_info_pmh);
…
/* Inicializar miembros de ésta estructura */
qm_info->child_queue_pool_ptr= OPC_NIL;
qm_info->default_queue_pool_ptr= OPC_NIL;
qm_info->qpool_in_service_ptr= OPC_NIL;
qm_info->buffer_pool_handle= OPC_NIL;
qm_info->arch_type= qm_client_type;
…
/* Creación de colas para esta interfaz y otras operaciones, dependiendo del
protocolo*/
assign_function_ptr (interface_index, speed, qm_info, buffer_pool);
…
/* Devolver la estructura qm_info con toda la información concerniente a las
colas de una interfaz. */
FRET (qm_info);
}
La función oms_qm_qscheme_specific_functions_register tiene una utilidad parecida a la función
explicada anteriormente: asocia funciones a la tabla global OmsI_Qscheme_Specific_Func_Table,
declarada en oms_qm.h. Esta tabla contendrá funciones específicas para cada disciplina de cola.
Para poner un ejemplo, a continuación se muestra una de las asignaciones hechas en la función,
cuando la estructura que se utiliza en la FIFO:
…
OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing][OmsC_Qm_Pkt_Deq_Complete]
= (OmsT_Qm_Qscheme_Void_Func) OPC_NIL;
OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing][OmsC_Qm_Queue_Select]
= (OmsT_Qm_Qscheme_Void_Func) Oms_Qm_FIFO_Queue_Select;
125
Capítulo 4.Implementación del algoritmo RED en OPNET
La invocación de las funciones asociadas se hará mediante macros, como en el caso anterior. Como
ejemplo de la declaración de esas macros en oms_qm.h:
#define OMS_PKT_DEQ_COMPLETE_FUNC(qscheme) ((OmsT_Qm_Pkt_Deq_Complete_Func)\
OmsI_Qscheme_Specific_Func_Table [qscheme][OmsC_Qm_Pkt_Deq_Complete])
#define OMS_QUEUE_SELECT_FUNC(qscheme) ((OmsT_Qm_Queue_Select_Func)\
OmsI_Qscheme_Specific_Func_Table [qscheme][OmsC_Qm_Queue_Select])
[3] La función ip_qos_info_assign, definida en ip_qos_support.ex.c, es específica del
protocolo IP, y asigna valores a ciertos campos de la estructura qm_info. Es una función
interesante, porque obtiene información de la base de datos global (recordemos que desde el nodo
QoS se había guardado ahí parte de esa información), como el nombre del perfil QoS, y accede a
datos de la memoria compartida. Inicializa colas dependiendo de los valores obtenidos, y devuelve
la estructura qm_info a la función Oms_Qm_Info_create que la llama desde su cabecera para seguir
asignando valores iniciales a otros campos de la estructura.
- Idle: en el exit executive comprueba de qué tipo es la invocación que le llega, y dependiendo de
eso, se cumplirá una condición u otra, y realizará una transición u otra de entre las posibles. Nos
hemos centrado en la condición RECEIVE_PACKET, definida en el header block, como se ha
mencionado. El resto de transiciones tienen que ver con peticiones RSVP, que no han sido
contempladas en los casos de estudio, por los que las omitimos.
•
Durante la transición, que se efectuará cada vez que llegue un paquete, se ejecuta
la función enqueue_packet, definida en el bloque de funciones. Esta función es
la que procesa cada paquete y decide qué hacer con él: descartarlo, marcarlo o
almacenarlo para posteriormente enviarlo.
Aquí acaba el estudio del STD. En las siguientes páginas se verá el conjunto de llamadas que
desencadena la invocación de enqueue_packet.
Al igual que se hizo en ip_dispatch, al lado de las funciones aparecerán números para facilitar
su seguimiento y unos corchetes a su derecha indicando dónde están.
•
Llamadas a funciones desde enqueue_packet: estudio de código fuente.
[1] enqueue_packet();
[Function Block]
Almacena el paquete recibido en una de las listas de la estructura qm_info. Si el procesador de la
interfaz está libre, se envía el paquete.
static void enqueue_packet (void)
{
Packet * pkptr = OPC_NIL;
intqueue_id = -1;
Ici *qos_ici_ptr = OPC_NIL;
OmsT_Qm_Signalqm_signal;
OmsT_Qm_Queue_Pool*q_pool_ptr = OPC_NIL;
126
Control de Congestión con OPNET
OmsT_Qm_Classifier_Func_Ptr classify_func_ptr = OPC_NIL;
/* Obtener el paquete.*/
pkptr = (Packet *) op_pro_argmem_access ()) == OPC_NIL
/*Asigna clasificacion por defecto*/
classify_func_ptr = ip_qos_classifier;[2]
/* Procesa el paquete que llega a la interfaz */
Oms_Qm_Packet_Process (pkptr, qm_info, classify_func_ptr, &q_pool_ptr,
&queue_id); [3]
/* En este punto ya se sabe lo que hacer con el paquete. Se han aplicado los
algoritmos pertinentes y el paquete se procesa conforme a ello. */
qm_signal = qm_info->signal;
/* Registrar estadísticas */
output_iface_stats_register [9](q_pool_ptr, queue_id);
if (qm_signal == OmsC_Qm_Dropped_Packet)
{
/* Cuando hay congestion el paquete se descarta. Se actualizan */
/* las estadísticas y se imprime un warning. */
qos_ici_ptr = op_pk_ici_get (pkptr);
/* Destruir el paquete */
…
}
else if (qm_signal == OmsC_Qm_Queued_Packet)
{
if (!qm_info->processor_busy)
{/* El procesador esta libre, todas las colas están vacías. */
/* Extraer el paquete, enviarlo y activar planificador.*/
/* Block variable declaration */
doublepkt_svc_completion_time;
OmsT_Qm_Queue_Info*q_info_ptr = OPC_NIL;
/* Si en procesador de interfaz esta en espera, el */
/* paquete se extrae y manda inmediatamente.*/
q_info_ptr = q_pool_ptr->queue_info_parray [queue_id];
/* Extraer paquete y actualizar estadisticas. Funcion definida */
/* en oms_qm.ex.c, 3387.*/
pkptr = oms_qm_packet_extract_handler (qm_info,
q_info_ptr, queue_id, &pkt_svc_completion_time, OPC_NIL);
qm_info->sending_packet_ptr = pkptr;
qm_info->processor_busy = OPC_TRUE;
/* planificar el borrado del paquete después de enviar */
output_iface_dequeue_schedule (pkptr, q_pool_ptr, pkt_svc_completion_time);
/* Enviar el paquete a la red. */
output_iface_packet_send (pkptr, queue_id);
}
}
FOUT;
}
[2]
ip_qos_classifier();
[ip_qos_support.ex.c]
127
Capítulo 4.Implementación del algoritmo RED en OPNET
Esta función obtiene el criterio para conceder prioridad al paquete que llega, accediendo a la
información de dicho paquete y basándose en el ToS . De esta forma, se permite al procesador
almacenar al paquete en la cola correcta (dependiendo de la planificación de colas adoptada).
OMSC_EXPORT OmsT_Qm_Pkt_Info ip_qos_classifier (Packet* pkptr, OmsT_Qm_Queue_Pool**
main_qpool_pptr, int* enq_id_ptr)
{
intoutgoing_phb;
Ici*ici_ptr;
OmsT_Qm_Pkt_Infoqm_pkt_info;
IpT_Pkt_Infopkt_info;
IpT_Dgram_Fields*pk_fd_ptr = OPC_NIL;
OmsT_Qm_Queue_Pool*sel_qpool_ptr = OPC_NIL, *main_qpool_ptr = OPC_NIL;
…
/* Inicializa la información del paquete mediante la siguiente función: */
ip_qos_pk_info_init (&pkt_info);
if (op_pk_nfd_is_set (pkptr, "MPLS Shim Header") == OPC_TRUE)
{
//Obtener el tamaño del paquete.
pkt_info.packet_size = (int) op_pk_total_size_get (pkptr);
ici_ptr = op_pk_ici_get (pkptr);/* Obtain reference to the ICI */
op_ici_attr_get (ici_ptr, "traffic_class", &outgoing_phb);
pkt_info.tos = (OmsT_Qm_Tos) outgoing_phb;
pkt_info.drop_precedence =
mpls_support_phb_to_drop_precedence_convert (outgoing_phb);
pkt_info.pk_fragment = OPC_FALSE;
}
else if(op_pk_nfd_access (pkptr, "fields" ,&pk_fd_ptr)!= OPC_COMPCODE_FAILURE)
{
int incoming_iface;
ici_ptr = op_pk_ici_get (pkptr);
op_ici_attr_get (ici_ptr, "incoming_iface", &incoming_iface);
/* Obtener el contenido del campo “fields" en el datagrama IP para saber el
ToS, protocolo, y las direcciones fuente y destino.*/
ip_qos_pk_info_get (pkptr, incoming_iface, pk_fd_ptr, &pkt_info);}
main_qpool_ptr = *main_qpool_pptr;
/* Aquí busca mediante una función en la jerarquía de colas una adecuada para
almacenar el paquete. Pero en nuestro caso, usamos una por defecto, pues sólo
aplicamos FIFO */
sel_qpool_ptr = main_qpool_ptr->qmgmt_info_ptr->default_queue_pool_ptr;
*enq_id_ptr = sel_qpool_ptr->attributes_ptr->default_queue;
/* Almacenar la información en la estructura adecuada. */
pkt_info.queue_id = *enq_id_ptr;
qm_pkt_info.ip_pkt_info = pkt_info;
FRET (qm_pkt_info);/* Devuelve la estructura a la función anterior */
}
En realidad, acabaremos teniendo valores por defecto porque en la configuración global, hemos
elegido un perfil básico FIFO sin ninguna distinción de prioridad (todos los paquetes tendrán la
misma, y se almacenan en la misma cola FIFO por defecto dentro del router), y los datos enviados
por todos los nodos de la red son de tipo FTP.
128
Control de Congestión con OPNET
Las funciones resaltadas ip_qos_pk_info_init, mpls_support_phb_to_drop_precedence_convert y
ip_qos_pk_info_get se han señalado por ser interesantes ya que describen el procesamiento de los
distintos campos de las estructuras que representan los paquetes. Realmente no implican ningún
cambio en la implementación del AMQ RED, por lo que aquí no se muestran, pero se deja a
elección del usuario estudiarlas por su interés a la hora de entender mejor los conceptos y las
estructuras usadas en la aplicación.
[3] Oms_Qm_Packet_Process
[oms_qm.ex.c]
Esta función determina el clasificador y envía el paquete a sus correspondientes procedimientos de
encolado.
OMSC_EXPORT void Oms_Qm_Packet_Process (Packet *pkptr, OmsT_Qm_Info* qm_info,
OmsT_Qm_Classifier_Func_Ptr classify_func_ptr,
OmsT_Qm_Queue_Pool** sel_pool_pptr, int *enqueue_id_ptr) {
OmsT_Qm_Queue_Pool*qpool_ptr = OPC_NIL;
OmsT_Qm_Pkt_Infopkt_info;
intenq_id = OMSC_UNASSIGNED;
/* Primero mira la disciplina de cola usada */
switch (qm_info->queue_processing_scheme)
{
case OmsC_Qm_FIFO_Queuing:
…
{
qpool_ptr = qm_info->child_queue_pool_ptr;
/* Encontrar la cola a la que este paquete pertenece */
pkt_info = classify_func_ptr (pkptr, &qpool_ptr, &enq_id);
*enqueue_id_ptr = enq_id;
/* Basándose en el status del procesador, guardar o enviar el paquete */
Oms_Qm_Incoming_Packet_Handler (pkptr, qm_info, qpool_ptr, enq_id,
pkt_info);[4]
if (OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC
(qm_info->queue_processing_scheme) != OPC_NIL)
(OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC (qm_info->queue_processing_scheme))
(pkptr, qm_info, qpool_ptr, enq_id);
break;
}
case OmsC_Qm_No_Queuing:
{
qm_info->signal = OmsC_Qm_Send_Packet;
break;
}
default:break;
}
…
FOUT;
}
[4] Oms_Qm_Incoming_Packet_Handler
[oms_qm.ex.c]
129
Capítulo 4.Implementación del algoritmo RED en OPNET
Función que maneja los paquetes recibidos. Obtiene si hay espacio para el paquete en el buffer o
no. También actualiza estadísticas y variables de tiempo para futuros cómputos como por ejemplo
retrasos en la red.
static void Oms_Qm_Incoming_Packet_Handler (Packet* pkptr, OmsT_Qm_Info* qm_info,
OmsT_Qm_Queue_Pool* qpool_ptr, int enqueue_q_id, OmsT_Qm_Pkt_Info pkt_info)
{
doublecurrent_time;
Ici*oms_qm_ici_ptr = OPC_NIL;
doubleinsertion_time;
charqm_trace [64], mu_sim_trace [64];
OmsT_Qm_Queue_Info *q_info_ptr = OPC_NIL;
…
insertion_time = current_time = op_sim_time ();
oms_qm_ici_ptr = op_pk_ici_get (pkptr);
q_info_ptr = qpool_ptr->queue_info_parray[enqueue_q_id];
…
/* Almacenar el paquete en el buffer */
insert_ok = Oms_Qm_Packet_Enqueue (pkptr, qm_info, q_info_ptr,
pkt_info, current_time, enqueue_q_id);[5]
…
if (insert_ok == OPC_FALSE)
{/* El buffer se desborda. Descartar el paquete*/
qm_info->signal = OmsC_Qm_Dropped_Packet;
…
/* Destruir el paquete. */
}
else
{/* Almacenar el paquete */
qm_info->signal = OmsC_Qm_Queued_Packet;
…
FOUT;
}
[5] Oms_Qm_Packet_Enqueue
[oms_qm.ex.c]
Almacena el paquete en la cola correcta basándose en los argumentos de invocación. También
identifica si hay congestión. En éste caso, se aplica el algoritmo seleccionado para restringir el
tamaño de la cola. Devuelve TRUE si el paquete se ha insertado en la cola con éxito, y FALSE en
caso contrario.
OMSC_EXPORT Boolean Oms_Qm_Packet_Enqueue (Packet* pkptr, OmsT_Qm_Info* qm_info,
OmsT_Qm_Queue_Info* q_info_ptr,OmsT_Qm_Pkt_Info pkt_info,
double insert_time, int PRG_ARG_UNUSED (enqueue_q_id))
{
if ((OMS_ENQ_TEST_FUNC (qm_info->arch_type)) [6]
(qm_info, q_info_ptr, pkptr, pkt_info) == OmsC_Buffer_Insert_After)
{
if (oms_buffer_enqueue (q_info_ptr->buffer_handle, pkptr, OPC_NIL, insert_time)
!= OmsC_Buffer_Enqueue_Success)
{FRET (OPC_FALSE);}
}
else
{FRET (OPC_FALSE);}
130
Control de Congestión con OPNET
FRET (OPC_TRUE);
}
[6] ip_qos_packet_enqueue_test ();
[ip_qos_support.ex.c]
Como se ha visto en páginas anteriores, la macro OMS_ENQ_TEST_FUNC se había definido en
oms_qm.h y se había asignado a esta función a través de ip_qos_sup_functions_register de
manera que al aparecer esa macro en el texto, se invoca ip_qos_packet_enqueue_test.
Esta función comprueba si el paquete puede ser encolado, basándose en el espacio disponible y en
el nivel de congestión de la red en ese momento, caso en el cual se pueden aplicar distintas
disciplinas. De hecho en esta función es donde se elige si aplicar AQM, y cual aplicar. Así, aquí se
ven las llamadas a las funciones específicas de cómputo del algoritmo RED. Es, por lo tanto, una
de las más relevantes.
OMSC_EXPORT OmsT_Buffer_Insert ip_qos_packet_enqueue_test (OmsT_Qm_Info* qm_info,
OmsT_Qm_Queue_Info* q_info_ptr, Packet* pkptr, OmsT_Qm_Pkt_Info qm_pkt_info)
{
intmax_number_of_pkts, max_subqueue_size;
intcurrent_total_number_of_pkts, current_number_of_pkts;
doublecurrent_total_number_of_bytes, packet_size;
intqueue_id;
IpT_Pkt_Infoip_pkt_info;
Booleanpkt_drop = OPC_FALSE, red_drop_status = OPC_FALSE
IpT_Dgram_Fields* ip_dgram_fields_ptr = OPC_NIL;
OmsT_Qm_RED_Vars*red_vars_ptr = OPC_NIL;
OmsT_Qm_Attributes*ip_attribs_ptr = OPC_NIL;
OmsT_Buffer_Pool_Handlebuffer_pool;
OmsT_Qm_IP_Queue_Configuration*queue_config_ptr = OPC_NIL;
…
ip_pkt_info = qm_pkt_info.ip_pkt_info;
queue_id = ip_pkt_info.queue_id;
ip_attribs_ptr = q_info_ptr->parent_queue_pool_ptr->attributes_ptr;
buffer_pool = qm_info->buffer_pool_handle;
…
queue_config_ptr = (OmsT_Qm_IP_Queue_Configuration *)
ip_attribs_ptr->queue_configuration [queue_id];
/* Obtener el valor del máximo número de paquetes en la cola.*/
max_number_of_pkts = ip_attribs_ptr->max_total_no_buf_pkts;
/* Obtener número actual de paquetes almacenados en todo el conjunto de colas*/
current_total_number_of_pkts = oms_buffer_pool_num_packets_get (buffer_pool);
/* Obtener el número de paquetes almacenados en esta cola */
current_number_of_pkts =
oms_buffer_num_packets_get (q_info_ptr->buffer_handle);
/* Máximo número de paquetes permitido en períodos de congestión..*/
max_subqueue_size = queue_config_ptr->max_size;
/* Computar el tamaño medio de cola para RED, WRED, GRED, etc. */
if (queue_config_ptr->red_status != OMSC_NO_RED)
{
Oms_Qm_Average_Queue_Size_Update [7](q_info_ptr,
queue_config_ptr->red_queue_params_ptr->exponential_weight_factor);
131
Capítulo 4.Implementación del algoritmo RED en OPNET
}
/* Obtener el tamaño del paquete en bytes.*/
packet_size = (double) op_pk_total_size_get (pkptr) / 8;
current_total_number_of_bytes = oms_buffer_pool_num_bytes_get (buffer_pool);
/* Hay 5 condiciones para decidir si se puede encolar el paquete. */
/* 1. Si no hay espacio en el buffer, descartar paquete.*/
/* 2. Si hay espacio, aceptar paquetes directamente. */
/* 3. Si va dirigida a una LLQ, comprobar si hay congestión. En caso que si,
forzar el límite LLQ.*/
/* 4. Para situaciones de RSVP …*/
/* 5. Si no hay espacio basándose en un límite, forzar un algoritmo para
controlarlo. */
/* ----CHECK #1----- Comprobar espacio*/
if (packet_size + current_total_number_of_bytes > qm_info->max_buffer_size)
{
/* Buffer lleno descartar paquete */
FRET (OmsC_Buffer_Insert_Units_Overflow);
}
/* ----CHECK #2----- */
else if ((ip_pkt_info.protocol == IpC_Protocol_Ospf) ||
(ip_pkt_info.protocol == IpC_Protocol_Igrp) ||
(ip_pkt_info.protocol == IpC_Protocol_Eigrp))
{
/* Para paquetes de control, guardarlo si no se excede el tamaño del buffer sin
hacer otros cálculos.*/
FRET (OmsC_Buffer_Insert_After);
}
/* ----CHECK #3----- */
/* Cuando LLQ está configurado. No nos detenemos en ello. */
/* ----CHECK #4----- */
/* Cuando RSVP está configurado. No nos detenemos en ello. */
/* ----CHECK #5----- */
{/* Comparar el número de paquetes en el buffer con el número permitido.SI es
mayor que lo permitido, aplicar el algoritmo elegido. Este es el check
utilidado en caso de configurar AQM*/
if ((current_total_number_of_pkts >= max_number_of_pkts) &&
((int) current_number_of_pkts >= max_subqueue_size))
{
pkt_drop = OPC_TRUE;
else if (!is_micro_sim_pkt && queue_config_ptr->red_status != OMSC_NO_RED)
{
red_vars_ptr = (OmsT_Qm_RED_Vars*) q_info_ptr->drop_policy_vars_ptr;
/* Comprobar si RED necesita descartar este paquete. */
red_drop_status =
oms_qm_red_packet_drop [8](red_vars_ptr->average_queue_size,
queue_config_ptr->red_status,
queue_config_ptr->red_queue_params_ptr, ip_pkt_info.tos);
/*Si está acitvado CE marking, en vez de descartar, marcar el paquete.
if ((red_drop_status == OPC_TRUE) &&
(queue_config_ptr->red_queue_params_ptr->ce_marking == OPC_TRUE))
{
pkt_drop = OPC_FALSE;/* No descartar */
op_pk_nfd_access(pkptr,"fields",&ip_dgram_fields_ptr);
if (ip_dgram_fields_ptr->ECT == OPC_TRUE)
{/*Marcar el paquete indicando congestión y almacenarlo.*/
132
Control de Congestión con OPNET
ip_dgram_fields_ptr->CE = 1;
}//fin_if(ip_dgram_fields_ptr->ECT == OPC_TRUE)
}//fin_if
else if (red_drop_status == OPC_TRUE)
{
/* Descartar el datagrama. */
pkt_drop = OPC_TRUE;
strcpy (disp_string1, "Packet dropped on RED's drop policy");
}
}
if (pkt_drop)
{
/* The packet can be dropped due to insufficient buffer or RED policy */
FRET (OmsC_Buffer_Insert_Ignore_Element);
}
}
/* El paquete es aceptado, y almacenado el ultimo. */
FRET (OmsC_Buffer_Insert_After);
}
[7] Oms_Qm_Average_Queue_Size_Update ;
[oms_qm.ex.c]
Esta función actualiza el parámetro Tamaño medio de cola o Average_queue_size, usado por RED
para determinar si un paquete debe ser descartado debido a la congestión. Esta función se utiliza
cada vez que un paquete entra en el sistema.
OMSC_EXPORT void Oms_Qm_Average_Queue_Size_Update
(OmsT_Qm_Queue_Info* queue_info_ptr, int exp_weight_factor)
{
doubleavge_queue_size, wq, m, last_start_idle_time;
intqueue_size;
doubletypical_transmission_time_for_a_small_packet = 0.001;
…
/* Obtener los parámetros para calcular average queue size.*/
avge_queue_size = ((OmsT_Qm_RED_Vars *)
queue_info_ptr-> drop_policy_vars_ptr)->average_queue_size;
queue_size = (int) oms_buffer_num_packets_get (queue_info_ptr->buffer_handle);
wq = pow (0.5, exp_weight_factor);
last_start_idle_time = ((OmsT_Qm_RED_Vars *)
queue_info_ptr->drop_policy_vars_ptr)->start_idle_time;
/* Una vez obtenidos los parámetros, hacer el cálculo.*/
if (queue_size == 0)
{ m = (op_sim_time () - last_start_idle_time) /
typical_transmission_time_for_a_small_packet;
avge_queue_size = pow ((1 - wq), m) * avge_queue_size;
}
else
{ avge_queue_size = (avge_queue_size * (1 - wq)) + (queue_size * wq);}
/* Actualizar el parámetro average queue size en la estructura de datos. */
((OmsT_Qm_RED_Vars *)queue_info_ptr->drop_policy_vars_ptr)->average_queue_size=
avge_queue_size;
FOUT;
}
133
Capítulo 4.Implementación del algoritmo RED en OPNET
Como se ve en la función, se calcula el tamaño de cola utilizando la fórmula de RED ya vista en la
teoría,
Qavg = (1 − ωq) Qavg + ωq Qavg
siempre y cuando el tamaño de cola actual no sea cero. Si no, tiene en cuenta el tiempo pasado
desde el último paquete recibido, para que el algoritmo sea más eficiente.
[8] oms_qm_red_packet_drop;
[oms_qm.ex.c]
Esta función implementa el comportamiento del algoritmo RED y su variante WRED. Además, es
donde se ha modificado el código para añadir la variante Gentle Red o GRED que se ha ido viendo
a lo largo del documento.
Se devuelve como resultado si el paquete se debe descartar por probabilidad o no.
OMSC_EXPORT Boolean oms_qm_red_packet_drop (doubleavge_queue_size, int
red_status,OmsT_Qm_RED_Queue_Params* red_queue_params_ptr, int dscp)
{
int
ip_precedence;
int
discard_class;
int
i, num_entries;
intmin_threshold, max_threshold, mark_prob_denominator;
doublerandom_number, dropping_probability, maxp;
Booleanmatch_found = OPC_FALSE;
OmsT_Qm_RED_Class_Params* red_class_params_ptr = OPC_NIL;
OmsT_Qm_RED_Class_Params* default_red_class_params_ptr = OPC_NIL;
OmsT_Qm_Property_Type red_match_property = OmsC_Qm_Ip_Precedence;
/* Cálculos necesarios para la variante WRED. */
red_match_property = red_queue_params_ptr->match_property;
num_entries = op_prg_list_size(red_queue_params_ptr->red_class_params_lptr);
for(i = 0; i < num_entries; i++)
{
red_class_params_ptr = (OmsT_Qm_RED_Class_Params *)
op_prg_list_access (red_queue_params_ptr->red_class_params_lptr, i);
/* Si estamos en el caso por defecto */
if(red_class_params_ptr->match_value == OmsC_Qm_Best_Effort)
default_red_class_params_ptr = red_class_params_ptr;
switch(red_match_property)
{
case OmsC_Qm_Discard_Class:
discard_class = (int) ((dscp & 24 ) >> 3);
if(red_class_params_ptr->match_value == discard_class)
match_found = OPC_TRUE;
break;
case OmsC_Qm_Dscp:
if(red_class_params_ptr->match_value == dscp)
match_found = OPC_TRUE;
break;
case OmsC_Qm_Ip_Precedence:
134
Control de Congestión con OPNET
/* Uso de mascaras para obtener la IP Precedence (0 a 7).
ip_precedence = (int) dscp/32;
if(red_class_params_ptr->match_value == ip_precedence)
match_found = OPC_TRUE;
break;
default:break;
}
if(match_found == OPC_TRUE)
break;
}
*/
/* En caso de Best Effort, aplicar valores por defecto. */
if (match_found == OPC_FALSE)
{
red_class_params_ptr = default_red_class_params_ptr;
}
/* Obtener los umbrales máximo y mínimo.*/
max_threshold = red_class_params_ptr->maximum_threshold;
min_threshold = red_class_params_ptr->minimum_threshold;
/* Obtener el denominador de probabilidad máxima. Este parámetro es la fracción
de paquetes descartados cuando el tamaño medio de cola alcanza el umbral
máximo. */
mark_prob_denominator = red_class_params_ptr->mark_probability_denominator;
/* Si WRED está habilitado, se modifica el umbral mínimo, que depende de la IP
precedence. OMSC_WRED solo se configura globalmente desde el icono IP QoS
Config (nuestro nodo QoS en la topología) */
if (red_status == OMSC_WRED)
{
/* Extraer la IP precedence de los tres primeros bits del valor ToS/DSCP. */
ip_precedence = (int) dscp/32;
min_threshold = min_threshold +
(max_threshold - min_threshold) * ip_precedence/ 7;
}
/* Si el tamaño medio de cola cae entre los umbrales máximo y mínimo, descartar
el paquete aleatoriamente con una probabilidad. */
if ((avge_queue_size >= min_threshold) && (avge_queue_size < max_threshold))
{
/* Calcular la probabilidad de pérdida de este paquete.*/
dropping_probability =
1.0 / mark_prob_denominator * (avge_queue_size - min_threshold) /
(max_threshold - min_threshold);
/* Obtener un número aleatorio. */
random_number = op_dist_uniform (1.0);
FRET ((Boolean) (random_number <= dropping_probability));
}
else
/* CODIGO AÑADIDO PARA IMPLEMENTACIÓN DE GRED */
{
if ((red_status == OMSC_GRED) && (avge_queue_size >= max_threshold)
&& (avge_queue_size < max_threshold*2))
{/* Con GRED habilitado, el algoritmo varia su comportamiento cuando se
excede el umbral máximo. En vez de descartar todos los paquetes
directamente, varía la fórmula para que se aumente la probabilidad
desde maxp o probabilidad máxima hasta uno. */
maxp = 1.0 / mark_prob_denominator;
dropping_probability =((1.0-maxp)*
(avge_queue_size-max_threshold))/max_threshold + maxp;
random_number = op_dist_uniform (1.0);
135
Capítulo 4.Implementación del algoritmo RED en OPNET
FRET ((Boolean) (random_number <= dropping_probability));
}
FRET ((Boolean) (avge_queue_size >= max_threshold));
}
}
Este es el código que se ha añadido en oms_qm.ex.c para la implementación de la variante
GRED. Como se ve, sólo entra en funcionamiento si el tamaño medio de cola (o parámetro
avge_queue_size) excede el umbral máximo, implementado en forma de condición if. Así, se
calcula la probabilidad de pérdida de paquetes como ya se dijo en el bloque de teoría, a partir de la
fórmula
Pd_gred =(1- Maxp)(Qavg − Maxth) / (Maxth) + Maxp
Si
Maxth<Qavg<2*Maxth
Por último, después de haber calculado lo que hacer con el paquete, se deben actualizar
estadísticas, lo cual se hace de nuevo en la función del function block enqueue_packet,
utilizando output_iface_stats_register:
[9] output_iface_stats_register;
[function block]
Registra estadísticas para una cola para mostrarlas cuando el usuario lo requiere. A continuación se
muestra la parte de la función relativa a AQM:
static void output_iface_stats_register(OmsT_Qm_Queue_Pool* qpool_ptr, int q_index)
{
charqueuing_scheme [256], new_name [256], intf_name [128];
charstat_annotation_str [256], queue_category_str [80]="\0";
intq_label, red_status;
Booleanllq_flag = OPC_FALSE;
Objidmy_id;
OmsT_Qm_Queue_Info*qinfo_ptr = OPC_NIL;
OmsT_Dim_Stat_Handledim_stathandle;
qinfo_ptr = qpool_ptr->queue_info_parray [q_index];
/* Obtener la ID del proceso.*/
/* Obtener el nombre del esquema de cola. */
/* Inicializar estadísticas para Buffer Usage (packets y bytes), queuing delay,
jitter, tráfico descartado, enviado y recibido. */
/* Registrar estadísticas para RED si está habilitado.*/
(OMS_ATTRIBUTE_GET_FUNC (OmsC_Qm_IP))
(qpool_ptr, OmsC_Qm_RED_Status, q_index, &red_status);
if (red_status == OMSC_RED)
{
sprintf (new_name, "RED Average Queue Size %s Q%d%s",
intf_name, q_label, queue_category_str);
dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "RED Average Queue
Size", stat_annotation_str, OPC_STAT_LOCAL);
Oms_Dim_Stat_Rename (dim_stathandle, new_name);
136
Control de Congestión con OPNET
oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle);
}
else if (red_status == OMSC_WRED)
{
/* Registrar estadísticas para WRED si está habilitado.*/
sprintf (new_name, "WRED Average Queue Size %s Q%d%s",
intf_name, q_label, queue_category_str);
dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "RED Average Queue
Size", stat_annotation_str, OPC_STAT_LOCAL);
Oms_Dim_Stat_Rename (dim_stathandle, new_name);
oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle);
}
else if (red_status == OMSC_GRED)
{ /* CÓDIGO AÑADIDO */
/* Registrar estadísticas para GRED si está habilitado.*/sprintf (new_name,
"GRED Average Queue Size %s Q%d%s",intf_name, q_label, queue_category_str);
dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "GRED Average Queue
Size", stat_annotation_str, OPC_STAT_LOCAL);
Oms_Dim_Stat_Rename (dim_stathandle, new_name);
oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle);
}
…
FOUT;
}
Y con esto acabaría la sucesión de llamadas que procesan un paquete desde su llamada hasta la
ejecución del AQM para decidir si descartar/marcar un paquete o no.
En la siguiente página se muestra un esquema con las llamadas implicadas desde el modelo de
proceso ip_output_iface, indicando el orden en que se producen y agrupadas por fichero donde
fueron implementadas, al igual que se hizo con el modelo de proceso ip_dispatch, con el fin de
aportar un poco de claridad a lo que se ha explicado.
137
Capítulo 4.Implementación del algoritmo RED en OPNET
Ilustración 69. Esquema de llamadas desde ip_output_iface
•
Otras funciones que participan en la implementación del AQM RED.
Además de lo explicado aquí, quedarían varias llamadas a funciones para actualizar las variables y
estructuras de RED, borrarlas, etc. En este caso, por ser un acercamiento a lo que es el
funcionamiento de OPNET en general y al procesamiento en los routers de los AQM en particular,
138
Control de Congestión con OPNET
no nos centraremos en esas funciones. En caso de querer añadir nuevos algoritmos de gestión
Activa de Colas, habría que modificarlas, pues habría que añadir nuevas estructuras o ampliar las
existentes, y luego llevar a cabo su inicialización y borrado, o acceder a la base de datos global para
obtener y almacenar sus valores.
También se debe tener en cuenta que hemos estudiado la implementación desde el punto de vista de
la configuración de atributos QoS global, y no en el router de forma local, por lo que si se quiere
extender la implementación al router, habría que modificar funciones a mayores .
A continuación se cita una recopilación de todas las funciones examinadas para este proyecto
Fichero OPNET
Función
ip_dispatch.pr.c
ip_dispatch_cleanup_and_create_child_processes
ip_rte_qos_informacion_process
ip_output_iface.pr.c
do_init
allocate_buffers
enqueue_packet
output_iface_stats_register
qos_attribute_definer.pr.c
attr_def_fifo_profiles_info_parse
attr_def_red_parameters_get
ip_qos_attr_def_support.ex.c
ip_rte_qos_attr_config_info
ip_rte_queuing_profiles_defaults_register
ip_qos_support.ex.c
ip_qos_sup_functions_register
ip_qos_queue_config_element_mem_alloc
ip_qos_red_queue_params_mem_alloc
ip_qos_red_class_params_mem_alloc
ip_qos_attribute_value_get
ip_qos_packet_enqueue_test
ip_qos_iface_info_process
ip_qos_iface_attribute_sort
ip_qos_policy_process
ip_qos_iface_profiles_create
ip_qos_profiles_database_create
ip_qos_local_profiles_memory_free
ip_qos_iface_qos_info_destroy
ip_qos_profile_dbase_access
ip_qos_profile_dbase_add
ip_qos_red_profile_get
ip_qos_red_profile_attach
ip_qos_fifo_profile_get
Oms_Qm_Average_Queue_Size_Update
oms_qm_red_packet_drop
oms_qm_red_vars_create
139
Capítulo 4.Implementación del algoritmo RED en OPNET
oms_qm_red_variables_update
oms_qm_red_variables_delete
oms_qm_initialize_all_pools
oms_qm_support_queues_create
oms_qm_support_queue_add
oms_qm_support_queue_remove
oms_qm.ex.c
4.5 Esquema-resumen para la implementación
de GRED
En los puntos 4.3 y 4.4 de este capítulo se ha explicado detalladamente qué pasos se han seguido
para modificar el algoritmo RED proporcionado por OPNET. En este apartado se describen esos
pasos de manera concisa y práctica, sin entrar en detalles teóricos, a modo de recordatorio o
recopilación de lo contado hasta ahora.
4.5.1 Modificación de código en ficheros externos
Abrir mediante un editor de texto o código los ficheros nombrados a continuación
4.5.1.1 oms_qm.h
Se añade la constante:
#define
OMSC_GRED
3
Que servirá como identificador de la versión Gentle de RED a la hora de seleccionarlo como
atributo en el nodo QoS.
4.5.1.2 oms_qm.ex.c
Se añade dentro de la función oms_qm_red_packet_drop el siguiente código
if ((avge_queue_size >= min_threshold) && (avge_queue_size < max_threshold))
{
…
}
else
/* CODIGO AÑADIDO PARA IMPLEMENTACIÓN DE GRED */
{
if ((red_status == OMSC_GRED) && (avge_queue_size >= max_threshold)
&& (avge_queue_size < max_threshold*2))
{
/* Con GRED habilitado, el algoritmo varia su comportamiento cuando se
excede el umbral máximo. En vez de descartar todos los paquetes
directamente, varía la fórmula para que se aumente la probabilidad
140
Control de Congestión con OPNET
desde maxp o probabilidad máxima hasta uno. */
maxp = 1.0 / mark_prob_denominator;
dropping_probability =
((1.0-maxp)* (avge_queue_size- max_threshold))/max_threshold + maxp;
random_number = op_dist_uniform (1.0);
FRET ((Boolean) (random_number <= dropping_probability));
}
cuya función es evitar que se descarten paquetes cuando se ha sobrepasado el umbral máximo en
RED .
4.5.2 Modificación del modelo de procesos ip_output_iface
•
Desde el editor de proyectos, entrar en el modelo de nodos de uno de los router (doble clic
sobre él).
•
Entrar en el modelo de procesos del módulo ip (doble clic sobre el módulo).
•
En el modelo de procesos ip_dispatch, acceder al menú File › Open Child Process
Model… › ip_output_iface
•
Ya en el editor de procesos de ip_output_iface.pr.c acceder a Function block.
•
Se añade en la función output_iface_stats_register otra condición más para
mostrar la estadística tamaño medio de cola de GRED:
static void output_iface_stats_register(OmsT_Qm_Queue_Pool* qpool_ptr, int q_index)
{
if (red_status == OMSC_RED)
{…}
…
else if (red_status == OMSC_GRED)
{ /* CÓDIGO AÑADIDO */
/* Registrar estadísticas para GRED si está habilitado.*/
sprintf (new_name, "GRED Average Queue Size %s Q%d%s",intf_name, q_label,
queue_category_str);
dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "GRED Average Queue
Size", stat_annotation_str, OPC_STAT_LOCAL);
Oms_Dim_Stat_Rename (dim_stathandle, new_name);
oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle);
}…
•
Guardar los cambios a partir del menú de la ventana de bloque de funciones, File ›
Commit.
141
Capítulo 4.Implementación del algoritmo RED en OPNET
•
Compilar el modelo de proceso (es necesario este caso después de haber modificado el
código), a partir del menú Compile del editor de procesos, o mediante el botón de acceso
directo .
4.5.3. Modificación de atributos del nodo QoS
Una vez modificado el código, hay que permitir que el usuario seleccione el algoritmo. Para ello
añadíamos una nueva opción en el árbol de atributos del nodo QoS de la siguiente manera:
•
Acceder al modelo de nodos del nodo QoS (doble clic sobre el nodo en el editor de
proyectos).
•
Acceder al modelo de procesos del nodo, qos_attribute_definer.
•
Acceder a la tabla de atributos a través del menú Interfaces › Model Attributes.
•
Editar los atributos que van apareciendo en el siguiente orden
FIFO Profiles › Details › RED Parameters › RED Status
•
Una vez seleccionado RED Status, pulsar el botón Edit Compound Attribute Properties.
•
En la ventana que aparece (Attribute: RED Parameters), seleccionar en el campo Attribute
properties Private para pasar a editar el atributo de forma privada. Pulsar OK.
•
De vuelta en la ventana anterior, seleccionar de nuevo RED Status, pero esta vez pulsar en
el botón Edit Properties.
•
Aparece una nueva ventana, con un nuevo Symbol map. Añadir el nuevo valor GRED en
el campo Symbol Map y asignarle el valor 3 (que es el que se ha asignado a la constante
OMSC_GRED en oms_qm.h). Pulsar OK para volver a la ventana anterior.
De nuevo en la ventana de los atributos de RED Parameters, volvemos a pulsar Edit
Compound Attribute Properties. Ya en la ventana, volver al dominio público
habilitando la casilla Public.
•
142
•
Pulsar en el botón Save Public. Dar nombre al nuevo fichero con las propiedades del
atributo y pulsar OK.
•
Pulsar OK en las siguientes ventanas hasta terminar en la ventana del editor de procesos
de nuevo. En este punto ya está añadido el nuevo valor GRED para elegir desde el Editor
de Proyectos.
Control de Congestión con OPNET
Capítulo 5. Experimentos
5.1 Introducción
En este capítulo se muestran algunos de los experimentos realizados para este proyecto, tanto
variando las topologías, como los AQM utilizados o los tipos de estadísticas recogidos.
5.2 Topologías utilizadas
Las topologías siguen todas el esquema llamado “cuello de botella” o bottleneck, consistente en
nodos emisores que envían datos a través de conexiones rápidas, provocando que lleguen al router
más datos de los que puede procesar, desembocando en la correspondiente congestión de red. La
clave para ello está en que la conexión entre los routers sea sensiblemente más lenta que el resto de
las conexiones de la red.
En los siguientes puntos se detallarán todas las topologías utilizadas para realizar los experimentos
de este proyecto.
5.2.1 CuelloBotella
Es la topología ya conocida utilizada para describir el modelado en el modelo de redes mediante el
editor de proyectos en el capítulo 4, y la más sencilla de las utilizadas en éste proyecto. Consta,
como se ha indicado anteriormente, de cinco fuentes TCP denominadas ClienteN y cinco fuentes
receptoras denominadas ServidorN, además de dos routers, dos switch y tres nodos de
configuración de parámetros globales (parámetros del tipo de aplicación, perfiles de los nodos y
configuración de parámetros de Calidad de Servicio o QoS).
Las conexiones entre los nodos emisores/receptores y los switchs, y entre éstos y los routers es de
tipo 10BaseT, es decir, una conexión rápida que asegure que todos los datos son enviados sin
problema, y el tiempo de procesamiento en los switch despreciable, para evitar congestión y
143
Capítulo 5. Experimentos
pérdida de paquetes ya en ellos. La conexión entre los dos routers elegida es T1, mucho más lenta
(1.42 Mb), con lo que la congestión está asegurada.
5.2.1.1 Escenarios
El proyecto CuelloBotella consta de tres escenarios, en los que la topología es la misma pero varía
el tipo de AQM utilizado:
•
DT: se emplea Drop Tail, configurado por defecto en el router.
•
RED: se emplea el AQM Random Early Detection o RED como mecanismo de
control de congestión.
•
GRED: se emplea la versión Gentle-RED como mecanismo de control de
congestión, AQM añadido a OPNET.
Ilustración 70. Topología CuelloBotella
144
Control de Congestión con OPNET
5.2.2 CuelloBotella2
En esta topología se aumenta la complejidad y la carga de tráfico en la red aumentando el número
de nodos de la red, tanto fuentes emisoras como receptoras. El tráfico sigue siendo íntegramente de
tipo TCP.
Ahora, el número de clientes asciende a catorce, al igual que el número de servidores.
5.2.2.1 Escenarios
Como en el anterior caso, CuelloBotella2 consta de tres escenarios: DT, RED y GRED, llamados
así por el tipo de AQM configurado en sus routers.
Ilustración 71. Topología CuelloBotella2
145
Capítulo 5. Experimentos
5.3 Reglas de ajuste de parámetros de RED
Como se ha dicho anteriormente, uno de los mayores problemas de utilizar el algoritmo RED es
configurar sus parámetros, ya que este algoritmo es extremadamente sensible a ellos. De hecho, una
mala configuración de parámetros puede provocar que se obtengan resultados peores que aplicando
el algoritmo por defecto, Drop Tail.
Cuando Floyd y Jacobson presentaron en 1993 el algoritmo RED [5], proporcionaron ciertas pautas
para la configuración de esos parámetros, que si bien no son muy aclaratorias, permiten al usuario
tener una base para “tantear” cual puede ser el rango de valores más adecuado para cada parámetro
en situaciones concretas.
A continuación se exponen ideas obtenidas de dicho documento.
5.3.1 Configuración de los parámetros en general
No hay reglas estrictas para hallar valores óptimos, éstos dependen de varios factores incluyendo
no sólo la velocidad del enlace o retardo de propagación, si no también las características del
tráfico, por ejemplo.
Un factor a tener en cuenta en general es cuántos paquetes pueden llegar a la cola durante la
duración de un RTT medio (si hubiera tal cosa). Para situaciones de congestión que duran menos
que RTT, el comportamiento ideal sería que la cola tuviera un tamaño suficiente para absorver
dicha congestión sin descartar paquetes. Si la congestión dura más que RTT, el comportamiento
ideal sería que la cola reflejara ésta congestión, avisando a los nodos emisores.
5.3.2 Umbral Mínimo
La configuración optima de Min_th se debe hacer con la idea de mantener un equilibrio entre
conseguir un tiempo de espera bajo en el enlace y una utilización alta de su capacidad. Cuanto más
intenso sea el tráfico de llegada, mayor debe ser Min_th para conseguir una utilización del enlace
adecuada. Si éste valor fuera demasiado bajo, el router no soportaría ráfagas de datos.
Además se debe tener en cuenta también la velocidad del link, el retardo de propagación y el
tamaño máximo del buffer. Por ejemplo, hay que observar si el retraso en la cola es trivial con
respecto al retardo de propagación a través del enlace. Eso es señal de que el parámetro está bien
configurado. En caso contrario, habría que aumentar el valor de Min_th.
5.3.3 Umbral Máximo
146
Control de Congestión con OPNET
En el documento se dice que Max_th debe ser como mínimo dos veces Min_th. Según otras
fuentes, lo más aconsejable es de hecho asignar Max_th = 3*Min_th.
5.3.4 Exponential Weight Factor (wq)
Se recomienda establecer wq como mínimo a 0.001. La elección de este parámetro determina la
“constante de tiempo” de muestreo del parámetro Average Queue Size. Si es demasiado bajo, RED
tendrá una respuesta demasiado baja a las situaciones de congestión. Por el contrario, si es
demasiado alta, puede oscilar demasiado, asemejándose demasiado al tamaño real de la cola.
En OPNET, no damos el valor de wq directamente, si no otro parámetro, que se usa en la función
Oms_Qm_Average_Queue_Size_Update para calcular el tamaño medio de cola cada vez que llega un
paquete al sistema. El propio OPNET nos sugiere por defecto que tal valor sea 9, pero también se
permiten los valores 1, 5, o un valor que el usuario edite.
5.3.5 Probabilidad Máxima
No se especifica mucho acerca del valor que debe tomar Max_p. Las simulaciones descritas en el
artículo establecen max_p a 0.02, pero según algunos usuarios, es más aconsejable establecer su
valor a 0.1. Esto traducido a la forma de configurar los parámetros en OPNET, equivaldría a
establecer el parámetro Mark Probability Denominator a 10, ya que éste parámetro, en la función
oms_qm_red_packet_drop a dividirá a uno, como ya hemos visto en el anterior capítulo. Así,
1/10=0.1.
5.3.6 Ajuste de parámetros GRED
En general, todo lo dicho para el AQM RED se puede aplicar para la configuración de los
parámetros del algoritmo GRED.
GRED y RED obtienen unos resultados similares, pero se puede decir que GRED va a ser un
algoritmo más robusto y se va a comportar mejor que RED en situaciones en las que el ajuste de los
parámetros no es tan bueno.
Según el artículo [3] de la bibliografía, hay una fuerte relación lineal entre los parámetros umbral
mínimo, máximo o probabilidad máxima y el tamaño medio de cola.
Ya que tanto GRED como RED no descartan paquetes hasta que se sobrepasa el umbral mínimo,
el valor mínimo del tamaño de cola medio estará precisamente determinado por ese umbral. En
general, para evitar desbordamiento o desaprovechamiento del buffer, sería adecuado que se
estabilizara el tamaño medio de cola en torno a un valor apropiado. Para conseguir esto, el umbral
mínimo debe estar configurado de forma que se evite el mal aprovechamiento, es decir, que no se
comiencen a descartar paquetes cuando la carga de tráfico no es muy alta.Así mismo, el umbral
147
Capítulo 5. Experimentos
máximo y la probabilidad de descarte máxima deberán tener un valor adecuado para evitar el
desbordamiento.
Si se comparan los resultados obtenidos con RED y con GRED se puede observar que en RED, el
umbral máximo es el que tiene mayor impacto sobre el tamaño de cola. Sin embargo, en GRED es
el umbral mínimo. Esto es porque GRED mejora el problema que tenía su antecesor al incrementar
a uno la probabilidad de descarte cuando se alcanzaba el umbral máximo.
5.4 Resultados con la topología CuelloBotella
5.4.1 Especificación de parámetros para los experimentos
5.4.1.1 Nodo Aplicaciones:
Aplicación
FTP
Inter-Request Time
(secs)
exponential(100)
File Size
500000B
5.4.1.2 Nodo Perfiles
Offset
No
Ajuste de Aplicación_FTP
Duration (secs) Inter-Rep. Time
Number of
(secs)
Repetitions
constant(400)
constant(50)
Ilimitada
Operation Mode
Simultaneous
stara
Time
const(0.5)
Ajuste de Perfil_FTP
Duration Inter-Rep.
Time
End of
const(50)
Simulation
Number
of Reps
const(4)
Pattern
Serial
Pattern
Concurrent
5.4.1.3 Nodo QoS
Este cuadro, como los anteriores, resume las características configuradas para todos los escenarios
que se simulan. El parámetro Buffer Size se aplica en los todos, pero el resto de parámetros de esta
tabla sólo se aplicarán a los escenarios de simulación de los AQM RED y GRED.
148
Control de Congestión con OPNET
Experimento
E1
E2
E3
E4
Buffer Size
(pkts)
100
60
60
60
Max_th
(pkts)
15
15
15
15
Min_th
(pkts)
5
5
5
5
Mark Prob.
Denominator
10
10
40
40
Exp. Weight
Factor
9
9
9
12
Los parámetros han sido elegidos en relación al documento original de los creadores del algoritmo
RED, y se han ido variando para cada experimento intentando mostrar un poco los efectos que cada
parámetro causa tanto en RED como en GRED.
5.4.1.4 Otros parámetros
Se ha utilizado dos tipos de enlaces en esta topología. El enlace entre los routers debe ser lento en
relación al resto de enlaces de la red para provocar la situación de cuello de botella. Para tal función
el enlace elegido es T1 (1.544Mb/sec), asignándole un retardo de propagación de 0.008 segundos.
Para el resto de los enlaces, entre los nodos emisores/receptores y los switch, y entre los switch y
los routers, los enlaces son de 10BaseT, con un retardo de propagación de 0.001 segundos.
Tanto las fuentes emisoras como las receptoras utilizan el protocolo TCP, configurado a la versión
Tahoe, como indica en el documento [5] que utilizan para sus experimentos.
La duración de la simulación es de 3000 segundos, para dar tiempo a la red a adaptarse al tráfico, y
se vea su funcionamiento de forma estable.
En los siguientes apartados se muestran las gráficas con los resultados obtenidos tras la simulación
de la topología CuelloBotella tras configurarse como se indica en los cuatro experimentos.
149
Capítulo 5. Experimentos
5.4.2 Gráficas
5.4.2.1 Tráfico descartado globalmente
DT en azul, RED en verde, GRED en rojo.
Ilustración 72. E1 y E2. Tráfico descartado en la red.
En la primera gráfica, que corresponde al experimento con tamaño de buffer 100, tal y como se han
configurado los parámetros se ve que la línea roja (GRED) es la que se encuentra por debajo en
todo momento, es decir, ese escenario es el que menos descartes produce.
150
Control de Congestión con OPNET
En general se puede observar que la tasa de descarte en los cuatro escenarios aumenta conforme
avanza el tiempo de simulación, debido a que el nodo Aplicaciones está configurado para emitir
tráfico de manera exponencial, y la cola del router se llena rápido.
Para el experimento E2, en el que sólo cambia el tamaño del buffer de 100 a 60 paquetes, se
demuestra lo sensible que son RED y GRED a la configuración de los parámetros, aumentando la
tasa de descartes. Es la situación en la que peor ventaja demuestra GRED. Aún así, el resto de
estadísticas obtenidas para este escenario muestran unos resultados bastante satisfactorios para
GRED.
DT en azul, RED en verde, GRED en rojo.
Ilustración 73. E3, E4. Tráfico descartado en la red.
151
Capítulo 5. Experimentos
El tercer experimento, basado en el segundo, cambia sólo maxp, pasando de 10 (se descartan uno
de cada diez paquetes) a 40 (uno de cada cuarenta). Al descartar menos paquetes, tanto RED como
GRED alcanzan antes el umbral máximo, con lo que llegado este punto la tasa de descartes se eleva
en RED de manera visible con respecto a los otros dos escenarios, llegando al valor 40. Sin
embargo GRED vuelve a igualarse en descarte a Drop Tail.
La última gráfica muestra cómo afecta la modificación del parámetro wq, o lo que es lo mismo, el
intervalo de muestreo del tamaño medio de cola. Aumentar el valor de 9 a 12 provoca que se
descarten menos paquetes, no llegando a alcanzar 28 para el caso de RED o 18 en el caso de
GRED. Sin embargo, para otras estadísticas el resultado no será tan bueno.
5.4.2.2 Retardo global de la red
DT en azul, RED en verde, GRED en rojo.
Ilustración 74. E1, E2. Valores medios del retardo en la red.
152
Control de Congestión con OPNET
Viendo las gráficas, en los cuatro experimentos GRED es el que menor retardo global consigue.
Por lo tanto, se puede concluir que no se ve muy afectado por los cambios de parámetros realizados
en los distintos experimentos.
DT en azul, RED en verde, GRED en rojo.
Ilustración 75.E3, E4. Valores medios del retardo en la red.
RED sin embargo es más dedependiente de la configuración de los parámetros. El escenario en el
que más retardo hay es el tercero, E3, porque al efectuar un descarte menos agresivo de paquetes,
llega un momento en que se satura y dispara su tasa de descartes, descartando todos los paquetes
que llegan al router, lo cual contribuye a aumentar el retardo global.
153
Capítulo 5. Experimentos
5.4.2.3 Utilización del buffer en Router1
DT en azul, RED en verde, GRED en rojo.
Ilustración 76. E1, E2. Utilización del buffer en Router1.
En los cuatro experimentos se observa que para Drop Tail el buffer se llena momentos después de
comenzar la simulación, manteniedo ese nivel hasta el final de la misma.
Para RED y GRED, se consigue mantener en un nivel de utilización bastante más bajo, debido al
descarte temprano, disminuyendo el retardo que lo paquetes experimentan. Observar que la cola se
mantiene en un tamaño cercano a 30 paquetes independientemente del tamaño del buffer (100 en
E1, 60 en el resto).
Por la gráfica del escenario E3 (siguiente página), vemos que el hecho de disminuir la agresividad
en el descarte de paquetes no va a influír mucho en estos resultados, debido a los umbrales máximo
y mínimo, manteniéndose alrededor de 30 paquetes en todo momento.
154
Control de Congestión con OPNET
Ilustración 77 E3, E4. Utilización del buffer en Router1.
El parámetro que sí que influye más en estos resultados es wq, como se ve en el cuarto
experimento, E4. Se puede ver que la utilización del buffer va a crecer tanto para RED, que se
mantiene en torno al valor 45 (un valor demasiado alto, que no deja margen para absorber ráfagas
de tráfico), como para GRED sobretodo, que alcanza picos de utilización mayores, y experimenta
gran inestabilidad en el tamaño de cola.
La gráfica obtenida para el cuarto experimento demuestra que no es bueno disminuir el intervalo de
muestreo en situaciones de este tipo, en que el tráfico es tan inestable (recordar de estamos ante una
distribución exponencial del tráfico), puesto que tanto GRED como RED no van a comportarse
como deben.
155
Capítulo 5. Experimentos
5.4.2.4 Variación en el retardo o jitter en Router1
DT en azul, RED en verde, GRED en rojo
Ilustración 78. E1, E2. Jitter en Router1, valores medios.
En el primer eexperimento es donde mejores resultados se obtienen, habiendo un nivel de jitter
mucho menor en los escenarios controlados por AQM que en el controlado por Drop Tail. Este
último siempre sigue el mismo patrón de comportamiento: primero tiene un pico en la gráfica,
correspondiente a los primeros instantes de simulación en los que el buffer está vacío y pasa a estar
lleno, punto en el que se mantiene hasta el final de la simulación, con lo que el valor medio
desciende hasta quedarse, en algunos casos, por debajo del de RED y GRED.
En otras situaciones de tráfico, se podría observar un nivel alto de jitter debido al efecto de
sincronización global creado por Drop Tail.
156
Control de Congestión con OPNET
Ilustración 79.E3, E4. Jitter en Router1, valores medios.
En el caso de RED y GRED, la variación en el retardo o jitter conserva un valor más estable en los
cuatro experimentos.
El experimento en el que peores resultados se obtinen es el cuarto, en el que como se ha visto en el
anterior apartado los valores alcanzados por GRED y GRED eran más parecidos a Drop Tail en
cuanto a la ocupación del buffer. Además, había más oscilaciones, de ahí que aumente el nivel de
jitter.
157
Capítulo 5. Experimentos
5.4.2.5 Retardo en Router1 o Delay
DT en azul, RED en verde, GRED en rojo
Ilustración 80. E1, E2. Retardo en Router1, valores medios.
En los cuatro experimentos el escenario en el que más retardo sufren los paquetes que llegan a
Router1 es Drop Tail. El retardo está muy por encima del experimentado con RED y GRED.
Este retardo tiene relacion directa con la ocupación del buffer, que es mucho mayor en el caso de
Drop Tail. De hecho, el experimento en el que más retardo hay es en el primero, es decir, el que
tiene un buffer con mayor capacidad, por lo tanto, un paquete tardará más en ser procesado, porque
tiene más paquetes esperando delante en todo momento.
158
Control de Congestión con OPNET
Ilustración 81. E3, E4. Retardo en Router1, valores medios.
Se observa que dentro de los dos escenarios en los que se utiliza AQM, el que mejores resultados
muestra para todos los experimentos es GRED, teniendo siempre un valor muy similar o inferior,
independientemente de la configuración de los parámetros.
Cabe destacar que el experimento en el que más retardo sufren estos dos escenarios es el cuarto, en
el que se veía anteriormente que subía la utilización del buffer del router. En esa situación es en la
que más se nota la mejora de GRED con respecto a RED, y su fiabilidad ante el cambio de la
configuración de parámetros.
159
Capítulo 5. Experimentos
5.4.2.6 Comparación entre RED y GRED
Ilustración 82. E1, E2. Tamaño de cola medio con el algoritmo RED (rojo) y GRED (azul).
Aquí se muestra una comparación entre el parámetro Tamaño medio de cola de los dos algoritmos.
Es la gráfica más útil para comprobar cómo se comportan ambos, sus semejanzas y diferencias.
En las cuatro gráficas, excepto la correspondiente al cuarto experimento (en el que varía wq), el
tamaño de cola medio es igual para los dos escenarios al principio, pero luego (cuando se alcanzan
valores próximos al umbral máximo) se separan, conservando un valor mayor para GRED que para
RED. Esto es por la política de descarte de ambos algoritmos, en la cual, como se ha descrito
anteriormente, si se llega al umbral máximo, RED descarta los paquetes con probabilidad 1, y
GRED lo suaviza aumentando la probabilidad de descarte de manera lineal hasta uno, con lo que es
menos probable que se descarten paquetes.
160
Control de Congestión con OPNET
Ilustración 83. E3, E4. Tamaño de cola medio con el algoritmo RED y GRED.
Lo que se puede observar también es que el tamaño medio de cola de GRED oscila más en los
cuatro experimentos, sobre todo en el cuarto, en el que se adapta más rápidamente al tráfico.
Otra curiosidad es que en los tres primeros experimentos, el tamaño medio de cola en RED no llega
a superar el valor 11. Sin embargo, en el último escenario, aumenta un poco, nunca sobrepasando el
umbral máximo (15).
Se necesitarían situaciones de más tráfico para comprobar cómo efectivamente RED controla el
tamaño medio de cola para que nunca sobrepase el umbral máximo, y sin embargo GRED sí que lo
sobrepasa, aunque moderadamente. El valor máximo que podría alcanzar el tamaño medio de cola
para GRED sería dos veces el umbral máximo, punto a partir del cual GRED descarta los paquetes
con probabilidad 1.
161
Capítulo 5. Experimentos
5.4.2.7 Utilización del enlace entre Router1 y Router2
DT en azul, RED en verde, GRED en rojo
Ilustración 84. E1, E2. Utilización del enlace entre los routers.
En los cuatro experimentos se observa que Drop Tail es el que obtiene una utilización máxima del
enlace entre Router1 y Router2. Es un resultado lógico puesto que con los valores introducidos de
tráfico la cola del buffer siempre está llena, por lo que siempre hay paquetes que transmitir al
siguiente nodo.
Con los algoritmos AQM el resultado que se obtiene es también satisfactorio, teniendo en cuenta
que la utilización del enlace es muy alta a pesar de la baja ocupación del buffer dentro de router1,
gracias a la cual se ha conseguido disminuir el retardo de los paquetes en dicho router.
162
Control de Congestión con OPNET
Ilustración 85. E3, E4. Utilización del enlace entre los routers.
El experimento en el que peores resultados se observan es en el cuarto, en el caso del escenario
GRED, en el que la inestabilidad del tamaño de cola medio y por tanto la ocupación del buffer
provoca picos de baja utilización, aunque en el resto de ls momentos sea casi igual a la utilización
obtenida con el escenario Drop Tail.
En este experimento se debe resaltar también que RED es el escenario que permanece más estable
163
Capítulo 5. Experimentos
5.5 Resultados con la topología CuelloBotella2
5.5.1 Especificación de parámetros para los experimentos
5.5.1.1 Nodo Aplicaciones:
Aplicación
Inter-Request Time
(secs)
exponential(100)
FTP
File Size
500000B
5.5.1.2 Nodo Perfiles
Ajuste de Aplicación_FTP
Duration (secs) Inter-Rep. Time
Number of
(secs)
Repetitions
constant(400)
constant(50)
Ilimitada
Offset
No
Operation Mode
Simultaneous
stara
Time
const(0.5)
Ajuste de Perfil_FTP
Duration Inter-Rep.
Time
End of
const(50)
Simulation
Number
of Reps
const(4)
Pattern
Serial
Pattern
Concurrent
5.5.1.3 Nodo QoS
Experimento
E5
Buffer Size
(pkts)
100
Max_th
(pkts)
15
Min_th
(pkts)
5
Mark Prob.
Denominator
10
Exp. Weight
Factor
9
El resto de parámetros está configurado como la topología CuelloBotella:
Capacidad del enlace entre routers: T1 (1.544Mb/sec). Retardo: 0.008 segundos.
Capacidad del resto de los enlaces: 10Mb/sec. Retardo: 0.001 segundo.
TCP: Tahoe
A continuación se muestra uno de los experimentos realizados con la topología CuelloBotella2, en
la que, como se ven los parámetros arriba expuestos, sólo varía el número de nodos de la red. El
tráfico enviado por cada nodo emisor será el mismo, lo que provoca que Router1 esté más saturado,
y se experimente más congestión en la red.
Concretamente, en las siguientes gráficas se muestra la comparación de tráfico registrado a la
entrada del router para ambas topologías:
164
Control de Congestión con OPNET
Ilustración 86. Tráfico registrado para CuelloBotella y CuelloBotella2
En la primera de las gráficas se muestra el tráfico obtenido para el escenario Drop Tail en ambas
topologías: CuelloBotella corresponde con la línea azul y CuelloBotella2 con la roja. Como se ve,
en ambos casos se supera el tamaño del buffer del router (100 paquetes), llegando a alcanzar para la
segunda topología más del doble del tamaño, 220.
La segunda gráfica corresponde a la misma comparación para el escenario GRED, que es parecido
a lo que ocurre con RED, pero que no se muestra en este caso. Se ve que en la primera topología se
controla que llegue menos tráfico al router, manteniendose éste entre los 160 y 180 paquetes. Sin
embargo, en la segunda topología (línea roja), el tráfico se desborda, superando los 260 paquetes.
A continuación vemos como repercute esto en los resultados, y la necesidad de reconfigurar los
parámetros RED y GRED.
165
Capítulo 5. Experimentos
5.5.2 Gráficas
5.5.2.1 Tráfico descartado globalmente
(GRED en rojo, Drop Tail en azul, RED en verde)
Ilustración 87. E5, Retardo global para la topología CuelloBotella2
Como se ve, en el escenario E5, los resultados han variado mucho con respecto a lo obtenido en E1.
RED es el escenario que más paquetes descarta, seguido de GRED. Drop tail descarta muchos
menos paquetes y de manera constante. Esto demuestra que los parámetros RED no están bien
configurados para la situación de tráfico actual.
5.5.2.2 Retardo global en la red
Ilustración 88. E5, Retardo global en la red, valores medios.
166
Control de Congestión con OPNET
Como se ve en la gráfica, para el escenario E5, el escenario que más retardo tiene se GRED,
aunque los tres escenarios tienen un retardo similar.
5.5.2.3 Utilización del buffer en Router1
Ilustración 89. E5, Utilización del buffer en el Router1.
Debido a la implementación tanto de GRED como RED, se puede apreciar, como pasaba con la
anterior topología, que la cola del router se llena mucho menos que para Drop Tail, provocando
menos retardo en el router.
5.5.2.4 Retardo en Router1
Ilustración 90. E5, Retardo en el Router1, valores medios.
167
Capítulo 5. Experimentos
El retardo en el buffer va asociado a la ocupación. Como en la gráfica anterior, en este caso, hay
mucho más retardo en el escenario Drop Tail que en RED y GRED, porque al estar el buffer más
lleno, los paquetes permanecen más tiempo en la cola antes de ser procesados.
5.5.2.5 Comparación entre RED y GRED
Ilustración 91. Tamaño medio de cola de GRED (azul) y RED (rojo)
Como se ha visto en otros experimentos, el tamaño de cola medio es más alto para GRED que para
RED, ya que este último descarta paquetes de forma más agresiva.
5.5.2.6 Utilización del enlace entre Router1 y Router2
Ilustración 92. E5, Utilización del enlace
Aunque la utilización del buffer sea mucho más baja para los escenarios GRED y RED, no afecta a
la utilización del enlace, siendo muy parecida a la obtenida por Drop Tail.
168
Control de Congestión con OPNET
Capítulo 6: Conclusiones y líneas
futuras
6.1 Conclusiones
En esta memoria primero se ha presentado de forma general los mecanismos que garantizan
Calidad de Servicio en las redes de ordenadores y su ámbito de funcionamiento. Entre ellos se ha
mencionado la necesidad de algoritmos de gestión activa de colas como RED para evitar efectos
indeseables derivados de la congestión de redes como son la sincronización global, el alto jitter, o
la pérdida excesiva de paquetes.
En el tercer capítulo se ha descrito detalladamente aspectos del simulador OPNET tales como el
funcionamiento de los modelos de nodos y procesos, o cómo se lleva a cabo la simulación de
eventos discretos.
Otra parte que ha ocupado mucho tiempo en este proyecto (y espacio en la memoria) ha sido el
estudio del nivel de modelado más bajo en el simulador, es decir, tanto los modelos de proceso que
describen el comportamiento de los componentes del simulador, como las librerías con el código
fuente que complementan la funcionalidad que por cualquier motivo no estuviera incluida en los
modelos de proceso (por ejemplo, por cuestiones de utilidad o reutilización). Mediante este estudio
se ha comprendido cómo se modelan en OPNET cuestiones como la calidad de servicio o el control
de congestión.
Al final, se han presentado los resultados de las simulaciones para distintas situaciones y
topologías. Con esos resultados, se ha comprobado que la configuración de los algoritmos RED y
GRED no es intuitiva. Se debe tener en cuenta muchas situaciones como son el tráfico de la red, el
tipo de tráfico, la naturaleza y duración de las posibles ráfagas, los retardos en la red, etc.
Se ha visto que en líneas generales, el algoritmo GRED se comporta mejor, obteniendo una menor
tasa de descartes y un menor retardo global. Uno de los problemas que se ha visto es que el
parámetro tamaño medio de cola tiende a oscilar, sobre todo ante cambios de configuración de wq y
del umbral mínimo, por lo que se debe tener cuidado al configurarlo.
En general, además de todo lo dicho en este apartado, se ha podido comprobar que OPNET es una
herramienta muy potente y puede ser extremadamente útil para modelar redes de ordenadores y
entornos de comunicación a nivel profesional. Puede tener mucha utilidad también a nivel
académico, para ilustrar temas relacionados con redes y protocolos, debido a lo intuitivo de su
interfaz gráfica, si se han descrito los pasos a seguir previamente por medio de un tutorial al estilo a
lo que se ha hecho en esta memoria.
169
Capítulo 6.Conclusiones y líneas futuras
6.2 Posibles Ampliaciones
A medida que este proyecto ha ido avanzando, se ha pensado en distintas líneas de investigación
que se podrían seguir a partir de los expuesto aquí.
Una de las propuestas que quedan pendientes es exportar el uso de GRED a otras disciplinas de
cola como PQ, WFQ, LLQ, … puesto que tal y como está implementado el algoritmo es sólo
configurable para su uso con FIFO.
Pendiente queda también hacer simulaciones con tráfico de distinta índole, como UDP, y ver cómo
se comporta el algoritmo cuando hay flujos de tráfico con más peso que otros (simulacines tipo
elefante-ratón).
Una vez demostrado que se ha podido modificar el código para añadir la versión de RED, Gentle
RED, otra de las ideas que se proponían es modificar la forma en que RED trabaja, dando al
usuario la posibilidad de actualizar el tamaño medio de cola cada cierto tiempo (definido mediante
un intervalo de muestreo) en vez de actualizarlo por cada paquete que llega, como es el caso
actualmente. En el Anexo D se explican unas pautas iniciales para realizar esta modificación.
Otra de las ampliaciones que se proponen es estudiar el algoritmo GRED y compararlo con RED
utilizando otras topologías, como pueden ser cuellos de botella más complejos, con mayor tráfico y
número de fuentes TCP, y también mayor número de routers, creando cruces de tráfico de distintas
características.
170
Control de Congestión con OPNET
Bibliografía
A. Publicaciones Científicas
[1] N. Alborz. “Implementation and performance simulation of Virtual Clock scheduling in IP
Networks”. Sha Shahid Beheshti University, Tehran, Iran, 1998.
[2] A. Bitorika, M. Robin, M. Huggard. “A Framework For Evaluating Active Queue Management
Schemes”. Department of Computer Science, Trinity College Dublin, Ireland. July 2003.
[3] T. Eguchi, H. Ohsaki, M. Murata. Osaka University. “On Control Parameters Tuning for Active
Queue Management Mechanisms using Multivariate Analysis”. 2003 Symposium on
Applications and the Internet (SAINT'03) . Orlando, Florida. January 2003
[4] G. Flores Lucio, M. Paredes Farrera, E. Jammeh, M. J. Reed, M. Ghanbari, “Análisis a NivelPaquete de Simuladores de Red Contemporáneos”. Revista IEEE America Latina. Volumen 4,
páginas: 299-307. Junio 2006.
[5] S. Floyd, V. Jacobson. “Random Early Detection Gateways for Congestion Avoidance”.
IEEE/ACM Transactions on networking. VOL I . NO 4, pages: 397-413. August 1993.
[6] V. Hnatyshin, G. Gramatges, M. Stiefel. Rowan University, Department of Computer Science,
Glassboro, NJ. “Practical Considerations for Extending Network Layer Models with OPNET
Modeler”. The 18th IASTED International Conference on Modelling and Simulation.
Montreal, Quebec, Canada. Symposium signal processing and intelligent systems. Year of
Publication: 2007
[7] G. Iannaccone, C. Brandauer, T. Ziegler, C. Diot, S. Fdida y M. May, “Comparison of tail drop
and active queue management performance for bulk-data and web-like internet traffic”.
Proceedings of the Sixth IEEE Symposium on Computers and Communications, page: 122.
July 2001
[8] D. Mitchell, J. Yeung. “Implementation of Start-Time Fair Queuing Algorithm in Opnet™”.
Ensc835, School of Engineering Service, Simon Fraser University, April 2002.
[9] K. Ramakrishnan, S. Floyd, D. Black. “The Addition of Explicit Congestion Notification (ECN)
to IP”.RFC 3168. Sept. 2001.
[10] E. Tsolakou, I. S. Venieris. National Technical University of Athens, Telecommunications
Laboratory. Department of Electrical and Computer Engineering. “Implementation of Traffic
Conditioning and PHB mechanisms in OPNET”. International conference on advances in
communication and control No8 , GRECE 2002 , pp. 197-207
171
Bibliografía
[11] B. Van den Broeck, P. Leys, J. Potemans1, J. Theunis, E. Van Lil, A. Van de Capelle.
Katholieke Universiteit Leuven, Department of Electrical Engineering. “Validation of Router
Models in OPNET” . OPNETWORK 2002, Washington D.C., USA, 2002.
[12] J. Wang, K. Nahrstedt and Y. Zhou, “Design and Implementation of DiffServ Routers in
OPNET”. Proceedings of OPNETWORK 2000, Washington D.C., Aug 28 - Sep. 1, 2000.
[13] K. Wu, Y. Ma, L. Trajkovic, Simon Fraser UniversityBurnaby, British Columbia, Canada.
“OPNET Implementation of Endpoint Admission Control Algorithms”. OPNETWORK 2003,
Washington, DC, Aug. 2003
[14] C. Zhu, O. W.W. Yang, J. Aweya, M. Ouellette, Delfin Y. Montuno. Ottawa, Ontario, Canada.
“A Comparison of Active Queue Management Algorithms Using OPNET Modeler”.
Communications Magazine, IEEE. Vol. 40, Issue 6, pp. 158-167. Jun 2002.
B. Páginas Web
[1] A Hybrid Systems Modeling Framework for Communication Network
http://www-rcf.usc.edu/~junsool/hybrid/. Último acceso: 30/11/2009
[2] Cisco Systems. Cisco Packet Tracer.
www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html.
Último acceso: 18/12/09
[3] Control de Congestión
www.it.uc3m.es/~prometeo/rsc/apuntes/Conges/conges.html#1.3.2%20Control%20de%20con
gesti%C3%B3n. Último acceso: 13/5/2009
[4] D. Erman. “M/M/1 simulation in OpNET”.
www.its.bth.se/courses/etd012/slides/OpNET_mm1.sxi.pdf. Último acceso: 27/08/2009.
[5] Establecimiento Conexión TCP.
http://seguridadyredes.nireblog.com/ Seguridad y redes. Último acceso: 30/11/09
[6] Protocolo TCP
http://www.tesisenxarxa.net/TESIS_UPC/AVAILABLE/TDX-1222106164746//04AMCA04de15.pdf
Último acceso 27/11/09.
[7] Mejores Simuladores de Redes
http://www.taringa.net/posts/downloads/1047902/Mejores-Simuladores-de-Redes.html
Último acceso 18/12/09
[8] OPNET Modeler Documentation Set. Version: 14.5. 2008
172
Control de Congestión con OPNET
Glosario
ACK: Acknowledgement, señal emitida por el host receptor como reconocimiento al recibir un
segmento de datos de parte del host transmisor.
AQM: Active Queue Management, Gestión Activa de Colas
Buffer: area de almacenamiento utilizada para manejar datos en tránsito. Los buffers se usan en las
redes para compensar las diferencias en velocidad de procesamiento entre dispositivos de red. Son
útiles sobre todo para almacenar ráfagas de datos.
CAR: Committed Access Rate algorithm.
Cola: Reserva de paquetes que esperan ser enviados por una interfaz de router.
Control de flujo: Técnica que permite sincronizar el envío de información entre dos entidades que
producen/procesan información a distintas velocidades. Es una más de las técnicas para combatir la
congestión. Se consigue con ella parar a aquellas fuentes que vierten a la red un tráfico excesivo.
DiffServ: Differentiated Service, Servicio Diferenciado. Método para proveer QoS Con un coste
bajo.
ECN: Explicit Congestion Notification.
FB: Function Block, Bloque de Funciones.
FTP: File Transfer Protocol. Protocolo de transferencia de archivos. Protocolo utilizado para la
transferencia de archivos en la red.
HB: Header Block, Bloque de Cabecera.
IP: Internet Protocol. Protocolo del nivel de red que ofrece un servicio no orientado a conexión. IP
brinda funciones de direccionamiento, especificación del tipo de servicio, fragmentación y
reensamblaje, y seguridad.
KP: Kernel Procedures. Conjunto de procedimientos proporcionados por OPNET para realizar
funciones específicas relacionadas con el tratamiento de datos en el modelado de una red.
MSS: Maximum Segment Size. Tamaño máximo de segmento para el protocolo TCP.
173
Glosario
Paquete: agrupación lógica de información que incluye un encabezado que contiene la información
de control y (generalmente) los datos de usuario. El término “paquete” se usa con frecuencia para
referirse a las unidades de datos en la capa de red.
QoS: Quality of Service, Calidad de Servicio. Es la capacidad de asignar diferentes prioridades a
diferentes aplicaciones, flujos de datos, usuarios, o garantizar un cierto nivel de eficiencia a un
flujo de datos. Si no hay congestión en la red, no se necesita QoS. “Best Effort” es el nivel QoS por
defecto.
RED: Random Early Detection, algoritmo de gestión activa de colas basado en el seguimiento del
tamaño medio de cola para asignar una probabilidad de descarte a cada paquete que llega al router.
Red: agprupación de varios nodos como pueden ser ordenadores, impresoras, routers, switches y
otros dispositivos que se pueden comunicar entre sí a través de un medio de transmisión.
Router: es un dispositivo de interconexión de redes de ordenadores que opera en el nivel de red.
Permite asegurar el enrutamiento de paquetes entre redes o determinar la ruta que debe tomar el
paquete de datos. Además de enrutar, los routers también se utilizan para manipular los datos que
circulan en forma de datagramas, para que puedan pasar de un tipo de red a otra. Como no todas las
redes pueden manejar el mismo tamaño de paquetes de datos, los routers deben fragmentar los
paquetes de datos para que puedan viajar libremente.
RSVP: ReSource ReserVation Protocol.
RTO: Retransmission Timeout, Contador de retransmisión.
RTT: Round Trip Delay Time. Tiempo que tarda un paquete desde un emisor en volver a éste
mismo emisor habiendo pasado por el receptor de destino.
SMTP: Simple Mail Transfer Protocol, Protocolo Simple de Transferencia de Correo.
STD: State Transition Diagram, Diagrama de Transición de estado
TCP: Transmission Control Protocol, protocolo para el control de la transmisión. Protocolo de la
capa de transporte orientado a conexión que proporciona una transmisión fiable de datos.
ToS: Type of Service. Es un byte ubicado en la cabecera de los datagramas IP. Usado por los routers
para elegir el destino de cada paquete. Proporciona QoS. En Opnet, éste byte se utiliza para ver qué
paquetes de datos tienen mayor probabilidad para ser descartados. (in-profile Vs. out-of-profile).
UDP: Protocolo de datagrama de usuario. Es un protocolo no orientado a conexión de la capa de
transporte. Intercambia datagramas sin acuse de recibo o garantía de entrega y requiere que el
procesamiento y retransmisión de errores sea manejado por otros protocolos.
174
Control de Congestión con OPNET
Anexo A. Contenido del CD
En el CD adjunto se encuentras los siguientes archivos:
•
Memoria.pdf: Memoria del proyecto en formato PDF.
•
oms_qm.h: fichero de cabecera o librería de OPNET modificada.
•
oms_qm.ex.c: fichero externo de datos de OPNET con la versión GRED añadida.
•
ip_output_iface.pr.c: modelo de proceso de OPNET modificado.
•
RED_parameters2.ad: fichero de propiedades del árbol de atributos RED
Parameters con GRED añadido en el Symbol map.
•
CuelloBotella.project, CuelloBotella2.project: Topologías utilizadas para los
experimentos mostrados en esta memoria.
Para obtener los ficheros del programa OPNET (no incluidos en este CD), entrar en la página web
www.OPNET.com e informarse sobre las distintas versiones que la empresa ofrece de su aplicación.
Para más información, también se puede acudir al apartado 4.1.2 Obtención de Licencias de este
documento.
175
Control de Congestión con OPNET
Anexo B. Guia para integrar el
algoritmo GRED en OPNET
En este anexo se explica cómo utilizar los ficheros que contiene el CD para conseguir utilizar
eficazmente el algoritmo presentado en este proyecto.
1.
Obtener las licencias en la página web de OPNET e instalar el programa a partir de los tres
ficheros que la empresa proporciona.
Tras la instalación, se puede comprobar que se habrá creado en el disco duro del ordenador
varias carpetas. Entre ellas:
2.
•
Una carpeta para los proyectos creados por el usuario, denominada por defecto
op_models.
•
Una carpeta en el directorio Archivos de programa, llamada OPNET y que
contiene todos los ficheros relacionados con la implementación de los modelos
existentes en OPNET como los ficheros de tipo .ex.c, modelos de proceso
(extensión .pr.c), archivos relacionados con la gestión de licencias, y varias cosas
más.
Copiar las dos carpetas CuelloBotella y CuelloBotella2 en el directorio op_models. De
esta forma, podemos acceder a los proyectos que contienen directamente desde el editor.
•
3.
También se pueden abrir los proyectos entrando dentro de las carpetas de las
topologías y ejecutando el único archivo en la carpeta con icono de tipo:
Sobreescribir las librerías existentes por las proporcionadas en el CD en las siguientes
carpetas:
•
oms_qm.h: se encuentra en la carpeta OPNET\models\std\include.
•
oms_qm.ex.c: en la carpeta OPNET\models\std\utilities\oms.
•
ip_output_iface.pr.c: sobrescribir en la carpeta OPNET\models\std\ip.
177
Anexo B. Guia para integrar el algoritmo GRED en OPNET
•
4.
RED_parameters2.ad: copiar en la carpeta OPNET\models\std\ip y cargarlo
desde el editor de procesos como se ha explicado en el capítulo 4, apartado 4.3.4
Modificación de atributos.
Una vez seguidas estas instrucciones y copiados los ficheros en sus directorios, abrir
cualquiera de las topologías. Al seleccionar Edit Attributes debe estar, dentro de:
FIFO Profiles › Details › RED Parameters › RED Status
la opción GRED Enabled.
178
Control de Congestión con OPNET
Anexo C. Estructuras y variables
importantes
En esta sección se muestran las estructuras más importantes que intervienen en la implementación
de algoritmos AQM en el simulador OPNET. Se han podido ir viendo en los extractos de código
mostrados en el Capítulo 4, mientras se explicaban las funciones paso a paso hasta llegar a la
implementación de RED y GRED. El estudio de éstas estructuras es esencial a la hora de
comprender las funciones citadas anteriormente.
Las estructuras están ordenadas según el archivo a que pertenecen. Se mostrarán en subapartados.
Tener en cuenta que aquí no se muestran todas, ni todos sus argumentos, sólo las partes que se han
considerado más relevantes. Dentro de cada estructura se muestran resaltados las variables o
estructuras relevantes.
C.1 iq_qos_support.h
•
Definición de tipos enumerados para asignar mecanismos QoS como disciplinas de
planificación, AQM, etc.:
typedef enum
{
IpC_QoS_Unknown
= -1,
IpC_QoS_Custom_Queuing
= 1,
IpC_QoS_Dropping = 2,
IpC_QoS_DWFQ_Class_Based
= 3,
IpC_QoS_DWRR
= 4,
IpC_QoS_FIFO
= 5,
…
IpC_QoS_RED
= 12,
IpC_QoS_Traffic_Class
= 13,
IpC_QoS_Traffic_Policy = 14,IpC_QoS_In_Traffic_Policy = 15,
…
IpC_QoS_Max_Scheme_Type = 20
} IpT_QoS_Scheme_Type;
•
Enumeración correspondiente a los distintos esquemas de disciplina de cola:
typedef enum
{
IpC_No_Queuing
IpC_FIFO_Queuing
IpC_WFQ_Queuing
IpC_Priority_Queuing
=
=
=
=
OmsC_Qm_No_Queuing,
OmsC_Qm_FIFO_Queuing,
OmsC_Qm_WFQ_Queuing,
OmsC_Qm_Priority_Queuing,
179
Anexo C. Estructuras y variables importantes
…
IpC_Max_Queuing_Scheme
} IpT_Queuing_Scheme;
•
Estructura para los distintos tipos de políticas de clasificación dentro de una cola (RED, CAR,
etc). No utilizada en el ámbito en que hemos desarrollado este proyecto, pero se debe conocer:
typedef struct
{
char *
policy_name;
List
scheduling_info_list;
List
red_info_list;
…
IpT_QoS_Scheme_Type scheduling_type;
}IpT_QoS_Policy_Info;
•
Estructura que contiene otras que serán importantes a la hora de procesar información QoS:
typedef struct
{
char *
profile_name;
List *
policy_list_ptr;
IpT_QoS_Scheme_Type type;
}IpT_QoS_Mechanism_Info;
•
La siguiente estructura guarda información que será usada para almacenar diversa información
QoS relativa a una interfaz IP dentro de un router:
typedef struct
{
char *
iface_name;
int
hold_q_capacity;
int
buffer_size;
…
IpT_QoS_Bandwidth_Type
bandwidth_type;
…
IpT_QoS_Mechanism_Info * scheduling_info;
IpT_QoS_Mechanism_Info * red_info;
} IpT_QoS_Iface_Info;
•
Definición de tipos enumerados para perfiles de interfaz:
typedef enum
{
IpC_QoS_Scheduling_Profile,
IpC_QoS_CAR_Profile,
IpC_QoS_RED_Profile,
IpC_QoS_Class_Map_Profile,
…
}IpT_QoS_Profile_Type;
180
Control de Congestión con OPNET
•
Contiene información general sobre la interfaz y variables del tipo OmsT_Qm_Attributes, que
como veremos después, guarda información básica sobre cada cola dentro de una interfaz:
typedef struct
{
char
*iface_name, char *q_profile_name;
int
buffer_size;
double
reserved_bandwidth;
IpT_QoS_Bandwidth_Type
IpT_Queuing_Scheme
…
OmsT_Qm_Attributes *
OmsT_Qm_Attributes *
bandwidth_type;
queuing_scheme;
qm_attr_ptr;
llq_qm_attr_ptr;
}IpT_QoS_Iface_Config;
•
Esta estructura es importante por contener una variable de tipo IpT_Rte_Module_Data, es
decir, será compartida entre el proceso padre y los hijos que implementen mecanismos de IP
QoS. Contiene además variables para manejo de estadísticas relacionadas con el descarte y el
envío de paquetes:
typedef struct
{
struct
IpT_Rte_Module_Data* //estructura para acceder a memoria compartida
iprmd_ptr; // Module Data del nodo.
intiface_index; // Output interface index.
Stathandle *locl_pk_dropped_hdl_ptr;
…
// Varias variables de acceso a estadísticas como son descarte de paquetes y
paquetes enviados Statisitic handle for local packets dropped.
…
intstatistic_index; // index to register queuing statistics.
…
} OmsT_Qm_Shared_Memory;
•
Esta estructura es importante. De éste tipo es la variable qconfig_ptr que se ha venido usando
en las funciones del Capítulo 4. Tiene referencia a parámetros IP específicos de la cola, entre
ellos, acceso a estructuras específicas de RED:
typedef struct
{
double max_size; /* Max size of the queue during congestion. */
…
int red_status;
/* Habilitar o deshabilitar RED y sus variantes
OmsT_Qm_Property_Type
red_match_property;
OmsT_Qm_RED_Queue_Params* red_queue_params_ptr;
*/
} OmsT_Qm_IP_Queue_Configuration;
•
Definición de enumerados para describir tipo de cola. Sólo nos ha interesado el FIFO:
181
Anexo C. Estructuras y variables importantes
typedef enum
{
IpT_Mother_Pool = OMSC_MOTHER_POOL,
…
IpT_Fifo_Pool,
…
IpT_Max_Pool_Type
} IpT_Pool_Type;
•
Estructura para guardar información IP QoS dentro de OmsT_Qm_Info. Es parecida a la que
se ha descrito anteriormente, IpT_QoS_Iface_Info, pero como diferencia, guarda los
parámetros globalmente y no para una interfaz determinada:
typedef struct IpT_Qos_Info
{
char * q_profile_name;
int
buffer_size;
double reserved_bandwidth;
IpT_QoS_Bandwidth_Type
bandwidth_type;
OmsT_Qm_Attributes * attribs_ptr;
} IpT_Qos_Info;
•
Estructura que guarda las variables que manejan todas las estadísticas de una cola dentro de
una interfaz:
typedef struct
{
Boolean
stat_is_registered; // Indicates whether the stat is registered.
Stathandle queuing_delay_stathandle;// Statistic for queuing delay.
…
Stathandle red_average_queue_size_stathandle; // Avq size calculated by RED.
} OmsT_Qm_Stat_Info;
C.2. ip_rte_support.h
Este fichero de cabecera contiene la definición de procedimientos para enrutamiento del protocolo
IP. Sólo es usado por el modelo de proceso ip_dispatch y por sus hijos. Incluye muchos ficheros de
cabecera y define muchas constantes necesarias para cálculos posteriores en otras funciones como
tamaño de cabecera, velocidad del enlace entre interfaces por defecto, flags para niveles de nodos...
Aún así, de este fichero solo nos interesa una estructura, IpT_Rte_Module_Data, pero será una de
las más importantes, pues es la que aloja los datos de la memoria compartida entre procesos dentro
de una jerarquía, y otros datos interesantes relativos a IP, como el tamaño de los datagramas, tabla
de enrutado, etc. :
typedef struct IpT_Rte_Module_Data
{
182
Control de Congestión con OPNET
Objid module_id;
Objid node_id;
char* node_name;
Prohandle
ip_root_prohandle;/* ip_dispatch */
…
/* Memory shared between various process models */
OmsT_Qm_Shared_Memory shared_mem;
Ici *arp_iciptr;
List *interface_table_ptr;
/* Table consisting of an array of all interfaces of the node */
IpT_Interface_Table
interface_table;
/* Tabla de enrutamiento usada por los paqueres IP en cada nodo.
Registra los routers operatives. */
IpT_Cmn_Rte_Table*
ip_route_table;
…
/* Static Route Table */
IpT_Rte_Table*
ip_static_rte_table;
…
Objidip_parameters_objid; /* Objid of IP Routing Parameters or*/
/* IP Host Parameters attribute */
Objid
ip_qos_params_objid; /* IP QoS attribute object id*/
/* Variables para el registro de estadísticas y otros
datos referentes al tráfico background */
…
/* Memoria compartida entre este proceso y sus hijos. Su propósito es
proporcionar un método para diferenciar entre el hijo desde donde el proceso fue
invocado y recivir un paquete en este proceso desde ese hijo. */
IpT_Ptc_Memory
ip_ptc_mem;
…
OmsT_Dv_Proc_Scheme
processing_scheme;
/* Variables para el manejo de estadísticas de cantidad de paquetes, de tipo
Stathandle. Tambien para el registro de “hops” */
…
/* Indicación de presencia/ausencia de protocolos de enrutado en el nodo.
int
routing_protos;
*/
/* Tamaño del datagrama después de la compresión. */
OpT_Packet_Size
dgram_compressed_size;
…
/* Identificador único de datagrama para cada paquete IP. */
int
dgram_id;
…
/* Array que almacena datos QoS para todas las interfaces. */
IpT_Rte_Iface_QoS_Data ** interface_qos_data_pptr;
…
/* Campos relacionados con fragmentación de datagramas.*/
Sbhandle
seg_buf_ptr;/* To fragment full datagrams*/
Sbhandle
reseg_buf_ptr;/* To fragment fragments*/
Sbhandle
rsm_buf_ptr;/* To reassemble fragments*/
} IpT_Rte_Module_Data;
183
Anexo C. Estructuras y variables importantes
C.3. oms_qm.h
En éste fichero hay muchas estructuras importantes, pues es el que tiene los elementos necesarios
para implementar el manejo de colas en OPNET. Ya se ha dicho en el Capítulo 4 que éste es uno de
los ficheros que se han modificado, añadiendo una nueva constante OMSC_GRED a las ya
existentes. Los tipos enumerados se utilizarán para asignar valores a algunos de los campos de las
estructuras y para tomar decisiones de procesamiento mientras la simulación.
•
Estructura de tipos enumerados para las disciplinas de cola:
typedef enum
{
OmsC_Qm_No_Queuing = -1,
OmsC_Qm_FIFO_Queuing = 0,
…
OmsC_Qm_Max_Queuing_Schemes = 9 /* should be last-but-one entry */
} OmsT_Qm_Queuing_Scheme;
•
Estructura de tipos enumerados que indica características de los datos:
typedef enum
{
…
OmsC_Qm_Discard_Class = 250,
OmsC_Qm_Packet_Size = 550,
OmsC_Qm_Queue_Number = 660,
OmsC_Qm_Route_Map = 800,
…
} OmsT_Qm_Property_Type;
•
OmsC_Qm_Dscp = 300,
OmsC_Qm_Ip_Precedence = 600,
OmsC_Qm_Protocol= 650,
OmsC_Qm_Type_of_Service= 900,
Definición de tipos enumerados con los posibles valores de ToS que se pueden asignar según
la precedencia, el tipo de tráfico, disciplina, etc. En este proyecto se ha tenido en cuenta sólo el
caso Best Effort, puesto que no se aplica ningún método de calidad de servicio salvo AQM:
typedef enum OmsT_Qm_Tos
{
OmsC_Qm_Tos_Unspecified = -1, OmsC_Qm_Best_Effort = 0,
OmsC_Qm_Background = 32,
OmsC_Qm_Standard = 64,
OmsC_Qm_Excellent_Effort = 96, OmsC_Qm_Streaming_Multimedia
…
} OmsT_Qm_Tos;
•
Definición de tipos enumerados que indican qué hacer con un determinado paquete. Entre los
elementos, descartan por ejemplo OmsC_Qm_Dropped_Packet o OmsC_Qm_Queued_Packet, que
se vió anteriormente que aparecen en la función Oms_Qm_incoming_Packet_Handler para ver
si se debe o no descartar el paquete que llega:
typedef enum
{
OmsC_Qm_Send_Packet = 0,
OmsC_Qm_Dropped_Packet = 1,
OmsC_Qm_Queued_Packet = 2, OmsC_Qm_Dequeue_Abort = 3,
OmsC_Qm_Dequeue_Packet = 4, OmsC_Qm_Invalid_Signal
} OmsT_Qm_Signal;
184
= 128,
Control de Congestión con OPNET
•
Definición de tipos enumerados para algunos de los atributos que puede haber en una cola:
typedef enum
{
…
OmsC_Qm_RED_Status, /* RED attribs should be the last group */
OmsC_Qm_RED_Match_Property,
OmsC_Qm_RED_Match_Value,
OmsC_Qm_RED_Exp_Weight_Factor, OmsC_Qm_RED_Min_Threshold,
OmsC_Qm_RED_Max_Threshold,
OmsC_Qm_RED_Prob_Denominator,
OmsC_Qm_Max_Attrib_Type
} OmsT_Qm_Attribute_Type;
•
Estructura que alberga las características de un paquete necesarias para saber en qué cola se
debe almacenar y cómo aplicar QoS sobre él dependiendo de su precendencia, destino,
prioridad, etc:
typedef struct IpT_Pkt_Info
{
int
drop_precedence; /* Used by RED while dropping packets. */
OmsT_Qm_Tos tos;
/* Type of Service of the packet.
*/
int
protocol;
/* protocol of the packet.(TCP/UDP/etc.)*/
InetT_Address source_address; /* source_address of the packet.
*/
InetT_Address dest_address;
/* destination address of the packet.*/
int
source_port;
/* source port of the packet.
*/
int
dest_port;
/* destination port of the packet.
*/
int
incoming_iface;
/* Incoming interface for the packet.
*/
int
queue_id; /* Queue to which this packet belongs.*/
int
CE, ECT, packet_size, loss_priority, queue_number;
Boolean pk_fragment;
Packet* pkptr;
} IpT_Pkt_Info;
•
De esta estructura, interesa saber que contiene el identificador de la cola:
typedef struct AtmT_Pkt_Info
{
int queue_id;
…
} AtmT_Pkt_Info;
Las dos estructuras anteriores están contenidas dentro de una unión que forma la estructura
OmsT_Qm_Pkt_Info, que es ampliamente utilizada en varias de las funciones explicadas en el
Capítulo 4, pues es a partir de la que se va a acceder a toda la información de cada paquete.
Las siguientes dos estructuras, implementan lo que sería la jerarquía de colas. Como recordatorio,
en OPNET una cola puede contener varias subcolas, y éstas a su vez contener más subcolas, y así,
hasta el nivel que el modelador considere oportuno, teniendo todas la misma estructura. Por ello, la
primera estructura alberga características de una subcola simple, con referencia a la cola padre, y la
segunda tiene campos que son punteros a arrays de colas. A continuación se muestran las dos:
185
Anexo C. Estructuras y variables importantes
•
Estructura de datos concretos para una cola simple o una subcola. Contiene campos de tipo
void* que durante la simulación se asociarán a tipos contretos mediante operaciones de tipo
cast.
typedef struct
{
OmsT_Qm_Queue_Pool*
parent_queue_pool_ptr; /*Referencia a la cola padre,
en caso de ser subcola. */
int
queue_index;
/* Índice de la cola */
OmsT_Buffer_Handle buffer_handle; /*Buffer asociado para almacenar paquetes.*/
void* drop_policy_vars_ptr; /* Variables para aplicar políticas de descarte */
void* qscheme_vars_ptr;
/*Variables específicas para disciplinas de cola.*/
OmsT_Qm_Stats
queue_stats; /* Acceso a estadísticas asociadas a la cola. */
OmsT_Stat_Data* qdelay_stat_data_ptr; /* Maintain samples for queue delay */
OmsT_Qm_Pkt_Info pkt_info;
/* Información IP del paquete */
…
} OmsT_Qm_Queue_Info;
•
Esta estructura contiene las características del nivel superior de una jerarquía de colas (puede
contener varias subcolas), de ahí que tenga un campo de su propio tipo, y otro del tipo de la
estructura anterior, que se refiere a las características de cada cola en particular:
struct OmsT_Qm_Queue_Pool
{
OmsT_Qm_Queue_Pool* parent_queue_pool_ptr; //Referencia al la cola padre
OmsT_Qm_Queue_Info** queue_info_parray; //Información de este conjunto de colas
OmsT_Qm_Queue_Pool** queue_pool_parray; //Array de subcolas que contiene
OmsT_Qm_Attributes*
attributes_ptr;
OmsT_Buffer_Pool_Handle buffer_pool_handle;//Buffer asociado al conjunto
OmsT_Qm_Queuing_Scheme queue_processing_scheme;//Disciplina asociada a las colas
/* Variables específicas a las disciplinas de cola. Estan determinadas por la
cola padre, si es el caso.*/
void*
qscheme_vars_ptr;
int
queue_to_service; /* Cola que se está utilizando */
OmsT_Qm_Info*
qmgmt_info_ptr;
};
•
Variables necesarias para el algoritmo RED, en concreto, para la actualización del tamaño
medio de cola:
typedef struct
{
double average_queue_size;
double start_idle_time;
} OmsT_Qm_RED_Vars;
•
De ésta estructura, lo que interesa es el campo queue_configuration, que será el que después
accederá a la estructura OmsT_Qm_IP_Queue_Configuration explicada anteriormente:
struct OmsT_Qm_Attributes
{
186
Control de Congestión con OPNET
int
no_queues;
int
default_queue;
int
max_total_no_buf_pkts;
…
void**
queue_configuration;
…
/* Numero de colas o subcolas */
/* Cola para paquetes por defecto. */
/* Maximo número de paquetes almacenados.
*/
/* Parámetros de configuración de la cola. */
};
•
Estructura con algunos de los parámetros RED relativos a la elección de descarte de paquetes
para cada cola IP:
typedef struct
{
OmsT_Qm_Property_Type match_property;
int
exponential_weight_factor;
Boolean
ce_marking;
/*Bandera indicadora de ECN habilitado. */
List
*red_class_params_lptr;
} OmsT_Qm_RED_Queue_Params;
•
Estructura con los parámetros relativos a cada clase de descarte dentro de la cola. Nosotros
hemos jugado con una clase de descarte única para toda la simulación, por lo que sólo habrá
una estructura de éste tipo. Si aplicaramos más clases de descarte, se rellenaría ésta estructura
para cada una de las clases. Esto se elije mediante el parámetro QoS FIFO Profiles RED
Parameters Mark Probability denominator. Si en vez de configurarlo con un solo valor,
se configura dándole una cadena de números separados por una coma, cada uno de esos
números implicaría una clase de descarte.
typedef struct
{
OmsT_Qm_Tos
match_value;
int
minimum_threshold; /* Umbral
int
maximum_threshold; /* Umbral
int
mark_probability_denominator;
cuando la probabilidad es
} OmsT_Qm_RED_Class_Params;
•
mínimo configurado en los atributos.*/
máximo del algoritmo RED.*/
/* Fracción del tráfico descartado
maxima.*/
La siguiente estructura es una definición de tipos de funciones enumeradas que van a servir
como identificadores de las posiciones de la tabla global OmsT_Qm_Arch_Void_Func de la que
ya se habló antes, cuya definición era:
/* Global Table to maintain architecture specific functions */
extern
OmsT_Qm_Arch_Void_Func
OmsI_Arch_Specific_Func_Table
[OmsC_Qm_Max_Arch_Types] [OmsC_Qm_Max_Arch_Func_Types];
typedef enum
{
OmsC_Qm_Attribute_Get_Func = 0,
OmsC_Qm_Enqueue_Test_Func,
OmsC_Qm_Drop_Policy_Vars_Create_Func,
OmsC_Qm_Drop_Policy_Vars_Update_Func,
OmsC_Qm_Drop_Policy_Vars_Delete_Func,
OmsC_Qm_Dequeue_Time_Get_Func,
OmsC_Qm_Dequeue_Schedule_Func,
OmsC_Qm_Dequeue_Test_Func,
OmsC_Qm_Service_Time_Get_Func,
OmsC_Qm_Get_Pool_Weight_Func,
OmsC_Qm_Micro_Sim_Enable_Func,
OmsC_Qm_Max_Arch_Func_Types
/* should be the last entry */
187
Anexo C. Estructuras y variables importantes
} OmsT_Qm_Arch_Func_Types;
•
Para un propósito similar se define la siguiente estructura:
typedef enum
{
OmsC_Qm_Pkt_Deq_Complete = 0,
OmsC_Qm_Queue_Select,
OmsC_Qm_Qscheme_Vars_Init,
OmsC_Qm_Qscheme_Vars_Update_Enq,
OmsC_Qm_Max_Qscheme_Func_Types /* should
OmsC_Qm_Qscheme_Vars_Create,
OmsC_Qm_Qscheme_Vars_Update_Deq,
OmsC_Qm_Qscheme_Vars_Delete,
be the last entry */
} OmsT_Qm_Qscheme_Func_Types;
Asociada con la tabla global que también hemos visto con anterioridad:
/* Global Table to maintain Qscheme specific functions */
extern
OmsT_Qm_Qscheme_Void_Func
OmsI_Qscheme_Specific_Func_Table
[OmsC_Qm_Max_Queuing_Schemes] [OmsC_Qm_Max_Qscheme_Func_Types];
188
Control de Congestión con OPNET
Anexo D. Pautas para la
modificación del funcionamiento
del algoritmo RED
Se ha pensado en una posible extensión de este proyecto que sería sencilla a partir de lo explicado,
pero que no se ha podido llevar a cabo por problemas de tiempo.
La modificación consiste en cambiar la frecuencia con la que se ejecuta el algoritmo RED, pasando
de ser cada vez que llega un paquete a producirse cada cierto intervalo de tiempo o período de
muestreo. Este nuevo algoritmo, lo podríamos llamar CRED.
Los cambios a realizar serían del orden de los hechos para extender la aplicación con el algoritmo
GRED. Habría que editar el modelo de proceso ip_output_iface, añadiendo una variable de
estado que lleve el control del tiempo y otra que contenga el intervalo de muestreo.
En el header block habría que añadir la macro correspondiente a una interrupción, que consiste en
comprobar si se ha agotado el tiempo indicado por la variable de muestreo.
En el Function Block, definir una función que calcule el tamaño medio de cola y la probabilidad de
pérdida, reutilizando o llamando a las funciones Oms_Qm_Average_Queue_Size_Update y
oms_qm_red_drop_packet.
El funcionamiento sería de la siguiente forma:
1.
Comienza la ejecución del modelo de proceso ip_output_iface. Inicialización de un
contador de tiempo. La inicialización de variables se podría realizar en el estado init.
2.
En el estado idle, esperar por una de las interrupciones, entre las cuales se añade una que
tenga en cuenta el tiempo que ha pasado desde que se ejecutó la última vez el algoritmo
CRED.
3.
Una vez agotado el tiempo del temporizador, se lanza una interrupción que termina en el
mismo estado, y que estará aparejada a un transition executive en el que se llama a la
función que calcula los parámetros de RED y almacena la probabilidad de pérdida del
paquete en una variable.
4.
Ya en el estado idle de nuevo, y con la probabilidad de pérdida del paquete calculada, se
procede como se ha hecho hasta entonces, llamando a la función enqueue_packet, en la
que habría que hacer alguna operación para advertir que el algoritmo utilizado es CRED, y
189
Anexo D. Pautas para la modificación del algoritmo RED en OPNET
que la probabilidad de descarte ya está calculada, para no volver a realizar de nuevo las
llamadas que se hacen para el algoritmo RED tradicional.
Para poder configurar el algoritmo desde el modelo de procesos, es el mismo procedimiento que se
ha seguido para el caso de GRED.
Estos pasos son orientativos, puesto que se ha pensado cómo hacer el algoritmo pero no se ha
hecho físicamente, por lo que puede ser que para que funcione CRED haya que tenerse en cuenta
más cosas que las explicadas. No obstante, se espera que sea una buena base para la continuación
de futuros trabajos.
190
Control de Congestión con OPNET
Anexo E. Herramientas utilizadas
D.1 VisualC ++
Compilador de código C y C++ que transforma código fuente en código ejecutable. Necesario para
compilar los modelos de proceso utilizados en OPNET antes de la simulación.
D.2 OPNET Modeler
Modelador y simulador de redes. Es la principal herramienta utilizada en éste proyecto tanto para
modelar las topologías como para realizar las simulaciones y estudiar el código fuente de los
modelos de proceso.
D.3 Notepad ++
Editor gratuíto de código fuente, que soporta varios lenguajes de programación y se ejecuta en MS
Windows. Se distribuye bajo la licencia pública de GNU. Utilizado en este proyecto para revisar y
editar el código fuente de los ficheros de cabecera (extensión .h) y de los ficheros de código
externo (extensión .ex.c).
191