Hispanopedia WikiLa compresión robusta de encabezados ( ROHC ) es un método estandarizado para comprimir los encabezados IP , UDP , UDP-Lite , RTP y TCP de los paquetes de Internet .
La necesidad de compresión de encabezado
En aplicaciones de transmisión, la sobrecarga de IP, UDP y RTP es de 40 bytes para IPv4 o de 60 bytes para IPv6 . Para VoIP , esto corresponde a aproximadamente el 60 % de la cantidad total de datos enviados. Estas grandes sobrecargas pueden ser tolerables en enlaces cableados locales donde la capacidad no suele ser un problema, pero son excesivas para redes de área amplia y sistemas inalámbricos donde el ancho de banda es escaso. [ 1 ]
ROHC comprime estos 40 o 60 bytes de sobrecarga, generalmente en solo uno o tres bytes, colocando un compresor antes del enlace de capacidad limitada y un descompresor después de dicho enlace. El compresor convierte la gran sobrecarga en solo unos pocos bytes, mientras que el descompresor hace lo contrario.
El esquema de compresión ROHC se diferencia de otros esquemas de compresión, como IETF RFC 1144 y RFC 2508 , en que ofrece un buen rendimiento en enlaces con una alta tasa de pérdida de paquetes, como los enlaces inalámbricos.
Principios básicos de compresión ROHC
El protocolo ROHC aprovecha la redundancia de información en las cabeceras de los siguientes elementos:
- un único paquete de red (por ejemplo, la longitud de la carga útil en los encabezados IP y UDP)
- varios paquetes de red que pertenecen a una misma secuencia (por ejemplo, las direcciones IP)
La información redundante se transmite únicamente en los primeros paquetes. Los paquetes siguientes contienen información variable, como identificadores o números de secuencia. Estos campos se transmiten comprimidos para ahorrar bits.
Para un mejor rendimiento, los paquetes se clasifican en flujos antes de comprimirse. Esta clasificación aprovecha la redundancia entre paquetes. El algoritmo de clasificación no está definido por el protocolo ROHC, sino que depende de la implementación del fabricante del equipo. Una vez clasificado un flujo de paquetes, se comprime según el perfil de compresión más adecuado. Un perfil de compresión define la forma de comprimir los diferentes campos de las cabeceras de red. Existen varios perfiles de compresión disponibles, entre ellos:
- Sin comprimir
- Solo IP
- UDP/IP
- UDP-Lite/IP
- ESP/IP
- RTP/UDP/IP
- RTP/UDP-Lite/IP
- TCP/IP
Modos de funcionamiento
Según el RFC 3095, el esquema ROHC tiene tres modos de funcionamiento, como se indica a continuación:
- el modo unidireccional (modo U)
- el modo optimista bidireccional (modo O)
- el modo bidireccional fiable (modo R)
Tanto el compresor como el descompresor se inician en modo U. Posteriormente, pueden pasar al modo O si disponen de un enlace de retorno utilizable y el descompresor envía una confirmación positiva, especificando el modo O, al compresor. La transición al modo R se realiza de la misma manera.
Modo unidireccional (modo U)
En el modo de operación unidireccional, los paquetes se envían en una sola dirección: del compresor al descompresor. Por lo tanto, este modo permite utilizar ROHC en enlaces donde no es posible o deseable una ruta de retorno del descompresor al compresor. Para gestionar posibles errores de descompresión, el compresor envía actualizaciones periódicas del contexto del flujo al descompresor.
Modo optimista bidireccional (Modo O)
El modo optimista bidireccional es similar al modo unidireccional, con la diferencia de que utiliza un canal de retroalimentación para enviar solicitudes de recuperación de errores y (opcionalmente) confirmaciones de actualizaciones de contexto importantes del descompresor al compresor. El modo O busca maximizar la eficiencia de la compresión y minimizar el uso del canal de retroalimentación.
Modo fiable bidireccional (modo R)
El modo Bidireccional Confiable difiere en muchos aspectos de los dos modos anteriores. Las diferencias más importantes radican en un uso más intensivo del canal de retroalimentación y una lógica más estricta tanto en el compresor como en el descompresor, que evita la pérdida de sincronización de contexto entre ambos, salvo en casos de tasas de error de bits residuales muy elevadas.
Estados del compresor/descompresor
El concepto de estados del compresor/descompresor es independiente de los modos de operación. Independientemente del modo, tanto el compresor como el descompresor funcionan en uno de sus tres estados. Básicamente, son máquinas de estados finitos. Cada paquete entrante puede provocar un cambio en el estado interno del compresor/descompresor. Cada estado se refiere a un comportamiento y un nivel de compresión definidos.
El algoritmo ROHC es similar a la compresión de vídeo, ya que se envía un fotograma base y varios fotogramas de diferencia para representar un flujo de paquetes IP. Esto tiene la ventaja de permitir que ROHC soporte numerosas pérdidas de paquetes en su estado de máxima compresión, siempre que no se pierdan los fotogramas base.
Estados del compresor
La máquina de estados del compresor define los siguientes tres estados:
- Estado de inicialización y actualización (IR)
- Estado de primer orden (FO)
- Estado de segundo orden (SO)
Operaciones en los diferentes estados del compresor
En el estado de Inicialización y Actualización (IR), el compresor se acaba de crear o reiniciar, y se envían las cabeceras completas de los paquetes. En el estado de Primer Orden (FO), el compresor ha detectado y almacenado los campos estáticos (como direcciones IP y números de puerto) en ambos extremos de la conexión. El compresor también envía las diferencias de los campos dinámicos de los paquetes en el estado FO. Por lo tanto, el estado FO es esencialmente una compresión estática y pseudodinámica. En el estado de Segundo Orden (SO), el compresor suprime todos los campos dinámicos, como los números de secuencia RTP, y envía solo un número de secuencia lógico y una suma de verificación parcial para que el otro extremo genere y verifique de forma predictiva las cabeceras del siguiente paquete esperado. En general, el estado FO comprime todos los campos estáticos y la mayoría de los campos dinámicos. El estado SO comprime todos los campos dinámicos de forma predictiva utilizando un número de secuencia y una suma de verificación.
Transiciones entre estados del compresor
Las transiciones entre los estados anteriores ocurren cuando el compresor:
- Comprime un paquete que contiene demasiadas variaciones
- recibe una retroalimentación positiva/negativa del descompresor
- actualiza periódicamente el contexto
Encabezados ROHC de segundo orden: encabezados de 1 byte
Una implementación típica de ROHC tendrá como objetivo llevar el terminal al estado de segundo orden, donde un encabezado ROHC de 1 byte puede sustituir al encabezado IPv4/UDP/RTP de 40 bytes o al encabezado IPv6/UDP/RTP de 60 bytes (es decir, VoIP). En este estado, el encabezado ROHC de 8 bits contiene tres campos:
- un indicador de tipo de paquete de 1 bit (establecido en '1' solo para encabezados ROHC más largos)
- un número de secuencia de 4 bits (con un rango de −1 ... +14 paquetes desde la trama base)
- un CRC de 3 bits
Estados del descompresor
La máquina de estados del descompresor define los siguientes tres estados:
- Estado sin contexto
- Estado de contexto estático
- Estado de contexto completo
Las transiciones entre los estados anteriores ocurren cuando el descompresor:
- descomprime correctamente un paquete
- No logra descomprimir varios paquetes.
Robustez
El tamaño del campo de número de secuencia (SN) determina la cantidad de paquetes que ROHC puede perder antes de que el compresor deba reiniciarse para continuar. El algoritmo W-LSB se utiliza para comprimir el SN de forma robusta. El tamaño del número de secuencia en los paquetes ROHC de 1 y 2 bytes es de 4 bits (desplazamiento de trama de -1/+14) o de 6 bits (desplazamiento de trama de -1/+62), respectivamente, por lo que ROHC puede tolerar como máximo 62 tramas perdidas con una cabecera de 1-2 bytes.
Perfiles de compresión adicionales
El RFC 3095 define un mecanismo de compresión genérico. Este puede ampliarse definiendo nuevos perfiles de compresión dedicados a encabezados de protocolo específicos. Se publicaron nuevos RFC para comprimir nuevos protocolos:
- El RFC 3843 define un perfil de compresión para encabezados IP o túneles IP.
- El RFC 4019 define un perfil de compresión para las cabeceras UDP-Lite/IP y RTP/UDP-Lite/IP.
- El RFC 6846 define un perfil de compresión para las cabeceras TCP/IP.
Nuevas RFC de ROHC
Se han publicado dos nuevos RFC, el RFC 4995 y el RFC 5225, para abordar la confusión que algunos han encontrado al intentar interpretar e implementar ROHC. El primer documento define un marco de trabajo ROHC, mientras que el segundo define versiones más recientes de los perfiles ROHC ya establecidos.
Véase también
Referencias
- ↑ Michael Dosch y Steve Church. "VoIP en el estudio de radiodifusión" . Axia Audio. Archivado del original el 7 de octubre de 2011. Consultado el 21 de junio de 2011 .
Enlaces externos
- Estatuto oficial del grupo de trabajo ROHC IETF
- RFC 3095 - "Marco ROHC y cuatro perfiles: RTP, UDP, ESP y sin comprimir"
- RFC 3759 - "Terminología ROHC y ejemplos de asignación de canales"
- RFC 4815 - "Correcciones y aclaraciones al RFC 3095 "
- RFC 4995 - "El marco de compresión de encabezados robusto (ROHC)" (obsoleto por RFC 5795)
- RFC 4996 - "Compresión de encabezados robusta (ROHC): un perfil para TCP/IP (ROHC-TCP)" (obsoleto por RFC 6846)
- RFC 4997 - "Notación formal para ROHC"
- RFC 5225 - "Compresión de encabezados robusta versión 2 (ROHCv2): Perfiles para RTP, UDP, IP, ESP y UDP-Lite". Segunda versión de los perfiles descritos en RFC 3095, RFC 3843 y RFC 4019. Si bien reemplaza su definición, no los deja obsoletos.
- RFC 5795 - "El marco de compresión de encabezados robusto (ROHC)" (sustituye a RFC 4995)
- RFC 6846 - "Compresión de encabezados robusta (ROHC): un perfil para TCP/IP (ROHC-TCP)" (sustituye a RFC 4996)
- Una implementación gratuita de ROHC en sourceforge.net
- Una biblioteca gratuita y eficiente que implementa el estándar ROHC.
- Compresión de datos
- Estándares de Internet
