5. 6LoWPAN Routing Requirements (6LoWPAN-Routing-Anforderungen)

Dieser Abschnitt definiert eine Liste von Anforderungen für das 6LoWPAN-Routing. Eine wichtige Designeigenschaft, die spezifisch für Low-Power-Netzwerke ist, besteht darin, dass LoWPANs mehrere Gerätetypen und Rollen unterstützen müssen, wie zum Beispiel:

• Host-Knoten, die ihre Energie aus Primärbatterien beziehen oder Energy Harvesting verwenden (manchmal als "leistungsbeschränkte Knoten" bezeichnet)
• Netzgespeiste Host-Knoten (ein Beispiel für das, was wir "leistungsreiche Knoten" nennen)
• Leistungsreiche (aber nicht unbedingt netzgespeiste) Hochleistungs-Gateways
• Knoten mit verschiedenen Funktionalitäten (Datenaggregat oren, Relays, lokale Manager/Koordinatoren usw.)

Aufgrund dieser unterschiedlichen Gerätetypen und Rollen müssen LoWPANs die folgenden zwei Hauptattribute berücksichtigen:

• Energieeinsparung: Einige Geräte sind netzgespeist, aber viele sind batteriebetrieben und müssen mehrere Monate bis zu einigen Jahren mit einer einzigen AA-Batterie halten. Viele Geräte sind die meiste Zeit netzgespeist, müssen aber dennoch für möglicherweise längere Zeiträume (z.B. auf einer Baustelle, bevor die Gebäudestromversorgung zum ersten Mal eingeschaltet wird) mit Batterien funktionieren.

• Niedrige Leistung: Winzige Geräte, kleine Speichergrößen, leistungsschwache Prozessoren, geringe Bandbreite, hohe Verlustraten usw.

Diese grundlegenden Attribute von LoWPANs beeinflussen das Design von Routing-Lösungen. Ob bestehende Routing-Spezifikationen vereinfacht und modifiziert werden oder neue Lösungen eingeführt werden, um den Low-Power-Anforderungen von LoWPANs gerecht zu werden, sie müssen die unten beschriebenen Anforderungen erfüllen.

5.1. Support of 6LoWPAN Device Properties (Unterstützung von 6LoWPAN-Geräteeigenschaften)

Die in diesem Abschnitt aufgeführten allgemeinen Ziele sollten von 6LoWPAN-Routing-Protokollen erfüllt werden. Die Bedeutung jeder Anforderung hängt davon ab, auf welchem Knotentyp das Protokoll ausgeführt wird und welche Rolle der Knoten hat. Die folgenden Anforderungen berücksichtigen das Vorhandensein batteriebetriebener Knoten in LoWPANs.

[R01] 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) eine Implementierung mit kleiner Codegröße ermöglichen und einen niedrigen Routing-Zustand erfordern, um der typischen 6LoWPAN-Knotenkapazität zu entsprechen. Im Allgemeinen ist die Codegröße durch die verfügbare Flash-Speichergröße begrenzt, und die Routing-Tabelle ist durch die RAM-Größe begrenzt, möglicherweise auf weniger als 32 Einträge beschränkt.

Die RAM-Größe von LoWPAN-Knoten liegt häufig zwischen 4 KB und 10 KB (mindestens 2 KB), und der Programm-Flash-Speicher besteht normalerweise aus 48 KB bis 128 KB. (Beispielsweise hat MICAz auf dem aktuellen Markt 128 KB Programm-Flash, 4 KB EEPROM und 512 KB externen Flash-ROM; TIP700CM hat 48 KB Programm-Flash, 10 KB RAM und 1 MB externen Flash-ROM.)

Aufgrund dieser Hardware-Einschränkungen SOLLTE (SHOULD) der Code in eine kleine Speichergröße passen -- nicht mehr als 48 KB bis 128 KB Flash-Speicher, einschließlich mindestens einiger Dutzend KB Anwendungscodegröße. (Als allgemeine Beobachtung kann ein Routing-Protokoll mit geringer Komplexität dazu beitragen, das Ziel der Reduzierung des Stromverbrauchs zu erreichen, die Robustheit zu verbessern, einen niedrigeren Routing-Zustand zu erfordern, einfacher zu analysieren zu sein und möglicherweise weniger anfällig für Sicherheitsangriffe zu sein.)

