CAPITULO 1 : INTRODUCCION

1.1 Terminología Básica

Esta sección define gran parte de la terminología básica de conmutación de paquetes , Esta terminología
es un marco de referencia importante ya que explicamos cómo SDN difiere de los tradicionales
conmutadores de paquetes. Hasta cierto punto, sin embargo, SDN elimina algunos de estos conceptos
históricos o cambia su significado de una manera fundamental.

1.2 Antecedentes Históricos

Estas redes eran redes universalmente conmutadas por circuitos. Las redes tenían poca supervivencia
características en que la pérdida de un solo centro de conmutación podría eliminar la capacidad del
teléfono de un gran franja del país.

La solución propuesta por Baran era transmitir las señales de voz de las conversaciones telefónicas en
paquetes de datos que podrían viajar de forma autónoma a través de la red, encontrando su propio
camino hacia su destino.

ARPANET conectó instituciones de investigación académica, departamentos militares y contratistas de

defensa. Esta red descentralizada y sin conexión crece durante años hasta estallar en el paisaje comercial
alrededor de 1990 en la forma de Internet, Durante décadas después del surgimiento de ARPANET, los
profesionales de la red libraron batallas las ventajas de las arquitecturas basadas en conexión vs. sin
conexión y centralizadas vs. Distribuidas arquitecturas.

Cualquier diseño demasiado centralizado se consideró demasiado vulnerable atacar,

1.3 Centro de Datos Moderno

Durante este período de ascendencia, el mundo Web (WWW), un descendiente de Internet, creado por
Sir Tim Berners-Lee del Reino Unido, dio lugar a centros de datos cada vez más grandes que alojan web
cada vez más compleja y más suscrita servicios.

Con el tiempo, la demanda de eficiencia impulsó la migración del servidor Individual computadoras en
servidores Blade en estantes densamente empaquetados.

Centros de datos se están construyendo ahora que acomodarán más de 120,000 servidores físicos
[8].Estado físico del estado de la técnica los servidores pueden alojar 20 máquinas virtuales (VM) por
servidor físico. Esto significa que el interno ¡la red en tal centro de datos interconectaría 2,400,000 hosts!

la investigación actual [13] predice que para 2014 el 80%del tráfico en los centros de datos será Tráfico
Este-Oeste. El tráfico este-oeste se compone de paquetes enviados por un host en un centro de datos a
otro host en ese mismo centro de datos. tráfico Norte-Sur es el tráfico que ingresa (deja) los datos centro
desde (hacia) el mundo exterior.

Los mega centros de datos discutidos en esta sección difieren de las redes anteriores de varias maneras:
estabilidad de topología, patrones de tráfico y escala completa.

1.4 Arquitectura de Switch tradicional

Dado que cada categoría puede ser capaz de comunicación horizontal con elementos pares en entidades
adyacentes en una topología, y también es capaz de comunicación vertical con las otras categorías, se ha
vuelto común representar cada una de estas categorías como una capa o plano.

1.4.1 Planos de datos, control y gestión

El plano de datos consta de los diversos puertos que se utilizan para la recepción y transmisión de
paquetes y una tabla de reenvío con su lógica asociada.
El plano de control está involucrado en muchas actividades. Su función principal es mantener actualizada
la información en la tabla de reenvío es responsable de procesar una cantidad de protocolos de control
diferentes que pueden afectar la tabla de reenvío, según la configuración y el tipo de interruptor. Estos
protocolos de control son conjuntamente responsables de gestionar la topología activa de la red.

El plano de gestión los administradores de red configuran y supervisan el cambio a través de este plano,
que a su vez extrae información o modifica los datos en los planos de control y datos, según corresponda.
Los administradores de red utilizan algún tipo de sistema de gestión de red para comunicarse con el plano
de gestión en un conmutador.

1.4.2 Enrutamiento basado en software y puente

La terminología entonces vigente era usar los términos puente de marcos para la capa dos y enrutamiento
de paquetes para la capa tres.

1.4.3 Búsqueda de hardware de tablas de reenvío

El primer uso importante de la aceleración de hardware en la conmutación de paquetes fue a través del
uso de circuitos integrados específicos de la aplicación (ASIC) para realizar funciones de hash de alta
velocidad para búsquedas de tablas.
1990, los avances en la tecnología de memoria direccionable por contenido (CAM) permitieron realizar
búsquedas de muy alta velocidad. utilizando campos de direcciones de destino para encontrar la interfaz
de salida para el paquete de alta velocidad.

Los enrutadores todavía estaban basados en software por varias razones. Primero, las modificaciones del
encabezado del paquete requeridas para la conmutación de la capa tres estaban más allá de la capacidad
de los ASIC utilizados en ese momento, La búsqueda de direcciones en la capa tres es más complicada
porque los dispositivos buscan la coincidencia más cercana en una dirección de red.

las capacidades de CAM mejoraron de manera constante, y en pocos años hubo enrutadores de capa tres
capaces de buscar hardware en la dirección de capa de destino tres. En este punto, la distinción entre el
enrutador y el conmutador comenzó a difuminarse, y los términos capa dos switch y layer tres switch
llegaron a ser de uso común.

Hoy en día, cuando el mismo dispositivo tiene la capacidad de actuar simultáneamente como interruptor
de capa dos y capa tres, el uso del interruptor de término simple se ha convertido en algo común.

1.4.4. Reglas de reenvío genéricamente programables.

hay muchos paquetes que necesitan ser procesados por un conmutador y que necesitan un tratamiento
más complicado que el simple envío en otra interfaz, La solución consistía en introducir una mayor
inteligencia en la tabla de reenvío.

Los primeros enrutadores solo tenían que realizar modificaciones limitadas en el campo del encabezado
del paquete. Esto incluyó la disminución del campo Time-to-Live (TTL) y el cambio del encabezado MAC a
los encabezados MAC de origen-destino para el siguiente salto, a medida que las funciones del
conmutador crecieron para admitir capacidades avanzadas como redes de área local virtuales (VLAN) y
conmutación de etiquetas multiprotocolo (MPLS), más campos de encabezado de paquetes necesitaban
una manipulación cada vez más compleja. Con este fin, surgió la idea de reglas programables, Esta misma
capacidad de programación del hardware fue una de las primeras semillas que dio vida al concepto de
SDN.

1.5 Tablas de reenvío autónomas y dinámicas

se desarrollaron protocolos para que los puentes y enrutadores pudieran ser dinámicos y autónomos
construir y actualizar sus tablas de reenvío.
1.5.1 Control de capa dos

