Comparison Between MAC- Address- Based Simple Switch AND IP- Address- Based Simple Switch PDF

Preview

Summary

En esta práctica se tiene como objetivo comparar el ​simple_switch_13.py​, basado en direcciones físicas MAC, con el desarrollo de otro modelo pero basado en direcciones de red IP. Este contraste se espera realizar por medio de tres parámetros: ​delay, throughput y​ ​packet loss, y​ nos permitirá co...

Description

COMPARISON BETWEEN MAC-ADDRESS-BASED SIMPLE SWITCH AND IP-ADDRESS-BASED SIMPLE SWITCH

PRESENTADO A: OSCAR MAURICIO CAICEDO RENDÓN

PRESENTADO POR: JUAN SEBASTIÁN GUZMÁN ALARCÓN LUDWING NICOLE PALOMINO VENACHI ISABELA TOLEDO BALCÁZAR

FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES APLICACIONES Y SERVICIOS TELEMÁTICOS POPAYÁN, 2019

INTRODUCCIÓN La API de Ryu permite el rápido desarrollo de prototipos de aplicaciones del controlador. En la API se incluye tanta funcionalidad que la creación de un controlador de switch de aprendizaje L2 simple, como el simple_switch_13.py, requiere una pequeña cantidad de líneas de código en Python [1]. A diferencia de un hub L2 que inunda todos los puertos con las tramas recibidas, un switch L2 debe enrutar eficientemente las tramas Ethernet unicast al puerto físico específico que está conectado al dispositivo con la dirección de destino MAC. Por supuesto, cuando se ejecuta un switch por primera vez, no conoce la ubicación de cada dispositivo al que está conectado, por lo que debe producirse una inundación hasta que se reciban las tramas de cada dispositivo al que se dirigirá. El flujo generalmente presenta la siguiente estructura. En primer lugar, se recibe una trama en un puerto físico con direcciones MAC de origen y destino. La tabla interna MAC-to-port del switch se actualiza con la dirección de origen y el puerto físico. En la tabla MAC-to-port se busca la dirección MAC de destino para encontrar el puerto físico asociado. En caso de fallo, la trama se inunda en todos los puertos físicos del conmutador, excepto en el puerto de recepción. En un match o acierto, la trama se envía al puerto físico asociado con la dirección. En esta práctica se tiene como objetivo comparar el simple_switch_13.py, basado en direcciones físicas MAC, con el desarrollo de otro modelo pero basado en direcciones de red IP. Este contraste se espera realizar por medio de tres parámetros: delay, throughput y packet loss, y nos permitirá conocer cuál de los protocolos nos brinda una mejor respuesta frente a las pruebas.

1. REGULAR MAC-ADDRESS-BASED SIMPLE SWITCH Para desarrollar la práctica asignada, como primera parte se harán las medidas de los parámetros de delay, throughput y packet loss, sobre una topología de red lineal con un número de switches escalable para hacer las comparaciones respectivas en función del número de switches. Para estas pruebas se utilizará como controlador el simple_switch_13 basado en direcciones MAC. Para describir el funcionamiento del simple_switch_13.py brevemente, nos remitimos a la lógica principal en la aplicación del controlador, que se encuentra en el ‘packet_in_handler’. Se define un controlador para ryu.controller.ofp_event.EventOFPPacketIn que se llama cada vez que el conmutador envía un paquete al controlador. Esto solo ocurre si el switch aún no sabe a dónde enviar el paquete debido a un table-miss. La primera parte del controlador extrae información vital sobre el mensaje y el paquete enviado al controlador. Una vez que se extraen los elementos esenciales, se crea la tabla MAC-to-Port para el DPID del conmutador actual si aún no existe. La información del paquete se registra y la tabla MAC-to-Port finalmente se actualiza con la dirección de origen del paquete asociado con el puerto al que llegó. Si la dirección MAC de destino se encontró en la tabla MAC-to-Port, se agrega una entrada de flujo al switch para garantizar que los paquetes futuros del mismo puerto a la misma dirección se reenvíen sin ir al controlador. Finalmente, ahora que el destino está configurado como flood o un puerto aprendido, el conmutador recibe instrucciones de enviar el paquete que recibió el controlador para que el paquete no se pierda durante el proceso de aprendizaje.

Fig 1. Script simple_switch_13.py La ejecución del simple_switch_13 se describe en la Fig. 2 y el lanzamiento de la topología de red lineal con 12 switches se puede observar en la Fig. 3.

Fig 2. Lanzamiento controlador MAC routing. En seguida (Fig 3), se procede a lanzar una red con 12 host, para evaluar sus parámetros relativos al desempeño para este número de switches. Cabe recalcar que tal y como se muestra en esta imagen, para poder observar una pérdida de paquetes apreciable, se establece enlaces con un tamaño máximo de colas de paquetes en los buffer de los switch, tal que al superar dicho tamaño máximo, el buffer se desborda, conduciendo a la pérdida de paquetes.

Fig 3. Lanzamiento red lineal, 12 hosts

