Subject: [Roll] Next items ...

From: JP Vasseur <[email-masked]>
Date: Mon, 3 Aug 2009 09:26:34 +0200

Dear all,

As a reminder, RPL being a WG ID, it now "belongs" to the WG.

Several working items have been listed but before starting to address  
all open items in some unstructured way, I would like to propose the  
following.

It clearly appeared that there were some misunderstandings on how RPL  
works. The DT did an outstanding job but I also understand that  
several areas must be clarified. So before changing RPL, adding new  
mechanisms (e.g. to optimize P2P, support source routing, loop  
detection, ... ), I would first want you to list your questions on the  
mailing list on each area for which you would like to get  
clarification. This will help make sure that everybody is indeed on  
the same page.

 From there, we will continue to quickly move forward, I will track  
the list of open items via the issue tracker.

Many Thanks.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 03 Aug 2009 11:06:25 +0200

JP,

Thank you for requesting questions.

I would like to get clarification on the IPv6 addressing architecture 
and subnet structure considered in RPL.

-is it the AUTOCONF addressing model?
-is it the 6LoWPAN route over or mesh-under?

-how many physical interfaces does a node have?
-if a node has several interfaces then does it have only one physical
  interface?

-what is the default route behaviour?  Does each node have default
  route?

-are there IPv6 prefix subnets /64?

Here is a DAG excerpt from 01 draft:

                   (A)
                    |\
                    | `-----.
                    |        \
                   (B)        \
                     \        |
                      `-----. |
                             \|
                             (C)

Does that mean the IPv6 addressing arechitecture is this:

                   (A)
                    |\
    2001:db8:1::/64 | `-----.
                    |        \  2001:db8:2::/64
                   (B)        \
                     \        |
                      `-----. |
         2001:db8:3::/64     \|
                             (C)

?

Thanks for clarification,

Alex

JP Vasseur a écrit :
> works. The DT did an outstanding job but I also understand that several 
> areas must be clarified. So before changing RPL, adding new mechanisms 
> (e.g. to optimize P2P, support source routing, loop detection, ... ), I 
> would first want you to list your questions on the mailing list on each 
> area for which you would like to get clarification. This will help make 
> sure that everybody is indeed on the same page.
> 
>  From there, we will continue to quickly move forward, I will track the 
> list of open items via the issue tracker.
> 
> Many Thanks.
> 
> JP.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 3 Aug 2009 04:23:06 -0700

Hi JP,

Here are some points that I would like to see the design team clarify with
respect to the current RPL draft:
1)  P2P support
	a.    I believe the P2P feature uses Destination Address
advertisements from the device wishing to receive P2P traffic:
		i.    What are the requirements for the receiving device
advertising via Destination Address Advertisements assuming it is not the
DAG-root (eg, What is the rate of Destination Address advertisements, How
does the device (or does it/can it) notify devices of lower rank/depth that
it has detached from the DAG).   If there is no mechanism for the receiving
device to notify devices of lower rank/depth it if detaches, how is
maintenance of the Destination Address advertisement caching within the DAG
performed.
		ii.   What are the requirements for devices with lower
rank/depth in the same DAG when receiving a Destination Address
advertisement (eg, does it store the Destination Address advertisements of
its children, Does it further re-propagate the Destination Address
advertisements to devices of lower rank/depth, How long should devices of
lower rank/depth store these destination address advertisements)
	b.    Routing of P2P traffic
		i.     I assume that the DAG-root holds the address of all
Destination Address Advertisements it has received from devices in its DAG.
Is this true?
		ii.    I assume that other devices in the DAG of higher
rank/depth from the DAG-root but still lower in rank than the final
destination routes packets down the DAG.  It seems possible for the
destination to receive multiple copies (is this correct) and more
importantly it also seems possible for an Unreachable notification to be
generated by some device in the DAG when in fact the packet reached its
destination through another path (did I read the proposal wrong?)
	c.    Sibling routing seems to be not supported (though I saw
discussion of this on the reflector).  It seems problematic to have Siblings
processing Destination Address advertisements within the same DAG.  We
should leave this out of the clarification if my reading is correct and only
add it back as part of support for optimized P2P if that is where the
optimization leads.

I also have some questions on the freezing of DAGs and ungrounded DAGs but I
think that is a separate issue and I will put out a note later in the week
on this.

Thanks,

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: Monday, August 03, 2009 12:27 AM
To: ROLL WG
Subject: [Roll] Next items ...

Dear all,

Many Thanks.

JP.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 3 Aug 2009 13:47:39 +0200

Hi JP, DT,

I would personally want to see more discussion on 3 topics where I'm still not fully convinced:

[SIBLINGS] The role of siblings: this adds quite some extra complexity to the routing but what does it really bring in practice? Should siblings be part of the foundation layer? My opinion is no.

[METRICS] If the choice of possible metrics is specified in the metric draft, why not impose the right conditions on these metrics so that we can base the DAG construction and the loop avoidance on a single metric rather than have a separate hop count or depth?

[TIMERS] Interaction between timers: I'm thinking in particular of the interaction of the RA timers and the DAG hop timers. In the loop avoidance example given by Jonathan during the IETF meeting can we guarantee the right sequencing of RA / DAG Hop timer firing?

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP Vasseur (jvasseur)
Sent: lundi, 3. août 2009 09:27
To: ROLL WG
Subject: [Roll] Next items ...

Dear all,

Several working items have been listed but before starting to address all open items in some unstructured way, I would like to propose the following.

It clearly appeared that there were some misunderstandings on how RPL works. The DT did an outstanding job but I also understand that several areas must be clarified. So before changing RPL, adding new mechanisms (e.g. to optimize P2P, support source routing, loop detection, ... ), I would first want you to list your questions on the mailing list on each area for which you would like to get clarification. This will help make sure that everybody is indeed on the same page.

 From there, we will continue to quickly move forward, I will track the list of open items via the issue tracker.

Many Thanks.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Aug 2009 15:04:51 +0200

Hi Don

>it has detached from the DAG).   If there is no mechanism for the
receiving

A DAO of lifetime 0 is used to indicate that the reachability is lost
(5.4.1.1).
If the Node has a chance to leave gracefully, it could send that about
itself. 
I trust that the most common case is timing out a child though.

>lower rank/depth store these destination address advertisement

The idea is that the no-DAO (lifetime 0) are propagated immediately and
unreliably.
This another instance where a loop is easily created and thus requires
detection.
This is a case where CTP's approach to loop detection would be enough.

s)
>Destination Address Advertisements it has received from devices in its
DAG.

If DAO is used at all that would be true. I suspect that this is
something that should circulate in DIO.
Our approach to autonomicity is that a lot of the config applies for a
whole DAG and is pushed by the root in DIO.

>destination through another path (did I read the proposal wrong?)

The no-DOA should be absorbed by a parent that still has an alternate
solution.
I'm not sure I get/answer what you really mean here?

>add it back as part of support for optimized P2P if that is where the

Right. No sibling DAO at the moment. You go through parents.

We need to multicast the DAO about connected routes (owned prefix) to
enable line of sight connectivity.
That's at the beginning of the list of stuff we look at to improve P2P.
I think we is now the whole WG...

We need a inter-sibling routing protocol to enable what I called
boulevard routing aka beltlines. The idea would be to redistribute DAOs
into beltlines but not beltlines into DAOs, so you'd learn a prefix
through either but not both, effectively offloading the core of the mesh
near the sink like belts and boulevards do around cities.

That's a bit deeper in the list :)

Cheers,

Pascal

---

From: [email-masked]
Date: Mon, 3 Aug 2009 13:09:19 -0500

I would like the following questions answered on subsequent revisions of 
the draft:

a) What is the roll of 'siblings'?  They are in the current RPL document, 
yet seem to be demoted from parental links.  As I read the draft, one 
cannot use a sibling link unless the parental links are exhausted.  The 
nodes don't seem to explicitly define sibling links. 

b) What is the plan on communication to devices within direct radio range? 
 As I read the draft unless a node is made a 'parent', or possibly a 
'sibling' it cannot be communicated with.  However, Anand mentions in his 
memo that at the Stockholm meeting there was discussion on directly 
connected devices.  Unfortunately, I couldn't attend the meeting.

c) What are the approximate timer values for RPL?  The document gives no 
indication as to these timers, hence I can't calculate how long a floating 
DAG may be dislodged from its network.  In a real-time facility management 
control system, all nodes are monitored for falling off-line.  If the 
convergence time is too long (more than 1 minute), the devices will be 
flagged off-line and reported to the customer.

d) What is the plan for security?  RPL doesn't currently weigh in on the 
topic.  Are security policies optional or mandatory?  Must the policy be 
consistent with the rest of the enterprise's IT security on other parts of 
the network?  Will security require nodes to keep state info as Rene 
suggests?

e) What requirements from the 4 requirement drafts are being considered? 
When the DT first was engaged, it said it would publish the list of 
requirements as an appendix and note if the current draft supported which 
requirement.  This hasn't occurred and may be adding to the email angst. 
As a requirement's author, I would rather know up front that some of my 
MUST requirements are not being considered.

f) What is the expected frame overhead size based on all the above 
criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation, 
UDP/TCP.  We need to add in the encryption and authentication overhead; 
and now maybe source routing.  I realize ROLL is trying to be agnostic to 
L2, however in practice 802.15.4 is the only game in town.  It only 
carries a 128 by packet size.  The DT/WG should at least give an 
accounting of the expected frame overhead so we can determine what L2s are 
feasible for the protocol.

g) What routing data must persist a warmstart/coldstart?  The overhead to 
establish a DAG is significant.  We should consider what data might be 
able to transcend a network reboot to minimize communication startup 
bottlenecks.

As Pascal has noted in previous emails, some of these issues may be 
considered out-of bounds for the protocol and should be an implementation 
decision.  That may indeed be true, but RPL should state its case 
explicitly.  In the Building Market, it is multi-disciplined (HVAC, Fire, 
Lighting) and multi-vendor.  Unless some higher authority prescribes 
operation, the chances of LLN node-to-node interoperability are moot.

Thanks,

Jerry

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
08/03/2009 02:27 AM

To
ROLL WG <[email-masked]>
cc

Subject
[Roll] Next items ...

Dear all,

Many Thanks.

JP.

---

From: Tim Winter <[email-masked]>
Date: Mon, 03 Aug 2009 20:50:49 -0400

Hi Jerry,

I have a few supplemental points to your questions inline:

[email-masked] wrote:
> a) What is the roll of 'siblings'?  They are in the current RPL
> document, yet seem to be demoted from parental links.  As I read the
> draft, one cannot use a sibling link unless the parental links are
> exhausted.  The nodes don't seem to explicitly define sibling links.  
> 
> b) What is the plan on communication to devices within direct radio
> range?  As I read the draft unless a node is made a 'parent', or
> possibly a 'sibling' it cannot be communicated with.  However, Anand
> mentions in his memo that at the Stockholm meeting there was discussion
> on directly connected devices.  Unfortunately, I couldn't attend the
> meeting.
> 
> indication as to these timers, hence I can't calculate how long a
> floating DAG may be dislodged from its network.  In a real-time facility
> management control system, all nodes are monitored for falling off-line.
>  If the convergence time is too long (more than 1 minute), the devices
> will be flagged off-line and reported to the customer.
In general the suggestion is that parameterization of RPL should occur in
application-specific applicability statements.  So the RPL specification
might not end up including specific numbers, but a Building Applicability
Statement may give an implementer further guidance in how to setup timers,
etc. in order that RPL can be operated in a manner to meet the requirements
of that application domain.  The applicability statements can help to bridge
the gap between the protocol specification and the implementation.
Also, in the current proposal some precedence is given to communicate key
parameters (e.g. DAGDelay) in the DIO- so some flexibility could be given
even within an implementation if the WG believes it to be desirable.

