See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/320244798

RPL – IPv6 Routing Protocol for LLNs

Chapter · October 2017

CITATIONS READS

3 1,632

1 author:

Anatol Badach
University of Applied Sciences Fulda
247 PUBLICATIONS 115 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Electronic Switching System for Slow Data Transmission View project

Voice over IP View project

All content following this page was uploaded by Anatol Badach on 06 October 2017.

The user has requested enhancement of the downloaded file.

 R
► RPL

RPL
IPv6 Routing Protocol for LLNs
Autor: Prof. Dr.-Ing. Heutzutage werden an das Internet nicht nur Rechner verschiedener
Anatol Badach Art angeschlossen, sondern zunehmend auch drahtlose Netze, wel-
che aus unterschiedlichen, mit diversen Sensoren und Aktoren aus-
gestatteten, intelligenten Geräten/Einrichtungen bestehen, angebun-
den. Diese Netze werden als Wireless Sensor Networks (WSN)
bezeichnet, die intelligenten Geräte Smart Objects genannt. De facto
stellt ein WSN eine Vernetzung von Smart Objects dar. Die Integra-
tion verschiedener WSNs in das herkömmliche Internet führt zur
Entstehung einer neuen, besonderen, als Internet of Things (IoT)
(Internet der Dinge) bezeichneten Erweiterung des Internets. Da
WSNs aber sehr stark ressourcenbeschränkt (resource constrained),
besonders energiearm (low-power) und verlustbehaftet (lossy net-
Auszug aus dem Werk: work) angelegt sind, werden sie auch als Low-Power and Lossy
Networks (LLN) bezeichnet.

Das IoT bilden de facto die in das Internet integrierten LLNs mit
dem Protokoll IPv6 (Internet Protocol, Version 6). Im IoT, genauer
in LLNs mit dem Protokoll IPv6, ist ebenso wie im herkömmlichen
Internet ein Routingprotokoll nötig. Hierfür wurde das IPv6 Routing
Protocol for Low-Power and Lossy Networks (RPL) entwickelt. Wie
bereits aus dem Namen hervorgeht, handelt es sich um ein Routing-
protokoll für energiearme und verlustbehaftete Netze mit IPv6 und
kann auch als Routingprotokoll für das IoT angesehen werden.

Herausgeber: Dipl.-Ing. LLNs bilden drahtlose Netze mit energiearmen Knoten, zwischen
Heinz Schulte denen die als Links bezeichneten Funkkanäle datenverlustbehaftet
sind. Dies hat zur Folge, dass bei der Ermittlung optimaler Routen
mehrere Faktoren, insbesondere die Qualität von Links, z.B. deren
Zuverlässigkeit (Reliability) und Verzögerung (Latency) sowie die
zum Betrieb knappe Energie in Knoten berücksichtigt werden müs-
sen. Hinzu kommt noch die Tatsache, dass die Topologie der Ver-
netzung von Smart Objects in LLNs nicht dauerhaft angelegt ist,
sondern schnell veränderbar sein muss. Diese Umstände führen
dazu, dass die Anforderungen an ein LLN-Routingprotokoll im
Vergleich zum Routingprotokoll in klassischen IP-Netzen sehr viel
WEKA-Verlag komplexer sind. Diese vielfältigen Anforderungen führten schließ-
ISBN 978-3-8276-9142-2

1
R
► RPL

lich zur multifunktionalen und zugleich flexiblen Protokollspezifika-

tion des RPL.

Das RPL wurde nicht als ein einziger Algorithmus konzipiert, son- Routing
dern ist als ein Routing Framework anzusehen, in dem mehrere Framework
Algorithmen zur Bereitstellung der benötigten Funktionalität mit-
wirken müssen. Mithilfe der dazu spezifizierten einzelnen Funk-
tionsmodule wird in einem physischen LLN, welches im Allgemei-
nen eine drahtlose, schleifenbehaftete Vernetzung von Smart Objects
darstellt, eine logische, zielgerichtete, azyklische, also schleifenfreie
(loop-free) Vernetzung von Smart Objects gebildet.

Die technischen Entwicklungen im Hinblick auf RPL werden bei der Entwicklung
Internet Engineering Task Force (IETF) von der Working Group bei der IETF
ROLL (Routing over Low-Power and Lossy Networks) koordiniert.
Die bisherigen RPL betreffenden Entwicklungen wurden in zahlrei-
chen als Request for Comments (RFC) von der IETF veröffentlich-
ten Internet Standards bzw. Internet Drafts dokumentiert. Eine Auf-
listung dieser findet sich am Ende dieses Beitrags.

Dieser Beitrag erläutert zuerst kurz die Aufgaben vom RPL. Danach Beitrags-
wird ein funktionales Modell des Protokolls eingeführt, in dem die schwerpunkte
wesentlichen RPL-Funktionsmodule wie jene zur Realisierung von
Objective Functions, Path Calculation Algorithm, Estimation of
Routing Metrics, Packet Forwarding Scheme, Rerouting & Maintai-
ning Support, Mobility Support und Security Support präsentiert
werden. Schließlich wird detaillierter auf die Bedeutung und Aufga-
be einzelner Funktionsmodule eingegangen.

Protokollfunktionen des RPL

Ein LLN kann im Allgemeinen eine beliebige Vernetzungstopologie Netzelemente
aufweisen, die aus
 Intermediate Nodes (IN), welche als IoT-Router fungieren, und
 End Nodes (EN), die diverse Smart Objects mit Sensoren und
Aktoren repräsentieren, besteht.
Als Bestandteil des IoT wird das LLN an das Internet über einen
speziellen LLN Border Router (LBR) angebunden. Bild 008361
zeigt eine solche Topologie und verweist im ersten Ansatz auf die
Funktion des RPL.

2
 R
► RPL

Bild 008361: Illustration der RPL-Funktion: a) LLN als eine draht-

lose, schleifenbehaftete Vernetzung von INs und ENs, b) DODAG
als eine schleifenfreie (loop-free) Vernetzung von INs und ENs im
LLN
EN: End Node: Smart Object wie Sensor, Aktor, Maschine usw.
IN: Intermediate Node: IoT-Router, IoT-Forwarding Node
LBR: LLN Border Router

Loop-free Routing In einem LLN können bei der Übermittlung von Datenpaketen ver-
schiedene unerwünschte, als Routing Loops (kurz Loops) bezeichne-
te Schleifen entstehen, welche dazu führen, dass die Pakete entlang
von „geschlossenen Übermittlungspfaden“ zirkulieren. In einem
Wireless Sensor Network kann eine solche Situation z.B. dazu füh-
ren, dass ein Aktor und/oder Sensor die gleichen Daten wiederholt
empfängt. Um derartige negative Effekte zu vermeiden, muss das
RPL eine schleifenfreie Übermittlung von Datenpaketen zwischen
Intermediate Nodes und End Nodes im LLN gewährleisten.

DODAG Diese Anforderung wird vom RPL mittels einer besonderen logi-
Destination-Oriented schen Vernetzungstopologie (Bild 008361b) erfüllt. Sie bildet einen
Directed Acyclic sog. Destination-Oriented Directed Acyclic Graph (DODAG), das
Graph heißt einen zielorientierten, gerichteten, azyklischen Graphen. Er
stellt eine nach einer sog. Objective Function optimierte schleifen-
freie Topologie dar, in welcher der LBR die Wurzel bildet und die
Intermediate Nodes als Abzweigungen einer Baumstruktur angese-
hen werden können, in der die End Nodes die Blätter darstellen.

3
R
► RPL

Im Kontext des IoT sind die Intermediate Nodes und End Nodes im Adressierte
LLN als IoT-Devices zu betrachten, denen IPv6-Adressen zugewie- IoT-Devices
sen werden müssen. Hierfür werden sog. LLU-Adressen (Link-Local
Unicast IPv6 Addresses) mit einem 64 Bit langen Präfix FE80::/64
in LLNs verwendet. Die letzten 64 Bit in diesen IPv6-Adressen
stellen die Interface-ID (Identification) dar und bilden die sog. EUI-
64-Adresse (Extended Unique Identifier). Sie entsteht durch die
Erweiterung von MAC-Adressen um eine festgelegte Bitkombinati-
on und ist wie die ursprüngliche Adresse im Grunde als MAC-
Adresse anzusehen. Folglich werden die Nodes in LLNs – und dem-
entsprechend auch in DODAGs – mit Interface-IDs, die de facto
MAC-Adressen sind, identifiziert.

Es sei angemerkt, dass sowohl Links zwischen Intermediate Nodes RPL-

als auch zwischen Intermediate Nodes und End Nodes im LLN sehr Beschränkungen
stark funktionell beschränkt sind. Aus diesem Grund werden LLNs
als Constraint Networks betrachtet. Diese Beschränkungen müssen
im RPL-Konzept berücksichtigt werden, was wiederum zu einer
großen Komplexität des RPL führt. Die verschiedenen RPL-
Constraints gehen insbesondere auf folgende Umstände zurück:
 Link Constraints
Drahtlose LLN-Links arbeiten stark verlustbehaftet, was zu häu-
figen Verlusten der über diese Links übermittelten Datenpakete
führt. Zudem erfolgt die Übermittlung mit nur geringer Ge-
schwindigkeit (Low Bit Rate), sodass die Datenpakete mit relativ
langen Verzögerungszeiten ihr Ziel erreichen. Diese Besonder-
heiten von LLN-Links werden beim RPL auf die sog. Link-based
Metrics (Bild 008367) abgebildet und bei der Festlegung der
Routen (Datenpfade) berücksichtigt.
 Node Constraints
LLN-Nodes sind in der Regel funktionell sehr beschränkt, denn
ihre Verarbeitungsleistung (Processing Power) und Speicherka-
pazität (Memory Capacity) sind nur gering. Oft werden diese
Nodes, insbesondere jene, welche Sensoren darstellen, von klei-
nen Batterien mit Energie versorgt, wodurch sie nur energiearm
(low energy) und leistungsbegrenzt (processing limited) betrie-
ben werden können. Aus diesem Grund sind sowohl Nodes als
auch Links in LLNs nicht betriebssicher, folglich nicht hochver-
fügbar. Beschränkungen dieser Art, d.h. die Low Energy Cons-
traints, sind bei der Ermittlung von Routen im LLN zu berück-

4
 R
► RPL

sichtigen. Hierfür dienen beim RPL die sog. Node-based Metrics

(Bild 008367). Das RPL trägt dem Rechnung, indem es ver-
sucht, Routen möglichst nicht über energiearme Nodes zu füh-
ren.
 Funktionelle Instabilität von Nodes und Links
Die Energiearmut von Nodes im LLN hat zur Folge, dass man
mit Nichtverfügbarkeit (Non-Availability) von Nodes, die als
Router dienen, rechnen muss. Damit kann auch nicht von dauer-
haft verfügbaren Links bzw. Routen ausgegangen werden, über
die sich die Übermittlung der Datenpakete vollzieht. Das heißt,
es ist von einer Instabilität (Function Instability) der Links und
somit auch der DODAGs auszugehen.
Aus diesem Grund verfügt das RPL über einen Algorithmus, der
dazu dient, diverse Anomalien im DODAG zu erkennen und,
falls nötig, die Ermittlung eines neuen DODAG zu initiieren –
was ein Rerouting im LLN bedeutet. Hierbei wird eine neue
Version von DODAG aufgebaut. Um darauf zu verweisen, ob es
sich um eine neue oder alte Version von DODAG handelt, wird
jeder eine Versionsnummer zugeteilt und diese in allen RPL-
Protokollnachrichten (Messages) eingetragen.

Protokollarchitektur von IoT-Devices

