Control de Congestión con OPNETtere/memoria.pdf · Control de Congestión con OPNET 3 AGRADECIMIENTOS En primer lugar quisiera agradecer a mi tutora, Teresa, por su trato cercano

Control de Congestión con OPNET

1

Universidad de Valladolid

E. T. S. DE INGENIERÍA INFORMÁTICA

Ingeniería Técnica en Informática de Sistemas


Alumna: Lourdes Nicolás Fernández Tutora: Mª Teresa Álvarez Álvarez


3

AGRADECIMIENTOS

En primer lugar quisiera agradecer a mi tutora, Teresa, por su trato cercano. Su ayuda y su optimismo me han dado ánimo en aquellos momentos en los que no sabía cómo seguir adelante con el proyecto, o pensaba que no iba a terminar a tiempo. A mis padres y mi a hermano, las personas más importantes para mí, que me han dado su cariño y su apoyo incondicional durante todos estos años de la carrera. Muchas veces he descargado mi frustración con vosotros injustamente. Gracias por ser pacientes conmigo. Por supuesto también debo agradecer al resto de mi familia: mis tíos y primos, y especialmente a mis abuelos, que siempre están pendientes de mí. Es una suerte poder seguir contando con ellos. A Pablo, por ser mi punto de apoyo del día a día y por sacar siempre tiempo y paciencia para escucharme. Tus consejos y tu compañía me hacen recuperar la fuerza cuando más débil me siento y la estabilidad cuando todo se derrumba a mi alrededor . Se dice que un amigo es una persona con la que se puede pensar en voz alta. Muchas gracias a vosotras, Rocío y Virginia, por “pensar” conmigo tantas veces a lo largo de todos estos años de universidad, en los momentos buenos y en los malos. Que sepáis que os tocará seguir escuchándome por unos cuantos años más… También debo agradecer a la gente de fuera de la universidad: a Luis, Tatiana, Pedro y los demás… por los momentos inolvidables que hemos pasado juntos, y lo que todavía nos queda. Debo dedicar un agradecimiento especial a Rubén, un gran amigo que siempre está ahí, y una de las personas que más me ha ayudado durante toda la carrera. Sin tu consejo y tu ayuda este camino habría sido mucho menos llevadero.

Por todo ello, muchas gracias a todos,

Lourdes.


5

Í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

Indice

6

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


7

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

Indice

8

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


9

ANEXO B. GUIA PARA INTEGRAR EL ALGORITMO GRED EN OPNET ..................... 177

ANEXO C. ESTRUCTURAS Y VARIABLES IMPORTANTES ............................................ 179

C.1 IQ_QOS_SUPPORT.H .............................................................................................................. 179 C.2. IP_RTE_SUPPORT.H .............................................................................................................. 182 C.3. OMS_QM.H........................................................................................................................... 184

ANEXO D. PAUTAS PARA LA MODIFICACIÓN DEL FUNCIONAMIENTO DEL ALGORITMO RED ..................................................................................................................... 189

ANEXO E. HERRAMIENTAS UTILIZADAS.......................................................................... 191

D.1 VISUALC ++......................................................................................................................... 191 D.2 OPNET MODELER ............................................................................................................... 191 D.3 NOTEPAD ++ ........................................................................................................................ 191

Indice

10


11

Índice de ilustraciones

Ilustración 1. Vista de la sección de clientes de la página de OPNET ............................................. 18 Ilustración 2. Fragmento del árbol de contenidos de la documentación de OPNET utilizada para éste proyecto ..................................................................................................................................... 20 Ilustración 3. Ejemplo de un caso de congestión.............................................................................. 24 Ilustración 4. Estructura de un segmento TCP ................................................................................. 28 Ilustración 5. Ventana de congestión y cola en TCP ........................................................................ 30 Ilustración 6. Planificación de Colas FIFO...................................................................................... 33 Ilustración 7. Funcionamiento de FQ............................................................................................... 34 Ilustración 8. Comparación entre el tamaño real de cola y el valor que toma Qavg ....................... 37 Ilustración 10. Probabilidad de descarte de RED y de GRED......................................................... 39 Ilustración 11. Pantalla de inicio del Simulador OPNET................................................................. 41 Ilustración 12. Vista de varios editores en OPNET .......................................................................... 42 Ilustración 13. Interacción de un módulo transmisor con el modelo de nodos y el de red............... 46 Ilustración 14. Jerarquía de procesos en OPNET ............................................................................ 50 Ilustración 15. Memoria padre-hijo en una jerarquía de procesos .................................................. 51 Ilustración 16. Esquema de input streams en un QP. ....................................................................... 53 Ilustración 17. Estadísticas locales en el modelo de proceso ip_output_iface ................................. 54 Ilustración 18. Ejemplo de STD: ip_output_iface............................................................................. 57 Ilustración 19. Flujo de ejecución a través de unforced states......................................................... 59 Ilustración 20. Modelado con forced states ...................................................................................... 60 Ilustración 21. Representación de transiciones en un STD .............................................................. 61 Ilustración 22. Declaración de variables de estado en ip_output_iface........................................... 63 Ilustración 23. Declaración de variables temporales en ip_output_iface ........................................ 64 Ilustración 24. Dos tramos de la lista de ficheros externos en ip_dispatch...................................... 65 Ilustración 25. Acceso a los atributos del modelo de procesos qos_attribute_definer ..................... 66 Ilustración 26. Distribución típica de eventos durante el tiempo de simulación .............................. 69 Ilustración 27. Organización de una lista de eventos durante el tiempo de ejecución ..................... 70 Ilustración 28. Ventana de preferencias en OPNET......................................................................... 75 Ilustración 29. Paleta de objetos ...................................................................................................... 77 Ilustración 30. Nodos en el espacio de trabajo del editor de proyectos ........................................... 78 Ilustración 31. Atributos del nodo Perfiles ....................................................................................... 80 Ilustración 32. Un paso en la configuración de un Cliente .............................................................. 81 Ilustración 33. Tabla para elegir destino de Cliente1 ...................................................................... 82 Ilustración 34. Elección de la disciplina FIFO en las interfaces de los routers conectados............ 83 Ilustración 35. Unión entre routers con las interfaces configuradas ............................................... 84 Ilustración 36. Menú para elegir estadísticas................................................................................... 84 Ilustración 37. Ventana de elección de estadísticas sin desglosar ................................................... 84

Indice

12

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


13

Ilustración 88. E5, Retardo global en la red, valores medios......................................................... 166 Ilustración 89. E5, Utilización del buffer en el Router1. ................................................................ 167 Ilustración 90. E5, Retardo en el Router1, valores medios. ........................................................... 167 Ilustración 91. Tamaño medio de cola de GRED (azul) y RED (rojo) ........................................... 168 Ilustración 92. E5, Utilización del enlace....................................................................................... 168

Indice

14


15

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

Capítulo1. Introducción

16

donde reproducir las características reales de una red específica diseñada para tal propósito, pudiendo configurarla fácilmente según la situación que se quiera analizar. Otra ventaja de utilizar simuladores de red, además de cómo herramienta de investigación de protocolos, es que se pueden hacer diversas pruebas sobre el diseño de la futura red sin gasto económico (sólo cambiando ciertos atributos o componentes dentro de la interfaz ofrecida por el simulador), de forma que su correcto funcionamiento queda garantizando antes de implementarla de forma física.

1.1.1 Simuladores de red

Antes de crear una red física real, es conveniente planificar su estructura, protocolos y otros parámetros, para asegurarse que el diseño sea una solución adecuada a la necesidad que se quiere satisfacer mediante la red. Construir directamente una red física podría significar una importante pérdida de dinero y tiempo si una vez puesta en marcha no cumple las condiciones especificadas inicialmente. De ahí surge la utilidad de usar simuladores de redes. Un simulador de red es una aplicación que permite al usuario diseñar un sistema de redes de comunicación a través de una interfaz gráfica en la que puede elegir los distintos componentes que formarán la red y configurarlos individualmente. El objetivo que busca todo simulador es recrear un modelo lo más fiable posible a la realidad, al menos en cuanto a las características a estudiar, para poder extrapolar los resultados obtenidos mediante la simulación. Los simuladores de redes han madurado desde que aparecieron por primera vez como herramientas de desarrollo, administración y predicción. Hoy en día se les suele utilizar también para estudios de calidad de servicio, además de ser de gran aplicación en el ámbito de la ingeniería. Gracias a la simulación se puede observar la evolución de un sistema de comunicación específico, sus características, propiedades… utilizando como recurso sólo la memoria de un ordenador. Existe un número considerable de herramientas de simulación disponibles. Las características principales que generalmente las describen e influyen a la hora de elegir una u otra son: precisión, rapidez, facilidad de uso y costo. A continuación se cita alguno de éstos simuladores.

• Packet Tracer Es una herramienta de aprendizaje y simulación gratuita desarrollada por la empresa CISCO Systems con fines académicos. Esta herramienta permite a los usuarios crear topologías de red, configurar dispositivos, insertar paquetes y simular una red con múltiples representaciones visuales. Una ventaja que tiene este simulador es que ofrece el análisis de cada proceso que se ejecuta en el programa de acuerdo a la capa del modelo de referencia OSI que interviene en dicho proceso, por ello es muy adecuado para el estudio y aprendizaje del funcionamiento y configuración de las redes de comunicaciones y aplicaciones. Soporta una gran variedad de switches y routers, así como protocolos del tipo HTTP, DNS, TFTP, Telnet, OSPF, VTP y STP.


17

• AdventNet La herramienta de simulación AdventNet comprende un simulador de agente y red con una sencilla interfaz gráfica para el testeo, entrenamiento y demostración de aplicaciones de gestión de redes. Brinda además el editor de topologías para establecer interconexiones a través de routers, switches y otros componentes de red y ver la relación topológica entre ellos. A esto se añade un modelo avanzado de conducta de agentes y redes, generación de trampas, gestión de desperfectos y configuración de los componentes, siendo este simulador especialmente eficaz en la simulación de la conducta de redes en escenarios realistas o negativos.

• Shunra VE Desktop Es una herramienta de simulación de redes ideal para probar el impacto de una red en el desempeño de aplicaciones, permitiendo probar éstas bajo una gran variedad de condiciones de red directamente desde el escritorio del ordenador. Es una de las aplicaciones de este tipo más fáciles de usar y de integrar con el ambiente de trabajo existente. Permite configurar los parámetros de red manualmente o simplemente descargar archivos de escenarios de red predefinidos.

• NS ns (más conocido como ns-2 por su versión actual) es una herramienta muy potente dentro del campo de los simuladores de redes de eventos discretos. Es utilizado principalmente en ambientes académicos debido a que está escrito en código abierto y a la abundancia de documentación existente. De hecho, probablemente es el simulador de redes de código abierto más extendido tanto en investigación como para propósitos docentes. Puede simular una amplia gama de protocolos tanto para redes cableadas o redes wireless, así como mixtas. Existen en ns-2 diferentes niveles de configuración, al ser, como se dijo antes, software de tipo open source. ns-2 fue construido en C++ y proporciona una interfaz de simulación a través de un lenguaje de script llamado Tcl que permite ir generando el modelo. El usuario describe una topología de red escribiendo los citados scripts Tcl y a continuación el programa principal de ns simula la topología con los parámetros especificados. También proporciona una interfaz gráfica llamada nam que permite visualizar las simulaciones e incluso crear y editar modelos a simular. Entre los usos más habituales que se le dan a este simulador son: simular estructuras y protocolos de redes de todo tipo, desarrollar nuevos algoritmos, comprobar su funcionamiento y comparar distintos protocolos en cuanto a prestaciones se refiere.

• Por último, en el siguiente apartado se aporta una pequeña introducción a OPNET Modeler, el simulador utilizado para éste proyecto.


18

1.1.2 Simulador OPNET Modeler

Es un simulador híbrido, basado en simulación de eventos discretos en combinación con un modelo analítico (uso de modelos matemáticos). Utiliza máquinas de estado finitas para modelar el comportamiento de sus diferentes componentes. Puede modelar protocolos, componentes y comportamiento de redes, con alrededor de cuatrocientos modelos de funciones de propósito específico. Hay disponibles varios editores durante el diseño de la simulación, cada uno con sus funcionalidades y su interfaz, siendo los más importantes: proyecto, nodo y proceso, a través de los cuales se puede modificar la configuración de la red, equipo, protocolos y aplicaciones a diferentes niveles. Además, si se dispone de la versión adecuada, como ha sido en nuestro caso, se proporciona acceso al código fuente de las librerías y modelos, siendo esto una gran ventaja a la hora de desarrollar nuevos protocolos o aplicaciones. OPNET es utilizado en el ámbito profesional en todo el mundo. Es utilizado por grandes empresas de telecomunicaciones para desarrollar proyectos de distinta índole. Podríamos citar por ejemplo empresas como Telefonica International, Motorola Inc., Emirates Airlines, Thales, Ericsson etc. como se muestra en la siguiente imagen sacada de la página web oficial de OPNET, http://www.opnet.com

Ilustración 1. Vista de la sección de clientes de la página de OPNET

Aparte de sus aplicaciones comerciales, es destacable remarcar que mientras se ha realizado este proyecto, se ha observado que hay un gran número de universidades españolas (por ejemplo la Universidad Politécnica de Cataluña, Universidad de Oviedo, Universidad Politécnica de Madrid, Universidad Politécnica de Valencia, Universidad de Alicante) que usan este programa como herramienta de docencia, por la facilidad con la que se puede mostrar a los estudiantes el comportamiento de una red gracias al realismo de los resultados obtenidos en sus simulaciones.


19

1.2 Objetivo del proyecto

Uno de los puntos principales de este proyecto es estudiar el funcionamiento y la técnica de modelado utilizada por el simulador OPNET, centrándose en concreto en cómo se trata la implementación del algoritmo RED con vista a extender la funcionalidad del simulador. Mediante este trabajo se trata, por tanto, de aportar a futuros usuarios ideas que sirvan como punto de inicio o referencia para la extensión del programa si se quieren añadir algoritmos de gestión activa de colas. El estudio del programa se hará primero desde el punto de vista teórico y general, describiendo cómo funcionan sus diferentes niveles de implementación, y después mediante un desarrollo detallado de cómo y dónde se pueden hacer modificaciones en el código para añadir algoritmos de gestión activa de colas. También se mostrará cómo se ha añadido el algoritmo GRED al simulador, qué ficheros se han modificado y cómo se ha configurado una nueva interfaz de atributos para que dicho algoritmo sea accesible al usuario. Para complementar todo lo anterior, se realizan al final varios experimentos para estudiar el comportamiento de distintos AQM presentes en las librerías de modelos de OPNET: Drop Tail, RED y la extensión de éste último que hemos implementado, Gentle-RED.

1.3 Recopilación de información

El principal problema con el que nos hemos encontrado a la hora de realizar éste proyecto ha sido comprender de manera más específica e interna la herramienta OPNET ya que, a pesar de la gran cantidad de prácticas y tutoriales que hay por la red, y referencias al programa, en realidad todos se centran en aspectos muy básicos de OPNET, sin meterse en temas más complejos como son la implementación del comportamiento de los modelos de nodos, los modelos de procesos, los tipos de datos, o el funcionamiento interno del programa. Esto se traduce en que cuando se quiere hacer algo más complejo, como implementar redes con parámetros y componentes más específicos, o incluso extender la funcionalidad, añadiendo nuevos protocolos o algoritmos, el usuario se encuentra con que la información que hay es muy escasa e insuficiente. No queda entonces más remedio que explorar todo el sistema de librerías (incluyendo los modelos de proceso del programa, ficheros de cabeceras y ficheros externos) que proporciona el programa para comprender exactamente dónde y cómo extender la funcionalidad. Una ayuda valiosa han sido los artículos científicos sobre el tema, en su mayoría estudios realizados por colectivos de profesores y alumnos de universidades, que aunque poco extensos, han servido como guía para recortar los posibles caminos que iban surgiendo. El problema es que muchos de estos artículos son relativamente modernos (puesto que la propia herramienta OPNET lo es), por lo que es difícil disponer de ellos gratuitamente. Todos los artículos o estudios científicos sobre OPNET citados en la bibliografía han sido obtenidos de páginas y enlaces gratuitos, siendo de dominio público.


20

Otra valiosa referencia, para entender en sí el funcionamiento de OPNET, ha sido la documentación accesible desde los editores del propio programa, en el menú Help › Product Documentation. Una vez en la ventana de la documentación, a la izquierda se encuentra el árbol de contenidos, o si se prefiere, se puede acceder a los contenidos mediante un índice o un buscador. Los apartados de la ayuda más utilizados, y de los que se ha sacado parte de la información y gráficos del Capítulo 3 de esta memoria son los contenidos dentro de Modeler Reference, como se muestra en la siguiente figura

Ilustración 2. Fragmento del árbol de contenidos de la documentación de OPNET utilizada para éste proyecto

Otro apartado valioso dentro de la ayuda de OPNET, sobre todo a la hora de entender el código fuente en el que están implementados los modelos, ha sido Programmers Reference › Discrete Event Simulation, en el que se describen todos los procedimientos o Kernel Procedures (KP) que proporciona el Simulation Kernel, ordenados por paquetes, y que forman parte del lenguaje de programación Proto-C.

1.4 Estructura de la memoria

Esta memoria está estructurada en los 6 capítulos descritos a continuación: Capítulo 1. Introducción En este capítulo se especifica el marco de realización y la motivación del proyecto, incluyendo introducción, objetivo y búsqueda de información.


21

Capítulo 2. Conceptos Teóricos En este capítulo se explica contenido teórico relacionado con las redes de ordenadores, necesario para entender claramente el funcionamiento de los algoritmos de gestión activa de colas, específicamente el algoritmo RED. Capítulo 3. Introducción Teórica al simulador OPNET En este capítulo se describirán aspectos teóricos necesarios para entender el comportamiento de OPNET, como son los distintos entornos de modelado o los fundamentos de la simulación por eventos. Los conceptos se irán enlazando con los casos particulares de estudio en éste proyecto, para ir centrando en todo momento el ámbito del mismo. Capítulo 4. Modelado de AQM en el OPNET En este capítulo se explica paso a paso el modelado de una red, empezando por la creación de una topología, configuración de sus parámetros, estudio del modelo de nodos tanto del nodo de configuración de QoS como del router, terminando con el estudio de tres modelos de proceso y los ficheros externos con los que están relacionados. En todo momento nos centraremos en los componentes que forman parte de la implementación del AQM RED en OPNET. Capítulo 5. Experimentos En este capítulo se muestran los experimentos realizados junto con las gráficas que muestran los resultados obtenidos. Capítulo 6. Conclusiones y líneas futuras En este capítulo se exponen las conclusiones obtenidas tras la realización de este proyecto y se proponen algunas ideas para continuar con futuras líneas de investigación. Por último, se incluye la bibliografía utilizada como referencia en este proyecto, y un glosario de términos básicos. Además de lo anterior, se incluyen cinco Anexos:

• Contenido del CD

• Guía para la utilización de los archivos del CD

• Estructuras de datos importantes en OPNET

• Pautas para la modificación del algoritmos RED

• Herramientas utilizadas


22


23

Capítulo 2. Conceptos Teóricos

2.1 Introducción

En este bloque se irán explicando desde las ideas más generales de la congestión de redes, hasta los mecanismos específicos para prevenirla, o solucionar la situación una vez se ha llegado a ella. Así, será necesario hablar de términos como los protocolos extremo-a-extremo, Calidad de Servicio o la labor de los routers dentro de una red, terminando por hablar de los Algoritmos de Gestión Activa de Colas, donde nos centraremos en especial en RED y alguna de sus variantes.

2.1.1 Situación de las redes actuales

Las redes de ordenadores han crecido vertiginosamente desde sus orígenes tanto en número de usuarios como en prestaciones y servicios ofrecidos. Internet se apoya en el protocolo IP. Éste protocolo es muy simple, se basa en permitir que los paquetes de datos (datagramas) atraviesen routers desde un nodo fuente a uno destino sin la ayuda del emisor ni del receptor. Gracias a la simplicidad que aporta IP a las redes de ordenadores, el tráfico de datos no sólo se ha incrementado (debido al creciente número de usuarios), sino también ha cambiado su naturaleza, apareciendo nuevas aplicaciones que imponen nuevos requisitos en el servicio. El buen funcionamiento de las aplicaciones se puede ver afectado al no poder garantizar los servicios solicitados, su deterioro puede causar problemas significativos a los usuarios, lo que se materializa en una pobre calidad de servicio. La calidad de servicio (QoS, Quality of Service) es un concepto multidimensional que se caracteriza por el retardo extremo-a-extremo introducido, su fluctuación (o jitter), por la pérdida de paquetes y por su disponibilidad. El servicio que ofrece el protocolo IP, no orientado a conexión y best effort, no siempre satisface la calidad de servicio demandada por todas las aplicaciones, especialmente por aquellas con requerimientos de tiempo real. Los recursos disponibles (ancho de banda y capacidad de almacenamiento en routers) son siempre limitados, mientras que la demanda continúa creciendo. Así, en ciertas condiciones de pico, nada impide que localmente la entrada de datos sea superior a la disponibilidad. Para paliar estos problemas, desde sus inicios, se incorporaron medidas para el control de congestión. Entre ellas, los


24

mecanismos de gestión activa de colas (AQM, Active Queue Management). Estos mecanismos consisten en la detección temprana de la congestión reaccionando en base a criterios probabilísticos. La mayoría de las aplicaciones de Internet sin requisitos de tiempo real utilizan el protocolo TCP para recuperar los paquetes perdidos en situaciones de congestión, así como para adoptar medidas reactivas regulando el volumen de tráfico generado. La severidad del problema de la congestión crece en magnitud al crecer el volumen de las demandas de tráfico. Con el protocolo IP y best effort, el intento de entrega al nodo destino puede converger desde uno hasta miles de flujos de paquetes. Si la razón de llegadas de tráfico en un router es superior a la razón de salidas (impuesta por el ancho de banda disponible en el correspondiente enlace), los paquetes recibidos son almacenados en la cola de salida. Dichos paquetes en la memoria de la interfaz de salida (de naturaleza FIFO) serán posteriormente reenviados a su IP destino correspondiente de acuerdo con la tabla de encaminamiento. Una vez que un determinado router sufre congestión, la calidad del servicio de transporte se deteriora, aunque exista exceso de ancho de banda en todo el resto de la ruta. La técnica tradicional para controlar el tamaño de las colas en routers denominada Drop tail, se ha ido sustituyendo por la gestión Activa de Colas, que proporciona un mejor rendimiento en la red en términos de utilización de las líneas, probabilidad de pérdida de paquetes y retardo extremo a extremo.

El control de congestión

El control de congestión es el esfuerzo hecho por los nodos de la red para prevenir o responder a sobrecargas de la red que desembocan en congestión y, por tanto, conducen a perdidas de paquetes y deterioro de la Calidad de Servicio. Durante los siguientes apartados se hablará sobre los mecanismos que contribuyen a ésta tarea y su entorno de aplicación.

Ilustración 3. Ejemplo de un caso de congestión.


25

2.2 Calidad de Servicio

2.2.1 Introducción

Calidad de Servicio es un concepto que caracteriza las prestaciones y el funcionamiento de una comunicación extremo-a-extremo entre dos puntos finales de una red. Otra forma de explicar este concepto sería como la habilidad de un elemento de red (aplicación, host o router) de ofrecer cierto nivel de garantía para que los requisitos del servicio sean satisfechos. En Internet la tecnología dominante proporciona el servicio denominado best effort. Por lo general, cada vez que se requiere información en la red, ésta tiene que transmitirse a través de varias redes, por tanto, la calidad de servicio extremo-a-extremo depende principalmente de las características de QoS de los enlaces y routers por los que tiene que atravesar a su paso. En consecuencia, varias herramientas son imprescindibles para conseguir la QoS necesaria según el tipo de aplicación y usuario. Para sustentar la QoS extremo-a-extremo es importante conocer más acerca del comportamiento dinámico de las redes. Esto es posible lograrlo mediante algunos parámetros que pueden ser medidos y monitoreados en la red. Entre los parámetros más importantes se encuentran: el ancho de banda, el retardo, el jitter y la probabilidad de pérdida de paquetes. Además del popular best effort se han propuesto otros mecanismos, que satisfacen mejor las demandas de nuevas aplicaciones: Servicios Integrados y Servicios Diferenciados. La implementación de QoS puede estar formada por uno de los mecanismos nombrados, o una combinación de los tres. Sin embargo estos mecanismos no son independientes: necesitan cooperar con otros mecanismos menos complejos, como son protocolos extremo-a-extremo y el procesamiento en los routers intermedios, los cuales se discutirán en secciones posteriores.

2.2.2 Mecanismos de QoS

2.2.2.1 Servicio Best Effort

Este servicio no aporta ninguna característica QoS. De hecho, no garantiza cuándo ni cómo se entregarán los datos. Las redes IP tradicionales usan este servicio por ser conveniente para aplicaciones sin restricciones de tiempo, o de baja prioridad como son FTP y SMTP.

2.2.2.2 Servicios Integrados (IntServ)

Definen un modelo que se basa en garantizar QoS a las aplicaciones a través de reservar recursos extremo-a-extremo de la red para cada flujo antes de ser transmitido. Esta reserva se


26

realiza a través de RSVP, que trabaja en paralelo con TCP o UDP. Las aplicaciones solicitan el nivel de servicio necesario para poder trabajar apropiadamente y las reservas son mantenidas hasta que la aplicación termina o mientras cumpla con las demandas solicitadas. Dentro de este modelo se definen dos clases de servicios: servicios de carga controlada y servicios garantizados.

- Servicios de Carga Controlada: Proporcionan al flujo de datos una calidad de servicio lo más cercana posible a la calidad que el mismo flujo recibiría en una red best effort sin cargas. Para ello se utiliza un procedimiento de control de admisión en cada nodo para asegurarse que hay recursos para el flujo y supervisión a pesar de haber sobrecarga. Está especialmente indicado para implementaciones altamente simples que no tengan demandas precisas de QoS, y no proporciona ninguna garantía cuantitativa respecto a retardo y ancho de banda. - Servicios Garantizados: Este tipo de reserva proporciona un retardo controlado extremo-a-extremo de la red y garantiza un ancho de banda para el tráfico conformado con las especificaciones prefijadas. Para ello se necesita conocer las especificaciones del tráfico y las especificaciones de requerimiento de servicio como el ancho de banda y el retardo solicitado. Este servicio está sujeto a un procedimiento de control de admisión en cada nodo.

Ésta arquitectura, si bien garantiza QoS, no es lo suficientemente escalable debido a que el tratamiento por flujos puede dificultar su despliegue en escenarios de grandes demandas. Es muy costoso mantener en cada nodo una tabla de estados y reservas por cada flujo para el control de admisión. Esto conduce a un considerable tráfico de señalización (por el protocolo RSVP) a lo largo del camino, y ocupación de recursos en cada router.

2.2.2.3 Servicios Diferenciados (DiffServ)

Para solucionar el problema de escalabilidad de IntServ se desarrolla la arquitectura de servicios diferenciados o DiffServ. En contraste a la orientación por flujo de RSVP, este modelo se basa en considerar el tráfico en diferentes clases de servicios (Class of Service, CoS), controlar la cantidad de tráfico de cada clase que un cliente envía a la red y asegurar los requerimientos de QoS de varios tipos de aplicaciones utilizando mecanismos de colas en cada nodo con políticas claramente definidas (y dependientes del contrato o compromiso adquirido con el usuario) de scheduling y dropping. El modelo de servicios diferenciados no utiliza la comunicación extremo-a-extremo para la reserva de recursos como lo hace IntServ. Este modelo se aplica a una región de la red y usa un criterio de clasificación agregado basado en reglas predefinidas para agrupar a los paquetes en clases. Para aplicar los parámetros de QoS a las clases, los paquetes son clasificados con algún criterio, marcándolos usando la clave de servicios diferenciados (DSCP, Differentiated Services Code Point), utilizando para ello el campo tipo de servicio (Type of Service, ToS), establecido en la cabecera del paquete IP. El término PHB (Per-Hop Behavior) describe en este modelo el tratamiento específico de envío que recibirá un paquete en el interior de la red después de ser clasificado en una clase dada. Este tratamiento proporciona al paquete un apropiado retardo, ancho de banda jitter, etc.


27

de tal manera que todos aquellos paquetes que contengan igual DSCP recibirán idéntico tratamiento durante su envío. Esta arquitectura logra dar servicios diferenciados a tráfico agregado, es decir, se proporciona un tratamiento por clase, no por flujos; sin embargo se requiere la consideración de mecanismos complicados para negociar los acuerdos del nivel de servicio. Todo ello, además de requerir supervisión de tráfico, clasificación, conformación, marcado y, posiblemente, descarte de paquetes.

2.2.3 Elementos que deterioran la QoS percibida por el usuario

2.2.3.1 Retardo extremo-a-extremo

Dividido en los siguientes:

- Retardo de propagación: Ésta es una fuente de retardo ineludible y se define como el tiempo que se produce durante la transmisión de los datos desde su origen hasta su destino final, directamente relacionada con la velocidad de la luz. Por lo tanto, es función de la distancia que tiene que recorrer. El retardo total de la propagación vendrá dado por Retardo total = distancia/velocidad de la luz.

- Retardo de procesamiento: Este retardo es consecuencia de los sucesivos procesos que tiene que pasar el paquete durante su trayecto desde el envío hasta que es recibido por el usuario final. Estos procesos son codificación y empaquetado, que se llevan a cabo en el emisor, y decodificación y desempaquetado que se realizan en el receptor. Por otra parte existen otros factores que contribuyen a este retardo, como pueden ser el retardo de encolamiento y el de conmutación introducidos por los routers como resultado de la clasificación, almacenamiento temporal (colas de entrada y salida) y conmutación.

- Retardo de transmisión: Es el tiempo que se tarda en transmitir un paquete. Este retardo está en función de la velocidad de la línea de transmisión y la longitud del paquete.

Sumado a todos los retrasos especificados, el retardo extremo-a-extremo se ve afectado además por otro factor: fluctuación o jitter. El transmisor envía cada paquete de una aplicación a un mismo ritmo de salida pero la red (debido a la naturaleza de encolado de los routers IP) puede provocar que el ritmo de llegada en el receptor no sea constante (fluctuaciones en los retardos). La medida de la variación del retardo al llegar al receptor entre paquetes consecutivos de un flujo transmitido se denomina jitter.

2.2.3.2 Pérdida de paquetes y corrupción de datos

Cuanto mayor sea el número de paquetes consecutivos (o longitud de la ráfaga) que se pierdan o se dañen, mayor será la degradación de la calidad suscitada. Las pérdidas de paquetes pueden


28

ocurrir por el descarte generado en una situación de congestión en un router intermedio o como consecuencia de errores provocados por el medio físico de transmisión.

2.3 Protocolos Extremo a Extremo

2.3.1 Protocolos de Transporte TCP y UDP

En la arquitectura de Internet sobre el protocolo IP, entre las aplicaciones y el nivel de red se prevén dos protocolos de transporte: TCP (Transmission Control Protocol) y UDP (User Datagram Protocol), ambos operando extremo-a-extremo, es decir, involucrando a sistemas finales. TCP es el protocolo de transporte predominante en Internet que acarrea la mayor parte del volumen total del tráfico. Este protocolo orientado a conexión es utilizado por un rango de diferentes aplicaciones como son HTTP/HTTPS (WWW), FTP (transferencia de archivos) y SMTP/POP3/IMAP (correo electrónico) entre otras.

Ilustración 4. Estructura de un segmento TCP

Una serie de mecanismos claves determinan la fiabilidad y robustez del protocolo TCP. Los segmentos TCP son transportados en paquetes IP y con el fin de asegurar la entrega de cada segmento, cada paquete contiene 16 bits de datos de información del contenido de la cabecera y del segmento TCP, con los cuales el receptor puede verificar si el dato recibido es correcto o no. Además, los segmentos pueden perderse como consecuencia de errores o por la congestión en la red. Si el paquete es recibido con éxito el receptor envía un paquete de confirmación (segmento con el bit ACK activado) a la fuente. En caso de recibir un dato defectuoso, será descartado por el receptor. Para compensar errores, paquetes perdidos o retrasos, la fuente retransmite cada paquete que no ha sido confirmado después de un tiempo apropiado (se cumple un time-out o expiración de temporizadores).


29

Alternativamente a TCP, otro protocolo de transporte utilizado en Internet es UDP. Éste está especialmente indicado para las aplicaciones multimedia (audio y vídeo), las cuales prefieren pocos retardos, aún asumiendo que la capa de transporte no proporcione fiabilidad ninguna. Es decir, UDP no ofrece control de congestión ni de errores, lo cual puede ser indicado para aplicaciones sencillas que no pueden implementar toda la complejidad que implica el protocolo TCP. Al ser enviados de esta manera, los segmentos UDP no tienen garantía alguna de fiabilidad en la entrega, por lo que no van protegidos frente a las pérdidas en la red durante la congestión. Esto se puede traducir en una posible degradación de la calidad.

2.3.2 Control de congestión en TCP

A diferencia de UDP, el protocolo TCP garantiza la transmisión fiable de los paquetes. Para ello, además de mecanismos que proporcionan control de errores, incorpora mecanismos para el control de congestión con el propósito de lograr que TCP reaccione rápidamente en condiciones de alta congestión, lo cual lo convierte en un importante mecanismo a tener en cuenta también a la hora de proveer QoS. Si una fuente de información TCP detecta que en la transmisión de sus paquetes empieza a haber problemas, (es decir, detecta pérdidas mediante la expiración de los temporizadores arbitrados para la recepción de las correspondientes confirmaciones), asume que dichas pérdidas son siempre debidas a problemas de congestión. Como medida reactiva, en ese caso TCP reduce drásticamente la tasa de transferencia con la esperanza de reducir el número de paquetes perdidos o descartados.

2.3.2.1 Arranque lento y prevención de la congestión

Arranque lento (slow start) y prevención de la congestión (congestión avoidance) son dos de los algoritmos incorporados a TCP utilizados para controlar la tasa de transferencia de paquetes generados, monitorizando permenantemente las prestaciones de la red y determinando la capacidad disponible, para así evitar la congestión incluso cuando se generen grandes ráfagas de paquetes. Estos mecanismos de control tienen objetivos diferentes pero son implementados en conjunto. Para su operación requieren la definición de dos variables por cada conexión TCP: la ventana de congestión cwnd, que determina la cantidad de bytes que el remitente puede transmitir sin necesidad de ser confirmados, y la ventana de recepción, rwnd que especifica el número de bytes que el receptor tiene capacidad para recibir. Para una conexión dada, la cantidad máxima a transmitir estará acotada por el valor mínimo de cwnd y rwnd. Al establecerse la conexión TCP, el transmisor asigna a cwnd el tamaño máximo de segmento para la conexión y por lo tanto envía un paquete con ese tamaño. Al mismo tiempo, mantiene un temporizador de retransmisión que se activa al enviar cada segmento. El algoritmo Slow Start es implementado de la siguiente forma: un segmento es enviado si un ACK es recibido (antes de la expiración del temporizador), el valor de cwnd es incrementado en un segmento. Por lo que ahora, dos segmentos pueden ser enviados y causar dos ACKs. Por cada uno de esos ACKs, cwnd es incrementada en un segmento, de ahí que ahora permite que cuatro segmentos sean enviados. Este proceso de crecimiento exponencial de la ventana de congestión permanece con ese ritmo de crecimiento hasta que ocurre una de las dos posibles alternativas: se alcance el valor acotado de rwnd o se alcance un umbral establecido de antemano denominado ssthresh.


30

