Hi,
On Apr 3, 2009, at 4:39 PM, Pascal Thubert (pthubert) wrote:
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.
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.
- 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.
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.
- 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.
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.
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