Darüber hinaus SOLLTE (SHOULD) der Betrieb mit begrenzten Mengen an Routing-Zustand (wie Routing-Tabellen und Nachbarlisten) aufrechterhalten werden, da einige typische Speichergrößen das Speichern des Zustands einer großen Anzahl von Knoten ausschließen. Beispielsweise müssen industrielle Überwachungsanwendungen möglicherweise maximal 20 Hops unterstützen [RFC5673]. Kleine Netzwerke können so konzipiert werden, dass sie eine kleinere Anzahl von Hops unterstützen. Während der Bedarf dafür stark von der Netzwerkarchitektur abhängig ist, sollte mindestens ein Betriebsmodus vorhanden sein, der mit 32 oder weniger Weiterleitungseinträgen funktionieren kann.

[R02] 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) einen minimalen Stromverbrauch verursachen, indem sie Kontrollpakete effizient verwenden (z.B. durch Minimierung teurer IP-Multicasts, die Link-Broadcasts an das gesamte LoWPAN verursachen) und durch effizientes Routing von Datenpaketen.

Eine Möglichkeit zur Optimierung der Batterielebensdauer besteht darin, einen minimalen Overhead für Kontrollnachrichten zu erreichen. Im Vergleich zu Funktionen wie Rechenoperationen oder der Aufnahme von Sensorproben ist die Funkkommunikation bei weitem der dominierende Faktor für den Stromverbrauch [Doherty]. Der Stromverbrauch von Übertragung und/oder Empfang hängt linear von der Länge der Dateneinheiten und von der Häufigkeit der Übertragung und des Empfangs der Dateneinheiten ab [Shih].

Der Energieverbrauch von zwei beispielhaften Funkfrequenz (RF)-Controllern für Low-Power-Knoten wird in [Hill] gezeigt. Das TR1000-Funkgerät verbraucht 21 mW beim Senden mit 0,75 mW und 15 mW während des Empfangs (mit einer Empfängerempfindlichkeit von -85 dBm). Der CC1000 verbraucht 31,6 mW beim Senden mit 0,75 mW und 20 mW während des Empfangs (mit einer Empfängerempfindlichkeit von -105 dBm). Die Energieausdauer unter dem Konzept einer idealisierten Energiequelle wird in [Hill] erklärt. Basierend auf der Energie einer idealisierten AA-Batterie kann der CC1000 etwa 4 Tage am Stück senden oder 9 aufeinanderfolgende Tage empfangen. Beachten Sie, dass die Verfügbarkeit für tatsächliche Aufgaben von der Häufigkeit der Kommunikation und anderen Operationen mit niedrigem Duty-Cycle sowie von der Energiekapazität abhängt, die die Batterie bereitstellt.

In einigen Fällen ist der vom Routing-Protokoll eingeführte Overhead groß. [Doherty] berichtet, dass im LEACH-Protokoll, das für hierarchisches Routing verwendet wird, Daten- und Protokollpakete, die in [Heinzelman] vorgeschlagen wurden, 97% der Übertragungsenergie bei einer Rate von 100 Bit pro Sekunde verbrauchen. In Fällen, in denen die Anforderung an den Overhead von Kontrollpaketen nicht so anspruchsvoll ist, spielen Kontrollpakete immer noch eine wichtige Rolle. Für Low-Rate Low-Power Wireless Personal Area Network (LR-WPAN)-Sensordaten verwendet ZigBee (IEEE 802.15.4) AODV-Routing bei der Sensordatenübertragung, die Routing-Protokollpakete verbrauchen etwa 15% der Übertragungsenergie, während der Übertragungsenergieverlust von Datenpaketen etwa 85% beträgt [Doherty]. Daher SOLLTEN (SHOULD) Routing-Protokolle die Verwendung effizienter Routing-Mechanismen und einfacher Austauschprotokoll-Paketformate in Betracht ziehen.

[R03] 6LoWPAN-Routing-Protokoll-Kontrollnachrichten SOLLTEN NICHT (SHOULD NOT) die Größe eines einzelnen IEEE 802.15.4 MAC-Rahmens (maximal 127 Bytes) überschreiten, um die kostspieligen Fragmentierungs- und Reassemblierungskosten zu vermeiden.

