Subject: [RSN] New Mailing List: Routing for Sensor Network

From: "Dominik Kaspar" <[email-masked]>
Date: Fri, 13 Apr 2007 11:22:00 +0900

JP, David,

I would like to refer to our 6lowpan Routing Requirements draft, which
discusses the issues of routing in "sensor networks". The draft
provides design goals and a list of requirements for IP-based routing
solutions in low-rate WPANs.

At IETF-68 in Prague, we presented our work and solicited advice from
both MANET and 6lowpan folks. There seemed to be a general consent
that routing is a very important task to solve, however, it is heavily
dependent on the network architecture itself, and what exactly this
"architecture" is should be clarified first.

If you haven't done it yet, please read our draft; we appreciate any
constructive comments:
http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt

Sincerely,
Dominik

On 4/12/07, JP Vasseur <[email-masked]> wrote:
> Hi,
>
> We wanted to inform you that a new Mailing List has been set up, the aim of
> which is to discuss Routing for Sensor Networks (at the IP layer). Anybody
> interested in contributing to the work is of course more than welcome to
> subscribe and collaborate. To register:
> https://www1.ietf.org/mailman/listinfo/rsn
>
> Several of you already expressed some real interest in this work and several
> documents (with currently no home WG) already exist. David and I posted are
> about to post an ID on the routing requirements for Sensor Networks
> (probably early next week) to kick off the discussion.
>
> What is the overall objective ?
> 1) As you know a plethora of proprietary routing protocols (thus outside of
> the IETF) have been developed and there is within the IETF currently no
> clear answer on which protocol(s) can satisfy the very specific requirements
> of Sensor Networks. This triggered this initiative so as to define a routing
> architecture and routing protocol at the IETF for Sensor Nets, thus this new
> mailing list. Note that we may not be able to come up with a single set of
> requirements but a few requirement documents accompanied with some
> applicability IDs if it turns out that a unique solution cannot satisfy them
> all.
> 2) There is at this stage no a priori on the routing protocol that could be
> used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR,
> Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements
> or (3) new routing protocol(s).
>
> Possible next steps
> If enough interest for this work is shown on the list, we will request a BOF
> for Chicago, which may lead to forming a new WG.
>
> JP and David.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet

_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Fri, 13 Apr 2007 11:26:17 +0900

JP, David,

I'm happy to see RSN has been built up.

> http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt
which dominik mentioned below outlines the high-level of routing
requirements of LowPAN.

The draft has the same objectives as RSN pursuits.

> > or (3) new routing protocol(s).

I hope we can gather many interests and results from this mailing list.

Cheers,

Eunah

On 4/13/07, Dominik Kaspar <[email-masked]> wrote:
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Apr 2007 07:40:04 -0400

Hi Dominik and and Kim,

Thanks for your email and support for this work, no need to say that  
your contribution is most welcome.
What I would propose here would be for you to read the draft that  
Dave and I have posted and that should be
available in the next few days and provide us some feed-back.

As you will see we're trying to exclusively focus on the requirements  
for the time being while staying completely technology agnostic,  
which is key for a requirement ID.

If my understanding is correct you state in R0 "Existing MANET  
protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would propose  
to step back for the moment from any specific solution to again focus  
on the requirements. As indicated below, we may end up using a MANET  
protocol with adaptation but this should not be a pre-requisite and  
none of them fully satisfy the requirements, thus the need for  
discussion on this list and potentially a WG since this discussion  
will likely require a significant amount of work. There is another  
fundamental difference: in R02 you mention "6LoWPAN routing MUST be  
performed in the adaptation layer, as defined in [3].". We propose to  
specify a routing protocol for Sensor Network above IP, not coupled  
with any specific layer1/2 technologies, which is of the utmost  
importance to support mixed environments that already exist.

Looking forward to having your comments on the draft (draft-culler- 
rsn-routing-reqs-00.txt), which should be available very soon.

Thanks.

JP.

---

From: <[email-masked]>
Date: Fri, 13 Apr 2007 12:46:59 +0100

Dear all,
 I think it will be dangerous to start-off with requirements based on
MANET work. I would suggest a more top-down approach by looking at the
specific routing challenges for sensor networks and then looking at the
SoA to see if there are existng protocols which can be used as the basis
for further work.
 
