JeongGil Ko1, Jongsoo Jeong2, Jongjun Park1, Jong Arm Jun1 and Naesoo Kim1 1IoT Architecture Research Team, Electronics and Telecommunications Research Institute, Korea

2Real-time SW Research Team, Electronics and Telecommunications Research Institute, Korea {jeonggil.ko, jsjeong, juny, jajun, nskim}@etri.re.kr

Introduction

Towards Full RPL Interoperability: Addressing the Case with Downward Routing

In this work we point out the issue of the IETF RPL routing protocol’s two different downward routing schemes not being able to interoperate with each other. This problem is less of an issue when low-power and lossy networks (LLNs) are deployed homogeneously but with the industrial kickoff and large scale deployments, the interoperability of heterogeneous standards-compliant implementations will become a significant issue. To accomplish this, we suggest some changes to the current RFC 6550. We show, with two different LLN IPv6 implementations in TinyOS and NanoQplus, that our suggestions help different implementations to successfully exchange point-to-point messages that require downwards routing.

Two types of RPL downwards routing modes

Storing mode Non-storing mode

DAO Hop-by-hop (to the DAO parents)

End-to-end (to the DODAG root

directly)

Downward Packet Format

Routing Table

Each node (distributed) Only root (centralized)

1. New MOP: Hybrid Mode with Storing or Non-storing Features

2. Storing mode nodes should be capable of adding and understanding SRHs when needed.

3. All DAO messages should be forwarded on a hop-by-hop basis rather than end-to-end to the DODAG root.

4. Parent Address field should be specified in the transit information option of the DAOs.

5. Optionally, nodes should indicate whether they are a route storing node or not in the DAO base message.

Making Different RPL Modes Interoperate

Evaluation

IPv6 RPL Opt. Data IPv6 SRH Data

Operation Mode ROM RAM

NanoQplus MOP 1 to 4 (Non-Storing)

+0.18 KB +0 KB

TinyOS MOP 2 to 4 (Storing)

+1.66 KB +0.10 KB

Topology for interoperability testing and PRR with and without our proposed changes.

Memory footprint increases for TinyOS and NanoQplus nodes

Simulation setup • Simulator: Cooja Contiki Simulator • RPL Objective Function: OF0 • RPL DAO period: 1 packet / 30 seconds • The root (TinyOS) sends packets periodically

each second while changing destination of the packet sequentially.

Results • No Interoperability Support: ~25 % PRR • Interoperability Support: ≈ 100% PRR • Memory footprints increase only minimally

compared to non-interoperable MOPs.

Root: purple TinyOS: green NanoQplus: yellow

Common Parent

Destination Source

Root

Destination Source

Root

Storing mode node

Storing mode node

Non-storing mode node

Non-storing mode node

Non-storing mode node

Root (Storing mode)

Storing mode node

Storing mode node

Non-storing mode node

Non-storing mode node

Non-storing mode node

Root (Hybrid mode)

Mixture of storing and non-storing nodes can partition a single network.

Minimal changes to RFC 6550 allow efficient interoperation of different modes.

In RFC 6550, when a RPL node joins a network with a different MOP, it may only join the network as a leaf node, which is not allowed to forward others’ packets. While this is a safe decision, it limits the benefits and applications that interoperating RPL systems can introduce

• Hop-by-hop DAO transmission allows intermediate storing mode nodes maintain sub-DODAG routes.

• Storing mode nodes can forward packets to non-storing mode nodes. Also, they can attach SRH before forwarding if needed.