Die maximale Paketgröße der physikalischen Schicht eines einzelnen IEEE 802.15.4-Rahmens beträgt 127 Bytes [IEEE802.15.4]. In dem Fall, dass LLC/SNAP den Ethernet-Frame-Typ trägt, benötigt ein 40-Byte-IPv6-Header plus ein UDP-Header 8 Bytes, und somit beträgt die UDP-Nutzlast 74 Bytes. Im Allgemeinen sollten 6LoWPAN-Routing-Protokoll-Kontrollnachrichten, um das Protokoll einfach zu halten und die Fragmentierung und Reassemblierung von Frames zu vermeiden, in begrenzten Mengen gesendet werden und so klein wie möglich sein (SHOULD).

5.2. Support of 6LoWPAN Link Properties (Unterstützung von 6LoWPAN-Link-Eigenschaften)

Aufgrund der topologischen Bedingungen von LoWPANs treten Link-Ausfälle und Übertragungsausfälle häufig auf. Eine erhöhte Zuverlässigkeit von Paketen oder die Verwendung zusätzlicher Backup-Übertragungen kann erforderlich sein. Der Umgang mit unerwarteten Netzwerkbedingungen (wie verlorenen Daten- oder Kontrollpaketen, unidirektionalen Links, variabler Link-Qualität) ist entscheidend für die Gestaltung robuster und zuverlässiger Routing-Protokolle. Routing-Protokolle müssen nicht nur in ihrem Design auf diese Arten von Netzwerkbedingungen aufmerksam sein, sondern müssen auch die von der 6LoWPAN-Interkonnektivität bereitgestellte Funktionalität nutzen, um sicherzustellen, dass Daten zuverlässig von der Quelle zum Ziel geliefert werden können. Die folgenden Anforderungen berücksichtigen die Eigenschaften von Links in LoWPANs.

[R04] Das Design von Routing-Protokollen für LoWPANs MUSS (MUST) die Link-Zuverlässigkeit, die Link-Fehlerrate, die Link-Qualität und die Link-Stabilität für die Routing-Optimierung berücksichtigen.

Drahtlose Low-Power-Links sind von Natur aus unzuverlässig, und es gibt mehrere Gründe für Paketverluste, wie zum Beispiel:

• Viele Geräte befinden sich möglicherweise die meiste Zeit im Schlafmodus, sodass beim Senden von Paketen möglicherweise keine Nachbarn zuhören.
• Umweltfaktoren wie EMI, Hindernisse von Gebäuden und Infrastruktur, Gelände usw. können Übertragungsausfälle verursachen oder symmetrische Links asymmetrisch machen und umgekehrt.
• Überlastung, insbesondere in Sensornetzwerken, wo Multi-Hop-Kommunikation und Routing-Verkehr von vielen Quellen, die zum Gateway konvergieren, die Wahrscheinlichkeit von Überlastung um Knoten in der Nähe des Gateways erhöhen [Shelby-6LoWPAN].
• Das drahtlose Spektrum wird in der Regel gemeinsam genutzt und erfordert eine Koordination zwischen mehreren drahtlosen Technologien, die die ISM-Bänder verwenden, und Netzwerke, die in diesen Bändern betrieben werden, können durch Interferenzen von anderen Netzwerken oder Geräten beeinträchtigt werden.

Daher MUSS (MUST) das Design von 6LoWPAN-Routing-Protokollen die Link-Zuverlässigkeit, die Link-Fehlerrate, die Link-Qualität und die Link-Stabilität für die Routing-Optimierung berücksichtigen.

[R05] Das Design von Routing-Protokollen für LoWPANs MUSS (MUST) asymmetrische Links berücksichtigen.

6LoWPAN-Routing-Protokolle MÜSSEN (MUST) asymmetrische Links unterstützen, da viele praktische Links in LoWPANs asymmetrisch sind (zum Beispiel Links zwischen Low-Power-Sensing-Knoten und leistungsreichen Basisstationen) [Shelby-CoAP]. In solchen Fällen MUSS (MUST) die Auswahl von Routing-Pfaden asymmetrische Links handhaben.

[R06] 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) robust gegenüber dynamischen Verluständerungen in Links sein.

