Subject: [6lowpan] ND for 6LoPWAN - tickets from SFO

From: Zach Shelby <[email-masked]>
Date: Wed, 01 Apr 2009 11:45:27 +0300

Hi,

Thanks everyone from a great meetings at SFO. It was a productive IETF, 
and we collected lots of good feedback on draft-ietf-nd-02. We plan on 
releasing -03 of the draft within a couple weeks.

I have opened up tickets for all the issues collected recently on the 
mailing list, in the WG meeting, and by the authors. See:

http://trac.tools.ietf.org/wg/6lowpan/trac/report/1

We currently have 8 tickets there, mostly pretty minor. Please take a 
look that your issues are covered and throw a note to the list if there 
is something we are missing.

- Regarding the naming of Router Registration (RR) we decided to make no 
change at this time.

- Regarding the inclusion of a metric to the Multihop Information Option 
   for determining the best router for hosts not participating in 
routing: Carsten will propose a solution to the list... 
http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/25

- After seeing how the terminology is developing in ROLL I have a 
suggestion. Should we synchronize our terminology and rename LoWPAN Edge 
Router to LoWPAN Border Router so as to minimize confusion?

Zach

-- 
http://zachshelby.org - My blog “On the Internet of Things”
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: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Apr 2009 10:51:40 +0200

Zach Shelby a écrit :
[...]

Issue 25:
> The issues is that some scalar metric representing the cost to the
> best ER through a Router should be advertised in RAs. What goes in
> the metric is determined by some routing algorithm but should be an
> easily comparable scalar for nodes to use simply to determine which
> router to use as a default without knowing anything about routing.

Let me ask clarification about 'best router', in this example topology:

    ------    RA1 -------  RA3  -------
   |Host  |---+--|Router1|-----|Router3|\
    ------    |   -------       -------  \_______Internet
              |   -------                /
              +--|Router2|--------------/
              RA2 -------

-what do you assume Host should choose as 'best router' - Router1,
  Router2 or Router3?
-did I assume correctly the subnet structure above?

Alex

---

From: "Peter Siklosi" <[email-masked]>
Date: Fri, 3 Apr 2009 13:50:04 +0200

Alexandru Petrescu wrote:
>Zach Shelby wrote:

>    ------    |   -------       -------  \_______Internet

In the figure above, I assume that "Internet" would represent the edge
router and that the lines are the possible links, so the host can
communicate directly with Router1 and Router2, but cannot reach router3
directly. The question is then if router1 or router2 should be selected.

In my mind, the simplest model would be to represent the cost as hop
count and in this case router1 would advertise the cost 2, while router2
would advertise the cost 1. The host would then select router2 based on
lowest cost, which would in this case be the shortest route to edge
router. In practical cases, this would be infinitely better than
selecting routers by random, but still not perfect.

A better model would be to take link quality into account. In this case,
the cost going through router1 is a function of the link quality of the
link to router1 and the cost from router1 to the edge router. It would
probably be best to define the cost as the sum of the cost to router1
and the cost from router1 to the edge router and we should require the
link cost to be at least one. By this procedure, it would still be
possible to use just hop count, but also possible to use something
slightly more sophisticated.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Apr 2009 14:10:38 +0200

On Apr 3, 2009, at 13:50, Peter Siklosi wrote:

> In my mind, the simplest model would be to represent the cost as

ND in 6lowpan is (mainly) about the host-router interface.
Does the host even have to know about the way the router metric is  
computed?
The host (if it wants to be just a host) should not need to know about  
the routing protocol and its metrics.

I have therefore proposed the ND metric to simply be a 16-bit integer,  
with a mid-range default (i.e., 0x8000 if the number is unsigned).
Routing protocols may want to define a way how to compute that integer  
at a router so that multiple routers present numbers that make sense  
when used together by a host. (And that may not exclude use of the  
value found via ND in bootstrapping a router.  Still outside the scope  
of ND proper.)

BTW, standard IPv6 ND does not have such a metric for the following  
stated reason:

       Unlike in IPv4 Router Discovery, the Router Advertisement  
messages
       do not contain a preference field.  The preference field is not
       needed to handle routers of different "stability"; the Neighbor
       Unreachability Detection will detect dead routers and switch to a
       working one.

[RFC 4861, p 16].  This thinking does not really seem to apply to  
6lowpans very well.

Gruesse, Carsten

(No WG chair hats included in this message.)

---

From: Zach Shelby <[email-masked]>
Date: Fri, 03 Apr 2009 17:01:49 +0300

Hi,

Carsten Bormann wrote:
> when used together by a host. (And that may not exclude use of the value 
> found via ND in bootstrapping a router.  Still outside the scope of ND 
> proper.)
> 
>       Unlike in IPv4 Router Discovery, the Router Advertisement messages

