Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt

From: JP Vasseur <[email-masked]>
Date: Fri, 13 Apr 2007 16:28:05 -0400

Hi,

Glad to see a good number of people who signed up to list already.  
Here is the first revision of the requirements ID. Feedbacks most  
welcome of course !

Thanks.

JP and David.

Begin forwarded message:

> From: [email-masked]
> Date: April 13, 2007 3:50:01 PM EDT
> To: [email-masked]
> Subject: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Routing Requirements for Sensor Networks
> 	Author(s)	: D. Cullerot, J. Vasseur
> 	Filename	: draft-culler-rsn-routing-reqs-00.txt
> 	Pages		:
> 	Date		: 2007-4-13
> 	
>    The need for high quality routing for Sensor networks comprised of
>    highly constrained devices (CPU, memory, ...) in sometimes unstable
>    wireless environments is critical now and will continue to  
> increase.
>    Interest in this class of applications has grown dramatically in
>    recent years and a routing solution addressing the specific
>    environments of such networks is highly required considering the
>    numerous, incompatible open-source and proprietary routing  
> protocols
>    as well as several industrial forums.  The aim of this document  
> is to
>    define the routing requirements for Sensor Networks at the IP  
> layer.
>    Such routing protocol(s) would need to address several unique  
> aspects
>    of this class of embedded devices and would operate in networks
>    comprising links of various nature.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-culler-rsn-routing- 
> reqs-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-culler-rsn-routing-reqs-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-culler-rsn-routing-reqs-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: Subba Reddy <[email-masked]>
Date: Mon, 16 Apr 2007 12:51:56 +0530

Hi,

Overall, the draft is good.
Here are few questions / comments on the draft.

1. From Section 2.10

"   Ultimately, scalability may benefit from the ability to perform
   computations for data reduction or fusion within the network, not
   just at the data processing sink level.  The most common case being
   aggregation along a dynamically computed path to a sink.  Thus the
   routing protocol SHOULD take points of aggregation (another node
   capability) into account when calculating routes."

Does this mean, we can drop few packets (destined to sink) at aggregator and send the aggregated data to sink?
I feel this is more related to application than routing. 
Please clarify.

2. Following may need to be considered while designing routing protocol.
    a. Node Failures - more common than other networks
    b. Increasing network lifetime
    c. Non real time nature of the data (in general) 

Here are few typos.

>From section 1,

1.   "Considering the variety of Sensor based applications, there may not
   be a single routing protocol satisfying the entire list of
   requirements, in which case it may be decided to define a limited set
   of routing protocols that could be combined to satify the overall
                                                                          ^^^^^^
   objective."

s/satify/satisfy

2. From section 2.10,
    "Date Aware routing"
      ^^^^^

s/Date/Data

-Subba Reddy

  ----- Original Message ----- 
  From: JP Vasseur 
  To: [email-masked] 
  Sent: Saturday, April 14, 2007 1:58 AM
  Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt

  Hi,

  Glad to see a good number of people who signed up to list already. Here is the first revision of the requirements ID. Feedbacks most welcome of course !

  Thanks.

  JP and David.

  Begin forwarded message:

       The need for high quality routing for Sensor networks comprised of
       highly constrained devices (CPU, memory, ...) in sometimes unstable
       wireless environments is critical now and will continue to increase.
       Interest in this class of applications has grown dramatically in
       recent years and a routing solution addressing the specific
       environments of such networks is highly required considering the
       numerous, incompatible open-source and proprietary routing protocols
       as well as several industrial forums.  The aim of this document is to
       define the routing requirements for Sensor Networks at the IP layer.
       Such routing protocol(s) would need to address several unique aspects
       of this class of embedded devices and would operate in networks
       comprising links of various nature.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-culler-rsn-routing-reqs-00.txt

    Send a message to:
    [email-masked].
    In the body type:

------------------------------------------------------------------------------

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 16 Apr 2007 17:51:43 +0200

Hi JP:

Congrats to the authors for this excellent 00 draft. It is already very thorough and sheds some good light on how different the WSN approaches need to be vs. traditional routing and MANET approaches.

Now to the comments:

High level:
-----------

I believe you need a terminology:

- In particular, you need to define what a "sink" is and which functions you expect there
- you also need to define what a "point of connectivity" is and how that's different from a sink
- same for data aggregation
- finally, IMHO, it would be good to define RFD and FFD which are implicit in the draft, and link that with battery problem and the expected functional set (host, forwarder, router, aggregator).

There are 2 assumptions in the text that could be discussed:

- The need for multiple topologies. I do like the concept of MTR in that space and agree it will be useful. But it is not mandatory as suggested in section 2.9. For instance, you can achieve similar results with multiple feasible successors in EIGRP, or with ants routing, link reversal (TORA), etc... long as your routing protocol enables multiple non-equal-cost routes in parallel you can get QoS enabled forwarding.

- The need for A routing protocol that does everything you mention:
	In one hand, some of the operations you describe are forwarding operation and could be done outside of routing, provided that the routing proposes either multiple feasible successors or multiple topologies. 
	ITOH, considering the broad range of applications (radio types, battery vs. power source, device size, etc...) we might not need A routing protocol that does it all but maybe a more generic framework that interoperates at a basic level but can be extended with specific options and protocol values for the various cases that you describe, and the ones which will come in the future.

- The fact that the requirements are unique to sensors can also be discussed. Taken individually, that might not be true. For instance you'll find UHF radios in places with very scare bandwidth, and radios carried by soldiers and firemen with similar constraints but a different trade off in range vs. battery life. I'd hope that whatever comes out of this work is not limited to sensors but can also be applied / extended to other types of mesh networking applications.

Details :
---------

Page 3. Title 2.

- I believe that some text would be good to position WSN that is covered by the document vs. mesh and PAN (that are not?). Note that per its new charter, NEMO is actually gathering requirements for PANs, and there's still no official WG for mesh and sensors.

Page 4, section 2.4

- First sentence is a bit hard to read, could you rephrase?
- I'm not convinced that routing is the key to power management. It is true some protocols merge the control of the routing (decide who are the next hops) and the forwarding (decide which next hop and when to transmit for a given packet). But it might be much more economical to separate the routing and the forwarding protocols in order to get a simpler and more generic routing plane; you could then add a more specific forwarding protocol when needed, in order to change only the forwarding behavior as some conditions change (link load, link interference, path load, you name it) which do not require to establish new routes. An example of what we can not do in WSN is using SPF with dynamic metrics, because it computes a single path to the sink and has to re-compute it all when things change, that is all the time. OTOH, a DV or a greedy approach give you multiple next hops in a general Directed Acyclic Graph towards the sink, and circulating metrics in a forwarding protocol is a sufficient and more to the point to enable the next hop selection in the forwarding plane.
- last sentence about " the devices have their network link off most of the time." This is a very interesting point and it might deserve a bit more text; maybe a little discussion on FFD vs. RFD. And the related expectation in the routing, forwarding and data aggregation functions that you would place in those boxes; also, please note that in the military, being able to operate in stealth (send nothing unless absolutely necessary) mode is a critical feature.

Page 5, section 2.5

Again comes the FFD / RFD discussion. Considering the wide variety of cases within sensors itself I can hardly believe that one protocol / one algorithm  / one set of metrics fits it all. Back to the 2nd assumption I discussed at the beginning of this mail, we have to propose something that guarantees interoperability and loopless routing, but we need to ensure some liberty for case specific routing decisions, based on specific extension options (for instance radio dependent metrics, L3 data that might influence policies, etc), and timing. 

Page 5, section 2.5

"and detection of a point of connectivity". Apart from the missing dot :) and that you really need to define not only what this is (a wire access or any router that can relay including a wireless sensor?), this sentence implies that there is a need for the protocol to discover that "point of connectivity". In many cases that you describe in 2.7, a logical topology that is defined by this sink is sufficient for the basic needs of the WSN, and that deserves some words either in 2.5 or maybe in 2.8.

Page 6, section 2.8

Another interesting aspect of mobile mesh and WSN is that there might not be a global topology for the routing to converge, just because too many things move for the control plane to cope with over the limited resources. 

As a result, SPF-type convergence is a non-goal. In such an environment you can expect at best to reach most peers at most times. A consequence is that if there are peers that are more equals than the others (the sinks for instance), you should be able to maintain the associated path(s) back and forth before you consider maintaining other, less important routes (Back to the discussion on 2.5).

Page 7, section 2.10 (you mean data aware, right? - note: we can do both :)

The "point of aggregation" is another good topic that illustrates that the routing protocol that we want will need the capability to support extensions for case specific and even proprietary algorithms from day 1. Some deployments will have aggregations and some will not. Some nodes will support the aggregation options, and some will not. It all needs to work and interoperate regardless of the specific options and option derived algorithms that nodes in the network actually support.

Thanks again to the authors for this excellent work.

Pascal
________________________________________
From: Jean Philippe Vasseur (jvasseur) 
Sent: Friday, April 13, 2007 10:28 PM
To: [email-masked]
Subject: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt 

Hi,

Thanks.

JP and David.

Begin forwarded message:

	

Send a message to:
	[email-masked].
In the body type:

---

From: JP Vasseur <[email-masked]>
Date: Mon, 16 Apr 2007 16:52:53 -0400

Hi Subba,

Thanks for your comments - see in line,

On Apr 16, 2007, at 3:21 AM, Subba Reddy wrote:

> Does this mean, we can drop few packets (destined to sink) at  
> aggregator and send the aggregated data to sink?

The intention here is to indicate that when fusion is used, it may be  
beneficial to compute a path to the
sink while taking into account the capability of some nodes to  
perform data fusion. Although this is indeed
an application-level capability of the node, we may need a routing  
protocol that favors the use of such path,
which is a pretty unique requirement of Sensor Networks. Such  
capability should be learned by the computing
node thanks to the routing protocol itself.

Note that such function is also performed in other routing contexts:  
for example, when a router computes a Point to Multipoint Label  
Switched Path, the ability of some nodes to perform traffic  
replication can be learned via the routing protocol to compute the path.

Does that clarify ?

>     c. Non real time nature of the data (in general)

Fully agree.

We surely need to specify that node failures are generally more  
common in WSNs, which may or may not have
an impact on the routing protocol. Very likely the impact will be on  
the rerouting times: indeed, it is quite well-known
that fast rerouting times is more challenging in case of node  
failures than link failures.

Note sure what you mean by b. ?

As far as c. is concerned, this is an interesting topic of  
discussion. For the time being, you're absolutely right.
But since we'll need to design a routing protocol for the next few  
years, what will be the requirements of future Sensor Nets  
applications ? Think of industrial alarms to report critical states  
or healthcare applications ...

Thoughts ?

>    of routing protocols that could be combined to satify the overall

Thanks. We'll fix them.

JP.

---

From: Subba Reddy <[email-masked]>
Date: Tue, 17 Apr 2007 13:15:06 +0530

Hi JP,

    Please see my inline comments starting with sr>>
  1. From Section 2.10

  The intention here is to indicate that when fusion is used, it may be beneficial to compute a path to the
  sink while taking into account the capability of some nodes to perform data fusion. Although this is indeed
  an application-level capability of the node, we may need a routing protocol that favors the use of such path,
  which is a pretty unique requirement of Sensor Networks. Such capability should be learned by the computing
  node thanks to the routing protocol itself. 

  Note that such function is also performed in other routing contexts: for example, when a router computes a Point to Multipoint Label Switched Path, the ability of some nodes to perform traffic replication can be learned via the routing protocol to compute the path.

  Does that clarify ?

  sr>> Thanks for the clarification.

  Fully agree. 

  We surely need to specify that node failures are generally more common in WSNs, which may or may not have
  an impact on the routing protocol. Very likely the impact will be on the rerouting times: indeed, it is quite well-known
  that fast rerouting times is more challenging in case of node failures than link failures.

  sr>> Some of the sensor nodes may be selected in most of the forwarding paths (may be beacuse of their 
  position in the network).  This can exhaust the energy of those nodes and thereby disconnecting the network. 

  As far as c. is concerned, this is an interesting topic of discussion. For the time being, you're absolutely right. 
  But since we'll need to design a routing protocol for the next few years, what will be the requirements of future Sensor Nets applications ? Think of industrial alarms to report critical states or healthcare applications ...

  Thoughts ?

  sr>> I agree that the data can be of real time nature. Can we have some optimizations (may be interms of configurations or options) in saving the energy for non-real time applications?

  -Subba Reddy

---

From: Tiago Camilo <[email-masked]>
Date: Tue, 17 Apr 2007 13:34:39 +0100

Hi,
Glad to see WSN standard work in IETF.

I agree with Pascal comment regarding the terminology. I think that a 
terminology section helps to clarify some points in the ID. Terms such 
as sink, RFD and FFD are very common in WSN routing protocols, and 
should be IMO defined and used in the text.

I think that is important in the introduction when you write about 
"Considering the variety of Sensor based applications" to refer that in 
WSNs, the routing protocol is somehow restricted by the application, 
meaning it is the application that defines if the protocol is 
time-driven, event-driven or hybrid.

In section 2.7, I believe that is important to say that differently from 
MANETs, WSNs communications are normally not made between monitoring 
sensors, meaning sensors normally communicate in point-to-point fashion 
only  with the sink and not with  others monitoring sensors (i.e. RFD), 
except in forwarding operations.

In section 2.9. I do not understand why the phrase "MUST support 
multi-topology routing in one form or another with different degrees of 
route optimization" is under the QoS topic. Moreover I suggest to change 
the keyword MUST to SHOULD, since in some applications scenarios, such 
support is not a requirement, i.e. habitat monitoring.

Apart from QoS I feel that is necessary to say something about Security, 
which nowadays is a hot topic in WSNs. There are several ways to attack 
a WSN, and some use the routing protocol leaks to perform DoS attacks, 
data hijacking, introduce radio noise, etc. Therefore I think its 
necessary to say that at least security aspects SHOULD be made.

It is important in section 2.10 to enhance that is more energy-efficient 
to process data locally then forward it, thats the main reason for data 
aggregation.

Regards,

Tiago Camilo
University of Coimbra

JP Vasseur wrote:
>> *From: [email-masked] <mailto:[email-masked]>
>> *Date: *April 13, 2007 3:50:01 PM EDT
>> *To: [email-masked] <mailto:[email-masked]>
>> *Subject: **I-D ACTION:draft-culler-rsn-routing-reqs-00.txt *
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>
>> [email-masked] <mailto:[email-masked]> 
>> with the word unsubscribe in the body of 
>> the message. 
>> [email-masked] <mailto:[email-masked]>.
>> In the body type:
>> Content-ID: <[email-masked] 
>> <mailto:[email-masked]>>
>>
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Apr 2007 12:43:24 -0400

Hi Subba,

On Apr 17, 2007, at 3:45 AM, Subba Reddy wrote:

> Note that such function is also performed in other routing  
> contexts: for example, when a router computes a Point to Multipoint  
> Label Switched Path, the ability of some nodes to perform traffic  
> an impact on the routing protocol. Very likely the impact will be  
> on the rerouting times: indeed, it is quite well-known
> sr>> Some of the sensor nodes may be selected in most of the  
> forwarding paths (may be beacuse of their
> position in the network).  This can exhaust the energy of those  
> nodes and thereby disconnecting the network.
Dynamic node states should be taken into account by the routing  
protocols, the level of energy available per node being one possible  
constraints considering during route computation.
> sr>> I agree that the data can be of real time nature. Can we have  
> some optimizations (may be interms of configurations or options) in  
> saving the energy for non-real time applications?
>
Yes definitely, thus the need for MTR (Multi-topology Routing)  
expressed in section 2.9; note that the text must still require some  
work of course.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Apr 2007 13:01:04 -0400

Hi,

> Glad to see WSN standard work in IETF.

Good, thanks for the support.

> I agree with Pascal comment regarding the terminology. I think that  
> a terminology section helps to clarify some points in the ID. Terms  
> such as sink, RFD and FFD are very common in WSN routing protocols,  
> and should be IMO defined and used in the text.
>

Absolutely, this will be in the next revision for sure.

> "Considering the variety of Sensor based applications" to refer  
> that in WSNs, the routing protocol is somehow restricted by the  
> application, meaning it is the application that defines if the  
> protocol is time-driven, event-driven or hybrid.
>

I'm not sure that the routing protocol is "restricted" by the  
application. It may be somehow related to it, an example of which  
being data-aware routing. I agree with you that the applications  
dictates the requirements for the routing protocols but in that  
respect this does not differ from other routing protocols. For  
example, the convergence requirements for BGP, OSPF, ... have also  
been driven by the emergence of new applications.

> In section 2.7, I believe that is important to say that differently  
> from MANETs, WSNs communications are normally not made between  
> monitoring sensors, meaning sensors normally communicate in point- 
> to-point fashion only  with the sink and not with  others  
> monitoring sensors (i.e. RFD), except in forwarding operations.

Yes indeed, most traffic flows are MP2MP, although the routing  
protocol will have to support P2P since we start to see such traffic  
patterns in WSN as well.

> multi-topology routing in one form or another with different  
> degrees of route optimization" is under the QoS topic. Moreover I  
> suggest to change the keyword MUST to SHOULD, since in some  
> applications scenarios, such support is not a requirement, i.e.  
> habitat monitoring.

OK let me clarify something wrt MUST and SHOULD: in the requirement  
document, the MUST applies to the ability for the routing protocol to  
support MTR, which does not mean that MTR will be used in all  
environments. This is an important distinction.

>
> Apart from QoS I feel that is necessary to say something about  
> Security, which nowadays is a hot topic in WSNs. There are several  
> ways to attack a WSN, and some use the routing protocol leaks to  
> perform DoS attacks, data hijacking, introduce radio noise, etc.  
> Therefore I think its necessary to say that at least security  
> aspects SHOULD be made.

200% ... interesting that you mentioned this since we were about to  
send an email to the list looking for security experts to work on  
this KEY topic. I'll follow up on this.

