Subject: [RSN] Interest in the Interplay of "routing" and "meshing"

From: "dculler" <[email-masked]>
Date: Tue, 22 May 2007 16:24:58 -0700

Several of the comments on this list have touched on the issue of different
kinds of "multihop routing" in the context of sensor networks.  Is there
interest in working on how these forms of routing tie together?
 
To make the question more grounded:  Low power radios have relatively short
range.  IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 mW
for 802.11, and have typical ranges in 10s to 100 m.  Generally speaking,
the power required to communicate a given distance by radio grows
polynomially with distance.  In typical settings it grows like the cube, but
it can be much worse near the ground or somewhat better with directional
antennas.  The cost to communicate hop-by-hop grows only linearly, and it
offers the potential to route around obstacles and enhance reliability
through "receiver diversity".  
 
The question is at what layer(s) in the stack this routing occurs and how it
relates to IP routing more generally.  Most multihop protocols in the sensor
network research community are effectively at layer2 - they form a single
"patch" of homogeneous media.  Logically, they are a subnet, although few of
the protocols address what happens beyond the "patch" of sensor nodes, other
than that some of the nodes are "gateways".  Current industry standards,
such as Zigbee, Zwave, and wirelessHART, are also a "multihop link", leaving
open the question of how nodes within the sensor patch communicate with
nodes outside.
 
6LoWPAN provides a compressed header format for "mesh routing", meaning
multihop forwarding of packets within the 802.15.4 link.  Such a link is
assumed to be formed by a contiguously connected set of 802.15.4 nodes.  The
presence of such "mesh routing" capabilities does not eliminate the need for
layer 3 routing.  If a 15.4 node communicates with a remote node, say an
802.11 node, how is routing and forwarding carried out?  If two "LoWPAN
subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4-to-15.4
routing occur?  The 6LoWPAN header format is, of course, a general solution
for carrying IP over 802.15.4, so it is able to express these other forms of
routing, as well.  In the extreme case, each individual node is an IP link
and all routing is done at the IP layer.  On the other hand, patches of
nodes may want to function as a logical subnet, even if the wireless
multihop routing is done at the IP layer.  At this point, the concerns
overlap with those addressed in autoconf (cf.,
draft-ietf-autoconf-manetarch-01).
 
There is substantial commonality of concerns at the different layers of
multihop routing, but also differences.  It is also important to separate
the process of forming a routing topology from the process of forwarding
packets.  Both of which are distinct (but not entirely independent of) how
power management (turning on/off the radios) is performed.

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

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 May 2007 04:33:31 +0200

Dear List members,

Looking at the number of people who registered to this list, there  
seems to be a strong interest in designing a Routing solution for  
Sensor Networks. David and I had during the last few months a number  
of off-line discussions with positive feed-back and support, it is  
now a good time to use the Mailing List to gauge whether there is a  
consensus on whether to work on this topic.

David provided an excellent problem statement below. I'd like to add  
a few comments and get feed-back from the ML members on whether we  
collectively want to work on this item.

With no doubt, we'll see many other radio networks emerging soon and  
sensor networks will soon be made links using various layer1/2  
protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non  
wireless links. Such networks will also comprise sensor nodes with a  
wide range of capabilities, which makes the routing fairly unique in  
term of requirement. Thus the proposal is to design a IP routing  
solution specifically for sensor networks, that would of course be  
independent to the L1/L2 protocol in use (it may be desirable to take  
into account link layer attributes when calculating a route but the  
routing process would not be tied up with the link layer).

It looks fairly obvious that a network made of N "mesh-under" routing  
protocols is very unlikely to satisfy an end to end path constraint  
and would be fairly complex to manage and tune. We all remember the  
issue of IP routing over ATM PVCs routed by PNNI. Think of this with  
N "Mesh-under" routing protocols. That said, this is not to say that  
we exclude the use of "mesh-under" solutions, but we propose to  
define a IP-based routing protocol.

What would be a charter proposal ?

First we would need to spend a good amount of time on the routing  
requirements. David and I posted a first revision of a generic  
requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next  
revision will soon be posted accounting for the comments received so  
far. I would propose to continue to list the generic requirements in  
this draft and have other application-specific routing requirements  
drafts discussed in other IDs: for home networking, industrial  
applications, ... Such approach has been successfully adopted in  
other WGs.

The second step would consist of making a survey on the existing  
routing protocols and see whether (1) they could be used as such (2)  
they should be adapted (for instance, see whether AODV or OLR or RIP  
could be made energy efficient, could support some form of  
constrained based routing, ...) or (3) we should design a new generic  
new protocol.

Note that we may not be able to satisfy all the requirements, and  
this might be perfectly acceptable and should be documented. Indeed,  
we all know that Sensor Networks may significantly differ in term of  
degree of mobility, link layer reliability/bandwidth, node  
constraints, ... A very good outcome of this work might be that the  
newly defined/adapted protocol could satisfy the requirement IDs A,  
B, D and E but not C.

So please use this list to provide feed-back on whether you would  
support such initiative and if so your contribution is more than  
welcome. Note that several people already mentioned some interest and  
we do expect to see new IDs posted before Chicago.

JP and David.

Begin forwarded message:

> From: "dculler" <[email-masked]>
> Date: May 23, 2007 1:24:58 AM GMT+02:00
> To: <[email-masked]>
> Subject: [RSN] Interest in the Interplay of "routing" and "meshing"
> Reply-To: [email-masked]
>
> Several of the comments on this list have touched on the issue of  
> different kinds of "multihop routing" in the context of sensor  
> networks.  Is there interest in working on how these forms of  
> routing tie together?
>
> To make the question more grounded:  Low power radios have  
> relatively short range.  IEEE 802.15.4 radios are typically 1 mW  
> transmit power, vs 100 mW for 802.11, and have typical ranges in  
> 10s to 100 m.  Generally speaking, the power required to  
> communicate a given distance by radio grows polynomially with  
> distance.  In typical settings it grows like the cube, but it can  
> be much worse near the ground or somewhat better with directional  
> antennas.  The cost to communicate hop-by-hop grows only linearly,  
> and it offers the potential to route around obstacles and enhance  
> reliability through "receiver diversity".
>
> The question is at what layer(s) in the stack this routing occurs  
> and how it relates to IP routing more generally.  Most multihop  
> protocols in the sensor network research community are effectively  
> at layer2 - they form a single "patch" of homogeneous media.   
> Logically, they are a subnet, although few of the protocols address  
> what happens beyond the "patch" of sensor nodes, other than that  
> some of the nodes are "gateways".  Current industry standards, such  
> as Zigbee, Zwave, and wirelessHART, are also a "multihop link",  
> leaving open the question of how nodes within the sensor patch  
> communicate with nodes outside.
>
> 6LoWPAN provides a compressed header format for "mesh routing",  
> meaning multihop forwarding of packets within the 802.15.4 link.   
> Such a link is assumed to be formed by a contiguously connected set  
> of 802.15.4 nodes.  The presence of such "mesh routing"  
> capabilities does not eliminate the need for layer 3 routing.  If a  
> 15.4 node communicates with a remote node, say an 802.11 node, how  
> is routing and forwarding carried out?  If two "LoWPAN  
> subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4- 
> to-15.4 routing occur?  The 6LoWPAN header format is, of course, a  
> general solution for carrying IP over 802.15.4, so it is able to  
> express these other forms of routing, as well.  In the extreme  
> case, each individual node is an IP link and all routing is done at  
> the IP layer.  On the other hand, patches of nodes may want to  
> function as a logical subnet, even if the wireless multihop routing  
> is done at the IP layer.  At this point, the concerns overlap with  
> those addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01).
>
> There is substantial commonality of concerns at the different  
> layers of multihop routing, but also differences.  It is also  
> important to separate the process of forming a routing topology  
> from the process of forwarding packets.  Both of which are distinct  
> (but not entirely independent of) how power management (turning on/ 
> off the radios) is performed.
>
>

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 23 May 2007 11:35:24 +0200

> ... it is now a good time to use the Mailing List to gauge whether
there is a consensus on whether to work on this topic. 
 
Speaking on behalf of Zensys, we are ready to go on with this topic.
 
I expect to provide input to the Home Automation requirements ID within
a few weeks.
Anyone else focusing on this domain are invited to join.
 
Best regards,
  
-------------
Anders Brandt
Senior Software Architect
 
Zensys
 
phone: +45 70209940
fax:   +4570209950
mail: [email-masked] <mailto:[email-masked]> 
web: www.zen-sys.com <http://www.zen-sys.com/> 
_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 24 May 2007 15:45:44 +0200

Hi JP:

Please see inline:

It looks fairly obvious that a network made of N "mesh-under" routing protocols is very unlikely to satisfy an end to end path constraint and would be fairly complex to manage and tune. We all remember the issue of IP routing over ATM PVCs routed by PNNI. Think of this with N "Mesh-under" routing protocols. That said, this is not to say that we exclude the use of "mesh-under" solutions, but we propose to define a IP-based routing protocol. 

Pascal => I agree there's a lot of value to federate over IP the various approaches that are defined for mesh-under. 

The second step would consist of making a survey on the existing routing protocols and see whether (1) they could be used as such (2) they should be adapted (for instance, see whether AODV or OLR or RIP could be made energy efficient, could support some form of constrained based routing, ...) or (3) we should design a new generic new protocol. 

