RPL-BIERCisco Systems, IncBuilding D45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis06254FRANCE+33 497 23 26 34pthubert@cisco.com
Routing
ROLLThis specification updates RFC 6550 and RFC 6775 unicast
routing service in a RPL domain to 6LoWPAN ND nodes that do not participate
to the routing protocol.
The design of Low Power and Lossy Networks (LLNs) is generally focused on
saving energy, which is the most constrained resource of all. Other design
constraints, such as a limited memory capacity, duty cycling of the LLN
devices and low-power lossy transmissions, derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power
and Lossy Networks" (RPL) to provide routing services
within such constraints.
RPL is a Distance-Vector protocol, which, compared to link-state protocols,
limits the amount of topological knowledge that needs to be installed and
maintained in each node.
RPL also leverages Routing Stretch to reduce further the amount of control
traffic and routing state that is required to operate the protocol.
Finally, broken routes may be fixed lazily and on-demand, based on dataplane
inconsistency discovery, which avoids wasting energy in the proactive repair
of unused paths.
In order to cope with lossy transmissions, RPL forms Direction-Oriented
Directed Acyclic Graphs (DODAGs) using DODAG Information Solicitation (DIS)
and DODAG Information Object (DIO) messages. For most of the nodes, though
not all, a DODAG provides multiple forwarding solutions towards the Root of
the topology via so-called parents.
Because it is designed to adapt to fuzzy connectivity with lazy control, RPL
can only provide a best effort routability, connecting most of the LLN nodes,
most of the time.
RPL provides unicast and multicast routing services back to RPL-Aware nodes.
A RPL-Aware Node will inject routes to self using Destination Advertisement
Object (DAO) messages sent to either their parents in Storing Mode or to the
Root indicating their parent in Non-Storing mode.
This process effectively forms a DODAG back to the device that is a subset of
the DODAG to the Root with all links reversed.
The IPv6 Neighbor Discovery (IPv6 ND) Protocol (NDP)
suite defined for fast
media such a Ethernet, relies heavily on multicast operations for address
discovery and duplicate address detection (DAD).
"Neighbor Discovery Optimizations for 6LoWPAN networks"
(6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained LLNs.
In particular, 6LoWPAN ND introduces a unicast host address registration
mechanism that contributes to reduce the use of multicast messages that are
present in the classical IPv6 ND protocol. 6LoWPAN ND defines a new Address
Registration Option (ARO) that is carried in the unicast
Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between
the 6LoWPAN Node (6LN) and the 6LoWPAN Router (6LR).
6LoWPAN ND also defines the Duplicate Address Request (DAR) and Duplicate
Address Confirmation (DAC) messages between the 6LR and the 6LoWPAN Border
Router (6LBR).
In an LLN, the 6LBR is the central repository of all the registered addresses
in its domain.
RFC 6775 was further
updated with to enable mobility
and proxy operations; this latter update includes changes that are required
by this document. The update defines an Extended Address Registration Option
(EARO) to include a sequence counter called Transaction ID (TID), which maps
to the Path Sequence Field found in Transit Options in a RPL DAO messages.
When a routing protocol such as RPL is used to maintain reachability within a
Non-Broadcast Multi-Access (NBMA) subnet, Some nodes may act as routers and
participate to the routing operations whereas others may be plain hosts.
In 6LoWPAN ND terms, this means that 6LN that may also be a 6LR and manage
its own routing. Alternatively, it may rely on its 6LR to perform routing on
its behalf.
With this specification, a 6LN may declare itself as a router in the 6LoWPAN
ND exchange in order to declare that it will manage it own routing.
By default, the 6LN is considered as a plain host, and the 6LR that accepts
the registration will inject routing information on behalf of the 6LN in the
RPL domain.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”,
and “OPTIONAL” in this document are to be interpreted as described in
.
The Terminology used in this document is consistent with and incorporates
that described in Terms Used in Routing for Low-Power
and Lossy Networks (LLNs)..
Other terms in use in LLNs are found in
Terminology for Constrained-Node Networks.
The term “byte” is used in its now customary sense as a synonym for “octet”.
"RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO and DIS
messages are defined in the
"RPL: IPv6 Routing Protocol for Low-Power and Lossy
Networks" specification.
This document specifies a new behavior whereby a 6LR injects DAO messages
for unicast addresses registered through the updated 6LoWPAN ND
on behalf of 6LN nodes that are
not RPL-aware.
Upon the renewal of a registration, this specification changes the behavior or
the 6LR. If a DAO is sent for the registered address, then the 6LR refrains
from sending a DAR message.
Upon reception of the DAO message initiated at the 6LR, the DAR/DAC exchange
happens between the RPL Root and the 6LBR, the Root acting as a proxy Root on
behalf of the 6LR to maintain an existing state in the 6LBR.
This document specifies a new flag in the EARO option, the 'R' flag,
used by the registering node to indicate that the 6LN that performs the
registration is a router and that it handles its reachability.
Setting the 'R' flag effectively suppresses the behavior defined in this
specification whereby the 6LR that processes the registration advertises the
registered address in DAO messages and bypasses the DAR/DAC process for the
renewal of a registration.
This document also specifies a keep-alive DAR message that the RPL Root may
use to maintain an existing state in the 6LBR upon receiving DAO messages.
The DAR message may only act as a refresher and can only update the Lifetime
and the TID of the state in the 6LBR.
This document introduces a new 'R' flag in the EARO option, as follows:
33
8-bit unsigned integer.
The length of the option (including the type and length fields) in units
of 8 bytes.
Defined in and updated in
.
This field is unused. It MUST be initialized to zero by the sender and
MUST be ignored by the receiver.
When set, this flag indicates that the registering node is a router
that handles it reachability.
If the 'R' flag is not set, the registering node expects that the 6LR
ensures reachability for the registered address.
In the context of this specification, this means that the 6LR will
advertise the registered address in the RPL domain.
-->
Defined in .
Defined in .
Defined in and updated in
.
This specification does not alter the operation of a 6LowpAN ND-compliant 6LN,
which is expected to operate as follows:
The 6LN obtains an IPv6 global address, for instance using autoconfiguration
based on a Prefix Information Option (PIO)
found in a Router Advertisement message
or by some other means such as DHCPv6 .
Once it ha formed an address, the 6LN (re)registers its address periodically,
within the Lifetime of the previous registration, as prescribed by
.
Upon each consecutive registration, the 6LN increases the TID field.
The 6LN MAY register to more than one 6LR at the same time. In that case, a
same value of TID is used for each registration.
The 6LN MAY use any of the 6LRs to which it register to forward its packets.
Also as prescribed by ,
the 6LR generates a DAR/DAC message upon reception of a valid NS(EARO)
message for a new registration. If the exchange succeeds, then
the 6LR installs a Neighbor Cache Entry (NCE).
At this stage, and upon each NS(EARO) received afterwards that maintain the
NCE in the 6LR; if the 'R' flag was set in a NS(EARO) message,
the 6LR refrains from injecting the registered address into RPL; else
the 6LR SHOULD redistribute the registered address into RPL by sending
a DAO message on behalf of the 6LN.
The DAO message advertising the registered address MUST be constructed as
follows:
The registered address is placed in a RPL Target Option in the DAO
message as the Target Prefix, and the Prefix Length is set to 128
the External 'E' flag in the Transit Information Option (TIO)
associated to the Target Option is set to indicate that the 6LR redistributes
an external target into the RPL network
the Path Lifetime in the TIO is computed from the Lifetime in the EARO Option
to adapt it to the Lifetime Units used in the RPL operation.
the Path Sequence in the TIO is set to the TID value found in the EARO option.
Additionally, in Non-Storing Mode the 6LR indicates one of its global IPv6
unicast addresses as the Parent Address in the TIO.
If a 6LR receives a valid NS(EARO) message with the 'R' flag set and the 6LR
was redistributing the registered address due to previous NS(EARO) messages
with the flag not set, then it MUST stop redistributing the address.
It is up to the registering node to maintain the corresponding route from then
on, either keeping it active by sending further DAO messages, or destroying
it using a No-Path DAO.
Upon reception of a DAO message that creates or updates an existing RPL state,
the Root notifies the 6LR using an internal API if they are collocated, or
a proxied DAR/DAC exchange on behalf of the registering node if they are
separated.
In the latter case, the DAR message MUST be constructed as follows:
The registered address from in the Target Option is placed in the
Registered Address field
the Owner Unique ID field is set to all ones to indicate that it is not
provided
the Registration Lifetime in the DAR message is adapted from the Path Lifetime
in the TIO.
the TID value is set to the Path Sequence in the TIO.
Upon a status in a DAC message that is not "Success", the Root MAY destroy
the formed paths using a No-Path DAO downwards as specified in
.
In Non-Storing Mode, the outer IPv6 header that is used by the Root to
transport the source routing information in data packets down the DODAG has
the 6LR that serves the 6LN as final destination. This way, when the final
6LR decapsulates the outer header, it also removes all the RPL artifacts
from the packet.
Upon reception of a DAR message with the Owner Unique ID field is set to all
ones, the 6LBR checks whether and entry exists for the
and computes whether the TID in the DAR message is fresher than that in the
entry as prescribed in .
If the entry does not exist, the 6LBR does not create the entry, and answers
with a Status "Removed" in the DAC message.
If the entry exists but is not fresher, the 6LBR does not update the entry, and answers
with a Status "Success" in the DAC message.
If te entry exists and the TID in the DAR message is fresher, the 6LBR
updates the TID in the entry, and if the
lifetime of the entry is extended by the Registration Lifetime in the DAR
message, it also updates the lifetime of the entry.
In that case, the 6LBR replies with a Status "Success" in the DAC message.
TBDTBD
This specification has no requirement on IANA.
TBDIEEE Standard for Local and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)
IEEE standard for Information Technology