Universidad Nacional de Ingeniería

1. ANÁLISISE
IMPLEMENTACIÓNDE
UNAREDSDNUSANDO
CONTROLADORESOPEN
SOURCE
Un enfoque arquitectónico de
la red, que permite a la red ser
controlada de manera
inteligente y central.

2. NOMBRE O LOGOTIPO
Administrar
eficientemente un red
Desde la década pasada se ha venido
impulsando un rediseño de la red de datos
clásica, que dispone el control descentralizado, a
una red de datos futura, con el control
centralizado.
Quiénes somos
Somos egresados de la especialidad de Ingeniería
de Telecomunicaciones de la Universidad Nacional
de Ingeniería.
2

3. NOMBRE O LOGOTIPO
Equipo
Andy Juan
Sarango
Luis Felipe
Soto
Jesus Frara
Quispe
Egresado de Ingeniería de
Telecomunicaciones de la
Universidad Nacional de
Ingeniería
3
Egresado de Ingeniería de
Telecomunicaciones de la
Universidad Nacional de
Ingeniería
Actualmente es Practicante
Profesional del
Departamento “Fulfilment”
– División de Transmisión
en Viettel Perú (Bitel).
Egresado de Ingeniería de
Telecomunicaciones de la
Universidad Nacional de
Ingeniería
Actualmente es Practicante
Profesional de Preventa en
Italtel Perú.
Actualmente es Datacomm
Maintenance en Huawei
Technologies.

4. NOMBRE O LOGOTIPO
Camino a la evolución
○ Según Open Networking Fundation (ONF)
• Estática, arquitectura compleja.
• Políticas inconsistentes.
• Incapacidad de escalar
• Dependencia del vendedor
○ Según Data Center Alliance(ODCA)
• Adaptabilidad
• Automatización
• Mantenibilidad
• Gestión de modelos
• Movilidad
• Seguridad integrada
• Escalado bajo demanda
4
Características negativas de la red
tradicional
Requerimientos para una
red moderna

5. NOMBRE O LOGOTIPO
El problema
Flexibilidad y
Escalabilidad
La red tradicional posee
poca flexibilidad y en
consecuencia esto
impide que sea escalable
Gestión de la red
La falta de un gestor
adecuado para realizar
operación y
mantenimiento
Costos de equipos
El costo excesivo de los
equipos de un red
clásica y mantenimiento
de estos
Análisis de red
Se necesita analizar
topologías comunes y
complejas que puedan
saturar al controlador
5

6. NOMBRE O LOGOTIPO
Solución
6
Redes Definidas por Software (SDN)
Redes Definidas por Software (SDN)
Control Centralizado
Plano de Datos

7. NOMBRE O LOGOTIPO 7
Arquitectura de SDN
Pilares en que se basa la arquitectura SDN:
• El plano de control y el plano de datos están
desacoplados.
• La decisión de envío está basada en flujo en
lugar de la red de destino.
• El control lógico de cada dispositivo de
interconexión está centralizado en un
dispositivo externo denominado Controlador.
• La red es programable a través de un software
de aplicación que se ejecuta en el controlador.

8. NOMBRE O LOGOTIPO 8
Arquitectura de SDN
• La capa de aplicación es donde se define las
reglas y los diferentes servicios.
• La capa de control donde se ofrece una
abstracción de la red.
• La capa de datos es simplemente responsable
de reenviar paquetes.

9. NOMBRE O LOGOTIPO
Software Defined WAN – SD WAN
9
En la industria
Cisco SD WAN Fortinet Secure
SD WAN
Vmware SD WAN Huawei SD WAN Silver Peak SD
WAN

10. NOMBRE O LOGOTIPO 10
Software Defined WAN – SD WAN

11. NOMBRE O LOGOTIPO
El presente proyecto tiene como objetivos definir las topologías
que saturen al controlador para trabajar en situaciones
desfavorables. Implementar las redes en el escenario de
simulación Mininet para los controladores, analizar los
parámetros de “jitter”, “packet loss” y “delay” para cada
escenario usando los tres controladores mencionados.
OpenDayLight
Es un proyecto de
Código Abierto
Floodlight
Es un controlador SDN
desarrollado por una
comunidad abierta de
desarrolladores
Ryu
Ryu es un marco de
red definido por
software basado en
componentes
11
ANÁLISIS E
IMPLEMENTACIÓN
DE UNA RED SDN
USANDO
CONTROLADORES
OPEN SOURCE

