Subject: [Roll] P2P route discovery: "Good enough" criteria

From: Mukul Goyal <[email-masked]>
Date: Sat, 19 Jun 2010 09:19:32 -0500 (CDT)

Here is some text from the Introduction section of draft-dt-roll-p2p-rpl-01:

The specified scheme is based on a reactive on-demand approach, which
   enables a router to discover one or more "good-enough" routes in
   either direction between itself and another router in the LLN without
   any constraints regarding the existing DAG-membership of the links
   that such routes may use.  

JP commented:
JP> This will be an aspect triggering some discussion. How "good" is"good enough" ? You will need some text to elaborate here or point to another section explaining what is meant by "good enough"

I think there needs to be an Applicability section in the draft that talks about how and when the P2P route discovery might be invoked. Such a section will be added in the next version of the draft.

Basically, the idea is that the origin router will first measure the cost of the DAG-based route to/from the target router (using the Measurement Request and Measurement Reply messages that were part of the 00 version of the draft and would now be proposed in a separate draft).

Once the origin router knows the cost of the DAG-based route, it can choose the good enough criteria for the P2P routes it wants to discover. This criteria can be specified as contraints in the Metric Container associated with Route Discovery option.

In case, the origin and target routers are not connected via a DAG or the cost measurement of the DAG-based route fails, the origin router will have to guess the good enough criteria. Once, the initial route discovery succeeds or fails, the origin router will have a better idea of how to set the good enough criteria.

Comments?

Thanks
Mukul

---

From: [email-masked]
Date: Mon, 21 Jun 2010 08:48:52 -0500

A few comments.

First, I would like the text to read
...

The specified scheme is based on a reactive on-demand
approach, which

enables a router or
host to discover one or more "good-enough"
routes in

either direction between itself and another router or
host in the LLN without

I think reactive discoveries have to
be cognizant of 'hosts'.  In the commercial building world a router
(building controller) will likely be initiating a route discovery, but
most often it will be trying to find a host (sensor).  We need to
make sure route discoveries work from router/hosts to/from router/hosts.

Most often, discoveries will only be
necessary after first trying the DAG-based route.  As you say, we
will first determine the latency through the DAG.  Depending on the
application performance requirements, we may then define a P2P reactive
route instead.  We will always check if the destination node is a
neighbor of the source since in many cases the source and destination nodes
are within 10 meters and should be within radio range.

Jerry

From:

Mukul Goyal <[email-masked]>

To:

roll <[email-masked]>

Date:

06/19/2010 09:19 AM

Subject:

[Roll] P2P route discovery: "Good
enough" criteria

Here is some text from the Introduction section of
draft-dt-roll-p2p-rpl-01:

enables a router to discover one or more "good-enough"
routes in

JP commented:

JP> This will be an aspect triggering some discussion. How "good"
is"good enough" ? You will need some text to elaborate here or
point to another section explaining what is meant by "good enough"

I think there needs to be an Applicability section in the draft that talks
about how and when the P2P route discovery might be invoked. Such a section
will be added in the next version of the draft.

Basically, the idea is that the origin router will first measure the cost
of the DAG-based route to/from the target router (using the Measurement
Request and Measurement Reply messages that were part of the 00 version
of the draft and would now be proposed in a separate draft).

Once the origin router knows the cost of the DAG-based route, it can choose
the good enough criteria for the P2P routes it wants to discover. This
criteria can be specified as contraints in the Metric Container associated
with Route Discovery option.

In case, the origin and target routers are not connected via a DAG or the
cost measurement of the DAG-based route fails, the origin router will have
to guess the good enough criteria. Once, the initial route discovery succeeds
or fails, the origin router will have a better idea of how to set the good
enough criteria.

Comments?

Thanks

Mukul

_______________________________________________

Roll mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/roll

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 21 Jun 2010 10:28:42 -0400

> From: [email-masked]
> Date: Mon, 21 Jun 2010 08:48:52 -0500
> 
> I think reactive discoveries have to be cognizant of
> 'hosts'.  In the commercial building world a router
> (building controller) will likely be initiating a route
> discovery, but most often it will be trying to find a host
> (sensor).  We need to make sure route discoveries work
> from router/hosts to/from router/hosts.

Route discovery to a host should work just fine, as
neighboring routers can respond on behalf of the host.

