

En el enrutamiento , el plano de datos , también llamado plano de reenvío o plano de usuario , define la parte de la arquitectura del enrutador que determina qué hacer con los paquetes que llegan a una interfaz de entrada. Generalmente, 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(ces) de salida correspondiente(s).
En ciertos casos, la tabla puede especificar que un paquete debe descartarse. En tales casos, el enrutador puede devolver un mensaje ICMP de "destino inalcanzable" u otro código apropiado. Sin embargo, algunas políticas de seguridad dictan que el enrutador debe descartar el paquete silenciosamente, para que un posible atacante no se dé cuenta de que se está protegiendo un objetivo.
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 origen del paquete (es decir, el nodo indicado por la dirección de origen), el enrutador puede estar configurado 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 donde se busca la dirección de destino puede 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) independiente que es alimentada (es decir, cargada) por el plano de control de enrutamiento , pero utilizada por el plano de reenvío para búsquedas a velocidades mucho mayores. Antes o después de examinar el destino, se pueden consultar otras tablas para determinar cómo procesar los paquetes según otras características, como la dirección de origen, el campo del identificador del 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 suelen tener 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. Dependiendo del software del enrutador y su configuración, las funciones, generalmente implementadas en la interfaz de salida, pueden establecer varios campos del paquete, como el campo DSCP utilizado por los servicios diferenciados .
En general, el paso directo desde la interfaz de entrada a la interfaz de salida, a través de la red con mínimas modificaciones en la interfaz de salida, se denomina ruta rápida del enrutador. Si el paquete requiere un procesamiento significativo, como segmentación o cifrado, puede seguir una ruta más lenta, a la que a veces se denomina plano de servicios del enrutador. Los planos de servicios pueden tomar decisiones de reenvío o procesamiento basándose en información de capas superiores, como una URL web contenida en la carga útil del paquete.
Contraste con el plano de control
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 desactiva 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 archivos son abrir y 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, la simplicidad y la 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, para facilitar y simplificar el procesamiento del plano de datos. [ 5 ] [ 6 ]
Problemas en el rendimiento del reenvío del enrutador
Los fabricantes diseñan routers para mercados específicos. El diseño de routers para uso doméstico, que pueden admitir varios ordenadores y telefonía VoIP, se centra en mantener el coste lo más bajo posible. En este tipo de routers, no existe una arquitectura de reenvío independiente, y solo hay una ruta de reenvío activa: hacia el procesador principal y desde este.
Los enrutadores para aplicaciones más exigentes aceptan un mayor coste y complejidad para obtener un mayor rendimiento en sus planos de reenvío.
Varios factores de diseño afectan al rendimiento del reenvío del enrutador:
- Procesamiento de la capa de enlace de datos y extracción del paquete
- Decodificación del encabezado del paquete
- Consultar la dirección de destino en el encabezado del paquete.
- Analizando otros campos en el paquete
- Envío del paquete a través de la "estructura" que interconecta las interfaces de entrada y salida.
- Procesamiento y encapsulación del enlace de datos en la interfaz de salida
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 también por la competencia por el mismo. Los enrutadores de mayor rendimiento invariablemente cuentan con múltiples elementos de procesamiento, que pueden ser chips procesadores de propósito general o circuitos integrados de aplicación específica (ASIC) especializados.
Los productos de muy alto rendimiento cuentan con múltiples elementos de procesamiento en cada tarjeta de interfaz. En estos diseños, el procesador principal no participa en el reenvío de datos, sino únicamente en el plano de control y el procesamiento de gestión.
Rendimiento comparativo
En el Grupo de Trabajo de Ingeniería de Internet (IETF), dos grupos de trabajo en el Área de Operaciones y Mantenimiento se ocupan de aspectos del 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 de rendimiento en enrutadores individuales, o en sistemas de enrutadores definidos con precisión, son competencia del Grupo de Trabajo de Evaluación Comparativa (BMWG).
RFC 2544 es el documento clave de BMWG. [ 7 ] Una prueba de rendimiento clásica de RFC 2544 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.
Diseño de la base de información de reenvío
Originalmente, todos los destinos se consultaban en la tabla de enrutamiento (RIB). Quizás el primer paso para acelerar los enrutadores fue disponer de una RIB y una FIB separadas en la memoria principal. La FIB, que generalmente contenía menos entradas que la RIB, estaba organizada para una búsqueda rápida de destinos, mientras que la RIB se optimizó para una actualización eficiente mediante protocolos de enrutamiento.
Los primeros enrutadores de uniprocesamiento solían organizar la FIB como una tabla hash , mientras que la RIB podía ser una lista enlazada . Dependiendo de la implementación, la FIB podía tener menos entradas que la RIB, o la misma cantidad.
Cuando los routers comenzaron a tener procesadores de reenvío independientes, estos procesadores solían tener mucha menos memoria que el procesador principal, de modo que el procesador de reenvío solo podía almacenar las rutas más utilizadas. En los primeros Cisco AGS+ y 7000, por ejemplo, la caché del procesador de reenvío podía almacenar aproximadamente 1000 entradas de ruta. En una empresa, esto solía funcionar bastante bien, ya que había menos de 1000 subredes de servidores u otros destinos populares. Sin embargo, dicha caché era demasiado pequeña para el enrutamiento general de Internet. Los diferentes diseños de routers se comportaban de maneras distintas cuando un destino no estaba en la caché.
Problemas de fallos de caché
A cache miss condition might result in the packet being sent back to the main processor, to be looked up in a slow path that had access to the full routing table. Depending on the router design, a cache miss might cause an update to the fast hardware cache or the fast cache in main memory. In some designs, it was most efficient to invalidate the fast cache for a cache miss, send the packet that caused the cache miss through the main processor, and then repopulate the cache with a new table that included the destination that caused the miss. This approach is similar to an operating system with virtual memory, which keeps the most recently used information in physical memory.
As memory costs went down and performance needs went up, FIBs emerged that had the same number of route entries as in the RIB, but arranged for fast lookup rather than fast update. Whenever a RIB entry changed, the router changed the corresponding FIB entry.
FIB design alternatives
High-performance FIBs achieve their speed with implementation-specific combinations of specialized algorithms and hardware.
Software
Various search algorithms have been used for FIB lookup. While well-known general-purpose data structures were first used, such as hash tables, specialized algorithms, optimized for IP addresses, emerged. They include:
- Binary tree
- Radix tree
- Four-way trie
- Patricia tree[8]
A multicore CPU architecture is commonly used to implement high-performance networking systems. These platforms facilitate the use of a software architecture in which the high-performance packet processing is performed within a fast path environment on dedicated cores, in order to maximize system throughput. A run-to-completion model minimizes OS overhead and latency.[9]
Hardware
Various forms of fast RAM and, eventually, basic content-addressable memory (CAM) were used to speed lookup. CAM, while useful in layer 2 switches that needed to look up a relatively small number of fixed-length MAC addresses, had limited utility with IP addresses having variable-length routing prefixes (see Classless Inter-Domain Routing). Ternary CAM (CAM), while expensive, lends itself to variable-length prefix lookups.[10]
One of the challenges of forwarder lookup design is to minimize the amount of specialized memory needed, and, increasingly, to minimize the power consumed by memory.[11]
Distributed forwarding
Un paso más en la aceleración de los enrutadores fue la incorporación de un procesador de reenvío especializado, separado del procesador principal. Si bien seguía existiendo una única ruta, el reenvío ya no tenía que competir con el control en un solo procesador. El procesador de enrutamiento rápido generalmente contaba con una FIB pequeña, con memoria de hardware (por ejemplo, memoria de acceso aleatorio estática (SRAM)) más rápida y costosa que la FIB en la memoria principal. La memoria principal solía ser memoria de acceso aleatorio dinámica (DRAM).
Reenvío distribuido temprano
A continuación, 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 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 propio FIB. Véase, por ejemplo, el procesador de interfaz versátil en el Cisco 7500 [ 15 ].
Finalmente, el recurso compartido se convirtió en un cuello de botella, con un límite de velocidad del bus compartido de aproximadamente 2 millones de paquetes por segundo (Mpps). Las redes de interconexión de barras cruzadas superaron este cuello de botella.
Los caminos compartidos se convierten en cuellos de botella.
A medida que aumentaba el ancho de banda de reenvío, incluso eliminando la sobrecarga por fallos de caché, las rutas compartidas limitaban el rendimiento. Si bien un enrutador podía tener 16 motores de reenvío, si solo había un bus, solo era posible la transferencia de un paquete a la vez. Existían algunos casos especiales en los que un motor de reenvío podí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 se encontraba completamente dentro de la tarjeta. Sin embargo, incluso en este caso especial, solía ser más sencillo enviar el paquete fuera del bus y recibirlo desde el mismo.
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 un número reducido de motores de reenvío, las redes de reenvío de barra cruzada son prácticas y eficientes para el enrutamiento de alto rendimiento. Existen diseños multietapa para sistemas de barra cruzada, como las redes Clos .
Véase también
Referencias
- ↑ Marco de separación de elementos de reenvío y control (ForCES) , RFC 3746, Grupo de trabajo de redes, abril de 2004
- ↑ Conran, Matt (25 de febrero de 2019). "Redes de datos con nombre: plano de reenvío con estado para la entrega de datagramas" . Network World . Recuperado el 15 de octubre de 2019 .
- 1 2 Do, Truong-Xuan; Kim, Younghan (2017-06-01). "Arquitectura de separación del plano de control y de datos para soportar oyentes de multidifusión sobre gestión de movilidad distribuida" . ICT Express . 3 (2): 90– 95. doi : 10.1016/j.icte.2017.06.001 . ISSN 2405-9595 .
- ↑ Bach, Maurice J. (1986). El diseño del sistema operativo Unix . Prentice-Hall. Bibcode : 1986duos.book.....B . ISBN 9780132017992.
- ↑ Ahmad, Ijaz; Namal, Suneth; Ylianttila, Mika; Gurtoz, Andrei (2015). "Seguridad en redes definidas por software: una revisión" (PDF) . IEEE Communications Surveys & Tutorials . 17 (4): 2317– 2342. doi : 10.1109/COMST.2015.2474118 . S2CID 2138863 .
- ↑ Xia, W.; Wen, Y.; Foh, CH; Niyato, D.; Xie, H. (2015). "Una revisión sobre redes definidas por software" . IEEE Communications Surveys & Tutorials . 17 (1): 27– 51. doi : 10.1109/COMST.2014.2330903 .
- ↑ Metodología para dispositivos de interconexión de red , RFC 2544, S. Bradner y J. McQuade, marzo de 1999
- ↑ Enrutamiento basado en prefijos coincidentes más largos , ID, W. Doeringer y otros, IEEE/ACM Transactions on Networking, febrero de 1996
- ↑ "Módulos de software 6WINDGate" . 6WIND . Consultado el 14 de agosto de 2015 .
- ↑ Mapeo eficiente de clasificador de rango en CAM ternario , Simposio IEEE sobre interconexiones de alta velocidad, H. Liu, agosto de 2002
- ↑ Reducción del consumo de energía de la TCAM y aumento del rendimiento , Simposio IEEE sobre interconexiones de alta velocidad, R. Panigrahy y S. Sharma, agosto de 2002
- ↑ Reenvío IP de alto rendimiento mediante interconexión de interfaces de host , J. Touch et al. , Actas del 9.º Taller IEEE sobre Redes de Área Local y Metropolitana (LANMAN), mayo de 1998
- ↑ Arquitecturas de multiprocesadores de memoria compartida para enrutadores IP de software , Y. Luo et al. , IEEE Transactions on Parallel and Distributed Systems, 2003
- ↑ Arquitectura de enrutadores de Juniper Networks , Guía de referencia de Juniper Networks: Enrutamiento, configuración y arquitectura de JUNOS , T. Thomas, Addison-Wesley Professional, 2003
- ↑ Arquitectura de hardware del router Cisco 7500 , Arquitectura de software de Cisco IOS (CCIE Professional Development , V. Bollapragada et al. , Cisco Press, 2000)
- Arquitectura de Internet
- Enrutadores (informática)