Exposición 1111

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 5

- Exposición

El primer punto que vamos abarcar es los principios que definieron a la arquitectura SDN y la
presentación de la arquitectura misma.

Estos principios estan asociados a los precursores de SDN, que entre los mas importantes estan
el proyecto Ethane y Openflow.

De ethane podemos decir que se basa en estas tres ideas fundamentales.

Gestion basada en políticas: es un enfoque en el que la política de seguridad de la red se define


en un lenguaje de alto nivel que permite a los administradores de red definir políticas para el
acceso a la red y la gestión del trafico. SDN ha adoptado este principio lo que permite a los
adminitradores de red definir políticas que rigen el acceso a al red, la seguridad y la gestión del
trafico

Luego estas las siguientes ideas que son comunes en ambos proyectos tanto como ethane y
como openflow.

Separacion del plano de control y del plano de datos: tanto Ethane como OpenFlow separan los
planos de control y datos, lo que permite a los administradores de red configurar y administrar
la red independientemente del hardware subyacente. Esta separación facilita la administración
y actualización de dispositivos de red, lo que permite a los administradores de red responder
rápidamente a los requisitos cambiantes de la red.

Control centralizado: SDN adopta el principio de control centralizado de Ethane y Openflow,


que separa los planos de control y datos en la arquitectura de la red. El plano de control está
ubicado en un controlador central, mientras que el plano de datos reside en dispositivos de red
como conmutadores y enrutadores. Este control centralizado permite a los administradores de
red administrar la red de manera más eficiente y dinámica.

Finalmente tenemos a la idea que mas desarrolla openflow que es la

Programabilidad de la red: en el que incorpora una interfaz de programación estandarizada y


abierta para la programabilidad de la red, esto permite la interoperabilidad entre diferentes
dispositivos de red y fabricantes asi como tambien permite la creación de política de red
pesonalizada y especificas para las necesidades de cada organización, lo que la hace eficiente y
escalable

Entonces de estos principios es que posteriormente se define la arquitectura SDN establecido


en 3 planos

Planos de datos: que esta compuesto por los dispositivos de red sea (conmutadores,
enrutadores, etc) y que en general reciben el termino de switches ya que su única función es el
reenvio de paquetes porque ya no posee el plano de control.

Plano de control: es el encargado de tomar decisiones y controlar el comportamiento de los


dispositivos de red mediante la programación en los controladores SDN}

Plano de Gestion: es donde se desarrollan las aplicaciones para automatizar tareas de


configuración y despliegue de nuevos servicios en la red.

Y por últimos esta las interfaces que conectan a estas capas que vendrían hacer las APIS, para
el caso de la comunicación de la capa de datos con la capa de control esta openflow y para la
comunicación de la capa de control con la capa de aplicación se encuentra una variedad de
opciones porque todavía no se ha estandarizado un protocolo en particular.

Ahora sigue los componentes que definen una arquitectura SDN

Los planos de datos, control y gestión se subdividen capas

El plano de datos tiene la capa de infraestructura de red y interfaces hacia al sur.

Capa de infraestructura: es similar a la red tradicional que contiene varios dispositivos de red y
hardware físico como conmutadores y router.el mas común que vamos a observar es el switch
openflow el que se divide en 3 partes:

1. Canal seguro: es la conexión entre el controlador remoto y el switch que se utiliza para
enviar y recibir información de control. El canal seguro proporciona autenticación y
cifrado a través de TLS para garantizar la seguridad de la comunicación.
2. Tabla de flujo: es donde se almacenan las reglas de flujo que el switch utiliza para
tomar decisiones sobre cómo procesar los paquetes que recibe en los puertos. La tabla
de flujo es controlada por el controlador remoto a través del canal seguro (Secure
Channel).
3. Openflow protocolo de comunicación utilizado en los switches OpenFlow para permitir
el control remoto de su tabla de flujo, función principal del protocolo OpenFlow es
permitir que un controlador de red externo programe y controle la forma en que los
paquetes de red se procesan en el switch.

Capa de interfaces hacia el sur (southbound intergfaces)

