PRACTICA 3 (ENUNCIADO)

3. Práctica de simulación del estándar IEEE 802.5 mediante OMNet++ 3.1. Introducción El estudio de las redes de comunicación requiere hacer el ejercicio de simplificar y abstraer los conceptos involucrados utilizando para ello un conjunto de hipótesis simplificadoras que permiten “intuir” cómo funciona ésta. Empezamos aquí a tratar algunos matices algo más detallados sobre el tipo de problemas prácticos al que nos vamos a enfrentar. Complementa esta práctica las dos anteriores: su resolución (e interpretación) requería, como se ha visto, utilizar un conjunto de hipótesis simplificadoras. Sin embargo, al estudiar redes mas próximas a la realidad, como la ilustrada en la Fig. 1 algunas de las hipótesis dejan de ser ciertas. Se hace entonces necesario recurrir a herramientas de simulación. A ello dedicaremos esta práctica. PRÁCTICA 3
Fig. 1. Representación conceptual de una red de comunicación genérica. 3.2. Objetivos docentes y revisión de conceptos clave Se pretende que el alumno aprehenda, con claridad: •
•
•
•
cómo funciona un caso ilustrativo y convenientemente simplificado de una red de comunicación, qué propiedades se pueda modelar y evaluar “con lápiz y papel” y cuáles no, explorar cómo se comporta una red de comunicación cuando se modifican ciertos parámetros que configuran su funcionamiento y que extraiga de ello conclusiones propias que pueda debatir de forma crítica. En concreto, el tipo de red cuyo comportamiento se pretende simular es una red local formada por un número reducido (5, en primera aproximación) de estaciones finales (terminales, equipos de datos, ordenadores o “hosts”) que están conectadas formando un anillo como el ilustrado en la Fig. 2. Obsérvese que, como comparten el medio de transmisión, se hace necesario implementar algún protocolo de acceso al medio (MAC = Medium Access Protocol) [1]. El esquema de acceso que se utilizará en estas prácticas está basado en un protocolo libre de colisión (planificado) y, en particular, en uno basado en consulta. En el caso en el cual el alumno desee obtener una información más detallada sobre éstos, se sugieren como referencias apropiadas [1] y [2]. En concreto, por cuestiones de orden docente e índole práctico, se utilizará un esquema basado en una versión convenientemente simplificada del estándar “Token Ring” que se implementa en las muestras de prueba que ofrece el simulador de eventos discretos conocido como OMNet++ [3], 2 PRÁCTICA DE SIMULACIÓN DEL ESTÁNDAR IEEE 802.5 MEDIANTE OMNET++
[4], cuya distribución y utilización es libre para fines docentes. No obstante, y para facilitar la realización de la práctica, resumimos aquí el concepto básico que el alumno debe tener en mente: los sistemas basados en consulta (o sondeo) suelen implementarse a través de la utilización de una trama especial llamada frecuentemente “testigo” (o token). Este testigo circula por el medio de transmisión compartido por las estaciones de manera que, para que una estación pueda transmitir, debe antes capturar dicho testigo [1]. Para ayudarle en los propósitos mencionados previamente se proponen un conjunto de hipótesis simplificadoras (como las de la Práctica 2), a saber: •
•
•
•
Topología “en anillo” como la indicada en la Fig. 2 . Obsérvese que exhibe las siguientes propiedades interesantes: o Está formada por N estaciones finales (o “hosts”). Todas ellas forman parte del anillo lógico desde el principio. Esto significa que, en algún instante de tiempo, alguna de las N estaciones puede estar dispuesta a transmitir. o Las N estaciones están equiespaciadas o La longitud total del anillo es L ANILLO El tiempo que cada estación tarda en generar el testigo (= token) se considera despreciable en comparación con los otros tiempos que aparecen involucrados. Se considera que todas las tramas tienen igual tamaño. Se llama “tiempo de posesión del testigo” (THT = Token Holding Time) al tiempo durante el cual la estación que lo ha capturado puede transmitir datos. El modelo simplificado es tal que, sólo se permite la transmisión de una única trama de datos y, después de transmitir ésta, se procede a “pasar” el testigo. 3 PRÁCTICA 3
Fig. 2. Ilustración de la topología que exhibe la red en estudio. El número de estaciones o hosts en la red es N=5. Gracias a estas hipótesis simplificadoras es posible enfrentarse a una serie de razonamientos que ayudan a clarificar bajo qué circunstancias de trabajo la red funciona de forma más eficiente. Para ello nos proponemos contestar a dos interrogantes, a saber: 1)¿Qué sucede cuando la red se enfrenta a la situación límite en la que sólo una (1) de las estaciones pretende transmitir? Y 2)¿Cuál es su eficiencia en la situación límite contraria en la cual todos los host intentan transmitir de forma simultánea? Gracias a la Práctica 2 podemos contestar a estas preguntas. Sin embargo, ¿qué pasa cuando, por ejemplo, las tramas tienen distintas longitudes?... 3.3. ¿Qué podemos simular? Una vez que el alumno se ha familiarizado con los conceptos esenciales se encuentra en condiciones de dar un paso más y explorar un modelo algo “más realista” de una red inspirada en una versión simplificada del estándar Token Ring (IEEE 802.5). Los objetivos que se persiguen son, básicamente: •
•
4 simular el comportamiento de la red bajo ciertas condiciones menos restrictivas, que se irán desgranando a continuación, comprender qué sucede y PRÁCTICA DE SIMULACIÓN DEL ESTÁNDAR IEEE 802.5 MEDIANTE OMNET++
•
extraer las debidas conclusiones. La herramienta de simulación disponible en el laboratorio permite estudiar redes más complejas (en general, cualquier sistema de eventos discretos) y, en consecuencia, permite suprimir algunas de las hipótesis simplificadoras esbozadas (que, por otra parte, suelen aparecer con cierta profusión en los libros especializados) que servían para aprender “con lápiz y papel”. Sin embargo, tales hipótesis nada permiten intuir cuando, por ejemplo, el tamaño de las tramas de datos de cada estación exhiben, como cabe esperar en la realidad, tamaños distintos y aleatorios. En concreto, algunas de las situaciones más realistas que podremos abordar a lo largo de las simulaciones de este módulo son, entre otras, las siguientes: •
•
•
el trafico con que cada estación carga la red se modelará de forma probabilística más compleja, el tiempo de posesión del testigo (THT = Token Holding Time) se considerara un parámetro característico de cada simulación, y las tramas de datos podrán tener, eventual y aleatoriamente, diferentes tamaños. 3.4. Descripción del programa que simula la red bajo estudio El objetivo que se persigue en la presente práctica consiste en que el alumno se familiarice con: •
•
•
el entorno de simulación, el programa que modela la red esbozada y el conjunto reducido de parámetros que configuran el funcionamiento de ésta. La estrategia a la hora de aproximarnos al modelado y simulación de estas redes consiste en hacer uso de la biblioteca de recursos implementada por el grupo de universidades que trabajan con el software de libre distribución (para fines docentes) OMNet++ [3]. En el modelo simplificado, que utiliza los recursos de esa biblioteca, cada uno de las estaciones (host u ordenadores de la red) se implementan utilizando tres módulos que describen respectivamente, el protocolo en sí mismo, la fuente y el drenador que, respectivamente, generan y consumen el trafico ofrecido a la red. Los conceptos esenciales de OMNet tales como 5 PRÁCTICA 3
“módulo simple”, “módulo compuesto”, o “mensaje” , por citar algunos, son conocidos por el alumno, aunque el lector interesado podrá, no obstante, encontrar una descripción más profunda en la referencia [3]. Por ejemplo, resulta ilustrativo echar un vistazo al módulo simple que implementa la generación de las tramas de datos: // Generador de tramas de datos
// Nombre: gen.ned
//
simple Generator
parameters:
// Número de estaciones o hosts de la red
// Se numeran empezando por 0
numStations : numeric const,
// Dirección MAC de esta estación o host
address : numeric const,
// Número de mensajes a generar
numMessages : numeric const,
// Longitud del mensaje en bytes (podría ser una variable aleatoria)
messageLength : numeric,
// Tiempo entre 2 mensajes consecutivos (puede ser una variable aleatoria)
interArrivalTime: numeric;
gates:
out: out;
endsimple
//
La razón de su interés radica en que empieza a presentar al lector ciertos parámetros (por ejemplo, el intervalo de tiempo que transcurre entre la aparición de dos tramas consecutivas) en cuya influencia (sobre el comportamiento de la red) nosotros estaremos particularmente. Finalmente, y por su mayor interés práctico que el anterior, resulta conveniente destacar el módulo que implementa el protocolo de acceso al medio: // // Implementación del protocolo simplificado Token Ring // simple TokenRingMAC parameters: // Velocidad o tasa binaria en bps dataRate : numeric const, // Tiempo de posesión del testigo -­‐Token Holding Time (THT) 6 PRÁCTICA DE SIMULACIÓN DEL ESTÁNDAR IEEE 802.5 MEDIANTE OMNET++
THT : numeric const, // Dirección de la estación address : numeric const, // Tamaño máximo de la cola de espera queueMaxLen : numeric const; gates: in: phy_in; in: from_hl; out: phy_out; out: to_hl; endsimple Nótese que, desde el punto de vista de estudiar aspectos más relevantes del funcionamiento de la red, los parámetros de diseño más importantes, resaltados con un tamaño de letra mayor, resultan ser: •
•
THT (Token Holding Time): El tiempo de posesión de testigo modela el tiempo durante el cual la estación que lo ha capturado puede transmitir datos. En el modelo simplificado que se aborda sólo se permite la transmisión de una única trama de datos y, después de transmitir ésta, se procede a “pasar” el testigo. queueMaxLen: El número máximo de paquetes que caben en la cola de espera de cada host de la red. El módulo que implementa el comportamiento del protocolo utiliza una cola de tamaño finito para ir almacenando las tramas de datos hasta que se pueden procesar de la forma adecuada. Cuando el buffer de la cola supera el máximo tamaño, las nuevas trama empiezan a no poder almacenarse y se pierden (“se tiran”). El comportamiento concreto de cada módulo simple se programa en C++. Tal programación no es objeto de esta práctica. 3.5. Descripción de la “Práctica de simulación” Una vez que tenemos en mente una visión del programa que se va a utilizar para simular podemos hacer énfasis en algunos aspectos de mayor interés práctico. Uno de ellos es el archivo de configuración, cuya extensión es .ini, y que sí que merece algunos comentarios. La razón hay que buscarla en 7 PRÁCTICA 3
que permite al usuario introducir nuevos valores de los parámetros importantes y, posteriormente, simular el comportamiento de la red. El archivo de configuración exhibe una estructura muy sencilla: [General] preload-­‐ned-­‐files=*.ned network = token total-­‐stack-­‐kb=4096 ; 4 Mbyte sim-­‐time-­‐limit = 1800s # cpu-­‐time-­‐limit= 300s [Cmdenv] runs-­‐to-­‐execute = 1 express-­‐mode = yes # for non-­‐express mode: module-­‐messages = yes event-­‐banners = yes # for express mode: status-­‐frequency = 50000 performance-­‐display = no [Tkenv] #default-­‐run=1 extra-­‐stack=20000 ;20K [Parameters] token.comp[*].gen.numMessages = 1000000 token.comp[*].gen.messageLength = uniform(1,4500) token.comp[*].mac.queueMaxLen = 20 [Run 1] description="Red de referencia" token.THT=0.2s token.comp[*].gen.interArrivalTime = truncnormal(0.025, 0.006) output-­‐vector-­‐file = simul1.vec El objetivo general de la presente práctica consistirá en, una vez comprendido todo lo expuesto en los párrafos anteriores, estudiar la influencia sobre el comportamiento de la red de diferentes valores que pudieran tomar los parámetros ( y cuyo cuantía podremos introducir en el mencionado archivo .ini). 8 PRÁCTICA DE SIMULACIÓN DEL ESTÁNDAR IEEE 802.5 MEDIANTE OMNET++
3.6. ¿Qué se pide? 1. Cambie de nombre la carpeta de trabajo que usted ha bajado de la red (Sim1RCII). Para mantener el orden en los ordenadores, se aconseja que le añada su nombre, por ejemplo: Sim1RCIINombre. No utilice espacios en blanco. A continuación copie dicha carpeta de trabajo en C:\OMNeT++\samples. Cuando termine la práctica, no olvide llevarse su carpeta de trabajo. Ello le permitirá continuar el próxima día… 2. Simule una red, que llamaremos “Red 1”, con: • N = 5 estaciones • El tiempo de posesión de testigo es 200 ms • La variable aleatoria que modela el tiempo entre dos llegadas consecutivas es una variable aleatoria normal o gasussiana de media 0,025 s y desviación estándar 0,006 s. • La longitud máxima de la cola que el buffer es capaz de almacenar es 10 paquetes de datos • El tiempo de simulación es 2 s Para ello modifique el archivo de configuración (omnetpp) de forma adecuada y, a continuación, ejecute el programa simul1.exe. Nótese que los resultados de la simulación se guardan, por defecto, en el archivos simul1.vec. Esto se ha especificado en la última línea del archivo de configuración. Represente, en función del tiempo de simulación (en segundos), las siguientes magnitudes (cada magnitud en una gráfica distinta): •
•
•
•
Longitud (en bytes) de la cola de espera en cada estación Número de paquetes en la cola de cada ordenador Tiempo de espera en cola (s) Retardo (en segundos) Sugerimos que se guarde cada una de las figuras en una carpeta de Resultados y con formato .gif para que luego se pueda insertar con comodidad en la memoria que habrá de confeccionarse. Si tiene problemas con las gráficas le sugerimos que lea los anexos 1 y 2. 3. Simule ahora otra red, que llamaremos “Red 2”, con: • N = 10 estaciones 9 PRÁCTICA 3
•
•
•
•
El tiempo de posesión de testigo sea 200 ms La variable aleatoria que modela el tiempo entre dos llegadas consecutivas es una variable aleatoria normal o gasussiana de media 0,025 s y desviación estándar 0,006 s. La longitud máxima de la cola que el buffer es capaz de almacenar es 10 paquetes de datos El tiempo de simulación es 4 s. Represente, en función del tiempo de simulación (en segundos), las siguientes magnitudes: • Longitud (en bytes) de la cola de espera en cada estación • Número de paquetes en la cola de cada ordenador • Tiempo de espera en cola (s) • Retardo (en segundos) • Número de paquetes perdidos por cada ordenador 4. Elabore una memoria recopilando las figuras de los apartados anteriores y, a la vista de ellas, compare en qué difiere el funcionamiento de ambas redes. Como sugerencia para efectuar tal análisis, le sugerimos reflexionar, entre otros, sobre los siguientes aspectos: • el número de bytes en cola en una y otra red • el número de paquetes en cola • el tiempo de espera • ¿Qué le sugiere la gráfica correspondiente al número de paquetes perdidos? 3.7. Anexos Anexo 1. Sugerencia sobre la presentación de las gráficas •
10 El número de paquetes en cola que hay en cada estación. Etiquete el eje de la variable independiente como “Tiempo de simulación (s)” . El eje de ordenadas debe etiquetarse como “Número de paquetes en cola”. No olvide escribir un pie de figura que sea suficientemente descriptivo. La Fig. 3 sirve como ejemplo ilustrativo de la forma en que se deben presentar los resultados. Si no sabe cómo obtener las gráficas, el Anexo 0 le ayudará en ello. PRÁCTICA DE SIMULACIÓN DEL ESTÁNDAR IEEE 802.5 MEDIANTE OMNET++
•
•
El tiempo de espera en cola en cada estación. Etiquete el eje de la variable independiente como “Tiempo de simulación (s)”. El eje de ordenadas debe llamarse “Tiempo de espera en cola (s)”. De nuevo, no olvide escribir un pie de figura que sea suficientemente descriptivo. Y así sucesivamente… Fig. 3. Numero de paquetes en la cola de cada ordenador de la red en función del tiempo de simulación en segundos. Las gráficas de color azul (cuadrado), rojo (circulo), verde claro (rombo), naranja (+) y verde oscuro (x) corresponden, respectivamente, a los hosts etiquetados como “1”, “2”, “3”, “4” y “5”. 11 PRÁCTICA 3
Anexo 2: ¿Cómo obtener gráficas? Haciendo doble clic sobre simul1.vec se puede obtener la pantalla representada en la Fig. 4. En este punto, ahora hay que seleccionar, de la columna izquierda de la Fig. 4, etiquetada como Vector Store, aquellos parámetros que queremos representar. Por ejemplo, el retardo (“End-­‐to-­‐End Delay”). Una vez seleccionado, se pulsa la flecha que indica hacia la derecha y los pasamos a la columna Ready-­to-­plot Vectors. A continuación, se selecciona, en el menú de la barra superior, la opción Plot. Se sugiere guardar cada gráfica en formato .gif Fig. 4. Captura de la pantalla generada por el simulador para la representación gráfica de los valores adoptados por diferentes parámetros y magnitudes en la simulación llevada a cabo. La columna de la izquierda, etiquetada como Vector Store, es una lista de todos los resultados obtenidos disponibles y que, potencialmente se pueden representar para ilustrar su evolución durante el intervalo de simulación. La columna de la derecha (Ready-­‐to-­‐Plot vectors) se utilizará para indicar qué magnitudes en concreto estamos interesados en representar. Estas se pueden pasar (y quitar) a dicha columna utilizando las flechas correspondientes que aparecen entre ambas columnas. 12 PRÁCTICA DE SIMULACIÓN DEL ESTÁNDAR IEEE 802.5 MEDIANTE OMNET++
3.8. Referencias [1] W. STALLINGS, Comunicaciones y redes de computadores, Pearson-­‐Prentice Hall, Madrid, 2004, ISBN: 84-­‐205-­‐4110-­‐9. [2] A. LEÓN-­‐GARCÍA E I. WIDJAJA, Redes de comunicación. Conceptos fundamentales y arquitecturas básicas, McGraw-­‐Hill, 2001, ISBN: 84-­‐481-­‐
3197-­‐5. [3] OMNET++ COMMUNITY SITE, http://omnetpp.org/index.php [4] OMNet++ 3.2 User Manual, disponible en la página web siguiente: http://omnetpp.org/doc/manual/usman.html. [5] A.D. TANENBAUM, Computers Networks, Prentice-­‐Hall, 2003. 13