I am not sure that route discovery from a host would
work.  How could a host initiate discovery without
acting as a router?

                        -Richard Kelsey

---

From: [email-masked]
Date: Mon, 21 Jun 2010 09:35:59 -0500

Hi Richard,

Like you, I was assuming a router would act as a proxy for the initiating
host.  Maybe it's as simple as routers always proxying for hosts.

However, maybe I missed it, but do routers
even know who its hosts are?  In DAGs, children know about parents,
but do parents know about children?  What message is used to establish
this link?  Since hosts are not part of the DAG, I wouldn't think
they would sent out DAOs.

Thanks,

Jerry

From:

Richard Kelsey <[email-masked]>

To:

[email-masked]

Cc:

[email-masked], [email-masked], [email-masked]

Date:

06/21/2010 09:24 AM

Subject:

Re: [Roll] P2P route discovery: "Good
enough" criteria

acting as a router?

-Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 21 Jun 2010 11:29:26 -0400

> Date: Mon, 21 Jun 2010 09:35:59 -0500
> 
> Like you, I was assuming a router would act as a proxy for the
> initiating host.  Maybe it's as simple as routers always proxying for
> hosts.

Jerry,

A router can act as a proxy for a host that is the goal of a
route discovery, just as it acts as a proxy for other
routing to the host.

I do not see how a router can act as a proxy for a host that
wants to initiate a route discovery.

> However, maybe I missed it, but do routers even know who its hosts
> are?  In DAGs, children know about parents, but do parents know about
> children?  What message is used to establish this link?  Since hosts
> are not part of the DAG, I wouldn't think they would sent out DAOs.

Hosts do not necessarily participate in RPL.  Routers find
out about non-RPL-participating neighboring hosts via ND.

As for hosts that do participate in RPL, I am not clear on
exactly what they must and must not do.  Perhaps there
should be a separate 'hosts' section that spells out the
requirements and options for host behavior.  I know that
I am not the only confused about this.

                                  -Richard Kelsey

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 Jun 2010 20:11:28 +0200

> I am not the only confused about this.

Let me try to shed some light (hopefully that will help). In the  
context of RPL
(or any other routing protocol), nodes participating to the routing  
domain
could either be hosts (device that do not "route" packet) or routers.
This is no different than for other routing protocols: a unix station  
can run
ISIS or OSPF too, without acting as a router.

Here we do define a routing protocol. Devices such as host and routers  
can
participate to the routing domain.

Now if a device does not run RPL and still requires to get routing
information, this is outside of our scope (proxy function, ND, ...).

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 Jun 2010 20:14:18 +0200

On Jun 19, 2010, at 4:19 PM, Mukul Goyal wrote:

> is"good enough" ? You will need some text to elaborate here or point  
> to another section explaining what is meant by "good enough"
>
> I think there needs to be an Applicability section in the draft that  
> talks about how and when the P2P route discovery might be invoked.  
> Such a section will be added in the next version of the draft.
>
> Basically, the idea is that the origin router will first measure the  
> cost of the DAG-based route to/from the target router (using the  
> Measurement Request and Measurement Reply messages that were part of  
> the 00 version of the draft and would now be proposed in a separate  
> draft).
>
> Once the origin router knows the cost of the DAG-based route, it can  
> choose the good enough criteria for the P2P routes it wants to  
> discover. This criteria can be specified as contraints in the Metric  
> Container associated with Route Discovery option.
>
> In case, the origin and target routers are not connected via a DAG  
> or the cost measurement of the DAG-based route fails, the origin  
> router will have to guess the good enough criteria. Once, the  
> initial route discovery succeeds or fails, the origin router will  
> have a better idea of how to set the good enough criteria.
>

That does make sense. One slight comment though in the spirit of the  
text that I had proposed. It is clearly important to describe the  
several required steps though, especially in the context of  
constrained networks. Having to first determine the path quality,  
guess the good enough criteria and then potentially run a reactive on- 
demand routing protocol has some cost (for a gain that is not known a  
priori). I am not saying that this is not worth it, but in that  
particular, context it must be spelled out in the document itself.

Thanks

JP.

---

From: [email-masked]
Date: Wed, 23 Jun 2010 16:35:31 -0500

Hi JP,

I'm not sure we can let ROLL off the
hook on access to/from hosts simply by saying it's out of scope.

