Memoria

Control de Congestin con OPNET
Universidad de Valladolid
E. T. S. DE INGENIERA INFORMTICA
Ingeniera Tcnica en Informtica de Sistemas
Alumna: Lourdes Nicols Fernndez Tutora: M Teresa lvarez lvarez
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 saba cmo seguir adelante con el proyecto, o pensaba que no iba a terminar a tiempo. A mis padres y mi a hermano, las personas ms importantes para m, que me han dado su cario y su apoyo incondicional durante todos estos aos de la carrera. Muchas veces he descargado mi frustracin con vosotros injustamente. Gracias por ser pacientes conmigo. Por supuesto tambin debo agradecer al resto de mi familia: mis tos y primos, y especialmente a mis abuelos, que siempre estn pendientes de m. Es una suerte poder seguir contando con ellos. A Pablo, por ser mi punto de apoyo del da a da y por sacar siempre tiempo y paciencia para escucharme. Tus consejos y tu compaa me hacen recuperar la fuerza cuando ms dbil 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, Roco y Virginia, por pensar conmigo tantas veces a lo largo de todos estos aos de universidad, en los momentos buenos y en los malos. Que sepis que os tocar seguir escuchndome por unos cuantos aos ms Tambin debo agradecer a la gente de fuera de la universidad: a Luis, Tatiana, Pedro y los dems por los momentos inolvidables que hemos pasado juntos, y lo que todava nos queda. Debo dedicar un agradecimiento especial a Rubn, un gran amigo que siempre est ah, y una de las personas que ms me ha ayudado durante toda la carrera. Sin tu consejo y tu ayuda este camino habra sido mucho menos llevadero.
Por todo ello, muchas gracias a todos, Lourdes.
ndice general
NDICE DE ILUSTRACIONES.................................................................................................... 11 CAPTULO 1. INTRODUCCIN ........................................................................................ 15 1.1 MOTIVACIN ........................................................................................................................... 15 1.1.1 Simuladores de red ......................................................................................................... 16 1.1.2 Simulador OPNET Modeler ........................................................................................... 18 1.2 OBJETIVO DEL PROYECTO........................................................................................................ 19 1.3 RECOPILACIN DE INFORMACIN ............................................................................................ 19 1.4 ESTRUCTURA DE LA MEMORIA ................................................................................................ 20 CAPTULO 2. CONCEPTOS TERICOS .......................................................................... 23
2.1 INTRODUCCIN ....................................................................................................................... 23 2.1.1 Situacin de las redes actuales...................................................................................... 23

El control de congestin..................................................................................................................... 24
2.2 CALIDAD DE SERVICIO ............................................................................................................ 25 2.2.1 Introduccin .................................................................................................................. 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 Prdida de paquetes y corrupcin 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 congestin en TCP .................................................................................. 29
2.3.2.1 Arranque lento y prevencin de la congestin........................................................................ 29 2.3.2.2 Retransmisin Rpida y Recuperacin Rpida....................................................................... 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 Clasificacin................................................................................................................... 32 2.4.2 Gestin de colas ............................................................................................................. 32 2.4.3 Planificacin 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 GESTIN ACTIVA DE COLAS.................................................................................................... 35 5
Indice
2.5.1 Introduccin y fundamentos de los AQM ........................................................................35

2.5.1.1 Notificacin Explcita de la Congestin (ECN) ..................................................................... 36
2.5.2 Random Early Detection (RED)......................................................................................36

2.5.2.1 Gentle-RED............................................................................................................................ 38
CAPTULO 3.
INTRODUCCIN TERICA AL SIMULADOR OPNET .......................41
3.1 INTRODUCCIN ........................................................................................................................41 3.2 DOMINIO DE RED (NETWORK DOMAIN).....................................................................................43 3.3 DOMINIO DE NODOS (NODE DOMAIN).......................................................................................44 3.3.1 Mdulos...........................................................................................................................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 Ejecucin basada en interrupciones........................................................................................ 49 3.4.1.2 Procesos Dinmicos ............................................................................................................... 49 Jerarqua de procesos ......................................................................................................... 49 Memoria compartida .......................................................................................................... 50 Operaciones con Procesos Dinmicos ................................................................................ 51 Control de interrupciones ................................................................................................... 52 3.4.1.3 Recursos de un proceso .......................................................................................................... 52 Canales de entrada/salida (Input and Output Streams)....................................................... 52 Estadsticas (Input Statistics y Local Output Statistics)...................................................... 53 Estadsticas 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 Transicin 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 SIMULACIN ............................................................................................................................67 3.5.1 Construccin de un modelo de simulacin......................................................................67 3.5.2 Simulacin de eventos discretos......................................................................................68
3.5.2.1 Eventos y simulation time ...................................................................................................... 68 3.5.2.2 Planificacin y Lista de eventos ............................................................................................. 69

3.5.2.3 Eventos................................................................................................................................... 70 Atributos de los Eventos..................................................................................................... 70 Tipos de Eventos ................................................................................................................ 71 Procesamiento de Eventos - Interrupciones........................................................................ 71
CAPTULO 4.
IMPLEMENTACIN DEL ALGORITMO RED EN OPNET................ 73
4.1 INTRODUCCIN ....................................................................................................................... 73 4.1.1 Requisitos previos a la instalacin y uso........................................................................ 73 4.1.2 Obtencin y Gestin de licencias ................................................................................... 74 4.1.3 Instalacin ...................................................................................................................... 74 4.1.4 Configuracin................................................................................................................. 75
Comprobar las preferencias de OPNET:.................................................................................. 75
4.2 MODELADO A NIVEL DE TOPOLOGA ....................................................................................... 76 4.2.1 Descripcin de la topologa ........................................................................................... 76 4.2.2 Construccin paso a paso .............................................................................................. 76
4.2.2.1 Creacin de un proyecto nuevo: ............................................................................................. 76 4.2.2.2 Creacin de la red: ................................................................................................................. 77 4.2.2.3 Configuracin del Nodo de Aplicaciones............................................................................... 79 4.2.2.4 Configuracin del Nodo de Perfiles ...................................................................................... 79 4.2.2.5 Configuracin de Clientes y Servidores ................................................................................. 80
4.2.3 Configuracin de Atributos QoS .................................................................................... 83 4.2.4 Eleccin de estadsticas.................................................................................................. 84 4.2.5 Duplicar escenarios........................................................................................................ 85
4.2.5.1 Operaciones del men Scenarios............................................................................................ 86 4.2.5.2 Creacin y configuracin del escenario RED......................................................................... 87 4.2.5.3 Creacin y configuracin del escenario GRED...................................................................... 88
4.2.6 Simulacin de los escenarios.......................................................................................... 89

4.2.6.1 Simular un solo escenario....................................................................................................... 90
4.2.7 Comparacin y visualizacin 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 mdulo attribute_definer..................................................... 95
Header Block .......................................................................................................................... 95 Variables de Estado ................................................................................................................ 96 Variables Temporales ............................................................................................................. 96 Enter Executives ..................................................................................................................... 96 Function Block ....................................................................................................................... 97
4.3.4 Modificacin de atributos............................................................................................. 100

4.3.4.1 Acceso a la tabla de atributos ............................................................................................... 101 4.3.4.2 Aadir un nuevo atributo...................................................................................................... 102 4.3.4.3 Aadir 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 mdulo ip ............................................................................... 109
4.4.2.1 Anlisis de ip_dispatch......................................................................................................... 110 4.4.2.2 Anlisis de ip_output_iface .................................................................................................. 121
4.5 ESQUEMA-RESUMEN PARA LA IMPLEMENTACIN DE GRED ................................................. 140 4.5.1 Modificacin de cdigo en ficheros externos ............................................................... 140
4.5.1.1 oms_qm.h............................................................................................................................. 140 4.5.1.2 oms_qm.ex.c ........................................................................................................................ 140
4.5.2 Modificacin del modelo de procesos ip_output_iface ................................................ 141 7
Indice
4.5.3. Modificacin de atributos del nodo QoS......................................................................142 CAPTULO 5. EXPERIMENTOS...............................................................................................143 5.1 INTRODUCCIN ......................................................................................................................143 5.2 TOPOLOGAS 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 PARMETROS DE RED .......................................................................146 5.3.1 Configuracin de los parmetros en general...............................................................146 5.3.2 Umbral Mnimo.............................................................................................................146 5.3.3 Umbral Mximo ............................................................................................................146 5.3.4 Exponential Weight Factor (wq) ...................................................................................147 5.3.5 Probabilidad Mxima ...................................................................................................147 5.3.6 Ajuste de parmetros GRED .........................................................................................147 5.4 RESULTADOS CON LA TOPOLOGA CUELLOBOTELLA .............................................................148 5.4.1 Especificacin de parmetros 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 parmetros .................................................................................................................. 149
5.4.2 Grficas.........................................................................................................................150
5.4.2.1 Trfico descartado globalmente ........................................................................................... 150 5.4.2.2 Retardo global de la red ....................................................................................................... 152 5.4.2.3 Utilizacin del buffer en Router1 ......................................................................................... 154 5.4.2.4 Variacin en el retardo o jitter en Router1 ........................................................................... 156 5.4.2.5 Retardo en Router1 o Delay ................................................................................................. 158 5.4.2.6 Comparacin entre RED y GRED........................................................................................ 160 5.4.2.7 Utilizacin del enlace entre Router1 y Router2.................................................................... 162
5.5 RESULTADOS CON LA TOPOLOGA CUELLOBOTELLA2 ...........................................................164 5.5.1 Especificacin de parmetros 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 Grficas.........................................................................................................................166
5.5.2.1 Trfico descartado globalmente ........................................................................................... 166 5.5.2.2 Retardo global en la red ....................................................................................................... 166 5.5.2.3 Utilizacin del buffer en Router1 ......................................................................................... 167 5.5.2.4 Retardo en Router1............................................................................................................... 167 5.5.2.5 Comparacin entre RED y GRED........................................................................................ 168 5.5.2.6 Utilizacin del enlace entre Router1 y Router2.................................................................... 168
CAPTULO 6: CONCLUSIONES Y LNEAS FUTURAS........................................................169 6.1 CONCLUSIONES ......................................................................................................................169 6.2 POSIBLES AMPLIACIONES ......................................................................................................170 BIBLIOGRAFA ...........................................................................................................................171 A. PUBLICACIONES CIENTFICAS .................................................................................................171 B. PGINAS WEB .........................................................................................................................172 GLOSARIO....................................................................................................................................173 ANEXO A. CONTENIDO DEL CD ............................................................................................175 8
Control de Congestin con OPNET ANEXO B. GUIA PARA INTEGRAR EL ALGORITMO GRED EN OPNET ..................... 177 ANEXO C. ESTRUCTURAS Y VARIABLES IMPORTANTES ............................................ 179 C.1 IQ_QOS_SUPPORT.H .............................................................................................................. 179 C.2. IP_RTE_SUPPORT.H .............................................................................................................. 182 C.3. OMS_QM.H ........................................................................................................................... 184 ANEXO D. PAUTAS PARA LA MODIFICACIN 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
ndice de ilustraciones
Ilustracin 1. Vista de la seccin de clientes de la pgina de OPNET ............................................. 18 Ilustracin 2. Fragmento del rbol de contenidos de la documentacin de OPNET utilizada para ste proyecto ..................................................................................................................................... 20 Ilustracin 3. Ejemplo de un caso de congestin.............................................................................. 24 Ilustracin 4. Estructura de un segmento TCP ................................................................................. 28 Ilustracin 5. Ventana de congestin y cola en TCP ........................................................................ 30 Ilustracin 6. Planificacin de Colas FIFO...................................................................................... 33 Ilustracin 7. Funcionamiento de FQ............................................................................................... 34 Ilustracin 8. Comparacin entre el tamao real de cola y el valor que toma Qavg ....................... 37 Ilustracin 10. Probabilidad de descarte de RED y de GRED ......................................................... 39 Ilustracin 11. Pantalla de inicio del Simulador OPNET................................................................. 41 Ilustracin 12. Vista de varios editores en OPNET .......................................................................... 42 Ilustracin 13. Interaccin de un mdulo transmisor con el modelo de nodos y el de red............... 46 Ilustracin 14. Jerarqua de procesos en OPNET ............................................................................ 50 Ilustracin 15. Memoria padre-hijo en una jerarqua de procesos .................................................. 51 Ilustracin 16. Esquema de input streams en un QP. ....................................................................... 53 Ilustracin 17. Estadsticas locales en el modelo de proceso ip_output_iface ................................. 54 Ilustracin 18. Ejemplo de STD: ip_output_iface............................................................................. 57 Ilustracin 19. Flujo de ejecucin a travs de unforced states......................................................... 59 Ilustracin 20. Modelado con forced states ...................................................................................... 60 Ilustracin 21. Representacin de transiciones en un STD .............................................................. 61 Ilustracin 22. Declaracin de variables de estado en ip_output_iface........................................... 63 Ilustracin 23. Declaracin de variables temporales en ip_output_iface ........................................ 64 Ilustracin 24. Dos tramos de la lista de ficheros externos en ip_dispatch...................................... 65 Ilustracin 25. Acceso a los atributos del modelo de procesos qos_attribute_definer ..................... 66 Ilustracin 26. Distribucin tpica de eventos durante el tiempo de simulacin .............................. 69 Ilustracin 27. Organizacin de una lista de eventos durante el tiempo de ejecucin ..................... 70 Ilustracin 28. Ventana de preferencias en OPNET......................................................................... 75 Ilustracin 29. Paleta de objetos ...................................................................................................... 77 Ilustracin 30. Nodos en el espacio de trabajo del editor de proyectos ........................................... 78 Ilustracin 31. Atributos del nodo Perfiles ....................................................................................... 80 Ilustracin 32. Un paso en la configuracin de un Cliente .............................................................. 81 Ilustracin 33. Tabla para elegir destino de Cliente1 ...................................................................... 82 Ilustracin 34. Eleccin de la disciplina FIFO en las interfaces de los routers conectados............ 83 Ilustracin 35. Unin entre routers con las interfaces configuradas ............................................... 84 Ilustracin 36. Men para elegir estadsticas................................................................................... 84 Ilustracin 37. Ventana de eleccin de estadsticas sin desglosar ................................................... 84 11
Indice
Ilustracin 38. Parte de la interfaz de visualizacin de las estadsticas disponibles para la interfaz IP de Router1 ................................................................................................................................85 Ilustracin 39. Vista de algunas de las operaciones del men Scenarios.....................................86 Ilustracin 40. Lista de los escenarios dentro del proyecto CuelloBotella .......................................87 Ilustracin 41. Configuracin de parmetros del algoritmo RED en el nodo QoS...........................87 Ilustracin 42. Configuracin de parmetros del algoritmo RED en el nodo QoS...........................89 Ilustracin 43. Dos instantes de simulacin: antes y despus de la simulacin................................90 Ilustracin 45. Ventana del editor de simulaciones...........................................................................91 Ilustracin 46. Ventana de visualizacin de resultados. ...................................................................92 Ilustracin 47. El nodo QoS y su modelo de nodos. ..........................................................................94 Ilustracin 48. Acceso al modelo de procesos de attribute_definer ....................................95 Ilustracin 49. Atributo recogido por attr_def_fifo_profiles_info_parse..........................................97 Ilustracin 50. Parmetros recogidos mediante attr_def_red_parameters_get................................99 Ilustracin 51. Ventana Model Attributes del modelo de proceso del nodo QoS ............................101 Ilustracin 52. Atributos de FIFO Profiles .....................................................................................102 Ilustracin 53. Aadir un nuevo atributo ........................................................................................103 Ilustracin 54. Atributos dentro del atributo compuesto RED Parameters.....................................103 Ilustracin 55. Symbol map de RED Parameters ............................................................................104 Ilustracin 56. Correspondencia con Symbol map..........................................................................105 Ilustracin 57. Propiedades del atributo RED Parameters.............................................................105 Ilustracin 58. Aadiendo un valor a Symbol Map .........................................................................106 Ilustracin 59. Asignacin de valor a nuevo smbolo......................................................................106 Ilustracin 60. Nuevo fichero de propiedades pblicas de un atributo...........................................107 Ilustracin 61. Modelo de nodos de Router1, ethernet4_slip8_gtwy_adv.......................................108 Ilustracin 62. Modelo padre del mdulo ip: ip_dispatch...............................................................109 Ilustracin 63. Especificacin de ip_dispatch como proceso raz en el mdulo ip .........................109 Ilustracin 64. rbol de atributos IP, Interface Information en un router, recorrido por la funcin ip_qos_info_process ........................................................................................................................115 Ilustracin 65. Esquema de llamadas desde ip_dispatch ................................................................120 Ilustracin 66. Ver los procesos hijos de ip_dispatch .....................................................................121 Ilustracin 67. Variables de estado de ip_output_iface ..................................................................122 Ilustracin 68. STD del modelo de proceso ip_output_iface...........................................................123 Ilustracin 69. Esquema de llamadas desde ip_output_iface..........................................................138 Ilustracin 70. Topologa CuelloBotella .........................................................................................144 Ilustracin 71. Topologa CuelloBotella2 .......................................................................................145 Ilustracin 72. E1 y E2. Trfico descartado en la red.....................................................................150 Ilustracin 73. E3, E4. Trfico descartado en la red. .....................................................................151 Ilustracin 74. E1, E2. Valores medios del retardo en la red. ........................................................152 Ilustracin 75.E3, E4. Valores medios del retardo en la red. .........................................................153 Ilustracin 76. E1, E2. Utilizacin del buffer en Router1. ..............................................................154 Ilustracin 77 E3, E4. Utilizacin del buffer en Router1. ...............................................................155 Ilustracin 78. E1, E2. Jitter en Router1, valores medios. ..............................................................156 Ilustracin 79.E3, E4. Jitter en Router1, valores medios. ...............................................................157 Ilustracin 80. E1, E2. Retardo en Router1, valores medios...........................................................158 Ilustracin 81. E3, E4. Retardo en Router1, valores medios...........................................................159 Ilustracin 82. E1, E2. Tamao de cola medio con el algoritmo RED (rojo) y GRED (azul).........160 Ilustracin 83. E3, E4. Tamao de cola medio con el algoritmo RED y GRED. ...........................161 Ilustracin 84. E1, E2. Utilizacin del enlace entre los routers......................................................162 Ilustracin 85. E3, E4. Utilizacin del enlace entre los routers......................................................163 Ilustracin 86. Trfico registrado para CuelloBotella y CuelloBotella2 ........................................165 Ilustracin 87. E5, Retardo global para la topologa CuelloBotella2 ............................................166 12
Control de Congestin con OPNET Ilustracin 88. E5, Retardo global en la red, valores medios......................................................... 166 Ilustracin 89. E5, Utilizacin del buffer en el Router1. ................................................................ 167 Ilustracin 90. E5, Retardo en el Router1, valores medios. ........................................................... 167 Ilustracin 91. Tamao medio de cola de GRED (azul) y RED (rojo) ........................................... 168 Ilustracin 92. E5, Utilizacin del enlace....................................................................................... 168
13
Indice
14
Captulo 1. Introduccin
1.1 Motivacin
Hoy en da, las tecnologas de comunicacin y las redes de ordenadores avanzan rpidamente, incrementndose el nmero de usuarios, la carga de trfico y la complejidad total. Probablemente uno de los mayores problemas con que se enfrenta la ciencia en este campo es el del rpido crecimiento del volumen de datos (mayor tamao, con mayor velocidad), y la incapacidad de aumentar suficientemente la velocidad de procesamiento de esos datos en los routers y dems nodos intermedios en la red. Esto lleva a situaciones de congestin (llegan ms datos de los que el sistema tiene capacidad de procesar), produciendo una importante prdida de paquetes y retraso en la entrega de informacin y finalmente, deteriorando la calidad de servicio o QoS demandada por el usuario. La congestin de redes es un problema inevitable, pero gracias a diversas tcnicas se pueden paliar sus efectos en gran medida. Entre esas tcnicas, se encuentran mecanismos de control de flujo como el que proporcionan las ventanas deslizantes del protocolo TCP, o algoritmos de control de congestin como son las disciplinas de cola (FIFO, PQ) y la gestin de colas activa o AQM. La idea bsica de los algoritmos AQM es anticiparse a situaciones de congestin estableciendo reglas para el descarte controlado de paquetes cuando la situacin as lo requiere. Esto permite maximizar la capacidad del enlace del router, con el fin de obtener una tasa alta de envo de paquetes y mantener un tiempo de espera en la cola lo ms pequeo 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 congestin, es un algoritmo muy sensible a la configuracin que el usuario da a sus parmetros 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 parmetros de RED ha demostrado ser un trabajo difcil. Por ello, con los aos el estudio de este tipo de algoritmos ha sido objeto de diversas investigaciones, obteniendo soluciones que se adaptan mejor a la carga de trfico de las redes modernas. Los simuladores de redes son una herramienta idnea para llevar a cabo investigaciones sobre nuevos mtodos de control de congestin, pues proporcionan al investigador un entorno fiable 15
Captulo1. Introduccin
donde reproducir las caractersticas reales de una red especfica diseada para tal propsito, pudiendo configurarla fcilmente segn la situacin que se quiera analizar. Otra ventaja de utilizar simuladores de red, adems de cmo herramienta de investigacin de protocolos, es que se pueden hacer diversas pruebas sobre el diseo de la futura red sin gasto econmico (slo 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 fsica.
1.1.1 Simuladores de red

Antes de crear una red fsica real, es conveniente planificar su estructura, protocolos y otros parmetros, para asegurarse que el diseo sea una solucin adecuada a la necesidad que se quiere satisfacer mediante la red. Construir directamente una red fsica podra significar una importante prdida 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 aplicacin que permite al usuario disear un sistema de redes de comunicacin a travs de una interfaz grfica en la que puede elegir los distintos componentes que formarn la red y configurarlos individualmente. El objetivo que busca todo simulador es recrear un modelo lo ms fiable posible a la realidad, al menos en cuanto a las caractersticas a estudiar, para poder extrapolar los resultados obtenidos mediante la simulacin. Los simuladores de redes han madurado desde que aparecieron por primera vez como herramientas de desarrollo, administracin y prediccin. Hoy en da se les suele utilizar tambin para estudios de calidad de servicio, adems de ser de gran aplicacin en el mbito de la ingeniera. Gracias a la simulacin se puede observar la evolucin de un sistema de comunicacin especfico, sus caractersticas, propiedades utilizando como recurso slo la memoria de un ordenador. Existe un nmero considerable de herramientas de simulacin disponibles. Las caractersticas principales que generalmente las describen e influyen a la hora de elegir una u otra son: precisin, rapidez, facilidad de uso y costo. A continuacin se cita alguno de stos simuladores.
Packet Tracer
Es una herramienta de aprendizaje y simulacin gratuita desarrollada por la empresa CISCO Systems con fines acadmicos. Esta herramienta permite a los usuarios crear topologas de red, configurar dispositivos, insertar paquetes y simular una red con mltiples representaciones visuales. Una ventaja que tiene este simulador es que ofrece el anlisis 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 configuracin de las redes de comunicaciones y aplicaciones. Soporta una gran variedad de switches y routers, as como protocolos del tipo HTTP, DNS, TFTP, Telnet, OSPF, VTP y STP. 16
AdventNet
La herramienta de simulacin AdventNet comprende un simulador de agente y red con una sencilla interfaz grfica para el testeo, entrenamiento y demostracin de aplicaciones de gestin de redes. Brinda adems el editor de topologas para establecer interconexiones a travs de routers, switches y otros componentes de red y ver la relacin topolgica entre ellos. A esto se aade un modelo avanzado de conducta de agentes y redes, generacin de trampas, gestin de desperfectos y configuracin de los componentes, siendo este simulador especialmente eficaz en la simulacin de la conducta de redes en escenarios realistas o negativos.
Shunra VE Desktop
Es una herramienta de simulacin de redes ideal para probar el impacto de una red en el desempeo 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 ms fciles de usar y de integrar con el ambiente de trabajo existente. Permite configurar los parmetros de red manualmente o simplemente descargar archivos de escenarios de red predefinidos.
NS
ns (ms conocido como ns-2 por su versin actual) es una herramienta muy potente dentro del campo de los simuladores de redes de eventos discretos. Es utilizado principalmente en ambientes acadmicos debido a que est escrito en cdigo abierto y a la abundancia de documentacin existente. De hecho, probablemente es el simulador de redes de cdigo abierto ms extendido tanto en investigacin como para propsitos 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 configuracin, al ser, como se dijo antes, software de tipo open source. ns-2 fue construido en C++ y proporciona una interfaz de simulacin a travs de un lenguaje de script llamado Tcl que permite ir generando el modelo. El usuario describe una topologa de red escribiendo los citados scripts Tcl y a continuacin el programa principal de ns simula la topologa con los parmetros especificados. Tambin proporciona una interfaz grfica llamada nam que permite visualizar las simulaciones e incluso crear y editar modelos a simular. Entre los usos ms 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 pequea introduccin a OPNET Modeler, el simulador utilizado para ste proyecto.
17
1.1.2 Simulador OPNET Modeler

Es un simulador hbrido, basado en simulacin de eventos discretos en combinacin con un modelo analtico (uso de modelos matemticos). Utiliza mquinas 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 propsito especfico. Hay disponibles varios editores durante el diseo de la simulacin, cada uno con sus funcionalidades y su interfaz, siendo los ms importantes: proyecto, nodo y proceso, a travs de los cuales se puede modificar la configuracin de la red, equipo, protocolos y aplicaciones a diferentes niveles. Adems, si se dispone de la versin adecuada, como ha sido en nuestro caso, se proporciona acceso al cdigo fuente de las libreras 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. Podramos citar por ejemplo empresas como Telefonica International, Motorola Inc., Emirates Airlines, Thales, Ericsson etc. como se muestra en la siguiente imagen sacada de la pgina web oficial de OPNET,
http://www.opnet.com
Ilustracin 1. Vista de la seccin de clientes de la pgina de OPNET
Aparte de sus aplicaciones comerciales, es destacable remarcar que mientras se ha realizado este proyecto, se ha observado que hay un gran nmero de universidades espaolas (por ejemplo la Universidad Politcnica de Catalua, Universidad de Oviedo, Universidad Politcnica de Madrid, Universidad Politcnica de Valencia, Universidad de Alicante) que usan este programa como herramienta de docencia, por la facilidad con la que se puede mostrar a los estudiantes el comportamiento de una red gracias al realismo de los resultados obtenidos en sus simulaciones. 18
1.2 Objetivo del proyecto

Uno de los puntos principales de este proyecto es estudiar el funcionamiento y la tcnica de modelado utilizada por el simulador OPNET, centrndose en concreto en cmo se trata la implementacin 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 extensin del programa si se quieren aadir algoritmos de gestin activa de colas. El estudio del programa se har primero desde el punto de vista terico y general, describiendo cmo funcionan sus diferentes niveles de implementacin, y despus mediante un desarrollo detallado de cmo y dnde se pueden hacer modificaciones en el cdigo para aadir algoritmos de gestin activa de colas. Tambin se mostrar cmo se ha aadido el algoritmo GRED al simulador, qu ficheros se han modificado y cmo 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 libreras de modelos de OPNET: Drop Tail, RED y la extensin de ste ltimo que hemos implementado, Gentle-RED.
1.3 Recopilacin de informacin

El principal problema con el que nos hemos encontrado a la hora de realizar ste proyecto ha sido comprender de manera ms especfica e interna la herramienta OPNET ya que, a pesar de la gran cantidad de prcticas y tutoriales que hay por la red, y referencias al programa, en realidad todos se centran en aspectos muy bsicos de OPNET, sin meterse en temas ms complejos como son la implementacin 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 ms complejo, como implementar redes con parmetros y componentes ms especficos, o incluso extender la funcionalidad, aadiendo nuevos protocolos o algoritmos, el usuario se encuentra con que la informacin que hay es muy escasa e insuficiente. No queda entonces ms remedio que explorar todo el sistema de libreras (incluyendo los modelos de proceso del programa, ficheros de cabeceras y ficheros externos) que proporciona el programa para comprender exactamente dnde y cmo extender la funcionalidad. Una ayuda valiosa han sido los artculos cientficos sobre el tema, en su mayora estudios realizados por colectivos de profesores y alumnos de universidades, que aunque poco extensos, han servido como gua para recortar los posibles caminos que iban surgiendo. El problema es que muchos de estos artculos son relativamente modernos (puesto que la propia herramienta OPNET lo es), por lo que es difcil disponer de ellos gratuitamente. Todos los artculos o estudios cientficos sobre OPNET citados en la bibliografa han sido obtenidos de pginas y enlaces gratuitos, siendo de dominio pblico.
19
Otra valiosa referencia, para entender en s el funcionamiento de OPNET, ha sido la documentacin accesible desde los editores del propio programa, en el men Help Product Documentation. Una vez en la ventana de la documentacin, 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 ms utilizados, y de los que se ha sacado parte de la informacin y grficos del Captulo 3 de esta memoria son los contenidos dentro de Modeler Reference, como se muestra en la siguiente figura
Ilustracin 2. Fragmento del rbol de contenidos de la documentacin de OPNET utilizada para ste proyecto
Otro apartado valioso dentro de la ayuda de OPNET, sobre todo a la hora de entender el cdigo fuente en el que estn 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 programacin Proto-C.
1.4 Estructura de la memoria

Esta memoria est estructurada en los 6 captulos descritos a continuacin: Captulo 1. Introduccin En este captulo se especifica el marco de realizacin y la motivacin del proyecto, incluyendo introduccin, objetivo y bsqueda de informacin.
20
Control de Congestin con OPNET Captulo 2. Conceptos Tericos En este captulo se explica contenido terico relacionado con las redes de ordenadores, necesario para entender claramente el funcionamiento de los algoritmos de gestin activa de colas, especficamente el algoritmo RED. Captulo 3. Introduccin Terica al simulador OPNET En este captulo se describirn aspectos tericos necesarios para entender el comportamiento de OPNET, como son los distintos entornos de modelado o los fundamentos de la simulacin por eventos. Los conceptos se irn enlazando con los casos particulares de estudio en ste proyecto, para ir centrando en todo momento el mbito del mismo. Captulo 4. Modelado de AQM en el OPNET En este captulo se explica paso a paso el modelado de una red, empezando por la creacin de una topologa, configuracin de sus parmetros, estudio del modelo de nodos tanto del nodo de configuracin de QoS como del router, terminando con el estudio de tres modelos de proceso y los ficheros externos con los que estn relacionados. En todo momento nos centraremos en los componentes que forman parte de la implementacin del AQM RED en OPNET. Captulo 5. Experimentos En este captulo se muestran los experimentos realizados junto con las grficas que muestran los resultados obtenidos. Captulo 6. Conclusiones y lneas futuras En este captulo se exponen las conclusiones obtenidas tras la realizacin de este proyecto y se proponen algunas ideas para continuar con futuras lneas de investigacin. Por ltimo, se incluye la bibliografa utilizada como referencia en este proyecto, y un glosario de trminos bsicos. Adems de lo anterior, se incluyen cinco Anexos: Contenido del CD Gua para la utilizacin de los archivos del CD Estructuras de datos importantes en OPNET Pautas para la modificacin del algoritmos RED Herramientas utilizadas
21
22
Captulo 2. Conceptos Tericos
2.1 Introduccin
En este bloque se irn explicando desde las ideas ms generales de la congestin de redes, hasta los mecanismos especficos para prevenirla, o solucionar la situacin una vez se ha llegado a ella. As, ser necesario hablar de trminos 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 Gestin Activa de Colas, donde nos centraremos en especial en RED y alguna de sus variantes.
2.1.1 Situacin de las redes actuales

Las redes de ordenadores han crecido vertiginosamente desde sus orgenes tanto en nmero 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 trfico de datos no slo se ha incrementado (debido al creciente nmero de usuarios), sino tambin 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 fluctuacin (o jitter), por la prdida de paquetes y por su disponibilidad. El servicio que ofrece el protocolo IP, no orientado a conexin 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 contina 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 congestin. Entre ellas, los 23
mecanismos de gestin activa de colas (AQM, Active Queue Management). Estos mecanismos consisten en la deteccin temprana de la congestin reaccionando en base a criterios probabilsticos. La mayora de las aplicaciones de Internet sin requisitos de tiempo real utilizan el protocolo TCP para recuperar los paquetes perdidos en situaciones de congestin, as como para adoptar medidas reactivas regulando el volumen de trfico generado. La severidad del problema de la congestin crece en magnitud al crecer el volumen de las demandas de trfico. 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 razn de llegadas de trfico en un router es superior a la razn 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) sern posteriormente reenviados a su IP destino correspondiente de acuerdo con la tabla de encaminamiento. Una vez que un determinado router sufre congestin, la calidad del servicio de transporte se deteriora, aunque exista exceso de ancho de banda en todo el resto de la ruta. La tcnica tradicional para controlar el tamao de las colas en routers denominada Drop tail, se ha ido sustituyendo por la gestin Activa de Colas, que proporciona un mejor rendimiento en la red en trminos de utilizacin de las lneas, probabilidad de prdida de paquetes y retardo extremo a extremo.
El control de congestin
El control de congestin es el esfuerzo hecho por los nodos de la red para prevenir o responder a sobrecargas de la red que desembocan en congestin 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 aplicacin.
Ilustracin 3. Ejemplo de un caso de congestin.
24
2.2 Calidad de Servicio