Regards,
Nadeem

________________________________

From: JP Vasseur [mailto:[email-masked]] 
Sent: 13 April 2007 12:40
To: Dominik Kaspar; Eunsook Eunah Kim
Cc: [email-masked]
Subject: Re: [RSN] New Mailing List: Routing for Sensor Network

Hi Dominik and and Kim, 

Thanks for your email and support for this work, no need to say that
your contribution is most welcome.
What I would propose here would be for you to read the draft that Dave
and I have posted and that should be
available in the next few days and provide us some feed-back. 

As you will see we're trying to exclusively focus on the requirements
for the time being while staying completely technology agnostic, which
is key for a requirement ID. 

If my understanding is correct you state in R0 "Existing MANET protocols
(e.g., AODV, OLSR, DYMO) SHOULD be reused." I would propose to step back
for the moment from any specific solution to again focus on the
requirements. As indicated below, we may end up using a MANET protocol
with adaptation but this should not be a pre-requisite and none of them
fully satisfy the requirements, thus the need for discussion on this
list and potentially a WG since this discussion will likely require a
significant amount of work. There is another fundamental difference: in
R02 you mention "6LoWPAN routing MUST be performed in the adaptation
layer, as defined in [3].". We propose to specify a routing protocol for
Sensor Network above IP, not coupled with any specific layer1/2
technologies, which is of the utmost importance to support mixed
environments that already exist. 

Looking forward to having your comments on the draft
(draft-culler-rsn-routing-reqs-00.txt), which should be available very
soon.

Thanks.

JP.

	JP, David,

	I would like to refer to our 6lowpan Routing Requirements draft,
which
	discusses the issues of routing in "sensor networks". The draft
	provides design goals and a list of requirements for IP-based
routing
	solutions in low-rate WPANs.

	At IETF-68 in Prague, we presented our work and solicited advice
from
	both MANET and 6lowpan folks. There seemed to be a general
consent
	that routing is a very important task to solve, however, it is
heavily
	dependent on the network architecture itself, and what exactly
this
	"architecture" is should be clarified first.

	If you haven't done it yet, please read our draft; we appreciate
any
	constructive comments:

	Sincerely,
	Dominik

		Hi,

		We wanted to inform you that a new Mailing List has been
set up, the aim of
		which is to discuss Routing for Sensor Networks (at the
IP layer). Anybody
		interested in contributing to the work is of course more
than welcome to
		subscribe and collaborate. To register:
		https://www1.ietf.org/mailman/listinfo/rsn

		Several of you already expressed some real interest in
this work and several
		documents (with currently no home WG) already exist.
David and I posted are
		about to post an ID on the routing requirements for
Sensor Networks
		(probably early next week) to kick off the discussion.

		What is the overall objective ?
		1) As you know a plethora of proprietary routing
protocols (thus outside of
		the IETF) have been developed and there is within the
IETF currently no
		clear answer on which protocol(s) can satisfy the very
specific requirements
		of Sensor Networks. This triggered this initiative so as
to define a routing
		architecture and routing protocol at the IETF for Sensor
Nets, thus this new
		mailing list. Note that we may not be able to come up
with a single set of
		requirements but a few requirement documents accompanied
with some
		applicability IDs if it turns out that a unique solution
cannot satisfy them
		all.
		2) There is at this stage no a priori on the routing
protocol that could be
		used: it could either be (1) existing routing
protocol(s) (AODV, DYMO, OLSR,
		Triggered RIP, NEMO, ...) (1) existing routing
protocol(s) with enhancements
		or (3) new routing protocol(s).

		Possible next steps
		If enough interest for this work is shown on the list,
we will request a BOF
		for Chicago, which may lead to forming a new WG.

		JP and David.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Apr 2007 07:58:59 -0400

Hi,

On Apr 13, 2007, at 7:46 AM, <[email-masked]>  
<[email-masked]> wrote:

> Dear all,
>  I think it will be dangerous to start-off with requirements based  
> on MANET work. I would suggest a more top-down approach by looking  
> at the specific routing challenges for sensor networks and then  
> looking at the SoA to see if there are existng protocols which can  
> be used as the basis for further work.
>

Right, as you'll see in the draft, this is the approach we took (a  
requirement ID must be solution agnostic anyway).
Comments welcome.

