Rediseñar la pasarela de red de banda ancha (BNG) en un mundo nativo de las funciones de red (NFV) y en el mundo nativo de la nube

Resumen ejecutivo

La creciente demanda de los consumidores de más ancho de banda y servicios por menos dinero ha llevado a las redes de los proveedores de servicios a su límite económico desde hace algunos años. Además, los proveedores de servicios de comunicaciones (CoSP) tienen que soportar múltiples tipos de tecnología de acceso (xDSL, PON, FWA y DOCSIS), al tiempo que hacen un mejor uso de las redes de fibra existentes y aumentan el rendimiento de la prestación de servicios, todo ello en un contexto de disminución de los ingresos. Se estima que el tráfico de datos de los clientes crecerá a un ritmo del 26% (año tras año) de 2017 a 2023,¹ las futuras soluciones de red deben mostrar un camino para resolver el reto de la tasa de crecimiento anual compuesto (CAGR) de los datos del mañana de forma rentable y escalable.

Para desafiar los límites del rendimiento, es necesario contar con la última y más avanzada tecnología, además de implementar esta tecnología con un enfoque integral y fácil de utilizar. Este documento propone el siguiente conjunto de principios de diseño para llevar las soluciones basadas en procesadores de arquitectura Intel® y la virtualización de las funciones de red (NFV) a un nuevo nivel de rendimiento y automatización de la red utilizando lo siguiente

• Configuración optimizada del servidor
• Modelo de software «de ejecución a finalización»
• Paquete de E/S inteligente y distribución de flujo
• Escalado independiente del control y los planos de usuario
• Consideraciones jerárquicas sobre la calidad del servicio
• Implementación de los fundamentos de la red nativa de la nube

Siguiendo estos principios, Intel ha demostrado casi 661 Gbps² de rendimiento de enrutamiento RFC2544 (cero pérdida de paquetes) para una pasarela de red de banda ancha virtual (vBNG) que se ejecuta en un único servidor con procesadores escalables Intel® Xeon® de tercera generación. Este documento describe este esfuerzo y propone una arquitectura vBNG para construir una infraestructura de red y unas funciones de red que permitan aprovechar mejor la infraestructura subyacente y afrontar el reto del CAGR de datos.

Para complementar el cambio del plano de datos de Banda Ancha a un ecosistema virtual, este documento también propone una arquitectura de despliegue utilizando el motor de orquestación de contenedores Kubernetes (K8s).

Broadband Network Gateway (Pasarela de red de banda ancha)

El BNG, también conocido como servidor de acceso remoto de banda ancha (BRAS), es el punto de agregación del perímetro de la red utilizado por los suscriptores para acceder a la red del proveedor de servicios de Internet (ISP). A través del BNG, los suscriptores se conectan a la red del ISP para descargar el tráfico originado por Internet y los servicios del ISP (por ejemplo, web, voz, datos y vídeo).

vBNG es una instanciación de software virtualizada de lo que suele ser un gran aparato de funciones fijas basado en ASIC que suele estar ubicado en una oficina central o en un punto de presencia (PoP) metropolitano.

Canal de aplicaciones de referencia

Cada generación de tecnologías Intel (por ejemplo, CPU, NIC, SSD, FPGA y aceleradores) aporta nuevas oportunidades para mejorar el rendimiento y la calidad de la experiencia (QoE) de los usuarios.

El plano de control es responsable de la autenticación y gestión de los suscriptores, incluido el acceso a los servicios de uso mensual y la configuración del plano de datos, en función de los perfiles de los suscriptores.

El plano de datos ascendente gestiona el flujo de tráfico desde los routers domésticos de los usuarios hasta la red del ISP. El tamaño medio de los paquetes del tráfico ascendente suele ser menor que el del tráfico descendente, y la cantidad de tráfico ascendente suele ser de cinco a ocho veces menor que el tráfico descendente. Aunque aplicaciones como Instagram, Snapchat y Periscope han hecho que los usuarios envíen grandes cantidades de datos a la red de los proveedores de servicios de Internet, los usuarios de banda ancha siguen siendo, en su gran mayoría, consumidores netos de datos. En los últimos años, la creación de datos y contenidos ha reducido la brecha entre el uso de ancho de banda ascendente y descendente.

