3.1. LOWPAN_IPHC-Codierungsformat

Dieser Abschnitt spezifiziert das Format der LOWPAN_IPHC-Codierung, das beschreibt, wie ein IPv6-Header komprimiert wird. Die Codierung kann 2 Oktette lang sein für die Basiscodierung oder 3 Oktette lang, wenn eine zusätzliche Kontextcodierung vorhanden ist. Die IPv6-Header-Felder, die nicht vollständig weggelassen werden, werden unmittelbar nach dem LOWPAN_IPHC platziert, entweder in komprimierter Form, wenn das Feld teilweise weggelassen wird, oder wörtlich.

3.1.1. Basisformat

    0                                       1
    0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  | 0 | 1 | 1 |  TF   |NH | HLIM  |CID|SAC|  SAM  | M |DAC|  DAM  |
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                 Abbildung 2: LOWPAN_IPHC-Basiscodierung

TF: Traffic Class, Flow Label (Verkehrsklasse, Flusskennzeichnung): Wie in [RFC3168] spezifiziert, wird das 8-Bit-IPv6-Traffic-Class-Feld in zwei Felder aufgeteilt: 2-Bit Explicit Congestion Notification (ECN) und 6-Bit Differentiated Services Code Point (DSCP).

• 00: ECN + DSCP + 4-Bit Pad + Flow Label (4 Bytes)
• 01: ECN + 2-Bit Pad + Flow Label (3 Bytes), DSCP wird weggelassen.
• 10: ECN + DSCP (1 Byte), Flow Label wird weggelassen.
• 11: Traffic Class und Flow Label werden weggelassen.

NH: Next Header (Nächster Header):

• 0: Volle 8 Bits für Next Header werden inline transportiert.
• 1: Das Next Header-Feld wird komprimiert und der nächste Header wird unter Verwendung von LOWPAN_NHC codiert, was in Abschnitt 4.1 diskutiert wird.

HLIM: Hop Limit:

• 00: Das Hop Limit-Feld wird inline transportiert.
• 01: Das Hop Limit-Feld wird komprimiert und das Hop Limit ist 1.
• 10: Das Hop Limit-Feld wird komprimiert und das Hop Limit ist 64.
• 11: Das Hop Limit-Feld wird komprimiert und das Hop Limit ist 255.

CID: Context Identifier Extension (Kontextidentifikator-Erweiterung):

• 0: Keine zusätzliche 8-Bit-Kontextidentifikator-Erweiterung wird verwendet. Wenn kontextbasierte Kompression entweder in Source Address Compression (SAC) oder Destination Address Compression (DAC) spezifiziert ist, wird Kontext 0 verwendet.
• 1: Ein zusätzliches 8-Bit-Kontextidentifikator-Erweiterungsfeld folgt unmittelbar auf das Destination Address Mode (DAM)-Feld.

SAC: Source Address Compression (Quelladresskompression)

• 0: Quelladresskompression verwendet zustandslose Kompression.
• 1: Quelladresskompression verwendet zustandsbehaftete, kontextbasierte Kompression.

SAM: Source Address Mode (Quelladressmodus):

Wenn SAC=0:

• 00: 128 Bits. Die volle Adresse wird inline transportiert.
• 01: 64 Bits. Die ersten 64 Bits der Adresse werden weggelassen. Der Wert dieser Bits ist das mit Nullen aufgefüllte link-lokale Präfix. Die verbleibenden 64 Bits werden inline transportiert.
• 10: 16 Bits. Die ersten 112 Bits der Adresse werden weggelassen. Der Wert der ersten 64 Bits ist das mit Nullen aufgefüllte link-lokale Präfix. Die folgenden 64 Bits sind 0000:00ff:fe00:XXXX, wobei XXXX die 16 Bits sind, die inline transportiert werden.
• 11: 0 Bits. Die Adresse wird vollständig weggelassen. Die ersten 64 Bits der Adresse sind das mit Nullen aufgefüllte link-lokale Präfix. Die verbleibenden 64 Bits werden aus dem kapselnden Header (z. B. 802.15.4 oder IPv6-Quelladresse) berechnet, wie in Abschnitt 3.2.2 spezifiziert.