6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) robust gegenüber Variationen im Link-Verlust sein, um die unzuverlässige Natur von IEEE 802.15.4-Links zu handhaben. Typische Links, die mit LoWPAN-Knoten verbunden sind, sind möglicherweise nicht die ganze Zeit verfügbar. Variationen im Link-Verlust können auf verschiedene Faktoren wie Knotenbewegung, Strom-/Batterieerschöpfung, Schlafzyklen, Signalschwund oder verringerte Empfangssignalstärke und Interferenzen zurückzuführen sein und können dazu führen, dass Links für längere Zeiträume deaktiviert werden. Routing-Protokolle SOLLTEN (SHOULD) die Eigenschaften dieser Links auf angemessene Weise handhaben.

[R07] 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) so konzipiert sein, dass sie mögliche Frame-Größen korrekt handhaben.

In einigen LoWPANs ist die maximal mögliche Größe von Kontrollpaketen sehr begrenzt (bis zu 127 Bytes in einem einzelnen IEEE 802.15.4 MAC-Frame), da die MAC-Schicht keine native Fragmentierungs- und Reassemblierungsunterstützung hat.

Die maximale Frame-Größe bedeutet, dass kleine Header und niedriger State-Message-Overhead erzwungen werden MÜSSEN (MUST). Kontrollpakete SOLLTEN (SHOULD) klein genug sein, um in einen einzelnen Link-Layer-Frame zu passen. Es ist jedoch noch Flexibilität beim Erstellen von Nachrichten erforderlich; Das Nachrichtendesign MUSS (MUST) den für Standard-IPv6-Header und andere Header (wie Link-Layer-Header und Adaptionsschicht-Header) erforderlichen Platz berücksichtigen, und MUSS (MUST) auch Optionen aufnehmen können, die von anderen Routing-Protokollen und bestehenden IETF-Protokollen benötigt werden.

5.3. Support of 6LoWPAN Characteristics (Unterstützung von 6LoWPAN-Eigenschaften)

Dieser Abschnitt berücksichtigt grundlegende Netzwerkeigenschaften, die das Design von 6LoWPAN-Routing-Protokollen beeinflussen können.

[R08] Das Design von 6LoWPAN-Routing-Protokollen SOLLTE (SHOULD) Verkehrsmuster, Netzwerkdichte, mögliche Rollen oder Funktionen von Knoten sowie die Verwendung und Anzahl verschiedener Netzwerkkonfigurationen berücksichtigen.

6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) in der Lage sein, eine Vielzahl verschiedener LoWPAN-Topologien zu handhaben, wie zum Beispiel:

• Punkt-zu-Punkt-, Punkt-zu-Mehrpunkt-, Mehrpunkt-zu-Punkt- oder Mehrpunkt-zu-Mehrpunkt-Verkehrsmuster
• Kommunikationsverkehr, der an einem einzelnen Punkt konzentriert ist (z.B. Gateway)
• Variierende Host- und Router-Dichte, variierendes Router-zu-Host-Verhältnis
• Router-Funktionalität kann sich von Host-Funktionalität unterscheiden oder auf demselben Knoten sein
• Verschiedene Knotenfunktionalitäten, wie eingeschränkte und nicht eingeschränkte Knoten oder Knoten, die Funktionen wie Routing, Relaying, Aggregation usw. ausführen
• Verschiedene Netzwerkkonfigurationen, wie Peer-to-Peer, Stern, Mesh-Netzwerke
• Dynamische Netzwerkbildung und Topologieänderungen während der Post-Deployment-Periode (Laufzeit)
• Variierende Netzwerkgröße; die Größe der Netzwerke kann auch sehr vielfältig sein, von Netzwerken mit wenigen Knoten bis zu mehreren hundert oder mehr Knoten
• Netzwerk-Partitionierung kann auftreten und muss behandelt werden

[R09] Die von 6LoWPAN-Routing-Protokollen verwendete Metrik SOLLTE (SHOULD) die kombinierten Auswirkungen von Knoten- und Link-Attributen berücksichtigen.

Es ist wichtig, Link-Qualität und Knotenattribute in Routing-Metriken einzubeziehen, um den Energieverbrauch zu minimieren und eine erfolgreiche Zustellung sicherzustellen. Zum Beispiel ist der kürzeste Pfad mit minimaler Hop-Anzahl möglicherweise nicht der energieeffizienteste Pfad, da er möglicherweise durch sehr überlastete Knoten oder durch Links verläuft, die mehr Fehler erfahren und daher mehr Neuübertragungen erfordern.