Etapas de procesamiento ascendentes

El canal de referencia de Intel implementa las etapas de procesamiento ascendente mostradas en la figura 3 y describe lo siguiente:

Packet Rx (Recepción): El controlador de modo de sondeo (PMD) del kit de desarrollo del plano de datos (DPDK) se utiliza para recibir ráfagas de tramas desde el puerto del controlador de la interfaz de red (NIC) y enviarlas directamente a un hilo de enlace ascendente para comenzar el procesamiento de paquetes vBNG, descrito en las siguientes etapas.

Listas de control de acceso: La biblioteca de listas de control de acceso (ACL) de DPDK se utiliza para aplicar una lista ordenada de filtros (por ejemplo, máscaras, rangos, etc.) a la trama. Estos comprenden filtros de permiso y denegación, y todos los filtros se evalúan por paquete.

Clasificación de flujos: La biblioteca de clasificación de flujos DPDK se utiliza para identificar la sesión y clasificar el paquete en función de los campos seleccionados (por ejemplo, 5 tuplas).

Vigilancia de la medición: La API de medición y vigilancia del tráfico de DPDK se utiliza para aplicar un esquema de marcado y vigilancia de dos tarifas y tres colores al tráfico.

Reescritura DSCP: Esta etapa admite la clasificación opcional del tipo de tráfico y la reescritura del campo de punto de código de servicios diferenciados (DSCP) de IP para asignar el flujo a una clase de servicio (CoS) admitida por la red.

NAT: Opcionalmente, se realiza NAT 44 para convertir direcciones privadas a direcciones públicas.

Enrutamiento: Las encapsulaciones de la red de acceso se eliminan de los paquetes del plano de datos, y los paquetes se enrutan a la interfaz correcta de la red central para su transmisión. Cualquier encapsulación de la red central, como MPLS, se aplica aquí o en el bloque de transmisión de paquetes.

Packet Tx (Transmisión): El DPDK PMD se utiliza para enviar ráfagas de tramas al puerto NIC.

El plano de datos descendente gestiona el flujo de tráfico y datos desde la red de Internet y de los proveedores de servicios de Internet hasta el usuario final. Gestiona y agrupa el tráfico a los usuarios conectados al BNG. La función de bajada optimiza el ancho de banda y el uso de recursos para maximizar la calidad de vida de los usuarios, basándose en la clase de tarifa del usuario y en las prioridades del tráfico. El objetivo del ISP es garantizar que todos sus suscriptores reciban servicios de alta calidad, al tiempo que se maximiza la utilidad de la infraestructura de red. Para 2022, se prevé que el tráfico mundial de vídeo IP se cuadruplique de 2017 a 2022, una CAGR del 29%,³ y esta tendencia aumentará el tamaño medio de los paquetes del enlace descendente.

Etapas de procesamiento descendente

El canal de referencia de Intel implementa las etapas de procesamiento descendente mostradas en la figura 4 y describe lo siguiente:

Packet Rx: el DPDK PMD recibe las tramas del puerto NIC y las envía directamente a un hilo de enlace descendente para comenzar el procesamiento de paquetes vBNG, descrito en las siguientes etapas.

Listas de control de acceso (ACL): la biblioteca de listas de control de acceso (ACL) de DPDK se utiliza para aplicar una lista ordenada de filtros (por ejemplo, máscaras, rangos, etc.) a la trama. Esta etapa bloquea el reenvío de la ruta inversa.

NAT: Opcionalmente, se realiza NAT 44 para convertir direcciones públicas a direcciones privadas.