In most cases the sensors (hosts) will
likely be sleepers and hence will not be aware of the periodic DIOs and
needed DAG maintenance requirements.  Due to latency and power constraints,
we cannot expect these sleepers to be DAG aware and regain routing state
each time they awake.  Hence, they seem like they will most likely
be non-RPL oriented hosts.

Yet, they clearly need to submit packets
onto the RPL DAG and in some cases be targeted devices to receive packets
from other nodes on the LLN and even nodes off the LLN network.  As
Richard points out below, a host wanting to submit a packet onto an RPL
LLN could use ND to find its neighbors.  However, since ND is not
RPL based, the host has no idea if the device he's sending the packet to
is a router and is even capable of forwarding the packet.  Furthermore
there may be multiple routers within radio range, which one should it deliver
the packet?

Conversely, if I have a non-RPL host
is a target for a received packet, how do the routers find a route to the
host?  The host doesn't 'DAO' since it is RPL unaware.  Yet,
the host has an IPv6 address and packets should be routerable to it.
They sure can be routed to any host on any other type of IP network.

I have posed the need for clearly defining
sleeping host devices access to/from the RPL network since the first draft
of the Building Requirements RFC.  I'm confused.  It sounds like
Richard is also confused.  I think ROLL needs to explicitly state
its position on host access in the RPL draft.  Even if you want to
state that it is out of scope (which I hope you don't) , I still think
the draft needs to explicitly state it.

Jerry

From:

JP Vasseur <[email-masked]>

To:

Cc:

[email-masked], [email-masked]

Date:

06/23/2010 03:18 PM

Subject:

context of RPL

domain

could either be hosts (device that do not "route" packet) or
routers.

can run

can

Thanks.

JP.

-Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 23 Jun 2010 18:52:09 -0400

> Date: Wed, 23 Jun 2010 16:35:31 -0500
> 
> I'm not sure we can let ROLL off the hook on access to/from hosts
> simply by saying it's out of scope.

I do not think that is what JP is saying.  What is out of
scope is
   "a device that does not run RPL and still requires to
    get routing information"
Is there any requirement for such devices?  What do they
need the routing information for?

I think the problem is that what we are asking about is so
basic to IP routing that JP doesn't understand that we need
confirmation of it.

JP, we don't care about hosts that run RPL.  We don't care
about hosts that need routing information.  Can a host in a
network of RPL routers send and receive packets without
implementing any of RPL or any other routing protocol?

                                  -Richard Kelsey

---

From: [email-masked]
Date: Thu, 24 Jun 2010 08:27:06 -0500

Richard,

You've hit it on the head.  We
need non-RPL hosts (which I termed sleepers) to submit packets to and receive
packets from an RPL network.

Jerry

From:

To:

Cc:

[email-masked], [email-masked]

Date:

06/23/2010 05:47 PM

Subject:

Re: Non-RPL Host access to/from an RPL
LLN

scope is

get routing information"

confirmation of it.

-Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Jun 2010 15:24:55 +0200

Hi Richard and Jerry:

There's at least the problem of the instance ID that's specific to RPL.
The node needs to know which instance it is using. All things could
default to instance 0 for config-less network but the draft does not
mention that at this moment.

Then there's the question of ND. Only 6LoWPAN ND has the concept of
registration that's necessary for the RPL router to inject the host
route into the RPL network. Even iIf 6LoWPAN ND is being used and it has
a real table -not a cache- that can be redistributed into RPL, then the
router still needs the instanceID to redistribute that in. OTOH, RPL
requires classical NUD between all nodes, that's the only thing we have
to detect that a parent or a child is gone.

And there's DAD. RPL expects that the node performs DAD before it joins
the network. 6LoWPAN ND can do DAD to some level but only supports the
case where the node registration is explicitly sent to all LBRs, so by
itself it does not scale to multiple LBRs far away from one another. RPL
could scale and do DAD itself but that would require a minor extension
to pass the unique ID with the DAO, and some additional flows to reject
the duplicates that are detected.

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Richard Kelsey
> Sent: Thursday, June 24, 2010 12:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Roll] Non-RPL Host access to/from an RPL LLN
> 
> I do not think that is what JP is saying.  What is out of scope is
> Is there any requirement for such devices?  What do they need the
routing
> information for?
> 
> I think the problem is that what we are asking about is so basic to IP
routing
> that JP doesn't understand that we need confirmation of it.
> 
> JP, we don't care about hosts that run RPL.  We don't care about hosts
that
> need routing information.  Can a host in a network of RPL routers send
and
> receive packets without implementing any of RPL or any other routing
> protocol?
> 
>                                   -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 24 Jun 2010 10:09:18 -0400