Pascal => One aspect of this could be to consider the features that mesh and sensor networks have deployed and why, and then see if there is a need to generalize the approach at layer 3. For instance, offline routing is popular in WSNs while not the prominent model in IP or MANET.

Pascal => Another specificity could be to work on a tighter integration with the radio and a more specific abstraction for L3. I know we have that barrier at IETF against L2 related activities. Yet, if the radio model provides such things as beacons, then it could be beneficial to define a routing protocol that can take advantage of the beacons. At the moment, IP is carried in data frames only.

Pascal => We'll also have to work out the relationship with MANEMO. My understanding is that MANEMO is for bigger boxes (routers really) and has strong mobility and global reachability constraints. That makes it pretty different in the objectives. OTOH, there seems to be value to keep sharing views and ideas between the groups, should they form.

Pascal

---

From: "Miguel Sanchez" <[email-masked]>
Date: Thu, 24 May 2007 15:55:53 +0200

Hi all:

As Pascal just mentioned, I'm not certain IETF is the right forum for this
discussion as I can see how including IP protocol into sensor networks makes
sense from the point of view of IETF. My question is whether or not we can
say the same from the point of view of many sensor networks.

Please not I formulate my point a question to stimulate the debate, by means
of what I hope we all may learn more about it.

Best regards,

Miguel Sánchez
Polytechnic University of Valencia, Spain
_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 May 2007 16:34:09 +0200

Hi JP, I've received this on the MANEMO list but I'm replying here.

I have some comments, more like against forming the RSN work, but
I'm ok with all other opinions too :-)

One is that I generally don't really see why routing for sensor networks
is different than other networks.  Or maybe that it is generally too
early for that.

One can interpret that routing for serverfarms is same as routing for
laptops (same std routing protocols) - and serverfarms and laptops have
very different energy requirements.  Or, sensors are to laptops what
laptops are to serverfarms...

JP Vasseur wrote:
> protocols defined by other SDOs: 802.15.4,

802.15.4 no doubt offers its own link-layer routing... IP routing not
necessary here.

> Wifi,

WiFi has a very clear network topology (BAse Station and mobile) where
routing is not necessary at all over the air (neither link-layer nor
IP).  Most deployments are done this way and I haven't seen any wifi
deployment needing IP routing.

> WiMax

Same as wifi.  No need for IP routing for WiMax over the air and down to
mobile.

BEsides, I doubt WiFi or WiMAx can be used by the smallest of the
sensors...  I really don't see a sensor having WMAN  capability... it's
really too far-fetched.

Or do you mean to IP route and gate through the heterogeneity of these
wireless link-layers?

> but also *non wireless links*.

Which ones?  I think that the smallest wired network interfaces and
connections are Ethernet and probably USB.

> Such networks will also comprise sensor nodes with a wide range of 
> capabilities, *which makes the routing fairly unique in term of 
> requirement*. Thus the proposal is to design a IP routing solution 
> specifically for sensor networks, that would of course be independent
>  to the L1/L2 protocol in use (it may be desirable to take into 
> account link layer attributes when calculating a route but the 
> /*What would be a charter proposal ?*/
> 

I agree with this point.

MANEMO effort was recently (in March) directed to analyse what MANET
protocol can satisfy the MANEMO needs.

I think that if one goes to MANET and asks one will most certainly find
out that MANET protocols (currently: DYMO, OLSRv2 and NDHP) can surely
deal with RSN needs.  I think that will be a tough barrier to overcome
if one wants to build a new RSN protocol.

> degree of mobility,

Mobility?  I think sensor networks once deployed are not mobile at all.
  Neither do they move homogeneously as a group (with respect to Earth),
nor do they move with respect to each-other.

> link layer reliability/bandwidth, node constraints, ... A very good 
> outcome of this work might be that the newly defined/adapted protocol
>  could satisfy the requirement IDs A, B, D and E but not C.
> 

What's the potential interaction between RSN and MANEMO?

Will a vehicle full of sensors talk to another such vehicle by using RSN
or MANEMO protocol?  Or MANET protocol?

Alex

> 
> JP and David.
> 
> Begin forwarded message:
> 
>> *From: *"dculler" <[email-masked] 
>> <mailto:[email-masked]>> *Date: *May 23, 2007 1:24:58 AM 
>> GMT+02:00 *To: *<[email-masked] <mailto:[email-masked]>> *Subject: 
>> **[RSN] Interest in the Interplay of "routing" and "meshing"* 
>> *Reply-To: [email-masked] <mailto:[email-masked]>
>> 
>> 10s to 100 m. Generally speaking, the power required to communicate
>>  a given distance by radio grows polynomially with distance.  In 
>> typical settings it grows like the cube, but it can be much worse 
>> near the ground or somewhat better with directional antennas.  The 
>> cost to communicate hop-by-hop grows only linearly, and it offers 
>> the potential to route around obstacles and enhance reliability 
>>  is routing and forwarding carried out?  If two "LoWPAN subnets" 
>> [sic] happen to be connected by 15.4 nodes, how does 15.4-to-15.4 
>> routing occur?  The 6LoWPAN header format is, of course, a general 
>> solution for carrying IP over 802.15.4, so it is able to express 
>> these other forms of routing, as well.  In the extreme case, each 
>> individual node is an IP link and all routing is done at the IP 
>> layer.  On the other hand, patches of nodes may want to function as
>>  a logical subnet, even if the wireless multihop routing is done at
>>  the IP layer.  At this point, the concerns overlap with those 
>> addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01).
>> 
>>  (but not entirely independent of) how power management (turning 
>> on/off the radios) is performed.
>> 
>> 
>> _______________________________________________ RSN mailing list 
>> [email-masked] <mailto:[email-masked]> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> _______________________________________________ RSN mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/rsn

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Philip Levis <[email-masked]>
Date: Thu, 24 May 2007 16:17:36 -0700

> is different than other networks.  Or maybe that it is generally too

Routing for sensornets is different than other networks because they  
operate under different constraints. The two major differences are:

1) Nodes are energy-limited.
2) One repercussion of 1) is that nodes are state-limited.

You can take existing routing approaches, such as AODV, DYMO, GPSR,  
etc. and apply them to sensor networks. Users have done so. Practice  
has shown, however, that they don't work that well and generally  
aren't a very good fit. Instead, working versions of these protocols  
typically constrain the protocol. For example, the AODV  
implementation for sensor nodes[1] supports routing to a single  
destination.  High densities, combined with slow radios (a product of  
energy concerns), make flooding discovery such as AODV's tricky to  
get right, especially without some kind of scoping. Fundamentally,  
links behave differently during a flood than during unicast flows due  
to the correlations in packet transmissions.

David summarized many of the implications of 2) very well in a  
message to the 6lowpan list. In the context of routing, having each  
node store up to O(n) state is generally unfeasible. Capping the  
routing state to some value R obviously has problems if you need R+1  
routes. Achieving scalable unicast communication within a state- 
limited wireless network is a very active area of research. Right  
now, the state of the art (S4, presented at NSDI in March, which uses  
compact routing) requires O(sqrt(n)) state. Achieving this, however,  
requires embedding a little bit more information in a routing packet  
besides the destination address.

Phil

[1] tinyos-1.x/contrib/hsn/tos/lob/AODV.nc from http:// 
sourceforge.net/cvs/?group_id=28656

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 May 2007 14:57:35 +0200

Pascal,

> Pascal => Another specificity could be to work on a tighter
integration with the radio and a more specific abstraction for L3.
> I know we have that barrier at IETF against L2 related activities.
Yet, if the radio model provides such things as beacons,
> then it could be beneficial to define a routing protocol that can take
advantage of the beacons. At the moment, IP is carried
> in data frames only.

Since the basic goal of the RSN work is to achieve a Layer 2 technology
agnostic routing mechanism, awareness of beacon capabilities seems to be
a drastic move.
I suppose the goal for us must be to describe a L2 service API, which
gives a sufficiently precise abstraction of the link layer so that the
routing layer can make sensible decisions.

Whether beacons or some other arbitration strategy is used should not be
relevant to the routing layer. What is important is which capabilites is
provided by the lower layer, such as:

* Guaranteed delivery to another node (Yes/No)
* Worst-case time for delivery of a packet to another node (may depend
on target node capabilities)
* Power properties (AC / AC w. batt. Backup / Big battery / Button cell
battery / Environmental -sun or wind)
* Availability of another node (A sun-powered node may be available and
reliable for long periods, but not always...)

I see RSN as a strong initiative because it is targeting a sensor world
with just a good integration of technologies as classic IP provides
today:
I do not have to worry whether my IP traffic is running over GPRS, ADSL,
ATM, Ethernet, MPLS or WiFi.

In exactly the same way, RSN should provide seamless operation between
sensor solutions running over Z-Wave, 802.15.4 and other wireless
low-power technologies.

Br.
  Anders

-------------
Anders Brandt
 
Zensys
Emdrupvej 26
DK-2100 Copenhagen O
DENMARK
 
phone: +45 70209940
fax:   +4570209950
mail: [email-masked]
web: www.zen-sys.com

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 25 May 2007 15:41:12 +0200

>routing layer can make sensible decisions.

Pascal => I would question that. I suspect that we need to define a
sensor network abstraction and define a routing protocol for that
abstraction. If the abstraction is really agnostic of the radio layer,
then we might be missing a chance to get the optimizations that can be
so critical in WSNs. 

Pascal => For instance, I believe that an abstract notion of beacon can
be useful to advertise L3 triggers that will help in peer selection,
considering that the memory footprint will not enable to track all peers
at all times. You can imagine that the L2 abstraction provides an
optional timely broadcast on which L3 message can be passed, with a
fallback solution of triggering a data frame broadcast if the beacon is
not provided by one specific MAC.

>reliable for long periods, but not always...)
Pascal => Agreed but it's a different level. These are metrics and
constraints that will enter in path selection. I was discussing a
potential optimization of the flow of the PDUs that would depend on how
well we can exploit L2 mechanisms.

---

From: "Nielsen Klaus Sonderskov" <[email-masked]>
Date: Fri, 25 May 2007 16:02:35 +0200

Hi JP,

Just following this effort on the side... and hearing talks about RSN being done in L2... would it by any chance be beneficial/possible to talk about placing the routing on top of 6LowPan? From my point of view placing routing on top of 6LowPan would add large amount of benefits to the sensor community for building low power sensor networks on various technologies. The benefit would come in taking the 6LowPan specification and just change the adaptation layer to whatever PHY you have underneath, and while not tie the RSN effort to the PHY there will be no change to RSN if we were to use a different technology. Adding the possibility to create interoperable applications running on 802.15.4, FSK, 802.11 seamlessly on the same network (only having thin PHY translators)... as David mentions below. 

Perhaps, there need to be a study of what are the costs in power/latency etc. by have routing entirely on top of 6LowPan. 

Best regards / Med venlig hilsen
Klaus Sønderskov Nielsen
Danfoss A/S, Communication Technology Centre

________________________________

From: JP Vasseur [mailto:[email-masked]] 
Sent: Wednesday, May 23, 2007 4:34 AM
To: [email-masked]
Subject: [RSN] Next step for RSN ?

Dear List members,

Looking at the number of people who registered to this list, there seems to be a strong interest in designing a Routing solution for Sensor Networks. David and I had during the last few months a number of off-line discussions with positive feed-back and support, it is now a good time to use the Mailing List to gauge whether there is a consensus on whether to work on this topic.

David provided an excellent problem statement below. I'd like to add a few comments and get feed-back from the ML members on whether we collectively want to work on this item.

With no doubt, we'll see many other radio networks emerging soon and sensor networks will soon be made links using various layer1/2 protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non wireless links. Such networks will also comprise sensor nodes with a wide range of capabilities, which makes the routing fairly unique in term of requirement. Thus the proposal is to design a IP routing solution specifically for sensor networks, that would of course be independent to the L1/L2 protocol in use (it may be desirable to take into account link layer attributes when calculating a route but the routing process would not be tied up with the link layer). 

First we would need to spend a good amount of time on the routing requirements. David and I posted a first revision of a generic requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next revision will soon be posted accounting for the comments received so far. I would propose to continue to list the generic requirements in this draft and have other application-specific routing requirements drafts discussed in other IDs: for home networking, industrial applications, ... Such approach has been successfully adopted in other WGs.

Note that we may not be able to satisfy all the requirements, and this might be perfectly acceptable and should be documented. Indeed, we all know that Sensor Networks may significantly differ in term of degree of mobility, link layer reliability/bandwidth, node constraints, ... A very good outcome of this work might be that the newly defined/adapted protocol could satisfy the requirement IDs A, B, D and E but not C. 

So please use this list to provide feed-back on whether you would support such initiative and if so your contribution is more than welcome. Note that several people already mentioned some interest and we do expect to see new IDs posted before Chicago.

JP and David.

Begin forwarded message:

To: <[email-masked]>

Several of the comments on this list have touched on the issue of different kinds of "multihop routing" in the context of sensor networks.  Is there interest in working on how these forms of routing tie together?

To make the question more grounded:  Low power radios have relatively short range.  IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 mW for 802.11, and have typical ranges in 10s to 100 m.  Generally speaking, the power required to communicate a given distance by radio grows polynomially with distance.  In typical settings it grows like the cube, but it can be much worse near the ground or somewhat better with directional antennas.  The cost to communicate hop-by-hop grows only linearly, and it offers the potential to route around obstacles and enhance reliability through "receiver diversity".  

The question is at what layer(s) in the stack this routing occurs and how it relates to IP routing more generally.  Most multihop protocols in the sensor network research community are effectively at layer2 - they form a single "patch" of homogeneous media.  Logically, they are a subnet, although few of the protocols address what happens beyond the "patch" of sensor nodes, other than that some of the nodes are "gateways".  Current industry standards, such as Zigbee, Zwave, and wirelessHART, are also a "multihop link", leaving open the question of how nodes within the sensor patch communicate with nodes outside.

6LoWPAN provides a compressed header format for "mesh routing", meaning multihop forwarding of packets within the 802.15.4 link.  Such a link is assumed to be formed by a contiguously connected set of 802.15.4 nodes.  The presence of such "mesh routing" capabilities does not eliminate the need for layer 3 routing.  If a 15.4 node communicates with a remote node, say an 802.11 node, how is routing and forwarding carried out?  If two "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4-to-15.4 routing occur?  The 6LoWPAN header format is, of course, a general solution for carrying IP over 802.15.4, so it is able to express these other forms of routing, as well.  In the extreme case, each individual node is an IP link and all routing is done at the IP layer.  On the other hand, patches of nodes may want to function as a logical subnet, even if the wireless multihop routing is done at the IP layer.  At this point, the concerns overlap with those addressed in autoconf (cf., draft-ietf-autoconf-manetarch-01).

There is substantial commonality of concerns at the different layers of multihop routing, but also differences.  It is also important to separate the process of forming a routing topology from the process of forwarding packets.  Both of which are distinct (but not entirely independent of) how power management (turning on/off the radios) is performed.

RSN mailing list

[email-masked]

---

From: JP Vasseur <[email-masked]>
Date: Fri, 25 May 2007 10:04:50 -0400

Hi anders,

Thanks for your feed-back and support in this initiative considering  
your experience in Home Networking for Sensor.

In line,

> reliable for long periods, but not always...)

Indeed, such capabilities will be used by the routing layer for  
efficient constrained routing. Note that node capability is another  
example of unique requirements for Sensor Nets, not covered in most  
existing IP routing protocols.

> ATM, Ethernet, MPLS or WiFi.

Indeed.

> sensor solutions running over Z-Wave, 802.15.4 and other wireless

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 25 May 2007 10:05:20 -0400

Hi Pascal,

> then we might be missing a chance to get the optimizations that can be

I think you both agree: we do want to be able to have an IP routing  
protocol not tied up with a specific layer 2 but it may be desirable to
get layer2 information used for routing, this is why I wrote in my  
original email:

" ... Thus the proposal is to design a IP routing solution  
specifically for sensor networks, that would of course be independent  
to the L1/L2 protocol in use (it may be desirable to take into  
account link layer attributes when calculating a route but the  
routing process would not be tied up with the link layer). ..."

> not provided by one specific MAC.

Agree, similarly to what is being done in today's network when SONET/ 
SDH/Optical parameters are used by the layer 3.
But still, we want a routing solution working above any type of  
layer-2, we're in sync.

> well we can exploit L2 mechanisms.

Yes.

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Fri, 25 May 2007 09:16:48 -0700

Comments inline.

> routing layer can make sensible decisions.

In the TinyOS world, the networking working group struggled with a  
very similar problem when defining a "standard" collection protocol.  
Note that this effort (still ongoing) has two separate parts, the  
first being the specification of a standard API for TinyOS, the  
second being the specification of the protocol format itself. As  
TinyOS runs on top of a lot of link layers -- full 802.15.4,  
alternative MACs using the 15.4 link layer, FSK radios in the 900MHz  
and 433MHz band, etc. -- deciding on a minimal set of features that a  
multihop (layer 3) protocol could assume was fairly important.

Note that these relate only to one particular protocol (an anycast  
collection tree): IP routing may have different requirements which  
call for a different layer 2 abstraction. Nevertheless, these may  
provide a strawman proposal. The four requirements the group settled  
on were[1]:

"The CTP protocol assumes that the data link layer provides four things:

1) Provides an efficient local broadcast address.
2) Provides synchronous acknowledgments for unicast packets.
3) Provides a protocol dispatch field to support multiple higher-level
     protocols.
4) Has single-hop source and destination fields."

Some of these might seem obvious, but it turns out that historically  
there have been link protocols that didn't have them. For example,  
early active messages in TinyOS (e.g., 1.1 and earlier) did not have  
a layer 2 source address. Similarly, not all TDMA protocols provide  
an efficient local broadcast address. Finally, 802.15.4 by itself  
does not provide a protocol dispatch field, so this means a link  
layer on top of 15.4 must add one.

The requirement for synchronous layer 2 acknowledgements turns out to  
be pretty critical. Without it, it is very difficult for a protocol  
to quickly adapt to link variations. Unless there are single-hop  
acknowledgements issued by the layer 3 protocol -- which can really  
disrupt protocol timing in the wireless domain, as it introduces  
additional interference along a path -- detecting the cause of an end- 
to-end failure is difficult and retransmissions may just fail on the  
same link. Note that these 4 requirements do not include being able  
to overhear unicast packets destined to another node (snooping). This  
is a common assumption in the sensornet world, but turns out to be  
difficult or inefficient on some hardware, so we didn't include it.

> provided by the lower layer, such as:

One way to generalize "beacons" is "efficient local broadcast."

> * Guaranteed delivery to another node (Yes/No)

This is of course impossible. A better way to phrase it is  
"mechanisms for improved reliability."

> on target node capabilities)

This is also impossible (see above).

