Vous êtes sur la page 1sur 16

ESCUELA POLITECNICA DEL EJERCITO DEPARTAMENTO DE ELECTRICA Y ELECTRONICA COMUNICACIONES INALAMBRICAS INFORME DE LA PRACTICA N.

N.- 2: Evaluaci on del desempe no de TCP Inal ambrico en una red WLAN en ambientes exteriores de la ESPE. Yessenia Relica Diego Zamora 09 de Abril 2013

1.

Resumen

Este informe mostrara el an alisis gr aco de la tasa de bits por medio inyector de tr aco D-ITG ejecutado sobre una m aquina virtual con el sistema operativo Ubuntu 10.04 (Linux), con los datos obtenidos en la pr actica como son (*.log) generamos los archivos *.txt del bitrate, jitter, delay, packetloss con los cuales procedemos a ejecutar el modo gr aco (*.dat) para posteriormente hacer el an alisis de gr acas mediante el ploteo.

2.

Introducci on

Hoy en d a las redes inal ambricas siguen ganando terreno frente a las redes cableadas gracias a su facilidad de instalaci on, adem as sus ventajas como movilidad y cobertura siguen creciendo, logrando as tener la capacidad de proveer el servicio a muchos usuarios de acceso limitado a conexiones f sicas. La importancia de esta practica se basa en realizar un an alisis del tr aco en un enlace inal ambrico bajo el est andar 802.11b en el canal 11, y as poder determinar varios par ametros como tasas de transmisi on y tasas de error, con el objetivo de poder escoger el mejor Kernel utilizado bajo nuestras condiciones. Para lograr este objetivo se uso la herramienta DITG (Distributed Internet Trac Generator) el cual es una plataforma de c odigo abierto para la generaci on de tr aco, para paquetes con tama no y tiempo variable. Esta herramienta nos permitir a hacer una medici on de rendimiento del enlace, y calcular par ametros para lograr nuestro objetivo.

3.
3.1.

Objetivos de la pr actica
Objetivo General
Analizar la inyecci on de tr aco en los tres kernel que nos permite manejar la m aquina virtual de Ubuntu y as considerar el que mejor transmite al realizarla en tcp.

3.2.

Objetivos Espec cos


Realizar el an alisis gr aco por medio de los *.log generados en la pr actica. Realizar la conguraci on en el terminal de la m aquina virtual para la generaci on de los *.dat y asi lograr que el estudiante se familiarice con los modos gr acos en bitrate, jitter, etc. Lograr evaluaci on del desempe no de la red con el est andar IEEE 802.11, mediante la inyecci on de tr aco por medio de las gr acas obtenidas.

4.
4.1.

Fundamento Te orico
Protocolo TCP

Es uno de los principales protocolos de la capa de transporte del modelo TCP/IP. En el nivel de aplicaci on, posibilita la administraci on de datos que vienen del nivel m as bajo del modelo, o van hacia el, (es decir, el protocolo IP). Cuando se proporcionan los datos al protocolo IP, los agrupa en datagramas IP, jando el campo del protocolo en 6 (para que sepa con anticipaci on que el protocolo es TCP). TCP es un protocolo orientado a conexi on, es decir, que permite que dos m aquinas que est an comunicadas controlen el estado de la transmisi on. Las principales caracter sticas del protocolo TCP son las siguientes: TCP permite colocar los datagramas nuevamente en orden cuando vienen del protocolo IP. TCP permite el monitoreo del ujo de los datos y as evita la saturaci on de la red. TCP permite que los datos se formen en segmentos de longitud variada para entregarlos al protocolo IP. TCP permite multiplexar los datos, es decir, que la informaci on que viene de diferentes fuentes (por ejemplo, aplicaciones) en la misma l nea pueda circular simult aneamente. Por u ltimo, TCP permite comenzar y nalizar la comunicaci on amablemente.

