Subject: [Roll] P2P performance with current RPL proposal

From: "Anders Brandt" <[email-masked]>
Date: Mon, 8 Mar 2010 09:19:32 +0100

Hello
 
I would like to probe the temperature of the WG on using DAOs to
support P2P.
 
The building and home application spaces (and maybe others) have
a few clearly defined requirements.
It is not obvious to me how the current RPL proposal (cRPLp) can
satisfy those requirements:

In both cases it is the worst case scenario that hurts:

P2P routing inside the PAN
==========================
cRPLp has no way of routing inside the PAN if you need more than
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up)
and down again (maybe 4 hops down) to get just 2 hops to the side.
 
The consequence is high latency and high levels of background noise
for nodes just outside the direct radio range.
At the same time the risk of meeting a failing link is 4 times higher =>
latency may be much more than 4 times larger.
 
Latency may sound like a minor issue but it actually translates directly
into lower battery lifetime. In the above (very realistic) example,
the battery lifetime is reduced to 25% of what it should be.
 
We have lots of battery devices sending into the network:
* PIR sensors turning on lights
* Door locks sending alarms
* Door/window sensors starting chimes
* Smoke sensors triggering an alarm system

 
Response time
=============
The latency issue is important.
When a user (real human being) presses a light button the user expects
the light to turn on.
cRPLp proposes that nodes in the tree periodically advertises their
presence using DAOs.
The periodicity is a real beast:
Thanks to Trickle, the rate of updates in a (apparently) stable network
is low. This is good since it leaves bandwidth for data.
But it is not good if existing routes to my lamp fail and I do not get
new routes to my lamp until it decides to send out a new DAO.
My user will (with a good reason) not tolerate waiting for minutes for
the light to turn on.
 
I have met two arguments to counter this concern:
 
A1: Well, your lamp can always send a DAO when it detects a problem.
  My answer:
  True, except that my lamp does not intend to send anything
  so it will never experience any problems from its side of the network.
 
A2: Well, you can increase the DAO rate to sub-second updates.
  My answer:
  Oh no. I get a very high degree of management traffic which
  limits my available bandwidth, increases the risk of collisions and
  even run the risk of violating EU legislation requiring me to only
  transmit in less than 1% of the time:
  http://focus.ti.com/lit/an/swra048/swra048.pdf
<http://focus.ti.com/lit/an/swra048/swra048.pdf> 
  868 - 868.6 MHz: <1%
 
  Reactiveness is hard to achieve via polling.

If you agree that this seems to be critical issues please raise your
voice on the list.
 
Going forward
=============
 
We need some reactive mechanism to reach lamps before the user decides
to sue our companies.
So is this possible? I think so.

Existing commercial (non-IP) solutions are capable of re-routing quickly
if they really have to.
 
Let me try scoping the requirements to a potential solution:
(no different from the req. docs for home and building)
 
* P2P routing in any direction independent of the tree.
 
* On-demand P2P route discovery if requested by a real-time critical
app.
  Data collection apps may be able to just wait for the next DAO update.
 
* Limited range of discovery mechanism: max 4 repeaters.
  A TTL field may limit the scope of the repeaters.
 
* Suboptimal routing and traffic bursts are accepted in exchange
  for quick route repair. But only as an exception.

Just as an example, one existing home control technology uses a
(source routing) variant of AODV for quick route repair.
Nothing comes for free. The price is flooding - but not just flooding:
Managed flooding using a distributed algorithm running in all
participating nodes.
The algorithm dampens the flooding in a time, volume and range
perspective. 
Some similar mechanism could be built into RPL for quick route repair.

If anyone have alternative proposals, please bring it to the list.
Now is the time.

Thanks,
  Anders

---

From: JP Vasseur <[email-masked]>
Date: Mon, 8 Mar 2010 11:12:47 +0100

Ticket #24 was created.

On Mar 8, 2010, at 9:19 AM, Anders Brandt wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 8 Mar 2010 06:19:48 -0800

Hi Anders,

First let me say +1 on your note.  Agree these are the issues to solve.  I
was happy to see JP add a ticket.  I would encourage establishment of a
subgroup within the DT to address these.  These points have been open for
some time.

The trouble with "managed flooding" is that it would be the application that
would somehow have to know how many hops it needed to flood to fine the
device of interest.  That has been problematic in the past...

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Brandt
Sent: Monday, March 08, 2010 12:20 AM
To: ROLL WG
Subject: [Roll] P2P performance with current RPL proposal

Hello

support P2P.

 

 

 

Response time

=============

the light to turn on.

presence using DAOs.

the light to turn on.

  My answer:

  My answer:

 

voice on the list.

Going forward

=============

to sue our companies.

if they really have to.

* On-demand P2P route discovery if requested by a real-time critical app.
  Data collection apps may be able to just wait for the next DAO update.

 

The algorithm dampens the flooding in a time, volume and range perspective. 

 

Now is the time.

Thanks,

  Anders

---

From: "Monnerie, Emmanuel" <[email-masked]>
Date: Mon, 8 Mar 2010 09:56:13 -0500

Anders,

Thanks for bringing this topic on the table.

Clearly there are many other applications that would need P2P, such as
Smart Grid/Urban networks. P2P does not represent a high volume of
traffic, but is usually required in time critical applications, such as
local management of power grid switches.

The chapter 5 (Traffic Pattern) of RFC5548 would be good place to
describe in detail these use cases.

Best Regards

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Brandt
Sent: Monday, March 08, 2010 3:20 AM
To: ROLL WG
Subject: [Roll] P2P performance with current RPL proposal

Hello

support P2P.

 

 

 

Response time

=============

the light to turn on.

presence using DAOs.

the light to turn on.

  My answer:

  My answer:

 

voice on the list.

Going forward

=============

to sue our companies.

if they really have to.

 

 

Now is the time.

Thanks,

  Anders

Emmanuel Monnerie
Senior Research Engineer
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 1695
Fax: +1 678 258 1316
[email-masked]
www.landisgyr.com
manage energy better

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 8 Mar 2010 15:56:35 +0100

Hi Anders,

I am also concerned about this subject, and I support the creation of a DT
to address this particular topic.

In particular, I think we need to be clearer about what we mean by
"real-time critical apps". Do we mean:

1 - once the app uses a path, this path better be as short as possible to
reduce latency, or
2 - once a path needs to reach a destination, a path must be available as
soon as possible to reduce buffering, or
3 - both of the above.

If we aim at anything else than property 1 in this list, the time needed for
the discovery phase of a reactive protocol may be an issue at some point. It
is hard to imagine a way to be "real-time" in the sense of property 3,
without being more proactive (and to thus introducing other types of
issues/tradeoffs).

In a way, the current RPL proposal may be seen as an attempt at providing
property 2, with the additional assumption that destinations "know" who they
are in advance. It remains to be seen if this approach actually works the
way it is intended to.

If on the other hand we are just aiming for property 1, then reactive
approaches, such as the one you point out, are an interesting potential
alternative indeed.

Regards,

Emmanuel

On Mon, Mar 8, 2010 at 3:19 PM, Don Sturek <[email-masked]> wrote:

> The trouble with “managed flooding” is that it would be the application
> that would somehow have to know how many hops it needed to flood to fine the
> device of interest.  That has been problematic in the past………
>
>
>
> Don
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Anders Brandt
> *Sent:* Monday, March 08, 2010 12:20 AM
> *To:* ROLL WG
>
> *Subject:* [Roll] P2P performance with current RPL proposal
>
>
>
> Hello
>
>
>

---

From: JP Vasseur <[email-masked]>
Date: Mon, 8 Mar 2010 17:39:22 +0100

Hi Don,

On Mar 8, 2010, at 3:19 PM, Don Sturek wrote:

> Hi Anders,
>
> First let me say +1 on your note.  Agree these are the issues to  
> solve.

Absolutely. P2P supports is a clear MUST spelled out in many  
requirements documents and as a WG we will provide a solution.
The question is to judge how RPL in its current form is in support of  
P2P for specific applications.
Indeed, RPL does support P2P (although we have few issues to sort out  
with regards to DAO) but is it good enough for all
applications ?

*with a co-chair hat off*

Here is what I would recommend.
* look at specific scenario for which we think there is a potential  
issue (like the one listed by Anders)
* see how we can deploy RPL: remember that one can deploy RPL with  
more than one DODAG.
If there is a critical destination, it could be the root of a new DODAG.
* tune RPL accordingly
See how far we are from what we need.

* end*

> I was happy to see JP add a ticket.  I would encourage establishment  
> of a subgroup within the DT to address these.  These points have  
> been open for some time.
>

Yes, we also need to close on a few items:
	* Security (The Security DT is working on it)
	* DAO mode of operation: new tickets will be opened soon, packing, ...

I do not think that we need another DT there. I'd rather have it a WG  
discussion for the time being.

> The trouble with “managed flooding” is that it would be the  
> application that would somehow have to know how many hops it needed  
> to flood to fine the device of interest.  That has been problematic  
> in the past………

Very much true.

Thanks.

JP.

>
> Don
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Anders Brandt

---

From: Kris Pister <[email-masked]>
Date: Mon, 08 Mar 2010 11:44:56 -0800

Anders - if we take JP's suggestion to make The Lamp a DODAG root, and 
take Phoebus' recommendation that we use path diversity to improve 
end-to-end reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get 
extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution 
either.  I'm open to ideas on how to bring those in as (presumably 
infrequently used) options.

ksjp

Anders Brandt wrote:
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Mon, 8 Mar 2010 14:08:13 -0600

A concern also will be how much overhead
(memory space) will be required for a DODAG Root?

and based on the first question how
many DODAG roots a lamp may need to be a member of?

For example in lighting  a single
lamp may be a root for a single switch (1 DODAG root),  this lamp
/ luminaire may also

be a member of another group - -  which
could be all lights on the floor (2nd DODAG root), and a third group

of all the lights in the building.  There
can be many more speciality groups associated based on the building configuration.

Consider also during the installation
time - how these DODAG roots will be configured?  Must I commission
each device

to tell it which DODAG it must use for
its Object Function?  How easy will this be to change and add in a
new DODAG root

for the end user if the lighting group
changes??

With respect to Jerry Martocci's - commercial
building requirements - every device may need to communicate to any or

all of the end devices.  If each
device must establish a DODAG for the other 499 devices in a 500 node network
- How much memory

space will this require for each end
device to maintain?

Keep in mind that the end devices are
very limited processor and memory wise.

Not to mention all of the network maintenance
messages that would need to be transmitted to maintain all of these DODAGs.

Consider the reconvergence time when
one device is turned off and it was in the middle of the majority of the
100+ DODAGS?

In many lighting and building application
an application acknowledgement - must be returned {Back down the DODAG}
so . . . the

requirement is not just getting to the
Root - a return path must also be maintained and have a  low latency
path.

Ted Humpal

From:

Kris Pister <[email-masked]>

To:

Anders Brandt <[email-masked]>

Cc:

ROLL WG <[email-masked]>

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current
RPL proposal

Anders - if we take JP's suggestion to make The Lamp a
DODAG root, and take Phoebus' recommendation that we use path diversity
to improve end-to-end reliability, do you see a chance of success?

I have no aversion to TTL-limited floods as a part of a solution either.
I'm open to ideas on how to bring those in as (presumably infrequently
used) options.

ksjp

Anders Brandt wrote:

Hello

I would like to probe the temperature of
the WG on using DAOs to

support P2P.

The building and home application spaces
(and maybe others) have

It is not obvious to me how the current
RPL proposal (cRPLp) can

In both cases it is the worst case scenario
that hurts:

cRPLp has no way of routing inside the
PAN if you need more than

one repeater. cRPLp has to go all the way
to the top (maybe 4 hops up)

and down again (maybe 4 hops down) to get
just 2 hops to the side.

The consequence is high latency and high
levels of background noise

At the same time the risk of meeting a
failing link is 4 times higher =>

Latency may sound like a minor issue but
it actually translates directly

the battery lifetime is reduced to 25%
of what it should be.

We have lots of battery devices sending
into the network:

Response time

=============

When a user (real human being) presses
a light button the user expects

the light to turn on.

cRPLp proposes that nodes in the tree periodically
advertises their

presence using DAOs.

Thanks to Trickle, the rate of updates
in a (apparently) stable network

But it is not good if existing routes to
my lamp fail and I do not get

new routes to my lamp until it decides
to send out a new DAO.

My user will (with a good reason) not tolerate
waiting for minutes for

the light to turn on.

I have met two arguments to counter this
concern:

A1: Well, your lamp can always send a DAO
when it detects a problem.

My answer:

True, except that my lamp does not
intend to send anything

so it will never experience any
problems from its side of the network.

A2: Well, you can increase the DAO rate
to sub-second updates.

My answer:

Oh
no. I get a very high degree of management traffic which

limits my available bandwidth, increases
the risk of collisions and

even run the risk of violating EU
legislation requiring me to only

transmit in less than 1% of the
time:

868 - 868.6 MHz: <1%

Reactiveness is hard to achieve
via polling.

If you agree that this seems to be critical
issues please raise your

voice on the list.

Going forward

=============

We need some reactive mechanism to reach
lamps before the user decides

to sue our companies.

if they really have to.

Let me try scoping the requirements to
a potential solution:

(no different from the req. docs for home
and building)

* P2P routing in any direction independent
of the tree.

* On-demand P2P route discovery if requested
by a real-time critical app.

* Limited range of discovery mechanism:
max 4 repeaters.

A TTL field may limit the scope
of the repeaters.

* Suboptimal routing and traffic bursts
are accepted in exchange

for quick route repair. But only
as an exception.

Just as an example, one existing home control
technology uses a

Nothing comes for free. The price is flooding
- but not just flooding:

participating nodes.

The algorithm dampens the flooding in a
time, volume and range perspective.

Some similar mechanism could be built into
RPL for quick route repair.

If anyone have alternative proposals, please
bring it to the list.

Now is the time.

Thanks,

Anders

Roll mailing list

[email-masked]

Roll mailing list

[email-masked]

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 8 Mar 2010 13:58:21 -0800

Hi Kris,

In general it is a bad idea to map application function (like a lamp) to
network function (like DODAG root) to help address latency concerns.   This
won't scale if you look at the use cases for building or home automation.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris
Pister
Sent: Monday, March 08, 2010 11:45 AM
To: Anders Brandt
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal

Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take
Phoebus' recommendation that we use path diversity to improve end-to-end
reliability, do you see a chance of success?
In my experience, with diverse paths and order-minutes updates you get
extremely high reliability.

I have no aversion to TTL-limited floods as a part of a solution either.
I'm open to ideas on how to bring those in as (presumably infrequently used)
options.

ksjp

Anders Brandt wrote: 

Hello

support P2P.

 

 

 

Response time

=============

the light to turn on.

presence using DAOs.

the light to turn on.

  My answer:

  My answer:

 

voice on the list.

Going forward

=============

to sue our companies.

if they really have to.

 

 

Now is the time.

Thanks,

  Anders

  _____

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Tue, 9 Mar 2010 04:52:39 +0200

Hi,

Did you consider managed flooding using bloom filters?

http://www.cs.ucsb.edu/~rgilbert/pubs/GJW+06.pdf

This relatively simple method basically allows a compact way of knowing
whether a node is NOT N hops away from a transmitting node and also whether
it is with some probability.

If table entries can be integrated into DIO messages (not all of them at
once, can be by layer), it will allow for better hops manageability and also
discarding (or significantly reduced probability) to congest irrelevant
zones in the network.

Thanks,

Yoav

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Don
Sturek
*Sent:* Monday, March 08, 2010 4:20 PM
*To:* 'Anders Brandt'; 'ROLL WG'
*Subject:* Re: [Roll] P2P performance with current RPL proposal

Hi Anders,

The trouble with “managed flooding” is that it would be the application that
would somehow have to know how many hops it needed to flood to fine the
device of interest.  That has been problematic in the past………

Don

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Anders
Brandt
*Sent:* Monday, March 08, 2010 12:20 AM
*To:* ROLL WG
*Subject:* [Roll] P2P performance with current RPL proposal

Hello

support P2P.

Response time

=============

the light to turn on.

presence using DAOs.

the light to turn on.

  My answer:

  My answer:

voice on the list.

Going forward

=============

to sue our companies.

if they really have to.

Now is the time.

Thanks,

  Anders

---

From: [email-masked]
Date: Wed, 10 Mar 2010 15:00:28 -0600

Anders,

+1

Sorry for the delayed response.  I
was on vacation this past week and only saw your email today.

As you probably expect, I certainly
agree with your assessment and concern about RPL latency in P2P
mission critical applications.  Lighting applications will visually
be unacceptable to our customers.  We cannot have lights turning on
seconds (much less minutes) after the light switch is depressed.

However, Fire and Physical Security
applications are even more time critical.  Fire alarms must start
sounding, strobes must start flashing and evacuation instructions must
be presented almost instantaneously to its detection.  HVAC smoke
control operations must be in place within a few seconds after the detector
has smelled smoke.  These applications affect various subsystems randomly
based on the fire and smoke's path.  Hence there is no preordained
control path that can be established.

I think I have pretty much bored the
entire WG on this issue the past 6 months.  I also agree that RPL
needs some reactive means to quickly discovering a new path.  I am
glad that JP has added this an 'issue tracker'.

Regards,

Jerry

From:

"Anders Brandt" <[email-masked]>

To:

"ROLL WG" <[email-masked]>

Date:

03/08/2010 02:20 AM

Subject:

[Roll] P2P performance with current
RPL proposal

Hello

support P2P.

Response time

=============

the light to turn on.

presence using DAOs.

the light to turn on.

My answer:

My answer:

Oh

868 - 868.6 MHz: <1%

voice on the list.

Going forward

=============

to sue our companies.

if they really have to.

participating nodes.

Now is the time.

Thanks,

Anders_______________________________________________

Roll mailing list

[email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Thu, 11 Mar 2010 13:43:16 +0000

I agree with Ted's comments below. Creating a DODAG for every reachable 
node as a root seems a very inefficient approach compared to alternative 
routing algorithms. I am concerned that RPL does not actually meet the 
original requirements in I-D.ietf-roll-building-routing-reqs, 
I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic 
pattern requirement for a sink node features prominently in only two of 
those documents. Even in this case, as Ted points out, communication is 
likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG 
approach is fundamentally asymmetric, especially if no intermediate 
storage is allowed for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms 
of memory as well as power and bandwidth. The RPL draft as it stands is 
82 pages long and that doesn't include text about the objective function.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

[email-masked] wrote:
>
> A concern also will be how much overhead (memory space) will be 
> required for a DODAG Root?
>
> and based on the first question how many DODAG roots a lamp may need 
> to be a member of?
>
> For example in lighting  a single lamp may be a root for a single 
> switch (1 DODAG root),  this lamp / luminaire may also
> be a member of another group - -  which could be all lights on the 
> floor (2nd DODAG root), and a third group
> of all the lights in the building.  There can be many more speciality 
> groups associated based on the building configuration.
> Consider also during the installation time - how these DODAG roots 
> will be configured?  Must I commission each device
> to tell it which DODAG it must use for its Object Function?  How easy 
> will this be to change and add in a new DODAG root
> for the end user if the lighting group changes??
>
> With respect to Jerry Martocci's - commercial building requirements - 
> every device may need to communicate to any or
> all of the end devices.  If each device must establish a DODAG for the 
> other 499 devices in a 500 node network - How much memory
> space will this require for each end device to maintain?  
>
> Keep in mind that the end devices are very limited processor and 
> memory wise.
>
> Not to mention all of the network maintenance messages that would need 
> to be transmitted to maintain all of these DODAGs.
>
> Consider the reconvergence time when one device is turned off and it 
> was in the middle of the majority of the 100+ DODAGS?
>
> In many lighting and building application an application 
> acknowledgement - must be returned {Back down the DODAG} so . . . the
> requirement is not just getting to the Root - a return path must also 
> be maintained and have a  low latency path.
>
> Ted Humpal
>
>
>
>
> From: 	Kris Pister <[email-masked]>
> To: 	Anders Brandt <[email-masked]>
> Cc: 	ROLL WG <[email-masked]>
> Date: 	03/08/2010 01:45 PM
>   _http://focus.ti.com/lit/an/swra048/swra048.pdf_
>  868 - 868.6 MHz: <1%
>  
> [email-masked] <mailto:[email-masked]>
> _https://www.ietf.org/mailman/listinfo/roll_

---

From: JP Vasseur <[email-masked]>
Date: Thu, 11 Mar 2010 15:48:42 +0100

Hi Robert,

On Mar 11, 2010, at 2:43 PM, Robert Cragie wrote:

> I agree with Ted's comments below. Creating a DODAG for every  
> reachable node as a root seems a very inefficient approach compared  
> to alternative routing algorithms. I am concerned that RPL does not  
> actually meet the original requirements in I-D.ietf-roll-building- 
> routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548.

Just to re-assure you, I opened a ticket on this since we will as a WG  
deliver a solution for P2P that satisfy the requirements.
I think that before jumping to the conclusions that RPL (as it stands)  
does not meet some of the requirements we need to make a careful  
analysis and we will.

> The traffic pattern requirement for a sink node features prominently  
> in only two of those documents. Even in this case, as Ted points  
> out, communication is likely to be bidirectional (e.g. end-to-end  
> acks.) therefore the DODAG approach is fundamentally asymmetric,  
> especially if no intermediate storage is allowed for destination  
> routes and source routing has to be used.
>
> Also, RPL seems highly complex for what are constrained nodes in  
> terms of memory as well as power and bandwidth.

Let's wait until we get numbers from implementers ... there are about  
10 implementations and numbers should be provided
fairly soon but early numbers show that we are talking about a few K  
of RAM and a dozen of K of Flash.

Implementers, please chime in here to provide feed-back to the WG.

> The RPL draft as it stands is 82 pages long and that doesn't include  
> text about the objective function.
>

You are right !

But we need to be careful not to judge complexity by the length of the  
document. I'd rather look at the FSM, which is not that complex.
Just so you know, the document will be reworked, there are still  
redundant sections, appendix, sections that will be removed.

Thanks for your comments.

JP.

> http://www.gridmerge.com
>> and based on the first question how many DODAG roots a lamp may  
>> need to be a member of?
>>
>> of all the lights in the building.  There can be many more  
>> speciality groups associated based on the building configuration.
>> to tell it which DODAG it must use for its Object Function?  How  
>> easy will this be to change and add in a new DODAG root
>> With respect to Jerry Martocci's - commercial building requirements  
>> - every device may need to communicate to any or
>> all of the end devices.  If each device must establish a DODAG for  
>> the other 499 devices in a 500 node network - How much memory
>> Not to mention all of the network maintenance messages that would  
>> need to be transmitted to maintain all of these DODAGs.
>>
>> Consider the reconvergence time when one device is turned off and  
>> it was in the middle of the majority of the 100+ DODAGS?
>>
>> requirement is not just getting to the Root - a return path must  
>> also be maintained and have a  low latency path.
>>
>> Ted Humpal
>>
>>
>>
>>
>> Anders - if we take JP's suggestion to make The Lamp a DODAG root,  
>> and take Phoebus' recommendation that we use path diversity to  
>> improve end-to-end reliability, do you see a chance of success?
>> In my experience, with diverse paths and order-minutes updates you  
>> get extremely high reliability.
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Mar 2010 17:24:01 +0100

HI Robert :

I respectfully have to disagree.

My understanding is that we are considering a limited set of P2P pairs,
for which the specific path that we need to create might have to obey
specific constraints. 

So it makes sense to use an on-demand technique, probably inspired by
the MANET Reactive protocols.

As it goes, those protocols usually use flooding for a node to locate
another. Forking a DAG is just another flooding. It does not take a lot
of addition to the existing DIO for a root to use RPL to build a DAG
that contains one or multiple Targets as leaves, under a set of
constraints expressed as an objective function. Please find attached a
slideware that illustrates that.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: [email-masked]
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal

storage is allowed for destination routes and source routing has to be
used.

Also, RPL seems highly complex for what are constrained nodes in terms
of memory as well as power and bandwidth. The RPL draft as it stands is
82 pages long and that doesn't include text about the objective
function.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

A concern also will be how much overhead (memory space) will be required
for a DODAG Root? 

and based on the first question how many DODAG roots a lamp may need to
be a member of? 

For example in lighting  a single lamp may be a root for a single switch
(1 DODAG root),  this lamp / luminaire may also 
be a member of another group - -  which could be all lights on the floor
(2nd DODAG root), and a third group 
of all the lights in the building.  There can be many more speciality
groups associated based on the building configuration. 
Consider also during the installation time - how these DODAG roots will
be configured?  Must I commission each device 
to tell it which DODAG it must use for its Object Function?  How easy
will this be to change and add in a new DODAG root 
for the end user if the lighting group changes?? 

Keep in mind that the end devices are very limited processor and memory
wise. 

Consider the reconvergence time when one device is turned off and it was
in the middle of the majority of the 100+ DODAGS? 

In many lighting and building application an application acknowledgement
- must be returned {Back down the DODAG} so . . . the 
requirement is not just getting to the Root - a return path must also be
maintained and have a  low latency path. 

Ted Humpal 

From: 

Kris Pister <[email-masked]> <mailto:[email-masked]>

To: 

Anders Brandt <[email-masked]> <mailto:[email-masked]>  

Cc: 

ROLL WG <[email-masked]> <mailto:[email-masked]>  

Date: 

03/08/2010 01:45 PM 

Subject: 

Re: [Roll] P2P performance with current RPL proposal

________________________________

ksjp

Anders Brandt wrote: 
Hello 

  

  

  
Response time 
============= 

  

  
Going forward 
============= 

if they really have to. 

  

  
Thanks, 
  Anders 

________________________________

_______________________________________________
Roll mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll> 
 _______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll
<https://www.ietf.org/mailman/listinfo/roll> 

________________________________

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 15 Mar 2010 10:33:20 -0700

Hi Pascal,

I think we have fundamental disagreement on P2P support in RPL.  Here are
the issues that I see:

1)       "We are considering a limited set of P2P pairs" - I think most of
the use cases for Building Automation and Home Automation use P2P pairs.
Even Smart Energy is mostly a P2P solution (as a percentage of messages
sent/received).  I think to handle P2P we need to view the deployment as NOT
being a limited set of P2P pairs.

