Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Universidad de Valladolid
E. T. S. DE INGENIERÍA INFORMÁTICA
Ingeniería Técnica en Informática de Sistemas
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.
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
9
Indice
10
Control de Congestión con OPNET
Índice de ilustraciones
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
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.
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.
• 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.
• 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.
17
Capítulo1. Introducción
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
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
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.
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
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.
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 5. Experimentos
En este capítulo se muestran los experimentos realizados junto con las gráficas que muestran los
resultados obtenidos.
Por último, se incluye la bibliografía utilizada como referencia en este proyecto, y un glosario de
términos básicos.
21
Capítulo1. Introducción
22
Control de Congestión con OPNET
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.
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.
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.
24
Control de Congestión con OPNET
2.2.1 Introducción
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.
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.
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.
- 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.
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.
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.
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.
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.
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.
• 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
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.
• 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.
32
Control de Congestión con OPNET
Existen varios mecanismos de planificación, entre ellos se ha considerado oportuno citar los
siguientes:
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.
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.
34
Control de Congestión con OPNET
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
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.
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:
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:
Esta situación es considerada como el estado normal de operación. Aquí, ningún paquete es
marcado o descartado, simplemente se encola.
Se pone en marcha el mecanismo de prevención de congestión. Los paquetes que lleguen serán
notificados con una probabilidad Pd .
37
Capítulo 2. Conceptos Teóricos
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.
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.
38
Control de Congestión con OPNET
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:
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.
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
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.
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).
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.
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.
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.
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
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
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:
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:
46
Control de Congestión con OPNET
3.3.1.4 Receptor:
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.
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.
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
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.3 Atributos
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).
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.
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.
• 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.
49
Capítulo 4. Implementación del algoritmo RED 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
- 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
Un proceso hijo obtiene la dirección de la memoria que comparte con su padre mediante la
rutina op_pro_parmem_access().
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.
Éstos son:
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().
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.
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.
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().
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
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.
- Creación de procesos dinámicos. Ya se ha hablado de ello. Los procesos crearán otros según las
exigencias de ejecución.
56
Control de Congestión con OPNET
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.
58
Control de Congestión con OPNET
- 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
• 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
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
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.
62
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.
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.
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
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.
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.
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:
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.
65
Capítulo 4. Implementación del algoritmo RED en OPNET
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.
Para entender los siguientes apartados, es necesario conocer los siguientes conceptos:
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.
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.
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.
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
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).
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
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
• 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:
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
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.
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
• 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.
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.
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
- 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.
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
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.
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.
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
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 :
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.
79
Capítulo 4.Implementación del algoritmo RED en OPNET
80
Control de Congestión con OPNET
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.
7. Repetir la operación hasta tener los 5 clientes.
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:
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.
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:
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.
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:
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…
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
6. Guarda tu proyecto.
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.
84
Control de Congestión con OPNET
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.
9. Guarda tu proyecto.
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.
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.
Algunas de las funciones de este menú que se han utilizado en éste estudio son:
- 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
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.
87
Capítulo 4.Implementación del algoritmo RED en OPNET
4. Pulsa OK.
- 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
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
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.
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.
90
Control de Congestión con OPNET
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
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:
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.
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.
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:
- 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.
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.
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
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.
• Header Block
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
• Variables de Estado
Destaca la variable:
• Variables Temporales
Sólo se usan dentro del STD:
• 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:
- 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.
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
En este proyecto nos hemos centrado en FIFO, por lo que no se contemplarán el resto de opciones.
• Function Block
/*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
/* 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;
}
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):
if (qconfig_ptr->red_status == OMSC_NO_RED)FOUT;
98
Control de Congestión con OPNET
/* 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);
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 OMSC_NO_RED 0
#define OMSC_RED 1
#define OMSC_WRED 2
#define OMSC_GRED 3
99
Capítulo 4.Implementación del algoritmo RED en OPNET
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.
É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.
De momento, se debe saber que las tres están definidas en el fichero externo
ip_qos_support.ex.c,
dependiente de oms_qm.h, fichero incluído a través del header block.
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
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:
• 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 . Aparece la siguiente ventana, que son los
atributos de los que está compuesto el atributo.
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.
102
Control de Congestión con OPNET
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.
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):
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).
Aparece una nueva ventana (se muestra a continuación), con los atributos de RED Parameters,
incluido el del atributo GRED añadido anteriormente.
• Data Type: Nos dice el tipo de atributo que estamos editando (que compuesto).
• Units: Unidades en que está expresado el valor (vacío, al ser atributo compuesto).
104
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:
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:
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:
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).
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.
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.
107
Capítulo 4.Implementación del algoritmo RED en OPNET
Abrir el proyecto CuelloBotella y dar doble clic sobre el nodo Router1. Se abrirá una ventana con
el modelo de nodos residente.
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
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:
109
Capítulo 4.Implementación del algoritmo RED en OPNET
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.
• 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
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.
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.
- 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.
- 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.
…
/* Lista para guardar los procesos registrados */
proc_record_handle_list_ptr = op_prg_list_create ();
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. **/
112
Control de Congestión con OPNET
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 ()
{
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;
}
IpT_Rte_Module_Data * module_data_ptr;
IpT_QoS_Profiles_Dbase * profiles_dbase_ptr;
/* Notificaciones */
ip_qos_notif_log_handles_init();
114
Control de Congestión con OPNET
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
IpT_QoS_Bandwidth_Type bw_type;
IpT_QoS_Iface_Info * iface_qos_info_ptr;
IpT_QoS_Iface_Config * qos_iface_config_ptr = OPC_NIL;
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.
IpT_QoS_Scheme_Type scheme_type;
IpT_QoS_Mechanism_Info * qos_mechanism_info_ptr;
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
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;
qos_iface_config_ptr = (IpT_QoS_Iface_Config *)
118
Control de Congestión con OPNET
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.
/* 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
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.
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
Basta con seleccionar uno de ellos y aparecerá la correspondiente ventana del editor de procesos.
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
• 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.
#define RECEIVE_PACKET
((invocation_mode == OPC_PROINV_INDIRECT) && (rsvp_call_type == RsvpC_Invalid))
122
Control de Congestión con OPNET
• STD
- 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.
123
Capítulo 4.Implementación del algoritmo RED en OPNET
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;
…
}
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):
124
Control de Congestión con OPNET
…
/* Devolver la estructura qm_info con toda la información concerniente a las
colas de una interfaz. */
FRET (qm_info);
}
…
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:
- 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.
126
Control de Congestión con OPNET
/* Obtener el paquete.*/
pkptr = (Packet *) op_pro_argmem_access ()) == OPC_NIL
/* 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.*/
qm_info->sending_packet_ptr = pkptr;
qm_info->processor_busy = OPC_TRUE;
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).
pkt_info.pk_fragment = OPC_FALSE;
}
else if(op_pk_nfd_access (pkptr, "fields" ,&pk_fd_ptr)!= OPC_COMPCODE_FAILURE)
{
int incoming_iface;
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;
128
Control de Congestión con OPNET
OmsT_Qm_Queue_Pool*qpool_ptr = OPC_NIL;
OmsT_Qm_Pkt_Infopkt_info;
intenq_id = OMSC_UNASSIGNED;
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;
}
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.
…
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;
}
130
Control de Congestión con OPNET
FRET (OPC_TRUE);
}
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.
…
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];
131
Capítulo 4.Implementación del algoritmo RED en OPNET
/* ----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.
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);
}
}
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.
FOUT;
}
133
Capítulo 4.Implementación del algoritmo RED en OPNET
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.
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;
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
/* 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);
135
Capítulo 4.Implementación del algoritmo RED en OPNET
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:
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);
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
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
ip_dispatch.pr.c ip_dispatch_cleanup_and_create_child_processes
ip_rte_qos_informacion_process
do_init
ip_output_iface.pr.c 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_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_support.ex.c 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.ex.c 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
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))
{
140
Control de Congestión con OPNET
dropping_probability =
((1.0-maxp)* (avge_queue_size- max_threshold))/max_threshold + maxp;
cuya función es evitar que se descarten paquetes cuando se ha sobrepasado el umbral máximo en
RED .
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 .
• Acceder al modelo de nodos del nodo QoS (doble clic sobre el nodo en el editor de
proyectos).
• Una vez seleccionado RED Status, pulsar el botón Edit Compound Attribute Properties.
• 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.
• 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.
142
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.
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:
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.
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.
145
Capítulo 5. Experimentos
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.
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.
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.
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.
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.
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.
Ajuste de Perfil_FTP
Operation Mode stara Duration Inter-Rep. Number Pattern
Time Time of Reps
Simultaneous const(0.5) End of const(50) const(4) Concurrent
Simulation
148
Control de Congestión con OPNET
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.
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
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.
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.
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.
153
Capítulo 5. Experimentos
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
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
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
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.
157
Capítulo 5. Experimentos
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
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
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
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.
En este experimento se debe resaltar también que RED es el escenario que permanece más estable
163
Capítulo 5. Experimentos
Ajuste de Perfil_FTP
Operation Mode stara Duration Inter-Rep. Number Pattern
Time Time of Reps
Simultaneous const(0.5) End of const(50) const(4) Concurrent
Simulation
TCP: Tahoe
164
Control de Congestión con OPNET
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)
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.
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.
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.
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.
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.
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
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
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 Nivel-
Paquete 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.
[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
[9] K. Ramakrishnan, S. Floyd, D. Black. “The Addition of Explicit Congestion Notification (ECN)
to IP”.RFC 3168. Sept. 2001.
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
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.
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.
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.
FTP: File Transfer Protocol. Protocolo de transferencia de archivos. Protocolo utilizado para la
transferencia de archivos en la red.
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.
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.
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.
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).
174
Control de Congestión con OPNET
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
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:
• Una carpeta para los proyectos creados por el usuario, denominada por defecto
op_models.
• 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:
177
Anexo B. Guia para integrar el algoritmo GRED en OPNET
4. 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:
178
Control de Congestión con OPNET
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;
typedef enum
{
IpC_No_Queuing = OmsC_Qm_No_Queuing,
IpC_FIFO_Queuing = OmsC_Qm_FIFO_Queuing,
IpC_WFQ_Queuing = OmsC_Qm_WFQ_Queuing,
IpC_Priority_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;
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 bandwidth_type;
IpT_Queuing_Scheme queuing_scheme;
…
OmsT_Qm_Attributes * qm_attr_ptr;
OmsT_Qm_Attributes * llq_qm_attr_ptr;
}IpT_QoS_Iface_Config;
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;
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. :
182
Control de Congestión con OPNET
Objid module_id;
Objid node_id;
char* node_name;
Prohandle ip_root_prohandle;/* ip_dispatch */
…
OmsT_Dv_Proc_Scheme processing_scheme;
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.
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;
typedef enum
{
…
OmsC_Qm_Discard_Class = 250, OmsC_Qm_Dscp = 300,
OmsC_Qm_Packet_Size = 550, OmsC_Qm_Ip_Precedence = 600,
OmsC_Qm_Queue_Number = 660, OmsC_Qm_Protocol= 650,
OmsC_Qm_Route_Map = 800, OmsC_Qm_Type_of_Service= 900,
…
} OmsT_Qm_Property_Type;
• 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:
• 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
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:
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 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
• 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 mínimo configurado en los atributos.*/
int maximum_threshold; /* Umbral máximo del algoritmo RED.*/
int mark_probability_denominator; /* Fracción del tráfico descartado
cuando la probabilidad es maxima.*/
} OmsT_Qm_RED_Class_Params;
• 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;
typedef enum
{
OmsC_Qm_Pkt_Deq_Complete = 0,
OmsC_Qm_Queue_Select, OmsC_Qm_Qscheme_Vars_Create,
OmsC_Qm_Qscheme_Vars_Init, OmsC_Qm_Qscheme_Vars_Update_Deq,
OmsC_Qm_Qscheme_Vars_Update_Enq, OmsC_Qm_Qscheme_Vars_Delete,
OmsC_Qm_Max_Qscheme_Func_Types /* should be the last entry */
} OmsT_Qm_Qscheme_Func_Types;
Asociada con la tabla global que también hemos visto con anterioridad:
188
Control de Congestión con OPNET
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.
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.
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
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.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