Static Context Header Compression
compression et fragmentation
From Wikipedia, the free encyclopedia
La compression d'en-tête de contexte statique (SCHC) est un mécanisme standard de compression et de fragmentation défini par le groupe de travail LPWAN[1] de l'IETF. Il permet la compression et la fragmentation des paquets IPv6 / UDP / CoAP pour rendre possible leur transmission sur les réseaux étendus à faible puissance (Low-Power Wide-Area Networks ou LPWAN).
Cet article est une ébauche concernant l’informatique et les télécommunications.
Schéma de compression adapté au LPWAN
À propos des LPWAN
Les réseaux étendus à faible consommation d'énergie (LPWAN) regroupent les technologies de connectivité adaptées à l'Internet des objets (IoT), permettant :
- une communication très longue portée (jusqu'à 40 km),
- une très faible consommation d'énergie (côté objet connecté),
- et efficacité énergétique (côté réseaux).
Pour atteindre ces fonctionnalités, un compromis est réalisé sur les débits et la taille des paquets pris en charge (RFC 8376[2]). De plus, les LPWAN comportent des limitations sur les modalités de transmission car, afin d'économiser la batterie, les appareils sont dormants la plupart du temps et ne se réveillent que de manière épisodique pour transmettre et recevoir des données pendant une courte période.
De ce fait, les LPWAN utilisent leurs protocoles spécifiques, chacun adapté à ses propres spécificités. Plus important encore, ils ne peuvent pas transporter IPv6, qui à la base a été conçu pour attribuer des adresses aux milliards d'appareils connectés à l'IoT.
Standards de compression IETF
Au début des années 2000, l'IETF a produit la première vague de normes matures pour la compression et la fragmentation :
- RoHC (Robust Header Compression) en 2001,
- et 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) en 2007.
Pourtant, ces schémas de compression ne peuvent pas s'appliquer aux spécificités LPWAN[3],[4],[5].
SCHC associe les avantages du contexte RoHC, qui offre une grande flexibilité dans le traitement des champs et des opérations 6LoWPAN, pour éviter le transit de champs déjà connus par l'autre partie[5].
La compression SCHC
SCHC tire parti des caractéristiques des LPWAN (pas de routage, format de trafic et contenu des messages hautement prévisibles) pour réduire la surcharge à quelques octets et économiser le trafic réseau.
La compression SCHC est basée sur la notion de contexte. Un contexte est un ensemble de règles qui décrit le contexte de communication, c'est-à -dire les champs d'en-tête. Il est partagé et pré-provisionné à la fois dans les objets connectés et dans le réseau central. Le « contexte statique » suppose que la description de la règle ne change pas pendant la transmission. Grâce à ce mécanisme, les en-têtes IPv6 / UDP sont réduits à un petit identifiant dans la plupart des cas.
La fragmentation SCHC
Lorsque la compression ne suffit pas, SCHC fournit un mécanisme de fragmentation qui fonctionne de 3 manières différentes :
No-Ack
Dans ce mode, le paquet SCHC est séparé en plusieurs fragments qui sont envoyés aveuglément au récepteur. Si le récepteur a manqué un paquet, il ne sera pas en mesure de reconstruire le paquet envoyé.
Ack-On-Error
Dans ce mode, on utilise le concept de fenêtres. Les fenêtres ont une taille prédéfinie, permettant au récepteur de pointer quelles fenêtres ou parties de fenêtres qui ont été reçues. Au moment où le récepteur obtient le dernier fragment envoyé par l'expéditeur, il calculera quelles parties des paquets sont manquantes et en informera l'expéditeur. L'expéditeur initialisera alors la retransmission des parties de paquet manquantes.
Ack-Always
En mode Ack-Always, un mécanisme de retransmission similaire à Ack-On-Error est utilisé à la différence que l'acquittement n'est pas effectué à la fin de la transmission mais pour chaque fenêtre.
La standardisation de SCHC
Le RFC 8724[6], Generic Framework for Static Context Header Compression and Fragmentation, a été publié en avril 2020[7]. Il décrit le cadre générique qui peut être utilisé sur toutes les technologies LPWAN, et plus généralement sur tous les réseaux Internet. Un travail supplémentaire est dédié à la définition des paramètres standards et des modes de fonctionnement pour optimiser les performances de SCHC selon les protocoles implémentés et les technologies LPWAN sous-jacentes :
- RFC 9011[8] : SCHC sur LoRaWAN
- RFC 8824[9] : SCHC for CoAP
- RFC 9363[10][11]: YANG Data Model for SCHC
- SCHC sur NB-IoT[12]
- SCHC sur Sigfox[13]
En dehors de l'IETF, SCHC est en cours d'adoption dans le cadre d'un effort de normalisation conjoint mené par l'Association des utilisateurs DLMS et la LoRa Alliance pour le marché des compteurs intelligents[14].