2)       "for which the specific path that we need to create might have to
obey specific constraints." - I think there was discussion on having
application server type devices (like lamps for example) become DAG roots to
help solve the mapping of RPL to P2P solutions.  This really won't work.
Aligning the network topology by moving application devices to the role of
DAG roots won't scale.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: Monday, March 15, 2010 9:24 AM
To: [email-masked]; [email-masked]
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal

HI Robert :

My understanding is that we are considering a limited set of P2P pairs, for
which the specific path that we need to create might have to obey specific
constraints. 

So it makes sense to use an on-demand technique, probably inspired by the
MANET Reactive protocols.

As it goes, those protocols usually use flooding for a node to locate
another. Forking a DAG is just another flooding. It does not take a lot of
addition to the existing DIO for a root to use RPL to build a DAG that
contains one or multiple Targets as leaves, under a set of constraints
expressed as an objective function. Please find attached a slideware that
illustrates that.

Pascal

I agree with Ted's comments below. Creating a DODAG for every reachable node
as a root seems a very inefficient approach compared to alternative routing
algorithms. I am concerned that RPL does not actually meet the original
requirements in I-D.ietf-roll-building-routing-reqs,
I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern
requirement for a sink node features prominently in only two of those
documents. Even in this case, as Ted points out, communication is likely to
be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is
fundamentally asymmetric, especially if no intermediate storage is allowed
for destination routes and source routing has to be used.

Also, RPL seems highly complex for what are constrained nodes in terms of
memory as well as power and bandwidth. The RPL draft as it stands is 82
pages long and that doesn't include text about the objective function.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

A concern also will be how much overhead (memory space) will be required for
a DODAG Root? 

and based on the first question how many DODAG roots a lamp may need to be a
member of? 

For example in lighting  a single lamp may be a root for a single switch (1
DODAG root),  this lamp / luminaire may also 
be a member of another group - -  which could be all lights on the floor
(2nd DODAG root), and a third group 
of all the lights in the building.  There can be many more speciality groups
associated based on the building configuration. 
Consider also during the installation time - how these DODAG roots will be
configured?  Must I commission each device 
to tell it which DODAG it must use for its Object Function?  How easy will
this be to change and add in a new DODAG root 
for the end user if the lighting group changes?? 

With respect to Jerry Martocci's - commercial building requirements - every
device may need to communicate to any or 
all of the end devices.  If each device must establish a DODAG for the other
499 devices in a 500 node network - How much memory 
space will this require for each end device to maintain?   

Not to mention all of the network maintenance messages that would need to be
transmitted to maintain all of these DODAGs. 

Consider the reconvergence time when one device is turned off and it was in
the middle of the majority of the 100+ DODAGS? 

In many lighting and building application an application acknowledgement -
must be returned {Back down the DODAG} so . . . the 
requirement is not just getting to the Root - a return path must also be
maintained and have a  low latency path. 

Ted Humpal 

From: 

Kris Pister  <mailto:[email-masked]> <[email-masked]> 

To: 

Anders Brandt  <mailto:[email-masked]> <[email-masked]> 

Cc: 

ROLL WG  <mailto:[email-masked]> <[email-masked]> 

Date: 

03/08/2010 01:45 PM 

Subject: 

  _____  

ksjp

Anders Brandt wrote: 
Hello 

  

  
  
Response time 
============= 

  

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders 

  _____  

_______________________________________________
Roll mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/roll>
https://www.ietf.org/mailman/listinfo/roll
 _______________________________________________
Roll mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/roll>
https://www.ietf.org/mailman/listinfo/roll

  _____

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Mar 2010 18:55:13 +0100

Hi Don :

Well, in both cases my words did not convey the message I wished to
convey.

1)      I mean that the nodes that need to do P2P need to do so with a
limited set of other nodes, as opposed to all other nodes in the
network. So what you want to do is not any to any but  a number of
groups of 2 or more nodes that need to talk to one another

2)      I  mean that the path that we create might have to obey
constraints, like low latency, that the generic P2MP DAG does not need.
For instance, I think about a closed loop in process control.

I'm not sure we disagree so far.

I read your earlier mail about application role vs. network role. In
that, we might have to discuss some more. Because RPL is designed to
optimize P2MP and MP2P, it is not symmetrical wrt the P and the MP. The
P has to be selected to match the Goal that the DAG is built to serve.

Taking your example, one way of handling multiple lamps in a room can be
to set them all as roots , and then coordinate them, for instance
through the powerline, as discussed in section 3.2.

Our we could use the on-demand approach that I just suggested. For
instance, we could have each switch lookup the set of lamps by forking a
DAG. With the proposal, the DAG only spans so far, and acts as a
reactive route setup. The DIO contains the list of lamps, and each lamp
answers with a DAO that can be fanned out. The nodes that do not see the
DAO back forget about that DAG just like they would other reactive
floodings.

How far do we really disagree?

Pascal

From: Don Sturek [mailto:[email-masked]] 
Sent: Monday, March 15, 2010 6:33 PM
To: Pascal Thubert (pthubert); [email-masked];
[email-masked]
Cc: 'ROLL WG'
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Pascal,

I think we have fundamental disagreement on P2P support in RPL.  Here
are the issues that I see:

1)       "We are considering a limited set of P2P pairs" - I think most
of the use cases for Building Automation and Home Automation use P2P
pairs.  Even Smart Energy is mostly a P2P solution (as a percentage of
messages sent/received).  I think to handle P2P we need to view the
deployment as NOT being a limited set of P2P pairs.

2)       "for which the specific path that we need to create might have
to obey specific constraints." - I think there was discussion on having
application server type devices (like lamps for example) become DAG
roots to help solve the mapping of RPL to P2P solutions.  This really
won't work.  Aligning the network topology by moving application devices
to the role of DAG roots won't scale.

Don

HI Robert :

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

ksjp

Anders Brandt wrote: 
Hello 

  

  

  
Response time 
============= 

  

  
Going forward 
============= 

if they really have to. 

  

  
Thanks, 
  Anders

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Mar 2010 19:04:51 +0100

Hi Mukul

> 1. A node/router in the middle may need to maintain state for multiple DAGs
> that lead to the same destination. Consider the situation where 5 nearby
> nodes need to find route to the same destination D. As per your scheme,
> each node would form its own DAG towards the destination D and the nodes
> in the middle would need to maintain state about all 5 DAGs. This seems
> wasteful. You may argue that this is a fit case for these 5 nodes to belong to a
> single DAG rooted at D. But the problem is that D does not know that it is a
> destination for these 5 nodes. So, in general, I see a scalability problem
> associated with the use of DAGs for P2P routing. A simple DV approach,
> where the nodes maintain information about destinations (rather than
> DAGs), seems to avoid this scalability problem.

[Pascal] I do not know what you call regular :) 
RIP usually maintains trees but eigrp allows for non-equal cost feasible successors and thus builds DAGs.

AODV (Thomas, or Charlie if you're listening, correct me if I'm wrong) builds and maintains routes that are dotted lines between 2 points.

With RPL used reactively as proposed here, we can do either way. 

The OF can be designed to build a tree and if so, we end up with something quite similar to AODV/DYMO.
Or the OF wants a DAD for redundancy and we build a DAG.

One cool thing is that we can request more than one target, effectively building a DAG that looks like a flower.

It's not a matter of scalability, it's a matter of what you cant to achieve and the associated cost. DAG is more expensive than tree.

> 
> 2. So, in your scheme, the nodes timeout the state they have for a DAG. This
> means that a node that does not belong to the actual route taken by the
> packets would end up timing out its state for this DAG. This is ok unless this
> node is part of an obvious backup route and should have maintained
> information about this DAG. It would be good to use the "routing interest"
> concept in this situation. As per this concept, each node maintains a "routing
> interest" in a particular DAG (or destination). The routing interest is a metric
> between 0 and 1. If a node is actively sending packets along the DAG, its
> routing interest would be 1. Otherwise, the routing interest would be
> x*max(routing interest of its nbrs), where x is a fraction. A node may delete
> state about a DAG/destination if its routing interest in that dag/destination
> drops below a threshold. The routing interest concept would allow nodes
> "around' the actual path to maintain state about this dag while other nodes
> can delete this state after initial route discovery.
[Pascal] 

Cool : ) Now we're building a solution.

Pascal 

> 
> Thanks
> Mukul
> ----- Original Message -----
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> To: "robert cragie" <[email-masked]>, "Ted Humpal"
> <[email-masked]>
> Cc: "ROLL WG" <[email-masked]>
> Sent: Monday, March 15, 2010 11:24:01 AM GMT -06:00 US/Canada Central
> As it goes, those protocols usually use flooding for a node to locate another.
> Forking a DAG is just another flooding. It does not take a lot of addition to the
> existing DIO for a root to use RPL to build a DAG that contains one or multiple
> Targets as leaves, under a set of constraints expressed as an objective
> function. Please find attached a slideware that illustrates that.
> 
> 
> 
> 
> Pascal
> 
> 
> 
> 
> 
> 
> original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-
> routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a
> sink node features prominently in only two of those documents. Even in this
> case, as Ted points out, communication is likely to be bidirectional (e.g. end-
> to-end acks.) therefore the DODAG approach is fundamentally asymmetric,
> especially if no intermediate storage is allowed for destination routes and
> source routing has to be used.
> 
> be a member of another group - -  which could be all lights on the floor (2nd
> DODAG root), and a third group
> to tell it which DODAG it must use for its Object Function?  How easy will this
> be to change and add in a new DODAG root
> take Phoebus' recommendation that we use path diversity to improve end-
> to-end reliability, do you see a chance of success?
> I have no aversion to TTL-limited floods as a part of a solution either.  I'm
> open to ideas on how to bring those in as (presumably infrequently used)
> options.
> 
> ksjp
> 
> Anders Brandt wrote:
> Hello
> 
>   _______________________________________________ Roll mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: Robert Cragie <[email-masked]>
Date: Mon, 15 Mar 2010 18:26:48 +0000

Hi Pascal,

So in your slideware T can end up talking to R (DODAG root) through the 
DODAG. So are you proposing that all potential targets can act as a 
DODAG root? And therefore all intermediates have to retain DIO 
propagation support for that DODAG as well? This may work for limited 
P2P but seems less efficient than simple distance vector flooding 
RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or 
anyone else for that matter)? Do we source route, maintain state, some 
undefined hybrid of the two?