2.2.1 Introduccin
Calidad de Servicio es un concepto que caracteriza las prestaciones y el funcionamiento de una comunicacin extremo-a-extremo entre dos puntos finales de una red. Otra forma de explicar este concepto sera como la habilidad de un elemento de red (aplicacin, host o router) de ofrecer cierto nivel de garanta para que los requisitos del servicio sean satisfechos. En Internet la tecnologa dominante proporciona el servicio denominado best effort. Por lo general, cada vez que se requiere informacin en la red, sta tiene que transmitirse a travs de varias redes, por tanto, la calidad de servicio extremo-a-extremo depende principalmente de las caractersticas 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 segn el tipo de aplicacin y usuario. Para sustentar la QoS extremo-a-extremo es importante conocer ms acerca del comportamiento dinmico de las redes. Esto es posible lograrlo mediante algunos parmetros que pueden ser medidos y monitoreados en la red. Entre los parmetros ms importantes se encuentran: el ancho de banda, el retardo, el jitter y la probabilidad de prdida de paquetes. Adems del popular best effort se han propuesto otros mecanismos, que satisfacen mejor las demandas de nuevas aplicaciones: Servicios Integrados y Servicios Diferenciados. La implementacin de QoS puede estar formada por uno de los mecanismos nombrados, o una combinacin 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 discutirn en secciones posteriores.
2.2.2 Mecanismos de QoS

2.2.2.1 Servicio Best Effort
Este servicio no aporta ninguna caracterstica QoS. De hecho, no garantiza cundo ni cmo se entregarn 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 travs de reservar recursos extremo-a-extremo de la red para cada flujo antes de ser transmitido. Esta reserva se 25
realiza a travs 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 aplicacin 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 ms cercana posible a la calidad que el mismo flujo recibira en una red best effort sin cargas. Para ello se utiliza un procedimiento de control de admisin en cada nodo para asegurarse que hay recursos para el flujo y supervisin a pesar de haber sobrecarga. Est especialmente indicado para implementaciones altamente simples que no tengan demandas precisas de QoS, y no proporciona ninguna garanta cuantitativa respecto a retardo y ancho de banda. - Servicios Garantizados: Este tipo de reserva proporciona un retardo controlado extremoa-extremo de la red y garantiza un ancho de banda para el trfico conformado con las especificaciones prefijadas. Para ello se necesita conocer las especificaciones del trfico 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 admisin 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 admisin. Esto conduce a un considerable trfico de sealizacin (por el protocolo RSVP) a lo largo del camino, y ocupacin 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 orientacin por flujo de RSVP, este modelo se basa en considerar el trfico en diferentes clases de servicios (Class of Service, CoS), controlar la cantidad de trfico de cada clase que un cliente enva a la red y asegurar los requerimientos de QoS de varios tipos de aplicaciones utilizando mecanismos de colas en cada nodo con polticas claramente definidas (y dependientes del contrato o compromiso adquirido con el usuario) de scheduling y dropping. El modelo de servicios diferenciados no utiliza la comunicacin extremo-a-extremo para la reserva de recursos como lo hace IntServ. Este modelo se aplica a una regin de la red y usa un criterio de clasificacin agregado basado en reglas predefinidas para agrupar a los paquetes en clases. Para aplicar los parmetros de QoS a las clases, los paquetes son clasificados con algn criterio, marcndolos 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 trmino PHB (Per-Hop Behavior) describe en este modelo el tratamiento especfico de envo que recibir un paquete en el interior de la red despus de ser clasificado en una clase dada. Este tratamiento proporciona al paquete un apropiado retardo, ancho de banda jitter, etc. 26
Control de Congestin con OPNET de tal manera que todos aquellos paquetes que contengan igual DSCP recibirn idntico tratamiento durante su envo. Esta arquitectura logra dar servicios diferenciados a trfico agregado, es decir, se proporciona un tratamiento por clase, no por flujos; sin embargo se requiere la consideracin de mecanismos complicados para negociar los acuerdos del nivel de servicio. Todo ello, adems de requerir supervisin de trfico, clasificacin, conformacin, 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 propagacin: sta es una fuente de retardo ineludible y se define como el tiempo que se produce durante la transmisin de los datos desde su origen hasta su destino final, directamente relacionada con la velocidad de la luz. Por lo tanto, es funcin de la distancia que tiene que recorrer. El retardo total de la propagacin 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 envo hasta que es recibido por el usuario final. Estos procesos son codificacin y empaquetado, que se llevan a cabo en el emisor, y decodificacin 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 conmutacin introducidos por los routers como resultado de la clasificacin, almacenamiento temporal (colas de entrada y salida) y conmutacin. - Retardo de transmisin: Es el tiempo que se tarda en transmitir un paquete. Este retardo est en funcin de la velocidad de la lnea de transmisin y la longitud del paquete. Sumado a todos los retrasos especificados, el retardo extremo-a-extremo se ve afectado adems por otro factor: fluctuacin o jitter. El transmisor enva cada paquete de una aplicacin 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 variacin del retardo al llegar al receptor entre paquetes consecutivos de un flujo transmitido se denomina jitter.
2.2.3.2 Prdida de paquetes y corrupcin de datos