Una tabla de reenvío de la capa dos es una tabla de búsqueda indexada por la dirección MAC de destino,
donde la entrada de la tabla indica qué puerto en el interruptor se debe utilizar para reenviar el paquete.

En el caso de que se recibiera una dirección de destino desconocida, el puente podría inundarse, se
desarrollaron protocolos que permitieron que el puente aprendiera las direcciones MAC dinámicamente
y para aprender a asignar estas direcciones a los puertos de forma que se evite automáticamente creando
bucles de conmutación.

La conmutación de bucles es más exagerada en la conmutación de capa dos que en la capa tres, ya que el
encabezado MAC tiene no es análogo al campo Time-to-Live (TTL).

El protocolo Spanning Tree (STP), especificado en IEEE 802.1D [15], fue diseñado específicamente para
evitar bucles y, por lo tanto, aborda el problema de la radiación emitida. lo logra haciendo que todos los
conmutadores de la topología comprendan colectivamente un árbol de expansión, el Puente de ruta más
corta (SPB) [11] y la interconexión transparente de muchos enlaces (TRILL)

1.5.2 Control de capa tres

La tarea más fundamental del enrutador cuando recibe un paquete es determinar si el paquete debe ser
reenviado a una de sus interfaces o si el paquete necesita algún procesamiento de excepción. Encontrar
una coincidencia proporciona el enrutador de siguiente salto, que se asigna a un sitio específico puerto
de reenvío, y el proceso de reenvío puede continuar. En un enrutador tradicional, esta tabla de
enrutamiento es construido principalmente a través del uso de protocolos de enrutamiento cuyo
propósito común de permitir el enrutador pueda construir de forma autónoma una tabla de reenvío de
capa tres.

RIP es un protocolo de vector de distancia, mediante el cual cada enrutador utiliza el conteo de saltos
ponderados en una interfaz como su distancia a ese destino red, RIP no necesita tener una imagen
completa de la topología de red para poder hacer este cálculo de enrutamiento vectorial de distancia.

Tanto OSPF como IS-IS son protocolos de enrutamiento dinámico de estado de enlace. El costo de los
bordes puede ser asignado por cualquier métrica, pero uno obvio es el ancho de banda. El algoritmo
estándar de ruta más corta, conocido como el algoritmo de Dijkstra, se usa para calcular la ruta más corta
a cada red accesible desde la perspectiva de cada enrutador. Para esto clase de algoritmo, la ruta más
corta se define como la que se recorre con el menor costo total.

BGP principalmente residir en la periferia de un AS y aprender acerca de las redes que son accesibles a
través de enrutadores de extremo ASs adyacentes. A diferencia de RIP, la métrica no es una distancia
simple (es decir, recuento de saltos) sino que incluye parámetros como la red políticas y reglas.

1.5.3 Protocolo Sopa o (S) bruja de cerveza

es probable que el enrutador moderno también admita LDP [18] para intercambiar información sobre
etiquetas MPLS, como así como IGMP [12], MSDP [19] y PIM [16] para el enrutamiento de multidifusión.

estos protocolos de control en realidad son protocolos distribuidos, cuando algo se cambia
intencionalmente, como agregar un servidor o un enlace de comunicaciones fuera de servicio, estos
protocolos distribuidos tardan en converger a un conjunto de tablas de reenvío consistentes, causando
estragos temporales dentro del centro de datos.

Por lo tanto, llegamos a una situación donde la mayoría del cambio de topología se realiza de forma
programática e intencional, reduciendo el beneficio de los protocolos autónomos y distribuidos,
Entonces, mientras que esta matriz de protocolos de control era necesaria para desarrollar interruptores
autónomos que puedan de forma dinámica y autónoma responden a las condiciones de la red que
cambian rápidamente, estas condiciones no existen en el centro de datos moderno, y al usarlos de esta
manera exagerada, hemos creado una red pesadilla de gestión que es completamente evitable.

Este plano de control centralizado programaría el reenvío tablas en todos los switches en el centro de
datos.

(1) la topología dentro del centro de datos es bastante estable y bajo estricto control administrativo
(2) el conocimiento de la topología ya está centralizado y controlado por los mismos administradores,
(3) cuando hay fallas de nodos o enlaces, este conocimiento de topología global puede ser utilizado por
la central control personalizado para reaprovisionar rápidamente un conjunto coherente de tablas
de reenvío.

1.6 ¿Podemos aumentar el IQ de reenvío de paquetes?

Es posible que deseemos enrutar diferentes clases de QoS, como datos, voz y video, a través de diferentes
rutas, incluso si están dirigidas al mismo host de destino. Una vez que dejamos el campo de enrutamiento
solo en la dirección de destino, ingresamos a un mundo donde se pueden usar muchos campos diferentes
en el paquete para las decisiones de reenvío. En general, este tipo de enrutamiento se denomina
enrutamiento basado en políticas (PBR).

flujo, para describir un conjunto particular de tráfico de aplicaciones entre dos puntos finales que recibe
el mismo tratamiento de reenvío. PBR normalmente se implementa mediante el uso de listas de control
de acceso (ACL).

Aunque PBR ha estado en uso durante varios años, esto solo ha sido posible mediante la configuración
de estas reglas de reenvío especiales a través del plano de gestión.

En particular, podemos identificar flujos de tráfico de aplicaciones de usuario particulares y darles un

tratamiento diferente, enrutando su tráfico a lo largo de caminos diferentes en algunos casos, incluso si
están destinados al mismo punto final de red. De esta manera, podemos incorporar PBR en el nivel del
suelo de SDN.

SDN se ha basado en la idea de construir las tablas de reenvío que definen acciones para tomar flujos en
lugar de tener tablas de reenvío simplemente asignan la dirección de destino al puerto de salida.

SDN pretende incorporar un conjunto de información más completo en su procesamiento de flujos

individuales, incluidos campos como el número de puerto TCP que proporciona pistas sobre a qué
aplicación corresponde ese flujo.

1.7 Código abierto y cambios tecnológicos

parte de este esfuerzo vendrá de empresas comerciales que esperan seguir a la estrella de SDN para el
éxito financiero, se espera que SDN sea capaz de proporcionar rápidamente la funcionalidad
correspondiente a los sistemas heredados al contar con la comunidad de código abierto para desarrollar
gran parte del Software de plano de control SDN.

Otro ejemplo importante de código abierto es la implementación de OpenSSL [14]. El software de cifrado
es notoriamente complejo, pero se requiere en más y más productos en el mundo actual de la seguridad.

Trasladar el plano de control y sus protocolos complejos asociados del hardware del conmutador
propietario a un servidor centralizado construido en una plataforma de PC hace que el uso del software
de control de código abierto sea mucho más factibles
 CAPITULO 2 : ¿Por qué SDN?
Las razones de este hecho incluyen los costos cada vez mayores de poseer y operar equipos de red, la
necesidad de acelerar la innovación en la creación de redes y, en particular, las crecientes demandas del
moderno centro de datos.

2.1 Evolución de los interruptores y planos de control

2.1.1 Reenvío y enrutamiento simple utilizando software

hablamos sobre los primeros días de las redes informáticas, cuando casi todo lo que no sea la capa física
(capa uno) se implementó en el software. Esto fue cierto tanto para los sistemas de usuario final como
para los dispositivos de red.

2.1.2 Independencia y autonomía en primeros dispositivos

Los desarrolladores hicieron todo lo posible para implementar este entorno distribuido con inteligencia
residente en cada dispositivo. Cada vez que se requiriera coordinación entre dispositivos, las decisiones
colectivas podrían tomarse a través del intercambio colaborativo de información entre dispositivos.

Ejemplos de esta inteligencia distribuida son los protocolos de capa dos (puente) y capa tres
(enrutamiento), que implicaron la negociación entre los dispositivos con el fin de llegar a un consenso

 Protocolo de Spanning Tree. es un ejemplo de la operación de dispositivos autónomos que

participan en un proceso de toma de decisiones distribuidas para crear y aplicar una jerarquía en
la red. El resultado es la operación correcta de puentes transparentes en todo el dominio a
expensas de la latencia de convergencia y la configuración posiblemente arbitraria. Esta solución
fue una compensación entre costo y complejidad.

 Bridging de ruta más corta.(SPB) es un mecanismo para permitir múltiples rutas simultáneas a
través de un tejido de capa dos a través del cálculo colaborativo y distribuido de las rutas más
cortas y más eficientes, y luego compartir esa información entre los nodos participantes en la red
mallada. Esta característica se llama multipath.

 RIP, BGP, OSPF e IS-IS.protocolos de enrutamiento implican el intercambio de información de

enrutamiento local por cada dispositivo, ya sea en el borde de la red o como un nodo intermedio.
Su intercambio colectivo de información permite que el estado de enrutamiento converja a
medida que los dispositivos comparten su información entre ellos. Cada enrutador permanece
autónomo en términos de su capacidad para tomar decisiones de enrutamiento a medida que
llegan los paquetes.
2.1.3 El software se mueve hacia el silicio

Se muestra que con el tiempo estas funciones se movieron del software al hardware. Ahora vemos la
mayoría de las decisiones de reenvío y filtrado implementadas completamente en hardware. Estas
decisiones son impulsadas por tablas configuradas establecidas por el software de control anterior.

En la actualidad, los dispositivos de conmutación se componen normalmente de componentes de

hardware tales como circuitos integrados específicos de la aplicación (ASIC), arreglos de compuertas
totalmente programables (FPGA) y memorias ternarias de contenido direccionable (TCAM). La potencia
combinada de estos circuitos integrados permite que las decisiones de reenvío se realicen íntegramente
en el hardware a velocidad de línea.

El hardware ahora es capaz de manejar todas las decisiones de reenvío, enrutamiento, lista de control de
acceso (ACL) y QoS.

2.1.4 Reenvío y control de hardware en el software

Bridging {puenteo} (reenvío de la capa dos).

La capa básica dos reenvíos MAC de paquetes se maneja en las tablas de hardware.
Routing {enrutamiento} (reenvío de la capa tres).
Para mantenerse al día con los enlaces de alta velocidad de hoy y para enrutar paquetes a velocidades de
enlace, la funcionalidad de reenvío de capa tres también se implementa en las tablas de hardware.
Filtrado y priorización avanzados.
Las reglas generales de gestión de tráfico, como las ACL, que filtran, reenvían y priorizan paquetes, se
gestionan a través de tablas de hardware ubicadas en el hardware (por ejemplo, en TCAM) y se accede a
ellas a través de un software de bajo nivel.
Control.
El software de control utilizado para tomar decisiones de enrutamiento más amplias e interactuar con
otros dispositivos para converger en topologías y rutas de enrutamiento se implementa en un software
que se ejecuta de forma autónomo dentro de los dispositivos. Dado que el software del plano de control
actual en los dispositivos de red carece de la capacidad de distribuir información sobre políticas tales
como seguridad, QoS y ACL,

2.1.5 La creciente necesidad de simplificación

Los autores afirman que uno de los principales impulsores para SDN es la simplificación. Esto se debe en
parte al diseño independiente y autónomo de dispositivos que hacen que sea necesaria tanta inteligencia
dentro de cada dispositivo.
Poner más funcionalidades en el hardware de alguna manera simplifica el dispositivo, pero en otras
formas hace que el dispositivo sea más complicado debido a los intercambios entre el manejo de paquetes
en hardware y el software.
existe la oportunidad de simplificar la administración de las redes de estos dispositivos. En lugar de utilizar
herramientas de administración de red primitivas como SNMP y CLI, los operadores de red preferirían
utilizar sistemas de administración basados en políticas.

2.1.6 Desplazar el control del dispositivo

En esencia, SDN consiste en mover ese software de control del dispositivo a un recurso informático
ubicado en el centro que sea capaz de ver toda la red y tomar decisiones que sean óptimas.

Reenvío, filtrado y priorización.

Las responsabilidades de reenvío, implementadas en tablas de hardware, permanecen en el dispositivo.
Además, las características como el filtrado basado en las ACL y la priorización del tráfico también se
aplican localmente en el dispositivo.
Control.
El software de control complicado se elimina del dispositivo y se coloca en un controlador centralizado,
que tiene una vista completa de la red y la capacidad de tomar decisiones óptimas de reenvío y
enrutamiento.

Application.
Encima del controlador es donde se ejecutan las aplicaciones de red, implementando funciones de nivel
superior y, además, participando en las decisiones sobre la mejor manera de administrar y controlar el
reenvío y distribución de paquetes dentro de la red.

2.2 Costo
Los argumentos relacionados con la necesidad de SDN a menudo incluyen el costo como un factor
determinante para este cambio

2.2.1. Mayor costo de desarrollo