A continuación, para realizar la recolección de datos para las estadísticas, se utiliza el software de simulación D-ITG, con el cual tras establecer un receptor en el host terminal de la red, es decir, en el host 12 (Fig. 4) y un transmisor en el primer host de la red, es decir, el host 1 (Fig. 5), se inicia una comunicación UDP. Para la comunicación se configuran los siguientes parámetros (Fig 6): la dirección de destino (-a 10.0.0.12), el tamaño de los paquetes de 512 bytes (- c 512), tasa de transmisión de paquetes de 1000 pkts/s (-C 100) y protocolo de transporte UDP (-T UDP). Sin embargo, como se observa en esta imagen, con el objetivo de simular condiciones más realistas en la red se simuló otras condiciones de tráfico normal en la red, es decir, se estableció otra comunicaciones entre otros terminales en la red, siendo estas comunicaciones bien sea del tipo UDP, o en su defecto de VoIP pues este último tipo de comunicaciones son conocidas por las condiciones adversas que imponen a la red en lo respectivo al tráfico soportado por la misma.

Fig 4. host A, communication receiver.

Fig 5. host B, communication sender.

Fig 6. Configuración de tráfico para comunicación sender-receiver. Finalmente (Fig 7), se procede a decodificar el archivo generado por D-ITG en el cual se almacenaron los datos para realizar las estadísticas.

Fig 7. Information Decoding. Este mismo procedimiento se realiza escalando la topología inicial. Para ello, se hacen las pruebas sobre topologías lineales con 24, 48 y 36 switches. Este número de switches son elegidos con el objetivo de analizar los parámetros de desempeño previamente establecidos conforme hay un incremento lineal en el número de switches presentes en la red.

Fig 8. Lanzamiento red lineal, 24 host. 2. MODIFIED IP-ADDRESS-BASED SIMPLE SWITCH Continuando con los requerimientos de la práctica, ahora se procede a realizar las modificaciones necesarias del simple_switch_13 (Fig 9) para que el controlador trabaje con direccionamiento IP en lugar de MAC. Esto se logró primero importando algunas librerías de RYU que permitieran el trabajo con IP, tal y como lo son. En seguida se procedió a establecer una variable “pkt” en la cual se obtienen datos relativos a un paquete de entrada, para posteriormente obtener de ella el paquete ipv4 con el cual se realizará el respectivo direccionamiento. Posteriormente, se procede a verificar si en el paquete de entrada si existe un paquete ipv4, donde si este es el caso, se extraer su respectivo campo de fuente y destino para establecer el destino del mensaje a la entrada del switch. Acto seguido se procede a verificar si el destino en cuestión ya se encuentra en alguna acción de direccionamiento de la tabla de flujo, tal que de ser ese el caso, se establece como puerto de entrada el puerto determinado por el mensaje de entrada, mientras que si el destino no se encuentra en la tabla, la salida del switch debe ser realizar una inundación a todos los puertos del mismo, para verificar con cuál de ellos hacer match con el puerto de entrada. De esta forma, se cubren los dos casos posibles para establecer la comunicación, donde en uno de ellos no se ha establecido previamente una entrada de flujo para un mensaje de entrada determinado, como en el caso en que ya exista un match para el mensaje de entrada en cuestión.

Fig 8. Script simple_switch_13_IP.py

Finalmente, se procedió a lanzar en el controlador esta programación establecida para realizar un enrutamiento a nivel IP (Fig 10) y a seguir todos los pasos explicados en la primera sección del documento, pues básicamente se debe ejecutar la red con enrutamiento IP con las mismas condiciones establecidas para enrutamiento MAC para tener una acertada comparación entre el comportamiento de estos dos tipos de enrutamientos a nivel de desempeño

Fig 10. Lanzamiento controlador IP routing.

3. GRAPHICAL COMPARISON Para la comparación gráfica se tiene establecido un esquema en el que se presente en el eje x el número de switches de la topología lanzada, con un n que representa un número entero de nuestra elección, y por otro lado, el eje y representa los valores obtenidos del delay, throughput y packet loss. A continuación se modelan los resultados obtenidos para las red lanzada con 24 como número máximo de switches.

Fig 11. Throughput comparison between MAC-based Simple Switch vs IP-based Simple Switch, 48 max Sw.

Fig 12. Delay comparison between MAC-based Simple Switch vs IP-based Simple Switch, 48 max Sw.

Fig 13. Packet loss comparison between MAC-based Simple Switch vs IP-based Simple Switch, 48 max Sw. Como conclusión se logró determinar que a través de direcciones MAC se logran obtener mejores resultados que con direcciones de red IP, sin embargo este comportamiento se evidencia desde un número determinado de switches, es decir, conforme más se incrementa el número de switches que componen la red, hay un punto en el que el direccionamiento MAC mejora con diferencia su comportamiento con respecto al direccionamiento IP. Esto se logra evidenciar en parámetros como el packet loss (Fig 13), en donde se presenta mayor porcentaje de pérdida de paquetes. Estas conclusiones se hacen más contundente al realizar las mismas pruebas planteadas a lo largo del documento pero con un número más escalado (100) de switches (Fig 14, 15, 16), donde se observa de manera más diferenciada, como el incrementar el número de switches en la red mejora el desempeño del enrutamiento MAC en comparación al enrutamiento IP.

Fig 14. Throughput comparison between MAC-based Simple Switch vs IP-based Simple Switch, 48 max Sw.

Fig 15. Delay comparison between MAC-based Simple Switch vs IP-based Simple Switch, 48 max Sw.

Fig 16. Packet loss comparison between MAC-based Simple Switch vs IP-based Simple Switch, 48 max Sw. REFERENCIAS [1] “Understanding the Ryu API: Dissecting Simple Switch”, Leo Scott, General, OF Core Track [Online]. Available: https://inside-openflow.com/2016/07/21/ryu-api-dissecting-simple-switch/ [Accessed: 29-May-2019]...