[RSN] RE: Comments on draft-dohler-rl2n-urban-routing-reqs-00

["DOHLER Mischa RD-TECH-GRE" <[e-mail]>]

Dear JP,

Sorry for the long silence but I was clogged up with some other work.

Thanks for the comments! Please, find the replies inline. I have attached an improved requirements draft. More comments are more than welcome!

Kind regards,
Mischa.

_______________________________________

Dr Mischa Dohler
France Telecom R&D
Senior Research Expert

Tel: [phone]
Fax: [phone]
Mob: [phone]

http://perso.rd.francetelecom.fr/dohler
_______________________________________

... visit http://www.pimrc2008.org/ ...
_______________________________________


-----Message d'origine-----
De : JP Vasseur [mailto:[e-mail]] 
Envoyé : lundi 26 novembre 2007 23:08
À : DOHLER Mischa RD-TECH-GRE; CHEGARAY Gabriel RD-TECH-GRE
Cc : [e-mail]
Objet : Comments on draft-dohler-rl2n-urban-routing-reqs-00

Hi Mischa and Gabriel,

Excellent first draft. Please find below a few comments (skipping comments on ID Nits/acronyms expansion/references/... Issues for the moment):

1) Section 2: you may want to elaborate a bit more on what you refer to as "repeaters". The following text may deserve further clarifications:
Repeaters generally act as relays with the aim to close coverage and routing gaps; examples of their use are:
    prolong the U-L2N¹s lifetime,
    balance nodes¹ energy depletion,
    build advanced sensing infrastructures.

[MISCHA:] I have expanded on this section as you can see from the attached doc.



2) " The battery life-time is usually in the order of 10-15 years, rendering network lifetime maximization with battery-powered nodes beyond this lifespan useless. " You may want to say that this is highly application dependant since the frequency at which sensed data are sent to the sink may substantially vary.

[MISCHA:] We meant something different here. Due to leaks, etc, batteries do not exist longer than 10-15 years, independent whether you use them or not, or recharge them or not. Therefore, what we need are protocols which optimize but not necessarily maximize network lifetime. 



3) I do agree with your structured pattern statement wrt to L2N in urban networks. That being said, we will very likely see more collaborative scenarios with inter-device traffic flows. This is especially true if network processing actions can be triggered upon the occurrence a set of specific events, thus avoiding to rely on a central decision point. This would undoubtedly help in saving energy and will decrease the reaction time.
Again fully agree with you on the current structured patterns but we need to kind in mind that inter-device communication is likely to be needed at some point.

[MISCHA:] I am not sure it would save energy nor decrease reaction time; however, you are right, it would avoid the reliance on a single or very few access point(s). No need to say though that we as an operator are not very keen on having inter-device communication taking place which is avoiding our access points ;). Nonetheless, I understand the open nature of the IETF and have hence added a phrase concerning this. 



4) Typo section 4.1 " tenth of thousands"
 -> " tens of thousands"

[MISCHA:] Thanks, corrected :).



5) " the routing protocol MUST support parameter constrained Routing" - This is indeed one of the key functions that RL2N MUST achieve (also true for industrial application). Just reword as dynamic/static node constraints. 

[MISCHA:] I am not sure what you mean here.



6) Section 4.1 " To this end, the routing protocol SHOULD support and utilize this fact to facilitate scalability and parameter constrained routing." -> You may want to elaborate here. I think that you refer to the ability to make use of asymmetrical load balancing, to avoid traffic concentration on a few specific paths as we get closer to the sink, which is I think a key requirement. Is this also what you have in mind?

[MISCHA:] Ok, I have explained in more details.



7) Section 4.5 " To this end, the routing protocols proposed in U-L2N SHOULD support a variety of different devices without compromising the operability and energy efficiency of the network."
This section probably requires explanation. Is this (as I think) another node constraint or are you thinking of another form of routing constraint?

[MISCHA:] The motivation of this section was based on the fact that we plan to closely work with various MACs, such as IEEE 802.15.4, TSMP, etc, which may or may not have an impact on routing protocols. This has actually been stated clearly in the section and, unless you insist on the contrary, I have decided not to expand this section.



8) In section 4.3

"For the latter, the protocol SHOULD support multicast and broadcast addressing." - sounds more of a MUST to me.

And then in section 4.6

" To this end, the routing protocol MUST support multicast, where the routing protocol MUST provide the ability to route a packet towards a single field device (unicast) or a set of devices, which explicitly
(multicast) or implicitly (groupcast) belong to the same group/cast. "

I guess that the bottom line is a MUST for multicast support.

[MISCHA:] Yes, it is. I have corrected this. Thanks.



9) I would suggest to move " Convergence and route establishment times SHOULD be significantly lower than the inverse of the smallest reporting cycle." to a new scalability section where you could add number in term of # nodes, ... That have been provided in section 2.

[MISCHA:] Difficult one, because it is difficult to quantify scalability as we have given in terms of "significantly lower than the inverse of the smallest reporting cycle". We prefer to leave as is at the moment.



10) Latency: do you think that multi-topology routing is required in light of these requirements? By MTR I refer to the ability to decompose the network in multiple logical topologies based on their characteristics (low delay, ...)?

[MISCHA:] Maybe. Good idea. I have added this. Thanks.



11) Just a minor comment on the security section, which deals a large set of L2Ns security issues, including non routing issues. We have time to work on these in further revisions of the document and in light of the security framework item.

[MISCHA:] Ok, we will delete non-relevant parts if you feel this is needed.



Thanks.

JP.

> From: DOHLER Mischa RD-TECH-GRE <[e-mail]>
> Date: Sat, 24 Nov 2007 20:37:52 +0100
> To: <[e-mail]>
> Cc: CHEGARAY Gabriel RD-TECH-GRE <[e-mail]>
> Conversation: draft-dohler-rl2n-urban-routing-reqs-00
> Subject: [RSN] draft-dohler-rl2n-urban-routing-reqs-00
> 
> Dear all,
> 
> Please, find a first draft on urban lossy and low power networks 
> attached to this email. There are still pieces missing and also IDNits 
> still gives some warnings, but I think it should do for a first round 
> of comments.
> 
> Thanks and kind regards,
> Mischa.
> 
> _______________________________________
> 
> Dr Mischa Dohler
> France Telecom R&D
> Senior Research Expert
> 
> Tel: [phone]
> Fax: [phone]
> Mob: [phone]
> 
> http://perso.rd.francetelecom.fr/dohler
> _______________________________________
> 
> ... visit http://www.pimrc2008.org/ ...
> _______________________________________
> _______________________________________________
> RSN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/rsn

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