>
> It is important in section 2.10 to enhance that is more energy- 
> efficient to process data locally then forward it, thats the main  
> reason for data aggregation.
>

Agree, although this is a bit of the scope of this ID (focussed on  
routing issues).

Thanks.

JP.

>>> A New Internet-Draft is available from the on-line Internet- 
>>> Drafts directories.
>>>
>>>
>>> Pages : Date : 2007-4-13
>>> To remove yourself from the I-D Announcement list, send a message  
>>> to [email-masked] <mailto:i-d-announce- 
>>> [email-masked]> with the word unsubscribe in the body of the  
>>> message. You can also visit https://www1.ietf.org/mailman/ 
>>> listinfo/I-D-announce to change your subscription settings.
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with  
>>> the username "anonymous" and a password of your e-mail address.  
>>> After logging in, type "cd internet-drafts" and then "get draft- 
>>> culler-rsn-routing-reqs-00.txt".
>>>
>>> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/ 
>>> 1shadow-sites.txt
>>>
>>> Content-ID: <[email-masked] <mailto: 
>>> [email-masked]>>
>>>

---

From: Kris Pister <[email-masked]>
Date: Tue, 17 Apr 2007 10:15:54 -0700

This is an excellent start.

Tiago Camilo wrote:
> [...]
> monitoring sensors, meaning sensors normally communicate in 
> point-to-point fashion only  with the sink and not with  others 
Hmmm.  I'm concerned that people are spending too much time worrying 
about RFDs.  Have you seen one?  Is anyone 
shipping/installing/configuring any?  I don't think that RFDs are likely 
to be a part of the WSN future.  If anything, technology will push us to 
FFDs and EMFFDs (even more full function devices :) ).
Regarding communication flow, I think that 2.7 reads well as it stands.  
It calls out that any-to-any does happen sometimes, but often the flows 
are very different, including aggregation, dissemination, and local 
multi-hop to another mote.
> [...]
> Therefore I think its necessary to say that at least security aspects 
> SHOULD be made.
I agree.
>
> It is important in section 2.10 to enhance that is more 
> energy-efficient to process data locally then forward it, thats the 
> main reason for data aggregation.
>
As it turns out, it is often *not* more energy-efficient to process data 
locally than forward it, at least not in terms of what is sometimes 
called distributed signal processing.  Compressing your own data stream 
is great.  Payload concatenation/aggregation is great.  Processing your 
neighbor's payload introduces other security concerns.  I think that 
2.10 is fine the way it is.  It's clear that some times this will be 
useful - do we need to enumerate the reasons why?
> University of Coimbra
ksjp
--
Prof. EECS, UC Berkeley
Founder & CTO, Dust Networks

---

From: "dculler" <[email-masked]>
Date: Tue, 17 Apr 2007 11:46:52 -0700

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 8:52 AM
To: Jean Philippe Vasseur (jvasseur)
Cc: [email-masked]
Subject: RE: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt 

Hi JP:

Congrats to the authors for this excellent 00 draft. It is already very
thorough and sheds some good light on how different the WSN approaches need
to be vs. traditional routing and MANET approaches.

>> Thanks.  It is intended to be a start.  Through the discussion, those
trade-offs and alternatives
Will hopefully be spelled out in greater detail.

Now to the comments:

High level:
-----------

I believe you need a terminology:

>> Yes.  This section will be in 01.

- In particular, you need to define what a "sink" is and which functions you
expect there

>> This is indeed an important point of clarification.  Different terms get
used with slightly
varying meaning in different communities.   Traditionally, collections of
sensors (instruments, meters, guages, sense points) typically provide data
into data collection points (e.g., controllers, logs, analytics).  As we
move from "traditional instrumentation" to "a network of sensors" we need to
tease apart several related concepts, and this draft will be a good place to
do it.  Even in the more general sensor network setting, the dominant
traffic pattern is still likely to be a small minority of devices (often
one) collecting data from a large number of others.  Of course, this is true
if we have a network of completely independent devices routing through a
common gateway or router.  What makes it attractive to think of it as
multipoint-to-point is that the collection of "sources" are often closely
related and highly correlated, as they are part of the same application.
The "many sources to few sinks" relationship is often very long lived.  In
the case of a "sensor inter-network", rather than a "sensor link" in the IP
sense, the application level "sink" may be removed from the sensor "sources"
by multiple IP hops.  The convergence of flows may occur into intevening
routing points.

>> In addition, while these multipoint-to-point relationships are very
common from a data path perspective (sense points act like servers), there
is invariably a point-to-multipoint relationship in configuration, control
and management, say to set sample rates, configure thresholds, etc.