I apologise if some of these questions have been answered in detail in 
earlier reflector posts but I have only recently started to concentrate 
my efforts on RPL and have 82 pages to wade through :-). I look forward 
to a productive session in Anaheim.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Pascal Thubert (pthubert) wrote:
> My understanding is that we are considering a limited set of P2P 
> pairs, for which the specific path that we need to create might have 
> to obey specific constraints.
>
> another. Forking a DAG is just another flooding. It does not take a 
> lot of addition to the existing DIO for a root to use RPL to build a 
> DAG that contains one or multiple Targets as leaves, under a set of 
> Behalf Of *Robert Cragie
> *Sent:* Thursday, March 11, 2010 2:43 PM
> *To:* [email-masked]
> *Cc:* ROLL WG
> reachable node as a root seems a very inefficient approach compared to 
> alternative routing algorithms. I am concerned that RPL does not 
> actually meet the original requirements in 
> I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, 
> RFC5673 and RFC5548. The traffic pattern requirement for a sink node 
> features prominently in only two of those documents. Even in this 
> case, as Ted points out, communication is likely to be bidirectional 
> (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally 
> asymmetric, especially if no intermediate storage is allowed for 
> destination routes and source routing has to be used.
>
> of memory as well as power and bandwidth. The RPL draft as it stands 
> is 82 pages long and that doesn't include text about the objective 
> function.
>
> Robert
>
> [email-masked] <mailto:[email-masked]> wrote:
>
>

---

From: [email-masked]
Date: Mon, 15 Mar 2010 16:00:42 -0500

Pascal

Going over your P2P proposal - I have
a  fundamental question that I would like to clarify -

On  page 3 you show how a 'new
P2P' DAG could be formed, with the initial transmission of a DIO message.

Included in the DIO message is the base
option parameters and maybe  DIO suboption(s)

Of the defined suboptions in the version
8 of the standard - I do not see a way to include in the DIO which node

I wish to send a message to (destination)
-  - -   so as the DIO is transmitted along the network
- - -  How does a node know which DAG  it should join ?

Should a node join any DAG for some
initial period - since it may be in the path, to the ultimate destination?

For instance in your example R wishes
to send a message to T but T is not aware, that it will be receiving a
message. When

the DIO comes along Should I join this
new DAG or not?  How do I decide?

When a DIO is received by this nod (T)
or any node (along the path A,D,E,F,G) - How do they determine if they
should join this new DAG?

Eventually  D and E join this new
DAG,  and A drops opts of the DAG.

How does a node know how to associate
a DAG to a destination address -  Is there an OCP / OF for each destination
address?

Does is matter if all of the nodes have
the same prefix on the LLN network?  If they all have the same prefix,
which has been discussed,

then the prefix suboption for the DIO
is less valuable.

How many DAGs can a LLN support?  For
P2P the number of DAGs could be the number of nodes minus 1, and every
node may be a member

of every DAG??

Typically every node does not need to
communicate with every other node, but the design should not limit the
number of P2P paths that

may be required.

Thanks

Ted

From:

"Pascal Thubert (pthubert)"
<[email-masked]>

To:

<[email-masked]>,
<[email-masked]>

Cc:

ROLL WG <[email-masked]>

Date:

03/15/2010 11:29 AM

Subject:

HI Robert :

My understanding is that
we are considering a limited set of P2P pairs, for which the specific path
that we need to create might have to obey specific constraints.

So it makes sense to use
an on-demand technique, probably inspired by the MANET Reactive protocols.

As it goes, those protocols
usually use flooding for a node to locate another. Forking a DAG is just
another flooding. It does not take a lot of addition to the existing DIO
for a root to use RPL to build a DAG that contains one or multiple Targets
as leaves, under a set of constraints expressed as an objective function.
Please find attached a slideware that illustrates that.

Pascal

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Cragie

To: [email-masked]

Cc: ROLL WG

I agree with Ted's comments below. Creating
a DODAG for every reachable node as a root seems a very inefficient approach
compared to alternative routing algorithms. I am concerned that RPL does
not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs,
I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern
requirement for a sink node features prominently in only two of those documents.
Even in this case, as Ted points out, communication is likely to be bidirectional
(e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric,
especially if no intermediate storage is allowed for destination routes
and source routing has to be used.

Robert

Gridmerge Ltd.

89 Greenfield Crescent,

Wakefield, WF4 4WA, UK

+44 (0) 1924 910888

http://www.gridmerge.com

[email-masked]
wrote:

Ted Humpal

From:

To:

Cc:

ROLL WG <[email-masked]>

Date:

03/08/2010 01:45 PM

Subject:

Re: [Roll] P2P performance with current RPL
proposal

Anders - if we take JP's suggestion to make The Lamp a DODAG root, and
take Phoebus' recommendation that we use path diversity to improve end-to-end
reliability, do you see a chance of success?

ksjp

Anders Brandt wrote:

Hello

support P2P.

Response time

=============

the light to turn on.

presence using DAOs.

the light to turn on.

My answer:

My answer:

Oh no. I get a very high degree
of management traffic which

limits my available bandwidth, increases the risk of collisions
and

868 - 868.6 MHz: <1%

voice on the list.

Going forward

=============

to sue our companies.

if they really have to.

participating nodes.

Now is the time.

Thanks,

Anders

Roll mailing list

[email-masked]

Roll mailing list

[email-masked]

Roll mailing list

[email-masked]

[attachment "DAGPtP.pdf"
deleted by Ted Humpal/CORP/Johnson_Controls] _______________________________________________

Roll mailing list

[email-masked]

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 15 Mar 2010 14:53:43 -0700

Hi Pascal,

I think for Smart Energy what you outlined may work.  We have a lot of
traffic from devices in the DAG to a single point (MP to P) but then most of
that traffic has some sort of response.  This means even if we use the
Energy Services Interface as the DAG root, we must still route down the DAG
on the responses.  We don't, however, have the low latency requirements you
will see in Building or Home Automation.  I do think those use cases will be
more difficult.

Don

From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Monday, March 15, 2010 10:55 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: ROLL WG
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Don :

Well, in both cases my words did not convey the message I wished to convey.

1)      I mean that the nodes that need to do P2P need to do so with a
limited set of other nodes, as opposed to all other nodes in the network. So
what you want to do is not any to any but  a number of groups of 2 or more
nodes that need to talk to one another

2)      I  mean that the path that we create might have to obey constraints,
like low latency, that the generic P2MP DAG does not need. For instance, I
think about a closed loop in process control.

I read your earlier mail about application role vs. network role. In that,
we might have to discuss some more. Because RPL is designed to optimize P2MP
and MP2P, it is not symmetrical wrt the P and the MP. The P has to be
selected to match the Goal that the DAG is built to serve.

Taking your example, one way of handling multiple lamps in a room can be to
set them all as roots , and then coordinate them, for instance through the
powerline, as discussed in section 3.2.

Our we could use the on-demand approach that I just suggested. For instance,
we could have each switch lookup the set of lamps by forking a DAG. With the
proposal, the DAG only spans so far, and acts as a reactive route setup. The
DIO contains the list of lamps, and each lamp answers with a DAO that can be
fanned out. The nodes that do not see the DAO back forget about that DAG
just like they would other reactive floodings.

Pascal

Hi Pascal,

Don

HI Robert :

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

  _____  

ksjp

Anders Brandt wrote: 
Hello 

  

  
  
Response time 
============= 

  

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders 

  _____  

 

  _____

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Mar 2010 03:23:14 +0100

Hi Robert :

At least from a distance, the proposed mechanism emulates AODV, with the
DIO as RREQ and the DAO as RREP. So if we decide to dig along those
lines, we'll certainly appreciate help from MANET experts. I'd say that
if you already have RPL for P2MP and MP2P, the proposed extension are
probably simpler to add than doing AODV from scratch.

For the setup, the major differences are that we build a DAG and that we
can indicate multiple targets. If you look at it, the DAG capability is
a MUST for RPL, and I have not seen that this MUST goes away for P2P
flows. The multiple targets is something that appears in a number of use
cases and it seems more economical to build a single DAG for multiple
targets when possible.

For the maintenance, the major differences are that we have the DAG as
first line of defense, and the RPL detection to stimulate the local
repair.

About your questions:

The DODAG root is the one that spawns the DAG. The targets can reach the
root because the root advertises itself in the DIO. The idea is that the
root ID is the address that the targets need to talk to. If needed, the
root can also advertise a prefix that it can reach and that the targets
need to reach too.

All the intermediate nodes that are confirmed by the DAO need to retain
at least info about the DAG. That enables the targets to reach the root.
The flooding should cost about the same as that of AODV but the RPL way
will require more states in the nodes on the way if the OF requires a
DAG.

The way back (down) can be stateful of stateless, depending on which DAO
we're using. With fully stateful DAO, we are really in AODV-land. With
stateless, we could drift into DSR-land for that direction. Which limits
we place to keep it simple will be determined by the resolution of issue
#26 I guess...

And please, no apologize or on one will dare post anything anymore. Your
questions are fully relevant and at the core of the discussion.

I hope we can talk in Anaheim for sure,

Pascal

From: Robert Cragie [mailto:[email-masked]] 
Sent: Monday, March 15, 2010 11:27 AM
To: Pascal Thubert (pthubert)
Cc: [email-masked]; ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal

Hi Pascal,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

HI Robert :

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

ksjp

Anders Brandt wrote: 
Hello 

  

  

  
Response time 
============= 

  

  
Going forward 
============= 

if they really have to. 

  

  
Thanks, 
  Anders

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Mar 2010 03:23:10 +0100

Hi Ted :

As you point out, the proposal requires a new option for P2P to indicate
the targets. It also requires to limit the distance at which we spawn
the DIO, things like that, details to be worked out. And yes, the nodes
on the way would keep a state when confirmed by DAO, and others would
time out and forget. The decision to join would include the capability
to run the OF, capacity, and probably some consistency logic like no
need to join if many neighbors already did.

Pascal

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 15, 2010 2:01 PM
To: Pascal Thubert (pthubert)
Cc: [email-masked]; ROLL WG; [email-masked]
Subject: Re: [Roll] P2P performance with current RPL proposal

Pascal 

Going over your P2P proposal - I have a  fundamental question that I
would like to clarify - 

On  page 3 you show how a 'new P2P' DAG could be formed, with the
initial transmission of a DIO message. 
Included in the DIO message is the base option parameters and maybe  DIO
suboption(s) 
Of the defined suboptions in the version 8 of the standard - I do not
see a way to include in the DIO which node 
I wish to send a message to (destination)  -  - -   so as the DIO is
transmitted along the network  - - -  How does a node know which DAG  it
should join ? 
Should a node join any DAG for some initial period - since it may be in
the path, to the ultimate destination? 

[Pascal] 

You are correct, the proposal requires a new option for P2P to indicate
the targets. It also requires to limit the distance at which we spawn
the DIO, things like that, details to be worked out. And yes, the nodes
on the way would keep a state when confirmed by DAO, and others would
time out and forget. 

For instance in your example R wishes to send a message to T but T is
not aware, that it will be receiving a message. When 
the DIO comes along Should I join this new DAG or not?  How do I decide?

When a DIO is received by this nod (T) or any node (along the path
A,D,E,F,G) - How do they determine if they should join this new DAG? 
Eventually  D and E join this new DAG,  and A drops opts of the DAG.   

[Pascal] The decision to join would include the capability to run the
OF, capacity, and probably some consistency logic like no need to join
if many neighbors already did. TBD.

How does a node know how to associate a DAG to a destination address -
Is there an OCP / OF for each destination address? 

Does is matter if all of the nodes have the same prefix on the LLN
network?  If they all have the same prefix, which has been discussed, 
then the prefix suboption for the DIO is less valuable. 

[Pascal] The prefix in the DIO is really something that you can reach
via the root, not the prefix option in the RA. The spec allows nodes on
the way to add their own, but that might lead to unwanted complexities,
like should the OCP select parents that have this additional prefix, or
else, will the route table flap?

How many DAGs can a LLN support?  For P2P the number of DAGs could be
the number of nodes minus 1, and every node may be a member 
of every DAG?? 

[Pascal] In that extreme case, we end up with something close to the
traditional DV, like RIP, when you use the DV to maintain multiple
feasible successors. In the use cases that I know of, the DAGs do not
span far. So at least, we enable the optimization of controlling how far
we flood, when RIP would floor the entire network about every node in
the network.

Typically every node does not need to communicate with every other node,
but the design should not limit the number of P2P paths that 
may be required. 

[Pascal] Sure. RPL enables to align the cost to what's really useful.
But when what's useful is a lot, the cost grows accordingly, no magic.

Cheers,

Thanks 

Ted 

From: 

"Pascal Thubert (pthubert)" <[email-masked]> 

To: 

<[email-masked]>, <[email-masked]> 

Cc: 

ROLL WG <[email-masked]> 

Date: 

03/15/2010 11:29 AM 

Subject: 

HI Robert : 

  
  
Pascal 
  
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: [email-masked]
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal 

Robert 

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

  

ksjp

Anders Brandt wrote: 
Hello 

 

 

 
Response time 
============= 

 

 
 
Going forward 
============= 

if they really have to. 

 

 
Thanks, 
 Anders 

  

  
  [attachment "DAGPtP.pdf" deleted by Ted Humpal/CORP/Johnson_Controls]

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 18 Mar 2010 19:41:25 -0700

Hi Pascal,

I have to say I am skeptical of a solution where destination devices
advertise themselves as DAG roots and sources join those DAGs.  It is not
clear to me at network formation how this is known and the number of
destination devices and potential source devices would indicate that too
much routing information would need to be retained to make such a solution
make sense economically.

>From my experience with Smart Energy, we seem resigned to creating
relatively few DAGs (maybe only one) then using source routing to reach
devices lower in the DAG.  I would doubt we would invest the time in forming
multiple DAGs or trying to optimize with multiple destination devices as DAG
roots and devices lower in the DAG joining multiple DAG depending on the
destination address of their packets.  Keep in mind we don't have the
requirement right now for low latency P2P communication in Smart Energy
which I would maintain IS NOT supported in the current RPL proposal.

I encourage you to look at some of the alternative I-Ds to create a workable
solution for P2P communication.  If you believe that low latency P2P
communication is currently supported, I would encourage you to take some of
the requirements from the Building Controls or Home Automation requirements
and show how this works with RPL today (particularly showing the memory
storage requirements on the individual devices in the DAG).  I think you
will quickly conclude there is a problem with respect to P2P routing.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: Thursday, March 18, 2010 7:23 PM
To: [email-masked]
Cc: ROLL WG; [email-masked]
Subject: Re: [Roll] P2P performance with current RPL proposal

Hi Robert :

At least from a distance, the proposed mechanism emulates AODV, with the DIO
as RREQ and the DAO as RREP. So if we decide to dig along those lines, we'll
certainly appreciate help from MANET experts. I'd say that if you already
have RPL for P2MP and MP2P, the proposed extension are probably simpler to
add than doing AODV from scratch.

For the setup, the major differences are that we build a DAG and that we can
indicate multiple targets. If you look at it, the DAG capability is a MUST
for RPL, and I have not seen that this MUST goes away for P2P flows. The
multiple targets is something that appears in a number of use cases and it
seems more economical to build a single DAG for multiple targets when
possible.

For the maintenance, the major differences are that we have the DAG as first
line of defense, and the RPL detection to stimulate the local repair.

About your questions:

The DODAG root is the one that spawns the DAG. The targets can reach the
root because the root advertises itself in the DIO. The idea is that the
root ID is the address that the targets need to talk to. If needed, the root
can also advertise a prefix that it can reach and that the targets need to
reach too.

All the intermediate nodes that are confirmed by the DAO need to retain at
least info about the DAG. That enables the targets to reach the root. The
flooding should cost about the same as that of AODV but the RPL way will
require more states in the nodes on the way if the OF requires a DAG.

