Zum Hauptinhalt springen

3.1. SCHC Compound ACK Message Format (SCHC Zusammengesetzte Bestätigung Nachrichtenformat)

3.1. SCHC Compound ACK Message Format (SCHC Zusammengesetzte Bestätigung Nachrichtenformat)​

Abbildung 1 zeigt das erfolgreiche SCHC ACK-Format, d.h. wenn alle Fragmente korrekt empfangen wurden (C=1), wie in [RFC8724] definiert.

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

Abbildung 1: SCHC Erfolgs-ACK Nachrichtenformat, wie in RFC 8724 Definiert

Falls SCHC Fragment-Verluste in einem der windows (Fenster) des SCHC Packet gefunden werden, KANN die SCHC Compound ACK verwendet werden. Das SCHC Compound ACK Nachrichtenformat ist in den Abbildungen 2 und 3 dargestellt.

 |--- 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 ->|

Abbildung 2: SCHC Compound ACK Nachrichtenformat. Verluste werden in windows W = w1,...,wi gefunden, wobei w1 < w2 <...< wi.

Die SCHC Compound ACK gruppiert die window number (Fensternummer) (W) mit ihrer entsprechenden bitmap (Bitmap). Window numbers müssen nicht zusammenhängend sein. Allerdings MÜSSEN die in der SCHC Compound ACK-Nachricht enthaltenen window numbers und ihre entsprechenden bitmaps von der niedrigsten bis zur höchsten nummerierten window geordnet sein. Wenn daher die bitmap der window number null in der SCHC Compound ACK-Nachricht vorhanden ist, MUSS sie immer die erste in der Reihenfolge sein und ihre window number MUSS im SCHC ACK Header platziert werden.

Wenn M oder mehr padding (Auffüll-) Bits nach der letzten bitmap in der Nachricht benötigt würden, um das letzte layer two (L2, Schicht zwei) Word zu füllen, MÜSSEN M Bits mit Wert 0 nach der letzten bitmap angefügt werden, und dann wird padding nach Bedarf angewendet (siehe Abbildung 2). Da window number 0 (falls in der Nachricht vorhanden) als w1 platziert wird, können die auf Null gesetzten M Bits nicht mit window number 0 verwechselt werden; daher signalisieren sie das Ende der SCHC Compound ACK-Nachricht.

Abbildung 3 zeigt den Fall, wenn die erforderlichen padding Bits strikt kleiner als M Bits sind. In diesem Fall lässt die L2 Maximum Transmission Unit (MTU, maximale Übertragungseinheit) keinen Raum für einen zusätzlichen window-Wert, geschweige denn für eine bitmap, und signalisiert damit das Ende der SCHC Compound ACK-Nachricht.

 |--- 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 ->|

Abbildung 3: SCHC Compound ACK Nachrichtenformat mit Weniger als M Padding Bits. Verluste werden in windows W = w1,...,wi gefunden, wobei w1 < w2 <...< wi.

Die SCHC Compound ACK DARF NICHT das Compressed Bitmap (komprimierte Bitmap) Format für Zwischen-windows/bitmaps verwenden (d.h. bitmaps, die nicht die letzte der SCHC Compound ACK-Nachricht sind); daher MÜSSEN Zwischen-bitmap-Felder die Größe WINDOW_SIZE haben. Daher KANN die SCHC Compound ACK ein Compressed Bitmap Format nur für die letzte bitmap in der Nachricht verwenden. Die optionale Verwendung dieser Compressed Bitmap für die letzte bitmap MUSS durch das technologiespezifische SCHC Profile (SCHC-Profil) spezifiziert werden.

Der Fall, in dem die letzte bitmap effektiv komprimiert ist, entspricht Abbildung 3, wobei die letzte bitmap (durch Konstruktion) an einer L2 Word-Grenze endet und daher überhaupt kein padding benötigt.

Abbildung 4 veranschaulicht ein bitmap-Kompressionsbeispiel einer SCHC Compound ACK, bei dem die bitmap des letzten window (wi) anzeigt, dass die erste tile (Kachel) nicht korrekt empfangen wurde. Da der Kompressionsalgorithmus zu einer effektiven Kompression führte, ist kein padding erforderlich.

 |--- 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 mit Unkomprimierter Bitmap

 |--- 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 ->|

       Übertragene SCHC Compound ACK mit Komprimierter Bitmap

Abbildung 4: SCHC Compound ACK Nachrichtenformat mit Komprimierter Bitmap und Ohne Hinzugefügtes Padding. Verluste werden in windows W = w1,...,wi gefunden, wobei w1 < w2 <...< wi.

Abbildung 5 veranschaulicht ein weiteres bitmap-Kompressionsbeispiel einer SCHC Compound ACK, bei dem die bitmap des letzten window (wi) anzeigt, dass die zweite und vierte tiles nicht korrekt empfangen wurden. In diesem Beispiel führt der Kompressionsalgorithmus nicht zu einer effektiven Kompression der letzten bitmap. Da außerdem mehr als M Bits padding benötigt würden, um das letzte L2 Word zu füllen, werden M Bits mit Wert 0 an die Nachricht angehängt, bevor padding angewendet wird.

|--- 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 mit Unkomprimierter Bitmap

|--- 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 ------>|

                 Übertragene SCHC Compound ACK

Abbildung 5: SCHC Compound ACK Nachrichtenformat mit Komprimierter Bitmap und Hinzugefügtem Padding zum Erreichen der L2-Grenze. Verluste werden in windows W = w1,...,wi gefunden, wobei w1 < w2 < ... < wi.

Wenn ein SCHC sender (SCHC-Sender) eine SCHC Compound ACK mit ungültigen window numbers erhält, wie z.B. doppelte W-Werte oder noch nicht gesendete W-Werte, MUSS er die gesamte SCHC Compound ACK-Nachricht verwerfen.

Hinweis: SCHC Compound ACKs sind von der Receiver-Abort (Empfänger-Abbruch) Nachricht auf dieselbe Weise unterscheidbar wie reguläre SCHC ACKs unterscheidbar sind, da das Receiver-Abort-Muster niemals in einer legitimen SCHC Compound ACK [RFC8724] auftritt.

Letztes Update am