Las interfaces hacia el sur (APIs hacia el sur) se utiliza para enlazar el plano de control y los
dispositivos de reenvio, y actualmente el protocolo openflow es el estandar abierto hacia el sur
mas aceptado e implementado para las SDN.

El protocolo Openflow proporciona tres datos esenciales a los sistemas operativos de red.

1. Mensaje que envia los dispositivos de reenvio al controlador cuando ocurre un cambio
de enlace o puerto
2. Estadísticas de flujo producidad por los dispositivos de reenvio y recogidas por el
controlador.
3. Paquetes reenviados al controlador cuando el dispositivo de reenvio no sabe como
tratar un flujo entrante

Capa de hipervisor de red:

Que en la arquitectura SDN, se utiliza para virtualizar y gestionar los recursos de red en una red
virtualizada. El hipervisor de red se encarga de proporcionar una capa de abstracción entre la
infraestructura física de red y la red virtualizada, permitiendo que la red virtualizada se
adapte de forma más dinámica y flexible a las necesidades de las aplicaciones.

En otras palabras, el hipervisor de red en SDN permite la creación de redes lógicas o virtuales
que se superponen a la infraestructura física de red existente, lo que permite la segmentación
de la red y la asignación de recursos de red específicos a cada red virtual.
Capa de Sistema operativo de red

la capa de sistema operativo de red se refiere a la capa de software que se encarga de la


gestión y control de la red. es responsable de comunicarse con los switches y otros dispositivos
de red para programar y controlar su comportamiento. Esto se logra a través de la utilización
de controladores de red que se ejecutan en la capa de sistema operativo de red y que pueden
programar y gestionar los switches en la red mediante el protocolo OpenFlow u otros
protocolos de control de red.

Los controladores se dividen en dos categorías: centralizados y distribuidos

• Centralizados: se trada de un único elemento individual que se ocupa de todo los


dispositivos de transmisión presentes en la red.
• El controlador distribuido, por otro lado, es un controlador de red que se distribuye en
varios dispositivos de la red. En este caso, cada dispositivo de red tiene su propio
controlador local, y estos controladores trabajan juntos para controlar y gestionar la
red.

La principal diferencia entre un controlador centralizado y uno distribuido es que el primero


tiene una vista global y centralizada de toda la red, lo que le permite tomar decisiones más
coherentes y unificadas. Sin embargo, el controlador centralizado también puede ser un punto
único de fallo, y puede generar un mayor tráfico de red debido a la comunicación directa con
todos los dispositivos de la red.

Por otro lado, el controlador distribuido puede proporcionar una mayor redundancia y
tolerancia a fallos, ya que cada controlador local puede tomar decisiones de manera autónoma
y la red puede seguir funcionando incluso si uno o varios dispositivos fallan. Además, el
controlador distribuido puede reducir el tráfico de red al tener una comunicación más limitada
entre los controladores locales.

Capa de interfaces hacia el norte (NBI, Northbound Interfaces)

La interface hacia el norte permite a los desarrolladores la libertad de desplegar sus


aplicaciones sin ser afectados y limitado por la complejidad de las redes subyacentes. Para ello,
la NBI tiene que permitir que las aplicaciones puedan expresar sus necesidades y limitaciones
en el lenguaje de programación específico de la aplicación, y el controlador SDN debe traducir
esos requisitos en el lenguaje empleado en la capa de infraestructura para realizar la provisión
de recursos y servicios que satisfagan los requisitos de la aplicación

Capa de virtualización basada en lenguaje

La virtualización basada en lenguaje en SDN se refiere a la capacidad de utilizar lenguajes de


programación de alto nivel para describir y definir la configuración y el comportamiento de las
redes definidas por software (SDN). Esta capa de virtualización permite a los administradores
de redes definir y modificar la topología de la red, la gestión de recursos y la seguridad de la
red utilizando un lenguaje de programación común, en lugar de tener que programar
directamente en el lenguaje de bajo nivel de la plataforma de SDN.

Capa de lenguaje de programación

La capa de lenguajes de programación en SDN se refiere a la posibilidad de utilizar diferentes


