EVALUACIÓN Y ANÁLISIS DEL RENDIMIENTO DE UNA RED DE …

1

EVALUACIÓN Y ANÁLISIS DEL RENDIMIENTO DE UNA

RED DE ÁREA EXTENSA DEFINIDA POR SOFTWARE

Santiago Ochoa Velásquez & Jhonnatan Felipe Sánchez Cortes

Director: Gustavo Adolfo Puerto Leguizamon

2020

Universidad Distrital Francisco José de Caldas

Facultad de ingeniería

Ingeniería Electrónica

2

Tabla de contenido

Lista de figuras .................................................................................................................. 4

I. Introducción ................................................................................................................ 8

Planteamiento del problema .............................................................................................. 8

Justificación ..................................................................................................................... 10

Objetivos .......................................................................................................................... 11

1.1. General .............................................................................................................. 11

1.2. Específicos ........................................................................................................ 11

II. Estado del arte ......................................................................................................... 12

III. Marco conceptual ..................................................................................................... 20

3.1. Parámetros de QoS ........................................................................................... 20

3.1.1. Soluciones QoS .......................................................................................... 20

3.1.2. Retardo ....................................................................................................... 23

3.1.3. Jitter ........................................................................................................... 26

3.1.4. Pérdida de paquetes ................................................................................... 31

3.1.1. Throughput ................................................................................................. 33

3.2. Software Defined Network (SDN) ...................................................................... 34

3.2.1. Características ............................................................................................ 37

3.2.2. Funcionamiento de una red SDN ................................................................ 40

3.2.3. Plano de datos ............................................................................................ 41

3.2.4. Plano de control .......................................................................................... 43

3.2.5. Aplicaciones ............................................................................................... 45

3.3. Red WAN .......................................................................................................... 48

3.3.1. Características ............................................................................................ 48

3.3.2. Protocolos de una red WAN ....................................................................... 49

3.3.3. Tipos de redes WAN ................................................................................... 50

3.3.4. MPLS ......................................................................................................... 50

3.3.5. Topologías .................................................................................................. 51

3.3.6. Problemática en las WAN empresariales tradicionales ............................... 56

IV. Plataformas y complementos .................................................................................... 57

4.1. Instalación de mininet ........................................................................................ 62

3

4.2. Instalación de ONOS ......................................................................................... 64

V. Definición y evaluación de escenarios ...................................................................... 70

5.1. Red SDWAN ...................................................................................................... 73

5.2. Red WAN .......................................................................................................... 92

5.3. Comparación entre la Red SDWAN y la Red WAN .......................................... 104

Conclusiones ................................................................................................................. 114

Referencias ................................................................................................................... 116

Anexos .......................................................................................................................... 119

4

Lista de figuras

Figura 1. Enrutamiento ECMP vs enrutamiento OpenFlow SDN [34]. .............................................................. 12

Figura 2. Resultados de prueba escalabilidad [35]. .......................................................................................... 13

Figura 3. Clasificación basada en cola en Open vSwitch, [36]. ......................................................................... 13

Figura 4. Resultados del retraso en múltiples flujos TCP [37]. .......................................................................... 14

Figura 5. Adaptación de muestreo para diferentes usos de ancho de banda [38]. .......................................... 15

Figura 6. Tiempo de respuesta del servidor [39]. ............................................................................................. 16

Figura 7. Escenario de prueba [40]. .................................................................................................................. 16

Figura 8. Comparación de rendimiento del enfoque de reserva de ancho de banda: escenarios basados en el

flujo y usuario, segundo y cuarto escenario [41]. ............................................................................................. 17

Figura 9. Flujo de paquetes [42]. ...................................................................................................................... 18

Figura 10. Tiempo de computación en función del número de switches [43]. ................................................. 19

Figura 11. Señalamiento RSVP [9]. ................................................................................................................... 21

Figura 12. Encabezado IPv4 [9]. ....................................................................................................................... 22

Figura 13. Diferencia entre retardo instantáneo y retardo promedio [13]. ..................................................... 26

Figura 14. Diagrama de tiempos para paquetes recibidos [14]. ...................................................................... 27

Figura 15. Supervivencia apropiada del del jiter [17] ....................................................................................... 29

Figura 16. Histograma normalizado de Alpha [17]. ......................................................................................... 30

Figura 17. Dispersión del jitter (𝛾) vs número de saltos (hop) (17] ................................................................. 31

Figura 18. Modelo combinado Markov run-length [6]. .................................................................................... 33

Figura 19. Organograma de ONF [19]. ............................................................................................................. 36

Figura 20. Arquitectura de capas SDN general aprobada [2]. .......................................................................... 37

Figura 21. Componente del dispositivo tradicional y estructura SDN [24] ....................................................... 38

Figura 22. Descripción general del funcionamiento de una red SDN [21] ........................................................ 41

Figura 23. Switch OpenFlow [24] ...................................................................................................................... 42

Figura 24. Dispositivo SDN/OpenFlow [24] ...................................................................................................... 43

Figura 25. Estructura del controlador SDN [21]. ............................................................................................... 44

Figura 26. Diseño de una aplicación reactiva [23]. ........................................................................................... 46

Figura 27. Diseño de una aplicación proactiva [23]. ........................................................................................ 47

Figura 28. Aplicaciones internas vs externas [23]. ........................................................................................... 48

Figura 29. Red WAN [29]. ................................................................................................................................. 49

Figura 30. Topología punto a punto. ................................................................................................................ 52

Figura 31. Topología de malla completa. ......................................................................................................... 53

Figura 32. Topología de bus. ............................................................................................................................ 54

Figura 33. Topología de bus. ............................................................................................................................ 55

Figura 34. Topología en anillo. ......................................................................................................................... 56

Figura 35. Actualización del sistema. ............................................................................................................... 58

Figura 36. Instalación de Common. .................................................................................................................. 58

Figura 37. Instalación de java. .......................................................................................................................... 58

Figura 38. Instalación de jdk. ............................................................................................................................ 59

Figura 39. Versión de java. ............................................................................................................................... 59

Figura 40. Configuración JAVA HOME. ............................................................................................................. 59

Figura 41. Configuración JAVA HOME. ............................................................................................................. 59

5

Figura 42. Instalación de Maven. ..................................................................................................................... 60

Figura 43. Versión de Maven. ........................................................................................................................... 60

Figura 44. Descarga de karaf............................................................................................................................ 61

Figura 45. Descomprimiendo karaf. ................................................................................................................. 61

Figura 46. Instalación de git-core. .................................................................................................................... 61

Figura 47. Instalación de net-tools. .................................................................................................................. 62

Figura 48. Instalación de git. ............................................................................................................................ 62

Figura 49. Clonando mininet. ........................................................................................................................... 63

Figura 50. Selección del git. .............................................................................................................................. 63

Figura 51. Instalación de mininet y sus complementos. ................................................................................... 63

Figura 52. Red predeterminada de mininet. ..................................................................................................... 64

Figura 53. Comandos de conexión en mininet. ................................................................................................. 64

.......................................................................................................................................................................... 65

Figura 54. Instalación python-minimal. ............................................................................................................ 65

Figura 55. Creando usuario. ............................................................................................................................. 65

Figura 56. Carpeta para onos. .......................................................................................................................... 65

Figura 57. Obtención del url para descargar ONOS.......................................................................................... 66

Figura 58. Descargara de ONOS. ...................................................................................................................... 66

Figura 59. Descomprimir ONOS. ....................................................................................................................... 67

Figura 60. Otorgando permisos para trabajar en ONOS. ................................................................................. 67

Figura 61. Archivo para instalar aplicaciones de ONOS. .................................................................................. 67

Figura 62. Configurando e instalando ONOS. ................................................................................................... 68

Figura 63. Inicialización de ONOS. .................................................................................................................... 68

Figura 64. Status de ONOS. .............................................................................................................................. 68

Figura 65. Terminal de ONOS. .......................................................................................................................... 69

Figura 66. Login página web de ONOS. ............................................................................................................ 70

Figura 67. Página web de ONOS. ...................................................................................................................... 70

Figura 68. Comando para crear topología de árbol con controlador. .............................................................. 71

Figura 69. Topología de árbol con controlador. ............................................................................................... 71

Figura 70. Conectividad entre los hosts. ........................................................................................................... 71

Figura 71. Activación de la aplicación org.onosproject.fwd. ........................................................................... 72

Figura 72. Conectividad entre los hosts. ........................................................................................................... 72

Figura 73. Topología vista desde el controlador. ............................................................................................. 73

Figura 74. Red SDWAN. .................................................................................................................................... 74

Figura 75. Comando para crear la red personalizada. ..................................................................................... 74

Figura 76. Red personalizada. .......................................................................................................................... 75

Figura 77. Tabla de conmutación generada por ONOS para el switch 1. ......................................................... 76

Figura 78. Comando para ingresar a los hosts de la red. ................................................................................. 76

Figura 79. configuración del host servidor TCP. ............................................................................................... 76

Figura 80. Petición del host cliente. .................................................................................................................. 77

Figura 81. Datos de la prueba. ......................................................................................................................... 77

Figura 82. Throughput TCP links con 50 𝜇𝑠 de delay. ....................................................................................... 78

Figura 83. Throughput TCP links con 100 𝜇𝑠 de delay. ..................................................................................... 79


Figura 85. Throughput TCP. .............................................................................................................................. 80

6

Figura 86. Configuración del host servidor. ...................................................................................................... 80

Figura 87. Petición del host cliente. .................................................................................................................. 80

Figura 88. Datos de la prueba. ......................................................................................................................... 81

Figura 89. Throughput UDP enviando 10 Mbit/s. ............................................................................................. 82

Figura 90. Jitter enviando 10 Mbit/s. ............................................................................................................... 82

Figura 91. Packet loss enviando 10 Mbit/s. ...................................................................................................... 83

Figura 92. Throughput UDP enviando 50 Mbit/s. ............................................................................................. 83

Figura 93. Jitter enviando 50 Mbit/s. ............................................................................................................... 84

Figura 94. Packet loss enviando 50 Mbit/s. ...................................................................................................... 84

Figura 95. Throughput UDP enviando 100 Mbit/s. ........................................................................................... 85

Figura 96. Jitter enviando 100 Mbit/s. ............................................................................................................. 85

Figura 97. Packet loss enviando 100 Mbit/s. .................................................................................................... 86



Figura 100. Packet loss enviando 150 Mbit/s. .................................................................................................. 87

Figura 101. Throughput UDP. ........................................................................................................................... 88

Figura 102. Jitter. .............................................................................................................................................. 88

Figura 103. Packet loss. .................................................................................................................................... 89

Figura 104. Ruta más eficiente entre el host 4 al host 3. ................................................................................. 90

Figura 105. Ruta después del fallo entre el host 4 al host 3. ............................................................................ 91

Figura 106. Tiempo de recuperación con controlador. ..................................................................................... 92

Figura 107. Comando para crear la red personalizada sin controlador. .......................................................... 92

Figura 108. Red WAN personalizada. ............................................................................................................... 92

Figura 109. Conectividad fallida en la red. ....................................................................................................... 93

Figura 110. Activación de los switch de forma manual. ................................................................................... 93

Figura 11.1 Conectividad correcta en la red. .................................................................................................... 94


Figura 113. Throughput TCP links con 100 𝜇𝑠 de delay. ................................................................................... 95

Figura 114. Throughput TCP links con 200 𝜇𝑠 de delay. ................................................................................... 95

Figura 115. Throughput TCP. ............................................................................................................................ 96







Figura 122. Throughput UDP enviando 100 Mbit/s. ......................................................................................... 99

Figura 123. Jitter enviando 100 Mbit/s. ......................................................................................................... 100

Figura 124. Packet loss enviando 100 Mbit/s. ................................................................................................ 100

Figura 125. Throughput UDP enviando 150 Mbit/s. ....................................................................................... 101



Figura 128. Throughput UDP. ......................................................................................................................... 102

Figura 129. Jitter. ............................................................................................................................................ 103

Figura 130. Packet loss. .................................................................................................................................. 103

7

Figura 131. Tiempo de recuperación sin controlador. .................................................................................... 104

Figura 132. Comparación throughput TCP links con 50 𝜇𝑠 de delay. ............................................................. 105

Figura 133. Comparación throughput TCP links con 100 𝜇𝑠 de delay. ........................................................... 105

Figura 134. Comparación throughput TCP links con 200 𝜇𝑠 de delay. ........................................................... 106


Figura 136. Jitter enviando 10 Mbit/s. ........................................................................................................... 107



Figura 139. Jitter enviando 50 Mbit/s. ........................................................................................................... 108








8

I. Introducción

Planteamiento del problema

El poder cumplir con los requerimientos de telecomunicaciones del público a nivel

mundial es imposible con las redes tradicionales, debido a que los departamentos de IT en

las diferentes empresas y proveedores de servicios gastan gran parte de sus recursos en

tratar de aprovechar al máximo sus redes. Sin embargo, la solución solo es temporal, ya

que por las limitaciones de las redes actuales tanto en hardware como en software no

pueden abarcar los requerimientos de los usuarios, empresas y proveedor [1].

Las redes de WAN tradicionales ya se están quedando obsoletas debido a que su

estructura es estática e inflexible, todo debido a que el hardware sobre el cual están

constituidas requiere reconfiguraciones cada vez que se hace un cambio en la red, esto a

nivel de grandes redes involucra grandes costos y un alto grado de procesamiento en los

nodos de la red. Además, desde el punto de vista de seguridad, los ciberdelincuentes ya

conocen el funcionamiento de una red WAN y por tanto este tipo de red se ve amenazado

frecuentemente por ataques automatizados y sofisticados, esto implica un gran peligro para

los negocios y organizaciones que cada día están más conectados directamente a internet,

por tanto, su nivel de exposición aumenta. Al tiempo, el tráfico total en una red distribuida

está en un 50% encriptado, se espera que este valor llegue al 80% en un futuro cercano, al

igual que se espera que aumente el malware dirigido al tráfico SSL, por lo que es necesario

un método de inspección SSL en tiempo real sin ralentizar el tráfico de la empresa [2].

El método ideado para resolver todos los anteriores problemas son las redes

definidas por software (SDN en ingles Software Defined Netwroking) ya que al centrarse

alrededor de la API de Openflow y junto con otros protocolos podrán potencialmente

satisfacer las necesidades de telecomunicaciones de la sociedad actual. Las redes SDN

constan con rentabilidad, adaptabilidad, dinamismo y manejabilidad que hacen que sea una

solución adecuada para la naturaleza de alto consumo y siempre cambiante de ancho de

banda de las aplicaciones modernas. Además, ofrece un mejoramiento de la red sin tener

que cambiar el hardware actualmente en uso. Con la adición de los controladores SDN será

posible reutilizar el hardware actual y controlarlo de forma centralizada desde el controlador

SDN, ahorrando así costos incalculables a nivel mundial por la gran cantidad de equipos

que se encuentran hoy en día en la red [3].

El elevado grado de aceptación de SDN en el mercado no es casualidad, ya que

muchos de los problemas que se han encontrado a la hora de diseñar y operar las redes

WAN se ven resueltos, lo que representa un ahorro de capital, tiempo y una mayor

flexibilidad a la hora de adaptarse a las necesidades del negocio. Una de las mayores

ventajas es la distribución del tráfico, ya que este usa los diversos enlaces disponibles

respondiendo a criterios del negocio o la aplicación, dejando de lado las reglas de

9

enrutamiento IP permitiendo así una gestión y adaptabilidad más flexible y sencilla en

comparación con una red tradicional [4].

Aun con las grandes ventajas que ofrece SDN , en el año 2016 solo el 1% de las

empresas utilizaba soluciones de redes de área extensa definidas por software (SD-WAN),

Gartner (empresa consultora de investigación de las tecnologías de la información) estima

un crecimiento del más del 30% para el año 2019 [5], y es que la implementación de SDN

es lucrativa tanto para las empresas como a los que la implementan, según un informe de

IDC (International Data Corporation) las ventas de SD-WAN se aproximaron a los 1,4 mil

millones de dólares en 2017 y se espera un aumento de casi el doble para el año 2018 [2].

Pero el cambio de una arquitectura de red a otra supone oposición por temas

económicos, de tiempo y de rentabilidad, además de ser relativamente nueva no hay mucho

conocimiento de ella y sus ventajas, entonces, ¿las redes definidas por software SDN

realmente ofrecen un aumento en el rendimiento tanto para los clientes como para los que

las administran? Y de ser así, ¿en qué porcentaje es mejorado?

10

Justificación

Este trabajo tiene como objetivo principal generar un impacto académico derivado

de un proceso investigativo, al evaluar el rendimiento en sistema de red de área extensa

definidas por software (SD-WAN), respecto a las redes de área local extensa (WAN)

actuales. Esto es necesario debido a que la implementación de redes SDN tienen como

una de sus características principales, la flexibilidad lo cual permite que se adapten a cada

momento a sus necesidades, permitiendo el crecimiento exponencial de las redes sin

necesidad de cambiar los elementos actuales. Uno de los grandes problemas de las redes

tradicionales es la dependencia a la infraestructura estática que es inflexible, debido a su

dependencia al hardware, que necesita reconfigurarse para cualquier cambio en la red,

generando una constante actualización a los equipos provocando un gran problema

ambiental por la constante basura electrónica generada.

En el ámbito económico, al realizar simulaciones comparativas entre los sistemas

SD-WAN y WAN actual, se podrá evidenciar los parámetros principales de calidad de

servicio (QoS) reduciendo el tiempo y el costo de las pruebas físicas. La reducción de costos

