Hi Pascal,
>Current ND is the de facto abstraction for the host interface.
....
>At the other, we could consider that RPL is actually the component of
ND that handles router to router. Why not after all?
I understand that it makes sense in a router perspective to have this
stuff in the routing protocol.
My problem is that I have to make code for very small nodes.
Having two methods I need to support translates into two code blocks I
need to include when building code for my nodes.
For sure I need a way of assigning addresses to host nodes. This is a
hard requirement. RPL assignment seems optional.
If I can use the same code in the routing nodes I have more code space
for the interesting parts.
Don't you agree?
>The recent developments are that people tend to think that you can live
with an IPv6 derived from the MAC address without any DAD.
That is fine with me - but I still need to convey prefix and default
gateway, so this really does not change a lot, does it?.
Thanks,
Anders
________________________________
From: Pascal Thubert (pthubert) [mailto:pthub...@cisco.com]
Sent: Friday, May 07, 2010 14:47
To: Anders Brandt; Kris Pister
Cc: ROLL WG; 6lowpan@ietf.org
Subject: RE: [6lowpan] [Roll] how does a node get an IPaddress
Hi Anders:
There are a number of requirement drafts for this and that.
I think Julien and Mathilde tried to compile at some point what
the arch minimum would be in a device to run IPv6 and looks OK.
The recent developments are that people tend to think that you
can live with an IPv6 derived from the MAC address without any DAD.
But you'd still need the prefix information that's found in the
RA-PIO and the routing information that's found in the RA-RIO (that's
very much like RPL 08's DPO).
So you see, it is actually very useful to RPL routers to carry
those RA options unchanged within RPL's DIO
Current ND is the de facto abstraction for the host interface.
Some LLN/LoWPANs bring in a number of new concepts from route
over. And now we're wondering what's the position of ND in that world.
At one extreme we could say that the route over piece is a
router problem and externalize it from ND unto RPL and such.
At the other, we could consider that RPL is actually the
component of ND that handles router to router. Why not after all?
Cheers,
Pascal
From: 6lowpan-boun...@ietf.org [mailto:6lowpan-boun...@ietf.org]
On Behalf Of Anders Brandt
Sent: Friday, May 07, 2010 9:03 AM
To: Kris Pister
Cc: ROLL WG; 6lowpan@ietf.org
Subject: Re: [6lowpan] [Roll] how does a node get an IPaddress
Kris,
> But it's not a power issue
Agreed. This was meant to be an example only ;-)
- Anders
________________________________
From: Kris Pister [mailto:pis...@eecs.berkeley.edu]
Sent: Thursday, May 06, 2010 23:27
To: Anders Brandt
Cc: ROLL WG; 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] how does a node get an
IPaddress
Anders - there are many commercial networks (even in
buildings and homes) where battery operated nodes are routers. I don't
think that we should confuse the line/battery power issue with the
host/router issue.
There are many reasons why a node might choose or be
designated to be a host not a router, so your question still stands.
But it's not a power issue.
ksjp
Anders Brandt wrote:
Let me try one more time:
How much of this will I have to implement to be
compliant with other
LLN/RPL nodes?
In a home control/building environment, the notion of a
router nodes is
rather artificial.
I may have _host_nodes_. They are host nodes because
they are sleeping
(battery operated)
and therefore they cannot participate in routing.
They still have to get an IP address to talk to other IP
hosts.
Alternatively, I may have combined _host&router_nodes_
which serve a
purpose application-wise
and at the same time happen to be routing resources.
Do these hosts have to use another way of getting IP
addresses just
because they happen to
be able to do routing?
From a designer's standpoint it does not seem quite
elegant that I have
to do use different
methods depending on the power model for my node. Am I
missing something
here?
Thanks,
Anders
-----Original Message-----
From: 6lowpan-boun...@ietf.org
[mailto:6lowpan-boun...@ietf.org] On Behalf Of
Carsten Bormann
Sent: Thursday, May 06, 2010 10:04
To: Pascal Thubert (pthubert)
Cc: ROLL WG; zach.she...@sensinode.com;
6lowpan@ietf.org
Subject: [6lowpan] RPL aware hosts (Re: [Roll]
how does a
node get an IPaddress)
On May 6, 2010, at 09:02, Pascal Thubert
(pthubert) wrote:
enable RPL aware hosts
Should we?
(Obviously, if a node really needs to know about
RPL, it can
always become a router.)
If I understand you correctly, this is about
hosts selecting
a specific RPL instance-ID for outgoing traffic.
Traditionally, IP has used the TOS byte (Traffic
Class in
IPv6) to select between different behaviors of
the forwarding
system. What is it that the host wants to say
by selecting a
specific RPL instance ID? Why can't the router
make that
selection, e.g. based on the Traffic Class and
the
destination address?
(Another interesting question is, for incoming
traffic, how a
host selects which instances it wants to be part
of. Is that
even a useful thing to do? Would that selection
be made by
the host, by its first-hop router, or by some
configuration agent?)
It would be useful to get more information about
how
instance-IDs are intended to be used with RPL.
On the protocol side:
If there really is something that a host needs
to know about
RPL-specific information (instances or
whatever), this could
be delivered in an ND option that could very
well be defined
in an RPL-related document, no need to define it
in
6LoWPAN-ND. Another way to set up this
information would be
to configure it during commissioning or using a
host
configuration protocol like DHCP.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
Roll mailing list
r...@ietf.org
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan
