Sender: "JeongGil (John) Ko" <jeonggil.ko@gmail.com>
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: JeongGil Ko <jeonggil.ko@etri.re.kr>
In-Reply-To: <CADnDZ88JAxHJa3TJ+VeD1Ams30xp4yk2nGetLRjofsf_PvtFRA@mail.gmail.com>
Date: Sat, 20 Oct 2012 19:09:26 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <112E19DC-138E-4D21-ABA1-592B5A09CC48@etri.re.kr>
References: <20121020080910.1372.90616.idtracker@ietfa.amsl.com>
 <EC677191-74E4-4AEC-976A-B2C1450120EE@etri.re.kr>
 <CADnDZ88JAxHJa3TJ+VeD1Ams30xp4yk2nGetLRjofsf_PvtFRA@mail.gmail.com>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: =?utf-8?Q?=EB=B0=95=EC=A2=85=EC=A4=80_Park?= <juny@etri.re.kr>,
 roll@ietf.org
Subject: Re: [Roll] Fwd: New Version Notification for
 draft-ko-roll-mix-network-pathology-01.txt
Precedence: list

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.=20

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 =
<abdussalambaryun@gmail.com>
 wrote:

>=20
> 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.
>=20
> AB
>=20
> On 10/20/12, JeongGil Ko <jeonggil.ko@etri.re.kr> wrote:
>> Dear RoLL WG,
>>=20
>> Please review this updated version of =
draft-ko-roll-mix-network-pathology.
>>=20
>> 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.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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 =93actuation=94 =
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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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 :)
>>=20
>> Thanks!
>>=20
>> -John
>>=20
>> ------
>> JeongGil Ko, Ph.D.
>> Researcher
>> Electronics and Telecommunications Research Institute (ETRI)
>> http://sites.google.com/site/jeonggilko/
>>=20
>> Begin forwarded message:
>>=20
>>> From: <internet-drafts@ietf.org>
>>> 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: <jeonggil.ko@etri.re.kr>
>>> Cc: <jsjeong@etri.re.kr>, <juny@etri.re.kr>, <nskim@etri.re.kr>,
>>> <jajun@etri.re.kr>, <gnawali@cs.uh.edu>
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>> 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=3Ddraft-ko-roll-mix-network-pathology-01
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat
>>>=20
>>=20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>=20