> consistent with the rest of the enterprise's IT security on other parts
> of the network?  Will security require nodes to keep state info as Rene
> suggests?
> 
> requirements as an appendix and note if the current draft supported
> which requirement.  This hasn't occurred and may be adding to the email
> angst.  As a requirement's author, I would rather know up front that
> some of my MUST requirements are not being considered.
All requirements.  Here is the list that the DT worked with as extracted
from the drafts:
http://www.ietf.org/mail-archive/web/roll/current/msg01291.html
The intention is not to re-declare the requirements in an appendix of RPL-
the requirements drafts give a lot better background/context in presenting
the requirements.  Instead, the suggestion is that at the end of this
process, if we (WG) find that any requirement is lacking in the final
version of the protocol, we should then clearly document such and why in the
appendix.  As the WG takes up the process of further developing RPL I do
hope that you, other requirements authors, and any other interested parties
do make the WG aware if a requirement is in jeopardy of not being satisfied
(and helping to work out the alternatives ;)  ).

> and now maybe source routing.  I realize ROLL is trying to be agnostic
> to L2, however in practice 802.15.4 is the only game in town.  It only
> accounting of the expected frame overhead so we can determine what L2s
> are feasible for the protocol.
> 
> g) What routing data must persist a warmstart/coldstart?  The overhead
> to establish a DAG is significant.  We should consider what data might
> be able to transcend a network reboot to minimize communication startup
> bottlenecks.
> 
> considered out-of bounds for the protocol and should be an
> implementation decision.  That may indeed be true, but RPL should state
> its case explicitly.  In the Building Market, it is multi-disciplined
> (HVAC, Fire, Lighting) and multi-vendor.  Unless some higher authority
> prescribes operation, the chances of LLN node-to-node interoperability
> are moot.
> 
> Thanks,
> 
> Jerry
> 
> 
> 
> 
> *JP Vasseur <[email-masked]>*
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Tue, 4 Aug 2009 09:02:16 -0500

Thanks Tim.

I realize that setting timer values is the province of the application in 
the long run.  However, I was trying to look into the DTs head as to what 
it thinks the timer values should be.  If we select 802.15.4 as the radio 
technology, it has certain preordained parameters (e.g. 250kbps. 128 byte 
packets, CSMA-CA backoffs) that at least sets the lower bound as to how 
fast convergence can happen.  I would think we would want to at least 
understand the unstability of an LLN and the convergence time if a high 
ranked node in the DAG decides to reposition itself.  I am not too worried 
about that breakaway node itself as much as all its sub-DAG nodes that are 
affected by the move. 

Tim Winter <[email-masked]> 
08/03/2009 07:51 PM

To
[email-masked]
cc
ROLL WG <[email-masked]>
Subject
Re: [Roll] Next items ...

Hi Jerry,

etc. in order that RPL can be operated in a manner to meet the 
requirements
of that application domain.  The applicability statements can help to 
bridge

All requirements.  Here is the list that the DT worked with as extracted
from the drafts:
http://www.ietf.org/mail-archive/web/roll/current/msg01291.html
The intention is not to re-declare the requirements in an appendix of RPL-
the requirements drafts give a lot better background/context in presenting
the requirements.  Instead, the suggestion is that at the end of this
process, if we (WG) find that any requirement is lacking in the final
version of the protocol, we should then clearly document such and why in 
the
appendix.  As the WG takes up the process of further developing RPL I do
hope that you, other requirements authors, and any other interested 
parties
do make the WG aware if a requirement is in jeopardy of not being 
satisfied
(and helping to work out the alternatives ;)  ).