los marcos de los servidores de aplicaciones proporcionan plataformas que permiten a los desarrolladores
de software reutilizar el código provisto por esos marcos comunes y, por lo tanto, concentrarse en
resolver problemas específicos del dominio. Sin la capacidad de aprovechar la funcionalidad del software
de esta manera, cada proveedor tendría que desarrollar, probar y mantener grandes cantidades de código
redundante, que no es el caso en un entorno de software abierto. En los últimos años, los proveedores
de silicio han estado produciendo ASIC comunes y listos para usar (COTS) que son capaces de alcanzar
velocidades y funcionalidades que rivalizan o superan las versiones patentadas desarrolladas por los
proveedores de hardware de redes, los NEM deben escribir y admitir grandes cantidades de software de
lo que sería necesario si los dispositivos de red se desarrollaran en entornos verdaderamente abiertos.

2.2.2. Los entornos cerrados fomentan el bloqueo del proveedor

a menudo se agregan mejoras a estas implementaciones estándar, que intentan permitir que un producto
de un proveedor supere a su competencia. Con muchos proveedores agregando tales mejoras, el
resultado final es que cada producto del proveedor tendrá dificultades para interoperar sin problemas
con productos de otro proveedor. Como resultado, los clientes con frecuencia se casan efectivamente con
un proveedor que eligieron años o incluso décadas antes. Este tipo de bloqueo por parte del vendedor
alivia la presión a la baja sobre el costo porque el vendedor está en gran medida

2.2.3. Complejidad y resistencia al cambio

Esa resistencia al cambio da como resultado un estancamiento tecnológico y una lentitud a largo plazo.
Lo ideal sería un mundo de redes más simple y progresivo, con dispositivos de red abiertos, eficientes y
menos costosos. Este es un objetivo de SDN

2.2.4. Mayor costo de operación de la red

A medida que las redes se vuelven cada vez más grandes y complejas, crece el gasto operacional (OPEX)
de la red. Este componente de los costos generales se considera cada vez más significativo que el
componente de gasto de capital correspondiente (CAPEX). SDN permitirá un aprovisionamiento más
rápido de nuevos servicios y brinda la agilidad para cambiar de equipo entre diferentes servicios [5],
debería llevar a un OPEX más bajo con SDN.

2.3. Implicaciones SDN para investigación e innovación

Los proveedores de redes Controlan los dispositivos de red de abajo hacia arriba: el hardware, el firmware
de bajo nivel y el software requerido para producir un dispositivo de red inteligente plataformas de
hardware diferentes creadas por múltiples proveedores y que constan de capacidades diferentes y
propietarias. Sobre ese hardware residen múltiples capas de software, que en última instancia
proporcionan una interfaz común y abierta para la capa de aplicación. La Máquina Virtual de Java y el
Entorno de Desarrollo Integrado de NetBeans proporcionan un buen ejemplo de métodos de desarrollo
multiplataforma. Usando tales herramientas, podemos desarrollar software que pueda ser portado entre
PC con Windows, Linux o entornos Apple Mac
2.3.1. Status Quo beneficia a los proveedores titulares

Los monopolios colectivos existentes en el mundo de las redes hoy en día son ventajosos para los
proveedores de redes. Su única competencia legítima proviene de sus compañeros NEM establecidos.
Aunque periódicamente surgen nuevas empresas de redes para desafiar el status quo, esa es la excepción
más que la regla. El resultado es que el panorama competitivo evoluciona a un ritmo mucho más lento de
lo que lo haría en un entorno verdaderamente abierto

2.3.2. SDN promueve la investigación y la innovación

Los entornos de software abierto como Linux han ayudado a promover este rápido ritmo de avance, Si
están trabajando en el área de virtualización de servidor o bases de datos, pueden mirar KVM o Xen y
MySQL o Postgres. Todos estos paquetes de código abierto se utilizan en implementaciones comerciales
a gran escala.
Desafortunadamente, la naturaleza cerrada actual del software de red, los protocolos de red, la seguridad
de red y la virtualización de red es tal que ha sido un reto experimentar, probar, investigar e innovar en
estas áreas. Este hecho es uno de los principales impulsores de SDN [1]. Varias universidades colaboraron
para proponer un nuevo estándar para redes llamado Open Flow, si SDN finalmente será para el mundo
de las redes lo que Linux se ha convertido para el mundo de la informática.
Para ser justos, hay que tener en cuenta que la innovación también está impulsada por la perspectiva de
generar riqueza. Sería ingenuo imaginar que un mundo de productos de redes de bajo costo tendrá un
impacto puramente positivo en el ritmo de la innovación

2.4. Innovación del Centro de Datos

Este crecimiento ilimitado ha hecho posible nuevas tendencias de informática como es la nube, que es
capaz de almacenar cantidades masivas de computación o informática de potencia y capacidad de
almacenamiento.

2.4.1. Computación y virtualización de almacenamiento

En 1998, VMware se estableció y comenzó a ofrecer software para virtualizar escritorios y servidores.
El uso de esta tecnología de virtualización informática no explotó hasta que los centros de datos se
volvieron frecuentes y la necesidad de crear y eliminar servidores dinámicamente, así como moverlos de
un físico servidor a otro, se volvió importante.
Del mismo modo, la virtualización del almacenamiento ha existido durante bastante tiempo, al igual que
el concepto de abstracción bloques de almacenamiento y lo que les permite ser separados del hardware
de almacenamiento físico real.

2.4.2. Insuficiencias en las redes hoy

Sin embargo, con la llegada de los centros de datos, existe una necesidad creciente de que las redes no
solo se recuperen de este tipo de eventos, sino que también puedan responder rápidamente a los cambios
frecuentes e inmediatos.
Por lo tanto, la tarea de reconfigurar una red en un centro de datos moderno no tomar minutos, sino días.
Tales redes inflexibles están obstaculizando a los administradores de TI en sus intentos para automatizar
y optimizar sus entornos de centros de datos virtualizados. SDN tiene la promesa de que el tiempo
requerido para dicha reconfiguración de red se reducirá al orden de minutos, como ya es el caso para la
reconfiguración de máquinas virtuales.

2.5. Necesidades del centro de datos

2.5.1. Automatización: La automatización permite a las redes ir y venir a voluntad, siguiendo los
movimientos de los servidores y el almacenamiento como el cambio que necesita. Esto a veces se
denomina agilidad-la capacidad de crear instancias dinámicas de redes y desactivarlos cuando ya no sean
necesarios.
2.5.2. Escalabilidad

Con los centros de datos y los entornos de nube, la gran cantidad de estaciones finales que se conectan a
un único, la red ha crecido exponencialmente. Las limitaciones de los tamaños de tabla de direcciones
MAC y el número de VLAN se han convertido en impedimentos para las instalaciones de red y las
implementaciones. La gran cantidad de exámenes físicos, los dispositivos presentes en los centros de
datos también plantean un problema de control de difusión (broadcast control). El uso de túneles y las
redes virtuales pueden contener la cantidad de dispositivos en un dominio de difusión a un número
razonable.

