Un vistazo a SCHC para entender cómo facilita el envío de paquetes IP comprimidos en enlaces restringidos

SCHC (Static Context Header Compression) es un estándar definido en el RFC 8724 que especifica un mecanismo de compresión y fragmentación de paquetes diseñado para entornos con recursos extremadamente limitados. Su objetivo principal es reducir drásticamente el tamaño de las cabeceras de protocolos como IPv6, UDP o CoAP mediante el uso de contextos estáticos previamente compartidos entre los extremos de la comunicación.

Además de la compresión de cabeceras, el estándar define un esquema de fragmentación adaptado a enlaces con tamaño de trama muy reducido, como los típicos de redes LPWAN. Este mecanismo incorpora distintos modos de operación, incluyendo opciones con confirmación (ACK-on-Error y ACK-Always), lo que permite introducir control y recuperación de fragmentos perdidos sin necesidad de recurrir a protocolos de transporte como TCP.

Cabecera IPv6 sin extensiones (40 bytes - 320 bits)

Tras la compresión/fragmentación de información con SCHC, lo que viaja por la red no es un paquete IP/IPv6 válido, puesto que su cabecera ha sido comprimida y ya no contiene toda la información necesaria. Lo que viaja por la red es un residuo SCHC + RuleID + fragmentos (si hay), por lo que solo un receptor con el mismo contexto puede reconstruir el paquete IP/IPv6 original.

Esto se vuelve útil, incluso necesario en redes LPWAN porque las restricciones en el enlace suelen ser muy limitantes, con tamaños máximos de transferencia de unas cuantas decenas de bytes (50-200 aprox.). Teniendo en cuenta que el par de cabeceras IPv6+UDP sin extensiones ya ocupa 48 bytes, la compresión se hace muy necesaria.

Un vistazo a la cabecera IPv6

Campo	Tamaño
Version	4 bits
Traffic Class	8 bits
Flow Label	20 bits
Payload Length	16 bits
Next Header	8 bits
Hop Limit	8 bits
Source Address	128 bits
Destination Address	128 bits

En la tabla anterior se recojen todos los campos de la cabecera de IPv6 y sus respectivos tamaños en bits. Con compresión SCHC se puede reducir muchísimo su tamaño teniendo una cosa en mente: enviar únicamente aquellos campos que no se puedan conocer de antemano o deducir en el destino.

En escenarios altamente deterministas, SCHC puede reducir la cabecera IPv6 a unos pocos bits (principalmente el RuleID). Sin embargo, el tamaño real depende del grado de variabilidad de los campos y del diseño del contexto.

Cómo reduce SCHC cada campo de la cabecera IPv6

El llamado contexto estático no es más que un conjunto de reglas que definen explícitamente cómo se comprime y descomprime cada campo de la cabecera.

Version (4 bits)

El campo Version en IPv6 siempre vale 6. En un contexto SCHC, se puede definir una regla donde esto se recoja. Como el valor es constante y conocido por ambos extremos, no es necesario transmitirlo.

Traffic Class (8 bits)

Si el dispositivo siempre utiliza el valor 0, puede omitirse completamente, ya que el receptor lo reconstruirá a partir del contexto compartido.

Flow Label (20 bits)

En muchos dispositivos IoT este campo no se utiliza y permanece en 0. Si ese comportamiento es constante, tampoco se transmite.

Payload Length (16 bits)

Este valor puede inferirse a partir del tamaño real del paquete recibido o del mecanismo de fragmentación SCHC. Por tanto, no es necesario enviarlo explícitamente.

Next Header (8 bits)

Si el protocolo de transporte es siempre UDP (valor 17), el campo puede definirse en el contexto como constante y no enviarse.

Hop Limit (8 bits)

Si el valor es fijo (por ejemplo, 64), puede omitirse. Si varía dentro de un rango limitado, podría enviarse de forma comprimida, transmitiendo únicamente los bits necesarios.

Source Address (128 bits)

Supongamos una dirección como 2001:db8:abcd:0012::1234. En un escenario LPWAN típico, el prefijo de red suele ser fijo. En ese caso:

• El prefijo no se envía (2001:db8:abcd:0012).
• Solo se envía el IID (1234)
• El resultado es que los 64 bits del prefijo pueden eliminarse del paquete transmitido.

Destination Address (128 bits)

Si el dispositivo siempre se comunica con el mismo servidor, la dirección de destino también puede definirse en el contexto y no enviarse. Al menos podría no enviarse el IID, por ejemplo.

Gracias al uso de estos contextos estáticos SCHC previamente establecidos en cada dispositivo, el extremo receptor puede reconstruir de forma determinista la cabecera IPv6 completa a partir de un residuo mínimo o incluso nulo, eliminando la necesidad de transmitir explícitamente campos redundantes.

Para más detalles recomiendo la lectura del estándar oficial: "SCHC: Generic Framework for Static Context Header Compression and Fragmentation".