1. Einführung
1. Einführung
Der [IEEE802.15.4]-Standard spezifiziert eine MTU von 127 Bytes, was etwa 80 Oktette tatsächlicher Media Access Control (MAC)-Nutzlast bei aktivierter Sicherheit ergibt, auf einer drahtlosen Verbindung mit einem Verbindungsdurchsatz von 250 kbps oder weniger. Das 6LoWPAN-Anpassungsformat [RFC4944] wurde spezifiziert, um IPv6-Datagramme über solche eingeschränkten Verbindungen zu transportieren, unter Berücksichtigung begrenzter Bandbreiten-, Speicher- oder Energieressourcen, die in Anwendungen wie drahtlosen Sensornetzwerken erwartet werden. [RFC4944] definiert einen Mesh Addressing Header zur Unterstützung von Sub-IP-Weiterleitung, einen Fragmentierungs-Header zur Unterstützung der IPv6-Mindest-MTU-Anforderung [RFC2460] und zustandslose Header-Kompression für IPv6-Datagramme (LOWPAN_HC1 und LOWPAN_HC2), um die relativ großen IPv6- und UDP-Header auf (im besten Fall) mehrere Bytes zu reduzieren.
LOWPAN_HC1 und LOWPAN_HC2 sind für die meisten praktischen Anwendungen von IPv6 in 6LoWPANs unzureichend. LOWPAN_HC1 ist am effektivsten für link-lokale Unicast-Kommunikation, bei der IPv6-Adressen das link-lokale Präfix und einen Interface Identifier (IID) tragen, der direkt von IEEE 802.15.4-Adressen abgeleitet ist. In diesem Fall können beide Adressen vollständig weggelassen werden. Obwohl link-lokale Adressen jedoch häufig für lokale Protokollinteraktionen wie IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315] oder Routing-Protokolle verwendet werden, werden sie normalerweise nicht für Datenverkehr der Anwendungsschicht verwendet, sodass der tatsächliche Wert dieses Kompressionsmechanismus begrenzt ist.
Routbare Adressen müssen verwendet werden, wenn mit Geräten außerhalb des 6LoWPAN oder in einer Route-Over-Konfiguration kommuniziert wird, bei der IP-Weiterleitung innerhalb des 6LoWPAN stattfindet. Für routbare Adressen erfordert LOWPAN_HC1, dass sowohl IPv6-Quell- als auch Zieladressen das Präfix inline (in der Zeile) tragen. In Fällen, in denen der Mesh Addressing Header nicht verwendet wird, muss die IID einer routbaren Adresse inline transportiert werden. LOWPAN_HC1 benötigt jedoch 64 Bits für die IID, wenn sie inline transportiert wird, und kann nicht verkürzt werden, selbst wenn sie von der 16-Bit-Kurzadresse IEEE 802.15.4 abgeleitet ist. Wenn das Ziel eine IPv6-Multicast-Adresse ist, erfordert LOWPAN_HC1, dass die vollständige 128-Bit-Adresse inline transportiert wird.
Infolgedessen definiert dieses Dokument ein Codierungsformat, LOWPAN_IPHC, für eine effektive Kompression von Unique Local, Global und Multicast IPv6-Adressen basierend auf einem gemeinsamen Zustand innerhalb von Kontexten. Darüber hinaus führt dieses Dokument auch eine Reihe zusätzlicher Verbesserungen gegenüber dem in [RFC4944] definierten Header-Kompressionsformat ein.
LOWPAN_IPHC ermöglicht die Kompression einiger häufig verwendeter IPv6 Hop Limit-Werte. Wenn das 6LoWPAN ein Mesh-Under-Stub ist, reichen ein Hop Limit von 1 für eingehenden und ein Standardwert wie 64 für ausgehenden Datenverkehr normalerweise für Datenverkehr der Anwendungsschicht aus. Darüber hinaus wird ein Hop Limit-Wert von 255 häufig verwendet, um zu überprüfen, ob eine Kommunikation über einen einzigen Hop erfolgt. Diese Spezifikation ermöglicht die Kompression des IPv6 Hop Limit-Feldes in diesen häufigen Fällen, während LOWPAN_HC1 dies nicht tut.
Dieses Dokument definiert auch LOWPAN_NHC, ein Codierungsformat für beliebige Next Header. LOWPAN_IPHC gibt an, ob der folgende Header unter Verwendung von LOWPAN_NHC codiert ist. Wenn dies der Fall ist, beginnen die Bits unmittelbar nach dem komprimierten IPv6-Header mit der LOWPAN_NHC-Codierung. Im Gegensatz dazu könnte LOWPAN_HC1 erweitert werden, um die Kompression von Next Headern unter Verwendung von LOWPAN_HC2 zu unterstützen, jedoch nur für UDP, TCP und ICMPv6. Darüber hinaus befindet sich das LOWPAN_HC2-Oktett zwischen dem LOWPAN_HC1-Oktett und unkomprimierten IPv6-Header-Feldern. Diese Spezifikation verschiebt die Next Header-Codierungsbits so, dass sie allen IPv6-bezogenen Bits folgen, was eine ordnungsgemäß geschichtete Struktur und direkte Unterstützung für IPv6-Erweiterungsheader ermöglicht.
Unter Verwendung von LOWPAN_NHC definiert dieses Dokument einen Kompressionsmechanismus für UDP. Während [RFC4944] einen Kompressionsmechanismus für UDP definiert, ermöglicht dieser Mechanismus keine Prüfsummenkompression, wenn dies durch zusätzliche Mechanismen der oberen Schicht wie Upper-Layer Message Integrity Check (MIC) möglich gemacht wird. Diese Spezifikation fügt die Fähigkeit hinzu, die UDP-Prüfsumme über das 6LoWPAN wegzulassen, was das Einsparen von zwei weiteren Oktetten ermöglicht.
Außerdem definiert dieses Dokument unter Verwendung von LOWPAN_NHC Codierungsformate für IPv6-in-IPv6-Kapselung sowie für IPv6-Erweiterungsheader. Mit LOWPAN_HC1 und LOWPAN_HC2 können Ketten von Next Headern nicht effizient codiert werden.
1.1 Anforderungssprache
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in RFC 2119 [RFC2119] beschrieben.