2.5.3. Multipathing

Acompañando las grandes demandas impuestas a la red por el requisito de escalabilidad que hemos
establecido es la necesidad de que la red sea eficiente y confiable. Es decir, la red debe hacer un uso
óptimo de sus recursos, y debe ser resistente a fallas de cualquier tipo; y, si ocurren fallas, la red debe ser
capaz de recuperarse de inmediato.

2.5.5. Virtualización de red

La urgencia de la automatización, la multiplicidad de clientes y la multirruta se ha incrementado como

resultado de la escala y fluidez introducida por el servidor y la virtualización de almacenamiento. La idea
general de la virtualización es que crea una abstracción de nivel superior que se ejecuta en la parte
superior de la entidad física real que estás abstrayendo. Los El crecimiento de la virtualización de
servidores de computación y almacenamiento ha creado una demanda de virtualización de red. Esto
significa tener una abstracción virtual de una red que se ejecuta en la parte superior de la red física real.

En resumen, los avances en la tecnología del centro de datos han causado debilidades en la red actual
tecnología para ser más evidente. Esta situación ha estimulado la demanda de mejores formas de
construir y administrar redes [9], y esa demanda ha impulsado la innovación entorno a SDN

El Génesis de SDN
En general, el sistema que ha evolucionado es demasiado cerrado, y hay un fuerte deseo de migrar a un
modelo más cercano al desarrollo de código abierto y abierto iniciativas de fuente (similar a Linux con
respecto a los sistemas operativos de computadora). También hemos notado que por una variedad de
razones, los fabricantes de equipos de red (NEM) están empantanados en su las tecnologías actuales y no
pueden innovar a la velocidad requerida por el centro de datos moderno.

3.1 La evolución de la tecnología de redes

Cada computadora individual ocupaba una toda habitación o incluso un piso completo. A medida que
surgieron los mainframes y comenzaron a encontrar su camino en nuestra tecnología conciencia, estas
potencias de cómputo todavía operan como islas, y cualquier intercambio de datos se llevó a cabo
utilizando medios físicos como cintas magnéticas.

3.1.1 Redes de mainframe: terminales remotas

Esto fue provisto en la forma de controladores remotos de terminales y lectores de tarjetas, que
funcionaban como dispositivos subordinados conocidos como periféricos, con control que reside
completamente en el mainframe central. Conexiones de red en este Los casos fueron simples enlaces
punto a punto o punto a multipunto.

3.1.2 Conexiones Punto-a-Punto Peer-to-Peer-to-Peer-to-Peer-to-Peer

informática comenzó a pasar de solo mainframes a la adición de miniordenadores, estas máquinas tenían
una mayor necesidad de compartir información de manera rápida y eficiente. informática comenzó a
pasar de solo mainframes a la adición de miniordenadores, estas máquinas tenían una mayor necesidad
de compartir información de manera rápida y eficiente.

3.1.3 Redes de área local

surgió la necesidad de una forma de conectar estos dispositivos para permitirles compartir información y
colaborar de una manera eso no era necesario cuando todo se ejecutaba en un mainframe grande o
incluso en un miniordenador potente.

Por lo tanto, llegó la tecnología de redes de área local (LAN), con varias batallas libradas entre tecnologías
(por ejemplo, Ethernet / IEEE 802.3 versus Token Ring / IEEE802.5). Notablemente, estas LAN tempranas
se ejecutaban en medios compartidos.

3.1.4 Redes puenteadas

Eventualmente, estas redes de medios compartidos necesitaron escalar tanto en extensión física como
en cantidad de nodos. Como explicado en la sección anterior, las redes de medios compartidos no escalan
bien a medida que crece la cantidad de hosts.

Los primeros dispositivos para realizar esto la funcionalidad se llamaba puentes, precursores de los
conmutadores actuales, pero mucho más simple. Por lo general tenían solo dos puertos que conectan dos
dominios compartidos. Además, estos puentes se implementaron de tal manera que cada dispositivo fue
capaz de operar de forma independiente y autónoma, sin requerir ninguna inteligencia centralizada.

Si traducimos las realidades de este período a la terminología actual, no había un controlador

centralizado, simplemente un recopilador de estadísticas. Políticas, si es que se puede usar ese término,
se administraron al establecer parámetros específicos en cada dispositivo en la red.

3.1.5 Redes enrutadas

estrategias similares fueron empleadas para el enrutamiento de capa tres. Router directamente
conectado localmente a los dominios de la capa dos e interconectado a grandes distancias con WAN punto
a punto.

Esta secuencia ha llevado al estado actual de las cosas, con inteligencia de red distribuida en los
dispositivos de red en sí mismos.

3.2 Precursores de SDN

Esta sección considera algunas de esas primeras exploraciones de tecnología similar a SDN. Hay una
progresión constante de ideas sobre el avance de la tecnología de red hacia lo que ahora conocemos como
SDN. La Tabla 3.1 muestra esta progresión
La señalización abierta propuso un conjunto de interfaces abiertas y programables para el hardware de
conmutación de ATM. El concepto clave fue separar el software de control del hardware de conmutación.
Este trabajo condujo a el esfuerzo de IETF que resultó en la creación del Protocolo general de
administración de conmutadores (GSMP)

En efecto, MPLS y las tecnologías relacionadas son una desviación de las decisiones de reenvío autónomo
y distribuido característica del enrutador de Internet tradicional, y en ese sentido, fueron un pequeño
paso hacia un Paradigma de conmutación de Internet similar a SDN.

Los flujos se definieron como un conjunto relativamente persistente de paquetes entre los mismos dos
puntos finales, donde un punto final fue determinado por la dirección IP y el puerto TCP / UDP.

El proyecto de red activo [10, 11] también incluyó el concepto de interruptores que podrían programarse
mediante protocolos de administración fuera de banda.

3.2.2 Control de acceso a la red

la red (NAC) controlan el acceso a una red en función de las políticas establecidas por la administración
de la red.

3.2.3 Orquestación

Los primeros intentos de automatización involucraron aplicaciones que comúnmente se denominaban

orquestadores tales aplicaciones podrían tomar un comando u objetivo generalizado y aplicarlo en una
amplia gama de a menudo dispositivos heterogéneos.

Protocolo de gestión (SNMP).

