En comunicaciones , la vigilancia del tráfico es el proceso de supervisar el tráfico de la red para comprobar que cumple con un contrato de tráfico y tomar medidas para hacer cumplir ese contrato. Las fuentes de tráfico que conocen un contrato de tráfico pueden aplicar modelado de tráfico para garantizar que su salida se mantenga dentro del contrato y, por lo tanto, no se descarte. El tráfico que excede un contrato de tráfico puede descartarse inmediatamente, marcarse como no conforme o dejarse como está, según la política administrativa y las características del exceso de tráfico.
El receptor del tráfico que ha sido controlado observará una pérdida de paquetes distribuida a lo largo de los períodos en los que el tráfico entrante excedió el contrato. Si la fuente no limita su tasa de envío (por ejemplo, a través de un mecanismo de retroalimentación), esto continuará y puede parecerle al receptor como si errores de enlace o alguna otra interrupción estuvieran causando una pérdida aleatoria de paquetes. El tráfico recibido, que ha sido controlado en ruta, normalmente cumplirá con el contrato, aunque los elementos de la red que se encuentran aguas abajo del controlador pueden introducir fluctuaciones .
Con protocolos confiables, como TCP en lugar de UDP , los paquetes descartados no serán reconocidos por el receptor y, por lo tanto, serán reenviados por el emisor, generando así más tráfico.
Las fuentes con mecanismos de control de congestión basados en retroalimentación (por ejemplo TCP ) normalmente se adaptan rápidamente al control estático, convergiendo a una tasa justo por debajo de la tasa sostenida controlada. [ cita requerida ]
Los mecanismos de control cooperativo, como el descarte basado en paquetes [1], facilitan una convergencia más rápida, una mayor estabilidad y un uso compartido de recursos más eficiente. Como resultado, puede resultar difícil para los puntos finales distinguir el tráfico TCP que simplemente ha sido controlado del tráfico TCP que ha sido moldeado .
Cuando se aplica la eliminación a nivel de celda (en contraposición a lo que se logra mediante la vigilancia basada en paquetes), el impacto es particularmente grave en los paquetes más largos. Dado que las celdas suelen ser mucho más cortas que el tamaño máximo de paquete, los controladores convencionales descartan las celdas que no respetan los límites de los paquetes y, por lo tanto, la cantidad total de tráfico descartado normalmente se distribuirá entre varios paquetes. Casi todos los mecanismos de reensamblaje de paquetes conocidos responderán a una celda faltante descartando el paquete por completo y, en consecuencia, puede resultar una gran cantidad de pérdidas de paquetes si se excede moderadamente el contrato controlado.
RFC 2475 describe elementos de control de tráfico como un medidor y un cuentagotas . [2] También pueden incluir opcionalmente un marcador . El medidor mide el tráfico y determina si excede o no el contrato (por ejemplo, mediante GCRA ). Cuando excede el contrato, alguna política determina si se descarta una PDU determinada o, si se implementa el marcado, si se debe marcar y cómo. El marcado puede comprender la configuración de un indicador de congestión (como el indicador ECN de TCP o el bit CLP de ATM ) o la configuración de una indicación de agregación de tráfico (como el Punto de código de servicios diferenciados de IP ).
En implementaciones simples, el tráfico se clasifica en dos categorías o "colores": conforme (verde) y en exceso (rojo). RFC 2697 propone una clasificación más precisa, con tres "colores". [3] En este documento, el contrato se describe a través de tres parámetros: Tasa de información comprometida (CIR), Tamaño de ráfaga comprometida (CBS) y Tamaño de ráfaga en exceso (EBS). Un paquete es "verde" si no excede la CBS, "amarillo" si excede la CBS, pero no la EBS, y "rojo" en caso contrario.
El "marcador de tres colores de velocidad única" descrito en el RFC 2697 permite ráfagas temporales. Las ráfagas se permiten cuando la línea estaba infrautilizada antes de que aparecieran. En el RFC 2698 se describe un algoritmo más predecible, que propone un "marcador de tres colores de velocidad doble". [4] El RFC 2698 define un nuevo parámetro, la tasa de información máxima (PIR). El RFC 2859 describe el "marcador de tres colores de ventana deslizante temporal" que mide un flujo de tráfico y marca los paquetes en función del rendimiento medido en relación con dos tasas especificadas: tasa objetivo comprometida (CTR) y tasa objetivo máxima (PTR). [5]
En los equipos Cisco, tanto el control como el modelado del tráfico se implementan a través del algoritmo Token Bucket . [6]
El control del tráfico en las redes ATM se conoce como control de uso/parámetros de red . [7] La red también puede descartar el tráfico no conforme en la red (utilizando el control de prioridad). La referencia tanto para el control del tráfico como para la modelación del tráfico en ATM (proporcionada por el Foro ATM y la UIT-T ) es el algoritmo genérico de velocidad de celdas ( GCRA ), que se describe como una versión del algoritmo de cubo con fugas . [8] [9]
Sin embargo, la comparación de los algoritmos de depósito con fugas y depósito de tokens muestra que son simplemente imágenes especulares entre sí: uno agrega contenido del depósito donde el otro lo quita y quita contenido del depósito donde el otro lo agrega. Por lo tanto, dados parámetros equivalentes, las implementaciones de ambos algoritmos verán exactamente el mismo tráfico como conforme y no conforme.
La vigilancia del tráfico requiere el mantenimiento de estadísticas numéricas y medidas para cada flujo de tráfico vigilado, pero no requiere la implementación o gestión de volúmenes significativos de búfer de paquetes. En consecuencia, es significativamente menos compleja de implementar que la modelación del tráfico .
Las redes orientadas a la conexión (por ejemplo, los sistemas ATM) pueden realizar un control de admisión de conexión (CAC) basado en contratos de tráfico. En el contexto de la voz sobre IP (VoIP), esto también se conoce como control de admisión de llamadas (CAC). [10]
Una aplicación que desee utilizar una red orientada a conexión para transportar tráfico debe primero solicitar una conexión (a través de señalización, por ejemplo Q.2931 ), lo que implica informar a la red sobre las características del tráfico y la calidad de servicio (QoS) requerida por la aplicación. [11] Esta información se compara con un contrato de tráfico. Si se acepta la solicitud de conexión, se permite a la aplicación utilizar la red para transportar tráfico.
Esta función protege los recursos de la red de conexiones maliciosas y exige el cumplimiento de cada conexión con su contrato de tráfico negociado.
La diferencia entre CAC y control de tráfico es que CAC es una verificación a priori (antes de que se produzca la transferencia), mientras que control de tráfico es una verificación a posteriori (durante la transferencia).