Cuando la ventana alcanza el valor ssthresh, TCP pasa a la fase de Prevención de la Congestión, donde en lugar de incrementar cwnd en un segmento adicional por cada ACK recibido, ahora la ventana será incrementada en un segmento por cada RTT. Se está en fase de Prevención de la Congestión hasta que se detecta la pérdida de paquetes (se asume por expiración del temporizador) y es entonces cuando la fuente TCP regresa a la fase de arranque lento, estableciendo cwnd a un segmento y ssthresh a la mitad del tamaño actual de la ventana. En definitiva, lo que se pretende con el arranque lento y la prevención de la congestión es incrementar la tasa de generación de tráfico, mientras no haya problemas y la capacidad de salida lo permita.

Ilustración 5. Ventana de congestión y cola en TCP

2.3.2.2 Retransmisión Rápida y Recuperación Rápida

Además de los anteriores, en TCP se añaden los algoritmos denominados Fast Retransmit y Fast Recovery para detectar y reparar paquetes perdidos. TCP adopta estos algoritmos de control cuando se reciben consecutivamente tres segmentos con el bit ACK activado, que pueden ser provocados por diversos problemas en la red, como la congestión. Tras esta eventualidad, TCP infiere que ha habido una pérdida y reacciona (entra en fase de retransmisión rápida) transmitiendo nuevamente el que parece ser el segmento perdido, sin esperar a que el correspondiente temporizador de transmisión expire. Tras realizar el procedimiento Retransmisión Rápida, la entidad TCP emisora entra en la fase denominada Recuperación Rápida, que es ahora quien controla la retransmisión de nuevos segmentos hasta que llega un ACK que no sea duplicado. Durante éste intervalo, por cada paquete ACK duplicado, (DupAck) que llegue al emisor, la ventana cwnd es incrementada en un segmento. En el instante en que TCP detecta la llegada de un nuevo ACK, asume que la transferencia de paquetes ya es normal, y establece cwnd al umbral establecido al inicio de la transmisión. En caso de que nunca llegue un nuevo ACK, el emisor permanecerá en la fase de recuperación rápida hasta que ocurra la expiración de un


31

temporizador. Estos algoritmos permiten la recuperación rápida de paquetes que se han perdido esporádicamente, sin embargo suele haber problemas para recuperar cuando múltiples paquetes son descartados.

2.3.2.3 Versiones de TCP

• Tahoe Usa los algoritmos Slow Start y Congestion Avoidance para detectar estado de la red y el control de flujo para disminuir la pérdida de segmentos. Se incluye Fast Retransmit para poder hacer la retransmisión de segmentos perdidos lo más rápidamente posible sin esperar a que expire el time-out. • Reno La ventana de congestión crece según Slow Start hasta llegar a un umbral previamente definido a partir del cual comienza fase de prevención de la congestión creciendo la ventana de forma lineal. Es Tahoe con Fast Recovery que evita, en lo posible, que el tamaño de la ventana llegue a dos y se inicie la fase Slow Start en redes que presentan una determinada congestión con picos de gran congestión. El inconveniente más destacado es que, en caso de tener múltiples pérdidas por ventana, el protocolo de Rapid Retransmit no puede recuperar de forma rápida más que la primera pérdida.

• New Reno Intenta solventar los inconvenientes de Slow Start y Congestion Avoidance en relación al tamaño del ssthresh. Intenta buscar un valor de umbral inicial óptimo para el estado de la red mediante el algoritmo Packet-Pair. La fuente envía series de dos paquetes conociendo el intervalo de tiempo entre ambos. Según llegan los ACK se va conociendo el retardo y por tanto el estado de la red, la situación de congestión, etc. También propone una modificación del algoritmo Fast Recovery de forma que en caso de existir varias pérdidas por ventana se soluciona el problema de TCP Reno.

• Vegas Modifica algunos aspectos de los algoritmos de Fast Recovery y Fast Retransmit, así y como del de Slow Start. Como aspecto más relevante, no obstante, es la propuesta a actuar contra la congestión antes de que ésta se detecte por la expiración del temporizador de retransmisión. TCP Vegas introduce un algoritmo para la predicción de la cantidad de datos que el enlace puede cursar sin congestión, e inyecta en el enlace dicha cantidad. Esta predicción se basa en medidas de caudal.


32

2.4 QoS dentro de los Routers

Los mecanismos de control de congestión incorporados a TCP funcionan en los extremos finales y pueden llegar a ser insuficientes para proporcionar un buen servicio en todo tipo de circunstancias. De forma complementaria, en los puntos intermedios de la red o routers, pueden ser incorporados mecanismos de prevención de la congestión. La tarea principal de un router es interconectar redes y encaminar paquetes entre ellas. Cuando un transmisor envía un paquete IP a un destino situado en una red remota, éste siempre pasará al menos por un router o nodo intermedio antes de llegar al receptor. En orden de proporcionar cualquier clase de servicio a los paquetes, éstos deben ser primeramente clasificados. Después, dependiendo de varios parámetros, el router debe tomar la decisión de si los paquetes deben enviarse, almacenarse en colas, descartarse o marcarse, y de qué manera debe hacerse para evitar excesivos descartes y en definitiva, pérdidas de paquetes. Los routers que soportan QoS tienen las funciones definidas en los siguientes apartados

2.4.1 Clasificación

La clasificación de paquetes se puede hacer basándose sólo en el campo ToS de la cabecera de un paquete IP ó en campos adicionales como la dirección IP y el número de puerto de la fuente y destino o en el tipo de aplicación. La clasificación es útil para determinar la interfaz de salida de los paquetes entrantes, además del búfer particular necesario para el almacenamiento, o la reserva de un ancho de banda de salida.

2.4.2 Gestión de colas

Sólo el control de flujo y congestión extremo-a-extremo TCP, como se ha dicho, no es suficiente,. Puede ser que la congestión ocurra también cuando la magnitud del tráfico excede la capacidad de transmisión y procesamiento de los nodos intermedios. Los buffers son usados para absorber éste exceso de tráfico. Sin embargo, por razones de espacio (el tamaño de un búfer es limitado), los routers tienen que marcar o descartar el exceso de tráfico para que así TCP detecte congestión y reduzca su tasa de transmisión. Los routers no pueden dejar todo el control de congestión a TCP, pues sin los algoritmos de gestión de colas, al producir descarte de paquetes, se incrementaría la tasa de retransmisión por parte de TCP, incrementando aún más la congestión. Los algoritmos de gestión de cola se dividen en dos categorías:

• Gestión Pasiva de Colas (PQM, Passive Queue Management), descartan paquetes sólo cuando la cola alcanza su capacidad, o algún valor específico. Dentro de éste tipo está el tradicional Drop Tail.

• Gestión Activa de Colas (AQM, Active Queue Management), descartan paquetes

preventivamente antes de que la cola alcance su capacidad máxima. Este tipo de algoritmos se explicarán con mayor detalle en la próxima sección.


33

2.4.3 Planificación de colas

Las disciplinas gestión y planificación de colas trabajan conjuntamente para controlar el tráfico de la red a nivel de router. Se ha explicado que la gestión de colas intenta evitar la congestión descartando los paquetes apropiados. Sin embargo, si los paquetes están esperando mucho tiempo para su transmisión, y llegan a mayor ritmo del que son enviados, entonces aumenta el retraso en la cola (queuing delay), provocando congestión. Para evitar esta situación, los algoritmos de planificación de colas trabajan seleccionando el siguiente paquete a ser transmitido de entre todos los paquetes que están esperando. Existen varios mecanismos de planificación, entre ellos se ha considerado oportuno citar los siguientes:

2.4.3.1 FIFO (First In First Out)

Es la disciplina de planificación por defecto, y la más utilizada. Los paquetes se envían en el mismo orden en que van llegando al buffer. La ventaja de éste esquema es su simplicidad a la hora de implementarlo y la posibilidad de predecir el máximo valor de queuing delay a partir de la capacidad del buffer. De ahí se deduce que el retraso será pequeño si la cola tiene poca capacidad, y aumentará si el tamaño de ésta se hace mayor. FIFO trata de igual manera a las diferentes clases de tráfico, y a los distintos flujos.

Ilustración 6. Planificación de Colas FIFO

2.4.3.2 Colas de prioridad ( PQ, Priority Queueing)

Se clasifica el tráfico en diferentes clases. Cada clase es asociada a una cola particular dependiendo de su prioridad. Cada cola individualmente se comporta de acuerdo al algoritmo FIFO. Se envía un paquete sólo si no hay paquetes en colas con prioridades superiores. Es un esquema útil en situaciones en que se produce tráfico de alta prioridad, como ocurre en casos de aplicaciones de tiempo real o VoIP. Sin embargo, si la proporción de éste tipo de tráfico es muy grande, el tráfico con menor prioridad puede sufrir demasiado retardo, al igual que una alta tasa de pérdida de paquetes, desembocando en una situación de inanición.


34

Incluso en caso de tráfico de alta prioridad compartiendo la misma cola de prioridad, un flujo de tráfico con una tasa muy alta puede deteriorar la QoS, ya que puede provocar un alto retraso y jitter en esa cola.

2.4.3.3 FQ (Fair Queueing)

Es una disciplina de colas basada en flujo, diseñada para obtener un reparto equitativo de los recursos de la red y prevenir que haya flujos dominantes que se apropien de todo el ancho de banda. A cada paquete que llega se le clasifica dentro de una clase acorde con el flujo de tráfico al que pertenece, y se asigna a una cola dedicada a ese flujo. Se va eligiendo el paquete situado en la cabeza de cada cola según el algoritmo Round Robin.

Ilustración 7. Funcionamiento de FQ

La ventaja de este algoritmo es que da la misma oportunidad de transmitir a todos los flujos, independientemente si hay algunos más dominantes que otros, solucionando el problema que tenía PQ. Una desventaja es que no se pueden satisfacer los requisitos de ancho de banda de los diferentes flujos. De hecho, FQ debe reservar el mismo ancho de banda para cada uno de ellos. Sin embargo, el ancho de banda recibido por cada flujo depende del tamaño de los paquetes, y paquetes mayores necesitarían más ancho de banda.

2.4.3.4 WFQ (Weighted Fair Queueing)

Ésta disciplina fue diseñada para mejorar FQ, especialmente ofreciendo diferenciación de servicio en términos de ancho de banda, satisfaciendo las demandas de las diferentes aplicaciones. WFQ reparte los recursos de la red entre los distintos flujos basándose en sus necesidades de ancho de banda, dando preferencia a los que menos consumen para reducir el retraso en el buffer, y repartiendo equitativamente el resto de ancho de banda entre los demás.


35

2.5 Gestión Activa de Colas

Este capítulo intenta proporcionar una visión general de cómo trabajan los algoritmos de gestión activa de colas, centrándonos después en el algoritmo RED, por ser uno de los puntos centrales de estudio de éste proyecto en cuanto al análisis de OPNET se refiere, y por ser considerado en muchas publicaciones como punto de partida o esquema de referencia para posteriores algoritmos de gestión activa de colas. Por último, se describirá otro algoritmo basado en RED con el que se ha trabajado en este proyecto.

2.5.1 Introducción y fundamentos de los AQM

La Gestión Activa de Colas es una clase de algoritmos que intentan prevenir la congestión descartando paquetes o marcando paquetes en el router comprometido. Estos utilizan una aproximación probabilística para reaccionar a las condiciones de congestión. Por lo general, para amortiguar las diferencias entre la razón de llegadas y la de salidas, las interfaces de salida de los routers disponen de un buffer o memoria temporal donde los paquetes serán almacenados para ser enviados posteriormente. Esta cola puede estar constituida por paquetes de distintos tipos de flujos, los cuales pueden haber seguido rutas diferentes. En situaciones de congestión, es decir, cuando la cola se llena, si el router sigue una estrategia no diferenciada, los paquetes son descartados o marcados sin importar a qué tipo de flujo pertenecen. Tradicionalmente, la técnica de gestión de colas más habitual utilizada en los routers de Internet es el drop tail. En los routers que adoptan esta técnica, los paquetes que van llegando son temporalmente aceptados y almacenados hasta que un determinado tamaño máximo de la cola, especificado en número de paquetes, sea alcanzado. Cuando la cola se llena, los siguientes paquetes que llegan serán descartados mientras que la ocupación de la cola no decrezca. Drop tail, si así lo permite el tráfico de llegada, tiende a mantener la cola al máximo nivel de ocupación durante largos períodos de tiempo, ya que el descarte se inicia cuando la cola esté llena. No obstante, como desventaja, puede que el descarte se inicie demasiado tarde, implicando una merma significativa en las prestaciones. Con el fin de mitigar estas limitaciones de funcionamiento se desarrolla la gestión activa de colas. En AQM, cuando un router detecta una incipiente congestión, los paquetes son descartados para notificar a las fuentes que deben reducir la carga en la red y con ello poder controlar la velocidad de llegada de los paquetes. Si el paquete es descartado tempranamente, la longitud de la cola crecerá más despacio, evitando colas sobresaturadas, de tal forma que AQM es capaz de soportar mayores ráfagas de tráfico. Esto no es posible lograrlo si se utiliza drop tail, que mantiene casi al máximo la capacidad de la cola y no deja espacio suficiente para albergar rápidos crecimientos de tráfico o ráfagas. Aunque los mecanismos implementados en TCP restringen la tasa de envío, no son capaces de recuperar tan fácilmente los paquetes descartados cuando ocurre una ráfaga, es menos costoso cuando se trata de recuperar un solo paquete descartado. Por otra parte, operar con una baja ocupación en los routers reduce el retardo de transmisión extremo-a-extremo, dado que cuando la ocupación media de las colas de salida tienda a cero, el retardo introducido tenderá a su vez a cero también.


36

En resumen, la idea esencial de la implementación de AQMs consiste en reemplazar la técnica tradicional de gestión pasiva de colas drop tail con el fin de proporcionar un mejor rendimiento en la red en términos de utilización de las líneas, probabilidad de pérdida de paquetes y del retardo extremo-a-extremo.

2.5.1.1 Notificación Explícita de la Congestión (ECN)

Para el control de congestión, junto con AQM se incorpora la así denominada Notificación Explícita de la Congestión (ECN, Explicit Congestion Notification). Esto se resume en que los paquetes pueden ser marcados (en lugar de descartados) si se sufre congestión utilizando un bit ECN en la cabecera IP de cada uno de ellos (si éste bit tiene el valor 1, indica congestión), y ser enviados a los nodos. Con esta alternativa, se está notificando a los siguientes routers que ese paquete ha sufrido congestión. El número y selección de paquetes que son marcados durante una congestión dependen de las políticas AQM que se establezcan.

2.5.2 Random Early Detection (RED)

El algoritmo Random Early Detection (Detección Temprana Aleatoria) fue desarrollado en 1993 por Floyd y Jacobson. Es uno de los primeros y más relevantes esquemas para evitar la congestión en la arquitectura de Internet. RED detecta la congestión estimando la ocupación media de la cola siempre que llega un paquete a ella. Este algoritmo pretende evitar el descarte y posterior pérdida de paquetes IP en los routers sin disminuir con ello las prestaciones de la red. Cada vez que llega un paquete y siempre que la ocupación media de la cola exceda un umbral predeterminado, el mecanismo provoca que se descarte o marque con una cierta probabilidad, donde la probabilidad está en función del tamaño medio de la cola del router. Con RED, un router puede realizar un descarte antes que la cola se sature. La idea por tanto es situar al algoritmo en un punto de funcionamiento óptimo que involucre un compromiso adecuado entre la utilización del ancho de banda de salida de la cola y la reacción temprana o prevención de la congestión. Una vez terminada la necesidad de notificar la congestión (esto es cuando la cola supera una ocupación determinada) RED selecciona con algún criterio una fuente emisora (de entre las que tienen paquetes en la cola) y le notifica la congestión para que ésta pueda bajar su tasa de transmisión. RED es independiente del mecanismo de notificación adoptado, el cual puede ser tanto marcando como descartando el paquete). RED logra mantener un bajo nivel de ocupación medio de la cola mientras permite ocasionalmente ráfagas de paquetes. Téngase en cuenta que el objetivo último de todo algoritmo de gestión activa de colas es mantener la ocupación media de la cola siempre al menor valor posible, ya que así el retardo que sufra cada paquete será menor. Estudiemos con más detalle el funcionamiento de RED: para su operación, se designan dos umbrales, un umbral mínimo (Minth) y un umbral máximo (Maxth). Estos son comparados con una estimación de la ocupación media de la cola (Qavg), que se calcula mediante un filtrado paso bajo (utilizando el parámetro wq) del tamaño instantáneo de la cola. En las siguientes figuras se muestra un ejemplo de curva que caracteriza el comportamiento de RED, representándose para cada valor del tamaño medio de cola (Qavg) la correspondiente


37

probabilidad de notificación (Pd). Nótese, que en general cuanto mayor es la ocupación media mayor será la probabilidad de notificación. En la otra, se aprecia el valor que va tomando el tamaño medio de cola con respecto al tamaño instantáneo (real) de la cola del router.

Ilustración 8. Comparación entre el tamaño real de cola y el valor que toma Qavg

El tamaño de cola medio se estima cada vez que llega un paquete. El cálculo se realiza de la siguiente manera:

Qavg = (1 − ωq) Qavg + ωq Q

Hay un caso especial en el cálculo del parámetro Qavg, cuando el paquete llega a una cola que está vacía. En ese caso, RED calculará este parámetro teniendo en cuenta cuando fue la última vez que la cola estuvo vacía. RED establece tres estados de operación que se determinan haciendo la comparación entre los dos umbrales y la Qavg estimada. El comportamiento de RED dependerá del resultado obtenido:

• Cuando la ocupación media de la cola (Qavg) es menor que Minth . Esta situación es considerada como el estado normal de operación. Aquí, ningún paquete es marcado o descartado, simplemente se encola. • Cuando la ocupación media de la cola esté entre Minth y Maxth .(Minth<Qavg<Maxth) Se pone en marcha el mecanismo de prevención de congestión. Los paquetes que lleguen serán notificados con una probabilidad Pd . • Cuando la ocupación media de la cola sea mayor que Maxth. El paquete se descarta directamente, por ser considerado un nivel de riesgo de congestión.


38

La probabilidad de descarte de paquetes se calcula de la siguiente forma:

Pd = Maxp (Qavg − Minth) / (Maxth− Minth ) Siedo Maxp la máxima probabilidad de descarte de paquetes.

La ejecución del algoritmo RED depende por lo tanto de dos procedimientos diferentes: de cómo se estime el tamaño medio de cola (Qavg) y de la probabilidad de descartes. En RED, tanto la probabilidad de descartes como el descarte forzado no dependerán en ningún momento del tipo de flujo al que pertenezca el paquete en cuestión, sino que sólo está determinado por el nivel de congestión que se experimente en el router en ese momento. Uno de los problemas de este algoritmo está relacionado con la configuración de sus parámetros, ya que una mala configuración puede significar un mal funcionamiento del algoritmo. Otro problema es que el parámetro Average Queue Size permanece estable dependiendo de la cantidad de conexiones TCP de la red. De ahí que se hayan propuesto varias variantes de RED como pueden ser GRED, SRED, DRED, ARED, etc. para resolver estos problemas.

2.5.2.1 Gentle-RED

GRED es una modificación del algoritmo RED propuesto también por Floyd y Jacobson. En RED, cuando el tamaño de cola medio es alto, la probabilidad de descarte aumenta drásticamente de max_p a 1. De ahí se deduce que el tamaño medio de cola se vuelve inestable a medida que su valor aumenta. Gentle RED soluciona este problema moderando la variación de la probabilidad de pérdida en esas ocasiones, es decir, cuando el tamaño medio de cola supera el umbral máximo. Aunque se ha estudiado detalladamente el algoritmo RED, no pasa lo mismo con GRED, no se ha podido encontrar mucha información acerca del mismo y de su comportamiento en distintas circunstancias. A continuación se explica brevemente el funcionamiento de este algoritmo.


39

El algoritmo GRED es básicamente el mismo que se ha explicado en RED, con alguna modificación como veremos más adelante. Para el cálculo del tamaño de cola medio o Average Queue Size se mantiene el mecanismo de RED, es decir, por cada paquete que llega se actualiza el parámetro de la siguiente manera:

Qavg = (1 − ωq) Qavg + ωq Q

donde Qavg es el tamaño medio de cola, wq un parámetro de control y Q es el tamaño real de la cola del router en cada instante. En cuanto a la función para calcular la probabilidad de descarte, está también basada en la ocupación media de la cola, pero en GRED la probabilidad de descarte se incrementa lentamente entre Maxp y 1, mientras que la ocupación media de la cola varía entre Maxth y 2*Maxth:

Pd_gred = Maxp (Qavg − Minth) / (Maxth− Minth) Si Minth<Qavg<Maxth Pd_gred =(1- Maxp)(Qavg − Maxth) / (Maxth) + Maxp Si Maxth<Qavg<2*Maxth Es decir, GRED no descarta paquetes de manera tan agresiva cuando se llega al umbral máximo, sólo aumenta la velocidad a la que crece la probabilidad de descarte. Una vez calculada Pd_gred se descartará un paquete aleatoriamente con dicha probabilidad, que como se ve en las gráficas, es cada vez mayor. En las dos gráficas siguientes se muestra la diferencia en la probabilidad de descarte en ambos algoritmos:

Ilustración 10. Probabilidad de descarte de RED y de GRED

GRED tiene una gran ventaja, ya que, como se ve en el gráfico, descarta paquetes de forma menos agresiva que su antecesor RED. Veremos la desmostración de esto en el capítulo 5.


40


41

Capítulo 3.Introducción Teórica al Simulador OPNET

3.1 Introducción

OPNET Modeler es un programa ampliamente utilizado en la industria para modelar y simular sistemas de comunicaciones. El nombre corresponde a las siglas de OPtimized Network Engineering Tool. La compañía que lo comercializa fue fundada en 1986 y se introdujo en el mercado en el año 2000. Permite diseñar y estudiar redes, dispositivos, protocolos y aplicaciones. Está basado en la teoría de redes de colas e incorpora las librerías para facilitar el modelado de las topologías de red. Soporta un amplio rango de tecnologías tipo LAN, MAN y WAN.

Ilustración 11. Pantalla de inicio del Simulador OPNET

Capítulo 4. Implementación del algoritmo RED en OPNET

42

OPNET Modeler utiliza distintos niveles de modelado o paradigmas para representar los diferentes componentes de una red. Cada nivel está asociado a un dominio y a un editor. Para hacer el desarrollo más intuitivo al usuario, los editores se organizan jerárquicamente, de forma que los modelos desarrollados en el Editor de Proyectos (Project Editor) dependen de elementos desarrollados en el Editor de Nodos (Node Editor). Éste a su vez usa modelos definidos Editor de Procesos (Process Editor). Éstos son los tres principales editores de OPNET, pero existen también otros complementarios como son Link Model Editor (para crear, editar y ver modelos de link), Packet Format Editor (sirve para desarrollar paquetes con un formato determinado) o Probe Editor (para configuración de las estadísticas que se quieren obtener durante una simulación).

Ilustración 12. Vista de varios editores en OPNET

Hay dos conceptos fundamentales para describir un sistema: objetos y procedimientos. Los objetos representan la estructura del sistema y los procedimientos su comportamiento. Ambos trabajan conjuntamente. Para explicarlo más detalladamente, los objetos aportan una forma natural de describir la estructura de las redes de comunicaciones. Además de capturar las características físicas de los componentes del sistema, los objetos pueden ser usados para representar su descomposición e interconexión interna. Ejemplos de objetos físicos de las redes usadas para éste proyecto serían: router, switch, servidor, cliente y links, en definitiva, los componentes que forman las redes, y a los que se tiene acceso a través de la paleta de objetos del Project Editor. También existen objetos abstractos como


43

procesos (se hablará más tarde de ellos) o contadores, pero son dinámicos, y no forman parte de la estructura del sistema. Los términos objeto y modelo en OPNET están muy unidos. Cada vez que se crea en la red un objeto, en realidad, se crea una instancia del modelo que define a ese objeto, podríamos decir que ese modelo es una clase. Esto es porque OPNET está fuertemente unido a la programación orientada a objetos, ya que así se proporciona una forma centralizada de controlar un gran número de objetos: hacer cambios en un modelo implica que todos los objetos creados a partir de él incorporarán ese cambio. Un modelo incluye la información común a todas sus instancias. Esto incluye especificaciones de interfaz de los objetos, comportamiento, y estructura interna. La interfaz describe cómo un objeto interactúa con su entorno, incluyendo especificaciones relacionadas con interconexiones físicas y mecanismos de comunicación con otros objetos. Además de las interfaces de los objetos, los modelos describen su comportamiento. Es decir, cómo reaccionan a estímulos externos y cómo actúan. Por ejemplo, un cliente, es un objeto que en algún momento actuará generando tráfico. El comportamiento de un objeto suele depender de varias variables, como información de estado, estímulos externos, tiempo o variables aleatorias. Esto se implementará mayoritariamente mediante un modelo de procesos, que se explicará en otro apartado. Finalmente, entre la información del modelo está, como se ha dicho antes, la estructura interna del objeto. Esto se representa con la descomposición del objeto en otros componentes, que a su vez pueden ser objetos con su propio modelo. Un ejemplo de esto son los modelos de nodos, que están especificados en términos de objetos llamados módulos y conexiones. Un ejemplo de modelo de nodos sería el que define el comportamiento de un router, dentro del cual se encuentra el módulo IP. En un apartado posterior se hará referencia a estos modelos. Por último queda explicar un concepto importante: los atributos. Cuando se representa un objeto, hay características de éste que se consideran privadas y permanecen escondidas en su interior. Otras, se consideran útiles para mostrar al usuario. Esas características públicas que tiene un objeto son las llamadas atributos. Estos pueden estar asociados con clases de objetos, o con un objeto particular. Suelen tener dos objetivos: informar al usuario de las características seleccionadas de un objeto y permitir que esas características sean modificadas por el usuario para una aplicación específica. Para éste proyecto el concepto de atributo ha sido muy importante, pues, por poner un ejemplo de aplicación, la forma de seleccionar los distintos AQM en una red es modificando uno de los atributos del objeto IP QoS Attribute Definition. En otras secciones se verá cómo modificar o crear o configurar los atributos.

3.2 Dominio de Red (Network Domain)

El papel del Dominio de Red es definir la topología de una red de comunicaciones. Las entidades de comunicación se llaman nodos y las capacidades de cada nodo están definidas mediante su


44

modelo de nodos asociado. Los modelos de nodos se desarrollan utilizando el editor de nodos. Dentro de un modelo de red, puede haber varios nodos basados en el mismo modelo de nodos. Una topología podrá contener tantos nodos y modelos de nodos como el usuario crea conveniente. Los usuarios pueden desarrollar su propia librería de modelos de nodo, implementando la funcionalidad requerida para cada caso. El editor de proyectos (Project Editor) aporta un contexto geográfico para el desarrollo de un modelo de red. Se pueden elegir localizaciones en el mapa del mundo o en el de un país para redes de área extensa o WANs, y áreas dimensionadas para redes de área local o LANs. Ésta característica, además de ayudar a crear un entorno intuitivo a la hora de modelar, añade a la red una noción de distancia, útil para después calcular retardos de comunicación entre nodos. La mayoría de los nodos necesitan la habilidad de comunicarse con otros para llevar a cabo su función dentro de la red. Hay varios tipos de links para cumplir esa tarea: simplex (unidireccional) y duplex (bidireccional) para conectar una pareja de nodos, y bus link para emisión de datos a un conjunto de nodos. Además cada tipo de link se puede adaptar a las necesidades del usuario editando sus atributos o mediante el editor de links. Para quitar un poco de complejidad a los modelos de red, a la hora de crear una topología se usan subredes. Una subred es una agrupación de dispositivos que forma una red en sí misma, y pertenece a una red principal. Las subredes pueden estar conectadas por distintos tipos de links, dependiendo del tipo de subred. Se pueden anidar unas subredes dentro de otras, estableciendo una jerarquía en la que el nivel más bajo está compuesto sólo por nodos y links.

3.3 Dominio de nodos (Node Domain)

El dominio de nodos proporciona el comportamiento de los dispositivos de comunicación o nodos que se usan e interconectan en un modelo de redes. La estructura interna de los nodos que forman los modelos de redes (Network Models) en OPNET no es visible a nivel de red (o los que es lo mismo, desde el Project Editor). En este apartado se explican los componentes de esa estructura interna. Un modelo de nodos está compuesto por una serie de bloques conectados llamados módulos. Cada uno de ellos contiene un conjunto de entradas y salidas, memoria de estado, y un método para obtener las salidas a partir de las entradas y la información en la memoria. El procesamiento depende del tipo de módulo. Algunos tienen un comportamiento predefinido con algún propósito específico, mientras que otros pueden ser definidos por el usuario. La forma de unir las entradas y salidas de los distintos módulos en un modelo de nodos es mediante unos objetos llamados conexiones (connections). Hay dos tipos de conexiones: una para transportar paquetes de datos y otra para transmitir valores individuales. Un módulo puede enviar paquetes a través de sus output packet streams (canales de salida de paquetes) y recibirlos de sus input packet streams. Por otro lado, puede enviar valores individuales a través de output statistics y recibirlos de input statistics. También existen las asociaciones lógicas entre módulos, pero no tienen interés a nivel de modelado, salvo por simplificar la comprensión del modelo de nodos.


45

3.3.1 Módulos

Los módulos representan aquellas partes del modelo en que se genera, consume o procesan datos. Hay varios tipos de módulos, dependiendo de su función dentro de un nodo: procesadores (processors), colas (queues), receptores (receivers) y transmisores (transmitters). Algunos de ellos (procesadores y colas) poseen funciones estrictamente internas del nodo, mientras que otros (receptores y transmisores) tienen conexiones externas con los links de transmisión del dominio de redes. El comportamiento de los procesadores y colas viene dado por modelos de procesos que puede modificar el usuario, como pasa con el módulo IP, definido mediante el modelo de procesos ip_dispatch y sus hijos. Sin embargo, otros módulos tienen un comportamiento ya predefinido, sólo modificable cambiando el valor de sus atributos. El algoritmo interno de un módulo se invoca cuando se produce un evento externo que afecta al estado de ese módulo. Esto es a consecuencia del método de simulación por eventos que emplea OPNET. A continuación se describen los módulos que se han considerado más relevantes en éste proyecto.

3.3.1.1 Procesador

Icono de un procesador en el editor de nodos Este tipo de módulos es el más importante. Se suele usar para procesamiento general de paquetes. Su comportamiento viene dado por su atributo “process model”, que especifica el modelo de proceso que va a ser ejecutado en el módulo. Éste puede responder a eventos externos o interrupciones según el comportamiento que esté implementando. Los procesadores se pueden conectar a otros módulos para intercambiar paquetes a través de packet streams. Un procesador también se puede usar como controlador dentro de un modelo de nodos. En ese caso se comunicará con otros módulos a través de cables estadísticos o interrupciones remotas. Como todos los objetos, un procesador tiene atributos para configurar su comportamiento, y pueden ser especificados usando la interfaz gráfica del editor de nodos. Sin embargo, cuando se selecciona un modelo de proceso, los atributos pueden cambiar. Esto depende de los atributos declarados en el modelo de proceso asociado y en sus interfaces. Los atributos de un modelo de proceso permiten añadir nuevos atributos, que automáticamente serán heredados por el módulo procesador.

3.3.1.2 Cola

Icono de una cola en el editor de nodos Al igual que los módulos procesador, un módulo cola puede ejecutar un modelo de proceso que describe el comportamiento de un determinado protocolo, y puede estar conectado a otros


46

módulos a través de packet streams, pudiendo enviar y recibir paquetes. El modelo de proceso también afectará en éste caso a la lista de atributos que posea el módulo. La mayor diferencia entre un procesador y una cola es que las colas contienen recursos internos adicionales llamados subcolas (subqueues). Las subcolas facilitan las tareas de almacenamiento y de gestión de la colección de paquetes guardada en ellas. Así se proporciona al usuario una manera más sencilla para implementar disciplinas de cola. Cada cola contiene un número definido de subcolas subordinadas a ella, con sus propios atributos. Al poder controlar el comportamiento del módulo mediante un modelo de proceso, se puede modelar cualquier tipo de protocolo de cola definiendo la manera en que se accede y controla la subcolas.

3.3.1.3 Transmisor:

Iconos de transmisores punto a punto y bus en el editor de nodos Los módulos transmisores actúan de interfaz de salida del modelo de nodos con el modelo de red al que el nodo pertenece. Hay dos tipos de nodos, correspondientes a los dos tipos de links de comunicación: punto a punto y bus. Ambos se diferencian en sus mecanismos de comunicación. Dentro de un modelo de nodo, los transmisores son considerados sumideros de datos. Desde el punto de vista del modelo de red, éstos módulos actúan como puertos de salida del nodo a los que conectar los links. En la siguiente ilustración se aprecia el papel de éstos módulos en una red:

Ilustración 13. Interacción de un módulo transmisor con el modelo de nodos y el de red


47

3.3.1.4 Receptor:

Iconos de receptores punto a punto y bus en el editor de nodos

Un módulo receptor sirve como interfaz entre los links externos al nodo y los packet streams dentro del nodo. Como en los transmisores, hay dos tipos de módulos receptores: punto a punto y bus. Los receptores pueden distribuir los paquetes ente uno o varios output packet streams después de obtenerlos del link. Dentro de un modelo de nodos, los receptores son considerados fuentes de tráfico, y desde el punto de vista de la red, un puerto de entrada al nodo.

3.3.2 Conexiones

Las conexiones representan los caminos y asociaciones entre los distintos módulos de un nodo. En un modelo de nodos se pueden encontrar tres tipos de conexiones.

3.3.2.1 Packet Streams

Transportan los paquetes desde un módulo destino hasta uno fuente. Representan el flujo de datos a través de las interfaces hardware y software dentro de un nodo de comunicaciones. No tienen errores de transmisión ni retrasos, ni límite de ancho de banda. De hecho, tienen capacidad ilimitada para almacenar los paquetes en orden de llegada al módulo destino. OPNET proporciona tres métodos para transferir un paquete a través de un stream y notificar al módulo de su llegada: planificado, forzado y silencioso. Con la versión planificada, llega una “interrupción de canal” o stream interrupt y se espera hasta que llegue el turno de recoger el paquete. Con la forzada, cuando la interrupción ocurre, el paquete es procesado inmediatamente, sin ejecutar los evento que hubiera antes. Con la última forma, no hay interrupción: el paquete se almacena en el buffer hasta que el módulo lo solicite.

3.3.2.2 Statistic Wires

Transportan datos desde un módulo fuente hasta uno destino. Cada statistic wire transporta un valor individual. Se usan generalmente como interfaces en las que el módulo fuente comparte ciertos valores con el destino, incluida información de estado. También son usados como mecanismos de señalización, permitiendo que el módulo origen informe al destino cuando una condición particular de interés se ha cumplido. Cada módulo dentro de un nodo tiene un conjunto de local output statistics cuyos valores son actualizados durante la simulación. Este conjunto de estadísticas es el que actúa como fuente de los statistic wire. En concreto, los procesadores y colas tienen estadísticas cuya manipulación e interpretación está definida por el modelo de proceso, y cuya actualización se


48

produce cuando dentro de éste se llama a un procedimiento predefinido en OPNET, op_stat_write(). Otros módulos sin embargo tienen unas estadísticas predeterminadas que son actualizadas automáticamente por el Simulation Kernel cuando es conveniente. Los statistic wires se suelen utilizar de dos formas. Primero, pueden ser empleadas para monitorizar el estado de algún otro componente dentro de un nodo. Segundo, permiten que un módulo avise a otro (procesados o cola) para que cambie de estado, enviando valores que comprueba el proceso asociado.

3.3.2.3 Logical Associations

Son conexiones especiales que no transportan datos, ni existen durante la simulación. Simplemente sirven como mecanismos de especificación: indican que hay relación entre dos módulos de un nodo. Son ayudas para interpretar la estructura de un modelo de nodo.

3.3.3 Atributos

