Aller au contenu principal

3.1. SCHC Compound ACK Message Format (Format de Message ACK Composé SCHC)

3.1. SCHC Compound ACK Message Format (Format de Message ACK Composé SCHC)​

La figure 1 montre le format SCHC ACK de succès, c'est-à-dire lorsque tous les fragments ont été correctement reçus (C=1), tel que défini dans [RFC8724].

              |--- SCHC ACK Header ---|
              |        |--T-|--M--| 1 |
              +--------+----+-----+---+~~~~~~~~~~~~~~~~~~
              | RuleID |DTag|  W  |C=1| padding as needed
              +--------+----+-----+---+~~~~~~~~~~~~~~~~~~

Figure 1: Format de Message SCHC ACK de Succès, tel que Défini dans RFC 8724

Dans le cas où des pertes de SCHC Fragment sont trouvées dans l'une des windows (fenêtres) du SCHC Packet, le SCHC Compound ACK PEUT être utilisé. Le format du message SCHC Compound ACK est montré dans les figures 2 et 3.

 |--- SCHC ACK Header --|- W=w1 -|`...`|---- W=wi -----|
        |--T-|---M--|-1-|        |`...`|---M--|        |---M--|
 +------+----+------+---+--------+`...`+------+--------+------+~~~~~+
 |RuleID|DTag| W=w1 |C=0| Bitmap |`...`| W=wi | Bitmap |00..00| pad |
 +------+----+------+---+--------+`...`+------+--------+------+~~~~~+
                           next L2 Word boundary ->|<-- L2 Word ->|

Figure 2: Format de Message SCHC Compound ACK. Des pertes sont trouvées dans les windows W = w1, ..., wi, où w1 < w2 < ... < wi.

Le SCHC Compound ACK regroupe le window number (numéro de fenêtre) (W) avec sa bitmap (carte de bits) correspondante. Les window numbers n'ont pas besoin d'être contigus. Cependant, les window numbers et leurs bitmaps correspondantes inclus dans le message SCHC Compound ACK DOIVENT être ordonnés du window numéroté le plus bas au window numéroté le plus haut. Par conséquent, si la bitmap du window number zéro est présente dans le message SCHC Compound ACK, elle DOIT toujours être la première dans l'ordre et son window number DOIT être placé dans le SCHC ACK Header.