Con el uso del protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al sistema de acuse de recibo del protocolo TCP) independientemente de las capas inferiores. Esto signica que los routers (que funcionan en la capa de Internet) s olo tienen que enviar los datos en forma de datagramas, sin preocuparse con el monitoreo de datos porque esta funci on la cumple la capa de transporte (o m as espec camente el protocolo TCP). Durante una comunicaci on usando el protocolo TCP, las dos m aquinas deben establecer una conexi on. La m aquina emisora (la que solicita la conexi on) se llama cliente, y la m aquina receptora se llama servidor. Por eso es que decimos que estamos en un entorno Cliente-Servidor. Las m aquinas de dicho entorno se comunican en modo en l nea, es decir, que la comunicaci on se realiza en ambas direcciones. Para posibilitar la comunicaci on y que funcionen bien todos los controles que la acompa nan, los datos se agrupan; es decir, que se agrega un encabezado a los paquetes de datos que permitir an sincronizar las transmisiones y garantizar su recepci on. Otra funci on del TCP es la capacidad de controlar la velocidad de los datos usando su capacidad para emitir mensajes de tama no variable. Estos mensajes se llaman segmentos.

4.2.

Kernel

El kernel o n ucleo de linux se puede denir como el coraz on de este sistema operativo. Es el encargado de que el software y el hardware de tu ordenador puedan trabajar juntos. Las funciones m as importantes del mismo, aunque no las u nicas, son: Administraci on de la memoria para todos los programas y procesos en ejecuci on. Administraci on del tiempo de procesador que los programas y procesos en ejecuci on utilizan. Es el encargado de que podamos acceder a los perif ericos elementos de nuestro ordenador de una manera c omoda. En funci on del tama no y de las funcionalidades que posea el kernel podemos clasicarlo. Realmente, y pese a seguidores incondicionales en un modelo u otro, existe una tendencia b asica a reducir el tama no del n ucleo proporcionando menos funcionalidades, que son desplazadas a m odulos que se cargan en tiempo de ejecuci on. En funci on a esta idea tenemos tres tipos fundamentales de kernel: Kernel monol tico:Todas las funcionalidades posibles est an integradas en el sistema. Se trata de un programa de tama no considerable que deberemos recompilar al completo cada vez que queramos a nadir una nueva posibilidad. Esta es la estructura original de Linux. Por tratarse de una t ecnica cl asica y desfasada el creador de Linux fue muy criticado.

Kernel modular:Se trata de la tendencia actual de desarrollo. En el kernel se centran la funcionalidades esenciales como la administraci on de memoria, la planicaci on de procesos, etc. Sin embargo no tiene sentido que el n ucleo de un sistema operativo englobe toda la parafernalia para comunicarse con todas las posibles de tarjetas de video o de sonido. En otros sistemas operativos esto se soluciona con unos cheros proporcionados por el fabricante llamados drivers. En Linux se cre o un interfaz adecuado para posibilitar el desarrollo de m odulos que cumplieran esas funcionalidades. Esos m odulos pueden ser compilados por separado y a nadidos al kernel en tiempo de ejecuci on. Estructura de microkernel:Esta t ecnica pretende reducir a su m nima expresi on el kernel, dejando a los niveles superiores el resto de las funcionalidades. Existen algunos kernels que lo utilizan, si bien el que centra nuestra atenci on es Hurd. Se trata del u ltimo kernel GNU llamado a sustituir a Linux como n ucleo del sistema operativo. Aunque esta estrategia de dise no es tan antigua como la modular, no ha sido tenida en cuenta hasta ahora debido a las limitaciones de rendimiento que ten a.

4.3.

Par ametros de una transmisi on


Bitrate: el n umero de bits que se transmiten por unidad de tiempo a trav es de un sistema de transmisi on digital o entre dos dispositivos digitales. As pues, es la velocidad de transferencia de datos. Delay spread:En las telecomunicaciones, la dispersi on de retardo es una medida de la trayectoria m ultiple riqueza de un canal de comunicaciones. En general, se puede interpretar como la diferencia entre el tiempo de llegada de la componente de trayectoria m ultiple que importante (normalmente la l nea de visi on de componente) y el tiempo de llegada de la u ltima componente multitrayecto. La dispersi on del retardo se utiliza sobre todo en la caracterizaci on de los canales inal ambricos, pero tambi en se aplica a cualquier otro canal de trayectorias m ultiples. Jitter: Este par ametro resulta cr tico para aplicaciones en tiempo real, como la voz,y representa la variaci on en los tiempos de llegada de los paquetes, que viajan por las diversas rutas o nodos con diferentes estados de congesti on. Una alternativa para mejorar el jitter es incorporar la t ecnica de buering en los nodos, de tal manera de ir almacenando los paquetes en el interior de un buer y de esta manera darles un retardo constante, la idea b asica es que si el buer est a vac o el paquete tardara un per odo de tiempo T constante (por ejemplo, de 20 ms) en atravesarlo, y si el buer esta con paquetes, los entrantes empujan a los que est an en su interior de tal manera que estos salgan con el mismo per odo T de tiempo. Latencia:Retardo total de los paquetes entre fuente y destino a trav es de la red.

