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 protected] [mailto:[email protected]] On Behalf Of Zach Shelby >Sent: vendredi 3 avril 2009 16:02 >To: Carsten Bormann >Cc: [email protected] >Subject: Re: [6lowpan] multihop information option metric > >Hi, > >Carsten Bormann wrote: >> 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. > >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 > >> Gruesse, Carsten >> >> (No WG chair hats included in this message.) >> >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan > >-- >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