Gestión del tráfico: Cada paquete pasa por un bloque de QoS jerárquico (HQoS) para garantizar que los paquetes de alta prioridad se prioricen al transmitirlos a la red de acceso. Admite una construcción jerárquica escalable de cinco niveles (puerto, subpuerto, tubería, clase de tráfico y colas) de formadores y programadores de tráfico para garantizar el ancho de banda de los distintos servicios utilizados por los suscriptores. Cada canal se asigna a un único suscriptor.

Enrutamiento: Las encapsulaciones de la red de acceso se eliminan de los paquetes del plano de datos, y los paquetes se enrutan a la interfaz correcta de la red de datos para su transmisión. Cualquier encapsulación de la red de acceso, como VLAN, PPPoE, etc., se aplica aquí o en el bloque de transmisión de paquetes.

Packet Tx: Utilizando un controlador de modo sondeo (PMD), las ráfagas de los marcos se transmiten al puerto NIC.

Nueva propuesta de arquitectura y razonamiento

Para desplegar eficazmente una carga de trabajo BNG en un servidor de propósito general, deben considerarse los siguientes aspectos arquitectónicos y de implementación:

Implementación de un modelo de ejecución hasta finalización

Una de las consideraciones clave a la hora de diseñar un BNG basado en software es garantizar la escalabilidad del rendimiento según el enunciado del problema inicial de este documento. Al BNG se le debe asignar el número mínimo de recursos necesarios para soportar el número actual de suscriptores activos en cualquier momento del día. Esto significa que el BNG debe ser capaz de escalar tanto hacia arriba como hacia abajo en función de la carga de trabajo actual.

El canal del BNG de referencia de Intel utiliza un modelo de ejecución hasta el final para procesar las canalizaciones de enlace ascendente y descendente. Como resultado, todas las funciones del canal ejecutadas en un paquete se ejecutan en el mismo núcleo. Esto tiene la ventaja de que los paquetes no tienen que moverse entre los núcleos, minimizando así las pérdidas de caché y la latencia general. Un resultado directo de este patrón de diseño es que una instancia individual de vBNG no puede escalar más allá de un solo núcleo. El escalado más allá de un solo núcleo se realiza creando una nueva instancia vBNG que se ejecuta en un núcleo diferente. El NIC se programa (utilizando cabeceras personalizadas soportadas por el paquete Comms DDP) sobre la marcha para dirigir suscriptores específicos a cada nueva instancia individual de vBNG (más adelante en el documento se habla de esto).

La combinación de un modelo de ejecución hasta el final y un único núcleo que ejecuta una única instancia de vBNG elimina la necesidad de que el orquestador comprenda el funcionamiento interno de la aplicación vBNG para escalar. El orquestador puede escalar la capacidad hacia arriba o hacia abajo aumentando o disminuyendo el número de núcleos de CPU asignados al despliegue de BNG (5 vCPUs por Instancia con K8s), permitiendo una escalabilidad lineal en un servidor determinado. El orquestador puede optimizar la utilización de los recursos cuando dispone de información sobre el número de suscriptores (para un perfil de tráfico conocido) que puede soportar una instancia de núcleo único, que puede variar según la SKU de la CPU.

Separación del procesamiento del enlace ascendente y descendente

El uso de los recursos de la CPU por parte de los conductos de enlace ascendente y descendente del BNG no es simétrico, ya que el enlace descendente suele requerir más ciclos por paquete debido al tamaño inherente de los paquetes. Para programar eficazmente un BNG, el canal de referencia de Intel divide el enlace ascendente y el descendente en dos contenedores separados que pueden instanciarse y programarse por separado. Esta separación proporciona una mayor flexibilidad en la programación y en el uso de los recursos de la CPU. Por ejemplo, a un canal de enlace descendente se le puede asignar un núcleo físico completo (dos núcleos de hiperhilos hermanos), mientras que una canalización de enlace ascendente podría requerir solo medio núcleo físico (un núcleo de hiperhilos).

Asignación de una única conexión de E/S por canal

