Subject: [RSN] draft-dohler-rl2n-urban-routing-reqs-00

From: "DOHLER Mischa RD-TECH-GRE" <[email-masked]>
Date: Sat, 24 Nov 2007 20:37:52 +0100

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: +33 4 76 76 45 14
Fax: +33 4 76 76 44 50
Mob: +33 6 74 70 86 75

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

... visit http://www.pimrc2008.org/ ...
_______________________________________
_______________________________________________
RSN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rsn

---

From: JP Vasseur <[email-masked]>
Date: Mon, 26 Nov 2007 12:24:04 -0500

Draft also available at: http://www.employees.org/~jvasseur/

> From: DOHLER Mischa RD-TECH-GRE <[email-masked]>
> Date: Sat, 24 Nov 2007 20:37:52 +0100
> To: <[email-masked]>
> Cc: CHEGARAY Gabriel RD-TECH-GRE <[email-masked]>
> Conversation: draft-dohler-rl2n-urban-routing-reqs-00
> Subject: [RSN] draft-dohler-rl2n-urban-routing-reqs-00
> 
> Dear all,
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 26 Nov 2007 17:07:46 -0500

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.

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.

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.

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

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. 

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?

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?

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.

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.

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, ...)?

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.

Thanks.

JP.