The way back (down) can be stateful of stateless, depending on which DAO
we're using. With fully stateful DAO, we are really in AODV-land. With
stateless, we could drift into DSR-land for that direction. Which limits we
place to keep it simple will be determined by the resolution of issue #26 I
guess.

Pascal

Hi Pascal,

So in your slideware T can end up talking to R (DODAG root) through the
DODAG. So are you proposing that all potential targets can act as a DODAG
root? And therefore all intermediates have to retain DIO propagation support
for that DODAG as well? This may work for limited P2P but seems less
efficient than simple distance vector flooding RREQ/RREP like AODV or DYMO
for generic P2P. What about R to T (or anyone else for that matter)? Do we
source route, maintain state, some undefined hybrid of the two?

I apologise if some of these questions have been answered in detail in
earlier reflector posts but I have only recently started to concentrate my
efforts on RPL and have 82 pages to wade through :-). I look forward to a
productive session in Anaheim.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

HI Robert :

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

  _____  

ksjp

Anders Brandt wrote: 
Hello 

  

  
  
Response time 
============= 

  

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders 

  _____  

 

  _____

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 19 Mar 2010 02:09:06 -0500 (CDT)

Pascal, WG:

Here I have attempted to formulate a simple DV algorithm in RPL/DAG terms. I will appreciate it if you could let me know about your objections to this proposal:

Node A needs to reach a destination D. Node A initiates a discovery DAG towards D. As the DIOs reach D, it sends a DAO back to selected parents. As the DAO travels towards node A, in-route nodes store the cost to reach D.

When node B needs to reach D, it similarly initiates a discovery dag. During this discovery, when a DIO reaches a node C that maintains a cost to reach D, node C responds back with a DAO that travels towards B and stores in in-route nodes the cost to reach D.

Thus, as more and more nodes try to discover a route to D, a destination oriented DAG (DODAG) emerges that leads these nodes to D. The difference from the traditional DODAG, as explained in RPL draft, is that the DAG root does not initiate DAG formation. The leaf nodes initiate the discovery of the DAG root.

Now, we can go one step further in order to save on memory – combine DODAGs leading to D and another destination E into one. This can be done by aggregating the cost to reach D and E into one cost (the higher of the two) and letting parent nodes know about the aggregated cost. Repeated aggregations can help reduce memory requirements at the cost of suboptimality.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "robert cragie" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>
Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal

Hi Robert : 

At least from a distance, the proposed mechanism emulates AODV, with the DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines, we’ll certainly appreciate help from MANET experts. I’d say that if you already have RPL for P2MP and MP2P, the proposed extension are probably simpler to add than doing AODV from scratch. 

For the setup, the major differences are that we build a DAG and that we can indicate multiple targets. If you look at it, the DAG capability is a MUST for RPL, and I have not seen that this MUST goes away for P2P flows. The multiple targets is something that appears in a number of use cases and it seems more economical to build a single DAG for multiple targets when possible. 

For the maintenance, the major differences are that we have the DAG as first line of defense, and the RPL detection to stimulate the local repair. 

About your questions: 

The DODAG root is the one that spawns the DAG. The targets can reach the root because the root advertises itself in the DIO. The idea is that the root ID is the address that the targets need to talk to. If needed, the root can also advertise a prefix that it can reach and that the targets need to reach too. 

All the intermediate nodes that are confirmed by the DAO need to retain at least info about the DAG. That enables the targets to reach the root. The flooding should cost about the same as that of AODV but the RPL way will require more states in the nodes on the way if the OF requires a DAG. 

The way back (down) can be stateful of stateless, depending on which DAO we’re using. With fully stateful DAO, we are really in AODV-land. With stateless, we could drift into DSR-land for that direction. Which limits we place to keep it simple will be determined by the resolution of issue #26 I guess… 

And please, no apologize or on one will dare post anything anymore. Your questions are fully relevant and at the core of the discussion. 

Pascal 

To: Pascal Thubert (pth ubert) 

Hi Pascal, 

So in your slideware T can end up talking to R (DODAG root) through the DODAG. So are you proposing that all potential targets can act as a DODAG root? And therefore all intermediates have to retain DIO propagation support for that DODAG as well? This may work for limited P2P but seems less efficient than simple distance vector flooding RREQ/RREP like AODV or DYMO for generic P2P. What about R to T (or anyone else for that matter)? Do we source route, maintain state, some undefined hybrid of the two? 

I apologise if some of these questions have been answered in detail in earlier reflector posts but I have only recently started to concentrate my efforts on RPL and have 82 pages to wade through :-). I look forward to a productive session in Anaheim. 

Robert 

Gridmerge Ltd. 
89 Greenfield Crescent, 
Wakefield, WF4 4WA, UK 
+44 (0) 1924 910888 
http://www.gridmerge.com 

HI Robert : 

My understanding is that we are considering a limited set of P2P pairs, for which the specific path that we need to create might have to obey specific constraints. 

So it makes sense to use an on-demand technique, probably inspired by the MANET Reactive protocols. 

As it goes, those protocols usually use flooding for a node to locate another. Forking a DAG is just another flooding. It does not take a lot of addition to the existing DIO for a root to use RPL to build a DAG that contains one or multiple Targets as leaves, under a set of constraints expressed as an objective function. Please find attached a slideware that illustrates that. 

Pascal 

From: [email-masked] [ mailto:[email-masked] ] On Behalf Of Robert Cragie 
Sent: Thursday, March 11, 2010 2:43 PM 
To: [email-masked] 
Cc: ROLL WG 
Subject: Re: [Roll] P2P performance with current RPL proposal 

I agree with Ted's comments below. Creating a DODAG for every reachable node as a root seems a very inefficient approach compared to alternative routing algorithms. I am concerned that RPL does not actually meet the original requirements in I-D.ietf-roll-building-routing-reqs, I-D.ietf-roll-home-routing-reqs, RFC5673 and RFC5548. The traffic pattern requirement for a sink node features prominently in only two of those documents. Even in this case, as Ted points out, communication is likely to be bidirectional (e.g. end-to-end acks.) therefore the DODAG approach is fundamentally asymmetric, especially if no intermediate storage is allowed for destination routes and source routing has to be used. 

Also, RPL seems highly complex for what are constrained nodes in terms of memory as well as power and bandwidth. The RPL draft as it stands is 82 pages long and that doesn't include text about the objective function. 

Robert 

Gridmerge Ltd. 
89 Greenfield Crescent, 
Wakefield, WF4 4WA, UK 
+44 (0) 1924 910888 
http://www.gridmerge.com 

A concern also will be how much overhead (memory space) will be required for a DODAG Root? 

and based on the first question how many DODAG roots a lamp may need to be a member of? 

For example in lighting  a single lamp may be a root for a single switch (1 DODAG root),  this lamp / luminaire may also 
be a member of another group - -  which could be all lights on the floor (2nd DODAG root), and a third group 
of all the lights in the building.  There can be many more speciality groups associated based on the building configuration. 
Consider also during the installation time - how these DODAG roots will be configured?  Must I commission each device 
to tell it which DODAG it must use for its Object Function?  How easy will this be to change and add in a new DODAG root 
for the end user if the lighting group changes?? 

With respect to Jerry Martocci's - commercial building requirements - every device may need to communicate to any or 
all of the end devices.  If each device must establish a DODAG for the other 499 devices in a 500 node network - How much memory 
space will this require for each end device to maintain?   

Keep in mind that the end devices are very limited processor and memory wise. 

Not to mention all of the network maintenance messages that would need to be transmitted to maintain all of these DODAGs. 

Consider the reconvergence time when one device is turned off and it was in the middle of the majority of the 100+ DODAGS? 

In many lighting and building application an application acknowledgement - must be returned {Back down the DODAG} so . . . the 
requirement is not just getting to the Root - a return path must also be maintained and have a  low latency path. 

Ted Humpal 

From: 	

To: 	

Cc: 	

ROLL WG <[email-masked]> 

Date: 	

03/08/2010 01:45 PM 

Subject: 	

Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? 
In my experience, with diverse paths and order-minutes updates you get extremely high reliability. 

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably infrequently used) options. 

ksjp 

Anders Brandt wrote: 
Hello 

  

  
  
Response time 
============= 

  

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders 

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

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 19 Mar 2010 08:37:36 +0100

+1
 
Anders

Fra: [email-masked] på vegne af Don Sturek
Sendt: fr 19-03-2010 03:41
Til: 'Pascal Thubert (pthubert)'; [email-masked]
Cc: 'ROLL WG'; [email-masked]
Emne: Re: [Roll] P2P performance with current RPL proposal

Hi Pascal,

I have to say I am skeptical of a solution where destination devices advertise themselves as DAG roots and sources join those DAGs.  It is not clear to me at network formation how this is known and the number of destination devices and potential source devices would indicate that too much routing information would need to be retained to make such a solution make sense economically.

>From my experience with Smart Energy, we seem resigned to creating relatively few DAGs (maybe only one) then using source routing to reach devices lower in the DAG.  I would doubt we would invest the time in forming multiple DAGs or trying to optimize with multiple destination devices as DAG roots and devices lower in the DAG joining multiple DAG depending on the destination address of their packets.  Keep in mind we don't have the requirement right now for low latency P2P communication in Smart Energy which I would maintain IS NOT supported in the current RPL proposal.

I encourage you to look at some of the alternative I-Ds to create a workable solution for P2P communication.  If you believe that low latency P2P communication is currently supported, I would encourage you to take some of the requirements from the Building Controls or Home Automation requirements and show how this works with RPL today (particularly showing the memory storage requirements on the individual devices in the DAG).  I think you will quickly conclude there is a problem with respect to P2P routing.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)

Hi Robert :

At least from a distance, the proposed mechanism emulates AODV, with the DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines, we'll certainly appreciate help from MANET experts. I'd say that if you already have RPL for P2MP and MP2P, the proposed extension are probably simpler to add than doing AODV from scratch.

About your questions:

The way back (down) can be stateful of stateless, depending on which DAO we're using. With fully stateful DAO, we are really in AODV-land. With stateless, we could drift into DSR-land for that direction. Which limits we place to keep it simple will be determined by the resolution of issue #26 I guess...

Pascal

Hi Pascal,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

HI Robert :

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Thursday, March 11, 2010 2:43 PM
To: [email-masked]
Cc: ROLL WG
Subject: Re: [Roll] P2P performance with current RPL proposal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

ksjp

Anders Brandt wrote: 
Hello 

  

  
  
Response time 
============= 

  
  http://focus.ti.com/lit/an/swra048/swra048.pdf <http://focus.ti.com/lit/an/swra048/swra048.pdf> 
 868 - 868.6 MHz: <1% 

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders 

_______________________________________________
Roll mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll> 
 _______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>

---

From: "Salazar, Ruben" <[email-masked]>
Date: Fri, 19 Mar 2010 10:13:47 -0400

I would correct Anders on one point: 

We DO have requirements for low latency P2P in the smart grid in the USA.

The Distribution system (at least) counts on it already today.

Regards

Ruben Salazar, PhD

Director of Research  and Technology

Landys+Gyr EMS

Office: 678 258 3165

Cellular: 678 438 0063

[email-masked]

www.landisgyr.com

manage energy better

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Brandt
Sent: Friday, March 19, 2010 3:38 AM
To: [email-masked]; Pascal Thubert (pthubert); [email-masked]
Cc: ROLL WG; [email-masked]
Subject: Re: [Roll] P2P performance with current RPL proposal

+1

Anders

Ruben Salazar
Director of Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165
Fax: +1 678 258 1550
[email-masked]
www.landisgyr.com
manage energy better
________________________________

Hi Pascal,

Don

Hi Robert :

About your questions:

Pascal

Hi Pascal,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

HI Robert :

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

ksjp

Anders Brandt wrote: 
Hello 

  

  
  
Response time 
============= 

  

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders

---

From: "Don Sturek" <[email-masked]>
Date: Fri, 19 Mar 2010 07:23:32 -0700

Hi Ruben,

Yes, I was just speaking for the Home Area Network portion of the Smart
Energy solution (where we schedule events on minute boundaries).  If ROLL is
used as a mesh routing solution in the access side of the meter (towards the
utility) then there are low latency requirements.

Ruben:  It might be worth reviewing the building controls and home controls
requirements in ROLL to see whether these fit the application you are
thinking about.

Don

From: Salazar, Ruben [mailto:[email-masked]] 
Sent: Friday, March 19, 2010 7:14 AM
To: Anders Brandt; [email-masked]; Pascal Thubert (pthubert);
[email-masked]
Cc: ROLL WG; [email-masked]
Subject: RE: [Roll] P2P performance with current RPL proposal

Regards

Ruben Salazar, PhD

Landys+Gyr EMS

Office: 678 258 3165

Cellular: 678 438 0063

www.landisgyr.com

manage energy better

Ruben Salazar
Director of Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165
Fax: +1 678 258 1550        
[email-masked]
www.landisgyr.com <http://www.landisgyr.com/>  
manage energy better

+1

Anders

  _____  

Hi Pascal,

destination address of their packets.  Keep in mind we don’t have the

Don

Hi Robert :

