Re: [Roll] NA to transport DAO

[Michael Richardson <mcr at sandelman.ca>]

(You'll want to edit your mailer to not reply to SMTP from addresses, as
you CC'ed roll-bounces at ietf.org, which you certainly do not want to do)

>>>>> "Jerald" == Jerald P Martocci <Jerald.P.Martocci at jci.com> writes:
    Jerald> I guess I am one of those people that think that other
    Jerald> 6LoWPAN nodes must participate in RPL.  Unless I am missing
    Jerald> something RPL is the only game in town regarding meshing of
    Jerald> wireless sensors.  If they are not in RPL is there another
    Jerald> means that they can use to form mesh connectivity to get to
    Jerald> the LBR?

As far as I can tell 6LoWPAN-nd and RPL are somewhat complementary, and
somewhat overlapping.   

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <pthubert at cisco.com>> writes:
    >> Some things immediately jump out at me: 1) small packets are much
    >> more common, so DAOs may not fit into ND.

    Pascal> This is a non issue. IPv6 on any link requires an MTU of at
    Pascal> least 1280. 6LoWPAN provides a fragmentation mechanism for
    Pascal> those link layers that could hold the IPv6 MTU in a frame.
    Pascal> Above the IPv6 MTU, you can still fragment the ND packet
    Pascal> using IPv6 fragmentation.  This is more common than you
    Pascal> might think, as traditional ND packets can get real big, for
    Pascal> instance in the presence of SeND.

Uhm, the fact that 6LoWPAN provides a fragmentation mechanism is not
important.   What this means is that a single ND packet now takes
multiple packets.  One of the arguments against putting DAOs in the ND
is that they do not go often enough, and therefore we would have to send
more ND packets, which means more energy.

If in fact the ND will be fragmented by the layer-2 for delivery, then
we might well be better off to send the more frequent DAOs in their own
packet, ideally one which 6LoWPAN can carry without fragmentation.
That's a win because then the much larger ND packets (yes, I am very
familiar with SeND), can be sent less often.

    >> 2) multicast is not assumed, so the Whiteboard is used.

    Pascal> The routers could still use NS/NA between them but that
    Pascal> makes little sense I agree. RPL routers use NA as unicast to
    Pascal> their parent, a role that 6LoWPAN NR can perfectly play

Yes, we can certainly put DAOs on the NR/NC, once you know about the
parent.  

But, what's the point of running RPL on that node?  It can not talk to 
any other nodes unless they can also see the same whiteboard, which
means that the nodes can not have children.

    >> 3) nodes that are sleepy, are not going to be useful as members
    >> of an RPL DAG, so really, it's about RPL between the Edge
    >> Routers.

    Pascal> In my mind the edge router is usually also the root for a
    Pascal> RPL DAG.

I agree that this is reasonable.

What I do not understand is how/why you would run both RPL and 6LoWPAN
on the other nodes.  If they have connectivity to the edge router to be
able to send it updates for the Whiteboard, then you
have... well.. connectivity.  

(look at diagram on page 13 of nd-06.txt)

If you do not have connectivity to the Whiteboard/EdgeRouter, and you
are trying to use RPL to reach it (which I think a lot of people want to
do), then you need to broadcast/multicast a DAO somehow, such that you
can find a parent with a DAG to join.  

But, to do that, you need at least a link-scope address to use (which I
think you need to do DAD on, right? or does one skip that for link-scope
addresses...), and you need to be able to multicast/broadcast.  

6LoWPAN provided the whiteboard because multicast didn't work, so it
seems like you can not put RPL on nodes that aren't directly
connected to the whiteboard.  And if you have a node that can run RPL,
then it doesn't need 6LoWPAN either.

    >> It seems to me therefore that the only nodes in a 6lowpan that
    >> can participate in a RPL DAG would be the edge router that runs a
    >> Whiteboard.

    Pascal> RPL is the prime protocol for a route-over 6LoWPAN
    Pascal> network. So we must make it work, and hopefully it does.

I agree that we all want it to work.  
I'm just not sure that we do not have an impedance mismatch here.

I'm not a 6LoWPAN expert (and none of my consulting customers wanted me
to be).  
new acronym: IANA6L.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.