> battery / Environmental -sun or wind)

Rather than the property you care about, it might be better to start  
from the goal. Generally, the issue raised by variable power levels  
is that some nodes might be more willing to communicate than others  
are. If a node can control its routing metric, then it can influence  
whether other nodes will route through it. E.g., in a protocol that  
uses hop count to decide on a minimum cost path, nodes that want to  
route less traffic can increase their advertised hopcount (e.g., they  
add more than one "hop" to a route).

Phil

[1] TEP 123: The Collection Tree Protocol (CTP) http://www.tinyos.net/ 
tinyos-2.x/doc/html/tep123.html

---

From: Philip Levis <[email-masked]>
Date: Fri, 25 May 2007 09:26:32 -0700

> then we might be missing a chance to get the optimizations that can be

Clearly it can't be completely agnostic. The point is that if you  
make it specifically 802.15.4, then you're stuck once 802.15.99 (a  
hypothetical better and improved link layer) emerges. This requires  
distinguishing which parts of the abstraction are essential and which  
are ancillary. Minimalist abstractions give flexibility above and below.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Sat, 26 May 2007 11:16:43 -0400

Hi Alexandru,

> laptops are to serverfarms...

Phil already replied to this comment but let me add a new more things  
since this is the *key* reason for RSN: no, sensor networks
are very significantly different from other IP networks, in many  
respects and this is why an adequate routing solution is required.
Should you want to have a look at the requirements, please ready  
draft-culler-rsn-routing-reqs. Note that other routing application
specific IDs are in the works.

Without reiterating the set of unique requirements that affect the  
routing protocol for Sensor Nets, here are some comments with
regards to your statements:
1) First a laptop is usually a host rather than a router, but this is  
a cosmetic comment since it could perfectly run a routing protocol
and Linux machine running OSPF are sometimes used as router for  
experiments. Anyway, just a side note.
2) When you look at the routing protocols in used in the Internet  
(IGP), they are not designed/optimized for networks with low  
bandwidth links,
unreliable links and highly constraints nodes, the last aspects being  
key here since the computed path (SPT) does not taken into
account the node characteristics (other than potential node pruning  
using node cap).
There are networks with heterogenous devices indeed but the path is  
not a function of the nodes but the links using Dijkstra. This leads  
to defining IP constrained based routing while addressing the  
requirements of unreliable and dynamic topologies due to mobility and  
unstable links or nodes. Again the notion of constrained based  
routing (that has been designed in other contexts (MPLS)) differs  
from existing IGPs.

Other requirements such as QoS aware routing, MTR, ... have been  
defined for other IGPs but would very likely require a different
solutions here because of node constraints.

This is particularly unique to Sensor Networks. So your analogy does  
not hold at all here.

>> Sensor Networks. David and I had during the last few months a  
>> number of off-line discussions with positive feed-back and  
>> support, it is now a good time to use the Mailing List to gauge  
>> whether there is a consensus on whether to work on this topic.
>> David provided an excellent problem statement below. I'd like to  
>> add a few comments and get feed-back from the ML members on  
>> whether we collectively want to work on this item.
>> With no doubt, we'll see many other radio networks emerging soon  
>> and sensor networks will soon be made links using various layer1/2  

You're missing the point here of networks made of a variety of links  
of different natures, thus my comments to provide a routing
solution offering an end to end constrained path (this is not the  
only requirement): this is clearly extremely challenging without a IP  
routing solution independent of
the link layer.

> connections are Ethernet and probably USB.

You can perfectly have a Sensor Networks made of RF links and wired  
links.

>>  protocols is very unlikely to satisfy an end to end path  
>> constraint and would be fairly complex to manage and tune. We all  
>> remember the issue of IP routing over ATM PVCs routed by PNNI.  
>> Think of this with N "Mesh-under" routing protocols. That said,  
>> this is not to say that we exclude the use of "mesh-under"  
>> solutions, but we propose to define a IP-based routing protocol.
>> revision will soon be posted accounting for the comments received  
>> so far. I would propose to continue to list the generic  
>> requirements in this draft and have other application-specific  
>> routing requirements drafts discussed in other IDs: for home  
>> networking, industrial applications, ... Such approach has been  
>> successfully adopted in other WGs.
>> routing protocols and see whether (1) they could be used as such  
>> (2) they should be adapted (for instance, see whether AODV or OLR  
>> or RIP could be made energy efficient, could support some form of  

Ah.

> if one wants to build a new RSN protocol.

See my previous comment: No we cannot make the assumption that AODV  
or OLSR will be the protocol to use. It MAY be an excellent
solution with adaptations though. This is why the proposal is indeed  
to have a place where we could make a clear analysis of the requirements
and come up with a solution, which again could be based on Manemo,  
AODV, ... or a new routing protocol. There is NO reason to define a
new protocol if not needed and we do not want at the IETF to invent  
protocols when not required. On the other hand, it is certainly a bad  
idea
to state a priori that a protocol X should be used or could be used  
with several extensions if this is not the correct long term  
approach. We could
mention many examples where using an existing protocol and adapt it  
to meet new requirements was indeed the right solution but there are
also a number of example where we had to live with poorly engineered  
solutions, thus the proposed approach.

Does that clarify the approach ?

>> this might be perfectly acceptable and should be documented.  
>> Indeed, we all know that Sensor Networks may significantly differ  
>> in term of degree of mobility,
>

Ah no life is not so simple ;-) ... As pointed out, there are many  
types of sensor networks. Some of them are completely static indeed but
there are also many sensor networks where nodes are mobile with  
various degree of mobility. Just to mention two examples (among many
other ones): healthcare with wearable sensors (see the SMART project  
as one example of deployed network), vehicular, industrial (with
sensor on containers, moving machines, ...), ...

Now here is one of our challenges: since there are so many potential  
deployment cases, you could indeed come up with a superset of all
requirements and more than likely there won't be any protocols that  
would meet all of them, especially if designed for constrained nodes.
So we would have to identify a core set of requirements, specify the  
solution and potentially document that this protocol would not be used
for some applications (e.g DTN sensor nets, ... might be  
challenging). This is a perfectly fine approach.

>
>> link layer reliability/bandwidth, node constraints, ... A very  
>> good outcome of this work might be that the newly defined/adapted  
>> protocol

MANEMO is a good candidate to be evaluated once the detailed  
requirements work will have been completed.

> or MANEMO protocol?  Or MANET protocol?

This is part of the work item.

Thanks, hope this helps.

JP.

>>> <mailto:[email-masked]>> *Date: *May 23, 2007 1:24:58 AM GMT 
>>> +02:00 *To: *<[email-masked] <mailto:[email-masked]>> *Subject: ** 
>>> [RSN] Interest in the Interplay of "routing" and "meshing"*  
>>> near the ground or somewhat better with directional antennas.   
>>> The cost to communicate hop-by-hop grows only linearly, and it  
>>> offers the potential to route around obstacles and enhance  
>>> protocols in the sensor network research community are  
>>> effectively at layer2 - they form a single "patch" of homogeneous  
>>> media. Logically, they are a subnet, although few of the  
>>> protocols address
>>> subnets" [sic] happen to be connected by 15.4 nodes, how does  
>>> 15.4-to-15.4 routing occur?  The 6LoWPAN header format is, of  
>>> course, a general solution for carrying IP over 802.15.4, so it  
>>> is able to express these other forms of routing, as well.  In the  
>>> extreme case, each individual node is an IP link and all routing  
>>> is done at the IP layer.  On the other hand, patches of nodes may  
>>> want to function as
>>> [email-masked] <mailto:[email-masked]> https://www1.ietf.org/mailman/ 
>>> listinfo/rsn

---

From: Zach Shelby <[email-masked]>
Date: Mon, 28 May 2007 08:55:11 +0300

Hi,

I support the RSN effort and like the requirements-based approach. A few 
comments on the lastest e-mail exchanges.

- I like the minimum set of link-layer features approach suggested by 
Philip. In addition optional features such as providing RSSI/ToA could 
be listed as well. This should be added to the req ID?

- Although RSN is independent of e.g. WiFi or 6lowpan mesh-under, it 
should be aware of them, differentiated from them, and compatible with 
them. I suggest that the interoperability with these mesh-under 
techniques be made explicit in the RSN req ID. This does not lock RSN 
into any particular L1/L2 technique, but simply ensures 
interoperability. Unlike in Ethernet bridget networks, where latencies 
are very minimal, a mesh-under subnet in a low-speed wireless network 
will have very different properties than a single hop. We should also be 
explicit to avoid confusion with the 6lowpan work. Don't underestimate 
mesh-under, in the WiFi world it is really what is being successfully 
deployed.

- Application specific variants of the routing protocol reqs is a good 
idea.

Zach