una solución de orquestación puede entonces tener ciertas políticas de nivel superior que a su vez se
ejecutan en niveles más bajos con los complementos adecuados.

Los complementos específicos del proveedor se utilizan para convertir las solicitudes de políticas de nivel
superior en las correspondientes solicitud nativa de SNMP o CLI específica para cada proveedor.
Tales soluciones de orquestación aliviaron la tarea de actualizar las configuraciones del dispositivo.

ya que eran realmente limitado a proporcionar una interfaz más conveniente para las capacidades
existentes, y dado que no hay capacidad existía en el equipo heredado para la coordinación en toda la red
de políticas más complejas como la seguridad y administración de red virtual, tareas como la configuración
de VLANs permanecieron difíciles. Por consiguiente, las aplicaciones de administración de orquestaciones
continuaron siendo útiles principalmente para tareas tales como software y actualizaciones de firmware,
pero no para tareas que serían necesarias para automatizar los centros de datos actuales.

3.2.4. Complementos de red de Virtualization Manager

El concepto de los complementos de red del administrador de virtualización se basa en la noción de

orquestación e intenta automatizar las actualizaciones de red que se requieren en un entorno de
virtualización. Las herramientas específicamente dirigidas al centro de datos a menudo incluirían
complementos de administrador de virtualización (por ejemplo, complementos para VMware's vCenter),
que se configurarían para tomar medidas en el caso de un cambio de servidor, como un vMotion

3.2.5. ForCES: separación de los aviones de reenvío y control

ForCES fue una de las propuestas originales que recomendaba el desacoplamiento de los aviones de
reenvío y control. La idea general de ForCES era proporcionar entidades simples de reenvío basadas en
hardware en la base de un dispositivo de red y elementos de control basados en software anteriores.
Estos promotores de hardware simples se construyeron utilizando tecnología de cambio de celda o
conmutación de etiquetas

Los componentes funcionales de ForCES son los siguientes:

Elemento de reenvío: El Elemento de reenvío (FE) normalmente se implementaría en hardware y se

ubicaría en la red. El FE es responsable de hacer cumplir las reglas de reenvío y filtrado que recibe del
controlador.

Elemento de control: El elemento de control (CE) se refiere a la coordinación entre los dispositivos
individuales en la red y para el enrutamiento de la comunicación y la información de enrutamiento a los
FE siguientes.

Elemento de red: El elemento de red (NE) es el dispositivo de red real que consta de uno o más EF y uno
o más CE.

Protocolo ForCES: El protocolo ForCES se usa para comunicar información entre FE y EC.
ForCES propone la separación del plano de reenvío del plano de control, y sugiere dos formas de
realización diferentes de esta arquitectura. En una de estas realizaciones, tanto el reenvío como los
elementos de control están ubicados dentro del dispositivo de red

La otra realización especula que sería posible mover los elementos de control del dispositivo y ubicarlos
en un sistema completamente diferente. Aunque la sugerencia de un controlador por separado existe en
ForCES, se hace hincapié en la comunicación entre CE y FE sobre un plano posterior del conmutado

3.2.6. 4D: control de red centralizado

El trabajo seminal sobre el tema de trasladar la tecnología de red de elementos de red distribuidos a un
controlador centralizado apareció en la propuesta de 4D ,4D argumenta que el estado actual de las redes
es frágil y, por lo tanto, a menudo se tambalea al borde de la falla debido a su diseño actual basado en
sistemas distribuidos y autónomos. Dichos sistemas exhiben una característica definitoria de sistemas
complejos e inestables: un evento local pequeño como una configuración incorrecta de un protocolo de
enrutamiento puede tener un impacto global grave. La propuesta argumenta que la causa raíz es el hecho
de que el plano de control se ejecuta en los elementos de la red.

se centra en tres principios de diseño:

Objetivos de nivel de red: En resumen, las metas y objetivos del sistema de red deben establecerse en
términos de nivel de red basados en todo el dominio de red, separados de los elementos de red, en lugar
de en términos relacionados con el rendimiento individual de los dispositivos de red.

Vista de toda la red: debe haber una comprensión integral de toda la red. La topología, el tráfico y los
eventos de todo el sistema deben formar la base sobre la cual se toman las decisiones y se toman acciones.

Control directo: los sistemas de control y administración deberían poder ejercer control directo sobre los
elementos de la red, con la capacidad de programar las tablas de reenvío para cada dispositivo en lugar
de solo poder manipular algunos parámetros de configuración remota e individual, como es el caso hoy .
4D establece que "esperamos que explorar un punto de diseño extremo (el enfoque de pizarra limpia)
ayude a enfocar la atención de las comunidades industrial y de investigación en esta área de crucial
importancia e intelectualmente desafiante".

La propuesta 4D delinea algunos de los desafíos que enfrenta la arquitectura centralizada propuesta. Estos
desafíos continúan siendo relevantes hoy en SDN. Enumeramos algunos de ellos aquí:

Latencia: Tener un controlador centralizado significa que un número determinado (con suerte pequeño)
de decisiones sufrirá una latencia de ida y vuelta no trivial ya que el elemento de red solicita instrucciones
de política del controlador. La forma en que este retraso afecta el funcionamiento de la red y hasta qué
punto queda por determinar. Además, dado que el controlador central proporciona asesoramiento sobre
políticas para una serie de dispositivos de red, se desconoce si los servidores convencionales en los que
se ejecuta el controlador podrán atender estas solicitudes a una velocidad suficiente para tener un
impacto mínimo o nulo en la operación de la red.

Escala: Tener un controlador centralizado significa que la responsabilidad de la organización topológica

de la red, la determinación de las rutas óptimas y las respuestas a los cambios debe ser manejada por el
controlador. Como se ha argumentado, esta es la ubicación adecuada para esta funcionalidad; sin
embargo, a medida que se agregan más y más dispositivos de red a la red, surgen preguntas de escala y
la capacidad de un único controlador para manejar todos esos dispositivos. Es difícil saber qué tan bien
un sistema centralizado puede manejar cientos, miles o decenas de miles de dispositivos de red y saber
cuál es la solución cuando la cantidad de dispositivos de red supera la capacidad del controlador para
manejarlos. Si intentamos escalar agregando controladores, ¿cómo se comunican y quién coordina la
coordinación entre los controladores? La Sección 6.1.3 aborda estas preguntas.

Alta disponibilidad (HA): el controlador centralizado no debe constituir un único punto de falla para la red.
Esto implica la necesidad de esquemas de redundancia en varias áreas. En primer lugar, debe haber
controladores redundantes de modo que la potencia de procesamiento esté disponible en caso de falla
de un solo controlador. En segundo lugar, los datos reales utilizados por el conjunto de controladores
deben reflejarse de forma que los controladores puedan programar los dispositivos de red de forma
coherente. En tercer lugar, las rutas de comunicación a los diversos controladores deben ser redundantes
para garantizar que siempre haya una ruta de comunicaciones en funcionamiento entre un conmutador
y al menos un controlador. Discutimos más sobre la alta disponibilidad en el contexto de una red SDN
moderna en la Sección 6.1.2 .

Seguridad: Tener un controlador centralizado significa que los ataques de seguridad pueden enfocarse en
ese punto de falla y, por lo tanto, existe la posibilidad de que este tipo de solución sea más vulnerable al
ataque que un sistema más distribuido. Es importante considerar qué pasos adicionales deben darse para
proteger tanto el controlador centralizado como los canales de comunicación entre este y los dispositivos
de red.

ForCES y 4D contribuyeron en gran medida a la evolución de los conceptos subyacentes a SDN: separación
de los planos de reenvío y control (ForCES) y tener un controlador centralizado responsable de las
decisiones generales de encaminamiento y reenvío (4D).

Sin embargo, ambas propuestas adolecen de una falta de implementaciones reales. Ethane, examinado
en la siguiente sección, se benefició de la experiencia que solo puede provenir de una implementación de
la vida real.

3.2.7. Ethane: política de red basada en controlador

documento titulado Rethinking Enterprise Network Control en 2007. Ethane es una solución basada en
políticas que permite a los administradores de red definir políticas relacionadas con el acceso a nivel de
red para los usuarios

Ethane se basa en tres principios fundamentales:

 La red debe regirse por políticas de alto nivel: al igual que 4D, Ethane defiende la idea de que la
red se rige por políticas definidas en niveles altos en lugar de por dispositivo. Estas políticas
deberían estar al nivel de los servicios y usuarios y las máquinas a través de las cuales los usuarios
pueden conectarse a la red.
 El enrutamiento para la red debe tener en cuenta estas políticas: las rutas que toman los
paquetes a través de la red deben estar dictadas por las políticas de alto nivel descritas en el
punto anterior y no como en el caso de las redes actuales, en las que los caminos se eligen en
directivas de nivel inferior.

Por ejemplo, es posible que se requiera que los paquetes invitados pasen a través de un filtro de algún
tipo, o ciertos tipos de tráfico pueden requerir el enrutamiento a través de rutas con poca carga. Parte
del tráfico puede ser muy sensible a la pérdida de paquetes; otro tráfico (por ejemplo, Voz sobre IP o
VoIP) puede tolerar paquetes caídos pero no latencia y demora. Estas políticas de nivel superior son
directrices más poderosas para organizar y dirigir los flujos de tráfico que las reglas de bajo nivel y las
específicas del dispositivo.

 La red debe exigir el enlace entre los paquetes y su origen: si las decisiones políticas se basan en
conceptos de nivel superior como el concepto de usuario, entonces los paquetes que circulan en
la red deben ser rastreables hasta su punto de origen (es decir, el usuario o máquina que es la
fuente real del paquete).

hay muchas similitudes entre esta solución y OpenFlow. El comportamiento de los conmutadores Ethane
es generalmente el mismo que el de los conmutadores OpenFlow de hoy en día, que reenvían y filtran
paquetes basados en las tablas de flujo que se han configurado en el dispositivo. Si el interruptor no sabe
qué hacer con el paquete, lo reenvía al controlador y espera otras instrucciones.
3.3 Nacimiento Redes definidas por software

3.3.1 El nacimiento de OpenFlow

Así como las secciones anteriores presentaron estándares y propuestas que fueron precursores de SDN,
al ver SDN a través de un período de gestación, la llegada de OpenFlow es el punto en el que nació
realmente SDN.

La especificación OpenFlow delinea tanto el protocolo que se utilizará entre el controlador y el cambiar
así como el comportamiento esperado del interruptor.

La siguiente lista describe el funcionamiento básico de una solución OpenFlow:

• El controlador rellena el interruptor con las entradas de la tabla de flujo.

• El interruptor evalúa los paquetes entrantes y encuentra un flujo coincidente, luego realiza la acción
asociada.
• Si no se encuentra ninguna coincidencia, el interruptor reenvía el paquete al controlador para obtener
instrucciones sobre cómo tratar con el paquete
• Típicamente, el controlador actualizará el interruptor con nuevas entradas de flujo a medida que los
nuevos patrones de paquetes recibido, por lo que el cambio puede tratar con ellos localmente. También
es posible que el controlador programar reglas de comodines que gobernarán muchos flujos a la vez.

3.3.2 Open Networking Foundation

Ahora es el guardián del estándar OpenFlow y consiste en una serie de grupos de trabajo, muchos de los
cuales se enumeran en la Tabla 3.2.
3.4 Mantenimiento de la interoperabilidad SDN

 Plugfests. entornos en qué proveedores pueden traer sus dispositivos y software para probarlos
con dispositivos y software de otros proveedores.
 Laboratorios de interoperabilidad.
 Programas de certificación.
 Educación y consultoría.

3.5 Contribuciones de fuente abierta

Esta sección examina las formas en que el código abierto contribuye a este proceso.

3.5.1 El poder del colectivo

Sistemas operativos. El sistema operativo Linux fue desarrollado como de código abierto y se usa hoy para
control de innumerables dispositivos que utilizamos todos los días, desde grabadoras de video digital
(DVR) hasta teléfonos inteligentes.

Bases de datos. MySQL es un ejemplo de una base de datos de código abierto.

Servidores. Cuando accedemos a ubicaciones en Internet, muchos de esos servidores ejecutan

aplicaciones software de servidor y utilizando herramientas que han sido desarrolladas a lo largo del
tiempo por la comunidad de código abierto.

Seguridad. La aplicación del modelo de código abierto también se suele considerar para ofrecer un servicio
más seguro entornos. El código abierto puede ser más seguro debido a la revisión por pares y la caja
blanca evaluación que ocurre naturalmente en el paradigma de desarrollo de fuente abierta. Open SSL es
probablemente el principal ejemplo de una fuente abierta ampliamente utilizada juego de herramientas
de cifrado.

Compartición de archivos. El protocolo BitTorrent es un ejemplo de un protocolo abierto de gran éxito [3]
utilizado para compartir archivos.

3.5.2 El peligro del colectivo

Las áreas de riesgo incluyen calidad, seguridad, puntualidad y soporte. Aquí explicamos cómo estos
riesgos pueden ser mitigados Mantener los enfoques competitivos de alta calidad pueden ser evaluados
por la comunidad, y la admisión a un lanzamiento es realmente controlado por individuos clave asociados
con el esfuerzo de código abierto. Estos mismos factores sirven para minimizar el riesgo de amenazas a la
seguridad. Dado que el código fuente está abierto para que todos lo vean, es más difícil para ocultar
amenazas maliciosas como puertas traseras.

3.5.3 Contribuciones de código abierto a SDN

Con base en las discusiones previas, es fácil ver el valor potencial de las contribuciones de código abierto
en el camino hacia SDN. Los enormes avances en la tecnología SDN se pueden atribuir a proyectos de
código abierto. Múltiples implementaciones de código abierto de conmutadores SDN, controladores y
aplicaciones están disponibles.

3.6 Mecanismos heredados evolucionan hacia SDN

Las capacidades de los conmutadores heredados a veces se ampliaban para admitir configuraciones de
políticas detalladas relacionadas con la seguridad, la QoS y otras áreas. Las antiguas API se ampliaron para
permitir la programación centralizada de estas características. Algunos proveedores de SDN han basado
toda su solución SDN en una amplia familia de API extendidas en switches heredados, orquestados por
un controlador centralizado.

3.7 Virtualización de red

Los sistemas complejos han evolucionado para usar tanto la VLAN como las tecnologías de túnel para
proporcionar soluciones de virtualización de red. Uno de los esfuerzos comerciales más exitosos en este
espacio fue Nicira, ahora parte de VMware. Desde el principio, Nicira afirmó que había siete propiedades
de virtualización de red

1. Independencia del hardware de red

2. Fiel reproducción del modelo de servicio de red física
3. Siguiendo un modelo operacional de virtualización informática
4. Compatibilidad con cualquier plataforma de hipervisor
5. Aislamiento seguro entre redes virtuales, redes físicas y el plano de control
6. Desempeño y escalabilidad de la nube
7. Aprovisionamiento y control de la red programática

la virtualización de la red se ha convertido en sinónimo de SDN.

3.8 ¿Puedo llamar a mi red SDN?

una red SDN caracterizada por cinco rasgos fundamentales: separación de planos, un dispositivo
simplificado, control centralizado, automatización y virtualización de red y apertura.

3.9 Conclusión
Con las comunidades de investigación y de código abierto que claman por un entorno abierto para la
investigación y experimentación ampliadas, así como las necesidades urgentes de los centros de datos
para una mayor agilidad y virtualización, los proveedores de redes se han visto forzados a ingresar en el
mundo de SDN.

Cómo funciona SDN

Agrupamos las más importantes de estas implementaciones SDN alternativas en dos
categorías: SDN a través de API existentes y SDN a través de redes de superposición
basadas en hipervisor, que discutiremos por separado en la última mitad de este capítulo
4.1 Características fundamentales de SDN
evolucionó a partir de propuestas anteriores, estándares e implementaciones como
ForCES, 4D y Ethane, se caracteriza por cinco rasgos fundamentales: separación de
planos, un dispositivo simplificado, control centralizado, automatización de red y
virtualización y apertura.
4.1.1 Separación del plano

La primera característica fundamental de SDN es la separación de los planos de reenvío

y control
La funcionalidad de reenvío, incluida la lógica y las tablas para elegir cómo tratar los
paquetes entrantes según características como la dirección MAC, la dirección IP y la
identificación de la VLAN, reside en el plano de reenvío.
Los protocolos, la lógica y los algoritmos que se utilizan para programar el plano de
reenvío residen en el plano de control. El plano de control determina cómo deben
programarse o configurarse las tablas de reenvío y la lógica en el plano de datos.
la tarea principal de ese plano de control es ejecutar protocolos de enrutamiento o
conmutación para que todas las tablas de reenvío distribuidas en los dispositivos a lo
largo de la red permanezcan sincronizadas. El resultado más básico de esta
sincronización es la prevención de bucles
4.1.2 Un dispositivo simple y control centralizado
La siguiente característica es la simplificación de los dispositivos, que luego son
controlados por un sistema centralizado que ejecuta un software de gestión y control.
En lugar de cientos de miles de líneas de software de plano de control complicado que
se ejecutan en el dispositivo y permiten que el dispositivo se comporte de forma
autónoma, ese software se elimina del dispositivo y se coloca en un controlador
centralizado.
Este controlador basado en software administra la red utilizando políticas de mayor nivel.
4.1.3 Automatización de red y virtualización
La abstracción de estado distribuido proporciona al programador de red una vista de red
global que protege al programador de las realidades de una red que en realidad está
compuesta por muchas máquinas, cada una con su propio estado, que colaboran para
resolver problemas en toda la red.
La abstracción de reenvío permite al programador especificar los comportamientos de
reenvío necesarios sin ningún conocimiento de hardware específico del proveedor. Esto
implica que cualquiera que sea el idioma o los lenguajes que surjan de la abstracción
deben representar una especie de denominador común mínimo de las capacidades de
reenvío del hardware de red.
abstracción de especificación, debe poder expresar los objetivos deseados de la red
global sin perderse en los detalles de cómo la red física implementará esos objetivos
4.1.4 Apertura
La presencia de estas interfaces abiertas también fomenta los proyectos de código
abierto relacionados con SDN. Las API definidas deben proporcionar al software el
control suficiente para experimentar y controlar varias opciones de plano de control.
4.2 Operación SDN
Los componentes básicos de SDN: los dispositivos SDN, el controlador y las
aplicaciones.
La forma más fácil de entender la operación es mirarla de abajo hacia arriba,
comenzando con el dispositivo SDN
Los dispositivos también contienen los datos que controlan esas decisiones de
reenvío.
Los datos en sí están representados por los flujos definidos por el controlador,
como se representa en la parte superior izquierda de cada dispositivo.
Un flujo es unidireccional ya que los paquetes que fluyen entre los mismos dos
puntos finales en la dirección opuesta podrían constituir un flujo separado.
Cuando el dispositivo SDN recibe un paquete, consulta sus tablas de flujo en
busca de una coincidencia. Estas tablas de flujo se habían construido
previamente cuando el controlador descargaba las reglas de flujo apropiadas al
dispositivo. Si el dispositivo SDN encuentra una coincidencia, toma la acción
configurada apropiada, que generalmente implica reenviar el paquete.
Si no encuentra una coincidencia, el conmutador puede soltar el paquete o
pasarlo al controlador, según la versión de OpenFlow y la configuración del
conmutador.