Etherblade.net Encapsulador y sustitución de importaciones para componentes de red (segunda parte)

En el primer artículo, quería mostrar que el desarrollo de FPGA es una tarea interesante, y la implementación de un encapsulador de flujo es un proyecto bastante simple que bien podría actuar como un proyecto académico para estudiantes senior o estudiantes de posgrado.

Aunque vale la pena hacer el diseño del hardware solo por diversión, en este artículo quiero prestar atención al valor práctico de esta lección. En particular, nuestra conversación continuará sobre cómo crear una infraestructura de red para operadores de telecomunicaciones utilizando el encapsulador Etherblade.net implementado en FPGA.

Este texto es una idea de las tecnologías de red y para encajar en un tema tan extenso dentro del marco de un artículo, decidí escribirlo en el contexto de algún plan de acción o, si lo desea, la respuesta a la siguiente pregunta: "Cómo reemplazar el equipo usando FPGA y código abierto de la manera más eficiente posible". de Cisco y Juniper ".
Entonces comencemos.

El concepto de SDN (red definida por software) contra grandes proveedores

Tradicionalmente, durante décadas, los equipos de red han sido fabricados por gigantes como Cisco y Juniper. Hoy, los grandes operadores de redes que desarrollan sus propios equipos de red se están convirtiendo en la nueva norma. El objetivo que quieren lograr es la independencia de los proveedores de componentes y un mejor control sobre la infraestructura.

En Rusia, por razones políticas, este enfoque asociado con el reemplazo de productos de terceros con sistemas con un mayor porcentaje de componentes intelectuales desarrollados localmente (bloques de propiedad intelectual o núcleos de propiedad intelectual) generalmente se denomina sustitución de importaciones.

Debe entenderse que las grandes corporaciones tienen una gran cantidad de recursos de ingeniería y dependen de un modelo de desarrollo integrado verticalmente. ¿Y qué hay de los fabricantes relativamente pequeños?

La falta de recursos puede compensarse con código abierto. Y la falta de integración vertical con la distribución correcta de subtareas entre jugadores más pequeños.

La arquitectura de los dispositivos de red producidos tradicionalmente por grandes proveedores se segmenta fácilmente. Para paralelizar el proceso y resaltar subtareas individuales, el concepto de SDN (red definida por software) sugiere segmentar la arquitectura de los dispositivos de red en niveles, en particular, separando el nivel de gestión de red (plano de control) del nivel de dispositivos de transferencia de datos (plano de datos).

Observo que hoy el SDN se ha convertido en una poderosa herramienta de marketing para grandes proveedores que lo presentan como un conjunto de "nuevas características" útiles para el usuario final. Lo curioso es que históricamente, como ya señalé, el concepto de SDN se creó justo en contraste con los gigantes de la industria.

Entonces, SDN ofrece un modelo de arquitectura de un enrutador de red en forma desmontada. Nuestra tarea es identificar el componente que nos interesa en este modelo y comenzar a desarrollarlo.

"Comencemos por lo pequeño": encapsulación en enrutadores y superposición SDN

Es natural resolver todas las necesidades del mundo de una vez. Por lo tanto, cuando se construyen sistemas grandes, tiene sentido comenzar con poco y hacer que el sistema sea extensible, de modo que se pueda introducir una funcionalidad adicional integrando bloques adicionales o modificando los existentes. Con las palabras "comenzar con poco" me refiero a la selección de alguna función de red completa suficiente para construir un sistema que funcione.

En el proyecto Etherblade.net, como tales funciones, se decidió implementar un mecanismo para encapsular el tráfico de red.

La encapsulación en redes es una cosa común. "Desegreguemos" el enrutador y consideremos cómo sus componentes se corresponden con los componentes del modelo SDN y determinemos qué lugar ocupa la encapsulación en ambos modelos.

Por ejemplo, tome uno de los enrutadores que se muestran en la figura al comienzo del artículo y descríbalo en la figura a continuación, pero ya en forma "preparada".
En la misma figura, contrastamos el enrutador con un "modelo SDN superpuesto" alternativo que proporciona una funcionalidad similar.