JP Vasseur wrote:
> Dear List members,
> 
> Looking at the number of people who registered to this list, there seems 
> to be a strong interest in designing a Routing solution for Sensor 
> Networks. David and I had during the last few months a number of 
> off-line discussions with positive feed-back and support, it is now a 
> good time to use the Mailing List to gauge whether there is a consensus 
> on whether to work on this topic.
> 
> David provided an excellent problem statement below. I'd like to add a 
> few comments and get feed-back from the ML members on whether we 
> sensor networks will soon be made links using various layer1/2 protocols 
> defined by other SDOs: 802.15.4, Wifi, WiMax but also non wireless 
> links. Such networks will also comprise sensor nodes with a wide range 
> of capabilities, which makes the routing fairly unique in term of 
> requirement. Thus the proposal is to design a IP routing solution 
> specifically for sensor networks, that would of course be independent to 
> the L1/L2 protocol in use (it may be desirable to take into account link 
> layer attributes when calculating a route but the routing process would 
> not be tied up with the link layer).
> 
> protocols is very unlikely to satisfy an end to end path constraint and 
> would be fairly complex to manage and tune. We all remember the issue of 
> IP routing over ATM PVCs routed by PNNI. Think of this with N 
> "Mesh-under" routing protocols. That said, this is not to say that we 
> exclude the use of "mesh-under" solutions, but we propose to define a 
> IP-based routing protocol.
> 
> applications, ... Such approach has been successfully adopted in other WGs.
> 
> The second step would consist of making a survey on the existing routing 
> protocols and see whether (1) they could be used as such (2) they should 
> be adapted (for instance, see whether AODV or OLR or RIP could be made 
> energy efficient, could support some form of constrained based routing, 
> ...) or (3) we should design a new generic new protocol.
> 
> Note that we may not be able to satisfy all the requirements, and this 
> might be perfectly acceptable and should be documented. Indeed, we all 
> know that Sensor Networks may significantly differ in term of degree of 
> mobility, link layer reliability/bandwidth, node constraints, ... A very 
> protocol could satisfy the requirement IDs A, B, D and E but not C.
> 
> welcome. Note that several people already mentioned some interest and we 
> do expect to see new IDs posted before Chicago.
> 
> JP and David.
> 
> Begin forwarded message:
> 
>> networks.  Is there interest in working on how these forms of routing 
>> tie together?
>>
>> To make the question more grounded:  Low power radios have relatively 
>> short range.  IEEE 802.15.4 radios are typically 1 mW transmit power, 
>> vs 100 mW for 802.11, and have typical ranges in 10s to 100 m.  
>> Generally speaking, the power required to communicate a given distance 
>> by radio grows polynomially with distance.  In typical settings it 
>> grows like the cube, but it can be much worse near the ground or 
>> somewhat better with directional antennas.  The cost to communicate 
>> hop-by-hop grows only linearly, and it offers the potential to route 
>> around obstacles and enhance reliability through "receiver diversity".
>>
>> The question is at what layer(s) in the stack this routing occurs and 
>> how it relates to IP routing more generally.  Most multihop protocols 
>> in the sensor network research community are effectively at layer2 - 
>> they form a single "patch" of homogeneous media.  Logically, they are 
>> a subnet, although few of the protocols address what happens beyond 
>> the "patch" of sensor nodes, other than that some of the nodes are 
>> "gateways".  Current industry standards, such as Zigbee, Zwave, and 
>> wirelessHART, are also a "multihop link", leaving open the question of 
>> how nodes within the sensor patch communicate with nodes outside.
>>
>> meaning multihop forwarding of packets within the 802.15.4 link.  Such 
>> a link is assumed to be formed by a contiguously connected set of 
>> 802.15.4 nodes.  The presence of such "mesh routing" capabilities does 
>> not eliminate the need for layer 3 routing.  If a 15.4 node 
>> communicates with a remote node, say an 802.11 node, how is routing 
>> and forwarding carried out?  If two "LoWPAN subnets" [sic] happen to 
>> be connected by 15.4 nodes, how does 15.4-to-15.4 routing occur?  The 
>> 6LoWPAN header format is, of course, a general solution for carrying 
>> IP over 802.15.4, so it is able to express these other forms of 
>> routing, as well.  In the extreme case, each individual node is an IP 
>> link and all routing is done at the IP layer.  On the other hand, 
>> patches of nodes may want to function as a logical subnet, even if the 
>> wireless multihop routing is done at the IP layer.  At this point, the 
>> concerns overlap with those addressed in autoconf (cf., 
>> There is substantial commonality of concerns at the different layers 
>> of multihop routing, but also differences.  It is also important to 
>> separate the process of forming a routing topology from the process of 
>> forwarding packets.  Both of which are distinct (but not entirely 
>> independent of) how power management (turning on/off the radios) is 
>> performed.
>>
>>

-- 
Zach Shelby | Managing Director | +358 40 7796297
Sensinode Ltd.   www.sensinode.com

---

From: "Dominik Kaspar" <[email-masked]>
Date: Mon, 28 May 2007 16:35:40 +0900

Dear RSN List,

In my opinion, RSN should focus more on one basic problem or a number
of orthogonal problems. Especially for sensor networks, there is no
substitute for simplicity. This very basic requirement has been called
"light footprint" in draft-culler-rsn-routing-reqs-00, but seems to
have gone forgotten. The requirement list suggests a multi-purpose RSN
protocol, which dynamically adapts to topology changes, intelligently
switches between end-to-end routing and data diffusion, supports
data-aware routing, topology-dependent QoS, ...etc. I question the
feasibility of meeting such a complex set of orthogonal requirements
for sensor networks. In order words, which ones of the current
requirements, can we sacrifice?

Also..., is it the goal of RSN to provide IP-based querying of a
single sensor node in an end-to-end paradigm? Or is it the goal of RSN
to allow querying a network as an entity? Is it the goal to allow
sensors send their data to a sink on certain events? Is it the goal to
allow sensor nodes address other remote sensor nodes, too? Is the the
goal of RSN to support all of this at the same time?

The answers would help me to see RSN more clearly.

Regards,
Dominik.

On 5/23/07, JP Vasseur <[email-masked]> wrote:
> Dear List members,
>
> Looking at the number of people who registered to this list, there seems to
> be a strong interest in designing a Routing solution for Sensor Networks.
> David and I had during the last few months a number of off-line discussions
> with positive feed-back and support, it is now a good time to use the
> Mailing List to gauge whether there is a consensus on whether to work on
> this topic.
>
> David provided an excellent problem statement below. I'd like to add a few
> comments and get feed-back from the ML members on whether we collectively
> want to work on this item.
>
> With no doubt, we'll see many other radio networks emerging soon and sensor
> networks will soon be made links using various layer1/2 protocols defined by
> other SDOs: 802.15.4, Wifi, WiMax but also non wireless links. Such networks
> will also comprise sensor nodes with a wide range of capabilities, which
> makes the routing fairly unique in term of requirement. Thus the proposal is
> to design a IP routing solution specifically for sensor networks, that would
> of course be independent to the L1/L2 protocol in use (it may be desirable
> to take into account link layer attributes when calculating a route but the
> would be fairly complex to manage and tune. We all remember the issue of IP
> routing over ATM PVCs routed by PNNI. Think of this with N "Mesh-under"
> routing protocols. That said, this is not to say that we exclude the use of
> "mesh-under" solutions, but we propose to define a IP-based routing
> protocol.
>
> requirements. David and I posted a first revision of a generic requirement
> draft (draft-culler-rsn-routing-reqs-00.txt); the next
> revision will soon be posted accounting for the comments received so far. I
> would propose to continue to list the generic requirements in this draft and
> have other application-specific routing requirements drafts discussed in
> other IDs: for home networking, industrial applications, ... Such approach
> has been successfully adopted in other WGs.
>
> protocols and see whether (1) they could be used as such (2) they should be
> adapted (for instance, see whether AODV or OLR or RIP could be made energy
> efficient, could support some form of constrained based routing, ...) or (3)
> we should design a new generic new protocol.
>
> Note that we may not be able to satisfy all the requirements, and this might
> be perfectly acceptable and should be documented. Indeed, we all know that
> Sensor Networks may significantly differ in term of degree of mobility, link
> layer reliability/bandwidth, node constraints, ... A very good outcome of
> this work might be that the newly defined/adapted protocol could satisfy the
> requirement IDs A, B, D and E but not C.
>
> So please use this list to provide feed-back on whether you would support
> such initiative and if so your contribution is more than welcome. Note that
> several people already mentioned some interest and we do expect to see new
> IDs posted before Chicago.
>
> JP and David.
>
> Begin forwarded message:
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 28 May 2007 07:42:46 -0400

Hi Zach,

Thanks for supporting the initiative. Few comments in line,

On May 28, 2007, at 1:55 AM, Zach Shelby wrote:

> Hi,
>
> I support the RSN effort and like the requirements-based approach.  
> A few comments on the lastest e-mail exchanges.
>
> - I like the minimum set of link-layer features approach suggested  
> by Philip. In addition optional features such as providing RSSI/ToA  
> could be listed as well. This should be added to the req ID?
>
> - Although RSN is independent of e.g. WiFi or 6lowpan mesh-under,  
> it should be aware of them, differentiated from them, and  
> compatible with them. I suggest that the interoperability with  
> these mesh-under techniques be made explicit in the RSN req ID.  
> This does not lock RSN into any particular L1/L2 technique, but  
> simply ensures interoperability. Unlike in Ethernet bridget  
> networks, where latencies are very minimal, a mesh-under subnet in  
> a low-speed wireless network will have very different properties  
> than a single hop. We should also be explicit to avoid confusion  
> with the 6lowpan work. Don't underestimate mesh-under, in the WiFi  
> world it is really what is being successfully deployed.
>

We should certainly get some minimalist level of abstraction from the  
L1/L2, which should be worked out in concert with 6lowpan: this has  
been a quite common approach in designing routing protocols as long  
as we do not introduce dependencies, as you pointed out.
1) Minimalist link layer abstraction: it would be perfectly fine  
indeed to provide some data link characteristics to the routing layer  
such as the reliability, propagation delays, bandwidth. Such  
parameter may themselves be a function of a sub-layer routing  
function or just the environmental conditions. Two comments though:  
first, we will of course need to ensure that such characteristics are  
relevant and limited (let's remember some proposals to provide dozens  
of link attributes in some GMPLS networks leading to NP-complete path  
computation issues). Second, they should not be "too" dynamic (need  
dampening) because of uncontrolled sub-layer "routing" function: loop  
control feed-back may be a very good source of oscillation (examples  
of this nature are notorious), especially in situation of sporadic  
traffic load.
2) Inter-layer routing dependencies: what we must avoid is a routing  
protocol that would compute paths based upon the  decision of a mesh- 
under "routing" protocol. That would clear mean inter-layer dependency.