a largo plazo que implica la implementación de un sistema SD-WAN, supera por mucho los

gastos que se tendría que hacer para actualizar una red WAN, siendo así una alternativa

viable para darle solución a los problemas que se presentan actualmente por la constante

alza a los requerimientos exigidos a la red por los usuarios.

Es importante tener en cuenta todos los conocimientos adquiridos de telemática a

lo largo de nuestra carrera, para así tener la base con la que se analizarán las redes

actuales basadas en IP y las redes SD-WAN y tener criterios de comparación entre ellas.

Además, es necesario tener bases de programación para aprovechar al máximo el uso del

software libre Linux y Mininet con los cuales se desarrollará el proyecto. Linux es de vital

importancia, al ser un sistema operativo libre es muy robusto, estable y rápido, lo que lo

hace el sistema operativo (SO) ideal para servidores y aplicaciones, además de tener

muchas herramientas flexibles que permiten un uso más enfocado a las necesidades

específicas que se presentan [6], ejemplo de una de estas herramientas es la aplicación de

Mininet, software libre que permite la implementación de distintas topologías de redes y la

simulación de las mismas, además de poder conectar la topología construida a redes

externas para así poder obtener datos reales en sus resultados [7] .

Al saber la importancia de las redes SD-WAN y todas las ventajas que implicaría su

implementación, nos es de interés llevar esto a una verificación que permita dar a conocer

a qué aspectos en la calidad de servicio (QoS) mejora esta red, y con ello tener una base

teórica para que las empresas y demás instituciones públicas y privadas conozcan este tipo

de redes y vean la viabilidad de su implementación.

11

Objetivos

1.1. General

Evaluar y analizar el rendimiento de una red de área extensa definida por software.

1.2. Específicos

1. Identificar los principales parámetros de QoS en las redes IP actuales.

2. Reconocer las características de las redes definidas por software y los controladores

que permiten definir su plano de control.

3. Determinar un escenario de prueba para una red de área extensa definida por

software.

4. Evaluar mediante simulación parámetros de calidad de servicio de una red de área

extensa definida por software y contrastarlos con los generados por una red IP actual.

12

II. Estado del arte

Con el gran avance de los centros de datos de las estaciones de generación de energía,

ha avanzado en gran medida el flujo de datos que el centro de redes tiene que procesar,

por lo que usar una alternativa que aproveche la infraestructura existente es de vital

importancia. En el documento Design and Implementation of SDN-Base QoS Traffic Control

Method for Electric Power Data Center Network se implementa una topologia en árbol, se

utilizan dos métodos de enrutamiento, ECMP y el utlizado por OpenFlow, para dar solución

a este problema [34]. Se compararon tres aspectos del QoS de la red implementada con

los dos algoritmos de enrutamiento; rendimiento de los enlaces a lo largo del tiempo, el

tiempo de retraso y porcentaje de perdida de paquetes a medida que aumenta la carga de

la red. Como resultado de la prueba se demostró la mejora que presentan las redes en las

que se ha implementado SDN [34].

Figura 1. Enrutamiento ECMP vs enrutamiento OpenFlow SDN [34].

El paradigma SDN teóricamente es una muy buena alternativa para satisfacer los

requerimientos de las redes actuales, pero su implementación es costosa, ocasionando que

los investigadores recurran a herramientas de simulación que permita la experimentación

con este paradigma [35]. Mininet es un sistema que permite crear rápidamente prototipos

de redes en un entorno virtual. Algunas de las características generales son la flexibilidad,

aplicabilidad, interactividad, escalabilidad, el realismo y que permite que su contenido sea

compartible. En el documento Using Mininet for Emulation and Prototyping Software-

Defined Networks se hace uso del software Mininet para simular una red SDN y evaluar el

comportamiento y funcionalidad de Mininet. Después de varias pruebas, se llega a la

conclusión de aun con las limitaciones de una simulación, Mininet es una muy buena

13

herramienta para la simulación de redes SDN, por ello más de 18 instituciones alrededor

del mundo lo usan para sus investigaciones, instituciones como Princeton, Berkeley,

Purdue, NASA, Stanford, Deutsche Telekon Labs, entre muchas otras. En la siguiente figura

se muestra algunos de sus resultados [35].

Figura 2. Resultados de prueba escalabilidad [35].

Los flujos elefantes (Elephant flows) en los centros de datos de redes tienden a utilizar

gran parte del ancho de banda de un enlace, dejando en cola los paquetes sensibles a la

latencia. Esto causa un deterioro en los servicios prestados, las redes SDN al permitir una

visualización de toda la red es capaz de detectar los flujos elefantes, y así tomar las

decisiones adecuadas en tiempo real para garantizar QoS. En el documento Visualization

of Elephant Flows and QoS Provisioning in SDN-Based Networks abordan este problema

usando Mininet y la técnica de colas (queuing technique) de Open vSwitch, protocolo

incluido en el estándar OpenFlow de las redes SDN. Este protocolo permite clasificar los

paquetes entrantes al puerto de un switch, asignándoles un máximo de ancho de banda del

enlace para poder transmitirse, limitando así los flujos elefantes para que no ocupen todo

el canal, además de tener la posibilidad de ver el flujo de datos del switch por cada

clasificación programada. En el paper se mostró como detectar los flujos elefante y

procesarlos utilizando técnicas de QoS definidas por las especificaciones ofrecida por el

estándar OpenFlow de las redes SDN, en la siguiente figura se ve la clasificación del flujo

en Open vSwitch y su respectiva visualización de flujos elefante [36].

Figura 3. Clasificación basada en cola en Open vSwitch, [36].

14

El tiempo de retardo siempre ha sido un aspecto fundamental para la calidad de los

servicios prestados en las diferentes redes, en el paper Towards SDN Based Queuing Delay

Estimation se propone un modelo para la estimación del retardo en las colas en un solo

enlace, para luego extenderlo a un modelo de extremo a extremo. El modelo estimado es

implementado en el software Mininet, optando por el controlador SDN Floodlight, un

controlador de código abierto basado en java de fácil manejo. Gracias a la versatilidad de

Mininet, el modelo estimado es posible implementarlo mediante código sobre la red e

implementar un control dinámico de retardo, dando como resultado ser un método eficiente

[37].

Figura 4. Resultados del retraso en múltiples flujos TCP [37].

Aunque OpenFlow siendo el estándar que causo que las redes SDN tomaran fuerza en

el ámbito de desarrollo como de investigación, este no tiene muy buenas herramientas para

el monitorio del flujo de paquetes en un switch determinado, en la conferencia MonSamp:

A Distributed SDN Application for QoS Monitoring abarcan este problema analizando los

aspectos QoS en las redes SDN, y basados en eso plantean una arquitectura con la cual

se basan para la creación de la aplicación de monitoreo. Las pruebas del prototipo de la

aplicación fueron hechas sobre Mininet, dando como resultado una aplicación escalable y

rentable al estar soportada en el Northbound del controlador SDN, esto a su vez permite

que la aplicación pueda servir de base para otras aplicaciones, como aquellas que

necesiten el estado del flujo de paquetes en un switch dado, el prototipo se planea utilizar

en escenarios reales [38].

15

Figura 5. Adaptación de muestreo para diferentes usos de ancho de banda [38].

La arquitectura de internet actual hace su “mejor esfuerzo” en sus servicios, pero no

puede garantizar QoS todo el tiempo, aunque la IETF (Internet Engineering Task Force) ha

explorado varias soluciones a lo largo de los años, como lo son IntServ y Diffserv, pero

ninguna ha sido implementada con éxito de forma global. HiQoS es una aplicación

propuesta en la publicación HiQoS: An SDN-Based Multipath QoS Solution, esta aplicación

para redes SDN garantiza parámetros QoS, esta hace uso de multiples caminos entre la

fuente y el destino, además de usar diferentes mecanismos de colas para diferentes tipos

de tráfico. Se utilizo Mininet como plataforma de simulación para esta aplicación basada en

la tecnología de OpenFlow. HiQoS garantiza ancho de banda, y aplica enrutamiento de

multiples rutas para hacer uso de la capacidad disponible en la red. En la siguiente figura

vemos el resultado del tiempo de respuesta de un servidor, este es comparado con el

tiempo de respuesta de otras dos aplicaciones con diferentes características, las cuales son

LiQoS y MiQoS [39].

16

Figura 6. Tiempo de respuesta del servidor [39].

Aun cuando SDN es una muy buena solución a los problemas actuales de las redes IP,

la migración de un paradigma a otro es compleja, teniendo en cuenta el nivel de complejidad

y tamaño de las redes actuales, una implementación total de SDN en todas las redes es

imposible, lo que significa que gran parte de las redes serán hibridas, es decir, redes SDN

se comunicaran con redes no-SDN. El paper QoS Guarantee over Hybrid SDN/non-SDN

Networks aborda este problema para redes WAN, en donde se presentarán los dos tipos

de redes, y presenta una solución especifica utilizando la extensión de Border Gateway

Protocol (BGP) denominada BGP-LS en donde se extrae el estado del enlace, esto en

conjunto de Path Computation Element Communication Protocol (PCEP) serán los

protocolos base del controlador OpenDaylight, con el cual se controla la comunicación entre

las redes. El resultado de la simulación del algoritmo es la confirmación de la utilidad de un

controlador SDN, dando una mejora de hasta el 60% cuando el controlador está trabajando

en la red, demostrando así la utilidad de las redes SDN [40]. En la figura se observa el

escenario utilizado en las simulaciones.

Figura 7. Escenario de prueba [40].

Aun cuando varios investigadores han creado varias arquitecturas para el cumplimiento

de los diferentes parámetros del QoS en redes SDN, como lo son InServ y DiffServ, estos

17

no solucionan de todo el problema, ya que en escenarios de grandes redes su rendimiento

no está a la altura, llegando a tener bajo rendimiento en aplicaciones de transmisión de

video, debido a que sus estrategias de enrutamiento distribuido no tienen en cuenta los

recursos globales de la red. En el paper Bandwidth Reservation Approach to Improve

Quality of Service in Software-Defined Networking: A Performance Analysis se propone un

modelo del sistema el cual reserva segmentos del ancho de banda de los enlaces según el

flujo y la prioridad del usuario, sobre paquetes TCP y UDP. Este modelo da muy buenos

resultados cuando son pocos los usuarios finales quienes exigen un ancho de banda

reservado, pero cuando se manejan dos tipos de flujo de datos, TCP y UDP, y se le da

prioridad al tráfico UDP, este mismo impacta negativamente el rendimiento alcanzable del

otro tipo de tráfico [41].

Figura 8. Comparación de rendimiento del enfoque de reserva de ancho de banda: escenarios basados en el flujo y usuario, segundo y cuarto escenario [41].

Cuando un paquete de datos llega por primera vez a un nodo (nodo se refiere al plano

de datos) de una red SDN, este es analizado según las reglas de flujo actualmente en el

18

switch, si no hay reglas para ese tipo de paquete, el switch espera instrucciones del

controlador para luego si reenviar el paquete de datos. Debido a este proceso el sistema

puede generar un tiempo de retraso que se ve reflejado en el QoS de la red. El paper QoS

Enhancement using Embedded Agent in OplenFlow based SDN Node, propone un

algoritmo que permite al switch reducir el número de veces que consulta al controlador,

reduciendo el tiempo de retraso generado por este proceso, presentando una mejora del

66.6% en la carga del controlador, mejorando así el tiempo de retraso en la red y reduciendo

la perdida de paquetes [42].

Figura 9. Flujo de paquetes [42].

Una de las características más importantes de las redes SDN es la posibilidad de tener

una visión global de toda la red, pero este proceso implica que el controlador procese toda

esa información, lo que puede llegar a consumir los recursos físicos del mismo y afectar su

tiempo de respuesta. En el paper A Parsimonious Monitoring Approach for Link Bandwidth

Estimation within SDN-based Networks, se propone un método en el que el controlador solo

consulte el estado de la red a los switch clave que la componen, para ello abordan el

problema como una cobertura de vértices, y utilizando un método heurístico se implementa

el algoritmo resultante como un módulo del controlador Floodlight en el software Mininet,

reduciendo los tiempos de procesamiento del controlador como se observa en la siguiente

figura [43].

19

Figura 10. Tiempo de computación en función del número de switches [43].

20

III. Marco conceptual

3.1. Parámetros de QoS

Calidad de servicios (Qos) son parámetros para estandarizar el rendimiento de las redes

en términos de niveles de servicio que la red ofrece. QoS es de vital importancia en

aplicaciones de transmisión multimedia. Garantiza un cierto nivel de rendimiento al flujo de

datos que pasa sobre la red, usando técnicas de transmisión de datos y protocolos que

permiten a la red entregar de manera satisfactoria priorización de conmutación, ancho de

banda, rendimiento entre otros [8].

Al incorporar QoS sobre la red se priorizan los paquetes dependiendo de la urgencia de

envió de los mismos, que por lo general todos los paquetes provenientes de una misma

aplicación son tratados con la misma prioridad. Esta tecnología ha permitido que los

proveedores de servicio puedan soportar diferentes niveles de servicio a sus diferentes

clientes, priorizando las necesidades de cada uno y de esta garantizar un buen servicio

para todos los usuarios [8].

Las métricas de QoS típicas en las redes son el ancho de banda, tiempo de retraso, y

rendimiento. Mientras algunas aplicaciones requieren una garantía de un ancho de banda

determinado, otras exigen un tiempo de retraso satisfactoria de un extremo a otro, y otras

necesitan un rendimiento alto o la combinación de varios criterios del QoS. Aunque en la

teoría el cumplimiento de todas las métricas del QoS es lo ideal, en la práctica esto es

imposible de cumplir, debido a las diferentes limitantes del hardware [8].

3.1.1. Soluciones QoS

3.1.1.1. Integrated Services (Intserv) [9]

Intserv propone dos clases de servicio además del servicio de Mejor Esfuerzo, los

cuales son Servicio garantizado [RFC2212] y servicio de carga controlada [RFC2211] el

primero de estos funciona para aplicaciones en tiempo real que requieren un límite de

retardo mientras que el otro es utilizado en aplicaciones que requieren un servicio Best

Effort confiable y mejorado.

Este modelo consiste en que los enrutadores puedan reservar recursos para

proporcionar QoS especial para flujos de paquetes de usuarios específicos.

RSVP se inventó como un protocolo de señalización para que las aplicaciones reserven

recursos [RFC2205]. El proceso de señalización se ilustra en la Figura 1.

21

Figura 11. Señalamiento RSVP [9].

Donde se puede observar que el remitente envía un mensaje PATH al receptor

especificando las características del tráfico. Cada enrutador intermedio a lo largo de la ruta

reenvía el mensaje PATH al siguiente salto determinado por el protocolo de enrutamiento.

Al recibir un mensaje PATH, el receptor responde con un mensaje RESV para solicitar

recursos para el flujo. Cada enrutador intermedio a lo largo de la ruta puede rechazar o

aceptar la solicitud del mensaje RESV.

Intserv se implementa mediante cuatro componentes: el protocolo de señalización (por

ejemplo, RSVP), la rutina de control de admisión, el clasificador y el programador de

paquetes. Las aplicaciones que requieren un servicio garantizado o un servicio de carga

controlada deben configurar las rutas y los recursos de reserva antes de transmitir sus

datos. Las rutinas de control de admisión decidirán si se puede otorgar una solicitud de

recursos.

Intserv se caracteriza por dos propiedades:

• Confiar en la reserva de recursos y el control de admisión.

• Confiar en una cola separada y en una programación sofisticada para garantizar el

rendimiento al tiempo que permite compartir recursos.

3.1.1.2. Differentiated Services (Diffserv) [9]

Consiste en dividir el tráfico en múltiples clases y tratarlos de manera distinta,

especialmente cuando hay una escasez de recursos.

El encabezado IPv4 contiene un byte de tipo de servicio (TOS). Diffserv cambió el

nombre de byte TOS como campo de Differentiated Services (campo DS) y define su

estructura de la siguiente manera.

22

Figura 12. Encabezado IPv4 [9].

DSCP denota el tratamiento de reenvío que un paquete debe recibir, Este tratamiento

de reenvío se denomina comportamiento por salto del paquete (PHB).

Diffserv estandarizó varios grupos de PHB los principales son el PHB de reenvío

asegurado (AF) [RFC2597] y el grupo de PHB de reenvío acelerado (EF) [RFC2598]. El

cual el primero está destinado para los servicios better-than-Best-Effort, por ejemplo, una

red privada virtual o VPN mientras que el PHB de EF están destinados a servicios en tiempo

real.

Los clientes pueden marcar los campos de DS en sus paquetes para indicar el servicio

deseado o hacer que los enrutadores de borde NSP los marquen según la clasificación, los

paquetes se clasifican, vigilan y posiblemente se configuran. Las reglas de clasificación,

control y configuración utilizadas en los enrutadores de ingreso se especifican en el Acuerdo

de nivel de servicio (SLA).

Diffserv solo define los campos de DS y PHB. Es responsabilidad del NSP decidir qué

servicios proporcionar. Esto es bueno y malo, Es bueno porque le da a los NSPs la

flexibilidad de decidir qué servicios proporcionar y es malo porque esta flexibilidad causa

dificultad de interoperabilidad.

Diffserv se caracteriza por dos propiedades.

• No depender de la reserva de recursos o el control de admisión.

• Confiar en la priorización para el arbitraje de recursos.

3.1.1.3. Hybrid IntservDiffserv [9]

Es un modelo híbrido donde los operadores de red pueden utilizar Intserv en el acceso