El canal de referencia de Intel debe ejecutarse en un servidor de plano de datos BNG conectado a un conmutador de hoja básico que pueda enrutar tanto el tráfico de acceso como el de red de datos. Con esta configuración, el conmutador enruta el tráfico de enlace ascendente procedente de los puertos de la red de acceso a los puertos BNG para su procesamiento y enruta los paquetes de retorno de las canalizaciones de enlace ascendente BNG a los puertos de la red de datos. El flujo se invierte para el tráfico de enlace descendente. Como mencionábamos antes, la cantidad de tráfico de enlace ascendente está aumentando con el tiempo, pero generalmente es solo una octava parte del tráfico de enlace descendente en una red de cable. Por lo tanto, un BNG que utilice puertos físicos separados y dedicados para las conexiones de los puertos de acceso y de la red de datos probablemente infrautilizará el ancho de banda de E/S disponible en los puertos de enlace ascendente. En cambio, si se comparten los puertos físicos de una NIC entre el tráfico de subida y el de bajada, se puede aprovechar al máximo el ancho de banda de E/S. Como una instancia de vBNG está dividida en dos aplicaciones de canalización separadas, cada canalización solo gestiona el tráfico de una sola dirección. Todo el tráfico se dirige hacia y desde el servidor a través del conmutador L2 simple, de modo que cada canalización no requiere puertos de red de acceso y datos dedicados. El servidor solo necesita una única conexión de E/S en la que recibe el tráfico del conmutador y devuelve el tráfico procesado al conmutador para su reenvío.

El enrutamiento del tráfico de los suscriptores a una instancia vBNG se realiza a través de una conexión dedicada de virtualización de entrada/salida de raíz única (SR-IOV) que puede enviar los paquetes que llegan al vBNG de acuerdo con su conmutador SR-IOV (con DDP). SR-IOV permite que un único puerto NIC físico se divida y comparta entre múltiples instancias de canalización, cada una con su propio puerto de E/S, es decir, una función virtual (VF). SR-IOV también proporciona flexibilidad en el uso de las NIC físicas, como por ejemplo dedicar una NIC física solo al tráfico de enlace descendente o compartir una NIC entre el tráfico de enlace ascendente y descendente. A medida que las velocidades de NIC alcanzan los 100 gigabits, se espera que el tráfico de enlace descendente y ascendente comparta la misma NIC física y estos principios influyen en la arquitectura de despliegue del vBNG actual.

Equilibración de E/S en el servidor

En los servidores de doble zócalo, las conexiones internas, como los hubs de controladores de plataforma (PCH) y los controladores SATA, suelen estar conectados a la CPU 0. Esto puede resultar en una distribución desigual del ancho de banda de E/S PCIe entre las CPU, con la mayor parte del ancho de banda conectado a la CPU 1. Para equilibrar el ancho de banda, la aplicación Intel vBNG ejecuta funciones de plano de control en la CPU 0 y las del plano de datos en la CPU 1.

Al implementar un BNG en un servidor de propósito general, es importante garantizar que haya suficiente ancho de banda de E/S para utilizar completamente los recursos de CPU disponibles en la plataforma (es decir, el objetivo es estar conectado a la CPU y no a la E/S). La llegada de la Separación del Plano de Control y de Usuario (CUPS)⁴ para el BNG permite dedicar un servidor entero a la ejecución del plano de datos del BNG. Todo el procesamiento de datos se localiza en un único zócalo para aumentar la eficiencia del rendimiento, lo que requiere que se conecte una cantidad igual de E/S a cada zócalo para lograr un rendimiento óptimo. El aprovisionamiento de ranuras PCIe Gen 4 (16 GT/s) de 2x16 o 4x8 carriles en cada zócalo proporciona un ancho de banda de E/S total de 800 Gbps en el servidor, equilibrado a partes iguales entre los dos zócalos (véase el Apéndice para los detalles de configuración del servidor).

Distribuir flujos a través de una tarjeta de interfaz de red (NIC)

Como se describe anteriormente, cada instancia de BNG tiene un número establecido de vCPU que procesa el tráfico de los suscriptores. Es necesario algún tipo de distribuidor para repartir los flujos de los suscriptores entre las vCPU. Esta distribución puede realizarse por software utilizando núcleos dedicados, pero este enfoque presenta varias desventajas. En primer lugar, esta función de distribuidor puede convertirse en un cuello de botella de rendimiento, ya que todos los flujos deben pasar por esta función de software. En segundo lugar, tener uno o varios núcleos dedicados a realizar la distribución reduce la cantidad de ciclos de CPU disponibles para realizar el procesamiento de la carga de trabajo BNG real, lo que reduce el número de suscriptores BNG que el servidor puede manejar.

Estas desventajas pueden superarse distribuyendo los flujos en la NIC a las VF de SR-IOV o a las colas en el PMD, lo que elimina el cuello de botella del software, reduce la latencia a través del sistema y proporciona al BNG los núcleos y ciclos de CPU que, de otro modo, serían utilizados por la tarea de distribución.

Asignación de una única conexión de E/S por canal

Función de configuración de dispositivos (DCF)

El adaptador de red Ethernet Intel® E810 es una NIC que admite la distribución de flujos mediante la tecnología Devicce Config Function (DCF). DCF establece reglas de flujo a través de un VF de confianza que permite al usuario mantener la función física SR-IOV vinculada al controlador Linux para la gestión y la recopilación de métricas, como se ve en la figura 8. Al distribuir los flujos en el adaptador de red Intel® Ethernet E810 se debe tener en cuenta que, para distribuir los flujos entre las VF, se utiliza el conmutador SR-IOV, y para distribuir los flujos entre las colas, se utiliza el Flow Director (FDIR) o el Receive Side Scaling (RSS). En la implementación de BNG, los flujos se distribuyen utilizando VF, por lo que es el enfoque de este documento. Puede encontrar más información sobre RSS y FDIR en otros documentos técnicos de Intel Telco.

Personalización dinámica de dispositivos

Junto a DCF está la personalización dinámica de dispositivos (DDP) ⁵ que permite al conmutador SR-IOV filtrar más tipos de cabecera de paquetes que la cantidad predeterminada sin recargar la imagen NVM del controlador Ethernet. Para la implementación de la aplicación BNG, se utiliza el paquete de personalización dinámica de dispositivos (DDP) de telecomunicaciones (Comms). Una vez añadido, este paquete permite al controlador Ethernet dirigir el tráfico basado en los campos de cabecera PPPoE al VF de descarga del plano de control. El perfil DDP PPPoE permite a la NIC enrutar los paquetes a VF y colas específicas basadas en los campos de cabecera PPPoE únicos (descritos en la siguiente sección).

Reenvío de paquetes de plano de control

Para el tráfico del plano de control, como la configuración de la sesión PPPoE o los paquetes de control de enlace PPPoE, el plano de datos del BNG debe identificar y reenviar estos paquetes al plano de control para su procesamiento. En un BNG tradicional, el plano de control y el plano de datos se encuentran en el mismo lugar y se utiliza una cola de software local para mover los paquetes entre ellos. Con la llegada de CUPS, lo más probable es que el plano de control y el plano de datos correspondiente se encuentren en lugares físicos diferentes de la red. En tal caso, el planoo de datos BNG debe enviar los paquetes de control al plano de control generando un enlace físico para reenviarlos.

Consideraciones de HQoS

El QoS jerárquico es una función implementada en el canal de enlace descendente vBNG. Garantiza la conservación de la prioridad del tráfico cuando el tráfico procedente de la red central se programa para su transmisión en el canal de red de acceso de ancho de banda reducido a un suscriptor, y el ancho de banda disponible en un puerto determinado se comparte de forma eficiente entre todos los usuarios. El programador HQoS puede implementarse en la NIC, si se dispone de soporte, o como una función de software en el canal de procesamiento de paquetes antes de la función de transmisión. Como se ha comentado anteriormente, cada canal de enlace descendente tiene una única conexión de función virtual para E/S. En las siguientes secciones se describen tres modelos de implementación de HQoS:

Modelo de solo software

Un modelo de solo software implementa completamente el programa HQoS en software. Como se muestra en la figura 12, a cada canal de enlace descendente vBNG se le asigna parte del ancho de banda general del puerto y da forma a esa tasa de subpuerto. La ventaja de este método es que no se necesita soporte de hardware y permite escalar las instancias del planificador HQoS con canalizaciones de procesamiento de paquetes de enlace descendente. La desventaja de este método es que el ancho de banda no utilizado en una instancia vBNG no puede compartirse con otra instancia, lo que puede llevar a un uso subóptimo del ancho de banda del puerto.

Modelo híbrido de hardware / software

Un modelo híbrido puede utilizarse cuando los recursos de la NIC (por ejemplo, colas, programadores/nodos de configuración) no son suficientes para implementar completamente el planificador HQoS. En este modelo, cada instancia BNG implementa algunos niveles de programación/configuración de la jerarquía en el softwar, y los niveles restantes se implementan en NIC. La decisión de dividir la jerarquía entre el software y el hardware depende del número de recursos del NIC. Como ventaja, este modelo permite compartir el ancho de banda no utilizado de una instancia BNG entre otras instancias.

Modelo de descarga HQoS completa

Un modelo de descarga completa de HQoS requiere un NIC que pueda soportar la descarga completa del procesamiento de HQoS de todas las instancias de vBNG. Una de las principales ventajas de este modelo es que la CPU no interviene en HQoS, liberando ciclos de CPU para otros bloques de canal. La arquitectura vBNG propuesta admite estos tres modelos, dependiendo de las capacidades del hardware subyacente.

Orquestación del BNG

La arquitectura vBNG propuesta en este documento no limita la forma en que se virtualiza una instancia vBNG. Por ejemplo, se puede utilizar la virtualización virtual completa de una máquina virtual (VM) o los contenedores Linux. Cuando un vBNG se compone de dos canales individuales, el despliegue de cada uno en un contenedor separado puede ser mejor, ya que es una opción de virtualización ligera, en comparación con la implementación en máquinas virtuales. Los contenedores también permiten una inicialización y recuperación más rápida de las instancias siguiendo la convención en las implementaciones de red de alta disponibilidad. Para la implementación de una instancia de vBNG, tanto en la aplicación de referencia como en este documento, el motor de orquestación Kubernetes lanza un par de contenedores. En esta sección se analizará más a fondo cómo se logra esto bajo la convención paraguas de una función de red nativa de la nube (CNF). Las dos mayores influencias en el diseño y la implementación de vBNG son la arquitectura CUP y la red nativa de la nube. CUPS, descrito anteriormente, hace del plano de control y del plano de usuario dos entidades separadas que se comunican a través de una API establecida. Esta sección se centra principalmente en cómo el vBNG logra la red CloudNative a altas tasas de rendimiento. También se hace referencia en otros documentos de Intel a las siguientes convenciones que debe cumplir una aplicación de telecomunicaciones para considerarse una CNF:

• Alto rendimiento: la CNF debe aprovechar las características de reconocimiento de plataforma mejoradas (EPA) para garantizar una baja latencia y un alto rendimiento.
• Colocación ágil: la CNF debe permitir una colocación flexible para poder implementarse en cualquier plataforma preparada para las características EPA, y debe ser genérica para la infraestructura EPA proporcionada en las capas subyacentes.
• Gestión del ciclo de vida: utilizando controladores automáticos conscientes de la telemetría, la CNF debe garantizar que puede escalar los recursos bajo cargas de trabajo crecientes y retraer los recursos bajo cargas de trabajo decrecientes.
• Alta disponibilidad: la CNF debe presentar siempre una alta disponibilidad para la carga de trabajo requerida, incorporando una tolerancia extrema a los fallos en la arquitectura de los componentes para cumplir el acuerdo de nivel de servicio de tiempo de inactividad casi nulo. La CNF también debe utilizar el esquema de alta disponibilidad para mantener las interfaces que permiten actualizar el servicio de forma rápida y sencilla sin que ello afecte al servicio que presta.
• Capacidad de observación: la CNF debe garantizar que todas las métricas de red y de rendimiento de las cargas de trabajo estén expuestas a través de una plataforma fácil de consumir que permita una rápida depuración y modificación de la red.

