Subject: Re: [6lowpan] [Roll] NA to transport DAO

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 14 Oct 2009 12:33:07 +0200

Hi Michael

Thanks a lot for this discussion :)

>(You'll want to edit your mailer to not reply to SMTP from addresses,
as
>you CC'ed [email-masked], which you certainly do not want to do)
>
>>>>>> "Jerald" == Jerald P Martocci <[email-masked]> 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.

6lowpan-ND was designed with route over in mind from day 1, that was
part of the Dublin vote.
And one of the objectives of the authors has always been to make those 2
work together.
You'll find that some of the authors are actually working on both drafts
in parallel.
Now we (and I assume my own responsibility there) might have missed
something on the way.

But I'm certainly interested in discussing and fixing anything that
might be an issue between the 2, and hear more about the overlap that
you found. It is high time since we will probably be asking for WGLC
very soon.

At the moment, the issues I'm aware of are:

- RPL does not mention NR/NC. There's a point where it should enable the
use of those messages as an alternate or a replacement to NA unicast
- ND does not impose that nodes should send NA multicast after NR/NC
flow though the new RPL P2P expects it?

Anything else we should concentrate on?

>>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>>
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.

I'm sure you mean multiple frames for one ND packet. And yes, the frames
being small in 15.4, there's a point where you need multiple of them,
and there's overhead etc... This is a real issue certainly at L2 but
there's nothing IP can do about it, and whether you call the packet a NA
or something else will not make a difference there. 

My point was that L3 cannot and does not make a difference so from that
standpoint, it is a non issue. What we must clearly do for DAO as for
anything else is try to be concise in our protocol. After that, some
additional technology might be specifically put in place over certain
links for additional blocking or compression, like 6LoWPAN HC for
instance.

>
>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 cannot 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.

You right. In route-over, most of the nodes might need a DAG to reach
the white board.
IOW they are not in direct line of sight and attach to a router deep in
the DAG.
As you figure, the lucky ones that are will attach to the white board.

The brd/mlt cast is that of RA-DIO.

>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.

Note: In route-over, the link local address is only used over one radio
hop but its uniqueness is checked on the whole subnet - the larger non
transitive link that might incorporate a backbone and multiple RPL DAGs,
e.g. the whole diagram on page 13 of nd-06.txt - by the whiteboard.

Here's how it could go if we bind RPL over NR/NC: 

1) As the DAG forms, a RPL router discovers its parents. If the ND
operation on the link is based on NR/NC then it makes sense for the OCP
to favor a parent that can reach a whiteboard so that a single NR can be
used for RPL DAOs and to maintain the registration of its own addresses
at the same time.

2) Then the router obtains a link local and a global address using the
whiteboard via its parent(s). The parent is already part of the DAG so
it can relay the registration. The DAOs for the router's prefixes if it
has any are included in the NR. So would be the fact that the node is a
router, so that parents disable address filtering upon acceptance by the
whiteboard.

3) Upon successful completion from the white board, the parent installs
a binding to the address, and a route to the prefix via the address. For
a global address it could do either way, my take is bind the link local
to the mac address for address resolution, and for anything (global
addresses, prefixes and mcast DAOs) install routes via the link local. 

4) The parent also sets up RPL as to add the router's prefix (and/or
address) information in its own DAOs.

5) The parent sends a successful completion to the router

6) The router now owns its address(es), the right to be a router, can
send its owns RA-DIOs indicating that it can reach the whiteboard, and
the process recurses

Note: Extending 6LoWPAN ND for RPL is relatively consequent piece of
work, similar in essence to what NEMO is to MIPv6.
This will require a new draft for sure. At the moment, what we really
need from 6LoWPAN ND is to enable this as we see it coming. 

Potentially, this could mean that we need to enable the capability to
bind additional stuff in a same NS and probably couple the global and
the link local binding in a single message. We also need to think of
adding a 'router' bit to change the source address validation.

That discussion belongs to the 6LoWPAN list...

>
>    >> 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.

? sorry I missed that

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Oct 2009 13:07:43 -0400

{I am not on 6lowpan list}

(Pascal gives 6 step process of binding RPL over NR/NC.)

> used for RPL DAOs and to maintain the registration of its own addresses

What happens if there is no connectivity to the whiteboard?
I.e.  the DAG is not grounded?

I think the node/router in question has to talk to the whiteboard using
it's not-yet-known-to-be-unique link local address.  

I'm really unconfortable with the idea that the node/router has
participate on a network, and change routing state of upstream nodes,
using an address that is not yet unduplicated.  The attacks that I can
imagine are almost endless, such that I would very much want to consider
doing this only with SEND.

> send its owns RA-DIOs indicating that it can reach the whiteboard, and

How does it transmit he RA-DIOs?  They are multicast/broadcast on the
directly attached link, not I guess with the help of the whiteboard.
i.e. these are multicasts that have to bypass the 6lowpan multicast
system, I think?

I think this is important --- as it may mean that these DIOs can not be
extra payloads of the "ND" (NR/NC), which would normally got to the
whiteboard via unicast, right?

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