Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation

From: Tim Winter <[email-masked]>
Date: Sat, 03 Apr 2010 13:09:05 -0400

WG,

>From Anaheim and the list it seems that there is support to proceed on RPL with
storing and non-storing modes of operation, and not to elaborate mixed mode operation
at this time (while allowing room for future specification of mixed mode).

The summary approach would be to signal the mode of operation through the DIO, that
all nodes MUST be capable to support a non-storing mode of operation, and that nodes
who are incapable of acting as routers in a storing mode may participate in the DODAG
as hosts (leaves).  (The suitable behavior when a routing table in a storing node
becomes saturated is still under consideration).

Would you please confirm this approach to the list?  Then we may proceed to refine
RPL accordingly for the next revision, -08, and to take this into account when
working the other tickets.

Thanks,

-Tim

roll issue tracker wrote:
> #26: Establishing downward routes in RPL : storing / non-storing / mixed modes
> of operation
> --------------------------------+-------------------------------------------
>  Reporter:  jpv@…               |       Owner:  wintert@…      
>      Type:  task                |      Status:  new            
>  Priority:  major               |   Milestone:                 
> Component:  rpl                 |     Version:                 
>  Severity:  Active WG Document  |    Keywords:                 
> --------------------------------+-------------------------------------------
>  In the RPL-07 proposal the DAO mechanism described in Section 6 attempts
>  to support
>  operation with a mix of storing nodes and non-storing nodes- where storing
>  nodes may
>  be provisioned with enough memory that they are capable to provision hop-
>  by-hop
>  downward routes learned from DAO messages, and non-storing nodes would
>  rely on source
>  routing for downward routes.  The present proposal describes operation in
>  a mixed
>  mode operation, with both storing and non-storing nodes, where each node
>  may
>  provision downward routing state as according to its capabilities and
>  largely
>  independent of its position in the LLN topology.
> 
>  It has been noted that operation in the case where all nodes (except
>  possibly the
>  root) are non-storing nodes allows for certain optimizations, and that the
>  case where
>  all nodes (except possibly leaves) are storing leads to other
>  optimizations.  It has
>  also been noted that in the mixed cases the ability to provide an optimal
>  solution
>  may break down.  In particular there are concerns about the complexity and
>  correctness of mixed-mode operation as proposed by RPL-07.
> 
>  With this in mind, should RPL allow for operation in a mixture of storing
>  /non-storing
>  nodes?  Or should each RPL Instance be exclusively operating in either
>  storing or
>  non-storing mode (with the provision that operation as a leaf is always an
>  option)?
>  (The non-mixed case may imply some control flag or equivalent given in the
>  DIO to
>  signal the mode of operation).
> 
>  Tim Winter.
>

---

From: Philip Levis <[email-masked]>
Date: Sat, 3 Apr 2010 11:11:56 -0700

> working the other tickets.

+1

Phil

---

From: "Don Sturek" <[email-masked]>
Date: Sat, 3 Apr 2010 16:23:31 -0700

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Winter
Sent: Saturday, April 03, 2010 10:09 AM
To: [email-masked]
Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL : storing / non-storing / mixed modes of operation

WG,

Thanks,

-Tim

> #26: Establishing downward routes in RPL : storing / non-storing / mixed modes
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 4 Apr 2010 20:57:35 +0200

Me 2 :)

Pascal

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Philip Levis
> Sent: Saturday, April 03, 2010 8:12 PM
> To: Tim Winter
> Cc: [email-masked]
> Subject: Re: [Roll] [roll] #26: Establishing downward routes in RPL
:storing /
> non-storing / mixed modes of operation
> 
> 
> > From Anaheim and the list it seems that there is support to proceed
on
> > RPL with storing and non-storing modes of operation, and not to
> > elaborate mixed mode operation at this time (while allowing room for
> future specification of mixed mode).
> >
> > The summary approach would be to signal the mode of operation
through
> > the DIO, that all nodes MUST be capable to support a non-storing
mode
> > of operation, and that nodes who are incapable of acting as routers
in
> > a storing mode may participate in the DODAG as hosts (leaves).  (The
> > suitable behavior when a routing table in a storing node becomes
saturated
> is still under consideration).
> >
> > Would you please confirm this approach to the list?  Then we may
> > proceed to refine RPL accordingly for the next revision, -08, and to
> > take this into account when working the other tickets.
> 
> +1
> 
> Phil

