ESTADO DEL ARTE REDES DEFINIDAS POR SOFTWARE (SDN)

Universidad Católica de Pereira Facultad De Ciencias Básicas e Ingeniería Formulación & Evaluación de Proyectos Noviembre 28 de 2014

ESTADO DEL ARTE REDES DEFINIDAS POR SOFTWARE (SDN)

ANDRÉS FELIPE RUIZ

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERIA

PROF. INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA, NOVIEMBRE 2014


ESTADO DEL ARTE REDES DEFINIDAS POR SOFTWARE (SDN)

ANDRÉS FELIPE RUIZ

Documento presentado en la asignatura de Proyecto de Grado como nota final al

Ingeniero Néstor Álzate

UNIVERSIDAD CATÓLICA DE PEREIRA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERA

PROF. INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES

PEREIRA, NOVIEMBRE 2014


NOTA DE ACEPTACIÓN

_____________________

_____________________

_____________________

_____________________

_____________________

_____________________

_____________________

_____________________

__________________________

Firma del Presidente del Jurado

_________________________

Firma del Jurado

__________________________

Firma del Jurado

Pereira, noviembre de 2014


AGRADECIMIENTOS

En primera instancia, agradezco a Dios por darme la facultad e inteligencia para llegar

a esta etapa de mi vida, y por brindarme la oportunidad de pertenecer a esta grandiosa

Universidad.

A la Universidad Católica de Pereira que mediante sus docentes e infraestructura en

general nos brinda su apoyo para fortalecer nuestros conocimientos como

estudiantes y por hacer de nosotros cada día mejores, y permitieron que nos

sintiéramos respaldados y adaptados a los principios que tiene la universidad como

institución y su visión del ser humano. También por la oportunidad de poner en

práctica los conocimientos adquiridos y evidenciar la coherencia entre teoría y

práctica.

A mi familia por el acompañamiento constante con el único fin de llegar a esta meta

propuesta y con la convicción de ser mejores personas y sentirse orgullosos de los

objetivos logrados.


DEDICATORIA

A Dios y a mi familia, quienes me motivan a ser cada día mejor persona, también quiero

agradecer al ingeniero, Néstor Álzate, que con su grupo de trabajo donde con

dedicación se logró sacar el máximo provecho de toda la carrera aprendiendo cosas

muy importantes que ayudaron a mi crecimiento como persona y profesional.


RESUMEN

La idea de las redes definidas por software (SDN), es proporcionar una

configuración más eficiente de mejor rendimiento y mayor flexibilidad para dar la

apertura a nuevos diseños innovadores de la redes, en este documento se

examina el estado del arte de las SDN ofreciendo una perspectiva histórica de

las redes programables desde las ideas iniciales a los acontecimientos actuales.

Luego presentamos la arquitectura SDN y el protocolo Openflow, se discuten

alternativas actuales para implementación de pruebas SDN basadas en

protocolos y servicios, examinando las aplicaciones actuales y futuras de las

SDN, en la exploración de las diferentes líneas de investigación prometedoras de

las SDN.

Descriptores Redes, protocolos comunicación, ONF.


2

ABSTRACT

The idea of programmable networks (SDN) is positioned to provide more efficient

configuration, better performance, and higher flexibility to accommodate innovative

network designs, this document surveys the state-of-the-art in programmable networks

with an emphasis on SDN. We provide a historic perspective of programmable networks

from early ideas to recent developments. Then we present the SDN architecture and the

OpenFlow standard in particular, discuss current alternatives for implementation and

testing of SDN-based protocols and services, examine current and future SDN

Applications, and explore promising research directions based on the SDN.

Descriptores

Network, Communications protocol, ONF.


1

TABLA DE CONTENIDO

RESUMEN .............................................................................................................. 1

TABLA DE ILUSTRACIONES ................................................................................ 3

CONTENIDO DE TABLAS ..................................................................................... 4

INTRODUCCIÓN .................................................................................................... 5

1. PROPUESTA ...................................................................................................... 6

1.1 Situación problemática ................................................................................... 6

1.2 OBJETIVOS ..................................................................................................... 7

1.2.1 Objetivo general ....................................................................................... 7

1.2.2 Objetivos específicos ............................................................................... 7

1.3 Problema .......................................................................................................... 8

1.4 Aporte práctico ............................................................................................... 9

1.5 Aporte teórico ............................................................................................... 10

2. MARCO TEÓRICO ........................................................................................... 11

2.1 Antecedentes ................................................................................................. 11

2.3 Marco conceptual .......................................................................................... 20

2.4 Alcance ........................................................................................................... 25

2.5 Marco contextual ........................................................................................... 26

3. METODOLOGÍA ............................................................................................... 27

3.1 Metodología ................................................................................................... 27

4. CONTEXTUALIZACIÓN SDN ........................................................................... 28

4.1 Introducción SDN .......................................................................................... 28


2

4.2 Arquitectura SDN .......................................................................................... 30

4.2.1 Interfaces ............................................................................................... 31

4.2.2 Controladores (The New Norm for Networks, 2013) .............................. 39

4.3 Capas Arquitectura SDN ............................................................................... 43

4.3.1 Capa de infraestructura ......................................................................... 43

4.3.2 Capa de Control ..................................................................................... 52

4.3.4 Protocolo Openflow ................................................................................ 64

4.4. Implementación SDN.................................................................................... 74

4.5 Futuras investigaciones ............................................................................... 78

4.6 Investigaciones ............................................................................................. 80

4.7 Aplicaciones SDN .......................................................................................... 82

4.8 Problemas presentes en las SDN ............................................................... 87

4.9 Tendencias de las SDN ................................................................................. 89

5. Herramienta simulación MININET WORKFLOW ........................................... 93

6. CONCLUSIONES ........................................................................................... 102

7. BIBLIOGRAFIA .............................................................................................. 104


3

TABLA DE ILUSTRACIONES

FIGURA 1. Resumen De las Redes Programables. .............................................. 16

FIGURA 2. Comparación de una red tradicional y una red SDN ........................... 28

FIGURA 3. Arquitectura SDN ................................................................................ 30

FIGURA 4. Flujos identificación openflow L1-L4. .................................................. 34

FIGURA 5. Capas arquitectura SDN ..................................................................... 43

FIGURA 6. Conexión de una topología red con los medio de transmisión ............ 44

FIGURA 7. Dispositivo Switch ............................................................................... 44

FIGURA 8. Capa de control................................................................................... 52

FIGURA 9. Muestra el diseño lógico para lenguajes de programación de alto nivel

para aplicaciones SDN. ......................................................................................... 52

FIGURA 10. Capa de Aplicaciones ....................................................................... 60

FIGURA 11. Modelo Openflow .............................................................................. 64

FIGURA 12. Muestra los componentes principales de un switch basado tecnología

openflow ................................................................................................................ 66

FIGURA 13.Cabeceras de los flujos de datos ....................................................... 66

FIGURA 14.Envio de paquetes ............................................................................. 67

FIGURA15. Proceso de los paquetes en un flujo .................................................. 68

FIGURA 16. Entrada en la tabla de flujos ............................................................. 69

FIGURA 17. Cabecera de los mensajes ............................................................... 70

FIGURA 18. Encabezado de flujos en un switch. ................................................. 70

FIGURA19. Ejemplo de una red dispositivos habilitado para OpenFlow. .............. 71

FIGURA 20. Control centralizado y control distribuido ......................................... 73


4

FIGURA 21. Comparación de una red tradicional y una red con SDN .................. 75

FIGURA 22. Ejemplo procesamiento de paquetes router programable NetFPGA. 81

GRÁFICA 23. Link de datos para posición de vuelo aeronáutico .......................... 86

FIGURA24. Tecnologías SDN con IPV6 ............................................................... 91

FIGURA 25. Red creada en Mininet ...................................................................... 97

FIGURA 26. Ejemplo escalabilidad de Mininet ...................................................... 99

FIGURA 27. Comparación de topologías .............................................................. 99

FIGURA 28. Funciones básicas mininet respecto al tiempo ............................... 100

FIGURA 29. Programas miniedit.py y consoles.py .............................................. 101

CONTENIDO DE TABLAS

TABLA 1. Software que soporta Openflow ............................................................ 32

TABLA 2. Lenguajes de programación SDN ......................................................... 37

TABLA 3. Lenguajes de Programación para SDN ............................................... 41

TABLA 4. Resumen Futuras Investigaciones ........................................................ 78

TABLA 5. Resumen de las Diferentes Investigaciones (OpenFlow Enabling

Innovation, 2011), ( k.a .thang murugan, 2013) ..................................................... 80

TABLA 6. Resumen de las aplicaciones SDN ....................................................... 82


5

INTRODUCCIÓN

Debido a los avances que hoy en día se tiene respecto a las comunicaciones, se

evidencia un crecimiento muy significativo en las redes las cuales facilitan la

interacción entre los usuarios, siendo este un elemento fundamental para enfrentar

la saturación que se presentan en los medios de comunicación y luego adaptados

a una necesidad específica.

El mercado actual muestra el aumento de compañías donde la tecnología es

participe de este crecimiento global y se cuenta con excelentes recursos que a su

vez no son suficientes para la optimización. De hecho en la actualidad se puede

contar con el desarrollo de nuevas tecnologías tanto a nivel de hardware como de

software aplicado a las redes, aunque sus conocimientos se centralizan en las

mejoras físicas, dejando ciertos parámetros a nivel de software ya establecidos.

En el presente trabajo se busca mostrar de qué forma las redes definidas por

software (SDN) pueden aportar en la mejora de la optimización para el control del

flujo de datos, en un sistema de redes de comunicación.


6

1. PROPUESTA

1.1 Situación problemática

En la actualidad las redes se han convertido en un factor crítico en el crecimiento

de las comunicaciones, de la misma manera la necesidad de poder optimizar la

transmisión de información de una forma ágil y masiva, en donde se requiere

contar con elementos cuya infraestructura sea lo suficientemente idónea para la

administración de los datos de una forma eficiente. La posibilidad de implementar

de forma alterna herramientas de software que se adapten como funcionalidad

en los sistemas de redes de la actualidad, de esta forma se tornará más agradable

y óptima para la administración de recursos que se encargan de controlar el flujo

de datos. Las redes definidas por software facilita y mejora la transmisión de

información en tiempo real, además la alternativa de usar aplicativos API en lugar

de depender de los parámetros estándares de los fabricantes de dispositivos de

comunicación.


7

1.2 OBJETIVOS

1.2.1 Objetivo general

Estado del arte de las redes definidas por software (SDN); analizando ventajas

y desventajas de su implementación.

1.2.2 Objetivos específicos

Establecer el estado de las diferentes investigaciones existentes respecto a

las SDN.

Establecer las referencias bibliográficas que condense los aspectos más

relevantes relacionados con las redes definidas por software.

Determinar los requerimientos y características para la implementación de

SDN.

Documentar toda la información obtenida durante el desarrollo del proyecto.


8

1.3 Problema

El desarrollo de dispositivos móviles, la virtualización de dispositivos de red y el

auge de servicios en la nube (internet) son algunas de las tendencias que en la

actualidad existen para la implementación de las SDN, además del crecimiento

acelerado de la trasmisión de datos donde cada vez se hace más congestionado

el flujo de información, y en ocasiones los dispositivos de hardware encargados de

hacer el empalme de transmisión se saturan, causando así retrasos y sobre

posición de los datos. No es extraño que la capacidad de los sistemas de

comunicación no se vea optimizada en su totalidad, la idea es dar a conocer este

concepto para que de esta forma se aproveche al máximo las ventajas que este

sistema de administración ofrece para controlar los paquetes datos en las

diferentes estructuras de redes de la actualidad.


9

1.4 Aporte práctico

Contar en la actualidad con dispositivos que permiten un buen desempeño en la

distribución de las redes ha permitido mejorar notablemente el uso adecuado de

la información. En la utilización de estos recursos tecnológicos se pueden prestar

mejores servicios al usuario final, y en la posibilidad de que este desarrollo se

pueda llevar a cabo de una manera íntegra se podrá usar como alternativa de las

nuevas tendencias de administración de redes , que a la vez conllevan a conocer

herramientas que permitan mejorar tecnológicamente la transmisión de

información y poder ser presentada como propuesta en la mejora de la

infraestructura lógica de las redes actualmente existentes. Si se observa el

desempeño del tráfico de datos en esta infraestructura por medio de la aplicación

de simuladores se puede ver el comportamiento de la red durante la transmisión

de paquetes de las estaciones de trabajo al servidor principal, así se puede

identificar si se presenta algún retraso en la transferencia y ofrecer mejores

alternativas para el flujo eficiente de datos. Aunque los datos que viajan a través

de la red en ocasiones son sobrecargados, y los servidores actuales poseen las

capacidades necesarias para soportar las comunicaciones, se puede encontrar

ocasiones donde se denotan colapsos de tiempo causadas por alguna

actualización o cambio en aplicativos que se ve reflejado en tiempo real. De esta

manera haciendo buen uso de los canales los cambios no serían notables para los

funcionarios y por defecto tampoco para el usuario final. Es una conceptualización

de que las nuevas tecnologías aplicables a redes pueden contribuir en gran parte

al crecimiento empresarial de las compañías existentes.


10

1.5 Aporte teórico

Las compañías más importantes de redes y todos aquellos involucrados en el

desarrollo de tecnologías que buscan como mejorar la velocidad , calidad y la

cobertura de todos los servicios que actualmente se vienen presentando , se están

ocupando en estrategias para soportar la gran capacidad masiva de datos que se

tiene y evitar que se convierta en una situación fuera de control, y para resolver

estos desafíos las organizaciones necesitan contar con una gran capacidad de

automatización de las redes, aprovechando las SDN permiten incorporar

inteligencia de software para un mayor rendimiento de la red , sin importar la

marca del hardware o algunos protocolos que ya están definidos. El uso de estos

protocolos de configuración que se realiza fuera del hardware están destinados a

generar SDN y redistribuir tráfico, uno de esos protocolos es el OpenFlow que

permite a los switches y routers de diferentes marcas poder ser programados por

software y redirigir el trafico cuando el hardware falla haciendo diferentes acciones

según sea necesario.

Es un desarrollo nuevo para la tendencia de redes actualmente a nivel del

hardware ya que estos dispositivos vienen con una configuración estándar para

cada marca en particular, varias compañías se están viendo beneficiadas con la

viabilidad de poder implementar este sistema en el mercado tecnológico, ya que

se beneficiará gran parte de la población, en donde se requiere ver las redes como

una plataforma de aplicaciones inteligente ya que la información puede ser

procesada más eficientemente.


11

2. MARCO TEÓRICO

2.1 Antecedentes

La historia de las SDN comenzó alrededor de dos décadas atrás en el momento

en que el internet superaba las perspectivas del desarrollo y la evolución de las

redes (Erickson, 2013). Donde los primeros pasos que se dieron como eran las

transferencias de archivos y el correo electrónico fueron para los desarrolladores

las aplicaciones más interesantes y que presentaban mayor uso del público en

general, de esta situación se generaron ciertas curiosidades para probar e

implementar nuevas ideas para mejorar el servicio. Estos investigadores

diseñaron y probaron nuevos protocolos de red en áreas de laboratorios muy

reducidos y simulaban el comportamiento de redes muchos más grandes, en

respuesta a esto, varios investigadores perseguían un enfoque alternativo para el

control de las redes que facilitaba abrir las redes convencionales no programables.

Por otra parte muchos de los switches comerciales soportan la interfaz de

programación de aplicaciones (API), los proveedores apoyaban a OpenFlow

incluidos en dispositivos como HP, NEC y Pronto (Floodlight OpenFlow

Controller.2013) Desde entonces esta lista se ha ampliado creando muchas

plataformas de diferentes controladores. De esta forma los programadores han

utilizado plataformas para diversas aplicaciones, tales como control acceso

dinámico, virtualizaciones de red, migración usuarios; en donde se obtuvieron los

primeros éxitos comerciales, tales como el sistema de gestión del tráfico área

ampliada de Google (S.Jain, Aug. 2013.) y plataforma de Nicira de virtualización

de red, que han recibido atención significativa de la industria.

A continuación se hace referencia a los primeros esfuerzos de las redes definidas

por software.


12

Open Signaling:

Comenzó en 1995 con una serie de trabajos en grupo dedicados a "making ATM,

Internet y telefonía móvil de redes abiertas programables " (A.T. Campbell,

1999.),en donde se hacía una hipótesis que tenía involucrado los dispositivos de

red y el software utilizado para el control que era necesario para la comunicación

de red, pero a su vez difícil de realizar, esto es debido principalmente al diseño

los switches y routers, cuya característica de configuración era limitada lo cual

hacía imposible un rápido despliegue de nuevos servicios de redes y entornos.

Su propuesta era proporcionar acceso al hardware de red mediante las interfaces

de redes abiertas, programables, esto permitiría el despliegue de nuevos servicios

a través de un entorno de programación distribuida.

Motivado por estas ideas, fue creado el grupo de trabajo IETF (internet

engineering task force), que condujo a la especificación general de gestión de

protocolo (GSMP) (A. Doria, June 2002.), protocolo de control con propósitos

generales de etiquetas de los switches. GSMP permite a un controlador

establecer y liberar las conexiones a través del switch, agregar y eliminar las

conexiones multicast, administrar puertos del switch, solicitar la información de

configuración, eliminar la reserva de recursos del dispositivo y solicitar

estadísticas. Este grupo de trabajo ha concluido oficialmente y la última propuesta

de estándares, GSMPv3N, el cual fue publicado en junio de 2002.

Active networking:

A mediados de 1990, active networking (D.L. Tennenhouse, 1997)fue una

iniciativa que propuso la idea de que la infraestructura de red fuera programable

para servicios personalizados en donde hubo dos enfoques principales para este

protocolo.

(1) Switches programables por el usuario, con transferencia de datos en banda

ancha y canales de distribución; y (2) cápsulas, eran fragmentos de programa que


13

podían llevarse en los mensajes del usuario, entonces los fragmentos de los

programas serían interpretados y ejecutados por routers.

Active networking no pudo reunir las características para controlar circunstancias

críticas en redes masivas que era transferidas en la implementación industrial y el

uso generalizado, esto debido principalmente a preocupaciones de seguridad y de

rendimiento.

DCAN:

Otra iniciativa que tuvo lugar a mediados de los noventa, es el control de ATM

redes (DCAN). (Devolved Control of ATMNetworks, 2000) El objetivo de este

proyecto fue diseñar y desarrollar la infraestructura necesaria para el control

escalable y gestión de redes de los cajeros automáticos. La hipótesis es el control

y funciones de gestión de los muchos dispositivos (switches ATM en el caso de

DCAN) debieron ser desvinculadas de los dispositivos de sí mismos y delegó a

entidades externas dedicadas a ese propósito, que es básicamente el concepto

detrás de SDN. DCAN asume un protocolo entre el administrador y la red en

donde más sobre el proyecto DCAN puede encontrarse (Leslie, 1997)]. La

propuesta de la separación del plano de control y de los datos sobre las redes de

cajeros automáticos entre otros, es el trabajo propuesto en este apartado (J.E.

Van der Merwe, 1998) donde hace referencia al control múltiple de arquitecturas

heterogéneas las cuales se pueden ejecutar simultáneamente sobre una sola red

física ATM para repartir los recursos de ese switch entre esos controladores.

4D Project:

A partir de 2004, el proyecto 4D (J. Rexford, 2004) promovía un diseño nuevo que

destacó la separación de la lógica en la toma de decisiones del enrutamiento y el

de los protocolos que rigen la interacción entre elementos de la red. Propone dar

una visión global en control del tráfico y el envío de datos. Estas ideas sirvieron de

inspiración directa para obras posteriores como NOX N. Gude, 2008), que propone


14

un "sistema operativo para redes" en el contexto de una red habilitada para

OpenFlow.

Netconf:

En 2006, el IETF grupo de trabajo para propósitos de configuración red propuso

NETCONF (Enns, 2006) como protocolo de administración para modificar la

configuración de dispositivos de red. El protocolo permite a los dispositivos de red

presentar API a través de estos dispositivos, podrían ser enviados y recibidos los

datos de configuración existentes.

Otro protocolo de gestión, ampliamente desplegado en el pasado y hasta hoy, es

el SNMP (D Case, 1990). SNMP fue propuesto a finales de los 80 y demostró ser

un protocolo muy popular de administración de red, que utiliza la interfaz de

gestión estructurada (SMI) para buscar los datos contenidos en la base de MIB

(Management Information). Utilizado para cambiar las variables en el MIB y para

modificar las configuraciónes. Más tarde se hizo evidente que a pesar de lo que

originalmente fue diseñado, SNMP no estaba siendo utilizado para configurar

equipos de red, sino más bien como una herramienta de monitorización y

rendimiento. Además se detectaron múltiples deficiencias en la adquisicion de

SNMP, el más notable de las cuales era su falta de seguridad.

NETCONF, al tiempo fue propuesto por IETF, donde fue visto por muchos como

un nuevo enfoque para la gestión de red que arreglaría las deficiencias

mencionadas en SNMP. Aunque el protocolo NETCONF logra el objetivo de

simplificar el dispositivo de configuración y actúa como un bloque de construcción

para la gestión, no hay ninguna separación entre datos y el plano de control. Lo

mismo puede afirmarse de SNMP.

Una red con NETCONF no debería considerarse como totalmente programable

sino como una funcionalidad que tendría que aplicarse al adminsitrador del

dispositivo de red para que cualquier nueva funcionalidad pueda ser

proporcionada. Además está diseñado principalmente para configuración


15

automatizada y no para habilitar el control directo de los datos, ni permitir el

despliegue rápido de aplicaciones y servicios innovadores, aunque ambos

NETCONF y SNMP son herramientas de gestión útiles que se pueden utilizar en

switches para apoyar otras soluciones que permiten las redes programables.

El grupo de trabajo NETCONF está actualmente activo y la última propuesta

estándar se publicó en junio de 2011.

Ethane:

El antecesor inmediato de OpenFlow fue SANE / proyecto Ethane (M.Casado,

2007), en 2006, define una nueva arquitectura para las redes empresariales. El

enfoque de Ethane fue sobre el uso de un controlador centralizado para gestionar

las directivas y la seguridad en la red. Similar a la SDN Ethane empleó dos

componentes: un comunicador y un controlador para verificar si un paquete

coincidía en una tabla de flujos y tenía un canal seguro para el controlador.

En contexto se convertiría en un paradigma de hoy de las SDN. De otro lado

para el control de acceso basado en la identidad del Ethane es probable que se

adecuara como una aplicación sobre un controlador de SDN, tales como NOX,

(Z.Cai, 2010) Maestro, Beacon (Beacon, 2013), SNAC (Simple Network Access

Contro l (SNAC)., 2012), Helios (Helios by nec, 2011) y entre otros más.

Openflow:

El protocolo OpenFlow muy a menudo está relacionado con las SDN. Este último

es un bloque de desarrollo para SDN que permite crear una visión global de la red

y ofrecer de acuerdo a una interfaz de programación, poder centralizar los

dispositivos de una red. OpenFlow es un protocolo abierto que nació de los

laboratorios de la Universidad OpenFlow, fue propuesto por primera vez

permitiendo a los investigadores ejecutar protocolos experimentales (R. Sherwood,

2010) en las redes de los campos de la universidad. Ahora bien Open Networking

Foundation (ONF), es un consorcio industrial que está a cargo de apoyar


16

activamente a los avances de la SDN y la estandarización de OpenFlow, que se

publica actualmente en versión el periodo 2008-2013.

En conclusión, la historia de las SDN se puede resumir en tres etapas, cada una

con sus propias contribuciones, redes activas a partir de la década de 1990 para el

2000), que introdujo funciones programables en la red, llevando a una mayor

innovación;(2) separación de plano de control y de datos (de alrededor de 2001 a

2007), que desarrolló interfaces abiertas entre planos de control y de datos; (3)

los API OpenFlow y red de los sistemas operativos (alrededor de 2007 a 2010 ),

que representó la primera adopción generalizada de una interfaz abierta y

desarrollando maneras de hacer la separación de plano de control y de datos de

forma escalable y práctica y la virtualización que desempeñó un papel importante

a lo largo de la evolución histórica de la SDN

En la figura continuación se muestra en resumen los acontecimientos de las

redes programables en los últimos 20 años.

Fuente: https://www.cs.princeton.edu/.../sdnhistory.pdf

Traído a la actualidad se evidencia un buen desarrollo en la fabricación de

equipos capaces de controlar y soportar las necesidades del usuario, que podrían

FIGURA 1. Resumen De las Redes Programables.


17

aprovechar los recursos existentes para mejorar las aplicaciones, y en lo que

respecta al tráfico de datos en la red se observa que se puede mejorar la

distribución de los paquetes, haciendo más flexible y ágil la transmisión la cual

puede ser aplicable a diferentes escenarios actualmente existentes, aunque es un

concepto nuevo. En la actualidad hay empresas como HP y Cisco, que están

apostando por esta tecnología, así mismo IBM y destaca la alianza NEC con Big

Blue.

HP (Hp, 2012) es pionera en el uso de esta tecnología en los switches aptos para

protocolos openflow, es fundador de la Open Networking Foundation, para reducir

los costos operativos de las redes y compañías.

IBM está impulsando en la demanda del nuevo hardware en los datacenter con

Switches basados en modelo openflow. Se tiene conocimiento de empresas como

HBO o JPMorgan que lo están probando”. Además de estos dos proveedores, la

consultora suma a IBM y VMware (de EMC) como las empresas más interesadas

en crecer en SDN.

Durante los días 11 al 13 de junio se celebró o en el hotel Fira Palace de

Barcelona el congreso SDN Word 2013 (mundo contacto, 2013) para debatir este

nuevo paradigma de las telecomunicaciones. Allí se dio a conocer la oferta de los

fabricantes y las experiencias que han estado teniendo, principalmente operadores

de telecomunicaciones gracias a la adopción de las redes definidas por software.

Durante la feria de tecnología de Brasil campus party 2013 se dio a conocer las

tendencias DSN por Ingeniero Palco Arquímedes.

Durante presentación de seguridad de redes en la ciudad de México fue expuesto

por Ing. Oscar Gutiérrez, BDM Enterprise Networking y Seguridad de Cisco.


18

Los anteriormente descritos son los más representativos hoy en día en lo que

respecta a las SDN, se espera poder ser presentado en otros países para poder

mostrar la importancia de su aplicación en el desarrollo de tecnologías de

comunicaciones en los diferentes escenarios, de la misma forma uno de los más

extensivos respecto a la administración de la estructura de redes tradicionales.


19

2.2 Justificación

En la actualidad las configuraciones de red se hacen principalmente a través de un

software integrado, eso implica la posibilidad de hacer cambios de una forma

rápida en tiempo real.

Día a día la integración de estos dispositivos de red en las grandes y pequeñas

empresas conlleva a tener una coherencia en la distribución de la información.

Debido a este crecimiento la idea es obtener el mejor rendimiento y control en la

distribución de paquetes que ofrecen estos equipos los cuales forman parte de las

configuraciones de redes en las estructuras existentes pero con el crecimiento de

los servicios web se llevan a una mayor necesidad , flexibilidad, escalabilidad del

ancho de banda y adaptación tecnología de estos, que puede llevar a presentar

retrasos en la transmisión debido al exigente tráfico de la información y aumento

de las aplicaciones que se presenta de manera masiva los cuales se van haciendo

necesario para que los requerimientos de las plataformas sean más robustas

para poder ejecutarse de una forma correcta y poder aprovechar los recursos

tecnológicos actualmente existentes en el mercado, abriendo así la posibilidad de

encontrar herramientas que permitan la centralización del control de la

arquitectura de redes con diferentes plataformas y la disminución en la

automatización los procesos internos .

Con la implementación de este sistema, la velocidad de transmisión aumentará de

la misma manera que el consumo de energía de los dispositivos físicos

disminuiría.

Se pretende mostrar que puede haber menos pérdidas de conexión y mejor

administración del flujo de datos.


20

2.3 Marco conceptual

Software-Definid Networking – o redes definidas por software permiten definir el

flujo de información, la modificación y personalización de dicha infraestructura de

acuerdo a las necesidades del usuario final. Por consiguiente se debe tener una

conceptualización del uso de esta terminología. A continuación se definirán dos

conceptos fundamentales para la implementación, como lo son; las redes de

computadores, y los protocolos de comunicación.

Redes:

Se puede definir una red de computadoras (Red_de_computadoras, 2013), como

el conjunto de equipos informáticos y software conectados entre sí por medio de

dispositivos físicos que envían y reciben información, comparten recursos y

ofrecer servicios. Como en todo proceso de comunicación se requiere de un

emisor, un mensaje, un medio y un receptor. La finalidad principal para la

creación de una red de computadoras es compartir los recursos y la información

en la distancia, asegurar la confiabilidad y la disponibilidad de la información,

aumentar la velocidad de transmisión de los datos y reducir el costo general de

estas acciones. La estructura y el modo de funcionamiento de las redes

informáticas actuales están definidos en varios estándares, siendo el más

importante y extendido de todos ellos el modelo TCP/IP basado en el modelo de

referencia OSI.

Este último, lo resume la estructura de una red en siete capas con funciones

concretas pero relacionadas entre sí; en TCP/IP se reducen a cuatro capas donde

existen multitud de protocolos repartidos por cada capa, los cuales también están

regidos por sus respectivos estándares.

Para poder formar una red se requieren elementos: hardware, software y

protocolos. Los elementos físicos se clasifican en dos grandes grupos: dispositivos

de usuario final (hosts) y dispositivos de red. Los dispositivos de usuario final

incluyen los computadores, impresoras, escáneres, y demás elementos que


21

brindan servicios directamente al usuario y los segundos son todos aquellos que

conectan entre sí a los dispositivos de usuario final, posibilitando su

intercomunicación. Además las redes han tenido un crecimiento constante debido

a la ampliación de los servicios en la web, aumentando así los diferentes tipos de

red.

Como es importante tener claridad sobre este concepto en el siguiente aparte se

hace referencia a los tipos de redes y su respectiva clasificación.

Red de área personal.

Red inalámbrica de área personal, o WPAN (Wireless Personal Área Network).

Red de área local, o LAN (Local Área Network).

Red de área local inalámbrica, o WLAN (Wireless Local Área Network).

Red de área de campus, o CAN (Campus Área Network).

Red de área metropolitana (metropolitan área networking o MAN, en inglés).

Redes de área amplia, o WAN (Wide Área Network).

Red de área de almacenamiento.

Red de área local virtual, o VLAN (Virtual LAN).

Continuando con las redes, están distribuidas por medio de unos parámetros que

facilitan según la necesidad la arquitectura definida, tales como:

Topología redes1:

Red en bus se caracteriza por tener un único canal de comunicaciones

(denominado bus, troncal o backbone) al cual se conectan los diferentes

dispositivos.

Red en anillo cada estación está conectada a la siguiente y la última está

conectada a la primera.

1 http://www.ecured.cu/index.php/Red_de_computadoras


22

Red en estrella las estaciones están conectadas directamente a un punto central

y todas las comunicaciones se han de hacer necesariamente a través de este.

Red en malla cada nodo está conectado a todos los otros.

Red en árbol los nodos están colocados en forma de árbol. Desde una visión

topológica, la conexión en árbol es parecida a una serie de redes en estrella

interconectadas salvo en que no tiene un nodo central.

Red mixta se da cualquier combinación de las anteriores, la aplicación de las SDN

puede ser utilizada en cualquier topología actualmente existente, permitiendo la

centralización del control, además de implicar la personalización desentendiendo

de la necesidad del usuario final, de la estructura de topología que actualmente

este último tiene instalado.

Por la direccionalidad de los datos 2

Simplex o unidireccional: un equipo terminal de datos transmite y otro recibe.

Half-duplex, semidúplex: el método o protocolo de envío de información es

bidireccional pero no simultáneo bidireccional, solo un equipo transmite a la vez.

Full-dúplex, o dúplex: los dos equipos involucrados en la comunicación lo

pueden hacer de forma simultánea, transmitir y recibir.

Por grado de autentificación: ‘Red privada: una red privada se definiría como

una red que puede usarla solo algunas personas y que están configuradas con

clave de acceso personal.

2 http://www.ecured.cu/index.php/Red_de_computadoras


23

Red de acceso público: una red pública se define como una red que puede usar

cualquier persona y no como las redes que están configuradas con clave de

acceso personal. Es una red de computadoras interconectadas, capaz de

compartir información y que permite comunicar a usuarios sin importar su

ubicación geográfica.

Por grado de difusión: una intranet es una red de pc privados que utiliza

tecnología Internet para compartir dentro de una organización parte de sus

sistemas de información y sistemas operacionales. Internet es un conjunto

descentralizado de redes de comunicación interconectadas que utilizan la familia

de protocolos TCP/IP, garantizando que las redes físicas heterogéneas que la

componen funcionen como una red lógica única, de alcance mundial.

Por servicio o función una red comercial proporciona soporte e información

para una empresa u organización con ánimo de lucro.

Red educativa: proporciona soporte e información para una organización

educativa dentro del ámbito del aprendizaje.

Red para el proceso de datos: proporciona una interfaz para intercomunicar

equipos que vayan a realizar una función de cómputo conjunta.

Protocolo openflow (Stanford OpenFlow Team, 2012):

Protocolo: es un conjunto de reglas y normas que permiten que dos o más

entidades de un sistema de comunicación se comuniquen entre ellos para

transmitir información por medio de cualquier tipo de variación de una magnitud

física.

Openflow es un protocolo estándar que permite la ejecución experimental, y para

ello incorpora el uso de dispositivos comerciales como Ethernet, routers y puntos

http://es.wikipedia.org/wiki/Telecomunicaci%C3%B3n#Sistema_de_comunicaci.C3.B3n

http://es.wikipedia.org/wiki/Informaci%C3%B3n

http://es.wikipedia.org/wiki/Magnitud_f%C3%ADsica

http://es.wikipedia.org/wiki/Magnitud_f%C3%ADsica


24

acceso inalámbrico donde se puede tener acceso a las tablas de flujo y a las

reglas que indican el direccionamiento del tráfico de la red. Se usa entre los

dispositivos de red y un controlador de tecnología emergente en la virtualización

de redes que pueden proporcionar a los usuarios flexibilidad y control para

entornos de acuerdo a especificaciones ya definidas por protocolos estándar.

De esta forma, se hace necesario contar con un método formal y lenguajes de

aplicaciones y servicios, donde se incluyen todos los dispositivos de la red, no

depender del hardware limitado que ofrecen los distintos fabricantes de estos

dispositivos. Permitiendo obtener mejores beneficios y garantizar los resultados

como:

-Visión unificada de la estructura de red

-Alta utilización

-Manejo más rápido de fallos

-Elasticidad dispositivo de red

-Actualizaciones sin pérdida.

La referencia del artículo (Shin, Nam, & Kim, 2012) muestra una relación respecto

a la arquitectura de la SDN y la interfaces de programación.

Al instalar un componente de firmware (software ubicado en el hardware) de

OpenFlow, los ingenieros tienen acceso a tablas de flujo, reglas que le indican a

los routers y a los switch, además de cómo direccionar el tráfico de la red en

donde protege las instrucciones de asignación de ruta patentadas que diferencian

el hardware de cada empresa.

SDN puede ser utilizada en cualquier tipo de red, lo que trata es de hacerlo más

programable, utilizando los nuevos protocolos de redes que hacen que la

administración de la red sea más fácil, más inteligente y con mejor automatización.


25

2.4 Alcance

Se pretende hacer una investigación exploratoria donde se busca explicar

detalladamente el concepto SDN, junto a una aproximación con la actualidad del

protocolo Openflow, ya que ambos pueden ser utilizados en cualquier tipo de

conexión. Contando además con la utilización de aplicaciones existentes y la

distribución de canales de datos según la necesidad planteada.

Lo anterior teniendo en cuenta la viabilidad desde el punto de vista tecnológico,

características y requerimientos para su implementación.


26

2.5 Marco contextual

Las SDN se han convertido con rapidez en una estrategia para enfrentar las

necesidades que se observan a nivel de redes en las empresas de hoy en día,

donde se han aumentado el crecimiento de las conexiones, y la estructuración de

los datos. Otra característica es el uso de arquitecturas de código abierto entre los

protocolos que sea creado para asegurar la interoperabilidad que conforman una

red de datos, destacándose el protocolo Openflow que se agrega como

funcionalidad a los Switches, routers y puntos de acceso inalámbrico que

actualmente lo conforman, además de contar con los recursos físicos y humanos

para implementar esta nueva tendencia de redes.

El desarrollo tecnológico en Latinoamérica (telcom system, 2013) ha ido en

aumento paulatinamente al crecimiento global, destacándose argentina, Brasil,

México como grandes potenciales en los que se podría utilizar esta tecnología,

para nuestro país es un concepto relativamente nuevo, donde las empresas

proveedoras de los servicios de comunicación no han iniciado un proceso de

actualización.

No obstante compañías como HP, CISCO cuenta ya con la tecnología para ser

implementada en el país, ya sería un proceso en donde estos proveedores y las

grandes empresas que destinan parte de su presupuesto a la implementación

tecnológica puedan tener la oportunidad de implementarlo, como ya se ha

realizado durante el presente año en países como México y Brasil, teniendo una

buena acogida, aun cuando el crecimiento de ancho de banda va en aumento.

La idea de los fabricantes es buscar nuevas estrategias de programación

centralizadas mediante software, adoptando inteligencia en la red.


27

3. METODOLOGÍA

3.1 Metodología

La implementación de la metodología adecuada que permita guiar la realización

del proyecto que actualmente se está describiendo, y por ser un concepto

relativamente nuevo donde no se cuenta con toda la información suficiente

conlleva a explorar (Sampieri, 1991) su funcionamiento e implementación,

aumentando así el grado de interés de este tema.

Por lo anterior se pretende obtener una visión más clara acerca de este concepto

apoyados de un soporte documental en donde se deposita toda la información

necesaria para el desarrollo del proyecto, y poder identificar su funcionamiento.


28

4. CONTEXTUALIZACIÓN SDN

4.1 Introducción SDN

Durante varios años se han desarrollado avances en las tecnologías de redes de

computación en comparación con otro tipo de tecnologías como son las de la

información y la comunicación. Por otro lado en cuanto a los dispositivos como

los switches y routers que son fundamentales para las redes, es evidente observar

que son fabricados con sus propias características de diseño de hardware y

software, en relación a esto se presenta una situación de desaceleración en el

progreso de las tecnologías vigentes debido a que siempre se encontraran con

nuevos servicios en donde los dispositivos deben adaptarse a las redes existentes

(Open Networking Foundation version 1.4.0 (Wire Protocol 0x05), 2013), de esta

forma se genera un incremento en los costos de administración y operación que

se observan en las distintas limitaciones de las redes actuales.

En la figura a continuación se observa una comparación entre una red tradicional y

una red definida por software. Donde las redes SDN utilizan software para

controlar los dispositivos, a diferencia de una red tradicional.

Fuente: http://www.embeddedworld.co.kr/atl/view.asp?a_id=8009

FIGURA 2. Comparación de una red tradicional y una red SDN


29

De igual manera comunidades de investigación en conjunto con los líderes del

mercado tecnológico se han estado preparando para renovar el diseño actual de

las redes, de esta forma surgen nuevos conceptos de diseño para redes como las

SDN. Tanto que las redes SDN han ganado popularidad a nivel educativo y

tecnológico siendo una propuesta innovadora procedente de anteriores

investigaciones, por otra parte SDN se ve muy relacionado con el protocolo

Openflow, este es el último bloque de desarrollo que permite tener una visión

global de la red y ofrecer una interfaz de programación y centralizar todos los

dispositivos de la red existentes. Openflow es un protocolo que fue propuesto por

primera vez por la universidad de Stanford como protocolo experimental usado en

el campo universitario, de allí nació la idea de crear una organización que en la

en la actualidad se conoce como Open Networking Fundation (ONF), este

consorcio apoya actualmente los avances de SDN durante periodo 2008-2014.0

En cuanto a los dispositivos y middlebox que constituyen las redes se observa

que poseen protocolos complejos para los administradores, que son los

responsables de la respectiva configuración de las directivas, eventos y

aplicaciones en la red. En donde se tienen que realizar modificaciones manuales,

como también algunas tareas complejas como es el acceso limitado a

herramientas de red. Más aún los estándares tradicionales de red que están

basados en las configuraciones manuales de los dispositivos previamente

fabricados los cuales son complejos y pueden ser propensos a errores y no

utilizan plenamente la capacidad de su infraestructura. Este sistema permitiría

simplificar la administración de las redes permitiendo la innovación y la evolución

de este tipo de tecnología.

Por otro lado, no se ha encontrado mayor número de publicaciones científicas

respecto a las redes definidas por software (SDN), pero para la actualidad se han

convertido en una de las soluciones más efectivas para el futuro de las redes, ya

que se caracteriza por tener control centralizado de la red y proporcionar mejores


30

configuraciones, mejor rendimiento y más flexibilidad para ser adaptados al

diseño de las redes actuales.

4.2 Arquitectura SDN

A continuación se describe la arquitectura SDN y sus principales componentes,

según las especificaciones de la ONF (Open Networking Foundation) (The New

Norm for Networks, 2013) Resumidas en la figura No.3

Fuente: ONF”Software-DefinedNetworking: The: The: The New Normfor Networks,”Open Networking Foundation, Tech. Rep., April 2013, ONF white paper.

En un sistema SDN se encuentra la interacción de tres capas: la capa de

infraestructura, capa de control y la capa de aplicaciones, a través de tres

interfaces abiertas: Southbound, Northbound, East/westbound, que son descritas

más adelante.

FIGURA 3. Arquitectura SDN


31

Para empezar las aplicaciones SDN interactúan con los controladores a través de

una interfaz llamada Northbound que se encuentra ubicada entre el controlador y

las aplicaciones. Y otra interfaz llamada Southbound que se encuentra entre el

software del controlador y los elementos de envío.

Por otra parte un aspecto importante de las SDN es el enlace que hay entre el

plano de datos y el plano de control. Donde los elementos de envío son

controlados por una interfaz abierta en donde es importante que exista

disponibilidad y seguridad.

Otro elemento fundamental es el protocolo Openflow que se implementa en los

switches entre el controlador de red y el hardware, además Openflow V.1.3.0

cuenta con un soporte de seguridad adicional que consiste en la encriptación de

la información en el proceso de intercambio entre los switches y el controlador. De

esta forma en escenarios donde se encuentran múltiples controladores, da la

facultad de otorgar accesos y permisos autorizados por el controlador.

4.2.1 Interfaces

Interfaz Southbound:

Esta interfaz de comunicación permite al programador interactuar con los

elementos de envió en la capa de infraestructura. Donde el protocolo Openflow, es

un elemento fundamental para la implementación de soluciones SDN. Por otro

lado se encuentran soluciones que no son Openflow pero que están basadas en

SDN, en donde varios proveedores utilizan sus propios protocolos, tal como lo son

Cisco Open Network enviromenet plataforma (onePK) (Helios by nec, 2011) y

juniper’s contrail (Passarella, 2012). También existen otras alternativas para

openflow, por ejemplo separación de los elementos de envío (Forces) Framework

(M.Casado, 2007), este último define una arquitectura framework con protocolos


32

asociados para estandarizar en el intercambio de información entre el controlador

las capas de envío.

A continuación se describe un concepto fundamental para la interacción entre las

capas que conforman la arquitectura:

Envío de elementos:

El envío de elementos es fundamental en la arquitectura SDN, donde

principalmente los dispositivos de hardware como los switches son utilizados para

el envío de la información, estos tienen que admitir API Southbound, ahora bien

Los switches vienen en dos formas: basados en Software (por ejemplo Open

switch (OVS) (Andrew R. Curtis, 2011) y basados en hardware habilitado para

implementaciones Openflow (por ejemplo NetFPGA) (anxi Kang, 2012). De otra

forma en el desarrollo de estas implementaciones se ven afectados ya que a

menudo se presentan retardos de tiempo en los procesos.

Para tener una visión más amplia del software que puede soportar Openflow se

resumen en la tabla a continuación

TABLA 1. Software que soporta Openflow

Description Open Source

Language Origin OpenFlow

Version Open vSwitch

OpenFlow Stock: Soft switch and con-

trol stack for hardware switching

Yes C/Python Multiple contributors

v 1.0

OpenFlow Reference

Implementation [39]

OpenFlow Stack that follows the spec-

ification

Yes C Stanford University/

Nicira Networks

v 0.8

Pica8 hardware-independent software for

hardware switching

not yet C Pica8 v 1.2

Indigo For OpenFlow on physical and hyper-

visor switches based on the Stanford reference implementation

Yes C/Lua Big Switch Networks

v 1.0

Pantou/OpenWRT

Enable Commercial OpenWRT wireless

devices with OpenFlow

Yes C - v 1.0

Fuente: ONF”Software-DefinedNetworking: The New Normfor Networks,”Open Networking Foundation, Tech. Rep., April 2013, ONF white paper.

La característica del hardware de los switches que soportan OpenFlow es que

poseen circuitos integrados específicos (ASICs). Estos proporcionan mayor

velocidad ya que poseen un largo número de puertos, pero a su vez les falta

flexibilidad e integración en las implementaciones de software. Hay varios


33

proveedores que admiten Openflow en sus switch como: HP.NEC, PRONTO,

JUNIPER, CISCO, DELL, INTEL

Mientras tanto un switch activado con Openflow puede estar subdividido en tres

elementos principales (Leslie, In Proc Integrated Network Management, 1997), una

capa de hardware(datapath) , una capa de software(control Path) y el protocolo

openflow.

1-Datapath:

Consiste en un grupo de tablas conformadas por los flujos, este realiza una

búsqueda de los paquetes y los envía, cada tabla está asociada a un conjunto de

flujos, esta acción es realizada por el switch y aprobadas por el controlador.

2-Control Path:

Es un canal que comunica el switch con el controlador que se utiliza para

propósitos de programación. Allí los comandos y los paquetes son intercambiados

a través de este canal usando el protocolo Openflow.

3-Protocolo openflow:

El protocolo Openflow proporciona los medios de comunicación entre el

controlador y switch. Permite el intercambio de mensajes que incluyen la

información sobre los paquetes enviados, y los paquetes recibidos.

Para tener una idea más clara, se describe a continuación cada uno de los

campos de la forma en que se encuentra constituido el protocolo Openflow.

Donde se encuentran campos iguales basados en 15- tuplas, un puerto de ingreso

y un paquete adicional de meta-datos con priorización precedente del flujo de

entrada.


34

FIGURA 4. Flujos identificación openflow L1-L4.

Fuente: Open Networking Foundation, OpenFlow Switch specification, October 2013, version 1.4.0 (Wire Protocol 0x05)

Este cuenta con un conjunto de tres acciones específicas que se realizan en los

paquetes que son: el envío del paquete a los puertos, envío del flujo de paquetes

al controlador y la descarga del conjunto de paquetes.

Cuenta con un contador para realizar cálculo del flujo de paquetes y de bytes por

cada uno, además del tiempo desde que inicia hasta el tiempo en que finaliza el

envío de los datos.

En relación con los mensajes, Openflow pueden categorizarse en tres tipos

principales el Switch controlador, asíncrono y el simétrico.

Los mensajes que se inician por el controlador son utilizados para administrar o

inspeccionar el estado los mensajes de controlador y switch.

Un switch puede iniciar con mensajes asíncronos con el fin de actualizar el

controlador con los eventos de la red y los cambios en el estado del switch.

Finalmente, se inician mensajes simétricos, se generan sin necesidad de una

solicitud del switch al controlador y se utilizan, por ejemplo, para poner a prueba

la dinámica de una conexión del switch de control.


35

Una vez que el paquete llega al switch, este realiza una búsqueda en las tablas

de flujo. Esta entrada se identifica únicamente por sus campos y su prioridad

donde los valores del paquete deben coincidir con una entrada. Por lo tanto, un

paquete puede ser igual a un flujo (Microflow), que coincide con un campo

denotado como comodín (Macroflow) del flujo; o en otro de los casos no

coinciden, en el caso de una coincidencia encontrada, se realiza un conjunto de

acciones tal como se define en la entrada de la tabla de flujo.

En el caso de no encontrar una coincidencia, el switch envía el paquete (o

simplemente su cabecera) al controlador para solicitarle a este una decisión.

Después de consultar las directivas el controlador responde con una nueva

entrada de flujo el cual debe ser agregado a la tabla de flujos del switch. Por otro

lado se tiene una última entrada que es utilizada por el switch para manejar los

paquetes en cola, así como los siguientes paquetes en el mismo flujo y en orden

dinámico que son remotamente configurados en el switch openflow.

Interfaz Northbound:

La interfaz Northbound (Big Switch networks, 2012) es más un conjunto de API

definidos por software que un protocolo de datos. La programación que utiliza

estas API permite a las aplicaciones SDN tener una interfaz amigable en donde

se pueden configurar la red y sus componentes. De antemano Northbound APIs

permite incluir funciones básicas de red, como ruteo, manejo de tráfico y seguridad

que permiten la administración de servicios de red en la nube, en donde los

lenguajes de programación y herramientas apropiadas para compilación de las

reglas generadas por el protocolo que son utilizadas para el análisis del estado

de la red, pueden ser comparados de acuerdo a tres significativos criterios de

diseño: nivel de abstracción, programación lógica y directivas lógicas.


36

-Nivel de abstracción: bajo nivel vs alto-nivel:

Mientras que el lenguaje de alto nivel traduce la información proveniente por el

protocolo de Openflow dentro de esta semántica, permite a los programadores

gestionar las reglas impuestas en los lenguajes de bajos nivel.

-Programación; lógica vs funcionalidad reactiva:

Muchos de los lenguajes existentes para el manejo de las redes indican tan solo

la descripción lógica, mientras el control de flujo es delegado a la implementación.

No obstante, existen dos maneras de programación diferente para expresar

directivas de red: programación lógica (LP) y programación funcional reactiva

(FRP). En la programación lógica, un programa está constituido por un conjunto de

sentencias lógicas. Esta se aplica particularmente a las áreas de inteligencia

artificial.

La característica más importante de FRP es que permite capturar en tiempo real

los diferentes comportamientos basada en eventos, por lo tanto se utiliza en áreas

como la robótica y multimedia.

-Directivas lógicas: pasiva vs activa

Un lenguaje de programación puede crear ambas directiva tanto pasivas como

activas, una directiva pasiva solo puede observar el estado de la red, mientras una

directiva activa acciona el estado de una red extendida y da respuesta a algunos

eventos. Un ejemplo de una directiva activa es el limitar el acceso a dispositivos y

usuarios basados en el uso máximo del ancho de banda.

Para tener una idea sobre los distintos lenguajes de programación framework

desarrolladas para SDN, se resumen en la siguiente tabla y se hace una breve

descripción de cada uno de ellos.


37

TABLA 2. Lenguajes de programación SDN

Framework Level of

Abstraction

Query

Language

Runtime

System

Implementation

Language

Programming

Type

Policies Type

Frenetic] high yes yes Python FRP Active NetCore high yes yes Python FRP Active Nettle low No no Haskell FRP Active FML high No no Python/C++ LP Passive Procera high No no Haskell FRP Active

Fuente :( 342959900) A Survey and a Layered of Software-Defined Networking_1

Frenetic (N Foster, 2011)

Lenguaje de programación de alto nivel constituido por dos niveles de abstracción:

La primera es una de bajo-nivel que consiste en un sistema de ejecución

trasladado a uno de alto nivel, donde se encuentran directivas y consultas de bajo

nivel, como son los comandos que contienen las reglas de los dispositivos del

switch.

El segundo es alto-nivel abstracción que e se asemeja a las consulta SQL

(lenguaje Estructurado) el lenguaje de consulta proporciona medios para leer el

estado de la red, funciones diferentes de consultas y utiliza el nivel alto para

clasificar, filtrar, transformar y agregar en los paquetes de cada flujo.

FRENETIC, ofrece operaciones donde facilitan la construcción de nuevas

herramientas reutilizables, así mismo ha venido usándose como implementación

de varios servicios en la carga de balanceo de las diferentes topologías de redes,

en la detección de fallas y la tolerancia de enrutamiento en el diseño, en

cooperación con el controlador NOX.


38

2-NetCore (C. Monsanto, 2012)

Es el sucesor de FRENETIC, esta enriquecido con librerías en las directivas

administradas y propone algoritmos para compilación del monitoreo en la

interacción del control de los switches donde se manipulan dos componentes que

deben de coincidir con el sistema de paquetes y las directivas que especifican la

ubicación de envío de estos.

Netcore compila utilizando un usuario tipo comodín clasificando las reglas

generadas en el switch (conjunto reglas envío paquetes) con el incremento en la

eficiencia el proceso envió de paquetes del switches.

3-Nettle (Hudak, 2011)

Es otro basado en FRP aprovecha la programación de redes de openflow

integrado en Haskell, un lenguaje fuertemente estandarizado. Define las funciones

de la señal que transforman los mensajes emitidos desde los switches por los

comandos generados por el controlador. Nettle permite manipular cantidades

continuas de flujos que reflejan las propiedades de una red, tal como es el

volumen de los mensajes en un enlace de red; proporciona un mecanismo para

describir los comportamientos respecto al tiempo y variables como el balanceo

dinámico de carga. Se considera como un lenguaje de programación de bajo nivel,

que lo hace más apropiado para programar controladores.

4-Procera (A. Voellmy, 2012):

Es un FRP-basado en lenguaje de alto nivel integrado en Haskell. Este ofrece un

marco referencial de framework compuesto por operadores que reaccionan a los

cambios dinámicos de las condiciones de red. Estos cambios pueden originarse

desde el switch openflow o desde eventos externos, tal como el retraso del tiempo

en la autenticación de usuarios, en las medidas de banda ancha servidores,


39

cargas, etc. Por ejemplo, el acceso a la red puede estar denegado por el uso

temporal del ancho de banda usando condiciones existentes.

5- Administración de flujo basado en programación (FML) (TL.Hinrichs, 2009)

FML proporciona una abstracción de alto nivel, contrariamente a Procera, carece

de expresividad para describir las directivas dinámicas, donde la toma de

decisiones cambia con el tiempo, En FML las directivas consisten en archivos de

estados declarativos y puede incluir adicionalmente referencias externas, para

instancias SQL, Querys. Para cada nueva implementación FML es escrito en

C++ y Python sobre NOX. Además, las políticas FML son pasivas, lo que significa

que sólo puede observar el estado de la red sin modificarlo.

De esta forma los sistemas externos de administración o servicios de redes

pueden extraer información básica acerca de la red y las directivas.

Adicionalmente los controladores pueden encontrar la manera de comunicarse

con cada uno de ellos por diferentes razones.

De tal manera que esta interfaz de comunicación permite la programación de los

controladores de las redes, abstracción del modelo de datos y otras

funcionalidades como son los controladores para el uso de aplicaciones del plano

de aplicaciones.

4.2.2 Controladores (The New Norm for Networks, 2013)

Los controladores son el núcleo de las SDN y la parte principal del NOS. Se

encuentra entre los dispositivos de red en un extremo y las aplicaciones al otro

extremo. Cada entrada de flujo que se encuentra instalada en los dispositivos

debe ser establecida por el controlador. Estos se pueden distinguir dos modos de

configuración de flujo: proactiva y reactiva.


40

En las configuraciones proactivas, las configuraciones producen antes de que

llegue el primer paquete de flujos en el switch openflow ya que son preinstaladas

en las tablas de flujo. Las principales ventajas de la configuración de flujo

proactivo es un retraso en la configuración y reducción de la frecuencia en

contacto con el controlador, si bien pueden desbordarse algunas tablas de flujo de

los switches.

Con respecto a una configuración de flujo reactiva, solo si hay entradas existentes

en las tablas de flujo, estableciendo una regla en el switch, por lo tanto el primer

paquete de flujos llega al switch y lo comunica con el controlador. Estas entradas

de flujo caducan después de un tiempo de Inactividad y deben ser eliminadas.

De esta forma el controlador compara el flujo con las directivas de la capa de

aplicación y decide sobre las acciones a tomar, luego de esto se calcula una ruta

para este flujo, de esta manera nuevas entradas son instaladas en cada switch

que pertenezcan a esta ruta, incluyendo el que inicia la solicitud.

De esta forma se tiene un patrón conocido como comodín que es aplicado al

Macroflow, este puede ser reemplazado y permite obtener un control de tráfico en

términos de escalabilidad y flexibilidad.

Con el fin de obtener cálculos en la visión general del tráfico en los switches, que

se comunican entre el controlador y los switches. Cuentan con dos formas para

realizar dicho cálculo que son: push-based vs pull-based flow.

Push-based

Los cálculos son enviados por cada switch al controlador para informar sobre

eventos específicos, como son configurar un nuevo flujo o quitar una entrada de la

tabla de flujo debido a la velocidad por el límite de tiempo. Pero este mecanismo

no informa al controlador sobre el comportamiento del flujo antes de entrar en

tiempo de espera.


41

Pull-based

El controlador aprovecha y recoge un conjunto de flujos específicos.

Opcionalmente puede solicitar un reporte específico sobre todos los flujos y los

comodines mientras que esto puede ahorrar ancho de banda del switch al

controlador.

Continuando con los controladores, a continuación se muestra una lista de los más

representativos. Actualmente soportan versión 1.0 openflow, los switches están

resumido en la tabla 3, comparado con la disponibilidad del lenguaje de

programación.

TABLA 3. Lenguajes de Programación para SDN

Controller Open Source Language Multi-threaded GUI Origin NOX yes C++/Python no Yes Nicira Networks NOX-MT yes C++ yes No Nicira Networks and Big Switch

Networks POX yes Python - Yes Nicira Networks Maestro yes Java yes No Rice University Beacon yes Java yes Yes Stanford University SNAC no C++/Python no Yes Nicira Networks RISE yes C and Ruby non-

guaranteed No NEC

Floodlight yes Java - Yes Big Switch Networks McNettle yes Nettle/Haskell no No Yale University MUL yes C yes Yes KulCloud RYU yes Python - - NTT OSRG and VA Linux OpenDaylight yes Java yes Yes Multiple contributors

Fuente: 342959900) A Survey and a Layered of Software-Defined Networking_1


42

Interfaz East/westbound:

Esta interfaz provee interfaz de comunicación, que actualmente no está

soportado por una norma aceptada.

Lo anteriormente dicho correspondía a las interfaces de conexión de las SDN,

ahora bien continuamos con la descripción de las tres capas que las conforman,

iniciando con la capa de infraestructura, seguido con la capa de control y

finalizamos con la capa de aplicaciones.


43

4.3 Capas Arquitectura SDN

FIGURA 5. Capas arquitectura SDN

Fuente: http://www.ieee.org/publications_standards/publications/rights/index.htm

4.3.1 Capa de infraestructura

Es la capa más baja de SDN donde se encuentran los dispositivos físicos o

virtuales como (switch, routers) los cuales están conectados a través de una

interfaz abierta que permite el switcheo y envío de paquetes en una conexión de

red. Estas conexiones se hacen a través de medios de transmisión diferentes,

incluyendo, cobre, redes inalámbricas, y fibra óptica. Si bien las preocupaciones

básicas están asociadas a esta capa ya que dependen de estos dispositivos para

el correcto funcionamiento de las SDN.

En la gráfica a continuación se muestra la conexión de una topología general de

red con los medios de transmisión y las interconexiones de los dispositivos.


44

FIGURA 6. Conexión de una topología red con los medio de transmisión

Fuente: http://www.ieee.org/publications_standards/publications/rights/index.htm

A-dispositivos de switcheo:

El diseño de arquitectura para switches consta de dos componentes lógicos: El

plano de datos y el plano de control como se muestra imagen a continuación.

Fuente:http://www.ieee.org/publications_standards/publications/rights/index.htm

FIGURA 7. Dispositivo Switch


45

1-Plano de control:

En el plano de control los dispositivos switch se comunican con el controlador de

la capa de control, reciben unas reglas para el envío de paquetes y las ajustan al

enlace de datos, almacenándolos en una memoria local. Como ejemplo de este

tipo de memoria se tiene memoria TCAM, GCAM Y SRAM.

Static Random Acces memory (SRAM), la cual puede llegar a ser mucho más

flexible y escalable. Ternary Content Addressable Memory (TCAM) ofrece un

rápido escaneo de velocidad para clasificación de paquetes. Pero se tiene una

ventaja y es que ambas memorias tanto la SRAM como la TCAM puede usarse

juntas para balancear en compensación entre rendimiento y flexibilidad.

Presentando ventajas competitivas, a diferencia de los dispositivos

convencionales. Tales como la ejecución y toma de decisiones de los protocolos

de enrutamiento, así se deduce que los dispositivos SDN son sencillos de fabricar

los cuales pueden conllevar a reducir la complejidad y los costos de su

implementación, en donde esta nueva arquitectura debe requerir un nuevo

diseño de hardware para los dispositivos de switcheo, clasificando las

plataformas más para la ejecución de tareas, como el testeo que se utiliza para

verificar el desempeño de estos dispositivos (H. Yin, 2012).

Respecto a los dispositivos switches, uno de los principales cambios reside en la

eficiencia de las tarjetas de memoria, estas son fundamentales ya que de ellas

depende el alcance que pueda tener la red. Haciéndose necesario que estas

tarjetas tengan un gran espacio para que puedan soportan las constantes

actualizaciones de hardware y evitar insuficiencia del almacenamiento que

puede causar pérdida de paquetes.


46

En los switch tradicionales se utilizan técnicas de administración de las memorias,

las cuales se diseñan para optimizar el rendimiento, declarar reglas en el

momento en que se encuentra en uso y el determinar el límite máximo que puede

alcanzar. De la misma forma en que se utilizan reglas en los routers

convencionales tales como la agregación y reemplazo de las directivas de la

cache (E. Karpilovsky, 2012), en otras palabras puede reducir la memoria usada

incorporando varios registros de enrutamiento como un simple prefijo o una nueva

ruta de registro. De la misma manera aumenta la velocidad del envío de los

paquetes y limita la memoria de una manera adecuada.

Otra principal mejora es la combinación de diferentes tecnologías de

almacenamiento logrando el tamaño de memoria deseado, velocidad de

procesamiento, flexibilidad, costo y complejidad moderada y contar con el

almacenamiento de hardware de diferentes características.

2- Plano de datos:

El plano de datos del switch es el proceso en donde se lleva cabo el envío de

paquetes que están basados en reglas impuestas por el plano de control.

La principal función del plano de los datos es el envío de paquetes

específicamente sobre el receptor. El proceso que se lleva a cabo inicia con la

identificación de las reglas de envío basados en direcciones IP o MAC el cual

debe coincidir con el próximo salto del paquete. En SDN los paquetes también

pueden basarse en otros parámetros, como son las áreas de las redes virtuales y

el acceso a los puertos del switch, resultando un intercambio fundamental entre

costo y la eficiencia en el procesamiento de paquetes de SDN.

Otro punto son las diferentes soluciones que infieren para el procesamiento

rápido en la trayectoria de los datos. A continuación se explican las dos áreas y

su respectivo propósito.


47

Primero los equipos basados en software usados para el procesamiento de

paquetes pueden resultar con un desempeño poco productivo. Debido a esto

requieren el uso de hardware calificado para incrementar el rendimiento (V.

Tanyingyong, 2010), en este diseño los paquetes entrantes son direccionados en

la interfaz de controlador de red (NIC). Como resultado el procesador queda libre

para la consulta de procesos.

Segundo los flujos se pueden extraer, aunque son numerosos pero a su vez cada

uno de ellos tiene menos paquetes.

Igualmente las páginas web recuperan el flujo. Por ejemplo Mice (G. Lu, 2012) en

efecto contribuye primero a los eventos frecuentes que son manejados por los

dispositivos switch, pero ellos tienen una pequeña influencia en el rendimiento

general de la red.

En este mismo orden de ideas, se tienen ejemplos de procesadores para red que

incluyen familia procesadores XPL (MIPS64 arquitectura) de Boradcom, XScale

(ARM Arq.) de INTEL, NPxNPUS, deEZchip, powerQUICC comunicaciones,

procesadores (power), desde freescale NFP series procesadores (ARM

architecture) de Netronome, Xelerated HX de Marvell, OCTEON series (MIPS64

architecture) de Cavium y CPU con propósito generales por Intel and AMD-62.

Características referentes a la capa de infraestructura (S. Kandula, 2009):

1-Rendimiento y flexibilidad

Se han introducido varias inquietudes respecto al rendimiento y la flexibilidad que

proviene de aspectos como la implementación de openflow y el límite de soporte

de los siguientes modelos:


48

-Tamaño Tabla de Flujo:

El CAM es un tipo de memoria especial y mucho más rápido que la RAM, que

permite hacer búsquedas en paralelo. Un TCAM es descendiente de la CAM,

donde puede validar tres tipos de entradas ‘0’,’1’’y‘X’ esta última es utilizada como

comodín, sin importar las condiciones, por lo tanto TCAM requiere mayor número

de entradas que las almacenadas en la memoria CAM, con la aparición de SDN el

volumen del flujo de entradas almacenadas esperado, crece respecto a una red

tradicional.

Si bien las memorias tipo TCAM son recursos relativamente costosos en términos

de ASIC y son de gran consumo.

-Método de consultas:

Existen dos tipos de tablas de flujo, HASH y LINEAR (Banerjee, 2013), HASH se

utiliza para el almacenamiento de los Microflow donde son usados para realizar

consultas rápidas. Los hash están almacenados en la SRAM STATIC (SRAM) del

switch. Pero uno de los inconvenientes de este tipo de memoria es de tipo

electrónico ya que se despega debido altas latencias.

Respecto a LINEAR TABLES se utilizan para almacenar macro-Flow usualmente

implementados en TCAM son más eficiente en las entradas de flujo y

almacenamiento de los comodines, TCAM es un chip integrado localizado en la

board del switch, el cual se encarga de disminuir el retraso en las consultas. En

contrario a esto los switches normales las consultas no son un mecanismo de

operación principal, son consideras otro tipo de operaciones, conllevando a mayor

disipación en períodos largo de latencias en los switches regulares.

-Rendimiento CPU:

Todos los flujos están controlados por un sistema CPU en los switches basados

en el protocolo Openflow, por lo tanto su desempeño será determinado por la

potencia de la CPU. Además, del uso de la CPU que es necesario para


49

encapsular el paquete que se transmitirse a la controladora donde se hace la

respectiva configuración por medio de un canal seguro .Si bien es cierto que en

las redes tradicionales la CPU de los switch no pretenden manejar la operación de

flujos limitado así la tasa de las operaciones que son soportados en switch

Openflow aparte de restringir el ancho de banda entre el switch y el controlador

debido al el límite de funcionamiento de la CPU.

-Ancho de banda entre la CPU y ASCI:

El control de la ruta de datos entre el ASCI y la CPU generalmente es lento y no

se usa con frecuencia en la operaciones de los switch tradicionales.

-Tamaño paquetes de buffer:

Los paquetes de búfer del switch están caracterizados por el tamaño limitado,

esto puede causar perdida en los paquetes a causa de la degradación.

2-Correcta entrada de flujos:

La mayoría de los errores en la configuración de la red se deben al software ya

que en el envío de los bucles se presentan fallas en el contenido de la entrega

afectado la seguridad y eficiencia de la red y así mismo no hay garantía en el

aislamiento de las mismas, además de violación al acceso de control. SHOWYRA

(R. W. Skowyra, 2013) propone un enfoque basado en métodos formales para

diseñar y verificar una red con switches openflow respecto a las propiedades y

mejora de las mismas, y propiedades relacionadas con la movilidad. (McGeer,

2012) habla de la complejidad de la verificación de las redes openflow. En esto

una red de switches Openflow es considerado como una red a cíclica de gran

tamaño con funciones booleanas, además la restricción de reglas de Openflow de

verificación .FLOWCHECKER (Al-Haj, 2010) es otra herramienta para analizar,


50

validar y ejecución End-End, configuración y unión de infraestructuras openflow.

Varios tipos de configuraciones son investigadas dentro simples tablas de flujos a

través de las diferentes inconsistencias de la infraestructura openflow.

3-Medios de transmisión

Como se ilustra en la figura 6, SDN debe abarcar todos los medios posibles de

transmisión, incluyendo el cableado, las señales inalámbricas y los medios

ópticos, con el fin de cumplir con una cobertura general donde estos medios de

transmisión tienen sus propias características, en la configuración y administración

que deberían integrarse en las SDN. Para comprender un poco más de los medios

de transmisión a continuación se hace un breve resume de los radios inalámbricos

y la conexiones de fibra óptica

A-radio inalámbrico:

Muchos avances en las tecnologías para maximizar el espectro se han venido

desarrollando para ser utilizados en las transmisiones inalámbricas. Entre ellos,

Software defined Radio (SDR) que permite una estrategia para el control de la

transmisión inalámbrica vía software (Ulversoy, 2010). Dada su naturaleza similar,

a la integrada en SDN.

Un ejemplo es que casi todos los sistemas inalámbricos utilizan Fast Fourier

Access. (FFT) probablemente con diversas longitudes FFT que propone radio

abierto para separar el protocolo inalámbrico desde el hardware y usar protocolos

con interfaz programable inalámbrica. De igual manera se tiene conocimiento de

otro estudio en donde controlador NIC modifica los cálculos de colección de

comandos APII (R. Murty, 2010). Otro sistema es el que se presentan en los

Clientes y acceso a puntos(APS), pasivamente que reportan las características de

la información que incluye el número total de paquetes , y la duración del tiempo


51

al aire utilizado por el controlador central, este se encarga de administra los link

conexión de selección y modelado de clientes.

B-fibra óptica3:

Utilizan backbone por agregación de tráfico que ofrece bajo consumo. También

puede ser adoptado en las redes ópticas para desarrollos y reconfiguración óptica

(ROADMs) optical add/drop multiplexers, integra estas tecnologías ayudando a

lograr un eficiente control del plano de datos por medio de la integración. Una red

óptica puede controlarse por múltiples mecanismos dada su naturaleza, una ruta

de datos End-to-End de origen a destino puede controlarse por varios actores,

cada uno de los de ellos controla partes en la ruta de datos. Para este caso se

tiene el ejemplo de Split-control.

Donde "Controlador B" maneja un circuito dominio óptico de switch y "Controlador

C" maneja la "switch de paquetes dominio B", pueden ser una opción y pueden

volver a utilizar técnicas avanzadas en conmutación de circuito óptico. Por

ejemplo, un GMPLS administra el plano control de la red óptica a lo largo de una

línea lógica desacoplando el puente transporte del núcleo.

3 eeexplore.ieee.org/xpl/A Survey on Software-Defined Networking


52

4.3.2 Capa de Control

FIGURA 8. Capa de control

Fuente: ONF, “Software-Defined Networking: The New Norm for Networks,”Open Networking

Foundation, Tech. Rep., April 2013,

También es conocido como plano de control, consiste un conjunto de

controladores SDN basados en software que proporciona, a través de APIS

abiertas, supervisión del comportamiento del envío de paquetes de red a través

de una interfaz abierta.

FIGURA 9. Muestra el diseño lógico para lenguajes de programación de alto

nivel para aplicaciones SDN.


53

Fuente:http://www.ieee.org/publications_standards/publications/rights/index.html -software defined networking De igual forma el controlador es el más importante componente de la arquitectura,

donde se encuentra la complejidad, y donde está representado por dos

componentes principales; los objetos y las interfaces.

Objetos:

El controlador SDN se ocupa de dos tipos de objetos. Uno se utiliza para controlar

la red, donde se encuentran las directivas impuestas por la capa de aplicación y

los paquetes protegidos en las reglas para la infraestructura. El otro se relaciona

con el monitoreo en red.

Interfaces:

El controlador tiene dos interfaces que ya fueron explicadas al comienzo de este

documento el Southbound y Northbound. Ahora bien el diseño lógico para

controladores SDN se puede desacoplar entre la construcción de cuatro

componentes. A Continuación se explica las investigaciones existentes en el

diseño dentro de los componentes señalados.

La capa de control es el puente entre la capa de aplicación y la capa de

infraestructura, el cual está conformado por cuatro principales componentes como

son: el lenguaje de alto nivel, las reglas para proceso de actualización, colección

estado de la red y condiciones para proceso de sincronización de la red.


54

1-lenguaje de alto nivel:

De hecho es una de las llaves principales es el controlador de funciones, este

establece una comunicación por medio de un protocolo entre la capa de

aplicación y la capa de control, en el proceso de envío de paquetes.

No obstante, estos lenguajes comunes de configuración solo ofrecen

abstracciones primitivas derivadas de las capacidades básicas del hardware dado

que están diseñados a solo configuraciones de hardware que suelen ser

limitados para redes dinámicas.

Una estrategia es utilizar lenguajes de alto nivel existentes como por ejemplo,

Python, C++ y Java para desarrollo de aplicaciones, los cuales están conformados

con características tales como seguridad, garantía de ancho de banda y suministro

de requerimientos de bajo nivel normalmente, este enfoque es ofrecido un

Software Development Kit (SDK).otro ejemplo seria las plataforma de Kit (onePK)

de Cisco (A. Giorgetti, 2012). La otra estrategia adopta un diseño proponiendo

nuevos lenguajes de alto nivel con características especiales para lograr un control

de comportamiento eficiente red de SDN.

2-reglas de actualización:

Están instaladas apropiadamente en los dispositivos switch para las operaciones

y son los responsables de generar los paquetes enviados por las reglas de las

directivas descritas.

Al mismo tiempo, estos dispositivos necesitan actualizarse debido a los cambios

en la configuración y el control dinámico, como puede ser dirigir el tráfico desde

una réplica a otro para el balanceo dinámico de carga, la migración de máquinas

virtuales (VM) (Caesa, 2012), además la recuperación de la red tras fallas

inesperadas conservando y garantizando las propiedades de red preferidas, tal

como los bucles libres y seguridad. De igual forma las reglas establecidas pueden

ser de diferentes formas, principalmente dos definiciones están incluidas:


55

Lógica exacta:

Usando un conjunto de reglas actualizadas con seguridad se garantiza las reglas

originales. Por nivel de paquete, donde cada paquete es procesado, por las

actualizaciones de las reglas originales.

Consistencias eventuales:

Permite que los paquetes del mismo flujo sean usados en la regla original, antes o

durante la actualización de los procedimientos, esto garantiza que los paquetes

usados después de la actualización de las reglas eventualmente proceden a

finalizar y ser enviados.

3-Colección estado de la red:

Los controladores recolectan el estado de la red para construir una visión global

de toda la red y provee a la capa de aplicación toda la información necesaria,

como por ejemplo la topología gráfica de red para la toma de decisiones en las

operaciones de red teniendo como un estado principal de la red el cálculo de

tráfico de la red, además del tiempo de duración, el número de paquetes, tamaño

y división del flujo de ancho de banda para finalizar se tienen diferentes modos y

estrategias para las características respecto a la medición y precisión, de esta

manera es fundamental encontrar ‘sweet spot’ (punto óptimo) con suficiente

exactitud, pero manteniendo baja sobrecarga.

4-Sincorización del estado de la red:

Una de las causas que puede causar un controlador centralizado son los cuellos

de botella, se tiene una solución común a este inconveniente y consisten en hacer

replicas o copias de seguridad de los controladores (P. Fonseca, 21012),


56

asegurando las operaciones adecuadas de la red pero inconsistentemente

puede resultar la toma de decisiones incorrectas en la capa de aplicación que

luego llevan a inapropiadas operaciones de red.

Existen sistemas que se usan para tener una sincronización global de la red,

ejemplo Hyperflow, que permite mostrar toda la sincronización de la red entre

múltiples controladores, este se usa para publicar y mantener constantemente

una visión de la red a través de los controladores, así cuando se detecta un el

controlador publica los eventos a través del sistema, de esta forma el nuevo

estado es promovido a los controladores actualizados inmediatamente.

Ahora bien el incremento de los procesos de los controladores utilizan las

siguientes técnicas: incremento en la capacidad de procesamiento, reducción de

frecuencias y referencias de desempeño para disminuir la frecuencia y los

requisitos de los procesos.

A- Incremento capacidad de procesamiento:

Un controlador es esencialmente una pieza del software, que por medio de la

ejecución de lotes pueden ser usados para mejorar el desempeño de los

controladores o solicitar el procesamiento de la información, como tal existen

técnicas como MAESTRO (Cai, 2011) NOXT-MT y NETTLE. Específicamente

MAESTRO está basado en una implementación de java. Este aprovecha el

rendimiento de las técnicas de optimización entrada y salida de Bach del núcleo.

B-Solicitud en la reducción de frecuencia:

El resultado de cargar el controlador puede ser pesado ya que se presentan

retrasos a largo del tiempo en controladores SDN, como tal existes diferentes

estrategia que puede ser adoptadas para disminuir la frecuencia de las

solicitudes. Uno de ellos consiste en modificar los dispositivos de los switches con

el fin de manejar las solicitudes en el plan de otra estrategia es mejorar la

estructura en la cual se organizan los dispositivos de los switches como la


57

necesidad es acceder a las reglas propiamente. Todos los paquetes pueden ser

manejados en el plano de datos sin solicitarlo a los controladores algunos

paquetes pueden tener a lo largo de la trayectoria reglas apropiadas similares y

presentes en DEVOFLOW aún ‘Mice’ flujo en los dispositivos switches (P.

Fonseca, 21012).

El propósito de Devoflow es instalar pequeños segmentos en lo posible en las

reglas de envío de los paquetes de los dispositivos switches de tal forma que

genera un rápido enrutamiento después de asignar los puertos de salida sin

requisito de los controladores, también usa disparadores después de alcanzar el

límite de las condiciones que como resultado se reduce la cantidad de datos en la

comunicación con los controladores.

C-Referencia desempeño:

El controlador de referencia se puede usar para identificar a la referencia de los

cuellos de botella y es esencial para el incremento en el proceso apto del

controlador, CEBENCH (controlador referencia) (Cai, 2011) y OFCBENCHMARK

(P. Hudak, 2012) son dos herramientas diseñadas para el controlador de

referencia, el primero hace un testeo generado por requisitos de las reglas de los

paquetes enviados observando las respuestas desde el controlador.

El segundo ofrece agregar a la estadística del controlador través del tiempo de

respuesta de los dispositivos switches agregando las estadísticas que no puede

ser suficiente para su funcionamiento.


58

Características de la capa de control:

Rendimiento, escalabilidad y fiabilidad:

Una serie de preocupaciones han sido consideras como importantes en las SDN

desde sus inicios, donde los factores más determinantes que afectan el

rendimiento y la escalabilidad en el plano de control es la cantidad de flujos por

segundo y el retraso en la ejecución. BENCHMARKS en NOX demostró que se

podía manejar al menos 30.000 nuevos flujos instalados por segundo

manteniendo un retraso de configuración flujo sub 10-ms, hay estudios que

sugieren que esta cantidad es insuficiente para superar los problemas de

escalabilidad actuales. Por ejemplo (A. Greenberg, 2009), se ha demostrado en

que el caudal promedio de llegada en un clúster de 1500 servidores es

aproximadamente 100,000 flujos por segundo. Este nivel de rendimiento, que

llevan implicaciones a gran escala.

Al incrementar el número de switches, da como resultado el aumento de mensajes

Openflow, además de presentar un retardo en las configuraciones de flujo

adicionales en las redes de gran tamaño, en donde va aumentando el número de

controladores ubicados en la red y en el diseño para implementación del

software, permitiendo elegir diferentes propuestas.

Control partición:

Surgen varias propuestas para solucionar el empleo de múltiples controladores de

acuerdo a configuraciones específicas, una de ellas es HYPERFLOW este hace

una distribución de eventos basados en el plano de control para Openflow. Donde

se usan múltiples controladores físicos de distribución NOX para mantener el

control lógico centralizado. Estos controladores comparten la misma visión y

ejecución como él lo hace el controlador en toda la red. Para obtener buenos

resultados. HYPERFLOW donde cada subconjunto de requisitos del plano de

control es localizada en el servidor local y se implementa como una aplicación


59

sobre el NOX. HYPERFLOW es resistente a particiones de red y fallas en todos

los componentes interconectados independientemente del administrador de redes

de Openflow, mientras se reduce el control del tráfico de las regiones que

atraviesa.

2-Seguridad:

la seguridad es una de las características más importantes para el plano de datos

del protocolo openflow, una de las propuestas es AVANT-GUARD (S. Shin,

2013)],que permiten al plano de control y la red sean más resistente a ataques

de saturación ,como por ejemplo TCP-SYN, el cual consta de dos módulos , el

primero se encarga del a migraciones de las conexiones , mediante la prevención

de ataques por saturación .

El segundo hace llamado a unos disparadores que se activan cuando detectan

una amenaza, este va colocado dentro el plano de datos, se realiza mediante el

proceso de cálculos de las reglas de flujo bajo ciertas condiciones definidas, pese

a la implementación de AVANT-GUARD, necesita una serie de especificaciones,

además de nuevos comandos para poder manejar las operaciones en los

módulos.


60

4.3.3 capa de aplicaciones:

FIGURA 10. Capa de Aplicaciones

Fuente: ONF, “Software-Defined Networking: The New Norm for Networks,”Open Networking Foundation, Tech. Rep., April 2013

Principalmente consisten en aplicaciones para el usuario final y el uso de las SDN

en la comunicación y servicio de la red.

Como se ilustra en la figura 10 la capa de aplicaciones se ubica sobre la capa de

control, a través de esta capa, las aplicaciones SDN pueden tener una visión

general del estado de la red, por medios de las interfaces de conexión, utilizando

lenguajes de programación de alto nivel de esta forma se pueden implementar

como estrategias físicas para las redes. SDN ofrece plataformas tal como servicio

de modelo para redes, varias son las aplicaciones construidas en esta plataforma.

A continuación describimos varias de ellas.


61

A-Adaptación de Enrutamiento:

En una red las principales funciones son el switch y el enrutamiento , pero

cuando el diseño de la distribución tiene varias falencias en donde se ve

involucrado las implementaciones y le limita de su capacidad de adaptación; para

este tipo de falencias SDN ofrece cerrar el bucle de control , la introducción nde

aplicaciones oportunas del estado de información de la red y permitiendo así la

adaptación al control de la red viendo esta oportunidad varias propuestas para

hacer uso de las plataforma SDN para mejora de diseño de enrutamiento. A

continuación se describe las aplicaciones para este dominio load balancing y

croos-layer-design.

1-Load balancíng (R. Wang, 2011):

El balanceo de cargas aprovecha las reglas de los paquetes de envío, además

del cálculo del flujo para lograr balanceo de carga. Otra metodología es la

migración de tráficos desde la carga pesada de los dispositivos Switch, además

de la reducción de en los tiempos de respuesta.

Diferentes servicios necesitan la implementación para diferente tipo de tráfico, por

ejemplo la web y email, en donde se necesitan algoritmos especialmente para el

balanceo que depende carga de trabajo.

2-Cross layer design:

se ofrece para para la integración de las diferentes capas de la infraestructura de

las SDN , un ejemplo de ello es el conocido modelo OSI de las redes , el cual

permite el intercambio de información de una capa a la otra , además SDN ofrece

plataformas para aplicaciones de fácil acceso a la información de la red.


62

B-Boundless roaming:

Se debe garantizar el acceso a internet de los dispositivos como los Smartphone

y tables ya que estos dispositivos se mueven de un lugar a otro por medio de

conexiones enviadas por una estación base , esto puede conllevar a la

interrupción del servicio prestado, ya que se limita a un mismo operador con la

misma tecnología en SDN redes de diferentes operadores con diferentes

tecnologías pueden tener un plano de control común, esto permite la movilidad

ilimitada conexiones inalámbricas entre diferentes tecnologías y transporte como

se muestra fig.6.

C-Network maintenace:

Los errores más comunes en las redes son las configuraciones por parte humana

donde se ha reportado que un 60% de la inactividad de la red es por causa de

este inconveniente (Kerravala, 2004), para que esto no suceda existen

herramientas que permiten dar un diagnóstico individual tal como: ping, tracarute,

tcpdump y Netflow. Que proporcionan una solución automática del mantenimiento

de la red, ofreciendo oportunidades de diseño en el diagnóstico y mecanismo

para automatización de la red.

D-Network security (S. A. Mehdi, 2011)

La implementación de framework y servidores proxy para proteger al red física es

notable para la seguridad, pero debido a la heterogeneidad y asegurar el uso

exclusivo de aplicaciones, implica llevar a implementar una directiva en toda la

red con cierto nivel de complejidad en la configuración de las aplicaciones.

SDN ofrece plataformas centralizadas y chequeo de directivas, además de

configuraciones para asegurar la implementación eficiente de requisitos

protección para la seguridad.


63

E-Network virtualización:

Técnica popular que permite múltiples arquitecturas de redes heterogéneas que se

encuentran en una infraestructura red compartida (Boutaba, 2009), el uso de

métodos convencionales de virtualización usan túneles VLAN,MPLS que requieren

configuraciones complejas de todos los dispositivos involucrados , en

comparación SDN ofrece plataforma que permite la configuración de todos los

dispositivos de switcheo de red desde el controlador , ejemplo LIBNETVIRT (D.

Turull, 2011) con esta plataforma se pueden desarrollar varias estrategias en la

capa de aplicación para seleccionar automáticamente la red.

F-Green networking (A. Bianzino, 2012):

Se ha convertido en un importante elemento para el diseño de las redes y la

implementación de beneficios económicos y ambientales. Se ha considerado en

diferentes enfoques, incluyendo energy-aware adaptación, tráfico, infraestructura

y aplicación. Así mismo los dispositivos switch SDN ofrece beneficios de

reducción de energía en las operaciones de red, minimizando así el consumo de

energía.

G-SDN for cloud computing (T. Benson, 2011):

La disposición de recursos informáticos y almacenamiento con el uso de

virtualización de servidores de red Cloud. SDN brinda oportunidades para ampliar

el servicio de aprovisionamiento modelo de (IAAS) más allá de la computación y

almacenamiento recursos para incluir un conjunto para el acompañamiento de los

servicios de red siendo más flexible y eficiente para la Cloud.

De otro lado los Datacenter redes para el uso de Cloud tienen unos requisitos

claves, incluyendo escalabilidad para el despliegue a gran escala independiente

de la ubicación de los recursos dinámicos.


64

4.3.4 Protocolo Openflow

Existe una serie de normas de protocolo en el uso de SDN en aplicaciones reales.

Uno de los más populares estándares de protocolo conocido como OpenFlow.

Este protocolo permite la implementación del concepto de las SDN tanto en

hardware como en software, una de sus características es que puede utilizarse el

hardware existente para analizar y desarrollar nuevos protocolos, el uso de código

es de tipo abierto implementado comercialmente en los dispositivos de conexión

de redes. Con respecto a un switch en este caso el OpenVSwitch (OVS) es uno de

los más popular, impulsado por el software de OpenFlow switch. Su núcleo está

escrito en su firmware incluyendo Pica8 y Linux 3.3 (Helios by nec, 2011) e Índigo

(Passarella, 2012) también ya disponibles.

Además se utiliza para la orientación del flujo y la configuración d para esta

acción se hace por medio de los puertos del switch, allí existe un controlador que

se encarga de administrar el control de flujo por medio del protocolo openflow,

este contiene varias tablas de flujos y se conectan con los otros dispositivos por

medio de los puertos openflow

En la siguiente figura se muestra el modelo openflow y se describe su

procedimiento de aplicación.

FIGURA 11. Modelo Openflow

Fuente: OpenFlow switch specification, version 1.0.0,”online http://www.openflow. .org/documents/openflow-spec-v1.0.0.pdf


65

Procedimiento aplicación de protocolo openflow:

Inicialmente la ruta de datos de los dispositivos de enrutamiento OpenFlow tiene

una tabla de enrutamiento vacía con algunos campos (tales como dirección IP de

origen, tipo de QoS, etc.). Esta tabla contiene varios campos de los paquetes

como son el destino de los diferentes puertos (recepción o transmisión), así como

un campo de acción que contiene el código para diversas

Acciones, tales como él envió de paquetes o recepción, esta tabla se llena

basándose en los paquetes entrantes, así cuando un nuevo paquete no tiene

ninguna coincidencia en la tabla del flujo de datos, es enviada al controlador para

que la procese. Ya sea una pérdida de paquetes o se agregue una nueva entrada

en la tabla de flujos. También se pueden programar múltiples switch simultánea

pero todavía es un sistema distribuido causando pérdida de paquetes y retraso

en el control del mismo, ya sea una pérdida de paquetes o se agregue una nueva

entrada en la tabla de flujos, aparte de esto se pueden programar múltiples switch

simultáneamente.

Las plataformas actuales de SDN, tales como NOX y Faro, permiten

programación pero es todavía difícil programarlos en un nivel bajo. Con los nuevos

protocolos (como OpenFlow) cada vez son más estándares en la industria y la

SDN es cada vez más fácil de implementar. Por otra parte el plano de control del

protocolo Openflow genera la tabla de enrutamiento mientras el plano de datos

utiliza la tabla para determinar donde se deben enviar los paquetes. OpenFlow y

SDN permiten administrar y gestionar las redes robustas.

La arquitectura típica openflow incluye 3 importantes componentes (The New

Norm for Networks, 2013).


66

(1) switches: openflow define recursos protocolo abierto para monitorear o

cambiar las tablas de flujo en los diferentes dispositivos, estos están conformados

por tres componentes importantes

FIGURA 12. Muestra los componentes principales de un switch basado

tecnología openflow

Fuente: Pag oficial open networking foundation (ONF) disponible

En https://www.opennetworking.org

a) Flujo tablas: cada una con un campo de acción asociado Cada entrada de

flujo.

Entradas de flujo:

FIGURA 13.Cabeceras de los flujos de datos

Fuente: Pag oficial open networking foundation (ONF) disponible en

https://www.opennetworking.org


67

Cada entrada contiene los siguientes campos:

Match Field: para detectar los paquetes. Compuesto por el puerto de entrada y

cabecera de los paquetes.

Counters: Para la actualización de los paquetes

Instructions: Para la modificación o conjunto de acciones en el procesamiento.

A continuación se detalla gráficamente en envió de paquetes



Este proceso se lleva a cabo por un paquete dentro de una tabla, como se

observa en la figura 15.

FIGURA 14. Envió de paquetes


68

FIGURA15. Proceso de los paquetes en un flujo



1 En primer lugar el paquete entrénate coincide con la mayor prioridad

2 Una vez detectado se aplican distintas acciones

3 Envía el dato coincidente a la siguiente tabla, junto con el conjunto de acciones

b) Un canal de comunicación: Proporciona el enlace para la transmisión de

comandos y Paquetes entre un controlador y el switch.

c) El protocolo: OpenFlow, que permite a un controlador de OpenFlow capaz de

comunicarse con cualquier Routers/Switch y definir las tablas de flujo.

De igual forma la estandarización existente de openflow asume la centralización

del control, esto es que un simple punto del controlador pueda administrar la

tabla de flujos en diferentes switch.

Estos switch se pueden clasificar en dos grupos:

Dedicados:

No soportan Cap. 2 ni 3, se puede definir como un elemento sencillo que envían

paquetes entre los puertos establecido por un proceso de control remoto. Los


69

flujos están definidos, pero limitados por la capacidades implementación de la

tabla de flujos , por ejemplo un flujo puede ser una conexión TCP , los paquetes

de una dirección MAC o IP, o todos los paquetes dentro de una red pertenecientes

al mismo puerto del switch.

Cada flujo consta de tres acciones básicas:

Envió paquetes: envío de paquetes en determinado puerto.

Encapsulamiento: el paquete se entrega al canal seguro donde se encapsula y

se envía al controlador.

Descartar paquetes flujo: como mecanismo de seguridad.

Tenemos por otro lado que Una entrada en la tabla de flujo tiene 3 campos:

1) encabezado

2) acciones

3) cálculos: realizan seguimiento de los paquetes en el número de bytes y

paquetes de cada flujo y el tiempo de ejecución.

FIGURA 16. Entrada en la tabla de flujos




70

Cada encabezado contiene 10 tuplas, cada una actúa como comodín, permitiendo

agregación de flujos. En ejemplo un flujo TCP podría ser especificado por los diez

campos, mientras switch nivel 2 puede insertar flujo que incluye el campo MAC.



Por ejemplo en los primeros switches el encabezado del flujo sería como la figura 18. FIGURA 18. Encabezado de flujos en un switch.

Fuente: Pag oficial open networking foundation (onf) disponible en ttps://www.opennetworking.org

FIGURA 17. Cabecera de los mensajes

https://www.opennetworking.org/


71

Switch habilitados con openflow:

Este tipo de dispositivos añaden a la tabla de flujos, un canal de seguridad y

protocolo Openflow, donde las tablas de flujo son administradas por el mismo

controlador, permitiendo al switch ser controlado por dos o más controladores,

con el objetivo de incrementar el rendimiento robusto del sistema, y con uno de los

aspectos más importante que es la capacidad de aislar el tráfico, que son

procesadas en las capas 2 y 3 del switch, de la siguiente manera:

Envío de paquetes

Definición conjuntos separados vlans para tráfico experimental, donde ambos

enfoques permiten que el tráfico se efectúe de forma normal, procesada por el

switch.

Fuente: Pag oficial open networking foundation (onf) disponible en https://www.opennetworking.org

FIGURA 19. Ejemplo de una red dispositivos habilitado para

OpenFlow.


72

2) Controladores: Un controlador Puede actualizar (modificar, añadir o eliminar)

flujo las entradas de la tabla de flujo. Un controlador puede ejecutar una simple

unidad de un programa en un computador estáticamente y establece la ruta de

paquetes entre un grupo de equipos de prueba durante experimentos científicos.

3) Entrada de flujo: Incluye rápidas acciones simples de operación (operaciones

de red) la mayoría switches OpenFlow soportan las siguientes tres acciones: (a)

envío de paquetes de este flujo a un puerto, (b)

Encapsulando esto donde fluyen los paquetes y envían a un controlador(c) perdida

paquetes del flujo.

OpenFlow ha pasado por muchas interacciones de estándares y actualmente

está en versión 1.4; aunque solamente versión 1.0 está disponible para el diseño

práctico de software y hardware. La segunda y posteriores versiones de OpenFlow

cambiaron la elementos, que coinciden con las estructuras que podría

especificarse en el conteo del número y tiempo de cada campo de encabezado.

Así nuevos protocolos serían más fáciles de implementar (M.Casado, 2007). Se

habla del uso de un controlador especial se utiliza para separar los bits de datos,

bits de control que permite para que la infraestructura de red comparta más

fácilmente, y un servidor es utilizado a menudo para controlar una parte de la

arquitectura openflow.

Otras de las características de Openflow es su gran flexibilidad permitiendo

incorporar varios escenarios para el diseño

.

1- Control centralizado vs control distribuido

Las siguientes imágenes muestran las opciones de control, en la primera se

observa un esquema centralizado con un único controlador mientras en la otra

imagen se observa un control distribuido , donde se puede observar cada switch

conectado a un controlador.


73



(2)- enrutamiento flujo vs agregación:

Flujo:

-Cada flujo se genera en el controlador

-Coincidencia en las entradas de flujo

-La tabla de flujo contiene una entra por flujo

Agregado:

-Una entrada abarca un grupo de flujo

-Entrada flujo o comodín

-La tabla de flujo contiene una entrada por cada categoría de flujo

(3)-reactivo vs proactivo

Reactivo:

-El primer paquete del flujo causa que el flujo se cree en el controlador

-Uso eficiente tabla de flujo

-Tiempo adicional en la configuración

FIGURA 20. Control centralizado y control distribuido


74

Proactivo:

El controlador llena tabla de flujo

No se presenta pérdida de tiempo

Pérdida conexión no interrumpe el tráfico

Requiere reglas esenciales agregadas (comodín)

4.4. Implementación SDN

Mediante el uso de SDN, (Indigo Open Source OpenFlow Switches online, 2011)

los administradores tienen la capacidad de controlar el flujo de datos, así como

alterar las características de los dispositivos de switch (o dispositivos de

enrutamiento) en la red desde una ubicación central, con aplicación de control

Implementados como módulo de software sin la necesidad de lidiar con cada

dispositivo individual (Open Networking Foundation, 2011)]. En primer lugar, es

proveedor de la nube donde es más más fácil implementar dispositivos de

diferentes fabricantes. Tradicionalmente los proveedores gran nube (como Google,

Amazon, etc.), debe adquirir routers de alto rendimiento desde el mismo proveedor

con el fin de volver a configurar fácilmente los parámetros de enrutamiento (como

la Tabla de enrutamiento actualizar período).

Enrutadores de diferentes proveedores tienen sus propias ventajas y desventajas

haciéndose un poco complejo personalizar cada router, ya que cada proveedor

puede tener su propia sintaxis de lenguaje. Ahora SDN permite a un proveedor de

la nube generar una política el enrutamiento o problemas de distribución de

recursos mientras que cada proveedor de dispositivos de enrutamiento hacen

más eficiente uso nube o llevarla a cabo.


75

FIGURA 21. Comparación de una red tradicional y una red con SDN

Fuente. S. Li and W. Liao, “Software Defined Networks”, Editorial, IEEE Comm. Mag., Feb. 2013

De igual forma la implementación de SDN, cuenta con la capacidad de adquirir un

control centralizado en tiempo real de una red y definidos por políticas para el

usuario, además esto conduce a beneficios en la optimización de las

configuraciones de red y mejorar el rendimiento de la red.

Mejora en la configuración:

La configuración es una de las funciones más importantes. (N. Handigol, 2010), en

la administración de redes, cuando se agregan nuevos equipos en una red

existente, se requieren configuraciones adecuadas para alcanzar operación

coherentes de la red. Sin embargo, debido a la heterogeneidad entre los

fabricantes de dispositivos de red y la configuración de red actual implica

normalmente un cierto nivel de procesamiento manual, este procedimiento de

configuración manual es tedioso y propenso a errores.

Dispositivos (A. Gember, 2012), incluyendo switches, routers, traductores de

direcciones de red (NAT), firewalls y balanceadores de carga, hace que sea


76

posible configurar los dispositivos de red desde un único punto automáticamente

controlado por software, toda una red puede basarse en programación,

configuración y optimización dinámica.

Mejorar el rendimiento:

El objetivo es maximizar la utilización de la inversión en las operaciones de la red,

uno de ellos es la infraestructura de red, luego debido a la existencia de diferentes

tecnologías y las partes interesadas en una sola red. (K. Jeong, 2012) aumenta el

rendimiento de la red, así los enfoques actuales a menudo enfocan en el

desempeño optimización y caracterización de un subconjunto de redes.

Obviamente, estos enfoques, están basados en información local con la

introducción de SDN se está generando una oportunidad para mejorar el

rendimiento de la red.

Apoyar la innovación:

Continuando con la evolución de las aplicaciones de red futuras, debe existir un

valor agregado la innovación que cumplen requisitos de estas aplicaciones (T.

Koponen, 2011). NEC-tunately, o cualquier nueva idea de diseño inmediatamente

enfrenta desafíos en la implementación, la experimentación y despliegue en las

redes de existentes, donde el principal obstáculo surge del propietario del

hardware ya que ampliamente es utilizado en los componentes de red

convencional. La idea detrás de los esfuerzos de la comunidad como PlanetLab (

PlanetLab., 2007) y GENI (Global Environment for Network Innovations, 2014) que

son experimentos habilitados a gran escala, donde no se puede resolver el

problema completamente. SDN fomenta la Innovación proporcionando una

plataforma de red programable para implementar nuevas Ideas, nuevas

aplicaciones y nuevos ingresos ganando servicios convenientemente y flexible.


77

Hoy en día existen muchos proyectos relacionados con las SDN y entre ellas hay

una que es la más utilizada que es el controlador NOX (A. CovingtonR. Sherwood,

2010)y la herramienta para simulación de red Mininet (Pica8 Open Network Fabric,

2011).NOX permite que la implementación de aplicaciones basados en una visión

general de la red centralizada utilizando niveles altos de algoritmos que se

encuentran distribuidos como base en los lenguajes de bajo nivel, el lenguaje de

programación que utiliza es C++, Python. Por otro lado Mininet es un simulador

que se utiliza para el prototipo de redes con OpenFlow, basados en un prototipo

de red grande, según enlaces específicos y por medio de la virtualización de redes

donde involucra los dispositivos de conexión y los controladores. Otra

característica de Mininet es que posee Una CLI (interfaz de línea de comandos)

que proporciona la interacción con la red virtual, un ejemplo seria, verificar la

conexión de dos hosts por medio de un ping, desde Mininet proporciona de un

entorno real de una manera sencilla y el uso de la herramienta OS-level que

proporciona rápidas características de virtualización de nivel de sistema operativo,

incluyendo procesos en los diferentes nombres de la red, Mininet permite crear

redes virtuales escalar a cientos de nodos desde un sola computadora.


78

4.5 Futuras investigaciones

Desde el aspecto de las investigaciones futuras se pretende fomentar una serie

de investigaciones para las SDN, desde la estandarización, la implementación y el

desarrollo. Como se resumen en la tabla a continuación:

Fuente: http. Nadeau and P. Pan, “Framework for Software Defined Networks,”Internet draft, Oct. 2011. [Online].

Estandarización:

Siendo un hecho a implementación del concepto de SDN, como complemento de

SDN, respecto a la estandarización se tiene a IETF (internet Engineering task

force) ha lanzado un framework para SDN (Pan, 2011).la ETSI industria, grupo de

especificación (ISG) para funciones de virtualización de redes (NFV), han sido

recientemente promovidas por NFV. (Network Functions Virtualisation, An

Introduction,Benefits, Enablers,Challenges & Call for Action,” White Paper, ETSI

Industry Specification Group for Network Functions Virtualization, 2012). De esta

forma se tiene un progreso respecto a la madurez de SDN, en donde se hace una

comparación de todo el potencial de su implementación hasta donde pueda llegar

TABLA 4. Resumen Futuras Investigaciones


79

desde la fragmentación de funciones y un controlador para funciones añadiendo

las especificaciones en OpenFlow que evolucionan rápidamente y permite

diferentes interpretaciones.

La actual implementación de las SDN a nivel de arquitectura aprovecha el

desacople del plano de control , así permite la eliminación de cualquier ruta sobre

los protocolos de enrutamiento desde los dispositivos switch , pero esta necesita

una adaptación generalizada , pero una trasformación inmediata de este ideal

necesitaría una inversión riesgosa para reemplazar todos los dispositivos

convenciones de las redes actuales a SDN para ser controlados remotamente .

Por otro lado Existen algunos otros inconvenientes de diseño en la

implementación actual de SDN. Por ejemplo, en OpenFlow, un encabezado de

largo se utiliza para igualar más el control, es decir la cabecera en OpenFlow es

mayor enOpenFlow1.1y1.0, estos requieren más espacio para el almacenamiento

de las reglas y más tiempo en la búsqueda, el diseño de proxy es utilizado entre

los dispositivos y el switch ya ha demostrado un efecto negativo en el rendimiento

(A. Khurshid, 2012)

Más estudios de SDN han llevado a modificar los requisitos de soporte que

requieren alta fiabilidad y accesibilidad (Rahmani, 2011) para la implementación

de sensores en redes inalámbricas debido a la alta movilidad de los usuarios (P.

Dely, 2011), por último se observa que las cuestiones que son aquí descritas no

pretenden ser exhaustivas, sin embargo todavía quedan muchos más problemas

por resolver y que pretender ser atendidos por la implementación de SDN.

Como cualquier plataforma experimental, existe un conjunto de experimentos

usando el protocolo OpenFlow para activación de redes, en la tabla a

continuación se anuncia algunos de ellos (The OpenFlow Switch Specification,

2011):


80

4.6 Investigaciones

TABLA 5. Resumen de las Diferentes Investigaciones (OpenFlow Enabling

Innovation, 2011), ( k.a .thang murugan, 2013)

Nombre Investigación Características Descripción

Administración y control de acceso a la

red

Uso de Ethane (modelo arquitectura

de redes)

Administra y define las directivas del

controlador central

-Comprueban los flujos a través de

la comunicación http

-Un controlador asocia los DNS y

DHCP para autentificación

-El controlador determina los puertos

de conexión

-Procesa los flujos enviados a otros

usuarios.

Virtualización El uso de VLANS

-Declaración de flujos en puertos

específicos

-Identifica el tráfico a través de los

puertos del switch o MAC

-Etiqueta con un IDVLAN

-El uso de controlador para autenticar

usuarios

-Localiza las rutinas de trafico

Telefonía VOIP Telefonía inalámbrica

-Generación llamadas por mecanismo

de activación wifi

-Openflow habilita la conexión con los

usuarios

-Se implementa un controlador en la

trayectoria


81

-Reprogramación nde tablas d flujo

-Permite que no haya interrupciones

nde la comunicación

Procedimiento o de flujos

-Transferencia de flujos

-Flexibilidad y menos costo de

desarrollo

-Uso de NeTFGA(router programables

-Inspecciona todos los paquetes y

mecanismos de congestión de la red

-Inspecciona la conversión de formato

entre protocolos

-Forzar los paquete que pasan por el

controlador

-No se agregan nuevas entradas de

flujos

-Uso de NETFGA para el

procesamiento rápido de los paquetes

Fuente: http://www.OpenFlowSwitch.org- OpenFlow Enabling Innovation in Campus Networks.html

gráficamente se puede mostrar lo que puede hacerse con un switch, en donde el

switch Openflow opera secuencialmente en el Path panel ,alcanzado por

NetFPGA ,donde en estos caso la tarjeta principal PCI introducido entro sistemas

Linux )se pueden colocar junto a el cable switch openflow activado.

Fuente: http://www.slideshare.ne/KellyCheah/openflow-wplatest (3)

FIGURA 22. Ejemplo procesamiento de paquetes router programable

NetFPGA.


82

4.7 Aplicaciones SDN

A continuación se da a conocer algunos ejemplos sobre el uso de las redes

definidas por software (OpenFlow Enabling Innovation in Campus Networks,

2011):

TABLA 6. Resumen de las aplicaciones SDN

Aplicaciones Necesidad características Descripción

(3)investigaciones en

internet

proporciona medios para no

cambiar redes actuales

Aplicación de SDN para

mantener la topología actual

de internet

-Separa el tráfico de datos del switch

-Esquemas de arquitectura para

esquemas direccionamiento

-Procesamiento propio de los flujos

-Dispositivos envían los paquetes

basado en reglas por el controlador

-Si no se tiene definida la directiva ,

el controlador es determinante con el

paquete

-En otro de los casos si es necesario

envía de nuevo una regla

(3)Conexiones rurales La aplicación en escasa

poblaciones

hay limitación de recursos

(zonas rurales)

-Separación de la construcción de la

red física y configuración de

administración por medio controlador

central

-la unión de las industrias de

comunicaciones que son operadas

por diferentes entidades

(3) actualización de Proporcionar datos de -permitir el ahorro de tipo -Infraestructura red basada en

openflow conectado al centro de


83

centro de datos

manera rápida y eficiente

(ejemplo Google Tiene un

gran número de centros de

datos)

económico

datos

-Resuelve los problemas de latencia

por movimiento de carga en la red

-Crea un modelo de datos gran

número de nodos para probar

rendimiento ´y ancho de banda

-(ejemplo El modelo incluyó 192

nodos con 4 Switch regulares y 2

switch de core con un Controlador de

OpenFlow. Hubo un firewalls entre los

Switch principales, OpenFlow switch y

el router. Los Autores utilizaron

también una aplicación llamada

Mininet a Prototipo de red y de prueba

para el funcionamiento)

-Uso de herramientas como Iperf,

Ping, PingAll, PingPair y CBench para

analizar configuración y el ancho de

banda posible.

Descarga dispositivos

móviles

Confidencialidad en las

aplicaciones empresariales

La utilización de Empresa

central de descarga(ecos)

-Descarga de datos en máquinas solo

aprobadas

-Controla la red y selecciona

recursos

-El controlador determina si está listo

el dispositivo para la descarga y

ahorro de energía

-Verificase cumple con requisitos de

seguridad y ah

-Si no cumple este requisito no es

permitido descargar del dispositivo

móvil.

Maquina virtuales

inalámbricas

Flexibilidad y menos costos

operacionales en redes

-Utilización de máquinas

virtuales

-Utilización de móvil IP o

DNS para mantener el

-La utilización nde métodos como

Cross Road para permitir la movilidad

de máquinas virtuales tanto en

tiempo real como fuera de línea.

-Encargar de cuidar el tráfico desde

los centros de datos

-Hacer el uso de openflow en cada


84

direccionamiento IP

-Creación de directivas para

encontrar máquinas virtuales

de otra red

centro de datos

-Usar el pseudo de las direcciones IP

y Mac para mantener las direcciones

constantes

-Cuando el controlador recibe la

solicitud de una máquina virtual,

verifica que este en la tabla, de lo

contrario, el controlador que tiene la

dirección Ip real, envía pseudo al

controlador original y este actualiza la

tablas y hace la solicitud de los

requisitos.

Detección de

intrusiones

Asegurar de los ataques en

la infraestructura virtual SDN

Uso de (NICE)esquema de

Detección y respuesta al os

ataques

-La presencia de ataques

tradicionales sobre el hypervisor,

switch virtual y VM (máquina Virtual);

(3)

-Nice logra la seguridad de la red

virtual colocada en la nube

-Utilización nde Cloud Security

Alliance (CSA) para seguridad en la

nube

-Mejorar los parches de seguridad

que no funcionan bien en los centro

de datos

-Acceso total y seguro a los centros

de datos

(2) redes empresariales

Requisitos de seguridad y

rendimiento

La aplicación de directivas

mediante la programación

para liberación de middlebox

-Ayuda a la empresas en el

monitoreo para verificar el

rendimiento de la red

-integra la funcionalidad del

controlador

-(ejemplos: incluyen NAT, Firewalls,

balanceadores de carga] y control de

acceso de red la carga.)

-Proporciona control de gestión

unificado

(2) hogar y pequeñas

empresas

Disponibilidad de

dispositivos de red bajo

costo

La utilización de

almacenamiento de datos en

redes del hogar

-La implantación de

Gateway/controlador de red Para

actuar como una "almacenamiento

datos de redes de hogar"

-La utilización nde control remoto


85

programable del switch Feamster

para detectar posibles falencias de

seguridad

-Gestionar mejor a los usuario de

forma dinámica las directivas

tradicionales de una red domestica

-identificar la identificación de la

actividad maliciosa por medio de un

sistema de detección de anomalías

(DAS)

-Descarga le ISP para monitoreo de

un gran número de redes.

(4)Redes ambientales

Reducción de la energía

funcionamiento de la red

-Los dispositivos de switch SDN , no

ofrecen beneficios de reducción de

energía

-La adaptación de SDN propone

mecanismo para determinar los datos

mínimos en un centro de datos

basado en cargas de trafico

-Apagan directamente enlaces

redundantes para operación eficiente

de energía

Comunicaciones

aeronáuticas

Explotación de métricas en

la industria aeroespacial

la presencia de porciones de

red para propósitos aéreos ,

estas son administradas por

el sistema operativo(NOS)

-La utilización nde de sistema de

administración (MS app) para la

subdivisión de dominios aéreos

-La configuración de entornos como la

virtualización para el cálculo y

referencia de los nodos ,basado en

tiempo real

-La utilización de link datos para

proveer la posición de los vuelos

-El desarrollo de APPs de uso

exclusivo aéreo , ya que no requieren

middlebox , no framework ni filtros

Fuente:http://www.OpenFlowSwitch.org- OpenFlow Enabling Innovation in Campus Networks.html


86

En el siguiente aparte se muestra gráficamente la mejor utilización de link de

datos, redes dinámicas automáticas que proveen en base de la posición de vuelo

el cual puede ser una de las posibilidades con SDN, aplicaciones que muestran

informacion de las posicion de las aeronaves , además de una serie de llaves que

directamente son configurados para variar el tráfico.

Fuente: Software Defined Networking (SON) for Aeronautical Communications, K. A. ang a Murug

FIGURA 23. Link de datos para posición de vuelo aeronáutico


87

4.8 Problemas presentes en las SDN

Vulnerabilidad den la red:

Uno de los principales problemas planteado por Openflow (N. McKeown, 2008) es

la vulnerabilidad de la red, esta puede comprometer negativamente toda la red,

aunque Openflow proporciona una copia de seguridad de los controladores, no

proporciona mecanismo de coordinación entre ellos.

Existe un componente CPRecovery (P. Fonseca, 21012) este permite la réplica de

primer controlador y el segundo en dos fases.

Fase réplica: en donde envía actualizaciones constantes del Backup.

Fase de recuperación: este se activa durante la presencia de fallas en el

controlador primario, estas fallas pueden darse error inesperado en las

aplicaciones API, o ataques al Ddos. Se cuenta con resultados que muestra la

recuperación respecto al tiempo desde el inicio de la falla hasta conexión del

Backup de 800ms.

.

La arquitectura actual de Internet:

Actualmente se presentan problemas para la verificación y aplicaciones de

seguridad en la arquitectura actual, estos se basan en la protección de hits

(antivirus) o dispositivos de red especializada (middlebox) para detección de

anomalías, requiriendo constantes actualizaciones desde el administrador de red,

ejemplo seleccionado el tráfico de la red, este punto las SDN ayudan a la mejora

de nuevos modelos de seguridad. Como por ejemplo el sistema Pedigree (F.

Farias, 2012) utilizado para redes empresariales utiliza Openflow y un núcleo de

función de SO (A. Ramachandran, 2009) constituido por dos componentes.

El Tagger: este monitorea todos los eventos de la red y Arbiter Chequea las

etiquetas generadas ordenándolas apropiadamente en la tabla de flujos de los

switch , si se encontrará una conexión no autorizada, el controlador bloquea el


88

flujo del enlace , una vez la conexión es validada , el controlador se encarga de

establecer la ruta en los switch . Que son utilizados de una manera sencilla en los

hosts y su sobrecarga de proceso es comparado con la ejecución de un antivirus.

Interdominio de enrutamiento:

La arquitectura SD-openflow (N. McKeown, 2008), fue desarrollada inicialmente

con fines experimentales, para tratar de ser extendidas a arquitecturas más

grandes requiere atender cuestiones como el problema interdominio de

enrutamiento.

Hoy en día se cuenta con un protocolo más amplio para despliegue de sistemas

autónomos, como el Gateway protocolo (BGP). En otras palabras la información

de enrutamiento entre sistemas autónomos AS depende de la dirección IP del

destinatario y del encabezado del paquete.

AS solo intercambia información y tráfico de flujo solo con direcciones vecinas,

haciendo fácil el control de flujos a lo largo de la ruta, se tiene como tareas la

integración de interconexiones diferentes de AS.

Otra alternativa es el uso de la arquitectura NOX-Openflow (Inter-AS) este sistema

propone extender dos componentes NOX. Messenger y switch Messenger y crea

un canal dedicado (port 2603) y activa permitiendo el intercambio de información

entre varios componentes de NOX. En otras palabras el canal es utilizado

independizar los componente Ínter-AS, allí se hace un llamado a los componentes

del destinatario, se selecciona el datapath y el puerto correcto para el envío de los

paquetes.

Integración de redes tradicionales:

Otro desafío que considerado es la integración con las redes tradicionales. Es

decir, las redes que no tiene capacidad de tener Openflow (infraestructura actual


89

de Internet). Es de destacar que los equipos podrían ser actualizados o en incluso

sustituidos para soporte de Openflow, pero este cambio significa altos costos de

reingeniería de la red. Por esta razón es necesaria la compatibilidad entre los

equipos nuevos con SDN y los equipos tradicionales. En el proyecto LegacyFlow

(OpenFlow Switch Specification v.1.1.0,, 2011) presenta un modelo nuevo para

estas dos arquitecturas llamado Legacy Datapath (LD) que proporciona un puente

entre las diferentes funciones de los equipos heredados. LD recibe e interpreta

los mensajes enviados desde el controlador openflow y aplicando correctas

acciones en un switch real. Adicionalmente LegacyFlow (Doyle, 2002) también

propone agregar nueva acciones al protocolo OpenFlow con el fin de integrarlo

con las redes tradicionales.

4.9 Tendencias de las SDN

Modelo I2RS:

La evolución temprana de la SDN (al, 2012) tiene un rol importante en el campo

del proceso de estándares, en particular la estandarización IETF, encargada de la

investigación de muchas tecnologías SDN existentes. Tal como I2RS o PCE, que

son estándares esenciales no solo en la guía del desarrollo de los propios

estándares, si no también colaboran con información de modelos de desarrollo.

En un futuro se espera la combinación de estos modelos estandarizados e

implementarlos. El Modelo como I2RS anteriormente anunciado que propone el

uso de programación de redes en aquellos entornos heterogéneos en que la

escalabilidad es la primera inquietud. La arquitectura de los modelos

fundamentales I2RS prevén capas distribuidas en el plano de control y plano de

datos, considerando la ruptura del plano compartido entre en control y el plano de

datos produciendo la unión y la suma del plan de control (G. Tselentis, 2010)


90

RTT es el tiempo de ida y vuelta y PPT se refiere al tiempo de procesamiento del

paquete. De otro lado en varios ambientes Por ejemplo datacenter se sobreponen

tecnologías a nivel de escala y adaptabilidad los modelos iniciales han venido

cambiando pudiendo pensar en el principal objetivo de la arquitectura de internet,

en donde es renombrado la distribución de control capas, y la separación de los

planos, otros modelos más recientes intentan proporcionar la programación al

mismo tiempo reteniendo la arquitectura de internet como característica principal.

SDN e IPV6:

Las SDN son un enfoque potencial proporciona elementos abstractos , del otro

lado tenemos la escases de direcciones ipv4 ,y donde los actuales escenarios de

conectividad requieren la necesidad de comunicación M2M que son la evolución

de las redes modernas ,apropósito de esto se evidencia la mejora funcional de

forma fácil, escalable y es debido a que los dispositivos que desarrollan los

fabricantes poseen sus propios software apropiados para cada comunicación ,

además de las limitaciones técnicas y respaldo de soporte y factores de tipo

económico y social (NOXrepo, 2011).

De otro manera controlar y administrar las redes se ha convertido la tarea más

importante de la arquitectura de la red, y es allí donde dos tecnologías pueden

ayudar estos problemas; uno de ellos es respaldo tecnológico de tecnología ipv6 y

el otro es la aplicación de SDN , da la posibilidad de unificar estos dos tipos de

tecnología de la siguiente manera : IPV6 elimina la restricciones de HOST VM y

minimiza el control , y las configuraciones complejas, (SDN) al mismo tiempo

mejora el aprovechamiento máximo del ancho de banda .


91

Fuente Myung-Ki Shin; Ki-Hyuk Nam; Hyoung-Jun Kim, "Software-defined networking (SON): A

reference architecture and open APls," ICT Convergence (ICTC), 2012 International Conference,

Daejeon, South Korea, Oct. 2012

Las SDN solamente coloca el desarrollo de aplicaciones y soluciones a problemas

que perduran, asimismo esta nueva tecnología requiere avances innovadores

respecto a la escala de tiempo y múltiples visiones a largo plazo como la

activación de redes , la centralización operacional del plano de control y el plan de

datos.

En segundo lugar la visión firme de SDN defiende un amplio control de

aplicaciones, tales como yet, OpenFlows sobre el plano de datos que limitan las

operaciones que parten de las acciones de los campos del encabezado del

paquete, ahora bien el diseño inicial de OpenFlow, apoya una amplia gama de

servicios de red requerida, mucho más sofisticada en donde se analiza y

manipula el tráfico (inspección, pérdida de paquetes, compresión y encriptación

de paquetes) usando servidores productivos o haciendo hardware de tipo

programable, o en otro de los casos ambos.

FIGURA 24. Tecnologías SDN con IPV6


92

El renovado interés de la funcionalidad del plano de datos es más sofisticado tal

como la virtualización de funciones de red ateniendo una visión de la forma de

programar las redes, sin tener que verse involucrado las limitaciones tecnológicas,

en vez de esto diseñar sencillas aplicaciones SDN basados en protocolo

Openflow. Ahora bien, en lo que se debe pensar es en qué tipo de control se

requiere para hacer un balance de estrategias teóricas y herramientas de

desarrollo habilitadas a estos procesos.


93

5. Herramienta simulación MININET WORKFLOW

Dentro de las diferentes herramientas de simulación (Open vSwitch, 2011)

compatibles con el estándar Openflow, se encuentra Mininet esta plataforma es

escalable para la emulación de redes mediante el uso de virtualización.

Mininet permite la creación de redes virtuales openflow donde incluye los

dispositivos (Openflow, 2011)] necesarios para una conexión como controladores,

switches, host y los enlaces de conexión, el cual puede ser implementado sobre

una estructura de red real o virtual, donde el SO esta modificado para permitir la

ejecución de múltiples procesos en diferentes espacio de usuarios, cada uno con

su respectiva configuración de red.

Mininet crea redes definidas por software en un mismo equipo usando procesos

de Linux, este permite la creación rápida, internación y compartición de diferentes

prototipos de red definidos por software, además ofrece las rutinas necesarias

para ser ejecutadas sobre el hardware.

Muchos son las características que tiene esta herramienta, a continuación se

nombran las que son básicas para Mininet:

Flexibilidad:

Mediante el lenguaje de programación y SO conocidos define nuevas topologías y

funcionalidades de red.

Desplegabilidad:

Implementación correcta de un prototipo funcional no debe exigir cambios en los

códigos de la configuración.


94

Interactividad:

Toda operación o gestión debe realizarse en tiempo real, como si no estuviese en

una red no virtual

Escalabilidad:

Se debe permitir escalar en entornos reales con varios switch instalados desde

una única máquina física.

Realidad:

Todo comportamiento debe coincidir en lo más posible con la realidad.

Compatibilidad:

Compatibilidad sencilla de prototipos independientes para realizar pruebas sobre

ellos o ideas desarrolladas de forma paralela.

El código utilizado sobre Mininet para un controlador openflow sobre cualquier

dispositivo de red modificado, puede exportarse a un sistema real sin necesidad

de aplicar ningún cambio.

Sus principales características:

Ofrece test fácil de usar y económico para el desarrollo aplicaciones openflow

Permite trabajo de desarrollo sobre la misma topología de manera

concurrente.

Es compatible con cualquier topología personalizada , incluyendo las parame

trizadas

Proporciona una API de lenguaje de programación Python, sencilla para

creación de redes.

Permite probar topologías de red complejas, sin necesidad de dispositivos

físicos.


95

Incluye línea comandos (CLI) para diagnóstico, además de la capacidad de

enviar órdenes a los nodos.

En comparación de otros sistemas de virtualización, como Openflow VMS o el

entorno VMNox, ofrece las siguientes ventajas:

Ejecución de arranque en segundos.

Mayor escalabilidad.

Mayor ancho de banda.

Facilidad instalación y ejecución

Desventajas:

La limitación más significativa de Mininet es la pérdida de fidelidad en el

rendimiento, en especial ante grandes cargas. Los recursos de la CPU con

multiplexados en el tiempo por el planificador que viene por defecto de Linux, o en

otro de los caso los switch transmitan a la misma velocidad, donde el envío de

software no coincide con el hardware. De esta forma la búsqueda lineal (n), para

las tablas del software no puede acercarse a (1) de la búsqueda en la memoria

TCAM es acelerada por el hardware en un switch, haciendo que en el envío de

paquetes haya pérdidas, entonces para poder cumplir con los límites de ancho de

banda y calidad de servicio en un enlace de conexión, se utiliza el programa para

el control de tráfico de Linux conocido como: El uso de contenedores (método

para la virtualización a nivel de SO en donde se puede ejecutar múltiples sistemas

Linux sobre un único host) y ofrece prioridades en la planificación para mejorar la

planificación de operación en Mininet.

En la actualidad se ejecutas sobre una sola máquina y emula solo las conexiones

cableadas, aunque no son limitaciones de consideración al contrario ofrece


96

fidelidad en el rendimiento, al ofrecer una virtualización parcial, también limita la

funcionalidad, otra limitación sería que no se puede manejar diferentes kernel del

SO simultáneamente. Todos los host comparten un mismo sistema ficheros que

se puede cambiar con el uso de CHROOT (operación que invoca procesos),

además las instancias creadas se pueden migrar en tiempo real como máquinas

virtuales.

Procedimiento

Mininet proporciona un procedimiento para crear e interactuar una red definida

por software (Minnet, 2014), así como la posibilidad de ser ejecutada sobre

hardware real. Para el procedimiento de la creación de una red en Mininet se debe

seguir el siguiente procedimiento:

A-creación:

En la creación de una red se emula los diferentes dispositivos utilizando los

distintos mecanismos de virtualización de Linux, procesos que se ejecutan en

redes de diferentes nombres y pares virtuales Ethernet.

links:

Un par Ethernet virtual actua como un cable de red conectando dos interfaces

virtuales, así los paquetes enviados a través de una interfaz son recibidos por otra

pareciendo como un puerto Ethernet funcional para todo el sistema. Los extremos

de una conexión pueden estar conectados a los pc virtuales, tales como Linux

bridge o un switch OpenFlow.

Host:

Los nombres de red son contenedores para el estado de la red que proporcionan

procesos con propiedad exclusiva de las interfaces y tablas de enrutamiento

como (ARP e IP). Donde un host en Mininet es un proceso Shell, ubicado en su


97

propio espacio de nombre, cada host posee su propia interfaz de Ethernet virtual,

y un proceso Mininet principal que genera los comandos y monitoriza las salidas.

Switch:

Los dispositivos switch Openflow proporcionan la misma semántica que lo que

proporcionan un deposito real.

Controladores:

Estos pueden estar en cualquier parte de la red, siempre y cuando la máquina en

la que lo switch en ejecución tenga conectividad a nivel IP con el controlador,

para Mininet el controlador puede estar en la propia máquina virtual de forma

nativa en un equipo host o la nube.

En la figura 25 a continuación se muestra una red creada por Mininet. Los host se

ubican en los espacios de nombre de la red y se conectan con pares Ethernet.

FIGURA 25. Red creada en Mininet

Fuente:http://github.com/mininet/mininet/wiki/Documentation


98

B-interacción:

Iniciada la red, se puede empezar la interacción con ella, por ejemplo o ejecutando

comandos, comprobar operaciones, introducir fallas, o ajustando conectividad,

para esto incluye una interfaz de comandos que es el conocedor de la red,

permitiendo a los desarrolladores controlar y gestionar una red por completo

desde una consola y de sustituir las direcciones Ip de los Host.

C-personalización:

Exporta una PAI de Python para crear topologías y diferentes tipos de nodos

personalizados, con unas pocas líneas de código suficientes para realizar

pruebas de regresión, a medida que crea una red ejecutando comandos en

múltiples nodos y por consiguiente mostrando los resultados

D-Ejecución en hardware:

Para realizar la adecuación del hardware, cada componente en Mininet debe

actuar de la misma forma que se hace físicamente. Para ello la topología virtual

debe coincidir con la física, los elementos emulados como procesos deben ser

reemplazados por los host con la propia imagen del SO , cada switch Openflow

debe ser sustituido por uno real , configurado para conectarse con el controlador,

donde no es necesario modificarlo cuando Mininet se está ejecutando el

controlador ver una red física , gracias a una interfaz con los objetos proxy

representados en el datapath del switch, en donde la CLI permite la interacción

con la red de la misma manera que antes, contando además con scripts de prueba

sin necesidad de ser modificados.


99

E-Escalabilidad:

Como se nombró anteriormente uno de los atributos importante de Mininet es la

escalabilidad, a continuación se muestra en dos tablas pruebas de rendimiento

que se realizaron.

En la primera se muestra el ancho de banda End-to-End obtenido mediante test

iperf, sobre una topología estándar, como podemos observar al aumentar el

número de switch en la red, el ancho ode banda se reduce.

FIGURA 26. Ejemplo escalabilidad de Mininet

Fuente: https://github.com/mininet/mininet/wiki/Documentation

En la segunda se hace la comparación entre distintas topologías indicando el

