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>
Date: Sat, 20 Oct 2012 18:02:14 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC677191-74E4-4AEC-976A-B2C1450120EE@etri.re.kr>
References: <20121020080910.1372.90616.idtracker@ietfa.amsl.com>
To: roll@ietf.org
Cc: =?utf-8?Q?=EB=B0=95=EC=A2=85=EC=A4=80_Park?= <juny@etri.re.kr>
Subject: [Roll] Fwd: New Version Notification for
 draft-ko-roll-mix-network-pathology-01.txt
Precedence: list

Dear RoLL WG,

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.

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.

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.

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: <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