CAPITULO 4 – ¿CÓMO FUNCIONA SDN?

4.1 Características fundamentales de SDN

El nuevo paradigma SDN tiene 5 características principales
1. Separación del planos (datos y control)
Como bien sabemos el funcionamiento SDN de este se basa pues en la
separación de planos para recordar un poco los planos, a primer lugar
tendríamos el plano de control no que es donde se encuentran los algoritmos y
la lógica del dispositivo de red mientras que el plano de datos es en resumen el
que se encarga de reenviar los paquetes para sintetizar esto podemos
mencionar por ejemplo el protocolo ospf el cual pues tiene su algoritmo
llamado spf, este protocolo tanto como el algoritmo estarían almacenados en el
plano de control, la lógica que se aplicaría en la red generarían unas tablas
que serían usadas por el plano de datos para poder hacer el reenvío de
paquetes en SDN pues el paradigma que se tiene es que el plano de control de
cada dispositivo de red que pertenece a la red sdn es llevado hacia un
controlador centralizado mientras que los demás dispositivos de reenvío en
mantiene lo que es el solamente el plano de datos, entonces tenemos esta
arquitectura donde se tiene un controlador el cual va a poder manejar a estos
dispositivos simples
2. Dispositivos simples y Control centralizado: El equipo donde se implementa
el plano de control topológicamente forma una red estrella junto con los
equipos que implementan el plano de datos.
Como ya habíamos mencionado dentro de la red SDN van a existir dispositivos
simples (solo plano de datos) los cuales van a ser controlados por un sistema
centralizado el cual va ejercer un manejo y control a través de software
3. Red programable: Ofrece la flexibilidad de programar la red de acuerdo a las
necesidades del negocio.
Esta es una característica muy importante dentro de sn ya que la probabilidad
de una red va a permitir poder adaptarla a los cambios que se puedan
enfrentar la misma en un programa de red por ejemplo podrías especificar el
comportamiento de reenvío no basándose en la vista global de la red y no
necesariamente tener que poseer conocimientos acerca de las marcas
específicas de cada dispositivo de red
4. Automatización de la red: Busca evitar la configuración manual de la red
ante los cambios en esta.
5. Infraestructura genérica: Liberar al cliente de adquirir dispositivos de
fabricantes o de características muy específicas, privilegiando el uso de
soluciones de código abierto.
Otra característica de Sdn es que las que sus interfaces se mantengan
estándares bien documentados y no propietarias la premisa es que se
mantenga en protocolos abiertos tanto a la interfaz northbound y southbound
hacia el controlador ya que esto permitirá la investigación y podrá hacerse
innovaciones y nuevos métodos de operaciones de la red
4.2 Operación de SDN
Ahora bien en este apartado vamos a hablar un poco acerca de la operación de
Sdn pero en primer lugar vamos a definir estos términos que aparecen que
son el northbound y el southbound, en pocas pablabras el northbound es la
interfaz que conecta el controlador con las aplicaciones mientras que el
southbound es la interfaz que conecta el controlador con los dispositivos de la
red SDN. Como ejemplo de una API southbound tenemos a openflow que se
utiliza para programar los dispositivos de red mientras que para mientras el
controlador ofrece una API northbound permitiendo a las aplicaciones
conectarse al controlador y por tanto permitir que el software provea los
algoritmos y protocolos que puedan ejecutar eficientemente la red.
Los dispositivos sdn contienen funcionalidades de reenvío por tanto pueden
tomar decisiones respecto a qué hacer con paquetes entrantes asimismo
cuentan con una cierta data o información en la cual por sí misma representa
el los flujos definidos por el controlador no entendido también por flujo que es
son un conjunto de paquetes transferidos de una red final o un conjunto de
finales a otro a otros puntos finales ahora en los dispositivos sdn, los flujos
son representados en los dispositivos como entradas de flujos. Una tabla de
flujo se encuentra dentro del dispositivo de red y consiste de una serie de
entradas de flujos y las acciones que se van a tomar cuando un paquete
coincida o haga un match con el flujo que llega al dispositivo.
Por otro lado tenemos al controlador sdn el cual es el encargado de abstraer la
red de los dispositivos sdn para controlarlos y presentar una abstractaccion de
los recursos de la red a las aplicaciones en que se ejecutan en la parte
superior, entonces es el controlador sdn quien permite a las aplicaciones
definir los flujos en los dispositivos y ayudar a las aplicaciones a responder a
los paquetes los cuales serán reenviados del controlador a los dispositivos
SDN.
Las interfaces de las aplicaciones SDN con el controlador (northbound API)
utilizan un conjunto de flujos proactivos en los dispositivos y para recibir
paquetes los cuales han sido reenviados a el controlador. Los flujos proactivos
son establecidos por la aplicación, y dentro de los flujos proactivos tenemos
también tipos de flujos: el flujo estático el cual se va a configurar por las
aplicaciones cuando la aplicación cuando estas inician inicia y van a persistir
hasta que se realice algún cambio y por otro lado el flujo reactivo el cual es
definido en respuesta al reenvío de paquetes hechos por el controlado, ya que
una vez recibidos los paquetes entrantes que han sido enviados al controlador
las aplicaciones se instruirán al controlador en cómo responder a estos
paquetes y si es pertinente establecer también nuevos flujos en el dispositivo
con el fin de permitir a los dispositivos responder la próxima vez cuando vea
un paquete perteneciendo a este flujo de esta forma ahora es posible
implementar sobre los dispositivos es en acciones como reenvío enrutamiento
funciones de control accesos entre otros.