I support this proposal myself, and think it is a nice solution to the 
concern Peter brought up. The Multihop Information Option in 
draft-ietf-nd has plenty of reserved space for such a 16-bit option. 
This is also compatible with e.g. the work going on in ROLL as this 
information is meant for hosts that don't have knowledge of the routing 
algorithm. If a ROLL algorithm would produce such a metric - the router 
would simply copy that into this field for use by hosts.

With regard to integrating this into -03 of the draft, we would need to 
see some more consensus support on the list. Who else finds this useful?

- Zach

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Apr 2009 16:39:23 +0200

I agree with Carsten and Zach:

The metric is opaque to the host because it is (derived from) a routing
metric and the host does not route. But when it comes to forwarding,
then the host would benefit from using it wisely. In more details:

- We just make the router preference a bit wider in size than RFC 4191
but the host is clueless about what that means; all it does is compare
opaque scalar to opaque scalar. It's probably up to ROLL to give it a
meaning and a value but that's out of scope for our spec.

- The metric might fluctuate but it's not crucial for the host default
router selection as long as the default router still enables
reachability to/from an edge router. In Other Words the host does not
have to switch default router (and reregister to the edge router) each
time that metric varies though it should lazily try to stick to the best
one to optimize the return path from the edge router.

- But a host might favor the best metric router as next hop on a per
packet basis if it likes. And if sending a packet to a router fails then
it might select the next best in the default router list per that
metric. In that, forwarding host to router is pretty similar to
forwarding router to router within the LoWPAN - if ROLL enables this
that is.

Maybe we need a bit of text to be more specific on all this?

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zach Shelby
>Sent: vendredi 3 avril 2009 16:02
>To: Carsten Bormann
>Cc: [email-masked]
>Subject: Re: [6lowpan] multihop information option metric
>
>Hi,
>
>Carsten Bormann wrote:
value
messages
>http://zachshelby.org - My blog "On the Internet of Things"
>Mobile: +358 40 7796297
>
>Zach Shelby
>Head of Research
>Sensinode Ltd.
>Kidekuja 2
>88610 Vuokatti, FINLAND
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Apr 2009 22:01:34 +0200

Peter Siklosi a écrit :
>>> The issues is that some scalar metric representing the cost to
>>> the best ER through a Router should be advertised in RAs. What
>>> goes in the metric is determined by some routing algorithm but
>>> should be an easily comparable scalar for nodes to use simply to
>>> determine which router to use as a default without knowing
>>> anything about routing.
> 
>> ------    RA1 -------  RA3  ------- |Host
>> |---+--|Router1|-----|Router3|\ ------    |   -------       -------
>> \_______Internet |   -------                / 
>> +--|Router2|--------------/ RA2 -------
>> 
>> Router2 or Router3? -did I assume correctly the subnet structure
>> above?
[...]
> count and in this case router1 would advertise the cost 2, while
> router2 would advertise the cost 1. The host would then select
> router2 based on lowest cost, which would in this case be the
> shortest route to edge router.

I agree.  But remark I represented Router1 and 2 as devices with two
interfaces, and a different subnet for each interface.  Not sure this is
the case for 6LoWPAN ND.

Indeed there seems to be a need for a Cost to be put in the RA but not
sure it applies well in the subnet structure here, because 6lowpan ND
considers sometimes mesh-under intertwinned with route-over... which is
confusing.

Were it for Router1 and 2 in 6lowpan ND to have two real interfaces, two
different subnets, then I'd agree with the use of Cost as you suggest.
Otherwise I'm not clear what a hop is at all (in multihop option metric).

Alex

  In practical cases, this would be infinitely better than
> A better model would be to take link quality into account. In this
> case, the cost going through router1 is a function of the link
> quality of the link to router1 and the cost from router1 to the edge
> router. It would probably be best to define the cost as the sum of
> the cost to router1 and the cost from router1 to the edge router and
> we should require the link cost to be at least one. By this
> procedure, it would still be possible to use just hop count, but also
> possible to use something slightly more sophisticated.
> 
> Peter
> 
> _______________________________________________ 6lowpan mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Apr 2009 22:14:01 +0200

> ND in 6lowpan is (mainly) about the host-router interface.

I agree with the intention.  I have hower purposefully pictured Router1
and 2 to have two different interfaces each - I can reason with them so.
  I'm afraid 6lowpan ND may not uses such devices, though.

> Does the host even have to know about the way the router metric is 

No.

> The host (if it wants to be just a host) should not need to know
> about the routing protocol and its metrics.

I agree.