P erdida de paquetes:La p erdida de paquetes es cuando uno o m as paquetes que fueron transmitidos no fueron capaces de llegar a su destino, evento que puede causar efectos perjudiciales en todo tipo de comunicaciones digitales. Esto se puede dar por varias razones, como son: porque la intensidad de la se nal no es sucientemente alta como para alcanzar a su destino, por las interferencias en el medio ambiente, ruido excesivo del sistema, fallos en el hardware, corrupci on de software o una sobre carga en los nodos de la red. Generalmente, uno o m as de estos factores se encuentra presente cuando se produce una p erdida de paquetes.

5.

Equipos y Materiales
2 Computadoras con soporte para m aquina virtual VMWARE, instalados el sistema operativo Linux distribuci on Ubuntu. Punto de Acceso Ubiquiti Power Station 2. Cable Directo Ethernet. Software D-ITG instalado en las dos computadoras.

6.
6.1.

Procedimiento de la Pr actica
Montaje y Conguraci on del Router Inal ambrico

Para esto decidimos montar la antena en la torre ubicada en la terraza de los laboratorios como se puede apreciar en la Figura 15.Una vez asegurada, la apuntamos hacia los estacionamientos del laboratorio de Electr onica, de forma que tengamos una gran a rea de cobertura. Una vez hecho esto, conectamos el router, d andole energ a y accediendo a su puerto LAN a trav es de su adaptador. Para acceder a la conguraci on del router, ingresamos una ip manualmente, la cual deb a estar dentro del dominio de la la IP por defecto del router. Para esto utilizamos la IP 192.168.1.40. Luego de esto accedimos al sistema ingresando el nombre de usuario y la clave por defecto, tal como se aprecia en la gura 1. Luego conguramos al router , elegimos la secci on en la que nos encontramos, y el canal a utilizar. Todo esto lo podemos comprobar en la gura 2.

6.2.

Conguraci on de las Maquinas Virtuales

Debido a que se tenia activado el servicio DHCP en el router, las direeciones que nos dio el mimo se representan el cuadro 1. 5

Figura 1: Ventana de acceso al sistema de conguraci on del router inal ambrico.

Figura 2: Ventana de conguraci on del router inal ambrico. Computadoras Direcci on F sica Direcci on Virtual 1 10.1.10.133 10.1.10.115 2 10.1.10.124 10.1.10.100 Cuadro1.Direcciones IP usadas

6.3.

Ubicaci on de nuestra PC para la Transmisi on

La ubicaci on se tom o un lugar donde no exista muchos obst aculos, para poder alejarnos una distancia considerable de nuestro Router donde llegue aun la conexi on a nuestras PC y de esta manera realizar la inyecci on de tr aco, a continuaci on mostramos un esquema de donde nos ubicamos.

6.4.
6.4.1.

Inyecci on de tr aco unidireccional


Conguraci on de Par ametros Generales

Para comenzar la conguraci on primero debemos abrir el GUI del D-ITG. Esto se lo hace como se indica en la gura 4. Una vez adentro, la conguraci on se la hace en la maquina transmisora, debido a que en la receptora solo se debe presionar el boton Recive para que funcione. Los par ametros a congurar son: 6

Figura 3: Ubicaci on del router y las PC

Figura 4: Comandos utilizados para ejecutar el GUI del D-ITG

