Theme: Disconnection

El mecanismo de reparación de caminos en Flow-Path es análogo al de ARP- Path, salvo que en este caso no existe una diferenciación entre dos mecanismo de reparación “hacia atrás” y “hacia adelante” y sólo existe la opción “hacia atrás”, puesto que se debe recuperar el camino completo del flujo cada vez, al no ser ya independientes los árboles creados por dirección origen.

Como se observa en la siguiente figura, cuando una trama del flujo entre los hosts A y C no encuentra entrada para el puerto de salida hacia C (entrada C-A), se emite un PathFail hasta el puente frontera de A, que emitirá un PathRequest hasta el puente frontera de C y que éste último responderá con un PathReply hasta el frontera de A.

Loopback de tramas

La diferencia es que ahora en Flow-Path todos los caminos son siempre simétricos, al contrario de ARP-Path, que no puede garantizarlo en todos los casos. Al ser todos simétricos, se garantiza que el loopback de tramas es posible, por lo que el mensaje PathFail desaparece, ya ni siquiera será un mensaje broadcast, pues la misma trama unicast que descubrió el enlace caído se podrá reenvíar hacia atrás por el camino por el que vino.

Figura 81. Reparación de caminos para Flow-Path en tres pasos: PathFail, PathRequest y PathReply

Tablas y mensajes necesarios para la reparación en Flow-Path

En cuanto a las tablas y mensajes necesarios, son análogos a los necesarios en ARP-Path. Las tablas necesarias son Learning Table (LT), Broadcast Table (BT), Hello Table (HeT), Host Table (HoT) y Repair Table (RT). Los tipos de mensajes especiales necesarios, se podrían resumir en: mensajes Hello (para definir puentes frontera y no), PathRequest y PathReply (el mensaje PathFail ya no es necesario pues se sustituye por el loopback de tramas). Todos estos mensajes tienen como MAC destino una dirección multicast específica para ARP-Path (AllPathBridgesMcast) y como origen la MAC la dirección del switch que emite el mensaje, aunque en la práctica este campo podría ser cualquiera, dado que si la dirección multicast es

AllPathBridgesMcast estará claro que el mensaje lo ha creado un bridge ARP-Path y no es necesario tampoco saber cual. Dentro del mensaje estan encapsulados tres campos: tipo (Hello = 1, PathFail = 2, PathRequest = 3, PathReply = 4), “dirección origen del flujo a reparar” (siempre será el origen de la trama) y “dirección destino

del flujo a reparar” (destino de la trama). Es decir, el formato de la trama de reparación coincide con la de ARP-Path.

La necesidad de los mensajes especiales radica en el hecho de que los caminos en ARP-Path, inicialmente (FastPath), se fijaban con el primer ARP y luego nuevos mensajes ARP eran descartados para aprendizaje y Flow-Path evolucionó desde esa misma versión, conservando el bloqueo de aprendizaje con el primer ARP. Sin embargo, opcionalmente Flow-Path podría evolucionar hacia un protocolo menos bloqueante (como la última versión de ARP-Path, la versión “retardada”) y quizás utilizar igualmente mensajes ARP creados en los puentes frontera, en lugar de los mensajes especiales, para disminuir el tiempo de procesamiento de estas tramas especiales tal y como se puede hacer en las últimas versiones de ARP-Path. De esta manera, el único mensaje especial necesario para Flow-Path sería el Hello, al sustituirse el PathFail por el loopback de tramas, el PathRequest por un ARP Request y el PathReply por un ARP Reply, pero por supuesto es una opción que queda pendiente de exploración aún.

4.2.2Implementación en OMNeT++ y OpenFlow

Tras descubrir los problemas de la primera versión de ARP-Path (FastPath), surgieron dos nuevas variantes de desarrollo: ARP-Path unidireccional y Flow-Path. Así pues, se actualizaron las implementaciones en OMNeT++ y OpenFlow para Flow- Path (no así la de Linux, orientada a prueba de concepto y no a evaluación), al igual que se hizo para ARP-Path unidireccional. A continuación se detallan algunos matices de estas implementaciones para Flow-Path, puesto que la base en la práctica es la misma que la de FastPath.

Implementación en OMNeT++

Esta implementación está realizada sobre el simulador OMNeT++ (versión 4) y la librería, o framework, inet (versión 1), ya conocidas. La base de la implementación, al igual que con ARP-Path, es el módulo MACRelayUnitNP, que se encuentra dentro de la sección dedicada a Ethernet linklayer/etherswitch/ de la librería inet (en dicha versión 1) y, como su nombre indica, implementa la relay unit

de un switch Ethernet.

Así pues, la única diferencia entre el código de ARP-Path y Flow-Path es la lógica aplicada en la función handleAndDispatchFrame, dado que el resto de la estructura de los switches All-Path tiene mucho en común, como ya se ha visto.

Implementación en OpenFlow

Al igual que en la implementación anterior, en el caso de OpenFlow lo único que varía respecto a ARP-Path es la lógica aplicada en la función principal “handle_packet_in”, que pasa a contener la lógica de Flow-Path. Después, las pruebas se realizaron sobre la máquina virtual Mininet y switches OpenFlow sobre Linux en tarjetas Soekris.

A continuación se muestra una tabla comparativa de tiempos de creación de caminos (path set up) y ping entre hosts (pinging time) entre las implementaciones OpenFlow (Mininet y Soekris) de ARP-Path y Flow-Path. Como es posible apreciar, los tiempos de ping apenas varían, mientras que sí lo hacen a la hora de crear los caminos. Esto se debe a que los tiempos de ping se basan en los tiempos de forwarding de cada plataforma, que a su vez se basan en la tabla de encaminamiento que genera OpenFlow y que es idéntica para ARP-Path y Flow- Path; mientras que en la creación del camino influye la lógica de protocolo y ejecución del código Python en el controlador OpenFlow, que como ya sabemos es ligeramente más compleja para Flow-Path que para ARP-Path, de ahí que sea más lenta también.

Tabla 9: Comparativa de tiempos de creación de caminos y ping en la implementación OpenFlow (Mininet y Soekris) de ARP-Path y Flow-Path

4.2.3Evaluación de Flow-Path frente a ARP-Path

En el siguiente apartado se realiza primero un análisis de las soluciones aportadas por Flow-Path respecto a los problemas de FastPath y, en segundo lugar, una comparativa de estas dos variantes surgidas de FastPath, que son ARP-Path (versión unidireccional, en su evolución tras FastPath) y Flow-Path, y qué ventajas pueden tener una y otra versión, dadas sus diferentes características a la hora de almacenar entradas de encaminamiento en tablas y distribuir el tráfico en la red.