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

[JeongGil Ko <[e-mail]>]

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
Electronics and Telecommunications Research Institute (ETRI)
http://sites.google.com/site/jeonggilko/

On Oct 20, 2012, at 7:04 PM, Abdussalam Baryun <[e-mail]>
 wrote:

> 
> 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
>>