Subject: Re: [Roll] Comments on draft-ietf-roll-building-routing-reqs-02.txt

From: [email-masked]
Date: Fri, 30 Jan 2009 17:31:39 +0100

Hi Jerry,

On Jan 23, 2009, at 10:29 PM, [email-masked] wrote:

>> 10) "Communication to these mostly sleeping devices MUST be 
>> bidirectional."
>> JP> Please be more specific. Do you mean by the routing protocol 
>> MUST be able to compute bi-directional route to sleeping devices ? 
>> Why ?
>> Yes and No.  You're actually asking two questions in your question...
>>
>>
>Yes we leave in a constrained environment ;-))
>> With regard to sleeping devices, the routing protocol must allow for 
>> delivering messages to an assigned (awake) proxy device who will 
>> later transmit the information to the sleeping device upon its 
>> awaking.  I've actually addressed this as a separate requirement.
>>
>>
>Indeed.
>> With regard to bidirectionality, I am simply saying that sensors 
>> must be able to receive application ACKs and other configuration 
>> data from its controller.  Some protocols (such as EnOcean) support 
>> only unidirectional messaging from the sensor to the controller. 
>> This might work for a lightweight application such as a wireless 
>> light switch turning on a light, but will not work for most of the 
>> commercial applications where the sensor must know that the packet 
>> has been successfully transmitted to the controller (say in a Fire 
>> application).
>>
>>
>Which does not necessarily mean a bi-directional route though. As you 
>know most of routing protocols are computing unidirectional routes 
>(fortunately!)
>
>> I've changed the text to read ...
>>
>> Communication to  sleeping devices MUST be bidirectional to allow 
>> for guaranteed packet delivery from the sensor to the controller.
>>
>Which is clearer but I still have an issue since this is a routing 
>requirement. I do not think that you require the routing protocol to 
>compute bi-directional routes. I understand that the communication 
>must be bi-directional thus this does not add any routing requirements 
>in addition to being able to compute routes from a node A to a node B 
>(and vice versa of course). Thus this sentence can be deleted, it is 
>already covered.
>>

NR=> Building systems must allow for BOTH battery-less sensors (e.g. a 
self-powered switch), supporting only unidirectional messaging, as well as 
regular sensors, supporting (and/or requiring) bi-directional messaging. 
Nevertheless, I think it is more a matter of implementation issue of the 
sleeping device's proxy than a specific routing requirement. As JP 
suggested, I think we can delete this sentence. 

Best Regards,
Nicolas.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: [email-masked]
Date: Fri, 30 Jan 2009 14:04:10 -0600

Hi Nicolas,

I got your phone mail as well, but too late to call.  I will try to call 
you on Monday morning, 

With regards to this email, I have deleted the sentence JP requests in the 
latest version.  I hope to get this new version out in the next few days.

Jerry

[email-masked] 
01/30/2009 10:32 AM

To
[email-masked]
cc
[email-masked]
Subject
Re: [Roll] Comments on draft-ietf-roll-building-routing-reqs-02.txt

Hi Jerry, 

Best Regards, 
Nicolas.