Network Das von der IETF in zahlreichen RFCs beschriebene 6LoWPAN,
Layer kurz für IPv6 over Low-Power WPAN, stellt eine an die Anforde-
rungen des IoT und insbesondere der LLNs adaptierte und kompri-
mierte Form des Protokolls IPv6 dar. Bild 008362 zeigt die typische
Protokollarchitektur von IoT-Devices mit 6LoWPAN in der Netz-
werkschicht (Network Layer, Layer 3), die hier in der Regel von
6LoWPAN erbracht wird und somit als IPv6 Adaptation Layer
angesehen werden kann. Mit 6LoWPAN wird der Header des Proto-
kolls IPv6 komprimiert und an die Besonderheiten von Low Rate
Wireless Personal Area Networks (LR-WPAN) angepasst. Es ist zu
unterstreichen, dass das LR-WPAN eine Art LLN ist.

Transport Auf der Transportschicht (Transport Layer, Layer 4) im IoT kommt

Layer als Transportprotokoll hauptsächlich das verbindungslos arbeitende
UDP zum Einsatz, wobei auch dessen Header komprimiert werden
kann. Folglich unterscheidet man zwischen compressed UDP
(cUDP) und non-compressed UDP (ncUDP). 6LoWPAN ermöglicht

5
R
► RPL

den Einsatz des verbindungsorientierten Transportprotokolls TCP

und des ICMP.

Bild 008362: RPL innerhalb der Protokollarchitektur von IoT-

Devices in LLNs mit 6LoWPAN
c/ucUDP: compressed/non-compressed User Datagram Protocol
CoAP: Constrained Application Protocol
ICMP: Internet Control Message Protocol
TCP: Transmission Control Protocol

Auf der Applikationsschicht (Application Layer, Layer 6) der Proto- Application

kollarchitektur von IoT-Devices ist das Device Management für die Layer
verschiedenen Anwendungen des IoT positioniert.

RPL-Grundbegriffe
Das Routing in einem Netzwerk ist ein Optimierungsprozess im Objective
Sinne eines Kriteriums, welches das Ziel der Optimierung bestimmt. Function
Insbesondere in jedem LLN ist das Routing ein wiederholt durch-
führbarer Optimierungsprozess, dessen Ziel durch eine Zielfunktion
(Objective Function, OF) messbar und numerisch bestimmt werden
muss.

Als universell einsetzbares Routingprotokoll unterstützt das RPL OF-Identifikation

verschiedenartige Objective Functions, die es erlauben, Routen nach
unterschiedlichen Kriterien zu optimieren. Diese Objective Func-
tions lassen sich bei der Internetorganisation IANA (Internet Assig-
ned Numbers Authority) registrieren, wodurch ihnen weltweit gel-
tende, eindeutige OF-Identifikationen zugewiesen werden.

6
 R
► RPL

Um darauf zu verweisen, welche Objective Function beim Aufbau

bzw. Umbau (Rerouting) eines DODAG aktuell verwendet wird,
wird die OF-Identifikation in der den Auf- bzw. Umbau von
DODAG initiierenden RPL-Protokollnachricht DIO (DODAG In-
formation Object) eingetragen (Bild 008372).1 Damit wird angege-
ben, nach welcher Zielfunktion (Kriterium) der DODAG optimiert
wird.

Der DODAG in einem LLN wird so aufgebaut, dass die Routen von
jedem End Node zum Root Node nach einer Objective Function
optimiert sind. Zurzeit (August 2017) können beim RPL die zwei
folgenden als Internet-Standards geltenden Objective Functions zum
Einsatz kommen:
 OF0 – Objective Function Zero nach RFC 6552
 MRHOF – Minimum Rank with Hysteresis Objective Function
nach RFC 6719
Auf ihre Bedeutung wird im Folgenden noch eingegangen.

Die Parameter von Objective Functions, de facto ihre Argumente,

Metriken
repräsentieren verschiedene Metriken. Im Netzwerkbereich versteht
man unter dem Begriff Metrik (Metric) ein numerisches Maß für
Güte/Qualität. Bei der Ermittlung von Routen handelt es sich um die
Qualität von Routen und man spricht von Routing-Metriken (Rou-
ting Metrics).

Die Qualität einer Route, also ihre Metrik, wird durch die Qualität
von Systemkomponenten (insbesondere von Links und Nodes) ent-
lang der Route bestimmt. Dementsprechend spricht man von Link
Metrics und von Node Metrics, wenn die Qualität dieser System-
komponenten gemeint ist.

Rank Diese Metriken werden durch diverse quantitative Qualitätsmerkma-

le bestimmt, d.h. durch welche, die sich messen, numerisch ausdrü-
cken und folglich vergleichen lassen. Beim Einsatz des RPL in
LLNs kann die Güte jeder Route als ihre Metrik angegeben werden.

1
Genau genommen wird die Art der Objective Function (OF-Type) als Wert
von OCP (Objective Code Point) in der Option DODAG-Configuration
angegeben. Diese Option wird in den Nachrichten DIO übermittelt.

7
R
► RPL

Die Metriken von Routen und Links, also ihre Qualität, werden beim
RPL mit dem Parameter Rank quantitativ angegeben.

Jeder Node – sowohl ein Intermediate Node (Router) als auch ein
End Node – hat im DODAG seinen Rank, welcher die Metrik der
Route von ihm zum Root Node widerspiegelt. Damit ist der Rank
quasi ein Maß für die „Entfernung“ eines Node zum Root Node.
Deshalb wird der Rank von Nodes dazu verwendet, im DODAG
seine Entfernung zur Root zu bestimmen. Die Bedeutung des Rank
wird in den Bildern 008363 und 008364 gezeigt.

Logische Strukturierung von LLNs

In einem LLN können mehrere DODAGs eingerichtet werden. Bild
008363 zeigt solch einen Fall. Es sei hervorgehoben, dass Nodes
eines LLN zu mehreren DODAGs innerhalb dieses LLN gehören
und auf diese Weise also Multi-DODAG Nodes (MDN) sein kön-
nen. Infolgedessen sind diese Nodes von „außen“ z.B. über das
Internet über mehrere Roots erreichbar.