número de hosts (H), switch(S), en los tiempos de ejecución de inicio y stop de la

memoria en (MB)

FIGURA 27. Comparación de topologías


100


En la siguiente tabla se muestra el tiempo (ms) que requiere Mininet para realizar

funciones básicas.


Mininet ofrece un conjunto de implementaciones en Python que tiene como

objetivo servir en el momento de iniciar la ejecución de operaciones, destacan las

más importantes:

Consoles.py:Este genera un conjunto de ventanas, una para cada nodo

permitiendo la interacción y seguimiento de cada uno de ellos, además de todo

tipo ce test de la red.

FIGURA 28. Funciones básicas mininet respecto al tiempo


101

Emptynet.py:

Genera una red vacía y añade distintos nodos.

Linearbandwidth.py:

Muestra cómo crear una topología personalizada mediante programación por

medio de subclases y ejecutar pruebas sobre la misma.

Miniedit.py:

Creación de red a través de un editor gráfico.

Multitest.py:

Crea una red y se ejecutan pruebas sobre ella.

Scratchnet.py, scratchetuser.py:

Muestran como crear una red mediante el uso de funciones de bajo nivel de

Mininet.

Treeping64:

Este crea una red en forma de árbol de 64 hosts, comprueba la conectividad

empleando función ping para tres distintos datapath.

Tree1024.py:

Ejemplo con 1024 hosts y luego ejecuta CLI en ella. En al siguientes imágenes

se destaca los programas miniedit.py y consoles.py útiles para crear redes y

posterior estudio.

Fuente:https://github.com/mininet/mininet/wiki/Ideas#project-ideas-for-mininet

FIGURA 29. Programas miniedit.py y consoles.py


102

6. CONCLUSIONES

Nos fijamos en la historia de las redes programables desde sus inicios hasta los

acontecimientos de las redes actuales.

Se propuso un resumen de las redes programables examinando el campo de las

SDN.

Una vez entendida la idea de las SDN, se puede decir que es un proyecto muy

interesante, para tener en cuenta a corto y largo plazo y que persigue metas

ambiciosas.

En particular se describe en detalle la arquitectura SDN, así como el protocolo

OpenFlow.

Presentamos las implementaciones actuales de las SDN y las plataformas de

prueba.

La exploración de las futuras orientaciones de las SDN para el soporte en redes.

También se ha señalado algunas cuestiones sin resolver importantes de la

investigación de las SDN.

En la actualidad se cuenta con la formación de Open Networking Foundation que

permite el desarrollo de nuevos protocolos extenderlos en el uso de las SDN y

aplicarlo a las redes actuales.


103

Se espera la creación de una nueva generación de software para control de

redes, permiten la utilización de controladores existentes y experimentos

actuales.

En recomendaciones, como el SDN\Openflow es un campo relativamente nuevo,

y muchos temas de diseño práctico está a las espera de otras investigaciones,

estas podría ayudar comprender el estado del arte de las SDN.


104

7. BIBLIOGRAFIA

k.a .thang murugan. (2013). Software defined networking for aeronautical

Communications. aeronautical Communications, 1-20.

Devolved Control of ATMNetworks. (07 de 02 de 2000). Obtenido de

http://www.cl.cam.ac.uk/research/srg/netos/old-projects/dcan/#pub

PlanetLab. (09 de 2007).Recuperado el 10 de 2014,de http://www.planet-lab.org/

Helios by nec. (oct de 2011). Recuperado el oct de 2014, de http://www.nec.com/

Indigo Open Source OpenFlow Switches online. (08 de 2011). Recuperado el 10 de

2014, de openflow hub: http://www.openflowhub.org/display/Indigo/

NOXrepo(2011).Recuperadoel10 de 2014,de http://noxrepo.org/manual/vm_environment.html

Open Networking Foundation. (10 de 2011). Recuperado el 10 de 2014, de ONF:


Open vSwitch. (2011). Recuperado el 10 de 2014, de http://openvswitch.org/

Openflow.(2011).Recuperado el 10 de 2014, de

http://www.openflowswitch.org/wk/index.php/OpenFlowTutorial.

OpenFlow Enabling Innovation. (2011). Recuperado oct de 2014, de

http://www.OpenFlowSwitch.org- html

OpenFlow Enabling Innovation in Campus Networks. (2011). Recuperado el 10 de 2014,

de http://www.OpenFlowSwitch.org


105

OpenFlow Switch Specification v.1.1.0,. (2011). Recuperado el 10 de 2014, de


Pica8 Open Network Fabric. (2011). Recuperado el 10 de 2014, de

http://www.pica8.org/solutions/openflow.php

The OpenFlow Switch Specification. (2011). Recuperado el 10 de 2014, de

http://OpenFlowSwitch.org

Big Switch networks. (oct de 2012). Recuperado el 10 de 2014, de

http://www.bigswitch.com/sites/default/files/sdn

Hp.(agosto de 2012).Recuperado el 10 de 2014, de

http://h17007.www1.hp.com/us/en/networking/solutions/technology/sdn/#.U1A4w2J5Nik

Network Functions Virtualisation, An Introduction,Benefits, Enablers,Challenges & Call for

Action,” White Paper, ETSI Industry Specification Group for Network Functions

Virtualization. (2012). Recuperado el 09 de 2014, de http://portal.etsi.org/NFV/NFV White

Paper.pdf

Simple Network Access Contro l (SNAC). (09 de 2012). Recuperado el 10 de 2014, de

http://www.openflow.org/wp/snac/

Stanford OpenFlow Team. (2012). Recuperado el oct de 2014, de Estudio comparativo

de los distintos controladores OpenFlow: http://www.openflow.org/

Beacon. (octubre de 2013). Recuperado el octubre de 2014, de

https://openflow.stanford.edu/display/Beacon/Home

Floodlight OpenFlow Controller. . (2013). Obtenido de http://floodlight.openflowhub.org/

mundo contacto. (2013). Recuperado el OCT de 2014, de

http://mundocontact.com/mx13/temas.html


106

Open Networking Foundationversion 1.4.0 (Wire Protocol 0x05). ( de oct de 2013).

Obtenido de www.openfoundation.org

Red_de_computadoras. (2013). Recuperado el oct de 2014, de

http://www.ecured.cu/index.php/Red_de_computadoras

telcom system. (oct de 2013). Recuperado el oct de 2014, de

http://www.telco.com/index.php?page=comunicados-de-prensa&article=156

The New Norm for Networks. (2013). Open Networking Foundation tech, white paper.

Global Environment for Network Innovations. (agost de 2014). Recuperado el 10 de

2014, de http://www.geni.net/

Minnet. (2014). Obtenido de https://github.com/mininet/mininet/wiki/Documentation.

A. Bianzino, C. C. (2012). A survey of green networking research. Communications

Surveys & Tutorials, IEEE, vol. 14, 3–20.

A. CovingtonR. Sherwood, M. C. (2010). Carving research slices out of your production

networks with openflow. ACM SIGCOMM Computer Communication Review, vol. 40, no.

1, 129-130.

A. Doria, F. H. (June 2002.). General Switch Management Protocol (GSMP) V3.

(Proposed Standard), RFC 3292.

A. Gember, P. P. (2012). Toward softwaredefined middlebox networking. the 11th ACM

Workshop on Hot Topics in Networks. ACM, (págs. 11-15). Redmond, WA, USA .

A. Giorgetti, F. C. (2012). OpenFlow and PCE Architectures in Wavelength Switched

Optical Networks,” in Optical Network Design and Modeling . 16th International

Conference on. IEEE, (págs. 1-6). new york,NY.


107

A. Greenberg, S. K. (2009). The Nature of Data Center Traffic: Measurements & Analysis.

Proceedings of the 9th ACM SIGCOMM confer-ence on Internet measurement

conference,, (págs. 202-208). New York, NY.

A. Khurshid, W. Z. (2012). Proceedings of the first workshop on Hot topics in software

defined networks. VeriFlow: verifying network-wide invariants in real time, 49-54.

A. Ramachandran, Y. M. (2009). Secaran Enterprise Networks Using Traffic Tainting.

Secaran Enterprise Networks Using Traffic Tainting.

A. Voellmy, H. K. (2012). Procera;a Language for High-Level Reactive Network Contro. in

Proceedings of the first workshop on Hot topics in software defined networks, (págs. 43-

48). New York,USA.

A.T. Campbell, I. K. (1999.). Open signaling for atm. internet and mobile networks

(opensig’98), 29(1):97–108.

al, D. L. (2012). Logically Centralized? State Distribution Trade-Offs in Softwaredefined

Networks. 1st Workshop on Hot opicsinSoftware-DefinedNetworks(HotSDN12).

Al-Haj, E. A.-S. (2010). FlowChecker: Configuration Analysis and Verification of

Federated OpenFlow Infrastructures. the 3rd ACM workshop on Assurable and usable

security configuration (págs. 37-44). New York, NY: , “FlowChecker: Configuration

Analysis and Verification of Federated OpenFlow Infrastructures,” in Proceedings of , ser.

SafeConfig ’10. , USA: ACM, 20.

Andrew R. Curtis, J. C. (2011). Devoflow: scaling flow management for high-performance

networks. SIGCOMM Comput, 41(4):254–265.

anxi Kang, Z. L. (2012). . Optimizing the one big switch abstraction in software-defined

networks, 7-9.


108

Banerjee, K. K. (2013). Compact TCAM: Flow Entry Compaction in TCAM for Power

Aware SDN. Compact TCAM: Flow Entry Compaction in TCAM for Power Aware SDN,”

in DistributedComputing and Networking,vol 7730, (págs. 439-444). Berlin Heidelberg.

Boutaba, N. C. (2009). Network virtualization: state of the art and research challenges.

Communications Magazine, IEEE, vol. 47.

C. Monsanto, N. F. (2012). A Compiler and Run-Time System for Network Programming

Languages. symposium on Principles of programming languages,ser, (págs. 217-230).

New York.

Caesa, S. G. (2012). Walk the line: consistent network updates with bandwidth

guarantees. Proceedings of the first workshop on Hot topics in software defined networks,

(págs. 67-72). New York,NY, USA:.

Cai, Z. (august de 2011). Maestro: Achieving Scalability and Coordination in Centralized

Network Control Plane. new york.

D Case, M. M. (1990). Simple network management protocol (snmp). Internet

Engineering Task Force, rfc1157.

D. Turull, M. H. (2011). CloudNaaS: a cloud networking platform for enterprise

applications,. Proceedings of the 2nd ACM Symposium on Cloud Computing, ser.

SOCC’11, (págs. 8:1–8:13). New York, NY.

D.L. Tennenhouse, J. S. (1997). A survey of active network research. IEEE

Commun.Mag, 35(1):80–86,.

Doyle, M. C. (2002). Reverse Engineering of Biological Complexity. Science, vol. 295, no.

5560, 1664–1669.

E. Karpilovsky, M. C. (2012). Practical Network-Wide Compression of IP Routing Tables.

Network and Service Management, IEEE Transactions on, vol. 9, 446–458.


109

Enns, R. (2006). RFC 4741 (Proposed Standard). NETCONF Configuration Protocol,

RFC 6241.

Erickson, D. (Aug. de 2013). The Beacon OpenFlow controller. In Proc. HotSDN.

Recuperado el . , de www.openflow.org

F. Farias, J. S. (2012). A Proposal Management of the Legacy Network Environment

Using OpenflowControl Plane. Proceedings of the 2012 IEEE Network Operations and

Management Symposium, (págs. 1143-1150). new york,NY.

G. Lu, R. M. (2012). in Proceedings of the first workshop on Hot topics in software defined

networks. Using CPU as a traffic coprocessing unit in commodity switches, (págs. 31-36).

New York, NY.

G. Tselentis, A. G. (2010). Reverse Engineering of Biological Complexity. Towards the

future internet emerging trends from European research.

H. Yin, H. X. (SDNi: A Message Exchange Protocol for Software Defined Networks

(SDNS) across Multiple Domains de jun de 2012). Internet Research Task Force.

Recuperado el 10 de 2014, de http://tools.ietf.org/id/draft-yin-sdn-sdni-00.txt

Hudak, A. V. (2011). Nettle. Taking the Sting Out of Programming Network Routers

(págs. 235-249). Berlin: Heidelberg.

J. Rexford, A. G. ( 2004). Toward a wafer-thin control plane. In Proc. HotNets. Network-

wide decision making,Citeseer, 59–64.

J.E. Van der Merwe, S. R. (1998). The tempest practical framework for network

programmability. IEEE Netw, 12(3):20–28.

K. Jeong, J. K. (2012). QoS-aware Network Operating System for software defined

networking with Generalized OpenFlows. in Network Operations and Management

Symposium (NOMS), (págs. 1167–1174). Poland,NY.


110

Kerravala, Z. (2004). As the value of enterprise networks escalates, so does the need for

configuration management. Enterprise Computing & Networking, The Yankee Group

Report,, 4-9.

Leslie, J. E. (1997). In Proc Integrated Network Management V. Switchlets and dynamic

virtual atm networks,Chapman and Hall, 355– 368.

Leslie, J. E. (1997). In Proc Integrated Network Management V. Switchlets and dynamic

virtual atm networks, 355– 368.

M.Casado, M. S. (2007). Ethane: Taking control of the enterprise. ACM SIGCOMM

Computer Commun. Review, 37(4):1–12.

McGeer, R. (2012). Satisfiability,” in Communications (ICC). IEEE International

Conference , (págs. 6638–6644). new york.

N Foster, R. H. (2011). Frenetic. A Network Programming Language vol 46, 279–291.

N. Gude, T. K. (2008). Nox: towards an operating system for networks. ACM SIGCOMM

Computer Commun. Review38(3), 105–110.

N. Handigol, S. S. (2010). Load-balancing as a network primitive. 9th GENIEngineering

Conference (Plenary). Stanford,NY.

N. McKeown, T. A. (2008). OpenFlow: Enabling Innovation in Campus Networks,. ACM

SIGCOMM Computer Communication Vol 38, 69-74.

P. Dely, A. K. (2011). Openflow for wireless mesh networks. n Computer

Communications and Networks (ICCCN), 2011 Proceedings of 20th International

Conference , (págs. 1-6). Maui, Hawaii.

P. Fonseca, R. B. (21012). Network Operations and Management Symposium (NOMS).

A replication component for resilient OpenFlow-based networking, 933–939.


111

P. Hudak, a. Y. (2012). Scaling Softwaredefined Network Controllers on Multicore

Servers. 1468.

Pan, T. N. ( Oct de 2011). Framework for Software Defined Networks,”Internet draft.

Recuperado el 10 de 2014, de http://tools.ietf.org/id/ draft-nadeau-sdn-framework-01.txt

Passarella, A. (2012). A survey on content-centric technologies for the current internet.

Cdn and p2p solutions. Comput, 35(1):1–3.

R. Murty, J. P. (2010). an architecture for extensible wireless LANs. the 2010 USENIX

conference on USENIX annual technical conference, (pág. 10). CA, USA.

R. Sherwood, G. G.-K. (2010). Can the Production Network be the Testbed? Operating

systems design and implementation (pág. 9th ). Berkeley, CA, USA: OSDI’1.

R. W. Skowyra, A. L. (2013). erifiably-safe software-defined networks for CPS,” in Pro-

ceedings. international conference on High confidence networked systems, (págs. 101-

110). New York,.

R. Wang, D. B. (2011). OpenFlow-based Server Load Balancing Gone Wild. the

Proceedings of the11th USENIX Conference on Hot Topics in Management of Internet,

Cloud, and Enterprise Networks and Services, (págs. 12-12). Berkeley, CA, USA:.

Rahmani, A. M. (2011). Exploitation of OpenFlow in wireless sensor networks. Computer

Science and Network Technology (ICCSNT),International Conference vol. 1, (págs. 594-

600). Maui, Hawaii.

S. A. Mehdi, J. K. (2011). Revisiting traffic anomaly detection using software defined

networking. the Proceedings of the 14th International Conference on Recent Advances in

Intrusion Detection, ser. RAID’11, (págs. 161-180). Berlin,Heidelberg.


112

S. Kandula, S. S. (2009). The Nature of Data Center Traffic: Measurements & Analysis,”in

Proceedings of the 9th ACM SIGCOMM. confer-ence on Internet measurement

conference,, (págs. 202-208). New York, NY.

S. S. (2009). The Nature of Data Center Traffic: Measurements & Analysis,”in

Proceedings". the 9th ACM SIGCOMM confer-ence on Internet measurement

conference, (págs. 202–208). New York, NY, USA.

S. Shin, V. Y. (2013). “AVANTGUARD: Scalable and Vigilant Switch Flow Management

in Software-defined Networks. Proceedings of the 2013 ACM SIGSAC Conference on

Computer; Communications Security, (págs. 413-424). New York, NY.

S.Jain, A. (Aug. 2013.). globally deployed software defined WAN.

Sampieri, H. (1991). metodologia de la investigacion. Recuperado el octde 2014, dehttp://

atarina.udlap.mx/u_dl_a/tales/documentos/lad/arenas_m_a/capitulo3.pdf

Shin, M.-K., Nam, K.-H., & Kim, H.-J. (2012). Software-defined networking (SDN). A

reference architecture and open APIs", ICT Convergence (ICTC), (págs. .360,361). los

angeles.

T. Benson, A. A. (2011). CloudNaaS: a cloud networking platform for enterprise

applications. n Proceedings of the 2nd ACM Symposium on Cloud Computing, ser.

SOCC’11, (págs. 8:1–8:13). New York, NY.

T. Koponen, S. S. (2011). Architecting for innovation. ACM SIGCOMM Computer

Communication Review, vol. 41, 24-36.

TL.Hinrichs, N. S. (2009). Practical Declarative Network Management. inProceedings of

the 1st ACM workshop on Research on enter-prise networking, (págs. 1-10). New York,

NY, USA.


113

Ulversoy, T. (2010). Software defined radio: Challenges and opportunities.

Communications Surveys & Tutorials, IEEE, vol. 12, 531–550.

V. Tanyingyong, M. H. (2010). Improving PC-based OpenFlow switching performance,. in

Architectures for Networking and Communications Systems (ANCS), 2010 ACM/IEEE

Symposium, (págs. 1-2). new york.

Z.Cai, A. o. (2010). Technical Report Rice University, . A system for scalable openflow

control, TR10-08.

ESTADO DEL ARTE REDES DEFINIDAS POR SOFTWARE (SDN)

Documents

Transcript of ESTADO DEL ARTE REDES DEFINIDAS POR SOFTWARE (SDN)