Implementación del plano de datos

La implementación del vBNG sigue un estricto modelo de microservicios en el que cada elemento de la implementación de la aplicación se separa en la unidad de ejecución más pequeña posible que no afecte al rendimiento. La implementación completa del plano de datos (plano de no control) está separada en 3 componentes:

• Gestión de DP BNG
  • En resumen, esta sección se considera la interfaz entre el Plano de Control y el Plano de Datos en una implementación completo de CUPS
  • Esta sección es responsable de lo siguiente:
    • Recibir la configuración del plano de datos (agente PFCP)
    • Configuración y almacenamiento de la configuración del plano de datos (etcd)
    • Recuperación de los datos de telemetría de las instancias del plano de datos
    • Gestión de la escala de las Pods/Instancias vBNG
• Plano de datos BNG
  • Como se ha mencionado antes, esta sección es responsable de lo siguiente:
    • Los contenedores de reenvío vBNG de enlace ascendente y descendente
    • El agente Telnet etcd agente que se comparte entre el plano de gestión BNG DP y el plano de datos BNG, pero que está implementado físicamente en el plano de datos)
• Infraestructura
  • Esta sección utiliza los administradores de dispositivos y de la CPU del K8 para proporcionar todas las características de la EPA requeridas por la especificación de la CNF para obtener un rendimiento elevado.
  • Esta sección es responsable de lo siguiente:
    • El Kubelet K8s (gestiona el estado de contenedor del nodo)
    • El gestor de CPU K8s (suministra vCPU exclusivas a los contenedores vBNG)
    • El complemento de dispositivos SRIOV (suministra funciones virtuales SR-IOV bajo demanda a los contenedores vBNG)
    • El gestor de topología (garantiza que los recursos recibidos del host estén alineados con la topología NUMA)
    • La pila de flujo unificada (utiliza DCF y DDP para establecer las reglas de conmutación de SR-IOV que permiten el escalado basado en los campos de la cabecera del suscriptor)

Implementación de plano de control

El plano de control utilizado en la implantación del BNG está construido por BiSDN. Tiene la misma arquitectura de microservicios que los demás componentes de la implantación BNG, en la que cada elemento se implanta como una entidad contenedora. Para la implementación de BNG, el plano de control de BNG puede implementarse en el mismo clúster que el plano de administración de BNGDP y el plano de datos de BNG, o bien en un clúster remoto independiente para controlar varios clústeres de BNG. Si se implementa en el mismo clúster, utilizará las mismas interfaces de red de contenedores (CNI) que con otros componentes BNG; consulte la figura 16. Si el ingeniero de operaciones de red requiere que el plano de control del BNG se coloque en un clúster remoto, se espera que configure algo como el controlador de entrada K8s en el clúster del plano de datos para garantizar que el acceso al plano de control del BNG externo esté regulado y la carga equilibrada para que el agente DPPFCP reciba y analice los mensajes.

Descripción de la implementación

Combinando todas las propuestas de arquitectura comentadas anteriormente, es posible construir una solución BNG escalable, orquestada y habilitada para CUPS que utiliza de forma eficiente los recursos de E/S y de computación de un servidor basado en un procesador Intel®. Esta solución puede ayudar a los CoSP a responder a la necesidad de proporcionar un ancho de banda cada vez mayor a un coste menor, tal y como se indica al principio del documento. La figura 17 ofrece una descripción general detallada de una implementación de CUPS completa junto con todo el tráfico de banda ancha de entrada y salida.