At least from a distance, the proposed mechanism emulates AODV, with the DIO
as RREQ and the DAO as RREP. So if we decide to dig along those lines, we’ll
certainly appreciate help from MANET experts. I’d say that if you already
have RPL for P2MP and MP2P, the proposed extension are probably simpler to
add than doing AODV from scratch.

About your questions:

The way back (down) can be stateful of stateless, depending on which DAO
we’re using. With fully stateful DAO, we are really in AODV-land. With
stateless, we could drift into DSR-land for that direction. Which limits we
place to keep it simple will be determined by the resolution of issue #26 I
guess…

Pascal

Hi Pascal,

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

HI Robert :

Pascal

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

Ted Humpal 

From: 

To: 

Cc: 

Date: 

03/08/2010 01:45 PM 

Subject: 

  _____  

ksjp

Anders Brandt wrote: 
Hello 

  

  
  
Response time 
============= 

  

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders 

  _____  

 

  _____

---

From: Robert Cragie <[email-masked]>
Date: Fri, 19 Mar 2010 15:37:50 +0000

I think we are starting to get somewhere with the concept of DIO as RREQ 
and DAO as RREP. However, to make it on-demand and efficient, we need to 
be able to initiate a DIO immediately from any node and not have it 
associated with a trickle timer. Similarly, nodes with a higher rank 
number based on the origin of the DIO would need to store DAG 
information temporarily and expire it if a corresponding DAO is not 
received going back to the originator. So the concept of root goes away 
somewhat; in this case it is more originator. The DAG information can be 
set bidirectionally to allow route discovery in both directions 
(outbound on the DIO and return on the DAO) thus potentially eliminating 
the need for source routing.

I think this would allow DODAGs and this new route formations (not sure 
what to call them) to coexist without having to maintain the overhead of 
multiple DODAGs with different roots.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 19/03/2010 7:09 AM, Mukul Goyal wrote:
> From: "Pascal Thubert (pthubert)"<[email-masked]>
> To: "robert cragie"<[email-masked]>
> Cc: "ROLL WG"<[email-masked]>, "Ted Humpal"<[email-masked]>
> Robert Cragie (Pacific Gas&  Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Robert Cragie (Pacific Gas&  Electric)
>
> Gridmerge Ltd.
> 89 Greenfield Crescent,
> Wakefield, WF4 4WA, UK
> +44 (0) 1924 910888
> http://www.gridmerge.com
>
>
>
> Kris Pister<[email-masked]>
>
>
> To: 	
>
> Anders Brandt<[email-masked]>
>
>
> Cc: 	
>
> ROLL WG<[email-masked]>
>
>
> Date: 	
>
> 03/08/2010 01:45 PM
>
>
> Subject: 	
>
>   868 - 868.6 MHz:<1%

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 19 Mar 2010 17:20:58 +0100

Hi Mukul
> Here I have attempted to formulate a simple DV algorithm in RPL/DAG terms.
> I will appreciate it if you could let me know about your objections to this
> proposal:

[Pascal] It's cool that you do it is the first impression.
 
> Node A needs to reach a destination D. Node A initiates a discovery DAG
> towards D. As the DIOs reach D, it sends a DAO back to selected parents. As
> the DAO travels towards node A, in-route nodes store the cost to reach D.
> 
> When node B needs to reach D, it similarly initiates a discovery dag. During
> this discovery, when a DIO reaches a node C that maintains a cost to reach D,
> node C responds back with a DAO that travels towards B and stores in in-
> route nodes the cost to reach D.

[Pascal]  understand that you're trying to make RPL even closer to AODV.
I agree we need to gather as much as we can from that work. 

For the specifics of your proposal:

- B-C might be orthogonal to A-D so that B/C\D forms an angle. You do not end up with the best path that you're looking for.

- there might be multiple C's. Which one is the right one?

- RPL does not allow packets to switch instances. Following multiple DAGs is the recipe for loops - unless you have them strictly ordered by some means like the RPL sequence between iterations, more specific routes, blah blah...)

- the A to D path is optimized for a certain constraint. You seem to imply that the B to D path has the same constraints and metrics so we can compare apple to apple. Because this is a very delicate operation, RPL has introduced the Rank, which has the right properties to make that comparison efficiently.So for RPL, the loop avoidance metric is the Rank, and it is only valid within an iteration.

- A P2P path does not come out of the blue. There must be some provisionning system that determines that those nodes, A and B, are very special so they need a P2P optimization, with a given special OF, and that they both need to talk to D. Well, if that's so, the most economical is for that system to fork the DAG out of D, with dual targets A and B. There you obtain the shortest path for both A-D and B-D for the cost of a single flooding.

I see that you're trying to get the idea to work better, and I hope we find a way to do so, maybe along your lines if we can solve the issues above. But before we get there, we need to agree that this is the path we wish to take.

Cheers,

Pascal

> DIO as RREQ and the DAO as RREP. So if we decide to dig along those lines,
> we’ll certainly appreciate help from MANET experts. I’d say that if you
> already have RPL for P2MP and MP2P, the proposed extension are probably
> simpler to add than doing AODV from scratch.
> 
> 
> 
> indicate multiple targets. If you look at it, the DAG capability is a MUST for
> RPL, and I have not seen that this MUST goes away for P2P flows. The
> first line of defense, and the RPL detection to stimulate the local repair.
> 
> 
> 
> About your questions:
> 
> 
> 
> root because the root advertises itself in the DIO. The idea is that the root ID
> is the address that the targets need to talk to. If needed, the root can also
> advertise a prefix that it can reach and that the targets need to reach too.
> 
> 
> 
> root? And therefore all intermediates have to retain DIO propagation
> support for that DODAG as well? This may work for limited P2P but seems
> less efficient than simple distance vector flooding RREQ/RREP like AODV or
> DYMO for generic P2P. What about R to T (or anyone else for that matter)?
> Do we source route, maintain state, some undefined hybrid of the two?
> 
> I apologise if some of these questions have been answered in detail in earlier
> reflector posts but I have only recently started to concentrate my efforts on
> RPL and have 82 pages to wade through :-). I look forward to a productive
> session in Anaheim.
> 
> Robert
> 
>

---

From: "Anders Brandt" <[email-masked]>
Date: Sun, 21 Mar 2010 08:58:20 +0100

Pascal wrote:
 
>- A P2P path does not come out of the blue. There must be some provisionning system that determines
>that those nodes, A and B, are very special so they need a P2P optimization, with a given special OF,
>and that they both need to talk to D. Well, if 
 
I would claim that in a home control environment they have to come out of the blue!
I need application association and low-latency control to work beyond direct range an my users have NO
interest in setting up network rules for provisioning, etc.
Sorry.
 
- Anders

Fra: [email-masked] på vegne af Pascal Thubert (pthubert)
Sendt: fr 19-03-2010 17:20
Til: Mukul Goyal
Cc: ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL proposal

Hi Mukul

Cheers,

Pascal

> we'll certainly appreciate help from MANET experts. I'd say that if you
> guess...

---

From: "Don Sturek" <[email-masked]>
Date: Sun, 21 Mar 2010 08:08:25 -0700

Hi Anders,

Let me add one more point.

In a Smart Energy Home Area Network, the customer should not even know there
is a network let alone have any role in commissioning.  Network formation
and joining needs to happen autonomously and P2P routing needs to be enabled
and made to work without any action from the customer.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Brandt
Sent: Sunday, March 21, 2010 12:58 AM
To: Pascal Thubert (pthubert); Mukul Goyal
Cc: ROLL WG; Ted Humpal
Subject: Re: [Roll] P2P performance with current RPL proposal

>and that they both need to talk to D. Well, if 

I would claim that in a home control environment they have to come out of
the blue!

I need application association and low-latency control to work beyond direct
range an my users have NO
interest in setting up network rules for provisioning, etc.

Sorry.

- Anders

  _____  

Hi Mukul

- B-C might be orthogonal to A-D so that B/C\D forms an angle. You do not
end up with the best path that you're looking for.

- RPL does not allow packets to switch instances. Following multiple DAGs is
the recipe for loops - unless you have them strictly ordered by some means
like the RPL sequence between iterations, more specific routes, blah
blah...)

- the A to D path is optimized for a certain constraint. You seem to imply
that the B to D path has the same constraints and metrics so we can compare
apple to apple. Because this is a very delicate operation, RPL has
introduced the Rank, which has the right properties to make that comparison
efficiently.So for RPL, the loop avoidance metric is the Rank, and it is
only valid within an iteration.

- A P2P path does not come out of the blue. There must be some provisionning
system that determines that those nodes, A and B, are very special so they
need a P2P optimization, with a given special OF, and that they both need to
talk to D. Well, if that's so, the most economical is for that system to
fork the DAG out of D, with dual targets A and B. There you obtain the
shortest path for both A-D and B-D for the cost of a single flooding.

I see that you're trying to get the idea to work better, and I hope we find
a way to do so, maybe along your lines if we can solve the issues above. But
before we get there, we need to agree that this is the path we wish to take.

Cheers,

Pascal