Cuanto mayor sea el nmero de paquetes consecutivos (o longitud de la rfaga) que se pierdan o se daen, mayor ser la degradacin de la calidad suscitada. Las prdidas de paquetes pueden 27
ocurrir por el descarte generado en una situacin de congestin en un router intermedio o como consecuencia de errores provocados por el medio fsico de transmisin.
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 prevn 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 trfico. Este protocolo orientado a conexin es utilizado por un rango de diferentes aplicaciones como son HTTP/HTTPS (WWW), FTP (transferencia de archivos) y SMTP/POP3/IMAP (correo electrnico) entre otras.
Ilustracin 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 informacin del contenido de la cabecera y del segmento TCP, con los cuales el receptor puede verificar si el dato recibido es correcto o no. Adems, los segmentos pueden perderse como consecuencia de errores o por la congestin en la red. Si el paquete es recibido con xito el receptor enva un paquete de confirmacin (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 despus de un tiempo apropiado (se cumple un time-out o expiracin de temporizadores). 28
Control de Congestin con OPNET Alternativamente a TCP, otro protocolo de transporte utilizado en Internet es UDP. ste est especialmente indicado para las aplicaciones multimedia (audio y vdeo), las cuales prefieren pocos retardos, an asumiendo que la capa de transporte no proporcione fiabilidad ninguna. Es decir, UDP no ofrece control de congestin 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 garanta alguna de fiabilidad en la entrega, por lo que no van protegidos frente a las prdidas en la red durante la congestin. Esto se puede traducir en una posible degradacin de la calidad.
2.3.2 Control de congestin en TCP

A diferencia de UDP, el protocolo TCP garantiza la transmisin fiable de los paquetes. Para ello, adems de mecanismos que proporcionan control de errores, incorpora mecanismos para el control de congestin con el propsito de lograr que TCP reaccione rpidamente en condiciones de alta congestin, lo cual lo convierte en un importante mecanismo a tener en cuenta tambin a la hora de proveer QoS. Si una fuente de informacin TCP detecta que en la transmisin de sus paquetes empieza a haber problemas, (es decir, detecta prdidas mediante la expiracin de los temporizadores arbitrados para la recepcin de las correspondientes confirmaciones), asume que dichas prdidas son siempre debidas a problemas de congestin. Como medida reactiva, en ese caso TCP reduce drsticamente la tasa de transferencia con la esperanza de reducir el nmero de paquetes perdidos o descartados.
2.3.2.1 Arranque lento y prevencin de la congestin

Arranque lento (slow start) y prevencin de la congestin (congestin 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 congestin incluso cuando se generen grandes rfagas de paquetes. Estos mecanismos de control tienen objetivos diferentes pero son implementados en conjunto. Para su operacin requieren la definicin de dos variables por cada conexin TCP: la ventana de congestin cwnd, que determina la cantidad de bytes que el remitente puede transmitir sin necesidad de ser confirmados, y la ventana de recepcin, rwnd que especifica el nmero de bytes que el receptor tiene capacidad para recibir. Para una conexin dada, la cantidad mxima a transmitir estar acotada por el valor mnimo de cwnd y rwnd. Al establecerse la conexin TCP, el transmisor asigna a cwnd el tamao mximo de segmento para la conexin y por lo tanto enva un paquete con ese tamao. Al mismo tiempo, mantiene un temporizador de retransmisin 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 expiracin 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 congestin permanece con ese ritmo de crecimiento hasta que ocurre una de las dos posibles alternativas: se alcance el valor acotado de rwnd o se alcance un umbral establecido de antemano denominado ssthresh. 29
Cuando la ventana alcanza el valor ssthresh, TCP pasa a la fase de Prevencin de la Congestin, 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 Prevencin de la Congestin hasta que se detecta la prdida de paquetes (se asume por expiracin 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 tamao actual de la ventana. En definitiva, lo que se pretende con el arranque lento y la prevencin de la congestin es incrementar la tasa de generacin de trfico, mientras no haya problemas y la capacidad de salida lo permita.
Ilustracin 5. Ventana de congestin y cola en TCP
2.3.2.2 Retransmisin Rpida y Recuperacin Rpida

Adems de los anteriores, en TCP se aaden 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 congestin. Tras esta eventualidad, TCP infiere que ha habido una prdida y reacciona (entra en fase de retransmisin rpida) transmitiendo nuevamente el que parece ser el segmento perdido, sin esperar a que el correspondiente temporizador de transmisin expire. Tras realizar el procedimiento Retransmisin Rpida, la entidad TCP emisora entra en la fase denominada Recuperacin Rpida, que es ahora quien controla la retransmisin 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 transmisin. En caso de que nunca llegue un nuevo ACK, el emisor permanecer en la fase de recuperacin rpida hasta que ocurra la expiracin de un 30
Control de Congestin con OPNET temporizador. Estos algoritmos permiten la recuperacin rpida de paquetes que se han perdido espordicamente, sin embargo suele haber problemas para recuperar cuando mltiples 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 prdida de segmentos. Se incluye Fast Retransmit para poder hacer la retransmisin de segmentos perdidos lo ms rpidamente posible sin esperar a que expire el time-out.
Reno
La ventana de congestin crece segn Slow Start hasta llegar a un umbral previamente definido a partir del cual comienza fase de prevencin de la congestin creciendo la ventana de forma lineal. Es Tahoe con Fast Recovery que evita, en lo posible, que el tamao de la ventana llegue a dos y se inicie la fase Slow Start en redes que presentan una determinada congestin con picos de gran congestin. El inconveniente ms destacado es que, en caso de tener mltiples prdidas por ventana, el protocolo de Rapid Retransmit no puede recuperar de forma rpida ms que la primera prdida. New Reno
Intenta solventar los inconvenientes de Slow Start y Congestion Avoidance en relacin al tamao del ssthresh. Intenta buscar un valor de umbral inicial ptimo para el estado de la red mediante el algoritmo Packet-Pair. La fuente enva series de dos paquetes conociendo el intervalo de tiempo entre ambos. Segn llegan los ACK se va conociendo el retardo y por tanto el estado de la red, la situacin de congestin, etc. Tambin propone una modificacin del algoritmo Fast Recovery de forma que en caso de existir varias prdidas 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 ms relevante, no obstante, es la propuesta a actuar contra la congestin antes de que sta se detecte por la expiracin del temporizador de retransmisin. TCP Vegas introduce un algoritmo para la prediccin de la cantidad de datos que el enlace puede cursar sin congestin, e inyecta en el enlace dicha cantidad. Esta prediccin se basa en medidas de caudal.
31
2.4 QoS dentro de los Routers

Los mecanismos de control de congestin 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 prevencin de la congestin. La tarea principal de un router es interconectar redes y encaminar paquetes entre ellas. Cuando un transmisor enva 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. Despus, dependiendo de varios parmetros, el router debe tomar la decisin 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, prdidas de paquetes. Los routers que soportan QoS tienen las funciones definidas en los siguientes apartados
2.4.1 Clasificacin
La clasificacin de paquetes se puede hacer basndose slo en el campo ToS de la cabecera de un paquete IP en campos adicionales como la direccin IP y el nmero de puerto de la fuente y destino o en el tipo de aplicacin. La clasificacin es til para determinar la interfaz de salida de los paquetes entrantes, adems del bfer particular necesario para el almacenamiento, o la reserva de un ancho de banda de salida.
2.4.2 Gestin de colas

Slo el control de flujo y congestin extremo-a-extremo TCP, como se ha dicho, no es suficiente,. Puede ser que la congestin ocurra tambin cuando la magnitud del trfico excede la capacidad de transmisin y procesamiento de los nodos intermedios. Los buffers son usados para absorber ste exceso de trfico. Sin embargo, por razones de espacio (el tamao de un bfer es limitado), los routers tienen que marcar o descartar el exceso de trfico para que as TCP detecte congestin y reduzca su tasa de transmisin. Los routers no pueden dejar todo el control de congestin a TCP, pues sin los algoritmos de gestin de colas, al producir descarte de paquetes, se incrementara la tasa de retransmisin por parte de TCP, incrementando an ms la congestin. Los algoritmos de gestin de cola se dividen en dos categoras: Gestin Pasiva de Colas (PQM, Passive Queue Management), descartan paquetes slo cuando la cola alcanza su capacidad, o algn valor especfico. Dentro de ste tipo est el tradicional Drop Tail. Gestin Activa de Colas (AQM, Active Queue Management), descartan paquetes preventivamente antes de que la cola alcance su capacidad mxima. Este tipo de algoritmos se explicarn con mayor detalle en la prxima seccin.
32
2.4.3 Planificacin de colas

Las disciplinas gestin y planificacin de colas trabajan conjuntamente para controlar el trfico de la red a nivel de router. Se ha explicado que la gestin de colas intenta evitar la congestin descartando los paquetes apropiados. Sin embargo, si los paquetes estn esperando mucho tiempo para su transmisin, y llegan a mayor ritmo del que son enviados, entonces aumenta el retraso en la cola (queuing delay), provocando congestin. Para evitar esta situacin, los algoritmos de planificacin de colas trabajan seleccionando el siguiente paquete a ser transmitido de entre todos los paquetes que estn esperando. Existen varios mecanismos de planificacin, entre ellos se ha considerado oportuno citar los siguientes:
2.4.3.1 FIFO (First In First Out)

Es la disciplina de planificacin por defecto, y la ms utilizada. Los paquetes se envan 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 mximo valor de queuing delay a partir de la capacidad del buffer. De ah se deduce que el retraso ser pequeo si la cola tiene poca capacidad, y aumentar si el tamao de sta se hace mayor. FIFO trata de igual manera a las diferentes clases de trfico, y a los distintos flujos.
Ilustracin 6. Planificacin de Colas FIFO
2.4.3.2 Colas de prioridad ( PQ, Priority Queueing)

Se clasifica el trfico 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 enva un paquete slo si no hay paquetes en colas con prioridades superiores. Es un esquema til en situaciones en que se produce trfico de alta prioridad, como ocurre en casos de aplicaciones de tiempo real o VoIP. Sin embargo, si la proporcin de ste tipo de trfico es muy grande, el trfico con menor prioridad puede sufrir demasiado retardo, al igual que una alta tasa de prdida de paquetes, desembocando en una situacin de inanicin. 33
Incluso en caso de trfico de alta prioridad compartiendo la misma cola de prioridad, un flujo de trfico 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, diseada 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 trfico 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 segn el algoritmo Round Robin.
Ilustracin 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 ms dominantes que otros, solucionando el problema que tena 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 tamao de los paquetes, y paquetes mayores necesitaran ms ancho de banda.
2.4.3.4 WFQ (Weighted Fair Queueing)

sta disciplina fue diseada para mejorar FQ, especialmente ofreciendo diferenciacin de servicio en trminos de ancho de banda, satisfaciendo las demandas de las diferentes aplicaciones. WFQ reparte los recursos de la red entre los distintos flujos basndose 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 dems.
34
2.5 Gestin Activa de Colas

Este captulo intenta proporcionar una visin general de cmo trabajan los algoritmos de gestin activa de colas, centrndonos despus en el algoritmo RED, por ser uno de los puntos centrales de estudio de ste proyecto en cuanto al anlisis de OPNET se refiere, y por ser considerado en muchas publicaciones como punto de partida o esquema de referencia para posteriores algoritmos de gestin activa de colas. Por ltimo, se describir otro algoritmo basado en RED con el que se ha trabajado en este proyecto.
2.5.1 Introduccin y fundamentos de los AQM

La Gestin Activa de Colas es una clase de algoritmos que intentan prevenir la congestin descartando paquetes o marcando paquetes en el router comprometido. Estos utilizan una aproximacin probabilstica para reaccionar a las condiciones de congestin. Por lo general, para amortiguar las diferencias entre la razn de llegadas y la de salidas, las interfaces de salida de los routers disponen de un buffer o memoria temporal donde los paquetes sern 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 congestin, 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 tcnica de gestin de colas ms habitual utilizada en los routers de Internet es el drop tail. En los routers que adoptan esta tcnica, los paquetes que van llegando son temporalmente aceptados y almacenados hasta que un determinado tamao mximo de la cola, especificado en nmero de paquetes, sea alcanzado. Cuando la cola se llena, los siguientes paquetes que llegan sern descartados mientras que la ocupacin de la cola no decrezca. Drop tail, si as lo permite el trfico de llegada, tiende a mantener la cola al mximo nivel de ocupacin durante largos perodos 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 gestin activa de colas. En AQM, cuando un router detecta una incipiente congestin, 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 ms despacio, evitando colas sobresaturadas, de tal forma que AQM es capaz de soportar mayores rfagas de trfico. Esto no es posible lograrlo si se utiliza drop tail, que mantiene casi al mximo la capacidad de la cola y no deja espacio suficiente para albergar rpidos crecimientos de trfico o rfagas. Aunque los mecanismos implementados en TCP restringen la tasa de envo, no son capaces de recuperar tan fcilmente los paquetes descartados cuando ocurre una rfaga, es menos costoso cuando se trata de recuperar un solo paquete descartado. Por otra parte, operar con una baja ocupacin en los routers reduce el retardo de transmisin extremo-a-extremo, dado que cuando la ocupacin media de las colas de salida tienda a cero, el retardo introducido tender a su vez a cero tambin. 35
En resumen, la idea esencial de la implementacin de AQMs consiste en reemplazar la tcnica tradicional de gestin pasiva de colas drop tail con el fin de proporcionar un mejor rendimiento en la red en trminos de utilizacin de las lneas, probabilidad de prdida de paquetes y del retardo extremo-a-extremo.
2.5.1.1 Notificacin Explcita de la Congestin (ECN)

Para el control de congestin, junto con AQM se incorpora la as denominada Notificacin Explcita de la Congestin (ECN, Explicit Congestion Notification). Esto se resume en que los paquetes pueden ser marcados (en lugar de descartados) si se sufre congestin utilizando un bit ECN en la cabecera IP de cada uno de ellos (si ste bit tiene el valor 1, indica congestin), y ser enviados a los nodos. Con esta alternativa, se est notificando a los siguientes routers que ese paquete ha sufrido congestin. El nmero y seleccin de paquetes que son marcados durante una congestin dependen de las polticas AQM que se establezcan.
2.5.2 Random Early Detection (RED)

El algoritmo Random Early Detection (Deteccin Temprana Aleatoria) fue desarrollado en 1993 por Floyd y Jacobson. Es uno de los primeros y ms relevantes esquemas para evitar la congestin en la arquitectura de Internet. RED detecta la congestin estimando la ocupacin media de la cola siempre que llega un paquete a ella. Este algoritmo pretende evitar el descarte y posterior prdida 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 ocupacin 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 funcin del tamao 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 utilizacin del ancho de banda de salida de la cola y la reaccin temprana o prevencin de la congestin. Una vez terminada la necesidad de notificar la congestin (esto es cuando la cola supera una ocupacin determinada) RED selecciona con algn criterio una fuente emisora (de entre las que tienen paquetes en la cola) y le notifica la congestin para que sta pueda bajar su tasa de transmisin. RED es independiente del mecanismo de notificacin adoptado, el cual puede ser tanto marcando como descartando el paquete). RED logra mantener un bajo nivel de ocupacin medio de la cola mientras permite ocasionalmente rfagas de paquetes. Tngase en cuenta que el objetivo ltimo de todo algoritmo de gestin activa de colas es mantener la ocupacin media de la cola siempre al menor valor posible, ya que as el retardo que sufra cada paquete ser menor. Estudiemos con ms detalle el funcionamiento de RED: para su operacin, se designan dos umbrales, un umbral mnimo (Minth) y un umbral mximo (Maxth). Estos son comparados con una estimacin de la ocupacin media de la cola (Qavg), que se calcula mediante un filtrado paso bajo (utilizando el parmetro wq) del tamao instantneo de la cola. En las siguientes figuras se muestra un ejemplo de curva que caracteriza el comportamiento de RED, representndose para cada valor del tamao medio de cola (Qavg) la correspondiente 36
Control de Congestin con OPNET probabilidad de notificacin (Pd). Ntese, que en general cuanto mayor es la ocupacin media mayor ser la probabilidad de notificacin. En la otra, se aprecia el valor que va tomando el tamao medio de cola con respecto al tamao instantneo (real) de la cola del router.
Ilustracin 8. Comparacin entre el tamao real de cola y el valor que toma Qavg
El tamao de cola medio se estima cada vez que llega un paquete. El clculo se realiza de la siguiente manera:
Qavg = (1 q) Qavg + q Q
Hay un caso especial en el clculo del parmetro Qavg, cuando el paquete llega a una cola que est vaca. En ese caso, RED calcular este parmetro teniendo en cuenta cuando fue la ltima vez que la cola estuvo vaca. RED establece tres estados de operacin que se determinan haciendo la comparacin entre los dos umbrales y la Qavg estimada. El comportamiento de RED depender del resultado obtenido: Cuando la ocupacin media de la cola (Qavg) es menor que Minth .
Esta situacin es considerada como el estado normal de operacin. Aqu, ningn paquete es marcado o descartado, simplemente se encola. Cuando la ocupacin media de la cola est entre Minth y Maxth .(Minth<Qavg<Maxth)
Se pone en marcha el mecanismo de prevencin de congestin. Los paquetes que lleguen sern notificados con una probabilidad Pd . Cuando la ocupacin media de la cola sea mayor que Maxth.
El paquete se descarta directamente, por ser considerado un nivel de riesgo de congestin. 37
La probabilidad de descarte de paquetes se calcula de la siguiente forma:
Pd = Maxp (Qavg Minth) / (Maxth Minth )

Siedo
Maxp la mxima probabilidad de descarte de paquetes.
La ejecucin del algoritmo RED depende por lo tanto de dos procedimientos diferentes: de cmo se estime el tamao medio de cola (Qavg) y de la probabilidad de descartes. En RED, tanto la probabilidad de descartes como el descarte forzado no dependern en ningn momento del tipo de flujo al que pertenezca el paquete en cuestin, sino que slo est determinado por el nivel de congestin que se experimente en el router en ese momento. Uno de los problemas de este algoritmo est relacionado con la configuracin de sus parmetros, ya que una mala configuracin puede significar un mal funcionamiento del algoritmo. Otro problema es que el parmetro 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 modificacin del algoritmo RED propuesto tambin por Floyd y Jacobson. En RED, cuando el tamao de cola medio es alto, la probabilidad de descarte aumenta drsticamente de max_p a 1. De ah se deduce que el tamao medio de cola se vuelve inestable a medida que su valor aumenta. Gentle RED soluciona este problema moderando la variacin de la probabilidad de prdida en esas ocasiones, es decir, cuando el tamao medio de cola supera el umbral mximo. Aunque se ha estudiado detalladamente el algoritmo RED, no pasa lo mismo con GRED, no se ha podido encontrar mucha informacin acerca del mismo y de su comportamiento en distintas circunstancias. A continuacin se explica brevemente el funcionamiento de este algoritmo. 38
Control de Congestin con OPNET El algoritmo GRED es bsicamente el mismo que se ha explicado en RED, con alguna modificacin como veremos ms adelante. Para el clculo del tamao de cola medio o Average Queue Size se mantiene el mecanismo de RED, es decir, por cada paquete que llega se actualiza el parmetro de la siguiente manera:
Qavg = (1 q) Qavg + q Q
donde Qavg es el tamao medio de cola, wq un parmetro de control y cola del router en cada instante.
Q es el tamao real de la
En cuanto a la funcin para calcular la probabilidad de descarte, est tambin basada en la ocupacin media de la cola, pero en GRED la probabilidad de descarte se incrementa lentamente entre Maxp y 1, mientras que la ocupacin media de la cola vara entre Maxth y 2*Maxth:
Pd_gred = Maxp (Qavg Minth) / (Maxth Minth) Pd_gred =(1- Maxp)(Qavg Maxth) / (Maxth) + Maxp
Si Minth<Qavg<Maxth Si Maxth<Qavg<2*Maxth
Es decir, GRED no descarta paquetes de manera tan agresiva cuando se llega al umbral mximo, slo 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 grficas, es cada vez mayor. En las dos grficas siguientes se muestra la diferencia en la probabilidad de descarte en ambos algoritmos:
Ilustracin 10. Probabilidad de descarte de RED y de GRED
GRED tiene una gran ventaja, ya que, como se ve en el grfico, descarta paquetes de forma menos agresiva que su antecesor RED. Veremos la desmostracin de esto en el captulo 5.
39
40
Captulo 3.Introduccin Terica al Simulador OPNET
3.1 Introduccin
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 compaa que lo comercializa fue fundada en 1986 y se introdujo en el mercado en el ao 2000. Permite disear y estudiar redes, dispositivos, protocolos y aplicaciones. Est basado en la teora de redes de colas e incorpora las libreras para facilitar el modelado de las topologas de red. Soporta un amplio rango de tecnologas tipo LAN, MAN y WAN.
Ilustracin 11. Pantalla de inicio del Simulador OPNET
41
Captulo 4. Implementacin del algoritmo RED en OPNET
OPNET Modeler utiliza distintos niveles de modelado o paradigmas para representar los diferentes componentes de una red. Cada nivel est asociado a un dominio y a un editor. Para hacer el desarrollo ms intuitivo al usuario, los editores se organizan jerrquicamente, 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 tambin 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 configuracin de las estadsticas que se quieren obtener durante una simulacin).
Ilustracin 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 ms detalladamente, los objetos aportan una forma natural de describir la estructura de las redes de comunicaciones. Adems de capturar las caractersticas fsicas de los componentes del sistema, los objetos pueden ser usados para representar su descomposicin e interconexin interna. Ejemplos de objetos fsicos de las redes usadas para ste proyecto seran: router, switch, servidor, cliente y links, en definitiva, los componentes que forman las redes, y a los que se tiene acceso a travs de la paleta de objetos del Project Editor. Tambin existen objetos abstractos como 42
Control de Congestin con OPNET procesos (se hablar ms tarde de ellos) o contadores, pero son dinmicos, y no forman parte de la estructura del sistema. Los trminos objeto y modelo en OPNET estn 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, podramos decir que ese modelo es una clase. Esto es porque OPNET est fuertemente unido a la programacin orientada a objetos, ya que as se proporciona una forma centralizada de controlar un gran nmero de objetos: hacer cambios en un modelo implica que todos los objetos creados a partir de l incorporarn ese cambio. Un modelo incluye la informacin comn a todas sus instancias. Esto incluye especificaciones de interfaz de los objetos, comportamiento, y estructura interna. La interfaz describe cmo un objeto interacta con su entorno, incluyendo especificaciones relacionadas con interconexiones fsicas y mecanismos de comunicacin con otros objetos. Adems de las interfaces de los objetos, los modelos describen su comportamiento. Es decir, cmo reaccionan a estmulos externos y cmo actan. Por ejemplo, un cliente, es un objeto que en algn momento actuar generando trfico. El comportamiento de un objeto suele depender de varias variables, como informacin de estado, estmulos externos, tiempo o variables aleatorias. Esto se implementar mayoritariamente mediante un modelo de procesos, que se explicar en otro apartado. Finalmente, entre la informacin del modelo est, como se ha dicho antes, la estructura interna del objeto. Esto se representa con la descomposicin 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 estn especificados en trminos de objetos llamados mdulos y conexiones. Un ejemplo de modelo de nodos sera el que define el comportamiento de un router, dentro del cual se encuentra el mdulo 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 caractersticas de ste que se consideran privadas y permanecen escondidas en su interior. Otras, se consideran tiles para mostrar al usuario. Esas caractersticas pblicas 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 caractersticas seleccionadas de un objeto y permitir que esas caractersticas sean modificadas por el usuario para una aplicacin especfica. Para ste proyecto el concepto de atributo ha sido muy importante, pues, por poner un ejemplo de aplicacin, 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 cmo modificar o crear o configurar los atributos.
3.2 Dominio de Red (Network Domain)

El papel del Dominio de Red es definir la topologa de una red de comunicaciones. Las entidades de comunicacin se llaman nodos y las capacidades de cada nodo estn definidas mediante su
43
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 topologa podr contener tantos nodos y modelos de nodos como el usuario crea conveniente. Los usuarios pueden desarrollar su propia librera de modelos de nodo, implementando la funcionalidad requerida para cada caso. El editor de proyectos (Project Editor) aporta un contexto geogrfico para el desarrollo de un modelo de red. Se pueden elegir localizaciones en el mapa del mundo o en el de un pas para redes de rea extensa o WANs, y reas dimensionadas para redes de rea local o LANs. sta caracterstica, adems de ayudar a crear un entorno intuitivo a la hora de modelar, aade a la red una nocin de distancia, til para despus calcular retardos de comunicacin entre nodos. La mayora de los nodos necesitan la habilidad de comunicarse con otros para llevar a cabo su funcin 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 emisin de datos a un conjunto de nodos. Adems 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 topologa se usan subredes. Una subred es una agrupacin 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 jerarqua en la que el nivel ms bajo est compuesto slo por nodos y links.
3.3 Dominio de nodos (Node Domain)

El dominio de nodos proporciona el comportamiento de los dispositivos de comunicacin 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 mdulos. Cada uno de ellos contiene un conjunto de entradas y salidas, memoria de estado, y un mtodo para obtener las salidas a partir de las entradas y la informacin en la memoria. El procesamiento depende del tipo de mdulo. Algunos tienen un comportamiento predefinido con algn propsito especfico, mientras que otros pueden ser definidos por el usuario. La forma de unir las entradas y salidas de los distintos mdulos 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 mdulo puede enviar paquetes a travs 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 travs de output statistics y recibirlos de input statistics. Tambin existen las asociaciones lgicas entre mdulos, pero no tienen inters a nivel de modelado, salvo por simplificar la comprensin del modelo de nodos. 44
3.3.1 Mdulos
Los mdulos representan aquellas partes del modelo en que se genera, consume o procesan datos. Hay varios tipos de mdulos, dependiendo de su funcin 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 transmisin 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 mdulo IP, definido mediante el modelo de procesos ip_dispatch y sus hijos. Sin embargo, otros mdulos tienen un comportamiento ya predefinido, slo modificable cambiando el valor de sus atributos. El algoritmo interno de un mdulo se invoca cuando se produce un evento externo que afecta al estado de ese mdulo. Esto es a consecuencia del mtodo de simulacin por eventos que emplea OPNET. A continuacin se describen los mdulos que se han considerado ms relevantes en ste proyecto.
3.3.1.1 Procesador
Icono de un procesador en el editor de nodos
Este tipo de mdulos es el ms 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 mdulo. ste puede responder a eventos externos o interrupciones segn el comportamiento que est implementando. Los procesadores se pueden conectar a otros mdulos para intercambiar paquetes a travs de packet streams. Un procesador tambin se puede usar como controlador dentro de un modelo de nodos. En ese caso se comunicar con otros mdulos a travs de cables estadsticos o interrupciones remotas. Como todos los objetos, un procesador tiene atributos para configurar su comportamiento, y pueden ser especificados usando la interfaz grfica 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 aadir nuevos atributos, que automticamente sern heredados por el mdulo procesador.
3.3.1.2 Cola
Icono de una cola en el editor de nodos
Al igual que los mdulos procesador, un mdulo cola puede ejecutar un modelo de proceso que describe el comportamiento de un determinado protocolo, y puede estar conectado a otros 45
mdulos a travs de packet streams, pudiendo enviar y recibir paquetes. El modelo de proceso tambin afectar en ste caso a la lista de atributos que posea el mdulo. 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 gestin de la coleccin de paquetes guardada en ellas. As se proporciona al usuario una manera ms sencilla para implementar disciplinas de cola. Cada cola contiene un nmero definido de subcolas subordinadas a ella, con sus propios atributos. Al poder controlar el comportamiento del mdulo 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 mdulos transmisores actan 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 comunicacin: punto a punto y bus. Ambos se diferencian en sus mecanismos de comunicacin. Dentro de un modelo de nodo, los transmisores son considerados sumideros de datos. Desde el punto de vista del modelo de red, stos mdulos actan como puertos de salida del nodo a los que conectar los links. En la siguiente ilustracin se aprecia el papel de stos mdulos en una red:
Ilustracin 13. Interaccin de un mdulo transmisor con el modelo de nodos y el de red
46
3.3.1.4 Receptor:
Iconos de receptores punto a punto y bus en el editor de nodos
Un mdulo 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 mdulos receptores: punto a punto y bus. Los receptores pueden distribuir los paquetes ente uno o varios output packet streams despus de obtenerlos del link. Dentro de un modelo de nodos, los receptores son considerados fuentes de trfico, 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 mdulos 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 mdulo destino hasta uno fuente. Representan el flujo de datos a travs de las interfaces hardware y software dentro de un nodo de comunicaciones. No tienen errores de transmisin ni retrasos, ni lmite de ancho de banda. De hecho, tienen capacidad ilimitada para almacenar los paquetes en orden de llegada al mdulo destino. OPNET proporciona tres mtodos para transferir un paquete a travs de un stream y notificar al mdulo de su llegada: planificado, forzado y silencioso. Con la versin planificada, llega una interrupcin de canal o stream interrupt y se espera hasta que llegue el turno de recoger el paquete. Con la forzada, cuando la interrupcin ocurre, el paquete es procesado inmediatamente, sin ejecutar los evento que hubiera antes. Con la ltima forma, no hay interrupcin: el paquete se almacena en el buffer hasta que el mdulo lo solicite.
3.3.2.2 Statistic Wires

Transportan datos desde un mdulo fuente hasta uno destino. Cada statistic wire transporta un valor individual. Se usan generalmente como interfaces en las que el mdulo fuente comparte ciertos valores con el destino, incluida informacin de estado. Tambin son usados como mecanismos de sealizacin, permitiendo que el mdulo origen informe al destino cuando una condicin particular de inters se ha cumplido. Cada mdulo dentro de un nodo tiene un conjunto de local output statistics cuyos valores son actualizados durante la simulacin. Este conjunto de estadsticas es el que acta como fuente de los statistic wire. En concreto, los procesadores y colas tienen estadsticas cuya manipulacin e interpretacin est definida por el modelo de proceso, y cuya actualizacin se 47
produce cuando dentro de ste se llama a un procedimiento predefinido en OPNET, op_stat_write(). Otros mdulos sin embargo tienen unas estadsticas predeterminadas que son actualizadas automticamente 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 algn otro componente dentro de un nodo. Segundo, permiten que un mdulo 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 simulacin. Simplemente sirven como mecanismos de especificacin: indican que hay relacin entre dos mdulos 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 pertenecern 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 pblicas ciertas caractersticas del modelo de nodos y permitiendo que se modifiquen, los modelos se hacen ms aptos para la reutilizacin 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 mdulos del modelo de nodos. Por esto, dependiendo del mbito de utilizacin de los atributos, se declaran en el modelo de procesos (si se van a necesitar a nivel de implementacin 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 mdulos 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 comunicacin, 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 comunicacin. A partir de este punto, para facilitar la lectura, se llamar a los procesadores o colas con las abreviaturas QP. Para proporcionar una funcionalidad particular dentro de un QP, se pueden definir 48
Control de Congestin con OPNET uno o varios procesos. Un proceso es una instancia de un modelo de proceso, definido mediante el Editor de Procesos.
3.4.1 Entorno de un Proceso

En este apartado se describe el contexto en el que trabajan los procesos en OPNET.
3.4.1.1 Ejecucin 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 interrupcin. Una de las primeras acciones que realiza un proceso al recibir una interrupcin es determinar su tipo. Siempre que empieza la ejecucin de un proceso, ste est en modo de reposo o bloqueado, esperando a ser invocado. Una invocacin por tanto permitir al proceso reanudar su ejecucin 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 simulacin al principio y al final de una invocacin no vara, es decir, una invocacin no consume tiempo.
3.4.1.2 Procesos Dinmicos

Cuando comienza la simulacin, cada QP aloja slo un proceso, que es automticamente 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 raz, y puede crear durante la simulacin otros procesos que cooperan para hacer la tarea designada. A los procesos que son creados por otros procesos se les denomina procesos dinmicos.
Jerarqua de procesos
Debido a la metodologa de creacin de procesos dentro de un QP se puede establecer una jerarqua en la cual el proceso raz es el padre y los procesos que ste crea los hijos, los cuales, a su vez, podran crear otros y as sucesivamente, creando una estructura de rbol, como se puede ver en la figura de la siguiente pgina. No hay lmite en el nmero de generaciones. Adems de crear procesos, se pueden borrar tambin, con los que la jerarqua de procesos dentro de un QP vara dinmicamente durante la simulacin. 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 jerarqua. En la siguiente figura se muestra un esquema con ste tipo de jerarqua.
49
Ilustracin 14. Jerarqua 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). Adems, 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 estn declarados en una lista. Esa lista forma parte de la implementacin de cada modelo de proceso y debe ser declarada antes de la simulacin e instanciacin 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 informacin. Hay tres mecanismos de comunicacin: - Memoria compartida a nivel QP (module memory): los procesos de la jerarqua comparten la informacin guardndola en un rea comn definida por el QP, en forma de estructura de datos . Los procesos asignan y obtienen la direccin 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 definicin de ella en su bloque de cabecera o header block, accesible desde el editor de procesos. - Memoria compartida padre-hijo: Es un rea privada que se crea a la vez que el proceso hijo con el que se comparte. Otros procesos no tienen acceso a ella (cada uno tiene su propia memoria con su proceso padre). El Kernel mantiene por lo tanto un bloque de memoria para cada par padre-hijo del sistema. 50
Ilustracin 15. Memoria padre-hijo en una jerarqua de procesos
Un proceso hijo obtiene la direccin 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 direccin de un bloque de memoria. As, el proceso invocado obtiene parmetros 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 invocacin se debe pasar una direccin de memoria.
Operaciones con Procesos Dinmicos
Como se dijo antes, un proceso raz puede crear varios procesos hijos. Esto lo hace mediante la funcin op_pro_create(). Cuando esto sucede, el nuevo proceso se aade automticamente a la jerarqua del padre. Como resultado de sta operacin se devuelve un valor, el process handle, que es el identificador del nuevo proceso dentro de todo el sistema (no slo en la jerarqua). Este es un nmero nico para cada proceso, y se puede acceder a l mediante op_pro_id(). Ciertos procesos dinmicos tienen un tiempo de vida reducido al tiempo que tarden en realizar la tarea encomendada. En cuanto acaban, se le elimina de la jerarqua para no consumir recursos mediante la funcin op_pro_destroy, que puede ser empleada por otros procesos, o por ellos mismos. Slo puede haber un proceso ejecutndose a la vez. Se considera que un proceso est en ejecucin cuando progresa a travs de las instrucciones que forman parte de su modelo. Cuando un proceso necesita invocar a otro (anteriormente creado), lo hace mediante la funcin op_pro_invoke(). A partir de sta llamada, el proceso invocador se bloquea, cediendo el control del hilo de ejecucin al proceso invocado, el cual realiza su tarea y cuando acaba devuelve el control al proceso que lo llam, que contina ejecutndose donde lo haba dejado. Ntese que cuando un proceso invoca a otro, se a su vez puede invocar a otro y as sucesivamente, comportndose como un mecanismo de llamadas orientado a pila, con lo cual, no soporta recursividad (porque los procesos, una vez van invocando a otro, permanecen 51
bloqueados hasta que acaba la llamada). S que podra existir no obstante entre distintas instancias de un mismo proceso de modelo, invocndose una a la otra. Durante la invocacin, el proceso invocado puede acceder a cualquiera de los recursos del QP como por ejemplo paquetes o estadsticas. Por ello, hay que tener en cuenta que despus de una invocacin, ciertos valores pueden haber cambiado. Todas las operaciones aqu citadas para manejar los procesos dinmicos 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 estn ya definidas y se pueden usar directamente en el cdigo de los modelos de proceso, lo cual facilita mucho la tarea de implementacin de nuevos protocolos o aplicaciones dentro de OPNET. Hay informacin muy extensa sobre estos procedimientos en la documentacin del programa que conviene estudiar antes de entrar en detalles de cdigo.
Control de interrupciones
Una interrupcin indica que ha ocurrido un evento de inters en el sistema, como puede ser la expiracin de un temporizador o la llegada de un paquete. Cuando un proceso recibe una interrupcin, realiza una accin como respuesta y se bloquea, esperando una nueva interrupcin. Los modelos de proceso usan procedimientos predefinidos para obtener la informacin acerca del tipo y origen de la interrupcin. En la mayor parte de los casos, las interrupciones poseen informacin adicional a la que los procesos acceden para determinar qu accin llevar a cabo. Por ejemplo, una interrupcin 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 raz, el cual luego elige a quin invocar para que realice las operaciones debidas. Sin embargo, determinados procesos pueden solicitar recibir ciertos eventos, basndose 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 implcitamente 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 mdulos con otros, como hemos visto. Concretamente, comunican estructuras dinmicas en los nodos fuente y emisor llamadas output e input streams respectivamente.
52
Control de Congestin con OPNET Un input stream dentro de un QP recibe paquetes de fuentes externas. Los paquetes son automticamente 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 dinmicamente segn sean necesarios para soportar las entregas, pues Simulation Kernel no sabe de antemano el rango de canales que sern utilizados. Cuando se recibe un paquete en un input stream, se invoca uno de los procesos del QP mediante una interrupcin de canal (stream interrupt). El proceso determinar por qu canal llega el paquete llamando a la funcin 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().
Ilustracin 16. Esquema de input streams en un QP.
El lado opuesto al anterior de un packet stream es el output stream. Estos canales efectan la comunicacin de paquetes mediante las funciones del tipo op_pk_send(). Los output streams tambin tienen un ndice asociado, pero slo sern vlidos aquellos que estn asociados a un objeto fsico packet stream.
Estadsticas (Input Statistics y Local Output Statistics)
Ambos tipos de estadsticas forman los extremos de los statistic wires, vistos en el modelo de nodos.
53
Las input statistics son construcciones internas que aceptan valores numricos enviados por otros mdulos dentro del mismo nodo. Estas construcciones estn identificadas por un entero, y slo retienen el ltimo valor que ha llegado desde statistic wire (no hay buffer, al contrario de como ocurra en los output/input streams). Cuando hay varios statistic wire conectados a un mismo input statistic, el ltimo valor de la ltima estadstica que se haya actualizado es el que prevalece. Ese valor es accesible para cualquier proceso del mdulo mediante op_stat_local_read(). Las local output statistics son el otro extremo del cable, y se denominan local para diferenciarlas de las estadsticas globales, que pueden ser compartidas por varios QP dentro de un modelo de nodos. ste tipo de recursos permiten enviar estadsticas 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 travs de varios statistic wires a la vez . Para acceder a una estadstica 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 operacin del editor Edit local statistics como se ve a continuacin.
Ilustracin 17. Estadsticas locales en el modelo de proceso ip_output_iface
54
Estadsticas Globales
Las estadsticas globales recogen la actividad de todo el sistema de comunicaciones. Suelen ser la media de los valores de las estadsticas locales de los distintos componentes del sistema. Dentro de este tipo de estadsticas nos encontramos por ejemplo con el retardo extremo a extremo, jitter o rendimiento de la red. Como pasa con las estadsticas locales, cada modelo de proceso debe declarar las estadsticas globales que va a actualizar durante la simulacin mediante la operacin Global Statistics del editor de procesos. Para acceder a una estadstica global, un proceso primero debe obtener su identificacin y mediante op_stat_reg(), y despus actualizarla mediante op_stat_write().
Subcolas
Los mdulos cola pueden ser configurados para contener cualquier nmero 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 caractersticas 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 mdulo estn declarados en el modelo de proceso, y el usuario puede declarar nuevos para obtener caractersticas especficas para un tipo de aplicacin especfica. Esto se hace en el editor de procesos, con la opcin Interfaces Model Attributes (de hecho este paso es una de las cosas que se ha tenido que hacer en este proyecto para aadir 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 sern el conjunto de atributos del proceso raz 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 raz. El mbito de los atributos es slo el mdulo 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 dems objetos. Tambin existen atributos de mbito global: los llamados atributos de simulacin o simulation attributes. Son declarados tambin en el modelo de procesos y compartidos por varias entidades del sistema. 55
3.4.2 Componentes de un modelo de proceso

Un modelo de proceso especifica el comportamiento dinmico de un proceso. Para ser completo, un modelo de proceso debe describir las acciones que el proceso implementar en todas las circunstancias posibles. Adems, un modelo de proceso suele representar protocolos o algoritmos existentes en la vida real, por lo que su implementacin debe ajustarse a las especificaciones y estndares oficiales de dichos protocolos o algoritmos. Por ejemplo, la implementacin del protocolo TCP/IP est definida segn 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 caractersticas: - Basado en Diagramas de Transicin de Estados (STD) o Maquinas de estado Finitas (FSM). Proto-C utiliza STD por ser el mtodo idneo para describir la evolucin de sistemas de eventos discretos y mantener la informacin de estado. - Combina la representacin visual y textual. Utiliza la representacin visual para la transicin de estados, y para la informacin detallada o toma de decisiones la textual. La especificacin textual est contenida dentro de los estados y transiciones representados grficamente. Adems, se incluye una amplia librera de procedimientos (las funciones citadas hasta ahora forman parte de stos procedimientos). - Representacin de la informacin de estado. La informacin de estado es un conjunto de datos proporcionado o generado por el proceso. Esa informacin es guardada en forma de variables, que sern utilizadas durante la ejecucin. - Creacin de procesos dinmicos. Ya se ha hablado de ello. Los procesos crearn otros segn exigencias de ejecucin. - La estructura del lenguaje Proto-C garantiza una ejecucin eficiente. las
3.4.2.2 Diagramas de Transicin de Estados

Los diagramas de transicin de estados construidos en Proto-C consisten en dos tipos bsicos 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. Adems hay otros elementos como declaracin de variables, atributos y acciones asociadas a cada estado, que no se ven grficamente en el diagrama de estados.
56
Ilustracin 18. Ejemplo de STD: ip_output_iface
Estados Forzados y No forzados
La informacin de estado est continuamente actualizandose conforme van sucediendo los eventos. En trminos 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 ms 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 despus y las condiciones que cada cambio requiere. La especificacin 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 ejecucin. En un diagrama, se pueden distinguir unos de otros por el color: los forced estn representados por crculos de color verde, y los unforced, rojo, como muestra el dibujo de la siguiente pgina:
57
- Unforced States: permiten una pausa entre el enter y el exit executive y, por lo tanto, pueden modelar estados reales del sistema. Despus de completar el enter executive de un estado, el proceso se bloquea y devuelve el control al hilo de ejecucin en el que fue invocado. Ese contexto podra ser, por ejemplo, otro proceso que le invoc mediante la funcin de KP op_pro_invoke(), o si el proceso fue invocado por el Simulation Kernel, bloquearse significara el final del evento, y entonces el Kernel podra elegir el siguiente evento para comenzar su ejecucin. En este punto, el proceso permanece suspendido hasta que una nueva invocacin lo haga progresar y continuar con el exit executive del estado en el que se encuentra. El siguiente diagrama describe el flujo de ejecucin de un STD a travs de estados no forzados.
En la pgina siguiente se muestra el flujo de ejecucin de eventos a travs de estados no forzados, es decir, cmo se empieza ejecutando los exit executives de un estado, a continuacin ejecutando la transicin, el enter executive del siguiente estado, y finalmente bloquearse.
58
Ilustracin 19. Flujo de ejecucin a travs 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 grficamente, o para controlar decisiones de flujo comunes a varios unforced states. Separando grficamente las acciones a ejecutar ayuda a la modularidad, a la vez que se obtiene un STD ms informativo.
59
Ilustracin 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 opcin set initial state en el editor de nodos. Grficamente, se puede identificar el estado inicial porque tiene una flecha a su izquierda. El estado inicial es el punto en el que comienza la ejecucin cuando el proceso es invocado. En realidad puede jugar el papel de un estado normal, pero suele contener inicializaciones y otras sentencias que deberan 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 especificacin de una transicin: el estado fuente, el estado destino, la condicin, y la accin o executive. La especificacin de la transicin se lee de la siguiente forma: si la condicin es cierta, ejecutar lo indicado en el executive y transferir el control al estado destino. En el editor de procesos las transiciones se representan grficamente. Cada estado puede ser origen o destino de varias transiciones, dibujadas como arcos con la punta de la flecha apuntando al nodo destino. La condicin y el executive aparecen en forma de etiqueta al lado del arco. Siempre que se crea una transicin, el editor de Procesos automticamente encierra la condicin entre parntesis seguida de la barra / y el executive. Las transiciones que tienen condicin tienen el arco formado por una lnea discontinua, y las que no tienen condicin, su arco es una lnea continua. A continuacin se muestra un grfico en el que se ven los distintos tipos de transiciones:
60
Ilustracin 21. Representacin de transiciones en un STD
Las condiciones de las transiciones se evalan para decidir si se debe pasar al siguiente estado o no. Un proceso evala las transiciones de salida una vez ha completado la ejecucin de las exit executives del estado en el que est. El manejo de las condiciones de una transicin es muy flexible: pueden ser muy simples, o formar una expresin compleja que involucran variables de estado, atributos y otra informacin almacenada en la memoria local o global. Tambin puede ser que involucren llamadas a procedimientos definidos por el usuario que devuelvan un valor booleano que si se cumple o no la condicin. Alternativamente, tambin se pueden evaluar las condiciones de transicin en el propio estado orgen, al final del exit executives. Existe una condicin especial (default), que asegura que aunque no se cumplan las condiciones de transicin, siempre se pueda transitar a otro estado. La transicin default se cumple slo cuando las otras transiciones no lo hacen. Las transiciones que estn configuradas con una condicin vaca son equivalentes a transiciones en las que su condicin siempre es true. En el modelo de procesos, a estas transiciones se las llama transiciones incondicionales. Un estado que tenga una transicin incondicional, no tiene condicionales saliendo de l. Cada transicin incorpora un atributo que especifica una accin o executive, que es ejecutada en el momento en que el proceso decide atravesar esa transicin. En otras palabras, despus de evaluar las posibles transiciones, el proceso elige una de ellas, ejecuta su executive y pasa a las enter executives del siguiente estado.
3.4.2.3 Macros
Casi todas las macros usadas en un modelo de proceso se definen en su Header Block o HB. 61
Extracto del header block del modelo de proceso ip_output_iface en el que se ve la inclusin de ficheros externos .h y definicin de condiciones y constantes
Header Block o Bloque de cabecera es un rea de cdigo C y C++, similar a la cabecera de un fichero en C o C++. Las macros generalmente se usan para representar constantes, condiciones de transicin, transition executives, u operaciones comunes. En el bloque de cabecera, las macros se reconocen por empezar con la directiva #define. Tambin se pueden encontrar macros en ficheros de definicin 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 mtodo es til cuando varios modelos de proceso deben compartir un conjunto de definiciones, favorece la reutilizacin.
3.4.2.4 Variables
Los procesos en Proto-C tienen acceso a varias formas de memoria para almacenar informacin, cada una con las caractersticas 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 continuacin se presenta una tabla con los tipos de variables existentes y su mbito o visibilidad.
Tipo de Variable \ Visibilidad Temporal Estado Global (como las definidas en ficheros externos o en HB) 62
State Executives X X X
Function Block
Funciones en ficheros Externos (extensin .ex.c)
X X X (Usando extern)
La declaracin de cada uno de los tres tipos de variables utiliza un mecanismo distinto, para indicar al compilador qu categora aplicar. En los siguientes puntos se describe detalladamente las caractersticas de cada uno de los tipos.
Variables de estado (State variables)
Son variables utilizadas para representar la informacin acumulada y retenida por un proceso. Se las llama de estado porque, junto con la posicin 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 travs del tiempo. Slo 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 contina su ejecucin, todo est como lo haba dejado. Una caracterstica 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 mdulo, sus variables de estado guardarn la informacin independientemente sin conflictos, aunque el nombre de las variables sea el mismo. Las variables de estado se declaran en un rea especfica 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 declaracin), 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.
Ilustracin 22. Declaracin de variables de estado en ip_output_iface
Variables temporales (Temporary variables)
Almacenan informacin que no requiere persistencia por lo tanto, es posible que entre una invocacin y otra del mismo proceso hayan cambiado. Debido a esto, se las suele utilizar como instrumentos auxiliares para facilitar la ejecucin de expresiones complejas en un instante de tiempo. Por ejemplo, variables de este tipo pueden ser el ndice de un bucle o un paquete recin extrado de un stream. 63
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 asignacin en su declaracin. Como se ve a continuacin
Ilustracin 23. Declaracin de variables temporales en ip_output_iface
Variables Globales (Global variables)
Las variables globales proporcionan un mtodo para que diferentes procesos guarden informacin en un rea comn. Pueden ser de cualquier tipo predefinido en C o OPNET, incluyendo tambin 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 declaracin principal en el header block del modelo de proceso con el que ms asociado est. Si otros procesos comparten acceso a ella, su bloque de cabecera incluir una declaracin externa. Puede haber muchos procesos que tengan declaraciones externas de una variable, pero slo uno tendr una declaracin 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 declaracin mediante la asignacin de una valor, pero slo en la declaracin principal. La inicializacin se ejecutar antes del comienzo de la simulacin.
3.4.2.5 Uso de funciones

Para hacer los modelos de proceso ms modulares y sencillos, una de las tcnicas que se ha dicho anteriormente es utilizar forced states en el diagrama de estados, para as mostrar de forma ms intuitiva el flujo de ejecucin 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 seccin llamada function block o FB. El contenido de FB se puede editar mediante el Editor de 64
Control de Congestin con OPNET Procesos, haciendo clic en el botn . El texto escrito en ste bloque aparecer tambin en el header block, permitiendo usar tipos de datos y macros definidas en l. Cada funcin representa un paquete de funcionalidad que cualquier elemento de los STD puede usar. As, se simplifica la apariencia de los diagramas de transicin y tambin se fomenta la reutilizacin en distintas partes del cdigo. 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 mtodo, se pueden utilizar funciones definidas en ficheros externos, que se unen al modelo de proceso durante la simulacin. Esto permite desarrollar y mantener funciones de manera centralizada y compartirlas por varios modelos de proceso. Estos ficheros se encuentran fsicamente 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 continuacin:
Ilustracin 24. Dos tramos de la lista de ficheros externos en ip_dispatch
En la imagen se ve cmo estn seleccionados dos de los ficheros externos ms 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 propsito de permitir desarrollar modelos parametrizados. Los modelos de proceso son los que generalmente usan este mecanismo, porque es el modelador el que crea el cdigo 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 operacin Interfaces > Model Attributes. Cada atributo se define especificando un nombre nico y unas propiedades, como se ve a continuacin. 65
Ilustracin 25. Acceso a los atributos del modelo de procesos qos_attribute_definer
Durante la simulacin, 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 mayora de los casos, los atributos no son modificados durante su simulacin, sirven slo como parmetros que el proceso utiliza para configurarse a s mismo al inicio. Como ejemplo, a continuacin se muestra cmo el proceso qos_attribute_definer accede al atributo FIFO Profiles en el cdigo 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 tambin proporcionan la capacidad de asociar comentarios al para guiar e informar al usuario acerca del modelo de proceso.
66
3.5 Simulacin
En los siguientes apartados se describen primero los componentes que hacen falta para la simulacin de un sistema. Posteriormente se ver cmo se lleva a cabo la simulacin desde el punto de vista del tiempo, eventos e interrupciones. Definimos simulacin como una tcnica que imita el comportamiento de un sistema del mundo real conforme evoluciona en el tiempo. De esta manera, se puede analizar y observar caractersticas sin necesidad de acudir al sistema real. Se denomina modelo de simulacin discreto a la representacin 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 simulacin discreta: la simulacin de eventos discretos. Para entender los siguientes apartados, es necesario conocer los siguientes conceptos: Modelo de simulacin: conjunto de hiptesis acerca del funcionamiento del sistema expresado como relaciones matemticas y/o lgicas entre los elementos del sistema. Es decir, hace referencia a la representacin del sistema real que va a ser analizado, sus condiciones de funcionamiento y las variables que emplea. Proceso de simulacin: ejecucin del modelo de simulacin a travs del tiempo en un ordenador para generar representaciones de comportamiento del sistema.
3.5.1 Construccin de un modelo de simulacin

Antes de la simulacin de un sistema, se debe obtener un programa de simulacin compilado, compuesto por instrucciones en cdigo mquina que el ordenador puede ejecutar directamente. Un programa de simulacin consiste en partes separadas de cdigo objeto. Cada una de esas partes tiene un papel diferente durante la simulacin. Algunos de los ficheros objeto son proporcionados por OPNET, mientras que otros provienen de las especificaciones del usuario. A continuacin se citan los distintos tipos de componentes que forman parte de un programa de simulacin en OPNET:
- Simulation Kernel: Es una librera de cdigo objeto que contiene los algoritmos de simulacin
y otros servicios usados para la simulacin. Puede ser de varias categoras. Proporciona el marco para todas las simulaciones, incluyendo servicios bsicos como carga de modelos, planificacin y gestin de eventos, recoleccin de estadsticas, 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 simulacin se traduce en un fichero

en C, teniendo una extensin .pr.c. Cada uno de estos ficheros, inmediatamente antes de la simulacin se compila mediante un compilador instalado en el ordenador (en ste caso, Visual C++), que genera un fichero objeto con la extensin .pr.o. 67
- Pipeline Stages: Son la referencia a los links del sistema, e implementan operaciones
modulares y actividades relacionadas con la transmisin de paquetes entre los mdulos transmisores y los receptores. Tienen extensin .ps.c.
- External Object Files: Contienen funciones de apoyo a los modelos de proceso y pipeline stages durante la simulacin. Pueden estar desarrollados en C o en cualquier otro lenguaje que se pueda llamar desde C. Tienen extensin .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 mltiples ficheros objeto.
Una vez obtenidos todos los componentes de simulacin mencionados, OPNET proporciona un programa ejecutable, apto para simular.
3.5.2 Simulacin de eventos discretos

3.5.2.1 Eventos y simulation time
Generalmente, la simulacin de eventos discretos general una secuencia de estados para un sistema. ste evoluciona a travs de los estados en funcin del tiempo, basndose en las especificaciones de comportamiento de sus componentes y en la interaccin entre ellos. La nocin de tiempo en una simulacin no est relacionada con el tiempo real que se emplea en efectuar dicha simulacin: es una variable mantenida por el programa, y permite especificar cunto 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 nocin de la variable simulation time y a los eventos, que se explican a continuacin, es posible estudiar el comportamiento que tendra un sistema durante un largo periodo de tiempo empleando para ello un tiempo considerablemente menor. En la simulacin de eventos discretos, la progresin 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 algn cambio que afecte a su estado, o a realizar alguna decisin. Ejemplo de eventos seran: recepcin de un paquete, expiracin de un temporizador, la terminacin de alguna tarea, fallo, etc. Cada vez que se produce un nuevo evento, se dice que es ejecutado por la simulacin. Es posible que ocurran varios para el mismo valor de simulation time. Los eventos no se reparten de manera uniforme durante el tiempo de simulacin. De hecho, es comn que su densidad vare significativamente a medida que progresa la simulacin, como se ve a continuacin:
68
Ilustracin 26. Distribucin tpica de eventos durante el tiempo de simulacin
El tiempo de simulacin slo avanza entre eventos, durante la ejecucin de un evento el tiempo no puede cambiar(todos los eventos tienen duracin 0).
3.5.2.2 Planificacin y Lista de eventos

Una simulacin en progreso puede ser vista tanto como generadora como consumidora de eventos. Los componentes van generando eventos para planificar futuras acciones, basndose en el comportamiento descrito por los distintos modelos. Esos eventos, por otro lado se irn consumiendo segn progresa el tiempo de simulacin. La simulacin de eventos discretos maneja los eventos mediante una denominada lista de eventos. El propsito 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 tambin la variable simulation time. Es muy comn que los eventos se planifiquen para el tiempo actual como consecuencia de una reaccin en cadena, es decir, un evento causa otro, y se a su vez otro, y asi, sin que el tiempo de simulacin 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 ejecucin. El evento ms cercano al tiempo de simulacin actual es la cabeza de la lista, y el que est planificado para un instante ms lejano, la cola. Durante la simulacin, el Kernel ir aadiendo eventos a esta lista en cualquiera de sus posiciones, por lo que la cabeza y la cola pueden estar cambiando constantemente, as como el tamao de la lista. Por otro lado, el propio Kernel ser tambin 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 planificacin y anlisis de los eventos durante la simulacin. Durante la simulacin, la lista puede estar continuamente aumentando (conforme nuevos procesos son planificados) y disminuyendo (cuando dichos eventos son ejecutados o cancelados) . Cada simulacin tendr su propio patrn de crecimiento de la lista de eventos, dependiendo de las actividades modeladas. Una simulacin contina slo cuando tiene nuevos eventos que ejecutar. Por lo tanto, si la lista se vaca como resultado de ejecutar el ltimo evento, la simulacin termina, incluso si no se ha alcanzado el tiempo final convenido. 69
Ilustracin 27. Organizacin de una lista de eventos durante el tiempo de ejecucin
Al inicio de la simulacin, la lista de eventos debe recibir como mnimo un evento para que la ejecucin comience. Hay un tipo especial de evento (begin simulation) que los procesos alojados en los QP (mdulos de tipo cola o procesador) pueden lanzar si tienen un atributo especfico habilitado (begsim intrpt). Adems los mdulos procesador pueden elegir automticamente cundo enviarn su primer paquete. Eventos de ste tipo son los que se suelen ver en la lista de eventos en cuanto la simulacin 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 informacin describindolo. Parte de esta informacin es usada por el Simulation Kernel a la hora de ejecutarlo. La informacin tambin puede ser usada para procesar el evento segn haya definido el usuario dependiendo de unas circunstancias u otras . Algunos de esos atributos son: 70
- time: instante de la simulacin en que el evento debe ocurrir. - execution ID: identificador de la orden de ejecucin del evento. - module: mdulo en el que el evento ocurrir. - process: proceso que recibe el evento. - type: tipo de evento, segn 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 servirn slo para propsitos muy especficos, mientras que otros son ms generales y estn relacionados con actividades ms variadas. Entre ellos, cabe citar: - self: para contadores y modelado de delays. - stream: comunicacin de paquetes entre mdulos de un modelo de nodos. - statistic: notificacin asncrona de cambios en estadsticas y seales. - begin simulation: notificacin de comienzo de simulacin, permitiendo a los procesos inicializar su estado. - end simulation: notificacin de fin de simulacin, permitiendo a los procesos registrar informacin final, por ejemplo estadsticas. - process: invocacin directa de un proceso dentro de un mdulo.
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 ms usadas es op_intrpt_type(), para determinar el tipo de evento producido. Las interrupciones son las invocaciones que resultan de la ejecucin 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 interrupcin y se determina su tipo, procedencia y otra informacin que se considere relevante, el modelo de proceso es el que elige cmo ser tratada y las acciones a realizar, dependiendo de las especificaciones dadas por el usuario.
71
72

4.1 Introduccin
Una vez comprendido el marco terico de la Gestin Activa de Colas en el Captulo 2 y el funcionamiento de los principales mecanismos de OPNET en el Captulo 3, el usuario ya tiene los conocimientos necesarios para hacerse una idea de cmo modelar un sistema de comunicaciones y cmo moverse por los diferentes dominios del programa. Este captulo se centra en la utilizacin del programa de manera especfica, describiendo cmo se implementa la Gestin Activa de Colas dentro de los router, desde la creacin de la red donde se va a aplicar y configuracin de la misma a travs 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 explicacin es a travs de la obtencin de licencias del programa e instalacin, lo cual se hace en los siguientes puntos de este apartado.
4.1.1 Requisitos previos a la instalacin y uso

OPNET Modeler ha sido instalado en un ordenador personal con el sistema operativo Microsoft Windows XP Home Edition versin 2002. En este ordenador se instal previamente un compilador de cdigo C y C++ (Microsoft Visual C++ 6.0), necesario para compilar las distintas partes de cdigo que componen los programas de simulacin 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 automtica. Dependiendo del sistema operativo y del compilador, tras la instalacin estas variables pueden tener ya el valor correcto, o el usuario tendr que modificar su contenido. Si hay problemas en este paso, en la pgina de OPNET, http://www.opnet.com hay una seccin (FAQ) que puede dar respuesta a los problemas ms usuales.
73
Captulo 4.Implementacin del algoritmo RED en OPNET
4.1.2 Obtencin y Gestin de licencias

La versin del programa usada para ste proyecto ha necesitado de la concesin de licencias acadmicas para poderlo usar gratuitamente. Actualmente hay una versin gratuita del programa, OPNET IT Guru Academic Edition, pero la funcionalidad que permite es muy limitada (slo la de un simulador de redes normal y corriente, sin posibilidad de extender su cdigo) y no era suficiente para desarrollar los objetivos del proyecto. Por lo tanto, hemos tenido que solicitar una versin ms completa del programa (OPNET Modeler 14.5), acogindonos a la opcin 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 acadmico y no con fin comercial o empresarial. Este requisito se cumple en nuestro caso, al solicitarse la aplicacin para la realizacin de un proyecto de fin de carrera. Que todo resultado obtenido a travs del uso del programa se debe poner a disposicin del pblico y su uso ser gratuito. Las licencias de uso del programa slo son vlidas por perodo de seis meses, tras los cuales hay que renovarlas. Se debe crear una pgina web describiendo cmo se est utilizando el programa y para qu fin. Para renovar las licencias una vez transcurrido el perodo de seis meses, es requisito imprescindible actualizar la pgina creada antes de cada renovacin, incluyendo los avances que se van obteniendo en ese perodo de tiempo.
Tras completar estas condiciones, la tutora obtuvo los ficheros de instalacin del programa, y el nombre de usuario y contrasea para la autentificacin y renovacin de las licencias.
4.1.3 Instalacin
En la instalacin 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 libreras (modelos predeterminados de comportamiento de los componentes) y documentacin. Una vez instalados los tres ficheros, y comprobadas las licencias, ya se puede empezar a utilizar el programa. 74
4.1.4 Configuracin
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 prctica, es complicado moverse por los diferentes mens 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 configuracin 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.
Ilustracin 28. Ventana de preferencias en OPNET
La lista de atributos est ordenada alfabticamente, segn su nombre. Se pueden localizar atributos de manera ms rpida tecleando parte del nombre dentro del campo Find. Algunos de los atributos que se han considerado interesantes son: - License Server Name (license_server), que debe corresponderse con el nombre del host desde el que se obtiene la licencia. 75
Captulo 4.Implementacin del algoritmo RED en OPNET - Standalone License Server (license_server_standalone), que especifica si el programa acta 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 dnde se guardarn 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 topologa

Para el estudio de comportamiento de los algoritmos AQM en OPNET, se han realizado varias topologas, variando el nmero de usuarios. En este captulo se describir cmo crear la topologa ms sencilla utilizada y a configurar sus componentes, todo ello mediante el Editor de Proyectos de OPNET.
4.2.1 Descripcin de la topologa

A continuacin se presenta una topologa tpica en forma de cuello de botella, con cinco Clientes y cinco Servidores Ethernet, dos switch y dos routers. Los clientes actan como fuentes TCP, enviando trfico de tipo FTP. La capacidad del enlace entre los dos router ser muy inferior comparada con la del resto de enlaces, para crear la situacin de control de congestin y experimentar descarte de paquetes y otros efectos. Se utilizarn tres componentes de configuracin de parmetros globales de tres tipos: configuracin de aplicaciones, configuracin de perfiles y configuracin de QoS.
4.2.2 Construccin paso a paso

4.2.2.1 Creacin de un proyecto nuevo:
Ejecuta OPNET Modeler 14.5 1. Selecciona men File New. Nombra al proyecto CuelloBotella y al escenario DropTail
Selecciona Project y pulsa OK Pulsa OK.
2.
Aparecer el cuadro de dilogo Startup Wizard: Initial Topology, seleccionar la opcin Create Empty Scenario Pulsa Next En la lista Network Scale elige Enterprise Pulsa Next tres veces ms Por ltimo pulsa OK.
76
4.2.2.2 Creacin de la red:

Despus de los anteriores pasos, se abrir el editor de proyectos junto con la paleta de objetos. Vamos a elegir los elementos que formarn la topologa: 1. Pincha en el icono que hay a la izquierda de la ventana Search By Name. As tendremos una visualizacin ms sencilla de los objetos de la paleta:
Ilustracin 29. Paleta de objetos
2.
Haz clic con el botn izquierdo del ratn en el nodo Application Config y haz lo mismo en el espacio de trabajo Acto seguido haz clic con el botn derecho para dejar de crear nodos de este tipo.
77
Captulo 4.Implementacin del algoritmo RED en OPNET 3. Repite la operacin 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. 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. Cambiar el nombre a los nodos restantes hasta conseguir lo mostrado en el grfico:
4.
5.
Ilustracin 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 botn de la barra de herramientas Clic con el botn izquierdo sobre el nodo 100BaseT Pincha sobre Cliente1 y despus sobre Switch1. Quedarn unidas por una lnea que es el link. Repetir la operacin para unir Switch1 con Router1, Router2 con Switch2 y ste con Servidor1. Ente ambos routers se establece un link mucho ms lento, para as crear el cuello de botella. Pinchar en la paleta de objetos en el nodo PPP_DS1 Pinchar en el Router1 y despus en Router2. Guarda tu proyecto seleccionando en File Save.
7.
8.
9.
Ahora ya hemos tenemos los nodos bsicos de la red en el espacio de trabajo. Los siguientes pasos sern configurar el tipo de trfico que circular por la red, configurar tanto el cliente como el servidor, y por ltimo aadir ms clientes y servidores copiando los ya configurados.
78
4.2.2.3 Configuracin del Nodo de Aplicaciones

1. Haz clic con el botn derecho del ratn en el nodo Aplicaciones Edit Attributes. Se abrir la ventana de atributos (Aplicaciones) Attributes. En el atributo Application Definitions establecer Number of Rows a 1. Desplegar Enter Application Name y en la columna Value del atributo Name escribir Aplicacin_FTP. Desplegar Description y dar doble clic en la columna Value de Ftp Aparece el cuadro de texto (Ftp) Table. Aqu establecemos las caractersticas que tendr nuestra aplicacin FTP. Cambiar los valores de forma que quede como en la grfica :
2.
3.
4.
Pulsa OK tres veces para terminar con la configuracin de ste nodo.
4.2.2.4 Configuracin del Nodo de Perfiles

1. Haz clic con el botn derecho del ratn en el nodo Perfiles Edit Attributes. Se abrir la ventana de atributos (Perfiles) Attributes. 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 aplicacin creada anteriormente, que aparecer al hacer clic izquierdo en la casilla de Value, Aplicacin_FTP. Rellenar el resto de atributos como se muestra en la siguiente figura:
2.
3.
79
Ilustracin 31. Atributos del nodo Perfiles
4.
Pulsa OK para guardar los datos y cerrar la ventana y guarda tu proyecto.
4.2.2.5 Configuracin de Clientes y Servidores

Configurar Cliente1:
1. 2. Click derecho en el nodo Cliente1 Edit Attributes. 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. Da doble click ahora en la casilla de al lado de Application: Destination Preferences Volver a poner Rows a uno Debajo de Application elegir Aplicacin_FTP, y debajo de Symbolic Name elegir FTP Server (establecido en el nodo Aplicaciones ). Ms adelante volveremos a sta tabla a modificar el contenido de Actual Name, cuando hayamos incorporado a la red todos los clientes y servidores.
3.
80
Ilustracin 32. Un paso en la configuracin de un Cliente
4.
Pulsa OK dos veces para terminar con la configuracin del nodo Cliente1.
Ahora aadiremos los cuatro clientes restantes con sus links correspondientes. Para facilitar la tarea, copiamos Cliente1 y lo pegamos cuatro veces: 5. Teclear Ctrl+V para Selecciona el nodo Cliente1 Teclear Ctrl+C para copiar el nodo 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. Una vez fijado el nodo Cliente2, unirlo con el Switch1 a travs del link que automticamente parte desde el nodo cliente. Repetir la operacin hasta tener los 5 clientes.
6. 7.
Si miramos los atributos de cualquiera de ellos, vemos que se conservan los definidos para Cliente1. Esa fue la razn de emplear Copiar/Pegar. As ya no es necesario volver a configurar esos atributos.
Configurar Servidor1:
1. 2. Clic derecho en el nodo Servidor1 Edit Attributes. 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 trfico que va a aceptar ste servidor es el definido en el nodo Aplicaciones. 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 identificacin de ste servidor dentro de la red. Cada servidor necesitar uno distinto. Necesitamos definirlo para ms adelante. Pulsar OK para cerrar la edicin de atributos. Guarda el proyecto.
3.
4.
Ahora, como en el caso de los clientes, aadiremos los servidores restantes. 81
Captulo 4.Implementacin del algoritmo RED en OPNET 5. Repetir el procedimiento de copia de los clientes con Ctrl+C y Ctrl+V, uniendo los servidores con el Switch2. 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 podra elegir el nombre que se quiera, siempre y cuando nunca se repita).
6.
Lo ltimo que queda por hacer en este mbito es asignar a qu servidor enva datos cada cliente. Eso lo haremos mediante un atributo mencionado al configurar Cliente1, asignndole los diferentes Server Address dependiendo del cliente, de la siguiente manera:
7.
Seleccionar Cliente1 Editar Actual Name.
Edit Attributes
Editar Application: Destination Preferences
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. As queda establecido que Cliente1 enva datos a Servidor1. Pulsa OK tres veces.
9.
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.
Ilustracin 33. Tabla para elegir destino de Cliente1
82
Control de Congestin con OPNET A stas alturas ya tendramos una red vlida, pero para estudiar el comportamiento de los mecanismos de control de congestin hay aadir otro apartado:
4.2.3 Configuracin de Atributos QoS

