Zum Hauptinhalt springen

3.2. IPv6-Header-Codierung

Felder, die inline (ganz oder teilweise) transportiert werden, erscheinen in derselben Reihenfolge wie im IPv6-Header-Format [RFC2460]. Das Version-Feld wird immer weggelassen. Unicast-IPv6-Adressen können auf 64 oder 16 Bits komprimiert oder vollständig weggelassen werden. Multicast-IPv6-Adressen können auf 8, 32 oder 48 Bits komprimiert werden. Das IPv6 Payload Length-Feld MUSS (MUST) immer weggelassen und von den unteren Schichten unter Verwendung des 6LoWPAN-Fragmentierungsheaders oder des IEEE 802.15.4-Headers abgeleitet werden.

3.2.1. Kompression von Traffic Class und Flow Label​

Das Traffic Class-Feld im IPv6-Header umfasst 6 Bits der Diffserv-Erweiterung [RFC2474] und 2 Bits der Explicit Congestion Notification (ECN) [RFC3168]. Das TF-Feld in der LOWPAN_IPHC-Codierung gibt an, ob die Traffic Class und das Flow Label inline im komprimierten IPv6-Header transportiert werden. Wenn das Flow Label enthalten ist, während die Traffic Class komprimiert ist, werden zusätzliche 4 Bits eingefügt, um die Byte-Ausrichtung beizubehalten. Zwei der 4 Bits enthalten die ECN-Bits aus dem Traffic Class-Feld.

Um sicherzustellen, dass die ECN-Bits bei allen Codierungen, die sie enthalten, an derselben Stelle erscheinen, wird das Traffic Class-Feld im komprimierten IPv6-Header um 2 Bits nach rechts rotiert. Die Codierungen sind unten dargestellt:

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|   DSCP    |  rsv  |             Flow Label                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Abbildung 4: TF = 00: Traffic Class und Flow Label inline transportiert

                     1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|rsv|             Flow Label                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Abbildung 5: TF = 01: Flow Label inline transportiert

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN|   DSCP    |
+-+-+-+-+-+-+-+-+

        Abbildung 6: TF = 10: Traffic Class inline transportiert

3.2.2. Ableitung von IIDs aus dem kapselnden Header​

LOWPAN_IPHC lässt die IIDs von Quell- oder Zieladressen weg, wenn SAM = 3 bzw. DAM = 3 ist. In diesem Modus wird die IID aus dem kapselnden Header abgeleitet. Wenn der kapselnde Header IPv6-Adressen trägt, werden Bits für die Quell- und Zieladressen aus den Quell- und Zieladressen des kapselnden IPv6-Headers kopiert.

Der Rest dieses Abschnitts definiert die Zuordnung von IEEE 802.15.4 [IEEE802.15.4] Link-Layer-Adressen zu IIDs sowohl für kurze als auch für erweiterte IEEE 802.15.4-Adressen. IID-Bits, die nicht durch die Kontextinformationen abgedeckt sind, KÖNNEN (MAY) weggelassen werden, wenn sie mit der Link-Layer-Adresszuordnung übereinstimmen, und DÜRFEN NICHT (MUST NOT) weggelassen werden, wenn sie dies nicht tun.

Eine erweiterte IEEE 802.15.4-Adresse hat die Form einer IEEE EUI-64-Adresse. Das Generieren einer IID aus einer erweiterten Adresse ist identisch mit dem in Anhang A von [RFC4291] definierten Verfahren. Die einzige Änderung, die erforderlich ist, um einen IEEE EUI-64-Identifikator in einen Interface Identifier umzuwandeln, besteht darin, das Universal/Local-Bit zu invertieren.

Eine kurze IEEE 802.15.4-Adresse ist 16 Bits lang. Kurze Adressen werden in den eingeschränkten Raum der IEEE EUI-64-Adressen abgebildet, indem die mittleren 16 Bits auf 0xfffe gesetzt werden, die unteren 16 Bits auf die kurze Adresse und alle anderen Bits auf Null. Infolgedessen hat eine aus einer kurzen Adresse generierte IID die Form:

0000:00ff:fe00:XXXX

wobei XXXX die kurze Adresse trägt. Das Universal/Local-Bit ist Null, um lokalen Geltungsbereich (Scope) anzuzeigen.

Diese Zuordnung für Nicht-EUI-64-Identifikatoren unterscheidet sich von der in Anhang A von [RFC4291] vorgestellten. Die Verwendung des eingeschränkten Raums stellt sicher, dass keine Überlappung mit IIDs besteht, die aus uneingeschränkten IEEE EUI-64-Adressen generiert wurden. Außerdem hilft das Einfügen von 0xfffe in die Mitte der IID, Überlappungen mit anderen lokal verwalteten IIDs zu vermeiden.

Diese Zuordnung von einer kurzen IEEE 802.15.4-Adresse zu 64-Bit-IIDs wird auch verwendet, um jeden Teil einer IID zu rekonstruieren, der nicht durch Kontextinformationen abgedeckt ist.

3.2.3. Zustandslose Multicast-Adresskompression​

LOWPAN_IPHC unterstützt zustandslose Kompression von Multicast-Adressen, wenn M = 1 und DAC = 0. Eine IPv6-Multicast-Adresse kann unter Verwendung zustandsloser Kompression auf 48, 32 oder 8 Bits komprimiert werden. Das Format unterstützt die Kompression der Solicited-Node Multicast Address (ff02::1:ffXX:XXXX) sowie jeder IPv6-Multicast-Adresse, bei der die oberen Bits des Multicast-Gruppenidentifikators Null sind. Die 8-Bit-komprimierte Form trägt nur die niedrigstwertigen Bits des Multicast-Gruppenidentifikators. Die 48- und 32-Bit-komprimierten Formen tragen den Multicast-Scope und die Flags inline, zusätzlich zu den niedrigstwertigen Bits des Multicast-Gruppenidentifikators.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope |              Group Identifier                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Group Identifier       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Abbildung 7: DAM = 01. 48-Bit-komprimierte Multicast-Adresse
                     (ffFS::00GG:GGGG:GGGG)

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope |              Group Identifier                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Abbildung 8: DAM = 10. 32-Bit-komprimierte Multicast-Adresse
                        (ffFS::00GG:GGGG)

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Group ID    |
+-+-+-+-+-+-+-+-+

    Abbildung 9: DAM = 11. 8-Bit-komprimierte Multicast-Adresse (ff02::GG)

3.2.4. Zustandsbehaftete Multicast-Adresskompression​

LOWPAN_IPHC unterstützt zustandsbehaftete Kompression von Multicast-Adressen, wenn M = 1 und DAC = 1. Dieses Dokument definiert derzeit DAM = 00: kontextbasierte Kompression von Unicast-Prefix-basierten IPv6-Multicast-Adressen [RFC3306][RFC3956]. Insbesondere können die Präfixlänge und das Netzwerkpräfix aus einem Kontext entnommen werden. Infolgedessen kann LOWPAN_IPHC eine Unicast-Prefix-basierte IPv6-Multicast-Adresse auf 6 Oktette komprimieren, indem nur die 4-Bit Flags, 4-Bit Scope, 8-Bit Rendezvous Point Interface ID (RIID) und 32-Bit Group Identifier inline transportiert werden.

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Rsvd / RIID   |       Group Identifier        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Group Identifier       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Abbildung 10: DAM = 00.  Unicast-Prefix-basierte IPv6-
                       Multicast-Adresskompression

Beachten Sie, dass das Reserved-Feld die reservierten Bits aus dem Multicast-Adressformat tragen MUSS (MUST), wie in [RFC3306] beschrieben. Wenn ein Rendezvous Point in der Multicast-Adresse codiert ist, wie in [RFC3956] beschrieben, trägt das Reserved-Feld die RIID-Bits inline.

Letztes Update am