Requirements

Caso 4.5: OFPT_BARRIER_REQUEST y OFPT_BARRIER_REPLY. Asignación de atributos según librería.h

Caso 4.6: OFPT_QUEUE_GET_CONFIG_REQUEST y OFPT_QUEUE_GET_CONFIG_REPLY. Asignación de atributos según librería.h

CASO 5: MENSAJES DE MODIFICACIÓN DE ESTADO.

La dinámica de estos mensajes consiste en enviar un mensaje de modificación de un flow-entry ubicado dentro de la flow-table del switch desde el controlador y después de un SLOT_DURATION enviar un removed del flujo, este slot_duration simula los idle_timeout y hard_timeout expuestos anteriormente. Caso 5.1: OFPT_FLOW_MOD.

Asignación de atributos según librería.h Caso 5.2: OFPT_FLOW_REMOVED. Asignación de atributos según librería.h

CASO 6: MODIFICACIÓN DEL PUERTO (OFPT_PORT_MOD). Asignación de atributos según librería.h

CASO 7: ESTADO DE LOS PUERTOS (OFPT_PORT_STATUS). Asignación de atributos según librería.h

CASO 8: PAQUETE ENTRANTE (OFPT_PACKET_IN). Asignación de atributos según librería.h

34

CONFIGURACIÓN DE LOS PARÁMETROS DE SIMULACIÓN Y DOCUMENTACIÓN DE LAS INTERFAZ GRÁFICA DE CONTROL DE MENSAJES.

Parámetros comunes de configuración

En esta ventana se configuraran los valores comunes de la simulación:

 Duración de la simulación (duration): 1 minuto, este tiempo se configura con este valor, para poder validar el momento en que se presente el no envío de mensajes, para cada caso que se va a simular, y por lo tanto la máquinas deben pasar al estado de desconexión después de transcurrido un tiempo de 30 seg ( SLOT DURATION).

 Los demás parámetros se dejan configurados con los valores por default.

Figura 25. Parámetros comunes de configuración.

Atributo global de validación.

Para controlar cada uno de los mensajes del protocolo OpenFlow dentro del entorno de simulación SMARTNET, se utilizará un atributo global, el cual es configurable como una variable de entrada para la

35

simulación a través de la siguiente interfaz gráfica ofrecida por el software OPNET Modeler®. (Ver figura 26)

Figura 26. Asignar valor al atributo validation.

Este atributo global de validación es el encargado de definir el proceso de comunicación y estructura del mensaje del protocolo OpenFlow V1.0.0 a validar, (Ver tabla 1), el resultado de la validación será acorde con el valor del parámetro validation.

VALIDATION MENSAJE 1 OFPT_HELLO OFPT_ERROR 2 OFPT_PACKET_OUT 3 OFPT_XXXX_REQUEST OFPT_XXXX_REPLY 4 OFPT_PACKET_IN 5 OFPT_FLOW_MOD 6 OFPT_PORT_STATUS 7 OFPT_SET_CONFIG 8 OFPT_PORT_MOD 9 OFPT_FLOW_REMOVED Tabla 1. Valores atributo validation

36

El lector puede remitirse a los diagramas de secuencia definidos para el protocolo, e ir variando en la interfaz gráfica cada uno de los valores para el atributo global validation, con el fin de contratar los resultados obtenidos en la simulación con los definidos teóricamente.

RESULTADOS DE LA SIMULACIÓN.

En el print screen de la consola de simulación de OPNET Modeler® se observa como los diagramas de secuencia generados por la simulación corresponden a la estructura de mensajes utilizados en la especificación del protocolo y cumplen las especificaciones definidas en el trabajo a partir de los diagramas de secuencia. Los valores que van en cada una de esas variables y arreglos de los mensajes los he inicializado en 0.

CASO 1: CONFIGURACIÓN DE LA CONEXIÓN. Caso 1.1 (Same version) OFPT_HELLO.

En este caso para un Connection Setup. La conexión terminará después de pasado cierto tiempo y que no haya ningún envió de mensajes, este time slot está dado por el parámetro SLOT_DURATION en segundos, este intervalo de tiempo es el mismo utilizado para mantener activa la sesión TLS.

37 Caso 1.2 (Different version) OFPT_ERROR.

En este caso, el switch notifica mediante el envío de un mensaje de error al controlador y viceversa que la conexión no fue exitosa, debido a que las versiones son incompatibles entre sí.

Figura 28. Captura de pantalla caso 1.2 CASO 2: INTERRUPCIÓN DE LA CONEXIÓN.

