10. Compression d'en-tête (Header Compression)

Il existe de nombreux travaux de standardisation publiés et en cours sur la compression d'en-tête. Cependant, la compression d'en-tête pour IPv6 over IEEE 802.15.4 présente des contraintes différentes, résumées ci-dessous :

• Les travaux existants supposent de nombreux flux (Flows) entre deux dispositifs quelconques. Ici, nous supposons un style de compression d'en-tête très simple et à faible contexte (Low-Context). Bien que cela soit indépendant du travail sur les flux (il peut y en avoir plusieurs), il n'utilise aucun contexte spécifique à un flux particulier. Par conséquent, il ne peut pas atteindre le niveau de compression qu'un schéma construisant des contextes séparés pour chaque flux à compresser pourrait atteindre.

• Étant donné la taille de paquet très limitée, il est hautement souhaitable d'intégrer la compression des couches 2 et 3, ce qui n'a traditionnellement pas été fait (bien que cela soit en train de changer grâce au groupe de travail ROHC (RObust Header Compression, compression d'en-tête robuste)).

• Il est prévu que les dispositifs IEEE 802.15.4 seront déployés dans des réseaux multi-sauts (Multi-Hop Networks). Cependant, la compression d'en-tête dans un réseau maillé diffère du scénario habituel de liaison point à point, dans lequel le compresseur et le décompresseur communiquent directement et exclusivement l'un avec l'autre. Dans les réseaux IEEE 802.15.4, il est hautement souhaitable que les dispositifs puissent envoyer des paquets avec en-tête compressé via n'importe lequel de leurs voisins, avec le moins possible de construction de contexte préalable.

Tout nouveau format de paquet requis pour la compression d'en-tête réutilise le format de paquet de base défini à la section 5 en utilisant différentes valeurs de dispatch (Dispatch Values).

La compression d'en-tête peut entraîner un alignement qui ne tombe pas sur des limites d'octets. Étant donné que le matériel ne peut généralement pas transmettre des données en unités inférieures à l'octet, un rembourrage (Padding) doit être utilisé. Le rembourrage est effectué comme suit : premièrement, toute la série continue d'en-têtes compressés est arrangée (ce document ne définit que des schémas de compression d'en-tête IPv6 et UDP, mais d'autres schémas peuvent être définis ailleurs). Ensuite, des bits zéro sont ajoutés selon les besoins pour s'aligner sur une limite d'octet. Cela compense tout désalignement potentiel causé par la compression d'en-tête, de sorte que les champs suivants (par exemple, les en-têtes non compressés ou la charge utile de données) commencent à une limite d'octet et se poursuivent normalement.

10.1. Encodage des champs d'en-tête IPv6 (Encoding of IPv6 Header Fields)

En rejoignant le même réseau 6LoWPAN, les dispositifs partagent un certain état. Cela permet de compresser les en-têtes sans avoir à construire explicitement un état de contexte de compression. Par conséquent, la compression d'en-tête 6LoWPAN ne conserve aucun état de flux ; au lieu de cela, elle s'appuie sur des informations liées à l'ensemble du lien. Les valeurs d'en-tête IPv6 suivantes sont prévues comme étant courantes sur les réseaux 6LoWPAN, et l'en-tête HC1 est donc construit pour les compresser efficacement dès le départ :

• Version est IPv6
• Les adresses source et de destination IPv6 sont toutes deux locales au lien (Link Local)
• L'identifiant d'interface IPv6 (les 64 bits inférieurs) de l'adresse source ou de destination peut être déduit des adresses source et de destination de la couche 2 (bien sûr, cela n'est possible que pour les identifiants d'interface dérivés des adresses MAC 802.15.4 sous-jacentes)
• La longueur du paquet peut être déduite de la couche 2 (le champ « Frame Length » dans le PPDU IEEE 802.15.4) ou du champ « datagram_size » dans l'en-tête de fragmentation (s'il est présent)
• Traffic Class et Flow Label sont tous deux nuls
• Next Header est UDP, ICMP ou TCP

Le seul champ de l'en-tête IPv6 qui doit toujours être transporté intégralement est Hop Limit (limite de sauts, 8 bits). Selon le degré de correspondance du paquet avec ce cas courant, différents champs peuvent ne pas être compressibles et doivent donc être transportés « en ligne » (In-Line) (section 10.3.1). Cet en-tête IPv6 courant (tel que décrit ci-dessus) peut être compressé à 2 octets (1 octet pour l'encodage HC1, 1 octet pour Hop Limit), au lieu de 40 octets.

Un tel paquet peut être compressé via le format LOWPAN_HC1 en utilisant la valeur de dispatch de LOWPAN_HC1, suivie du champ « encodage HC1 » de l'en-tête LOWPAN_HC1 (8 bits) pour encoder les différentes combinaisons présentées ci-dessous.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9 : LOWPAN_HC1 (encodage d'en-tête compressé courant)

Les champs d'adresse encodés par « l'encodage HC1 » sont interprétés comme suit :