---

From: Phoebus Chen <[email-masked]>
Date: Sun, 04 Apr 2010 22:49:30 +0200

+1

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus

---

From: Robert Cragie <[email-masked]>
Date: Mon, 05 Apr 2010 12:05:12 +0100

+1

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/>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 5 Apr 2010 07:51:20 -0700

+1

--
Jonathan Hui

On Apr 3, 2010, at 10:09 AM, Tim Winter wrote:

> on RPL with
> through the DIO, that
> proceed to refine
>> -------------------------------- 
>> +-------------------------------------------
>> -------------------------------- 
>> +-------------------------------------------

---

From: Tzeta Tsao <[email-masked]>
Date: Mon, 05 Apr 2010 11:03:32 -0400

+1

---

From: [email-masked]
Date: Mon, 5 Apr 2010 10:09:37 -0500

Hi Tim,

Interspersed "storing" nodes
were added (I believe) in RPL-2 as a means to placate us P2P folks with
some means to move a packet laterally across a DAG efficiently.  Now
we're looking at dropping this concept with no solid replacement defined.
Going back to "non-storing' nodes moves us back to pre-RPL2
levels.  Adding state to all nodes likely will saturate state tables.

I don't think we should drop interspersed
storing nodes until we have a solid P2P replacement strategy.

Jerry

From:

Tim Winter <[email-masked]>

To:

[email-masked]

Date:

04/03/2010 12:09 PM

Subject:

Re: [Roll] [roll] #26: Establishing
downward routes in RPL : storing / non-storing / mixed modes of operation

WG,

>From Anaheim and the list it seems that there is support to proceed on
RPL with

storing and non-storing modes of operation, and not to elaborate mixed
mode operation

The summary approach would be to signal the mode of operation through the
DIO, that

all nodes MUST be capable to support a non-storing mode of operation, and
that nodes

who are incapable of acting as routers in a storing mode may participate
in the DODAG