Wie in Bild 008363 zum Ausdruck gebracht wurde, können mehrere RPL-Instance
DODAGs in einem LLN aufgebaut und zu einer logischen Instanz
zusammengefasst werden. Diese wird als RPL-Instance bezeichnet.
In einem sehr großen LLN lassen sich mehrere dieser Instanzen
einrichten. Um die geschilderte zweistufige logische Strukturierung
von LLNs zu ermöglichen, wird jedem DODAG eine im ganzen
LLN einmalige Identifikation (DODAG ID) zugewiesen. Als Identi-
fikation dient in der Regel die IPv6-Adresse der DODAG-Root.

Die in Bild 008363 gezeigte logische Strukturierung von LLNs, also Vorteil der
die Bildung mehrerer DODAGs innerhalb einer RPL-Instance, hat Strukturierung
einen großen Vorteil: In den einzelnen DODAGs innerhalb einer
RPL-Instance können dadurch die besten Routen nach den verschie-
denen, an die Besonderheiten des LLN angepassten Kriterien und
Prinzipien ermittelt werden. Damit besteht die Möglichkeit, die
Optimierung von LLN-Routen nach verschiedenen Optimierungskri-
terien (Objective Functions) vorzunehmen. In jedem DODAG des-
selben LLN kann so eine andere Objective Function verwendet
werden. Eine solche Lösung kann dazu dienen, die Nutzungsprofile
einzelner DODAGs in breit angelegten LLNs, z.B. in den künftigen
Smart Cities, an die Besonderheiten und Leistungsfähigkeiten von

8
 R
► RPL

LLN-Routern anzupassen. Dies würde implizit zur „Steigerung“ der

Funktionalität verschiedener Sensornetzwerke führen.

Bild 008363: Illustration der logischen Strukturierung von LLNs

und der Bedeutung der Begriffe: RPL Instance, Rank und DODAG
ID
CC: Consistency Check
DAO: Destination Advertisement Object
DAO-ACK: DAO Acknowledgement
DIO: DODAG Information Object
DIS: DODAG Information Solicitation
DODAG ID: DODAG Identification

Relevanz An dieser Stelle soll nochmals auf die in Bild 008363 herausgestellte
des Rank Relevanz des Rank im DODAG eingegangen werden. Auf diese
im DODAG Weise wird quasi dessen „Distanz“ zur Root angegeben – aber nicht
in klassischen Längewerten, sondern in den Werten verwendeter
Routing Metrics. Die präzise Aussage eines Rank erhält man somit
nur unter Beachtung der beim RPL verwendeten Routing Metric. So
kann der Rank z.B. in einem Sonderfall (siehe Anmerkung) die

9
R
► RPL

Entfernung in Hops zur Root abbilden (wie in Bild 008363) oder

aber auch die Batteriezustände einzelner Nodes auf dem Pfad zur
Root auf eine, durch speziell hierfür konzipierte Node-based Metrics
festgelegte Art und Weise berücksichtigen.
Anmerkung: Im Fall, dass als Optimierungskriterium von Routen OF0 beim
RPL zum Einsatz kommt und als Metrik von Routen die als Hop Count (HC)
bezeichnete Metrik verwendet wird, hat die Metrik aller Links dann den Wert
„Rank = 1“. In diesem Fall entspricht der Rank-Wert eines Node der Anzahl
von Hops, also der Anzahl von Links, zum Root Node.

Wie Bild 008363 zeigt, unterscheidet man bei der Übermittlung von
RPL-Nachrichten zwischen zwei Richtungen (Directions), und zwar Übermittlungs-
zwischen Downward Direction und Upward Direction. Hierbei wird richtungen
die Richtung „vom Root Node zu den End Nodes“ als Downward
Direction und die Gegenrichtung „von den End Nodes zum Root
Node“ als Upward Direction bezeichnet. Bild 008363 vermittelt
zudem, welche RPL-Nachrichten in welcher Richtung übermittelt
werden.

Besonderheiten des Routings mit RPL

Ein DODAG stellt quasi eine virtuelle/logische Routingtopologie Multi-Topology
innerhalb eines physikalischen LLN dar. Daher können in einem Routing
LLN mehrere dieser virtuellen Topologien eingerichtet werden und
diese bilden, eine RPL-Instance (Bild 008363). Da jedem DODAG
innerhalb einer RPL-Instance eine Identifikation zugewiesen wird,
können in einem LLN mehrere virtuelle Topologien eingerichtet
werden. In diesem Zusammenhang spricht man von Multi-Topology
Routing (MTR).

Eine wichtige Besonderheit des MTR besteht darin, dass innerhalb

einer RPL-Instance, de facto innerhalb eines LLN, mehrere DO-
DAGs nach unterschiedlichen Kriterien (z.B. der Minimierung des
Energieverbrauchs, Maximierung der Zuverlässigkeit usw.) optimiert
werden können. Dies bedeutet sowohl, dass in den einzelnen DO-
DAGs die verschiedenen Objective Functions angewandt werden, als
auch, dass in den DODAGs unterschiedliche Beschränkungen gelten
können. Die Bedeutung von Objective Functions soll Bild 008366
zum Ausdruck bringen.
Anmerkung: Einen DODAG könnte man auch als ein schleifenfreies (loop
free) virtuelles LLN ansehen und daher als Virtual LLN (VLLN) bezeichnen.

10
 R
► RPL

Die Bildung von VLLNs im IoT würde somit der Bildung von Virtual LANs
(VLANs) sowohl innerhalb von LANs als auch im „klassischen“ Internet
entsprechen.

Route Jedes Routingprotokoll spezifiziert die Art und Weise, wie optimale
Selection Routen gemäß der bei ihm verwendeten Zielfunktion (Objective
Function) unter Berücksichtigung möglichst aller Beschränkungen
ausgewählt werden sollen. Diese Routenauswahl wird beim RPL als
Route Selection bezeichnet. Sie ist die „Kernaufgabe” jedes Rou-
tingprotokolls – somit auch des RPL. Bild 008364 verfolgt das Ziel,
die Idee und Realisierung der Route Selection beim RPL zu veran-
schaulichen.