1. El Protocolo 2. La duraci on 3. El medidor 4. La direcci on de la pc receptora (target host) 5. El numero de paquetes por segundo. 6. El nombre del archivo del log. Tal como esta en la gura 6 Para esta conguraci on deberemos seguir los pasos indicados en la gu a de laboratorio, deniendo par ametros como: Direcciones tanto de logs como de bin Duraci on de env o de paquetes: 30(0.5 minutes) Selecci on de archivos de texto. Target Host: Aputamos a la direcci on IP de la m aquina receptora, entre otros par ametros para su posterior an alisis. Receptor: Settings y Analizer Como en el caso anterior se mantendr a la conguraci on indicada en la gu a. Se debe tomar en cuenta que la m aquina receptora deber a iniciar la transmisi on presionando loger y receiver, posteriormente la m aquina transmisora deber a presionar sender para su comunicaci on. La mayor a de la conguraci on se la puede apreciar en la gura 5. Tomemos en Cuenta que utilizamos One-Way-Delay para el medidor. Esto se debe a que a pesar de que estamos evaluando la calidad de un protocolos OC (orientado a la conexi on) basados en diferentes Kernels donde se le hizo cambios al tratamiento de los protocolos IP, pero los ACK siguen siendo iguales. Debido a esto no necesitemos medir el retardo de los ACK ya que en teor a causar an el mismo retardo en los 3 Kernels evaluados, y es por esto que pueden ser despreciados para esta practica. Una vez hecho esto, solo hab a que presionar el bot on Sender para comenzar el proceso.

7.
7.1.

An alisis de resultados
An alisis de logs

Utilizamos tres kernels con los que vamos a hacer pruebas de inyecci on de tr aco en cada uno de los n ucleos, el primero a ser analizado es el kernel de 15 luego el de 20 y el ultimo que analizaremos ser a el gen erico. Los resultados de los .txt los cuales los podemos ver mediante el analizador del DIT-G como texto usando el .log generado al momento de concluir la inyecci on de tr aco.

Figura 5: Conguraci on del D-ITG

Figura 6: Conguraci on del D-ITG

7.1.1.

An alisis Kernel 15

Figura 7: Kernel 15 Al realizar la inyecci on de tr aco pudimos observar que estamos enviando 1024 paquetes y obtuvimos como llegada 621.86 paquetes a una velocidad de 2547.14 kbits/s. 7.1.2. An alisis Kernel 20

Figura 8: Kernel 20 En esta inyecci on nos damos cuenta que obtuvimos como llegada 631.15 paquetes que resulto el mayor n umero de paquetes que llego evaluando los 3 kernels y la velocidad que se obtuvo fue de 2585.22 kbits/s, este kernel el mejor en velocidad y envi o de paquetes. 7.1.3. An alisis Kernel Gen erico

Para nuestra simulaci on este kernel fue el que menor tasa de bits recibi o como podemos observar en la gura.

10

Figura 9: Kernel gen erico

8.

Preguntas
ONE WAY DELAY

1. Dena cu al es la m etrica adecuada para evaluar el protocolo TCP.

El valor m nimo de esta m etrica da una indicaci on del retardo debido exclusivamente a la transmisi on y propagaci on, siendo ademas una estimaci on del retardo sufrido en condiciones de baja carga. Valores de retardo por arriba de este valor m nimo dan una indicaci on del nivel descongesti on de la red. Explicaci on Gr aca Desde una fuente a un destino en el tiempo T es dT si la fuente env a el primer bit de un paquete al destino en el tiempo T y el destino recibe el u ltimo bit del paquete en el tiempo T + dT. Esto quiere decir que esta m etrica se utiliza para calcular el tiempo de ida desde el transmisor hacia el receptor sin tomar en cuenta el camino que tome. El valor de retardo de una v a se calcula entre dos puntos A y B sincronizadas de una red IP , y es el tiempo en segundos que un paquete pasa en viajar a trav es de la red IP de A a B. Los paquetes transmitidos deben ser identicados en origen y de destino a n de evitar la p erdida de paquetes o reordenaci on de paquetes. El m etodo de medici on hace obvio que este valor es sustancialmente diferente del tiempo de ida y vuelta. La justicaci on de usar esta m etrica es con el n de medir correctamente un paquete OWD, los relojes de emisor y receptor deber estar sincronizados correctamente con un desfase de tiempo de segundos ya que el software DITG no proporciona ning un tipo de sincronizaci on entre emisor y receptor.

11

ROUND TRIP-TIME