1. 2. Selecciona el nodo QoS Edit Attributes 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 Asegurarse que la ventana tiene la siguiente forma:
4.
Ilustracin 34. Eleccin de la disciplina FIFO en las interfaces de los routers conectados
83
Captulo 4.Implementacin del algoritmo RED en OPNET 5. Pulsa OK. Vers que el link seleccionado ha cambiado de color.
Ilustracin 35. Unin entre routers con las interfaces configuradas
6.
Guarda tu proyecto.
4.2.4 Eleccin de estadsticas

En ste apartado se muestra cmo elegir las estadsticas que queremos que el programa registre durante la simulacin. 1. Elegimos primero las estadsticas globales: haz clic con el botn 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 estadsticas disponibles.
Ilustracin 36. Men para elegir estadsticas
Ilustracin 37. Ventana de eleccin de estadsticas sin desglosar
2. 84
Desglosa el men Global Statistics IP. Pincha en la casilla de al lado de Traffic Dropped(packets/sec).
3. 4. 5.
Sin salir de Global Statistics, desglosa TCP, y pincha en la casilla Delay(secs). Sal de Global Statistics, y expande ahora Link Statistics point-to-point utilization 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 utilizacin en todos los links de la red (nos permite hacernos una idea de cmo est aprovechando cada nodo sus conexiones).
6.
Ahora elegimos las estadsticas locales, las miramos en el router: haz clic con el botn Choose Individual Statistics Expande Node Statistics Expande IP derecho en Router1 Interface
Ilustracin 38. Parte de la interfaz de visualizacin de las estadsticas 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 variacin en el retraso o jitter experimentado en el router (el obtenido en las estadsticas globales ser a nivel de la red entera), y el tiempo que tienen que esperar los paquetes antes de ser procesados y enviados.
8. 9.
Pincha OK para terminar. Guarda tu proyecto.
4.2.5 Duplicar escenarios

