3.1. SCHC Compound ACK Message Format (Formato Messaggio ACK Composto SCHC)
3.1. SCHC Compound ACK Message Format (Formato Messaggio ACK Composto SCHC)
La figura 1 mostra il formato SCHC ACK di successo, cioè quando tutti i frammenti sono stati ricevuti correttamente (C=1), come definito in [RFC8724].
|--- SCHC ACK Header ---|
| |--T-|--M--| 1 |
+--------+----+-----+---+~~~~~~~~~~~~~~~~~~
| RuleID |DTag| W |C=1| padding as needed
+--------+----+-----+---+~~~~~~~~~~~~~~~~~~
Figura 1: Formato Messaggio SCHC ACK di Successo, come Definito in RFC 8724
Nel caso in cui vengano trovate perdite di SCHC Fragment in una qualsiasi delle windows (finestre) del SCHC Packet, il SCHC Compound ACK PUÒ essere utilizzato. Il formato del messaggio SCHC Compound ACK è mostrato nelle figure 2 e 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 ->|
Figura 2: Formato Messaggio SCHC Compound ACK. Le perdite si trovano nelle windowsdows W = w1, ..., wi, dove w1 < w2 < ... < wi.
Il SCHC Compound ACK raggruppa il window number (numero di finestra) (W) con la sua corrispondente bitmap (mappa di bit). I window numbers non devono essere contigui. Tuttavia, i window numbers e le loro corrispondenti bitmaps inclusi nel messaggio SCHC Compound ACK DEVONO essere ordinati dal window numerato più basso al window numerato più alto. Quindi, se la bitmap del window number zero è presente nel messaggio SCHC Compound ACK, DEVE sempre essere la prima nell'ordine e il suo window number DEVE essere posizionato nello SCHC ACK Header.
Se M o più bit di padding (riempimento) sarebbero necessari dopo l'ultima bitmap nel messaggio per riempire l'ultimo layer two (L2, livello due) Word, M bit a 0 DEVONO essere aggiunti dopo l'ultima bitmap, e poi il padding viene applicato come necessario (vedere Figura 2). Poiché il window number 0 (se presente nel messaggio) è posizionato come w1, gli M bit impostati a zero non possono essere confusi con il window number 0; pertanto, segnalano la fine del messaggio SCHC Compound ACK.
La figura 3 mostra il caso in cui i bit di padding richiesti sono strettamente inferiori a M bit. In questo caso, la L2 Maximum Transmission Unit (MTU, unità di trasmissione massima) non lascia spazio per alcun valore di window aggiuntivo, tanto meno per alcuna bitmap, segnalando così la fine del messaggio 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 ->|
Figura 3: Formato Messaggio SCHC Compound ACK con Meno di M Bit di Padding. Le perdite si trovano nelle windowsdows W = w1, ..., wi, dove w1 < w2 < ... < wi.
Il SCHC Compound ACK NON DEVE utilizzare il formato Compressed Bitmap (bitmap compressa) per windows/bitmaps intermedie (cioè bitmaps che non sono l'ultima del messaggio SCHC Compound ACK); pertanto, i campi bitmap intermedi DEVONO essere di dimensione WINDOW_SIZE. Quindi, il SCHC Compound ACK PUÒ utilizzare un formato Compressed Bitmap solo per l'ultima bitmap nel messaggio. L'uso opzionale di questa Compressed Bitmap per l'ultima bitmap DEVE essere specificato dal SCHC Profile (profilo SCHC) specifico della tecnologia.
Il caso in cui l'ultima bitmap è effettivamente compressa corrisponde alla Figura 3, con l'ultima bitmap che termina (per costruzione) su un confine di L2 Word, quindi non richiede alcun padding.
La figura 4 illustra un esempio di compressione bitmap di un SCHC Compound ACK, dove la bitmap dell'ultimo window (wi) indica che la prima tile (tessera) non è stata ricevuta correttamente. Poiché l'algoritmo di compressione ha portato a una compressione efficace, non è necessario alcun padding.
|--- 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 con Bitmap Non Compressa
|--- 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 Trasmesso con Bitmap Compressa
Figura 4: Formato Messaggio SCHC Compound ACK con Bitmap Compressa e Nessun Padding Aggiunto. Le perdite si trovano nelle windowsdows W = w1, ..., wi, dove w1 < w2 < ... < wi.
La figura 5 illustra un altro esempio di compressione bitmap di un SCHC Compound ACK, dove la bitmap dell'ultimo window (wi) indica che la seconda e la quarta tiles non sono state ricevute correttamente. In questo esempio, l'algoritmo di compressione non porta a una compressione efficace dell'ultima bitmap. Inoltre, poiché sarebbero necessari più di M bit di padding per riempire l'ultimo L2 Word, M bit a 0 vengono aggiunti al messaggio prima che venga applicato il padding.
|--- 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 con Bitmap Non Compressa
|--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
|--T-|---M--|-1-| |...|---M--| |---M--|
+------+----+------+---+------+...+------+--------------+------+~~~+
|RuleID|DTag| W=w1 |C=0|Bitmap|...| W=vi |1 0 1 0 1 1 1 |00..00|pad|
+------+----+------+---+------+...+------+--------------+------+~~~+
next L2 Word boundary ->|<------ L2 Word ------>|
SCHC Compound ACK Trasmesso
Figura 5: Formato Messaggio SCHC Compound ACK con Bitmap Compressa e Padding Aggiunto per Raggiungere il Confine L2. Le perdite si trovano nelle windows W = w1, ..., wi, dove w1 < w2 < ... < wi.
Se un SCHC sender (mittente SCHC) riceve un SCHC Compound ACK con window numbers non validi, come valori W duplicati o valori W non ancora inviati, DEVE scartare l'intero messaggio SCHC Compound ACK.
Nota: I SCHC Compound ACKs sono distinguibili dal messaggio Receiver-Abort (interruzione del ricevitore) nello stesso modo in cui gli SCHC ACKs regolari sono distinguibili, poiché il pattern Receiver-Abort non si verifica mai in un SCHC Compound ACK legittimo [RFC8724].