In Bezug auf die Arten von Metriken sollten Routing-Metriken in der Lage sein, effektiv darzustellen:

• Link-Metriken: Empfangssignalstärkenanzeige (RSSI), Link-Qualitätsindikator (LQI), erwartete Übertragungszählung (ETX), Durchsatz, Latenz
• Knoten-Metriken: Zustand (Schlaf, wach, zuhören), verbleibende Energie, Hop-Anzahl, geografische Informationen (z.B. GPS-Koordinaten)
• Zusammengesetzte Metriken (Link und Knoten)

Andere mögliche Metriken SOLLTEN (SHOULD) ebenfalls berücksichtigt werden, wie zum Beispiel:

• Zuverlässigkeit
• Robustheit
• Stabilität

[R10] 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) so konzipiert sein, dass sie sowohl Skalierbarkeit als auch Langlebigkeit in 6LoWPANs erreichen.

Skalierbarkeits- und Langlebigkeitsanforderungen sind grundlegende Eigenschaften von LoWPANs:

• Skalierbarkeit: Ein LoWPAN kann nur wenige Knoten enthalten (zum Beispiel für ein Personal Area Network oder Body Area Network), kann aber auch viel höhere Anzahlen von Geräten enthalten (z.B. Überwachung einer Stadtinfrastruktur oder einer Autobahn). Für Hausautomatisierungsanwendungen wird vorausgesehen, dass das Routing-Protokoll 250 Geräte im Netzwerk unterstützen MUSS (MUST) [RFC5826], während Routing-Protokolle für metropolitane Sensornetzwerke in der Lage sein MÜSSEN (MUST), eine große Anzahl von Sensorknoten in Regionen mit der Größenordnung von 10^2 bis 10^4 Sensorknoten zu clustern [RFC5548]. Es ist daher notwendig, dass Routing-Mechanismen so konzipiert sind, dass sie skalierbar für den Betrieb in Netzwerken verschiedener Größen sind. Aufgrund eines Mangels an Speichergröße und Rechenleistung könnte das 6LoWPAN-Routing jedoch Weiterleitungseinträge auf eine kleine Anzahl beschränken, wie z.B. maximal 32 Routing-Tabelleneinträge. Insbesondere in großen Netzwerken MUSS (MUST) der Routing-Mechanismus so konzipiert sein, dass die Anzahl der Router kleiner ist als die Anzahl der Hosts.

• Langlebigkeit: Das Verfahren zur Routenreparatur und die zugehörigen Kontrollnachrichten SOLLTEN NICHT (SHOULD NOT) dem Gesamtenergieverbrauch der Routing-Protokolle schaden.

[R11] Das Verfahren zur Routenreparatur und die zugehörigen Kontrollnachrichten SOLLTEN NICHT (SHOULD NOT) dem Gesamtenergieverbrauch der Routing-Protokolle schaden.

Lokale Reparatur verbessert den Durchsatz und die End-to-End-Latenz, insbesondere in großen Netzwerken. Da Routen schnell repariert werden, werden weniger Datenpakete verworfen, und eine geringere Anzahl von Routing-Protokoll-Paketübertragungen ist erforderlich, da Routen ohne von der Quelle initiierte Routen-Entdeckung repariert werden können [Lee]. Eine wichtige Überlegung hier kann sein, vorzeitige Energieerschöpfung zu vermeiden, auch wenn dies andere Anforderungen beeinträchtigt.

[R12] 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) dynamisch adaptive Topologien und mobile Knoten ermöglichen. Bei der Unterstützung dynamischer Topologien und mobiler Knoten sollte die Routenwartung das Ziel eines minimalen Routing-Zustands und minimalen Routing-Protokoll-Nachrichten-Overheads im Auge behalten.

Topologische Knotenmobilität kann das Ergebnis physischer Bewegung und/oder einer sich ändernden Funkumgebung sein, was es sehr wahrscheinlich macht, dass Mobilität auch in einem Netzwerk mit physisch statischen Knoten behandelt werden muss. 6LoWPANs verwenden kein separates Protokoll, um die Konnektivität zu mobilen Knoten aufrechtzuerhalten, sondern erwarten, dass das Routing-Protokoll dies handhabt.

Darüber hinaus können einige Knoten von einem 6LoWPAN zu einem anderen wechseln und es wird erwartet, dass sie in begrenzter Zeit funktionale Mitglieder des letzteren 6LoWPAN werden.