Su traducci on es el tiempo de retardo de ida y vuelta (RTD) o ida y vuelta tiempo (RTT) es la longitud de tiempo que tarda una se nal que se enviar a m as la longitud de tiempo que le toma a un reconocimiento de que la se nal a ser recibida. Este retardo de tiempo consiste, por tanto los tiempos de transmisi on entre los dos puntos de una se nal. La se nal es generalmente un paquete de datos , y el RTT es tambi en conocido como el tiempo de ping. Un usuario de Internet puede determinar la RTT mediante el comando ping. C alculo del RTT: RT T = ( Old RT T ) + ((1 ) Donde: : es el factor de ponderaci on constante (0 < 1) Si es cercano a 1 hace que el promedio ponderado sea inmune a los cambios que duran poco tiempo (por ejemplo, un segmento que se encuentra con retraso). Si es cercano a 0 hace que el promedio ponderado de responder a los cambios en el retardo sea muy r apido. La justicaci on de cual usar es: Si existe un desfase en la sincronizaci on de relojes de emisor y receptor es necesario utilizar la m etrica RTT que se basa en el calculo del tiempo en salir del emisor y volver al mismo pasando por el receptor. 2. A qu e tipo de distribuci on se puede ajustar una transmisi on real utilizando el protocolo TCP. Distribuci on Exponencial La distribuci on exponencial es el equivalente continuo de la distribuci on geom etrica discreta. Esta ley de distribuci on describe procesos en los que: Nos interesa saber el tiempo hasta que ocurre determinado evento, sabiendo que, el tiempo que pueda ocurrir desde cualquier instante dado t, hasta que ello ocurra en un instante tf, no depende del tiempo transcurrido anteriormente en el que no ha pasado nada. Distribuci on Gamma Este modelo es una generalizaci on del modelo Exponencial ya que, en ocasiones, 12

se utiliza para modelar variables que describen el tiempo hasta que se produce p veces un determinado suceso. Distribuci on Normal El teorema del l mite central garantiza que cualquier otra distribuci on se comporta como una gaussiana cuando se hacen un n umero suciente de experimentos: suma de muestras independientes para cualquier distribuci on con valor esperado y varianzas nitos converge a la distribuci on normal conforme el tama no de muestras tiende a innito. Distribuci on Uniforme Es una familia de distribuciones de probabilidad para variables aleatorias continuas, tales que cada miembro de la familia, todos los intervalos de igual longitud en la distribuci on en su rango son igualmente probables. Distribuci on Poisson La distribuci on de Poisson es una distribuci on de probabilidad discreta que expresa, a partir de una frecuencia de ocurrencia media, la probabilidad que ocurra un determinado n umero de eventos durante cierto periodo de tiempo. Para nuestro punto de vista se podr a utilizar algunas distribuciones cticias para un modelo de simulaci on pero en la realidad el tr aco viene dado de forma uniforme ya que si existe una demanda de tr aco grande se tiene equipos en la actualidad como son los routers o switch de core que permiten gestionar tr acos altos. 3. Cu al es el tama no del paquete, la tasa de transmisi on y ancho de banda o ptimos para una comunicaci on donde se utiliza TCP inal ambrico. TCP utiliza un u nico tipo de unidad de datos de protocolo, llamado segmento TCP.Ya que la cabecera debe servir para implementar todos los mecanismos del protocolo, esta es m as bien grande, con un a longitud m nima de 20 octetos. Los campos son los siguientes: Tasa de trasmisi on

Una regla general es que el caudal m aximo a nivel TCP/IP es la mitad de la tasa de s mbolos. Por ejemplo, un enlace 802.11 a 54 Mbps tiene un rendimiento m aximo pr actico de unos 25 Mbps. Un enlace 802.11b tiene un rendimiento m aximo de transmisi on de 13

5 Mbps. Para una mayor eciencia en redes de gran ancho de banda, debe ser usado un tama no de ventana mayor. El campo TCP de tama no de ventana controla el movimiento de datos y est a limitado a 16 bits, es decir, a un tama no de ventana de 65.535 bytes. Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala de ventana TCP (TCP window scale) es una opci on usada para incrementar el m aximo tama no de ventana desde 65.535 bytes, a 1 Gigabyte. 4. Realice una tabla conforme a los resultados obtenidos en las preguntas anteriores. Esto le ser a u til al momento de congurar el software DITG para realizar la inyecci on de tr aco utilizando TCP inal ambrico. Para determinar el tama no o ptimo del paquete debemos relacionar el protocolo en uso es decir TCP con el MTU que es la unidad m axima de transferencia entonces la conclusi on es: Cuanto mayor sea el MTU, menos paquetes o tramas ser an necesarios enviar, y por tanto ser a necesario un menor procesamiento, cuesti on muy importante en Firewalls y cualquier sistema que tenga que ltrar, analizar o tratar dicha informaci on. Un dispositivo de red puede usar muy bien con un peque no MTU y tambi en transferir paquetes muy r apidos. Con un MTU inferior ser a m as o ptimo debido a poseer un menor overhead (sobrecarga) debido a los protocolos que intervienen en todo el proceso. Esto es de gran importancia ya que tendr a una relaci on directa con el throughput. MTU Optimo para TCP Con estos valores te oricos se podr a comprobar un margen de error con valores

basados a la realidad 5. Analice los resultados obtenidos del jitter, paquetes perdidos, bit rate, delay, en cada uno de los modos. Se recomienda realizar una tabla comparativa para visualizar mejor estos resultados. En el Anexo A tenemos la representaci on gr aca obtenida en cada kernel, esto se lo realizo con el programa GNUplot. 6. Explique qu e signica y a que se debe obtener un retardo negativo y c omo se podr a solucionar este problema. Se debe a que los relojes de las maquinas tanto virtuales como f sicas no est an sincronizadas por tanto hay un desfase y el retardo nos resulta negativo por este 14

Figura 10: Tabla de datos motivo debemos tener cuidado al momento de sincronizar las maquinas las mismas deben tener la misma hora y fecha al realizar la transmisi on de tr aco.

9.

Conclusiones
Concluimos que al momento de realizar la conguraci on en la plataforma gracias DITG, tener cuidado en los par ametros que se est en insertando porque de no hacerlo este nos producir a errores sin si quiera poder realizar el envi o de los paquetes. Las desventajas de utilizar redes inal ambricas son la disminuci on del Ancho de Banda, y est an expuestas a interferencias, por el contrario es de f acil expansi on, exibilidad y movilidad. En los tres tipos de tr aco se obtuvo una optima comunicaci on ya que en ninguna se obtuvo perdida de paquetes o a su vez existi o una perdida m nima de paquetes debido a que en el mismo canal se encontraban varias antenas, esto se debe a que la comunicaci on 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 esemos tenido mayor p erdida de informaci on. D-ITG nos muestra el mejor rendimiento dentro de la plataforma de Linux a lo que se reere a la inyecci on de tr aco y es capaz de generar altas tasas de transferencia de datos con altos valores de tama no de cada paquete. De forma m as precisa, se realiz o varios experimentos para comparar la velocidad de datos alcanzados por DITG a la alcanzada por otros generadores de tr aco en escenarios

10.

Recomendaciones
Comprobar que la red inal ambrica tenga una buena comunicaci on entre los diferentes dispositivos para que al momento de inyectar tr aco no se generen falsos resultados. Es necesario utilizar cable cruzado para la comunicaci on entre las PCs ya que si utilizamos un cable directo tendremos muchos errores al momento de enviar informaci on, es decir tendremos demasiada p erdida de paquetes, Adem as de esto debemos 15

vericar que nuestras PCs est an en red caso contrario nunca se podr a establecer la comunicaci on se recomienda tambi en congurar de manera eciente el terminal en el que se guardara los logs, para con esta informaci on generar los archivos .txt y poder generar las gr acas que el inyector de traco proporciona de acuerdo a la informaci on enviada por el medio. Es recomendable matar los procesos realizados tanto en el receptor como en el transmisor para evitar errores o que a su vez que las PCs no puedan enviar recibir la informaci on deseada (paquetes), para lo que debemos ejecutar el terminal, con el comando ps ?ld desplegamos todos los procesos y con el comando kill matamos los proceso D-ITG producidos.

Referencias
[1] D-ITG, URL: http://www.grid.unina.it/software/ITG/ [2] Interfaz Gr aca de Usuario para DITG. URL:http://www.semken.com/projekte/index.html [3] D-ITG V. 2.7.0-Beta Manual, Stefano Avallone, Alessio Botta, Alberto Dainotti, Walter de Donato, and Antonio Pescap e, University of Napoli Federico II, December 3, 2008

16

Vous aimerez peut-être aussi