RPL-BIERCisco Systems, IncBuilding D45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis06254FRANCE+33 497 23 26 34pthubert@cisco.com
Routing
ROLLThis specification extends RPL to provide unicast and multicast routing
based on bitStrings such as used in Bit Index Explicit Replication and its
source-routed Traffic Engineering variant, which correspond to RPL storing
and non-storing modes respectively.
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.
In order to cope with lossy transmissions, RPL forms Direction-Oriented
Directed Acyclic Graphs (DODAGs) that provide multiple forwarding solutions
to most of the intermediate hops.
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 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.
RPL enables various trade-offs between routing stretch, amount of
routing state and packet size, with the introdution of different modes of
operation (MOPs):
With Reactive Discovery of Point-to-Point (P2P) Routes (aka on-demand)
,
a limited number of routes are optimized on-demand, between select pairs of
devices for which a service with some particular characteristics is needed.
In Storing mode of operation (aka storing mode), Multipoint to Point
(MP2P) routes from the LLN nodes to the root and Point to Multipoint (P2MP)
routes from the root to the LLN nodes are optimized, but P2P routes
between LLN nodes are stretched via a common parent. In storing mode, RPL
requires that nodes maintain routing information for the maximum number of
child nodes in their sub-DODAG. If a network is composed of similar nodes,
this means that each node should be able to store a number of routes that is
in the order of the total number of nodes in the network.
In Non-Storing mode of operation (aka non-storing mode), MP2P and P2MP
routes are also optimized, but downwards routes can only be computed by the
root and P2MP forwarding relies on strict source-routing. This increases the
size of the packets and limits the depth of the DODAG. The non-storing mode
also results in additional stretch for P2P routes, whereby all packets must
transit via the root following the default route all the way up, to be then
source-routed down.
In order to alleviate the issues above and improve the existing multicast
operations, this specification introduces the use of bitStrings in RPL LLNs.
BitStrings are already used in the art as a datapath analog to one or
more IPv6 addresses:
With the Bit Index Explicit Replication (BIER), introduced in the
"BIER Architecture", each
it in a bitStrings represents a particular destination. This specification
introduces a RPL-BIER storing mode that applies BIER operations to RPL
storing mode.
"Traffic Engineering for Bit Index
Explicit Replication" (BIER-TE) adds support for Traffic Engineering
by explicit hop-by-hop forwarding and loose hop forwarding of packets along
a unicast route. With BIER-TE, each bit in a bitStrings represents a
particular intermediate link. This specification introduces a RPL-BIER
non-storing mode that applies BIER-TE operations to RPL non-storing mode.
This specification provides new signaling in RPL to enable RPL-BIER
operations. In addition to classical bitStrings, this specification proposes
an new technique that derives from Bloom Filters. This technique provides
elasticity to the size of the bitString, which is not constrained to a
fixed number of entries, and a trade-off between the number of bits that are
needed for routing and the chances to waste energy forwarding down a path
where no target exist. The Bloom Filters mechanism applies to RPL-BIER in
both modes of operations.
In order to carry routing information in a concise fashion in a Low-Power
Wireless Personal Area Network (6LoWPAN) for Route-Over use cases, the
6LoWPAN adaptation layer framework was extended with the 6LoWPAN Routing Header
(6LoRH) specification , which uses the 6LoWPAN
Paging Dispatch .
The original specification includes the formats necessary for RPL such as
the Source Route Header (SRH) and is intended to be extended for additional
routing artifacts. A companion document to this, the
"6loRH for BitStrings",
specification, proposes new 6LoRH formats to enable the concise encoding of
the BIER bitstrings and of the Bloom Filters described therein.
In the current practive of LLN networks, the non-storing mode is largely
favored, because it does not place a restriction on how large a network
formed of a particular device can become.
One major benefit of introducing bitStrings is that the amount of state that
is required for routing in storing mode is no more growing in the order of
the total number of nodes in the network but linearly with the number of
children attached to the RPL router.
In other words, the maximum number of children that a router is willing to
accept determines both the size of the Neighbor Cache for 6LoWPAN Neighbor
Discovery (6LoWPAN ND)
and the
size of the routing table that is required in RPL-BIER storing mode.
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" are defined in the
"RPL: IPv6 Routing Protocol for Low-Power and Lossy
Networks" specification.
The terms Bit-Forwarding Egress Routers (BFR), BFR-id and bitString are
defined in .
A bitString indicates a continuous sequence of bits indexed by an
offset in the sequence. The leftmost bit is bit 0 and corresponds to the
value 0x80 of the leftmost byte in the BitString.
With this specification, a bitString maybe used to encode one or more
unsigned integer(s) as a bit position in the bitString (bit-by-bit),
or a Bloom filter.
BIER and other bit-indexed methods that would leverage bitStrings will
generally require additional information in the packet to complement the
bitString. For instance, BIER has the concept of a BFR-id and an Entropy
value in the BIER header. Since those additional fields depend on the
bit-indexed method, they are expected to be transported separately from
the bitString. This specification concentrates on the bitString and a
group identifier which enables a network to grow beyond the size of one
bitString.
TBD Do we need entropy ?
This specification introduces two new modes of operation for RPL, the
RPL-BIER non-storing mode which is discussed in and the
RPL-BIER storing mode which is discussed in .
A new Control Message Options (CMO) is introduced to transport the bitStrings
in .In RPL-BIER modes of operation, one or more RPL Target Option are replaced
by a new BitString Information Option which represent the advertised target(s) by a combination of a bitString and control information.
In Non-Storing RPL-BIER, a bit in classical BIER bit-by-bit bitStrings
(see ) or a set of bits in a Bloom Filter
(see ) is associated to a next-hop from the
perspective of an intermediate router. RPL non-storing mode DAO messages are
used to advertise the relation between a target and its parent (transit)
directly to the root.
If multiple Targets Options were to be placed consecutively to factorize a
Transit Information Option (TIO) in a classical RPL non-storing mode DAO message, they are replaced by a single BIO with the aggregated bitString
that represents all these targets.
In RPL-BIER storing mode, a bit in classical BIER Bit-by-bit bitStrings
(see ) or a set of bits in a Bloom Filter
(see ) is associated to a final destination.
RPL storing mode DAO messages are used to advertise recursively the targets
to the parent(s) all the way to the root.
The BitString Information Option(s) in the DAO message contain collectively
an aggregated bitString that represents the advertising node and all of
its descendants.
Parents save the bitString per child, and use it to forward down the DODAG
as discussed in .
The Transit Information Option is not used. The lack of transit information
is compensated by a more frequent transmission of DAO messages and a full
use of the RPL data plane loop avoidance and inconsistency detection
mechanisms (section 11.2 of ), in collaboration
with a periodic 6LoWPAN ND (re)registration that maintains the 6LBR
and the root aware of which devices are actually present in the network
with the associated lifetime and sequence information.
Section 6.7 of specifies optional CMOs to be placed
in RPL messages such as the Destination Advertisement Object (DAO) message.
The RPL Target Option and the Transit Information Option (TIO) are such
optional fields; the former indicates a node to be reached and the latter
specifies a parent that can be used to reach that node. Options may be
factorized; one or more contiguous TIOs apply to the one or more contiguous
Target options that immediately precede the TIOs in the RPL message.
This specification introduces a new CMO, the BitString Information option
(BIO). A BIO is used as an alterate to one or more Target Option(s) in
Storing and non-storing mode DAOs usig bit-by-bit bitStrings, and its format
is as follows:
0x0B (to be confirmed by IANA)In bytes; variable, depending on the Type.Indicates the size of the bitString field as
indicated in below.
BitString TypeBitString Size15 8 bits16 16 bits17 48 bits18 96 bits19160 bits8-bit unsigned integer. The Group ID for
the bit-by-bit bitString.8 to 160 bits, depending on the Type.
It is noted that RPL does not provide a Duplicate Address Detection (DAD)
and relies on 6LoWPAN ND to ensure that addresses are unique within the network. For that purpose, a 6LoWPAN Border Router (6LBR) maintains the
list of addresses that are currently in use in the network that it serves.
In the case of a RPL LLN, the 6LBR is typically collocated with the RPL
root, and serves the RPL DODAG. With 6LoWPAN ND,
a Duplicate Address Request (DAR) / Duplicate Address Confirmation (DAC)
exchange is used to perform the DAD operation .
Scalability is achieved by federating multiple DODAGs with IPv6 Backbone
Routers (6BBRs) .
In that context, it makes sense to also leverage the 6LBR to ensure that a
tuple (groupID, bitString) is assigned unequivocally to an IPv6 address for
the bit-by-bit operation. This specification extends the role of a 6LBR to
1) assign the tuple to the IPv6 address and 2) resolve an IPv6 address into a
tuple. To achieve this, RFC 6775 is updated as follows:
A BIER Address Resolution (BAR) / BIER Address Confirmation (BAC) exchange
is introduced for the purpose of the bitString lookup operation
(see ).
A new Bit Position Option (BPO) is introduced to carry the corresponding bit position bitString in 6LoWPAN ND exchanges. The BPO is transported in
BAC, NA and DAC messages in response to BAR, NS and DAR messages,
respectively (see ).
This specification also extends the 6LoWPAN framework with the capability to
transform an address into a tuple (Control field, bitString) as part of
the 6LoWPAN Header Compression (6LoWPAN HC).
Since the 6LBR and the Header Compression functions are typically
collocated, the latter may exploit local tables built by the former to
map a destination IPv6 address into a bitString.
In storing mode, P2P stretched routing via a common parent can be obtained
if the destination is expressed as a tuple (Control field, bitString).
This can be achieved with a BAR/BAC exchange with the 6LBR.
In order to allocate and lookup a bitString, this specification
extends 6LoWPAN ND with the following new messages and formats.
The Bit Position Option (BPO) is intended to be used to return a bitString
and related information in 6LoWPAN ND BA, DAC and BAC messages with a Status of 0 indicating success, the NA and DAC messages transporting an
Address Registration Option (ARO) indicating the IPv6 address that is
mapped with the bit position. Its format is as follows:
Option Fields
38 (to be confirmed by IANA)8-bit unsigned integer. The length of the
option (including the type and length fields) in units of 8 bytes.
The Length MUST be set to 1.8-bit unsigned integer. The GroupID for
the bit-by-bit bitString.8-bit unsigned integer. The offset in the
the bit-by-bit bitString.For the multihop lookup exchanges between a 6LR that needs to perform a
Header Compression including the bitString for the destination, and its 6LBR, which knows if the mapping exists and what it is, this specification
introduces two new ICMPv6 message called the BIER Address Resolution
(BAR) and the BIER Address Confirmation (BAC). We avoid reusing the NS
and NA messages for this purpose, since these messages are not subject to
the hop limit=255 check as they are forwarded by intermediate 6LRs.
The BAR and BAC use the same ICMPv6 type value which this specification, allocates for a generic Address Mapping service, but use different Codes.
This is done to save addressable space in the ICMPv6 type values which is
getting crowded, and because it is expected that in the future, other
mapping techniques may be needed as well.
The Status field and Information Lifetime are not meaningful in the BAR
message. When and only when the BAC message carries a status of 0, indicating success, the Information Lifetime must contain valid information
and the message must carry a Bit Position Option.
Message Fields
160 (to be confirmed by IANA)8-bit unsigned integer. 1 for BAR and 2 for BAC.
Other values are reserved. The ICMP checksum. See .8-bit unsigned integer. Indicates the status of the
lookup in the BAC. See below.StatusDescription0Success1Looked-up Address not Found2..255Allocated using Standards Action
16-bit unsigned integer. The length of
time in units of 60 seconds (relative to the time the packet is received)
that this mapping information is valid. A value of all zero
bits (0x0) assumes a default value of 10,000 (~one week).128-bit field. Carries the IPv6 address that
is being mapped.This specification introduces two BitString formats, the bit-by-bit and the
Bloom Filter.
In the bit-by-bit case, each bit is mapped in an unequivocal fashion with a
single addressable resource in the network. In RPL-BIER storing mode, this is an IPv6 address as advertised in RPL storing mode DAO messages, whereas
in RPL-BIER non-storing mode, this is a parent-child relationship as
advertised in RPL non-storing mode DAO messages.
if every node in a large network is given one or more bits in a bit-by-bit
bitString, then the bitString may grow very large and lead to undesirably
large overhead in the data plane.
BIER allows to divide a potentially the very large abstract bitString into segments, aka groups, indexed by a groupID.
In the protocol elements that use a bitString, only the relevant group(s)
are transported, and the advertised bitString is in fact the segment that
corresponds to the groupID. It results that a bit position in the large
abstract bitString is advertised either as the tuple (groupID, segment) or
the tuple (groupID, bit position within segment).
For simplicity, when dealing with protocol elements, the specification uses the term bitString to refer to the tuple (groupID, segment) and a
bitwise operation between bitStrings is really a bitwise operation between
segments of a same groupID.
TBD: do we allow multiple (groupID, bitString) tuples in one packet?
Several methods may be used to associate a bit in a biString to an IPv6
address. In order to guarantee interoperability, this specification
RECOMMENDS that all implementations provide at least the method described
therein.
With 6LoWPAN ND, a 6LoWPAN Node (6LN) registers with address(es) to one or
more 6LoWPAN Router to perform Duplicate
Address Detection (DAD). As part of the DAD process, the 6LN validates
that a Global Unicast Address (GUA) or a Unique Local Address (ULA) is
effectively unique using a unicast DAR/DAC exchange with the 6LBR (this
procedure is updated in ).
In a network that supports this specification, the 6LBR maintains a
configurable number of groups (up to 32, indexed by groupID), and for each
group, it maintains a pool of free bit positions. Upon a new registration,
the 6LBR selects a groupID and a free bit position and associates it to the
IPv6 address.
The bitString Size in any given group should be configurable. The policy for selecting the groupID for a new registration is left to implementation.
It is noted that in large networks that require multiple groups, associating
groups with immediate children of the root may be an option to limit the
number of groups that the RPL routers must be aware of.
If the 6LBR accepts the registration, then it returns a DAC message with a
status of 0 indicating success, adding
a 6LoWPAN ND Bit Position Option to the DAC
message to indicate the groupID and bit.
The 6LR maintains a binding cache entry (BCE) for the 6LN based on
successful DAC messages. With this specification, the 6LR also stores the
matching between the address and the bitString and uses it for searching
its children when forwarding packets in non-storing mode (see
).
If the 6LN child does not support the BIER encoding
(e.g.), then the packet is
converted in a format that the child supports
(e.g.).
BitStrings are aggregated by a 'OR' operation so that all the bits that
are set in either bitString is set in the resulting bitString.
In the concise form of a tuple (groupID, bitString), the aggregation is
done on a group-by-group basis, between segments of a same group.
In RPL-BIER storing mode, the bit-by-bit BitStrings are passed from child to parent using DAO messages, in a fashion similar to RPL storing mode
.
The BitString Information option is used in
replacement of the Target option. A DAO message contains one BIO per
group, and the parent that receives the messages associates the BIO
information to the advertising child.
In order to build a DAO message, the parent regenerates its own BIO, one
per group, by aggregating the bitStrings from all of its children with its
own, and places the resulting BIOs in the DAO message.
Forwarding is based on matching a bitString in a packet with those of
children. For unicast packets, only one matching child gets the packet. For
multicast packets, all matching children get a copy. Matches are found by
scanning all children and performing bitwise operations as follows.
In order to search for a match, a reference bitString is initialized with
the destination bitString in the packet.
A match is found with a child if the bitwise 'AND' between the reference
bitString and the bitString stored for that child does not result
in a NULL bitString of all zeroes.
In non-storing mode, a packet is copied to all matching children, which
are found by trying all children.
In non-storing mode, if a child is selected for forwarding,
then an 'XOR' operation is performed between the reference bitString
and the bitString resulting from the 'AND' operation. If the 'XOR' operation
does not result in a NULL bitString, denoting that more children should get
the packet, then the result of the 'XOR' operation becomes the new
reference bitString and the search continues.
The 'XOR' operation allows to stop the search loop as soon as all matches
are found; it also avoids forwarding twice to a same destination along
different downwards path in the DODAG.
Multicast from the root to a a collection of target 6LNs can be made
reliable with the following operation:
A multicast packet is identified by a unique packetID which is also found
in the acknowledgments. The root signals the set of targets with a
destination bitString that has the bits set for each of them, and the
message is forwarded as described on .
Listeners acknowledge with an acknowledgment packet that contains the same
information, the packetID and the bitString representing the listener. The
bitStrings in acknowledgment packets are aggregated recursively on the way
back as indicated in .
The root aggregates the bitStrings from its children into one
acknowledgment bitString. It then checks that the acknowledgment bitString
is correct, by and 'AND' operation with the destination bitString that
should result in the acknowledgment bitString. If this is not the case, bits
that are set in the acknowledgment bitString and not in the destination
bitString are in the acknowledgment bitString.
The root generates the bitString of the devices that did not acknowledge the
multicast message by a bitwise 'XOR' operation between the destination
bitString and the acknowledgment bitString, and may use it to selectively
retry the multicast.
A Bloom Filter can be seen as an additional compression technique for the
bitString representation. A Bloom Filter may generate false positives,
which, in the case of BIER, result in undue forwarding of a packet down a
path where no listener exists.
As an example, the Constrained-Cast
specification employs Bloom Filters as a compact representation of a
match or non-match for elements in a set that may be larger than the number
of bits in the BitString.
In the case of a Bloom Filter, a number of Hash functions must be run to
obtain a multi-bit signature of an encoded element. This specification uses
the 5-bits Control field to signal an Identifier of the set of Hash functions
being used to generate a certain bitString, so as to enable the migration
from a set of Hash functions to the next.
TBDTBDThis document extends the IANA registry created by RFC 6550 for RPL
Control Codes as follows:CodeDescriptionReference0x0BbitStringThis documentThis document is updating the registry created by RFC 6550 for the RPL
3-bit Mode of Operation (MOP) as follows:
MOP valueDescriptionReference6RPL-BIER non-storing mode of operationThis document7RPL-BIER Storing mode of operationThis document