Se pueden crear nuevos atributos y asociarlos a un modelo de nodos. Esos atributos no pertenecerán a un objeto en particular del dominio de nodos, sino al modelo en general. Cuando se crea un objeto nodo en el Project Editor, heredará esos atributos. Cada instancia de un modelo hereda su propia copia de los atributos. Por ello se dice que los atributos del modelo de nodos proporcionan una forma de aumentar el conjunto de atributos de un nodo u objeto de la red. Haciendo públicas ciertas características del modelo de nodos y permitiendo que se modifiquen, los modelos se hacen más aptos para la reutilización en diferentes situaciones de modelado. Lo mismo ocurre con los atributos de los modelos de proceso, que permiten que se introduzcan nuevos atributos en los módulos del modelo de nodos. Por esto, dependiendo del ámbito de utilización de los atributos, se declaran en el modelo de procesos (si se van a necesitar a nivel de implementación de nodos) o en el de nodos (en caso de que interese que sean visibles en el Network Domain).

3.4 Dominio de procesos

Los modelos de proceso se utilizan para definir el comportamiento de los módulos de tipo procesador y cola existentes en el Dominio de Nodos, como se ha explicado en el anterior punto. Implementan una gran variedad de subsistemas tanto hardware como software, incluyendo protocolos de comunicación, algoritmos, recursos compartidos como discos o memoria, disciplinas de cola, y en general todo tipo de comportamiento que se pueda necesitar en un modelo de redes de comunicación. A partir de este punto, para facilitar la lectura, se llamará a los procesadores o colas con las abreviaturas QP. Para proporcionar una funcionalidad particular dentro de un QP, se pueden definir


49

uno o varios procesos. Un proceso es una instancia de un modelo de proceso, definido mediante el Editor de Procesos.

3.4.1 Entorno de un Proceso

En este apartado se describe el contexto en el que trabajan los procesos en OPNET.

3.4.1.1 Ejecución basada en interrupciones

Como el resto de elementos en OPNET, los procesos trabajan en base a eventos. Cuando un evento afecta a un proceso, lo hace en forma de interrupción. Una de las primeras acciones que realiza un proceso al recibir una interrupción es determinar su tipo. Siempre que empieza la ejecución de un proceso, éste está en modo de reposo o bloqueado, esperando a ser invocado. Una invocación por tanto permitirá al proceso reanudar su ejecución y hacer nuevas tareas. Cuando acaba, el proceso se vuelve a bloquear, devolviendo el control a Simulation Kernel para que otros procesos puedan ser ejecutados. El tiempo de simulación al principio y al final de una invocación no varía, es decir, una invocación no consume tiempo.

3.4.1.2 Procesos Dinámicos

Cuando comienza la simulación, cada QP aloja sólo un proceso, que es automáticamente creado por Simulation Kernel. Este proceso es una instancia del modelo de proceso designado en el atributo “process model” del QP correspondiente. A éste proceso se le denominará proceso raíz, y puede crear durante la simulación otros procesos que cooperan para hacer la tarea designada. A los procesos que son creados por otros procesos se les denomina procesos dinámicos.

• Jerarquía de procesos Debido a la metodología de creación de procesos dentro de un QP se puede establecer una jerarquía en la cual el proceso raíz es el padre y los procesos que éste crea los hijos, los cuales, a su vez, podrían crear otros y así sucesivamente, creando una estructura de árbol, como se puede ver en la figura de la siguiente página. No hay límite en el número de generaciones. Además de crear procesos, se pueden borrar también, con los que la jerarquía de procesos dentro de un QP varía dinámicamente durante la simulación. El único proceso que no se puede borrar es el proceso padre, que será el responsable de transferir las interrupciones al resto de procesos de la jerarquía. En la siguiente figura se muestra un esquema con éste tipo de jerarquía.


50

Ilustración 14. Jerarquía de procesos en OPNET

Un detalle curioso del dominio de procesos es que se puede borrar un proceso padre sin que desaparezcan sus hijos (excepto, como se ha dicho, el proceso padre de cada QP). Además, podrá crear hijos basados en cualquier modelo de proceso, incluyendo el suyo propio, o el del proceso padre, siempre y cuando sus modelos de proceso correspondientes estén declarados en una lista. Esa lista forma parte de la implementación de cada modelo de proceso y debe ser declarada antes de la simulación e instanciación del proceso. La forma de acceder a ésta lista es desde el Editor de Procesos, dentro del menú File: Declare Child Process Model para permitir nuevos hijos y Open Child Process Model para acceder a la lista.

• Memoria compartida

Cuando dentro de un QP se ejecutan varios procesos para implementar su funcionalidad, éstos requieren comunicarse entre ellos para compartir información. Hay tres mecanismos de comunicación:

- Memoria compartida a nivel QP (module memory): los procesos de la jerarquía comparten la información guardándola en un área común definida por el QP, en forma de estructura de datos . Los procesos asignan y obtienen la dirección de ese área mediante las operaciones del KP op_pro_modem_install() y op_pro_modem_access(). Para asegurarse que todos los procesos usan de forma consistente esa estructura compartida, todos tienen una definición de ella en su bloque de cabecera o header block, accesible desde el editor de procesos. - Memoria compartida padre-hijo: Es un área privada que se crea a la vez que el proceso hijo con el que se comparte. Otros procesos no tienen acceso a ella (cada uno tiene su propia memoria con su proceso padre). El Kernel mantiene por lo tanto un bloque de memoria para cada par padre-hijo del sistema.


51

Ilustración 15. Memoria padre-hijo en una jerarquía de procesos

Un proceso hijo obtiene la dirección de la memoria que comparte con su padre mediante la rutina op_pro_parmem_access().

- Paso por argumento: Mediante la primitiva op_pro_invoke(), se pasa al otro proceso la dirección de un bloque de memoria. Así, el proceso invocado obtiene parámetros que pueden afectar a su comportamiento, o modifica la memoria para devolver su status al proceso que lo invocó. En este tipo de mecanismo, a diferencia de los dos anteriores, la memoria no es persistente. Es decir, en cada invocación se debe pasar una dirección de memoria.

• Operaciones con Procesos Dinámicos

Como se dijo antes, un proceso raíz puede crear varios procesos hijos. Esto lo hace mediante la función op_pro_create(). Cuando esto sucede, el nuevo proceso se añade automáticamente a la jerarquía del padre. Como resultado de ésta operación se devuelve un valor, el process handle, que es el identificador del nuevo proceso dentro de todo el sistema (no sólo en la jerarquía). Este es un número único para cada proceso, y se puede acceder a él mediante op_pro_id(). Ciertos procesos dinámicos tienen un tiempo de vida reducido al tiempo que tarden en realizar la tarea encomendada. En cuanto acaban, se le elimina de la jerarquía para no consumir recursos mediante la función op_pro_destroy, que puede ser empleada por otros procesos, o por ellos mismos. Sólo puede haber un proceso ejecutándose a la vez. Se considera que un proceso está en ejecución cuando progresa a través de las instrucciones que forman parte de su modelo. Cuando un proceso necesita invocar a otro (anteriormente creado), lo hace mediante la función op_pro_invoke(). A partir de ésta llamada, el proceso invocador se bloquea, cediendo el control del hilo de ejecución al proceso invocado, el cual realiza su tarea y cuando acaba devuelve el control al proceso que lo llamó, que continúa ejecutándose donde lo había dejado. Nótese que cuando un proceso invoca a otro, ése a su vez puede invocar a otro… y así sucesivamente, comportándose como un mecanismo de llamadas orientado a pila, con lo cual, no soporta recursividad (porque los procesos, una vez van invocando a otro, permanecen


52

bloqueados hasta que acaba la llamada). Sí que podría existir no obstante entre distintas instancias de un mismo proceso de modelo, invocándose una a la otra. Durante la invocación, el proceso invocado puede acceder a cualquiera de los recursos del QP como por ejemplo paquetes o estadísticas. Por ello, hay que tener en cuenta que después de una invocación, ciertos valores pueden haber cambiado. Todas las operaciones aquí citadas para manejar los procesos dinámicos y otras muchas forman parte del llamado Process Package, uno de los paquetes de operaciones existentes dentro de los Kernel Procedures o KP. Estas funciones están ya definidas y se pueden usar directamente en el código de los modelos de proceso, lo cual facilita mucho la tarea de implementación de nuevos protocolos o aplicaciones dentro de OPNET. Hay información muy extensa sobre estos procedimientos en la documentación del programa que conviene estudiar antes de entrar en detalles de código.

• Control de interrupciones

Una interrupción indica que ha ocurrido un evento de interés en el sistema, como puede ser la expiración de un temporizador o la llegada de un paquete. Cuando un proceso recibe una interrupción, realiza una acción como respuesta y se bloquea, esperando una nueva interrupción. Los modelos de proceso usan procedimientos predefinidos para obtener la información acerca del tipo y origen de la interrupción. En la mayor parte de los casos, las interrupciones poseen información adicional a la que los procesos acceden para determinar qué acción llevar a cabo. Por ejemplo, una interrupción causada por la llegada de un paquete hace que el proceso tenga que obtener el paquete y procesarlo. Por defecto, todas las interrupciones que llegan a un QP son dirigidas al proceso raíz, el cual luego elige a quién invocar para que realice las operaciones debidas. Sin embargo, determinados procesos pueden solicitar recibir ciertos eventos, basándose en el tipo de evento, o su procedencia.

3.4.1.3 Recursos de un proceso

Los procesos siempre operan dentro del contexto de un QP. Por ello, el objeto QP proporciona a sus procesos ciertos recursos que implícitamente forman parte del entorno de cada proceso. Éstos son:

• Canales de entrada/salida (Input and Output Streams) Los packet streams son objetos que existen en el modelo de nodos y conectan unos módulos con otros, como hemos visto. Concretamente, comunican estructuras dinámicas en los nodos fuente y emisor llamadas output e input streams respectivamente.


53

Un input stream dentro de un QP recibe paquetes de fuentes externas. Los paquetes son automáticamente almacenados dentro del stream, siguiendo un orden FIFO, y desde ahí pueden ser accedidos por los procesos del QP que lo soliciten. Los input streams son reservados dinámicamente según sean necesarios para soportar las entregas, pues Simulation Kernel no sabe de antemano el rango de canales que serán utilizados. Cuando se recibe un paquete en un input stream, se invoca uno de los procesos del QP mediante una interrupción de canal (stream interrupt). El proceso determinará por qué canal llega el paquete llamando a la función op_intrpt_strm(), que devuelve el índice asociado a un stream. Una vez conocido el canal, se recogerá el primer paquete que llegó mediante op_pk_get().

Ilustración 16. Esquema de input streams en un QP.

El lado opuesto al anterior de un packet stream es el output stream. Estos canales efectúan la comunicación de paquetes mediante las funciones del tipo op_pk_send(). Los output streams también tienen un índice asociado, pero sólo serán válidos aquellos que estén asociados a un objeto físico packet stream.

• Estadísticas (Input Statistics y Local Output Statistics)

Ambos tipos de estadísticas forman los extremos de los statistic wires, vistos en el modelo de nodos.


54

Las input statistics son construcciones internas que aceptan valores numéricos enviados por otros módulos dentro del mismo nodo. Estas construcciones están identificadas por un entero, y sólo retienen el último valor que ha llegado desde statistic wire (no hay buffer, al contrario de como ocurría en los output/input streams). Cuando hay varios statistic wire conectados a un mismo input statistic, el último valor de la última estadística que se haya actualizado es el que prevalece. Ese valor es accesible para cualquier proceso del módulo mediante op_stat_local_read(). Las local output statistics son el otro extremo del cable, y se denominan local para diferenciarlas de las estadísticas globales, que pueden ser compartidas por varios QP dentro de un modelo de nodos. Éste tipo de recursos permiten enviar estadísticas definidas por el usuario que son privadas para cada QP. Los procesos actualizan las local output statistics llamando a op_stat_write(). Una sola de éstas puede enviar datos a través de varios statistic wires a la vez . Para acceder a una estadística de éste tipo, los procesos primero tienen que saber su identificador, mediante op_stat_reg(). Los procesos dentro de un QP comparten las local output statistic existentes, cualquiera de ellos puede actualizarlas. Eso sí, los procesos deben declarar cuales van a utilizar, mediante la operación del editor “Edit local statistics” como se ve a continuación.

Ilustración 17. Estadísticas locales en el modelo de proceso ip_output_iface


55

• Estadísticas Globales Las estadísticas globales recogen la actividad de todo el sistema de comunicaciones. Suelen ser la media de los valores de las estadísticas locales de los distintos componentes del sistema. Dentro de este tipo de estadísticas nos encontramos por ejemplo con el retardo extremo a extremo, jitter o rendimiento de la red. Como pasa con las estadísticas locales, cada modelo de proceso debe declarar las estadísticas globales que va a actualizar durante la simulación mediante la operación “Global Statistics” del editor de procesos. Para acceder a una estadística global, un proceso primero debe obtener su identificación y mediante op_stat_reg(), y después actualizarla mediante op_stat_write().

• Subcolas

Los módulos cola pueden ser configurados para contener cualquier número de subcolas que permiten almacenar paquetes de una manera determinada. Todos los procesos dentro de una cola tienen el mismo derecho a acceder a las subcolas y pueden insertar y extraer paquetes cuando lo requieran para implementar una determinada disciplina de cola (FIFO,PQ,WFQ … ).

• Atributos Los QP tienen un conjunto de atributos que especifican algunas de sus características fundamentales. Todos los procesos dentro de un QP pueden modificar y obtener los valores de estos atributos utilizando respectivamente las funciones op_ima_obj_attr_set() y op_ima_obj_attr_get(). Esos atributos que definen el comportamiento de un módulo están declarados en el modelo de proceso, y el usuario puede declarar nuevos para obtener características específicas para un tipo de aplicación específica. Esto se hace en el editor de procesos, con la opción “Interfaces › Model Attributes” (de hecho este paso es una de las cosas que se ha tenido que hacer en este proyecto para añadir nuevos AQM). Para ser vistos en otros niveles de modelado, los atributos se heredan en los QP que alojan esos modelos de proceso. Por lo tanto, los atributos de un QP serán el conjunto de atributos del proceso raíz y de sus hijos. Para evitar conflictos en los nombres de los atributos, cada uno de ellos lleva como prefijo el nombre del modelo de proceso del que proviene, excepto los del proceso raíz. El ámbito de los atributos es sólo el módulo al que pertenecen, cada QP tiene una copia privada de los atributos, por lo que los cambios en uno de ellos no tienen efecto en los atributos de los demás objetos. También existen atributos de ámbito global: los llamados atributos de simulación o simulation attributes. Son declarados también en el modelo de procesos y compartidos por varias entidades del sistema.


56

3.4.2 Componentes de un modelo de proceso

Un modelo de proceso especifica el comportamiento dinámico de un proceso. Para ser completo, un modelo de proceso debe describir las acciones que el proceso implementará en todas las circunstancias posibles. Además, un modelo de proceso suele representar protocolos o algoritmos existentes en la vida real, por lo que su implementación debe ajustarse a las especificaciones y estándares oficiales de dichos protocolos o algoritmos. Por ejemplo, la implementación del protocolo TCP/IP está definida según los documentos RFC.

3.4.2.1 Proto-C: el lenguaje de los modelos de proceso

OPNET Modeler utiliza Proto-C, un lenguaje especial basado en C y C ++ para desarrollar modelos de proceso eficiente para describir el comportamiento de sistemas discretos de eventos. Este lenguaje tiene las siguientes características: - Basado en Diagramas de Transición de Estados (STD) o Maquinas de estado Finitas (FSM). Proto-C utiliza STD por ser el método idóneo para describir la evolución de sistemas de eventos discretos y mantener la información de estado. - Combina la representación visual y textual. Utiliza la representación visual para la transición de estados, y para la información detallada o toma de decisiones la textual. La especificación textual está contenida dentro de los estados y transiciones representados gráficamente. Además, se incluye una amplia librería de procedimientos (las funciones citadas hasta ahora forman parte de éstos procedimientos). - Representación de la información de estado. La información de estado es un conjunto de datos proporcionado o generado por el proceso. Esa información es guardada en forma de variables, que serán utilizadas durante la ejecución. - Creación de procesos dinámicos. Ya se ha hablado de ello. Los procesos crearán otros según las exigencias de ejecución. - La estructura del lenguaje Proto-C garantiza una ejecución eficiente.

3.4.2.2 Diagramas de Transición de Estados

Los diagramas de transición de estados construidos en Proto-C consisten en dos tipos básicos de componentes: estados y transiciones (de ahí su nombre). Los estados generalmente representan las situaciones en las que un proceso puede entrar. Las transiciones especifican los cambios de estado posibles en un proceso. Además hay otros elementos como declaración de variables, atributos y acciones asociadas a cada estado, que no se ven gráficamente en el diagrama de estados.


57

Ilustración 18. Ejemplo de STD: ip_output_iface

• Estados Forzados y No forzados

La información de estado está continuamente actualizandose conforme van sucediendo los eventos. En términos de un STD, la palabra estado se refiere a un objeto que está en uno de los modos o situaciones en que se puede encontrar un proceso. Los estados son mutuamente excluyentes y complementarios, es decir, que un proceso siempre estará exactamente en un estado, nunca habrá más de un estado ocupado en un instante determinado en un modelo de proceso. Las transiciones que parten de un estado indican qué estado se ocupará después y las condiciones que cada cambio requiere. La especificación de acciones en Proto-C está asociada con cada estado, y reciben el nombre de executives. Las executives en cada estado se dividen en enter executives y exit executives. Como su nombre indica, las primeras se realizan cuando un proceso entra en el estado, y las últimas, antes de abandonarlo para ejecutar una de las transiciones posibles. Proto-C define dos tipos de estados: forced y unforced, que difieren en su tiempo de ejecución. En un diagrama, se pueden distinguir unos de otros por el color: los forced están representados por círculos de color verde, y los unforced, rojo, como muestra el dibujo de la siguiente página:


58

- Unforced States: permiten una pausa entre el enter y el exit executive y, por lo tanto, pueden modelar estados reales del sistema. Después de completar el enter executive de un estado, el proceso se bloquea y devuelve el control al hilo de ejecución en el que fue invocado. Ese contexto podría ser, por ejemplo, otro proceso que le invocó mediante la función de KP op_pro_invoke(), o si el proceso fue invocado por el Simulation Kernel, bloquearse significaría el final del evento, y entonces el Kernel podría elegir el siguiente evento para comenzar su ejecución. En este punto, el proceso permanece suspendido hasta que una nueva invocación lo haga progresar y continuar con el exit executive del estado en el que se encuentra. El siguiente diagrama describe el flujo de ejecución de un STD a través de estados no forzados. En la página siguiente se muestra el flujo de ejecución de eventos a través de estados no forzados, es decir, cómo se empieza ejecutando los exit executives de un estado, a continuación ejecutando la transición, el enter executive del siguiente estado, y finalmente bloquearse.


59

Ilustración 19. Flujo de ejecución a través de unforced states

- Forced states: No permiten esperar al proceso, es decir, cuando un proceso entra en un estado de éste tipo, ejecuta las enter executives y seguidamente las exit executives. Por lo tanto, éstas últimas se suelen dejar en blanco en este tipo de estados. Aunque no sean útiles para modelar sistemas reales, sí que lo son en ciertos casos para separar acciones gráficamente, o para controlar decisiones de flujo comunes a varios unforced states. Separando gráficamente las acciones a ejecutar ayuda a la modularidad, a la vez que se obtiene un STD más informativo.


60

Ilustración 20. Modelado con forced states

• Estado Inicial

Es un estado especial que debe estar en todo modelo de proceso. Se puede convertir un estado existente en inicial mediante la opción “set initial state” en el editor de nodos. Gráficamente, se puede identificar el estado inicial porque tiene una flecha a su izquierda. El estado inicial es el punto en el que comienza la ejecución cuando el proceso es invocado. En realidad puede jugar el papel de un estado normal, pero suele contener inicializaciones y otras sentencias que deberían ocurrir solamente una vez, por lo que la mayor parte de los modelos de proceso no incluyen transiciones de vuelta a él.

• Transiciones

Las transiciones describen el posible movimiento de un proceso entre un estado y otro, y las condiciones bajo las cuales ese cambio puede ocurrir. Hay cuatro componentes en la especificación de una transición: el estado fuente, el estado destino, la condición, y la acción o executive. La especificación de la transición se lee de la siguiente forma: si la condición es cierta, ejecutar lo indicado en el executive y transferir el control al estado destino. En el editor de procesos las transiciones se representan gráficamente. Cada estado puede ser origen o destino de varias transiciones, dibujadas como arcos con la punta de la flecha apuntando al nodo destino. La condición y el executive aparecen en forma de etiqueta al lado del arco. Siempre que se crea una transición, el editor de Procesos automáticamente encierra la condición entre paréntesis seguida de la barra “/” y el executive. Las transiciones que tienen condición tienen el arco formado por una línea discontinua, y las que no tienen condición, su arco es una línea continua. A continuación se muestra un gráfico en el que se ven los distintos tipos de transiciones:


61

Ilustración 21. Representación de transiciones en un STD

Las condiciones de las transiciones se evalúan para decidir si se debe pasar al siguiente estado o no. Un proceso evalúa las transiciones de salida una vez ha completado la ejecución de las exit executives del estado en el que está. El manejo de las condiciones de una transición es muy flexible: pueden ser muy simples, o formar una expresión compleja que involucran variables de estado, atributos y otra información almacenada en la memoria local o global. También puede ser que involucren llamadas a procedimientos definidos por el usuario que devuelvan un valor booleano que si se cumple o no la condición. Alternativamente, también se pueden evaluar las condiciones de transición en el propio estado orígen, al final del exit executives. Existe una condición especial (default), que asegura que aunque no se cumplan las condiciones de transición, siempre se pueda transitar a otro estado. La transición default se cumple sólo cuando las otras transiciones no lo hacen. Las transiciones que están configuradas con una condición vacía son equivalentes a transiciones en las que su condición siempre es true. En el modelo de procesos, a estas transiciones se las llama transiciones incondicionales. Un estado que tenga una transición incondicional, no tiene condicionales saliendo de él. Cada transición incorpora un atributo que especifica una acción o executive, que es ejecutada en el momento en que el proceso decide atravesar esa transición. En otras palabras, después de evaluar las posibles transiciones, el proceso elige una de ellas, ejecuta su executive y pasa a las enter executives del siguiente estado.

3.4.2.3 Macros

Casi todas las macros usadas en un modelo de proceso se definen en su Header Block o HB.


62

Extracto del header block del modelo de proceso ip_output_iface en el que se ve la inclusión de ficheros externos .h y definición de condiciones y constantes

Header Block o Bloque de cabecera es un área de código C y C++, similar a la cabecera de un fichero en C o C++. Las macros generalmente se usan para representar constantes, condiciones de transición, transition executives, u operaciones comunes. En el bloque de cabecera, las macros se reconocen por empezar con la directiva #define. También se pueden encontrar macros en ficheros de definición externa (con el sufijo .h, del tipo oms_qm.h o ip_qos_support.h), que se incluyen en el header block con la directiva #include. Este método es útil cuando varios modelos de proceso deben compartir un conjunto de definiciones, favorece la reutilización.

3.4.2.4 Variables

Los procesos en Proto-C tienen acceso a varias formas de memoria para almacenar información, cada una con las características necesarias para usos particulares. Algunas de éstas formas, denominadas variables permiten ser referenciadas y manipuladas mediante nombres ordinarios, y no direcciones de memoria. En los modelos de proceso hay tres tipos de variables: de estado, temporales y globales. A continuación se presenta una tabla con los tipos de variables existentes y su ámbito o visibilidad.

Tipo de Variable \ Visibilidad

State Executives

Function Block

Funciones en ficheros Externos

(extensión .ex.c) Temporal X Estado X X

Global (como las definidas en ficheros externos o en HB)

X

X

X (Usando extern)


63

La declaración de cada uno de los tres tipos de variables utiliza un mecanismo distinto, para indicar al compilador qué categoría aplicar. En los siguientes puntos se describe detalladamente las características de cada uno de los tipos.

• Variables de estado (State variables) Son variables utilizadas para representar la información acumulada y retenida por un proceso. Se las llama de estado porque, junto con la posición que ocupa el proceso dentro del STD, representan el estado completo de un proceso en cualquier instante. Son persistentes, es decir, desde la perspectiva de cada proceso, mantienen su valor a través del tiempo. Sólo pueden ser modificadas mediante las acciones ejecutadas por el propio proceso. Esto implica que los valores de las variables de estado permanecen inalterados mientras el proceso está bloqueado, y cuando éste continúa su ejecución, todo está como lo había dejado. Una característica de las variables de estado es que, a pesar de su persistencia, son privadas para cada proceso. Esto implica que aunque haya dos instancias del mismo modelo de proceso existentes en el mismo módulo, sus variables de estado guardarán la información independientemente sin conflictos, aunque el nombre de las variables sea el mismo. Las variables de estado se declaran en un área específica del modelo llamada state variables block, accesible desde el editor de procesos (menú Code Blocks › State Variables), en el cual se pueden crear nuevas, o modificar las ya existentes. No tienen valores iniciales particulares cuando el proceso es invocado por primera vez (no se las puede dar valores durante su declaración), es responsabilidad del propio proceso asignar esos valores de manera consistente. De hecho, esa suele ser una de las principales actividades que se realizan en las executives del estado inicial.

Ilustración 22. Declaración de variables de estado en ip_output_iface

• Variables temporales (Temporary variables) Almacenan información que no requiere persistencia por lo tanto, es posible que entre una invocación y otra del mismo proceso hayan cambiado. Debido a esto, se las suele utilizar como instrumentos auxiliares para facilitar la ejecución de expresiones complejas en un instante de tiempo. Por ejemplo, variables de este tipo pueden ser el índice de un bucle o un paquete recién extraído de un stream.


64

Las variables temporales se declaran en una ventana que aparece al seleccionar Code Blocks › Temporary Variables. Se puede dar valores iniciales a las variables incorporando una asignación en su declaración. Como se ve a continuación

Ilustración 23. Declaración de variables temporales en ip_output_iface

• Variables Globales (Global variables) Las variables globales proporcionan un método para que diferentes procesos guarden información en un área común. Pueden ser de cualquier tipo predefinido en C o OPNET, incluyendo también tipos de datos definidos por el usuario. Cuando un proceso modifica una variable global puede afectar en las operaciones de otros procesos. Este tipo de variables se define en el header block. Cada una de ellas debe tener una declaración principal en el header block del modelo de proceso con el que más asociado esté. Si otros procesos comparten acceso a ella, su bloque de cabecera incluirá una declaración externa. Puede haber muchos procesos que tengan declaraciones externas de una variable, pero sólo uno tendrá una declaración principal. Las declaraciones externas se definen con extern. Como en el caso de las variables temporales, se puede inicializar las variables globales en el momento de su declaración mediante la asignación de una valor, pero sólo en la declaración principal. La inicialización se ejecutará antes del comienzo de la simulación.

3.4.2.5 Uso de funciones

Para hacer los modelos de proceso más modulares y sencillos, una de las técnicas que se ha dicho anteriormente es utilizar forced states en el diagrama de estados, para así mostrar de forma más intuitiva el flujo de ejecución de un proceso. La otra forma es el uso de funciones. Las funciones son especificaciones de una aplicabilidad determinada que pueden aceptar argumentos. Podemos usar funciones dentro de un modelo de proceso mediante dos mecanismos:

• Function Block

Dentro de un modelo de proceso, las funciones se pueden definir dentro de una sección llamada function block o FB. El contenido de FB se puede editar mediante el Editor de


65

Procesos, haciendo clic en el botón . El texto escrito en éste bloque aparecerá también en el header block, permitiendo usar tipos de datos y macros definidas en él. Cada función representa un “paquete” de funcionalidad que cualquier elemento de los STD puede usar. Así, se simplifica la apariencia de los diagramas de transición y también se fomenta la reutilización en distintas partes del código. Las funciones especificadas dentro de éste bloque en general van dirigidas a los modelos de proceso con los que van asociadas.

• External Object Files (Ficheros externos)

Como alternativa al anterior método, se pueden utilizar funciones definidas en ficheros externos, que se unen al modelo de proceso durante la simulación. Esto permite desarrollar y mantener funciones de manera centralizada y compartirlas por varios modelos de proceso. Estos ficheros se encuentran físicamente en la carpeta OPNET\14.5.A\Models\std, y se apellidan .ex.c. OPNET permite al usuario especificar y declarar la lista de ficheros externos que un modelo de proceso necesita. Esto se puede hacer desde el menú “File › Declare External Files…“, marcando los ficheros deseados en la lista como se ve a continuación:

…

Ilustración 24. Dos tramos de la lista de ficheros externos en ip_dispatch

En la imagen se ve cómo están seleccionados dos de los ficheros externos más relevantes para éste proyecto, por contener funciones relacionadas con IP y QoS.

3.4.2.6 Atributos del modelo de procesos

OPNET Modeler proporciona atributos con el propósito de permitir desarrollar modelos parametrizados. Los modelos de proceso son los que generalmente usan este mecanismo, porque es el modelador el que crea el código y elige qué valores deben ser interpretados como atributos para controlar el comportamiento de un proceso. Los atributos pueden ser declarados dentro del editor utilizando la operación Interfaces > Model Attributes. Cada atributo se define especificando un nombre único y unas propiedades, como se ve a continuación.


66

Ilustración 25. Acceso a los atributos del modelo de procesos qos_attribute_definer

Durante la simulación, los atributos aparecen como atributos de QP. Se accede a ellos para modificarlos u obtener su valor respectivamente mediante las primitivas op_ima_obj_attr_set() y op_ima_obj_attr_get(). Sin embargo, en la mayoría de los casos, los atributos no son modificados durante su simulación, sirven sólo como parámetros que el proceso utiliza para configurarse a sí mismo al inicio. Como ejemplo, a continuación se muestra cómo el proceso qos_attribute_definer accede al atributo FIFO Profiles en el código situado dentro de Function Block:

• Attribute Interfaces

Cada proceso mantiene un conjunto de interfaces de atributos o attribute interfaces distinto de los de su modelo. Generalmente contiene atributos promocionados desde objetos dentro del modelo, así como especificaciones para atributos que usará el modelo. En el caso de los modelos de proceso, ninguno de los objetos (por ejemplo estados, transiciones) puede promocionarlos. Por lo tanto, attribute interfaces consistirá simplemente en atributos de QP. Utilizando este mecanismo, el usuario puede especificar por adelantado los valores y propiedades del QP que usará este modelo. Los Attribute Interface también proporcionan la capacidad de asociar comentarios al para guiar e informar al usuario acerca del modelo de proceso.


67

3.5 Simulación

En los siguientes apartados se describen primero los componentes que hacen falta para la simulación de un sistema. Posteriormente se verá cómo se lleva a cabo la simulación desde el punto de vista del tiempo, eventos e interrupciones. Definimos simulación como una técnica que imita el comportamiento de un sistema del mundo real conforme evoluciona en el tiempo. De esta manera, se puede analizar y observar características sin necesidad de acudir al sistema real. Se denomina modelo de simulación discreto a la representación de un sistema donde su comportamiento cambia únicamente en instantes de tiempo concreto. OPNET es un simulador de redes basado en un tipo concreto de simulación discreta: la simulación de eventos discretos. Para entender los siguientes apartados, es necesario conocer los siguientes conceptos:

• Modelo de simulación: conjunto de hipótesis acerca del funcionamiento del sistema expresado como relaciones matemáticas y/o lógicas entre los elementos del sistema. Es decir, hace referencia a la representación del sistema real que va a ser analizado, sus condiciones de funcionamiento y las variables que emplea.

• Proceso de simulación: ejecución del modelo de simulación a través del tiempo en un

ordenador para generar representaciones de comportamiento del sistema.

3.5.1 Construcción de un modelo de simulación

Antes de la simulación de un sistema, se debe obtener un programa de simulación compilado, compuesto por instrucciones en código máquina que el ordenador puede ejecutar directamente. Un programa de simulación consiste en partes separadas de código objeto. Cada una de esas partes tiene un papel diferente durante la simulación. Algunos de los ficheros objeto son proporcionados por OPNET, mientras que otros provienen de las especificaciones del usuario. A continuación se citan los distintos tipos de componentes que forman parte de un programa de simulación en OPNET: - Simulation Kernel: Es una librería de código objeto que contiene los algoritmos de simulación y otros servicios usados para la simulación. Puede ser de varias categorías. Proporciona el marco para todas las simulaciones, incluyendo servicios básicos como carga de modelos, planificación y gestión de eventos, recolección de estadísticas, reservas de memoria, etc. Contiene todos los Kernel Procedures (KP) llamados por los modelos de proceso. - Process Models: Cada modelo de proceso incluido en la simulación se traduce en un fichero en C, teniendo una extensión .pr.c. Cada uno de estos ficheros, inmediatamente antes de la simulación se compila mediante un compilador instalado en el ordenador (en éste caso, Visual C++), que genera un fichero objeto con la extensión .pr.o.


68

- Pipeline Stages: Son la referencia a los links del sistema, e implementan operaciones modulares y actividades relacionadas con la transmisión de paquetes entre los módulos transmisores y los receptores. Tienen extensión .ps.c. - External Object Files: Contienen funciones de apoyo a los modelos de proceso y pipeline stages durante la simulación. Pueden estar desarrollados en C o en cualquier otro lenguaje que se pueda llamar desde C. Tienen extensión .ex.c. Para ser usados, deben estar declarados en una lista en los modelos de proceso correspondientes. - External Archives: similares a los external Object Files, pero empaquetados, en forma de archivo, conteniendo múltiples ficheros objeto. Una vez obtenidos todos los componentes de simulación mencionados, OPNET proporciona un programa ejecutable, apto para simular.

3.5.2 Simulación de eventos discretos

3.5.2.1 Eventos y simulation time

Generalmente, la simulación de eventos discretos general una secuencia de estados para un sistema. Éste evoluciona a través de los estados en función del tiempo, basándose en las especificaciones de comportamiento de sus componentes y en la interacción entre ellos. La noción de tiempo en una simulación no está relacionada con el tiempo real que se emplea en efectuar dicha simulación: es una variable mantenida por el programa, y permite especificar cuánto tiempo vamos a suponer que el sistema está en funcionamiento. A ésta variable se la llama simulation time para distinguirla del tiempo real. Gracias a la noción de la variable simulation time y a los eventos, que se explican a continuación, es posible estudiar el comportamiento que tendría un sistema durante un largo periodo de tiempo empleando para ello un tiempo considerablemente menor. En la simulación de eventos discretos, la progresión del modelo durante el simulation time se descompone en instantes individuales o eventos en los cuales se producen cambios. Cada evento representa la necesidad para el modelo de realizar algún cambio que afecte a su estado, o a realizar alguna decisión. Ejemplo de eventos serían: recepción de un paquete, expiración de un temporizador, la terminación de alguna tarea, fallo, etc. Cada vez que se produce un nuevo evento, se dice que es ejecutado por la simulación. Es posible que ocurran varios para el mismo valor de simulation time. Los eventos no se reparten de manera uniforme durante el tiempo de simulación. De hecho, es común que su densidad varíe significativamente a medida que progresa la simulación, como se ve a continuación:


69

Ilustración 26. Distribución típica de eventos durante el tiempo de simulación

El tiempo de simulación sólo avanza entre eventos, durante la ejecución de un evento el tiempo no puede cambiar(todos los eventos tienen duración 0).

3.5.2.2 Planificación y Lista de eventos

