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 protected], which you certainly do not want to do) > >>>>>> "Jerald" == Jerald P Martocci <[email protected]> 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 protected]>> 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