y en el borde de la red donde el ancho de banda es más limitado y la escalabilidad es un

problema menor, y usar Diffserv en el núcleo de la red.

23

3.1.1.4. Over Provisioning [9]

Este modelo consiste en tener una excesiva capacidad para el flujo de datos, por lo cual

muy rara vez tenemos congestión de información, se espera que la red por su diseño tenga

un alto QoS. Una de sus principales características concite en usar otros mecanismos de

control de tráfico con discreción, y no confiar en la reserva de recursos o el control de

admisión.

Muchas personas piensan que esta es una forma ingenua y un tanto inútil de

proporcionar QoS. Pensarán que tal enfoque solo es factible para los que tienen un mejor

estado finacioro.

3.1.1.5. ITU/ETSI aproximación al QoS, RACS [9]

La Unión Internacional de Telecomunicaciones ([UIT]) y el Instituto Europeo de Normas

de Telecomunicaciones ([ETSI]) definieron numerosas normas relacionadas con la QoS.

Entre ellas una que destaca es el subsistema de Control de Admisión y Recursos ([RACS]).

Su función consiste en poder obtener un tratamiento prioritario para un flujo de tráfico,

enviaría una solicitud de recurso al servidor RACS del dominio loca el cual tuene la

información de utilización de recursos de la red. Según la disipación de los recursos el

servidor RACS otorgará o denegará la solicitud. Si se concede una solicitud de recurso,

entonces el servidor RACS informará a los dispositivos de la red a lo largo de la ruta para

reservar el recurso a fin de garantizar el adecuado flujo de datos.

3.1.2. Retardo

Una de las métricas más importantes del QoS en las redes es el retardo o delay, este

es generalmente medido como el tiempo que tarda un paquete en trasladarse desde el host

de inicio hasta el servidor, router o host de destino [10]. El delay consiste principalmente de

tres partes: el delay de acumulación, paquetización y de red [11].

El retardo de paquetización es introducido por las aplicaciones, como por ejemplo la

paquetización de muestras de voz, este proceso conlleva un tiempo e introduce un retardo.

El retardo de la red está definido como el tiempo desde que es enviado el primer bit del

paquete hasta que llega el ultimo bit de dicho paquete al destino, además este tipo de

retardo es dividido en tres partes: el retardo de transmisión, retardo de procesamiento de

paquetes y el retardo de propagación [10].

El retardo de transmisión es el tiempo que toma el paquete en desplazarse en el medio,

ya sean cables o señales inalámbricas, este tipo de retardo es directamente proporcional al

tipo de red por la que se esté desplazando el paquete, es decir, en links de acceso de baja

velocidad este parámetro puede llegar a ser muy alto, caso contrario sucede en redes que

cuentan con links de acceso de alta velocidad, en donde el retardo de transmisión puede

llegar a ser insignificante [10].

24

El retardo de procesamiento de paquetes es el tiempo que se toman los nodos de una

red en redirigir un paquete, este tiempo es debido a diferentes procesos, como por ejemplo

consultar las tablas de enrutamiento, entre otros [10].

El retardo de propagación es el tiempo requerido para que el paquete viaje la distancia

requerida, esto se debe a que el las señales electromagnéticas que llevan los datos no se

propagan tan rápidamente en el cobre o fibra a como lo hace en el vacio, dando como

resultado un retardo promedio de 5ms cada 1000km de distancia, esto sin contar si tramos

de la línea de comunicación utilizan métodos de transferencia de datos de forma

inalámbrica, en este caso se pueden llegar a introducir retardos adicionales a la línea de

comunicación [10].

La tercera parte que constituye el retardo en redes IP, es el retardo de acumulación, se

presenta en casos como VoIP y consiste en el tiempo que se tomado para la acumulación

de muestras de voz, estas muestras son entonces empaquetadas lo que lleva al retardo por

acumulación, es decir, se tiene que esperar un tiempo hasta que se tomen todos los datos

requeridos para enviar un mensaje [10], este tiempo depende de la frecuencia de muestreo

de la señal de audio y como se está enviado voz en vivo, el tiempo de retardo de ida y

vuelta de los paquetes no debe superar los 300ms, esto implica que el retardo de uno de

los principales, si no el más importante, parámetro QoS para protocolos como VoIP, video

streaming, entre otros [12].

Teniendo en cuenta la definición de todos los parámetros expuestos anteriormente

sobre el retardo en redes IP, se tiene entonces la siguiente formula que describe el

comportamiento del retardo en la red [12].

𝐷𝑇𝑜𝑡𝑎𝑙 = 𝑇𝑓 + ∑(𝑇𝑖 + 𝑃𝑖 + 𝑄_𝑚𝑎𝑥)

En donde:

• Tf: es el tiempo de formación del paquete, como el tiempo de procesamiento para

video o audio.

• Ti: tiempo de transmisión.

• Pi: tiempo de propagación.

• Qmax el tiempo de cola máximo.

Desde el punto de vista del usuario, el delay o retardo es el factor que determina la

sensibilidad de la aplicación, es decir, que tan rápido una página web carga o la calidad de

un video de transmisión en vivo. Dependiendo del tipo de aplicación es el requerimiento de

la red frente al retardo, para aplicaciones de tiempo real es necesario que la red asegure

un retardo menor a 150ms, mientras que aplicaciones que no necesitan un tiempo de

respuesta rápido, como la navegación web, el retardo menor a los 400ms aún puede

considerarse aceptable, y esta distinción de las aplicaciones es de vital importancia, el

25

funcionamiento de la red variara dependiendo de la aplicación que este usando el canal,

esto se debe a los protocolos utilizados que permiten priorizar los paquetes que necesitan

llegar rápido, como los de las aplicaciones en tiempo real, y esto implica la utilización del

canal retrasando así otros paquetes que no tengan este tipo de características [10].

Si bien el retardo se ha definido de forma detallada mediante los parámetros que lo

componen, el retardo también se clasifica dependiendo de la aplicación que esté utilizando

el medio, por lo cual se tienen diferentes métricas del retardo, siendo estas el retardo

instantáneo, la variación del retardo instantáneo, retardo promedio y retardo del peor caso,

cada uno definen un comportamiento de red diferente dictado por la aplicación en uso [13].

3.1.2.1. Retardo instantáneo

Las aplicaciones de tiempo real generalmente tienen límites superiores de tiempo de

espera para la recepción de sus paquetes, como lo son los paquetes de VoIP, de video

streaming, entre otros, estos límites son requeridos para asegurar la calidad del servicio de

la aplicación y entregar una experiencia de usuario satisfactoria. Es requerido entonces que

la red funcione bajo estrictas condiciones de funcionamiento, en donde el esfuerzo de todas

las fuentes de retardo sea controlado y optimizado para garantizar así el tiempo de retardo

requerido [13].

3.1.2.2. Variación del retardo instantáneo

Esta métrica corresponde al tiempo de retraso que hay entre la recepción de dos

paquetes consecutivos, esta métrica es de interés en las aplicaciones que requieren un flujo

constante de paquetes para su funcionamiento. Esta métrica es también llamada Jitter, y

se explicara en otro apartado de esta sección del documento.

3.1.2.3. Retardo promedio

Algunas aplicaciones no requieren que los paquetes lleguen en el menor tiempo posible,

si no que requieren que llegue una gran cantidad de datos a lo largo del tiempo. Por lo tanto,

el retardo promedio es la métrica que se mide para su calidad de servicio, un ejemplo de

este tipo de aplicaciones son las aplicaciones de transferencia de archivos, en donde se

necesita que todo el archivo sea enviado en un tiempo determinado, sin importar con que

velocidad se envió cada segmento [13], ejemplos de este tipo de aplicaciones son páginas

web como Mega, Mediafire y WeTransfer o aplicaciones como Ares, Dropbox, entre otras

[4].

El retardo promedio es la medida obtenida a lo largo de una gran cantidad de tiempo,

mientras que el retardo instantáneo se mide cada que llega un paquete, un ejemplo de la

diferencia de ambos se observa en la figura X en donde en la figura A se observa el canal

26

usado por una aplicación que requiere retardo instantáneo y en la figura B una que solo

requiere un retardo promedio [13].

Figura 13. Diferencia entre retardo instantáneo y retardo promedio [13].

3.1.2.4. Retardo del peor caso

Este tipo de métrica es usada por operadores que requieren una distribución del recurso

de red de forma justa, debido a que en las comunicaciones multi usuario es necesario que

todos los usuarios tengan acceso al sistema, por lo cual esta métrica es una de las más

complicadas de implementar, ya que la asignación de recursos se ve afectada por las

características de cada canal. Entonces esta métrica es definida como el tiempo invertido

para la asignación de recursos para cada usuario en el sistema [13].

3.1.3. Jitter

El jitter es reconocido como un fenómeno importante que degrada el desempeño de la

comunicación, particularmente en servicios en tiempo real como voz y video a través de

Internet. Jitter se refiere a los retrasos variables en los paquetes causados durante el

transporte a través de la red, ocurre debido al retraso de fase variable entre los paquetes

de un servicio particular desde el origen hasta el destino. Debido a este retraso de fase la

información que llega al receptor puede estar errada o incompleta dificultando su

entendimiento. Este retraso de fase se produce debido al retardo de propagación, retraso

en la transmisión, retraso en la cola o demora del procesamiento del nodo en el momento

de la transmisión de los paquetes en la red. Entre estas la primera es constante y las

siguientes tres son variables [14].

Cada elemento del circuito que genera, transmite y recibe señales puede introducir jitter.

Como resultado, el jitter puede afectar a todo el sistema, comprender cuánto jitter introduce

cada elemento de un sistema es esencial para prever el rendimiento general del sistema.

Como falta una técnica estándar capaz de medir el jitter se han desarrollado métodos

para medirlo, en consecuencia con diferentes configuraciones de diferentes proveedores

se puede llegar a resultados diferentes, incluso operando en el mismo sistema conocer la

precisión de la medición de jitter es muy difícil, ya que no existe un estándar de referencia

27

de campo cruzado bien establecido, así como un guía completa capaz de abordar la

elección estándar correcta y llevar a cabo resultados compatibles [15].

La siguiente información viene de un estudio el cual realizo y examinó un amplio

conjunto de datos de mediciones de retardo de red. Muestran que el jitter tiene un

comportamiento que se aparta de la distribución laplaciana [16].

El trabajo de ellos nos muestra como la dispersión de jitter aumenta con el número de

saltos en los nodos siguiendo una ley de potencia con exponente de escala dependiente

del índice de estabilidad 𝛼. Esto nos permite predecir la QoS esperada en términos de

número de nodos y parámetros de tráfico [17].

3.1.3.1. Modelo de Jitter

El jitter se puede definir como la diferencia de los retrasos de viaje de paquetes

consecutivos en una conexión de extremo a extremo. En condiciones ideales, todos los

paquetes deben sufrir el mismo retraso. Sin embargo, debido a la cola de tráfico, las

variaciones de tiempo de procesamiento en los nodos e incluso los cambios de ruta, los

paquetes experimentan jitter, que se puede expresar como:

𝐽𝑁(𝑘) = 𝐷𝑁(𝑘) − 𝐷𝑁(𝑘 − 1)

Donde

𝐷𝑁(𝑘) es el retraso del paquete 𝑘-ésimo como se observa en el Nodo 𝑁-th.

Figura 14. Diagrama de tiempos para paquetes recibidos [14].

Cuando el jitter es negativo se conoce como un fenómeno de agrupación de paquetes,

un positivo se conoce como difusión de paquetes y si es cero entonces no hay jitter.

28

Sea 𝜉𝑖(𝑘) el retardo determinista de la etapa (es decir, la propagación y los tiempos de

procesamiento), y 𝑊𝑖 (𝑘) es el retardo aleatorio de la etapa (es decir, los fenómenos de cola

y cambio de ruta), por lo tanto, el retardo de extremo a extremo a través de los 𝑁 saltos de

la ruta está dado por [17]:

𝐽𝑁(𝑘) ∑[ ξi(k)

𝑁

𝑖=!

+ Wi (k)]

En una serie de estudios se ha demostrado que el tráfico exhibe una dependencia de

largo alcance, esto implica, según S. Resnick and G. Samorodnitsky en su libro

Performance Decay in a Single Server Exponential Queueing Model with Long Range

Dependence [17] que el tiempo de espera 𝑊𝑖 (𝑘) en la cola es pesado. Esto ha sido

revelado a través de mediciones de retardo cuyas Distribución exhibe un comportamiento

paretiano.

En 1925, L´evy, demostró que las leyes de Pareto pertenecen a las denominadas

distribuciones paratelas o no gaussianas estables. Esto implica que 𝑊𝑖 (𝑘) puede ser

modelado por una distribución alpha-stable, y luego 𝐷𝑁 (𝑘), en la ecuación número (X),

converge a una distribución también cuando 𝑊𝑖 (𝑘) es independiente [17].

Se sabe que, si dos variables aleatorias alfa estables son independientes, entonces su

diferencia también es alpha-stable, así el jitter se vuelve alpha-stable con función

característica dada por una distribución simétrica con 𝜇 = 1, 𝛽 = 0, como:

𝐶𝛼.𝛽𝛾,𝜇

(𝜁)𝐽𝑁(𝑘) = exp (−𝛾𝛼|𝜁|𝛼)

𝐷𝑁 (𝑘) tiene una distribución alpha-stable si su función característica es:

𝐶𝛼.𝛽𝛾,𝜇

(𝜁)𝐷𝑁(𝑘) = exp (𝑗𝜇𝜁 − 𝛾𝛼|𝜁|𝛼[1 − 𝑗𝛽𝑠𝑖𝑔𝑛(𝜁)𝜔(𝜁, α )])

(𝜔𝜁, α ) = 2𝜋

log|𝜁|, 𝛼 ≠1,

tan(𝛼𝜋2

), 𝛼 ≠1,

Donde 𝛼 es el índice de estabilidad, 𝛾 el parámetro de dispersión, 𝛽 el parámetro de

asimetría y 𝜇 el parámetro de desplazamiento. Hay tres formas cerradas de distribuciones

alfastables: la distribución gaussiana cuando 𝛼 = 2, la distribución de Cauchy cuando 𝛼 = 1,

𝛽 = 0, y la distribución de Levy cuando 𝛼 = 0.5, 𝛽 = 1.

29

Figura 15. Supervivencia apropiada del del jiter [17]

En el escenario de evaluación para las pruebas con el fin de presentar un modelo de jitter

realista, se realizaron mediciones extensivas de retardo en varios saltos y trayectorias en

un período de 24 días. La configuración involucró distintas ubicaciones seis países de

diferentes continentes: Argentina, Australia, Japón, México, Francia y Estados Unidos.

Todos los paquetes viajaron a través de EE.UU. Un conjunto de unos 7,2 millones de

medidas fue tomado [17].

Se puede ver que el jitter no se ajusta a los modelos laplacianos ni a los de Gauss, pero

la cola muestra una lenta decadencia.

Desde una perspectiva práctica, el pronóstico del rendimiento del sistema basado en el

modelado alfa-estable puede ser complejo, debido a la transformada inversa de la función

característica que no tiene una expresión cercana, pero para valores muy limitados de los

índices de estabilidad. La figura (16) muestra un ejemplo de un histograma normalizado del

parámetro alfa en una ruta de 21 nodos, donde el índice de estabilidad promedio es 𝐸 (𝛼) =

0.9716.

30

Figura 16. Histograma normalizado de Alpha [17].

3.1.3.2. Ley de acumulación de Jitter

El retardo que experimenta un paquete en un salto depende del tráfico anterior en el

nodo sin procesar, sin embargo, sólo una porción de los paquetes que llegan tendrá ese

nodo como destino final, mientras que los paquetes restantes se reenviarán a otras rutas,

debido al proceso de las fuentes de tráfico cruzado, el retraso de nodo a nodo exhibe una

pequeña correlación.

El proceso de multiplexación en los nodos permite reconstruir una supuesta

independencia, de modo que los retrasos en los nodos tienden a ser independientes a

medida que aumenta el tráfico y la conectividad. Entonces, de acuerdo con la formula (2) y

(3), la fluctuación de fase acumulada en una ruta de 𝑁 saltos tendrá una dispersión 𝛾𝑝 =

𝛾𝑁1 / 𝛼, donde 𝛾 es La dispersión de jitter en un solo nodo. Es decir, 𝛾𝑖 = 𝛾. Las

observaciones experimentales muestran que, aunque el entorno de red puede no ser

homogéneo [17] la dispersión de jitter crece como una función de ley de potencia del

número de nodos en la ruta. La Figura (17) muestra la comparación del crecimiento de

dispersión del jitter a lo largo de una ruta de 21 nodos y el modelo propuesto.

31

Figura 17. Dispersión del jitter (𝛾) vs número de saltos (hop) (17]

3.1.4. Pérdida de paquetes

Uno de los parámetros de más relevancia para evaluar el rendimiento de una red es el

porcentaje de perdida de paquetes, esta medida se refiere a los paquetes que no logran

llegar al destino por diferentes razones. La pérdida de paquetes es medida generalmente

como el porcentaje de paquetes perdidos respecto al total de paquetes enviados [12].

Desde el punto de vista del destino, la pérdida de paquetes afecta negativamente el

rendimiento y la calidad de presentación de las aplicaciones, esto se debe a que hay

aplicaciones que tienen requerimientos específicos para el porcentaje de perdida de

paquetes, estos requerimientos son necesarios debido a que se requiere una calidad

mínima de video y/o voz, por lo que son las aplicaciones en tiempo real las que se ven más

