La compresión robusta de encabezados ( ROHC ) es un método estandarizado para comprimir los encabezados IP , UDP , UDP-Lite , RTP y TCP de paquetes de Internet .
La necesidad de compresión de encabezados
En las aplicaciones de transmisión, la sobrecarga de IP, UDP y RTP es de 40 bytes para IPv4 o 60 bytes para IPv6 . Para VoIP , esto corresponde a alrededor del 60% de la cantidad total de datos enviados. Estos grandes gastos generales pueden ser tolerables en enlaces por cable locales donde la capacidad a menudo no es un problema, pero son excesivos para redes de área amplia y sistemas inalámbricos donde el ancho de banda es escaso. [1]
ROHC comprime estos 40 bytes o 60 bytes de sobrecarga típicamente en solo uno o tres bytes, colocando un compresor antes del enlace que tiene capacidad limitada y un descompresor después de ese 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, por el hecho de que funciona bien en enlaces donde la tasa de pérdida de paquetes es alta, como los enlaces inalámbricos.
Principios principales de compresión ROHC
El protocolo ROHC aprovecha la redundancia de información en los encabezados de lo siguiente:
- un solo paquete de red (por ejemplo, las longitudes de carga útil en los encabezados IP y UDP)
- varios paquetes de red que pertenecen a un solo flujo (por ejemplo, las direcciones IP)
La información redundante se transmite solo en los primeros paquetes. Los siguientes paquetes contienen información variable, por ejemplo, identificadores o números de secuencia. Estos campos se transmiten de forma comprimida para ahorrar más 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 en sí, sino que se deja a la implementación del proveedor del equipo. Una vez que se clasifica un flujo de paquetes, se comprime de acuerdo con el perfil de compresión que mejor se adapta. Un perfil de compresión define la forma de comprimir los diferentes campos en los encabezados de la red. Hay varios perfiles de compresión disponibles, incluidos los siguientes:
- Sin comprimir
- Solo IP
- UDP / IP
- UDP-Lite / IP
- ESP / IP
- RTP / UDP / IP
- RTP / UDP-Lite / IP
- TCP / IP
Modos de operacion
Según RFC 3095, el esquema ROHC tiene tres modos de operación, como sigue:
- el modo unidireccional (modo U)
- el modo optimista bidireccional (modo O)
- el modo bidireccional confiable (modo R)
Tanto el compresor como el descompresor arrancan en modo U. Luego pueden pasar al modo O si hay disponible un enlace de retorno utilizable, y el descompresor envía un reconocimiento positivo, con el modo O especificado, al compresor. La transición al modo R se realiza de la misma manera.
Modo unidireccional (modo U)
En el modo de funcionamiento Unidireccional, los paquetes solo se envían en una dirección: del compresor al descompresor. Por lo tanto, este modo hace que ROHC se pueda utilizar en enlaces donde una ruta de retorno del descompresor al compresor no está disponible o no es deseable. Para manejar posibles errores de descompresión, el compresor envía actualizaciones periódicas del contexto de la secuencia al descompresor.
Modo optimista bidireccional (modo O)
El modo bidireccional optimista es similar al modo unidireccional, excepto que se utiliza un canal de retroalimentación para enviar solicitudes de recuperación de errores y (opcionalmente) reconocimientos de actualizaciones de contexto significativas desde el descompresor al compresor. El modo O tiene como objetivo maximizar la eficiencia de la compresión y un uso escaso del canal de retroalimentación.
Modo confiable bidireccional (modo R)
El modo Bidirectional Reliable difiere en muchos aspectos de los dos modos anteriores. Las diferencias más importantes son 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 el compresor y el descompresor, excepto por tasas de error de bit residuales muy altas.
Estados del compresor / descompresor
La noción de estados de compresor / descompresor es ortogonal a los modos operativos. Cualquiera que sea el 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 hacer que el compresor / descompresor cambie su estado interno. Cada estado se refiere a un comportamiento y nivel de compresión definidos.
El algoritmo ROHC es similar a la compresión de video, ya que se envían una trama base y luego varias tramas de diferencia para representar un flujo de paquetes IP. Esto tiene la ventaja de permitir que ROHC sobreviva a muchas pérdidas de paquetes en su estado de compresión más alto, siempre que no se pierdan las tramas 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 restablecer y se envían los encabezados de paquetes completos. 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 lados de la conexión. El compresor también envía diferencias de campo de paquetes dinámicos en el estado FO. Por tanto, el estado de 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ógica y una suma de comprobación parcial para hacer que el otro lado genere y verifique de forma predictiva los encabezados del siguiente paquete esperado. En general, el estado de 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 comprobación.
Transiciones entre estados de 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 se puede sustituir por IPv4 / UDP / RTP de 40 bytes o IPv6 / UDP / RTP de 60 bytes (es decir, VoIP) encabezamiento. En este estado, el encabezado ROHC de 8 bits contiene tres campos:
- un indicador de tipo 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:
- Sin estado de contexto
- Estado de contexto estático
- Estado de contexto completo
Las transiciones entre los estados anteriores ocurren cuando el descompresor:
- descomprime con éxito un paquete
- no descomprime varios paquetes
Robustez
El tamaño del campo del número de secuencia (SN) gobierna el número 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 paquetes ROHC de 1 y 2 bytes es de 4 bits (desplazamiento de trama −1 / + 14) o 6 bits (desplazamiento de trama −1 / + 62), respectivamente, por lo que ROHC puede tolerar como máximo 62 pérdidas fotogramas con un encabezado de 1-2 bytes.
Perfiles de compresión adicionales
El RFC 3095 define un mecanismo de compresión genérico. Puede ampliarse definiendo nuevos perfiles de compresión dedicados a encabezados de protocolo específicos. Se publicaron nuevas 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 los encabezados UDP-Lite / IP y RTP / UDP-Lite / IP.
- El RFC 6846 define un perfil de compresión para encabezados TCP / IP.
RFC de ROHC más recientes
Se han publicado dos nuevos RFC, RFC 4995 y RFC 5225 para abordar la confusión que algunos han encontrado al intentar interpretar e implementar ROHC. El primer documento define un marco ROHC, mientras que el segundo define versiones más nuevas de los perfiles ROHC establecidos.
Ver también
Referencias
- ^ Michael Dosch y Steve Church. "VoIP en el estudio de transmisión" . Axia Audio. Archivado desde el original el 7 de octubre de 2011 . Consultado el 21 de junio de 2011 .
enlaces externos
- Carta oficial del grupo de trabajo ROHC IETF
- RFC 3095 - "Marco ROHC y cuatro perfiles: RTP, UDP, ESP y sin comprimir"
- RFC 3759 - "Ejemplos de asignación de canales y terminología de ROHC"
- RFC 4815 - "Correcciones y aclaraciones a RFC 3095"
- RFC 4995 - "El marco de compresión de encabezado RObust (ROHC)" (obsoleto por RFC 5795)
- RFC 4996 - "Compresión de encabezado RObust (ROHC): un perfil para TCP / IP (ROHC-TCP)"
- RFC 4997 - "Notación formal para ROHC"
- RFC 5225 - "RObust Header Compression Version 2 (ROHCv2): Perfiles para RTP, UDP, IP, ESP y UDP-Lite". Segunda versión de los perfiles que se encuentran en RFC 3095, RFC 3843 y RFC 4019. Reemplaza su definición, pero no los hace obsoletos.
- RFC 5795 - "El marco de compresión de encabezado RObust (ROHC)" (obsoleto RFC 4995)
- RFC 6846 - "Compresión de encabezado RObust (ROHC): un perfil para TCP / IP (ROHC-TCP)"
- Una implementación gratuita de ROHC en sourceforge.net
- Una biblioteca gratuita y eficiente que implementa el estándar ROHC