La conexión se interrumpe debido a la inactividad en la generación de mensajes, o desconexión de otro tipo, como lo puede ser la no existencia de interrupciones.

38

Figura 29. Captura de pantalla caso 2

CASO 3: ENVIAR PAQUETE FUERA (OFPT_PACKET_OUT).

El controlador envía un OFPT_PACKET_OUT a través de su puerto de salida, el switch lo recibe e imprime la información en pantalla.

39

Figura 30. Captura de pantalla caso 3

CASO 4: CONTROLLER REQUEST Y SWITCH REPLY.

Caso 4.1: OFPT_FEATURES_REQUEST Y OFPT_FEATURES_REPLY.

40

Caso 4.2: OFPT_GET_CONFIG_REQUEST y OFPT_GET_CONFIG_REPLY.

Figura 32. Captura de pantalla caso 4.2 Caso 4.3: OFPT_SET_CONFIG.

41

Caso 4.4: OFPT_STATS_REQUEST y OFPT_STATS_REPLY.

Figura 34. Captura de pantalla caso 4.4

Caso 4.5: OFPT_BARRIER_REQUEST y OFPT_BARRIER_REPLY.

Caso 4.6: OFPT_QUEUE_GET_CONFIG_REQUEST y OFPT_QUEUE_GET_CONFIG_REPLY.

En estos dos casos 4.5 y 4.6 el flujo del request y reply correspondiente es el mismo que para los casos anteriores validados, por ciertos inconvenientes a la hora de simularlos, y por falta de tiempo estos dos mensajes no se pudieron validar, solo faltaría crear las estructuras de los mensajes.

CASO 5: MENSAJES DE MODIFICACIÓN DE ESTADO. Caso 5.1: OFPT_FLOW_MOD.

42

Figura 35. Captura de pantalla caso 5.1

Caso 5.2: OFPT_FLOW_REMOVED.

43

CASO 6: MODIFICACIÓN DEL PUERTO (OFPT_PORT_MOD).

Figura 37. Captura de pantalla caso 6

CASO 7: ESTADO DE LOS PUERTOS (OFPT_PORT_STATUS).

44 CASO 8: PAQUETE ENTRANTE (OFPT_PACKET_IN).

45

CONCLUSIONES

En base a la especificación de OpenFlow V1.0.0 elaborada por Open Networking Foundation (ONF) en el año 2009, se planeó simular el envío y recepción de los mensajes que componen el protocolo, a través de la herramienta Opnet Modeler®. Para realizar este trabajo se comenzó con la creación y posterior explicación de las máquinas de estados para el protocolo Openflow, las cuales son un aporte muy importante en este trabajo. La primera máquina es la encargada de explicar el tratamiento que le da un Switch Ideal OpenFlow a los paquetes entrantes a este mediante la metodología SDN, las otras dos máquinas que se crearon fueron la del controlador y la del switch, las cuales explican completamente el intercambio de mensajes entre el switch y el controlador.

También cabe resaltar los diagramas de secuencia que se realizaron antes de entrar a diseñar las dos máquinas de estado switch y controlador.

Un segundo punto que se abordó en este trabajo fue el aprendizaje que se tuvo del simulador Opnet Modeler®. Para poder lograr a cabo la implementación y posterior simulación del módulo de comunicaciones para el protocolo OpenFlow, se trabajaron conceptos básicos de programación en C++, y la manera como Opnet permite simular diferentes escenarios de networking a través de la jerarquización en diferentes etapas de diseño, como son: Modelo de Red, ahí encontramos el nodo que representa el módulo de comunicaciones OpenFlow, el cual puede ser utilizado para desarrollos posteriores basados en OpenFlow, SDN, simulados bajo Opnet Modeler® y que se trabajen en el entorno de Simulación SMARNET liderado por el Ing. Gustavo Rodríguez. Los otros dos modelos el de nodo y el de procesos más específicamente permitirán a futuros estudiantes o ingenieros hacer cambios en la programación C++ base del módulo.

Por último se logró llevar a cabo una validación de las estructuras de los mensajes definidos en la especificación, a través de la simulación y posterior print en consola de cada una de las secuencias de mensajes utilizados por OpenFlow.

Creó que se logró de manera satisfactoria cada uno de los objetivos definidos desde un principio tanto el general, como los específicos, en estos últimos hubo un cambio, relacionado en cuanto a las interfaces de programación, no se desarrolló un API como tal, sino gracias a las herramientas del simulador este objetivo era más viable y práctico de desarrollar con solo documentar y explicar cada una de las interfaces gráficas que ofrece Opnet Modeler® para facilitar la asignación de atributos globales y específicos que permitieran controlar la secuencia de mensajes.