afectadas por este parámetro del QoS [10].

El mayor generador de perdida de paquetes en una red son los routers que la

componen, esto se debe a la gran carga de procesamiento del router o una gran cantidad

de carga en el link de comunicación. En estos casos los paquetes presentes en las colas

en los routers pueden llegar a ser descartados por falta de recursos físicos. Otra razón de

la perdida de paquetes es errores en la configuración de la red y colisiones que se presentan

en el medio de transmisión. Además de las razones anteriormente mencionadas, la pérdida

de paquetes también se puede presentar por cortes en la red y dispositivos congestionados

como lo son un teléfono IP o una puerta de enlace de red telefónica pública conmutada

(PSTN) [11].

32

La transferencia de datos en una red IP es de forma segura, respecto a los paquetes

que se lleguen a perder, debido a que es usado el protocolo de control de transmisión

(TCP), este protocolo permite que dos dispositivos primero se pongan de acuerdo para abrir

un canal de comunicación entre ellos, asegurando así la conectividad entre ambos, y en

caso de que se presente perdida de paquetes por algunas de las razones anteriormente

mencionadas, están en la capacidad de pedir un reenvió de los paquetes que no llegaron

al destino, asegurando así que toda la información llegue. Aunque TCP asegura que los

datos lleguen al destino, el hecho de perder paquetes en el camino afecta negativamente

el rendimiento de la red, debido a que al reenviar paquetes faltantes al destino conlleva un

tiempo adicional que afecta el delay presente en la red, y este porcentaje de perdida de

paquetes puede llegar ser hasta del 20% dependiendo del tipo de red, numero de saltos y

la congestión presente en la red. Por estas razones para él envió rápido de información se

usa el protocolo de datagrama universal (UDP), protocolo usado por las aplicaciones en

tiempo real, asegurando así el envío constante de paquetes sin importar el reenvió de los

paquetes perdidos y sin tener una interacción inicial entre dispositivos, permitiendo así una

transmisión rápida pero no confiable de paquetes. UDP es usado para aplicaciones como

VoIP, video streaming y aplicaciones de juegos, en donde se requiere que los paquetes

lleguen lo más rápido posible para reducir el tiempo de respuesta de las aplicaciones en el

otro extremo, es por esto que la red tiene que contar con unas especificaciones mínimas

para asegurar que el porcentaje de paquetes perdidos sea el menor posible [11].

Por diseño de las redes IP, cada vez que llega un paquete a un dispositivo este toma el

camino dictado por la tabla de enrutamiento, como cada dispositivo solo se comunica con

sus vecinos la ruta dictada por estas tablas no siempre es la óptima, implicando así que

algunos paquetes tomen rutas muy largas y se retrasen respectos al resto de paquetes,

esto conlleva a que estos paquetes se descarten en los dispositivos ya que su tiempo de

espera ha sido superado al tomar una ruta no optima. Para solucionar este problema se

pueden usar buffers en los dispositivos para esperar esos paquetes retrasados, sin

embargo, aún pueden llegar a ser descartados si el tiempo de retardo es muy alto o el link

de comunicación está muy congestionado [11].

El modelamiento matemático del comportamiento de la perdida de paquetes en una red

siempre ha sido complicado, esto se debe a que ha sido difícil predecir un algoritmo

matemático e implementarlo sin que afecte otros parámetros del QoS en la red, es por eso

que en el documento de modelamiento de perdida de paquetes, se han utilizado la

combinación de diferentes modelos teóricos para la creación de un modelo que tenga en

cuenta el nivel de los cuellos de botella tanto de la ráfaga como de la agregación. El modelo

“Combined Markov receive-loss run-length” (CMRL) está basado en los modelos Markov y

RLRL (Receive-loss run-length model) [18].

33

Figura 18. Modelo combinado Markov run-length [6].

Como se observa en la ilustración, el modelo se compone de tres grupos principales, el

grupo RM, Ek y Ln. El grupo RM es el encargado de recibir los estados y denota el caso en

que se reciben con éxito paquetes consecutivos sin perdidas, el grupo Ln representa el

caso de perdidas consecutivas y el grupo Ek captura las transiciones de recibido a perdido

o de perdido a recibido [18].

El modelo CMRL permite predecir probabilísticamente el comportamiento de los

paquetes perdidos en la red siguiendo las siguientes ecuaciones:

𝑃𝑟1|𝐸(𝐾) =𝑐𝑜𝑢𝑛𝑡([1||𝐸(𝐾)], 𝐵)

𝑐𝑜𝑢𝑛𝑡(𝐸(𝐾), 𝐵) ∀𝐸(𝐾) ∈ Ω(𝐾)

𝑃𝐿,ℎ =𝑔1(𝐾 + ℎ + 1)

𝑔1(𝐾 + ℎ), 𝑝𝑎𝑟𝑎 ℎ = 1, … , 𝑁.

𝑃𝑅,ℎ =𝑔0(𝐾 + ℎ + 1)

𝑔0(𝐾 + ℎ), 𝑝𝑎𝑟𝑎 ℎ = 1, … , 𝑀.

El modelo requiere M+N+2^K tareas para el cálculo de la probabilidad, valores dados

por las características de la red y en donde M y N son la longitud de los componentes de

los modelos RRL y LRL, respectivamente, y K es el tamaño del modelo de Markov.

3.1.1. Throughput

El throughput, o ancho de banda efectivo, en una red hace referencia a la cantidad de

datos transmitidos en un canal de comunicación en un tiempo determinado, siendo este un

parámetro del QoS de todo tipo de red, ya que es usado para medir la efectividad y

eficiencia de una red en cuanto a la transferencia de datos se refiere, encerrando en si otros

parámetros que pueden llegar a afectar su funcionamiento, como lo son los parámetros

cambiantes de TCP y las características del canal. Un ejemplo de los parámetros que

influyen en el throughput en una red son los parámetros anteriormente expuestos como es

el delay y pérdida de paquetes, además de otros parámetros como corrupción en los datos

transmitidos, falsos controles de congestión y pérdidas de información en el canal de

transmisión [19].

El throughput al ser tan amplio en su definición tiene variaciones dependiendo en donde

sea aplicado, es decir, no será lo mismo medir y analizar el throughput en una red de control

34

en una planta eléctrica a hacerlo sobre redes IP soportadas en TCP y UDP, es por esto que

para el caso de redes WAN y LAN los parámetros necesarios para medir el throughput es

el delay de extremo a extremo y el ancho de las ventanas disponibles a lo largo del canal

de comunicación [8], pero aunque estos son los parámetros principales el comportamiento

del throughput puede verse afectado por el efecto de la perdida de paquetes y el jitter,

siendo así uno de los parámetros del QoS más variantes en cuanto su rendimiento y así

mismo uno de los parámetros más influyentes a la hora de evaluar el rendimiento de una

red.

3.2. Software Defined Network (SDN)

Debido al incremento de usuarios presentes en las redes actuales, se ha tenido la

necesidad de mejorar de alguna manera los parámetros de funcionamiento de dichas redes

para poder cumplir con las expectativas de funcionamiento deseadas, pero esto ha llevado

a la creación de varios protocolos que intentan solucionar diferentes aspectos de las redes

actuales de una forma distribuida, causando así que estas redes sean complicadas de

implementar y mantener, debido a la cantidad de protocolos y fabricantes que implica la

implementación de todos los elementos de una red. Este problema ha llevado a que la

evolución de las redes se convierta en un sistema muy cerrado, en donde los fabricantes

NEMs (network equipment manufacturers) sean los que dicten en que idioma y como se

comunican los diferentes elementos en una red, implicando así que los NEMs deben

innovar sus tecnologías para las soluciones actuales, pero esto no sucede, es por eso que

es importante migrar a un modelo más cercano al desarrollo de fuente abierta [19].

Antes de la creación de lo que hoy conocemos como SDN (Software Defined Network)

los investigadores han abordado diferentes soluciones para la implementación de

dispositivos autónomos e independientes e inteligencia de redes distribuidas y control [19].

• Open Signaling: Separación de los planos de reenvió y control en la conmutación

ATM (1999).

• Active Networking: Control separado y switches programables (1990s).

• DCAN: Separación de los planos de reenvió y control en la conmutación ATM

(1997).

• IP Switching: Controla los conmutadores de la capa dos como una estructura de

enrutamiento de la capa tres (1990s).

• MPLS: El software de control independiente establece rutas de reenvió

semiestáticas para flujos en enrutadores tradicionales (1990s).

35

• RADIUS, COPS: Uso del control de admisión para proporcionar dinámicamente

la política (2010).

• Orchestration: Uso de SNMP y CLI para ayudar a automatizar la configuración

de equipo de red (2008).

• Virtualization manager: Uso de complementos para realizar la reconfiguración

de la red para admitir la virtualización del servidor 2011).

• ForCES: Separación de los planos de reenvió y control (2003).

• 4D: Inteligencia de plano de control ubicada en un sistema centralizado (2005).

• Ethane: Acceso y control completo de la empresa y la red utilizando planos de

reenvió y control separados, y utilizando un controlador centralizado (2007).

La creación del protocolo OpenFlow en 2008 dio como inicio oficial a lo que se conoce

como SDN. En 2011 gano tanto impulso que la responsabilidad de este estándar paso a

ser de la Fundación de Redes Abiertas (ONF por sus siglas en ingles). La ONF fue

establecida en 2011 por la colaboración de Telekom alemán, Facebook, Google, Microsoft,

Verizon y Yahoo!, y es lo que se le considera el guardián del estándar OpenFlow. Los

miembros corporativos de la junta directiva consisten de los mayores operadores de redes,

implicando así que la junta de la ONF está compuesta por CTOs, directores técnicos,

profesores de las universidades de Stanford y Princeton, y personal de compañías como

Verizon, Microsoft, NTT, Google, Yahoo!, Facebook, entre otros. Esto permite una visión

global de que debe ser investigado y estandarizado para las condiciones de las redes

actuales, además ofrece la ventaja de evitar que se maneje la ONF a conveniencia del

interés de un ente particular [19].

36

Figura 19. Organograma de ONF [19].

El acercamiento de la ONF a la arquitectura de las redes SDN es el observado en la

siguiente figura, en esa arquitectura, OpenFlow se concentra más que todo entre los planos

de datos y control, teniendo un sistema de soporte de operaciones (OSS por sus siglas en

ingles) en cada plano con un módulo de coordinación con los planos de control y datos,

estos OSS son importantes en la arquitectura en todos los niveles, y están involucrados en

la configuración inicial, políticas de configuración del plano de control, monitoreo de

rendimiento, SLA y problemas de seguridad [20].

37

Figura 10. Arquitectura de capas SDN general aprobada [2].

Siguiendo la evolución de los estándares de las industrias en 2016 y 2017, la ONF ha

extendido la vista de la arquitectura de las SDN, en esta nueva visión la interface de gestión

de servicios está ubicada en la capa de aplicación como se muestra en la figura 10 [20].

3.2.1. Características

Las redes SDN se caracterizan por los siguientes componentes: separación de planos,

dispositivos simplificados, control centralizado, automatización de redes y virtualización, y

fuente abierta.

3.2.1.1. Separación de planos

Una de las principales características de las redes SDN es la separación de los planos

de control y datos, esto permite que la toma de decisiones y lógica implementadas para los

paquetes entrantes en los dispositivos SDN puedan ser implementados en el plano de

datos, esto se logra haciendo el uso de tablas de flujo que filtran los paquetes entrantes

mediante sus características, como los son la dirección MAC, dirección IP, y el ID VLAN,

entre otros. Entre las acciones con las cuales el plano de datos interactúa con los paquetes

entrantes se encuentra el reenviar, abandonar, consumir y/o replicar, en otros casos puede

transformar el paquete de alguna forma antes de tomar cualquier otra acción. Ejemplos de

acciones realizadas en el plano de datos está el abandono de los paquetes debido a que el

buffer se encuentra sobrecargado o debido a la implementación de un protocolo de QoS,

también se puede presentar el caso de que algunos paquetes requieran un tratamiento

especial, como los son los paquetes que tienen algún tipo de protección de seguridad

especial, este tipo de paquetes es transferido al plano de control para un procesamiento y

luego ser retransmitidos [21][22].

38

Si bien como se mencionó antes, la lógica y tablas de flujo se encuentran en el plano

de datos, y de estas son derivadas las diferentes acciones que se le aplican a los paquetes

entrantes, son estas tablas y lógica programadas generadas en el plano de control. Muchos

de los protocolos y algoritmos implementados en una red SDN requieren de una vista global

de la red para la toma de decisiones, por lo que la separación del plano de control permite

programar y configurar la red para aprovechar en lo máximo los recursos de la red. En las

redes tradicionales, el plano de datos y de control se encuentran en los mismos dispositivos

que la componen, es decir, cada dispositivo cuenta con un plano de control y de datos, y

aunque estos son entidades separadas no se pueden desligar del hardware que las

contiene, es por esto que en las redes SDN estos planos también son separados desde el

punto de vista del hardware, permitiendo así la implementación de protocolos y la

configuración de la red de forma más sencilla y rápida [21][22].

Por último, se tiene la capa de aplicación, en esta capa es donde muchos de los

investigadores han basado sus trabajos y papers, y es porque esta capa permite la

implementación de algoritmos en lenguajes como Java, Pythons, entre otros, que permiten

una fácil implementación de algoritmos que ayuden a mejorar el rendimiento de las redes

[23], ejemplos de estas APIs se verán más adelante en el documento en la sección de

trabajos anteriores.

Figura 11. Componente del dispositivo tradicional y estructura SDN [24]

3.2.1.2. Dispositivos simplificados y control centralizado

Como consecuencia de la separación de planos, se vio la necesidad de implementar

dispositivos simplificados, los cuales serían entonces controlados por un sistema

centralizado que permitiría controlar y monitorear su funcionamiento. Uno de los problemas

de las redes actuales con tecnologías tradicionales, como son la mayoría de las redes WAN,

39

es que para la implementación de protocolos que mejoren una o varias características QoS

de una red, es necesario la programación de dichos protocolos en el software de cada

dispositivo de la red, haciendo más tedioso el mantenimiento de la red, así como aumenta

la complejidad de la misma. Con los dispositivos simplificados se resuelve el problema

anteriormente expuesto, esto se logra separando del todo el componente de software de

cada dispositivo y es puesto entonces en un controlador centralizado, este controlador

entonces tendrá la tarea de dar órdenes simples a los dispositivos simplificados para alterar

el funcionamiento de la red, permitiendo la toma rápida de decisiones de cómo tratar con

los paquetes entrantes [21][22].

3.2.1.3. Automatización de redes y virtualización

Las tres abstracciones básicas que forman la estructura de las redes SDN son las

abstracciones de estado distribuido, reenvió y configuración. Estas abstracciones surgieron

al evaluar cuales son los problemas que enfrentas las redes actuales, y es que en pocas

palabras son las causas que no permiten que las redes actuales den abasto a los

requerimientos de red. Así como los lenguajes de alto nivel permitieron que los procesos

en las maquinas fueran cada vez más complejos y eficientes, la abstracción de estado

distribuido permite al programador de la red observar la red de forma global, sin tener que

entrar en detalle de cada uno de sus componentes, dando así las herramientas necesarias

y suficientes para poder resolver problemas en toda la red [21].

La abstracción de reenvío permite programar los comportamientos de los switch de la

red sin tener que conocer el hardware de cada vendedor, esto quiere decir que la

programación y configuración de la red se realiza con un lenguaje unificado, permitiendo la

configuración del hardware de los dispositivos de la red mediante la representación de una

especie del mínimo común denominador de las capacidades de reenvío del hardware de

red [21].

Finalmente, tenemos la abstracción de configuración, la cual hace referencia al poder

especificar las metas de toda la red sin tener que enredarse en como el hardware llegara a

cumplir dichas metas. El hecho de que se pueda hacer esto en las redes SDN es a lo que

se le denomina virtualización de la red. El controlador centralizado basado en software

proporciona una interfaz abierta que hace posible el control automático en la red, este

controlador se caracteriza por dos términos, northbound y southbound, que son usados

para distinguir si la interfaz es para las aplicaciones o los dispositivos, y los nombres se

deben a que por convención las aplicaciones son representadas en la parte superior del

controlador y los dispositivos debajo de este. Un ejemplo claro de lo que es una API para

el southbound es la interfaz OpenFlow que los controladores usan para programar los

dispositivos de la red. Las API del northbound son aquellas interfaces que son fácilmente

implementadas en el controlador y permite controlar el comportamiento o de la red de

manera eficiente y dinámica, además de que son capaces de proporcionar una vista global

de la red [21]. Los beneficios clave de por qué las API del northbound en los controladores

son:

40

• Se convierte en una sintaxis que es más familiar para los desarrolladores,

utilizando sintaxis como REST y JSON.

• Proporciona abstracción de la topología de la red, permitiendo al programador

implementar algoritmos que maneje la red como un todo en lugar de nodo en

nodo.

• Proporciona abstracción de los protocolos de la red, ocultando al desarrollador

de la aplicación de los detalles de las southbound APIs como lo es OpenFlow,

lo que hace posible el desarrollar aplicaciones que funcionen en una amplia

gama de equipos de fabricantes que pueden diferir sustancialmente de sus

detalles de implementación.

3.2.1.4. Fuente abierta

Desde su concepción, SDN ha buscado que todas las interfaces desarrolladas deben

permanecer estándar, bien documentadas y sin propietarios, esto permite que las API

desarrolladas en el northbound y southbound sean de libre acceso, lo que implica que todos

