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 entrante. Más comúnmente, 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 del tejido de reenvío interno del enrutador y hasta la interfaz de salida adecuada. (s).
En ciertos casos, la tabla puede especificar que se debe descartar un paquete. En tales casos, el enrutador puede devolver un "destino inalcanzable" ICMP u otro código apropiado. Sin embargo, algunas políticas de seguridad dictan que el enrutador debe descartar el paquete en silencio, para que un atacante potencial no se dé cuenta de que un objetivo está siendo protegido.
El elemento de reenvío entrante también disminuirá 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, al nodo indicado por la dirección de origen), el enrutador puede configurarse para descartar el paquete. silenciosamente (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 completa (es decir, se carga ) por el plano de control de enrutamiento , pero utilizado por el plano de reenvío 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 de descartar el paquete en función de otras características, como la dirección de origen, el campo identificador del protocolo IP o el Protocolo de control de transmisión (TCP) o el Protocolo de datagramas de usuario (UDP). número de puerto.
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 distribuido, de modo que el enrutador aumenta el rendimiento con el procesamiento paralelo.
La interfaz saliente encapsulará el paquete en el protocolo de enlace de datos apropiado. Dependiendo del 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 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 mínima modificación 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 tomar una ruta más lenta, que a veces se denomina plano de servicios del enrutador. Los aviones de servicio pueden tomar decisiones de reenvío o procesamiento basándose en información de capa superior, 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 lleva realizando desde hace años. [3] Un ejemplo temprano es Unix , donde las operaciones básicas de archivos son abrir, cerrar para el plano de control y leer y 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 la 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 quizás 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 existe una estructura de reenvío separada y solo hay una ruta de reenvío activa: hacia el procesador principal y fuera 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 sólo por la velocidad del procesador, sino también por la competencia por el procesador. Los enrutadores de mayor rendimiento siempre tienen múltiples elementos de procesamiento, que pueden ser chips de procesador de uso general o circuitos integrados de aplicaciones específicas (ASIC) especializados.
Los productos de muy alto rendimiento tienen múltiples elementos de procesamiento en cada tarjeta de interfaz. En tales diseños, el procesador principal no participa en el reenvío, sino sólo en el plano de control y el procesamiento de gestión.
En el Internet Engineering Task Force , dos grupos de trabajo en el Área de Operaciones y Mantenimiento se ocupan de aspectos de desempeño. El grupo Interprovider Performance Measurement (IPPM) se centra, como su nombre indica, en la medición operativa de servicios. Las mediciones de rendimiento en enrutadores individuales, o sistemas de enrutadores estrictamente definidos, son competencia del Grupo de Trabajo de Evaluación Comparativa (BMWG).
RFC 2544 es el documento clave de BMWG. [7] Un punto de referencia 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 las salidas aparecen en los puertos de salida.
Originalmente, todos los destinos se buscaban en el RIB. Quizás el primer paso para acelerar los enrutadores fue tener un RIB y un FIB separados en la memoria principal, con el FIB, generalmente con menos entradas que el RIB, organizado para una búsqueda rápida de destinos. Por el contrario, el RIB se optimizó para una actualización eficiente mediante protocolos de enrutamiento.
Los primeros enrutadores sin procesamiento generalmente organizaban la FIB como una tabla hash , mientras que la RIB podía ser una lista enlazada . Dependiendo de la implementación, la FIB puede tener menos entradas que la RIB o el mismo número.
Cuando los enrutadores comenzaron a tener procesadores de reenvío separados, estos procesadores generalmente tenían mucha menos memoria que el procesador principal, de modo que el procesador de reenvío sólo podía contener las rutas utilizadas con más frecuencia. 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 a menudo funcionaría bastante bien, porque había menos de 1000 servidores u otras subredes de destino populares. Sin embargo, dicha caché era demasiado pequeña para el enrutamiento general de Internet. Los diferentes diseños de enrutadores se comportaron de diferentes maneras cuando un destino no estaba en la memoria caché.
Una condición de pérdida de caché podría provocar que el paquete se envíe de vuelta al procesador principal para buscarlo en una ruta lenta que tenga acceso a la tabla de enrutamiento completa. Dependiendo del diseño del enrutador, una pérdida de caché puede causar una actualización del caché rápido de hardware o del caché rápido en la memoria principal. En algunos diseños, era más eficiente invalidar el caché rápido por un error de caché, enviar el paquete que causó el error de caché a través del procesador principal y luego volver a llenar el caché con una nueva tabla que incluyera 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 FIB que tenían la misma cantidad de entradas de ruta que en el RIB, pero que permitían una búsqueda rápida en lugar de una actualización rápida. Cada vez que cambiaba una entrada RIB, el enrutador cambiaba la entrada FIB correspondiente.
Los FIB de alto rendimiento alcanzan 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 se utilizaron por primera vez estructuras de datos de propósito general bien conocidas, como las tablas hash , surgieron algoritmos especializados optimizados para direcciones IP. 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, para 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 básica direccionable por contenido (CAM) 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 ). CAM ternario (CAM), si bien es costoso, se presta para búsquedas de prefijos de longitud variable. [10]
Uno de los desafíos del diseño de búsqueda de reenviadores es minimizar la cantidad de memoria especializada necesaria y, cada vez más, minimizar la energía consumida por la memoria. [11]
El siguiente paso para acelerar los enrutadores fue tener un procesador de reenvío especializado separado del procesador principal. Todavía había un camino único, pero el reenvío ya no tenía que competir con el control en un solo procesador. El procesador de enrutamiento rápido normalmente 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 era generalmente una memoria dinámica de acceso aleatorio (DRAM).
Luego, los enrutadores comenzaron a tener múltiples elementos de reenvío, que se comunicaban a través de un bus compartido de alta velocidad [12] o mediante 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. Consulte, por ejemplo, el procesador de interfaz versátil en Cisco 7500 [15]
Con el tiempo, el recurso compartido se convirtió en un cuello de botella, con el límite de velocidad del bus compartido de aproximadamente 2 millones de paquetes por segundo (Mpps). Los tejidos con travesaños superaron este cuello de botella.
A medida que aumentó el ancho de banda de reenvío, incluso con la eliminación de la sobrecarga de pérdida de caché, las rutas compartidas limitaron el rendimiento. Si bien un enrutador puede tener 16 motores de reenvío, si había un solo bus, solo era posible la transferencia de un paquete a la vez. Hubo algunos casos especiales en los que un motor de reenvío podría encontrar 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 estaba totalmente dentro del reenviador. Sin embargo, a menudo era más fácil, incluso en este caso especial, enviar el paquete fuera del autobús y recibirlo desde el autobús.
Si bien algunos diseños experimentaron con múltiples buses compartidos, el enfoque final fue adaptar el modelo de conmutador de barra transversal de los conmutadores telefónicos, en los que cada motor de reenvío tenía una ruta de hardware a todos los demás motores de reenvío. Con una pequeña cantidad de motores de reenvío, las telas de reenvío con barras transversales son prácticas y eficientes para enrutamiento de alto rendimiento. Existen diseños multietapa para sistemas de travesaños, como las redes Clos .