lenguajes de programación para definir y configurar la red definida por software (SDN). La idea
detrás de esta capa es permitir que los administradores de redes elijan el lenguaje de
programación que mejor se adapte a sus necesidades y habilidades, en lugar de tener que
programar directamente en el lenguaje de bajo nivel de la plataforma de SDN.

Capa de aplicaciones de red

La Capa VIII en SDN se refiere a las aplicaciones de red que se ejecutan en la parte superior de
la plataforma SDN. Estas aplicaciones son creadas por desarrolladores de software y están
diseñadas para aprovechar la flexibilidad y la programabilidad de la arquitectura SDN para
resolver problemas específicos de la red o proporcionar nuevos servicios.

• Control de calidad de servicio (QoS)


• Monitoreo y análisis de red
• Seguridad de red
• Automatización de red
• Encaminamiento adaptativo
• Balance de carga
• Roaming ilimitado

Ahora vamos a hablar acerca del funcionamiento de la arquitectura openflow

Para ello debemos recordar que el protocolo openflow tiene varias versiones y que el articulo
que se ha leído solo abarca la v1.0 y las versiones posteriores incluyeron mejoras en el
rendimiento, nuevas características y funcionalidades asi como correcciones de errores.

Arquitectura Openflow
La arquitectura OpenFlow consta de un controlador, una tabla de flujo y un canal seguro

• Tabla de flujo: Es el que indica como se de procesar el flujo.


• Canal Seguro: Refiere al medio por el que se conecta el switch al controlador y se
comunican usando el protocolo openflow.
• Controlador: el encargado de añadir o eliminar entradas en la tabla de flujos.
Ahora Los conmutadores OpenFlow reenvían datos en función de las tablas de flujo que
contienen información de configuración de todas las capas de la red a través de las
llamadas entradas de fujo.

Las entradas de flujo hacen referencia a las reglas que se definen en el switch para decidir
como procesar un paquete que ingresa a la red, son exactamente combinaciones de
ciertas palabras clave y acciones.

Asu vez estas entradas de flujo estan asociadas a tres acciones básicas:

1. Reenvió de flujo de paquetes a un puerto: Esto permite que los paquetes sean
encaminados a través de la red.
2. Encapsulación y reenvió del flujo de paquetes al controlador: Típicamente se usa
para el primer paquete en un nuevo flujo, para que el controlador pueda decidir si
el flujo debe ser añadido a la tabla de flujos
3. Descarte de los paquetes del flujo: Puede ser usado por seguridad , para parar
ataques de denegación de servicio o reducir el falso tráfico de descubrimiento
broadcast desde los hosts finales.

Tabla de flujo consta de tres partes:


• Regla o llamado tambien campo de encabezados: contiene un conjunto de
entradas que son cabeceras del paquete

• Contador: es el campo encargado de actualizar la información, el proceso lo hace


por tabla, por flujo, por puerto además realiza un conteo detallado sobre paquetes
recibidos y enviados

• Acción: es donde se encuentra la información de que hacer con el paquete de


entrada es decir que acción de reenvio se debe ejecutar y por cual puerto.

En la primera versión, OpenFlow 1.0, se establecieron las bases del protocolo, como la
capacidad de enviar paquetes de control al switch y de especificar el flujo de tráfico.
Posteriormente, en la versión 1.1, se incluyeron mejoras en el manejo de múltiples tablas de
flujo, el soporte para múltiples controladores y la capacidad de manipular paquetes de red.

Con la versión 1.2, se introdujeron nuevas características, como la capacidad de manejar


múltiples canales de comunicación y la implementación de grupos de puertos. En la versión
1.3, se mejoró la escalabilidad y se incluyó soporte para múltiples tablas de flujo en un solo
switch, así como la capacidad de controlar los flujos de forma dinámica.

En la versión 1.4, se agregó soporte para el manejo de flujos de alta velocidad y la capacidad de
agrupar varios flujos en una sola entrada de tabla. En la versión 1.5, se incluyó el soporte para
extensiones propietarias y la capacidad de aplicar políticas de calidad de servicio.

También podría gustarte