as hosts (leaves).  (The suitable behavior when a routing table in
a storing node

Would you please confirm this approach to the list?  Then we may proceed
to refine

RPL accordingly for the next revision, -08, and to take this into account
when

Thanks,

-Tim

>      Type:  task
|      Status:  new

> Component:  rpl

Roll mailing list

[email-masked]

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 5 Apr 2010 08:20:40 -0700

Hi Jerry,

Within the RPL WG document, the intent to support mixed-mode has been  
there since the beginning in rpl-00.  The issue here is whether or not  
we are going to address piecewise source routing and the necessary  
mechanisms to build up distributed state for piecewise source routes  
at this time.

Separate is the issue of allowing anode to store its own source routes  
for packets that it sources.  This is different from piecewise source  
routing where an intermediate node may need to remove an existing  
source route header and replace it with a new one.  I don't think  
there is any objection for a node to store its own source route for  
packets that it sources at this time.

So do you really need piecewise source routing?  Or is some form of  
source routing good enough?

--
Jonathan Hui

On Apr 5, 2010, at 8:09 AM, [email-masked] wrote:

>
> Hi Tim,
>
> Interspersed "storing" nodes were added (I believe) in RPL-2 as a  
> means to placate us P2P folks with some means to move a packet  
> laterally across a DAG efficiently.  Now we're looking at dropping  
> this concept with no solid replacement defined.  Going back to "non- 
> storing' nodes moves us back to pre-RPL2 levels.  Adding state to  
> all nodes likely will saturate state tables.
>
> I don't think we should drop interspersed storing nodes until we  
> have a solid P2P replacement strategy.
>
> Jerry
>
>
>
>
> From:
> Re: [Roll] [roll] #26: Establishing downward routes in RPL :  
> storing / non-storing / mixed modes of operation
>
>
>
>
> WG,
>

---

From: [email-masked]
Date: Mon, 5 Apr 2010 10:43:54 -0500

Jonathan,

Good point.  To me piecewise source
routing is an implementation decision.  While it may be more efficient,
as was noted in Anaheim, it's way more complex.

I'm satisfied for your alternate proposal
that allows a node optionally to keep route info.  I didn't think
that's what Tim was asking us to vote on.  I thought the vote was
all or nothing.

To try and be clear, I would like to
see 'non-storing' nodes except for the LBR which MUST keep downward paths
to all nodes in the DAG.  Other nodes could then optionally keep state
as needed other nodes of interest.

Jerry

From:

Jonathan Hui <[email-masked]>

To:

[email-masked]

Cc:

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

Date:

04/05/2010 10:20 AM

Subject:

Hi Jerry,

there since the beginning in rpl-00.  The issue here is whether or
not

at this time.

--

Jonathan Hui

On Apr 5, 2010, at 8:09 AM, [email-masked] wrote:

> storing and non-storing modes of operation, and not to elaborate

> mixed mode operation

> at this time (while allowing room for future specification of mixed

> mode).

> all nodes MUST be capable to support a non-storing mode of

> operation, and that nodes

> who are incapable of acting as routers in a storing mode may

> participate in the DODAG

> as hosts (leaves).  (The suitable behavior when a routing table
in a

> storing node

> RPL accordingly for the next revision, -08, and to take this into

> account when

> > #26: Establishing downward routes in RPL : storing / non-storing
/

> mixed modes

|      Status:  new

> >  In the RPL-07 proposal the DAO mechanism described in Section
6

> attempts

> >  operation with a mix of storing nodes and non-storing nodes-

> where storing

> >  be provisioned with enough memory that they are capable
to

> provision hop-

> >  downward routes learned from DAO messages, and non-storing
nodes

> would

> >  routing for downward routes.  The present proposal
describes

> operation in

> >  mode operation, with both storing and non-storing nodes,
where

> each node

> >  provision downward routing state as according to its capabilities

> and

> >  It has been noted that operation in the case where all
nodes

> (except

> >  root) are non-storing nodes allows for certain optimizations,
and

> that the

> >  also been noted that in the mixed cases the ability to
provide an

> optimal

> >  may break down.  In particular there are concerns
about the

> complexity and

> >  With this in mind, should RPL allow for operation in a
mixture of

> storing

> >  nodes?  Or should each RPL Instance be exclusively
operating in

> either

> >  non-storing mode (with the provision that operation as
a leaf is

> always an

> >  (The non-mixed case may imply some control flag or equivalent

> given in the

---

From: Roger Alexander <[email-masked]>
Date: Tue, 6 Apr 2010 08:01:24 -0400

+1

Roger

---

From: Kris Pister <[email-masked]>
Date: Wed, 07 Apr 2010 13:45:46 -0700

+1

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2010 19:02:20 -0400

>>>>> "Tim" == Tim Winter <[email-masked]> writes:
    Tim> From Anaheim and the list it seems that there is support to
    Tim> proceed on RPL with storing and non-storing modes of operation,
    Tim> and not to elaborate mixed mode operation at this time (while
    Tim> allowing room for future specification of mixed mode). 

    Tim> The summary approach would be to signal the mode of operation
    Tim> through the DIO, that all nodes MUST be capable to support a
    Tim> non-storing mode of operation, and that nodes who are incapable
    Tim> of acting as routers in a storing mode may participate in the
    Tim> DODAG as hosts (leaves).  (The suitable behavior when a routing
    Tim> table in a storing node becomes saturated is still under
    Tim> consideration). 

Tim, 

My instinct is that dealing properly with this saturation issue likely
returns us to the mixed-mode operation.   As such, the only interim
solution I see is to declare solving the problem of saturation
out-of-scope. i.e: 

Patient: "Doctor, Doctor, it hurts when I fill up my routing table!"
Doctor:  "well, then don't do that."

Having said that, I would like us to declare a standard response for what
happens when the node is full:
        1) ignore subsequent additions (early bird wins)
        2) drop oldest additions (newest info wins)
        3) drop all contents, and become a leaf (become non-storing)

My goal in having a standard response is so that, in event that the
network is mis-provisioned, that it reacts in a predictable way.  I
suspect that #1 is the best, but I think the modelers should have a go
at this.

    Tim> Would you please confirm this approach to the list?  Then we
    Tim> may proceed to refine RPL accordingly for the next revision,
    Tim> -08, and to take this into account when working the other
    Tim> tickets.

+1

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.