4.3 Dispositivos SDN

El dispositivo sn está compuesto de una API para la comunicación con el
controlador una capa de abstracción y una función de procesamiento de
paquetes, la lógica del a procesamiento de paquetes con sistema mecanismo
que toma acciones basadas en el resultado de evaluación de los paquetes
entrantes y de encontrar la más alta prioridad compatible cuando una
compatibilidad es encontrado el paquete entrante es procesado localmente
cuando no hay ninguna compatibilidad encontrada entonces el paquete podría
ser copiado al controlador para un mayor procesamiento o ser descartado,
dependiendo de las políticas puestas en el dispositivo SDN

4.3.1 Tablas de Flujo

Las tablas de flujo son las estructuras fundamentales en los dispositivos sdn
estas tablas permiten al dispositivo evaluar los paquetes entrantes y tomar
una decisión apropiada basada en el contenido del paquete que acaba de
recibir, estas opciones podrían incluir desde el reenvío del paquete por un
puerto específico, desechar el paquete, o la inundación de este mismo por
todos los puertos entre otros como ya se mencionó una tabla de flujo consiste
en un gran número de entradas de flujo que están priorizadas, donde las
entradas de flujo está compuesto por 2 partes el match field (campo de
coincidencia) y las acciones asociada, cuando un paquete entra es comparado
con todas las entradas de flujo de la tabla y en la primera compatibilidad en
un orden prioritario se va a realizar una acción de acuerdo a lo que dicte la
entrada de flujo.

4.3.2 Switches SDN basados en software

Los dispositivos sdn basados en software son simples de crear el debido a que
las tablas de flujo, las entradas de flujo y los campos de compatibilidad que
contienen son fácilmente implementados en las estructuras de datos por el
software general la cual es está compuesto conjuntos de arrays y tablas hash,
una características de estos switches es que al ser implementaciones en
software son probablemente más lentas y menos eficientes que su contraparte
implementadas en hardware sin embargo la potencia de procesamiento y el
tamaño de memoria no son un problema en instalaciones típicas. Así mismo
las implementaciones en software tienen más flexibilidad de implementar
acciones complejas por tanto se espera que tenga un conjunto más amplio de
acciones disponibles en los dispositivos de software s más que en hardware

4.3.3 Switches SDN basados en hardware

Actualmente los dispositivos de red utilizan hardware diseñado especializado
para facilitar la inspección de paquetes entrantes y las decisiones
subsecuentes que le continúa, estas operaciones de reenvío de capa dos y
capa 3 son realizados por el hardware incluido ya sea a las CAM o las de
TCAM (insertar explicación de las CAM :v)

