The Internet of Things is a hot research topic right now. There are efforts to put the latest Internet protocol (IPv6) on small devices that connect to the Internet. Networks of these small devices, known as low power and lossy networks, and wireless sensor networks (WSNs), which are a subset of low power and lossy networks, are characterized by low power consumption, low power processing capabilities, and low memory requirements.

There are many uses for low power and lossy networks and WSNs, including applications in industrial, building, home automation, and urban environments. The Internet Engineering Task Force (IETF) has chartered a working group for routing over low power and lossy networks (ROLL). The ROLL project has identified and characterized the routing requirements for those applications. As a result, in March 2012, the IETF published Request for Comments (RFC) 6550, which contained specifications for RPL, an IPv6 routing protocol for low power and lossy networks. RPL has become the de facto routing protocol for low power and lossy networks. Until that publication, there was no standardized protocol for low power and lossy networks. This has led to the design of new protocols and the redesign of existing ones. In fact, even before RPL was published, researchers (including me and the team I’m working with) had started to implement and use it.

Presently, there are a few RPL implementations in both real network nodes and simulation. ContikiRPL (Contiki OS implementation), and TinyRPL (TinyOS implementation) operate on both real and simulation networks, while OMNeT++/Castalia is an example of a simulation implementation. The authors of this paper state that simulating routing protocols is a difficult task, and although Contiki and TinyOS have tools to perform network simulations, those tools (Cooja and TOSSIM, respectively) are hard to modify, whether you want to add new features or modify existing ones. The Castalia implementation is, for now, very limited.

Until recently, one of the most commonly used network simulators was ns-2. However, since ns-2 has no graphical user interface (GUI), would-be simulators are forced to learn a scripting language, queueing theory, and modeling techniques. For that reason, ns-3 was developed and is now widely used in research. Initially, low power and lossy networks were not implemented in ns-3; developers focused on implementing 6LoWPAN and IEEE 802.15.4, which are key technologies for WSNs. To overcome the issues of Cooja, TOSSIM, and Castalia, the authors have implemented RPL as an ns-3 module.

The paper is well written. The authors believe that the Internet of Things will become a reality and RPL will play a major role as the preferred routing protocol. Thus, it makes sense to put effort into the development of an RPL implementation for network simulation, since that will help with the deployment of new Internet of Things applications. The paper does a good job of characterizing the issues of existing RPL implementations, and very effectively explains why the authors chose to develop a new RPL implementation as an ns-3 module.

The authors summarize the RPL routing protocol and outline how they designed their RPL module. In the design description, they present classes and sequence diagrams to justify the choices they made for their RPL design. Some details of the RPL module implementation are also well described, including the most relevant classes and their main functions (for example, the RPL class, RPL routing tables, and RPL neighbors). The authors describe how they tested their implementation, the characteristics of the test network, and the steps followed. Test results are presented and discussed.

In conclusion, the authors have presented a very useful paper. They (and I) believe that the Internet of Things will be a reality and RPL will be its standard routing protocol. As a result, the deployment of many low power and lossy network applications is expected. Network tools such as simulators will be needed to study the design, deployment, and behavior of those applications. Existing RPL implementations have some issues; to address those issues, the authors chose ns-3 to host the implementation of the RPL module. For now, I just hope that all the RPL features--especially the peer-to-peer (P2P) routing mechanism--will be implemented in the near future, and that the RPL module will be included in the next ns-3 stable release.