>> Finally, even in the presence of a "dominant data collection under common
control and management" there is need to individually configure, calibrate,
or access sensor nodes.  

>> The draft should indeed clarify the relationship between these
application level characteristics and the underlying networking
characteristics, as well as how these drives the evaluation of routing
protocol alternatives and trade-offs.

- you also need to define what a "point of connectivity" is and how that's
different from a sink

>> Indeed, 2.6 seeks to broaden the domain of evaluation to include various
kinds of dynamics, including among others
  * varying interconnectivity even in a stationary network due to changing
environmental factors,
  * mobile devices moving within a stationary network (with potentially
varying connectivity), 
  * and networks of devices that move together.
The "point of connectivity" may indeed be a temporary "sink" in the
application level sense of a data collection point, or in the routing sense.
Even if it serves only at a routing point, its presence may trigger the
communication.

>> Agreed.  I'll try to pick this up on the other thread on "data aware
routing"

- finally, IMHO, it would be good to define RFD and FFD which are implicit
in the draft, and link that with battery problem and the expected functional
set (host, forwarder, router, aggregator).

>> This is a very important point.  The draft intentionally avoids the RFD
and FFD terms that have specific meaning relative to certain link
technologies.  Obviously, there is a broad spectrum of "fullness" or
"reducedness" in functionality.  An individual device may be able to change
its role substantial because it gets plugged in (or has some other power
service) even if it does not change its storage or processing capability.
We would like to recognize that a routing protocol that was able to utilize
the presence "more capable devices" to reduce the demand on "less capable
devices" has substantial value.  This also means that we need to define
scalability well.  It is not just the number of devices, but the ability to
scale down in the device dimension and to scale up.

- The need for multiple topologies. I do like the concept of MTR in that
space and agree it will be useful. But it is not mandatory as suggested in
section 2.9. For instance, you can achieve similar results with multiple
feasible successors in EIGRP, or with ants routing, link reversal (TORA),
etc... long as your routing protocol enables multiple non-equal-cost routes
in parallel you can get QoS enabled forwarding.

>> A very good point.  JP may want to comment more on this.  Clearly, if the
relevant variations in links can be captured in a common cost function it
provides a certain simplicity.

- The need for A routing protocol that does everything you mention:
	In one hand, some of the operations you describe are forwarding
operation and could be done outside of routing, provided that the routing
proposes either multiple feasible successors or multiple topologies. 
	ITOH, considering the broad range of applications (radio types,
battery vs. power source, device size, etc...) we might not need A routing
protocol that does it all but maybe a more generic framework that
interoperates at a basic level but can be extended with specific options and
protocol values for the various cases that you describe, and the ones which
will come in the future.

>> Indeed.  Part of the beauty of IP routing is precisely that we can
separate these two issues.  We can have a common fowarding engine, even if
the routing tables are derived from a variety of differ routing protocols.
These two issues too often get confused.  It would be good if the draft
could pull these issues apart.  Would you go farther and suggest that this
separation is a SHOULD or MUST?  

>>The other side of this, of course, is that you want aspects of the
forwarding (selection of multiple alternative routes, avoidance of energy
depleted nodes) to potentially be aware of issues associated with route
formation (e.g., costs) and potentially vice versa.

- The fact that the requirements are unique to sensors can also be
discussed. Taken individually, that might not be true. For instance you'll
find UHF radios in places with very scare bandwidth, and radios carried by
soldiers and firemen with similar constraints but a different trade off in
range vs. battery life. I'd hope that whatever comes out of this work is not
limited to sensors but can also be applied / extended to other types of mesh
networking applications.

>> Absolutely.  Even in the simplest case, sensors versus other transducers.
The question is what boundaries do we need to establish in order to get
enough focus on the technical issues that we can make solid progress.
Clearly there are issues in here having to do with the mobility model, the
presence or lack of infrastructure, the duration of communication
relationships, and the coherency of operation across collections of devices,
and whether devices are largely attended or unattended. 

Details :
---------

Page 3. Title 2.

- I believe that some text would be good to position WSN that is covered by
the document vs. mesh and PAN (that are not?). Note that per its new
charter, NEMO is actually gathering requirements for PANs, and there's still
no official WG for mesh and sensors.

>> Makes sense, but those terms are not terribly well defined.  "PAN" serves
as an IEEE concept to differentiation a certain wireless bit-rate and
transmission power from "LAN".  We certainly want to include "PAN"s.  Mesh
is particularly ill-defined.  Perhaps what you mean here is "multihop
routing within and IP link" versus routing at the next level up.  We would
certainly like to deal with IP routing over collections of "mesh routed"
links.  Obviously, a very interesting case is where the mesh is of size one.