> - Application specific variants of the routing protocol reqs is a  
> good idea.

Thanks, your contribution will be welcome. So far two IDs are in the  
works:
	- Routing requirements for Home networking applications
	- Routing requirements for Industrial applications

We would probably need another ID for Healthcare applications since  
there are specific requirements to such applications.

Thanks.

JP.

>> protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also  
>> non wireless links. Such networks will also comprise sensor nodes  
>> with a wide range of capabilities, which makes the routing fairly  
>> unique in term of requirement. Thus the proposal is to design a IP  
>> routing solution specifically for sensor networks, that would of  
>> course be independent to the L1/L2 protocol in use (it may be  
>> desirable to take into account link layer attributes when  
>> calculating a route but the routing process would not be tied up  
>> with the link layer).
>> It looks fairly obvious that a network made of N "mesh-under"  
>> routing protocols is very unlikely to satisfy an end to end path  
>> constrained based routing, ...) or (3) we should design a new  
>> generic new protocol.
>> in term of degree of mobility, link layer reliability/bandwidth,  
>> node constraints, ... A very good outcome of this work might be  
>> that the newly defined/adapted protocol could satisfy the  
>> welcome. Note that several people already mentioned some interest  
>> and we do expect to see new IDs posted before Chicago.
>> JP and David.
>> Begin forwarded message:
>>> antennas.  The cost to communicate hop-by-hop grows only  
>>> linearly, and it offers the potential to route around obstacles  
>>> and enhance reliability through "receiver diversity".
>>>
>>> protocols address what happens beyond the "patch" of sensor  
>>> nodes, other than that some of the nodes are "gateways".  Current  
>>> industry standards, such as Zigbee, Zwave, and wirelessHART, are  
>>> also a "multihop link", leaving open the question of how nodes  
>>> within the sensor patch communicate with nodes outside.
>>>
>>> Such a link is assumed to be formed by a contiguously connected  
>>> set of 802.15.4 nodes.  The presence of such "mesh routing"  
>>> capabilities does not eliminate the need for layer 3 routing.  If  
>>> a 15.4 node communicates with a remote node, say an 802.11 node,  
>>> how is routing and forwarding carried out?  If two "LoWPAN  
>>> want to function as a logical subnet, even if the wireless  
>>> multihop routing is done at the IP layer.  At this point, the  
>>> concerns overlap with those addressed in autoconf (cf., draft- 
>>> ietf-autoconf-manetarch-01).
>>>
>>> from the process of forwarding packets.  Both of which are  
>>> distinct (but not entirely independent of) how power management  
>>> (turning on/off the radios) is performed.
>>>
>>>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 28 May 2007 07:54:29 -0400

Hi Dominik,

> requirements, can we sacrifice?

This is a perfectly valid point, I can't agree more. This is why I  
wrote in a previous email:

>> this might

What makes Sensor Networks somehow unique is indeed the constrained  
nature of the nodes (and links somehow). This is
why we proposed an applications-specific requirements approach. The  
idea being to design a protocol
supporting a set of routing components that may not have to be  
simultaneously activated. A set of components
(called a sub-system) could be defined for each application thus  
avoiding to specify a routing protocol supporting all of
the requirements at once that would defeat the "light footprint"  
requirement.

This is of course just an early stage proposal and we would need to  
collectively discuss once all the applications
specific requirements will have been fleshed out.

> goal of RSN to support all of this at the same time?

All good questions ... short answer is "to be discussed in the  
requirements IDs" but more than likely the routing
protocol will have to support Multipoint to point, point to  
Multipoint and point to point. A good point of discussion
will be to decide whether to optimize it for MP2P, P2MP, ...  
depending on the traffic pattern. This should be spelled
out in the application specific ID.

Makes sense ?

> The answers would help me to see RSN more clearly.

Hope this helps. Suggestions very welcome of course.

Thanks.

JP.

>> seems to
>> add a few
>> and sensor
>> constraint and
>> requirement
>> so far. I
>> routing
>> this might
>> support
>> different
>> relatively short
>> and it
>> and how it
>> meaning
>> to-15.4
>> solution
>> concerns
>> layers of

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 May 2007 18:06:50 +0200

JP Vasseur wrote:
[...]
> bandwidth links, unreliable links and highly constraints nodes,

Err... not sure about this.

Years ago I saw RIP over a 9600bps rs232 dialup, a link that I'd qualify
as low bandwidth.

Highly-constrained nodes?  I think there exist very small footprint
TCP/IP implementations, unmodified protocols.
http://www.sics.se/~adam/uip/size.html

I think in general a high-performance software implementation doesn't
need to change a protocol.

> the last aspects being key here since the computed path (SPT) does 
> not taken into account the node characteristics (other than potential
>  node pruning using node cap). There are networks with heterogenous 
> devices indeed but the path is not a function of the nodes but the 
> links using Dijkstra. This leads to defining IP *constrained based 
> routing* while addressing the requirements of unreliable and dynamic
>  topologies due to mobility and unstable links or nodes. Again the 
> notion of constrained based routing (that has been designed in other
>  contexts (MPLS)) differs from existing IGPs.
> 

>  of different natures, thus my comments to provide a routing solution
>  offering an end to end constrained path (this is not the only 
> requirement): this is clearly extremely challenging without a IP 
> routing solution independent of the link layer.

I think I agree with the heterogeneity of wireless link types being
accommodated by IP.

> You can perfectly have a Sensor Networks made of RF links and wired 

Yes, I agree with this too.  What I wanted to say is to mention the
wired link names.  Probably Ethernet and USB.  Probably RS232 as well.
Not any other.

> or OLSR will be the protocol to use. It MAY be an excellent solution
>  with adaptations though. This is why the proposal is indeed to have
> a place where we could make a clear analysis of the requirements and
>  come up with a solution, which again could be based on Manemo, AODV,
>  ... or a new routing protocol. There is NO reason to define a new 
> protocol if not needed and we do not want at the IETF to invent 
>  idea to state a priori that a protocol X should be used or could be
>  used with several extensions if this is not the correct long term 
> approach. We could mention many examples where using an existing 
> protocol and adapt it to meet new requirements was indeed the right 
> solution but there are also a number of example where we had to live
>  with poorly engineered solutions, thus the proposed approach.
> 

It sounds to me like an argument trying to persuade.

>> Mobility?  I think sensor networks once deployed are not mobile at
>>  all. Neither do they move homogeneously as a group (with respect
>> to Earth), nor do they move with respect to each-other.
> 
> types of sensor networks. Some of them are completely static indeed 
> but there are also many sensor networks where nodes are mobile with 
> as one example of deployed network), vehicular,

Wearable sensor networks and vehicular networks are very similar
conceptually.  They pose two problems: (1) run IP on the sensor and (2)
use Mobile IP to manage mobility of the whole; by "whole" I mean the PAN
  or the vehicle.

For running an IP stack on the sensor itself we can talk about
constraints (memory, speed, communication).  But at the same time one
very easily questions the unreliability of running TCP/IP on the sensor.
  I'm saying this after seeing deployed Car Area Networks (with sensors)
and Personal Area Networks, where the necessity of running IP on the
sensors is not felt, even sometimes discouraged.

It's like the more the sensor is constrained the less chances are that
it runs IP.

For using Mobile IP to manage the mobility of the whole network (the VAN
Vehicular Area Network or the PAN) one would look and reuse the Network
Mobility work (in the NEMO WG).

> industrial (with sensor on containers,

I think currently sensor on containers seem to me more like RFIDs, with
no power supply.  I don't think TCP/IP can run on a device that doesn't
have power supply.

> moving machines, ...), ...

Which ones?

>  solution and potentially document that this protocol would not be 
> used for some applications (e.g DTN sensor nets, ... might be 

This sounds like procedure, looks good.

[snipped some parts]...

Thanks,

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 28 May 2007 12:25:53 -0400

Hi Alex,

Starting with your conclusion "This sounds like procedure, looks  
good.", it sounds like we are in sync with the approach.

See in line for few comments though.

> Years ago I saw RIP over a 9600bps rs232 dialup, a link that I'd  

Yes this is why we designed triggered RIP + many other  
optimizations, ...
By the way, RIP is not exactly running in the Internet as an IGP ;-)

>
> Highly-constrained nodes?

Yes none of the IGP like OSPF/ISIS takes into account the node  
capability when computing the path (other than exclude from SPT).

> I think there exist very small footprint

That's an entirely different question. Here when we are referring to  
taking into account link and node characteristics, we refer to the path
computation.

>>  node pruning using node cap). There are networks with  
>> heterogenous devices indeed but the path is not a function of the  
>> nodes but the links using Dijkstra. This leads to defining IP  
>> *constrained based routing* while addressing the requirements of  
>> unreliable and dynamic

OK.

>> You can perfectly have a Sensor Networks made of RF links and  
>> wired links.
>
> Yes, I agree with this too.

Good.

> What I wanted to say is to mention the
>> See my previous comment: No we cannot make the assumption that  
>> AODV or OLSR will be the protocol to use. It MAY be an excellent  
>> solution
>> protocol and adapt it to meet new requirements was indeed the  
>> right solution but there are also a number of example where we had  
>> to live
>> types of sensor networks. Some of them are completely static  
>> indeed but there are also many sensor networks where nodes are  
>> mobile with various degree of mobility. Just to mention two  
>> examples (among many other ones): healthcare with wearable sensors  
>> (see the SMART project as one example of deployed network),  
>> vehicular,
>
> conceptually.

And there are mobile nodes.

** Here starts a discussion that belongs to 6lowpan **

> They pose two problems: (1) run IP on the sensor and (2)

This is highly debatable, I do think that running IP on a Sensor is  
completely feasible and has been demonstrated
in many circumstances; note that this discussion belongs more to  
6lowpan though.

> no power supply.  I don't think TCP/IP can run on a device that  

Why ? There are many sensors for pressure for example that are  
battery powered used on mobile machines.

>> requirements and more than likely there won't be any protocols  
>> that would meet all of them, especially if designed for  
>> constrained nodes.

Glad that we converged.

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Mon, 28 May 2007 12:26:10 -0700

> could be listed as well. This should be added to the req ID?

RSSI is a tricky one; most radio hardware provides it, but by itself  
RSSI is useless. What really matters is the SNR. If you can't  
determine the N, then there are cases when RSSI breaks down (hardware  
noise floor is not uniform, and there are analog interference sources  
out there). Furthermore, multipath inter-symbol interference can  
cause high RSSI links to have a low SNR and so a low packet reception  
rate. In the cause of short range and low bandwidth radios, this  
isn't a big deal, as symbols won't overlap much, but who knows what  
future hardware will be like? 802.15.4 tried to deal with this by  
specifying LQI, but the specification is so vague it's hard to really  
depend on it.

ToA is a common need. In the case of the features I mentioned, ToA  
wasn't at all important for the protocol, so it wasn't there. The big  
question is how ToA is specified. The primitive you generally find is  
ToA specified in terms of a node's local time base. This is  
inexpensive to provide and doesn't require any protocols,  
synchronization, or other implied services. At the very least, this  
enables reference broadcast synchronization. If a transmitter can  
embed a transmission timestamp in an outgoing packet and timestamps  
are on byte and not packet fidelity, then simple linear regression  
can often get you tens of microsecond accuracy without too much  
complexity.

Phil

---

From: Zach Shelby <[email-masked]>
Date: Tue, 29 May 2007 11:45:12 +0300

Hi Phil,

Comments in-line:

Philip Levis wrote:
> RSSI is useless. What really matters is the SNR. If you can't determine 
> the N, then there are cases when RSSI breaks down (hardware noise floor 
> is not uniform, and there are analog interference sources out there). 
> Furthermore, multipath inter-symbol interference can cause high RSSI 
> links to have a low SNR and so a low packet reception rate. In the cause 
> of short range and low bandwidth radios, this isn't a big deal, as 
> symbols won't overlap much, but who knows what future hardware will be 
> like? 802.15.4 tried to deal with this by specifying LQI, but the 
> specification is so vague it's hard to really depend on it.

Agreed, it is useful on current 2.4 GHz 802.15.4 hardware as a very 
rough indicator, no more.

> ToA specified in terms of a node's local time base. This is inexpensive 
> to provide and doesn't require any protocols, synchronization, or other 
> implied services. At the very least, this enables reference broadcast 
> synchronization. If a transmitter can embed a transmission timestamp in 
> an outgoing packet and timestamps are on byte and not packet fidelity, 
> then simple linear regression can often get you tens of microsecond 
> accuracy without too much complexity.

I have been involved with 802.15.4a ultra-wideband and chirp efforts for 
years, and see them having bright potential. By ToA I do not mean the 
raw ToA calculation, but the resulting distance in m calculated from 
that with some confidence metric. E.g. in 802.l5.4a chirp spread 
spectrum, the current SoA technique uses a round-trip calculation 
between two nodes, accuracy at least 1 m. UWB can achieve the same 
round-trip with an accuracy of a few cm. I have a demo running in the 
lab with that UWB accuracy, pretty cool I must say (running on 
Time-Domain hardware).

That being, maybe the metric available to routing should be simply the 
last measured distance to the neighbor with a confidence metric 
attached? This would generalize RSSI and ToA. Of course RSSI would have 
a horrible confidence, and ToA quite a good one. This issue is to be 
left to later RSN work, so let's not get stuck on it now...

---

From: Ken Peirce <[email-masked]>
Date: Tue, 29 May 2007 08:04:18 -0700 (PDT)

It is exciting to see the vision process unfold for RSN. I see a lot of very good talk about using SNR, RSSI and other radio performance metrics. While it is certain that many sensors will have radios like 802.15.4, I would like to note that sensors can have much more simple radios that do not keep such detailed radio information. It takes power to compute and store radio statistics(state).  Has the RSN group determined that the PHY/MAC layers will have some minimum level of functionality? Are there classes of RSNs? I am not trying to complicate things, just trying to understand the scope of what consitutes an RSN radio or MAC/PHY link.
Cheers,
Ken Peirce

---

From: "dculler" <[email-masked]>
Date: Tue, 29 May 2007 11:31:46 -0700

Dominik,
  I agree that prioritizing the suite of requirements and focusing on a
small set is critical to rapid progress.  "Light footprint" is a very useful
one because it provides a sharp distinction in the scaling characteristics
of alternative algorithms.  (Of course, in practice we utilize many
techniques to enhance the scaling properties of a variety of protocols, but
it is good to understand the inherent scaling characteristics that we are
beginning with.)  The available memory footprint correlates with issues of
power consumption and cost.  It causes us to attend to issues of neighbor
table size, routing table size, route summarization, and even estimators -
and yet it is independent of the particular link technology.  
   The second issue that I believe provides very strong guidance is the
traffic characteristics or workload.  That provides useful guidance on the
"offered load" under which we should evaluate the different alternatives.
In general, the load for monitoring and instrumentation is quite different
from many of the traditionally dominant use characteristics, such as TTY,
file transfer, email, browsing, voice.  
   So perhaps we should identify the top three that do a fairly good job of
"spanning the space" and then look at the other factors in the refinement
stages.

David

-----Original Message-----
From: Dominik Kaspar [mailto:[email-masked]] 
Sent: Monday, May 28, 2007 12:36 AM
To: [email-masked]
Subject: Re: [RSN] Next step for RSN ?

Dear RSN List,

In my opinion, RSN should focus more on one basic problem or a number of
orthogonal problems. Especially for sensor networks, there is no substitute
for simplicity. This very basic requirement has been called "light
footprint" in draft-culler-rsn-routing-reqs-00, but seems to have gone
forgotten. The requirement list suggests a multi-purpose RSN protocol, which
dynamically adapts to topology changes, intelligently switches between
end-to-end routing and data diffusion, supports data-aware routing,
topology-dependent QoS, ...etc. I question the feasibility of meeting such a
complex set of orthogonal requirements for sensor networks. In order words,
which ones of the current requirements, can we sacrifice?

Also..., is it the goal of RSN to provide IP-based querying of a single
sensor node in an end-to-end paradigm? Or is it the goal of RSN to allow
querying a network as an entity? Is it the goal to allow sensors send their
data to a sink on certain events? Is it the goal to allow sensor nodes
address other remote sensor nodes, too? Is the the goal of RSN to support
all of this at the same time?

Regards,
Dominik.

On 5/23/07, JP Vasseur <[email-masked]> wrote:
> seems to be a strong interest in designing a Routing solution for Sensor
Networks.
> David and I had during the last few months a number of off-line 
> discussions with positive feed-back and support, it is now a good time 
> to use the Mailing List to gauge whether there is a consensus on 
> whether to work on this topic.
>
> issue of IP routing over ATM PVCs routed by PNNI. Think of this with N
"Mesh-under"
> routing protocols. That said, this is not to say that we exclude the 
> use of "mesh-under" solutions, but we propose to define a IP-based 
> routing protocol.
>
> could be made energy efficient, could support some form of constrained 
> based routing, ...) or (3) we should design a new generic new protocol.
>
> know that Sensor Networks may significantly differ in term of degree 
> of mobility, link layer reliability/bandwidth, node constraints, ... A 
> very good outcome of this work might be that the newly defined/adapted 
> networks.  Is there interest in working on how these forms of routing tie
together?
> communicates with a remote node, say an
> 802.11 node, how is routing and forwarding carried out?  If two 
> "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how does 
> 15.4-to-15.4 routing occur?  The 6LoWPAN header format is, of course, 
> a general solution for carrying IP over 802.15.4, so it is able to 
> express these other forms of routing, as well.  In the extreme case, 
> each individual node is an IP link and all routing is done at the IP 
> layer.  On the other hand, patches of nodes may want to function as a 
> logical subnet, even if the wireless multihop routing is done at the 
> IP layer.  At this point, the concerns overlap with those addressed in 
> autoconf (cf., draft-ietf-autoconf-manetarch-01).
>
performed.

---

From: Philip Levis <[email-masked]>
Date: Wed, 30 May 2007 17:29:36 -0700

On May 29, 2007, at 1:45 AM, Zach Shelby wrote:

>
>
> I have been involved with 802.15.4a ultra-wideband and chirp  
> efforts for years, and see them having bright potential. By ToA I  
> do not mean the raw ToA calculation, but the resulting distance in  
> m calculated from that with some confidence metric. E.g. in  
> 802.l5.4a chirp spread spectrum, the current SoA technique uses a  
> round-trip calculation between two nodes, accuracy at least 1 m.  
> UWB can achieve the same round-trip with an accuracy of a few cm. I  
> have a demo running in the lab with that UWB accuracy, pretty cool  
> I must say (running on Time-Domain hardware).
>
> That being, maybe the metric available to routing should be simply  
> the last measured distance to the neighbor with a confidence metric  
> attached? This would generalize RSSI and ToA. Of course RSSI would  
> have a horrible confidence, and ToA quite a good one. This issue is  
> to be left to later RSN work, so let's not get stuck on it now...

This seems like a link-specific thing; assuming its presence is  
probably a bad idea. At the very least, 802.15.4 doesn't have it, so  
that means that 15.4 nodes would require additional circuitry/hardware?

The goal should be to define a *minimal* set of primitives the  
routing layer can depend on, in order to support as a broad a set of  
layer 2s as possible. Individual routing implementations for specific  
layer 2s can always take advantage of special hardware, but they  
can't assume its presence for correct operation. For example, a  
routing implementation might use physical layer indicators to guide  
its route selection, but it shouldn't be embedding these indicators  
in its packets as other nodes might have different radios with  
different indicators. E.g., an XBee Pro-based device might not know  
what to do with the soft chip decision indicator of a CC2420.

Phil

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 31 May 2007 13:19:24 +0200

>The goal should be to define a *minimal* set of primitives the routing
layer can depend on, in order to support as a broad a set
>of layer 2s as possible. Individual routing implementations for
specific layer 2s can always take advantage of special hardware,
>but they can't assume its presence for correct operation. For example,
a routing implementation might use physical layer
>indicators to guide its route selection, but it shouldn't be embedding
these indicators in its packets as other nodes might have
>different radios with different indicators. E.g., an XBee Pro-based
device might not know what to do with the soft chip decision
>indicator of a CC2420.

I couldn't agree more. RSSI and ToA sounds very sexy but very HW
specific.

A more pragmatic approach might be some high-level L2 API indication of
the quality of the link to a given neighbour node.
The challenge is mapping the specific properties of different L2's into
that high-level L2 API.
RSN's finest goal should be a set of primitives that allows routing
across a broad range of RF platforms;
mesh-under or not, beacon or not, etc.
That high-level L2 API will give us a hard work before it satisfies all
our conflicting interests, but our success depends on it.

One final note on RF connection reliability:
Having statistics for a given path is fine, but in RF, an apparently
fine connection may quickly turn out to be weak because of some new
noise generator in the neighbourhood. Therefore, being able to quickly
choose another alternative link is at least as important as knowing the
link quality upfront.

Anders

---

From: Philip Levis <[email-masked]>
Date: Thu, 31 May 2007 10:06:40 -0700

> I couldn't agree more. RSSI and ToA sounds very sexy but very HW

Well, RSSI can definitely be useful, even if it is HW specific. For  
example, while different HW sensitivities (read: noise floors) means  
that trying to infer link quality from the RSSI value requires  
additional mechanisms, phenomena such as sudden changes in RSSI can  
be very valuable. For example, if a node observes that the RSSI of  
packets from another node just dropped 10 dB, this suggests that the  
link might have degraded.

> our conflicting interests, but our success depends on it.

15.4 tried to do this with LQI, and it's of limited use. There are  
basically two things to consider:

1) Unless you require an underlying protocol, neighborhood table  
management, or other state in the link layer, this measurement will  
be for *incoming* connectivity only. That is, it measures the quality  
of the packet you received, not the quality of packets you will  
transmit. As soon as you have link asymmetries from hardware (e.g.,  
calibration) or from local interference (e.g., a microwave), then  
this simple value is insufficient.

2) Settling on a value that is truly interoperable is very hard.  
Again, 15.4 tried to specify LQI, but if you look how manufacturers  
suggest you compute LQI from their hardware, they basically say "it's  
up to you." Even given how vague the LQI specification is, it's still  
hard to meet.

Based on these difficulties, the conclusion the TinyOS networking  
group was that trying to specify this L2 information was a lost  
cause. Rather, network protocols shouldn't assume any such  
information, and should be able to operate in its absence. In CTP,  
for example, the periodic routing beacons have sequence numbers in  
them so nodes can estimate PRRs at layer 3. Now, a particular  
implementation may have hardware resources that it can use to  
estimate more quickly or accurately, but the protocol does not assume  
them. For example, when seeding a routing table a node with a CC2420  
radio can use the soft chip decision indicator (sort of a bit error  
rate) to come up with an estimate that is a lot faster and usually  
but not always more accurate than packet sequence numbers.

> choose another alternative link is at least as important as knowing  

Very true. Most beacon-based routing protocols run into a problem  
here, in that the link quality is updated by periodic beacons, whose  
transmission is independent of data traffic. If a link goes down, the  
time it takes to recover is defined by the beacons and is independent  
of data traffic. The current CTP implementation in TinyOS deals with  
this problem by directly using acknowledgements to estimate link  
quality. CTP uses an ETX metric for routing, and there's no better  
measure of ETX than how many data packets you have to transmit before  
you get an ack...

Phil

---

From: Kris Pister <[email-masked]>
Date: Thu, 31 May 2007 11:53:01 -0700

I don't know what CTP and ETX are, but I'm 100% supportive of the use of 
L2 ACKs.

In my experience, it is quite rare for links to go down in the 2.4GHz 
band.  However, it is quite common for the PER to go from 0 to 100% on a 
given channel.  If we have a requirement to support people who don't 
channel hop (sigh) then L2 ACKs are even more critical, since a single 
bad channel is perceived as a bad link.  I do think that in an ideal 
world the network layer would have some visibility into the radio 
flexibility and the channel characteristics that the radio has to deal 
with.  In some cases the available information may be "I'm stuck at 
908.42MHz and don't move", or it may be "I can hop on 16 channels".  The 
link characteristics can always be represented at the very least by some 
short term average of PER.

I've included a plot below of a particular link in a mesh network 
running on 15.4 radios.  Each horizontal trace is the 15 minute average 
PDR (=1-PER) on a particular 15.4 channel (channels are in 15.4 order,  
with 2.405 on bottom).  You can clearly see the work-week in the 
periodicity of the data, for example all channels look great at around 
Day 12 (Sunday) and come Day 13 (monday morning) many of them go to 
hell.  It's interesting that there are a couple of channels that always 
look good, but that most would regularly be declared to be "down links" 
in a single-channel network.  Note also that other links in the network 
look similar, but with different channels that are good over the 
month-long test. (this data will be published soon at ICCCN)

Routing algorithms for sensor networks need to comprehend and leverage 
this kind of link behavior.

ksjp

Philip Levis wrote:
> additional mechanisms, phenomena such as sudden changes in RSSI can be 
> very valuable. For example, if a node observes that the RSSI of 
> management, or other state in the link layer, this measurement will be 
> for *incoming* connectivity only. That is, it measures the quality of 
> the packet you received, not the quality of packets you will transmit. 
> As soon as you have link asymmetries from hardware (e.g., calibration) 
> or from local interference (e.g., a microwave), then this simple value 
> is insufficient.
>
> group was that trying to specify this L2 information was a lost cause. 
> Rather, network protocols shouldn't assume any such information, and 
> should be able to operate in its absence. In CTP, for example, the 
> periodic routing beacons have sequence numbers in them so nodes can 
> estimate PRRs at layer 3. Now, a particular implementation may have 
> hardware resources that it can use to estimate more quickly or 
> accurately, but the protocol does not assume them. For example, when 
> seeding a routing table a node with a CC2420 radio can use the soft 
> chip decision indicator (sort of a bit error rate) to come up with an 
> estimate that is a lot faster and usually but not always more accurate 
> than packet sequence numbers.
>
>>

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 31 May 2007 14:30:58 -0600

Kris,
  I did get the plot.

It would be great if we can define a protocol that would allow for the
propagation of the link state information, but not require.

	geoff

---

From: Philip Levis <[email-masked]>
Date: Thu, 31 May 2007 14:14:32 -0700

On May 31, 2007, at 11:53 AM, Kris Pister wrote:

> I don't know what CTP and ETX are, but I'm 100% supportive of the  
> use of L2 ACKs.

CTP is a protocol that TinyOS uses to build a collection tree to a  
data sink.

ETX is "estimated transmissions." ETT -- "estimated transmission  
time" -- is a generalization of ETX that considers radios with  
multiple bit rates, such as 802.11.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Thu, 31 May 2007 17:37:58 -0400

Hi Geoff,

> propagation of the link state information, but not require.

Indeed, this is what I referred to as "minimal link layer  
abstraction" where the layer2 property of a link
(discussed in 6lowpan: agree Geoff ?) would translate into some form  
of metric used by the routing
protocol (Pascal and I will post soon an ID proposing a "framework"  
to define such metrics).

Cheers.

JP.

>> use of
>>> cause.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 31 May 2007 15:54:46 -0600

Yes.  We did talk briefly about this during the 6lowpan meeting.  I
don't know if we can abstract this down to a single metric number, but I
think that this was sort of the idea.

BTW- what I previously meant to say was that I DID NOT get Kris' plot.

	geoff