46

COSTOS Y FUENTES DE FINANCIACIÓN.

TABLA DE COSTOS DEL PROYECTO RECURSOS

TÉCNICOS

ITEM CANTIDAD DESCRIPCIÓN VALOR HORA VALOR TOTAL

Computadora personal 1 Procesador Intel (R) Core (TM) i3 CPU M370 @ 2.4 GHz 2.4 GHz, Una Memoria RAM de 4 G, Sistema Operativo de 32 bits con Windows 7 Professional.

$ 800.000

Licencia de uso

simulador 1

Licencia de uso para el Software de Simulación OPNET

Modeler ® 14.5. $ 2.000.000

Papelería

Impresión Informe Final, Proyecto y anteproyecto $ 50.000

Gastos de energía Luz y energía utilizada por el PC $ 90.000 RECURSOS

HUMANOS

Ing. Gustavo Ramírez 48 Asesorías y revisión de escritos del proyecto e informe final.

$ 180.000 $ 8.640.000

Est. Douglas Aguacía 248

Trabajo de investigación e Implementación de un módulo de comunicaciones OpenFlow V.1.0.0 sobre un modelo de proceso dentro del software de simulación OPNET Modeler®.

$ 25.000 $ 6.200.000

COSTO TOTAL DEL PROYECTO $ 17.780.000

Tabla 2 Costos Proyecto De Grado.

47

BIBLIOGRAFÍA Y FUENTES DE INFORMACIÓN.

[1] https://www.opennetworking.org/

[2]http://www.sdncentral.com/

[3] LU, ZHENG. YANG, HONGJI. Unlocking the Power of OPNET modeler. Estados Unidos: Cambridge University Press, 2012.

[4] OPEN NETWORK FOUNDATION, OpenFlow Switch specification Version 1.0.0. [En línea]. [Consulta: 04-09-2013]. Disponible en: http://archive.openflow.org/documents/openflow-spec-v1.0.0.pdf . [5]BJØRN R. MARTINUSSEN.Introduction toSoftware Defined Networks (SDN)and its relevance in the

DC. [En línea]. [Consulta: 01-09-2013]. Disponible en:

http://www.cisco.com/web/europe/ciscoconnect2013/pdf/DC_3_SDN.pdf.

[6] NETWORKWORLD. OpenFlow permite crear networking definido por software.[En línea]. [Última Consulta: 15-08-2013]. Disponible en:

http://www.networkworld.es/actualidad/openflow-permite-

crear-networking-definido-por-software

[7]MCKEOWN NICK, ANDERSON TOM, BALAKRISHNAN HARI, PARULKAR GURU, PETERSON LARRY, REXFORD JENNIFER, SHENKER SCOTT and TURNER JONATHAN. OpenFlow: Enabling Innovation in Campus Networks. [En línea]. [ÚltimaConsulta: 03-10-2013]. Disponible en: http://archive.openflow.org//documents/openflow-wp-latest.pdf.

[8] RAMÍREZ GUSTAVO. Presentación en diapositivas OPNET. Colombia: Pontificia Universidad Javeriana, 2009.

[9] DEPARTAMENTO DE INGENIERÍA Y TELEMÁTICA DE LA UNIVERSIDAD POLITÉCNICA DE CATALUÑA. OPNET: Manual del usuario. [En línea]. [Última Consulta: 10-01-2014]. Disponible en:

https://www.opnet.com/university_program/teaching_with_opnet/textbooks_and_materials/materials/OPN ET_Modeler_Manual.pdf

[10] ADELE E. HOWE and GABRIEL SOMLO. Modeling Discrete Event Sequences as State Transition Diagrams. [En línea]. [Última Consulta: 14-01-2014]. Disponible en:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.124.9701&rep=rep1&type=pdf

[11] http://www.opnet.com

[12] http://es.wikipedia.org/wiki/Openflow

[13] http://es.wikipedia.org/wiki/Red_de_telecomunicaci%C3%B3n

48 ANEXOS

En los siguientes anexos encontrarán (Ver CD_ROM contraportada): los programas fuente desarrollados, debidamente documentados, tanto para el modelo de proceso que representa al controlador como para el Switch, los packet format creados para la transmisión de cada uno de los mensajes y la librería.h, todo dentro de una carpeta llamada tesis.

El instalador y licencias requeridas para OpnetModeler® fueron suministradas por la Universidad, por lo tanto no se pudieron incluir dentro de los anexos.