Los análisis de rendimiento⁶.

Las mediciones de rendimiento en los bloques de canales azules se realizaron en un servidor de doble socket con la tecnología Intel® Hyper-Threading (tecnología Intel® HT) habilitada, la tecnología Intel SpeedStep® mejorada y la tecnología Intel® Turbo Boost deshabilitada. Se aplicó el mismo perfil de tráfico a todas las instancias (4000 flujos, tamaño de paquete de enlace descendente/arriba = 650 B), y se midió el rendimiento acumulado (enlace descendente+arriba) en todas las instancias. Los bloques grises opcionales no se activaron.

Rendimiento de un servidor basado en el procesador Intel® Xeon® con dos procesadores escalables Intel® Xeon® de 3ª generación 6338N que ejecuta instancias de contenedores vBNG. El rendimiento se escala de forma muy eficaz a medida que se implementan de cuatro a treinta y dos instancias vBNG con incrementos de cuatro instancias.

Con treinta y dos instancias implementadas, el rendimiento es de 661 Gbps cuando se utiliza la metodología de prueba RFC2544 con una pérdida de paquetes del 0,001%. Esto se logra utilizando 96 núcleos de procesamiento de datos (1,5 núcleos por instancia durante treinta dos instancias). Todos los recursos utilizados por la aplicación BNG son locales para el socket. Se ha comprobado que está ligada a la E/S, pero no a la CPU.

Algo que hay que tener en cuenta respecto a estos resultados es que se ejecutaron en una configuración de "solo Docker" en la que no se utilizó K8 para escalar las instancias hacia arriba y hacia abajo.

Resumen

La futura viabilidad de los equipos de red basados en NFV que se ejecutan en servidores de uso general depende de la capacidad de dar servicio a un volumen de tráfico cada vez mayor de manera rentable. Este documento aporta consideraciones de arquitectura y datos de evaluación comparativa que demuestran el enorme potencial del procesamiento de paquetes basado en NFV. Además, los CoSP pueden ofrecer conectividad de red y nuevos servicios desde el perímetro de la red, utilizando para ello una combinación de soluciones BNG y de borde de servicio. Al replantearse cómo se crean e implementan las funciones de red virtualizadas, surgen nuevas posibilidades, como:

1. Redefinir la unidad de rendimiento desde el número de VM o contenedores hasta el número de núcleos que ofrecen un aumento casi lineal del rendimiento de enlace ascendente y descendente.
2. Crear un modelo agnóstico a la arquitectura de la función de red virtual (VNF) (es decir, VM, contenedor o baremetal).
3. Generar un model de precio por hogar determinista que se mantenga predecible con el CAGR de tráfico.
4. Aumentar la disponibilidad de la red para convertir el gran bloque de sistemas en sistemas distribuidos, lo que permite a los CoSP gestionar mejor los dominios de fallo y contener las zonas afectadas, minimizando así las tormentas de conexión y los tiempos de interrupción.
5. Crear una infraestructura perimetral multifunción que pueda abordar tanto los servicios como los de NFV.

El rendimiento del BNG en bruto no es la respuesta de un solo punto de datos, sino un debate sobre la ubicación de la red, la densidad de suscriptores, el ancho de banda medio por suscriptor y el CAGR de tráfico a lo largo del ciclo de vida de la implementación. La arquitectura vBNG presentada en este documento permite a los CoSP modelar el rendimiento del enlace ascendente y descendente y escalar la función del plano de control y del usuario de forma independiente en servidores de propósito general de manera predecible y fiable.

*Todos los vfs están vinculados al módulo igb_uio para uso de la aplicación.
**El tamaño de los marcos citados es el tamaño máximo del marco en cualquier momento del procesamiento.
(por ejemplo, enlace ascendente 128 Byte =120 byte +{2x4Byte etiquetas vlan de acceso})