4.3.3 Implementaciones existentes de dispositivos SDN

Existe un gran número de implementaciones para dispositivos sdn disponibles
a día de hoy, ya sea comerciales o de fuente abierta, sin embargo, los
dispositivos predominantes son de fuente abierta. Entonces tenemos dos
alternativas disponibles Open vSwich (OVS ) Nicira, Indigo y las Network
Equipment Manufactures (NEMs) como Cisco, HP, IBM, Juniper que agregan
soporte a openflow para alguno de sus switches comerciales, estos switches
pueden operar tanto en modo heredado o un modo openflow, asimismo
también existe una nueva clase de dispositivos llamados White box switches
los cuales cuáles son dispositivos minimalistas de muy bajo costo construidos
con CPUs y chips de conmutación de bajo nivel y los fabricantes son de
marcas muy poco reconocidas (Original Device Manufacturer ODM) la premisa
de esos positivos es que la infraestructura física puedes ser construido con el
menor costo posible

4.4 Controlador SDN

El controlador mantiene una visión completa de la red e implementa políticas
de decisiones para el control de todos los dispositivos que con prenden la red y
provee la northbound API para las aplicaciones
Los controladores a menudo vienen con su propio conjunto de módulos de
aplicaciones por ejemplo conmutador, un router, un firewall básico, un
balanceador de carga, entre otros estos son en realidad las aplicaciones en
espera menos están englobadas con el controlador.
Dentro del controlador podemos observar que éste nos provee dos interfaces la
interfaz sur y la interfaz norte, en la interfaz sur cuando se trata de un caso de
un open sdn se utilizará una API openflow o como alternativa BPG en otro tipo
de soluciones, por otro lado para la interfaz norte no hay un estándar
definido, esta carencia ha hecho que exista una gran diversidad controladores
tenemos por ejemplo el controlador Floodlight el cual incluye una API Java el
controlador open day light provee una restfull api y asi tenemos varios
controladores para esta parte

4.4.1 Módulos principales del controlador SDN

En la imagen se puede ver tanto las interfaces norte como sur cada
controlador provee funcionalidades principales entre estas interfaces.
Características en el controlador incluyen
Descubrimientos dispositivos finales de usuarios: permite descubror
dispositivos como laptops, computadoras de escritorio, impresoras,
dispositivos móviles entre otros.
Descubrimiento de dispositivos de red permite descubir dispositivos de red
las cuales comprenden infraestructura de la red tales como switches routers
punto de acceso inalámbricos entre otros
Gestión de topología para dispositivo de red: mantiene información acerca
del detalle de las interconexiones de la red de los dispositivos de red hola con
otros y los dispositivos de usuarios finales los cuales están directamente
relacionados
Gestión de flujos mantiene una base de datos de los flujos que están siendo
gestionadas por el controlador y desarrolla todas las coordinaciones
necesarias con los dispositivos para asegurarse de la sincronización de la
entrada de flujo en los dispositivos con la base de datos
Las funciones principales del controlador son el descubridor y rastreador de
dispositivos y de topología, la gestión de flujos y dispositivos asi como el
seguimiento de estadísticas todos estos son implementados por un conjunto
de módulos internos en el controlador estos módulos necesitan mantener la
base local contenidos en la actual topología y sus estadísticas. el controlador
rastrea la topología al aprender la existencia de los switches (sdn devices ) y
dispositivos de usuarios finales siguiendo la conectividad entre ellos

4.4.2 Módulos principales del controlador SDN

Mirando un poco más de cerca las comunicación de las interfaz northbound
con las aplicaciones tenemos que el controlador informa a la aplicación de
eventos que ocurren en la red estos eventos son comunicados del controlador
a las aplicaciones, en respuesta las aplicaciones usan diferentes métodos para
afectar la operación de la red tales métodos pueden ser invocados en
respuesta a un evento recibido y podrían resultar en un paquete recibido
siendo desechado, modificado o reenviado adicionalmente podria darse la
eliminación o modificar el flujo que contenía el paquete, también las
aplicaciones también pueden invocar métodos independientemente si no
evento que estimule el controlador representadas por otro contexto