El nivel superior (verde) es el plano de control / orquestación SDN. Este es el cerebro del sistema, de hecho, el microprocesador en el que se ejecuta el software de red de control. En los enrutadores tradicionales, este componente está integrado. En SDN, esta funcionalidad generalmente se lleva a un "controlador de orquestación" externo, una computadora que sirve a muchos dispositivos de red.

Nivel medio (azul): ruta de reenvío. El papel principal de este nivel es la provisión de transporte de red (conmutación / enrutamiento de tráfico). En los enrutadores tradicionales: esta funcionalidad se implementa como una unidad de conmutación interna. En nuestro modelo de "superposición SDN", la función de este componente de "conmutación" se puede reducir completamente conectando directamente los dispositivos de borde (caja blanca) a la red de transporte.

Inferior (naranja): borde / nivel de acceso. En estos componentes, se producen todas las manipulaciones con el tráfico de red, como la encapsulación y otras conversiones de protocolos. Este nivel se caracteriza por una alta velocidad de procesamiento y funcionalidad determinista, un gran lugar para ASIC / FPGA. En los enrutadores tradicionales, esta funcionalidad se implementa en módulos lineales (tarjetas de línea), en SDN estos son los llamados "dispositivos de caja blanca".

Por lo tanto, resumiendo lo anterior, podemos decir que Etherblade.net es esencialmente un proyecto para desarrollar dispositivos "whitebox" para "SDN-overlay".

"Reenviar a centros de datos !!!" - encapsulador en función de NFV (virtualización de funciones de red)

Habiendo descubierto cómo se ve estructuralmente el sistema que estamos desarrollando, tiene sentido hablar sobre las opciones para su realización física.



A la izquierda hay un encapsulador Etherblade como un dispositivo CPE separado (versión del campus). A la derecha está el encapsulador Etherblade implementado dentro del servidor (opción para centros de datos).

Es interesante que al implementar un encapsulador en una placa con una interfaz PCIe y "ocultar" esta placa dentro del servidor, podemos crear la ilusión de virtualizar esta función de red. Este enfoque se llama NFV: virtualización de funciones de red.

El concepto de NFV implica deshacerse de dispositivos de red externos como firewalls, equilibradores de carga, etc. debido a la virtualización de sus funciones dentro de los servidores. La implementación del encapsulador como una función NFV nos permite deshacernos de los enrutadores "edge" físicos.

Entonces, NFV está de moda y conveniente. La dificultad es que, en términos de diseño de hardware, frenar PCIe no es tan fácil como ethernet. Si ethernet es un protocolo serie serial, entonces PCIe es un protocolo transaccional complejo con muchos estados finales (esencialmente una pila de red implementada en hardware). No olvide que el sistema operativo requiere los controladores adecuados para funcionar con el dispositivo PCIe.

Una de las soluciones más elegantes para el problema es el uso de placas FPGA, similar a la que se muestra al principio del artículo. La siguiente figura muestra la arquitectura de la placa y ambas opciones para implementar el encapsulador en ella.



Como puede ver, esta placa FPGA tiene adaptadores de red "externos" integrados, que son esencialmente convertidores entre Ethernet y PCIe. Por lo tanto, la implementación del encapsulador en tales dispositivos hace posible obtener NFV "de inmediato", sin problemas innecesarios con PCIe y controladores de escritura.

De "privado a general": creación de un repositorio abierto de núcleos IP de red

Uno no puede estar en desacuerdo con el hecho de que hoy en día hay muchos ASIC de red especializados (por ejemplo, de Broadcom) que pueden traducir cualquier proyecto de este tipo en otra historia de la serie "Disfrutando trabajando con FPGA". El escepticismo es apropiado en este caso, sin embargo, quiero recordarle que el proyecto Etherblade.net no se limita a crear un dispositivo de red separado. El objetivo principal de Etherblade.net es crear un repositorio abierto de núcleos IP parametrizados y documentados.

Este repositorio puede convertirse en una base efectiva para crear una amplia gama de dispositivos de red (incluidos los más exóticos), que a su vez se pueden implementar tanto en FPGA como en forma de ASIC.

Sobre esto, termino. En el próximo artículo, iremos directamente al diseño de hardware, pero por ahora lo invito a que se familiarice con el proyecto más cerca de etherblade.net .