Page 4, section 2.4

>> Agreed. 

- I'm not convinced that routing is the key to power management. It is true
some protocols merge the control of the routing (decide who are the next
hops) and the forwarding (decide which next hop and when to transmit for a
given packet). But it might be much more economical to separate the routing
and the forwarding protocols in order to get a simpler and more generic
routing plane; you could then add a more specific forwarding protocol when
needed, in order to change only the forwarding behavior as some conditions
change (link load, link interference, path load, you name it) which do not
require to establish new routes. An example of what we can not do in WSN is
using SPF with dynamic metrics, because it computes a single path to the
sink and has to re-compute it all when things change, that is all the time.
OTOH, a DV or a greedy approach give you multiple next hops in a general
Directed Acyclic Graph towards the sink, and circulating metrics in a
forwarding protocol is a sufficient and more to the point to enable the next
hop selection in the forwarding plane.

>> There is clearly a separation here.  The main point is that the routing
protocols should not prevent deep power management.  We generally focus on
links that are "always on".  A typical design point is WSNs is that radios
are only on 0.1% - 1% of the time.  All too often, this has caused
forwarding concerns (scheduled transfers and TDMA techniques) to get all
mixed up with routing.  Being able to maintain reasonable separation and
still be able to perform deep power management is a good goal.

- last sentence about " the devices have their network link off most of the
time." This is a very interesting point and it might deserve a bit more
text; maybe a little discussion on FFD vs. RFD. And the related expectation
in the routing, forwarding and data aggregation functions that you would
place in those boxes; also, please note that in the military, being able to
operate in stealth (send nothing unless absolutely necessary) mode is a
critical feature.
 
>> Agree

Page 5, section 2.5

Again comes the FFD / RFD discussion. Considering the wide variety of cases
within sensors itself I can hardly believe that one protocol / one algorithm
/ one set of metrics fits it all. Back to the 2nd assumption I discussed at
the beginning of this mail, we have to propose something that guarantees
interoperability and loopless routing, but we need to ensure some liberty
for case specific routing decisions, based on specific extension options
(for instance radio dependent metrics, L3 data that might influence
policies, etc), and timing. 

Page 5, section 2.5

"and detection of a point of connectivity". Apart from the missing dot :)
and that you really need to define not only what this is (a wire access or
any router that can relay including a wireless sensor?), this sentence
implies that there is a need for the protocol to discover that "point of
connectivity". In many cases that you describe in 2.7, a logical topology
that is defined by this sink is sufficient for the basic needs of the WSN,
and that deserves some words either in 2.5 or maybe in 2.8.

Page 6, section 2.8

Another interesting aspect of mobile mesh and WSN is that there might not be
a global topology for the routing to converge, just because too many things
move for the control plane to cope with over the limited resources. 

As a result, SPF-type convergence is a non-goal. In such an environment you
can expect at best to reach most peers at most times. A consequence is that
if there are peers that are more equals than the others (the sinks for
instance), you should be able to maintain the associated path(s) back and
forth before you consider maintaining other, less important routes (Back to
the discussion on 2.5).

The "point of aggregation" is another good topic that illustrates that the
routing protocol that we want will need the capability to support extensions
for case specific and even proprietary algorithms from day 1. Some
deployments will have aggregations and some will not. Some nodes will
support the aggregation options, and some will not. It all needs to work and
interoperate regardless of the specific options and option derived
algorithms that nodes in the network actually support.

Pascal

Hi,

Glad to see a good number of people who signed up to list already. Here is
the first revision of the requirements ID. Feedbacks most welcome of course
!

Thanks.

JP and David.

Begin forwarded message:

	

Send a message to:
	[email-masked].
In the body type:

---

From: "dculler" <[email-masked]>
Date: Tue, 17 Apr 2007 22:43:33 -0700

-----Original Message-----
From: Tiago Camilo [mailto:[email-masked]]
Sent: Tuesday, April 17, 2007 5:35 AM
To: JP Vasseur
Cc: [email-masked]
Subject: Re: [RSN] Fwd: I-D ACTION:draft-culler-rsn-routing-reqs-00.txt

Hi,

I agree with Pascal comment regarding the terminology. I think that a
terminology section helps to clarify some points in the ID. Terms such as
sink, RFD and FFD are very common in WSN routing protocols, and should be
IMO defined and used in the text.

RFD and FFD have been defined with respect to specific mechanisms in IEEE
802.15.4, such as power management, beaconing, and the need to "route" (in
the L2 sense) through a coordinator. I feel that is essential to recognize
and utilize heterogeneity, but I am concerned about using those terms that
have a specific technical meaning in IEEE 802.15.4 and certain industrial L2
protocols that run over it.

