Virtualización de la LAN Gi: qué hacer y qué evitar

Bart SalaetsDirector de Tecnología de Campo | F5

Tras muchos años de debates y pruebas de concepto, la virtualización de funciones de red (NFV) está pasando de la fase conceptual a la de implementación.

Algunos proveedores de servicios han comenzado a desplegar plataformas de infraestructura NFV, mientras que algunos de ellos ya han habilitado sus primeros casos de uso y aplicaciones basados en NFV sobre estas plataformas.

La virtualización del núcleo de paquetes evolucionado (EPC) y de la LAN Gi es uno de los casos de uso que más interés está despertando actualmente en el sector.

Al implementar una red LAN Gi virtual, hay que responder a dos preguntas fundamentales. La primera se refiere a la consolidación: ¿consolidamos varias funciones de la red LAN Gi en una única función de red virtual (VNF) o descomponemos por completo la arquitectura de la red LAN Gi en múltiples VNF independientes?

La segunda cuestión se refiere a la escalabilidad. ¿Cómo podemos ampliar eficazmente esta arquitectura, dado que una sola máquina virtual puede no tener capacidad suficiente para gestionar la carga de trabajo de la red Gi LAN?

Para proteger y monetizar sus redes, los operadores móviles han ido implementando numerosas tecnologías diferentes en la LAN Gi, entre las que se incluyen, entre otras, la optimización de TCP, la optimización de vídeo, el enriquecimiento de cabeceras, la inspección profunda de paquetes, los cortafuegos Gi y la traducción de direcciones de red de nivel de operador (CGNAT).

Históricamente, muchas de estas funciones se implementaban en plataformas distintas, a menudo de diferentes proveedores. En los últimos años, los operadores móviles han ido consolidando y simplificando su arquitectura LAN Gi.

Gracias a la consolidación, los operadores móviles han podido reducir significativamente el coste total de propiedad. Al migrar esta arquitectura a una plataforma NFV —que se basa en hardware comercial estándar—, puede surgir la tentación de empezar a descomponerla en distintas VNF independientes, cada una dedicada a una única función.

Esta arquitectura desagregada tiene sin duda sentido si cada una de las distintas funciones de la LAN Gi se aplica a un subconjunto muy específico de flujos. Basándose en las políticas empresariales mediante la interacción con una función de políticas y reglas de tarificación (PCRF), un motor inteligente de clasificación de servicios situado en la entrada de la LAN Gi puede determinar qué flujos deben dirigirse o encadenarse a servicios concretos desplegados como VNF independientes. De este modo, dichas VNF solo tendrán que procesar el tráfico sobre el que deban actuar, lo que permite distribuirlo de forma muy eficiente entre todas ellas.

Sin embargo, si las funciones de la LAN Gi deben aplicarse a casi todo el tráfico, esta descomposición de funciones no aporta ningún valor. Tomemos como ejemplo la optimización de TCP y los cortafuegos Gi. Casi todo el tráfico de la LAN Gi debe ser procesado por estas dos funciones, por lo que consolidarlas en una única VNF ofrece mejoras de eficiencia similares a las de una implementación física.

De hecho, en este caso no se necesita un clasificador de servicios inteligente para seleccionar una VNF, ni tampoco hacer que el tráfico entre y salga de la capa SDN para pasar de una VNF a la siguiente. Además, añadir una función de cortafuegos a una función de optimización de TCP apenas aumenta la carga de la CPU, por lo que las ventajas de la consolidación siguen siendo aplicables en un entorno NFV.

Otro reto consiste en gestionar flujos de trabajo que superan la capacidad de una sola VNF. Algunos proveedores han optado por permitir que una VNF esté compuesta por varias máquinas virtuales (VM). La mayoría de las funciones de la LAN Gi son operaciones con estado, lo que significa que el tráfico de entrada y salida de los mismos flujos debe procesarse en la misma VM. Por tanto, si el tráfico de salida llega a una VM distinta de la que procesó el tráfico de entrada, es necesario establecer una comunicación entre las VM para redirigir el tráfico a la VM correcta. Evidentemente, esto provocará una degradación del rendimiento.

En F5, hemos optado por el enfoque de implementar siempre cada VNF como una única máquina virtual y considerar el escalado horizontal de la arquitectura a varias máquinas virtuales como un factor de diseño externo. Existen distintas técnicas de escalado horizontal, desde las más sencillas hasta las más avanzadas.

Una arquitectura de escalado horizontal muy sencilla se basa en la distribución del tráfico mediante hash de IP entre las distintas máquinas virtuales, por ejemplo, mediante rutas múltiples de igual coste (ECMP). Sin embargo, esta técnica presenta varios inconvenientes y resulta poco práctica para la mayoría de los casos de uso en la LAN Gi. Los enfoques basados en SDN para controlar la distribución del tráfico pueden evitar algunas de esas limitaciones de ECMP, pero las capacidades seguirían siendo algo limitadas y dependerían en gran medida del proveedor de SDN elegido.

Con diferencia, el enfoque más flexible y avanzado para escalar horizontalmente cualquier función de la LAN Gi, con total independencia de la red subyacente o de la SDN, consiste en utilizar un equilibrador de carga sin estado basado en software (que también se implementa mediante máquinas virtuales). Al no mantener estado, puede escalar horizontalmente de forma prácticamente ilimitada, ya que es posible añadir más máquinas virtuales para el equilibrado de carga sin estado sin perder la coherencia en la distribución del tráfico entre las máquinas virtuales que proporcionan las funciones de la LAN Gi.

Teniendo en cuenta lo anterior, creemos que es muy importante que cualquier operador móvil considere detenidamente tanto la consolidación como la escalabilidad horizontal al migrar su arquitectura de LAN Gi de la capa física a la virtual.

Sobre el autor

Bart SalaetsDirector de Tecnología de Campo | F5

Más artículos de Bart Salaets