Gebäudeüberwachungsanwendungen haben beispielsweise eine Reihe von Anforderungen in Bezug auf Wiederherstellungs- und Einschwingzeit für Mobilität, die zwischen 5 und 20 Sekunden liegen (Abschnitt 5.3.1 von [RFC5867]). Für interaktivere Anwendungen wie die in Hausautomatisierungssystemen verwendeten, bei denen Benutzer Eingaben bereitstellen und sofortiges Feedback erwarten, sind die Mobilitätsanforderungen ebenfalls strenger, und für Bewegungen innerhalb eines Netzwerks ist üblicherweise eine Konvergenzzeit von unter 0,5 Sekunden erforderlich (Abschnitt 3.2 von [RFC5826]). In industriellen Umgebungen, in denen sich mobile Geräte (z.B. Kräne) bewegen, muss das Routing-Protokoll Fahrzeuggeschwindigkeiten von bis zu 35 km/h unterstützen [RFC5673]. Derzeit werden 6LoWPANs normalerweise nicht für eine so schnelle Mobilität verwendet, aber dynamische Assoziation und Disassoziation MÜSSEN (MUST) in 6LoWPANs unterstützt werden.

Es gibt mehrere Herausforderungen, die von einem 6LoWPAN-Routing-Protokoll angegangen werden sollten, um robustes Routing in dynamischen Umgebungen zu schaffen:

• Mobile Knoten, die ihren Standort innerhalb eines LoWPAN ändern: Wenn das Bewegungsmuster der Knoten unbekannt ist, kann Mobilität von den Routing-Protokollen nicht leicht erkannt oder unterschieden werden. Mobile Knoten können als Knoten behandelt werden, die an einem Ort verschwinden und an einem anderen wieder erscheinen. Die Verfolgung von Bewegungsmustern erhöht die Komplexität und kann vermieden werden, indem mobile Knoten mithilfe reaktiver Routen-Updates behandelt werden.

• Bewegung eines LoWPAN in Bezug auf andere (inter)verbundene LoWPANs: Innerhalb jedes Stub-Netzwerks müssen (ein oder mehrere) relativ leistungsstarke Gateway-Knoten (6LBRs) konfiguriert werden, um mobile LoWPANs zu handhaben.

• Knoten, die dauerhaft dem LoWPAN beitreten oder es verlassen: Um Routing-Tabellenaktualisierungen zu erleichtern, die Größe dieser Aktualisierungen zu reduzieren und Fehler-Kontrollnachrichten zu minimieren, können Knoten, die das Netzwerk verlassen, ihre Disassoziation dem nächsten Edge-Router oder einem bestimmten Knoten (falls vorhanden) ankündigen, der für lokale Assoziation und Disassoziation zuständig ist.

[R13] Ein 6LoWPAN-Routing-Protokoll SOLLTE (SHOULD) verschiedene Verkehrsmuster unterstützen -- Punkt-zu-Punkt, Punkt-zu-Mehrpunkt und Mehrpunkt-zu-Punkt -- und gleichzeitig übermäßigen Multicast-Verkehr in einem LoWPAN vermeiden.

6LoWPANs haben oft Punkt-zu-Mehrpunkt- oder Mehrpunkt-zu-Punkt-Verkehrsmuster. Viele aufkommende Anwendungen umfassen auch Punkt-zu-Punkt-Kommunikation. 6LoWPAN-Routing-Protokolle sollten mit Berücksichtigung der Weiterleitung von Paketen von/zu mehreren Quellen/Zielen entworfen werden. Aktuelle Dokumente der ROLL-Arbeitsgruppe erklären, dass die Arbeitslast oder das Verkehrsmuster von Anwendungsfällen für LoWPANs tendenziell hochstrukturiert ist, im Gegensatz zu beliebigen Datenübertragungen, die typische Client- und Server-Workloads dominieren. In vielen Fällen kann die Ausnutzung einer solchen Struktur schwierige Probleme vereinfachen, die sich aus Ressourcenbeschränkungen oder Variationen in der Konnektivität ergeben.

5.4. Support of Security (Unterstützung der Sicherheit)