Si M bits de padding (remplissage) ou plus seraient nécessaires après la dernière bitmap dans le message pour remplir le dernier layer two (L2, couche deux) Word, M bits à 0 DOIVENT être ajoutés après la dernière bitmap, puis le padding est appliqué au besoin (voir Figure 2). Puisque le window number 0 (s'il est présent dans le message) est placé comme w1, les M bits mis à zéro ne peuvent pas être confondus avec le window number 0; par conséquent, ils signalent la fin du message SCHC Compound ACK.

La figure 3 montre le cas où les bits de padding requis sont strictement inférieurs à M bits. Dans ce cas, la L2 Maximum Transmission Unit (MTU, unité de transmission maximale) ne laisse pas de place pour une valeur de window supplémentaire, et encore moins pour une bitmap, signalant ainsi la fin du message SCHC Compound ACK.

 |--- SCHC ACK Header --|- W=w1 -|`...`|---- W=wi -----|
        |--T-|---M--|-1-|        |`...`|---M--|        |---M--|
 +------+----+------+---+--------+`...`+------+--------+~~~+
 |RuleID|DTag| W=w1 |C=0| Bitmap |`...`| W=wi | Bitmap |pad|
 +------+----+------+---+--------+`...`+------+--------+~~~+
                                 next L2 Word boundary ->|

Figure 3: Format de Message SCHC Compound ACK avec Moins de M Bits de Padding. Des pertes sont trouvées dans les windows W = w1, ..., wi, où w1 < w2 < ... < wi.

Le SCHC Compound ACK NE DOIT PAS utiliser le format Compressed Bitmap (bitmap compressée) pour les windows/bitmaps intermédiaires (c'est-à-dire les bitmaps qui ne sont pas la dernière du message SCHC Compound ACK); par conséquent, les champs bitmap intermédiaires DOIVENT être de taille WINDOW_SIZE. Par conséquent, le SCHC Compound ACK PEUT utiliser un format Compressed Bitmap uniquement pour la dernière bitmap dans le message. L'utilisation optionnelle de cette Compressed Bitmap pour la dernière bitmap DOIT être spécifiée par le SCHC Profile (profil SCHC) spécifique à la technologie.

Le cas où la dernière bitmap est effectivement compressée correspond à la Figure 3, avec la dernière bitmap se terminant (par construction) sur une limite de L2 Word, ne nécessitant donc aucun padding du tout.

La figure 4 illustre un exemple de compression bitmap d'un SCHC Compound ACK, où la bitmap de la dernière window (wi) indique que la première tile (tuile) n'a pas été correctement reçue. Parce que l'algorithme de compression a abouti à une compression efficace, aucun padding n'est nécessaire.

 |--- SCHC ACK Header --|- W=w1 -|`...`|-------- W=wi -------|
        |--T-|---M--|-1-|        |`...`|---M--|
 +------+----+------+---+--------+`...`+------+--------------+
 |RuleID|DTag| W=w1 |C=0| Bitmap |`...`| W=wi |0 1 1 1 1 1 1 |
 +------+----+------+---+--------+`...`+------+--------------+
                        next L2 Word boundary ->|

                SCHC Compound ACK avec Bitmap Non Compressée

 |--- SCHC ACK Header --|- W=w1 -|`...`|-- W=wi --|
        |--T-|---M--|-1-|        |`...`|---M--|
 +------+----+------+---+--------+`...`+------+---+
 |RuleID|DTag| W=w1 |C=0| Bitmap |`...`| W=wi |0 1|
 +------+----+------+---+--------+`...`+------+---+
                        next L2 Word boundary ->|

       SCHC Compound ACK Transmis avec Bitmap Compressée

Figure 4: Format de Message SCHC Compound ACK avec Bitmap Compressée et Aucun Padding Ajouté. Des pertes sont trouvées dans les windows W = w1, ..., wi, où w1 < w2 < ... < wi.

La figure 5 illustre un autre exemple de compression bitmap d'un SCHC Compound ACK, où la bitmap de la dernière window (wi) indique que les deuxième et quatrième tiles n'ont pas été correctement reçues. Dans cet exemple, l'algorithme de compression ne résulte pas en une compression efficace de la dernière bitmap. De plus, comme plus de M bits de padding seraient nécessaires pour remplir le dernier L2 Word, M bits à 0 sont ajoutés au message avant que le padding ne soit appliqué.

|--- SCHC ACK Header --|-W=w1-|`...`|-------- W=wi -------|
       |--T-|---M--|-1-|      |`...`|---M--|
+------+----+------+---+------+`...`+------+--------------+
|RuleID|DTag| W=w1 |C=0|Bitmap|`...`| W=wi |1 0 1 0 1 1 1 |
+------+----+------+---+------+`...`+------+--------------+
                   next L2 Word boundary ->|

                SCHC Compound ACK avec Bitmap Non Compressée

|--- SCHC ACK Header --|-W=w1-|`...`|-------- W=wi -------|
       |--T-|---M--|-1-|      |`...`|---M--|              |---M--|
+------+----+------+---+------+`...`+------+--------------+------+~~~+
|RuleID|DTag| W=w1 |C=0|Bitmap|`...`| W=wi |1 0 1 0 1 1 1 |00..00|pad|
+------+----+------+---+------+`...`+------+--------------+------+~~~+
                   next L2 Word boundary ->|<------ L2 Word ------>|

                 SCHC Compound ACK Transmis

Figure 5: Format de Message SCHC Compound ACK avec Bitmap Compressée et Padding Ajouté pour Atteindre la Limite L2. Des pertes sont trouvées dans les windows W = w1, ..., wi, où w1 < w2 < ... < wi.

Si un SCHC sender (émetteur SCHC) reçoit un SCHC Compound ACK avec des window numbers invalides, tels que des valeurs W dupliquées ou des valeurs W non encore envoyées, il DOIT rejeter l'ensemble du message SCHC Compound ACK.

Note: Les SCHC Compound ACKs sont distinguables du message Receiver-Abort (abandon du récepteur) de la même manière que les SCHC ACKs réguliers sont distinguables, puisque le motif Receiver-Abort ne se produit jamais dans un SCHC Compound ACK légitime [RFC8724].

Dernière mise à jour le