85
Captulo 4.Implementacin del algoritmo RED en OPNET Ahora s que est configurada la red. Al no haber escogido ningn algoritmo, el control de congestin 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 mtodo de control de congestin, cambiando el tipo de AQM utilizado en los routers.
4.2.5.1 Operaciones del men Scenarios

Antes de duplicar escenarios, es til conocer cmo 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.
Ilustracin 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 operacin duplica todos los elementos del escenario original excepto los resultados de simulacin. - Manage Scenarios: Es una operacin 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, aadir, duplicar y borrar uno o varios escenarios. Adems, se puede seleccionar qu escenarios simular, cambiar la duracin de la simulacin, y reordenar los escenarios en la lista.
86
Ilustracin 40. Lista de los escenarios dentro del proyecto CuelloBotella
- Switch To Scenario: Operacin que permite cambiar de escenario, mediante un men emergente formado por los escenarios existentes en el proyecto. En la prctica, en vez de usar ste men, es ms rpido teclear ctrl.+NumEscenario, que te lleva directamente al escenario solicitado, sin necesidad de desplegar ningn men.
4.2.5.2 Creacin y configuracin del escenario RED

1. Selecciona Scenarios Duplicate Scenario Aparece un cuadro de dilogo con un nombre por defecto. Llama al nuevo escenario RED Pulsa OK. Automticamente pasamos a estar editando el nuevo escenario, que es una copia exacta del anterior.
Vamos a cambiar el mtodo de control de congestin, en vez de Drop Tail, esta vez usaremos el algoritmo RED. Para cambiar esta configuracin, hacer lo siguiente: 2. Pinchar en el nodo QoS Edit Attributes Expandir RED Parameters. Expandir FIFO Profiles FIFO Profile Details
3.
Cambiamos los parmetros del algoritmo RED como se muestra en la figura:
Ilustracin 41. Configuracin de parmetros del algoritmo RED en el nodo QoS
87
4.
Pulsa OK.
Los parmetros de RED son los siguientes: - RED Status: estatus de RED, si est habilitado, deshabilitado, o el tipo de versin. As configurado, estamos estableciendo la versin normal de RED. - CE Marking: Uso del bit ECN. Si est deshabilitado (disabled), RED descartar los paquetes en caso de congestin. En caso contrario, marcar los paquetes con el bit ECN en vez de descartarlos. - Maximum Threshold: Parmetro Umbral mximo del algoritmo RED. Una vez el parmetro avgq sobrepasa ste valor, la probabilidad de descarte es 1. - Minimum Threshold: Parmetro Umbral mnimo del algoritmo RED. Si avgq es menor que ste valor, ningn paquete es descartado o marcado. - Mark Probability Denominator: Fraccin de paquetes descartados cuando la probabilidad de descarte es mxima. Tal y como est configurado, se descarta 1 de cada 40 paquetes cuando la probabilidad es mxima. - Exponential Weight Factor: filtro pasa-bajo aplicado para calcular el parmetro tamao medio de cola o avgq. Ahora slo falta aadir una estadstica especfica del RED (el resto de estadsticas 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 botn derecho en Router1 Choose Individual Statistics IP Interface Activa una nueva casilla: RED Average Queue Size Pincha OK para terminar y guarda el proyecto. Node Statistics
6.
4.2.5.3 Creacin y configuracin del escenario GRED

Este escenario ser igual que el anterior, excepto que se ha cambiado la versin utilizada de RED por la de GRED, una modificacin 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 slo tenemos que configurar el nodo QoS para establecer como AQM el algoritmo GRED. 2. Pinchar en el nodo QoS Edit Attributes Expandir RED Parameters. Expandir FIFO Profiles FIFO Profile Details
3.
Establecer el parmetro RED Status a GRED Enabled, quedando los parmetros como la siguiente figura.
88
Ilustracin 42. Configuracin de parmetros del algoritmo RED en el nodo QoS
4.2.6 Simulacin de los escenarios

Vamos a simular todos los escenarios de manera secuencial. Para ello, usaremos la operacin Manage Scenarios del men Scenarios explicada en el apartado anterior.: 1. 2. Pincha en la barra de herramientas del editor de proyectos el botn Scenarios Manage Scenarios En la lista que aparece con los escenarios, pincha en las casillas debajo de la columna Results. Aparecern varias opciones. Escoge la opcin disponible <collect> o <recollect>, dependiendo de si es la primera vez que se simulan los escenarios o no. En Sim Duration (duracin de la simulacin) poner 1500, y en unidades o Time Units, segundos.
Al pinchar en el botn OK, aparecer la ventana DES Execution Manager: Cuello Botella, y en el apartado de la derecha, se ver el estado de la simulacin para cada escenario. Dependiendo de varios factores como la velocidad del procesador, o los procesos que se estn ejecutando en el ordenador en ese momento, etc la simulacin tardar ms o menos. Cuando el status de todas las simulaciones sea Completed, pulsa en el botn Close. Ahora slo nos queda ver los resultados obtenidos y compararlos. A continuacin se muestra el cuadro de simulaciones en dos momentos distintos.
89
Ilustracin 43. Dos instantes de simulacin: en el primer grfico, se ha completado la simulacin del primer escenario, y el segundo va a empezar a simularse. El tercer escenario est a la espera. En el segundo grfico, ya se han completado las tres simulaciones.
4.2.6.1 Simular un solo escenario

En caso de querer simular slo un escenario, se puede recurrir al men DES (Discrete Event Simulation) del editor de Proyectos: DES Configure/Run Discrete Event Simulacin
Al pinchar en la opcin Configure/Run Discrete Event Simulacin , aparece la ventana del editor de simulaciones completa, que presenta este aspecto:
90
Ilustracin 45. Ventana del editor de simulaciones
A continuacin se da una breve explicacin de los campos presentes en esta ventana: - Duration: Duracin del tiempo de la simulacin. En el campo adyacente se especifican las unidades de tiempo que se da la duracin. - Seed: valor inicial para la secuencia de nmeros aleatorios, necesario para la simulacin secuencial. - Values per statistic: mximo nmero de valores recogidos para cada estadstica. - Update interval: intervalo de actualizacin de las estadsticas. - Simulation Kernel: tipo de ncleo que se quiere utilizar para la simulacin. - Simulation set name: nombre del conjunto de simulacin (valores de configuracin de la simulacin)
4.2.7 Comparacin y visualizacin de resultados
En la ventana del editor de Proyectos, pulsa en el botn , que es para ver los resultados de las ltimas simulaciones. en el cual si dejamos el ratn sobre l, vemos que sale la nota View Results. Al pulsar sobre l, aparece la pantalla Results Browser, que tiene el siguiente aspecto:
91
Ilustracin 46. Ventana de visualizacin 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. En el cuadro inferior, vemos dos mens desplegables: Global Statistics y Object Statistics. En ellos, se pueden habilitar para ver en la pantalla Preview las estadsticas globales y locales elegidas antes, respectivamente. En el ejemplo, est habilitada la estadstica global de descarte de paquetes en la red para los tres escenarios.
2.
El primer campo del apartado Presentation est para elegir cmo mostrar varias grficas: - Overlaid Statistics: todas las grficas se superponen - Stacked Statistics: todas las grficas se muestran por separado En el segundo campo se elige cmo 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 transformacin matemtica. - Average: Se hace representa en la grfica valores medios - Con ejes logartmicos, distribucin de probabilidades, ... A partir de aqu slo es cuestin de probar a elegir distintas estadsticas y efectuar las comparaciones mediante las grficas que salen. La interfaz que ofrece OPNET para la visualizacin 92
Control de Congestin con OPNET de resultados es bastante cmoda e intuitiva. Basta con elegir las casillas, tanto de los escenarios como de las estadsticas, y luego ver las grficas de la forma que se crea ms 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 travs del modelo de nodos, y luego el comportamiento a travs del de procesos. Como los conceptos tericos de ambos modelos ya se conocen, este captulo se centrar directamente en explicar su estructura y funcionamiento. Adems, se indicar cmo 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 situacin:
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 travs 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 travs 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 mtodo utilizado en este proyecto, puesto que los nodos que se han estudiado ms a fondo para los algoritmos AQM son los routers y el nodo de configuracin QoS, ambos presentes en la topologa. Por ello lo ms sencillo es acceder a los modelos de nodos directamente desde la topologa.
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 especficas dentro de toda la red. Ya se ha visto que es donde se elige 93
Captulo 4.Implementacin del algoritmo RED en OPNET el AQM que despus utiliza Router1 para el control y prevencin de la congestin 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:
Ilustracin 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 mdulo de tipo procesador denominado
attribute_definer.
Este modelo de nodos es tan simple porque en realidad su nica labor es la configuracin de parmetros que otros modelos de nodos utilizarn en el momento de la simulacin. No tiene ninguna funcin equivalente a ningn dispositivo fsico. Por ello, slo consiste en un mdulo que contendr un modelo de procesos encargado de recoger los atributos elegidos por el usuario . Si se miran otros componentes que proporciona OPNET para configuracin de parmetros 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 debera mirar en el men Interfaces Model Attributes, pero la tabla emergente est vaca, lo que significa que esos atributos en realidad son heredados del modelo de procesos. Con lo cual, no hay nada ms que mostrar a este nivel.
94
4.3.3 Modelo de procesos del mdulo attribute_definer

El modelo de procesos residente en el mdulo attribute_definer ser el real encargado de obtener los datos de configuracin introducidos por el usuario mediante la operacin 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 mdulo de inters.
Ilustracin 48. Acceso al modelo de procesos de attribute_definer
Como se ve en la figura, el modelo de procesos se denomina qos_attribute_definer. Grficamente, el STD de este modelo de proceso est formado por el estado parse, que adems es el inicial. No hay ninguna transicin. Por el color rojo del estado, se trata de un unforced state, y su enter executive est compuesto de 56 lneas de cdigo, mientras que el exit executive estar vaco. Comprobemos la definicin de variables y otros elementos dentro de los bloques de cdigo:
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 sern usadas dentro del external file oms_qm.ex.c, el cual contiene funciones para el manejo de colas, entre ellos, funciones especficas del algoritmo RED.
95
Captulo 4.Implementacin del algoritmo RED en OPNET En el apartado de predefinicin 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 estn implementadas en el function block, y se vern ms adelante.
Variables de Estado
Destaca la variable:
que servir como referencia para acceder a los distintos atributos.
Variables Temporales
Slo se usan dentro del STD:
Y sirven sobre todo para el manejo de objetos e identificacin.
Enter Executives
Para acceder al cdigo de las enter executives, basta con hacer doble clic en la mitad superior del estado en cuestin. Las acciones realizadas son: - Inicializar variables de estado y temporales, inicializacin de ciertas estructuras - Registrar la existencia del modelo de proceso, para ser visible para otros procesos (por ejemplo, ip_dispatch, dentro del mdulo ip del nodo router), mediante la funcin oms_pr_process_register. - Llamada a la funcin attr_def_fifo_profiles_info_parse () para recoger los atributos del tipo FIFO, si estn configurados.
Tambin 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 informacin correspondiente a la ventana siguiente:
96
Ilustracin 49. Atributo recogido por attr_def_fifo_profiles_info_parse
En este proyecto nos hemos centrado en FIFO, por lo que no se contemplarn el resto de opciones. Para ver exactamente cmo se comporta attr_def_fifo_profiles_info_parse, abrir la ventana del function block:
Function Block
A continuacin se muestran fragmentos importantes y sus comentarios del cdigo de la funcin citada:
static voidattr_def_fifo_profiles_info_parse (void) { OmsT_Qm_Attributes*qm_attr_ptr = OPC_NIL; OmsT_Qm_IP_Queue_Configuration*qconfig_ptr = OPC_NIL; op_ima_obj_attr_get(my_objid,"FIFO Profiles", &qc_information_objid); /*Obtener el nombre del perfil FIFO*/ op_ima_obj_attr_get (queuing_type_objid, "Profile Name",prof_name); /*Reservar memoria para almacenar el atributo QoS usado por la interfaz IP*/ qm_attr_ptr = ip_qos_attributes_create (IpT_Fifo_Pool, 1, (int)OmsC_Buffer_Parent_Limit, OPC_TRUE); qconfig_ptr = (OmsT_Qm_IP_Queue_Configuration*) qm_attr_ptr->queue_configuration[0]; op_ima_obj_attr_get(queuing_type_objid,"Details",&(queue_configuration_objid)); op_ima_obj_attr_get (queue_configuration_child_objid, "Maximum Queue Size", &max_queue_size); qconfig_ptr->max_size = (double) max_queue_size;
97

/* Recoger los parmetros 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 informacin 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 informacin sobre colas del tipo nmero mximo de paquetes, nmero de colas por defecto, y contiene a otras estructuras para almacenar parmetros de cada una de las colas en particular, como es el parmetro qm_attr_ptr->queue_configuration , que como se ve en el cdigo, se le hace una asignacin de tipo OmsT_Qm_IP_Queue_Configuration, la otra estructura importante, que mantiene parmetros IP especficos de las colas, entre ellos, parmetros relativos al AQM RED. En la anterior funcin, para recoger los parmetros de RED y rellenar la estructura de tipo OmsT_Qm_IP_Queue_Configuration, se llama a otra funcin que tambin est definida en el bloque de funciones: attr_def_red_parameters_get, y que se muestra a continuacin (observar que no est el cdigo completo, slo las partes ms 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 parmetros RED */ red_queue_params_ptr = ip_qos_red_queue_params_mem_alloc ();
98

/* A continuacin recoge los parmetros 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 ningn mtodo 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 parmetros obtenidos a la estructura con la que ha sido llamada la funcin. */ qconfig_ptr->red_queue_params_ptr = red_queue_params_ptr; */
Ilustracin 50. Parmetros recogidos mediante attr_def_red_parameters_get.
Es interesante en esta ltima funcin saber que cuando recoge el parmetro RED Status, puede encontrarse con diferentes valores, definidos como constantes en el fichero de cabecera antes includo, oms_qm.h:
#define #define #define OMSC_NO_RED OMSC_RED OMSC_WRED 0 1 2
o con nuestro valor definido para la extensin de RED:

#define OMSC_GRED 3
99
Captulo 4.Implementacin del algoritmo RED en OPNET ste valor se quedar guardado en la estructura:
qm_attr_ptr qconfig_ptr red_status
Y se utilizar en una funcin posterior para saber qu tipo de clculo aplicar a la hora de obtener la probabilidad de descartes, y si un paquete debe ser descartado o no.
Funcion para recoger parmetros:
Un punto importante que explicar, es la funcin que recoge los parmetros, que ya se ha visto en otras ocasiones, pero no ha sido explicada. Vemoslo con un ejemplo:
op_ima_obj_attr_get (id_objeto, "Nombre Param", &variable );
sta funcin, perteneciente a los Kernel Procedures (KP) aportados por Simulation Kernel, recoge el parmetro 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
ip_qos_support.ex.c,
momento, se debe saber que las tres estn definidas en el fichero externo dependiente de oms_qm.h, fichero includo a travs del header block.
4.3.4 Modificacin 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 travs de una interfaz grfica, sin adentrarse en la complejidad de la implementacin 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 Gestin 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 ms accesible a los procesos para hacer sus clculos, como hemos visto que pasaba en el anterior captulo con la recoleccin de los atributos FIFO Profiles y RED Parameters. A continuacin se mostrar cmo extender el conjunto de atributos del nodo QoS para tener acceso al nuevo algoritmo GRED.
100
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:
Ilustracin 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 agrupacin de atributos, por lo que sta columna no tendr valor para nosotros). Type: tipo de informacin que guarda el atributo. Un atributo puede ser de tipo integer, double, compound, string, El valor compound significa que el atributo guardar informacin 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 vaca 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. Tambin se usa para sugerir un valor al usuario.
101
Captulo 4.Implementacin del algoritmo RED en OPNET Tags: palabras claves para identificar el atributo dentro del men Edit Attributes a la hora de realizar una bsqueda.
Ahora vamos a analizar lo que contiene el atributo FIFO Profiles. Para ello, sealar en la tabla este atributo y pulsar con el ratn en el botn atributos de los que est compuesto el atributo. . Aparece la siguiente ventana, que son los
Ilustracin 52. Atributos de FIFO Profiles
Que equivale al siguiente nivel en la jerarqua 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 tamao de buffer en una cola FIFO va a ser de 500 paquetes.
4.3.4.2 Aadir un nuevo atributo

Si se necesita aadir un nuevo atributo correspondiente a la configuracin de un nuevo AQM diferente de RED se podra hacer escribiendo su nombre en el campo New attribute y pulsando el botn Add, con lo que el atributo aparecera en una tabla, y habra configurar el resto de los campos. En la tabla siguiente, se muestra un ejemplo en el que se ha aadido un atributo compuesto que pueda guardar los parmetros de configuracin PID:
102
Ilustracin 53. Aadir un nuevo atributo
Observar que a diferencia de la primera tabla, en estas dos ltimas ha desaparecido la columna Group (slo se pueden agrupar atributos del primer nivel de la jerarqua) 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 dilogo del atributo compuesto. Ayuda a la comprensin del atributo compuesto. Prominent: para miembros de un atributo compuesto, incluye el atributo en las bsquedas con filtro.
A partir de tener el nuevo atributo, slo quedara crear y configurar su rbol de atributos (se ha definido de tipo compuesto por necesitar varios parmetros). No nos vamos a detener en cmo crear toda la jerarqua 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):
Ilustracin 54. Atributos dentro del atributo compuesto RED Parameters
103
Captulo 4.Implementacin del algoritmo RED en OPNET Se ha aadido la nueva versin de RED, GRED, como un nuevo tipo de RED, por lo que tendr un tratamiento parecido al de la versin de RED, WRED. Es decir, se debe aadir una nueva opcin 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 opcin Edit Properties como en los casos anteriores).
4.3.4.3 Aadir valores a un atributo ya creado

Para modificar un atributo, debemos hacer pblico su conjunto de valores. Para ello, sealamos dicho atributo y damos a la opcin Edit Compound Attributes Properties (como se ve, la opcin de las anteriores ventanas no est habilitada). Aparece una nueva ventana (se muestra a continuacin), con los atributos de RED Parameters, incluido el del atributo GRED aadido anteriormente.
Ilustracin 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 (vaco, al ser atributo compuesto). Comments: Comentarios explicando el significado del atributo o cualquier otra informacin que se considere oportuna.
104
Control de Congestin con OPNET Symbol map: Conjunto de valores posibles del atributo. Vemos que las opciones posibles son las que saldran al editar los atributos. La correspondencia de esto con la configuracin de parmetros sera los siguiente:
Ilustracin 56. Correspondencia con Symbol map
Para el conjunto de valores del symbol map, debemos entrar en el modo privado (el no accesible por el pblico): 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).
Ilustracin 57. Propiedades del atributo RED Parameters
105
Captulo 4.Implementacin del algoritmo RED en OPNET Los campos que antes estaban deshabilitados se habilitarn ahora. Por poner un ejemplo, vamos a aadir un nuevo valor al Symbol map, como si furamos a aadir un nuevo algoritmo, CRED: escribirlo en el campo donde pone New Symbol:
Ilustracin 58. Aadiendo 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 pblico). Lo seleccionamos y sale una nueva ventana con un nuevo Symbol map, que debemos cambiar para aadir el nuevo valor. Lo aadimos y le damos el valor 4 (luego habra 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 cdigo).
Ilustracin 59. Asignacin de valor a nuevo smbolo
Pulsar OK para volver a la ventana anterior, y volvemos a pulsar Edit Attribute Properties. Ya en la ventana, volver al dominio pblico habilitando la casilla Public. Al lado, aparecer la palabra unnamed, indicando que se ha creado un nuevo fichero de propiedades. Pulsar ahora el botn Save 106
Control de Congestin con OPNET Public. Aparece una ventana que nos deja elegir dnde grabar el nuevo fichero. Grabarlo con el nombre RED_Parameters3 y pulsar OK.
Ilustracin 60. Nuevo fichero de propiedades pblicas 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 cmo en el function block estn implementadas las funciones para recoger los atributos configurados a partir del men Interfaces Model Attributes, centrndonos en FIFO y RED. Finalmente se ha visto la necesidad de modificar una de las libreras, oms_qm.h, para declarar una variable que se corresponda con el valor aadido (versin de RED, GRED) para el atributo RED Status. Como ejemplo para la modificacin de atributos, se ha explicado cmo aadir un nuevo valor, CRED, incluyndolo 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 gestin de paquetes mediante el protocolo IP, y los algoritmos de control de congestin.
4.4 Estudio de un nodo router

En este apartado se describe la estructura interna de uno de los nodos router existentes en las topologas utilizadas en este proyecto. El router es el encargado, entre otras cosas, de aplicar las disciplinas de cola y de control de congestin 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 ms importante de los analizados para este proyecto. Primero se describir su estructura a travs del modelo de nodos, y luego su comportamiento a travs del de procesos. Tanto el modelo de nodos como el de procesos son ms complejos que los del nodo QoS, pues en este caso s que estamos ante un nodo que simula el desempeo de una tarea real dentro de una red. Estudiaremos esos modelos a continuacin. En el apartado anterior ya se ha descrito cmo acceder tanto al editor de nodos como al de procesos, por lo que si se necesita explicacin sobre lo que se va a hacer en los puntos siguientes, se puede recurrir a dicho apartado.
107
4.4.1 Modelo de nodos del nodo router1

Es importante saber que si tenemos varios nodos router del mismo tipo en la red, dara 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.
Ilustracin 61. Modelo de nodos de Router1, ethernet4_slip8_gtwy_adv
Como se ve en la ilustracin, en el modelo de nodos de un router hay varios mdulos de tipo procesador que implementan diferentes protocolos o mecanismos de comunicacin como son ip, tcp, udp, tpal, dhcp, ARP, etc. que cooperan envindose datos a travs de packet streams (en color rojo y azul en el dibujo) y datos estadsticos (entre los mdulos de tipo transmisor/receptor y los de tipo cola). Una vez analizados varios de esos mdulos, se ha visto que el manejo de los mecanismos de gestin de colas en ste modelo de nodos se hace a partir del mdulo ip, no es necesario analizar los dems. Por lo tanto, es en el que nos centraremos a partir de ahora.
108
4.4.2 Modelo de procesos del mdulo ip

Para acceder al modelo de procesos del mdulo ip, utilizar el mismo procedimiento que se ha venido explicando en el resto del documento: dar doble clic en el mdulo ip.
Ilustracin 62. Modelo padre del mdulo ip: ip_dispatch
Aparece la ventana del editor de procesos con el modelo de proceso ip_dispatch, que es el proceso padre o raz del mdulo, es decir, el modelo de procesos de ip que se va a activar nada ms empiece la simulacin. El modelo de procesos raz se especifica en el atributo process model del mdulo:
Ilustracin 63. Especificacin de ip_dispatch como proceso raz en el mdulo ip
109
4.4.2.1 Anlisis de ip_dispatch