Una simulación en progreso puede ser vista tanto como generadora como consumidora de eventos. Los componentes van generando eventos para planificar futuras acciones, basándose en el comportamiento descrito por los distintos modelos. Esos eventos, por otro lado se irán consumiendo según progresa el tiempo de simulación. La simulación de eventos discretos maneja los eventos mediante una denominada lista de eventos. El propósito de mantener semejante lista es el de asegurarse que todos los eventos se ejecutan en el correcto orden de tiempo. Cada evento tiene un tiempo asociado en el que se espera que ocurra. La solicitud de nuevos eventos es denominada event scheduling, y se pueden solicitar para un instante futuro o para el instante actual, pero nunca para uno pasado, puesto que le tiempo siempre progresa hacia delante, y así lo hace también la variable simulation time. Es muy común que los eventos se planifiquen para el tiempo actual como consecuencia de una reacción en cadena, es decir, un evento causa otro, y ése a su vez otro, y asi, sin que el tiempo de simulación progrese. La lista de eventos mantiene todos los eventos ordenados por orden de tiempo, así el siguiente evento se ejecutará una vez el evento actual ha completado su ejecución. El evento más cercano al tiempo de simulación actual es la cabeza de la lista, y el que está planificado para un instante más lejano, la cola. Durante la simulación, el Kernel irá añadiendo eventos a esta lista en cualquiera de sus posiciones, por lo que la cabeza y la cola pueden estar cambiando constantemente, así como el tamaño de la lista. Por otro lado, el propio Kernel será también el encargado de sacarlos y ejecutarlos. Hay un grupo de procedimientos (Ev package) dentro de los Kernel Procedures dedicado a manejar esta lista y todo lo relacionado a la planificación y análisis de los eventos durante la simulación. Durante la simulación, la lista puede estar continuamente aumentando (conforme nuevos procesos son planificados) y disminuyendo (cuando dichos eventos son ejecutados o cancelados) . Cada simulación tendrá su propio patrón de crecimiento de la lista de eventos, dependiendo de las actividades modeladas. Una simulación continúa sólo cuando tiene nuevos eventos que ejecutar. Por lo tanto, si la lista se vacía como resultado de ejecutar el último evento, la simulación termina, incluso si no se ha alcanzado el tiempo final convenido.


70

Ilustración 27. Organización de una lista de eventos durante el tiempo de ejecución

Al inicio de la simulación, la lista de eventos debe recibir como mínimo un evento para que la ejecución comience. Hay un tipo especial de evento (begin simulation) que los procesos alojados en los QP (módulos de tipo cola o procesador) pueden lanzar si tienen un atributo específico habilitado (begsim intrpt). Además los módulos procesador pueden elegir automáticamente cuándo enviarán su primer paquete. Eventos de éste tipo son los que se suelen ver en la lista de eventos en cuanto la simulación comienza.

3.5.2.3 Eventos

• Atributos de los Eventos Anteriormente se ha mencionado que un evento tiene un tiempo definido en el que debe ocurrir. Pero ésta no es la única propiedad que posee. Cada evento tiene un conjunto de atributos que almacenan información describiéndolo. Parte de esta información es usada por el Simulation Kernel a la hora de ejecutarlo. La información también puede ser usada para procesar el evento según haya definido el usuario dependiendo de unas circunstancias u otras . Algunos de esos atributos son:


71

- time: instante de la simulación en que el evento debe ocurrir. - execution ID: identificador de la orden de ejecución del evento. - module: módulo en el que el evento ocurrirá. - process: proceso que recibe el evento. - type: tipo de evento, según la actividad con la que está relacionado. - …

• Tipos de Eventos En OPNET hay trece tipos de eventos que soportan varias actividades de modelado. Algunos de ellos servirán sólo para propósitos muy específicos, mientras que otros son más generales y están relacionados con actividades más variadas. Entre ellos, cabe citar: - self: para contadores y modelado de delays. - stream: comunicación de paquetes entre módulos de un modelo de nodos. - statistic: notificación asíncrona de cambios en estadísticas y señales. - begin simulation: notificación de comienzo de simulación, permitiendo a los procesos inicializar su estado. - end simulation: notificación de fin de simulación, permitiendo a los procesos registrarinformación final, por ejemplo estadísticas. - process: invocación directa de un proceso dentro de un módulo.

• Procesamiento de Eventos - Interrupciones Cuando un modelo de proceso recibe un evento, necesita analizar ciertos atributos del mismo, como por ejemplo el tipo, para determinar las acciones a realizar. Una de las llamadas más usadas es op_intrpt_type(), para determinar el tipo de evento producido. Las interrupciones son las invocaciones que resultan de la ejecución de eventos por el Simulation Kernel. Ocurren cuando un evento alcanza la cabeza de la lista y es ejecutado. Tienen los mismos atributos que los eventos que las generan. De hecho, al ser las manifestaciones de los eventos, se accede a ellas obteniendo el control del evento en curso, utilizando los procedimientos de KP del paquete Ev. Una vez que se recibe una interrupción y se determina su tipo, procedencia y otra información que se considere relevante, el modelo de proceso es el que elige cómo será tratada y las acciones a realizar, dependiendo de las especificaciones dadas por el usuario.


72


73


4.1 Introducción

Una vez comprendido el marco teórico de la Gestión Activa de Colas en el Capítulo 2 y el funcionamiento de los principales mecanismos de OPNET en el Capítulo 3, el usuario ya tiene los conocimientos necesarios para hacerse una idea de cómo modelar un sistema de comunicaciones y cómo moverse por los diferentes dominios del programa. Este capítulo se centra en la utilización del programa de manera específica, describiendo cómo se implementa la Gestión Activa de Colas dentro de los router, desde la creación de la red donde se va a aplicar y configuración de la misma a través de los atributos, hasta el estudio de los External File Objetcs donde se implementa un algoritmo AQM concreto como es el RED. Una buena forma de comenzar la explicación es a través de la obtención de licencias del programa e instalación, lo cual se hace en los siguientes puntos de este apartado.

4.1.1 Requisitos previos a la instalación y uso

OPNET Modeler ha sido instalado en un ordenador personal con el sistema operativo Microsoft Windows XP Home Edition versión 2002. En este ordenador se instaló previamente un compilador de código C y C++ (Microsoft Visual C++ 6.0), necesario para compilar las distintas partes de código que componen los programas de simulación y crear el ejecutable. El siguiente paso ha sido revisar las variables de entorno locales del sistema operativo include, lib y path, que tengan los valores asociados correctamente, de manera que OPNET pueda detectar el compilador de manera automática. Dependiendo del sistema operativo y del compilador, tras la instalación estas variables pueden tener ya el valor correcto, o el usuario tendrá que modificar su contenido. Si hay problemas en este paso, en la página de OPNET, http://www.opnet.com hay una sección (FAQ) que puede dar respuesta a los problemas más usuales.

Capítulo 4.Implementación del algoritmo RED en OPNET

74

4.1.2 Obtención y Gestión de licencias

La versión del programa usada para éste proyecto ha necesitado de la concesión de licencias académicas para poderlo usar gratuitamente. Actualmente hay una versión gratuita del programa, OPNET IT Guru Academic Edition, pero la funcionalidad que permite es muy limitada (sólo la de un simulador de redes normal y corriente, sin posibilidad de extender su código) y no era suficiente para desarrollar los objetivos del proyecto. Por lo tanto, hemos tenido que solicitar una versión más completa del programa (OPNET Modeler 14.5), acogiéndonos a la opción que OPNET propone a las Universidades (OPNET University Program), cumpliendo las siguientes condiciones:

• Que la persona que solicita las licencias sea personal de docencia en la Universidad. En este caso, ha sido la tutora del proyecto la solicitante de esas licencias.

• Que el uso del programa será exclusivamente académico y no con fin comercial o

empresarial. Este requisito se cumple en nuestro caso, al solicitarse la aplicación para la realización de un proyecto de fin de carrera.

• Que todo resultado obtenido a través del uso del programa se debe poner a disposición del

público y su uso será gratuito. • Las licencias de uso del programa sólo son válidas por período de seis meses, tras los

cuales hay que renovarlas. • Se debe crear una página web describiendo cómo se está utilizando el programa y para qué

fin. • Para renovar las licencias una vez transcurrido el período de seis meses, es requisito

imprescindible actualizar la página creada antes de cada renovación, incluyendo los avances que se van obteniendo en ese período de tiempo.

Tras completar estas condiciones, la tutora obtuvo los ficheros de instalación del programa, y el nombre de usuario y contraseña para la autentificación y renovación de las licencias.

4.1.3 Instalación

En la instalación del programa se utilizan tres ficheros ejecutables, que instalan distintos componentes del programa, y se han ejecutado en el siguiente orden:

• modeler_145_PL8_7808_win • models_145_PL8_24Sep08_win • modeler_docs_02-Sep-2008_win

y que corresponden con modelador (el programa en sí) , modelos o librerías (modelos predeterminados de comportamiento de los componentes) y documentación. Una vez instalados los tres ficheros, y comprobadas las licencias, ya se puede empezar a utilizar el programa.


75

4.1.4 Configuración

Para poder utilizar el programa, hay que familiarizarse con su entorno. Previamente se han explicado conceptos necesarios para entender el programa, pero a la hora de la práctica, es complicado moverse por los diferentes menús de los editores y entender las opciones posibles. Antes de comenzar, es necesario configurar correctamente el programa para evitar posteriores problemas en su uso. La mejor forma de hacer esto es comprobando las preferencias del programa, que determinan cual es la configuración predeterminada del programa.

• Comprobar las preferencias de OPNET: Hacer clic en Edit › Preferences desde la ventana de inicio del programa o desde la ventana del Editor de Proyectos . Aparecerá la ventana Preferences Editor, que permite visualizar y editar atributos de entorno que controlan las operaciones del programa.

Ilustración 28. Ventana de preferencias en OPNET

La lista de atributos está ordenada alfabéticamente, según su nombre. Se pueden localizar atributos de manera más rápida tecleando parte del nombre dentro del campo Find. Algunos de los atributos que se han considerado interesantes son: - License Server Name (license_server), que debe corresponderse con el nombre del host desde el que se obtiene la licencia.


76

- Standalone License Server (license_server_standalone), que especifica si el programa actúa como su propio servidor de licencias. Por defecto está a FALSE, pero en nuestro caso se ha establecido a TRUE. - Model Directories (mod_dir), es un directorio que contiene los ficheros de modelos de OPNET. Si existe el atributo mod_dirs, OPNET usará los modelos que se encuentren en ese directorio. El primer directorio de la lista indica dónde se guardarán los modelos del propio usuario. Haciendo doble clic en la columna Values al lado del nombre de este atributo aparece una ventana en la que podemos insertar y eliminar directorios en cualquier momento.

4.2 Modelado a nivel de topología

Para el estudio de comportamiento de los algoritmos AQM en OPNET, se han realizado varias topologías, variando el número de usuarios. En este capítulo se describirá cómo crear la topología más sencilla utilizada y a configurar sus componentes, todo ello mediante el Editor de Proyectos de OPNET.

4.2.1 Descripción de la topología

A continuación se presenta una topología típica en forma de “cuello de botella”, con cinco Clientes y cinco Servidores Ethernet, dos switch y dos routers. Los clientes actúan como fuentes TCP, enviando tráfico de tipo FTP. La capacidad del enlace entre los dos router será muy inferior comparada con la del resto de enlaces, para crear la situación de control de congestión y experimentar descarte de paquetes y otros efectos. Se utilizarán tres componentes de configuración de parámetros globales de tres tipos: configuración de aplicaciones, configuración de perfiles y configuración de QoS.

4.2.2 Construcción paso a paso

4.2.2.1 Creación de un proyecto nuevo:

Ejecuta OPNET Modeler 14.5 � Selecciona menú File › New. 1. Selecciona Project y pulsa OK � Nombra al proyecto CuelloBotella y al escenario DropTail

� Pulsa OK. 2. Aparecerá el cuadro de diálogo Startup Wizard: Initial Topology, seleccionar la opción Create

Empty Scenario � Pulsa Next � En la lista Network Scale elige Enterprise � Pulsa Next tres veces más � Por último pulsa OK.


77

4.2.2.2 Creación de la red:

Después de los anteriores pasos, se abrirá el editor de proyectos junto con la paleta de objetos. Vamos a elegir los elementos que formarán la topología:

1. Pincha en el icono que hay a la izquierda de la ventana Search By Name. Así tendremos una visualización más sencilla de los objetos de la paleta:

Ilustración 29. Paleta de objetos

2. Haz clic con el botón izquierdo del ratón en el nodo Application Config y haz lo mismo en el

espacio de trabajo � Acto seguido haz clic con el botón derecho para dejar de crear nodos de este tipo.


78

3. Repite la operación con los nodos de la paleta hasta tener en el espacio de trabajo los siguientes nodos: Profile Config, QoS Attribute Config, ethernet_server, ethernet_wkstn, dos nodos ethernet4_slip8_gtwy y otros dos ethernet16_switch. Cierra Object Palette.

4. Cambia el nombre al nodo Application Config de la siguiente forma: clic derecho en el nodo

� Set Name � En la ventana Enter Value escribir Aplicaciones � Pulsa OK. 5. Cambiar el nombre a los nodos restantes hasta conseguir lo mostrado en el gráfico:

Ilustración 30. Nodos en el espacio de trabajo del editor de proyectos

6. Ahora vamos a unir los nodos: abrir la paleta de Objetos pinchando en el botón de la barra de herramientas � Clic con el botón izquierdo sobre el nodo 100BaseT � Pincha sobre Cliente1 y después sobre Switch1. Quedarán unidas por una línea que es el link.

7. Repetir la operación para unir Switch1 con Router1, Router2 con Switch2 y éste con

Servidor1. 8. Ente ambos routers se establece un link mucho más lento, para así crear el cuello de botella.

Pinchar en la paleta de objetos en el nodo PPP_DS1� Pinchar en el Router1 y después en Router2.

9. Guarda tu proyecto seleccionando en File › Save. Ahora ya hemos tenemos los nodos básicos de la red en el espacio de trabajo. Los siguientes pasos serán configurar el tipo de tráfico que circulará por la red, configurar tanto el cliente como el servidor, y por último añadir más clientes y servidores copiando los ya configurados.


79

4.2.2.3 Configuración del Nodo de Aplicaciones

1. Haz clic con el botón derecho del ratón en el nodo Aplicaciones › Edit Attributes. Se abrirá la ventana de atributos (Aplicaciones) Attributes.

2. En el atributo Application Definitions establecer Number of Rows a 1. Desplegar Enter

Application Name y en la columna Value del atributo Name escribir Aplicación_FTP. 3. Desplegar Description y dar doble clic en la columna Value de Ftp � Aparece el cuadro de

texto (Ftp) Table. Aquí establecemos las características que tendrá nuestra aplicación FTP. Cambiar los valores de forma que quede como en la gráfica :

4. Pulsa OK tres veces para terminar con la configuración de éste nodo.

4.2.2.4 Configuración del Nodo de Perfiles

1. Haz clic con el botón derecho del ratón en el nodo Perfiles › Edit Attributes. Se abrirá la ventana de atributos (Perfiles) Attributes.

2. Desplegar Profile Configuration y poner Number of Rows a uno � Desplegar Enter Profile

Name y nombrarlo Perfil_FTP. En Applications, establecer Number of Rows a 1 � En Enter Application Name seleccionar el nombre de la aplicación creada anteriormente, que aparecerá al hacer clic izquierdo en la casilla de Value, Aplicación_FTP.

3. Rellenar el resto de atributos como se muestra en la siguiente figura:


80

Ilustración 31. Atributos del nodo Perfiles

4. Pulsa OK para guardar los datos y cerrar la ventana y guarda tu proyecto.

4.2.2.5 Configuración de Clientes y Servidores

Configurar Cliente1: 1. Click derecho en el nodo Cliente1 › Edit Attributes. 2. Despliega Applications y da doble click en la casilla adyacente a Application: Supported

Profiles � En la nueva ventana, poner a uno la casilla Rows � En Profile Name elegir Perfil_FTP y pulsar OK.

3. Da doble click ahora en la casilla de al lado de Application: Destination Preferences �

Volver a poner Rows a uno � Debajo de Application elegir Aplicación_FTP, y debajo de Symbolic Name elegir FTP Server (establecido en el nodo Aplicaciones ). Más adelante volveremos a ésta tabla a modificar el contenido de Actual Name, cuando hayamos incorporado a la red todos los clientes y servidores.


81

Ilustración 32. Un paso en la configuración de un Cliente

4. Pulsa OK dos veces para terminar con la configuración del nodo Cliente1. Ahora añadiremos los cuatro clientes restantes con sus links correspondientes. Para facilitar la tarea, copiamos Cliente1 y lo pegamos cuatro veces: 5. Selecciona el nodo Cliente1 � Teclear Ctrl+C para copiar el nodo � Teclear Ctrl+V para

pegar: vemos que aparece un cuadrado debajo del cursor donde se va a emplazar el nuevo nodo. Pinchar una vez en el espacio de trabajo para fijarlo.

6. Una vez fijado el nodo Cliente2, unirlo con el Switch1 a través del link que automáticamente

parte desde el nodo cliente. 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: 1. Clic derecho en el nodo Servidor1 › Edit Attributes. 2. Despliega Applications y da doble clic en la casilla adyacente a Application: Supported

Services � En la nueva ventana, poner a 1 la casilla Rows � En Name elegir Aplicacion_FTP y pulsar OK. Así establecemos que el tráfico que va a aceptar éste servidor es el definido en el nodo Aplicaciones.

3. De vuelta en el menú general de atributos, localiza el atributo Server Address. Vemos que está

a Auto Assigned � Cambiarlo a Servidor1. Éste atributo es la identificación de éste servidor dentro de la red. Cada servidor necesitará uno distinto. Necesitamos definirlo para más adelante.

4. Pulsar OK para cerrar la edición de atributos. Guarda el proyecto. Ahora, como en el caso de los clientes, añadiremos los servidores restantes.


82

5. Repetir el procedimiento de copia de los clientes con Ctrl+C y Ctrl+V, uniendo los servidores con el Switch2.

6. Entra en el menú Edit Attributes de cada nuevo servidor y cambia el valor del atributo Server

Address como se hizo para Servidor1, de forma que un ServidorN tendrá como Server Address el valor ServidorN (se podría elegir el nombre que se quiera, siempre y cuando nunca se repita).

Lo último que queda por hacer en este ámbito es asignar a qué servidor envía datos cada cliente. Eso lo haremos mediante un atributo mencionado al configurar Cliente1, asignándole los diferentes Server Address dependiendo del cliente, de la siguiente manera: 7. Seleccionar Cliente1 � Edit Attributes � Editar Application: Destination Preferences �

Editar Actual Name. 8. Aparece una nueva tabla. Establece Rows a 1 � Pincha en la casilla debajo de Name, donde

pone None: aparecen las direcciones de todos los nodos de la red � Pinchar en Servidor1. 9. Así queda establecido que Cliente1 envía datos a Servidor1. Pulsa OK tres veces. Ya tenemos configurado del todo el Cliente1. Repetir el proceso para el resto de clientes, de manera que a cada ClienteN le sea asignado el ServidorN en la tabla mostrada. Cuando acabes guarda tu proyecto.

Ilustración 33. Tabla para elegir destino de Cliente1


83

A éstas alturas ya tendríamos una red válida, pero para estudiar el comportamiento de los mecanismos de control de congestión hay añadir otro apartado:

4.2.3 Configuración de Atributos QoS

1. Selecciona el nodo QoS › Edit Attributes 2. Desplegar FIFO Profiles � Desplegar FIFO Profile � Desplegar Details y cambiar el

atributo Maximum Queue Size a 70 � Pulsa OK dos veces para cerrar la ventana de atributos del nodo QoS.

3. Selecciona el link entre los dos routers en el espacio de trabajo. En la barra de tareas del editor de proyectos, desplegar el menú Protocols › IP › QoS › Configure QoS…

4. Asegurarse que la ventana tiene la siguiente forma:

Ilustración 34. Elección de la disciplina FIFO en las interfaces de los routers conectados


84

5. Pulsa OK. Verás que el link seleccionado ha cambiado de color.

Ilustración 35. Unión entre routers con las interfaces configuradas

6. Guarda tu proyecto.

4.2.4 Elección de estadísticas

En éste apartado se muestra cómo elegir las estadísticas que queremos que el programa registre durante la simulación. 1. Elegimos primero las estadísticas globales: haz clic con el botón derecho en cualquier punto

del espacio de trabajo que no sea un nodo � en el menú escoger Choose Individual Statistics: sale una ventana con todas las estadísticas disponibles.

Ilustración 36. Menú para elegir estadísticas

Ilustración 37. Ventana de elección de estadísticas sin desglosar

2. Desglosa el menú Global Statistics › IP. Pincha en la casilla de al lado de Traffic

Dropped(packets/sec).


85

3. Sin salir de Global Statistics, desglosa TCP, y pincha en la casilla Delay(secs). 4. Sal de Global Statistics, y expande ahora Link Statistics › point-to-point › utilization → 5. Pulsa OK para salir de ésta ventana. Es decir, hemos elegido registrar la tasa de paquetes perdidos en toda la red, el retraso en la entrega de los paquetes, y la utilización en todos los links de la red (nos permite hacernos una idea de cómo está aprovechando cada nodo sus conexiones). 6. Ahora elegimos las estadísticas locales, las miramos en el router: haz clic con el botón

derecho en Router1 � Choose Individual Statistics � Expande Node Statistics � Expande IP Interface

Ilustración 38. Parte de la interfaz de visualización de las estadísticas disponibles para la interfaz IP de

“Router1” 7. Activa las casillas Buffer Usage(packets), Queue Delay Variation(secs), Queuing Delay(secs) Con esto sabremos lo lleno que está el buffer del router en cada momento, la variación en el retraso o jitter experimentado en el router (el obtenido en las estadísticas globales será a nivel de la red entera), y el tiempo que tienen que esperar los paquetes antes de ser procesados y enviados. 8. Pincha OK para terminar. 9. Guarda tu proyecto.

4.2.5 Duplicar escenarios


86

Ahora sí que está configurada la red. Al no haber escogido ningún algoritmo, el control de congestión de ésta red se hará mediante Drop Tail, que es el implementado por defecto en los routers de todos los fabricantes. El siguiente paso es duplicar este escenario para crear otros en los que podamos cambiar el método de control de congestión, cambiando el tipo de AQM utilizado en los routers.

4.2.5.1 Operaciones del menú Scenarios

Antes de duplicar escenarios, es útil conocer cómo manejar y moverse en el entorno de los escenarios, para luego modificarlos, cambiar de uno a otro, hacer simulaciones, comparaciones, etc. En el editor de proyectos de OPNET hay un menú en la ventana principal, Scenarios, que aporta al usuario operaciones útiles para gestionar los escenarios que contiene un proyecto.

Ilustración 39. Vista de algunas de las operaciones del menú “Scenarios”

Algunas de las funciones de este menú que se han utilizado en éste estudio son: - New Scenario: Crear un nuevo escenario dentro del proyecto - Duplicate Scenario: Crear una copia del escenario seleccionado dentro del proyecto actual. Esta operación duplica todos los elementos del escenario original excepto los resultados de simulación. - Manage Scenarios: Es una operación muy potente y útil, ya que permite acceder a una lista de todos los escenarios del proyecto actual y su estatus. En esta lista se puede, de forma centralizada, renombrar, añadir, duplicar y borrar uno o varios escenarios. Además, se puede seleccionar qué escenarios simular, cambiar la duración de la simulación, y reordenar los escenarios en la lista.


87

Ilustración 40. Lista de los escenarios dentro del proyecto CuelloBotella

- Switch To Scenario: Operación que permite cambiar de escenario, mediante un menú emergente formado por los escenarios existentes en el proyecto. En la práctica, en vez de usar éste menú, es más rápido teclear ctrl.+NumEscenario, que te lleva directamente al escenario solicitado, sin necesidad de desplegar ningún menú.

4.2.5.2 Creación y configuración del escenario RED

1. Selecciona Scenarios › Duplicate Scenario � Aparece un cuadro de diálogo con un nombre por defecto. Llama al nuevo escenario RED � Pulsa OK. Automáticamente pasamos a estar editando el nuevo escenario, que es una copia exacta del anterior.

Vamos a cambiar el método de control de congestión, en vez de Drop Tail, esta vez usaremos el algoritmo RED. Para cambiar esta configuración, hacer lo siguiente: 2. Pinchar en el nodo QoS › Edit Attributes � Expandir FIFO Profiles › FIFO Profile › Details

� Expandir RED Parameters. 3. Cambiamos los parámetros del algoritmo RED como se muestra en la figura:

Ilustración 41. Configuración de parámetros del algoritmo RED en el nodo QoS


88

4. Pulsa OK. Los parámetros de RED son los siguientes: - RED Status: estatus de RED, si está habilitado, deshabilitado, o el tipo de versión. Así configurado, estamos estableciendo la versión normal de RED. - CE Marking: Uso del bit ECN. Si está deshabilitado (disabled), RED descartará los paquetes en caso de congestión. En caso contrario, marcará los paquetes con el bit ECN en vez de descartarlos. - Maximum Threshold: Parámetro Umbral máximo del algoritmo RED. Una vez el parámetro avgq sobrepasa éste valor, la probabilidad de descarte es 1. - Minimum Threshold: Parámetro Umbral mínimo del algoritmo RED. Si avgq es menor que éste valor, ningún paquete es descartado o marcado. - Mark Probability Denominator: Fracción de paquetes descartados cuando la probabilidad de descarte es máxima. Tal y como está configurado, se descarta 1 de cada 40 paquetes cuando la probabilidad es máxima. - Exponential Weight Factor: filtro pasa-bajo aplicado para calcular el parámetro tamaño medio de cola o avgq. Ahora sólo falta añadir una estadística específica del RED (el resto de estadísticas ya se configuraron en el anterior escenario, por lo que no hace falta repetir el proceso al haber duplicado el escenario), que será útil para futuras comparaciones: 5. Haz clic con el botón derecho en Router1 � Choose Individual Statistics � Node Statistics

� IP Interface � Activa una nueva casilla: RED Average Queue Size 6. Pincha OK para terminar y guarda el proyecto.

4.2.5.3 Creación y configuración del escenario GRED Este escenario será igual que el anterior, excepto que se ha cambiado la versión utilizada de RED por la de GRED, una modificación del algoritmo incorporada en los ficheros proporcionados por OPNET y que se explicará posteriormente. 1. Duplicar el escenario RED como se hizo en el anterior apartado. Llamar al nuevo escenario

GRED. Una vez creado el nuevo escenario sólo tenemos que configurar el nodo QoS para establecer como AQM el algoritmo GRED. 2. Pinchar en el nodo QoS › Edit Attributes � Expandir FIFO Profiles › FIFO Profile › Details

� Expandir RED Parameters. 3. Establecer el parámetro RED Status a GRED Enabled, quedando los parámetros como la

siguiente figura.


89

Ilustración 42. Configuración de parámetros del algoritmo RED en el nodo QoS

4.2.6 Simulación de los escenarios

Vamos a simular todos los escenarios de manera secuencial. Para ello, usaremos la operación Manage Scenarios del menú Scenarios explicada en el apartado anterior.: 1. Pincha en la barra de herramientas del editor de proyectos el botón Scenarios › Manage

Scenarios 2. En la lista que aparece con los escenarios, pincha en las casillas debajo de la columna Results.

Aparecerán varias opciones. Escoge la opción disponible <collect> o <recollect>, dependiendo de si es la primera vez que se simulan los escenarios o no. En Sim Duration (duración de la simulación) poner 1500, y en unidades o Time Units, segundos.

Al pinchar en el botón OK, aparecerá la ventana DES Execution Manager: Cuello Botella, y en el apartado de la derecha, se verá el estado de la simulación para cada escenario. Dependiendo de varios factores como la velocidad del procesador, o los procesos que se estén ejecutando en el ordenador en ese momento, etc la simulación tardará más o menos. Cuando el status de todas las simulaciones sea Completed, pulsa en el botón Close. Ahora sólo nos queda ver los resultados obtenidos y compararlos. A continuación se muestra el cuadro de simulaciones en dos momentos distintos.


90

Ilustración 43. Dos instantes de simulación: en el primer gráfico, se ha completado la simulación del primer

escenario, y el segundo va a empezar a simularse. El tercer escenario está a la espera. En el segundo gráfico, ya se han completado las tres simulaciones.

4.2.6.1 Simular un solo escenario

En caso de querer simular sólo un escenario, se puede recurrir al menú DES (Discrete Event Simulation) del editor de Proyectos: DES › Configure/Run Discrete Event Simulación…

Al pinchar en la opción Configure/Run Discrete Event Simulación… , aparece la ventana del editor de simulaciones completa, que presenta este aspecto:


91

Ilustración 45. Ventana del editor de simulaciones

A continuación se da una breve explicación de los campos presentes en esta ventana: - Duration: Duración del tiempo de la simulación. En el campo adyacente se especifican las unidades de tiempo que se da la duración. - Seed: valor inicial para la secuencia de números aleatorios, necesario para la simulación secuencial. - Values per statistic: máximo número de valores recogidos para cada estadística. - Update interval: intervalo de actualización de las estadísticas. - Simulation Kernel: tipo de núcleo que se quiere utilizar para la simulación. - Simulation set name: nombre del conjunto de simulación (valores de configuración de la simulación)

4.2.7 Comparación y visualización de resultados

En la ventana del editor de Proyectos, pulsa en el botón , que es para ver los resultados de las últimas simulaciones. en el cual si dejamos el ratón sobre él, vemos que sale la nota “View Results”. Al pulsar sobre él, aparece la pantalla Results Browser, que tiene el siguiente aspecto:


92

Ilustración 46. Ventana de visualización de resultados.

1. En el campo Results for: desplegar el menú y elegir Current Project para ver todos los

escenarios de los que consta el proyecto. 2. En el cuadro inferior, vemos dos menús desplegables: Global Statistics y Object Statistics. En

ellos, se pueden habilitar para ver en la pantalla Preview las estadísticas globales y locales elegidas antes, respectivamente. En el ejemplo, está habilitada la estadística global de descarte de paquetes en la red para los tres escenarios.

El primer campo del apartado Presentation está para elegir cómo mostrar varias gráficas: - Overlaid Statistics: todas las gráficas se superponen - Stacked Statistics: todas las gráficas se muestran por separado En el segundo campo se elige cómo se quieren representar los valores o en qué tipo de escala. Por poner un ejemplo: - As Is: Se representar los valores tal y como se han obtenido, sin ninguna transformación matemática. - Average: Se hace representa en la gráfica valores medios - Con ejes logarítmicos, distribución de probabilidades, ... A partir de aquí sólo es cuestión de probar a elegir distintas estadísticas y efectuar las comparaciones mediante las gráficas que salen. La interfaz que ofrece OPNET para la visualización


93

de resultados es bastante cómoda e intuitiva. Basta con elegir las casillas, tanto de los escenarios como de las estadísticas, y luego ver las gráficas de la forma que se crea más adecuada.

4.3 Estudio del nodo QoS

En este apartado se describe la estructura interna del nodo QoS, que es el que recoge globalmente los atributos relacionados con la Calidad de Servicio aplicada en la red. Primero se detalla la estructura a través del modelo de nodos, y luego el comportamiento a través del de procesos. Como los conceptos teóricos de ambos modelos ya se conocen, este capítulo se centrará directamente en explicar su estructura y funcionamiento. Además, se indicará cómo acceder a los editores de ambos modelos.

4.3.1 Acceso al editor de nodos

El modelado a nivel de nodos se realiza desde el editor de Nodos. Para acceder a un modelo de nodos y a su correspondiente editor, se puede hacer de varias maneras, dependiendo de la situación:

• Si se quiere crear un modelo nuevo, elegir en una ventana de inicio de OPNET o en la cualquiera de sus editores: File › New… � en el cuadro de texto que aparece, elegir Node Model del menú desplegable � Pulsar OK. Aparecerá una ventana nueva del Editor de Nodos.

• Si se quiere acceder a un modelo existente, se puede acceder de dos maneras: - A través del menú File › Open: aparece una ventana con un explorador, en la que se debe buscar ficheros del tipo Node Model Files(*.nd.m). Cuando se encuentre el modelo de nodos buscado, hacer doble clic y se abrirá una ventana del editor de nodos con el modelo concreto. - A través del editor de procesos, haciendo doble clic en el nodo del que se desea abrir su modelo, recordando que un modelo de nodos es el que describe el comportamiento del nodo en que reside. Es el método utilizado en este proyecto, puesto que los nodos que se han estudiado más a fondo para los algoritmos AQM son los routers y el nodo de configuración QoS, ambos presentes en la topología. Por ello lo más sencillo es acceder a los modelos de nodos directamente desde la topología.

4.3.2 Modelo de nodos del nodo QoS

Este nodo se utiliza para crear y configurar de manera global perfiles de QoS, que luego se aplican a nodos (routers) e interfaces específicas dentro de toda la red. Ya se ha visto que es donde se elige


94

el AQM que después utiliza Router1 para el control y prevención de la congestión y descarte de paquetes.

• Para acceder al modelo de nodos, abrir el proyecto CuelloBotella, cualquiera de sus escenarios.

• Hacer doble clic en el nodo QoS, aparecerá el siguiente modelo de nodos:

Ilustración 47. El nodo QoS y su modelo de nodos.

Como se aprecia en el dibujo, el modelo de nodos asociado al nodo QoS se denomina QoS Attribute Config, y consta de un solo módulo de tipo procesador denominado attribute_definer. Este modelo de nodos es tan simple porque en realidad su única labor es la configuración de parámetros que otros modelos de nodos utilizarán en el momento de la simulación. No tiene ninguna función equivalente a ningún dispositivo físico. Por ello, sólo consiste en un módulo que contendrá un modelo de procesos encargado de recoger los atributos elegidos por el usuario . Si se miran otros componentes que proporciona OPNET para configuración de parámetros como pueden ser los del tipo Aplicaciones y Perfiles, se ve un esquema similar. Para ver los atributos que ofrece este modelo de nodos al usuario, visibles desde el modelo de redes, se debería mirar en el menú Interfaces › Model Attributes, pero la tabla emergente está vacía, lo que significa que esos atributos en realidad son heredados del modelo de procesos. Con lo cual, no hay nada más que mostrar a este nivel.


95

4.3.3 Modelo de procesos del módulo “attribute_definer”

El modelo de procesos residente en el módulo attribute_definer será el real encargado de obtener los datos de configuración introducidos por el usuario mediante la operación Edit Attributes efectuada sobre el nodo QoS de nuestro sistema. Los modelos de procesos en general se pueden ver y editar mediante el editor de procesos que proporciona OPNET. La forma de acceder a éste editor es similar al editor de Nodos: mediante el menú File › New… y eligiendo Process Model, si se quiere crear uno nuevo. Si lo que se quiere es editar uno existente, mediante el menú File › Open, eligiendo en la ventana del explorador ficheros de tipo Process Model Files (*.pr.m), o si ya se tiene el modelo de nodos, haciendo doble clic en el módulo de interés.

Ilustración 48. Acceso al modelo de procesos de attribute_definer

Como se ve en la figura, el modelo de procesos se denomina qos_attribute_definer. Gráficamente, el STD de este modelo de proceso está formado por el estado parse, que además es el inicial. No hay ninguna transición. Por el color rojo del estado, se trata de un unforced state, y su enter executive está compuesto de 56 líneas de código, mientras que el exit executive estará vacío. Comprobemos la definición de variables y otros elementos dentro de los bloques de código:

• Header Block

Entre los ficheros de cabecera que incluye, cabe destacar :

oms_qm.h es un fichero con estructuras asociadas al manejo de colas (queue management). Las estructuras definidas aquí serán usadas dentro del external file oms_qm.ex.c, el cual contiene funciones para el manejo de colas, entre ellos, funciones específicas del algoritmo RED.


96

En el apartado de predefinición de funciones, nos fijamos en attr_def_fifo_profiles_info_parse, que recoge los atributos guardados en el atributo compuesto “FIFO Profiles”, y en attr_def_red_parameters_get, que recoge los valores almacenados en el atributo “RED Parameters”. Ambas funciones están implementadas en el function block, y se verán más adelante.