los investigadores y desarrolladores podrán tener acceso a la misma tecnología,

aumentando la colaboración entre las diferentes instituciones e investigadores privados,

esto tiene como consecuencia un aumento en la generación de nuevas ideas, aumentando

la velocidad con la que la tecnología avanza, y por consiguiente, la rapidez con la que la

población en general puede llegar a tener acceso a los servicios ofrecidos por esta [21].

Además de que, al estandarizar las interfaces, las instituciones y empresarios se verán

obligados en implementar nuevas estrategias para hacer más apetecible sus productos de

red, siendo una de estas un bajo costo para el hardware en switches y demás dispositivos

de red, cumpliendo así uno de los objetivos de SDN, reducir el costo del equipamiento de

red.

3.2.2. Funcionamiento de una red SDN

De forma simple, la estructura de una red SDN es la observada en la ilustración 2, en

esta se observan los componentes básicos de una red SDN, los cuales son los dispositivos

SDN, el controlador y las API que conforman el funcionamiento del controlador, formando

una arquitectura con tres planos, el plano de datos, plano de control y plano de aplicaciones.

El plano de datos consiste esencialmente de dispositivos de red tales como router, switches

físicos o virtuales, puntos de acceso, entre otros, los cuales son controlados mediante una

aplicación denominada API ubicada en el Southbound del controlador, y esta es la

encargada de la comunicación entre el controlador y los dispositivos. El plano de control es

el encargado de la abstracción de la red de dispositivos SDN, es decir, es un dispositivo

que está escaneando constantemente la red para tener una vista global y directa de toda la

red, lo que abre la puerta al siguiente plano, el plano de aplicación, es en este donde se

programa y configura toda la red, y usa el denominado northbound del controlador para el

uso de las API que implementan funcionalidades a la red y el controlador, como son el

41

monitoreo de tráfico, algoritmos de predicción de flujo, implementación de protocolos, entre

otros [20][21].

Figura 12. Descripción general del funcionamiento de una red SDN [21]

3.2.3. Plano de datos

Este plano consiste de los dispositivos SDN tales como routers, switches físicos o

virtuales, puntos de acceso, etc. Estos dispositivos son configurados y administrados

mediante C-DPIs (Controller-Data Plane Interfaces) por el controlador SDN, permitiendo así

una adaptabilidad a los cambios de la red de forma rápida y dinámica [26]. Los dispositivos

SDN no cuentan con un control integrado o un software que les permita tomar decisiones

autónomas, y la infraestructura de red (conmutadores, vswitches, enrutadores, etc) se

abstrae de las aplicaciones. Como se ha mencionado con anterioridad, el controlador se

comunica y controla los dispositivos SDN mediante las aplicaciones del southbound, siendo

la más conocida y estandarizada OpenFlow. Hay dos elementos fundamentales en una

arquitectura SDN/OpenFlow, el controlador y los dispositivos SDN [21].

Un dispositivo SDN es un programa de software o un dispositivo de hardware que

reenvía paquetes en la red, un dispositivo SDN o lo que es lo mismo un dispositivo

OpenFlow consiste de tres partes: la tabla de flujo, el canal seguro que es usualmente un

canal TLS o SSL entre el switch y el controlador, y el protocolo OpenFlow, de este último

hablaremos con detalle más adelante en el documento [24].

42

Figura 13. Switch OpenFlow [24]

La tabla de flujo es una implementación de estructuras de datos en el dispositivo SDN,

estas tablas son programadas en los dispositivos por el controlador usando el protocolo

OpenFlow, y permite al dispositivo evaluar los paquetes entrantes y realizar acciones sobre

ellos según el contenido del paquete. Aunque los dispositivos actuales también pueden

llegar a tomar acciones sobre los paquetes además del reenvió, los dispositivos SDN hacen

de estas tareas más genéricas y programables, permitiendo una implementación a mayor

escala [21][25][27]. Las tablas de flujo en un switch OpenFlow pueden ser creadas,

borradas o actualizadas por el controlador, y consisten de muchas entradas de flujo, que se

dividen en seis partes como se observa en la siguiente ilustración:

43

Figura 14. Dispositivo SDN/OpenFlow [24]

El campo Match hace una comparación de las reglas de la tabla de flujo con los

paquetes entrantes, el switch comparan con la tabla de flujo el puerto de entrada y el

encabezado del paquete, luego de comparar, y según haya sido programado el dispositivo,

el switch realizara acciones sobre el paquete, los counters se utilizan para actualizar los

paquetes que coinciden, los timeouts indican el tiempo máximo o tiempo de inactividad que

tiene el paquete, el priority se aplica para hacer coincidir la precedencia de la entrada del

flujo y por último la cookie es el valor de datos opaco elegido por el controlador, que puede

ser utilizado por el controlador para filtrar estadísticas de flujo, modificación de flujo y

eliminación de flujo [24][25].

3.2.4. Plano de control

El plano de control en una red SDN es el aquel encargado de monitorear y controlar los

dispositivos de la red, por lo cual recibe el nombre de controlador, y es precisamente este

controlador quien actúa como un intermediario entre la interfaz de aplicaciones northbound

(NBI) y el plano de datos y la interfaz southbound (SBI). Un controlador actúa como el

cerebro de la red, proporcionando una vista centralizada y abstracta de la red global. Cada

controlador está conformado por dos componentes, las aplicaciones y el sistema operativo

de red (NOS). Las aplicaciones hacen referencia a los programas de software que se

utilizan para el monitoreo, toma de métricas y toma de decisiones, siendo parte importante

del funcionamiento de una red SDN [24][26][27].

44

Figura 15. Estructura del controlador SDN [21].

3.2.4.1. Diseño de controladores

En el uso de los dispositivos físico o de software en una red SDN, se encuentra

involucrados uno o más controladores, los cuales tienen que comportarse de tal manera

que no interfieran entre ellos mismos y permita una buena comunicación entre sus puntos

de acceso, es por esto que muchos investigadores están enfocados en mejorar el diseño

de los controladores para mejorar el rendimiento en aspectos como lo son: consistencia de

estado, escalabilidad, flexibilidad, seguridad, disponibilidad, latencia y colocación [24].

La consistencia de estado permite que los controladores OpenFlow y los dispositivos

SDN mantengan la misma información de reenvío, manteniendo una política de reenvío

estable en toda la red. La escalabilidad hace referencia a la capacidad de las SDN de poder

implementarse en diferentes ambientes productivos de forma gradual sin perder las

propiedades que la caracterizan, siendo una técnica efectiva el diseño de redes SDN de

forma distribuida en el plano de control. En cuanto a la flexibilidad se refiere, los

controladores SDN permiten compartir la carga de procesamiento de las diferentes

aplicaciones cuando son usados de forma distribuida, permitiendo así una distribución de

carga uniforme en toda la red. Debido al múltiple desarrollo en paralelo de parte de las

instituciones educativas y los investigadores, pueden llegar a presentarse problemas

potenciales de confianza con las aplicaciones de terceros, lo que ha llevado a la creación

de diferentes mecanismos para limitar de alguna manera los permisos que tienen las

aplicaciones para interactuar con el controlador, y es en esto en que se destaca el

controlador SDN, permite la implementación de este tipo de aplicaciones de forma sencilla

y al ser de código abierto permite su mejoramiento constante. El rango de tolerancia y

recuperación en caso de que haya fallas en algún nodo de la red siempre ha sido uno de

45

los aspectos más importantes en las redes de hoy en día, y las redes SDN abarcan este

problema de la mejor forma posible, esto es logrado mediante la implementación de

algoritmos que escanean la red de forma constate y en caso de encontrar fallas en un nodo

son capaces de crear controladores virtuales para manejar parte de la red en lo que esta

recupera su estado normal. Si bien los controladores pueden controlar el comportamiento

de toda una red de forma dinámica, esto solo es logrado cuando el posicionamiento del

controlador con los dispositivos de la red se encuentra en distancias optimas, esto es para

disminuir en lo máximo posible la latencia que hay en los canales de comunicación [24][27].

Un controlador SDN puede llegar a trabajar de tres formas diferentes cuando instala

una regla en una tabla de flujos, siendo estas el modo reactivo, hibrido y proactivo. El modo

reactivo hace referencia al momento en que un switch OpenFlow compara un paquete

entrante con las reglas definidas en las tablas de flujo, y al no encontrar un match es

entonces reenviado al controlador para que este decida como tratar con el paquete

entrante, luego de ser procesado el controlador entonces reenviara el paquete al dispositivo

que lo detecto y le programara, a ese dispositivo y a los demás de la red, una nueva regla

que permita la toma de decisiones para futuros paquetes que tengan las mismas

características. En el modo proactivo el switch es programado con anterioridad, es entonces

capaz de tomar decisiones sobre todos los paquetes entrantes sin tener que consultar el

controlador de la red. Y por último se tiene el modo hibrido, en este se combina los modos

reactivos y proactivos, ofreciendo ventajas como es el poder crear, eliminar y actualizar las

tablas de flujos a lo largo de la red para adaptarse al consumo cambiante que se puede

llegar a presentar en la red [26].

3.2.5. Aplicaciones

Las aplicaciones usadas en el northbound del controlador tienen como función principal

realizar cualquier función para la que fue diseñada, es decir, hacer uso de las herramientas

a su disposición para realizar acciones como el balanceo de carga en la red, firewall,

monitoreo, reenvío, entre muchas otras acciones. Cuando el controlador termina de

inicializar y abstraer los dispositivos en la red, es en ese momento en que entran en juego

las aplicaciones, estas hacen uso de las herramientas que le entrega el controlador para

responder a cualquier tipo de evento que pueda llegar a pasar, y es que los eventos bien

pueden venir por el mismo controlador o por entradas externas como lo es la manipulación

del hombre con la API. Las aplicaciones SDN mantienen constantemente un “listener” en la

espera de escucha de eventos, es este listener el que utiliza el controlador para saber

cuándo llamar los métodos de la aplicación, y una vez es accionado es enviada toda la

información pertinente desde el controlador hacia la aplicación, haciendo posible la toma

de decisiones en el momento en que se necesite, ejemplos de estas aplicaciones son End-

user Device Discovery, Network Device Discovery y Incoming Packet, en los dos primeros

casos, son enviados eventos a la aplicación SDN cuando se descubre un nuevo dispositivo

de usuario final o un dispositivo en la red como los son los routers y switches, una vez son

recibidos los eventos la aplicación SDN registrara en el controlador estos nuevos

46

dispositivos en su vista global del sistema, por otro lado los eventos de Incoming Packet

son accionados cuando un paquete entra a un nodo de la red y este es reenvía al

controlador, el reenvío puede darse debido a que no existe ninguna regla en las tablas de

flujo que puedan determinar qué acción tomar o por que se ha programado con anterioridad

que ese tipo de paquetes deben ser enviados al controlador, y una vez es proceso el

paquete en el controlador, se tomara la decisión de agregar reglas en las tablas de flujo que

permita la toma de decisiones sobre ese tipo de paquetes o el controlador simplemente lo

procesara y reenviara o eliminara según vea necesario [21].

Las aplicaciones que se pueden llegar a usar en el northbound de un controlador SDN

pueden tener varias clases, como las que se verán a continuación.

Como ya se había mencionado con anterioridad, existen aplicaciones reactivas y

proactivas en su comportamiento que controlan la comunicación del controlador hacia el

plano de datos, siendo la mayor diferencia entre los dos paradigmas es que las aplicaciones

reactivas van a recibir de forma periódica paquetes enviados desde el switch para que sea

procesado en el controlador, esto se hace con la idea de mantener el menor número posible

de tablas de flujo en cada dispositivo de la red, así como también disminuir el número de

acciones tomadas de forma local, esto permite que la respuesta de la red a los diferentes

flujos que la puedan recorrer sea lo más optima posible, además de aumentar el dinamismo

de la red frente a nuevos flujos, permitiendo la creación de tablas de flujo en el momento

en que se detectan nuevos tipos de paquete, un ejemplo claro de este tipo de aplicaciones

es OpenFlow [23].

Figura 16. Diseño de una aplicación reactiva [23].

47

Por otro lado, las aplicaciones proactivas se caracterizan por la baja comunicación que

tiene el dispositivo hacia el controlador, este tipo de aplicaciones programa con anterioridad

las tablas de flujo y atributos de configuración en los dispositivos de red, cuando entran

paquetes a los dispositivos estos ya cuentan con las tablas de flujo suficientes para llegar

a tomar una acción, y en el remoto caso en que se adicione un flujo a la red de una fuente

externa, el controlador está en la capacidad de crear/actualizar las tablas de flujo en todos

los dispositivos para que logren responder a los nuevos flujos. Uno de los puntos fuertes de

las aplicaciones proactivas es que en el caso en que llegue a fallar el controlador, es más

probable que pueda seguir con su operación normal ya que las tablas de flujo contenidas

en los dispositivos cuentan con las reglas necesarias para manejar el trabajo entrante [23].

Figura 17. Diseño de una aplicación proactiva [23].

Otra clasificación para las aplicaciones son las aplicaciones internas y externas. Las

aplicaciones internas son aquellas aplicaciones que son alojadas y ejecutadas de forma

nativa en el controlador SDN, y mediante lenguajes de programación como Java son

ejecutadas en controladores basados en Java que soportan un entorno de múltiples

modulo, un ejemplo de un entorno que soporta este tipo de aplicaciones es Apache Karaf.

Por otro lado, las aplicaciones externas pueden llegar ser ejecutadas desde cualquier punto

fuera del contenedor que es el controlador y ser modeladas por cualquier lenguaje de

programación, y se comunica mediante RESTful APIs que proporciona el controlador. Una

buena comparación entre ambos tipos de aplicaciones se puede observar en la siguiente

figura [23].

48

Figura 18. Aplicaciones internas vs externas [23].

De la anterior figura se puede destacar lo siguiente:

• Las aplicaciones internas deben ser programadas en Java, mientras que las

externas permiten cualquier tipo de lenguaje de programación.

• El API usado en el controlador es Java para las aplicaciones internas y REST

para las externas.

• Las aplicaciones internas están confinadas a alojarse y ejecutarse dentro del

controlador.

• Al ser aplicaciones nativas, las aplicaciones internas tienen un tiempo de

respuesta mucho mayor a las aplicaciones externas.

• Las aplicaciones internas soportas aplicaciones reactivas debido a su cercanía

con el controlador.

• En caso de alguna falla, las aplicaciones externas implican un menor impacto al

funcionamiento del controlador frente al impacto que ocasionaría una aplicación

interna si llegara a fallar.

3.3. Red WAN

Es una red de área extensa (Wide Area Network) que cubre distancias muy grandes lo

que le permite brindar conectividad a varias ciudades o incluso a un país entero.

Una red WAN se emplea para crear conexiones al corporativo, sucursales, servicios en la

nube y entre otras, el uso de redes WAN solas o en combinación con Internet permite a

las organizaciones y a los particulares satisfacer sus necesidades de comunicaciones de

área extensa [28].

3.3.1. Características

Las principales características de una red WAN son:

49

• Conectan dispositivos que están separados por un área geográfica más extensa que

la que puede cubrir una LAN

• Usan conexiones seriales de diversos tipos para brindar acceso al ancho de banda

a través de área geográfica extensas.

Figura 29. Red WAN [29].

Las operaciones de una WAN se centran principalmente en las Capas 1 y 2 del modelo

OSI. Los estándares de acceso WAN normalmente describen tanto los métodos de entrega

de la capa física como los requisitos de la capa de enlace de datos, incluyendo la dirección

física, el control del flujo y la encapsulación. La definición y la administración de los

estándares de acceso WAN están a cargo de varias autoridades reconocidas, entre ellas la

Organización Internacional de Normalización (OIE).

3.3.2. Protocolos de una red WAN

Los protocolos de la capa física describen cómo proporcionar conexiones eléctricas,

mecánicas, operativas y funcionales para los servicios WAN. La capa física también

describe la interfaz entre el DTE y el DCE. La interfaz DTE/DCE utiliza diversos protocolos

de capa física, entre ellos [28]:

• EIA/TIA-232: este protocolo permite velocidades de señal de hasta 64 Kbps en un

conector D de 25 pins en distancias cortas. Antiguamente denominado RS-232. La

especificación ITU-T V.24 es en efecto lo mismo.

• EIA/TIA-449/530: este protocolo es una versión más rápida (hasta 2 Mbps) del

EIA/TIA-232. Utiliza un conector D de 36 pins y admite cables más largos. Existen

varias versiones. Este estándar también se conoce como RS-422 y RS-423.

• EIA/TIA-612/613: este estándar describe el protocolo de interfaz serial de alta

velocidad (HSSI, High-Speed Serial Interface), que brinda acceso a servicios de

hasta 52 Mbps en un conector D de 60 pins

50

Además de los dispositivos de la capa física, las WAN necesitan protocolos de la capa

de enlace de datos para establecer el vínculo a través de la línea de comunicación, desde

el dispositivo emisor hasta el dispositivo receptor.

Los protocolos de la capa de enlace de datos definen cómo se encapsulan los datos

para su transmisión a lugares remotos, así como también los mecanismos de transferencia

de las tramas resultantes. Se utiliza una variedad de tecnologías diferentes, como ISDN,

Frame Relay o ATM. Muchos de estos protocolos utilizan los mismos mecanismos básicos

de entramado, HDLC, un estándar ISO o uno de sus subgrupos o variantes.

Los protocolos de enlace de datos WAN más comunes son [28]:

• High-Level Data Link Control (HDLC)