4.4.3 Implementaciones existentes de controladores SDN

De igual forma como existen diferentes tipos de implementaciones para los
dispositivos SDN también existen diversas soluciones para las
implementaciones del controlador SDN tenido también controladores de fuente
abierta o comerciales, los controladores de fuente abierta vienen en diferentes
formas como por ejemplo controladores basados en lenguaje C como NOX
basados en Java como bacon y floodlight y otras alternativas como rest o
Python en donde tenemos a open day light Por otro lado los vendedores como
NEC IBM y HP ofrecen controladores que ofrecen implementaciones openflow
en principalmente la mayoría de estos proveedores de marcas reconocidas
ofrecen en controladores SDN propietarios que incluyen algún nivel de apoyo
para Openflow sin embargo open day light y onos asumen roles dominantes
para aplicaciones comerciales

4.5 Aplicaciones SDN

Las aplicaciones SDN se ejecutan por encima del controlador SDN que
conectan hacia la red vía la API norte las aplicaciones sn son en última
instancia responsables del manejo de las entradas de flujo que están
programadas en los dispositivos de red utilizando era el gestor de flujos en el
controlador a través de esta app y las aplicaciones tiene una capacidad de
1 configurar los flujos para encontrar paquetes a través del mejor camino
entre 2 dispositivos finales
2 balancear el tráfico de carga a través de los múltiples caminos o destinos o
conjunto de destino
3 reaccionar a los cambios en la topología de la red como fallas en los enlaces
y adicionalmente en la agregación de nuevos dispositivos y rutas
4 redireccionar del tráfico con propósitos de inspección autentificación
segregación y tareas similares de seguridad
4.5.1 Responsabilidad de aplicaciones SDN
La responsabilidad general de una aplicación es en cualquier sea solución
para la cual fue diseñado se abalanzó de carga firewall o alguna otra operación
una vez que el controlador ha finalizado de inicializar los dispositivos y ha
reportado la topología de red a la aplicación la aplicación pasa la mayor parte
de su procesamiento respondiendo a los eventos mientras que las
funcionalidades principales de las aplicaciones varían de una a otra aplicación
el comportamiento de las aplicaciones va a hacer manejado por los eventos
entrantes del controlador así como también de las entradas externas

CAPITULO 5 – Especificaciones de OpenFlow

5.2.1 El switch OpenFlow
En la figura se muestra la reacción del switch con el controlador vemos que
llega un paquete al puerto dos el cual va a seguir una ruta x y será reenviado
por otro puerto, N la figura haciendo las modificaciones necesarias al paquete
a lo largo del camino un aspecto inherente en este proceso es la
compatibilidad de la función de compatibilidad de paquetes que está dada por
la tabla de asociada a una acción, ahora bien en este punto existen 3 opciones
fundamentales para la disposición del paquete, reenviar el paquete fuera,
desechar el paquete, pasar el paquete del controlador
En el caso del camino C el paquete será pasado al controlador a través del
canal seguro, cuando el controlador tiene un paquete de información para
reenviar fuera a través del switch utiliza el mensaje PACKET_OUT , por otro
lado un paquete que viene el controlador podría tomar dos diferentes caminos
en la parte derecha el controlador lo envía directamente a través de un puerto
específico de salida y el paquete es pasado a través del puerto (n en este caso)
en la parte izquierda el controlador ahora indica que desea retrasar la decisión
del reenvío del paquete
En la implementación de un switch openflow se tienen dos opciones only-
openflow o openflow- híbrido, only-openflow es aquel que reenvia paquetes de
acuerdo a la lógica openflow que hemos venido definiendo, por otro lado
openflow híbrido es un switch que también puede reenviar paquetes en modo
heredado como un switch ethernet o un router IP.

5.2.1 El controlador OpenFlow

