En comunicaciones , la vigilancia del tráfico es el proceso de monitorear el tráfico de la red para verificar el cumplimiento de 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 producción permanezca dentro del contrato y, por lo tanto, no se descarte. El tráfico que exceda 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 destinatario del tráfico que ha sido vigilado observará la 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 velocidad de envío (por ejemplo, a través de un mecanismo de retroalimentación), esto continuará y al destinatario le puede parecer como si errores de enlace o alguna otra interrupción estuviera causando la pérdida aleatoria de paquetes. El tráfico recibido, que ha experimentado vigilancia en ruta, normalmente cumplirá con el contrato, aunque elementos en la red aguas abajo de la policía pueden introducir fluctuaciones .
Con protocolos confiables, como TCP en lugar de UDP , el receptor no reconocerá los paquetes descartados y, por lo tanto, el emisor los reenviará, generando así más tráfico.
Las fuentes con mecanismos de control de congestión basados en retroalimentación (por ejemplo TCP ) generalmente se adaptan rápidamente a la vigilancia estática, convergiendo a una tasa justo por debajo de la tasa sostenida vigilada. [ cita necesaria ]
Los mecanismos de vigilancia cooperativa, como el descarte basado en paquetes [1], facilitan una convergencia más rápida, una mayor estabilidad y un intercambio de recursos más eficiente. Como resultado, puede resultar difícil para los puntos finales distinguir el tráfico TCP que simplemente ha sido vigilado del tráfico TCP que ha sido moldeado .
Cuando se impone la caída a nivel de celda (a diferencia de lo que se logra mediante la vigilancia basada en paquetes), el impacto es particularmente severo en los paquetes más largos. Dado que las celdas suelen ser mucho más cortas que el tamaño máximo de paquete, las políticas 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 conocidos de reensamblaje de paquetes responderán a una celda faltante descartando el paquete por completo y, en consecuencia, puede producirse una gran cantidad de pérdidas de paquetes si se excede moderadamente el contrato controlado.
RFC 2475 describe elementos de vigilancia del tráfico como un medidor y un cuentagotas . [2] Opcionalmente también podrán incluir un marcador . El medidor mide el tráfico y determina si excede o no el contrato (por ejemplo por GCRA ). Cuando excede el contrato, alguna política determina si se elimina alguna PDU determinada , o si se implementa el marcado, si se debe marcar y cómo. El marcado puede comprender establecer un indicador de congestión (tal como un indicador ECN de TCP o un bit CLP de ATM ) o establecer una indicación de agregado de tráfico (tal como un 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 comprometido (CBS) y Tamaño de ráfaga excesivo (EBS). Un paquete es "verde" si no supera el CBS, "amarillo" si supera el CBS, pero no el EBS, y "rojo" en caso contrario.
El "marcador de tres colores de tasa única" descrito por RFC 2697 permite ráfagas temporales. Las ráfagas están permitidas cuando la línea estaba infrautilizada antes de su aparición. En RFC 2698 se describe un algoritmo más predecible, que propone un "marcador de tres colores de doble velocidad". [4] RFC 2698 define un nuevo parámetro, la Tasa de Información Máxima (PIR). RFC 2859 describe el "Marcador de tres colores de ventana deslizante de tiempo" que mide un flujo de tráfico y marca paquetes según el rendimiento medido en relación con dos velocidades específicas: tasa objetivo comprometida (CTR) y tasa objetivo máxima (PTR). [5]
En los equipos de Cisco, tanto la vigilancia como la configuración del tráfico se implementan a través del algoritmo de depósito de tokens . [6]
La vigilancia del tráfico en las redes de cajeros automáticos se conoce como control de parámetros de uso/red . [7] La red también puede descartar el tráfico no conforme en la red (mediante el control de prioridad). La referencia tanto para la vigilancia del tráfico como para la configuración del tráfico en ATM (proporcionada por el Foro ATM y el ITU-T ) es el Algoritmo de velocidad de celda genérica ( GCRA ), que se describe como una versión del algoritmo del cubo con fugas . [8] [9]
Sin embargo, la comparación de los algoritmos del depósito con fugas y del depósito de tokens muestra que son simplemente imágenes reflejadas entre sí: uno agrega contenido al depósito donde el otro lo quita y quita contenido al 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 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 buffer de paquetes. En consecuencia, su implementación es significativamente menos compleja que la configuración del tráfico .
Las redes orientadas a la conexión (por ejemplo, los sistemas ATM) pueden realizar el Control de Admisión de Conexión (CAC) basándose en contratos de tráfico. En el contexto de 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 (mediante 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, la aplicación puede 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 vigilancia de tránsito es que CAC es una verificación a priori (antes de que ocurra la transferencia), mientras que la vigilancia de tránsito es una verificación a posteriori (durante la transferencia).