Wenn SAC=1:

• 00: Die UNSPECIFIED (unspezifizierte) Adresse, ::
• 01: 64 Bits. Die Adresse wird unter Verwendung von Kontextinformationen und den 64 Bits, die inline transportiert werden, abgeleitet. Bits, die durch Kontextinformationen abgedeckt sind, werden immer verwendet. Alle IID-Bits, die nicht durch Kontextinformationen abgedeckt sind, werden direkt aus den entsprechenden Bits übernommen, die inline transportiert werden. Alle verbleibenden Bits sind Null.
• 10: 16 Bits. Die Adresse wird unter Verwendung von Kontextinformationen und den 16 Bits, die inline transportiert werden, abgeleitet. Bits, die durch Kontextinformationen abgedeckt sind, werden immer verwendet. Alle IID-Bits, die nicht durch Kontextinformationen abgedeckt sind, werden direkt aus ihren entsprechenden Bits in der 16-Bit-zu-IID-Zuordnung übernommen, gegeben durch 0000:00ff:fe00:XXXX, wobei XXXX die 16 Bits sind, die inline transportiert werden. Alle verbleibenden Bits sind Null.
• 11: 0 Bits. Die Adresse wird vollständig weggelassen und unter Verwendung von Kontextinformationen und dem kapselnden Header (z. B. 802.15.4 oder IPv6-Quelladresse) abgeleitet. Bits, die durch Kontextinformationen abgedeckt sind, werden immer verwendet. Alle IID-Bits, die nicht durch Kontextinformationen abgedeckt sind, werden aus dem kapselnden Header berechnet, wie in Abschnitt 3.2.2 spezifiziert. Alle verbleibenden Bits sind Null.

M: Multicast Compression (Multicast-Kompression)

• 0: Zieladresse ist keine Multicast-Adresse.
• 1: Zieladresse ist eine Multicast-Adresse.

DAC: Destination Address Compression (Zieladresskompression)

• 0: Zieladresskompression verwendet zustandslose Kompression.
• 1: Zieladresskompression verwendet zustandsbehaftete, kontextbasierte Kompression.

DAM: Destination Address Mode (Zieladressmodus):

Wenn M=0 und DAC=0 Dieser Fall entspricht SAC=0, aber für die Zieladresse:

• 00: 128 Bits. Die volle Adresse wird inline transportiert.
• 01: 64 Bits. Die ersten 64 Bits der Adresse werden weggelassen. Der Wert dieser Bits ist das mit Nullen aufgefüllte link-lokale Präfix. Die verbleibenden 64 Bits werden inline transportiert.
• 10: 16 Bits. Die ersten 112 Bits der Adresse werden weggelassen. Der Wert der ersten 64 Bits ist das mit Nullen aufgefüllte link-lokale Präfix. Die folgenden 64 Bits sind 0000:00ff:fe00:XXXX, wobei XXXX die 16 Bits sind, die inline transportiert werden.
• 11: 0 Bits. Die Adresse wird vollständig weggelassen. Die ersten 64 Bits der Adresse sind das mit Nullen aufgefüllte link-lokale Präfix. Die verbleibenden 64 Bits werden aus dem kapselnden Header (z. B. 802.15.4 oder IPv6-Zieladresse) berechnet, wie in Abschnitt 3.2.2 spezifiziert.

Wenn M=0 und DAC=1:

• 00: Reserviert.
• 01: 64 Bits. Die Adresse wird unter Verwendung von Kontextinformationen und den 64 Bits, die inline transportiert werden, abgeleitet. Bits, die durch Kontextinformationen abgedeckt sind, werden immer verwendet. Alle IID-Bits, die nicht durch Kontextinformationen abgedeckt sind, werden direkt aus den entsprechenden Bits übernommen, die inline transportiert werden. Alle verbleibenden Bits sind Null.
• 10: 16 Bits. Die Adresse wird unter Verwendung von Kontextinformationen und den 16 Bits, die inline transportiert werden, abgeleitet. Bits, die durch Kontextinformationen abgedeckt sind, werden immer verwendet. Alle IID-Bits, die nicht durch Kontextinformationen abgedeckt sind, werden direkt aus ihren entsprechenden Bits in der 16-Bit-zu-IID-Zuordnung übernommen, gegeben durch 0000:00ff:fe00:XXXX, wobei XXXX die 16 Bits sind, die inline transportiert werden. Alle verbleibenden Bits sind Null.
• 11: 0 Bits. Die Adresse wird vollständig weggelassen und unter Verwendung von Kontextinformationen und dem kapselnden Header (z. B. 802.15.4 oder IPv6-Zieladresse) abgeleitet. Bits, die durch Kontextinformationen abgedeckt sind, werden immer verwendet. Alle IID-Bits, die nicht durch Kontextinformationen abgedeckt sind, werden aus dem kapselnden Header berechnet, wie in Abschnitt 3.2.2 spezifiziert. Alle verbleibenden Bits sind Null.

Wenn M=1 und DAC=0:

• 00: 128 Bits. Die volle Adresse wird inline transportiert.
• 01: 48 Bits. Die Adresse hat die Form ffXX::00XX:XXXX:XXXX.
• 10: 32 Bits. Die Adresse hat die Form ffXX::00XX:XXXX.
• 11: 8 Bits. Die Adresse hat die Form ff02::00XX.

Wenn M=1 und DAC=1:

• 00: 48 Bits. Dieses Format ist so konzipiert, dass es Unicast-Prefix-basierten IPv6-Multicast-Adressen entspricht, wie in [RFC3306] und [RFC3956] definiert. Die Multicast-Adresse hat die Form ffXX:XXLL:PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. wobei die X die Nibbles sind, die inline transportiert werden, in der Reihenfolge, in der sie in diesem Format erscheinen. P bezeichnet Nibbles, die zur Codierung des Präfixes selbst verwendet werden. L bezeichnet Nibbles, die zur Codierung der Präfixlänge verwendet werden. Die Präfixinformationen P und L werden aus dem angegebenen Kontext entnommen.
• 01: reserviert
• 10: reserviert
• 11: reserviert

3.1.2. Kontextidentifikator-Erweiterung

Diese Spezifikation erwartet, dass ein konzeptioneller Kontext zwischen dem Knoten, der ein Paket komprimiert, und dem/den Knoten, der/die es expandieren muss/müssen, geteilt wird. Wie die Kontexte geteilt und gepflegt werden, liegt außerhalb des Geltungsbereichs. Welche Informationen in einer Kontextinformation enthalten sind, liegt außerhalb des Geltungsbereichs. Aktionen als Reaktion auf unbekannte und/oder ungültige Kontexte liegen außerhalb des Geltungsbereichs. Die Spezifikation ermöglicht es einem Knoten, bis zu 16 Kontexte zu verwenden. Der zur Codierung der Quelladresse verwendete Kontext muss nicht derselbe sein wie der zur Codierung der Zieladresse verwendete Kontext.

Wenn das CID-Feld in der LOWPAN_IPHC-Codierung auf '1' gesetzt ist, erweitert ein zusätzliches Oktett die LOWPAN_IPHC-Codierung nach den DAM-Bits, aber vor den IPv6-Header-Feldern, die inline transportiert werden. Das zusätzliche Oktett identifiziert das Kontextpaar, das verwendet werden soll, wenn die IPv6-Quell- und/oder Zieladresse komprimiert wird. Der Kontextidentifikator beträgt 4 Bits für jede Adresse und unterstützt bis zu 16 Kontexte. Kontext 0 ist der Standardkontext. Die Codierung ist in Abbildung 3 dargestellt.

    0   1   2   3   4   5   6   7
  +---+---+---+---+---+---+---+---+
  |      SCI      |      DCI      |
  +---+---+---+---+---+---+---+---+

   Abbildung 3: LOWPAN_IPHC-Codierung

SCI: Source Context Identifier (Quellkontext-Identifikator). Identifiziert das Präfix, das verwendet wird, wenn die IPv6-Quelladresse zustandsbehaftet komprimiert wird.

DCI: Destination Context Identifier (Zielkontext-Identifikator). Identifiziert das Präfix, das verwendet wird, wenn die IPv6-Zieladresse zustandsbehaftet komprimiert wird.