[Roll] Fwd: New Version Notification for draft-ko-roll-mix-network-pathology-01.txt

[JeongGil Ko <[e-mail]>]

Dear RoLL WG,

Please review this updated version of draft-ko-roll-mix-network-pathology. 

This draft discusses about the routing pathologies that occur when storing and non-storing mode nodes are mixed together in a single network. Compared to the previous version of the draft, we have addressed some of the comments from the mailing list and added in an additional case where the mixture of storing and non-storing mode nodes can affect the performance of the RPL network for *collection traffic* as well as downwards connectivity. As the draft indicates, due to RPL restricting different MOPs from fully functioning in the same network (e.g., one MOP is forced to be a leaf), differences in downwards routing schemes affects the route quality for collection traffic as well. Specifically, due to different MOPs despite having physical connectivity to the root, a node may not be able to find a routing connection to the root. Given that collection is the main focus in many applications, this is something that needs to be addressed.

As a side comment, this draft addresses some of the issues that came up in our large scale HVAC supporting WSN system deployment in a 15 story building. We plan to install ~2000 sensors and actuators in this building for HVAC related applications (e.g., CO, Temp, Hum, PIR sensors and Air Conditioning, light, ventilation, heating controlling actuators). 

Cost reasons restrict us to have resource rich devices on the sensor devices but actuation units (which are pretty expensive already) can be resource rich (i.e., sensing devices will have similar capabilities to an MSP430 while the actuators are more Cortex M3-like MCUs). Since these sensor devices cannot support storing mode routing, and RPL restricts us from having a mixture of storing and non-storing mode nodes, all nodes will have to be non-storing mode nodes for the network to be RPL compliant.

While sensor nodes typically generate collection-direction traffic, to make the actuators take action, downwards packets would need to be generated; thus, this would increase the number of downwards packets and make the network/transmission quality/efficiency for the downwards routes an important factor to consider. By adding in features such as application layer acknowledgements, the quantity of downwards traffic will increase even more. 

Nevertheless a few inefficiencies exist with downwards routes in our application when using the non-storing mode ONLY. (1) First, due to the increased number of nodes, the length of the source routing headers can result to be long. (2) Second, the number of hops that “actuation” messages travel increases, since most of these, essentially downwards, packets would need to travel all the way to the root before being transmitted downwards. (3) Third, the increased quantity in downwards traffic will give more load on the one hop neighborhood of the DODAG root since the root would need to deal with sensor reports in large quantities (e.g., collection) and also actuation messages in increased quantities (e.g., downwards). (4) Fourth, given that the locations of the sensor and actuator units are not adjustable (e.g., the placement must be close to the actual sensing/actuation units) it is difficult to overcome this inefficiency by simply improving the network topology.

Given this, we can think of a case where more powerful nodes have storing mode capabilities. This change can *ideally* resolve the issues that we introduced above. Nevertheless, the DODAG root should be able to attach source routing headers for its non-storing mode sensor nodes to forward downwards packets; therefore, the root should implement non-storing mode. In this case, even if the actuators are configured as storing mode nodes, given RPL, they can only act as leaf nodes. By forcing storing mode nodes to be leaf nodes brings back the issues introduced above. Furthermore, since we cannot use these nodes for collection traffic forwarding, this will affect the data collection performance as well. Therefore, we are in need of a scheme that can mix storing and non-storing mode nodes in a single network effectively.

By allowing both storing and non-storing modes to fully interoperate (as the draft indicates), the number of downwards messages that the DODAG root MUST take care of can decrease given that actuator nodes with storing capabilities can add source routing headers within the network to cool down the hot-spot near the DODAG root and also reduce the number of hops that each packet travels to reach the final destination. Furthermore, since all nodes will participate in the DODAG construction process as routing-capable nodes, the quality of the selected links can potentially increase; thus, improving the performance of collection routes as well.

Due to the aforementioned reasons, we are proposing the attached draft. Our proposal in the draft introduces light-weight modifications to the current RPL specs so that RPL can also support the cases mentioned above. With minimal increase in complexity, RPL will be able to tolerate more types of networks and you won't need to worry about which MOP your neighbors installed on their RPL network! :) Your review and thoughts will be of great help in improving the draft :)

Thanks!

-John

------
JeongGil Ko, Ph.D.
Researcher
Electronics and Telecommunications Research Institute (ETRI)
http://sites.google.com/site/jeonggilko/

Begin forwarded message:

> From: <[e-mail]>
> Subject: New Version Notification for draft-ko-roll-mix-network-pathology-01.txt
> Date: October 20, 2012 5:09:10 PM GMT+09:00
> To: <[e-mail]>
> Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
> 
> 
> 
> A new version of I-D, draft-ko-roll-mix-network-pathology-01.txt
> has been successfully submitted by JeongGil Ko and posted to the
> IETF repository.
> 
> Filename:	 draft-ko-roll-mix-network-pathology
> Revision:	 01
> Title:		 RPL Routing Pathology In a Network With a Mix of Nodes Operating in Storing and Non-Storing Modes
> Creation date:	 2012-10-20
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-ko-roll-mix-network-pathology-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-ko-roll-mix-network-pathology
> Htmlized:        http://tools.ietf.org/html/draft-ko-roll-mix-network-pathology-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ko-roll-mix-network-pathology-01
> 
> Abstract:
>   The RPL specification allows nodes running with storing or non-
>   storing modes to operate in the same network.  We describe how such a
>   mix can result in network partitioning even when there are plenty of
>   physical links available in the network.  The partitioning affects
>   both upwards (nodes to root) and downwards (root to leaf) traffic.
>   This routing pathology stems from a recommendation made in the RPL
>   specification forcing nodes with different modes of operation to join
>   the RPL network as leaf nodes only.  We propose a solution that
>   modifies RPL by mandating that all the nodes parse and interpret
>   source routing headers and storing mode nodes to sometimes act like a
>   non-storing mode root by attaching source routing headers.
> 
> 
> 
> 
> The IETF Secretariat
>