La funcin de ip_dispatch es sobre todo repartir las interrupciones que le llegan al mdulo 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 jerarqua de procesos del mdulo por lo que es una de las ms 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 seleccin 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 tambin en el modelo de proceso del nodo QoS. Tambin hay definicin de macros para las condiciones de las transiciones, y definiciones de constantes. Por ltimo, declara estructuras globales y funciones implementadas en function block.
Declaracin 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 ms sobre ellos.
STD
Como se ve en la ilustracin 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 cdigo del tipo de interrupcin producida, para comprobar si se cumple la transicin para pasar al siguiente estado.
- init: llama a la funcin ip_dispatch_do_init(), la cual registra el puntero a la variable que se utilizar como memoria compartida con otros procesos: 110

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 interrupcin para usar posteriormente. En la transicin, se ejecuta la funcin ip_dispatch_wait_for_registrations(), que se asegura que antes de proseguir estn registrados en el Registro de Procesos todos los procesos relacionados con IP, para evitar incoherencias durante el resto de la simulacin.
- wait, wait_1, wait_2: transita de estado a estado planificando auto-interrupciones, teniendo en cuenta los tiempos de simulacin a la hora de interrumpir. En la transicin, se ejecuta la funcin ip_dispatch_init_phase_2(), que prosigue con la inicializacin de variables efectuada en el estado init.
- cmn_rte_tbl: plantea dos posibilidades de transicin: estado inactive (si todas las interfaces IP del nodo estn inactivas) y estado init_too(hay alguna interfaz activa). Nos centraremos en este ltimo estado. Durante la transicin al siguiente estado, init_too, se ejecuta la funcin ip_dispatch_distribute_routing_info(), que activa los distintos protocolos de enrutamiento configurados en el router.
- init_too: en este estado se finaliza la inicializacin del mdulo, a partir de lo cual crea diversos hijos que ejecutan tareas especficas. En los exit executives encontramos la llamada a la funcin:
ip_dispatch_cleanup_and_create_child_processes ();[1]
Esta funcin es muy importante porque es la que desencadena el procesamiento de las interfaces IP. A partir de aqu, dejamos de analizar la mquina de estados, y nos centramos en la ejecucin de sta funcin definida, como todas las dems con el prefijo ip_dispatch, en el function block.
Llamadas a funciones desde el function block. Estudio del cdigo fuente.
Seguiremos la trayectoria de llamadas a partir de la funcin 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 enva datos. */ ip_rte_qos_information_process (); [2]
111

... 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, adems de mecanismos de control de congestin como RED/WRED. **/ /* Guarda en la memoria compartida informacion acerca de cada interfaz*/ module_data.shared_mem.iprmd_ptr = &module_data; /* Almacena en memoria compartida handles para paquetes enviados y descartados. Tambien se comparten otras variables de estado con el modelo de proceso de la interfaz de salida para tener en cuenta el trafico background en las estadisticas de esa interfaz de salida.*/ module_data.shared_mem.locl_pk_dropped_hdl_ptr = &module_data.locl_num_pkts_dropped_hndl; module_data.shared_mem.globl_pk_dropped_hdl_ptr = &module_data.globl_num_pkts_dropped_hndl; module_data.shared_mem.locl_num_pkts_sent_hdl_ptr = &module_data.locl_tot_pkts_sent_hndl; /* Obtener num de interfaces.*/ iface_table_size = inet_rte_num_interfaces_get (&module_data); /* Inicializar la lista QoS iface. */ op_prg_list_init (&qos_ifaces_list); /*Comprobar la existencia del objeto QoS Attributes Config. Si no existe o no est configurado,crea perfiles por defecto.*/ ip_rte_qos_attr_config_info ();[3] /* Obtener y preprocesar la informacion de la IP QoS local */ ip_qos_info_process ((void *) &module_data, &qos_ifaces_list);[4] /* Obtener el numero de interfaces con QoS activa */ total_num_of_qos_ifaces = op_prg_list_size (&qos_ifaces_list); /* Reservar memoria para el array de datos de la interfaz QoS */ module_data.interface_qos_data_pptr = (IpT_Rte_Iface_QoS_Data**)op_prg_mem_alloc(iface_table_size * sizeof(IpT_Rte_Iface_QoS_Data *)); /* Crear una tabla para buscar el objid de cada interfaz*/ intf_objid_lookup_table = ip_rte_proto_intf_attr_objid_table_build (module_data.ip_parameters_objid); /* Recorrer todas las QoS active interfaces para inicializar parametros relacionados con QoS como queuing schemes, CAR y RED/WRED. */ for (qos_iface_index = 0; qos_iface_index < total_num_of_qos_ifaces; qos_iface_index ++) {
112

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 travs de las definiciones en el Header Block. A continuacin del nombre de cada funcin se detalla el fichero al que pertenecen:
3. ip_rte_qos_attr_config_info ();[ip_qos_attr_def_support.ex.c]
ip_rte_qos_attr_config_info () { /** Comprueba la existencia de ip attribute object. **/ if (ip_attribute_object_exists == OPC_FALSE) { /* Comprueba la existencia del objeto mediante el registro de procesos. */ op_prg_list_init (&proc_record_handle_list); oms_pr_process_discover (OPC_OBJID_INVALID, &proc_record_handle_list, "protocol", OMSC_PR_STRING, "ip_qos_attribute_object", OPC_NIL); if (op_prg_list_size (&proc_record_handle_list) == 0) {/* Si no existe el nodo QoS, crea los valores por defecto. */ oms_qm_package_init (); ip_rte_queuing_profiles_defaults_register ();} }
113

FOUT; }
Observar en esta funcin 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 haba registrado el nodo mediante oms_pr_process_register. Contando que dicho nodo va a existir en todas las topologas 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. Slo tener en cuenta que dichas funciones son las que dan los valores QoS globales por defecto, en caso que el usuario no haya aadido 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 informacin 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 informacin 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 nmero de interfaces configuradas en el router. */ num_rows = op_topo_child_count (iface_info_objid, OPC_OBJTYPE_GENERIC); /* Salir de sta funcin si no hay interfaces configuradas. */ if (num_rows == 0)FOUT; oms_qm_package_init ();/* Inicializa ciertos valores QoS */ op_prg_list_init (&policies_list); /* Creacin de base de datos para almacenar perfiles QoS locales. */ profiles_dbase_ptr = ip_qos_profiles_database_create (module_data_ptr); /* Recorrer todas las interfaces IP del router. */ for (i = 0; i < num_rows; i++) { /* Recoger identificador del atributo interfaz */ ith_attr_objid = op_topo_child (iface_info_objid, OPC_OBJTYPE_GENERIC, i);
114
/* Procesar la informacin 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 informacin de subinterfaces. En nuestro caso est vaco*/ 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 informacin. */ } /* Liberar memoria */ ip_qos_local_profiles_memory_free (profiles_dbase_ptr, &policies_list); FOUT; }
En esta funcin 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 anlisis, que en caso de querer configurar un router con subinterfaces distintas, una subinterfaz en realidad tiene idntica estructura a una interfaz, por lo que su procesamiento a la hora de recolectar parmetros QoS tambin idntico.
Ilustracin 64. rbol de atributos IP, Interface Information en un router, recorrido por la funcin ip_qos_info_process
Las funciones resaltadas son interesantes por inicializar y reservar memoria para varios parmetros relativos a QoS. No nos detendremos en ellas. Seguimos analizando la ltima funcin resaltada, ip_qos_iface_info_process, que recorrer el sub-atributo compuesto QoS Scheme, como veremos a continuacin. 115
5. ip_qos_iface_info_process ();
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; /* Funcin que procesa la informacin de cada interfaz, incluyendo QoS. */ FIN (ip_qos_iface_info_process (Objid iface_objid, List * qos_ifaces_lptr,)); /* Reservar memoria para la estructura QoS. */ iface_qos_info_ptr = (IpT_QoS_Iface_Info *) op_prg_mem_alloc (sizeof (IpT_QoS_Iface_Info)); /* Initializar la estructura con valores iface_qos_info_ptr->hold_q_capacity = iface_qos_info_ptr->reserved_bandwidth = iface_qos_info_ptr->bandwidth_type = iface_qos_info_ptr->buffer_size = iface_qos_info_ptr->scheduling_info = iface_qos_info_ptr->red_info = iface_qos_info_ptr->in_shaping_info = iface_qos_info_ptr->out_shaping_info = por defecto. */ (int) OmsC_Buffer_Parent_Limit; 1.0; IpC_QoS_Relative_Bandwidth; 1000000; OPC_NIL; OPC_NIL; OPC_NIL; OPC_NIL;
/* Obtencin 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 informacin QoS para la interfaz. */ ip_qos_iface_attribute_sort (profiles_dbase_ptr, iface_qos_info_ptr, qos_attr_objid,qos_scheme_objid, policies_lptr); [6] /* Crear perfiles QoS para esta interfaz. */ ip_qos_iface_profiles_create (profiles_dbase_ptr, &qos_iface_config_ptr, iface_qos_info_ptr, qos_attr_objid); [7] FOUT; }
116
Control de Congestin con OPNET En la Ilustracin 64 se ven los atributos recogidos por sta funcin. Al ser QoS Scheme un atributo compuesto, se utiliza la funcin resaltada ip_qos_iface_attribute_sort para registrarlo.
6. ip_qos_iface_attribute_sort ();
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 funcin clasifica la informacin QoS configurada desntro de la interfaz en una de las siguientes categoras: scheduling,in/out CAR y RED. Slo se muestra el cdigo 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 cdigo se ha omitido. 117
7. ip_qos_iface_profiles_create ();
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 funcin crea perfiles QoS para las interfaces IP */ /* basada en la infomacin 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 configuracin 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 informacin RED. */ red_info_ptr = iface_qos_info_ptr->red_info; profile_name = qos_mechanism_ptr->profile_name; /* Obtener queuing scheme basndose 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 configuracin de interfaz QoS. */ qos_iface_config_ptr = (IpT_QoS_Iface_Config *)
118

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 ();
Esta funcin comprueba la existencia perfiles FIFO. Si ya existe (se ha configurado globalmente mediante el atributo QoS), como es el caso, lo agrega a la interfaz del router de forma local. Si no, crea uno por defecto.
static OmsT_Qm_Attributes * ip_qos_fifo_profile_get (IpT_QoS_Profiles_Dbase * profiles_dbase_ptr,int hold_q_capacity, IpT_QoS_Mechanism_Info * qos_mechanism_ptr, IpT_QoS_Mechanism_Info * red_info_ptr, Objid qos_attr_objid) { void * tmp_ptr; char * profile_name; Boolean red_from_policy = OPC_FALSE; OmsT_Qm_Attributes * IpT_QoS_Profile_Entry * OmsT_Qm_IP_Queue_Configuration * OmsT_Qm_RED_Queue_Params * qm_attr_ptr = OPC_NIL ; profile_entry_ptr; qconfig_ptr = OPC_NIL; red_params_ptr = OPC_NIL;
/* Obtener el nombre del perfil. */ profile_name = qos_mechanism_ptr->profile_name; /* Comprobar si el perfil ya existe en la base de datos local mediante la funcin resaltada. Si es as, salir de la funcin. 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 todava 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, aade el perfil global al local del router desde la base de datos mediante la siguiente funcin: */ 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 nmeros indicados entre corchetes), el control vuelve a la funcin ip_rte_qos_information_process, que crea e invoca el modelo de procesos ip_output_iface. A continuacin de muestra un esquema-resumen de lo explicado en este apartado.
119
Ilustracin 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 configuracin. 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 gestin de los paquetes que llegan a cada interfaz. Por ltimo, queda explicar dnde se declaran los procesos hijos, entre ellos ip_output_iface.
Declaracin 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 jerarqua. Sin embargo, si slo queremos ver la lista de procesos hijo que puede crear y no modificarla, ir al men File Open Child Process Model. Se desplegar una ventana en la que aparecen los procesos hijos declarados: 120
Ilustracin 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 Anlisis 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. Ms adelante se estudiarn con ms detalle. Estas variables son importantes porque, como se ha dicho en el Captulo 3 sern las que vayan guardando los valores que harn transitar el proceso de un estado a otro del STD. No se explicar ninguna en concreto, pero se puede ver cmo van tomando valores a medida que se hacen llamadas a las funciones tanto del function block como de los ficheros externos de tipo .ex.c.
121
Ilustracin 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 interrupcin ante cada llegada de un paquete.
Declaracin de ficheros externos
Desde el men File, como se indic para el anterior modelo de proceso, se accede a la lista de ficheros externos, entre los cuales cabe destacar de nuevo ip_qos_support.ex.c y oms_qm.ex.c.
122
STD
Ilustracin 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 ningn executive), y la transicin, para la cual no se necesita cumplir ninguna condicin, bloquendose en init2. En la transicin se produce la llamada a do_init, funcin definida en el bloque de funciones o function block. Esta funcin inicializa variables, destacando la variable de estado qm_info, de tipo OmsT_Qm_Info. Esta variable se configura para cada interfaz. Contiene informacin general como el mximo nmero de paquetes en cada cola, funcionamiento del procesador o lista de paquetes.
- init2: Estado que no tiene ningn executive. En la transicin, que al igual que la anterior no tiene condiciones, se llama a la funcin allocate_buffers, definida en el function block. Lleva a cabo la segunda fase de inicializacin de las variables del proceso, que slo se puede efectuar cuando se ha completado la llamada do_init. A continuacin se presenta un extracto de dicha funcin.
static void allocate_buffers (void) { IpT_Rte_Iface_QoS_Data* iface_qos_data_ptr; OmsT_Buffer_Pool_Handlebuffer_pool_handle; charnew_name [200], intf_name[128]; doubleprocessing_rate;
123
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 funcin 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 funcin 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. Atencin. No se estn invocando, slo registrando. Su invocacin vendr ms 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 declaracin est la palabra reservada extern, que como decamos, hace que una variable sea accesible desde todas las funciones. Tambin se definen las macros asociadas de sta manera (el ejemplo corresponde a la primera de las asignaciones mostradas en la funcin de arriba):
#define OMS_ENQ_TEST_FUNC (arch_type) ((OmsT_Qm_Enqueue_Test_Func)\
124

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 invocacin, se hacen nuevas asignaciones a la tabla, pero la forma de acceder a ellas sigue siendo mediante la misma macro. [2] La funcin 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 nmero mximo de paquetes. Tambin 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); /* Inicializacin 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; /* Creacin 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 informacin concerniente a las colas de una interfaz. */ FRET (qm_info); }
La funcin oms_qm_qscheme_specific_functions_register tiene una utilidad parecida a la funcin explicada anteriormente: asocia funciones a la tabla global OmsI_Qscheme_Specific_Func_Table, declarada en oms_qm.h. Esta tabla contendr funciones especficas para cada disciplina de cola. Para poner un ejemplo, a continuacin se muestra una de las asignaciones hechas en la funcin, cuando la estructura que se utiliza en la FIFO:
OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing][OmsC_Qm_Pkt_Deq_Complete] = (OmsT_Qm_Qscheme_Void_Func) OPC_NIL; OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_FIFO_Queuing][OmsC_Qm_Queue_Select] = (OmsT_Qm_Qscheme_Void_Func) Oms_Qm_FIFO_Queue_Select;
125
Captulo 4.Implementacin del algoritmo RED en OPNET La invocacin de las funciones asociadas se har mediante macros, como en el caso anterior. Como ejemplo de la declaracin 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 funcin ip_qos_info_assign, definida en ip_qos_support.ex.c, es especfica del protocolo IP, y asigna valores a ciertos campos de la estructura qm_info. Es una funcin interesante, porque obtiene informacin de la base de datos global (recordemos que desde el nodo QoS se haba guardado ah parte de esa informacin), 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 funcin 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 invocacin que le llega, y dependiendo de eso, se cumplir una condicin u otra, y realizar una transicin u otra de entre las posibles. Nos hemos centrado en la condicin 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 transicin, que se efectuar cada vez que llegue un paquete, se ejecuta la funcin enqueue_packet, definida en el bloque de funciones. Esta funcin 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 pginas se ver el conjunto de llamadas que desencadena la invocacin de enqueue_packet. Al igual que se hizo en ip_dispatch, al lado de las funciones aparecern nmeros para facilitar su seguimiento y unos corchetes a su derecha indicando dnde estn.
Llamadas a funciones desde enqueue_packet: estudio de cdigo fuente.

[Function Block]
[1] enqueue_packet();
Almacena el paquete recibido en una de las listas de la estructura qm_info. Si el procesador de la interfaz est libre, se enva el paquete.
static void enqueue_packet (void) { Packet * pkptr = OPC_NIL; intqueue_id = -1; Ici *qos_ici_ptr = OPC_NIL; OmsT_Qm_Signalqm_signal; OmsT_Qm_Queue_Pool*q_pool_ptr = OPC_NIL;
126

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 estadsticas */ 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 estadsticas 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 estn vacas. */ /* 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 despus 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();
127
Captulo 4.Implementacin del algoritmo RED en OPNET Esta funcin obtiene el criterio para conceder prioridad al paquete que llega, accediendo a la informacin de dicho paquete y basndose en el ToS . De esta forma, se permite al procesador almacenar al paquete en la cola correcta (dependiendo de la planificacin 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 informacin del paquete mediante la siguiente funcin: */ ip_qos_pk_info_init (&pkt_info); if (op_pk_nfd_is_set (pkptr, "MPLS Shim Header") == OPC_TRUE) { //Obtener el tamao 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 funcin en la jerarqua de colas una adecuada para almacenar el paquete. Pero en nuestro caso, usamos una por defecto, pues slo 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 informacin 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 funcin anterior */ }
En realidad, acabaremos teniendo valores por defecto porque en la configuracin global, hemos elegido un perfil bsico FIFO sin ninguna distincin de prioridad (todos los paquetes tendrn la misma, y se almacenan en la misma cola FIFO por defecto dentro del router), y los datos enviados por todos los nodos de la red son de tipo FTP. 128
Control de Congestin con OPNET Las funciones resaltadas ip_qos_pk_info_init, mpls_support_phb_to_drop_precedence_convert y ip_qos_pk_info_get se han sealado por ser interesantes ya que describen el procesamiento de los distintos campos de las estructuras que representan los paquetes. Realmente no implican ningn cambio en la implementacin del AMQ RED, por lo que aqu no se muestran, pero se deja a eleccin del usuario estudiarlas por su inters a la hora de entender mejor los conceptos y las estructuras usadas en la aplicacin.
[3] Oms_Qm_Packet_Process
[oms_qm.ex.c]
Esta funcin determina el clasificador y enva 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; /* Basndose en el status del procesador, guardar o enviar el paquete */ Oms_Qm_Incoming_Packet_Handler (pkptr, qm_info, qpool_ptr, enq_id, pkt_info);[4] if (OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC (qm_info->queue_processing_scheme) != OPC_NIL) (OMS_QSCHEME_VARS_UPDATE_ENQ_FUNC (qm_info->queue_processing_scheme)) (pkptr, qm_info, qpool_ptr, enq_id); break; } case OmsC_Qm_No_Queuing: { qm_info->signal = OmsC_Qm_Send_Packet; break; } default:break; } FOUT; }
[4] Oms_Qm_Incoming_Packet_Handler
[oms_qm.ex.c]
129
Captulo 4.Implementacin del algoritmo RED en OPNET Funcin que maneja los paquetes recibidos. Obtiene si hay espacio para el paquete en el buffer o no. Tambin actualiza estadsticas y variables de tiempo para futuros cmputos 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 basndose en los argumentos de invocacin. Tambin identifica si hay congestin. En ste caso, se aplica el algoritmo seleccionado para restringir el tamao de la cola. Devuelve TRUE si el paquete se ha insertado en la cola con xito, y FALSE en caso contrario.
OMSC_EXPORT Boolean Oms_Qm_Packet_Enqueue (Packet* pkptr, OmsT_Qm_Info* qm_info, OmsT_Qm_Queue_Info* q_info_ptr,OmsT_Qm_Pkt_Info pkt_info, double insert_time, int PRG_ARG_UNUSED (enqueue_q_id)) { if ((OMS_ENQ_TEST_FUNC (qm_info->arch_type)) [6] (qm_info, q_info_ptr, pkptr, pkt_info) == OmsC_Buffer_Insert_After) { if (oms_buffer_enqueue (q_info_ptr->buffer_handle, pkptr, OPC_NIL, insert_time) != OmsC_Buffer_Enqueue_Success) {FRET (OPC_FALSE);} } else {FRET (OPC_FALSE);}
130

FRET (OPC_TRUE); }
[6] ip_qos_packet_enqueue_test ();
Como se ha visto en pginas anteriores, la macro OMS_ENQ_TEST_FUNC se haba definido en oms_qm.h y se haba asignado a esta funcin a travs de ip_qos_sup_functions_register de manera que al aparecer esa macro en el texto, se invoca ip_qos_packet_enqueue_test. Esta funcin comprueba si el paquete puede ser encolado, basndose en el espacio disponible y en el nivel de congestin de la red en ese momento, caso en el cual se pueden aplicar distintas disciplinas. De hecho en esta funcin es donde se elige si aplicar AQM, y cual aplicar. As, aqu se ven las llamadas a las funciones especficas de cmputo del algoritmo RED. Es, por lo tanto, una de las ms 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 mximo nmero de paquetes en la cola.*/ max_number_of_pkts = ip_attribs_ptr->max_total_no_buf_pkts; /* Obtener nmero 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 nmero de paquetes almacenados en esta cola */ current_number_of_pkts = oms_buffer_num_packets_get (q_info_ptr->buffer_handle); /* Mximo nmero de paquetes permitido en perodos de congestin..*/ max_subqueue_size = queue_config_ptr->max_size; /* Computar el tamao medio de cola para RED, WRED, GRED, etc. */ if (queue_config_ptr->red_status != OMSC_NO_RED) { Oms_Qm_Average_Queue_Size_Update [7](q_info_ptr, queue_config_ptr->red_queue_params_ptr->exponential_weight_factor);
131

} /* Obtener el tamao 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 congestin. En caso que si, forzar el lmite LLQ.*/ /* 4. Para situaciones de RSVP */ /* 5. Si no hay espacio basndose en un lmite, 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 tamao del buffer sin hacer otros clculos.*/ 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 nmero de paquetes en el buffer con el nmero 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 congestin y almacenarlo.*/
132

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 funcin actualiza el parmetro Tamao medio de cola o Average_queue_size, usado por RED para determinar si un paquete debe ser descartado debido a la congestin. Esta funcin 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 parmetros 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 parmetros, hacer el clculo.*/ 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 parmetro average queue size en la estructura de datos. */ ((OmsT_Qm_RED_Vars *)queue_info_ptr->drop_policy_vars_ptr)->average_queue_size= avge_queue_size; FOUT; }
133
Como se ve en la funcin, se calcula el tamao de cola utilizando la frmula de RED ya vista en la teora,
Qavg = (1 q) Qavg + q Qavg

siempre y cuando el tamao de cola actual no sea cero. Si no, tiene en cuenta el tiempo pasado desde el ltimo paquete recibido, para que el algoritmo sea ms eficiente.
[8] oms_qm_red_packet_drop;
[oms_qm.ex.c]
Esta funcin implementa el comportamiento del algoritmo RED y su variante WRED. Adems, es donde se ha modificado el cdigo para aadir 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; /* Clculos necesarios para la variante WRED. */ red_match_property = red_queue_params_ptr->match_property; num_entries = op_prg_list_size(red_queue_params_ptr->red_class_params_lptr); for(i = 0; i < num_entries; i++) { red_class_params_ptr = (OmsT_Qm_RED_Class_Params *) op_prg_list_access (red_queue_params_ptr->red_class_params_lptr, i); /* Si estamos en el caso por defecto */ if(red_class_params_ptr->match_value == OmsC_Qm_Best_Effort) default_red_class_params_ptr = red_class_params_ptr; switch(red_match_property) { case OmsC_Qm_Discard_Class: discard_class = (int) ((dscp & 24 ) >> 3); if(red_class_params_ptr->match_value == discard_class) match_found = OPC_TRUE; break; case OmsC_Qm_Dscp: if(red_class_params_ptr->match_value == dscp) match_found = OPC_TRUE; break; case OmsC_Qm_Ip_Precedence:
134

/* 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 mximo y mnimo.*/ max_threshold = red_class_params_ptr->maximum_threshold; min_threshold = red_class_params_ptr->minimum_threshold; /* Obtener el denominador de probabilidad mxima. Este parmetro es la fraccin de paquetes descartados cuando el tamao medio de cola alcanza el umbral mximo. */ mark_prob_denominator = red_class_params_ptr->mark_probability_denominator; /* Si WRED est habilitado, se modifica el umbral mnimo, que depende de la IP precedence. OMSC_WRED solo se configura globalmente desde el icono IP QoS Config (nuestro nodo QoS en la topologa) */ 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 tamao medio de cola cae entre los umbrales mximo y mnimo, descartar el paquete aleatoriamente con una probabilidad. */ if ((avge_queue_size >= min_threshold) && (avge_queue_size < max_threshold)) { /* Calcular la probabilidad de prdida de este paquete.*/ dropping_probability = 1.0 / mark_prob_denominator * (avge_queue_size - min_threshold) / (max_threshold - min_threshold); /* Obtener un nmero aleatorio. */ random_number = op_dist_uniform (1.0); FRET ((Boolean) (random_number <= dropping_probability)); } else /* CODIGO AADIDO PARA IMPLEMENTACIN 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 mximo. En vez de descartar todos los paquetes directamente, vara la frmula para que se aumente la probabilidad desde maxp o probabilidad mxima hasta uno. */ maxp = 1.0 / mark_prob_denominator; dropping_probability =((1.0-maxp)* (avge_queue_size-max_threshold))/max_threshold + maxp; random_number = op_dist_uniform (1.0); */
135
FRET ((Boolean) (random_number <= dropping_probability)); } FRET ((Boolean) (avge_queue_size >= max_threshold)); } }
Este es el cdigo que se ha aadido en oms_qm.ex.c para la implementacin de la variante GRED. Como se ve, slo entra en funcionamiento si el tamao medio de cola (o parmetro avge_queue_size) excede el umbral mximo, implementado en forma de condicin if. As, se calcula la probabilidad de prdida de paquetes como ya se dijo en el bloque de teora, a partir de la frmula
Pd_gred =(1- Maxp)(Qavg Maxth) / (Maxth) + Maxp
Si
Maxth<Qavg<2*Maxth
Por ltimo, despus de haber calculado lo que hacer con el paquete, se deben actualizar estadsticas, lo cual se hace de nuevo en la funcin del function block enqueue_packet, utilizando output_iface_stats_register:
[9] output_iface_stats_register;
[function block]
Registra estadsticas para una cola para mostrarlas cuando el usuario lo requiere. A continuacin se muestra la parte de la funcin 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 estadsticas para Buffer Usage (packets y bytes), queuing delay, jitter, trfico descartado, enviado y recibido. */ /* Registrar estadsticas para RED si est habilitado.*/ (OMS_ATTRIBUTE_GET_FUNC (OmsC_Qm_IP)) (qpool_ptr, OmsC_Qm_RED_Status, q_index, &red_status); if (red_status == OMSC_RED) { sprintf (new_name, "RED Average Queue Size %s Q%d%s", intf_name, q_label, queue_category_str); dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "RED Average Queue Size", stat_annotation_str, OPC_STAT_LOCAL); Oms_Dim_Stat_Rename (dim_stathandle, new_name);
136

oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle); } else if (red_status == OMSC_WRED) { /* Registrar estadsticas 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) { /* CDIGO AADIDO */ /* Registrar estadsticas 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 acabara la sucesin de llamadas que procesan un paquete desde su llamada hasta la ejecucin del AQM para decidir si descartar/marcar un paquete o no.
En la siguiente pgina se muestra un esquema con las llamadas implicadas desde el modelo de proceso ip_output_iface, indicando el orden en que se producen y agrupadas por fichero donde fueron implementadas, al igual que se hizo con el modelo de proceso ip_dispatch, con el fin de aportar un poco de claridad a lo que se ha explicado.
137
Ilustracin 69. Esquema de llamadas desde ip_output_iface
Otras funciones que participan en la implementacin del AQM RED.
Adems de lo explicado aqu, quedaran varias llamadas a funciones para actualizar las variables y estructuras de RED, borrarlas, etc. En este caso, por ser un acercamiento a lo que es el funcionamiento de OPNET en general y al procesamiento en los routers de los AQM en particular, 138
Control de Congestin con OPNET no nos centraremos en esas funciones. En caso de querer aadir nuevos algoritmos de gestin Activa de Colas, habra que modificarlas, pues habra que aadir nuevas estructuras o ampliar las existentes, y luego llevar a cabo su inicializacin y borrado, o acceder a la base de datos global para obtener y almacenar sus valores. Tambin se debe tener en cuenta que hemos estudiado la implementacin desde el punto de vista de la configuracin de atributos QoS global, y no en el router de forma local, por lo que si se quiere extender la implementacin al router, habra que modificar funciones a mayores . A continuacin se cita una recopilacin de todas las funciones examinadas para este proyecto
Fichero OPNET
ip_dispatch.pr.c
Funcin
ip_dispatch_cleanup_and_create_child_processes ip_rte_qos_informacion_process
ip_output_iface.pr.c
do_init allocate_buffers enqueue_packet output_iface_stats_register
qos_attribute_definer.pr.c
attr_def_fifo_profiles_info_parse attr_def_red_parameters_get
ip_qos_attr_def_support.ex.c
ip_rte_qos_attr_config_info ip_rte_queuing_profiles_defaults_register
ip_qos_support.ex.c
ip_qos_sup_functions_register ip_qos_queue_config_element_mem_alloc ip_qos_red_queue_params_mem_alloc ip_qos_red_class_params_mem_alloc ip_qos_attribute_value_get ip_qos_packet_enqueue_test ip_qos_iface_info_process ip_qos_iface_attribute_sort ip_qos_policy_process ip_qos_iface_profiles_create ip_qos_profiles_database_create ip_qos_local_profiles_memory_free ip_qos_iface_qos_info_destroy ip_qos_profile_dbase_access ip_qos_profile_dbase_add ip_qos_red_profile_get ip_qos_red_profile_attach ip_qos_fifo_profile_get
Oms_Qm_Average_Queue_Size_Update oms_qm_red_packet_drop oms_qm_red_vars_create
139

oms_qm_red_variables_update oms_qm_red_variables_delete oms_qm_initialize_all_pools oms_qm_support_queues_create oms_qm_support_queue_add oms_qm_support_queue_remove
oms_qm.ex.c
4.5 Esquema-resumen para la implementacin de GRED

En los puntos 4.3 y 4.4 de este captulo 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 prctica, sin entrar en detalles tericos, a modo de recordatorio o recopilacin de lo contado hasta ahora.
4.5.1 Modificacin de cdigo en ficheros externos

Abrir mediante un editor de texto o cdigo los ficheros nombrados a continuacin
4.5.1.1 oms_qm.h
Se aade la constante:
#define OMSC_GRED 3
Que servir como identificador de la versin Gentle de RED a la hora de seleccionarlo como atributo en el nodo QoS.
4.5.1.2 oms_qm.ex.c
Se aade dentro de la funcin oms_qm_red_packet_drop el siguiente cdigo
if ((avge_queue_size >= min_threshold) && (avge_queue_size < max_threshold)) { } else /* CODIGO AADIDO PARA IMPLEMENTACIN 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 mximo. En vez de descartar todos los paquetes directamente, vara la frmula para que se aumente la probabilidad
140

desde maxp o probabilidad mxima 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 funcin es evitar que se descarten paquetes cuando se ha sobrepasado el umbral mximo en RED .
4.5.2 Modificacin 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 mdulo ip (doble clic sobre el mdulo). 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 aade en la funcin output_iface_stats_register otra condicin ms para mostrar la estadstica tamao 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) { /* CDIGO AADIDO */ /* Registrar estadsticas para GRED si est habilitado.*/ sprintf (new_name, "GRED Average Queue Size %s Q%d%s",intf_name, q_label, queue_category_str); dim_stathandle = Oms_Dim_Stat_Reg (my_id, "IP Interface", "GRED Average Queue Size", stat_annotation_str, OPC_STAT_LOCAL); Oms_Dim_Stat_Rename (dim_stathandle, new_name); oms_qm_statistic_set(qinfo_ptr,OmsC_Qm_RED_Avg_Queue_Size, dim_stathandle); }
Guardar los cambios a partir del men de la ventana de bloque de funciones, File Commit. 141
Compilar el modelo de proceso (es necesario este caso despus de haber modificado el cdigo), a partir del men Compile del editor de procesos, o mediante el botn de acceso directo .
4.5.3. Modificacin de atributos del nodo QoS

Una vez modificado el cdigo, hay que permitir que el usuario seleccione el algoritmo. Para ello aadamos una nueva opcin 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 travs 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 botn 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 botn Edit Properties. Aparece una nueva ventana, con un nuevo Symbol map. Aadir 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 pblico habilitando la casilla Public. Pulsar en el botn 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 aadido el nuevo valor GRED para elegir desde el Editor de Proyectos.
142
Captulo 5. Experimentos
5.1 Introduccin
En este captulo se muestran algunos de los experimentos realizados para este proyecto, tanto variando las topologas, como los AQM utilizados o los tipos de estadsticas recogidos.
5.2 Topologas utilizadas

Las topologas siguen todas el esquema llamado cuello de botella o bottleneck, consistente en nodos emisores que envan datos a travs de conexiones rpidas, provocando que lleguen al router ms datos de los que puede procesar, desembocando en la correspondiente congestin de red. La clave para ello est en que la conexin entre los routers sea sensiblemente ms lenta que el resto de las conexiones de la red. En los siguientes puntos se detallarn todas las topologas utilizadas para realizar los experimentos de este proyecto.
5.2.1 CuelloBotella
Es la topologa ya conocida utilizada para describir el modelado en el modelo de redes mediante el editor de proyectos en el captulo 4, y la ms 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, adems de dos routers, dos switch y tres nodos de configuracin de parmetros globales (parmetros del tipo de aplicacin, perfiles de los nodos y configuracin de parmetros 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 conexin rpida que asegure que todos los datos son enviados sin problema, y el tiempo de procesamiento en los switch despreciable, para evitar congestin y
143
Captulo 5. Experimentos prdida de paquetes ya en ellos. La conexin entre los dos routers elegida es T1, mucho ms lenta (1.42 Mb), con lo que la congestin est asegurada.
5.2.1.1 Escenarios
El proyecto CuelloBotella consta de tres escenarios, en los que la topologa es la misma pero vara 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 congestin. GRED: se emplea la versin Gentle-RED como mecanismo de control de congestin, AQM aadido a OPNET.
Ilustracin 70. Topologa CuelloBotella
144
5.2.2 CuelloBotella2
En esta topologa se aumenta la complejidad y la carga de trfico en la red aumentando el nmero de nodos de la red, tanto fuentes emisoras como receptoras. El trfico sigue siendo ntegramente de tipo TCP. Ahora, el nmero de clientes asciende a catorce, al igual que el nmero 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.
Ilustracin 71. Topologa CuelloBotella2
145
5.3 Reglas de ajuste de parmetros de RED

Como se ha dicho anteriormente, uno de los mayores problemas de utilizar el algoritmo RED es configurar sus parmetros, ya que este algoritmo es extremadamente sensible a ellos. De hecho, una mala configuracin de parmetros 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 configuracin de esos parmetros, que si bien no son muy aclaratorias, permiten al usuario tener una base para tantear cual puede ser el rango de valores ms adecuado para cada parmetro en situaciones concretas. A continuacin se exponen ideas obtenidas de dicho documento.
5.3.1 Configuracin de los parmetros en general

No hay reglas estrictas para hallar valores ptimos, stos dependen de varios factores incluyendo no slo la velocidad del enlace o retardo de propagacin, si no tambin las caractersticas del trfico, por ejemplo. Un factor a tener en cuenta en general es cuntos paquetes pueden llegar a la cola durante la duracin de un RTT medio (si hubiera tal cosa). Para situaciones de congestin que duran menos que RTT, el comportamiento ideal sera que la cola tuviera un tamao suficiente para absorver dicha congestin sin descartar paquetes. Si la congestin dura ms que RTT, el comportamiento ideal sera que la cola reflejara sta congestin, avisando a los nodos emisores.
5.3.2 Umbral Mnimo

La configuracin 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 utilizacin alta de su capacidad. Cuanto ms intenso sea el trfico de llegada, mayor debe ser Min_th para conseguir una utilizacin del enlace adecuada. Si ste valor fuera demasiado bajo, el router no soportara rfagas de datos. Adems se debe tener en cuenta tambin la velocidad del link, el retardo de propagacin y el tamao mximo del buffer. Por ejemplo, hay que observar si el retraso en la cola es trivial con respecto al retardo de propagacin a travs del enlace. Eso es seal de que el parmetro est bien configurado. En caso contrario, habra que aumentar el valor de Min_th.
5.3.3 Umbral Mximo
146
Control de Congestin con OPNET En el documento se dice que Max_th debe ser como mnimo dos veces Min_th. Segn otras fuentes, lo ms aconsejable es de hecho asignar Max_th = 3*Min_th.
5.3.4 Exponential Weight Factor (wq)

Se recomienda establecer wq como mnimo a 0.001. La eleccin de este parmetro determina la constante de tiempo de muestreo del parmetro Average Queue Size. Si es demasiado bajo, RED tendr una respuesta demasiado baja a las situaciones de congestin. Por el contrario, si es demasiado alta, puede oscilar demasiado, asemejndose demasiado al tamao real de la cola. En OPNET, no damos el valor de wq directamente, si no otro parmetro, que se usa en la funcin Oms_Qm_Average_Queue_Size_Update para calcular el tamao medio de cola cada vez que llega un paquete al sistema. El propio OPNET nos sugiere por defecto que tal valor sea 9, pero tambin se permiten los valores 1, 5, o un valor que el usuario edite.
5.3.5 Probabilidad Mxima

No se especifica mucho acerca del valor que debe tomar Max_p. Las simulaciones descritas en el artculo establecen max_p a 0.02, pero segn algunos usuarios, es ms aconsejable establecer su valor a 0.1. Esto traducido a la forma de configurar los parmetros en OPNET, equivaldra a establecer el parmetro Mark Probability Denominator a 10, ya que ste parmetro, en la funcin oms_qm_red_packet_drop a dividir a uno, como ya hemos visto en el anterior captulo. As, 1/10=0.1.
5.3.6 Ajuste de parmetros GRED

En general, todo lo dicho para el AQM RED se puede aplicar para la configuracin de los parmetros del algoritmo GRED. GRED y RED obtienen unos resultados similares, pero se puede decir que GRED va a ser un algoritmo ms robusto y se va a comportar mejor que RED en situaciones en las que el ajuste de los parmetros no es tan bueno. Segn el artculo [3] de la bibliografa, hay una fuerte relacin lineal entre los parmetros umbral mnimo, mximo o probabilidad mxima y el tamao medio de cola. Ya que tanto GRED como RED no descartan paquetes hasta que se sobrepasa el umbral mnimo, el valor mnimo del tamao de cola medio estar precisamente determinado por ese umbral. En general, para evitar desbordamiento o desaprovechamiento del buffer, sera adecuado que se estabilizara el tamao medio de cola en torno a un valor apropiado. Para conseguir esto, el umbral mnimo debe estar configurado de forma que se evite el mal aprovechamiento, es decir, que no se comiencen a descartar paquetes cuando la carga de trfico no es muy alta.As mismo, el umbral 147
Captulo 5. Experimentos mximo y la probabilidad de descarte mxima debern 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 mximo es el que tiene mayor impacto sobre el tamao de cola. Sin embargo, en GRED es el umbral mnimo. Esto es porque GRED mejora el problema que tena su antecesor al incrementar a uno la probabilidad de descarte cuando se alcanzaba el umbral mximo.
5.4 Resultados con la topologa CuelloBotella

5.4.1 Especificacin de parmetros para los experimentos
5.4.1.1 Nodo Aplicaciones:
Aplicacin FTP Inter-Request Time (secs) exponential(100) File Size 500000B
5.4.1.2 Nodo Perfiles

Offset No Ajuste de Aplicacin_FTP Duration (secs) Inter-Rep. Time Number of (secs) Repetitions constant(400) constant(50) Ilimitada Ajuste de Perfil_FTP Duration Inter-Rep. Time End of const(50) Simulation Pattern Serial
Operation Mode Simultaneous
stara Time const(0.5)
Number of Reps const(4)
Pattern Concurrent
5.4.1.3 Nodo QoS

Este cuadro, como los anteriores, resume las caractersticas configuradas para todos los escenarios que se simulan. El parmetro Buffer Size se aplica en los todos, pero el resto de parmetros de esta tabla slo se aplicarn a los escenarios de simulacin de los AQM RED y GRED.
148
Control de Congestin con OPNET Experimento E1 E2 E3 E4 Buffer Size (pkts) 100 60 60 60 Max_th (pkts) 15 15 15 15 Min_th (pkts) 5 5 5 5 Mark Prob. Denominator 10 10 40 40 Exp. Weight Factor 9 9 9 12
Los parmetros han sido elegidos en relacin 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 parmetro causa tanto en RED como en GRED.
5.4.1.4 Otros parmetros

Se ha utilizado dos tipos de enlaces en esta topologa. El enlace entre los routers debe ser lento en relacin al resto de enlaces de la red para provocar la situacin de cuello de botella. Para tal funcin el enlace elegido es T1 (1.544Mb/sec), asignndole un retardo de propagacin 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 propagacin de 0.001 segundos. Tanto las fuentes emisoras como las receptoras utilizan el protocolo TCP, configurado a la versin Tahoe, como indica en el documento [5] que utilizan para sus experimentos. La duracin de la simulacin es de 3000 segundos, para dar tiempo a la red a adaptarse al trfico, y se vea su funcionamiento de forma estable. En los siguientes apartados se muestran las grficas con los resultados obtenidos tras la simulacin de la topologa CuelloBotella tras configurarse como se indica en los cuatro experimentos.
149
5.4.2 Grficas
5.4.2.1 Trfico descartado globalmente
DT en azul, RED en verde, GRED en rojo.
Ilustracin 72. E1 y E2. Trfico descartado en la red.
En la primera grfica, que corresponde al experimento con tamao de buffer 100, tal y como se han configurado los parmetros se ve que la lnea roja (GRED) es la que se encuentra por debajo en todo momento, es decir, ese escenario es el que menos descartes produce.
150
Control de Congestin con OPNET En general se puede observar que la tasa de descarte en los cuatro escenarios aumenta conforme avanza el tiempo de simulacin, debido a que el nodo Aplicaciones est configurado para emitir trfico de manera exponencial, y la cola del router se llena rpido. Para el experimento E2, en el que slo cambia el tamao del buffer de 100 a 60 paquetes, se demuestra lo sensible que son RED y GRED a la configuracin de los parmetros, aumentando la tasa de descartes. Es la situacin en la que peor ventaja demuestra GRED. An as, el resto de estadsticas obtenidas para este escenario muestran unos resultados bastante satisfactorios para GRED.
Ilustracin 73. E3, E4. Trfico descartado en la red.
151
Captulo 5. Experimentos El tercer experimento, basado en el segundo, cambia slo 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 mximo, 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 grfica muestra cmo afecta la modificacin del parmetro wq, o lo que es lo mismo, el intervalo de muestreo del tamao 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 estadsticas el resultado no ser tan bueno.
5.4.2.2 Retardo global de la red
Ilustracin 74. E1, E2. Valores medios del retardo en la red.
152
Viendo las grficas, 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 parmetros realizados en los distintos experimentos.
Ilustracin 75.E3, E4. Valores medios del retardo en la red.
RED sin embargo es ms dedependiente de la configuracin de los parmetros. El escenario en el que ms retardo hay es el tercero, E3, porque al efectuar un descarte menos agresivo de paquetes, llega un momento en que se satura y dispara su tasa de descartes, descartando todos los paquetes que llegan al router, lo cual contribuye a aumentar el retardo global. 153
5.4.2.3 Utilizacin del buffer en Router1

Ilustracin 76. E1, E2. Utilizacin del buffer en Router1.
En los cuatro experimentos se observa que para Drop Tail el buffer se llena momentos despus de comenzar la simulacin, manteniedo ese nivel hasta el final de la misma. Para RED y GRED, se consigue mantener en un nivel de utilizacin bastante ms bajo, debido al descarte temprano, disminuyendo el retardo que lo paquetes experimentan. Observar que la cola se mantiene en un tamao cercano a 30 paquetes independientemente del tamao del buffer (100 en E1, 60 en el resto). Por la grfica del escenario E3 (siguiente pgina), vemos que el hecho de disminuir la agresividad en el descarte de paquetes no va a influr mucho en estos resultados, debido a los umbrales mximo y mnimo, mantenindose alrededor de 30 paquetes en todo momento. 154
Ilustracin 77 E3, E4. Utilizacin del buffer en Router1.
El parmetro que s que influye ms en estos resultados es wq, como se ve en el cuarto experimento, E4. Se puede ver que la utilizacin 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 rfagas de trfico), como para GRED sobretodo, que alcanza picos de utilizacin mayores, y experimenta gran inestabilidad en el tamao de cola. La grfica obtenida para el cuarto experimento demuestra que no es bueno disminuir el intervalo de muestreo en situaciones de este tipo, en que el trfico es tan inestable (recordar de estamos ante una distribucin exponencial del trfico), puesto que tanto GRED como RED no van a comportarse como deben.
155
5.4.2.4 Variacin en el retardo o jitter en Router1

DT en azul, RED en verde, GRED en rojo
Ilustracin 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 patrn de comportamiento: primero tiene un pico en la grfica, correspondiente a los primeros instantes de simulacin en los que el buffer est vaco y pasa a estar lleno, punto en el que se mantiene hasta el final de la simulacin, con lo que el valor medio desciende hasta quedarse, en algunos casos, por debajo del de RED y GRED. En otras situaciones de trfico, se podra observar un nivel alto de jitter debido al efecto de sincronizacin global creado por Drop Tail.
156
Ilustracin 79.E3, E4. Jitter en Router1, valores medios.
En el caso de RED y GRED, la variacin en el retardo o jitter conserva un valor ms 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 ms parecidos a Drop Tail en cuanto a la ocupacin del buffer. Adems, haba ms oscilaciones, de ah que aumente el nivel de jitter.
157
5.4.2.5 Retardo en Router1 o Delay

Ilustracin 80. E1, E2. Retardo en Router1, valores medios.
En los cuatro experimentos el escenario en el que ms 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 ocupacin del buffer, que es mucho mayor en el caso de Drop Tail. De hecho, el experimento en el que ms retardo hay es en el primero, es decir, el que tiene un buffer con mayor capacidad, por lo tanto, un paquete tardar ms en ser procesado, porque tiene ms paquetes esperando delante en todo momento.
158
Ilustracin 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 configuracin de los parmetros. Cabe destacar que el experimento en el que ms retardo sufren estos dos escenarios es el cuarto, en el que se vea anteriormente que suba la utilizacin del buffer del router. En esa situacin es en la que ms se nota la mejora de GRED con respecto a RED, y su fiabilidad ante el cambio de la configuracin de parmetros.
159
5.4.2.6 Comparacin entre RED y GRED
Ilustracin 82. E1, E2. Tamao de cola medio con el algoritmo RED (rojo) y GRED (azul).
Aqu se muestra una comparacin entre el parmetro Tamao medio de cola de los dos algoritmos. Es la grfica ms til para comprobar cmo se comportan ambos, sus semejanzas y diferencias. En las cuatro grficas, excepto la correspondiente al cuarto experimento (en el que vara wq), el tamao de cola medio es igual para los dos escenarios al principio, pero luego (cuando se alcanzan valores prximos al umbral mximo) se separan, conservando un valor mayor para GRED que para RED. Esto es por la poltica de descarte de ambos algoritmos, en la cual, como se ha descrito anteriormente, si se llega al umbral mximo, RED descarta los paquetes con probabilidad 1, y GRED lo suaviza aumentando la probabilidad de descarte de manera lineal hasta uno, con lo que es menos probable que se descarten paquetes.
160
Ilustracin 83. E3, E4. Tamao de cola medio con el algoritmo RED y GRED.
Lo que se puede observar tambin es que el tamao medio de cola de GRED oscila ms en los cuatro experimentos, sobre todo en el cuarto, en el que se adapta ms rpidamente al trfico. Otra curiosidad es que en los tres primeros experimentos, el tamao 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 mximo (15). Se necesitaran situaciones de ms trfico para comprobar cmo efectivamente RED controla el tamao medio de cola para que nunca sobrepase el umbral mximo, y sin embargo GRED s que lo sobrepasa, aunque moderadamente. El valor mximo que podra alcanzar el tamao medio de cola para GRED sera dos veces el umbral mximo, punto a partir del cual GRED descarta los paquetes con probabilidad 1.
161
5.4.2.7 Utilizacin del enlace entre Router1 y Router2

Ilustracin 84. E1, E2. Utilizacin del enlace entre los routers.
En los cuatro experimentos se observa que Drop Tail es el que obtiene una utilizacin mxima del enlace entre Router1 y Router2. Es un resultado lgico puesto que con los valores introducidos de trfico 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 tambin satisfactorio, teniendo en cuenta que la utilizacin del enlace es muy alta a pesar de la baja ocupacin del buffer dentro de router1, gracias a la cual se ha conseguido disminuir el retardo de los paquetes en dicho router.
162
Ilustracin 85. E3, E4. Utilizacin 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 tamao de cola medio y por tanto la ocupacin del buffer provoca picos de baja utilizacin, aunque en el resto de ls momentos sea casi igual a la utilizacin obtenida con el escenario Drop Tail. En este experimento se debe resaltar tambin que RED es el escenario que permanece ms estable
163
5.5 Resultados con la topologa CuelloBotella2

5.5.1 Especificacin de parmetros para los experimentos
5.5.1.1 Nodo Aplicaciones:
Aplicacin FTP Inter-Request Time (secs) exponential(100) File Size 500000B
5.5.1.2 Nodo Perfiles

Offset No Ajuste de Aplicacin_FTP Duration (secs) Inter-Rep. Time Number of (secs) Repetitions constant(400) constant(50) Ilimitada Ajuste de Perfil_FTP Duration Inter-Rep. Time End of const(50) Simulation Pattern Serial
Operation Mode Simultaneous
stara Time const(0.5)
Number of Reps const(4)
Pattern Concurrent
5.5.1.3 Nodo QoS

Experimento E5 Buffer Size (pkts) 100 Max_th (pkts) 15 Min_th (pkts) 5 Mark Prob. Denominator 10 Exp. Weight Factor 9
El resto de parmetros est configurado como la topologa 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 continuacin se muestra uno de los experimentos realizados con la topologa CuelloBotella2, en la que, como se ven los parmetros arriba expuestos, slo vara el nmero de nodos de la red. El trfico enviado por cada nodo emisor ser el mismo, lo que provoca que Router1 est ms saturado, y se experimente ms congestin en la red. Concretamente, en las siguientes grficas se muestra la comparacin de trfico registrado a la entrada del router para ambas topologas: 164
Ilustracin 86. Trfico registrado para CuelloBotella y CuelloBotella2
En la primera de las grficas se muestra el trfico obtenido para el escenario Drop Tail en ambas topologas: CuelloBotella corresponde con la lnea azul y CuelloBotella2 con la roja. Como se ve, en ambos casos se supera el tamao del buffer del router (100 paquetes), llegando a alcanzar para la segunda topologa ms del doble del tamao, 220. La segunda grfica corresponde a la misma comparacin 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 topologa se controla que llegue menos trfico al router, manteniendose ste entre los 160 y 180 paquetes. Sin embargo, en la segunda topologa (lnea roja), el trfico se desborda, superando los 260 paquetes. A continuacin vemos como repercute esto en los resultados, y la necesidad de reconfigurar los parmetros RED y GRED. 165
5.5.2 Grficas
5.5.2.1 Trfico descartado globalmente
(GRED en rojo, Drop Tail en azul, RED en verde)
Ilustracin 87. E5, Retardo global para la topologa 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 ms paquetes descarta, seguido de GRED. Drop tail descarta muchos menos paquetes y de manera constante. Esto demuestra que los parmetros RED no estn bien configurados para la situacin de trfico actual.
5.5.2.2 Retardo global en la red
Ilustracin 88. E5, Retardo global en la red, valores medios.
166
Control de Congestin con OPNET Como se ve en la grfica, para el escenario E5, el escenario que ms retardo tiene se GRED, aunque los tres escenarios tienen un retardo similar.
5.5.2.3 Utilizacin del buffer en Router1
Ilustracin 89. E5, Utilizacin del buffer en el Router1.
Debido a la implementacin tanto de GRED como RED, se puede apreciar, como pasaba con la anterior topologa, 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
Ilustracin 90. E5, Retardo en el Router1, valores medios.
167
Captulo 5. Experimentos El retardo en el buffer va asociado a la ocupacin. Como en la grfica anterior, en este caso, hay mucho ms retardo en el escenario Drop Tail que en RED y GRED, porque al estar el buffer ms lleno, los paquetes permanecen ms tiempo en la cola antes de ser procesados.
5.5.2.5 Comparacin entre RED y GRED
Ilustracin 91. Tamao medio de cola de GRED (azul) y RED (rojo)
Como se ha visto en otros experimentos, el tamao de cola medio es ms alto para GRED que para RED, ya que este ltimo descarta paquetes de forma ms agresiva.
5.5.2.6 Utilizacin del enlace entre Router1 y Router2
Ilustracin 92. E5, Utilizacin del enlace
Aunque la utilizacin del buffer sea mucho ms baja para los escenarios GRED y RED, no afecta a la utilizacin del enlace, siendo muy parecida a la obtenida por Drop Tail. 168
Captulo 6: Conclusiones y lneas 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 gestin activa de colas como RED para evitar efectos indeseables derivados de la congestin de redes como son la sincronizacin global, el alto jitter, o la prdida excesiva de paquetes. En el tercer captulo se ha descrito detalladamente aspectos del simulador OPNET tales como el funcionamiento de los modelos de nodos y procesos, o cmo se lleva a cabo la simulacin 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 ms bajo en el simulador, es decir, tanto los modelos de proceso que describen el comportamiento de los componentes del simulador, como las libreras con el cdigo fuente que complementan la funcionalidad que por cualquier motivo no estuviera incluida en los modelos de proceso (por ejemplo, por cuestiones de utilidad o reutilizacin). Mediante este estudio se ha comprendido cmo se modelan en OPNET cuestiones como la calidad de servicio o el control de congestin. Al final, se han presentado los resultados de las simulaciones para distintas situaciones y topologas. Con esos resultados, se ha comprobado que la configuracin de los algoritmos RED y GRED no es intuitiva. Se debe tener en cuenta muchas situaciones como son el trfico de la red, el tipo de trfico, la naturaleza y duracin de las posibles rfagas, los retardos en la red, etc. Se ha visto que en lneas 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 parmetro tamao medio de cola tiende a oscilar, sobre todo ante cambios de configuracin de wq y del umbral mnimo, por lo que se debe tener cuidado al configurarlo. En general, adems 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 comunicacin a nivel profesional. Puede tener mucha utilidad tambin a nivel acadmico, para ilustrar temas relacionados con redes y protocolos, debido a lo intuitivo de su interfaz grfica, si se han descrito los pasos a seguir previamente por medio de un tutorial al estilo a lo que se ha hecho en esta memoria.
169
Captulo 6.Conclusiones y lneas futuras
6.2 Posibles Ampliaciones

