Zum Hauptinhalt springen

10. Header Compression (Header-Komprimierung)

Es gibt umfangreiche veröffentlichte und laufende Standardisierungsarbeiten zur Header-Komprimierung. Die Header-Komprimierung für IPv6 über IEEE 802.15.4 unterliegt jedoch anderen Einschränkungen, die im Folgenden zusammengefasst werden:

  • Bestehende Arbeiten gehen von vielen Datenströmen (Flows) zwischen beliebigen zwei Geräten aus. Hier gehen wir von einem sehr einfachen und kontextarmen (Low-Context) Header-Komprimierungsstil aus. Obwohl dieser unabhängig von Datenströmen funktioniert (es kann mehrere geben), verwendet er keinen für einen bestimmten Datenstrom spezifischen Kontext. Daher kann er nicht den Komprimierungsgrad erreichen, den Schemata erzielen, die für jeden zu komprimierenden Datenstrom einen separaten Kontext aufbauen.

  • Angesichts der sehr begrenzten Paketgröße ist eine Integration der Schicht-2- und Schicht-3-Komprimierung sehr wünschenswert, was traditionell nicht gemacht wurde (obwohl sich dies jetzt durch die ROHC (RObust Header Compression, Robuste Header-Komprimierung)-Arbeitsgruppe ändert).

  • Es wird erwartet, dass IEEE 802.15.4-Geräte in Mehrsprung-Netzwerken (Multi-Hop Networks) eingesetzt werden. Die Header-Komprimierung in Mesh-Netzwerken unterscheidet sich jedoch vom üblichen Punkt-zu-Punkt-Verbindungsszenario, in dem Kompressor und Dekompressor direkt und exklusiv miteinander kommunizieren. In IEEE 802.15.4-Netzwerken ist es sehr wünschenswert, dass Geräte header-komprimierte Pakete über beliebige ihrer Nachbarn senden können, mit möglichst wenig vorherigem Kontextaufbau.

Alle neuen Paketformate, die für die Header-Komprimierung benötigt werden, verwenden das in Abschnitt 5 definierte Basispaketformat durch Verwendung verschiedener Dispatch-Werte (Dispatch Values).

Header-Komprimierung kann dazu führen, dass Ausrichtungen nicht auf Oktett-Grenzen fallen. Da Hardware typischerweise keine Daten in Einheiten kleiner als ein Oktett übertragen kann, muss Auffüllung (Padding) verwendet werden. Das Auffüllen erfolgt wie folgt: Zunächst wird die gesamte zusammenhängende Reihe komprimierter Header angeordnet (dieses Dokument definiert nur IPv6- und UDP-Header-Komprimierungsschemata, aber andere Schemata können anderswo definiert werden). Dann werden nach Bedarf Null-Bits hinzugefügt, um auf Oktett-Grenzen auszurichten. Dies kompensiert jede potenzielle Fehlausrichtung durch Header-Komprimierung, sodass nachfolgende Felder (z. B. unkomprimierte Header oder Datennutzlast) an Oktett-Grenzen beginnen und normal fortfahren.

10.1. Encoding of IPv6 Header Fields (Kodierung von IPv6-Header-Feldern)​