• Point-to-Point Protocol (PPP)

• Frame Relay

• ATM

3.3.3. Tipos de redes WAN

3.3.3.1. Conmutación de circuitos

Las redes de conmutación de circuitos son las que establecen un circuito (o canal)

dedicado entre los nodos y las terminales, antes de que los usuarios puedan comunicarse

los usuarios disponen de un enlace directo a través de los distintos segmentos de la red.

3.3.3.2. Conmutación de paquetes

En este tipo de redes se divide los datos del tráfico en paquetes más pequeños que se

envían a través de una red compartida. Las redes de conmutación de paquetes no requieren

que se establezca un circuito y permiten que muchos pares de nodos se comuniquen a

través del mismo canal.

3.3.4. MPLS

Las compañías en cada momento están conectadas a las redes y siempre requieren un

gran flujo de datos, por eso es importante la velocidad y más en el caso de aplicaciones

sensibles al tiempo como videoconferencia o voz sobre IP (VoIP).

Donde es más evidente los retardos es en el enrutamiento de paquetes, dificultando la

recepción del mensaje tanto de audio como de video. Esto sucede porque cuando un

paquete de ip llega a un enrutador, ese paquete no contiene información más allá de una

dirección IP de destino. No hay instrucciones sobre cómo ese paquete debe llegar a su

destino o cómo debe tratarse en el camino. Cada enrutador debe tomar una decisión de

reenvío independiente para cada paquete basándose únicamente en el encabezado de la

capa de red del paquete. Por lo tanto, cada vez que un paquete llega a un enrutador, el

enrutador solo puede obedecer las tablas de enrutamiento ya predeterminadas

Es por esto que las empresas usan la conmutación de etiquetas de protocolo múltiple

(MPLS) abordando este problema, estableciendo rutas predeterminadas y altamente

51

eficientes. Con MPLS, la primera vez que un paquete ingresa a la red, se asigna a una

clase de equivalencia de reenvío específica (FEC), que se indica al agregar una secuencia

de bit corto (la etiqueta) al paquete [33].

Cada enrutador de la red tiene una tabla que indica cómo manejar los paquetes de un

tipo de FEC específico, por lo que una vez que el paquete ha ingresado a la red, los

enrutadores no necesitan realizar un análisis de encabezado. En cambio, los enrutadores

posteriores usan la etiqueta como un índice en una tabla que les proporciona un nuevo FEC

para ese paquete. Los paquetes que transportan tráfico en tiempo real, como voz o video,

se pueden asignar fácilmente a rutas de baja latencia en toda la red, algo que es difícil con

el enrutamiento convencional [33].

Los enrutadores MPLS establecen una ruta de conmutación de etiquetas (LSP), una

ruta predeterminada para enrutar el tráfico en una red MPLS, según los criterios de la FEC.

Solo después de que se haya establecido un LSP, puede producirse el reenvío de MPLS.

Los LSP son unidireccionales, lo que significa que el tráfico de retorno se envía a través de

un LSP diferente.

MPLS es una técnica, no un servicio, por lo que puede ofrecer cualquier cosa,

desde VPN IP hasta Ethernet metropolitana, debe ser administrada por el operador, lo cual

genera un costo constante. Es por esto que SD-WAN tiene un papel muy importante ya que

maneja una arquitectura de tráfico WAN empresarial puede ubicarse en un punto central y

aplicar políticas fácilmente en todos los dispositivos WAN, para enviar tráfico a lo largo de

la mejor ruta, por el contrario, con MPLS las rutas predeterminadas deben ser

cuidadosamente aprovisionadas pero una vez que se implementa una red MPLS, ofrece un

rendimiento garantizado para el tráfico en tiempo real. SD-WAN puede enrutar el tráfico a

lo largo de la ruta más eficiente, pero una vez que esos paquetes IP llegan a la Internet

abierta, no hay garantías de rendimiento [33].

3.3.5. Topologías

Los siguientes modelos de arquitectura WAN son típicos en las redes actuales. Hoy en día,

casi todas las empresas esperan disponibilidad WAN 24 x 7. Junto con la alta disponibilidad,

garantizar una mejor experiencia del cliente, independientemente de la aplicación o

dispositivo de usuario final en sitios / sucursales remotas, requiere niveles consistentes y

deterministas de métricas de rendimiento de la red, por ejemplo, jitter, packet delay/loss,

QoS, entre otros.

3.3.5.1. Topología punto a punto

Para que funcione la topología punto a punto (PPP), cada sitio está conectado al otro sitio

y tiene puntos finales mutuos. Un diseño punto a punto funciona con casi cualquier

tecnología de red, desde Ethernet hasta ATM. Las redes punto a punto se pueden agrupar

para usar múltiples enlaces para proporcionar ancho de banda adicional. La figura 30

muestra una topología punto a punto.

52

Figura 30. Topología punto a punto.

PPP está diseñado para enlaces que transportan paquetes entre dos pares. PPP puede

operar de forma asíncrona, sincrónica, RDSI e implementaciones de acceso telefónico

punto a punto. PPP es un estándar de protocolo de capa 2 de interconexión de sistemas

abiertos (OSI) que permite que dos dispositivos se comuniquen entre sí mediante

conexiones punto a punto [30]. Los enlaces PPP proporcionan una operación bidireccional,

full-duplex simultánea, y se supone que entregan paquetes en orden. PPP encapsula

paquetes de protocolo de capa superior como el Protocolo de Internet (IP), Internetwork

Packet Exchange (IPX) y AppleTalk en paquetes PPP para la transmisión a través del

enlace por orden de llegada, encapsula la información del protocolo de capa de red (que

incluye, entre otros, IP sobre enlaces punto a punto) [31].

Principales características:

• Múltiples protocolos por línea de comunicación

• Autenticación

• Detección de errores

• Compresión de encabezado

3.3.5.2. Topología de malla completa

Una topología de red totalmente mallada solo se recomienda para una red pequeña. En el

diseño de malla completa, como se muestra en la Figura (31), cada enrutador está

conectado a cualquier otro enrutador en la red.

53

Figura 31. Topología de malla completa.

Una ventaja de este diseño es que permite que cada sitio se comunique directamente entre

sí en lugar de pasar por un sitio central. Sin embargo, la escalabilidad está severamente

limitada. También se debe tener en cuenta la cantidad de puertos y circuitos disponibles. Al

igual que cualquier topología de malla completa, la cantidad de recursos necesarios para

mantener una malla completa crece exponencialmente con el número de dispositivos [30].


• Proporciona enlaces redundantes a través de la red.

• Si se produce una ruptura en un segmento de cable, el tráfico aún se puede redirigir

utilizando los otros cables.

• Es una topología muy costosa de implementar

3.3.5.3. Topología de bus

La topología de Bus dentro del entorno WAN a menudo cubre áreas geográficas pequeñas,

es decir, dentro del mismo país. La topología del bus se caracteriza por cableado rígido

(comúnmente denominado backbone) en el que los diferentes sitios de la red están

conectados por un cableado de red de alta capacidad. cada sitio se conecta en línea con

los otros sitios a través de la red troncal. Con la excepción de los sitios al final, cada sitio

está conectado a otro directamente antes y después [31].

54

Figura 32. Topología de bus.


• Debido a que todas estas computadoras usan el mismo cable, solo una

computadora puede enviar paquetes de datos a la red a la vez.

• Si un sitio desea comunicarse con otro sitio, transmite un mensaje en la red troncal,

que es accesible y visto por todos los sitios conectados. Sin embargo, el destinatario

será el único en recuperar el mensaje.

• Cuando uno de los cables del sitio falle, genera una falla completa de la red

• Al aumentar el número de nodos aumenta el tráfico en la red troncal reduciendo la

eficiencia de la red.

3.3.5.4. Topología de estrella

En la topología de estrella hay un hub central y cada sitio está conectado directamente al

hub, Cuando una computadora envía datos a otras computadoras en la red, se envía a lo

largo del cable a un hub o switch, que luego determina a través de qué puerto necesita

enviar los datos para que llegue al destino adecuado, Una falla en una conexión no afecta

a otras partes de la red las cuales son independientes pero no podrán comunicarse donde

se generó la falla [31].

55

Figura 33. Topología de bus.

Principales características

• Todos los cables pasan a un punto de conexión central

• Agregar y eliminar nodos es fácil y la red es más robusta, con la orientación que

evita la colisión de datos entre sitios.

• Debido a que se utiliza mucho cableado para conectar computadoras individuales

a un punto central, esto puede aumentar el costo de expandir y mantener la red

• Toda la operación y eficiencia de las redes depende completamente del

concentrador. Si el concentrador falla por algún motivo, toda la red se cae.

3.3.5.5. Topología en anillo

Una topología en anillo consiste en computadoras conectadas a un cable que gira alrededor

formando un anillo, El tráfico de red se puede enrutar en ambas direcciones. Esto hace que

esta topología sea menos vulnerable que la topología de Bus. Si falla una conexión de línea,

el tráfico se redirige en la dirección opuesta y no se pierde la comunicación. Los repetidores

también se utilizan para mantener la integridad de la red y evitar la pérdida de datos, cuando

hay una gran cantidad de sitios [31].

56

Figura 34. Topología en anillo.

Principales características

• La transmisión de datos es unidireccional, cada computadora examina cada

paquete y verifica si hay alguno destinado a él. Si no lo hay, la computadora envía

el paquete a la siguiente computadora en el anillo.

• Cada computadora actúa como un repetidor.

• Cuando un paquete llega a la computadora de origen, lo elimina de la red.

• En una topología de anillo, si una computadora falla, toda la red se cae.

3.3.6. Problemática en las WAN empresariales tradicionales

En las arquitecturas empresariales actuales, especialmente en los entornos con múltiples

opciones de conectividad WAN, el enrutamiento se configura de tal manera que una ruta se

elige como primaria y la otra se configura como secundaria para garantizar la simetría del

tráfico de modo que los elementos de la infraestructura, como los firewalls y / o soluciones

de optimización WAN, aún pueden funcionar de manera efectiva.

El flujo de datos siempre seguirá el camino principal no puede usar una ruta alternativa,

con mucho ancho de banda, ya que la ruta primaria desde el punto de vista del enrutamiento

sigue siendo válida. Este es uno de los principales problemas que se desperdicia mucho

ancho de banda.

Las políticas de seguridad de la información empresarial en línea deben cumplir la

normativa PCI la cual exige el uso de firewalls y el cifrado de los datos enviados a través

de Internet. La encriptación IPSec de la capa de red normalmente se implementa entre el

enrutador remoto del sitio / sucursal y el enrutador del centro de datos corporativo de la

cabecera.

57

Existen varios con este modo tradicional de implementación de IPSec. Las deficiencias en

el escalamiento, la eficiencia, la resistencia y el cumplimiento de la seguridad que se

experimentan en las grandes empresas.

Las implementaciones empresariales típicas de IPSec utilizan cifrado simétrico. Con cifrado

simétrico, ambos sitios usan una clave secreta compartida. Dada la sobrecarga potencial

de la administración manual de claves en miles de sitios, las grandes empresas

normalmente usan las mismas claves previamente compartidas en todos los sitios /

sucursales, lo que significa que, si algún sitio / sucursal se ve comprometido, la red también

lo está [32].

Las redes WAN de la empresa tiene un alto costo, sobre todo en los lugares remotos donde

se aplica MPLS prometido y entregado en la separación del reenvío de datos y plano de

control, el mayor uso de la función empresarial, como Calidad de servicio, La multidifusión,

el cifrado, tiene un costo y complejidad adicionales. Los cargos únicos por dispositivo /

dispositivo WAN junto con el costo recurrente mensual adicional (mantenimiento,

monitoreo).

Las empresas dependen totalmente de los operadores y / o MSP para cada pequeño

cambio en el contexto de su red de área amplia, lo cual dificulta su administración de

manera oportuna, ya que en cuestión de información el tiempo es dinero. Esto, junto con

los problemas de control y costos anteriores, ha obligado a las empresas a revisar SD-WAN

como un medio para incorporar Internet de manera segura en su red corporativa mientras

retoma el control a través de la administración centralizada de políticas y gana visibilidad a

nivel de aplicación a través de un proceso razonablemente automatizado [32]

IV. Plataformas y complementos

Se procede a instalar Ubuntu, para el caso se instaló la versión 18.04 por su compatibilidad

con los programas que se van a trabajar para el desarrollo del proyecto de grado, una vez

se tiene el sistema operativo instalado se procede a actualizarlo para tener la versión más

completa.

• apt-get update && apt-get upgrade

58

Figura 35. Actualización del sistema.

Se instala JAVA con sus componentes necesarios para los programas que se usaran.

Common

• apt-get install software-properties-common

Figura 36. Instalación de Common.

Java

• add-apt-repository ppa:linuxuprising/java

Figura 37. Instalación de java.

Jdk

• apt install default-jdk

59

Figura 38. Instalación de jdk.

Se comprueba si la instalación fue exitosa observado la versión de java

• java -versión

Figura 39. Versión de java.

Una vez completada la instalación de java y sus componentes se establece el JAVA_HOME, para lo cual se usa el siguiente comando

• update-alternatives --config java

Figura 40. Configuración JAVA HOME.

El comando anterior brinda el path de instalación de Java, con la cual se copia la parte que esta subrayada y se agrega al siguiente comando

• export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

Figura 41. Configuración JAVA HOME.

Se instala Apache Maven con los siguientes comandos

• sudo apt install maven

60

Figura 42. Instalación de Maven.

Se comprueba si la istalacion fue realizada con exito observando la version

• mvn -version

Figura 43. Versión de Maven.

Ahora se Instala apache karaf para lo cual se crea una carpeta llamada Aplicaciones

• mkdir Aplicaciones

Se descarga el apache karaf con el siguiente comando

• wget http://archive.apache.org/dist/karaf/3.0.5/apache-karaf-3.0.5.tar.gz

61

Figura 44. Descarga de karaf.

Una vez termine se descomprime y se pasa a la carpeta de Aplicaciones

• tar -zxvf apache-karaf-3.0.5.tar.gz -C ../Aplicaciones /

Figura 45. Descomprimiendo karaf.

Por último, se instala git core y net tools, para lo cual se usan los siguientes comandos

• sudo apt-get install git-core

Figura 46. Instalación de git-core.

• sudo apt-get install net-tools

62

Figura 47. Instalación de net-tools.

4.1. Instalación de mininet

Con los complementos necesarios listos para el correcto funcionamiento de mininet se

procede a su instalación, lo primero que se hace es comprobar e instalar las

actualizaciones.

• apt-get update && apt-get upgrade

• sudo apt-get dist-upgrade

Una vez se ha actualizado el sistema, se procede a instalar mininet instalando git y clonado

la carpeta de mininet de la página oficial

• sudo apt-get install git

Figura 48. Instalación de git.

• git clone git://github.com/mininet/mininet

63

Figura 49. Clonando mininet.

Se ingresa a la carpeta clonada de mininet, se lista las versiones disponibles de mininet en

git y se cambia a la versión 2.2.2 con los siguientes comandos

• git tag

• git checkout -b 2.2.2

Figura 50. Selección del git.

Por último, se instala mininet con todos los complementos, con el siguiente comando

• /home/tesis/mininet/util/install.sh -nfv

Figura 51. Instalación de mininet y sus complementos.

64

Ya con mininet instalado, se procede a verificar su correcto funcionamiento, para lo cual se

corre el siguiente comando que crea una topología por defecto.

• sudo mn

Figura 52. Red predeterminada de mininet.

Ahora se muestra algunos comandos simples que se pueden correr desde la terminal de

mininet.

• pingall= un ping entre todos los hosts de la red

• xterm = ingresa a la consola del host seleccionado

Figura 53. Comandos de conexión en mininet.

Luego de comprobar el correcto funcionamiento de mininet, se continua con la instalación

del controlador, que para el caso se trabajará con ONOS.

4.2. Instalación de ONOS

Lo primero es actualizar e instalar los programas pre requeridos por ONOS

• sudo apt update

• sudo apt install git zip curl unzip python-minimal openjdk-8-jdk -y

65

Figura 54. Instalación python-minimal.

Se crea un usuario llamado sdn. Al cual se le otorgan los permisos para poder trabajar en

ONOS.

Figura 55. Creando usuario.

Se crea una carpeta en la cual se descargará ONOS.

• sudo mkdir -p /opt && cd /opt

Figura 56. Carpeta para onos.

66

Luego se ingresa a la página oficial de ONOS en la sección de descargas,

https://wiki.onosproject.org/display/ONOS/Downloads donde se puede encontrar las

diferentes versiones disponibles del controlador, por cuestiones de compatibilidad y

facilidad se instala la versión 2.0.0 obteniendo el URL de la siguiente manera.

Figura 57. Obtención del url para descargar ONOS.

Se descarga el programa con el siguiente comando

• sudo wget http://repo1.maven.org/maven2/org/onosproject/onos-

releases/2.0.0/onos-2.0.0.tar.gz

Figura 58. Descargara de ONOS.

Cuando se termina la descarga, se descomprime y se cambia el nombre del directorio por

onos.

• sudo tar xzf onos-2.0.0.tar.gz

• sudo mv onos-2.0.0 onos

https://wiki.onosproject.org/display/ONOS/Downloads

http://repo1.maven.org/maven2/org/onosproject/onos-releases/2.0.0/onos-2.0.0.tar.gz

http://repo1.maven.org/maven2/org/onosproject/onos-releases/2.0.0/onos-2.0.0.tar.gz

67

Figura 59. Descomprimir ONOS.