Bild 008364: Routing-Metrik in Form von Rank: a) Selektion der

Route nach der Objective Function MRHOF, b) Schätzung der Link-
Metrik ETX

11
R
► RPL

ETX: Expected Transmission Count

DIO: DODAG Information Object
MRHOF: Minimum Rank with Hysteresis Objective Function

Beim RPL wird vorausgesetzt, dass jeder Router (Root Node) die Güte
Metriken, also die Güte von Links (Funkkanälen) zu allen benach- der Links
barten Routern, kennt. Diese Metriken werden in der Konfigurati-
onsphase beim betreffenden Router eingetragen. Er kann sie in
bestimmten Fällen auch experimentell auf eine festgelegte, vom
konkreten Fall abhängige Art und Weise abschätzen, so wie es z.B.
in Bild 008364b gezeigt wurde. Der hier dargestellte Router X k
kennt folglich die Metriken zu allen ihm bekannten benachbarten
Routern in Root-Richtung.

Beim Aufbau des DODAG und insbesondere bei der Route Selection Aktualisierung
spielt die Nachricht DIO (Bild 008372) eine sehr wichtige Rolle. Mit der Routing-
DIO initiiert die Root den Aufbau eines neuen DODAG, genauer informationen
gesagt einer neuen DODAG-Version, die in DIO angegeben werden
muss. Auch jeder Router, der eine auf das Routing bezogene Verän-
derung in seinem Umfeld feststellt, verschickt DIO an alle seine
Nachbarn, um diese über die Notwendigkeit der Änderung von
Routen zu informieren und de facto das sog. Rerouting, also die
Neuermittlung aktueller Routen, einzuleiten. Durch diese seitens
jedes Routers realisierte Aktion versetzen sich alle Router gegensei-
tig in die Lage, alle benachbarten, über einen Hop erreichbaren
Router in Root-Richtung kennenzulernen.

Betrachtet man z.B. den Router Xk, in Bild 008364, so sind die
Router P1, …, Pi, Pm, …, PN dessen Nachbarrouter (Neighbour Rou-
ters) in Root-Richtung. Aus diesen Nachbarroutern wird ein Router,
über den die optimale Route zur Root führt, ausgewählt und als
Parent bezeichnet. Es werden also alle benachbarten Router in Root-
Richtung eines Routers als seine Parent Candidates angesehen.2
Jeder Router muss die Liste seiner Parent Candidates, die sog. Parent
Candidates List (PCL), immer auf dem aktuellen Stand halten. Er
muss diese Liste fast ständig aktualisieren, insbesondere nach dem
Empfang von DIO.

2
Parent Candidates nennt man (wie z.B. in RFC 6552) auch Potential Pa-
rents. Die Parent Candidates List wird dann als Parent Set bezeichnet.

12
 R
► RPL

Rerouting Um zu erkennen, ob eine Aktualisierung von DODAG als eine Art

and Rerouting durchgeführt werden muss, verschicken alle als Router
Maintaining funktionierenden Nodes die bereits bekannte Nachricht DIO als
Broadcast an alle ihre Nachbarn. Dies kann aber zu einer großen und
unnötigen Vermehrung von DIOs im DODAG führen. Um eine
unnötige große – die Energie in Nodes raubende und den DODAG
stark belastende – Vermehrung von DIOs zu vermeiden und diese
auf eine unabdingbare Menge zu begrenzen, wird ein als Trickle
Algorithm bezeichnetes Verfahren realisiert. Mit diesem im RFC
6206 spezifizierten Verfahren werden „Rerouting and Maintaining“
unterstützt (Bild 008366).

Zu Bild 008364 sei schließlich noch Folgendes angemerkt: Der

aktuelle Parent und jeder Parent Candidate des Routers X k kennt die
optimalen, von ihm zur Root führenden Routen. Die Güte jeder
dieser Routen beschreiben die entsprechenden Rank-Werte. Diese
sind dem Router Xk bereits bekannt, denn sie wurden ihm sowohl
seitens des Parent als auch der Parent Candidates mittels DIO mitge-
teilt. Jeder Router muss somit die Rank-Werte aller Parent Candi-
dates auf der Parent Candidates List eintragen.

MRHOF Wie in Bild 008364 gezeigt, werden die optimalen Routen nach der
und ETX Objective Function MRHOF ausgewählt. Als Metrik von Links bei
MRHOF wird in der Regel der Parameter ETX verwendet. Bei der
MRHOF wird der Rank jedes Routers als Parameter PathCost ange-
nommen und als Kosten (Cost) der Route (Path) vom Router zum
Root angesehen. Demzufolge wird bei der Route Selection, als opti-
male Route, die Route zur Root mit den minimalsten Kosten ange-
nommen.

Der Parameter ETX stellt die Metrik von Links dar und dient als
Maß zur Bewertung der Qualität von fehlerbehafteten und unzuver-
lässigen Links im LLN. Der ETX-Wert eines Links repräsentiert die
in stochastischem Sinne geschätzte mittlere Anzahl der Sendungs-
versuche eines Pakets, die benötigt werden, um dieses erfolgreich
über den Link zu übermitteln und eine Quittung dafür in Form eines
entsprechenden Acknowledgement-Pakets zu erhalten.

Registrierung Hat der in Bild 008364 betrachtete Router Xk die Nachricht DIO von
von Parent einem neuen, ihm noch unbekannten Router Pm empfangen, gilt
Candidates dieser als dessen Parent Candidate. Daher nimmt der Router X k
zuerst den neuen Router Pm in seine Parent Candidates List auf.

13
R
► RPL

Danach muss er noch überprüfen, ob der neue Router P m als sein

neuer Parent fungieren soll. Also muss der Router Xk überprüfen, ob
die optimale Route zur Root über den neuen Nachbarrouter P m ver-
läuft. Hierfür ermittelt er seinen neuen Rank-Wert R(Xk|Pm), d.h. den
Rank-Wert im Fall, dass die Route zur Root über den neuen Nach-
barrouter Pm verläuft, und vergleicht diesen neuen Rank-Wert mit
dem alten Rank-Wert R(Xk|Pi), welcher dem Verlauf der Route zur
Root über den aktuellen Parent Pi entspricht.