Sicherheit ist ein kritisches Thema für Low-Power-Netzwerke. Jede Lösung für 6LoWPAN-Routing-Protokolle SOLLTE (SHOULD) die folgenden grundlegenden Sicherheitsanforderungen erfüllen. Diese Anforderungen MÜSSEN (MUST) für den Routing-Mechanismus und den Netzwerkdatenaustausch gelten, während übermäßiger Stromverbrauch und Nutzung der Rechenleistung vermieden werden sollten.

[R14] 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) Nachrichtenintegrität, Nachrichtenquellenauthentifizierung und Nachrichtenvertraulichkeitsdienste unterstützen, um sich gegen Routing-Bedrohungen zu verteidigen.

In Anbetracht der Bedeutung der Routing-Protokollsicherheit und der Natur von Sicherheitsbedrohungen für 6LoWPANs (zum Beispiel wie in [ROLL-SEC] beschrieben) SOLLTEN (SHOULD) Routing-Protokolle Folgendes unterstützen:

• Nachrichtenintegrität, um Protokollnachrichtenänderungen durch Zwischenknoten zu verhindern
• Nachrichtenquellenauthentifizierung, um Spoofing-Angriffe von gefälschten Quellen zu verhindern
• Nachrichtenvertraulichkeit, um passives Abhören zu verhindern

Die Aktualität von Nachrichten sollte ebenfalls berücksichtigt werden. Veraltete Nachrichten können selbst eine Form des Angriffs sein, in diesem Fall sind Aktualitätsdienste auf Anwendungsebene selbst oder zusammen mit Datenlinkp-Sicherheitsfunktionen für 6LoWPANs hilfreich.

Routing-Protokolle MÜSSEN (MUST) vor Angriffen wie Replay, Injection, Modification usw. geschützt werden, die zu Bedrohungen führen können, einschließlich Routing- oder Topologieschleifen, gezieltem Denial of Service für bestimmte Knoten, Generierung falscher Routing-Informationen, Ressourcenerschöpfung oder Netzwerk-Partitionierung [ROLL-SEC].

Sicherheitsunterstützung wird eine Option sein, und wenn sie aktiviert ist, wird sie alle Regeln für die Verwendung sicherer 6LoWPAN-Routing-Protokolle einhalten. Durch Implementierung von Link-Layer-Sicherheit (Sicherheit im CCM*-Modus, wie in Unterklausel 7.6 von IEEE 802.15.4 definiert) und Hinzufügen zusätzlicher routing-protokollspezifischer Sicherheits- und Nachrichtenintegritätsprüfmechanismen (wie Zeitstempel oder Sequenznummern) kann Widerstand gegen die meisten Sicherheitsbedrohungen erreicht werden.

Das Design MUSS (MUST) die Kosten für umfangreiche Operationen berücksichtigen, die das Protokoll ausführen MUSS (MUST). Zum Beispiel kann die Verwendung öffentlicher Schlüssel im Vergleich zu symmetrischen Schlüsseln zu einem höheren Energieverbrauch führen. Allgemeine Lösungen für Sicherheitsoperationen, die große Mengen an Knotenstatus erfordern (wie Adress-/Schlüsselverwaltung, Authentifizierung, Link-Layer-Schlüsseleinrichtung), sollten über alle LoWPAN-Protokolle hinweg verwendet werden, um Overhead zu sparen. 6LoWPAN-Routing-Protokolle SOLLTEN (SHOULD) so konzipiert sein, dass sie die Aktivierung dieser Funktionen unterstützen, und diese Funktionen selbst sollten darauf achten, nicht übermäßig viel Strom zu verbrauchen.

5.5. Support of Mesh-Under Forwarding (Unterstützung von Mesh-Under-Weiterleitung)

Die aktuelle 6LoWPAN-Architektur ermöglicht Multi-Hop-Weiterleitung durch Mesh-Under-Routing [RFC4944]. Ein wesentliches Merkmal dieses Ansatzes ist, dass die Fähigkeit zur Unterstützung von Mesh-Under-Weiterleitung und Route-Over-Routing eine Anforderung in 6LoWPAN-Protokollen sein kann. Ob dies jedoch eine Anforderung für 6LoWPAN-Routing-Protokolle ist, bleibt eine offene Frage. In dieser Hinsicht müssen wir die Anforderungen für diese beiden unterschiedlichen Ansätze (einer verwendet IP-Routing, der andere verwendet seinen eigenen Weiterleitungsmechanismus) berücksichtigen.