Por cuestiones de seguridad se le otorga únicamente al usuario sdn los permisos para

trabajar en la carpeta onos.

• sudo chown -R sdn:sdn onos

Figura 60. Otorgando permisos para trabajar en ONOS.

Se procede a agregar las opciones de inicio en donde se instalan algunas de las

aplicaciones que nos ofrece el controlador, para eso se crea un documento con el siguiente

comando.

• sudo -u sdn nano /opt/onos/options

En el cual se agrega la siguiente información:

# running onos with user sdn

export ONOS_USER=sdn

# default active drivers and openflow

export ONOS_APPS=drivers,openflow,gui2

Figura 61. Archivo para instalar aplicaciones de ONOS.

Una vez echo estos pasos se está muy cerca de completar la instalación, daremos los

siguientes comandos para que todos los servicios y aplicaciones de ONOS queden

instaladas correctamente

68

• sudo cp /opt/onos/init/onos.initd /etc/init.d/onos

• sudo cp /opt/onos/init/onos.service /etc/systemd/system/

• sudo systemctl daemon-reload

• sudo systemctl enable onos

Figura 62. Configurando e instalando ONOS.

Solo hace falta iniciar ONOS, el cual se inicia mediante el siguiente comando

• sudo systemctl start onos

Figura 63. Inicialización de ONOS.

Para verificar la correcta instalación de ONOS se utiliza el siguiente comando

• sudo systemctl status onos

Figura 64. Status de ONOS.

69

En la imagen se identifica que ONOS fue instalado correctamente y está activo.

En ONOS se puede hacer la administración de la red desde una terminal o desde un

navegador web, para entrar a la consola de ONOS se utiliza el siguiente comando, en el

cual pedirá una contraseña, la cual es rocks

• ssh -p 8101 onos@localhost

Figura 65. Terminal de ONOS.

En esta terminal se puede activar y desactivar las aplicaciones del controlador, además de

poder ver la IP y el puerto que está usando, entre otras funciones.

El entorno web es más utilizado ya que se puede interactuar y observar el comportamiento

de la red, para ello se ingresa a la siguiente dirección desde un navegador web,

localhost:8181/onos/ui/index.html donde pedirá la siguiente información.

username : onos

password : rocks

70

Figura 66. Login página web de ONOS.

Figura 67. Página web de ONOS.

Como no hay ninguna red conectada al controlador la pantalla de inicio muestra ese

mensaje.

V. Definición y evaluación de escenarios

Teniendo instalado los 2 programas principales, es necesario hacer que trabajen

conjuntamente, para ello se crea una topología por defecto de mininet la cual va a funcionar

por medio del controlador ONOS, para este caso será una topología de árbol y se crea e

inicializa con el siguiente comando

71

• sudo mn –topo tree,3,3 –controller=remote ,ip=10.0.2.15

Figura 68. Comando para crear topología de árbol con controlador.

La IP escrita en el comando anterior hace referencia a la IP del controlador la cual se puede

observar desde la consola de ONOS o desde el navegador

La red creada es

Figura 69. Topología de árbol con controlador.

Pero aún no está funcionado correctamente el controlador, al tratar de realizar un pingall se

observa que no ahí comunicación entre ellos

Figura 70. Conectividad entre los hosts.

72

Para solucionar este, problema es necesario activar una aplicación de ONOS la cual se

llama org.onosproject.fwd que se encarga del reenvío reactivo, permitiendo la conexión

entre los dispositivos. Para activarla se puede hacer desde la consola de ONOS o en la

aplicación web como se puede observar a continuación.

Figura 71. Activación de la aplicación org.onosproject.fwd.

Se vuelve a realizar un ping entre los hosts, teniendo respuesta entre cada uno de ellos

Figura 72. Conectividad entre los hosts.

En aplicación web se tiene información completa de la red como numero de host, switch,

links, entre otros

73

Figura 73. Topología vista desde el controlador.

5.1. Red SDWAN

Con todos los programas listos y funcionado de forma correcta, además de la información

recaudada sobre redes WAN, se procede a crear una topología personalizada que cumpla

las condiciones reales en un habiente laboral, esta topología se generara mediante una API

donde se agregan varios parámetros como ancho de banda de los links, delay y packet los,

esto con el fin de hacer el trabajo más real ya que se sabe que el cableado y la distancia

son factores a tener en cuenta.

La topología creada es la siguiente:

74

Figura 74. Red SDWAN.

Donde los links de los hosts 10.0.0.1 y 10.0.0.2 están limitados a un máximo de ancho de

banda de 100 Mbit/s mientras que los hosts 10.0.0.3 y 10.0.0.4 tiene un ancho de banda de

150 Mbit/s esto con el fin de ver el comportamiento y las limitaciones a trasmitir información.

Cabe resaltar que la topología diseñada, junto con sus características, esta pensada en una

red de alta velocidad, tomando como ejemplo los entornos de prueba mencionados en el

estado del arte consultado.

Se realiza una serie de pruebas para ver criterios de QoS como ancho de banda, tiempos

de recuperación, pérdida de paquetes, throughput y delay. De este modo se puede evaluar

el rendimiento de la red cuando es trabajada con controlador, es decir, una SDWAN

comparada a una red tradicional WAN.

Para crear la red con el controlador se utiliza el siguiente comando

Figura 75. Comando para crear la red personalizada.

75

El documento srTopo8.py es donde está la topología diseñada, el contenido de este

documento se encuentra en los anexos.

Figura 76. Red personalizada.

Se tiene la red creada en mininet la cual es controlada por ONOS, es decir, están trabajando

conjuntamente, esto ofrece un gran seguimiento en tiempo real de la red mediante la

aplicación web, siendo una herramienta muy útil para administrar la red y encontrar fallas.

Una de las ventajas que tienen las redes SDWAN sobre las redes WAN, es que cuando es

iniciado el controlador, y continuamente de ahí en adelante, escanea y detecta todos los

dispositivos conectados en la red y crea las tablas de conmutación necesarias para

garantizar que todos los nodos estén conectados, un ejemplo de la tabla de conmutación

que genera ONOS es el siguiente.

76

Figura 77. Tabla de conmutación generada por ONOS para el switch 1.

En donde las 4 primeras tablas son reservadas para la comunicación entre el controlador y

el switch, y es con estas tablas que el controlador sabe el estado actual del switch, sus

estadísticas, entre muchas otras cosas. Por otro lado, la última tabla hace referencia a la

tabla de conmutación normal y necesaria para la comunicación entre los 2 host con sus

respectivas direcciones MAC. Cabe resaltar que el controlador solo creará una tabla de

conmutación de un switch a otro si en algún momento recibe un paquete que necesite de

esta conexión.

Para evaluar parámetros de la red, se ingresa a la ventana de comandos de los hosts

creados con el siguiente comando.

Figura 78. Comando para ingresar a los hosts de la red.

Se hace una conexión cliente servidor, donde h1 será el cliente y h3 se comportará como

un servidor TCP para así poder obtener el throughput que ahí entre ellos.

Se ingresa al host 3 y se realiza siguiente comando

Figura 79. configuración del host servidor TCP.

Donde el puerto seleccionado, para este caso, es el 5566 y el tiempo de respuesta de 1

segundo, el resultado del comando iperf es almacenado en una variable llamada result.

Ahora en el host 1 se realiza la petición con el siguiente comando

77

Figura 80. Petición del host cliente.

Para ello se utiliza la IP del host 3 y el puerto que está usando, además de especificar el

tiempo durante el cual generara el flujo de tráfico, una vez termine ese tiempo se puede

guardar toda la información obtenida en un documento por medio del siguiente comando

• nano result

Figura 81. Datos de la prueba.

Con la información obtenida se identifica cual es el throughput TCP entre estos dos hosts.

Luego se repiten los mismos pasos, pero el host 2 y 4 son servidores y el host 1 el cliente.

Finalmente, solo falta la comunicación entre el host 3 y el host 4 para obtener el throughput

de todos los dispositivos. Por lo cual el host 4 será el servidor y el host 3 el cliente, vale

aclarar que se reinicia la red cada vez que se ejecuta una prueba.

78

Con los documentos de cada prueba y usando la herramienta de MATLAB se grafican el

throughput TCP.

Se modifica un poco el delay en los links para ver que tanto esto afecta al throughput de la

red, pasando el delay de 100 𝜇𝑠 a 50𝜇𝑠 y después a 200 𝜇𝑠, para luego realizar las mismas

pruebas. Igualmente, utilizando MATLAB se obtienen las siguientes graficas

• Host 2, 3 y 4 como servidor host 1 como cliente

o Links con un delay de 50 𝜇𝑠

Figura 82. Throughput TCP links con 50 𝜇𝑠 de delay.

79





80

• Host 4 como servidor host 3 como cliente

Figura 85. Throughput TCP.

Continuando con las pruebas, ahora se realiza una con conexión UDP, para esto se

configura el host 3 para que se comporte como servidor UDP por medio del siguiente

comando.

Figura 86. Configuración del host servidor.

Al igual que las pruebas anteriores, se utiliza el puerto 5566 y el intervalo de muestreo es

de 1 segundo.

En host 1 se comporta como cliente y realizará las peticiones utilizando el siguiente

comando.

Figura 87. Petición del host cliente.

81

En el comando antes descrito también se agrega el ancho de banda a enviar en bits /s el

puerto y el tiempo de conexión para el envió de información.

Una vez termina la prueba, se guarda toda la información en un archivo local, para lo cual

usaremos el comando

• nano result

Figura 88. Datos de la prueba.

Como resultado de la prueba, se observa información muy importante como el jitter y el

packet loss, se repiten estos mismos pasos con el host 1 como cliente y los hosts 2 y 4

como servidor y, por último, el host 3 como cliente y el host 4 como servidor. Vale aclarar

que la red se reinicia cada prueba para evitar errores en la medición.

Para tener más claridad y seguridad sobre los parámetros de QoS medidos, se realizan

variaciones en las pruebas modificando el ancho de banda a enviar, tomando valores de

10, 50, 100 y 150 Mbit/s, guardando los resultados en un documento para su posterior

análisis y grafico por medio de MATLAB.

82

• Host 2 3 y 4 como servidor host 1 como cliente

o Enviando 10 Mbit/s

Throughput UDP

Figura 89. Throughput UDP enviando 10 Mbit/s.

Jitter

Figura 90. Jitter enviando 10 Mbit/s.

83

Packet loss

Figura 91. Packet loss enviando 10 Mbit/s.


Throughput UDP


84

Jitter


Packet loss


85


Throughput UDP


Jitter


86

Packet loss



Throughput UDP


87

Jitter


Packet loss


88


Throughput UDP

Figura 101. Throughput UDP.

Jitter

Figura 102. Jitter.

89

Packet loss

Figura 103. Packet loss.

En las pruebas realizadas no se evidencia un gran cambio en términos de throughput UDP,

obteniendo variaciones entre el 2,5 % y el 5 % del ancho de banda con los que se generó

los enlaces en la topología de las pruebas, también se evidencia que la distancia entre los

servidores (siendo distancia el número de switch de un host a otro), no es un factor a tener

en cuenta para el throughput ya que sus cambios no son significativos con respecto a otros

que están mucho más cerca.

Otro parámetro analizado es el jitter, el cual se evidencia que cuando se trasmite

información a mayor distancia el jitter en la red aumentará, en las pruebas realizas se

identifica que entre más se utilice el canal, es decir, se envíe un volumen de información

mayor, se genera un jitter más alto, lo cual afecta las aplicaciones en tiempo real como

video llamadas y voz IP. El jitter más alto fue el registrado en la prueba UDP con 150 Mbps,

teniendo un valor promedio de 0,034 ms con el host 4 como servidor, y aunque es cierto

que a mayor tasa de transferencia mayor es el jitter, para el caso de las pruebas UDP con

50 Mbps se evidencio el jitter más bajo, teniendo un promedio de 0,0034 ms con el host 2

como servidor.

Para los datos obtenidos de packet loss en las pruebas con un ancho de banda de 10 y 50

Mbit/s, no se logra identificar una diferencia significativa, ya que le promedio de packet los

para ambas pruebas es aproximadamente 0,2%, además este parámetro tampoco se ve

afectado de una forma apreciable por la distancia (número de switch intermedios) entre los

hosts. Pero el problema del packet los se evidencia en gran medida cuando se trasmite más

90

de lo que el canal está diseñado para soportar, como se evidencia en la figura 102 en donde

se observa un promedio del 38% de packet loss, esto debido a que los links del host 1 tiene

como ancho de banda 100 Mbit/s, y esto limita la comunicación con el servidor host 3, en

el cual su enlace de conexión si soporta un ancho de banda de 150 Mbit/s.

• Tiempo de recuperación

Ahora se procede a la medición de un parámetro muy importante en el QoS de una red, y

es el tiempo de recuperación luego de alguna falla, esto sucede cuando hay algún problema

en la ruta mientras se está enviando un flujo de datos, en ese momento los switch tienen

que buscar la ruta más efectiva para hacer llegar la información a su destino final y esto

puede conllevar un tiempo de respuesta apreciable.

Para esta prueba se enviará información mediante un ping continuo del host 4 al host 3, y

como se observa en la siguiente ilustración, se evidencia la ruta más corta para el envío de

información entre ambos hosts.

Figura 104. Ruta más eficiente entre el host 4 al host 3.

Se observa que el flujo de información sale por el host 4 y pasa por el switch 7, 5 y por

último al 6, para finalmente llegar al host 3.

91

Ahora se simula una falla en la red, para lo cual se deshabilita el enlace entre el switch 7 y

5, se identifica cual es la nueva ruta que toma ONOS para solucionar el problema y la

cantidad de tiempo que tarda en aplicar la decisión.

Para deshabilitar el link se realiza desde la terminal de mininet con el siguiente comando

o link s7 s5 down

Una vez se elimina el enlace, ONOS busca de forma automática una nueva ruta y envía la

información actualizada a cada uno de los switch de la red, como se observa en la siguiente

figura.

Figura 105. Ruta después del fallo entre el host 4 al host 3.

Utilizando la herramienta Wireshark se capturan los datos de la red durante la prueba, en

el momento de simular el error de la red se observa el tiempo que tarda en llegar la siguiente

trama ICMP, siendo este tiempo el tiempo de recuperación de la conexión.

92

Figura 106. Tiempo de recuperación con controlador.

Como se observa en la figura 106, el fallo se dio en el momento de enviar el paquete 109,

siendo el tiempo de recuperación tan rápido que no logra ser diferenciado del tiempo entre

tramas de los demás paquetes.

5.2. Red WAN

La red WAN es igual a la red SDWAN a excepción que esta no tiene un controlador, es

decir, se utiliza el mismo script para crearla, y por tanto misma topología, solamente que se

deshabilita el controlador por medio del siguiente comando

Figura 107. Comando para crear la red personalizada sin controlador.

Esto permite crear la red con los siguientes parámetros

Figura 108. Red WAN personalizada.

Pero en el momento de probar la conectividad de la todos los hosts en la red, se evidencia

que falla el ping.

93

Figura 109. Conectividad fallida en la red.

Esto es muy similar a lo que pasa cuando se trabaja con ONOS sin tener habilitada la

aplicación que se encarga del reenvío reactivo, y este problema se presenta debido a que

los switch, aunque están conectados físicamente, no cuentan con tablas de conmutación

que describan su comportamiento de conmutación, por lo que ahora es necesario hacer las

tablas de conmutación de cada switch de forma manual, esto se hace de la forma que se

muestra a continuación

Figura 110. Activación de los switch de forma manual.

Ahora bien, para una red WAN de topología de anillo o de bus el definir las tablas de

conmutación de forma manual bastaría para tener conectividad entre todos los hosts, pero

como la topología usada es de tipo malla, es necesario hacer un paso más, para lo cual se

activa el protocolo STP (Spanning tree protocol) presente en los switch ovs usados. El

protocolo STP permite la eliminación de los bucles ocasionados por las tablas de

conmutación dentro de una red malla, además de eliminar la propagación de los mensajes

de tipo broadcast producto de los bucles.

94

Figura 11.1 Conectividad correcta en la red.

Se observa en la imagen que una vez realizado los comandos anteriores y realizando un

pingall todos los hosts están comunicados entre ellos, ahora ya se cuenta con la red WAN

funcionado. Para la red WAN se realiza las mismas pruebas realizadas para la red SDWAN

mostradas anteriormente en el documento, esto con la idea de identificar los mismos

parámetros de QoS y poder comparar los resultados de ambas redes.

TCP Throughput

• Host 2, 3 y 4 como servidor host 1 como cliente



95





96


Figura 115. Throughput TCP.

• Host 2 3 y 4 como servidor host 1 como cliente


Throughput UDP


97

Jitter


Packet loss


98


Throughput UDP


Jitter


99

Packet loss



Throughput UDP


100

Jitter


Packet loss


101


Throughput UDP


Jitter


102

Packet loss



Throughput UDP

Figura 128. Throughput UDP.

103

Jitter

Figura 129. Jitter.

Packet loss

Figura 130. Packet loss.

104

En las pruebas realizadas para la red sin controlador, al igual que su contra parte con

controlador, no se evidencia un gran cambio en términos de throughput UDP, obteniendo

variaciones entre el 2,5 % y el 5 % del ancho de banda.

En el parámetro del jitter, al igual que las pruebas con controlador, se evidencia que a mayor

tasa de transferencia de información empeora este parámetro del QoS. La mayor varianza

del jitter medida fue de 0,00079 ms para la prueba de UDP a 150 Mbps, y su menor varianza

