Phil
3. Protocol Model
The aim of this section is to describe RPL in the spirit of
[RFC4101]. Protocol details can be found in further sections.
3.1 Overview
Each RPL instance constructs a routing topology optimized for a certain
Objective
Function (OF). An instance may provide routes to certain destination
prefixes.
A single RPL instance consists of one or more DAG roots. These roots may
operate independently, or may coordinate over a non-RPL backchannel.
Each root
has a unique identifier, such that nodes can identify the root of a route.
3.1.1: Multipoint-to-Point Traffic
Multipoint-to-Point (MP2P) is a dominant traffic flow in many
LLN applications ([I-D.ietf-roll-building-routing-reqs],
[I-D.ietf-roll-home-routing-reqs], [RFC5673], and [RFC5548]). The
destinations of MP2P flows are designated nodes that have some application
significance, such as providing connectivity to the larger Internet or
core private IP network. RPL supports MP2P traffic by allowing MP2P
destinations to be DAG roots.
3.1.2 Point-to-Multipoint Traffic Flows
Point-to-multipoint (P2MP) is a traffic pattern required by several
LLN applications[cite]. RPL supports P2MP traffic by using a destination
advertisement mechanism that sets up routes toward destination prefixes
and
away from roots. Destination advertisements can update routing tables as
the underlying DAG topology changes.
3.1.3 Point-to-Point Traffic Flows
RPL DAGs provide a basic structure for point-to-point (P2P) traffic.
For a RPL network to support P2P traffic, a root must be able to
route packets to a destination. Nodes within the network may also
have routing tables to destinations. A packet flows towards a root
until it reaches a node that has a known route to the destination.
RPL supports the case where a P2P destination is a `one-hop' neighbor.
RPL neither specifies nor precludes additional mechanisms for
computing and installing more optimal routes to support arbitrary P2P
traffic.
3.2. DAG Construction and the DAG Information Object (DIO)
RPL creates minimum cost routes to DAG roots. RPL nodes construct these
DAGs through DAG Information Object (DIO) messages.
A DIO identifies the DAG root, the Objection Function (OF) of the DAG,
the position of the transmitter within the DAG, and other routing
information. RPL uses DIOs to establish and maintain routes. RPL
adapts the rate at which nodes send DIOs. When a DAG is inconsistent
or needs repair, RPL sends DIOs more frequently. As the DAG
stabilizes, the DIO rate tapers off, reducing the maintenance cost
of a steady and well-working DAG.
3.2.1 Grounded and Floating DAGs
DAGs can be grounded or floating. A grounded DAG that offers
connectivity to
to an external routed infrastructure. A floating DAG offers no such
external connectivity, and provides routes only to nodes within the DAG.
3.2.2 Objective Function (OF)
The Objective Function (OF) conveys and controls the optimization
objectives of route selection within a DAG. The Objective Function
defines the cost function a RPL instance uses to compute minimum
cost routes. Examples of simple optimization
functions include minimizing latency, maximizing throughput, or
minimizing energy spent. An Objective Code Poiint (OCP) specifies
the Objective Function of the DAG. Further details can be found in
[I-D.ietf-roll-routing-metrics].
This document describes a default OF, OF0 (designated by OCP value of
0x0000).
OF0 may be used to d code efine RPL behaviors in the case where a node
encounters a
DIO message containing a point that it does not support, if allowed by
policy. [I-D.ietf-roll-routing-metrics] contains additional OFs.
3.2.3 Administrative Preference
An DAG instance may specify that some DAG roots should be used over others
through an administrative preference. Administrative preference offers a
way to control traffic and engineer DAG formation in order to better
support application requirements or needs.
3.2.4 Distributed Algorithm Operation
A high level overview of the distributed algorithm which constructs
the DAG is as follows:
o Some nodes are DAG roots, with associated administrative preferences.
o Nodes advertise their presence, DAG instance, and routing cost
with DIO messages sent to the link-local multicast address.
o Nodes listen for DIOs and use their information to join a new DAG,
maintain their position within an existing DAG, or improve their
position within an existing DAG as according to the DAG's Objective
Function.
o The nodes provision routing table entries for the destinations
specified by the DIO towards their DAG Parents. Nodes may
provision a DAG Parent as a default gateway.
o RPL supports both global and local DAG repair. Each DAG root
maintains a sequence number. Incrementing this sequence number
institutes a global repair, allowing nodes to choose an arbitrary
new position within a DAG.
o Nodes may locally repair or change the topology, moving within
the DAG without requiring a global repair event. The OCP
specifies the limits of this local repair.
o Using both DIOs and possibly information in data packets,
RPL nodes detect possible routing loops. When a RPL node detects a
possible routing loop, it adapts its DIO transmission rate to
quickly apply these local repair to the topology. This process
and its limitations is discussed in greater detail in 3.4.
3.3 Outward Routes and the Destination Advertisement Object (DAO)
RPL uses DIO messages to establish Inward routes from nodes within the LLN
to DAG roots. It uses Destination Advertisement Object (DAO) messages
to establish Outward routes from DAG roots to nodes within the DAG. DAO
messages and Outward traffic are an optional feature for applications
that require P2MP traffic. DIO messages advertise whether a DAG
instance supports DAOs.
3.3.1 Destination Advertisement Object (DAO)
A Destination Advertisement Object conveys destination information
so that a root (and other nodes within the network) can establish Outward
routes. A DAO message includes prefix information to identify
destinations,
reverse route information to record routes, and information to
determine the
freshness of a particular advertisement. Nodes send DAOs Inward towards
DAG Roots.
Nodes that can maintain routing state may aggregate routes they
received in the DAOs they transmit. Nodes that cannot maintain
routing state forward DAOs toward the DAG Root and adds
the next-hop address to a Reverse Route Stack carried within
the DAO message.
3.3.2. `One-Hop' Neighbors
In addition to sending DAOs toward DAG roots, RPL nodes may periodically
emit a link-local multicast DAO message advertising available
destination prefixes. This mechanism allow provisioning a trivial
`one-hop' route to local neighbors.
3.4. Loop Detection and Limiting Local Repair
RPL nodes maintains route cost information within a DAG. Because links
may fail or change over time, nodes can move within a DAG. If routers
only move Inward, the DAG remains consistent. However, if a router moves
Outward, it can create a routing loop. RPL embeds information in data
packets that enable it to quickly detect potential loops and locally
repair
the DAG. A data packet includes the route cost metric of the transmitter:
if a router receives a packet from a router that advertises a cost lower
than its own, there may be a routing loop.
Allowing nodes to move Outward can, in the case of a Floating DAG,
lead to the count-to-infinity problem, where nodes continuously move
Outward as they search for a route to a DAG Root.
RPL allows a DAG Instance to specify the amount of local repair a
router may
apply. If a router is unable to find a valid route after this amount of
repair,
it marks itself as Floating until the DAG Root applies a global repair by
incrementing its sequence number. If the local repair limit is zero, then
a router cannot move Outward without a global repair. If the local repair
limit is infinity, then routers may locally repair freely and can suffer
from the count-to-infinity problem.
_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll
