PRÁCTICA DE COMUNICACIONES

INALAMBRICAS - DITG

ESCUELA POLITÉCNICA DEL EJÉRCITO

DEPARTAMENTO DE ELÉCTRICA Y ELECTRÓNICA

ÁREA TELECOMUNICACIONES

LORENA PAZMIÑO
JUAN CARLOS VILLACÍS
MARCELO MOREANO

ING. ROMÁN LARA C.

SANGOLQUÍ - ECUADOR

2010

i
Índice
1. Abstracto: 1

2. Introducción: 1

3. Materiales: 1

4. Desarrollo: 2
4.1. Instalación de Repositorios y Software: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.2. Inyección de Tráfico Unidireccional: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.2.1. Análisis de Gráficas: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.3. Inyección de Tráfico Bidireccional: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.3.1. Análisis de Gráficas: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.4. Inyección de Tráfico Multiflujo: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4.1. Análisis de Gráficas: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5. Conclusiones: 7

6. Recomendaciones: 7

7. Referencias: 8

8. Anexos: 9

ii
 Inyección De Tráfico con DITG

1. Abstracto:

En la presente práctica se pretende simular la inyección de tráfico utilizando el simulador DITG, el cual nos va
a facilitar el envı́o de paquetes de modo unidireccional, bidireccional y multiflujo; para lo cual se debera realizar
las configuraciones necesarias en lo que respecta a las opciones: Definición de flujo, Propiedades, Analizador,
Multiflujo.
El inyector de tráfico DITG que se utilizará en el presente laboratorio, se implementará sobre el sistema
operativo UBUNTU, por lo que se necesita su previa instalación, y se recomienda montar el sistema dentro de
una partición del disco debido a ciertas limitaciones que presenta en máquina virtual. Cabe recalcar que para
que los equipos se puedan comunicar entre sı́ debemos configurar las conexiones de red, asignando direcciones
IP para que se encuentren dentro de la misma red.

2. Introducción:

La calidad de servicio denominado como QoS, es un parámetro muy importante para el análisis de una red,
de esto dependerá su buen funcionamiento y desempeño dentro del sistema a trabajar, es por eso que se han
creado diversas herramientas que permiten simular comunicaciones en tiempo real.
Al utilizar herramientas de inyección de tráfico se permite generar el mismo basados en patrones lo más cercanos
a la realidad, y mediante el mismo se traza tanto en emisión como en recepción el movimiento de cada paquete
transmitido, de manera que se pueda representar gráficamente los diferentes parámetros de calidad.

DITG es particularmente interesante por varias razones: dispone de una interfaz gráfica que puede simpli-
ficar su uso, dispone de un ”manager” que permite enviar ordenes a fuentes y sumideros de tráfico remotos,
ası́ como de un servidor de logs que se puede ubicar en cualquier máquina que convenga (coincida o no con
las fuentes o sumideros de tráfico), permite caracterizar estadı́sticamente el tráfico inyectado, y mide todos los
parámetros de QoS como: throughput, retardo, jitter y probabilidad de pérdida de paquetes, además dispone
de una interfaz gráfica que facilita su uso, dispone de un ”manager” que permite enviar ordenes a fuentes y
sumideros de tráfico remotos, ası́ como de un servidor de logs que se puede ubicar en cualquier máquina que
convenga (coincida o no con las fuentes o sumideros de tráfico), permite caracterizar estadı́sticamente el tráfico
inyectado, y mide todos los parámetros de QoS citados.

a.Jitter.- Es la medida de variación de delay entre paquetes consecutivos en un determinado flujo de tráfico.
A medida que varı́a la tasa de delay, el jitter impacta sobre el rendimiento de la aplicación. Una cantidad mı́nima
de jitter puede ser aceptable.
b.Packetloss.- Indica los paquetes fallados para llegar a su destino que viajan dentro de una comunicación.
Para una transmisión óptima los paquetes perdidos no debe ser más del 1 % y para una prioridad mı́nima entre
5 % y 10 % de paquetes perdidos.
a.Delay.- Es aquel que especı́fica cuan largo se le hace para un bit de datos viajar dentro de la red de un nodo
a otro.
b.Bitrate.- Es el número de bits que son transportados, se lo calcula en bits por segundo (bps).[1][2]