Thanks.

JP.

> Thanks for your email and support for this work, no need to say  
> that your contribution is most welcome.
> As you will see we're trying to exclusively focus on the  
> requirements for the time being while staying completely technology  
> agnostic, which is key for a requirement ID.
>
> protocols (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would  
> propose to step back for the moment from any specific solution to  
> again focus on the requirements. As indicated below, we may end up  
> using a MANET protocol with adaptation but this should not be a pre- 
> requisite and none of them fully satisfy the requirements, thus the  
> need for discussion on this list and potentially a WG since this  
> discussion will likely require a significant amount of work. There  
> is another fundamental difference: in R02 you mention "6LoWPAN  
> routing MUST be performed in the adaptation layer, as defined in  
> [3].". We propose to specify a routing protocol for Sensor Network  
> above IP, not coupled with any specific layer1/2 technologies,  
> which is of the utmost importance to support mixed environments  
> that already exist.
>

---

From: Philip Levis <[email-masked]>
Date: Fri, 13 Apr 2007 09:04:24 -0700

On Apr 13, 2007, at 4:40 AM, JP Vasseur wrote:

> discussion will likely require a significant amount of work.

I think this is a very important point. While mobility is an issue in  
many sensornets, many are quite stationary. Requiring the stationary  
ones to incur the energy cost of the overhead of supporting mobility  
might not be a good idea.

Phil

---

From: "Dominik Kaspar" <[email-masked]>
Date: Fri, 20 Apr 2007 18:24:28 +0900

JP and David,

I agree with your point that MANET is not a pre-requisite for sensor
network routing, and the reason why we wrote the routing requirements
draft was to find what will be really necessary for designing a new
protocol or reusing existing protocols.

> discussion will likely require a significant amount of work.

The reason why we added requirement R00 was that 6lowpan has been
handling sensor network issues, and the WG charter states: "As such,
the working group may also work on an informational document to show
how to apply an existing MANET protocol to LoWPANs (e.g., AODV, OLSR,
DYMO, etc)". Therefore, we tried to work within the WG work scope.

If our R00 causes some confusion, and if the discussion is not
restricted within 6lowpan, but general sensor network routing, I
totally agree that we need to take a different approach for this work.

> agnostic, which is key for a requirement ID.

Well, I can see your concerns from your draft, which our draft also
covers and already listed many common requirements with yours; just
using different wording. (FYI, I listed our intention of the listed
requirements compared to your requirements at the end of this email. I
hope you don't misunderstand this. It's for your better understanding
that we are talking in the same language.)

One of our main concerns is the possibility of creating a big list of
requirements for sensor networks, but if you analyze what the
requirement differences are between sensor network routing and routing
in other areas (such as MANET) you see that they are mostly coming
from a few common design goals. The main requirements for sensor
networks are namely power saving and what you call "light footprint".
That's why we wrote a chapter on the major design goals and have drawn
out the requirements from that.

Your requirements draft details the requirements, but IMHO, if you
added another chapter "the design challenge of sensor routing" before
the list of the requirements, and explain the special characteristics
of sensor network and why and how it effects routing, it would
increase readability. For this, I suggest you to check Section 3 of
our draft (http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt).
I think we can merge the works to a nice shape.

Other than to your requirements list, I have one more comment. In
Chapter 3 it is stated that "The objective of this work would be to
define a routing protocol that will satisfy those requirements as much
as possible and that would potentially adapt itself to the particular
deployment context."

If I understand correctly, this objective contradicts with your own
requirements. Sensor network applications are really diverse, and for
certain applications, they only need a subset of the requirements,
while others need a different subset of requirements.
I think we shouldn't constrain us to defining "a" routing protocol to
satisfy those requirements as much as possible. Please correct me in
case of a misunderstanding.

Greetings,
Dominik & Eunsook

---<Draft Comparison>---------------------------

2.1.  Spatially-Driven Multihop:
- Your point of energy-aware multihop routing is a major design goal
in our draft (Section 3.1) and is addressed by requirement R04
("energy-minimal routing").

2.2.  Light Footprint:
- This requirement is also one of our major design goals (Section 3.2)
and listed as requirement R05 ("low protocol complexity").

2.3.  Small MTU:
- This requirement is covered by our requirements R03 ("small
frames"), R04 ("energy-minimal routing"), R06 ("code length") and in
some way R02 ("header compression").

2.4.  Deep power management:
- Parts of this requirement is basically "minimizing energy" again.
- The other part is covered by our requirement R11 ("sleeping nodes")

2.5.  Heterogeneous Capabilities:
- The way you word it, this requirement also boils down to R04
("energy-minimal routing").

2.6.  Highly Variable Connectivity:
- The first and third paragraphs are covered by our requirements R13
("adaptive topologies") and R04 ("energy-minimal routing").
- The second paragraph can be seen as a subset of our requirement R11
("sleeping nodes") or R08 ("neighbor discovery");

2.7.  Structured Workload and Traffic Pattern:
- This requirement is partially described as our R10 ("gateways & querying").

2.8.  Partial Information:
- This requirement has been thought of in our draft as R14 ("scalable
architecture").

2.9.  Quality of Service Capable Routing:
- Path selection, path quality optimization and route performance are
already part of other requirements, such as R04 ("energy-minimal
routing").
- QoS is intentionally left out as a routing requirement for sensornets.

2.10. Data Aware routing:
- If "points of aggregation" is the same as "gateways", it is covered
by our requirement R10 ("gateways & querying").

---<\Draft Comparison>---------------------------

On 4/13/07, JP Vasseur <[email-masked]> wrote:
> Hi Dominik and and Kim,
>
> Thanks for your email and support for this work, no need to say that your
> contribution is most welcome.
> What I would propose here would be for you to read the draft that Dave and I
> have posted and that should be
> As you will see we're trying to exclusively focus on the requirements for
> the time being while staying completely technology agnostic, which is key
> for a requirement ID.
>
> (e.g., AODV, OLSR, DYMO) SHOULD be reused." I would propose to step back for
> the moment from any specific solution to again focus on the requirements. As
> indicated below, we may end up using a MANET protocol with adaptation but
> this should not be a pre-requisite and none of them fully satisfy the
> requirements, thus the need for discussion on this list and potentially a WG
> since this discussion will likely require a significant amount of work.
> There is another fundamental difference: in R02 you mention "6LoWPAN routing
> MUST be performed in the adaptation layer, as defined in [3].". We propose
> to specify a routing protocol for Sensor Network above IP, not coupled with
> any specific layer1/2 technologies, which is of the utmost importance to
> support mixed environments that already exist.
>
> (draft-culler-rsn-routing-reqs-00.txt), which should be
> available very soon.
>
> Thanks.
>
> JP.
>
>

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 20 Apr 2007 12:03:01 +0200

Hi Dominik
>case of a misunderstanding.
[Pascal] I agree with that. There will hardly be one fits it all in WSN.
It's not just the subnet, the power level and othet low layer things but
maybe application layer reasons, like the type of data being reported,
the application run in the sensor (like tinyDB vs. Messo), which will be
used to structure the network.
 
Still we want interoperability. I see the requirement as a plug-in
structure. We need a simple common framework that guarantees some
loopless routing and leave up to specific vendors / deployment how the
plug ins actually use that framework to structure the network.

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Mon, 23 Apr 2007 07:49:17 -0400

Hi Dominik,

> protocol or reusing existing protocols.

Good, we're in sync.

> totally agree that we need to take a different approach for this work.

Perfect.

> case of a misunderstanding.

I think that we should indeed try to have "a" routing protocol rather  
than a set of routing protocols since
as soon as more than one routing protocol is defined that does add a  
lot of complexity, interop issues and
so on. There are many such examples of course. Now the question is  
"Is that possible ?". Here is a proposed
approach:
1) Try to list the requirements ... during that phase it is critical  
to differentiate the MUST, SHOULD, ...
2) If we can find or define "a" protocol that satisfies the MUST and  
for which we can provide options to support
the SHOULD, that would be ideal. We may also decide to not support  
all the MUST if that allows us to not
define many protocols, to be discussed of course.

Thanks for the draft comparison. I understand that you added some  
requirements because of the 6lowpan WG
charter. Instead of a comparison, would you want to point the section  
that you would like to add or remove ?

Thanks.

JP.

>> requirements for
>> protocols