I think that is important in the introduction when you write about
"Considering the variety of Sensor based applications" to refer that in
WSNs, the routing protocol is somehow restricted by the application, meaning
it is the application that defines if the protocol is time-driven,
event-driven or hybrid.

I certainly understand that sensor applications may be time-driven,
event-driven, or hybrid, and I can see that these apply to forwarding.  It
is less clear that this defines the routing protocol.

In section 2.7, I believe that is important to say that differently from
MANETs, WSNs communications are normally not made between monitoring
sensors, meaning sensors normally communicate in point-to-point fashion only
with the sink and not with  others monitoring sensors (i.e. RFD), except in
forwarding operations.

Although such collection is indeed the dominate traffic in typical usage,
there are a number of useful cases where point-to-point occurs.  There are
certainly cases where it make sense for a sensor reading to trigger or in
some way be incorporated into the readings or actions of another sensor
before being collected.  There are also cases where an individual sensor is
queried or configured.  These need not have a geographic locality involved.
There are also a number of cases where geographic locality is essential,
such as the combining a set of readings covering a certain region of space
or a person interacting with nearby sensors through a handheld field unit.
So it does seem wise to attend to how different the traffic patterns are in
this domain from that which we normally use to evaluate routing algorithms,
but it is also important to cover the less common cases properly.

In section 2.9. I do not understand why the phrase "MUST support
multi-topology routing in one form or another with different degrees of
route optimization" is under the QoS topic. Moreover I suggest to change the
keyword MUST to SHOULD, since in some applications scenarios, such support
is not a requirement, i.e. habitat monitoring.

I agree.  It is probably premature to make MUST determinations at this stage
of requirements definition.

Apart from QoS I feel that is necessary to say something about Security,
which nowadays is a hot topic in WSNs. There are several ways to attack a
WSN, and some use the routing protocol leaks to perform DoS attacks, data
hijacking, introduce radio noise, etc. Therefore I think its necessary to
say that at least security aspects SHOULD be made.

It is important in section 2.10 to enhance that is more energy-efficient to
process data locally then forward it, thats the main reason for data
aggregation.

Regards,

Tiago Camilo
University of Coimbra

JP Vasseur wrote:
>> with the word unsubscribe in the body of the message.
>> You can also visit
>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>> logging in, type "cd internet-drafts" and then "get
>> draft-culler-rsn-routing-reqs-00.txt".
>>
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> MIME-encoded form by using the "mpack" utility.  To use this feature,
>> insert the command "ENCODING mime" before the "FILE"
>> command.  To decode the response(s), you will need "munpack" or a
>> MIME-compliant mail reader.  Different MIME-compliant mail readers
>> exhibit different behavior, especially when dealing with "multipart"
>> MIME messages (i.e. documents which have been split up into multiple
>> messages), so check your local documentation on how to manipulate
>> these messages.
>>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 18 Apr 2007 10:23:33 -0400

> This is an excellent start.

Thanks, still require significant work, but we should collectively be  
able to come up with a good
set of requirements, important before moving to the protocol design.

> Tiago Camilo wrote:
>> [...]
>> In section 2.7, I believe that is important to say that  
>> differently from MANETs, WSNs communications are normally not made  
>> between monitoring sensors, meaning sensors normally communicate  
>> in point-to-point fashion only  with the sink and not with  others  
> Hmmm.  I'm concerned that people are spending too much time  
> worrying about RFDs.  Have you seen one?  Is anyone shipping/ 
> installing/configuring any?  I don't think that RFDs are likely to  
> be a part of the WSN future.  If anything, technology will push us  
> to FFDs and EMFFDs (even more full function devices :) ).

Yes, by the way, let's avoid Zigbee terminology here ;-)

> Regarding communication flow, I think that 2.7 reads well as it  
> stands.  It calls out that any-to-any does happen sometimes, but  
> often the flows are very different, including aggregation,  
> dissemination, and local multi-hop to another mote.

Right.

> As it turns out, it is often *not* more energy-efficient to process  
> data locally than forward it, at least not in terms of what is  
> sometimes called distributed signal processing.  Compressing your  
> own data stream is great.  Payload concatenation/aggregation is  
> great.  Processing your neighbor's payload introduces other  
> security concerns.  I think that 2.10 is fine the way it is.  It's  
> clear that some times this will be useful - do we need to enumerate  
> the reasons why?

I don't think so ... as long as we state the requirement.

Thanks.

JP.