• Variables de Estado Destaca la variable:

que servirá como referencia para acceder a los distintos atributos.

• Variables Temporales

Sólo se usan dentro del STD:

Y sirven sobre todo para el manejo de objetos e identificación.

• Enter Executives

Para acceder al código de las enter executives, basta con hacer doble clic en la mitad superior del estado en cuestión. Las acciones realizadas son: - Inicializar variables de estado y temporales, inicialización de ciertas estructuras - Registrar la existencia del modelo de proceso, para ser visible para otros procesos (por ejemplo, ip_dispatch, dentro del módulo ip del nodo router), mediante la función oms_pr_process_register. - Llamada a la función attr_def_fifo_profiles_info_parse () para recoger los atributos del tipo FIFO, si están configurados. También llama a otras funciones para recoger los atributos de otras disciplinas de cola como WFQ, PQ y los de otros mecanismos de QoS como CAR y RSVP. Es decir, recoge la información correspondiente a la ventana siguiente:


97

Ilustración 49. Atributo recogido por attr_def_fifo_profiles_info_parse

En este proyecto nos hemos centrado en FIFO, por lo que no se contemplarán el resto de opciones. Para ver exactamente cómo se comporta attr_def_fifo_profiles_info_parse, abrir la ventana del function block:

• Function Block

A continuación se muestran fragmentos importantes y sus comentarios del código de la función citada: static voidattr_def_fifo_profiles_info_parse (void) { OmsT_Qm_Attributes*qm_attr_ptr = OPC_NIL; OmsT_Qm_IP_Queue_Configuration*qconfig_ptr = OPC_NIL; op_ima_obj_attr_get(my_objid,"FIFO Profiles", &qc_information_objid); … /*Obtener el nombre del perfil FIFO*/ op_ima_obj_attr_get (queuing_type_objid, "Profile Name",prof_name); /*Reservar memoria para almacenar el atributo QoS usado por la interfaz IP*/ qm_attr_ptr = ip_qos_attributes_create (IpT_Fifo_Pool, 1, (int)OmsC_Buffer_Parent_Limit, OPC_TRUE); qconfig_ptr = (OmsT_Qm_IP_Queue_Configuration*) qm_attr_ptr->queue_configuration[0]; op_ima_obj_attr_get(queuing_type_objid,"Details",&(queue_configuration_objid)); … op_ima_obj_attr_get (queue_configuration_child_objid, "Maximum Queue Size", &max_queue_size); qconfig_ptr->max_size = (double) max_queue_size; …


98

/* Recoger los parámetros RED, si existen, y guardarlos en una estructura*/ attr_def_red_parameters_get (prof_name, qconfig_ptr, 0, queue_configuration_child_objid); /* Registrar los datos del atributo FIFO Profiles en una base de datos global pasando el puntero a la estructura qm_attr_ptr. Así la información es accesible para todos los objetos de la red, por ejemplo, los routers IP*/ oms_data_def_entry_insert ("FIFO Profiles", prof_name, qm_attr_ptr); FOUT; }

Y los atributos que recoge, para que se vea la correspondencia:

La estructura qm_attr_ptr, de tipo OmsT_Qm_Attributes es importante, pues guarda información sobre colas del tipo número máximo de paquetes, número de colas por defecto, y contiene a otras estructuras para almacenar parámetros de cada una de las colas en particular, como es el parámetro qm_attr_ptr->queue_configuration , que como se ve en el código, se le hace una asignación de tipo OmsT_Qm_IP_Queue_Configuration, la otra estructura importante, que mantiene parámetros IP específicos de las colas, entre ellos, parámetros relativos al AQM RED. En la anterior función, para recoger los parámetros de RED y rellenar la estructura de tipo OmsT_Qm_IP_Queue_Configuration, se llama a otra función que también está definida en el bloque de funciones: attr_def_red_parameters_get, y que se muestra a continuación (observar que no está el código completo, sólo las partes más relevantes):

static void attr_def_red_parameters_get { OmsT_Qm_RED_Queue_Params* red_queue_params_ptr = OPC_NIL; OmsT_Qm_RED_Class_Params* red_class_params_ptr = OPC_NIL; /* Get the RED attribute object identifier.*/ op_ima_obj_attr_get (queue_configuration_child_objid, "RED Parameters", &red_parameters_objid); /* Accede al siguiente nivel en el árbol de atributos */ red_parameters_child_objid = op_topo_child (red_parameters_objid, OPC_OBJTYPE_GENERIC, 0); /* Comprobar que RED esté habilitado.*/ op_ima_obj_attr_get (red_parameters_child_objid, "RED Status", &(qconfig_ptr->red_status)); if (qconfig_ptr->red_status == OMSC_NO_RED)FOUT; /* Reservar memoria para los parámetros RED */ red_queue_params_ptr = ip_qos_red_queue_params_mem_alloc ();


99

/* A continuación recoge los parámetros de RED */ op_ima_obj_attr_get (red_parameters_child_objid, "Exponential Weight Factor", &(red_queue_params_ptr->exponential_weight_factor)); op_ima_obj_attr_get (red_parameters_child_objid, "CE Marking", &red_queue_params_ptr->ce_marking); op_ima_obj_attr_get (red_parameters_child_objid, "Minimum Threshold", &minimum_threshold); op_ima_obj_attr_get (red_parameters_child_objid, "Maximum Threshold", &maximum_threshold); … op_ima_obj_attr_get (red_parameters_child_objid, "Mark Probability Denominator", &mark_prob_string); … /* Reservar memoria para el perfil RED. */ red_class_params_ptr = ip_qos_red_class_params_mem_alloc (); /* Set the tresholds. */ red_class_params_ptr->minimum_threshold = minimum_threshold; red_class_params_ptr->maximum_threshold = maximum_threshold; /* Match best effort traffic. (No aplicaremos ningún método de QoS) */ red_class_params_ptr->match_value = OmsC_Qm_Best_Effort; /* Insert the RED class ptr into the RED queue ptr list */ op_prg_list_insert (red_queue_params_ptr->red_class_params_lptr, red_class_params_ptr, OPC_LISTPOS_TAIL); /* Asignar los parámetros obtenidos a la estructura con la que ha sido llamada la función. */ … qconfig_ptr->red_queue_params_ptr = red_queue_params_ptr; }

Ilustración 50. Parámetros recogidos mediante attr_def_red_parameters_get.

Es interesante en esta última función saber que cuando recoge el parámetro “RED Status”, puede encontrarse con diferentes valores, definidos como constantes en el fichero de cabecera antes incluído, oms_qm.h:

#define OMSC_NO_RED 0 #define OMSC_RED 1 #define OMSC_WRED 2

o con nuestro valor definido para la extensión de RED:

#define OMSC_GRED 3


100

Éste valor se quedará guardado en la estructura:

qm_attr_ptr�qconfig_ptr�red_status

Y se utilizará en una función posterior para saber qué tipo de cálculo aplicar a la hora de obtener la probabilidad de descartes, y si un paquete debe ser descartado o no.

• Funcion para recoger parámetros: Un punto importante que explicar, es la función que recoge los parámetros, que ya se ha visto en otras ocasiones, pero no ha sido explicada. Veámoslo con un ejemplo: op_ima_obj_attr_get (id_objeto, "Nombre Param", &variable );

Ésta función, perteneciente a los Kernel Procedures (KP) aportados por Simulation Kernel, recoge el parámetro de nombre "Nombre Param" del objeto con identificador id_objeto, y lo guarda en una variable llamada variable. Otras funciones destacadas son: ip_qos_attributes_create, ip_qos_red_queue_params_mem_alloc, ip_qos_red_class_params_mem_alloc De momento, se debe saber que las tres están definidas en el fichero externo ip_qos_support.ex.c, dependiente de oms_qm.h, fichero incluído a través del header block.

4.3.4 Modificación de atributos

Como se ha dicho anteriormente, los atributos proporcionan al usuario la manera de configurar un nodo conforme a las especificaciones que necesite a través de una interfaz gráfica, sin adentrarse en la complejidad de la implementación del nodo. En el caso del nodo QoS, el usuario puede elegir distintos mecanismos para proporcionar a la red cierta Calidad de Servicio a partir de los nodos intermedios, como son las disciplinas de cola, los algoritmos de Gestión Activa de colas, o el protocolo RSVP. Se puede modificar o extender esa interfaz de acceso a los atributos tanto desde el editor de nodos como desde el de procesos para especializar los nodos que utilicemos en nuestro sistema. En este caso nos interesa modificar esa interfaz desde el modelo de procesos, ya que así, el modelo de nodos heredará el nuevo conjunto de atributos, y a la vez está más accesible a los procesos para hacer sus cálculos, como hemos visto que pasaba en el anterior capítulo con la recolección de los atributos FIFO Profiles y RED Parameters. A continuación se mostrará cómo extender el conjunto de atributos del nodo QoS para tener acceso al nuevo algoritmo GRED.


101

4.3.4.1 Acceso a la tabla de atributos

En la barra de tareas del editor de proyectos, acceder al menú Interfaces › Model Attributes. Aparecerá la siguiente ventana:

Ilustración 51. Ventana Model Attributes del modelo de proceso del nodo QoS

Como se ve, son los mismos atributos existentes al elegir Edit Attributes sobre el nodo QoS en el editor de proyectos. Analizando esta ventana, vemos que en realidad es una tabla con varias columnas. Veamos cada una de ellas, y a la vez veamos qué significan los valores asignados al atributo FIFO en concreto:

• Attribute Name: indica el nombre del atributo • Group: grupo al que pertenece el atributo (no hemos hecho ninguna clase de agrupación

de atributos, por lo que ésta columna no tendrá valor para nosotros). • Type: tipo de información que guarda el atributo. Un atributo puede ser de tipo integer,

double, compound, string, … El valor compound significa que el atributo guardará información de tipo Objid, es decir, que contendrá otros objetos atributo anidados, y que en el nivel de redes aparece como (…).

• Units: unidades en que estará expresado el atributo. Vemos que ésta columna permanece

vacía para toda la tabla por ser todos atributos compuestos. • Default Value: valor por defecto proporcionado por el sistema cuando el atributo es

requerido y no ha sido configurado por el usuario. También se usa para sugerir un valor al usuario.


102

• 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.

Ilustración 52. Atributos de FIFO Profiles

Que equivale al siguiente nivel en la jerarquía de atributos (se puede observar en figuras anteriores que muestran el atributo FIFO Profiles desplegado). Vemos que el segundo atributo, Details es a su vez compuesto, por lo que volvemos a editarlo como en el caso anterior, obteniendo los atributos:

Esta vez vemos como ya se le da a uno de los atributos, Maximum Queue Size, un valor por defecto (500) y una unidad (pkts). Esto significa que si el usuario no configura este atributo, por defecto, el tamaño de buffer en una cola FIFO va a ser de 500 paquetes.

4.3.4.2 Añadir un nuevo atributo

Si se necesita añadir un nuevo atributo correspondiente a la configuración de un nuevo AQM diferente de RED se podría hacer escribiendo su nombre en el campo New attribute y pulsando el botón Add, con lo que el atributo aparecería en una tabla, y habría configurar el resto de los campos. En la tabla siguiente, se muestra un ejemplo en el que se ha añadido un atributo compuesto que pueda guardar los parámetros de configuración PID:


103

Ilustración 53. Añadir un nuevo atributo

Observar que a diferencia de la primera tabla, en estas dos últimas ha desaparecido la columna Group (sólo se pueden agrupar atributos del primer nivel de la jerarquía) y han aparecido dos nuevas columnas:

• Primary Key: designa el atributo como clave primaria. El nombre del atributo designado de esta manera aparece en la columna de la caja de diálogo del atributo compuesto. Ayuda a la comprensión del atributo compuesto.

• Prominent: para miembros de un atributo compuesto, incluye el atributo en las búsquedas

con filtro. A partir de tener el nuevo atributo, sólo quedaría crear y configurar su árbol de atributos (se ha definido de tipo compuesto por necesitar varios parámetros). No nos vamos a detener en cómo crear toda la jerarquía del atributo PID, pues eso formará parte de posteriores trabajos. Seguimos estudiando el árbol de atributos, para ello, editamos esta vez el atributo compuesto RED Parameters. Obtenemos la siguiente tabla, en la que ya todos los atributos son simples, y se ven los valores por defecto que aparecen al editar los atributos desde el editor de proyectos por primera vez (hemos llegado al último nivel de estructura del atributo):

Ilustración 54. Atributos dentro del atributo compuesto RED Parameters


104

Se ha añadido la nueva versión de RED, GRED, como un nuevo tipo de RED, por lo que tendrá un tratamiento parecido al de la versión de RED, WRED. Es decir, se debe añadir una nueva opción al valor del atributo RED Status. Para editar este atributo ya definido, primero debemos tener acceso a él, pero es privado (no podemos utilizar la opción Edit Properties como en los casos anteriores).

4.3.4.3 Añadir valores a un atributo ya creado

Para modificar un atributo, debemos hacer público su conjunto de valores. Para ello, señalamos dicho atributo y damos a la opción Edit Compound Attributes Properties (como se ve, la opción de las anteriores ventanas no está habilitada). Aparece una nueva ventana (se muestra a continuación), con los atributos de RED Parameters, incluido el del atributo GRED añadido anteriormente.

Ilustración 55. Symbol map de RED Parameters

Vamos a describir los campos de ésta ventana:

• Data Type: Nos dice el tipo de atributo que estamos editando (que compuesto). • Default Value: Valor que aparecerá por defecto en el atributo. • Units: Unidades en que está expresado el valor (vacío, al ser atributo compuesto). • Comments: Comentarios explicando el significado del atributo o cualquier otra

información que se considere oportuna.


105

• Symbol map: Conjunto de valores posibles del atributo. Vemos que las opciones posibles son las que saldrían al editar los atributos. La correspondencia de esto con la configuración de parámetros sería los siguiente:

Ilustración 56. Correspondencia con Symbol map

Para el conjunto de valores del symbol map, debemos entrar en el modo privado (el no accesible por el público): nos fijamos en el campo de la ventana que falta por explicar: • Attribute Properties: Las propiedades de los atributos se guardan en un fichero llamado RED_Parameters, como se ve. Para modificarlos, seleccionar Private, y pasaremos a editar un nuevo fichero (desaparece el nombre anterior).

Ilustración 57. Propiedades del atributo RED Parameters


106

Los campos que antes estaban deshabilitados se habilitarán ahora. Por poner un ejemplo, vamos a añadir un nuevo valor al Symbol map, como si fuéramos a añadir un nuevo algoritmo, CRED: escribirlo en el campo donde pone New Symbol:

Ilustración 58. Añadiendo un valor a Symbol Map

Ahora pulsar OK para salir de las propiedades y volver a la pantalla anterior, recordando que seguimos en modo privado. Ahora, al seleccionar RED Status, sí que podemos elegir Edit Properties (a diferencia de antes en el modo público). Lo seleccionamos y sale una nueva ventana con un nuevo Symbol map, que debemos cambiar para añadir el nuevo valor. Lo añadimos y le damos el valor 4 (luego habría que declararlo en oms_qm.h como constante con valor 4, como se hizo con GRED y el valor 3, como se ha visto antes, para que el valor se asocie correctamente con el código).

Ilustración 59. Asignación de valor a nuevo símbolo

Pulsar OK para volver a la ventana anterior, y volvemos a pulsar Edit Attribute Properties. Ya en la ventana, volver al dominio público habilitando la casilla Public. Al lado, aparecerá la palabra unnamed, indicando que se ha creado un nuevo fichero de propiedades. Pulsar ahora el botón Save


107

Public. Aparece una ventana que nos deja elegir dónde grabar el nuevo fichero. Grabarlo con el nombre RED_Parameters3 y pulsar OK.

Ilustración 60. Nuevo fichero de propiedades públicas de un atributo.

En este punto, ya hemos terminado de trabajar con el modelo de procesos del nodo QoS, centrado en recoger los atributos que configuran la Calidad de Servicio de una red de forma global. Por hacer un resumen, primero se han analizado las variables implicadas en el modelo de proceso, tanto temporales como globales y de estado, luego el STD asociado, y en cómo en el function block están implementadas las funciones para recoger los atributos configurados a partir del menú Interfaces › Model Attributes, centrándonos en FIFO y RED. Finalmente se ha visto la necesidad de modificar una de las librerías, oms_qm.h, para declarar una variable que se corresponda con el valor añadido (versión de RED, GRED) para el atributo RED Status. Como ejemplo para la modificación de atributos, se ha explicado cómo añadir un nuevo valor, CRED, incluyéndolo en el symbol map del atributo, entrando antes en el dominio privado para crear un nuevo fichero con las propiedades del atributo. El siguiente apartado se centrará en el funcionamiento de un router, en el que se implementa la gestión de paquetes mediante el protocolo IP, y los algoritmos de control de congestión.

4.4 Estudio de un nodo router

En este apartado se describe la estructura interna de uno de los nodos router existentes en las topologías utilizadas en este proyecto. El router es el encargado, entre otras cosas, de aplicar las disciplinas de cola y de control de congestión bajo el protocolo IP, por lo que en este tipo de nodos es donde se encuentra implementada la funcionalidad de los AQM, y su modelo de nodos es, por tanto, el más importante de los analizados para este proyecto. Primero se describirá su estructura a través del modelo de nodos, y luego su comportamiento a través del de procesos. Tanto el modelo de nodos como el de procesos son más complejos que los del nodo QoS, pues en este caso sí que estamos ante un nodo que simula el desempeño de una tarea real dentro de una red. Estudiaremos esos modelos a continuación. En el apartado anterior ya se ha descrito cómo acceder tanto al editor de nodos como al de procesos, por lo que si se necesita explicación sobre lo que se va a hacer en los puntos siguientes, se puede recurrir a dicho apartado.


108

4.4.1 Modelo de nodos del nodo router1

Es importante saber que si tenemos varios nodos router del mismo tipo en la red, daría igual sobre cual de ellos pinchar, porque al usar los mismos modelos para describir su comportamiento, los cambios que hagamos en uno se actualizan en todos. Abrir el proyecto CuelloBotella y dar doble clic sobre el nodo Router1. Se abrirá una ventana con el modelo de nodos residente.

Ilustración 61. Modelo de nodos de Router1, ethernet4_slip8_gtwy_adv

Como se ve en la ilustración, en el modelo de nodos de un router hay varios módulos de tipo procesador que implementan diferentes protocolos o mecanismos de comunicación como son ip, tcp, udp, tpal, dhcp, ARP, etc. que cooperan enviándose datos a través de packet streams (en color rojo y azul en el dibujo) y datos estadísticos (entre los módulos de tipo transmisor/receptor y los de tipo cola). Una vez analizados varios de esos módulos, se ha visto que el manejo de los mecanismos de gestión de colas en éste modelo de nodos se hace a partir del módulo ip, no es necesario analizar los demás. Por lo tanto, es en el que nos centraremos a partir de ahora.


109

4.4.2 Modelo de procesos del módulo ip

Para acceder al modelo de procesos del módulo ip, utilizar el mismo procedimiento que se ha venido explicando en el resto del documento: dar doble clic en el módulo ip.

Ilustración 62. Modelo padre del módulo ip: ip_dispatch

Aparece la ventana del editor de procesos con el modelo de proceso ip_dispatch, que es el proceso padre o raíz del módulo, es decir, el modelo de procesos de ip que se va a activar nada más empiece la simulación. El modelo de procesos raíz se especifica en el atributo process model del módulo:

Ilustración 63. Especificación de ip_dispatch como proceso raíz en el módulo ip


110

4.4.2.1 Análisis de ip_dispatch

La función de ip_dispatch es sobre todo repartir las interrupciones que le llegan al módulo desde otros puntos entre los distintos procesos hijos, que se dedican ya a tareas concretas.

• Variables de estado Destaca la variable module_data, de tipo IpT_Rte_Module_Data. Es la variable que almacena los datos compartidos por toda la jerarquía de procesos del módulo por lo que es una de las más importantes. La estructura IpT_Rte_Module_Data está definida en el fichero de cabecera ip_rte_support.h

• Variables temporales En éste bloque declara variables útiles para el procesamiento y selección de las transiciones dentro del STD.

• Header Block Sentencias para incluir ficheros de cabecera, como ip_rte_support.h nombrado antes y oms_qm.h y ip_qos_support.h, utilizados también en el modelo de proceso del nodo QoS. También hay definición de macros para las condiciones de las transiciones, y definiciones de constantes. Por último, declara estructuras globales y funciones implementadas en function block.

• Declaración de ficheros externos Para ver los ficheros externos a los que se hará referencia desde este modelo de proceso, ir al menú File › Declare External Files. Ahí se ven declarados tanto ip_qos_support.ex.c como oms_qm.ex.c. Posteriormente se escribirá más sobre ellos.

• STD

Como se ve en la ilustración 62, está formado por varios estados. Algo curioso es ver que en todos los estados, en las exit executives aparecerá la sentencia

intrpt_type = op_intrpt_type ();

que asigna a la variable temporal intrpt_type el código del tipo de interrupción producida, para comprobar si se cumple la transición para pasar al siguiente estado. - init: llama a la función ip_dispatch_do_init(), la cual registra el puntero a la variable que se utilizará como memoria compartida con otros procesos:


111

op_pro_modmem_install (&module_data);

e inicializa campos de esta variable y paquetes de datos concernientes a IP. inicializa tablas y variables referentes a flujo IP, y captura el tipo de interrupción para usar posteriormente.

• En la transición, se ejecuta la función ip_dispatch_wait_for_registrations(), que se asegura que antes de proseguir estén registrados en el Registro de Procesos todos los procesos relacionados con IP, para evitar incoherencias durante el resto de la simulación.

- wait, wait_1, wait_2: transita de estado a estado planificando auto-interrupciones, teniendo en cuenta los tiempos de simulación a la hora de interrumpir.

• En la transición, se ejecuta la función ip_dispatch_init_phase_2(), que prosigue con la inicialización de variables efectuada en el estado init.

- cmn_rte_tbl: plantea dos posibilidades de transición: estado inactive (si todas las interfaces IP del nodo están inactivas) y estado init_too(hay alguna interfaz activa). Nos centraremos en este último estado.

• Durante la transición al siguiente estado, init_too, se ejecuta la función ip_dispatch_distribute_routing_info(), que activa los distintos protocolos de enrutamiento configurados en el router.

- init_too: en este estado se finaliza la inicialización del módulo, a partir de lo cual crea diversos hijos que ejecutan tareas específicas. En los exit executives encontramos la llamada a la función: ip_dispatch_cleanup_and_create_child_processes ();[1]

Esta función es muy importante porque es la que desencadena el procesamiento de las interfaces IP. A partir de aquí, dejamos de analizar la máquina de estados, y nos centramos en la ejecución de ésta función definida, como todas las demás con el prefijo ip_dispatch, en el function block.

• Llamadas a funciones desde el function block. Estudio del código fuente. Seguiremos la trayectoria de llamadas a partir de la función anterior: 1. ip_dispatch_cleanup_and_create_child_processes() [definida en FB] static void ip_dispatch_cleanup_and_create_child_processes (void) { List*proc_record_handle_list_ptr; … /* Lista para guardar los procesos registrados */ proc_record_handle_list_ptr = op_prg_list_create (); /* Determina la disciplina de cola: FIFO, WFQ,... El proceso IP delegará sus tareas en un proceso hijo para cada interfaz que envía datos. */ ip_rte_qos_information_process (); [2]


112

... FOUT; }

2. ip_rte_qos_information_process (); [FB] static voidip_rte_qos_information_process (void) { List qos_ifaces_list; IpT_Qos_Info*intf_qos_info; IpT_QoS_Iface_Config * qos_iface_config_ptr; IpT_Rte_Iface_QoS_Data * interface_qos_data_ptr; … /** Crea los procesos hijos para procesar paquetes en la cola de salida. Se genera un proceso hijo por cada interfaz. Cada uno modela un mecanismo de encolado como FIFO, WFQ o PQ, además de mecanismos de control de congestión como RED/WRED. **/ /* Guarda en la memoria compartida informacion acerca de cada interfaz*/ module_data.shared_mem.iprmd_ptr = &module_data; /* Almacena en memoria compartida handles para paquetes enviados y descartados. Tambien se comparten otras variables de estado con el modelo de proceso de la interfaz de salida para tener en cuenta el trafico background en las estadisticas de esa interfaz de salida.*/ module_data.shared_mem.locl_pk_dropped_hdl_ptr = &module_data.locl_num_pkts_dropped_hndl; module_data.shared_mem.globl_pk_dropped_hdl_ptr = &module_data.globl_num_pkts_dropped_hndl; module_data.shared_mem.locl_num_pkts_sent_hdl_ptr = &module_data.locl_tot_pkts_sent_hndl; … /* Obtener num de interfaces.*/ iface_table_size = inet_rte_num_interfaces_get (&module_data); /* Inicializar la lista QoS iface. */ op_prg_list_init (&qos_ifaces_list); /*Comprobar la existencia del objeto QoS Attributes Config. Si no existe o no está configurado,crea perfiles por defecto.*/ ip_rte_qos_attr_config_info ();[3] /* Obtener y preprocesar la informacion de la IP QoS local */ ip_qos_info_process ((void *) &module_data, &qos_ifaces_list);[4] /* Obtener el numero de interfaces con QoS activa */ total_num_of_qos_ifaces = op_prg_list_size (&qos_ifaces_list); /* Reservar memoria para el array de datos de la interfaz QoS */ module_data.interface_qos_data_pptr = (IpT_Rte_Iface_QoS_Data**)op_prg_mem_alloc(iface_table_size * sizeof(IpT_Rte_Iface_QoS_Data *)); … /* Crear una tabla para buscar el objid de cada interfaz*/ intf_objid_lookup_table = ip_rte_proto_intf_attr_objid_table_build (module_data.ip_parameters_objid); /* Recorrer todas las QoS active interfaces para inicializar parametros relacionados con QoS como queuing schemes, CAR y RED/WRED. */ for (qos_iface_index = 0; qos_iface_index < total_num_of_qos_ifaces; qos_iface_index ++) {


113

qos_iface_config_ptr = (IpT_QoS_Iface_Config *) op_prg_list_remove (&qos_ifaces_list, OPC_LISTPOS_HEAD); /* Obtener iface_info_ptr desde el nombre de la interfaz */ if (inet_rte_is_local_intf_name (qos_iface_config_ptr->iface_name, &module_data,&iface_id,&iface_info_ptr, InetC_Addr_Family_Unknown)) { … /* Habilitar Queuing en esta Interfaz */ if (qos_iface_config_ptr->qm_attr_ptr != OPC_NIL) { iface_info_ptr->queuing_scheme = qos_iface_config_ptr->queuing_scheme; /* Crear una estructura para pasar objid del qos_information_attribute al modelo de proceso ip_output_iface*/ intf_qos_info = (IpT_Qos_Info*) op_prg_mem_alloc (sizeof (IpT_Qos_Info)); … intf_qos_info->bandwidth_type = qos_iface_config_ptr->bandwidth_type; intf_qos_info->q_profile_name = qos_iface_config_ptr->q_profile_name; intf_qos_info->buffer_size = qos_iface_config_ptr->buffer_size; intf_qos_info->attribs_ptr = qos_iface_config_ptr->qm_attr_ptr; /* Crear y generar proceso hijo ip_output_iface para la interfaz.*/ iface_info_ptr->output_iface_prohandle = op_pro_create ("ip_output_iface", &module_data.shared_mem); module_data.shared_mem.iface_index = iface_id; op_pro_invoke(iface_info_ptr->output_iface_prohandle, intf_qos_info); }//Aquí acaba lo que nos concierne en el estudio de ip_dispatch. ... }

A partir de este punto, se explican funciones implementadas en los ficheros externos declarados mediante el menú File, a los que el modelo de proceso accede a través de las definiciones en el Header Block. A continuación del nombre de cada función se detalla el fichero al que pertenecen: 3. ip_rte_qos_attr_config_info (); [ip_qos_attr_def_support.ex.c] ip_rte_qos_attr_config_info () { /** Comprueba la existencia de ip attribute object. **/ if (ip_attribute_object_exists == OPC_FALSE) { /* Comprueba la existencia del objeto mediante el registro de procesos. */ op_prg_list_init (&proc_record_handle_list); oms_pr_process_discover (OPC_OBJID_INVALID, &proc_record_handle_list, "protocol", OMSC_PR_STRING, "ip_qos_attribute_object", OPC_NIL); if (op_prg_list_size (&proc_record_handle_list) == 0) {/* Si no existe el nodo QoS, crea los valores por defecto. */ oms_qm_package_init (); ip_rte_queuing_profiles_defaults_register ();} }


114

FOUT; }

Observar en esta función la llamada a oms_pr_process_discover, que es la que realmente detecta si hay un atributo QoS global. Recordar que anteriormente, en el modelo de proceso estudiado en el nodo QoS, se había registrado el nodo mediante oms_pr_process_register. Contando que dicho nodo va a existir en todas las topologías utilizadas en este proyecto, el programa no llega a llamar a las funciones oms_qm_package_init ni ip_rte_queuing_profiles_defaults_register en este punto. Sólo tener en cuenta que dichas funciones son las que dan los valores QoS globales por defecto, en caso que el usuario no haya añadido ese nodo a su red. 4. ip_qos_info_process (); [ip_qos_support.ex.c] OMSC_EXPORT void ip_qos_info_process (void * data_ptr, List * qos_ifaces_lptr) { Compcode status; Objid attr_objid, iface_info_objid, sub_iface_info_objid, ith_attr_objid, h_subiface_objid; int num_rows, num_sub_ifaces, i, j; List policies_list; IpT_Rte_Module_Data * module_data_ptr; IpT_QoS_Profiles_Dbase * profiles_dbase_ptr; /** Procesamiento de la información de las interfaces IP. **/ FIN (ip_qos_info_process (Objid attr_objid, qos_ifaces_lptr, ...)); /* Notificaciones */ ip_qos_notif_log_handles_init(); /* Hacer un cast para una variable local equivalente a module_data */ module_data_ptr = (IpT_Rte_Module_Data *) data_ptr; /* Variable para guardar atributos IP QoS.*/ attr_objid = module_data_ptr->ip_qos_params_objid; /* Acceso al atributos Interface Information del router, que guardará información QoS pero esta vez de forma local, en el router. */ status = op_ima_obj_attr_get (attr_objid, "Interface Information" , &iface_info_objid); /* Obtener el número de interfaces configuradas en el router. */ num_rows = op_topo_child_count (iface_info_objid, OPC_OBJTYPE_GENERIC); /* Salir de ésta función si no hay interfaces configuradas. */ if (num_rows == 0)FOUT; oms_qm_package_init ();/* Inicializa ciertos valores QoS */ op_prg_list_init (&policies_list); /* Creación de base de datos para almacenar perfiles QoS locales. */ profiles_dbase_ptr = ip_qos_profiles_database_create (module_data_ptr); /* Recorrer todas las interfaces IP del router. */ for (i = 0; i < num_rows; i++) { /* Recoger identificador del atributo interfaz */ ith_attr_objid = op_topo_child (iface_info_objid, OPC_OBJTYPE_GENERIC, i);


115

/* Procesar la información en esta interfaz. */ ip_qos_iface_info_process (attr_objid, ith_attr_objid, qos_ifaces_lptr,

profiles_dbase_ptr, &policies_list, OPC_FALSE); [5] /* Obtener información de subinterfaces. En nuestro caso está vacío*/ op_ima_obj_attr_get (ith_attr_objid, "Subinterface Information" , &sub_iface_info_objid); /*Aquí hay procesamiento de subinterfaces, pero lo omitimos por no haber configurado esa información. */ … } /* Liberar memoria */ ip_qos_local_profiles_memory_free (profiles_dbase_ptr, &policies_list); FOUT; }

En esta función se recorre el atributo compuesto Interface Information del nodo router . Como se ve, en el atributo Subinterface Information, el valor es None, por eso no se ha tenido en cuenta su procesamiento. No obstante, tener en cuenta como referencia para futuros análisis, que en caso de querer configurar un router con subinterfaces distintas, una subinterfaz en realidad tiene idéntica estructura a una interfaz, por lo que su procesamiento a la hora de recolectar parámetros QoS también idéntico.

Ilustración 64. Árbol de atributos IP, Interface Information en un router, recorrido por la función

ip_qos_info_process Las funciones resaltadas son interesantes por inicializar y reservar memoria para varios parámetros relativos a QoS. No nos detendremos en ellas. Seguimos analizando la última función resaltada, ip_qos_iface_info_process, que recorrerá el sub-atributo compuesto QoS Scheme, como veremos a continuación.


116

5. ip_qos_iface_info_process (); [ip_qos_support.ex.c] static void ip_qos_iface_info_process (Objid qos_attr_objid, Objid iface_objid, List * qos_ifaces_lptr,IpT_QoS_Profiles_Dbase * profiles_dbase_ptr, List * policies_lptr, Boolean is_subiface) { Compcode status; Objid qos_scheme_objid, hold_q_objid; int hold_q_capacity = -1, bandwidth; char iface_name [256]; IpT_QoS_Bandwidth_Type bw_type; IpT_QoS_Iface_Info * iface_qos_info_ptr; IpT_QoS_Iface_Config * qos_iface_config_ptr = OPC_NIL; /* Función que procesa la información de cada interfaz, incluyendo QoS. */ FIN (ip_qos_iface_info_process (Objid iface_objid, List * qos_ifaces_lptr,…)); /* Reservar memoria para la estructura QoS. */ iface_qos_info_ptr = (IpT_QoS_Iface_Info *) op_prg_mem_alloc (sizeof (IpT_QoS_Iface_Info)); /* Initializar la estructura con valores por defecto. */ iface_qos_info_ptr->hold_q_capacity = (int) OmsC_Buffer_Parent_Limit; iface_qos_info_ptr->reserved_bandwidth = 1.0; iface_qos_info_ptr->bandwidth_type = IpC_QoS_Relative_Bandwidth; iface_qos_info_ptr->buffer_size = 1000000; … iface_qos_info_ptr->scheduling_info = OPC_NIL; iface_qos_info_ptr->red_info = OPC_NIL; iface_qos_info_ptr->in_shaping_info = OPC_NIL; iface_qos_info_ptr->out_shaping_info = OPC_NIL; /* Obtención de varios atributos de la interfaz. */ op_ima_obj_attr_get (iface_objid, "Name" , iface_name); op_ima_obj_attr_get (iface_objid, "Maximum Reserved Bandwidth" , &bandwidth); op_ima_obj_attr_get (iface_objid, "Reserved Bandwidth Type" , &bw_type); … op_ima_obj_attr_get (iface_objid, "Buffer Size" , &iface_qos_info_ptr->buffer_size); op_ima_obj_attr_get (iface_objid, "Hold Queue Capacity", &hold_q_objid); op_ima_obj_attr_get (hold_q_objid, "Outbound", &hold_q_capacity); … /* Obtener el atributo QoS. */ status = op_ima_obj_attr_get (iface_objid, "QoS Scheme", &qos_scheme_objid); /* Ordenar la información QoS para la interfaz. */ ip_qos_iface_attribute_sort (profiles_dbase_ptr, iface_qos_info_ptr, qos_attr_objid,qos_scheme_objid, policies_lptr); [6] /* Crear perfiles QoS para esta interfaz. */ ip_qos_iface_profiles_create (profiles_dbase_ptr, &qos_iface_config_ptr, iface_qos_info_ptr, qos_attr_objid); [7] … FOUT; }


117

En la Ilustración 64 se ven los atributos recogidos por ésta función. Al ser QoS Scheme un atributo compuesto, se utiliza la función resaltada ip_qos_iface_attribute_sort para registrarlo. 6. ip_qos_iface_attribute_sort (); [ip_qos_support.ex.c] static void ip_qos_iface_attribute_sort (IpT_QoS_Profiles_Dbase * profiles_dbase_ptr, IpT_QoS_Iface_Info * iface_qos_info_ptr, Objid qos_attr_objid, Objid qos_scheme_objid, List * policies_lptr) { Compcode status; Objid jth_attr_objid; int j, num_entries; char scheme_name [256]; IpT_QoS_Scheme_Type scheme_type; IpT_QoS_Mechanism_Info * qos_mechanism_info_ptr; /* Esta función clasifica la información QoS configurada desntro de la interfaz en una de las siguientes categorías: scheduling,in/out CAR y RED. Sólo se muestra el código perteneciente al caso que nosotros tenemos: FIFO y AQM (RED,WRED,GRED o cualquier otro algoritmo que se implemente) */ FIN (ip_qos_iface_attribute_sort (iface_qos_info_ptr,... )); num_entries = op_topo_child_count (qos_scheme_objid, OPC_OBJTYPE_GENERIC); for (j = 0; j < num_entries; j++) { jth_attr_objid = op_topo_child (qos_scheme_objid, OPC_OBJTYPE_GENERIC, j); /* Recoge los atributos Type y Name*/ op_ima_obj_attr_get (jth_attr_objid, "Type", &scheme_type); op_ima_obj_attr_get (jth_attr_objid, "Name", scheme_name); /* Obtiene scheme_type para las condiciones de despues y lo guarda en la estructura qos_mechanism_info_prt */ … strcpy (qos_mechanism_info_ptr->profile_name, scheme_name); qos_mechanism_info_ptr->type = scheme_type; if ((scheme_type==IpC_QoS_In_Traffic_Policy) || (scheme_type==IpC_QoS_Out_Traffic_Policy)) {/* No es nuestro caso. */} else { if ((scheme_type == IpC_QoS_DWFQ_Class_Based) || (scheme_type == IpC_QoS_FIFO) ||… {/* This is a scheduling mechanism. */ if (iface_qos_info_ptr->scheduling_info == OPC_NIL) {/*Nuestro caso, valor dado en ip_qos_iface_info_process*/ iface_qos_info_ptr->scheduling_info = qos_mechanism_info_ptr; profile_not_used = OPC_FALSE; } else {…} } … FOUT; }

En estas funciones en general no estamos asignando muchos valores porque ya se han configurado de manera global. Por eso, parte del código se ha omitido.


118

7. ip_qos_iface_profiles_create (); [ip_qos_support.ex.c] static void ip_qos_iface_profiles_create (IpT_QoS_Profiles_Dbase * profiles_dbase_ptr, IpT_QoS_Iface_Config ** qos_iface_config_pptr, IpT_QoS_Iface_Info * iface_qos_info_ptr, Objid qos_attr_objid) { char * profile_name; IpT_Queuing_Scheme queuing_scheme; IpT_QoS_Mechanism_Info *qos_mechanism_ptr, *red_info_ptr; OmsT_Qm_Attributes *qm_attr_ptr = OPC_NIL; IpT_QoS_Iface_Config qos_iface_config, *qos_iface_config_ptr = OPC_NIL; Boolean is_config_needed = OPC_FALSE; /* Esta función crea perfiles QoS para las interfaces IP */ /* basada en la infomación contenida en iface_qos_info_ptr.*/ FIN (ip_qos_iface_profiles_create (profiles_dbase_ptr, qos_iface_config_ptr, ...)); /* Asignar el nombre de la interfaz. */ qos_iface_config.iface_name = iface_qos_info_ptr->iface_name; qos_iface_config.qm_attr_ptr = OPC_NIL; /* Ver si hay configuración de QoS scheduling en la interfaz. */ if (iface_qos_info_ptr->scheduling_info != OPC_NIL) { qos_mechanism_ptr = iface_qos_info_ptr->scheduling_info; /* Coger la información RED. */ red_info_ptr = iface_qos_info_ptr->red_info; profile_name = qos_mechanism_ptr->profile_name; /* Obtener queuing scheme basándose en el tipo de perfil configurado. .*/ switch (qos_mechanism_ptr->type) {… case IpC_QoS_FIFO: queuing_scheme = IpC_FIFO_Queuing; qm_attr_ptr = ip_qos_fifo_profile_get (profiles_dbase_ptr, iface_qos_info_ptr->hold_q_capacity, qos_mechanism_ptr,red_info_ptr,qos_attr_objid); [8] break; …} /* Guardar varios valores en la estructura qos_iface_config*/ qos_iface_config.queuing_scheme = queuing_scheme; qos_iface_config.bandwidth_type = iface_qos_info_ptr->bandwidth_type; qos_iface_config.reserved_bandwidth=iface_qos_info_ptr->reserved_bandwidth; qos_iface_config.buffer_size = iface_qos_info_ptr->buffer_size; qos_iface_config.qm_attr_ptr = qm_attr_ptr; /* Guardar el nombre del perfil */ qos_iface_config.q_profile_name = (char *) op_prg_mem_alloc (sizeof (char) * (strlen (profile_name) + 1)); strcpy (qos_iface_config.q_profile_name, profile_name); is_config_needed = OPC_TRUE; } } if (is_config_needed) { /* Reservar memoria para configuración de interfaz QoS. */ qos_iface_config_ptr = (IpT_QoS_Iface_Config *)


119

op_prg_mem_alloc (sizeof (IpT_QoS_Iface_Config)); *qos_iface_config_ptr = qos_iface_config; *qos_iface_config_pptr = qos_iface_config_ptr; } … FOUT; }

8. ip_qos_fifo_profile_get (); [ip_qos_support.ex.c] Esta función comprueba la existencia perfiles FIFO. Si ya existe (se ha configurado globalmente mediante el atributo QoS), como es el caso, lo agrega a la interfaz del router de forma local. Si no, crea uno por defecto. static OmsT_Qm_Attributes * ip_qos_fifo_profile_get (IpT_QoS_Profiles_Dbase * profiles_dbase_ptr,int hold_q_capacity, IpT_QoS_Mechanism_Info * qos_mechanism_ptr, IpT_QoS_Mechanism_Info * red_info_ptr, Objid qos_attr_objid) { void * tmp_ptr; char * profile_name; Boolean red_from_policy = OPC_FALSE; OmsT_Qm_Attributes * qm_attr_ptr = OPC_NIL ; IpT_QoS_Profile_Entry * profile_entry_ptr; OmsT_Qm_IP_Queue_Configuration * qconfig_ptr = OPC_NIL; OmsT_Qm_RED_Queue_Params * red_params_ptr = OPC_NIL; /* Obtener el nombre del perfil. */ profile_name = qos_mechanism_ptr->profile_name; /* Comprobar si el perfil ya existe en la base de datos local mediante la función resaltada. Si es así, salir de la función. Si es default, crear perfil por defecto */ profile_entry_ptr = (IpT_QoS_Profile_Entry *) ip_qos_profile_dbase_access (profile_name, profiles_dbase_ptr, IpC_QoS_Scheduling_Profile,IpC_FIFO_Queuing, OPC_NIL); … /* Veamos directamente el caso de un perfil configurado globalmente en la base de datos, pero todavía no está en la local. Primero accedemos a la base de datos global en busca del perfil*/ qm_attr_ptr = (OmsT_Qm_Attributes *) oms_data_def_entry_access ("FIFO Profiles", profile_name); /* Una vez encontrado, añade el perfil global al local del router desde la base de datos mediante la siguiente función: */ ip_qos_profile_dbase_entry_add (profile_name, (void *) qm_attr_ptr, OPC_NIL, profiles_dbase_ptr, IpC_QoS_Scheduling_Profile, IpC_FIFO_Queuing, OPC_NIL); FRET (qm_attr_ptr); }

Una vez realizadas todas estas llamadas (se ha podido seguir su secuencia gracias a los números indicados entre corchetes), el control vuelve a la función ip_rte_qos_information_process, que crea e invoca el modelo de procesos ip_output_iface. A continuación de muestra un esquema-resumen de lo explicado en este apartado.


120

Ilustración 65. Esquema de llamadas desde ip_dispatch

Las funciones explicadas anteriormente se utilizan sobre todo para inicializar los valores referentes a las interfaces y a establecer su configuración. Una vez que esto está hecho, se crea un hijo o instancia del modelo de proceso ip_output_iface por cada interfaz IP detectada en el nodo router. En cada uno de esos hijos se lleva a cabo la gestión de los paquetes que llegan a cada interfaz. Por último, queda explicar dónde se declaran los procesos hijos, entre ellos ip_output_iface. • Declaración de procesos hijo Para ver seleccionar los procesos que ip_dispatch puede crear, ir al menú File › Declare Child Process Model Aparecerá una ventana con los distintos modelos de proceso y unas casillas al lado que se pueden activar o desactivar dependiendo si queremos incluir o no instancias de ese modelo en la jerarquía. Sin embargo, si sólo queremos ver la lista de procesos hijo que puede crear y no modificarla, ir al menú File › Open Child Process Model. Se desplegará una ventana en la que aparecen los procesos hijos declarados:


121

Ilustración 66. Ver los procesos hijos de ip_dispatch

Basta con seleccionar uno de ellos y aparecerá la correspondiente ventana del editor de procesos.

4.4.2.2 Análisis de ip_output_iface

Pinchar en el menú anterior en el ip_output_iface. Aparecerá una nueva ventana del editor de procesos con el modelo de proceso ip_output_iface.

• Variables de estado Viendo las variables de estado, se observan varias estructuras importantes, como OmsT_Qm_Info, o IpT_Interface_Info. Más adelante se estudiarán con más detalle. Estas variables son importantes porque, como se ha dicho en el Capítulo 3 serán las que vayan guardando los valores que harán transitar el proceso de un estado a otro del STD. No se explicará ninguna en concreto, pero se puede ver cómo van tomando valores a medida que se hacen llamadas a las funciones tanto del function block como de los ficheros externos de tipo .ex.c.


122

Ilustración 67. Variables de estado de ip_output_iface

• Variables temporales Hay que mencionar la variable invocation_mode, que el proceso utiliza para saber de qué manera está siendo invocado.

• Header Block Incluye el fichero de cabecera ip_qos_support.h, que a su vez incluye oms_qm.h. Es importante el siguiente macro: #define RECEIVE_PACKET ((invocation_mode == OPC_PROINV_INDIRECT) && (rsvp_call_type == RsvpC_Invalid))

Que dispara una interrupción ante cada llegada de un paquete.

• Declaración de ficheros externos Desde el menú File, como se indicó para el anterior modelo de proceso, se accede a la lista de ficheros externos, entre los cuales cabe destacar de nuevo ip_qos_support.ex.c y oms_qm.ex.c.


123

• STD

Ilustración 68. STD del modelo de proceso ip_output_iface

- init: es el estado inicial y como se puede ver por su color verde, es un estado forzado, es decir, en cuanto el proceso entra en este estado, ejecuta el estado (que no tiene ningún executive), y la transición, para la cual no se necesita cumplir ninguna condición, bloqueándose en init2.

• En la transición se produce la llamada a do_init, función definida en el bloque de funciones o function block. Esta función inicializa variables, destacando la variable de estado qm_info, de tipo OmsT_Qm_Info. Esta variable se configura para cada interfaz. Contiene información general como el máximo número de paquetes en cada cola, funcionamiento del procesador o lista de paquetes.

- init2: Estado que no tiene ningún executive.

• En la transición, que al igual que la anterior no tiene condiciones, se llama a la función allocate_buffers, definida en el function block. Lleva a cabo la segunda fase de inicialización de las variables del proceso, que sólo se puede efectuar cuando se ha completado la llamada do_init. A continuación se presenta un extracto de dicha función.

static void allocate_buffers (void) { IpT_Rte_Iface_QoS_Data* iface_qos_data_ptr; OmsT_Buffer_Pool_Handlebuffer_pool_handle; charnew_name [200], intf_name[128]; doubleprocessing_rate;


124

FIN (allocate_buffers ()); buffer_pool_handle = (OmsT_Buffer_Pool_Handle) op_pro_argmem_access (); /* Registro de funciones en una tabla global */ ip_qos_sup_functions_register (); [1] /* Obtener los datos qos de la interfaz. */ iface_qos_data_ptr = shared_mem_ptr->iprmd_ptr->interface_qos_data_pptr [interface_index]; … /* Initializa la estructura qm_info.*/ qm_info = Oms_Qm_Info_Create [2](ip_rte_intf_index_get (interface_info_ptr), processing_rate, ip_qos_info_assign [3],buffer_pool_handle, queuing_processing_scheme, op_pro_self (), OmsC_Qm_IP, (void*) intf_qos_info_ptr); … FOUT; }

[1] La función ip_qos_sup_functions_register, implementada en ip_qos_support.ex.c, OMSC_EXPORT void ip_qos_sup_functions_register (void) { … OmsI_Arch_Specific_Func_Table [OmsC_Qm_IP][OmsC_Qm_Enqueue_Test_Func] =(OmsT_Qm_Arch_Void_Func ) ip_qos_packet_enqueue_test; OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Create_Func] =(OmsT_Qm_Arch_Void_Func ) oms_qm_red_vars_create; OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Update_Func] =(OmsT_Qm_Arch_Void_Func ) oms_qm_red_variables_update; OmsI_Arch_Specific_Func_Table[OmsC_Qm_IP][OmsC_Qm_Drop_Policy_Vars_Delete_Func] =(OmsT_Qm_Arch_Void_Func ) oms_qm_red_variables_delete; … }

Es una función en la que se registran en la tabla global OmsI_Arch_Specific_Func_Table las funciones que se ejecutan, estando las diferentes posiciones de la tabla asociadas a macros. ¡Atención. No se están invocando, sólo registrando. Su invocación vendrá más tarde! . En el fichero oms_qm.h la tabla está definida de la siguiente forma: extern OmsT_Qm_Arch_Void_Func OmsI_Arch_Specific_Func_Table [OmsC_Qm_Max_Arch_Types] [OmsC_Qm_Max_Arch_Func_Types];

Observar que delante de la declaración está la palabra reservada extern, que como decíamos, hace que una variable sea accesible desde todas las funciones. También se definen las macros asociadas de ésta manera (el ejemplo corresponde a la primera de las asignaciones mostradas en la función de arriba): #define OMS_ENQ_TEST_FUNC (arch_type) ((OmsT_Qm_Enqueue_Test_Func)\


125

OmsI_Arch_Specific_Func_Table [arch_type] [OmsC_Qm_Enqueue_Test_Func])

De esta forma, se crea un acceso de forma unificada a las funciones, por si hubiera distintas arquitecturas con sus correspondientes funciones. Así, en vez de cambiar la invocación, se hacen nuevas asignaciones a la tabla, pero la forma de acceder a ellas sigue siendo mediante la misma macro. [2] La función Oms_Qm_Info_create, definida en oms_qm.ex.c inicializa al principio la estructura OmsT_Qm_Info. En ella se guardan atributos globales como el número máximo de paquetes. También crea una estructura para guardar los paquetes. OMSC_EXPORT OmsT_Qm_Info * Oms_Qm_Info_Create (int interface_index, double speed, OmsT_Qm_Info_Assign_Func_Ptr assign_function_ptr, OmsT_Buffer_Pool_Handle buffer_pool, OmsT_Qm_Queuing_Scheme q_scheme, Prohandle qm_invoker_prohandle, OmsT_Qm_Arch_Type qm_client_type, void* arch_info) { static Pmohandleqm_info_pmh = OPC_PMO_INVALID; OmsT_Qm_Info *qm_info = OPC_NIL; charintf_name [64]; … oms_qm_qscheme_specific_functions_register (); sprintf (intf_name, "Interface #%d", interface_index); /* Inicialización y reserva de memoria para la estructura OmsT_Qm_Info.*/ qm_info = (OmsT_Qm_Info *) op_prg_pmo_alloc (qm_info_pmh); … /* Inicializar miembros de ésta estructura */ qm_info->child_queue_pool_ptr= OPC_NIL; qm_info->default_queue_pool_ptr= OPC_NIL; qm_info->qpool_in_service_ptr= OPC_NIL; qm_info->buffer_pool_handle= OPC_NIL; qm_info->arch_type= qm_client_type; … /* Creación de colas para esta interfaz y otras operaciones, dependiendo del protocolo*/ assign_function_ptr (interface_index, speed, qm_info, buffer_pool); … /* Devolver la estructura qm_info con toda la información concerniente a las colas de una interfaz. */ FRET (qm_info); }

La función oms_qm_qscheme_specific_functions_register tiene una utilidad parecida a la función explicada anteriormente: asocia funciones a la tabla global OmsI_Qscheme_Specific_Func_Table, declarada en oms_qm.h. Esta tabla contendrá funciones específicas para cada disciplina de cola. Para poner un ejemplo, a continuación se muestra una de las asignaciones hechas en la función, cuando la estructura que se utiliza en la FIFO: … OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing][OmsC_Qm_Pkt_Deq_Complete] = (OmsT_Qm_Qscheme_Void_Func) OPC_NIL; OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing][OmsC_Qm_Queue_Select] = (OmsT_Qm_Qscheme_Void_Func) Oms_Qm_FIFO_Queue_Select;


126

La invocación de las funciones asociadas se hará mediante macros, como en el caso anterior. Como ejemplo de la declaración de esas macros en oms_qm.h: #define OMS_PKT_DEQ_COMPLETE_FUNC(qscheme) ((OmsT_Qm_Pkt_Deq_Complete_Func)\ OmsI_Qscheme_Specific_Func_Table [qscheme][OmsC_Qm_Pkt_Deq_Complete]) #define OMS_QUEUE_SELECT_FUNC(qscheme) ((OmsT_Qm_Queue_Select_Func)\ OmsI_Qscheme_Specific_Func_Table [qscheme][OmsC_Qm_Queue_Select])

[3] La función ip_qos_info_assign, definida en ip_qos_support.ex.c, es específica del protocolo IP, y asigna valores a ciertos campos de la estructura qm_info. Es una función interesante, porque obtiene información de la base de datos global (recordemos que desde el nodo QoS se había guardado ahí parte de esa información), como el nombre del perfil QoS, y accede a datos de la memoria compartida. Inicializa colas dependiendo de los valores obtenidos, y devuelve la estructura qm_info a la función Oms_Qm_Info_create que la llama desde su cabecera para seguir asignando valores iniciales a otros campos de la estructura. - Idle: en el exit executive comprueba de qué tipo es la invocación que le llega, y dependiendo de eso, se cumplirá una condición u otra, y realizará una transición u otra de entre las posibles. Nos hemos centrado en la condición RECEIVE_PACKET, definida en el header block, como se ha mencionado. El resto de transiciones tienen que ver con peticiones RSVP, que no han sido contempladas en los casos de estudio, por los que las omitimos.

• Durante la transición, que se efectuará cada vez que llegue un paquete, se ejecuta la función enqueue_packet, definida en el bloque de funciones. Esta función es la que procesa cada paquete y decide qué hacer con él: descartarlo, marcarlo o almacenarlo para posteriormente enviarlo.

Aquí acaba el estudio del STD. En las siguientes páginas se verá el conjunto de llamadas que desencadena la invocación de enqueue_packet. Al igual que se hizo en ip_dispatch, al lado de las funciones aparecerán números para facilitar su seguimiento y unos corchetes a su derecha indicando dónde están.

• Llamadas a funciones desde enqueue_packet: estudio de código fuente. [1] enqueue_packet(); [Function Block] Almacena el paquete recibido en una de las listas de la estructura qm_info. Si el procesador de la interfaz está libre, se envía el paquete. static void enqueue_packet (void) { Packet * pkptr = OPC_NIL; intqueue_id = -1; Ici *qos_ici_ptr = OPC_NIL; OmsT_Qm_Signalqm_signal; OmsT_Qm_Queue_Pool*q_pool_ptr = OPC_NIL;


127

OmsT_Qm_Classifier_Func_Ptr classify_func_ptr = OPC_NIL; /* Obtener el paquete.*/ pkptr = (Packet *) op_pro_argmem_access ()) == OPC_NIL /*Asigna clasificacion por defecto*/ classify_func_ptr = ip_qos_classifier;[2] /* Procesa el paquete que llega a la interfaz */ Oms_Qm_Packet_Process (pkptr, qm_info, classify_func_ptr, &q_pool_ptr, &queue_id); [3] /* En este punto ya se sabe lo que hacer con el paquete. Se han aplicado los algoritmos pertinentes y el paquete se procesa conforme a ello. */ qm_signal = qm_info->signal; /* Registrar estadísticas */ output_iface_stats_register [9](q_pool_ptr, queue_id); if (qm_signal == OmsC_Qm_Dropped_Packet) { /* Cuando hay congestion el paquete se descarta. Se actualizan */ /* las estadísticas y se imprime un warning. */ qos_ici_ptr = op_pk_ici_get (pkptr); /* Destruir el paquete */ … } else if (qm_signal == OmsC_Qm_Queued_Packet) { if (!qm_info->processor_busy) {/* El procesador esta libre, todas las colas están vacías. */ /* Extraer el paquete, enviarlo y activar planificador.*/ /* Block variable declaration */ doublepkt_svc_completion_time; OmsT_Qm_Queue_Info*q_info_ptr = OPC_NIL; /* Si en procesador de interfaz esta en espera, el */ /* paquete se extrae y manda inmediatamente.*/ q_info_ptr = q_pool_ptr->queue_info_parray [queue_id]; /* Extraer paquete y actualizar estadisticas. Funcion definida */ /* en oms_qm.ex.c, 3387.*/ pkptr = oms_qm_packet_extract_handler (qm_info, q_info_ptr, queue_id, &pkt_svc_completion_time, OPC_NIL); qm_info->sending_packet_ptr = pkptr; qm_info->processor_busy = OPC_TRUE; /* planificar el borrado del paquete después de enviar */ output_iface_dequeue_schedule (pkptr, q_pool_ptr, pkt_svc_completion_time); /* Enviar el paquete a la red. */ output_iface_packet_send (pkptr, queue_id); } } FOUT; }

[2] ip_qos_classifier(); [ip_qos_support.ex.c]


128