> Date: Thu, 24 Jun 2010 15:24:55 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 
> The node needs to know which instance it is using.

Why?  The router can add the RPL Packet Information.
Yes, if the host wants to control which instance it
ahs to know what they are, but we have no need for
that added functionality.

> Then there's the question of ND.

The issue here is RPL, not ND.

                                -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 24 Jun 2010 17:01:15 +0200

> From: Richard Kelsey [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 4:09 PM
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]; [email-masked]
> Yes, if the host wants to control which instance it ahs to know what
they are,
> but we have no need for that added functionality.
> 
[Pascal] The network is not supposed to modify the flow label .

> The issue here is RPL, not ND.
[Pascal] RPL needs to learn the host addresses from somewhere. 

Pascal

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 24 Jun 2010 13:09:57 -0400

> Date: Thu, 24 Jun 2010 17:01:15 +0200

I thought we were going to use the hop-by-hop option
and not the flow label.

Pascal and I just discussed on the phone.  There are at
least two different use cases that need to be acommodated.
Putting the instance RPLInstanceID in the hop-by-hop option
works for the kind of RPL-ignorant hosts that the ZigBee
folks want.  Using the flow label allows RPL-aware hosts to
specify which instance they want to use.

We may need to allow both:
  - If the 6LoWPAN hop-by-hop option is present, then use
    the RPLInstanceID it contains.
  - If there is no 6LoWPAN hop-by-hop option, then use the
    RPLInstanceID from the flow label, if it is non-zero.
  - In the absence of an RPLInstanceID, pick an instance
    that will get the packet to its destination.  In
    particular, if the destination is the root of a
    DODAG, then use that DODAG's instance.
In the later two cases, add a 6LoWPAN hop-by-hop option
containing the RPLInstanceID before forwarding the packet.

> [Pascal] RPL needs to learn the host addresses from somewhere. 

Yes.  6LoWPAN ND works for that.

                            -Richard Kelsey

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 25 Jun 2010 13:12:07 +0200

Pascal,

comment inline...

Cheers,
  Anders
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: Thursday, June 24, 2010 15:25
> To: Richard Kelsey; [email-masked]
> Cc: [email-masked]
> The node needs to know which instance it is using. All things 
> could default to instance 0 for config-less network but the 
> draft does not mention that at this moment.

This is important. We agreed in Rolle that all this discussion
of multi-instance DAGs did not belong in a base spec at all and
that RPL should be able to get up running in a default configuration.

(and yes, then came the P2P discussion on temporary DAGs but those
do not need any configuration, so they are not really part of this
issue)

> Then there's the question of ND. Only 6LoWPAN ND has the 
> concept of registration that's necessary for the RPL router 
> to inject the host route into the RPL network. Even iIf 
> 6LoWPAN ND is being used and it has a real table -not a 
> cache- that can be redistributed into RPL, then the router 
> still needs the instanceID to redistribute that in. OTOH, RPL 
> requires classical NUD between all nodes, that's the only 
> thing we have to detect that a parent or a child is gone.
> 
> And there's DAD. RPL expects that the node performs DAD 
> before it joins the network. 6LoWPAN ND can do DAD to some 
> level but only supports the case where the node registration 
> is explicitly sent to all LBRs, so by itself it does not 
> scale to multiple LBRs far away from one another. RPL could 
> scale and do DAD itself but that would require a minor 
> extension to pass the unique ID with the DAO, and some 
> additional flows to reject the duplicates that are detected.
> 
> Pascal
> 
> basic to IP
> about hosts

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Jun 2010 15:14:20 +0200

Hi Richard:

Please find the proposed resolution below as an update to section 4.
The new text indicates that the instance ID (and DODAGID if needed) are
always indicated in the hop by hop option.
One side benefit is that a local instance can be used for packets that
are not from / to the root, in which case the dodagid must be included
in the hop by hop option.
The operation to derive the instanceID from incoming packet is left out.
Can be the destination, can be the flow label, can be deep packet
inspection for that matter.