Ist der neue, nach der MRHOF als NewPathCost bezeichnete Rank-
Wert R(Xk|Pm) um den Wert niedriger als der alte, als OldPathCost
bezeichnete Rank-Wert R(Xk|Pi), so dient der neue Nachbarrouter Pm
von jetzt an als neuer Parent, denn über diesen Router Pm verläuft
die aktuell optimale Route vom Router Xk zur Root.
Anmerkung: Der als PARENT_SWITCH_THRESHOLD bezeichnete Para-
meter  muss sorgfältig bestimmt werden. Er soll dazu beitragen, dass nicht
jede minimale Steigerung des Rank-Wertes der optimalen Route unbedingt
zur Ermittlung einer neuen, besseren Route führen muss. Somit trägt  dazu
bei, sog. Hysteresis-Effekte als negative Nachwirkungen, die durch ein sich
zu oft wiederholendes Rerouting zu Instabilitäten im LLN führen würden,
möglichst zu vermeiden. Folglich kann  als Hysteresis-Parameter angesehen
werden.

Traffic Patterns in LLNs

Das RPL wurde konzipiert, um im IoT auf der Basis von LLNs alle IoT-
Arten von Kommunikation realisieren zu können. Insbesondere soll Verkehrsbe-
das Protokoll es ermöglichen, mit einer aus dem Internet abgeschick- ziehungen
ten und über den Root Node verlaufenden Kontrollnachricht alle
End Nodes in einem LLN, welche als Sensoren und/oder Aktoren
fungieren, abzufragen bzw. anzusteuern. Dies setzt aus Sicht der
charakteristischen IoT-Verkehrsbeziehungen die Punkt-zu-Punkt-,
die Punkt-zu-Multipunkt- und die Multipunkt-zu-Punkt-
Kommunikation in einem DODAG voraus.

Auf Englisch werden diese auch Traffic Patterns genannten Ver- Verkehrsarten
kehrsarten entsprechend als
 P2P – Point-to-Point (auch One-to-One),
 P2MP – Point-to-Multipoint (auch One-to-Many) und

14
 R
► RPL

 MP2P – Multipoint-to-Point (auch Many-to-One)

bezeichnet.

Bild 008365 illustriert diese fundamentalen Verkehrsarten des RPL

zum Aufbau von Routen in einem LLN und verweist bereits auf den
weiter unten erörterten Storing Mode in den als Router arbeitenden
Nodes im LLN.

Bild 008365: Verkehrsarten in einem DODAG und RPL-Modi: a)

DODAG-Topologie, b) P2MP- und MP2P-Kommunikation, c) Non-
Storing MOP, d) Storing MOP
MOP: Mode of Operation, eine Art RPL-Betriebsart
RT: Routing Table, Routingtabelle speziell zur Unterstützung der
P2P-Kommunikation

Mögliche Verkehrsarten (Traffic Patterns) im DODAG:

 P2MP
Diese Verkehrsart ermöglicht eine gerichtete Datenübermittlung
vom Root Node zu allen End Nodes, welche de facto oft diverse
Sensoren und Aktoren repräsentieren. Dank der P2MP-
Kommunikation können alle End Nodes in einem DODAG quasi
auf einen Schlag mit einer aus dem Internet kommenden, über

15
R
► RPL

den Root Node verlaufenden Kontrollnachricht angesteuert bzw.

kann ihr aktueller Zustand abgefragt werden.
 MP2P
Bei dieser Verkehrsart handelt es sich im Vergleich zur P2MP-
Kommunikation um eine Datenübermittlung in Gegenrichtung –
d.h. um eine Datenübermittlung von End Nodes zum Root Node.
Bezogen auf das Internet heißt dies, dass End Nodes ihre Daten
zum Internet über den zentralen Root Node übermitteln können.
 P2P
Die Verkehrsart P2P ermöglicht, dass jeweils zwei End Nodes
untereinander (paarweise) Daten übermitteln können. Die Reali-
sierung dieser Verkehrsart ist jedoch davon abhängig, ob das
RPL im DODAG den sog. Storing Mode unterstützt.

Zur Erfüllung der soeben erwähnten Anforderungen in der P2P- RPL-Modi

Kommunikation werden die folgenden zwei, als RPL-Modi bezeich- in der P2P-
neten Betriebsarten des IPv6-Routingprotokolls RPL spezifiziert: Kommunikation
 Non-Storing Mode
Diese Betriebsart des RPL zeichnet sich dadurch aus, dass in der
Root nur eine globale P2P-spezifische Routingtabelle enthalten
sein muss. Wie in Bild 008365c gezeigt, verläuft die Übermitt-
lung von Daten in diesem Fall jeweils zwischen zwei End Nodes
nur über die zentrale Root.
 Storing Mode
Bei dieser Betriebsart des RPL müssen – zusätzlich zur globalen
P2P-spezifischen Routingtabelle in der Root – in anderen Inter-
mediate Nodes weitere lokale Routingtabellen gleicher Art ent-
halten sein. Wie Bild 008365d zeigt, kann in diesem Fall die
Übermittlung von Daten zwischen End Nodes nicht immer nur
über die Root, sondern auch über lokale, als Router dienende
und nah gelegene Intermediate Nodes verlaufen.
Bild 008365c bringt außerdem zum Ausdruck, dass in einem Sub-
DODAG im Storing Mode des RPL eine Art Sub-DODAG gebildet DODAG
werden kann. In jedem Sub-DODAG fungiert ein Intermediate Node
mit einer P2P-spezifischen Routingtabelle quasi als lokaler Root
Node. Über diesen verläuft dann nicht nur die lokale P2P-
Kommunikation zwischen den End Nodes aus dem Sub-DODAG,
sondern auch die Kommunikation zum und vom zentralen Root
Node, über den man den Internetzugang herstellt.

