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: [email protected] [mailto:[email protected]] On
Behalf Of Anders Brandt
Sent: Friday, May 07, 2010 9:03 AM
To: Kris Pister
Cc: ROLL WG; [email protected]
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:[email protected]] 
        Sent: Thursday, May 06, 2010 23:27
        To: Anders Brandt
        Cc: ROLL WG; [email protected]
        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: [email protected] 
                [mailto:[email protected]] On Behalf Of Carsten
Bormann
                Sent: Thursday, May 06, 2010 10:04
                To: Pascal Thubert (pthubert)
                Cc: ROLL WG; [email protected]; [email protected]
                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
                [email protected]
                https://www.ietf.org/mailman/listinfo/6lowpan
                 
                    

        _______________________________________________
        Roll mailing list
        [email protected]
        https://www.ietf.org/mailman/listinfo/roll
          

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

Reply via email to