What do you think?

"
4.  RPL Instance

   Within a given LLN, there may be multiple, logically independent RPL
   instances.  A RPL node may belong to multiple RPL Instances, and may
   act as a router in some and as a leaf in others.  This document
   describes how a single instance behaves.

   There are two types of RPL Instances: local and global.  Local RPL
   Instances are always a single DODAG whose singular root owns the
   corresponding DODAGID.  Local RPL Instances are intended for
   constructing temporary DODAGs to support on-demand P2P traffic.
   Global RPL Instances have one or more DODAGs and are typically long-
   lived.  RPL divides the RPLInstanceID space between global and local
   instances to prevent identifier collisions.

   The definition and provisionning of RPL instances are beyond the
   scope of this specification.  Those operations are expected to be
   such that data packets coming from the outside of the RPL network can
   unambiguously be associated to at least one RPL instance, and be
   safely routed over any instance that would match the packet.
   Information used to match a packet to a RPL instance can typically be
   taken from fields in the IPv6 header, like the flow label, TOS bits,
   or destination address.

   Control and data packets within RPL network are tagged to
   unambiguously identify what RPL Instance they are part of.  The
   identifiers in the RPL Hop-by-hop option include the RPLInstanceID
   and, for local instances, the DODAGID.  In some uses the DODAGID is
   implicit, in other uses it must be given explicitly.

   A router that injects a packet into the RPL network MUST tag the
   packet by inserting a RPL Hop-by-hop option as specified in
   [I-D.hui-6man-rpl-option], that unambiguously identifies what RPL
   Instance that is used to forward the packet.

   The router that routes a packet outside the RPL network MUST remove
   the RPL Hop-by-hop option that is non sensical outside the RPL
   Network.

   Every RPL control message has a RPLInstanceID field.  Some RPL
   control messages may optionally include a DODAGID.
"

Pascal

> Sent: Thursday, June 24, 2010 7:10 PM
> I thought we were going to use the hop-by-hop option and not the flow
> label.
> 
> Pascal and I just discussed on the phone.  There are at least two
different use
> cases that need to be acommodated.
> Putting the instance RPLInstanceID in the hop-by-hop option works for
the
> kind of RPL-ignorant hosts that the ZigBee folks want.  Using the flow
label
> allows RPL-aware hosts to specify which instance they want to use.
> 
> In the later two cases, add a 6LoWPAN hop-by-hop option containing the
> RPLInstanceID before forwarding the packet.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Jun 2010 15:43:22 +0200

Hi Anders:

Would you suggest/ask/agree to add some text about instance zero?

Pascal

> From: Anders Brandt [mailto:[email-masked]]
> Sent: Friday, June 25, 2010 1:12 PM
> To: Pascal Thubert (pthubert); Richard Kelsey;
> Cc: [email-masked]
> Subject: RE: [Roll] Non-RPL Host access to/from an RPL LLN
> 
> Pascal,
> 
> comment inline...
> 
> Cheers,
>   Anders
> > Of Pascal Thubert (pthubert)
> This is important. We agreed in Rolle that all this discussion of
multi-instance
> DAGs did not belong in a base spec at all and that RPL should be able
to get
> up running in a default configuration.
> 
> (and yes, then came the P2P discussion on temporary DAGs but those do
not
> need any configuration, so they are not really part of this
> issue)
> 
> > route into the RPL network. Even iIf 6LoWPAN ND is being used and it
> > has a real table -not a
> > cache- that can be redistributed into RPL, then the router still
needs
> > the instanceID to redistribute that in. OTOH, RPL requires classical
> > NUD between all nodes, that's the only thing we have to detect that
a
> > parent or a child is gone.
> >
> > And there's DAD. RPL expects that the node performs DAD before it
> > joins the network. 6LoWPAN ND can do DAD to some level but only
> > supports the case where the node registration is explicitly sent to
> > all LBRs, so by itself it does not scale to multiple LBRs far away
> > from one another. RPL could scale and do DAD itself but that would
> > require a minor extension to pass the unique ID with the DAO, and
some
> > > From: [email-masked] [mailto:[email-masked]] On
Behalf

---

From: JP Vasseur <[email-masked]>
Date: Fri, 25 Jun 2010 22:18:54 +0200