El plano de control de open Flow difiere de su contraparte del plano control
heredado en 3 puntos clave: primero puede programar diferentes elementos
del plan de datos con un lenguaje común y estándar el openflow, segundo
existe un dispositivo separado lejos del plano de reenvío a diferencia de los
switches tradicionales donde el plano de control y el plano de autos están
puestos en él en el mismo elemento físico y tercero el controlador puede
programar múltiples plano de datos desde una sola instancia de plano de
control el controlador openflow, responsable de programar todas la
compatibilidades de paquetes (matching) y las reglas de reenvío en un switch.

5.2.3 El protocolo OpenFlow

El protocolo consiste de un conjunto de mensajes enviados del controlador al
switch y en viceversa, los mensajes en conjunto permiten al controlador
programar el switch para permitir un control sobre el tráfico la conmutación
del tráfico del usuario las programaciones más básicas pueden definir
modificar o borrar un flujo, un conjunto de reglas que deescriban las acciones
de reenvío que el dispositivo debe tomar para todos los paquetes
pertenecientes a un flujo cuando el controlador define un flujo este provee al
switch con la información necesaria para conocer cómo tratar a los paquetes
entrantes que coincidan con los del flujo

5.2.4 El canal seguro controlador-switch

El canal seguro es un camino usadao para las comunicaciones entre el
controlador openflow y el dispositivo openflow, generalmente es asegurada
mediante una encriptación basada en TLS a traves de una conexión TCP no
encriptada, es importante también saber cuándo usar la encriptación en el
canal, no siempre se lleva a cabo ya que esta consume tiempo en su
implementación y requiere configurar certificados de seguridad, en ciertos
ambientes como data center podrían causar un desempeño menor y se
consideraría no colocar esta seguridad.

5.3 OpenFlow 1.0 AND OpenFlow BASICS

Fue lanzado en el diciembre del 2009, han existido versiones previas pero
consideramos esta como punto de partida

5.3.1 Puertos y Colas de puertos

Se define como puerto openflow a los puertos físicos, este conecto se expande
a las siguientes versiones de openflow, los switches modernos han soportado
multiples colas por puerto físico, estas colas son generalmente servidas por los
algoritmos de planificación que permiten el provisionamiento de diferentes
niveles de QoS para diferentes tipos de paquetes.

5.3.2 Tabla de flujo

Una tabla de flujo consiste en un conjunto de entradas de flujo, y estas
entradas consisten en un campo de cabecera, conteo y acción asociada a
dicha entrada, los campos de cabecera son usados para el criterio de
compatibilidad para determinar si un paquete pertenece a un flujo establecido,
los contadores son usados para rastrear las estadísticas relativas al flujo y el
campo de acción prescribe la acción que debería tomar el switch al encontrar
una compatibilidad con el paquete

5.3.3 Compatibilidad de paquetes

Cuando un paquete llega al switch openflow de entrada es comparado contra
la tabla de flujos para determinar si existe alguna compatibilidad con alguna
entrada de flujo, los siguientes campos de compatibilidad asociados con el
paquete entrante pueden ser usados para compararlo contra las entradas de
flujo en el switch openflow
El puerto de entrada del switch, el identificador y prioridad de VLAN, MAC de
fuente y de destino, IP destino y fuente, protocolo IP, puerto TCP/UDP fuente y
destino, tipo de servicio IP, tipo de frame Ethernet
Estos campos de compatbilidad son referidos como los 12 campos básicos, es
otra de flujo y una vez que una compatibilidad ha sido encontrada no habrá
mayores intentos de compatibilidad hechos contra la tabla de Flow Debido a
esto es posible que haya múltiples compatibilidades con las entradas de flujo
para un paquete presente en una tabla de flujo entonces solo la primera
entrada que es compatible va a proceder las otras no serán encontradas por el
paquete hasta que se detenga la primera compatibilidad

5.3.4 Acciones y reenvio de paquetes