Der Mesh-Under-Weiterleitungsmechanismus verwendet Link-Layer-Adressen (MAC-Adressen), daher stoppt er an der Grenze eines IP-Subnetzes. Wenn er in Verbindung mit Route-Over-Routing verwendet wird, das IPv6-Adressen und Routing-Tabellen verwendet, kann er schichtübergreifende Informationen erfordern, einschließlich seiner eigenen Weiterleitungstabelle.

Aus diesem Grund kann der Mesh-Under-Weiterleitungsmechanismus seine eigenen Topologiewartungsnachrichten und Weiterleitungstabelle für zugehörige Operationen bereitstellen. Dies kann mit der Funktionalität vergleichbar sein, die von Route-Over-Routing-Protokollen benötigt wird, die für Nachbar-/Link-Entdeckung, Verwaltung von Weiterleitungstabelleneinträgen, Topologiewartung und Pfadentdeckung verwendet werden.

Daher ist eine Schlüsselfrage, wie diese beiden Ansätze (Route-Over und Mesh-Under) kombiniert werden sollten, wie sie koordiniert arbeiten können und dadurch jegliche Redundanz oder Interoperabilitätsprobleme vermeiden, die auftreten können. Zukünftige Arbeiten sollten sich speziell auf diese architektonischen Fragen konzentrieren.

5.6. Support of Management (Unterstützung des Managements)

Für das Netzwerkmanagement SOLLTEN (SHOULD) die folgenden Anforderungen berücksichtigt werden.

LoWPANs müssen möglicherweise dynamisch konfiguriert und initialisiert werden, zum Beispiel weiß ein Gateway nach dem Einschalten nicht, welche Knoten zu seinem Subnetz gehören. Die Fähigkeit von Knoten, einem Netzwerk beizutreten, ist von Natur aus unabhängig von der Routing-Technologie, obwohl einige Routing-Protokolle diesen Prozess erleichtern können. Routing-Protokolle SOLLTEN (SHOULD) die Initialisierung und Konfiguration des Netzwerks unterstützen. Dies kann die Interaktion zwischen dem Routing-Protokoll und anderen Funktionen wie Adresszuweisung, Autokonfiguration und Nachbarentdeckung beinhalten.

Für Überwachung und Debugging ist die Fähigkeit wichtig, relevante Routing-Protokollparameter, aktuelle Konfiguration und aktuellen Zustand der Router- und Host-Funktionalität zu erhalten. Es sollte möglich sein, Informationen wie Routing-Tabellen, Nachbartabellen, Nachrichtenzählungen und Link-Qualitätsinformationen zu erhalten. Schnittstellen für Diagnose-, Fehlererkennung-, Überwachungs- und Ereignis-/Alarmberichtsfunktionen sollten berücksichtigt werden. Während in einigen Fällen bestehende Protokolle und Schnittstellen zu diesem Zweck verfügbar sein können, können speziell für LoWPANs zugeschnittene Lösungen erforderlich sein.

Da bestimmte LoWPANs typischerweise periodisch in den Schlafmodus eintreten, sollte es möglich sein, das Schlaf-/Wachmuster der Knoten zu steuern, damit Informationen mit geringerer Latenz gesammelt werden können.

Die Fähigkeit, die Evolution von Routing-Protokollen zu unterstützen und Routing-Parameter basierend auf Umständen und Verkehrsmustern zu ändern, ist wichtig. Zum Beispiel kann es erforderlich sein, einen Metriktyp auszuwählen, Timer-Werte anzupassen oder den Modus des Protokolls (falls unterstützt) auszuwählen/zu ändern. Eine Möglichkeit besteht darin, zu einem völlig anderen Protokoll zu wechseln. Dies kann jedoch aufgrund von Codegrößenanforderungen nicht machbar sein. Benutzer sollten in der Lage sein, Implementierungen mehrerer Routing-Protokolle zu unterstützen.

Die folgenden zusätzlichen Managementaspekte sollten berücksichtigt werden:

• Geräteverwaltung und Knotentopologiekonfigurationsfähigkeiten
• Sicherheitsmanagement, einschließlich Schlüsselverwaltung
• Schlafplanemanagement
• Quality-of-Service-Management
• Pfadreparatur, Fehlererkennung und Kontrolle
• Schichtübergreifende Integration und Koordination