• PI : Prefix carried in-line (préfixe transporté en ligne)
• PC : Prefix compressed (préfixe compressé, préfixe local au lien supposé)
• II : Interface identifier carried in-line (identifiant d'interface transporté en ligne)
• IC : Interface identifier elided (identifiant d'interface omis, peut être dérivé de l'adresse de couche liaison correspondante)

Encodage HC1 (du bit 0 au bit 7) :

Adresse source IPv6 (bits 0 et 1) :

• 00 : PI, II
• 01 : PI, IC
• 10 : PC, II
• 11 : PC, IC

Adresse de destination IPv6 (bits 2 et 3) :

• 00 : PI, II
• 01 : PI, IC
• 10 : PC, II
• 11 : PC, IC

Traffic Class et Flow Label (bit 4) :

• 0 : non compressé ; envoyer le Traffic Class complet sur 8 bits et le Flow Label sur 20 bits
• 1 : Traffic Class et Flow Label sont nuls

Next Header (bits 5 et 6) :

• 00 : non compressé ; envoyer les 8 bits complets
• 01 : UDP
• 10 : ICMP
• 11 : TCP

Encodage HC2 (bit 7) :

• 0 : pas d'autres bits de compression d'en-tête
• 1 : l'encodage HC1 est immédiatement suivi de bits de compression d'en-tête supplémentaires selon le format d'encodage HC2. Les bits 5 et 6 déterminent quels encodages HC2 possibles s'appliquent (par exemple, encodages UDP, ICMP ou TCP).

10.2. Encodage des champs d'en-tête UDP (Encoding of UDP Header Fields)

Les bits 5 et 6 de LOWPAN_HC1 permettent de compresser le champ Next Header dans l'en-tête IPv6 (pour UDP, TCP et ICMP). Il est également possible de compresser davantage chacun de ces en-têtes de protocole. Cette section explique comment compresser l'en-tête UDP lui-même. L'encodage HC2 dans cette section est l'encodage HC_UDP, qui ne s'applique que lorsque les bits 5 et 6 de HC1 indiquent que le protocole suivant l'en-tête IPv6 est UDP.

L'encodage HC_UDP permet de compresser les champs suivants de l'en-tête UDP : port source (Source Port), port de destination (Destination Port) et longueur (Length). Le champ de somme de contrôle (Checksum) de l'en-tête UDP n'est pas compressé et est donc transporté intégralement. Le schéma défini ci-dessous permet de compresser l'en-tête UDP à 4 octets, au lieu des 8 octets d'origine.

Le seul champ d'en-tête UDP dont la valeur peut être déduite d'informations disponibles ailleurs est Length. Les autres champs doivent être transportés en ligne, intégralement ou de manière partiellement compressée (section 10.3.2).

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10 : HC_UDP (encodage d'en-tête UDP compressé courant)

« Encodage HC_UDP » pour UDP (du bit 0 au bit 7) :

Port source UDP (bit 0) :

• 0 : non compressé, transporté en ligne
• 1 : compressé à 4 bits. Le port source 16 bits réel est obtenu par calcul : P + valeur short_port. La valeur de P est le nombre 61616 (0xF0B0). short_port est représenté comme une valeur de 4 bits, transportée en ligne

Port de destination UDP (bit 1) :

• 0 : non compressé, transporté en ligne
• 1 : compressé à 4 bits. Le port de destination 16 bits réel est obtenu par calcul : P + valeur short_port. La valeur de P est le nombre 61616 (0xF0B0). short_port est représenté comme une valeur de 4 bits, transportée en ligne

Length (bit 2) :

• 0 : non compressé, transporté en ligne
• 1 : compressé, la longueur est calculée à partir des informations de longueur de l'en-tête IPv6. La valeur du champ de longueur UDP est égale à la Payload Length de l'en-tête IPv6, moins la longueur de tout en-tête d'extension présent entre l'en-tête IPv6 et l'en-tête UDP

Réservé (bits 3 à 7)

10.3. Champs non compressés (Non-Compressed Fields)

10.3.1. Champs IPv6 non compressés (Non-Compressed IPv6 Fields)

Ce schéma permet de compresser l'en-tête IPv6 à différents degrés. Par conséquent, seuls les champs non compressés doivent être envoyés, et non l'intégralité de l'en-tête IPv6 (standard). Les en-têtes suivants (spécifiés par le champ Next Header dans l'en-tête IPv6 d'origine) suivent immédiatement les champs IPv6 non compressés.

Le champ IPv6 non compressé qui DOIT toujours être présent est Hop Limit (8 bits). Ce champ DOIT toujours suivre les champs d'encodage (par exemple, « l'encodage HC1 » comme illustré à la figure 9, pouvant inclure d'autres champs d'encodage futurs). Les autres champs non compressés DOIVENT suivre Hop Limit dans l'ordre impliqué par « l'encodage HC1 », exactement dans le même ordre que celui indiqué ci-dessus (section 10.1) : préfixe d'adresse source (64 bits) et/ou identifiant d'interface (64 bits), préfixe d'adresse de destination (64 bits) et/ou identifiant d'interface (64 bits), Traffic Class (8 bits), Flow Label (20 bits) et Next Header (8 bits). L'en-tête suivant réel (par exemple, UDP, TCP, ICMP, etc.) suit les champs non compressés.

10.3.2. Champs UDP non compressés et partiellement compressés (Non-Compressed and Partially Compressed UDP Fields)

Ce schéma permet de compresser l'en-tête UDP à différents degrés. Par conséquent, seuls les champs non compressés ou partiellement compressés doivent être envoyés, et non l'intégralité de l'en-tête UDP (standard).

Les champs en ligne non compressés ou partiellement compressés de l'en-tête UDP DOIVENT toujours suivre l'en-tête IPv6 et tous ses champs en ligne associés. Tout champ en ligne d'en-tête UDP présent DOIT apparaître dans le même ordre que les champs correspondants dans l'en-tête UDP normal [RFC0768], par exemple, port source, port de destination, longueur et somme de contrôle. Si le port source ou de destination utilise la notation « short_port » (comme indiqué dans l'en-tête UDP compressé), le numéro de port en ligne prend 4 bits au lieu de 16 bits.

---