3. Materiales:

2 Computadoras con sistema operativo Linux, distribución Ubuntu 9.04 o 9.10.

Cable cruzado de 1m.

Conexión a internet.

1
4. Desarrollo:

4.1. Instalación de Repositorios y Software:

Se debe descargar el inyector; DITG para el correcto funcionamiento del software previamente mencionado
se deberá instalar los siguientes repositorios: Sun-java6-jre, g++, octave3.0. Los que serán descargados con la
ayuda del gestor de paquetes synaptic.
Posteriormente se descargó los paquetes D-ITG-2.7.0-Beta y itggui-0911 desde:

http://www.grid.unina.it/software/ITG/

http://www.semken.com/projekte/index.html

Dentro de root creamos una carpeta con el nombre DITG, en el que descomprimimos el contenido de los
paquetes. En el terminal y digitamos las siguientes lı́neas de comando:

cd /root/DITG/src

make

Una vez realizado esto copiamos todos los archivos membretados ITG y lib que se encuentraron en el directorio
/home/monica/DITG/bin al directorio usr/local/bin y usr/local/lib respectivamente. En el siguiente análisis
de inyección de tráfico vamos a poder medir el rendimiento de la red, de acuerdo a su comportamiento. Cabe
recalcar que cuando a traves del terminal intentamos graficar los datos obtenidos no se logró puesto que ITGplot
no tenı́a todos los permisos; por lo que se procedió a: en el terminal # chmod 777 ITGplot para obtener los
permisos.

4.2. Inyección de Tráfico Unidireccional:

Transmisor:

Define Flow, Settings, Analizer

Para esta configuración deberemos seguir los pasos indicados en la guı́a de laboratorio, definiendo parámetros
como:

Direcciones tanto de logs como de bin

Duración de envı́o de paquetes: 30(0.5minutes)

Selección de archivos de texto, gráficos y los generados por octave.

Target Host: Aputamos a la dirección IP de la maquina receptora, entre otros parámetros para su posterior
análisis.

Receptor:

Settings y Analizer
Como en el caso anterior se mantendrá la configuración indicada en la guı́a.
Se debe tomar en cuenta que la máquina receptora deberá iniciar la transmisión presionando loger y receiver,
posteriormente la máquina transmisora deberá presionar sender para su comunicación.

2
4.2.1. Análisis de Gráficas:
El análisis del tráfico unidireccional está basado en la comunicación entre una estación transmisora con un
solo tráfico dirigido hacia la estación receptora.

Fig1: Gráfica Bitrate Unidireccional Fig2: Gráfica Delay Unidireccional

Bitrate.-La gráfica nos muestra la transmisión de bits por segundo que se obtuvo, es decir la velocidad de
transferencia de datos, dado que la inyección de tráfico es Unidireccional, este posee una elevada velocidad de
transferencia y ciertamente constante en el tiempo si obtenemos la media de la misma.
Delay.-Podemos ver que este es un tipo de delay fijo por transmisión de datos (queuing delay) sobre medios de
red fı́sicos en cada salto de la red.[2], presenta un comportamiento constante y relativamente alto puesto que
DITG al iniciar el envı́o no sincroniza los relojes y en las PCs que trabajamos las horas diferı́an considerablemente
por lo que se presenta este tipo de retardo.

Fig3: Gráfica Jitter Unidireccional Fig4: Gráfica Packetloss Unidireccional

Jitter.-El jitter genera un efecto importante sobre aplicaciones sensibles al delay que deben recibir paquetes en
una tasa relativamente contante con un delay fijo. Podemos ver que el jitter tiene cantidad y variación mı́nima
lo que es bueno ya que a medida que este incrementa, la aplicación puede terminar siendo inútil.
Packetloss.-Se observa que el valor fluctúa en 0 lo que muestra que es una comunicación de alta calidad ya que
está dentro del 1 % de paquetes perdidos.

4.3. Inyección de Tráfico Bidireccional:

Para este análisis de tráfico debemos tomar en cuenta que los equipos se deben configurar como emisores
y receptores a la vez, si bien es cierto esta configuración no es posible mediante la interfaz grafica del la
herramienta DITG, por lo que es necesario realizar esta configuración mediante el terminal de Ubuntu en el
cual pondremos en modo receptor a cada PC mediante los comandos ./ITGRecv y ./ITGLog para el caso del
receptor y ./ITGSend para transmisor.

3
 Fig5: Gráfica ITGRecv en terminal Fig6: Gráfica ITGLog en terminal

4.3.1. Análisis de Gráficas:

Cabe recalcar que una vez configurados los relojes de las PCs existe un retardo considerable ya que el concepto
que se utiliza para el trafico bidireccional en DITG no es simultaneo en las dos PCs sino que deben negociar
para decidir quien envı́a y quien recibe primero.

En las siguientes gráficas podemos ver los siguientes comportamientos:

Bitrate.-Vemos que la velocidad de transmisión de ambas PCs es constante mientras que la de recepción es
variante y disminuye respecto a la tasa de bits transmitidos.
Delay.-Vemos claramente que este parámetro sólo se distingue en el receptor tanto de la PC1 como PC2; en la
transmisión su valor es prácticamente nulo. Ası́ como que su valor es variante del tipo Delay de ingreso para el
tráfico en un nodo de la red; pero dado que su valor es relativamente bajo la QoS no se ve comprometida.
Jitter.-Al igual que el delay éste existe únicamente en el lado receptor, y su fluctuación depende de la variación
del delay pero dado que su valor medio es bajo la QoS no se ve comprometida.
Packetloss.-Podemos ver que en todos los casos su valor es constante al rededor de 0, es decir mantiene QoS
ya que está dentro del 1 % de paquetes perdidos.

Receptor PC1

Fig7: Gráfica Bitrate Receptor PC1 Fig8: Gráfica Delay Receptor PC1

Fig9: Gráfica Jitter Receptor PC1 Fig10: Gráfica Packetloss Receptor PC1

4
Transmisor PC1

Fig11: Gráfica Bitrate Transmisor PC1 Fig12: Gráfica Delay Transmisor PC1

Fig13: Gráfica Jitter Transmisor PC1 Fig14: Gráfica Packetloss Transmisor PC1
Receptor PC2

Fig15: Gráfica Bitrate Receptor PC2 Fig16: Gráfica Delay Receptor PC2

Fig17: Gráfica Jitter Receptor PC2 Fig18: Gráfica Packetloss Receptor PC2
Transmisor PC2

5
 Fig19: Gráfica Bitrate Transmisor PC2 Fig1:20 Gráfica Delay Transmisor PC2

Fig21: Gráfica Jitter Transmisor PC2 Fig22: Gráfica Packetloss Transmisor PC2

4.4. Inyección de Tráfico Multiflujo:

El análisis del tráfico mutiflujo está basado en la comunicación entre una estación transmisora con varios
tipos de tráficos dirigidos hacia la estación receptora, con lo cual mediante el analisis de graficos observaremos
los distintos tipos de paquetes enviados, dentro de la herramienta DITG debemos configurarla modificando la
pestaña de multiflow el f1 y f2 como se muestra en las imagenes:

Fig23: Gráfica Pestaña Multiflujo

Fig24: Gráfica Configuración F1 (Voz) Fig25: Gráfica Configuración F2 (DNS)

4.4.1. Análisis de Gráficas:

Bitrate.-Podemos ver que la tasa de bits es constante aunque su velocidad de transmisión a disminuido
respecto a los otros tipos de inyección de tráfico.
Delay.-En este caso se obtuvo un delay negativo ya que no habı́a una correcta sincronización con los relojes de
las PCs, pero visiblemente se mantiene constante lo que nos ayuda a mantener la QoS y evitar la pérdida de
paquetes.

6
 Fig26: Gráfica Bitrate Multiflujo Fig27: Gráfica Delay Multiflujo
Jitter.-Dado que el delay es constante la variación de éste en valor medio también lo es, y su valor es bajo lo
que ayuda para no comprometer los paquetes en la transmisión.
Packetloss.-De acuerdo al comportamiento del Delay y del Jitter podemos ver que no existe pérdida de paquetes.

Fig28: Gráfica Jitter Multiflujo Fig29: Gráfica Packetloss Multiflujo

5. Conclusiones:

En los tres tipos de tráfico se obtuvo una óptima comunicación ya que en ninguna se obtuvo perdida de
paquetes, esto se debe a que la comunicación entre las PCs fue por un medio cableado y a una corta
distancia, tomando en cuenta que el cable era de buena calidad y no presentaba deterioros caso contrario
hubiésemos tenido perdida de información.
Nos pudimos dar cuenta que el tráfico unidireccional presenta una gráfica de delay distinta a la del tráfico
bidireccional, esto se debió a que el DITG no sincroniza los relojes de las PCs y es por esto que en el
primer caso se obtiene un delay alto y con un comportamiento constante.
Para realizar la simulación del tráfico bidireccional fue necesario realizarlo por medio de código en el
terminal de UBUNTU ya que el software DITG no nos permite configurar a ambas PCs como emisoras y
transmisoras a la vez.
En el tráfico bidireccional se presentó retardo, puesto que este no es simultáneo en las dos PCs, esto se
debe a que en el momento de la comunicación las PCs deben decidir quién va a enviar y quien va a recibir
primero.
En el tráfico bidireccional se obtuvieron diferentes gráficas en las dos PCs eso se refiere a la negociación y
sincronismo de reloj para el paso de tráfico y dependiendo de la NIC de cada computadora establecerá la
comunicación.
El tráfico unidireccional es el menos determinı́stico frente a los demás dado que presenta una curva
Gausiana, mientras que los demás presentan su latencia en forma determinı́stica.

6. Recomendaciones:

Es necesario utilizar cable cruzado para la comunicación entre las PCs ya que si utilizamos un cable directo
tendremos muchos errores al momento de enviar información, es decir tendremos demasiada pérdida de

7
 paquetes, Además de esto debemos verificar que nuestras PCs están en red caso contario nunca se
podrá establecer la comunicación

Se recomienda también configurar de manera eficiente el terminal en el que se guardara los logs, para con
esta información generar las graficas que el inyector de tráfico proporciona de acuerdo a la información
enviada por el medio.

Es importante comprobar los permisos para ejecutar el ITGPlot caso contrario no se nos permitirá generar
ningún tipo de tráfico.

DITG mantien cerrado el mismo por medio de la interfaz gráfica; para esto se debe ingresar al terminal y
digitar el comando ps -d, donde muestra el número y nombre de los procesos activos, luego se digita kill
numerodelProceso. Si esto no se ejecuta este comando se puede presentar un mensaje de error ya que se
está ejecutando aún otro proceso.

7. Referencias:

DITG, d-itg-manual.pdf,29/09/10.

Parámetros para medir la QoS, www.nsrc.org/workshops/2008/walc/.../performance concepts.pdf,

01/10/10.[1]

Rendimiento de la red parámetros que intervienen, http://www.anixtersoluciones.com/latam/cl /infor-

macion general/2078/la importancia de la calidad de servicio qos parte ii es.htm, 01/10/10.[2]

8
8. Anexos:
CUESTIONARIO DIT-G

1. Es posible que el delay salga negativo, si es posible, porque?

Si es posible que el Delay salga negativo ya que el programa DITG no posee ningún tipo de sincronismo
entre emisor y receptor esto debido a los relojes internos de cada máquina tanto emisora como receptora;
por lo que esta variación de tiempo acasiona éste fenómeno.

2. Que se debe realizar para que el delay tenga el valor correcto?

Con el fin de medir correctamente paquetes de One Way Delay (OWD), los relojes de emisor y el receptor
deben estar sincronizados por otros medios (mediante el uso de NTP, GPS, etc.). En caso contrario, le
sugerimos utilizar el medidor de tiempo de ida y vuelta (RTT). Esta es otra caracterı́stica de la D-ITG.

3. Porque es importante la sincronización en la comunicación?

Como explicamos en las preguntas anteriores es muy importante, ya que sin una correcta sincronización
vamos a tener retardos muy grandes o con variacionesya que cuando esto ocurre produce pérdida de
paquetes o errores de transmisión como: datos erróneos o colisiones y congestión en el canal.