Hi Pascal,

I think that this text does clarify. One minor comment below:

>   constructing temporary DODAGs to support on-demand P2P traffic.

Since on-demand P2P traffic is defined somewhere else, just make it more
general in the text: "Local RPL Instances are intended for constructing
temporary DODAGs that may be used by future on-demand routing solutions
that are outside of the scope of this document".

---

From: Richard Kelsey <[email-masked]>
Date: Sat, 26 Jun 2010 09:08:10 -0400

> Date: Fri, 25 Jun 2010 15:14:20 +0200

Pascal,

That looks good.  I feel better now.  There are a few minor
comments below.
                                      -Richard 

>    lived.

Local instances are also intended for long-lived DODAGs for
communication with Goals within the LLN ("Goal: The Goal is
a application specific goal that is defined outside the
scope of RPL.").

I think it would be much better to say "can be used for"
than "are intended for".  The latter has proscriptive
overtones.

>    RPL divides the RPLInstanceID space between global and local

"RPL divides the RPLInstanceID space between global and local
 instances to allow for both coordinated and unilateral
 allocation of RPLInstanceIDs."

>    The definition and provisionning of RPL instances are beyond the

provisionning -> provisioning
                                
> > Yes.  6LoWPAN ND works for that.

----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 28 Jun 2010 09:58:12 +0200

Hi Pascal

I think we should cooperate on this one. I am not sufficiently
into the fine details of the current RPL spec to make text that
fits precisely into the framework.

In free text I would expect something like this:

While RPL allows for the creation of multi-instance DAGs this is
out of scope for this specification. Any RPL router MUST be able
to join a RPL topology using a DODAGID value of 0 (zero). For
support of such basic operation any RPL node MUST support a
default OCP value of 0 (zero).
(I guess someone has an opinion on how to describe default metrics
requirements?)

Does this make sense?

Thanks,
  Anders

> From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
> Sent: Friday, June 25, 2010 15:43
> To: Anders Brandt; Richard Kelsey; [email-masked]
> Cc: [email-masked]
> > > There's at least the problem of the instance ID that's 
> specific to 
> > > RPL.
> concept of

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Jun 2010 16:37:01 +0200

Hi Anders:

I think that makes a lot of sense. An instance 0 operating on default
OCP 0 provides a configless operating network that enables nodes to get
an initial connectivity.
That connectivity might be enough. If it is not, it is at least enough
to communicate and negotiate better terms, like learn about other, more
suited instances.

RPL could say that the default instanceID is zero and that a network
operates with instance 0 OF0 unless provisioned otherwise. What do
others think?

Pascal

> Sent: Monday, June 28, 2010 9:58 AM
> I think we should cooperate on this one. I am not sufficiently into
the fine
> details of the current RPL spec to make text that fits precisely into
the
> framework.
> While RPL allows for the creation of multi-instance DAGs this is out
of scope
> for this specification. Any RPL router MUST be able to join a RPL
topology
> using a DODAGID value of 0 (zero). For support of such basic operation
any
> RPL node MUST support a default OCP value of 0 (zero).

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Jun 2010 16:36:56 +0200

Hi Richard:

Digging more into what the RPL router needs to be able to act as a
router for a dumb host.

Unless it is the root of the DODAG, a Node is reachable over a RPL
network iff it matches a target that is injected using a DAO. On way of
achieving that for our non RPL host is that, in a classical IGP fashion,
the RPL router owns a prefix. The host forms an address from that
prefix, and the router injects that prefix as target in the instances of
its choice. This is not the expected way for an SGP though. We'd expect
that the prefix is valid across the whole subnet and that hosts form an
address from that same prefix independent on the router they initially
attach to or move to overtime as conditions change.

In that case, the router needs a registration like the 6LoWPAN ND that
it will turn into a DAO.  To turn a registration into a DAO, the router
needs to know:
- the instance ID in which to send the DAO. Without an instance ID, the
router can only default to 0.
- the sequence number to go with it.  Without a sequence number, the
host can only register to one router that would maintain its own
sequence.

That information is not conveyed in 6LoWPAN ND today. So to really
benefit from RPL with the specs that are currently on the table, a host
needs to operate as RPL leaf. 

Do I miss something?
 
Pascal

> Sent: Saturday, June 26, 2010 3:08 PM
> Cc: [email-masked]; [email-masked]; JP Vasseur (jvasseur);
> [email-masked]
> > The new text indicates that the instance ID (and DODAGID if needed)
> > are always indicated in the hop by hop option.
> That looks good.  I feel better now.  There are a few minor comments
below.
> Local instances are also intended for long-lived DODAGs for
communication
> with Goals within the LLN ("Goal: The Goal is a application specific
goal that is
> defined outside the scope of RPL.").
> 
> than "are intended for".  The latter has proscriptive overtones.
> 
instances to
> allow for both coordinated and unilateral  allocation of
RPLInstanceIDs."
> > > I thought we were going to use the hop-by-hop option and not the
> > > flow label.
> > >
> > > In the later two cases, add a 6LoWPAN hop-by-hop option containing
> > > the RPLInstanceID before forwarding the packet.
> > >
> This message and the information it contains are the proprietary and
> confidential property of Ember Corporation and may be privileged.
disclose or
> distribute its contents to any party, and notify the sender
immediately.

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 28 Jun 2010 11:29:57 -0400

> Date: Mon, 28 Jun 2010 16:36:56 +0200

Pascal,

Thanks for taking the time on this.

> the RPL router owns a prefix. [...]

I agree that this conflicts with having a single prefix
across the subnet and so won't work.

> router can only default to 0.

Why?  Why can't the router send DAOs for the host to
any and all instances that it sends its own DAOs to?

> host can only register to one router that would maintain its own

Which sequence number?  The host would be present in the DAO
as a RPL Target option, which has no sequence number.

In any case, this would be unfortunate, but not a disaster.
Current ZigBee networks restrict hosts to registering with
only one router.  Registering with multiple routers adds
redundancy but also adds considerable overhead.

The draft doesn't say what the path sequence is used for, by
the way.

> needs to operate as RPL leaf. 

That ZigBee can't do.  The hosts just don't wake up often
enough to stay current on the routing.

                                 -Richard

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Jun 2010 09:31:48 +0200

Hi Richard,

> Thanks for taking the time on this.

: )

> > network iff it matches a target that is injected using a DAO. On way
> > of achieving that for our non RPL host is that, in a classical IGP
> > fashion, the RPL router owns a prefix. [...]
> 
> I agree that this conflicts with having a single prefix across the
subnet and so
> won't work.
 
[Pascal] For a given sort of deployment. I think that some people have
in mind to do some aggregation with RPL and the draft allows it, but
that's not the case we are discussing here.

> > it will turn into a DAO.  To turn a registration into a DAO, the
> > router needs to know:
> > - the instance ID in which to send the DAO. Without an instance ID,
> > the router can only default to 0.
> 
> Why?  Why can't the router send DAOs for the host to any and all
instances
> that it sends its own DAOs to?

[Pascal] You're right. There must be an implicit behavior that the draft
does not specify. Instance 0 would be a default and then that could be
overridden by some other policy.

> Which sequence number?  The host would be present in the DAO as a RPL
> Target option, which has no sequence number.
> 
> Current ZigBee networks restrict hosts to registering with only one
router.
> Registering with multiple routers adds redundancy but also adds
> considerable overhead.
> 
> The draft doesn't say what the path sequence is used for, by the way.
> 
[Pascal] You're correct again. The sequence number I'm talking about is
now called path sequence and used to be DAO sequence up till 08. In 09,
we allowed to pack multiple "DAOs" in one message with the introduction
of target and transit options, and the sequence moved into the transit
option.
	
It seems that:
- a lot of important text has gone down the sink of needful
simplification between 08 and 09. Sorry I failed to realize that.
- the latest version is somewhat confused between the path sequence and
the DAOsequence. The DAOsequence is a new beast introduced with the DAO
Ack to correlate the DAO and the DAO Ack. It has little importance. The
sequence that allows to compare the freshness of a path to a target is
really the path sequence.

The text:   

 "DAOSequence:  Incremented at each DAO message from a given child,
         echoed in the DAO-ACK by the parent.  The DAOSequence serves in
         the parent-child communication and is not to be confused with
         the Transit Information option Sequence that is associated to a
         given target down the DODAG."

Is correct but later references to DAO sequences really refer to that
path sequence.

Section 7.1.4. DAO Operation on Storing Nodes Nodes of draft 08
explained the role of the DAO sequence number that's now the path
sequence.

In particular
"
7.1.4.1.1.2. Operation in the REACHABLE state

   1.  When a REACHABLE(*) entry times out, i.e. the DAO Lifetime has
       elapsed, the entry MUST be placed into the UNREACHABLE state and
       No-Path SHOULD be scheduled to send to the node's DAO Parents.

   2.  When a No-Path for a REACHABLE(*) entry is received with a newer
       DAO Sequence Number, the entry MUST be placed into the
       UNREACHABLE state and No-Path SHOULD be scheduled to send to the
       node's DAO Parents.

   3.  When a REACHABLE(*) entry is to be removed because NUD or
       equivalent has determined that the next-hop neighbor is no longer
       reachable, the entry MUST be placed into the UNREACHABLE state
       and No-Path SHOULD be scheduled to send to the node's DAO
       Parents.

   4.  When a REACHABLE(*) entry is to be removed because an associated
       Forwarding Error has been returned by the next-hop neighbor, the
       entry MUST be placed into the UNREACHABLE state and No-Path
       SHOULD be scheduled to send to the node's DAO Parents.

   5.  When a DAO (or No-Path) for a REACHABLE(*) entry is received with
       an older or unchanged DAO Sequence Number, then the DAO (or No-
       Path) SHOULD be ignored and the associated entry MUST NOT be
       updated with the stale information.
"

I'll talk with Tim see what we can do about it in real short term.

> > benefit from RPL with the specs that are currently on the table, a
> > host needs to operate as RPL leaf.
> 
> That ZigBee can't do.  The hosts just don't wake up often enough to
stay
> current on the routing.
 
[Pascal] Makes sense. The whole point of being a host after all.

I still think you'd be a lot better off with the sequence number. Even
if a host registers to only one router, the host might move from one
router to another due to radio conditions or failures. The whole point
of the sequence number is to detect that an information is stale and
should be replaced by a newer one.

For instance, let's pick the source route mode. I expect that the router
would create a DAO  with self as parent in the transit option and the
host as target, and send that up to the root.
If the host moves to a new router, the root will get 2 transit options.
With a sequence number, the root can find right away which is the
obsolete entry. 

Does Zigbee prevent a router to attach to more than one router? If not,
then in the case above, the root would not be able to figure that one
entry is obsolete.

What do you think?

Pascal

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 29 Jun 2010 09:37:13 +0200

Pascal, Richard,

(comment inline) 

> Behalf Of Richard Kelsey
> Sent: Monday, June 28, 2010 17:30
> Why?  Why can't the router send DAOs for the host to any and 
> all instances that it sends its own DAOs to?
> 

A Z-Wave as well, I might add. It would drain our batteries way too
fast.

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 29 Jun 2010 09:09:22 -0400

> Date: Tue, 29 Jun 2010 09:31:48 +0200

Yes, but I don't see how we can get a path sequence number
from a non-RPL-aware host.  In the absence of a sequence
number from the host, the router can simply add the host's
address in an RPL Target Option when the router sends a DAO.

> Does Zigbee prevent a router to attach to more than one router?

Currently in ZigBee a host (an "end device" in ZigBee-speak)
can attach to only one router.  Attatching to two routers
would double the cost of checking for incoming messages,
which is likely to be a problem.

                                      -Richard

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Jun 2010 15:11:50 +0200

Hi Richard:

Pascal Thubert (pthubert)" <[email-masked]>
> Yes, but I don't see how we can get a path sequence number from a non-
> RPL-aware host.  In the absence of a sequence number from the host,
the
> router can simply add the host's address in an RPL Target Option when
the
> router sends a DAO.

[Pascal] I'm trying to get the sequence counter in the 6LoWPAN ND ARO. 
Your support there would be appreciated : )

> Currently in ZigBee a host (an "end device" in ZigBee-speak) can
attach to
> only one router.  Attatching to two routers would double the cost of
checking
> for incoming messages, which is likely to be a problem.
> 

[Pascal] My question was about router not host. The bottom line is that
the root might need to accept multiple DAOs for a same target if that
target is a router.
But then, if it cannot differentiate a target that is a host from a
target that is a router, the root will maintain 2 states for a host that
moves from router A to router B, because it does not even know that only
one state is possible for a Zigbee host. 

Pascal