Durch den Beitritt zum selben 6LoWPAN-Netzwerk teilen Geräte einen gewissen Zustand. Dies ermöglicht die Komprimierung von Headern, ohne explizit einen Komprimierungskontextzustand aufbauen zu müssen. Daher behält die 6LoWPAN-Header-Komprimierung keinen Datenstromzustand; stattdessen stützt sie sich auf Informationen, die mit dem gesamten Link zusammenhängen. Die folgenden IPv6-Header-Werte werden in 6LoWPAN-Netzwerken als häufig erwartet, daher ist der HC1-Header so konstruiert, dass er sie von Anfang an effizient komprimiert:

  • Version ist IPv6
  • Sowohl IPv6-Quell- als auch Zieladresse sind verbindungslokal (Link Local)
  • Der IPv6-Schnittstellenidentifikator (untere 64 Bits) der Quell- oder Zieladresse kann aus der Schicht-2-Quell- und Zieladresse abgeleitet werden (dies ist natürlich nur für Schnittstellenidentifikatoren möglich, die aus der zugrunde liegenden 802.15.4-MAC-Adresse abgeleitet wurden)
  • Die Paketlänge kann aus Schicht 2 (dem „Frame Length"-Feld in der IEEE 802.15.4-PPDU) oder dem „datagram_size"-Feld im Fragmentierungs-Header (falls vorhanden) abgeleitet werden
  • Traffic Class und Flow Label sind beide null
  • Next Header ist UDP, ICMP oder TCP

Das einzige Feld im IPv6-Header, das immer vollständig übertragen werden muss, ist Hop Limit (Sprungzähler, 8 Bit). Je nachdem, wie gut ein Paket diesem häufigen Fall entspricht, können verschiedene Felder möglicherweise nicht komprimiert werden und müssen daher „inline" (In-Line) übertragen werden (Abschnitt 10.3.1). Dieser häufige IPv6-Header (wie oben beschrieben) kann auf 2 Oktette komprimiert werden (1 Oktett für die HC1-Kodierung, 1 Oktett für Hop Limit), anstatt 40 Oktette.

Ein solches Paket kann im LOWPAN_HC1-Format komprimiert werden, indem der Dispatch-Wert von LOWPAN_HC1 verwendet wird, gefolgt vom LOWPAN_HC1-Header-„HC1-Kodierungs"-Feld (8 Bit), das die verschiedenen unten gezeigten Kombinationen kodiert.

                       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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 9: LOWPAN_HC1 (Häufige komprimierte Header-Kodierung)

Die durch die „HC1-Kodierung" kodierten Adressfelder werden wie folgt interpretiert:

  • PI: Präfix inline übertragen (Prefix carried in-line)
  • PC: Präfix komprimiert (Prefix compressed, verbindungslokales Präfix angenommen)
  • II: Schnittstellenidentifikator inline übertragen (Interface identifier carried in-line)
  • IC: Schnittstellenidentifikator weggelassen (Interface identifier elided, kann aus der entsprechenden Verbindungsschichtadresse abgeleitet werden)

HC1-Kodierung (von Bit 0 bis Bit 7):

IPv6-Quelladresse (Bits 0 und 1):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

IPv6-Zieladresse (Bits 2 und 3):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

Traffic Class und Flow Label (Bit 4):

  • 0: Unkomprimiert; vollständige 8-Bit-Traffic-Class und 20-Bit-Flow-Label werden gesendet
  • 1: Traffic Class und Flow Label sind null

Next Header (Bits 5 und 6):

  • 00: Unkomprimiert; vollständige 8 Bits werden gesendet
  • 01: UDP
  • 10: ICMP
  • 11: TCP

HC2-Kodierung (Bit 7):

  • 0: Keine weiteren Header-Komprimierungsbits
  • 1: Auf die HC1-Kodierung folgen weitere Header-Komprimierungsbits gemäß dem HC2-Kodierungsformat. Bits 5 und 6 bestimmen, welche möglichen HC2-Kodierungen gelten (z. B. UDP-, ICMP- oder TCP-Kodierung).

10.2. Encoding of UDP Header Fields (Kodierung von UDP-Header-Feldern)​

Die Bits 5 und 6 von LOWPAN_HC1 ermöglichen die Komprimierung des Next-Header-Feldes im IPv6-Header (für UDP, TCP und ICMP). Jeder dieser Protokoll-Header kann weiter komprimiert werden. Dieser Abschnitt erklärt, wie der UDP-Header selbst komprimiert wird. Die HC2-Kodierung in diesem Abschnitt ist die HC_UDP-Kodierung, die nur gilt, wenn Bits 5 und 6 in HC1 anzeigen, dass das Protokoll nach dem IPv6-Header UDP ist.

Die HC_UDP-Kodierung ermöglicht die Komprimierung folgender Felder im UDP-Header: Quellport (Source Port), Zielport (Destination Port) und Länge (Length). Das Prüfsummenfeld (Checksum) des UDP-Headers wird nicht komprimiert und daher vollständig übertragen. Das unten definierte Schema ermöglicht die Komprimierung des UDP-Headers auf 4 Oktette statt der ursprünglichen 8 Oktette.

Das einzige UDP-Header-Feld, dessen Wert aus anderweitig verfügbaren Informationen abgeleitet werden kann, ist Length. Alle anderen Felder müssen vollständig oder in teilweise komprimierter Form inline übertragen werden (Abschnitt 10.3.2).

                       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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 10: HC_UDP (Häufige komprimierte UDP-Header-Kodierung)

„HC_UDP-Kodierung" für UDP (von Bit 0 bis Bit 7):

UDP-Quellport (Bit 0):

  • 0: Unkomprimiert, inline übertragen
  • 1: Auf 4 Bits komprimiert. Der tatsächliche 16-Bit-Quellport wird berechnet als: P + short_port-Wert. Der Wert von P ist die Zahl 61616 (0xF0B0). short_port wird als 4-Bit-Wert inline übertragen

UDP-Zielport (Bit 1):

  • 0: Unkomprimiert, inline übertragen
  • 1: Auf 4 Bits komprimiert. Der tatsächliche 16-Bit-Zielport wird berechnet als: P + short_port-Wert. Der Wert von P ist die Zahl 61616 (0xF0B0). short_port wird als 4-Bit-Wert inline übertragen

Length (Bit 2):

  • 0: Unkomprimiert, inline übertragen
  • 1: Komprimiert, die Länge wird aus den IPv6-Header-Längeninformationen berechnet. Der Wert des UDP-Längenfeldes entspricht der Payload Length des IPv6-Headers abzüglich der Länge aller Erweiterungs-Header, die zwischen IPv6-Header und UDP-Header vorhanden sind

Reserviert (Bits 3 bis 7)

10.3. Non-Compressed Fields (Unkomprimierte Felder)​

10.3.1. Non-Compressed IPv6 Fields (Unkomprimierte IPv6-Felder)​

Dieses Schema ermöglicht die Komprimierung des IPv6-Headers in unterschiedlichem Maße. Daher müssen nur die unkomprimierten Felder gesendet werden, nicht der gesamte (Standard-)IPv6-Header. Nachfolgende Header (angegeben durch das Next-Header-Feld im ursprünglichen IPv6-Header) folgen unmittelbar auf die unkomprimierten IPv6-Felder.

Das unkomprimierte IPv6-Feld, das immer vorhanden sein MUSS (MUST), ist Hop Limit (8 Bit). Dieses Feld MUSS (MUST) immer auf die Kodierungsfelder folgen (z. B. die „HC1-Kodierung" wie in Abbildung 9 gezeigt, möglicherweise einschließlich anderer zukünftiger Kodierungsfelder). Andere unkomprimierte Felder MÜSSEN (MUST) auf Hop Limit in der durch die „HC1-Kodierung" implizierten Reihenfolge folgen, genau in der oben (Abschnitt 10.1) gezeigten Reihenfolge: Quelladresspräfix (64 Bit) und/oder Schnittstellenidentifikator (64 Bit), Zieladresspräfix (64 Bit) und/oder Schnittstellenidentifikator (64 Bit), Traffic Class (8 Bit), Flow Label (20 Bit) und Next Header (8 Bit). Der tatsächliche nächste Header (z. B. UDP, TCP, ICMP usw.) folgt auf die unkomprimierten Felder.

10.3.2. Non-Compressed and Partially Compressed UDP Fields (Unkomprimierte und teilweise komprimierte UDP-Felder)​

Dieses Schema ermöglicht die Komprimierung des UDP-Headers in unterschiedlichem Maße. Daher müssen nur die unkomprimierten oder teilweise komprimierten Felder gesendet werden, nicht der gesamte (Standard-)UDP-Header.

Unkomprimierte oder teilweise komprimierte Felder im UDP-Header MÜSSEN (MUST) immer auf den IPv6-Header und alle zugehörigen Inline-Felder folgen. Alle vorhandenen UDP-Header-Inline-Felder MÜSSEN (MUST) in derselben Reihenfolge erscheinen, in der die entsprechenden Felder im normalen UDP-Header [RFC0768] erscheinen, also: Quellport, Zielport, Länge und Prüfsumme. Wenn der Quell- oder Zielport in der „short_port"-Notation (wie im komprimierten UDP-Header angegeben) dargestellt wird, nimmt die Inline-Portnummer 4 Bits statt 16 Bits ein.

Letztes Update am