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

From: JeongGil Ko <[email-masked]>
Date: Sat, 20 Oct 2012 18:02:14 +0900

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: <[email-masked]>
> 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: <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
> 
> 
> 
> 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
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 20 Oct 2012 12:04:45 +0200

Hi John,
I interested in your proposal, and like to see the draft team present
it to ROLL 85 meeting if available, I have commented before draft-00,
and my full comments will come when completed.

AB

On 10/20/12, JeongGil Ko <[email-masked]> wrote:
> 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
>> Subject: New Version Notification for
>> draft-ko-roll-mix-network-pathology-01.txt
>> 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:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: JeongGil Ko <[email-masked]>
Date: Sat, 20 Oct 2012 19:09:26 +0900

Abdussalam,

I am also hoping to present this draft at the meeting :)

Thank you for the comments on -00, your points have beed addressed in -01. 

Thanks!

-John

------
JeongGil Ko, Ph.D.
Researcher