Esta función obtiene el criterio para conceder prioridad al paquete que llega, accediendo a la información de dicho paquete y basándose en el ToS . De esta forma, se permite al procesador almacenar al paquete en la cola correcta (dependiendo de la planificación de colas adoptada). OMSC_EXPORT OmsT_Qm_Pkt_Info ip_qos_classifier (Packet* pkptr, OmsT_Qm_Queue_Pool** main_qpool_pptr, int* enq_id_ptr) { intoutgoing_phb; Ici*ici_ptr; OmsT_Qm_Pkt_Infoqm_pkt_info; IpT_Pkt_Infopkt_info; IpT_Dgram_Fields*pk_fd_ptr = OPC_NIL; OmsT_Qm_Queue_Pool*sel_qpool_ptr = OPC_NIL, *main_qpool_ptr = OPC_NIL; … /* Inicializa la información del paquete mediante la siguiente función: */ ip_qos_pk_info_init (&pkt_info); if (op_pk_nfd_is_set (pkptr, "MPLS Shim Header") == OPC_TRUE) { //Obtener el tamaño del paquete. pkt_info.packet_size = (int) op_pk_total_size_get (pkptr); ici_ptr = op_pk_ici_get (pkptr);/* Obtain reference to the ICI */ op_ici_attr_get (ici_ptr, "traffic_class", &outgoing_phb); pkt_info.tos = (OmsT_Qm_Tos) outgoing_phb; pkt_info.drop_precedence = mpls_support_phb_to_drop_precedence_convert (outgoing_phb); pkt_info.pk_fragment = OPC_FALSE; } else if(op_pk_nfd_access (pkptr, "fields" ,&pk_fd_ptr)!= OPC_COMPCODE_FAILURE) { int incoming_iface; ici_ptr = op_pk_ici_get (pkptr); op_ici_attr_get (ici_ptr, "incoming_iface", &incoming_iface); /* Obtener el contenido del campo “fields" en el datagrama IP para saber el ToS, protocolo, y las direcciones fuente y destino.*/ ip_qos_pk_info_get (pkptr, incoming_iface, pk_fd_ptr, &pkt_info);} main_qpool_ptr = *main_qpool_pptr; /* Aquí busca mediante una función en la jerarquía de colas una adecuada para almacenar el paquete. Pero en nuestro caso, usamos una por defecto, pues sólo aplicamos FIFO */ sel_qpool_ptr = main_qpool_ptr->qmgmt_info_ptr->default_queue_pool_ptr; *enq_id_ptr = sel_qpool_ptr->attributes_ptr->default_queue; /* Almacenar la información en la estructura adecuada. */ pkt_info.queue_id = *enq_id_ptr; qm_pkt_info.ip_pkt_info = pkt_info; FRET (qm_pkt_info);/* Devuelve la estructura a la función anterior */ }

En realidad, acabaremos teniendo valores por defecto porque en la configuración global, hemos elegido un perfil básico FIFO sin ninguna distinción de prioridad (todos los paquetes tendrán la misma, y se almacenan en la misma cola FIFO por defecto dentro del router), y los datos enviados por todos los nodos de la red son de tipo FTP.


129

Las funciones resaltadas ip_qos_pk_info_init, mpls_support_phb_to_drop_precedence_convert y ip_qos_pk_info_get se han señalado por ser interesantes ya que describen el procesamiento de los distintos campos de las estructuras que representan los paquetes. Realmente no implican ningún cambio en la implementación del AMQ RED, por lo que aquí no se muestran, pero se deja a elección del usuario estudiarlas por su interés a la hora de entender mejor los conceptos y las estructuras usadas en la aplicación. [3] Oms_Qm_Packet_Process [oms_qm.ex.c] Esta función determina el clasificador y envía el paquete a sus correspondientes procedimientos de encolado. OMSC_EXPORT void Oms_Qm_Packet_Process (Packet *pkptr, OmsT_Qm_Info* qm_info, OmsT_Qm_Classifier_Func_Ptr classify_func_ptr, OmsT_Qm_Queue_Pool** sel_pool_pptr, int *enqueue_id_ptr) { OmsT_Qm_Queue_Pool*qpool_ptr = OPC_NIL; OmsT_Qm_Pkt_Infopkt_info; intenq_id = OMSC_UNASSIGNED; /* Primero mira la disciplina de cola usada */ switch (qm_info->queue_processing_scheme) { case OmsC_Qm_FIFO_Queuing: … { qpool_ptr = qm_info->child_queue_pool_ptr; /* Encontrar la cola a la que este paquete pertenece */ pkt_info = classify_func_ptr (pkptr, &qpool_ptr, &enq_id); *enqueue_id_ptr = enq_id; /* Basándose en el status del procesador, guardar o enviar el paquete */ Oms_Qm_Incoming_Packet_Handler (pkptr, qm_info, qpool_ptr, enq_id, pkt_info);[4] if (OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC (qm_info->queue_processing_scheme) != OPC_NIL) (OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC (qm_info->queue_processing_scheme)) (pkptr, qm_info, qpool_ptr, enq_id); break; } case OmsC_Qm_No_Queuing: { qm_info->signal = OmsC_Qm_Send_Packet; break; } default:break; } … FOUT; }

[4] Oms_Qm_Incoming_Packet_Handler [oms_qm.ex.c]


130

Función que maneja los paquetes recibidos. Obtiene si hay espacio para el paquete en el buffer o no. También actualiza estadísticas y variables de tiempo para futuros cómputos como por ejemplo retrasos en la red. static void Oms_Qm_Incoming_Packet_Handler (Packet* pkptr, OmsT_Qm_Info* qm_info, OmsT_Qm_Queue_Pool* qpool_ptr, int enqueue_q_id, OmsT_Qm_Pkt_Info pkt_info) { doublecurrent_time; Ici*oms_qm_ici_ptr = OPC_NIL; doubleinsertion_time; charqm_trace [64], mu_sim_trace [64]; OmsT_Qm_Queue_Info *q_info_ptr = OPC_NIL; … insertion_time = current_time = op_sim_time (); oms_qm_ici_ptr = op_pk_ici_get (pkptr); q_info_ptr = qpool_ptr->queue_info_parray[enqueue_q_id]; … /* Almacenar el paquete en el buffer */ insert_ok = Oms_Qm_Packet_Enqueue (pkptr, qm_info, q_info_ptr, pkt_info, current_time, enqueue_q_id);[5] … if (insert_ok == OPC_FALSE) {/* El buffer se desborda. Descartar el paquete*/ qm_info->signal = OmsC_Qm_Dropped_Packet; … /* Destruir el paquete. */ } else {/* Almacenar el paquete */ qm_info->signal = OmsC_Qm_Queued_Packet; … FOUT; }

[5] Oms_Qm_Packet_Enqueue [oms_qm.ex.c] Almacena el paquete en la cola correcta basándose en los argumentos de invocación. También identifica si hay congestión. En éste caso, se aplica el algoritmo seleccionado para restringir el tamaño de la cola. Devuelve TRUE si el paquete se ha insertado en la cola con éxito, y FALSE en caso contrario. OMSC_EXPORT Boolean Oms_Qm_Packet_Enqueue (Packet* pkptr, OmsT_Qm_Info* qm_info, OmsT_Qm_Queue_Info* q_info_ptr,OmsT_Qm_Pkt_Info pkt_info, double insert_time, int PRG_ARG_UNUSED (enqueue_q_id)) { if ((OMS_ENQ_TEST_FUNC (qm_info->arch_type)) [6] (qm_info, q_info_ptr, pkptr, pkt_info) == OmsC_Buffer_Insert_After) { if (oms_buffer_enqueue (q_info_ptr->buffer_handle, pkptr, OPC_NIL, insert_time) != OmsC_Buffer_Enqueue_Success) {FRET (OPC_FALSE);} } else {FRET (OPC_FALSE);}


131

FRET (OPC_TRUE); }

[6] ip_qos_packet_enqueue_test (); [ip_qos_support.ex.c] Como se ha visto en páginas anteriores, la macro OMS_ENQ_TEST_FUNC se había definido en oms_qm.h y se había asignado a esta función a través de ip_qos_sup_functions_register de manera que al aparecer esa macro en el texto, se invoca ip_qos_packet_enqueue_test. Esta función comprueba si el paquete puede ser encolado, basándose en el espacio disponible y en el nivel de congestión de la red en ese momento, caso en el cual se pueden aplicar distintas disciplinas. De hecho en esta función es donde se elige si aplicar AQM, y cual aplicar. Así, aquí se ven las llamadas a las funciones específicas de cómputo del algoritmo RED. Es, por lo tanto, una de las más relevantes. OMSC_EXPORT OmsT_Buffer_Insert ip_qos_packet_enqueue_test (OmsT_Qm_Info* qm_info, OmsT_Qm_Queue_Info* q_info_ptr, Packet* pkptr, OmsT_Qm_Pkt_Info qm_pkt_info) { intmax_number_of_pkts, max_subqueue_size; intcurrent_total_number_of_pkts, current_number_of_pkts; doublecurrent_total_number_of_bytes, packet_size; intqueue_id; IpT_Pkt_Infoip_pkt_info; Booleanpkt_drop = OPC_FALSE, red_drop_status = OPC_FALSE IpT_Dgram_Fields* ip_dgram_fields_ptr = OPC_NIL; OmsT_Qm_RED_Vars*red_vars_ptr = OPC_NIL; OmsT_Qm_Attributes*ip_attribs_ptr = OPC_NIL; OmsT_Buffer_Pool_Handlebuffer_pool; OmsT_Qm_IP_Queue_Configuration*queue_config_ptr = OPC_NIL; … ip_pkt_info = qm_pkt_info.ip_pkt_info; queue_id = ip_pkt_info.queue_id; ip_attribs_ptr = q_info_ptr->parent_queue_pool_ptr->attributes_ptr; buffer_pool = qm_info->buffer_pool_handle; … queue_config_ptr = (OmsT_Qm_IP_Queue_Configuration *) ip_attribs_ptr->queue_configuration [queue_id]; /* Obtener el valor del máximo número de paquetes en la cola.*/ max_number_of_pkts = ip_attribs_ptr->max_total_no_buf_pkts; /* Obtener número actual de paquetes almacenados en todo el conjunto de colas*/ current_total_number_of_pkts = oms_buffer_pool_num_packets_get (buffer_pool); /* Obtener el número de paquetes almacenados en esta cola */ current_number_of_pkts = oms_buffer_num_packets_get (q_info_ptr->buffer_handle); /* Máximo número de paquetes permitido en períodos de congestión..*/ max_subqueue_size = queue_config_ptr->max_size; /* Computar el tamaño medio de cola para RED, WRED, GRED, etc. */ if (queue_config_ptr->red_status != OMSC_NO_RED) { Oms_Qm_Average_Queue_Size_Update [7](q_info_ptr, queue_config_ptr->red_queue_params_ptr->exponential_weight_factor);


132

} /* Obtener el tamaño del paquete en bytes.*/ packet_size = (double) op_pk_total_size_get (pkptr) / 8; current_total_number_of_bytes = oms_buffer_pool_num_bytes_get (buffer_pool); /* Hay 5 condiciones para decidir si se puede encolar el paquete. */ /* 1. Si no hay espacio en el buffer, descartar paquete.*/ /* 2. Si hay espacio, aceptar paquetes directamente. */ /* 3. Si va dirigida a una LLQ, comprobar si hay congestión. En caso que si, forzar el límite LLQ.*/ /* 4. Para situaciones de RSVP …*/ /* 5. Si no hay espacio basándose en un límite, forzar un algoritmo para controlarlo. */ /* ----CHECK #1----- Comprobar espacio*/ if (packet_size + current_total_number_of_bytes > qm_info->max_buffer_size) { /* Buffer lleno � descartar paquete */ FRET (OmsC_Buffer_Insert_Units_Overflow); } /* ----CHECK #2----- */ else if ((ip_pkt_info.protocol == IpC_Protocol_Ospf) || (ip_pkt_info.protocol == IpC_Protocol_Igrp) || (ip_pkt_info.protocol == IpC_Protocol_Eigrp)) { /* Para paquetes de control, guardarlo si no se excede el tamaño del buffer sin hacer otros cálculos.*/ FRET (OmsC_Buffer_Insert_After); } /* ----CHECK #3----- */ /* Cuando LLQ está configurado. No nos detenemos en ello. */ /* ----CHECK #4----- */ /* Cuando RSVP está configurado. No nos detenemos en ello. */ /* ----CHECK #5----- */ {/* Comparar el número de paquetes en el buffer con el número permitido.SI es mayor que lo permitido, aplicar el algoritmo elegido. Este es el check utilidado en caso de configurar AQM*/ if ((current_total_number_of_pkts >= max_number_of_pkts) && ((int) current_number_of_pkts >= max_subqueue_size)) { pkt_drop = OPC_TRUE; else if (!is_micro_sim_pkt && queue_config_ptr->red_status != OMSC_NO_RED) { red_vars_ptr = (OmsT_Qm_RED_Vars*) q_info_ptr->drop_policy_vars_ptr; /* Comprobar si RED necesita descartar este paquete. */ red_drop_status = oms_qm_red_packet_drop [8](red_vars_ptr->average_queue_size, queue_config_ptr->red_status, queue_config_ptr->red_queue_params_ptr, ip_pkt_info.tos); /*Si está acitvado CE marking, en vez de descartar, marcar el paquete. if ((red_drop_status == OPC_TRUE) && (queue_config_ptr->red_queue_params_ptr->ce_marking == OPC_TRUE)) { pkt_drop = OPC_FALSE;/* No descartar */ op_pk_nfd_access(pkptr,"fields",&ip_dgram_fields_ptr); if (ip_dgram_fields_ptr->ECT == OPC_TRUE) {/*Marcar el paquete indicando congestión y almacenarlo.*/


133

ip_dgram_fields_ptr->CE = 1; }//fin_if(ip_dgram_fields_ptr->ECT == OPC_TRUE) }//fin_if else if (red_drop_status == OPC_TRUE) { /* Descartar el datagrama. */ pkt_drop = OPC_TRUE; strcpy (disp_string1, "Packet dropped on RED's drop policy"); } } if (pkt_drop) { /* The packet can be dropped due to insufficient buffer or RED policy */ FRET (OmsC_Buffer_Insert_Ignore_Element); } } /* El paquete es aceptado, y almacenado el ultimo. */ FRET (OmsC_Buffer_Insert_After); }

[7] Oms_Qm_Average_Queue_Size_Update ; [oms_qm.ex.c] Esta función actualiza el parámetro Tamaño medio de cola o Average_queue_size, usado por RED para determinar si un paquete debe ser descartado debido a la congestión. Esta función se utiliza cada vez que un paquete entra en el sistema. OMSC_EXPORT void Oms_Qm_Average_Queue_Size_Update (OmsT_Qm_Queue_Info* queue_info_ptr, int exp_weight_factor) { doubleavge_queue_size, wq, m, last_start_idle_time; intqueue_size; doubletypical_transmission_time_for_a_small_packet = 0.001; … /* Obtener los parámetros para calcular average queue size.*/ avge_queue_size = ((OmsT_Qm_RED_Vars *) queue_info_ptr-> drop_policy_vars_ptr)->average_queue_size; queue_size = (int) oms_buffer_num_packets_get (queue_info_ptr->buffer_handle); wq = pow (0.5, exp_weight_factor); last_start_idle_time = ((OmsT_Qm_RED_Vars *) queue_info_ptr->drop_policy_vars_ptr)->start_idle_time; /* Una vez obtenidos los parámetros, hacer el cálculo.*/ if (queue_size == 0) { m = (op_sim_time () - last_start_idle_time) / typical_transmission_time_for_a_small_packet; avge_queue_size = pow ((1 - wq), m) * avge_queue_size; } else { avge_queue_size = (avge_queue_size * (1 - wq)) + (queue_size * wq);} /* Actualizar el parámetro average queue size en la estructura de datos. */ ((OmsT_Qm_RED_Vars *)queue_info_ptr->drop_policy_vars_ptr)->average_queue_size= avge_queue_size; FOUT; }


134

Como se ve en la función, se calcula el tamaño de cola utilizando la fórmula de RED ya vista en la teoría,

Qavg = (1 − ωq) Qavg + ωq Qavg

siempre y cuando el tamaño de cola actual no sea cero. Si no, tiene en cuenta el tiempo pasado desde el último paquete recibido, para que el algoritmo sea más eficiente. [8] oms_qm_red_packet_drop; [oms_qm.ex.c] Esta función implementa el comportamiento del algoritmo RED y su variante WRED. Además, es donde se ha modificado el código para añadir la variante Gentle Red o GRED que se ha ido viendo a lo largo del documento. Se devuelve como resultado si el paquete se debe descartar por probabilidad o no. OMSC_EXPORT Boolean oms_qm_red_packet_drop (doubleavge_queue_size, int red_status,OmsT_Qm_RED_Queue_Params* red_queue_params_ptr, int dscp) { int ip_precedence; int discard_class; int i, num_entries; intmin_threshold, max_threshold, mark_prob_denominator; doublerandom_number, dropping_probability, maxp; Booleanmatch_found = OPC_FALSE; OmsT_Qm_RED_Class_Params* red_class_params_ptr = OPC_NIL; OmsT_Qm_RED_Class_Params* default_red_class_params_ptr = OPC_NIL; OmsT_Qm_Property_Type red_match_property = OmsC_Qm_Ip_Precedence; /* Cálculos necesarios para la variante WRED. */ red_match_property = red_queue_params_ptr->match_property; num_entries = op_prg_list_size(red_queue_params_ptr->red_class_params_lptr); for(i = 0; i < num_entries; i++) { red_class_params_ptr = (OmsT_Qm_RED_Class_Params *) op_prg_list_access (red_queue_params_ptr->red_class_params_lptr, i); /* Si estamos en el caso por defecto */ if(red_class_params_ptr->match_value == OmsC_Qm_Best_Effort) default_red_class_params_ptr = red_class_params_ptr; switch(red_match_property) { case OmsC_Qm_Discard_Class: discard_class = (int) ((dscp & 24 ) >> 3); if(red_class_params_ptr->match_value == discard_class) match_found = OPC_TRUE; break; case OmsC_Qm_Dscp: if(red_class_params_ptr->match_value == dscp) match_found = OPC_TRUE; break; case OmsC_Qm_Ip_Precedence:


135

/* Uso de mascaras para obtener la IP Precedence (0 a 7). */ ip_precedence = (int) dscp/32; if(red_class_params_ptr->match_value == ip_precedence) match_found = OPC_TRUE; break; default:break; } if(match_found == OPC_TRUE) break; } /* En caso de Best Effort, aplicar valores por defecto. */ if (match_found == OPC_FALSE) { red_class_params_ptr = default_red_class_params_ptr; } /* Obtener los umbrales máximo y mínimo.*/ max_threshold = red_class_params_ptr->maximum_threshold; min_threshold = red_class_params_ptr->minimum_threshold; /* Obtener el denominador de probabilidad máxima. Este parámetro es la fracción de paquetes descartados cuando el tamaño medio de cola alcanza el umbral máximo. */ mark_prob_denominator = red_class_params_ptr->mark_probability_denominator; /* Si WRED está habilitado, se modifica el umbral mínimo, que depende de la IP precedence. OMSC_WRED solo se configura globalmente desde el icono IP QoS Config (nuestro nodo QoS en la topología) */ if (red_status == OMSC_WRED) { /* Extraer la IP precedence de los tres primeros bits del valor ToS/DSCP. */ ip_precedence = (int) dscp/32; min_threshold = min_threshold + (max_threshold - min_threshold) * ip_precedence/ 7; } /* Si el tamaño medio de cola cae entre los umbrales máximo y mínimo, descartar el paquete aleatoriamente con una probabilidad. */ if ((avge_queue_size >= min_threshold) && (avge_queue_size < max_threshold)) { /* Calcular la probabilidad de pérdida de este paquete.*/ dropping_probability = 1.0 / mark_prob_denominator * (avge_queue_size - min_threshold) / (max_threshold - min_threshold); /* Obtener un número aleatorio. */ random_number = op_dist_uniform (1.0); FRET ((Boolean) (random_number <= dropping_probability)); } else /* CODIGO AÑADIDO PARA IMPLEMENTACIÓN DE GRED */ { if ((red_status == OMSC_GRED) && (avge_queue_size >= max_threshold) && (avge_queue_size < max_threshold*2)) {/* Con GRED habilitado, el algoritmo varia su comportamiento cuando se excede el umbral máximo. En vez de descartar todos los paquetes directamente, varía la fórmula para que se aumente la probabilidad desde maxp o probabilidad máxima hasta uno. */ maxp = 1.0 / mark_prob_denominator; dropping_probability =((1.0-maxp)* (avge_queue_size-max_threshold))/max_threshold + maxp; random_number = op_dist_uniform (1.0);


136

FRET ((Boolean) (random_number <= dropping_probability)); } FRET ((Boolean) (avge_queue_size >= max_threshold)); } }

Este es el código que se ha añadido en oms_qm.ex.c para la implementación de la variante GRED. Como se ve, sólo entra en funcionamiento si el tamaño medio de cola (o parámetro avge_queue_size) excede el umbral máximo, implementado en forma de condición if. Así, se calcula la probabilidad de pérdida de paquetes como ya se dijo en el bloque de teoría, a partir de la fórmula

Pd_gred =(1- Maxp)(Qavg − Maxth) / (Maxth) + Maxp Si Maxth<Qavg<2*Maxth Por último, después de haber calculado lo que hacer con el paquete, se deben actualizar estadísticas, lo cual se hace de nuevo en la función del function block enqueue_packet, utilizando output_iface_stats_register: [9] output_iface_stats_register; [function block] Registra estadísticas para una cola para mostrarlas cuando el usuario lo requiere. A continuación se muestra la parte de la función relativa a AQM: static void output_iface_stats_register(OmsT_Qm_Queue_Pool* qpool_ptr, int q_index) { charqueuing_scheme [256], new_name [256], intf_name [128]; charstat_annotation_str [256], queue_category_str [80]="\0"; intq_label, red_status; Booleanllq_flag = OPC_FALSE; Objidmy_id; OmsT_Qm_Queue_Info*qinfo_ptr = OPC_NIL; OmsT_Dim_Stat_Handledim_stathandle; qinfo_ptr = qpool_ptr->queue_info_parray [q_index]; /* Obtener la ID del proceso.*/ /* Obtener el nombre del esquema de cola. */ /* Inicializar estadísticas para Buffer Usage (packets y bytes), queuing delay, jitter, tráfico descartado, enviado y recibido. */ /* Registrar estadísticas para RED si está habilitado.*/ (OMS_ATTRIBUTE_GET_FUNC (OmsC_Qm_IP)) (qpool_ptr, OmsC_Qm_RED_Status, q_index, &red_status); if (red_status == OMSC_RED) { sprintf (new_name, "RED Average Queue Size %s Q%d%s", intf_name, q_label, queue_category_str); dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "RED Average Queue Size", stat_annotation_str, OPC_STAT_LOCAL); Oms_Dim_Stat_Rename (dim_stathandle, new_name);


137

oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle); } else if (red_status == OMSC_WRED) { /* Registrar estadísticas para WRED si está habilitado.*/ sprintf (new_name, "WRED Average Queue Size %s Q%d%s", intf_name, q_label, queue_category_str); dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "RED Average Queue Size", stat_annotation_str, OPC_STAT_LOCAL); Oms_Dim_Stat_Rename (dim_stathandle, new_name); oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle); } else if (red_status == OMSC_GRED) { /* CÓDIGO AÑADIDO */ /* Registrar estadísticas para GRED si está habilitado.*/sprintf (new_name, "GRED Average Queue Size %s Q%d%s",intf_name, q_label, queue_category_str); dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "GRED Average Queue Size", stat_annotation_str, OPC_STAT_LOCAL); Oms_Dim_Stat_Rename (dim_stathandle, new_name); oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle); } … FOUT; }

Y con esto acabaría la sucesión de llamadas que procesan un paquete desde su llamada hasta la ejecución del AQM para decidir si descartar/marcar un paquete o no. En la siguiente página se muestra un esquema con las llamadas implicadas desde el modelo de proceso ip_output_iface, indicando el orden en que se producen y agrupadas por fichero donde fueron implementadas, al igual que se hizo con el modelo de proceso ip_dispatch, con el fin de aportar un poco de claridad a lo que se ha explicado.


138

Ilustración 69. Esquema de llamadas desde ip_output_iface

• Otras funciones que participan en la implementación del AQM RED. Además de lo explicado aquí, quedarían varias llamadas a funciones para actualizar las variables y estructuras de RED, borrarlas, etc. En este caso, por ser un acercamiento a lo que es el funcionamiento de OPNET en general y al procesamiento en los routers de los AQM en particular,


139

no nos centraremos en esas funciones. En caso de querer añadir nuevos algoritmos de gestión Activa de Colas, habría que modificarlas, pues habría que añadir nuevas estructuras o ampliar las existentes, y luego llevar a cabo su inicialización y borrado, o acceder a la base de datos global para obtener y almacenar sus valores. También se debe tener en cuenta que hemos estudiado la implementación desde el punto de vista de la configuración de atributos QoS global, y no en el router de forma local, por lo que si se quiere extender la implementación al router, habría que modificar funciones a mayores . A continuación se cita una recopilación de todas las funciones examinadas para este proyecto

Fichero OPNET Función

ip_dispatch.pr.c

ip_dispatch_cleanup_and_create_child_processes

ip_rte_qos_informacion_process

ip_output_iface.pr.c

do_init

allocate_buffers enqueue_packet

output_iface_stats_register

qos_attribute_definer.pr.c

attr_def_fifo_profiles_info_parse attr_def_red_parameters_get

ip_qos_attr_def_support.ex.c

ip_rte_qos_attr_config_info

ip_rte_queuing_profiles_defaults_register

ip_qos_support.ex.c

ip_qos_sup_functions_register

ip_qos_queue_config_element_mem_alloc ip_qos_red_queue_params_mem_alloc ip_qos_red_class_params_mem_alloc

ip_qos_attribute_value_get ip_qos_packet_enqueue_test ip_qos_iface_info_process ip_qos_iface_attribute_sort ip_qos_policy_process

ip_qos_iface_profiles_create ip_qos_profiles_database_create ip_qos_local_profiles_memory_free ip_qos_iface_qos_info_destroy ip_qos_profile_dbase_access ip_qos_profile_dbase_add ip_qos_red_profile_get

ip_qos_red_profile_attach ip_qos_fifo_profile_get

Oms_Qm_Average_Queue_Size_Update

oms_qm_red_packet_drop oms_qm_red_vars_create


140

oms_qm.ex.c

oms_qm_red_variables_update oms_qm_red_variables_delete oms_qm_initialize_all_pools

oms_qm_support_queues_create oms_qm_support_queue_add

oms_qm_support_queue_remove

4.5 Esquema-resumen para la implementación de GRED

En los puntos 4.3 y 4.4 de este capítulo se ha explicado detalladamente qué pasos se han seguido para modificar el algoritmo RED proporcionado por OPNET. En este apartado se describen esos pasos de manera concisa y práctica, sin entrar en detalles teóricos, a modo de recordatorio o recopilación de lo contado hasta ahora.

4.5.1 Modificación de código en ficheros externos

Abrir mediante un editor de texto o código los ficheros nombrados a continuación

4.5.1.1 oms_qm.h

Se añade la constante: #define OMSC_GRED 3

Que servirá como identificador de la versión Gentle de RED a la hora de seleccionarlo como atributo en el nodo QoS.

4.5.1.2 oms_qm.ex.c

Se añade dentro de la función oms_qm_red_packet_drop el siguiente código if ((avge_queue_size >= min_threshold) && (avge_queue_size < max_threshold)) { … } else /* CODIGO AÑADIDO PARA IMPLEMENTACIÓN DE GRED */ { if ((red_status == OMSC_GRED) && (avge_queue_size >= max_threshold) && (avge_queue_size < max_threshold*2)) { /* Con GRED habilitado, el algoritmo varia su comportamiento cuando se excede el umbral máximo. En vez de descartar todos los paquetes directamente, varía la fórmula para que se aumente la probabilidad


141

desde maxp o probabilidad máxima hasta uno. */ maxp = 1.0 / mark_prob_denominator; dropping_probability = ((1.0-maxp)* (avge_queue_size- max_threshold))/max_threshold + maxp; random_number = op_dist_uniform (1.0); FRET ((Boolean) (random_number <= dropping_probability)); }

cuya función es evitar que se descarten paquetes cuando se ha sobrepasado el umbral máximo en RED .

4.5.2 Modificación del modelo de procesos ip_output_iface

• Desde el editor de proyectos, entrar en el modelo de nodos de uno de los router (doble clic sobre él).

• Entrar en el modelo de procesos del módulo ip (doble clic sobre el módulo).

• En el modelo de procesos ip_dispatch, acceder al menú File › Open Child Process Model… › ip_output_iface

• Ya en el editor de procesos de ip_output_iface.pr.c acceder a Function block.

• Se añade en la función output_iface_stats_register otra condición más para mostrar la estadística tamaño medio de cola de GRED:

static void output_iface_stats_register(OmsT_Qm_Queue_Pool* qpool_ptr, int q_index) { if (red_status == OMSC_RED) {…} … else if (red_status == OMSC_GRED) { /* CÓDIGO AÑADIDO */ /* Registrar estadísticas para GRED si está habilitado.*/ sprintf (new_name, "GRED Average Queue Size %s Q%d%s",intf_name, q_label, queue_category_str); dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "GRED Average Queue Size", stat_annotation_str, OPC_STAT_LOCAL); Oms_Dim_Stat_Rename (dim_stathandle, new_name); oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle); }…

• Guardar los cambios a partir del menú de la ventana de bloque de funciones, File › Commit.


142

• Compilar el modelo de proceso (es necesario este caso después de haber modificado el código), a partir del menú Compile del editor de procesos, o mediante el botón de acceso directo .

4.5.3. Modificación de atributos del nodo QoS

Una vez modificado el código, hay que permitir que el usuario seleccione el algoritmo. Para ello añadíamos una nueva opción en el árbol de atributos del nodo QoS de la siguiente manera:

• Acceder al modelo de nodos del nodo QoS (doble clic sobre el nodo en el editor de proyectos).

• Acceder al modelo de procesos del nodo, qos_attribute_definer.

• Acceder a la tabla de atributos a través del menú Interfaces › Model Attributes.

• Editar los atributos que van apareciendo en el siguiente orden

FIFO Profiles › Details › RED Parameters › RED Status

• Una vez seleccionado RED Status, pulsar el botón Edit Compound Attribute Properties.

• En la ventana que aparece (Attribute: RED Parameters), seleccionar en el campo Attribute properties Private para pasar a editar el atributo de forma privada. Pulsar OK.

• De vuelta en la ventana anterior, seleccionar de nuevo RED Status, pero esta vez pulsar en el botón Edit Properties.

• Aparece una nueva ventana, con un nuevo Symbol map. Añadir el nuevo valor GRED en el campo Symbol Map y asignarle el valor 3 (que es el que se ha asignado a la constante OMSC_GRED en oms_qm.h). Pulsar OK para volver a la ventana anterior.

• De nuevo en la ventana de los atributos de RED Parameters, volvemos a pulsar Edit Compound Attribute Properties. Ya en la ventana, volver al dominio público habilitando la casilla Public.

• 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.


143

Capítulo 5. Experimentos

5.1 Introducción

En este capítulo se muestran algunos de los experimentos realizados para este proyecto, tanto variando las topologías, como los AQM utilizados o los tipos de estadísticas recogidos.

5.2 Topologías utilizadas

Las topologías siguen todas el esquema llamado “cuello de botella” o bottleneck, consistente en nodos emisores que envían datos a través de conexiones rápidas, provocando que lleguen al router más datos de los que puede procesar, desembocando en la correspondiente congestión de red. La clave para ello está en que la conexión entre los routers sea sensiblemente más lenta que el resto de las conexiones de la red. En los siguientes puntos se detallarán todas las topologías utilizadas para realizar los experimentos de este proyecto.

5.2.1 CuelloBotella

Es la topología ya conocida utilizada para describir el modelado en el modelo de redes mediante el editor de proyectos en el capítulo 4, y la más sencilla de las utilizadas en éste proyecto. Consta, como se ha indicado anteriormente, de cinco fuentes TCP denominadas ClienteN y cinco fuentes receptoras denominadas ServidorN, además de dos routers, dos switch y tres nodos de configuración de parámetros globales (parámetros del tipo de aplicación, perfiles de los nodos y configuración de parámetros de Calidad de Servicio o QoS). Las conexiones entre los nodos emisores/receptores y los switchs, y entre éstos y los routers es de tipo 10BaseT, es decir, una conexión rápida que asegure que todos los datos son enviados sin problema, y el tiempo de procesamiento en los switch despreciable, para evitar congestión y


144

pérdida de paquetes ya en ellos. La conexión entre los dos routers elegida es T1, mucho más lenta (1.42 Mb), con lo que la congestión está asegurada.

5.2.1.1 Escenarios

El proyecto CuelloBotella consta de tres escenarios, en los que la topología es la misma pero varía el tipo de AQM utilizado:

• DT: se emplea Drop Tail, configurado por defecto en el router. • RED: se emplea el AQM Random Early Detection o RED como mecanismo de

control de congestión. • GRED: se emplea la versión Gentle-RED como mecanismo de control de

congestión, AQM añadido a OPNET.

Ilustración 70. Topología CuelloBotella


145

5.2.2 CuelloBotella2

En esta topología se aumenta la complejidad y la carga de tráfico en la red aumentando el número de nodos de la red, tanto fuentes emisoras como receptoras. El tráfico sigue siendo íntegramente de tipo TCP. Ahora, el número de clientes asciende a catorce, al igual que el número de servidores.

5.2.2.1 Escenarios

Como en el anterior caso, CuelloBotella2 consta de tres escenarios: DT, RED y GRED, llamados así por el tipo de AQM configurado en sus routers.

Ilustración 71. Topología CuelloBotella2


146

5.3 Reglas de ajuste de parámetros de RED

Como se ha dicho anteriormente, uno de los mayores problemas de utilizar el algoritmo RED es configurar sus parámetros, ya que este algoritmo es extremadamente sensible a ellos. De hecho, una mala configuración de parámetros puede provocar que se obtengan resultados peores que aplicando el algoritmo por defecto, Drop Tail. Cuando Floyd y Jacobson presentaron en 1993 el algoritmo RED [5], proporcionaron ciertas pautas para la configuración de esos parámetros, que si bien no son muy aclaratorias, permiten al usuario tener una base para “tantear” cual puede ser el rango de valores más adecuado para cada parámetro en situaciones concretas. A continuación se exponen ideas obtenidas de dicho documento.

5.3.1 Configuración de los parámetros en general

No hay reglas estrictas para hallar valores óptimos, éstos dependen de varios factores incluyendo no sólo la velocidad del enlace o retardo de propagación, si no también las características del tráfico, por ejemplo. Un factor a tener en cuenta en general es cuántos paquetes pueden llegar a la cola durante la duración de un RTT medio (si hubiera tal cosa). Para situaciones de congestión que duran menos que RTT, el comportamiento ideal sería que la cola tuviera un tamaño suficiente para absorver dicha congestión sin descartar paquetes. Si la congestión dura más que RTT, el comportamiento ideal sería que la cola reflejara ésta congestión, avisando a los nodos emisores.

5.3.2 Umbral Mínimo

La configuración optima de Min_th se debe hacer con la idea de mantener un equilibrio entre conseguir un tiempo de espera bajo en el enlace y una utilización alta de su capacidad. Cuanto más intenso sea el tráfico de llegada, mayor debe ser Min_th para conseguir una utilización del enlace adecuada. Si éste valor fuera demasiado bajo, el router no soportaría ráfagas de datos. Además se debe tener en cuenta también la velocidad del link, el retardo de propagación y el tamaño máximo del buffer. Por ejemplo, hay que observar si el retraso en la cola es trivial con respecto al retardo de propagación a través del enlace. Eso es señal de que el parámetro está bien configurado. En caso contrario, habría que aumentar el valor de Min_th.

5.3.3 Umbral Máximo


147

En el documento se dice que Max_th debe ser como mínimo dos veces Min_th. Según otras fuentes, lo más aconsejable es de hecho asignar Max_th = 3*Min_th.

5.3.4 Exponential Weight Factor (wq)

Se recomienda establecer wq como mínimo a 0.001. La elección de este parámetro determina la “constante de tiempo” de muestreo del parámetro Average Queue Size. Si es demasiado bajo, RED tendrá una respuesta demasiado baja a las situaciones de congestión. Por el contrario, si es demasiado alta, puede oscilar demasiado, asemejándose demasiado al tamaño real de la cola. En OPNET, no damos el valor de wq directamente, si no otro parámetro, que se usa en la función Oms_Qm_Average_Queue_Size_Update para calcular el tamaño medio de cola cada vez que llega un paquete al sistema. El propio OPNET nos sugiere por defecto que tal valor sea 9, pero también se permiten los valores 1, 5, o un valor que el usuario edite.

5.3.5 Probabilidad Máxima

No se especifica mucho acerca del valor que debe tomar Max_p. Las simulaciones descritas en el artículo establecen max_p a 0.02, pero según algunos usuarios, es más aconsejable establecer su valor a 0.1. Esto traducido a la forma de configurar los parámetros en OPNET, equivaldría a establecer el parámetro Mark Probability Denominator a 10, ya que éste parámetro, en la función oms_qm_red_packet_drop a dividirá a uno, como ya hemos visto en el anterior capítulo. Así, 1/10=0.1.

5.3.6 Ajuste de parámetros GRED

En general, todo lo dicho para el AQM RED se puede aplicar para la configuración de los parámetros del algoritmo GRED. GRED y RED obtienen unos resultados similares, pero se puede decir que GRED va a ser un algoritmo más robusto y se va a comportar mejor que RED en situaciones en las que el ajuste de los parámetros no es tan bueno. Según el artículo [3] de la bibliografía, hay una fuerte relación lineal entre los parámetros umbral mínimo, máximo o probabilidad máxima y el tamaño medio de cola. Ya que tanto GRED como RED no descartan paquetes hasta que se sobrepasa el umbral mínimo, el valor mínimo del tamaño de cola medio estará precisamente determinado por ese umbral. En general, para evitar desbordamiento o desaprovechamiento del buffer, sería adecuado que se estabilizara el tamaño medio de cola en torno a un valor apropiado. Para conseguir esto, el umbral mínimo debe estar configurado de forma que se evite el mal aprovechamiento, es decir, que no se comiencen a descartar paquetes cuando la carga de tráfico no es muy alta.Así mismo, el umbral


148

máximo y la probabilidad de descarte máxima deberán tener un valor adecuado para evitar el desbordamiento. Si se comparan los resultados obtenidos con RED y con GRED se puede observar que en RED, el umbral máximo es el que tiene mayor impacto sobre el tamaño de cola. Sin embargo, en GRED es el umbral mínimo. Esto es porque GRED mejora el problema que tenía su antecesor al incrementar a uno la probabilidad de descarte cuando se alcanzaba el umbral máximo.

5.4 Resultados con la topología CuelloBotella

5.4.1 Especificación de parámetros para los experimentos

5.4.1.1 Nodo Aplicaciones:

Aplicación Inter-Request Time (secs)

File Size

FTP exponential(100) 500000B

5.4.1.2 Nodo Perfiles

Ajuste de Aplicación_FTP Offset Duration (secs) Inter-Rep. Time

(secs) Number of Repetitions

Pattern

No constant(400) constant(50) Ilimitada Serial

Ajuste de Perfil_FTP Operation Mode stara

Time Duration Inter-Rep.

Time Number of Reps

Pattern

Simultaneous const(0.5) End of Simulation

const(50) const(4) Concurrent

5.4.1.3 Nodo QoS

Este cuadro, como los anteriores, resume las características configuradas para todos los escenarios que se simulan. El parámetro Buffer Size se aplica en los todos, pero el resto de parámetros de esta tabla sólo se aplicarán a los escenarios de simulación de los AQM RED y GRED.


149

Experimento Buffer Size (pkts)

Max_th (pkts)

Min_th (pkts)

Mark Prob. Denominator

Exp. Weight Factor

E1 100 15 5 10 9 E2 60 15 5 10 9 E3 60 15 5 40 9 E4 60 15 5 40 12

Los parámetros han sido elegidos en relación al documento original de los creadores del algoritmo RED, y se han ido variando para cada experimento intentando mostrar un poco los efectos que cada parámetro causa tanto en RED como en GRED.

5.4.1.4 Otros parámetros

Se ha utilizado dos tipos de enlaces en esta topología. El enlace entre los routers debe ser lento en relación al resto de enlaces de la red para provocar la situación de cuello de botella. Para tal función el enlace elegido es T1 (1.544Mb/sec), asignándole un retardo de propagación de 0.008 segundos. Para el resto de los enlaces, entre los nodos emisores/receptores y los switch, y entre los switch y los routers, los enlaces son de 10BaseT, con un retardo de propagación de 0.001 segundos. Tanto las fuentes emisoras como las receptoras utilizan el protocolo TCP, configurado a la versión Tahoe, como indica en el documento [5] que utilizan para sus experimentos. La duración de la simulación es de 3000 segundos, para dar tiempo a la red a adaptarse al tráfico, y se vea su funcionamiento de forma estable. En los siguientes apartados se muestran las gráficas con los resultados obtenidos tras la simulación de la topología CuelloBotella tras configurarse como se indica en los cuatro experimentos.


150

5.4.2 Gráficas

5.4.2.1 Tráfico descartado globalmente

DT en azul, RED en verde, GRED en rojo.

Ilustración 72. E1 y E2. Tráfico descartado en la red.

En la primera gráfica, que corresponde al experimento con tamaño de buffer 100, tal y como se han configurado los parámetros se ve que la línea roja (GRED) es la que se encuentra por debajo en todo momento, es decir, ese escenario es el que menos descartes produce.


151

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.


Ilustración 73. E3, E4. Tráfico descartado en la red.


152

El tercer experimento, basado en el segundo, cambia sólo maxp, pasando de 10 (se descartan uno de cada diez paquetes) a 40 (uno de cada cuarenta). Al descartar menos paquetes, tanto RED como GRED alcanzan antes el umbral máximo, con lo que llegado este punto la tasa de descartes se eleva en RED de manera visible con respecto a los otros dos escenarios, llegando al valor 40. Sin embargo GRED vuelve a igualarse en descarte a Drop Tail. La última gráfica muestra cómo afecta la modificación del parámetro wq, o lo que es lo mismo, el intervalo de muestreo del tamaño medio de cola. Aumentar el valor de 9 a 12 provoca que se descarten menos paquetes, no llegando a alcanzar 28 para el caso de RED o 18 en el caso de GRED. Sin embargo, para otras estadísticas el resultado no será tan bueno.

5.4.2.2 Retardo global de la red


Ilustración 74. E1, E2. Valores medios del retardo en la red.


153

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.


Ilustración 75.E3, E4. Valores medios del retardo en la red.

RED sin embargo es más dedependiente de la configuración de los parámetros. El escenario en el que más retardo hay es el tercero, E3, porque al efectuar un descarte menos agresivo de paquetes, llega un momento en que se satura y dispara su tasa de descartes, descartando todos los paquetes que llegan al router, lo cual contribuye a aumentar el retardo global.


154

5.4.2.3 Utilización del buffer en Router1


Ilustración 76. E1, E2. Utilización del buffer en Router1.

En los cuatro experimentos se observa que para Drop Tail el buffer se llena momentos después de comenzar la simulación, manteniedo ese nivel hasta el final de la misma. Para RED y GRED, se consigue mantener en un nivel de utilización bastante más bajo, debido al descarte temprano, disminuyendo el retardo que lo paquetes experimentan. Observar que la cola se mantiene en un tamaño cercano a 30 paquetes independientemente del tamaño del buffer (100 en E1, 60 en el resto). Por la gráfica del escenario E3 (siguiente página), vemos que el hecho de disminuir la agresividad en el descarte de paquetes no va a influír mucho en estos resultados, debido a los umbrales máximo y mínimo, manteniéndose alrededor de 30 paquetes en todo momento.


155

Ilustración 77 E3, E4. Utilización del buffer en Router1.

El parámetro que sí que influye más en estos resultados es wq, como se ve en el cuarto experimento, E4. Se puede ver que la utilización del buffer va a crecer tanto para RED, que se mantiene en torno al valor 45 (un valor demasiado alto, que no deja margen para absorber ráfagas de tráfico), como para GRED sobretodo, que alcanza picos de utilización mayores, y experimenta gran inestabilidad en el tamaño de cola. La gráfica obtenida para el cuarto experimento demuestra que no es bueno disminuir el intervalo de muestreo en situaciones de este tipo, en que el tráfico es tan inestable (recordar de estamos ante una distribución exponencial del tráfico), puesto que tanto GRED como RED no van a comportarse como deben.


156

5.4.2.4 Variación en el retardo o jitter en Router1

DT en azul, RED en verde, GRED en rojo

Ilustración 78. E1, E2. Jitter en Router1, valores medios.

En el primer eexperimento es donde mejores resultados se obtienen, habiendo un nivel de jitter mucho menor en los escenarios controlados por AQM que en el controlado por Drop Tail. Este último siempre sigue el mismo patrón de comportamiento: primero tiene un pico en la gráfica, correspondiente a los primeros instantes de simulación en los que el buffer está vacío y pasa a estar lleno, punto en el que se mantiene hasta el final de la simulación, con lo que el valor medio desciende hasta quedarse, en algunos casos, por debajo del de RED y GRED. En otras situaciones de tráfico, se podría observar un nivel alto de jitter debido al efecto de sincronización global creado por Drop Tail.


157

Ilustración 79.E3, E4. Jitter en Router1, valores medios.

En el caso de RED y GRED, la variación en el retardo o jitter conserva un valor más estable en los cuatro experimentos. El experimento en el que peores resultados se obtinen es el cuarto, en el que como se ha visto en el anterior apartado los valores alcanzados por GRED y GRED eran más parecidos a Drop Tail en cuanto a la ocupación del buffer. Además, había más oscilaciones, de ahí que aumente el nivel de jitter.


158

5.4.2.5 Retardo en Router1 o Delay


Ilustración 80. E1, E2. Retardo en Router1, valores medios.

En los cuatro experimentos el escenario en el que más retardo sufren los paquetes que llegan a Router1 es Drop Tail. El retardo está muy por encima del experimentado con RED y GRED. Este retardo tiene relacion directa con la ocupación del buffer, que es mucho mayor en el caso de Drop Tail. De hecho, el experimento en el que más retardo hay es en el primero, es decir, el que tiene un buffer con mayor capacidad, por lo tanto, un paquete tardará más en ser procesado, porque tiene más paquetes esperando delante en todo momento.


159

Ilustración 81. E3, E4. Retardo en Router1, valores medios.

Se observa que dentro de los dos escenarios en los que se utiliza AQM, el que mejores resultados muestra para todos los experimentos es GRED, teniendo siempre un valor muy similar o inferior, independientemente de la configuración de los parámetros. Cabe destacar que el experimento en el que más retardo sufren estos dos escenarios es el cuarto, en el que se veía anteriormente que subía la utilización del buffer del router. En esa situación es en la que más se nota la mejora de GRED con respecto a RED, y su fiabilidad ante el cambio de la configuración de parámetros.


160

5.4.2.6 Comparación entre RED y GRED

Ilustración 82. E1, E2. Tamaño de cola medio con el algoritmo RED (rojo) y GRED (azul).

Aquí se muestra una comparación entre el parámetro Tamaño medio de cola de los dos algoritmos. Es la gráfica más útil para comprobar cómo se comportan ambos, sus semejanzas y diferencias. En las cuatro gráficas, excepto la correspondiente al cuarto experimento (en el que varía wq), el tamaño de cola medio es igual para los dos escenarios al principio, pero luego (cuando se alcanzan valores próximos al umbral máximo) se separan, conservando un valor mayor para GRED que para RED. Esto es por la política de descarte de ambos algoritmos, en la cual, como se ha descrito anteriormente, si se llega al umbral máximo, RED descarta los paquetes con probabilidad 1, y GRED lo suaviza aumentando la probabilidad de descarte de manera lineal hasta uno, con lo que es menos probable que se descarten paquetes.


161

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.


162

5.4.2.7 Utilización del enlace entre Router1 y Router2


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.


163

Ilustración 85. E3, E4. Utilización del enlace entre los routers. El experimento en el que peores resultados se observan es en el cuarto, en el caso del escenario GRED, en el que la inestabilidad del tamaño de cola medio y por tanto la ocupación del buffer provoca picos de baja utilización, aunque en el resto de ls momentos sea casi igual a la utilización obtenida con el escenario Drop Tail. En este experimento se debe resaltar también que RED es el escenario que permanece más estable


164

5.5 Resultados con la topología CuelloBotella2

5.5.1 Especificación de parámetros para los experimentos

5.5.1.1 Nodo Aplicaciones:

Aplicación Inter-Request Time (secs)

File Size

FTP exponential(100) 500000B

5.5.1.2 Nodo Perfiles

Ajuste de Aplicación_FTP Offset Duration (secs) Inter-Rep. Time

(secs) Number of Repetitions

Pattern

No constant(400) constant(50) Ilimitada Serial

Ajuste de Perfil_FTP Operation Mode stara

Time Duration Inter-Rep.

Time Number of Reps

Pattern

Simultaneous const(0.5) End of Simulation

const(50) const(4) Concurrent

5.5.1.3 Nodo QoS

Experimento Buffer Size

(pkts) Max_th (pkts)

Min_th (pkts)

Mark Prob. Denominator

Exp. Weight Factor

E5 100 15 5 10 9

El resto de parámetros está configurado como la topología CuelloBotella: Capacidad del enlace entre routers: T1 (1.544Mb/sec). Retardo: 0.008 segundos. Capacidad del resto de los enlaces: 10Mb/sec. Retardo: 0.001 segundo. TCP: Tahoe A continuación se muestra uno de los experimentos realizados con la topología CuelloBotella2, en la que, como se ven los parámetros arriba expuestos, sólo varía el número de nodos de la red. El tráfico enviado por cada nodo emisor será el mismo, lo que provoca que Router1 esté más saturado, y se experimente más congestión en la red. Concretamente, en las siguientes gráficas se muestra la comparación de tráfico registrado a la entrada del router para ambas topologías:


165

Ilustración 86. Tráfico registrado para CuelloBotella y CuelloBotella2

En la primera de las gráficas se muestra el tráfico obtenido para el escenario Drop Tail en ambas topologías: CuelloBotella corresponde con la línea azul y CuelloBotella2 con la roja. Como se ve, en ambos casos se supera el tamaño del buffer del router (100 paquetes), llegando a alcanzar para la segunda topología más del doble del tamaño, 220. La segunda gráfica corresponde a la misma comparación para el escenario GRED, que es parecido a lo que ocurre con RED, pero que no se muestra en este caso. Se ve que en la primera topología se controla que llegue menos tráfico al router, manteniendose éste entre los 160 y 180 paquetes. Sin embargo, en la segunda topología (línea roja), el tráfico se desborda, superando los 260 paquetes. A continuación vemos como repercute esto en los resultados, y la necesidad de reconfigurar los parámetros RED y GRED.


166

5.5.2 Gráficas

5.5.2.1 Tráfico descartado globalmente

(GRED en rojo, Drop Tail en azul, RED en verde)

Ilustración 87. E5, Retardo global para la topología CuelloBotella2

Como se ve, en el escenario E5, los resultados han variado mucho con respecto a lo obtenido en E1. RED es el escenario que más paquetes descarta, seguido de GRED. Drop tail descarta muchos menos paquetes y de manera constante. Esto demuestra que los parámetros RED no están bien configurados para la situación de tráfico actual.

5.5.2.2 Retardo global en la red

Ilustración 88. E5, Retardo global en la red, valores medios.


167

Como se ve en la gráfica, para el escenario E5, el escenario que más retardo tiene se GRED, aunque los tres escenarios tienen un retardo similar.

5.5.2.3 Utilización del buffer en Router1

Ilustración 89. E5, Utilización del buffer en el Router1.

Debido a la implementación tanto de GRED como RED, se puede apreciar, como pasaba con la anterior topología, que la cola del router se llena mucho menos que para Drop Tail, provocando menos retardo en el router.

5.5.2.4 Retardo en Router1

Ilustración 90. E5, Retardo en el Router1, valores medios.


168

El retardo en el buffer va asociado a la ocupación. Como en la gráfica anterior, en este caso, hay mucho más retardo en el escenario Drop Tail que en RED y GRED, porque al estar el buffer más lleno, los paquetes permanecen más tiempo en la cola antes de ser procesados.

5.5.2.5 Comparación entre RED y GRED

Ilustración 91. Tamaño medio de cola de GRED (azul) y RED (rojo)

Como se ha visto en otros experimentos, el tamaño de cola medio es más alto para GRED que para RED, ya que este último descarta paquetes de forma más agresiva.

5.5.2.6 Utilización del enlace entre Router1 y Router2

Ilustración 92. E5, Utilización del enlace

Aunque la utilización del buffer sea mucho más baja para los escenarios GRED y RED, no afecta a la utilización del enlace, siendo muy parecida a la obtenida por Drop Tail.


169

Capítulo 6: Conclusiones y líneas futuras

6.1 Conclusiones

En esta memoria primero se ha presentado de forma general los mecanismos que garantizan Calidad de Servicio en las redes de ordenadores y su ámbito de funcionamiento. Entre ellos se ha mencionado la necesidad de algoritmos de gestión activa de colas como RED para evitar efectos indeseables derivados de la congestión de redes como son la sincronización global, el alto jitter, o la pérdida excesiva de paquetes. En el tercer capítulo se ha descrito detalladamente aspectos del simulador OPNET tales como el funcionamiento de los modelos de nodos y procesos, o cómo se lleva a cabo la simulación de eventos discretos. Otra parte que ha ocupado mucho tiempo en este proyecto (y espacio en la memoria) ha sido el estudio del nivel de modelado más bajo en el simulador, es decir, tanto los modelos de proceso que describen el comportamiento de los componentes del simulador, como las librerías con el código fuente que complementan la funcionalidad que por cualquier motivo no estuviera incluida en los modelos de proceso (por ejemplo, por cuestiones de utilidad o reutilización). Mediante este estudio se ha comprendido cómo se modelan en OPNET cuestiones como la calidad de servicio o el control de congestión. Al final, se han presentado los resultados de las simulaciones para distintas situaciones y topologías. Con esos resultados, se ha comprobado que la configuración de los algoritmos RED y GRED no es intuitiva. Se debe tener en cuenta muchas situaciones como son el tráfico de la red, el tipo de tráfico, la naturaleza y duración de las posibles ráfagas, los retardos en la red, etc. Se ha visto que en líneas generales, el algoritmo GRED se comporta mejor, obteniendo una menor tasa de descartes y un menor retardo global. Uno de los problemas que se ha visto es que el parámetro tamaño medio de cola tiende a oscilar, sobre todo ante cambios de configuración de wq y del umbral mínimo, por lo que se debe tener cuidado al configurarlo. En general, además de todo lo dicho en este apartado, se ha podido comprobar que OPNET es una herramienta muy potente y puede ser extremadamente útil para modelar redes de ordenadores y entornos de comunicación a nivel profesional. Puede tener mucha utilidad también a nivel académico, para ilustrar temas relacionados con redes y protocolos, debido a lo intuitivo de su interfaz gráfica, si se han descrito los pasos a seguir previamente por medio de un tutorial al estilo a lo que se ha hecho en esta memoria.

Capítulo 6.Conclusiones y líneas futuras

170

6.2 Posibles Ampliaciones

A medida que este proyecto ha ido avanzando, se ha pensado en distintas líneas de investigación que se podrían seguir a partir de los expuesto aquí. Una de las propuestas que quedan pendientes es exportar el uso de GRED a otras disciplinas de cola como PQ, WFQ, LLQ, … puesto que tal y como está implementado el algoritmo es sólo configurable para su uso con FIFO. Pendiente queda también hacer simulaciones con tráfico de distinta índole, como UDP, y ver cómo se comporta el algoritmo cuando hay flujos de tráfico con más peso que otros (simulacines tipo elefante-ratón). Una vez demostrado que se ha podido modificar el código para añadir la versión de RED, Gentle RED, otra de las ideas que se proponían es modificar la forma en que RED trabaja, dando al usuario la posibilidad de actualizar el tamaño medio de cola cada cierto tiempo (definido mediante un intervalo de muestreo) en vez de actualizarlo por cada paquete que llega, como es el caso actualmente. En el Anexo D se explican unas pautas iniciales para realizar esta modificación. Otra de las ampliaciones que se proponen es estudiar el algoritmo GRED y compararlo con RED utilizando otras topologías, como pueden ser cuellos de botella más complejos, con mayor tráfico y número de fuentes TCP, y también mayor número de routers, creando cruces de tráfico de distintas características.


171

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. [6] V. Hnatyshin, G. Gramatges, M. Stiefel. Rowan University, Department of Computer Science,

Glassboro, NJ. “Practical Considerations for Extending Network Layer Models with OPNET Modeler”. The 18th IASTED International Conference on Modelling and Simulation. Montreal, Quebec, Canada. Symposium signal processing and intelligent systems. Year of Publication: 2007

[7] G. Iannaccone, C. Brandauer, T. Ziegler, C. Diot, S. Fdida y M. May, “Comparison of tail drop

and active queue management performance for bulk-data and web-like internet traffic”. Proceedings of the Sixth IEEE Symposium on Computers and Communications, page: 122. July 2001

[8] D. Mitchell, J. Yeung. “Implementation of Start-Time Fair Queuing Algorithm in Opnet™”.

Ensc835, School of Engineering Service, Simon Fraser University, April 2002. [9] K. Ramakrishnan, S. Floyd, D. Black. “The Addition of Explicit Congestion Notification (ECN)

to IP”.RFC 3168. Sept. 2001. [10] E. Tsolakou, I. S. Venieris. National Technical University of Athens, Telecommunications

Laboratory. Department of Electrical and Computer Engineering. “Implementation of Traffic Conditioning and PHB mechanisms in OPNET”. International conference on advances in communication and control No8 , GRECE 2002 , pp. 197-207

Bibliografía

172

[11] B. Van den Broeck, P. Leys, J. Potemans1, J. Theunis, E. Van Lil, A. Van de Capelle. Katholieke Universiteit Leuven, Department of Electrical Engineering. “Validation of Router Models in OPNET” . OPNETWORK 2002, Washington D.C., USA, 2002.

[12] J. Wang, K. Nahrstedt and Y. Zhou, “Design and Implementation of DiffServ Routers in

OPNET”. Proceedings of OPNETWORK 2000, Washington D.C., Aug 28 - Sep. 1, 2000. [13] K. Wu, Y. Ma, L. Trajkovic, Simon Fraser UniversityBurnaby, British Columbia, Canada. “OPNET Implementation of Endpoint Admission Control Algorithms”. OPNETWORK 2003,

Washington, DC, Aug. 2003 [14] C. Zhu, O. W.W. Yang, J. Aweya, M. Ouellette, Delfin Y. Montuno. Ottawa, Ontario, Canada.

“A Comparison of Active Queue Management Algorithms Using OPNET Modeler”. Communications Magazine, IEEE. Vol. 40, Issue 6, pp. 158-167. Jun 2002.

B. Páginas Web

[1] A Hybrid Systems Modeling Framework for Communication Network http://www-rcf.usc.edu/~junsool/hybrid/. Último acceso: 30/11/2009 [2] Cisco Systems. Cisco Packet Tracer.

www.cisco.com/web/learning/netacad/course_catalog/PacketTracer.html. Último acceso: 18/12/09

[3] Control de Congestión www.it.uc3m.es/~prometeo/rsc/apuntes/Conges/conges.html#1.3.2%20Control%20de%20con

gesti%C3%B3n. Último acceso: 13/5/2009 [4] D. Erman. “M/M/1 simulation in OpNET”. www.its.bth.se/courses/etd012/slides/OpNET_mm1.sxi.pdf. Último acceso: 27/08/2009. [5] Establecimiento Conexión TCP. http://seguridadyredes.nireblog.com/ Seguridad y redes. Último acceso: 30/11/09 [6] Protocolo TCP http://www.tesisenxarxa.net/TESIS_UPC/AVAILABLE/TDX-1222106-

164746//04AMCA04de15.pdf Último acceso 27/11/09. [7] Mejores Simuladores de Redes

http://www.taringa.net/posts/downloads/1047902/Mejores-Simuladores-de-Redes.html Último acceso 18/12/09

[8] OPNET Modeler Documentation Set. Version: 14.5. 2008


173

Glosario

ACK: Acknowledgement, señal emitida por el host receptor como reconocimiento al recibir un segmento de datos de parte del host transmisor. AQM: Active Queue Management, Gestión Activa de Colas Buffer: area de almacenamiento utilizada para manejar datos en tránsito. Los buffers se usan en las redes para compensar las diferencias en velocidad de procesamiento entre dispositivos de red. Son útiles sobre todo para almacenar ráfagas de datos. CAR: Committed Access Rate algorithm. Cola: Reserva de paquetes que esperan ser enviados por una interfaz de router. Control de flujo: Técnica que permite sincronizar el envío de información entre dos entidades que producen/procesan información a distintas velocidades. Es una más de las técnicas para combatir la congestión. Se consigue con ella parar a aquellas fuentes que vierten a la red un tráfico excesivo. DiffServ: Differentiated Service, Servicio Diferenciado. Método para proveer QoS Con un coste bajo. ECN: Explicit Congestion Notification. FB: Function Block, Bloque de Funciones. FTP: File Transfer Protocol. Protocolo de transferencia de archivos. Protocolo utilizado para la transferencia de archivos en la red. HB: Header Block, Bloque de Cabecera. IP: Internet Protocol. Protocolo del nivel de red que ofrece un servicio no orientado a conexión. IP brinda funciones de direccionamiento, especificación del tipo de servicio, fragmentación y reensamblaje, y seguridad. KP: Kernel Procedures. Conjunto de procedimientos proporcionados por OPNET para realizar funciones específicas relacionadas con el tratamiento de datos en el modelado de una red. MSS: Maximum Segment Size. Tamaño máximo de segmento para el protocolo TCP.

Glosario

174

Paquete: agrupación lógica de información que incluye un encabezado que contiene la información de control y (generalmente) los datos de usuario. El término “paquete” se usa con frecuencia para referirse a las unidades de datos en la capa de red. QoS: Quality of Service, Calidad de Servicio. Es la capacidad de asignar diferentes prioridades a diferentes aplicaciones, flujos de datos, usuarios, o garantizar un cierto nivel de eficiencia a un flujo de datos. Si no hay congestión en la red, no se necesita QoS. “Best Effort” es el nivel QoS por defecto. RED: Random Early Detection, algoritmo de gestión activa de colas basado en el seguimiento del tamaño medio de cola para asignar una probabilidad de descarte a cada paquete que llega al router. Red: agprupación de varios nodos como pueden ser ordenadores, impresoras, routers, switches y otros dispositivos que se pueden comunicar entre sí a través de un medio de transmisión. Router: es un dispositivo de interconexión de redes de ordenadores que opera en el nivel de red. Permite asegurar el enrutamiento de paquetes entre redes o determinar la ruta que debe tomar el paquete de datos. Además de enrutar, los routers también se utilizan para manipular los datos que circulan en forma de datagramas, para que puedan pasar de un tipo de red a otra. Como no todas las redes pueden manejar el mismo tamaño de paquetes de datos, los routers deben fragmentar los paquetes de datos para que puedan viajar libremente. RSVP: ReSource ReserVation Protocol. RTO: Retransmission Timeout, Contador de retransmisión. RTT: Round Trip Delay Time. Tiempo que tarda un paquete desde un emisor en volver a éste mismo emisor habiendo pasado por el receptor de destino. SMTP: Simple Mail Transfer Protocol, Protocolo Simple de Transferencia de Correo. STD: State Transition Diagram, Diagrama de Transición de estado TCP: Transmission Control Protocol, protocolo para el control de la transmisión. Protocolo de la capa de transporte orientado a conexión que proporciona una transmisión fiable de datos. ToS: Type of Service. Es un byte ubicado en la cabecera de los datagramas IP. Usado por los routers para elegir el destino de cada paquete. Proporciona QoS. En Opnet, éste byte se utiliza para ver qué paquetes de datos tienen mayor probabilidad para ser descartados. (in-profile Vs. out-of-profile). UDP: Protocolo de datagrama de usuario. Es un protocolo no orientado a conexión de la capa de transporte. Intercambia datagramas sin acuse de recibo o garantía de entrega y requiere que el procesamiento y retransmisión de errores sea manejado por otros protocolos.


175

Anexo A. Contenido del CD

En el CD adjunto se encuentras los siguientes archivos:

• Memoria.pdf: Memoria del proyecto en formato PDF. • oms_qm.h: fichero de cabecera o librería de OPNET modificada. • oms_qm.ex.c: fichero externo de datos de OPNET con la versión GRED añadida. • ip_output_iface.pr.c: modelo de proceso de OPNET modificado. • RED_parameters2.ad: fichero de propiedades del árbol de atributos RED

Parameters con GRED añadido en el Symbol map. • CuelloBotella.project, CuelloBotella2.project: Topologías utilizadas para los

experimentos mostrados en esta memoria.

Para obtener los ficheros del programa OPNET (no incluidos en este CD), entrar en la página web www.OPNET.com e informarse sobre las distintas versiones que la empresa ofrece de su aplicación. Para más información, también se puede acudir al apartado 4.1.2 Obtención de Licencias de este documento.


177

Anexo B. Guia para integrar el algoritmo GRED en OPNET

En este anexo se explica cómo utilizar los ficheros que contiene el CD para conseguir utilizar eficazmente el algoritmo presentado en este proyecto.

1. Obtener las licencias en la página web de OPNET e instalar el programa a partir de los tres ficheros que la empresa proporciona.

Tras la instalación, se puede comprobar que se habrá creado en el disco duro del ordenador varias carpetas. Entre ellas:

• Una carpeta para los proyectos creados por el usuario, denominada por defecto op_models.

• Una carpeta en el directorio Archivos de programa, llamada OPNET y que contiene todos los ficheros relacionados con la implementación de los modelos existentes en OPNET como los ficheros de tipo .ex.c, modelos de proceso (extensión .pr.c), archivos relacionados con la gestión de licencias, y varias cosas más.

2. Copiar las dos carpetas CuelloBotella y CuelloBotella2 en el directorio op_models. De

esta forma, podemos acceder a los proyectos que contienen directamente desde el editor.

• 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:

3. Sobreescribir las librerías existentes por las proporcionadas en el CD en las siguientes

carpetas:

• oms_qm.h: se encuentra en la carpeta OPNET\models\std\include. • oms_qm.ex.c: en la carpeta OPNET\models\std\utilities\oms. • ip_output_iface.pr.c: sobrescribir en la carpeta OPNET\models\std\ip.

Anexo B. Guia para integrar el algoritmo GRED en OPNET

178

• RED_parameters2.ad: copiar en la carpeta OPNET\models\std\ip y cargarlo desde el editor de procesos como se ha explicado en el capítulo 4, apartado 4.3.4 Modificación de atributos.

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:

FIFO Profiles › Details › RED Parameters › RED Status

la opción GRED Enabled.


179

Anexo C. Estructuras y variables importantes

En esta sección se muestran las estructuras más importantes que intervienen en la implementación de algoritmos AQM en el simulador OPNET. Se han podido ir viendo en los extractos de código mostrados en el Capítulo 4, mientras se explicaban las funciones paso a paso hasta llegar a la implementación de RED y GRED. El estudio de éstas estructuras es esencial a la hora de comprender las funciones citadas anteriormente. Las estructuras están ordenadas según el archivo a que pertenecen. Se mostrarán en subapartados. Tener en cuenta que aquí no se muestran todas, ni todos sus argumentos, sólo las partes que se han considerado más relevantes. Dentro de cada estructura se muestran resaltados las variables o estructuras relevantes.

C.1 iq_qos_support.h

• Definición de tipos enumerados para asignar mecanismos QoS como disciplinas de planificación, AQM, etc.:

typedef enum { IpC_QoS_Unknown = -1, IpC_QoS_Custom_Queuing = 1, IpC_QoS_Dropping = 2, IpC_QoS_DWFQ_Class_Based = 3, IpC_QoS_DWRR = 4, IpC_QoS_FIFO = 5, … IpC_QoS_RED = 12, IpC_QoS_Traffic_Class = 13, IpC_QoS_Traffic_Policy = 14,IpC_QoS_In_Traffic_Policy = 15, … IpC_QoS_Max_Scheme_Type = 20 } IpT_QoS_Scheme_Type;

• Enumeración correspondiente a los distintos esquemas de disciplina de cola: typedef enum { IpC_No_Queuing = 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,


180

… IpC_Max_Queuing_Scheme } IpT_Queuing_Scheme;

• Estructura para los distintos tipos de políticas de clasificación dentro de una cola (RED, CAR,

etc). No utilizada en el ámbito en que hemos desarrollado este proyecto, pero se debe conocer: typedef struct { char * policy_name; List scheduling_info_list; List red_info_list; … IpT_QoS_Scheme_Type scheduling_type; }IpT_QoS_Policy_Info;

• Estructura que contiene otras que serán importantes a la hora de procesar información QoS: typedef struct { char * profile_name; List * policy_list_ptr; IpT_QoS_Scheme_Type type; }IpT_QoS_Mechanism_Info;

• La siguiente estructura guarda información que será usada para almacenar diversa información

QoS relativa a una interfaz IP dentro de un router: typedef struct { char * iface_name; int hold_q_capacity; int buffer_size; … IpT_QoS_Bandwidth_Type bandwidth_type; … IpT_QoS_Mechanism_Info * scheduling_info; IpT_QoS_Mechanism_Info * red_info; } IpT_QoS_Iface_Info;

• Definición de tipos enumerados para perfiles de interfaz: typedef enum { IpC_QoS_Scheduling_Profile, IpC_QoS_CAR_Profile, IpC_QoS_RED_Profile, IpC_QoS_Class_Map_Profile, … }IpT_QoS_Profile_Type;


181

• 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;

• Esta estructura es importante por contener una variable de tipo IpT_Rte_Module_Data, es

decir, será compartida entre el proceso padre y los hijos que implementen mecanismos de IP QoS. Contiene además variables para manejo de estadísticas relacionadas con el descarte y el envío de paquetes:

typedef struct { struct IpT_Rte_Module_Data* //estructura para acceder a memoria compartida iprmd_ptr; // Module Data del nodo. intiface_index; // Output interface index. Stathandle *locl_pk_dropped_hdl_ptr; … // Varias variables de acceso a estadísticas como son descarte de paquetes y paquetes enviados Statisitic handle for local packets dropped. … intstatistic_index; // index to register queuing statistics. … } OmsT_Qm_Shared_Memory;

• Esta estructura es importante. De éste tipo es la variable qconfig_ptr que se ha venido usando

en las funciones del Capítulo 4. Tiene referencia a parámetros IP específicos de la cola, entre ellos, acceso a estructuras específicas de RED:

typedef struct { double max_size; /* Max size of the queue during congestion. */ … int red_status; /* Habilitar o deshabilitar RED y sus variantes */ OmsT_Qm_Property_Type red_match_property; OmsT_Qm_RED_Queue_Params* red_queue_params_ptr; } OmsT_Qm_IP_Queue_Configuration;

• Definición de enumerados para describir tipo de cola. Sólo nos ha interesado el FIFO:


182

typedef enum { IpT_Mother_Pool = OMSC_MOTHER_POOL, … IpT_Fifo_Pool, … IpT_Max_Pool_Type } IpT_Pool_Type;

• Estructura para guardar información IP QoS dentro de OmsT_Qm_Info. Es parecida a la que

se ha descrito anteriormente, IpT_QoS_Iface_Info, pero como diferencia, guarda los parámetros globalmente y no para una interfaz determinada:

typedef struct IpT_Qos_Info { char * q_profile_name; int buffer_size; double reserved_bandwidth; IpT_QoS_Bandwidth_Type bandwidth_type; OmsT_Qm_Attributes * attribs_ptr; } IpT_Qos_Info;

• Estructura que guarda las variables que manejan todas las estadísticas de una cola dentro de

una interfaz: typedef struct { Boolean stat_is_registered; // Indicates whether the stat is registered. Stathandle queuing_delay_stathandle;// Statistic for queuing delay. … Stathandle red_average_queue_size_stathandle; // Avq size calculated by RED. } OmsT_Qm_Stat_Info;

C.2. ip_rte_support.h

Este fichero de cabecera contiene la definición de procedimientos para enrutamiento del protocolo IP. Sólo es usado por el modelo de proceso ip_dispatch y por sus hijos. Incluye muchos ficheros de cabecera y define muchas constantes necesarias para cálculos posteriores en otras funciones como tamaño de cabecera, velocidad del enlace entre interfaces por defecto, flags para niveles de nodos... Aún así, de este fichero solo nos interesa una estructura, IpT_Rte_Module_Data, pero será una de las más importantes, pues es la que aloja los datos de la memoria compartida entre procesos dentro de una jerarquía, y otros datos interesantes relativos a IP, como el tamaño de los datagramas, tabla de enrutado, etc. : typedef struct IpT_Rte_Module_Data {


183

Objid module_id; Objid node_id; char* node_name; Prohandle ip_root_prohandle;/* ip_dispatch */ … /* Memory shared between various process models */ OmsT_Qm_Shared_Memory shared_mem; Ici *arp_iciptr; List *interface_table_ptr; /* Table consisting of an array of all interfaces of the node */ IpT_Interface_Table interface_table; /* Tabla de enrutamiento usada por los paqueres IP en cada nodo. Registra los routers operatives. */ IpT_Cmn_Rte_Table* ip_route_table; … /* Static Route Table */ IpT_Rte_Table* ip_static_rte_table; … Objidip_parameters_objid; /* Objid of IP Routing Parameters or*/ /* IP Host Parameters attribute */ Objid ip_qos_params_objid; /* IP QoS attribute object id*/ /* Variables para el registro de estadísticas y otros datos referentes al tráfico background */ … /* Memoria compartida entre este proceso y sus hijos. Su propósito es proporcionar un método para diferenciar entre el hijo desde donde el proceso fue invocado y recivir un paquete en este proceso desde ese hijo. */ IpT_Ptc_Memory ip_ptc_mem; … OmsT_Dv_Proc_Scheme processing_scheme; /* Variables para el manejo de estadísticas de cantidad de paquetes, de tipo Stathandle. Tambien para el registro de “hops” */ … /* Indicación de presencia/ausencia de protocolos de enrutado en el nodo. */ int routing_protos; /* Tamaño del datagrama después de la compresión. */ OpT_Packet_Size dgram_compressed_size; … /* Identificador único de datagrama para cada paquete IP. */ int dgram_id; … /* Array que almacena datos QoS para todas las interfaces. */ IpT_Rte_Iface_QoS_Data ** interface_qos_data_pptr; … /* Campos relacionados con fragmentación de datagramas.*/ Sbhandle seg_buf_ptr;/* To fragment full datagrams*/ Sbhandle reseg_buf_ptr;/* To fragment fragments*/ Sbhandle rsm_buf_ptr;/* To reassemble fragments*/ } IpT_Rte_Module_Data;


184

C.3. oms_qm.h

En éste fichero hay muchas estructuras importantes, pues es el que tiene los elementos necesarios para implementar el manejo de colas en OPNET. Ya se ha dicho en el Capítulo 4 que éste es uno de los ficheros que se han modificado, añadiendo una nueva constante OMSC_GRED a las ya existentes. Los tipos enumerados se utilizarán para asignar valores a algunos de los campos de las estructuras y para tomar decisiones de procesamiento mientras la simulación. • Estructura de tipos enumerados para las disciplinas de cola: typedef enum { OmsC_Qm_No_Queuing = -1, OmsC_Qm_FIFO_Queuing = 0, … OmsC_Qm_Max_Queuing_Schemes = 9 /* should be last-but-one entry */ } OmsT_Qm_Queuing_Scheme;

• Estructura de tipos enumerados que indica características de los datos: typedef enum { … OmsC_Qm_Discard_Class = 250, OmsC_Qm_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:

typedef enum OmsT_Qm_Tos { OmsC_Qm_Tos_Unspecified = -1, OmsC_Qm_Best_Effort = 0, OmsC_Qm_Background = 32, OmsC_Qm_Standard = 64, OmsC_Qm_Excellent_Effort = 96, OmsC_Qm_Streaming_Multimedia = 128, … } OmsT_Qm_Tos;

• Definición de tipos enumerados que indican qué hacer con un determinado paquete. Entre los

elementos, descartan por ejemplo OmsC_Qm_Dropped_Packet o OmsC_Qm_Queued_Packet, que se vió anteriormente que aparecen en la función Oms_Qm_incoming_Packet_Handler para ver si se debe o no descartar el paquete que llega:

typedef enum { OmsC_Qm_Send_Packet = 0, OmsC_Qm_Dropped_Packet = 1, OmsC_Qm_Queued_Packet = 2, OmsC_Qm_Dequeue_Abort = 3, OmsC_Qm_Dequeue_Packet = 4, OmsC_Qm_Invalid_Signal } OmsT_Qm_Signal;


185

• Definición de tipos enumerados para algunos de los atributos que puede haber en una cola: typedef enum { … OmsC_Qm_RED_Status, /* RED attribs should be the last group */ OmsC_Qm_RED_Match_Property, OmsC_Qm_RED_Match_Value, OmsC_Qm_RED_Exp_Weight_Factor, OmsC_Qm_RED_Min_Threshold, OmsC_Qm_RED_Max_Threshold, OmsC_Qm_RED_Prob_Denominator, OmsC_Qm_Max_Attrib_Type } OmsT_Qm_Attribute_Type;

• Estructura que alberga las características de un paquete necesarias para saber en qué cola se

debe almacenar y cómo aplicar QoS sobre él dependiendo de su precendencia, destino, prioridad, etc:

typedef struct IpT_Pkt_Info { int drop_precedence; /* Used by RED while dropping packets. */ OmsT_Qm_Tos tos; /* Type of Service of the packet. */ int protocol; /* protocol of the packet.(TCP/UDP/etc.)*/ InetT_Address source_address; /* source_address of the packet. */ InetT_Address dest_address; /* destination address of the packet.*/ int source_port; /* source port of the packet. */ int dest_port; /* destination port of the packet. */ int incoming_iface; /* Incoming interface for the packet. */ int queue_id; /* Queue to which this packet belongs.*/ int CE, ECT, packet_size, loss_priority, queue_number; Boolean pk_fragment; Packet* pkptr; } IpT_Pkt_Info;

• De esta estructura, interesa saber que contiene el identificador de la cola: typedef struct AtmT_Pkt_Info { int queue_id; … } AtmT_Pkt_Info;

Las dos estructuras anteriores están contenidas dentro de una unión que forma la estructura OmsT_Qm_Pkt_Info, que es ampliamente utilizada en varias de las funciones explicadas en el Capítulo 4, pues es a partir de la que se va a acceder a toda la información de cada paquete. Las siguientes dos estructuras, implementan lo que sería la jerarquía de colas. Como recordatorio, en OPNET una cola puede contener varias subcolas, y éstas a su vez contener más subcolas, y así, hasta el nivel que el modelador considere oportuno, teniendo todas la misma estructura. Por ello, la primera estructura alberga características de una subcola simple, con referencia a la cola padre, y la segunda tiene campos que son punteros a arrays de colas. A continuación se muestran las dos:


186

• 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 cola s OmsT_Qm_Queue_Pool** queue_pool_parray; //Array de subcolas que contiene OmsT_Qm_Attributes* attributes_ptr; OmsT_Buffer_Pool_Handle buffer_pool_handle;//Buffer asociado al conjunto OmsT_Qm_Queuing_Scheme queue_processing_scheme;//Disciplina asociada a las colas /* Variables específicas a las disciplinas de cola. Estan determinadas por la cola padre, si es el caso.*/ void* qscheme_vars_ptr; int queue_to_service; /* Cola que se está utilizando */ OmsT_Qm_Info* qmgmt_info_ptr; };

• Variables necesarias para el algoritmo RED, en concreto, para la actualización del tamaño

medio de cola: typedef struct { double average_queue_size; double start_idle_time; } OmsT_Qm_RED_Vars;

• De ésta estructura, lo que interesa es el campo queue_configuration, que será el que después

accederá a la estructura OmsT_Qm_IP_Queue_Configuration explicada anteriormente: struct OmsT_Qm_Attributes {


187

int no_queues; /* Numero de colas o subcolas */ int default_queue; /* Cola para paquetes por defecto. */ int max_total_no_buf_pkts; /* Maximo número de paquetes almacenados. */ … void** queue_configuration; /* Parámetros de configuración de la cola. */ … };

• Estructura con algunos de los parámetros RED relativos a la elección de descarte de paquetes

para cada cola IP: typedef struct { OmsT_Qm_Property_Type match_property; int exponential_weight_factor; Boolean ce_marking; /*Bandera indicadora de ECN habilitado. */ List *red_class_params_lptr; } OmsT_Qm_RED_Queue_Params;

• Estructura con los parámetros relativos a cada clase de descarte dentro de la cola. Nosotros

hemos jugado con una clase de descarte única para toda la simulación, por lo que sólo habrá una estructura de éste tipo. Si aplicaramos más clases de descarte, se rellenaría ésta estructura para cada una de las clases. Esto se elije mediante el parámetro QoS � FIFO Profiles � RED Parameters � Mark Probability denominator. Si en vez de configurarlo con un solo valor, se configura dándole una cadena de números separados por una coma, cada uno de esos números implicaría una clase de descarte.

typedef struct { OmsT_Qm_Tos match_value; int minimum_threshold; /* Umbral 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 */


188

} OmsT_Qm_Arch_Func_Types;

• Para un propósito similar se define la siguiente estructura: typedef enum { OmsC_Qm_Pkt_Deq_Complete = 0, OmsC_Qm_Queue_Select, OmsC_Qm_Qscheme_Vars_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:

/* Global Table to maintain Qscheme specific functions */ extern OmsT_Qm_Qscheme_Void_Func OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_Max_Queuing_Schemes] [OmsC_Qm_Max_Qscheme_Func_Types];


189

Anexo D. Pautas para la modificación del funcionamiento

del algoritmo RED

Se ha pensado en una posible extensión de este proyecto que sería sencilla a partir de lo explicado, pero que no se ha podido llevar a cabo por problemas de tiempo. La modificación consiste en cambiar la frecuencia con la que se ejecuta el algoritmo RED, pasando de ser cada vez que llega un paquete a producirse cada cierto intervalo de tiempo o período de muestreo. Este nuevo algoritmo, lo podríamos llamar CRED. Los cambios a realizar serían del orden de los hechos para extender la aplicación con el algoritmo GRED. Habría que editar el modelo de proceso ip_output_iface, añadiendo una variable de estado que lleve el control del tiempo y otra que contenga el intervalo de muestreo. En el header block habría que añadir la macro correspondiente a una interrupción, que consiste en comprobar si se ha agotado el tiempo indicado por la variable de muestreo. En el Function Block, definir una función que calcule el tamaño medio de cola y la probabilidad de pérdida, reutilizando o llamando a las funciones Oms_Qm_Average_Queue_Size_Update y oms_qm_red_drop_packet. El funcionamiento sería de la siguiente forma:

1. Comienza la ejecución del modelo de proceso ip_output_iface. Inicialización de un contador de tiempo. La inicialización de variables se podría realizar en el estado init.

2. En el estado idle, esperar por una de las interrupciones, entre las cuales se añade una que

tenga en cuenta el tiempo que ha pasado desde que se ejecutó la última vez el algoritmo CRED.

3. Una vez agotado el tiempo del temporizador, se lanza una interrupción que termina en el

mismo estado, y que estará aparejada a un transition executive en el que se llama a la función que calcula los parámetros de RED y almacena la probabilidad de pérdida del paquete en una variable.

4. Ya en el estado idle de nuevo, y con la probabilidad de pérdida del paquete calculada, se

procede como se ha hecho hasta entonces, llamando a la función enqueue_packet, en la que habría que hacer alguna operación para advertir que el algoritmo utilizado es CRED, y

Anexo D. Pautas para la modificación del algoritmo RED en OPNET

190

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.


191

Anexo E. Herramientas utilizadas

D.1 VisualC ++

Compilador de código C y C++ que transforma código fuente en código ejecutable. Necesario para compilar los modelos de proceso utilizados en OPNET antes de la simulación.

D.2 OPNET Modeler

Modelador y simulador de redes. Es la principal herramienta utilizada en éste proyecto tanto para modelar las topologías como para realizar las simulaciones y estudiar el código fuente de los modelos de proceso.

D.3 Notepad ++

Editor gratuíto de código fuente, que soporta varios lenguajes de programación y se ejecuta en MS Windows. Se distribuye bajo la licencia pública de GNU. Utilizado en este proyecto para revisar y editar el código fuente de los ficheros de cabecera (extensión .h) y de los ficheros de código externo (extensión .ex.c).

Documents

Control de Congestión con OPNETtere/memoria.pdf · Control de Congestión con OPNET 3 AGRADECIMIENTOS En primer lugar quisiera agradecer a mi tutora, Teresa, por su trato cercano