1. Introduction
1. Introduction
La norme [IEEE802.15.4] spécifie une MTU de 127 octets, ce qui donne environ 80 octets de charge utile réelle de contrôle d'accès au support (MAC) avec la sécurité activée, sur une liaison sans fil avec un débit de liaison de 250 kbps ou moins. Le format d'adaptation 6LoWPAN [RFC4944] a été spécifié pour transporter des datagrammes IPv6 sur de telles liaisons contraintes, en tenant compte de la bande passante, de la mémoire ou des ressources énergétiques limitées qui sont attendues dans des applications telles que les réseaux de capteurs sans fil. La [RFC4944] définit un en-tête d'adressage maillé (Mesh Addressing header) pour prendre en charge le transfert sous-IP, un en-tête de fragmentation pour prendre en charge l'exigence de MTU minimale IPv6 [RFC2460], et une compression d'en-tête sans état pour les datagrammes IPv6 (LOWPAN_HC1 et LOWPAN_HC2) afin de réduire les en-têtes IPv6 et UDP relativement volumineux à (dans le meilleur des cas) plusieurs octets.
LOWPAN_HC1 et LOWPAN_HC2 sont insuffisants pour la plupart des utilisations pratiques d'IPv6 dans les 6LoWPANs. LOWPAN_HC1 est le plus efficace pour la communication unicast lien-local, où les adresses IPv6 portent le préfixe lien-local et un identifiant d'interface (IID) directement dérivé des adresses IEEE 802.15.4. Dans ce cas, les deux adresses peuvent être complètement éludées. Cependant, bien que les adresses lien-local soient couramment utilisées pour les interactions de protocole locales telles que la découverte de voisins IPv6 (Neighbor Discovery) [RFC4861], DHCPv6 [RFC3315] ou les protocoles de routage, elles ne sont généralement pas utilisées pour le trafic de données de la couche application, de sorte que la valeur réelle de ce mécanisme de compression est limitée.
Des adresses routables doivent être utilisées lors de la communication avec des dispositifs externes au 6LoWPAN ou dans une configuration route-over où le transfert IP se produit au sein du 6LoWPAN. Pour les adresses routables, LOWPAN_HC1 nécessite que les adresses source et destination IPv6 portent le préfixe en ligne (in-line). Dans les cas où l'en-tête d'adressage maillé n'est pas utilisé, l'IID d'une adresse routable doit être transporté en ligne. Cependant, LOWPAN_HC1 nécessite 64 bits pour l'IID lorsqu'il est transporté en ligne et ne peut pas être raccourci même lorsqu'il est dérivé de l'adresse courte IEEE 802.15.4 de 16 bits. Lorsque la destination est une adresse IPv6 multidiffusion, LOWPAN_HC1 nécessite que l'adresse complète de 128 bits soit transportée en ligne.
En conséquence, ce document définit un format de codage, LOWPAN_IPHC, pour une compression efficace des adresses IPv6 uniques locales, globales et multidiffusion basées sur un état partagé au sein de contextes. De plus, ce document introduit également un certain nombre d'améliorations supplémentaires par rapport au format de compression d'en-tête défini dans la [RFC4944].
LOWPAN_IPHC permet la compression de certaines valeurs de limite de saut (Hop Limit) IPv6 couramment utilisées. Si le 6LoWPAN est un maillage de type stub (mesh-under stub), une limite de saut de 1 pour les flux entrants et une valeur par défaut telle que 64 pour les flux sortants sont généralement suffisantes pour le trafic de données de la couche application. De plus, une valeur de limite de saut de 255 est souvent utilisée pour vérifier qu'une communication se produit sur un saut unique. Cette spécification permet la compression du champ limite de saut IPv6 dans ces cas courants, alors que LOWPAN_HC1 ne le fait pas.
Ce document définit également LOWPAN_NHC, un format de codage pour des en-têtes suivants arbitraires. LOWPAN_IPHC indique si l'en-tête suivant est codé à l'aide de LOWPAN_NHC. Si c'est le cas, les bits suivant immédiatement l'en-tête IPv6 compressé commencent le codage LOWPAN_NHC. En revanche, LOWPAN_HC1 pourrait être étendu pour prendre en charge la compression des en-têtes suivants à l'aide de LOWPAN_HC2, mais uniquement pour UDP, TCP et ICMPv6. De plus, l'octet LOWPAN_HC2 se situe entre l'octet LOWPAN_HC1 et les champs d'en-tête IPv6 non compressés. Cette spécification déplace les bits de codage de l'en-tête suivant pour qu'ils suivent tous les bits liés à IPv6, permettant une structure correctement stratifiée et une prise en charge directe des en-têtes d'extension IPv6.
En utilisant LOWPAN_NHC, ce document définit un mécanisme de compression pour UDP. Alors que la [RFC4944] définit un mécanisme de compression pour UDP, ce mécanisme ne permet pas la compression de la somme de contrôle (checksum) lorsqu'elle est rendue possible par des mécanismes de couche supérieure supplémentaires tels que le contrôle d'intégrité de message (MIC) de couche supérieure. Cette spécification ajoute la capacité d'éluder la somme de contrôle UDP sur le 6LoWPAN, ce qui permet d'économiser deux octets supplémentaires.
De plus, en utilisant LOWPAN_NHC, ce document définit des formats de codage pour l'encapsulation IPv6-in-IPv6 ainsi que pour les en-têtes d'extension IPv6. Avec LOWPAN_HC1 et LOWPAN_HC2, les chaînes d'en-têtes suivants ne peuvent pas être codées efficacement.
1.1 Langage des exigences
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans la RFC 2119 [RFC2119].