fue presentada en la prueba UDP a 10 Mbps para el host 3 coomo servidor, teniendo un

valor de 0,000174 ms.

Para los datos obtenidos de packet los se tiene un comportamiento muy cercano al obtenido

en las pruebas de la red con controlador.

• Tiempo de recuperación

Para la realización de esta prueba, se hace replica el mismo entorno que se tenía con la

prueba de la red con controlador, a diferencia de que en este caso no se contara con el

controlador, haciendo así la conmutación entre los switch de forma manual mediante las

tablas de conmutación y la activación del protocolo STP. En la prueba se produce una falla

mientras se hace el monitoreo de los paquetes con Wireshark, obtenido el siguiente

resultado.

Figura 131. Tiempo de recuperación sin controlador.

Como se observa en la imagen, luego del paquete número 35 el siguiente paquete en ser

contestado es el 56, y es que es en ese momento en que se produce la falla en la red, lo

que implica la búsqueda de una nueva ruta para él envió de los paquetes, que para este

caso de la red sin controlador tarda 32 segundos aproximadamente, causando que la red

deje de funcionar por este periodo de tiempo.

5.3. Comparación entre la Red SDWAN y la Red WAN

Para hacer más evidente las diferencias en los parámetros QoS entre las dos clases de

redes, se toman las pruebas realizadas con el host 4 como servidor y el host 3 como cliente

105

para las redes con y sin controlador, y se grafican en el mismo panel como se muestra a

continuación

TCP Throughput


Figura 132. Comparación throughput TCP links con 50 𝜇𝑠 de delay.



106




Throughput UDP


107

Jitter


Packet loss


108


Throughput UDP


Jitter


109

Packet loss



Throughput UDP


110

Jitter


Packet loss


111


Throughput UDP


Jitter


112

Packet loss


Como se observa en las comparaciones anteriores de throughput en UDP para los

diferentes escenarios, la diferencia entre la red con y sin controlador puede llegar a ser

despreciable, ya que el throughput promedio para el tiempo de conexión es el mismo

(teniendo en cuenta la precisión con la que se tomaron las medidas).

En términos del jitter se evidencia un comportamiento no esperado, en las pruebas de UDP

enviando 10, 50 y 150 Mbit/s se evidencia que el jitter de la red con controlador tiene un

valor promedio y varianza mucho más altos, evidenciando un comportamiento errático

frente a su contraparte sin controlador, esto se debe a que el switch además de enrutar las

tramas del flujo UDP, intercambia mensajes openflow con el controlador, lo que puede llegar

a ocupar capacidad de procesamiento del switch, generar tiempos de espera en lo que el

controlador decide qué hacer con la primera trama de un flujo y generar un pequeño delay

en la conmutación de los paquetes debido a el envío de información de rendimiento del

switch al controlador.

Por último, en términos de packet los se evidencia que en las pruebas UDP de 10 y 50

Mbps, en términos de valor promedio y varianza, se ve que la red con controlador tiene

mejores resultados frente a la red sin controlador. En la prueba UDP de 100 Mbps se

encontró que el valor promedio de packet son muy cercanos en las 2 pruebas (alrededor

de 7,2%) teniendo una diferencia máxima entre ellos de 0,5%, este comportamiento

también se evidencia en la prueba UDP de 150 Mbps, con una diferencia máxima entre las

dos pruebas de 0,26%.

113

El parámetro de QoS que presentó un mejor resultado referente a su contraparte fue el

tiempo de recuperación, como se evidencia el tiempo de recuperación en la red SDWAN es

casi imperceptible y la red no se ve afectada en gran medida en su operación, en cambio

la red WAN presenta un tiempo de recuperación de aproximadamente 32 segundos, tiempo

que afecta enormemente el rendimiento de una red y su QoS, dejando los hosts

incomunicados por 32 segundos.

114

Conclusiones

La red SDWAN es una solución moderna que está en expansión por sus múltiples

beneficios, entre los cuales esta su gran facilidad de administración y monitoreo de datos

lo que facilita el seguimiento en tiempo real del estado de la red, ofrece la posibilidad de

implementar políticas de seguridad a toda la red y ver el estado físico de cada uno de los

switch y hosts que estén conectados y poder administrar las conexiones entre todos los

dispositivos según se requiera. Pero una de las mayores ventajas de las redes SDN es la

posibilidad de implementar aplicaciones que monitorean, analizan y toman decisiones de

forma automática y dinámica, lo que posibilita aplicar algoritmos de reglas de conmutación,

seguridad y rendimiento que modifican el comportamiento de la red para ofrecer un mejor

QoS.

Como resultado de las pruebas hechas para las redes WAN y SDWAN. no se evidencia

una mejora en el promedio de los parámetros de packet loss y throughput, el

comportamiento de ambos es muy similar en ambos casos. Aunque si se evidencio una

desmejora en términos de la varianza del packet loss en las pruebas de la red WAN,

indicando así que este parámetro QoS tiene un comportamiento un poco más erratico que

su contra parte SDWAN. Este resultado era de esperarse ya que, aunque existe la

implementación de varios protocolos y técnicas de administración de redes para mejorar el

packet loss y/o el throughput en una red, no se hizo uso de ninguno de estos, esto con la

idea de hacer que las condiciones de funcionamiento de ambas redes sean las mismas y

su comportamiento sea determinado por las características inherentes al funcionamiento

de los switch y sus tablas de conmutación. Por otra parte, el controlador ONOS usado para

las pruebas de la red SDWAN ofrece un gran catálogo de aplicaciones para instalar y que

permite al administrador de red monitorear, administrar y determinar el comportamiento de

la red, pero la gran mayoría de estas aplicaciones requieren ser ajustadas manualmente

para la topología de la red en cuestión y su implementación requiere un nivel alto de

conocimiento técnico de lenguajes de programación para el uso y modificación de la

aplicación, además de que son muy pocas las aplicaciones que ofrecen algún tipo de

documentación de su funcionamiento y/o implementación lo que incremente el nivel de

complejidad exponencialmente.

Un resultado no esperado fue el obtenido para el parámetro QoS del jitter, y es que

como se ve en las gráficas de comparación de las redes WAN y SDWAN, el jitter de la red

SDWAN llego a ser un 68,1% en su valor más alto que su contraparte WAN, este

comportamiento es debido principalmente a la ocupación de parte del recurso de máquina

de cada switch que se presenta en la red SDWAN, esta ocupación está dada debido a que

el ser una red SDWAN implica un monitoreo y control constante sobre los paquetes que

entran y salen de un switch, y aun que la comunicación del switch con el controlador y otros

switch se da en puertos e instantes distintos, estos afectan la velocidad de respuesta del

switch, además cabe resaltar el siguiente caso en específico, cuando llega el primer

115

paquete de un nuevo flujo a un switch, este debe ser enviado al controlador para que el

determine como va ser tratado y agregar esa regla a la tabla de conmutación, esto conlleva

un tiempo que ocasiona que los paquetes que le siguen entren en la cola del switch hasta

que el controlador termine de procesarlo, lo que implica que al enrutar los demás paquetes

se den estos casos de paquetes fuera de orden y con tiempos de propagación diferentes.

El parámetro QoS en el que se destaca la red SDWAN frente a la red WAN, es la

eficiencia que se tiene con el tiempo de recuperación, ya que es de forma prácticamente

inmediata la conmutación del flujo de datos a un camino alterno, lo cual garantiza que, en

caso de algún error en alguno de los enlaces de la red, el controlador buscara de forma

automática la ruta más rápida para hacer llegar la información en el menor tiempo posible.

116

Referencias

[1] "Software-Defined Networking: The New Norm for Networks", white paper, [online] Available:

https://www.opennetworking.org.

[2] Andrés C, “La transición de WAN a SD-WAN”, Agosto 2018, [Online] Available:

https://computerworld.co/la-transicion-de-wan-sd-

wan/?doing_wp_cron=1534860114.6338150501251220703125

[3] OpenNetworking.org Software-Defined Networking (SDN) Definition, Octubre 2014.

[4] Eduardo T. “Virtualización, SD-WAN y sus implicaciones de seguridad – Parte 1”, Noviembre

2016, [Online] Available: http://www.teldat.com/blog/es/virtualizacion-sd-wan-y-sus-implicaciones-

de-seguridad-parte-1/

[5] networkworld, “¿Cómo elegir una solución de redes WAN definidas por software?”, Abril 2016,

[Online] Available: http://www.networkworld.es/networking/como-elegir-una-solucion-de-redes-wan-

definidas-por-software

[6] Ubuntu. (2018, Septiembre 20). [Online]. Avalaible: https://www.ubuntu.com/

[7] Mininet. (2018, Septiembre 20). [Online]. Avalaible: http://mininet.org/

[8] S. Misra and S. Goswami. Netwok Routing: Fundamentals, Applications, and Emerging

Technologies. pp. 89-118. India: Wiley, 2017.

[9] X. Xiao. Technical, Commercial and Regulatory Challenges of QoS. Massachusetts: Morgan

Kaufmann, 2008, pp. 37-51

[10] X. Xiao. Technical, Commercial and Regulatory Challenges of QoS. Massachusetts: Morgan

Kaufmann, 2008, pp. 13-35.

[11] J. Ellis, C. Pursell y J. Rahman. Voice, Video, and Data Network Convergence. Academic Press,

2003, pp. 245-268.

[12] D. Wall, J. Kanclirz, Y. Jing, J. Faircloth y J. Barrett. Managing and Securing a Cisco SWAN,

Syngress, 2004, pp. 421-447.

[13] A. Pérez y M. Realp. Cross-Layer Resource Allocation in Wireless Communications, Academic

Press, 2009, pp. 125-149.

[14] S.Kandar and C.T.Bhunia “A New Protocol for Minimizing Jitter for Guaranteed QoS in Network

Multimedia Communication”, 2010 International Conference on Advances in Computer Engineering

[15] E. Balestrieri, F. Picariello, S. Rapuano, I. Tudosa, “Review on jitter terminology and definitions”,

Measurement (2019), doi: https://doi.org/10.1016/j.measurement.2019.05.047

[16] E. J. Daniel, C. M. White, and K.A. Teague, “An inter-arrival delay jitter model using multi-

structure network delay characteristics for packet networks”, in Proc. Conf. on Signals, Systems and

Computers, pp. 17381742, 2003

https://computerworld.co/la-transicion-de-wan-sd-wan/?doing_wp_cron=1534860114.6338150501251220703125

https://computerworld.co/la-transicion-de-wan-sd-wan/?doing_wp_cron=1534860114.6338150501251220703125

http://www.networkworld.es/networking/como-elegir-una-solucion-de-redes-wan-definidas-por-software

http://www.networkworld.es/networking/como-elegir-una-solucion-de-redes-wan-definidas-por-software

http://mininet.org/

117

[17] L. Rizo-Dominguez, D. Torres-Roman, D. Munoz-Rodriguez, and C. Vargas-Rosales, Senior

Member IEEE “Jitter in IP Networks: A Cauchy Approach”

[18] A. Lacovazzi, D. Frassinelli y Y. Elovici. “On packet loss modeling: An empirical assessment” en

International Conference on the Network of the Future (NOF), London, 2017, pp. 33-39.

[19] L. Mazalan, S. Syafiqah, N. Masudi, H. Hashim, R. Abd, N. Md Tahir, N. Mohamad, R. Rosli y H.

Akmar. “Throughput analysis of LAN and WAN network based on socket buffer length using JPerf”

en IEEE International Conference on Control System, Computing and Engineering, Mindeb, 2013,

pp. 621-625.

[19] P. Göransson, C. Black y T. Culver, Software Defined Networks A Comprehensive Approach.

2nd Edición. Amsterdam: Elsevier Inc., 2017, pp. 39-60.

[20] G. Saadon, Y. Haddad y N. Simoni, “A survey of application orchestration and OSS in next-

generation network management”, Computer Standards & Interfaces, vol.62, pp. 17-31, Febrero

2019.



[22] M. karakus y A. Durresi, “A survey: Control plane scalability issues and approaches in Software-

Defined Networking (SDN)”, Computer Networks, vol.112, pp. 279-293, Enero 2017.



[24] R. Masoudi y A. Ghaffari, “Software defined networks: A survey”, Journal of Network and

Computer Applications, vol.67, pp. 1-25, Mayo 2016.

[25] D. Medhi y K. Ramasamy, Network Routing Algorithms, Protocols, and Architectures. 2nd

Edición. Amsterdam: Elsevier Inc., 2018, pp. 378-395.

[26] M. Karakus y A. Durresi, “Quality of Service (QoS) in Software Defined Networking (SDN): A

survey”, Journal of Network and Computer Applications, vol.80, pp. 200-218, Febrero 2017.



[28] Cisco networking academy, Cisco CCNA exploration 5.0,2013

[29] Digital Guide, (2017, septiembre 18), Conoce los tipos de redes más importantes [Online]

Available: https://www.1and1.es/digitalguide/servidores/know-how/los-tipos-de-redes-mas-

conocidos/

[30] Riley, C., Flannagan, M. E., Fuller, R., Khan, U., Lawson, W. A., O’Brien, K., & Walshaw, M.

Wide Area Networking (WAN). The Best Damn Cisco Internetworking Book Period, 91–188. (2003).

[31] Naomi J. Alpern and Robert J. Shimonski “Eleventh Hour Network+. Exam N10-004 Study

Guide” 2010 “Wide Area Network Topologies”

[32] ONUG SD-WAN Working Group “ONUG Software-Defined WAN Use Case” octubre 2014

https://www.1and1.es/digitalguide/servidores/know-how/los-tipos-de-redes-mas-conocidos/

https://www.1and1.es/digitalguide/servidores/know-how/los-tipos-de-redes-mas-conocidos/

118

[33] networkworld “Cómo funciona MPLS” 21 MAR 2018[ONLINE]

https://www.networkworld.es/telecomunicaciones/como-funciona-mpls

[34] J. Di and Q. Ma, “Design and implementation of SDN-base QoS traffic control method for Electric

power data center network” in IEEE International Conference on Computer and Communications

(ICCC), Chengdu, October 2016.

[35] R. Santos, C. Marie, A. Akira and L. Rodrigues, “Using Mininet for emulation and prototyping

Software-Defined Networks” in IEEE Colombian Conference on Communications and Computing

(COLCOM), Bogota, July 2014.

[36] M. Afaq, S. Rehman and W. Song, “Visualization of Elephant Flows and QoS Provisioning in

SDN-Based Networks” in Asia-Pacific Network Operations and Management Symposium

(APNOMS), Busan, September 2015.

[37] M. Haiyan, Y. Jinyao, P. Georgopoulos and B.Plattner, “Towards SDN Based Queuing Delay

Estimation,” China Communications, vol. 13, no. 3, pp. 27-36, March 2016.

[38] D. Raumer, L. Schwaighofer and G. Carle, “MonSamp: A Distributed SDN Application for QoS

Monitoring” in Federated Conference on Computer Science and Information Systems, Warsaw,

September 2014.

[39] J. Yan, H. Zhang, Q. Shuai, B. Liu and X. Guo, “HiQoS: An SDN-Based Multipath QoS Solution,”

China Communications, vol. 12, no. 5, pp. 123-133, May 2015.

[40] O. Salman, I. Elhajj, A. Chehab and A. Kayssi, “QoS Guarantee over Hybrid SDN/non-SDN

Networks” in International Conference on the Network of the Future (NOF), London, November 2017.

[41] A. Moravejosharieh, M. Watts and Y. Song, “Bandwith Reservation Approach to Improve Quality

of Service in Software-Defined Networking: A Performance Analysis” in 15th International Joint

Conference on Computer Science and Software Engineering (JCSSE), Nakhonpathom, July 2018.

[42] B. Bhattacharya and D. Das, “QoS Enhancement using Embedded Agent in OpenFlow based

SDN Node” in IEEE International Conference on Electrical, Computer and Communication

Technologies (ICECCT), Coimbatore, March 2015.

[43] E. Bonfoh, S. Medjiah and C. Chassot, “A Parsimonious Monitoring Approach for Link Bandwidth

Estimation within SDN-based Networks” in 4th IEEE Conference on Network Softwarization and

Workshops (NetSoft), Montreal, QC, September 2018.

https://www.networkworld.es/telecomunicaciones/como-funciona-mpls

119

Anexos

Código para crear la topología personalizada

"""

Adding the 'topos' dict with a key/value pair to generate our newly defined

topology enables one to pass in '--topo=mytopo' from the command line.

"""

from mininet.topo import Topo

from mininet.net import Mininet

from mininet.node import CPULimitedHost

from mininet.link import TCLink

from mininet.util import dumpNodeConnections

from mininet.log import setLogLevel

class SRTopo( Topo ):

"Simple topology example."

def __init__( self ):

"Create custom topo."

# Initialize topology

Topo.__init__( self )

# Add hosts and switches

host1 = self.addHost( 'h1' )




120

s1 = self.addSwitch('s1')







# Add links for hosts

self.addLink( host1, s1, cls=TCLink, bw=100, delay='100us', loss=0.1,

max_queue_size=1000, use_htb=True )







# Add links between switches

# Only a single link will be added here between any pair of switches

# Extra links will be added bby the script that imports this topo file

# See sr_cpqd_full.py

self.addLink( s1, s2)







121




topos = 'mytopo': ( lambda: SRTopo() )

EVALUACIÓN Y ANÁLISIS DEL RENDIMIENTO DE UNA RED DE …

Documents

Transcript of EVALUACIÓN Y ANÁLISIS DEL RENDIMIENTO DE UNA RED DE …