Las acciones requeridas que deben ser soportadas por un entrada de flujo son
las de reenvío y desecho de un paquete que ya ha sido comparada, en el más
común de los casos se especifica una acción de salida a través de un puerto
físico en el cual el paquete debe ser reenviado sin embargo en openflow versión
1.0 se especifican 5 puertos virtuales que tiene el significado al momento de
realizar una acción de salida, ellos son: LOCAL, ALL, CONTROLLER, IN_PORT,
TABLE
LOCAL: ordena que un paquete debe ser reenviado a software de control
Openflow del switch, esto indica que un paquete debe ser procesado por el
software de control local
ALL: es usado para un paquete sea reenviado a través de todos los puertos del
switch excepto el puerto de entrada esto provee una capa capacidad de
broadcast al swtich openflow
CONTROLLER: indica al que el switch debe reenviar este paquete al
controlador openflow
IN_PORT: Instruye al switch a reenviar el paquete de regreso por el mismo
puerto en el cual ha llegado, y si esto crea una situación de loop pero es
beneficioso en algunos casos.
TABLE: Este es el único que aplica a los paquetes que envia el controlador al
switch, como mensajes PACKED_OUT que enviados desde el controlador los
cuales incluyen listas de acciones, las cuales contienen acciones de salida las
cuales especifican un numero de puerto.
Adicionalmente existen 2 por 2 adicionales virtuales el primero el puerto
virtual NORMAL, este reenvía paquetes al lógica del switch de reenvio
heredado en constraste a LOCAL que reenvía el paquete a la lógica Openflow
para procesarlo y el otro puerto virtual es FLOOD que también envia una
copia de un paquete por todos los puertos excepto el de entrada pero a lo largo
del mínimo STP, es decir también reenvía por puertos deshabilitados con STP,
por tanto ALL es mas limpio
Openflow 1.1 (Febrero 2011)

 Agregación de múltiples tablas: esta versión contaba solo con una tabla
lo cual restringía todas las capacidades del hardware, en la actualidad
es posible poder implementar múltiples tablas y agruparlas de manera
que el rendimiento pueda aumentar para así tener una buena
escalabilidad.
 Soporte para la Etiquetas MPLS y Vlan: En esta versión ya se contaba
con capacidades donde se pueden adicionar facilidades en la
programación para el plano de reenvió, esto ya que los paquetes
proveen mucha más información para el controlador.
 Puertos de tipo virtuales: esta versión permite la virtualización a una
gran escala para diferentes clientes.
 Grupos: Cuenta con la opción de agregar los grupos de puertos con la
idea de poder realizar acciones de redundancia.
Openflow 1.2 (Diciembre 2011)

 Soporte de coincidencia: se puede eliminar ya el tamaño fijo que tienen

las coincidencias con la idea de poder agregar más campos.
 Soporte de tipo básico para el IPv6: luego de agregar los campos en la
coincidencia se puede dar soporte al IPv6.
 Cambio en el mecanismo conexión del controlador: como novedad ya
todos los conmutadores se pueden conectar a varios controladores.
Openflow 1.3 (Abril 2013)

 Expansión al soporte IPv6: adición de más campos de incidencia.

 Estadísticas agregadas a los flujos: en el momento que se establecen los
flujos ya es posible agregar la opción de medición y control a la tasa de
paquetes.
 Tunnel ID meta datos: se agrega un campo de coincidencia que expone
al proceso de encolamiento a la meta data para un puerto lógico.
Openflow 1.4 (Agosto 2013)

 Ampliación en la escalabilidad: se logra que la tabla de flujo se pueda

expandir mediante un tipo de tabla sincronizada, logrando hacer que
trabajen forma bidireccional y que permita mostrar la tabla de origen.
 Bundle: Crean Bundle con la necesidad de una agrupación en las
modificaciones en las transacciones. También estas se generan con la
idea de una utilización en la restauración y pre validación de los
mensajes OpenFlow que se aplican a varios tipos de conmutadores.
 Cambios del puerto TCP por defecto al 6653: La IANA logra asignar a
ONF el número de puerto como lo es el TCP 6653 con la idea que pueda
ser utilizado por el protocolo de conmutador OpenFlow.