4. En las graficas obtenidas que se debe modificar para que sean mejor apreciadas?
Primero ubicamos el archivo llamado itgrecv.log, lo copiamos y pegamos en:
/root/DITG/D-ITG-2.7.0-Beta2/src/ITGDec
Posteriormente en el terminal nos ubicamos en la dirección anteriormente mencionada y digitamos el
comando:
./ITGDec itgrecv.log -v -d 250 -b 250 -p 250 -j 250
Donde los valores de 250 son los que nos indican la escala en la que se va a presentar para aumentar la
mismo, con este comando se generarán 4 archivos con extensión .dat los cuales deberán ser graficados
por lı́nea de comandos para observar el cambio.

5. Para qué sirve el inyector de tráfico?

Como pudimos observar en la práctica realizada un inyector de trafico nos permite saber cuánto es lo
máximo que nos podrı́a resistir un canal respecto a velocidad ası́ también como ver retardos que ocurren
en la conexión, ver si algunos paquetes se están perdiendo, verificar la tasa de error entre otras carac-
terı́sticas tanto del canal como de la transmisión y ası́ aprovechar al máximo nuestro enlace.

6. Que tipo de trafico podrı́a enviar?, se puede enviar video?

Los tipos que envı́a DITG son muy completos ya que logra soportar envió de voz, video y datos; especı́fi-
camente udp, tcp, icmp, dccp y sctp. Para el caso de udp al ser este no orientado a la conexión se puede
enviar: Gaming, Voice y DNS, Custom. Para tráfico TCP, se puede enviar: Telnet, DNS y Custom, para
el resto se puede enviar tráfico personalizado (Custom). En cuestión de video cabe recalcar que el trafico
debe ser en nivel medio de (1000 paquetes de 50 bytes c/u) y en un nivel alto de (1000 paquetes de 100
bytes c/u).

7. Qué se puede observar con la gráfica obtenida del Jitter?

Dado que es la medida de variación de delay entre paquetes consecutivos en un determinado flujo de
tráfico. Genera un efecto importante sobre las aplicaciones sensibles al delay en tiempo real, como voz
y video. A medida que varı́a la tasa de delay, el jitter impacta sobre el rendimiento de la aplicación. En
base a esto el valor promedio de todas las gráficas del Jitter fue bajo, lo que indica que su transmisión

9
 fué óptima ya que si este posee variaciones la comunicación serı́a inútil.

8. Que diferencia se encuentra entre las graficas obtenidas de tráfico, unidireccional y bidireccional?
Primero como todos debemos recordar el modo de transmisión es muy diferente en las 2 inyecciones de
trafico ya que en la unidireccional un PC recibe y otro transmite pero en el caso de la bidireccional las
dos PCs envı́an y reciben, por lo tanto las diferencias que podemos resaltar en las graficas son:
Bitrate: Podemos observar que existe una mayor tasa en la unidireccional respecto a la bidireccional
ya que utiliza todo el canal para el envió lo que en la bidireccional utiliza el canal para envió y
recepción al mismo tiempo

Delay: En esta grafica por motivos de sincronismo observamos un mayor retardo en la unidireccional
respecto a la bidireccional

Jitter: Como podemos observar no existe mucha diferencia el uno del otro y esto es bueno porque
sabemos que este si tiene muchas variaciones la inyección de trafico se volverá inútil.

Packetloss: En relacion de la unidireccional y bidireccional podemos decir que no existen diferencias

los 2 envios fueron exitosos ya que no poseen paquetes perdidos.
Cabe recalcar que todas estas diferencias las realizamos con respecto a las gráficas de transmisión
del tipo de inyección de tráfico Bidireccional.

9. Con las graficas del trafico multiflujo que se puede concluir?

Claramente podemos observar que en este tipo de inyección de tráfico la tasa de bits disminuye respecto
a las otras, ya que a través de este canal se está enviando 2 tipos de tráfico diferente por lo que el
ancho de banda para cada tipo de tráfico se ve comprometido, es decir disminuye y la cantidad de bits
por segundo transmitidos es menor. Referente a las otras gráficas vemos que tienen un comportamiento
adecuado para evitar la pérdida de paquetes.

10. Que indica la grafica del paquetloss?

Como sabemos paquetloss significa paquetes perdidos por lo cual las graficas presentadas de packetloss
lo que nos indica es la cantidad de paquetes que se perdieron durante la transmisión en un total de 30
paquetes los cuales fueron enviados en nuestro caso.

10