En el enrutamiento , el plano de datos , a veces llamado plano de reenvío o plano de usuario , define la parte de la arquitectura del enrutador que decide qué hacer con los paquetes que llegan a una interfaz de entrada. Por lo general, se refiere a una tabla en la que el enrutador busca la dirección de destino del paquete entrante y recupera la información necesaria para determinar la ruta desde el elemento receptor, a través de la estructura de reenvío interna del enrutador, hasta la(s) interfaz(es) de salida adecuadas.
En ciertos casos, la tabla puede especificar que se debe descartar un paquete. En tales casos, el enrutador puede devolver un código ICMP de "destino inalcanzable" u otro código apropiado. Sin embargo, algunas políticas de seguridad dictan que el enrutador debe descartar el paquete de forma silenciosa, para que un atacante potencial no se dé cuenta de que se está protegiendo un objetivo.
El elemento de reenvío entrante también reducirá el campo de tiempo de vida (TTL) del paquete y, si el nuevo valor es cero, descartará el paquete. Si bien la especificación del Protocolo de Internet (IP) indica que se debe enviar un mensaje de tiempo excedido del Protocolo de mensajes de control de Internet (ICMP) al originador del paquete (es decir, el nodo indicado por la dirección de origen), el enrutador puede configurarse para descartar el paquete de manera silenciosa (nuevamente de acuerdo con las políticas de seguridad).
Dependiendo de la implementación específica del enrutador, la tabla en la que se busca la dirección de destino podría ser la tabla de enrutamiento (también conocida como base de información de enrutamiento, RIB) o una base de información de reenvío (FIB) separada que se llena (es decir, se carga) por el plano de control de enrutamiento , pero que el plano de reenvío usa para búsquedas a velocidades mucho más altas. Antes o después de examinar el destino, se pueden consultar otras tablas para tomar decisiones sobre descartar el paquete en función de otras características, como la dirección de origen, el campo de identificador de protocolo IP o el número de puerto del Protocolo de control de transmisión (TCP) o del Protocolo de datagramas de usuario (UDP).
Las funciones del plano de reenvío se ejecutan en el elemento de reenvío. [1] Los enrutadores de alto rendimiento a menudo tienen múltiples elementos de reenvío distribuidos, de modo que el enrutador aumenta el rendimiento con el procesamiento paralelo.
La interfaz de salida encapsulará el paquete en el protocolo de enlace de datos apropiado. Según el software del enrutador y su configuración, las funciones, generalmente implementadas en la interfaz de salida, pueden configurar varios campos de paquetes, como el campo DSCP utilizado por los servicios diferenciados .
En general, el paso desde la interfaz de entrada directamente a una interfaz de salida, a través de la estructura con una modificación mínima en la interfaz de salida, se denomina ruta rápida del enrutador. Si el paquete necesita un procesamiento significativo, como segmentación o cifrado, puede pasar por una ruta más lenta, que a veces se denomina plano de servicios del enrutador. Los planos de servicios pueden tomar decisiones de reenvío o procesamiento en función de información de capas superiores, como una URL web contenida en la carga útil del paquete.
El plano de datos es la parte del software que procesa las solicitudes de datos. [2] Por el contrario, el plano de control es la parte del software que configura y apaga el plano de datos. [3]
La separación conceptual del plano de datos del plano de control se ha realizado durante años. [3] Un ejemplo temprano es Unix , donde las operaciones básicas de archivo son abrir, cerrar para el plano de control y leer, escribir para el plano de datos. [4]
La separación conceptual del plano de datos del plano de control en la programación de software ha demostrado ser útil en el campo de conmutación de paquetes , donde se originó. En redes , el plano de datos a veces se denomina plano de reenvío, ya que separa las preocupaciones: el plano de datos está optimizado para la velocidad de procesamiento y para la simplicidad y regularidad. El plano de control está optimizado para permitir la configuración , el manejo de políticas, el manejo de situaciones excepcionales y, en general, facilitar y simplificar el procesamiento del plano de datos. [5] [6]
Los proveedores diseñan productos de enrutadores para mercados específicos. El diseño de enrutadores destinados a uso doméstico, que tal vez admitan varias PC y telefonía VoIP, se basa en mantener el costo lo más bajo posible. En un enrutador de este tipo, no hay una estructura de reenvío independiente y solo hay una ruta de reenvío activa: hacia el procesador principal y hacia afuera del procesador principal.
Los enrutadores para aplicaciones más exigentes aceptan mayores costos y complejidad para obtener un mayor rendimiento en sus planos de reenvío.
Varios factores de diseño afectan el rendimiento del reenvío del enrutador:
Los enrutadores pueden tener uno o más procesadores. En un diseño monoprocesador, estos parámetros de rendimiento se ven afectados no solo por la velocidad del procesador, sino por la competencia por el procesador. Los enrutadores de mayor rendimiento invariablemente tienen múltiples elementos de procesamiento, que pueden ser chips de procesador de uso general o circuitos integrados específicos de la aplicación (ASIC) especializados.
Los productos de muy alto rendimiento tienen múltiples elementos de procesamiento en cada tarjeta de interfaz. En estos diseños, el procesador principal no participa en el reenvío, sino solo en el procesamiento del plano de control y de la gestión.
En el Grupo de trabajo de ingeniería de Internet , dos grupos de trabajo del área de operaciones y mantenimiento se ocupan de aspectos relacionados con el rendimiento. El grupo de medición del rendimiento entre proveedores (IPPM) se centra, como su nombre indica, en la medición operativa de los servicios. Las mediciones del rendimiento en enrutadores individuales, o en sistemas de enrutadores definidos de forma estricta, son competencia del Grupo de trabajo de evaluación comparativa (BMWG).
RFC 2544 es el documento clave de BMWG. [7] Un benchmark RFC 2544 clásico utiliza la mitad de los puertos del enrutador (es decir, el dispositivo bajo prueba (DUT)) para la entrada de una carga definida y mide el tiempo en el que aparecen las salidas en los puertos de salida.
Originalmente, todos los destinos se buscaban en la RIB. Tal vez el primer paso para acelerar los enrutadores fue tener una RIB y una FIB separadas en la memoria principal, con la FIB, generalmente con menos entradas que la RIB, organizada para una búsqueda rápida de destinos. En cambio, la RIB se optimizó para una actualización eficiente mediante protocolos de enrutamiento.
Los primeros enrutadores de un solo procesamiento solían organizar la FIB como una tabla hash , mientras que la RIB podía ser una lista enlazada . Según la implementación, la FIB podía tener menos entradas que la RIB, o la misma cantidad.
Cuando los enrutadores comenzaron a tener procesadores de reenvío independientes, estos procesadores generalmente tenían mucha menos memoria que el procesador principal, de modo que el procesador de reenvío solo podía contener las rutas más utilizadas. En los primeros Cisco AGS+ y 7000, por ejemplo, la caché del procesador de reenvío podía contener aproximadamente 1000 entradas de ruta. En una empresa, esto solía funcionar bastante bien, porque había menos de 1000 subredes de servidores u otros destinos populares. Sin embargo, una caché de este tipo era demasiado pequeña para el enrutamiento general de Internet. Los diferentes diseños de enrutadores se comportaban de diferentes maneras cuando un destino no estaba en la caché.
Una condición de error de caché puede provocar que el paquete se envíe de vuelta al procesador principal para buscarlo en una ruta lenta que tenía acceso a la tabla de enrutamiento completa. Según el diseño del enrutador, un error de caché puede provocar una actualización de la caché de hardware rápida o de la caché rápida en la memoria principal. En algunos diseños, era más eficiente invalidar la caché rápida para un error de caché, enviar el paquete que causó el error de caché a través del procesador principal y luego volver a llenar la caché con una nueva tabla que incluía el destino que causó el error. Este enfoque es similar a un sistema operativo con memoria virtual, que mantiene la información utilizada más recientemente en la memoria física.
A medida que los costos de memoria disminuyeron y las necesidades de rendimiento aumentaron, surgieron las FIB que tenían la misma cantidad de entradas de ruta que en la RIB, pero estaban organizadas para una búsqueda rápida en lugar de una actualización rápida. Siempre que cambiaba una entrada de la RIB, el enrutador cambiaba la entrada de la FIB correspondiente.
Los FIB de alto rendimiento logran su velocidad con combinaciones específicas de implementación de algoritmos y hardware especializados.
Se han utilizado varios algoritmos de búsqueda para la búsqueda de FIB. Si bien primero se utilizaron estructuras de datos de uso general conocidas, como las tablas hash , surgieron algoritmos especializados, optimizados para direcciones IP. Entre ellos se incluyen:
Una arquitectura de CPU multinúcleo se utiliza comúnmente para implementar sistemas de redes de alto rendimiento. Estas plataformas facilitan el uso de una arquitectura de software en la que el procesamiento de paquetes de alto rendimiento se realiza dentro de un entorno de ruta rápida en núcleos dedicados, con el fin de maximizar el rendimiento del sistema. Un modelo de ejecución hasta su finalización minimiza la sobrecarga y la latencia del sistema operativo. [9]
Se utilizaron varias formas de RAM rápida y, finalmente, memoria direccionable por contenido (CAM) básica para acelerar la búsqueda. CAM, si bien era útil en conmutadores de capa 2 que necesitaban buscar una cantidad relativamente pequeña de direcciones MAC de longitud fija , tenía una utilidad limitada con direcciones IP que tenían prefijos de enrutamiento de longitud variable (consulte Enrutamiento entre dominios sin clases ). La CAM ternaria (CAM), si bien es costosa, se presta a búsquedas de prefijos de longitud variable. [10]
Uno de los desafíos del diseño de búsqueda de reenvío es minimizar la cantidad de memoria especializada necesaria y, cada vez más, minimizar la energía consumida por la memoria. [11]
Un siguiente paso en la aceleración de los enrutadores fue tener un procesador de reenvío especializado separado del procesador principal. Todavía había una única ruta, pero el reenvío ya no tenía que competir con el control en un solo procesador. El procesador de enrutamiento rápido generalmente tenía una FIB pequeña, con memoria de hardware (por ejemplo, memoria estática de acceso aleatorio (SRAM)) más rápida y más cara que la FIB en la memoria principal. La memoria principal generalmente era una memoria dinámica de acceso aleatorio (DRAM).
Luego, los routers comenzaron a tener múltiples elementos de reenvío, que se comunicaban a través de un bus compartido de alta velocidad [12] o a través de una memoria compartida . [13] Cisco utilizó buses compartidos hasta que se saturaron, mientras que Juniper prefirió la memoria compartida. [14]
Cada elemento de reenvío tenía su propia FIB. Véase, por ejemplo, el procesador de interfaz versátil en el Cisco 7500 [15].
Con el tiempo, el recurso compartido se convirtió en un cuello de botella, ya que el límite de velocidad del bus compartido era de aproximadamente 2 millones de paquetes por segundo (Mpps). Las estructuras Crossbar superaron este cuello de botella.
A medida que aumentaba el ancho de banda de reenvío, incluso con la eliminación de la sobrecarga por errores de caché, las rutas compartidas limitaban el rendimiento. Si bien un enrutador podía tener 16 motores de reenvío, si había un solo bus, solo era posible transferir un paquete a la vez. Había algunos casos especiales en los que un motor de reenvío podía descubrir que la interfaz de salida era una de las interfaces lógicas o físicas presentes en la tarjeta de reenvío, de modo que el flujo de paquetes se encontraba totalmente dentro del reenvío. Sin embargo, a menudo era más fácil, incluso en este caso especial, enviar el paquete fuera del bus y recibirlo desde el bus.
Si bien algunos diseños experimentaron con múltiples buses compartidos, el enfoque final fue adaptar el modelo de conmutador de barra cruzada de los conmutadores telefónicos, en el que cada motor de reenvío tenía una ruta de hardware hacia todos los demás motores de reenvío. Con una pequeña cantidad de motores de reenvío, las estructuras de reenvío de barra cruzada son prácticas y eficientes para el enrutamiento de alto rendimiento. Existen diseños de múltiples etapas para sistemas de barra cruzada, como las redes Clos .