Showing papers by "Thomas Clausen published in 2015"
••
04 Mar 2015TL;DR: An extension of depth-first forwarding, denoted as DFF++, is proposed in this paper, in order to optimize the performance of DFF by way of introducing a more efficient search ordering.
Abstract: This paper introduces extensions and applications of depth-first forwarding (DFF)—a data forwarding mechanism for use in unreliable networks such as sensor networks and Mobile Ad hoc NETworks with limited computational power and storage, low-capacity channels, device mobility, etc. Routing protocols for these networks try to balance conflicting requirements of being reactive to topology and channel variation while also being frugal in resource requirements—but when the underlying topology changes, routing protocols require time to re converge, during which data delivery failure may occur. DFF was developed to alleviate this situation: it reacts rapidly to local data delivery failures and attempts to successfully deliver data while giving a routing protocol time to recover from such a failure. An extension of DFF, denoted as DFF++, is proposed in this paper, in order to optimize the performance of DFF by way of introducing a more efficient search ordering. This paper also studies the applicability of DFF to three major routing protocols for the Internet of Things (IoT), including the Lightweight On-demand Ad hoc Distance-vector Routing Protocol—Next Generation (LOADng), the optimized link state routing protocol version 2 (OLSRv2), and the IPv6 routing protocol for low-power and lossy networks (RPL), and presents the performance of these protocols, with and without DFF, in lossy and unreliable networks.
9 citations
01 Dec 2015
TL;DR: This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
Abstract: This specification describes an extension to the Optimized Link State
Routing Protocol version 2 (OLSRv2) to support multiple routing
topologies, while retaining interoperability with OLSRv2 routers that
do not implement this extension. This specification updates RFCs 7188
and 7631 by modifying and extending TLV registries and descriptions.
8 citations
01 Mar 2015
TL;DR: This specification updates RFC6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", and RFC7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)" to permit retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold.
Abstract: The link quality mechanism of the MANET Neighborhood Discovery
Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the
measured link quality from that 1-hop neighbor is below an acceptable
threshold, while still retaining the corresponding link information as
acquired from HELLO message exchange. This allows immediate
reinstatement of the 1-hop neighbor if the link quality later improves
sufficiently. NHDP also collects information about symmetric 2-hop
neighbors. However it specifies that if a link from a symmetric 1-hop
neighbor ceases being symmetric, including while "ignored" as
described above, then corresponding symmetric 2-hop neighbors are
removed. This may lead to symmetric 2-hop neighborhood information
being permanently removed (until further HELLO messages are received)
if the link quality of a symmetric 1-hop neighbor drops below the
acceptable threshold, even if only for a moment. This specification
updates RFC6130 "Mobile Ad Hoc Network (MANET) Neighborhood Discovery
Protocol (NHDP)", and RFC7181 "The Optimized Link State Routing
Protocol version 2 (OLSRv2)" to permit retaining, but ignoring,
symmetric 2-hop information when the link quality from the
corresponding 1-hop neighbor drops below the acceptable threshold.
This allows immediate reinstatement of the symmetric 2-hop neighbor if
the link quality later improves sufficiently, thus making the
symmetric 2-hop neighborhood more "robust".
7 citations
01 Sep 2015
TL;DR: This document reorganizes the naming of already-allocated TLV types and type extensions in the "Mobile Ad hoc NETwork (MANET) Parameters" registries defined by RFC 5444 to use names appropriately to establish a policy for consistent naming of future TLV type and type extension allocations.
Abstract: This document reorganizes the naming of already-allocated TLV (type-
length-value) types and type extensions in the "Mobile Ad hoc NETwork
(MANET) Parameters" registries defined by RFC 5444 to use names
appropriately. It has no consequences in terms of any protocol
implementation. This document also updates the Expert Review
guidelines in RFC 5444, so as to establish a policy for consistent
naming of future TLV type and type extension allocations. It makes no
other changes to RFC 5444.
3 citations
09 Jan 2015
TL;DR: This document provides recommendations for jittering (randomly timing) of routing control message transmission, especially route request dissemination, in reactive protocols of Mobile Ad Hoc Networks to reduce the probability of collisions, decrease routing overhead, and help finding the optimum paths in the network.
Abstract: This document provides recommendations for jittering (randomly timing)
of routing control message transmission, especially route request
dissemination, in reactive protocols of Mobile Ad Hoc Networks, to
reduce the probability of collisions, decrease routing overhead, and
help finding the optimum paths in the network.
2 citations
••
01 Sep 2015TL;DR: This paper presents an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2), providing support for source-destination routing, and provides routes for data packets based also on the source prefix announced by the gateways.
Abstract: Typical routing protocols maintain, in their RIB (Routing Information Base) entries permitting destination-based forwarding: for a given data packet, the choice of next hop is a function of the destination address only. However, in deployments where a given network is multi-homed, and where ingress filtering is commonly applied, a routing protocol is required to be able to provide routes so as to forward a data packet (i) to the destination address of the data packet, while (ii) routing through the gateway for which the source address of the data packet is topologically correct. This is called source-destination routing. This paper presents an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2), providing support for such source-destination routing. In a multi- homed network, this OLSRv2 extension provides routes for data packets based also on the source prefix announced by the gateways. The extension is interoperable with unextended OLSRv2. The performance of this extension is quantified by way of simulation studies.