> For the setup, the major differences are that we build a DAG and that we
can
> indicate multiple targets. If you look at it, the DAG capability is a MUST
for
repair.
> root because the root advertises itself in the DIO. The idea is that the
root ID
> stateless, we could drift into DSR-land for that direction. Which limits
we
> I apologise if some of these questions have been answered in detail in
earlier
> Robert Cragie (Pacific Gas & Electric)
for
> As it goes, those protocols usually use flooding for a node to locate
another.
> original requirements in I-D.ietf-roll-building-routing-reqs,
I-D.ietf-roll-home-
and
> Robert Cragie (Pacific Gas & Electric)
(1
> be a member of another group - -  which could be all lights on the floor
(2nd
> of all the lights in the building.  There can be many more speciality
groups
> to tell it which DODAG it must use for its Object Function?  How easy will
this
> With respect to Jerry Martocci's - commercial building requirements -
every
> all of the end devices.  If each device must establish a DODAG for the
other
> Consider the reconvergence time when one device is turned off and it was
in
> I have no aversion to TTL-limited floods as a part of a solution either.
I'm

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 21 Mar 2010 18:36:09 +0100

Hi Don and Anders,

The existence of small sets of things tied together, like the lamp(s) and the switch(es), or the remote and the TV, etc..., is what enable a P2P optimization within the sets that's cheaper than the general any to any.

I can understand that the end-user should be mostly transparent to this. But figuring out which nodes are in which sets is an application thing and out of scope for RPL. You give RPL a set of IP addresses and RPL builds on-demand routes between those.

Some additional optimizations are possible with RPL. For  instance, one on-demand DAG with multiple targets is cheaper and more efficient than one DAG per target. But an optimization like this can only happen if the something that builds the sets is smart enough to benefit from those in the first place.

Pascal

From: Don Sturek [mailto:[email-masked]] 
Sent: Sunday, March 21, 2010 8:08 AM
To: 'Anders Brandt'; Pascal Thubert (pthubert); 'Mukul Goyal'
Cc: 'ROLL WG'; 'Ted Humpal'
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Anders,

In a Smart Energy Home Area Network, the customer should not even know there is a network let alone have any role in commissioning.  Network formation and joining needs to happen autonomously and P2P routing needs to be enabled and made to work without any action from the customer.

Don

Sorry.

- Anders

Hi Mukul

Cheers,

Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 22 Mar 2010 02:47:00 -0500 (CDT)

Hi Pascal

Thanks for your comments (let me send my response in the next email). 

Based on further thoughts, it seems to me that a DAG based P2P solution would work if we do the following:

(a) allowing multicast DIS messages to spread to an originator-specified number of hops and 
(b) allowing nodes to join a DAG temporarily and leave it if there is not sufficient “routing interest” in being part of the DAG.

With these points in mind, a P2P scheme could work as follows:

1. When a node wants to join a DODAG(D,F), where D is the DODAG's root and F is the OF being used, it does the following:
    a. Initiates a discovery table entry for DODAG(D,F). The discovery table entries are removed after a certain lifetime.
    b. sends out a DIS via link-local multicast asking specifically for information about DODAG(D,F). It also lists in the DIS the number of hops the DIS can travel.

2. On receiving  a DIS, a node does the following:
    a.if it does not know about DODAG(D,F) and the DIS hop limit is not yet reached 
        i. Initiates a discovery table entry for DODAG(D,F). This entry maintains information about the nodes from whom the DIS were received.
        ii. sends out the DIS (via link-local multicast with trickle controlled timing) further.
    b. If it is already a part of DODAG(D,F) or is node D itself
        i. Send out a DIO about DODAG(D,F) to the node from whom the DIS was received.

3. On receiving a DIO about DODAG(D,F), a node does the following:
    a. Ignore the DIO if the node does not have a discovery table entry for DODAG(D,F)
    b. Otherwise, the node joins the DODAG(D,F) (if not already part of it) or updates its parent set in DODAG(D,F) and sends the DIO by unicast to the nodes that had sent it the DIS.

4. Once, the node is part of the DODAG(D,F), it maintains a “routing interest” for the DODAG in the following manner:
    a. Routing interest is a value between 0 and 1
    b. Routing interest is 1 if the node recently forwarded a packet along the DODAG(D,F)
    c. Otherwise, the routing interest is x*maximum routing interest of the neighbors in DODAG(D,F), where x is a fraction. The node comes to know of neighbor’s routing interest via the neighbor’s DIO. 
    d. A node leaves a DODAG if its routing interest in the DODAG goes below a threshold.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>, "robert cragie" <[email-masked]>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Mukul

Cheers,

Pascal

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 22 Mar 2010 15:46:20 +0100

Add to this an element of promiscuos listening to dampen the storm => if node already detected a copy of the DIS with the same TTL (or lower) - do not forward the DIS. Then you start getting closer to something.
 
Oh - and by the way - record the source route on the way ;-)
 
- Anders

Fra: [email-masked] på vegne af Mukul Goyal
Sendt: ma 22-03-2010 01:47
Til: Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL proposal

Hi Pascal

(a) allowing multicast DIS messages to spread to an originator-specified number of hops and
(b) allowing nodes to join a DAG temporarily and leave it if there is not sufficient "routing interest" in being part of the DAG.

4. Once, the node is part of the DODAG(D,F), it maintains a "routing interest" for the DODAG in the following manner:
    a. Routing interest is a value between 0 and 1
    b. Routing interest is 1 if the node recently forwarded a packet along the DODAG(D,F)
    c. Otherwise, the routing interest is x*maximum routing interest of the neighbors in DODAG(D,F), where x is a fraction. The node comes to know of neighbor's routing interest via the neighbor's DIO.
    d. A node leaves a DODAG if its routing interest in the DODAG goes below a threshold.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>, "robert cragie" <[email-masked]>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Mukul

Cheers,

Pascal

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 22 Mar 2010 07:52:38 -0700

Hi Anders and Mukul,

This is all sounding quite promising in addressing P2P routing in RPL.  How
can we organize a specific proposal we can gain WG approval for?  I would
like to leave Anaheim with an agreed path towards P2P routing support we all
believe addresses the Home Automation and Building Controls use cases.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Brandt
Sent: Monday, March 22, 2010 7:46 AM
To: Mukul Goyal; Pascal Thubert (pthubert)
Cc: ROLL WG; Ted Humpal
Subject: Re: [Roll] P2P performance with current RPL proposal

Add to this an element of promiscuos listening to dampen the storm => if
node already detected a copy of the DIS with the same TTL (or lower) - do
not forward the DIS. Then you start getting closer to something.

- Anders

  _____  

Hi Pascal

Based on further thoughts, it seems to me that a DAG based P2P solution
would work if we do the following:

(a) allowing multicast DIS messages to spread to an originator-specified
number of hops and
(b) allowing nodes to join a DAG temporarily and leave it if there is not
sufficient “routing interest” in being part of the DAG.

1. When a node wants to join a DODAG(D,F), where D is the DODAG's root and F
is the OF being used, it does the following:
    a. Initiates a discovery table entry for DODAG(D,F). The discovery table
entries are removed after a certain lifetime.
    b. sends out a DIS via link-local multicast asking specifically for
information about DODAG(D,F). It also lists in the DIS the number of hops
the DIS can travel.

2. On receiving  a DIS, a node does the following:
    a.if it does not know about DODAG(D,F) and the DIS hop limit is not yet
reached
        i. Initiates a discovery table entry for DODAG(D,F). This entry
maintains information about the nodes from whom the DIS were received.
        ii. sends out the DIS (via link-local multicast with trickle
controlled timing) further.
    b. If it is already a part of DODAG(D,F) or is node D itself
        i. Send out a DIO about DODAG(D,F) to the node from whom the DIS was
received.

3. On receiving a DIO about DODAG(D,F), a node does the following:
    a. Ignore the DIO if the node does not have a discovery table entry for
DODAG(D,F)
    b. Otherwise, the node joins the DODAG(D,F) (if not already part of it)
or updates its parent set in DODAG(D,F) and sends the DIO by unicast to the
nodes that had sent it the DIS.

4. Once, the node is part of the DODAG(D,F), it maintains a “routing
interest” for the DODAG in the following manner:
    a. Routing interest is a value between 0 and 1
    b. Routing interest is 1 if the node recently forwarded a packet along
the DODAG(D,F)
    c. Otherwise, the routing interest is x*maximum routing interest of the
neighbors in DODAG(D,F), where x is a fraction. The node comes to know of
neighbor’s routing interest via the neighbor’s DIO.
    d. A node leaves a DODAG if its routing interest in the DODAG goes below
a threshold.

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>, "robert
cragie" <[email-masked]>
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central
Subject: RE: [Roll] P2P performance with current RPL proposal

Hi Mukul

Cheers,

Pascal

can
for
repair.
root ID
we
earlier
for
another.
I-D.ietf-roll-home-
and
(1
(2nd
groups
this
every
other
in
I'm

---

From: Philip Levis <[email-masked]>
Date: Mon, 22 Mar 2010 09:20:46 -0700

Just to be sure I am hearing this right -the proposal is to use  
hopcount-based route selection?

Phil

On Mar 22, 2010, at 7:52 AM, "Don Sturek" <[email-masked]> wrote:

> Hi Anders and Mukul,
>
>
>
> This is all sounding quite promising in addressing P2P routing in  
> RPL.  How can we organize a specific proposal we can gain WG  
> approval for?  I would like to leave Anaheim with an agreed path  
> towards P2P routing support we all believe addresses the Home  
> Automation and Building Controls use cases.
>
>
>
> Don
>
>
>
>
>
> Add to this an element of promiscuos listening to dampen the storm  
> => if node already detected a copy of the DIS with the same TTL (or  
> lower) - do not forward the DIS. Then you start getting closer to  
> something.
>
>
>
> Based on further thoughts, it seems to me that a DAG based P2P  
> solution would work if we do the following:
>
> (b) allowing nodes to join a DAG temporarily and leave it if there  
> is not sufficient “routing interest” in being part of the DAG.
>
> 1. When a node wants to join a DODAG(D,F), where D is the DODAG's  
> root and F is the OF being used, it does the following:
>     a. Initiates a discovery table entry for DODAG(D,F). The  
> discovery table entries are removed after a certain lifetime.
>     b. sends out a DIS via link-local multicast asking specifically  
> for information about DODAG(D,F). It also lists in the DIS the  
> number of hops the DIS can travel.
>
>         i. Initiates a discovery table entry for DODAG(D,F). This  
> entry maintains information about the nodes from whom the DIS were  
> received.
>     b. Otherwise, the node joins the DODAG(D,F) (if not already part  
> of it) or updates its parent set in DODAG(D,F) and sends the DIO by  
> unicast to the nodes that had sent it the DIS.
>
>     c. Otherwise, the routing interest is x*maximum routing interest  
> of the neighbors in DODAG(D,F), where x is a fraction. The node  
> comes to know of neighbor’s routing interest via the neighbor’s DI 
> O.
> Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>,  
> "robert cragie" <[email-masked]>
> - B-C might be orthogonal to A-D so that B/C\D forms an angle. You  
> do not end up with the best path that you're looking for.
>
> - RPL does not allow packets to switch instances. Following multiple  
> DAGs is the recipe for loops - unless you have them strictly ordered  
> by some means like the RPL sequence between iterations, more  
> specific routes, blah blah...)
>
> - the A to D path is optimized for a certain constraint. You seem to  
> imply that the B to D path has the same constraints and metrics so  
> we can compare apple to apple. Because this is a very delicate  
> operation, RPL has introduced the Rank, which has the right  
> properties to make that comparison efficiently.So for RPL, the loop  
> avoidance metric is the Rank, and it is only valid within an  
> iteration.
>
> - A P2P path does not come out of the blue. There must be some  
> provisionning system that determines that those nodes, A and B, are  
> very special so they need a P2P optimization, with a given special  
> OF, and that they both need to talk to D. Well, if that's so, the  
> most economical is for that system to fork the DAG out of D, with  
> dual targets A and B. There you obtain the shortest path for both A- 
> D and B-D for the cost of a single flooding.
>
> I see that you're trying to get the idea to work better, and I hope  
> we find a way to do so, maybe along your lines if we can solve the  
> issues above. But before we get there, we need to agree that this is  
> the path we wish to take.
>
> Cheers,
>
> Pascal
>
>
> >
> pairs, for
> > From: [email-masked] [ mailto:[email-masked] ] On  
> Behalf Of
> > Robert Cragie
> reachable
> terms of
> need to
> switch (1
> speciality groups
> will be
> the other
> memory
> need
> it was in
> acknowledgement -
> end-
> either.  I'm

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 22 Mar 2010 17:31:11 +0100

Well, yes.
 
But it needs to be seen in the right context:
I really need to get my lamp turned on within seconds when my users press the button.
Even if this meens that I get a less-than-optimal route.
 
The intention is not to skip all the nice DODAG DIO work that was done. It serves a good purpose
in large networks.
The case is just that home & building have some tougher requirements within restricted areas (<= 4 repeaters)
such as battery-friendly (i.e. short routes) and reactive discovery to "guarantee" low response times always.
 
The challenge is to get this for free.
 
- Anders

Fra: Philip Levis [mailto:[email-masked]]
Sendt: ma 22-03-2010 10:20
Til: [email-masked]
Cc: Anders Brandt; Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal
Emne: Re: [Roll] P2P performance with current RPL proposal

Just to be sure I am hearing this right -the proposal is to use hopcount-based route selection?

Phil

	Hi Anders and Mukul,

	This is all sounding quite promising in addressing P2P routing in RPL.  How can we organize a specific proposal we can gain WG approval for?  I would like to leave Anaheim with an agreed path towards P2P routing support we all believe addresses the Home Automation and Building Controls use cases.

	Don

	- Anders

	Hi Pascal

	

	

	
	Thanks
	Mukul
	
	----- Original Message -----
	From: "Pascal Thubert (pthubert)" <[email-masked]>
	To: "Mukul Goyal" <[email-masked]>
	Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>, "robert cragie" <[email-masked]>
	Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central
	Subject: RE: [Roll] P2P performance with current RPL proposal
	
	Hi Mukul

	

	

	

	Cheers,
	
	Pascal

	> From: Robert Cragie [ <mailto:[email-masked]> mailto:[email-masked]]
	> <http://www.gridmerge.com/> http://www.gridmerge.com <http://www.gridmerge.com/> 
	>
	>
	>
	> From: [email-masked] [ <mailto:[email-masked]> mailto:[email-masked] ] On Behalf Of
	> Robert Cragie
	> To: <mailto:[email-masked]> [email-masked]
	> Cc: ROLL WG
	> <http://www.gridmerge.com/> http://www.gridmerge.com <http://www.gridmerge.com/> 
	>
	>
	>
	>   <http://focus.ti.com/lit/an/swra048/swra048.pdf> http://focus.ti.com/lit/an/swra048/swra048.pdf
	>  868 - 868.6 MHz: <1%
	>
	> <https://www.ietf.org/mailman/listinfo/roll> https://www.ietf.org/mailman/listinfo/roll
	> <https://www.ietf.org/mailman/listinfo/roll> https://www.ietf.org/mailman/listinfo/roll
	>
	>
	>
	>
	>
	> list [email-masked] <https://www.ietf.org/mailman/listinfo/roll> https://www.ietf.org/mailman/listinfo/roll
	> <https://www.ietf.org/mailman/listinfo/roll> https://www.ietf.org/mailman/listinfo/roll
	_______________________________________________
	Roll mailing list
	<mailto:[email-masked]> [email-masked]
	<https://www.ietf.org/mailman/listinfo/roll> https://www.ietf.org/mailman/listinfo/roll

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 22 Mar 2010 09:35:17 -0700

I would be interested in hearing Mukul’s thoughts on this.  I did not read
his proposal to say that hop count is the only metric.   I would expect the
metric used for the DODAG(D,F) to be the OF “F” (whatever that happens to be
for the DODAG).

Don

From: Anders Brandt [mailto:[email-masked]] 
Sent: Monday, March 22, 2010 9:31 AM
To: Philip Levis; [email-masked]
Cc: Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted Humpal
Subject: SV: [Roll] P2P performance with current RPL proposal

Well, yes.

I really need to get my lamp turned on within seconds when my users press
the button.

The intention is not to skip all the nice DODAG DIO work that was done. It
serves a good purpose

in large networks.

The case is just that home & building have some tougher requirements within
restricted areas (<= 4 repeaters)
such as battery-friendly (i.e. short routes) and reactive discovery to
"guarantee" low response times always.

- Anders

  _____  

Fra: Philip Levis [mailto:[email-masked]]
Sendt: ma 22-03-2010 10:20
Til: [email-masked]
Cc: Anders Brandt; Mukul Goyal; Pascal Thubert (pthubert); ROLL WG; Ted
Humpal
Emne: Re: [Roll] P2P performance with current RPL proposal

Phil

Hi Anders and Mukul,

Don

- Anders

  _____  

Hi Pascal

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>, "robert

Hi Mukul

Cheers,

Pascal

can
for
repair.
root ID
we
earlier
for
another.
I-D.ietf-roll-home-
and
(1
(2nd
groups
this
every
other
in
I'm

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 22 Mar 2010 17:40:06 +0100

I guess you are right!

Fra: Don Sturek [mailto:[email-masked]]
Sendt: ma 22-03-2010 10:35
Til: Anders Brandt; 'Philip Levis'
Cc: 'Mukul Goyal'; 'Pascal Thubert (pthubert)'; 'ROLL WG'; 'Ted Humpal'
Emne: RE: [Roll] P2P performance with current RPL proposal

I would be interested in hearing Mukul's thoughts on this.  I did not read his proposal to say that hop count is the only metric.   I would expect the metric used for the DODAG(D,F) to be the OF "F" (whatever that happens to be for the DODAG).

Don

Well, yes.

in large networks.

- Anders

Phil

	Hi Anders and Mukul,

	Don

	- Anders

	Hi Pascal

	

	

	
	Thanks
	Mukul
	
	----- Original Message -----
	From: "Pascal Thubert (pthubert)" <[email-masked]>
	To: "Mukul Goyal" <[email-masked]>
	Cc: "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>, "robert cragie" <[email-masked]>
	Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central
	Subject: RE: [Roll] P2P performance with current RPL proposal
	
	Hi Mukul

	

	

	

	Cheers,
	
	Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 22 Mar 2010 12:15:49 -0500 (CDT)

No. As Don pointed out, the route selection is based on an object function desired by the node initiating the route discovery. The only thing based on hop count at this point is the scope of discovery - how far the DIS travels. I guess this also could be changed to a "discovery scope" function if desired.

Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "d sturek" <[email-masked]>
Cc: "Anders Brandt" <[email-masked]>, "Mukul Goyal" <[email-masked]>, "Pascal Thubert (pthubert)" <[email-masked]>, "ROLL WG" <[email-masked]>, "Ted Humpal" <[email-masked]>
Sent: Monday, March 22, 2010 11:20:46 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal

Phil 

On Mar 22, 2010, at 7:52 AM, "Don Sturek" < [email-masked] > wrote: 

Hi Anders and Mukul, 

Don 

  

  

- Anders 

Hi Pascal 

Thanks 
Mukul 

----- Original Message ----- 
From: "Pascal Thubert (pthubert)" < [email-masked] > 
To: "Mukul Goyal" < [email-masked] > 
Cc: "ROLL WG" < [email-masked] >, "Ted Humpal" < [email-masked] >, "robert cragie" < [email-masked] > 
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central 
Subject: RE: [Roll] P2P performance with current RPL proposal 

Hi Mukul 

Cheers, 

Pascal 

> From: "Pascal Thubert (pthubert)" < [email-masked] > 
> To: "robert cragie" < [email-masked] > 
> Cc: "ROLL WG" < [email-masked] >, "Ted Humpal" < [email-masked] > 
> From: Robert Cragie [ mailto:[email-masked] ] 
> Cc: [email-masked] ; ROLL WG 
> Kris Pister < [email-masked] > 
> 
> 
> To: 
> 
> Anders Brandt < [email-masked] > 
> 
> 
> Cc: 
> 
> ROLL WG < [email-masked] > 
> 
> 
> Date: 
> 
> 03/08/2010 01:45 PM 
> 
> 
> Subject: 
>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 22 Mar 2010 19:06:33 +0000

I think the idea of multiple DODAGs could work for P2P if it is possible 
to provide some sort of pruned DODAGs. I think the DIS mechanism below 
could work but I think using DIOs to me seems more orthogonal and symmetric.

I think the solution could be to use a 'targeted' DIO which can be 
emitted and propagated immediately. Consider A trying to communicate with B:

   1. A does not have a routing table entry for B
   2. A (now effectively a DODAG root) sends a DIO targeted at B to all
      routers multicast immediately (with jitter)
   3. If a router hears it and has a DODAG entry to B it can then be
      routed as normal to B
   4. If a router hears it and doesn't have a DODAG entry to B, it will
      propagate it all routers multicast (with a TTL) immediately (with
      jitter)
   5. When B hears the DIO, it responds with a DAO destined for A and
      sent back along the DODAG to A.
   6. Intermediate routers can set up the route to B if desired or A can
      use source routing.

Some points:

    * The standard DAG processing of rank relative to A using the OF
      would assure propagation of the targeted DIO away from A and
      formation of a DAG back to A
    * Routers which do not see the corresponding DAO would time out and
      discard the DODAG entry for A.

This would give the ability to create a 'pruned' DODAG thus giving the 
P2P needed without all routers having to set up DODAG entries back to A. 
As far as I can see, this stays pretty close to RPL but adds the idea of 
a DIO target and an alternative delivery mechanism as opposed to trickle 
timer (even then, it is really a subset of a trickle timer).

As always, I am sure there are still some other issues to consider.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

On 22/03/2010 5:15 PM, Mukul Goyal wrote:
> From: "Philip Levis"<[email-masked]>
> To: "d sturek"<[email-masked]>
> Cc: "Anders Brandt"<[email-masked]>, "Mukul Goyal"<[email-masked]>, "Pascal Thubert (pthubert)"<[email-masked]>, "ROLL WG"<[email-masked]>, "Ted Humpal"<[email-masked]>
> On Mar 22, 2010, at 7:52 AM, "Don Sturek"<  [email-masked]  >  wrote:
>
>
>
>
>
>
>
>
> Hi Anders and Mukul,
>
>   
>
> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Anders Brandt
> Fra:[email-masked]  på vegne af Mukul Goyal
> From: "Pascal Thubert (pthubert)"<  [email-masked]  >
> To: "Mukul Goyal"<  [email-masked]  >
> Cc: "ROLL WG"<  [email-masked]  >, "Ted Humpal"<  [email-masked]  >, "robert cragie"<  [email-masked]  >
>> From: "Pascal Thubert (pthubert)"<  [email-masked]  >
>> To: "robert cragie"<  [email-masked]  >
>> Cc: "ROLL WG"<  [email-masked]  >, "Ted Humpal"<  [email-masked]  >
>> From: Robert Cragie [mailto:[email-masked]  ]
>> Cc:[email-masked]  ; ROLL WG
>> From:[email-masked]  [mailto:[email-masked]  ] On Behalf Of
>> Robert Cragie
>> To:[email-masked]
>> Kris Pister<  [email-masked]  >
>>
>>
>> To:
>>
>> Anders Brandt<  [email-masked]  >
>>
>>
>> Cc:
>>
>> ROLL WG<  [email-masked]  >
>>
>>
>> Date:
>>
>> 03/08/2010 01:45 PM
>>
>>
>> Subject:
>>
>> [email-masked]  https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Mon, 22 Mar 2010 12:35:15 -0700

> No. As Don pointed out, the route selection is based on an object function desired by the node initiating the route discovery. The only thing based on hop count at this point is the scope of discov…

So then this assumes that the OF has a monotonically increasing (or increasing?) scalar value to "scope" the flood? Your prior message said

"(a) allowing multicast DIS messages to spread to an originator-specified number of hops and 
(b) allowing nodes to join a DAG temporarily and leave it if there is not sufficient “routing interest” in being part of the DAG."

Phil

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 22 Mar 2010 19:29:10 -0500 (CDT)

Yes, I am assuming that we can define a monotonically increasing scope function. A simple example is hop-count.

The two points you quoted are not currently there in RPL draft. The scheme I proposed is based on these points. So, these two points are the delta change we will need to add in the RPL draft to allow the formation of localized P2P-oriented DAGs.

Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "roll" <[email-masked]>
Sent: Monday, March 22, 2010 2:35:15 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal

Phil

---

From: Zach Shelby <[email-masked]>
Date: Mon, 22 Mar 2010 18:30:30 -0700

Hi Mukul,

This starts to sound promising! It would be great if you guys could write an I-D explaining how this would work, which could later be integrated into the rpl document. That makes it easier to evaluate and refine, and we can read it a whole lot faster than rpl-08 ;-)

Thanks,
Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Mar 2010 03:49:13 +0100

Hi Robert and Mukul:

We’ve been living with a disconnect for some time it appears.

My current understanding is that the DIS that Mukul proposes is a fine approach to relocate a DAG that the node used to belong to or wishes to belong to. It is more like a quick repair mechanism to ensure that the light comes up in a reasonable time than finding a path that’s better than the one the DAG provides. Mukul, is that correct?

The DIO that we are discussing here deals with what I’d call the really P2P problem, that is to create optimized routes within a set of  nodes within specific constraints that are not those of the main DAG, and we do that by creating a new DAG in a somewhat AODV fashion. RPL needs small additions to do that:

-          Enable ‘local’ instanceIDs so that the root endpoint can autoconf an instanceID for a DAG that it is the sole root.

-          Add ‘targets’ to the DIO

-          Enable a quick time out of DIO states when no DAO is seen

Some of this can be hidden in an so-far-unspecified  objective function, but I think we need to discuss the instance ID piece a bit more.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Monday, March 22, 2010 12:07 PM
To: Mukul Goyal
Cc: roll
Subject: Re: [Roll] P2P performance with current RPL proposal

I think the idea of multiple DODAGs could work for P2P if it is possible to provide some sort of pruned DODAGs. I think the DIS mechanism below could work but I think using DIOs to me seems more orthogonal and symmetric.

I think the solution could be to use a 'targeted' DIO which can be emitted and propagated immediately. Consider A trying to communicate with B:

1.	A does not have a routing table entry for B
2.	A (now effectively a DODAG root) sends a DIO targeted at B to all routers multicast immediately (with jitter)
3.	If a router hears it and has a DODAG entry to B it can then be routed as normal to B
4.	If a router hears it and doesn't have a DODAG entry to B, it will propagate it all routers multicast (with a TTL) immediately (with jitter)
5.	When B hears the DIO, it responds with a DAO destined for A and sent back along the DODAG to A.
6.	Intermediate routers can set up the route to B if desired or A can use source routing.

Some points:

*	The standard DAG processing of rank relative to A using the OF would assure propagation of the targeted DIO away from A and formation of a DAG back to A
*	Routers which do not see the corresponding DAO would time out and discard the DODAG entry for A.

This would give the ability to create a 'pruned' DODAG thus giving the P2P needed without all routers having to set up DODAG entries back to A. As far as I can see, this stays pretty close to RPL but adds the idea of a DIO target and an alternative delivery mechanism as opposed to trickle timer (even then, it is really a subset of a trickle timer).

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888

 
Thanks
Mukul
 
----- Original Message -----
From: "Philip Levis" <[email-masked]> <mailto:[email-masked]> 
To: "d sturek" <[email-masked]> <mailto:[email-masked]> 
Cc: "Anders Brandt" <[email-masked]> <mailto:[email-masked]> , "Mukul Goyal" <[email-masked]> <mailto:[email-masked]> , "Pascal Thubert (pthubert)" <[email-masked]> <mailto:[email-masked]> , "ROLL WG" <[email-masked]> <mailto:[email-masked]> , "Ted Humpal" <[email-masked]> <mailto:[email-masked]> 
Sent: Monday, March 22, 2010 11:20:46 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal

Phil 

 

Hi Anders and Mukul, 

 
Don 

 

 

  

  

- Anders 

 

Hi Pascal 

 

 

 
Thanks 
Mukul 
 
----- Original Message ----- 
From: "Pascal Thubert (pthubert)" < [email-masked] > 
To: "Mukul Goyal" < [email-masked] > 
Cc: "ROLL WG" < [email-masked] >, "Ted Humpal" < [email-masked] >, "robert cragie" < [email-masked] > 
Sent: Friday, March 19, 2010 11:20:58 AM GMT -06:00 US/Canada Central 
Subject: RE: [Roll] P2P performance with current RPL proposal 
 
Hi Mukul 

	 

 

 

 
Cheers, 
 
Pascal 

	----- Original Message ----- 
	From: "Pascal Thubert (pthubert)" < [email-masked] > 
	To: "robert cragie" < [email-masked] > 
	Cc: "ROLL WG" < [email-masked] >, "Ted Humpal" < [email-masked] > 
	Sent: Thursday, March 18, 2010 9:23:14 PM GMT -06:00 US/Canada Central 
	Subject: Re: [Roll] P2P performance with current RPL proposal 

	Hi Robert : 

	 

	 
	About your questions: 

	 

	 

	 
	 
	Pascal 

	 

	Hi Pascal, 

	 
	Robert 

	Gridmerge Ltd. 
	89 Greenfield Crescent, 
	Wakefield, WF4 4WA, UK 
	+44 (0) 1924 910888 
	http://www.gridmerge.com 

	 
	HI Robert : 

	 

	 

	 
	Pascal 

	 
	From: [email-masked] [ mailto:[email-masked] ] On Behalf Of 
	Robert Cragie 
	Sent: Thursday, March 11, 2010 2:43 PM 
	To: [email-masked] 
	Cc: ROLL WG 
	Subject: Re: [Roll] P2P performance with current RPL proposal 

	 
	 
	Robert 

	Gridmerge Ltd. 
	89 Greenfield Crescent, 
	Wakefield, WF4 4WA, UK 
	+44 (0) 1924 910888 
	http://www.gridmerge.com 

	 

	 

	 
	 
	Ted Humpal 

	 
	From: 

	To: 

	Cc: 

	Date: 
	 
	03/08/2010 01:45 PM 

	Subject: 

	 

	 
	 
	ksjp 
	 
	Anders Brandt wrote: 
	Hello 

	 

	 
	 
	Response time 
	============= 

	 

	 
	 
	Going forward 
	============= 

	 

	 

	 
	Thanks, 
	  Anders