16
 R
► RPL

Multicasting Die beim RPL möglichen Betriebsarten verlangen, dass man beim
Aufbau eines DODAG in der Nachricht DIO darauf verweist, welche
Betriebsart jeweils unterstützt werden soll. Hierfür dient die Angabe
MOP (Mode of Operation) im DIO-Header (Bild 008372). Bezüg-
lich der Unterstützung von Multicast im DODAG sei angemerkt,
dass man bei der Betriebsart Storing Mode mithilfe der Angabe
MOP im DIO-Header noch zwischen zwei Möglichkeiten unter-
scheidet, nämlich, ob dabei das Multicasting unterstützt wird (MOP
= 3) oder nicht (MOP =2).

Funktionales Modell von RPL

Das RPL ist zu einem sehr komplexen, ausbaufähigen „funktionellen
Gebilde“ herangewachsen. Es wird noch weiterentwickelt und dem-
entsprechend auch funktionell erweitert. Aus diesem Grund ist das
RPL nicht mehr nur ein einziges Protokoll, sondern wie schon ein-
gangs festgestellt in Wirklichkeit ein Framework (Rahmenwerk), das
in sich mehrere Funktionsmodule integriert. Wie außerdem bereits
angesprochen, ist das Routing im IoT und besonders in dessen aus
LLNs bestehenden Teilen ein vielschichtiger, quasi kontinuierlicher
Prozess der Optimierung von Routen. Dies nimmt entscheidenden
Einfluss auf die Struktur und die Komplexität des RPL. Bild 008366
zeigt das funktionale Modell des RPL und vermittelt zugleich die
hohe Komplexität dieses Routingprotokolls.

Funktions- Das hier gezeigte funktionale Modell präsentiert, welche Funktions-

komponenten komponenten zum RPL gehören. Von zentraler Bedeutung sind
dabei insbesondere folgende Komponenten, deren Aufgaben kurz
vorgestellt werden sollen:
 Path Calculation Algorithm
Diese, auch als Path Selection Algorithm bezeichnete Funkti-
onskomponente, repräsentiert die Prinzipien, nach denen optima-
le Routen (Datenpfade) ermittelt/berechnet und ausgewählt wer-
den.
 Packet Forwarding Scheme
Hierbei handelt es sich um ein Schema, nach dem die Weiterlei-
tungstabellen (Forwarding Tables) in Routern aufgebaut und
entsprechend Datenpakete weitergeleitet werden.
 Estimation of Routing Metric(s)
Hierunter fallen Funktionen, die man zur kontinuierlichen Be-

17
R
► RPL

wertung/Schätzung von Routing-Metriken benötigt, wie z.B. zur

Schätzung der Metrik ETX von Links (Bild 008364b).
 Rerouting & Maintaining Support
Der Routing-Plan in einem LLN in Form eines DODAG muss
einerseits aufrechterhalten werden (Maintaining), andererseits
muss der DODAG durch Rerouting laufend an neu entstandene
Routingsituationen im LLN angepasst werden. Um die Funktio-
nalität „Rerouting & Maintaining“ beim RPL zu unterstützen,
sind weitere ergänzende Funktionskomponenten notwendig, u.a.
jene, die speziell für die Unterstützung von Mobility, Multipa-
thing, Broadcast, Multicasting und Security konzipiert wurden.

Bild 008366: Funktionales RPL-Modell mit seinen Komponenten

und ihren Aufgaben
LBR: LLN Border Router
WSN: Wireless Sensor Network

18
 R
► RPL

Optimie- Durch das Zusammenwirken aller Funktionskomponenten des RPL

rungsprozess werden die ständig laufende Ermittlung optimaler Routen, deren
Aufrechterhaltung (Maintaining) und Anpassung (Rerouting) an
veränderliche Beschränkungen (Constraints) und andere routing-
relevante Bedingungen in LLNs realisiert. Wie Bild 008366 veran-
schaulicht, bedeutet dies in Wirklichkeit, dass beim Aufbau des
DODAG und danach auch bei dessen Anpassung an alle routing-
relevanten Veränderungen im LLN unter Berücksichtigung von
Constraints verschiedener Art ein Optimierungsprozess stattfindet.
Das Ziel dieses Optimierungsprozesses definiert die entsprechende
Objective Function (OF) des RPL und diese bestimmt dabei auch die
Art und Weise der Route Selection. Da die Routing-Metriken als
Argumente der Objective Function zu betrachten sind, liefern ihre
OF-Werte eine Aussage über die Qualität/Güte von Routen. Aus
diesem Grund hat die Objective Function eine große Auswirkung auf
die Struktur des DODAG.

Standard-OFs OF0 und MRHOF

Wie schon erwähnt hat die IETF bis heute zwei Objective Functions
für den Einsatz im RPL als Internet Standards spezifiziert, die nun
etwas näher betrachtet werden sollen:
 OF0
Bei der in RFC 6552 beschriebenen OF0 (Objective Function
Zero) wird die Qualität einer Route in der Anzahl von Hops, ge-
nau genommen in der Anzahl von Links der Route, angegeben.
Dies bedeutet, dass die Metriken aller Links in einem LLN den
Wert 1 haben, also Hop = 1 bzw. Rank = 1 ist. Bei OF0 ent-
spricht der Rank-Wert 1 einem Hop. OF0 eignet sich eigentlich
nur zum Einsatz in LLNs, in denen die routenbeteiligten Links
sehr zuverlässig und hinsichtlich ihrer Güte in etwa vergleichbar
sind. Man kann OF0 aber auch zum Testen der Konnektivität in
einem LLN verwenden, z.B. beim Aufbau eines DODAG, um zu
prüfen, welche End Nodes (Sensoren, Aktoren) überhaupt vom
Internet über den Root Node erreichbar sind.
 MRHOF
Mit der in RFC 6719 beschriebenen MRHOF (Minimum Rank
with Hysteresis Objective Function) wurde eine flexible, fast
universelle Objective Function nach der Idee konzipiert, dass die
Art der Metriken von Links bzw. Nodes, die ihr als Argumente

