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

[Abdussalam Baryun <[e-mail]>]

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 <[e-mail]> wrote:
> 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
>>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>