Hi Alex,
Alexandru Petrescu wrote:
Pascal Thubert (pthubert) a écrit :
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
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.
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.
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.
I agree with this intention.
- 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 in the pictured case only the default routes are discussed. I think
I mean metric Cost -only for default routes.
Basic an a comparison of this metric, the host is able to choose the
default route.
- 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.
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".
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
Alex
--
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.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