> I have therefore proposed the ND metric to simply be a 16-bit
> integer, with a mid-range default (i.e., 0x8000 if the number is
> unsigned). Routing protocols may want to define a way how to compute
> that integer at a router so that multiple routers present numbers
> that make sense when used together by a host. (And that may not
> exclude use of the value found via ND in bootstrapping a router.
> Still outside the scope of ND proper.)

I agree with ND metric 16-bit, in this sense.  Maybe 8bit would be
sufficient too.  ?

> Unlike in IPv4 Router Discovery, the Router Advertisement messages do
> not contain a preference field.  The preference field is not needed
> to handle routers of different "stability"; the Neighbor 

Well yes, but there's something about default routes - which we seem to
consider here more than the specific routes.

For default routes (address of the default router) there are fields
"Router Lifetime".  If each router decreased the lifetime it advertised
further down the network then Host would make a decision to prefer the
default router whose Router Lifetime is higher, and thus reach quicker
the Internet via the least decreased Router Lifetime - a potential reuse
without defining new Cost field.

Yet again, all this provided I understand ok the IP subnet structure in
6lowpan ND.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Apr 2009 22:16:24 +0200

> concern Peter brought up. The Multihop Information Option in 

Well yes, I agree with you Zach, but provided that 'hop' in multi-hop is 
understood.  I already said in my review of the document that I don't 
understand it.

> see some more consensus support on the list. Who else finds this useful?

The discussion?  Me too.  The option as it stands now - I can' grasp it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 03 Apr 2009 22:25:27 +0200

> - We just make the router preference a bit wider in size than RFC 4191

rfc4191 "router prefs and more specific routes" has Preference size 
2bits: why would 6lowpan need more?

Has it somehow been agreed that the number of IP hops in a 6lowpan 
network is larger than 4?  If we consider all nodes to be mesh-under and 
  the entire 6lowpan link to be one subnet then there' only one hop, 
which is less than 4.

> meaning and a value but that's out of scope for our spec.

I agree with this intention.

> one to optimize the return path from the edge router.

But in the pictured case only the default routes are discussed.  I think 
I mean metric Cost -only for default routes.

> forwarding router to router within the LoWPAN - if ROLL enables this

Seems to need to go hand in hand with what ROLL may come up with, which 
is good.

> Maybe we need a bit of text to be more specific on all this?

Well the text I suggest is "it's not clear at this time what the subnet 
structure is and the solution to it is that the entire 6lowpan is a 
single subnet, only one hop".

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 6 Apr 2009 08:49:17 +0200

Hi,

> meaning and a value but that's out of scope for our spec.

Strongly agreeing. If the host really want to understand the meaning  
of that metric,
it should become part of the routing domain, which is not what we want  
to achieve
here. Provide an opaque metric computed by the routing protocol is a  
good option.

> one to optimize the return path from the edge router.

Well, it is an implementation issue but I would prefer not provide  
fluctuating
metric to hosts rather than relying on the host to do the right thing  
upon receiving
metrics that change too quickly. You may still want to add a  
recommendation
(RECOMMENDED) in the I-D with regards to the host behavior in such  
scenario.

> forwarding router to router within the LoWPAN - if ROLL enables this

Not sure that I would recommend router selection on a per packet  
basis ...
Such behavior may work in some cases where you have ECMPs with paths
having similar characteristics (in term of delays, ...) but clearly  
there are many
situations where this is highly undesirable. I would personally  
recommend NOT
to the this in the I-D. It is a recommendation, up to the implementers  
to follow it.

> Maybe we need a bit of text to be more specific on all this?

Thanks,

JP.

> integer,

---

From: Zach Shelby <[email-masked]>
Date: Mon, 06 Apr 2009 10:29:15 +0300

Hi Alex,

>  the entire 6lowpan link to be one subnet then there' only one hop, 

We are already using the preference bits to give preference to an Edge 
Router rather than a Router. This discussion only pertains to IP routing 
cases (not mesh-under!). Therefore the LoWPAN is not a single hop, there 
are IP hops in there. Thus the host may be multiple IP hops away from an 
ER - which is the whole reason we have Router opertaions defined in this 
draft, why we are relaying RR/RC messages, and why we are discussing 
this metric.

> I mean metric Cost -only for default routes.

Basic an a comparison of this metric, the host is able to choose the 
default route.

> single subnet, only one hop".

This is not correct. A LoWPAN may be a single hop if using some kind of 
mesh-under technology. In that case you have no LoWPAN routers, no 
multihop, no relaying, and you don't necessarily need this metric.

As I pointed out before - this draft supports IP routing where there are 
multiple IP hops within the LoWPAN. This is the case being discussed here.

- Zach

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