Subject: Re: [RSN] Next step for RSN ?

From: Tiago Camilo <[email-masked]>
Date: Fri, 01 Jun 2007 16:16:13 +0100

Hi JP,

>
> 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). ..."/
>
I 100% agree with this approach, due to sensor nodes constrains it is 
necessary and advisable (whenever is possible) to use L2 information for 
routing.
What I would like to raze here is, probably, a 
to-crazy-question-to-answer but here it goes: why not also adopting 
application layer requirements in routing protocols?
I know that we, in parallel, are building requirement IDs specially to 
application scenarios such as home automation, however i do see the need 
to supply
to RSN solutions, mechanisms such as service discovery, natively or as 
an extended option.
In a near future I can see the integration of several platforms working 
in the same sensornet, becoming in sensor mesh networks, such 
supposition will
make difficult to the network manager to track the service availability 
of his network, and IMO this can be applied to any kind of sensor 
application.
In a previous mail you mention the need to support point to Multipoint 
(P2MP) communication, and maybe you are already answering my question,
this could be supported by means of multicast-based solutions.
Are you considering service discovery as a requirement in the ID 
draft-culler-rsn-routing-reqs ? Or this ID should be application agnostic?

Thanks,
Tiago Camilo
University of Coimbra
>> 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.
>>
>
> 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.
>
>>> 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...)
>>>
>> 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. 
>
> Yes.
>
> Thanks.
>
> JP.
>
>>
>>> 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
>>> Senior Software Architect
>>>
>>> Zensys
>>> Emdrupvej 26
>>> DK-2100 Copenhagen O
>>> DENMARK
>>>
>>> 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] <mailto:[email-masked]>
>>> https://www1.ietf.org/mailman/listinfo/rsn
>>
>> _______________________________________________
>> RSN mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www1.ietf.org/mailman/listinfo/rsn
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> RSN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rsn
>   

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 1 Jun 2007 19:21:17 -0400

Hi,

On Jun 1, 2007, at 11:16 AM, Tiago Camilo wrote:

> Hi JP,
>
>>
>> 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
>> 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). ..."/
>>
> I 100% agree with this approach, due to sensor nodes constrains it  
> is necessary and advisable (whenever is possible) to use L2  
> information for routing.
> What I would like to raze here is, probably, a to-crazy-question-to- 
> answer but here it goes: why not also adopting application layer  
> requirements in routing protocols?
> I know that we, in parallel, are building requirement IDs specially  
> to application scenarios such as home automation, however i do see  
> the need to supply
> to RSN solutions, mechanisms such as service discovery, natively or  
> as an extended option.
> In a near future I can see the integration of several platforms  
> working in the same sensornet, becoming in sensor mesh networks,  
> such supposition will
> make difficult to the network manager to track the service  
> availability of his network, and IMO this can be applied to any  
> kind of sensor application.

This is a pefectly reasonable question to ask. We've been struggling  
with that exact same issue for other IGPs consisting of
off-loading the IGP to carry non routing information, but its  
flooding capability. So here is a proposal: we should definitely bear
this in mind when designing the routing protocol without making it a  
MUST requirement. If it turns out that the routing protocol
can also be used for application discovery w/o imposing too many  
constraints on it in term of bw usage, ... why not ? This may
or may not be feasible depending on the final design. The case of  
OSPF/ISIS was quite straightforward because of their flooding
nature (we just had to come up with prioritization mechanisms to  
avoid convergence impact because of the non-routing data):
thus specifying a node capability TLV carried within a Router  
Information LSA or ISIS LSP is not that much expensive
especially when such capability is fairly static (30mn refresh for  
OSPF and up to 18+ hours with ISIS). But we first need to study
the routing design and see whether we could use it for such purpose  
or would need to rely on other discovery service protocols.

> In a previous mail you mention the need to support point to  
> Multipoint (P2MP) communication, and maybe you are already  
> answering my question,

Although we should probably focus on the pure routing issues, I would  
very encourage further discussion on this topic: would you be willing  
to list such application-specific mechanism ?

Thanks.

JP.

---

From: Kris Pister <[email-masked]>
Date: Tue, 05 Jun 2007 10:08:43 -0700

oops.  Here's at link to the attachment that didn't go through:
http://www.eecs.berkeley.edu/~pister/tmp/Path24to17.gif

ksjp

Kris Pister wrote:
> 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:
>> On May 31, 2007, at 4:19 AM, Anders Brandt wrote:
>>
>>>> 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.
>>
>> 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.
>>
>>>
>>> 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.
>>
>> 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.
>>
>>>
>>> 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.
>>
>> 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
>>