A medida que este proyecto ha ido avanzando, se ha pensado en distintas lneas de investigacin que se podran 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 slo configurable para su uso con FIFO. Pendiente queda tambin hacer simulaciones con trfico de distinta ndole, como UDP, y ver cmo se comporta el algoritmo cuando hay flujos de trfico con ms peso que otros (simulacines tipo elefante-ratn). Una vez demostrado que se ha podido modificar el cdigo para aadir la versin de RED, Gentle RED, otra de las ideas que se proponan es modificar la forma en que RED trabaja, dando al usuario la posibilidad de actualizar el tamao 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 modificacin. Otra de las ampliaciones que se proponen es estudiar el algoritmo GRED y compararlo con RED utilizando otras topologas, como pueden ser cuellos de botella ms complejos, con mayor trfico y nmero de fuentes TCP, y tambin mayor nmero de routers, creando cruces de trfico de distintas caractersticas.
170
Bibliografa
A. Publicaciones Cientficas
[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, Anlisis a NivelPaquete de Simuladores de Red Contemporneos. Revista IEEE America Latina. Volumen 4, pginas: 299-307. Junio 2006. [5] S. Floyd, V. Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on networking. VOL I . NO 4, pages: 397-413. August 1993. [6] V. Hnatyshin, G. Gramatges, M. Stiefel. Rowan University, Department of Computer Science, Glassboro, NJ. Practical Considerations for Extending Network Layer Models with OPNET Modeler. The 18th IASTED International Conference on Modelling and Simulation. Montreal, Quebec, Canada. Symposium signal processing and intelligent systems. Year of Publication: 2007 [7] G. Iannaccone, C. Brandauer, T. Ziegler, C. Diot, S. Fdida y M. May, Comparison of tail drop and active queue management performance for bulk-data and web-like internet traffic. Proceedings of the Sixth IEEE Symposium on Computers and Communications, page: 122. July 2001 [8] D. Mitchell, J. Yeung. Implementation of Start-Time Fair Queuing Algorithm in Opnet. Ensc835, School of Engineering Service, Simon Fraser University, April 2002. [9] K. Ramakrishnan, S. Floyd, D. Black. The Addition of Explicit Congestion Notification (ECN) to IP.RFC 3168. Sept. 2001. [10] E. Tsolakou, I. S. Venieris. National Technical University of Athens, Telecommunications Laboratory. Department of Electrical and Computer Engineering. Implementation of Traffic Conditioning and PHB mechanisms in OPNET. International conference on advances in communication and control No8 , GRECE 2002 , pp. 197-207
171
Bibliografa [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. Pginas 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 Congestin 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 Conexin TCP. http://seguridadyredes.nireblog.com/ Seguridad y redes. ltimo acceso: 30/11/09 [6] Protocolo TCP http://www.tesisenxarxa.net/TESIS_UPC/AVAILABLE/TDX-1222106164746//04AMCA04de15.pdf ltimo acceso 27/11/09. [7] Mejores Simuladores de Redes http://www.taringa.net/posts/downloads/1047902/Mejores-Simuladores-de-Redes.html ltimo acceso 18/12/09 [8] OPNET Modeler Documentation Set. Version: 14.5. 2008
172
Glosario
ACK: Acknowledgement, seal emitida por el host receptor como reconocimiento al recibir un segmento de datos de parte del host transmisor. AQM: Active Queue Management, Gestin Activa de Colas Buffer: area de almacenamiento utilizada para manejar datos en trnsito. 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 rfagas de datos. CAR: Committed Access Rate algorithm. Cola: Reserva de paquetes que esperan ser enviados por una interfaz de router. Control de flujo: Tcnica que permite sincronizar el envo de informacin entre dos entidades que producen/procesan informacin a distintas velocidades. Es una ms de las tcnicas para combatir la congestin. Se consigue con ella parar a aquellas fuentes que vierten a la red un trfico excesivo. DiffServ: Differentiated Service, Servicio Diferenciado. Mtodo 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 conexin. IP brinda funciones de direccionamiento, especificacin del tipo de servicio, fragmentacin y reensamblaje, y seguridad. KP: Kernel Procedures. Conjunto de procedimientos proporcionados por OPNET para realizar funciones especficas relacionadas con el tratamiento de datos en el modelado de una red. MSS: Maximum Segment Size. Tamao mximo de segmento para el protocolo TCP.
173
Glosario Paquete: agrupacin lgica de informacin que incluye un encabezado que contiene la informacin de control y (generalmente) los datos de usuario. El trmino 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 congestin en la red, no se necesita QoS. Best Effort es el nivel QoS por defecto. RED: Random Early Detection, algoritmo de gestin activa de colas basado en el seguimiento del tamao medio de cola para asignar una probabilidad de descarte a cada paquete que llega al router. Red: agprupacin de varios nodos como pueden ser ordenadores, impresoras, routers, switches y otros dispositivos que se pueden comunicar entre s a travs de un medio de transmisin. Router: es un dispositivo de interconexin 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. Adems de enrutar, los routers tambin 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 tamao 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 retransmisin. 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 Transicin de estado TCP: Transmission Control Protocol, protocolo para el control de la transmisin. Protocolo de la capa de transporte orientado a conexin que proporciona una transmisin 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 conexin de la capa de transporte. Intercambia datagramas sin acuse de recibo o garanta de entrega y requiere que el procesamiento y retransmisin de errores sea manejado por otros protocolos.
174
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 librera de OPNET modificada. oms_qm.ex.c: fichero externo de datos de OPNET con la versin GRED aadida. 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 aadido en el Symbol map. CuelloBotella.project, CuelloBotella2.project: Topologas utilizadas para los experimentos mostrados en esta memoria.
Para obtener los ficheros del programa OPNET (no incluidos en este CD), entrar en la pgina web www.OPNET.com e informarse sobre las distintas versiones que la empresa ofrece de su aplicacin. Para ms informacin, tambin se puede acudir al apartado 4.1.2 Obtencin de Licencias de este documento.
175
Anexo B. Guia para integrar el algoritmo GRED en OPNET

En este anexo se explica cmo utilizar los ficheros que contiene el CD para conseguir utilizar eficazmente el algoritmo presentado en este proyecto. 1. Obtener las licencias en la pgina web de OPNET e instalar el programa a partir de los tres ficheros que la empresa proporciona.
Tras la instalacin, 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 implementacin de los modelos existentes en OPNET como los ficheros de tipo .ex.c, modelos de proceso (extensin .pr.c), archivos relacionados con la gestin de licencias, y varias cosas ms.
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.
Tambin se pueden abrir los proyectos entrando dentro de las carpetas de las topologas y ejecutando el nico archivo en la carpeta con icono de tipo:
3.
Sobreescribir las libreras existentes por las proporcionadas en el CD en las siguientes carpetas: oms_qm.h: se encuentra en la carpeta OPNET\models\std\include. oms_qm.ex.c: en la carpeta OPNET\models\std\utilities\oms. ip_output_iface.pr.c: sobrescribir en la carpeta OPNET\models\std\ip.
177
Anexo B. Guia para integrar el algoritmo GRED en OPNET RED_parameters2.ad: copiar en la carpeta OPNET\models\std\ip y cargarlo desde el editor de procesos como se ha explicado en el captulo 4, apartado 4.3.4 Modificacin de atributos.
4.
Una vez seguidas estas instrucciones y copiados los ficheros en sus directorios, abrir cualquiera de las topologas. Al seleccionar Edit Attributes debe estar, dentro de: FIFO Profiles Details RED Parameters RED Status la opcin GRED Enabled.
178
Anexo C. Estructuras y variables importantes

En esta seccin se muestran las estructuras ms importantes que intervienen en la implementacin de algoritmos AQM en el simulador OPNET. Se han podido ir viendo en los extractos de cdigo mostrados en el Captulo 4, mientras se explicaban las funciones paso a paso hasta llegar a la implementacin de RED y GRED. El estudio de stas estructuras es esencial a la hora de comprender las funciones citadas anteriormente. Las estructuras estn ordenadas segn el archivo a que pertenecen. Se mostrarn en subapartados. Tener en cuenta que aqu no se muestran todas, ni todos sus argumentos, slo las partes que se han considerado ms relevantes. Dentro de cada estructura se muestran resaltados las variables o estructuras relevantes.
C.1 iq_qos_support.h
Definicin de tipos enumerados para asignar mecanismos QoS como disciplinas de planificacin, 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;
Enumeracin correspondiente a los distintos esquemas de disciplina de cola:
typedef enum { IpC_No_Queuing IpC_FIFO_Queuing IpC_WFQ_Queuing IpC_Priority_Queuing
= = = =
OmsC_Qm_No_Queuing, OmsC_Qm_FIFO_Queuing, OmsC_Qm_WFQ_Queuing, OmsC_Qm_Priority_Queuing,
179

IpC_Max_Queuing_Scheme } IpT_Queuing_Scheme;
Estructura para los distintos tipos de polticas de clasificacin 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 sern importantes a la hora de procesar informacin QoS:
typedef struct { char * profile_name; List * policy_list_ptr; IpT_QoS_Scheme_Type type; }IpT_QoS_Mechanism_Info;
La siguiente estructura guarda informacin que ser usada para almacenar diversa informacin 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;
Definicin de tipos enumerados para perfiles de interfaz:
typedef enum { IpC_QoS_Scheduling_Profile, IpC_QoS_CAR_Profile, IpC_QoS_RED_Profile, IpC_QoS_Class_Map_Profile, }IpT_QoS_Profile_Type;
180
Contiene informacin general sobre la interfaz y variables del tipo OmsT_Qm_Attributes, que como veremos despus, guarda informacin bsica sobre cada cola dentro de una interfaz:
typedef struct { char *iface_name, char *q_profile_name; int buffer_size; double reserved_bandwidth; IpT_QoS_Bandwidth_Type IpT_Queuing_Scheme OmsT_Qm_Attributes * OmsT_Qm_Attributes * }IpT_QoS_Iface_Config; bandwidth_type; queuing_scheme; qm_attr_ptr; llq_qm_attr_ptr;
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 adems variables para manejo de estadsticas relacionadas con el descarte y el envo 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 estadsticas 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 Captulo 4. Tiene referencia a parmetros IP especficos de la cola, entre ellos, acceso a estructuras especficas 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;
*/
Definicin de enumerados para describir tipo de cola. Slo nos ha interesado el FIFO:
181

typedef enum { IpT_Mother_Pool = OMSC_MOTHER_POOL, IpT_Fifo_Pool, IpT_Max_Pool_Type } IpT_Pool_Type;
Estructura para guardar informacin 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 parmetros 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 estadsticas 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 definicin de procedimientos para enrutamiento del protocolo IP. Slo es usado por el modelo de proceso ip_dispatch y por sus hijos. Incluye muchos ficheros de cabecera y define muchas constantes necesarias para clculos posteriores en otras funciones como tamao de cabecera, velocidad del enlace entre interfaces por defecto, flags para niveles de nodos... An as, de este fichero solo nos interesa una estructura, IpT_Rte_Module_Data, pero ser una de las ms importantes, pues es la que aloja los datos de la memoria compartida entre procesos dentro de una jerarqua, y otros datos interesantes relativos a IP, como el tamao de los datagramas, tabla de enrutado, etc. :
typedef struct IpT_Rte_Module_Data {
182

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 estadsticas y otros datos referentes al trfico background */ /* Memoria compartida entre este proceso y sus hijos. Su propsito es proporcionar un mtodo 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 estadsticas de cantidad de paquetes, de tipo Stathandle. Tambien para el registro de hops */ /* Indicacin de presencia/ausencia de protocolos de enrutado en el nodo. int routing_protos; /* Tamao del datagrama despus de la compresin. */ 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 fragmentacin de datagramas.*/ Sbhandle seg_buf_ptr;/* To fragment full datagrams*/ Sbhandle reseg_buf_ptr;/* To fragment fragments*/ Sbhandle rsm_buf_ptr;/* To reassemble fragments*/ } IpT_Rte_Module_Data; */
183
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 Captulo 4 que ste es uno de los ficheros que se han modificado, aadiendo una nueva constante OMSC_GRED a las ya existentes. Los tipos enumerados se utilizarn para asignar valores a algunos de los campos de las estructuras y para tomar decisiones de procesamiento mientras la simulacin. 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 caractersticas de los datos:
typedef enum { OmsC_Qm_Discard_Class = 250, OmsC_Qm_Packet_Size = 550, OmsC_Qm_Queue_Number = 660, OmsC_Qm_Route_Map = 800, } OmsT_Qm_Property_Type;
OmsC_Qm_Dscp = 300, OmsC_Qm_Ip_Precedence = 600, OmsC_Qm_Protocol= 650, OmsC_Qm_Type_of_Service= 900,
Definicin de tipos enumerados con los posibles valores de ToS que se pueden asignar segn la precedencia, el tipo de trfico, disciplina, etc. En este proyecto se ha tenido en cuenta slo el caso Best Effort, puesto que no se aplica ningn mtodo de calidad de servicio salvo AQM:
typedef enum OmsT_Qm_Tos { OmsC_Qm_Tos_Unspecified = -1, OmsC_Qm_Best_Effort = 0, OmsC_Qm_Background = 32, OmsC_Qm_Standard = 64, OmsC_Qm_Excellent_Effort = 96, OmsC_Qm_Streaming_Multimedia } OmsT_Qm_Tos;
= 128,
Definicin 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 funcin Oms_Qm_incoming_Packet_Handler para ver si se debe o no descartar el paquete que llega:
typedef enum { OmsC_Qm_Send_Packet = 0, OmsC_Qm_Dropped_Packet = 1, OmsC_Qm_Queued_Packet = 2, OmsC_Qm_Dequeue_Abort = 3, OmsC_Qm_Dequeue_Packet = 4, OmsC_Qm_Invalid_Signal } OmsT_Qm_Signal;
184
Definicin 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 caractersticas de un paquete necesarias para saber en qu cola se debe almacenar y cmo 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 estn contenidas dentro de una unin que forma la estructura OmsT_Qm_Pkt_Info, que es ampliamente utilizada en varias de las funciones explicadas en el Captulo 4, pues es a partir de la que se va a acceder a toda la informacin de cada paquete.
Las siguientes dos estructuras, implementan lo que sera la jerarqua de colas. Como recordatorio, en OPNET una cola puede contener varias subcolas, y stas a su vez contener ms subcolas, y as, hasta el nivel que el modelador considere oportuno, teniendo todas la misma estructura. Por ello, la primera estructura alberga caractersticas de una subcola simple, con referencia a la cola padre, y la segunda tiene campos que son punteros a arrays de colas. A continuacin se muestran las dos: 185
Estructura de datos concretos para una cola simple o una subcola. Contiene campos de tipo void* que durante la simulacin se asociarn 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 polticas de descarte */ void* qscheme_vars_ptr; /*Variables especficas para disciplinas de cola.*/ OmsT_Qm_Stats queue_stats; /* Acceso a estadsticas asociadas a la cola. */ OmsT_Stat_Data* qdelay_stat_data_ptr; /* Maintain samples for queue delay */ OmsT_Qm_Pkt_Info pkt_info; /* Informacin IP del paquete */ } OmsT_Qm_Queue_Info;
Esta estructura contiene las caractersticas del nivel superior de una jerarqua 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 caractersticas 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; //Informacin de este conjunto de colas OmsT_Qm_Queue_Pool** queue_pool_parray; //Array de subcolas que contiene OmsT_Qm_Attributes* attributes_ptr; OmsT_Buffer_Pool_Handle buffer_pool_handle;//Buffer asociado al conjunto OmsT_Qm_Queuing_Scheme queue_processing_scheme;//Disciplina asociada a las colas /* Variables especficas 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 actualizacin del tamao 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 despus acceder a la estructura OmsT_Qm_IP_Queue_Configuration explicada anteriormente:
struct OmsT_Qm_Attributes {
186

int no_queues; int default_queue; int max_total_no_buf_pkts; void** queue_configuration; }; /* Numero de colas o subcolas */ /* Cola para paquetes por defecto. */ /* Maximo nmero de paquetes almacenados.
*/
/* Parmetros de configuracin de la cola. */
Estructura con algunos de los parmetros RED relativos a la eleccin 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 parmetros relativos a cada clase de descarte dentro de la cola. Nosotros hemos jugado con una clase de descarte nica para toda la simulacin, por lo que slo habr una estructura de ste tipo. Si aplicaramos ms clases de descarte, se rellenara sta estructura para cada una de las clases. Esto se elije mediante el parmetro QoS FIFO Profiles RED Parameters Mark Probability denominator. Si en vez de configurarlo con un solo valor, se configura dndole una cadena de nmeros separados por una coma, cada uno de esos nmeros implicara una clase de descarte.
typedef struct { OmsT_Qm_Tos match_value; int minimum_threshold; /* Umbral int maximum_threshold; /* Umbral int mark_probability_denominator; cuando la probabilidad es } OmsT_Qm_RED_Class_Params;
mnimo configurado en los atributos.*/ mximo del algoritmo RED.*/ /* Fraccin del trfico descartado maxima.*/
La siguiente estructura es una definicin 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 definicin era:
/* Global Table to maintain architecture specific functions */ extern OmsT_Qm_Arch_Void_Func OmsI_Arch_Specific_Func_Table [OmsC_Qm_Max_Arch_Types] [OmsC_Qm_Max_Arch_Func_Types];
typedef enum { OmsC_Qm_Attribute_Get_Func = 0, OmsC_Qm_Enqueue_Test_Func, OmsC_Qm_Drop_Policy_Vars_Create_Func, OmsC_Qm_Drop_Policy_Vars_Update_Func, OmsC_Qm_Drop_Policy_Vars_Delete_Func, OmsC_Qm_Dequeue_Time_Get_Func, OmsC_Qm_Dequeue_Schedule_Func, OmsC_Qm_Dequeue_Test_Func, OmsC_Qm_Service_Time_Get_Func, OmsC_Qm_Get_Pool_Weight_Func, OmsC_Qm_Micro_Sim_Enable_Func, OmsC_Qm_Max_Arch_Func_Types /* should be the last entry */
187
} OmsT_Qm_Arch_Func_Types;
Para un propsito similar se define la siguiente estructura:
typedef enum { OmsC_Qm_Pkt_Deq_Complete = 0, OmsC_Qm_Queue_Select, OmsC_Qm_Qscheme_Vars_Init, OmsC_Qm_Qscheme_Vars_Update_Enq, OmsC_Qm_Max_Qscheme_Func_Types /* should } OmsT_Qm_Qscheme_Func_Types;
OmsC_Qm_Qscheme_Vars_Create, OmsC_Qm_Qscheme_Vars_Update_Deq, OmsC_Qm_Qscheme_Vars_Delete, be the last entry */
Asociada con la tabla global que tambin hemos visto con anterioridad:
/* Global Table to maintain Qscheme specific functions */ extern OmsT_Qm_Qscheme_Void_Func OmsI_Qscheme_Specific_Func_Table [OmsC_Qm_Max_Queuing_Schemes] [OmsC_Qm_Max_Qscheme_Func_Types];
188
Anexo D. Pautas para la modificacin del funcionamiento del algoritmo RED

Se ha pensado en una posible extensin de este proyecto que sera sencilla a partir de lo explicado, pero que no se ha podido llevar a cabo por problemas de tiempo. La modificacin 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 perodo de muestreo. Este nuevo algoritmo, lo podramos llamar CRED. Los cambios a realizar seran del orden de los hechos para extender la aplicacin con el algoritmo GRED. Habra que editar el modelo de proceso ip_output_iface, aadiendo una variable de estado que lleve el control del tiempo y otra que contenga el intervalo de muestreo. En el header block habra que aadir la macro correspondiente a una interrupcin, que consiste en comprobar si se ha agotado el tiempo indicado por la variable de muestreo. En el Function Block, definir una funcin que calcule el tamao medio de cola y la probabilidad de prdida, reutilizando o llamando a las funciones Oms_Qm_Average_Queue_Size_Update y oms_qm_red_drop_packet. El funcionamiento sera de la siguiente forma: 1. Comienza la ejecucin del modelo de proceso ip_output_iface. Inicializacin de un contador de tiempo. La inicializacin de variables se podra realizar en el estado init. En el estado idle, esperar por una de las interrupciones, entre las cuales se aade una que tenga en cuenta el tiempo que ha pasado desde que se ejecut la ltima vez el algoritmo CRED. Una vez agotado el tiempo del temporizador, se lanza una interrupcin que termina en el mismo estado, y que estar aparejada a un transition executive en el que se llama a la funcin que calcula los parmetros de RED y almacena la probabilidad de prdida del paquete en una variable. Ya en el estado idle de nuevo, y con la probabilidad de prdida del paquete calculada, se procede como se ha hecho hasta entonces, llamando a la funcin enqueue_packet, en la que habra que hacer alguna operacin para advertir que el algoritmo utilizado es CRED, y 189
2.
3.
4.
Anexo D. Pautas para la modificacin del algoritmo RED en OPNET que la probabilidad de descarte ya est calculada, para no volver a realizar de nuevo las llamadas que se hacen para el algoritmo RED tradicional. Para poder configurar el algoritmo desde el modelo de procesos, es el mismo procedimiento que se ha seguido para el caso de GRED.
Estos pasos son orientativos, puesto que se ha pensado cmo hacer el algoritmo pero no se ha hecho fsicamente, por lo que puede ser que para que funcione CRED haya que tenerse en cuenta ms cosas que las explicadas. No obstante, se espera que sea una buena base para la continuacin de futuros trabajos.
190
Anexo E. Herramientas utilizadas

D.1 VisualC ++
Compilador de cdigo C y C++ que transforma cdigo fuente en cdigo ejecutable. Necesario para compilar los modelos de proceso utilizados en OPNET antes de la simulacin.
D.2 OPNET Modeler

Modelador y simulador de redes. Es la principal herramienta utilizada en ste proyecto tanto para modelar las topologas como para realizar las simulaciones y estudiar el cdigo fuente de los modelos de proceso.
D.3 Notepad ++
Editor gratuto de cdigo fuente, que soporta varios lenguajes de programacin y se ejecuta en MS Windows. Se distribuye bajo la licencia pblica de GNU. Utilizado en este proyecto para revisar y editar el cdigo fuente de los ficheros de cabecera (extensin .h) y de los ficheros de cdigo externo (extensin .ex.c).
191

Memoria

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Memoria

Hochgeladen von

Copyright:

Verfügbare Formate

Control de Congestin con OPNET

Control de Congestin con OPNET

Alumna: Lourdes Nicols Fernndez Tutora: M Teresa lvarez lvarez

Control de Congestin con OPNET

Por todo ello, muchas gracias a todos, Lourdes.

Control de Congestin con OPNET

2.1 INTRODUCCIN ....................................................................................................................... 23 2.1.1 Situacin de las redes actuales...................................................................................... 23

2.2.3 Elementos que deterioran la QoS percibida por el usuario ........................................... 27

2.5 GESTIN ACTIVA DE COLAS.................................................................................................... 35 5

2.5.1 Introduccin y fundamentos de los AQM ........................................................................35

2.5.2 Random Early Detection (RED)......................................................................................36

INTRODUCCIN TERICA AL SIMULADOR OPNET .......................41

3.4.2 Componentes de un modelo de proceso ..........................................................................56

Control de Congestin con OPNET

IMPLEMENTACIN DEL ALGORITMO RED EN OPNET................ 73

4.2.6 Simulacin de los escenarios.......................................................................................... 89

4.3.4 Modificacin de atributos............................................................................................. 100

4.5.2 Modificacin del modelo de procesos ip_output_iface ................................................ 141 7

5.2.2 CuelloBotella2 ..............................................................................................................145

Control de Congestin con OPNET

Control de Congestin con OPNET

1.1.1 Simuladores de red

Control de Congestin con OPNET

1.1.2 Simulador OPNET Modeler

Ilustracin 1. Vista de la seccin de clientes de la pgina de OPNET

Control de Congestin con OPNET

1.2 Objetivo del proyecto

1.3 Recopilacin de informacin

1.4 Estructura de la memoria

Control de Congestin con OPNET

Captulo 2. Conceptos Tericos

2.1.1 Situacin de las redes actuales

Captulo 2. Conceptos Tericos

Ilustracin 3. Ejemplo de un caso de congestin.

Control de Congestin con OPNET

2.2 Calidad de Servicio

2.2.2 Mecanismos de QoS

2.2.2.2 Servicios Integrados (IntServ)

Captulo 2. Conceptos Tericos

2.2.2.3 Servicios Diferenciados (DiffServ)

2.2.3 Elementos que deterioran la QoS percibida por el usuario

2.2.3.2 Prdida de paquetes y corrupcin de datos

Captulo 2. Conceptos Tericos

2.3 Protocolos Extremo a Extremo

Ilustracin 4. Estructura de un segmento TCP

2.3.2 Control de congestin en TCP

2.3.2.1 Arranque lento y prevencin de la congestin

Captulo 2. Conceptos Tericos

Ilustracin 5. Ventana de congestin y cola en TCP

2.3.2.2 Retransmisin Rpida y Recuperacin Rpida

2.3.2.3 Versiones de TCP

Captulo 2. Conceptos Tericos

2.4 QoS dentro de los Routers

2.4.2 Gestin de colas

Control de Congestin con OPNET

2.4.3 Planificacin de colas

2.4.3.1 FIFO (First In First Out)

Ilustracin 6. Planificacin de Colas FIFO

2.4.3.2 Colas de prioridad ( PQ, Priority Queueing)

Captulo 2. Conceptos Tericos

2.4.3.3 FQ (Fair Queueing)

2.4.3.4 WFQ (Weighted Fair Queueing)

Control de Congestin con OPNET

2.5 Gestin Activa de Colas