19
R
► RPL

dienen, nicht von vornherein festgelegt ist, sondern in der Opti-

on „DAG Metric Container“ der Nachricht DIO inklusive be-
rücksichtigender Beschränkungen spezifiziert wird.
In Bild 008368 wird gezeigt, wie diese Spezifikation erfolgen
kann. Es wird aber empfohlen, bei MRHOF die Link-Metrik
ETX zu verwenden; auf die Besonderheiten dieser Metrik wird
im Weiteren noch kurz eingegangen.
Die Güte von Routen wird bei der MRHOF in Rank-Werten an-
gegeben.

Routing Metrics und Constraints

Die allgemeine Intention des Routingprotokolls RPL ist es, in einem
LLN einen – im Sinne der geltenden Objective Function – optimalen
und alle Constraints erfüllenden DODAG einzurichten und diesen
danach durch das Rerouting an im Laufe der Zeit zufällig bezie-
hungsweise auch nicht zufällig entstandene neue Routingsituationen
im LLN anzupassen. Um diese Herausforderung zu meistern, müssen
einerseits verschiedene, dem Routing-Ziel angepasste Routing Met-
rics genutzt werden können und andererseits diverse Constraints
berücksichtigt und somit auch erfüllt werden. Demzufolge ist der
eingerichtete DODAG der „Beste“, der im Sinne der verwendeten
Objective Function optimal ist und alle Constraints erfüllt.

Es sei hervorgehoben, das beim RPL alle Parameter als Metriken Routing Met-
infrage kommen, die als Maß zur Bewertung der Qualität von Links rics
bzw. Nodes dienen können. Dabei unterscheidet man zwischen
Link-based und Node-based Metrics. Bild 008367 zeigt eine Auflis-
tung jener Metriken, welche bereits ausführlich untersucht worden
sind und sich für den Einsatz im RPL als besonders gut geeignet
erwiesen haben.

Für die vollständige Darstellung siehe: Dreibändiges Loseblatt-

werk (Print und CD-Version) mit Update-Dienst:
"Protokolle und Dienste der Informationstechnologie"
Aktualisierungszyklus: 2 Monate
WEKA Media, Kissing
ISBN-13: 978-3827691422, Bestell-Nr. OL9142J
http://shop.weka.de/protokolle-und-dienste-der-
informationstechnologie-online

20
 R
► RPL

Literatur
[1] Anand, M., C., Radhesh; Tahiliani, Mohit, P.: mRPL++:
Smarter-HOP for optimizing mobility in RPL, IEEE Region 10
Symposium (TENSYMP), May 2016; DOI:
10.1109/TENCONSpring.2016.7519374
[2] Badach, Anatol; Hoffmann, Erwin: Technik der IP-Netze.
Verlag Hanser, 2015, ISBN-13: 978-3446439764
[3] Djedjig, Nabil; Tandjaoui, Djamel; Medjek, Faiza: Trust-based
RPL for the Internet of Things, 20th IEEE Symposium on
Computers and Communication (ISCC), July 2015; DOI:
10.1109/ISCC.2015.7405638
[4] Djedjig, Nabil; Tandjaoui, Djamel; Medjek, Faiza; Romdhani,
Imed: New Trust Metric for the RPL Routing Protocol, 8th In-
ternational Conference on Information and Communication
Systems, Apr. 2017; DOI: 10.1109/IACS.2017.7921993
[5] Fotouhi, Hossein; Moreira, Daniel; Alves Mário: mRPL: Boost-
ing Mobility in the Internet of Things, Ad Hoc Networks, Vol.
26, Mar. 2015; DOI: 10.1016/j.adhoc.2014.10.009
[6] Fotouhi, Hossein; Moreira, Daniel; Alves Mário; Yomsi, Pat-
rick, Meumeu: mRPL+: A mobility management framework in
RPL/6LoWPAN, Computer Communications, Vol. 104, May
2017; DOI: 10.1016/j.comcom.2017.01.020
[7] Glissa, Ghada; Rachedi, Abderrezak; Meddeb, Aref: A secure
routing protocol based on RPL for Internet of Things, IEEE
Global Communications Conference (GLOBECOM), Dec.
2016; DOI: 10.1109/GLOCOM.2016.7841543
[8] Kim, Hyung-Sin; Paek, Jeongyeup; Bahk, Saewoong: QU-RPL:
Queue Utilization based RPL for Load Balancing in Large Scale
Industrial Applications, IEEE International Conference on
Sensing, Communication, and Networking (SECON), June
2015; DOI: 10.1109/SAHCN.2015.7338325
[9] Lodhi, M, Ali; Rehman, Abdul; Khan, Meer, M.; Hussain,
Faisal, Bashir: Multiple Path RPL for Low-Power Lossy Net-
works, IEEE Asia Pacific Conference on Wireless and Mobile,
Aug. 2015; DOI: 10.1109/APWiMob.2015.7374975
[10] Lorentea, Guillermo, Gastón; Lemmens, Bart; Carlier, Matthias;
Braeken, An; Steenhaut, Kris: BMRF: Bidirectional Multicast

21
R
► RPL

RPL Forwarding, Ad Hoc Networks, Vol. 54, Jan. 2017; DOI:

10.1016/j.adhoc.2016.10.004
[11] Schulte, Heinz (Hrsg.): Protokolle und Dienste der Informa-
tionstechnologie. WEKA Verlag, ISBN-13: 978-3824540662 –
siehe IoT und 6LoWPAN

Badach, Anatol: Internet of Things – IoT

DOI: 10.13140/RG.2.1.5157.5527
https://www.researchgate.net/publication/281005777_Internet_of_Thing
s_-_IoT
Badach, Anatol: 6LoWPAN – IPv6 over Low power Wireless
Personal Area Network
https://www.researchgate.net/publication/319205134_6LoWPAN_-
_IPv6_over_Low_power_Wireless_Personal_Area_Network

22

View publication stats