12. NOMBRE O LOGOTIPO 12
Topología N°1

13. NOMBRE O LOGOTIPO 13
Topología N°1 Análisis de Ancho de banda y Jitter para el controlador Ryu
Bandwidth
Jitter

14. NOMBRE O LOGOTIPO 14
Topología N°1
Análisis de Ancho de banda y Jitter para el controlador
OpenDayLight
Bandwidth
Jitter

15. NOMBRE O LOGOTIPO 15
Topología N°1
Análisis de Ancho de banda y Jitter para el controlador
Floodlight
Bandwidth
Jitter

16. NOMBRE O LOGOTIPO 16
Topología N°2

17. NOMBRE O LOGOTIPO 17
Topología N°2
Análisis de Ancho de banda y Jitter para el controlador Ryu
Bandwidth
Jitter

18. NOMBRE O LOGOTIPO 18
Topología N°2
Análisis de Ancho de banda y Jitter para el controlador
OpenDayLight
Bandwidth
Jitter

19. NOMBRE O LOGOTIPO 19
Topología N°2
Análisis de Ancho de banda y Jitter para el controlador
Floodlight
Bandwidth
Jitter

20. NOMBRE O LOGOTIPO 20
Topología N°3

21. NOMBRE O LOGOTIPO 21
Topología N°3
Análisis de Ancho de banda y Jitter para el controlador Ryu
Bandwidth
Jitter

22. NOMBRE O LOGOTIPO 22
Topología N°3
Análisis de Ancho de banda y Jitter para el controlador
OpenDayLight
Bandwidth
Jitter

23. NOMBRE O LOGOTIPO 23
Topología N°3
Análisis de Ancho de banda y Jitter para el controlador
Floodlight
Bandwidth
Jitter

24. NOMBRE O LOGOTIPO
Conclusiones
En la topología 1 se observa que el controlador
Floodlight ligeramente presenta mayor BW, y el
controlador Ryu presenta menor jitter promedio.
Con respecto al delay en controlador Ryu y el
controlador OpenDayLight presetan el mismo delay
promedio, el controloador Floodlight presenta un
mayor delay.
“ ”
En la topología 2 se observa un mayor BW para el
controlador Floodlight, con respecto al jitter, el
controlador Floodlight también presenta menor
valor respecto a los otros dos controladores.
Además el controlador Floodlight presenta menor
delay promedio.
“ ”
En la topología 3 se observa un mayor BW en el
controlador OpenDayLight y un menor jitter para el
controlador Ryu. Además el menor valor de delay
lo presenta el controlador Floodlight.
“ ”
24

25. NOMBRE O LOGOTIPO
○ Del análisis de las gráficas se deduce
que el rendimiento de los controladores
varía según la topología y no se puede
determinar que alguno sea mejor que el
otro.
○ Lo que podemos obtener como resultado
es que todo va a depender de la
topología o exigencia que tengamos
para poder decidirnos por algún
controlador.
○ Para que nuestra red sea confiable
necesitamos un controlador que también
lo sea y pueda trabajar en distintos
escenarios
Resumen
Escuela Profesional de Ingeniería de Telecomunicaciones
25

26. NOMBRE O LOGOTIPO
Referencias
26
[1] Mijumbi, R., Serrat, J., Gorricho, J., Bouten, N., De Turck, F., Boutaba, R. (2016). “NetworkFunction
Virtualization: State-of-the-art and Research Challenges”, IEEE Communications Surveys&Tutorials, Volumen 18,
Issue 1.
[2] Banzekki K., Fergougui A., Elalaoui A., “Software-Defined Networking (SDN): a survey”, Security and
Communication Network, John Wiley&Son, Published online 7 February 2017 in Wiley Online Library
(wileyonlinelibrary.com). DOI: 10.1002/sec.17372017.
[3] S. Sezer, S. Scott-Hayward, P. K. Chouhan, B. Fraser, D. Lake, J. Finnegan, N. Viljoen, M. Miller, and N. Rao,
“Are we ready for sdn? implementation challenges for software-defined networks,” IEEE Communications
Magazine.
[4] Y. Zhao, L. Iannone, and M. Riguidel, “On the performance of sdn controllers: A reality check,” January
2016.

27. Gracias
IEEE ComSoc UNI
+51 997172824
comsoc.uni@gmail.com
http://reieee.uni.edu.pe/comsoc