|
From: Tom <my....@gm...> - 2012-01-14 04:43:00
|
Hi Tommaso, I am new to WSN , so excuse my ignorance. But, wouldn't it be safe to assume fragmented 6LoWPAN transmission is a rarity in a typical WSN? Even the control packet's size, I assume remains low to fit in a 6LoWPAN fragment. Regards, Tom On Sat, Jan 14, 2012 at 6:55 AM, Tommaso Pecorella <tpe...@me...>wrote: > Hi Colin, > > thanks for your answer. > > Yeah, it's route over, but you understood what I meant :) I was referring > to a slightly more complex case tho. > > If you check the Zack Shelby's book (not the Bible, but a good source for > sure), you'll find that multihop can be done actually in 3 points: > - L2: mesh-under. Invisible to 6LoWPAN and above layers > - L3: route-over. The packet needs to be reassembled or you'll need *very* > dirty tricks. Not the sort of tricks you wanna do in a low power device. > - L2.5; inside 6LoWPAN, accessing directly the IP routing tables. I don't > know how to call this one. Forwarding-inside ? > > Now, I do agree that it's all a design choice, and that supporting all the > 2 modes in 6LoWPAN (mesh-under is invisible to 6LoW so I don't consider it > in this discussion) would make the code quite complex. On the other hand I > was interested into the rationale of the choice, and if it was discussed at > some point. > > The pros of reassembling are for sure that you can spot the "problem" (if > there is) in a link, the cons are that 1) you'll have to consume memory for > reassembly and 2) there is an increased packet processing delay in the > node, since before forwarding, a node will have to receive the whole set of > fragments. > Now, the delay is not usually a problem, but the memory can be. > > Comparing Contiki to TinyOS implementations (both do reassembly inside the > forwarding nodes), I've noticed that Contiki uses just one buffer, thus if > a node will have to forward two fragmented packets at the same time they > might be both lost. This might happen in a poorly designed data collection > system, where the sensors are sending fragmented packets toward the DODAG > root. > > TinyOS do have multiple buffers, but they're still a fixed and limited > number, so the problem is not eliminated, it's just less noticeable. It > might still trigger and due to Murphy's law it will, as soon as your > sensors network is deployed. > > Direct fragment forwarding have the pro to not require any memory, but the > following cons: > 1) you have to rely on a cross-layer information, and this is usually a > nightmare. You need to assume that there is µIP, that the routing tables > are there and ready to answer you and so on. > 2) you don't see anymore if a fragment is lost 'til it's too late. Plus > you'll need timers to handle the fragment timeout, like IPv6 does, > 3) more headaches I've forgotten. > > So, design choices. The one I love less to be honest, as the answer is > always the same: try 'em all, and it means that I'll have to implement 'em > all. > > BTW, if you're wondering... I'm implementing 6LoWPAN for the ns-3 network > simulator, so my questions are due to the fact that I need to be close > enough to what has been implemented to be realistic, but I need as well to > be able to explore other design choices. My reference atm is Contiki as we > do have a small testbed (a real one) with Contiki operated nodes. I know > Cooja can simulate nodes, but again, there are a number of reasons to use a > more general network simulator. > Moreover I have a scientific project going on that will use WSN with IPv6, > and we need to evaluate the design choices we can do for it. > > Anyway, thanks for your time. More code to write, not a biggie. > > Cheers, > > Tommaso > > > On 13 Jan 2012, at 19:26, Colin O'Flynn wrote: > > Ciao Tommaso, > > As I haven’t seen anyone else talk about this, thought I’d take a stab… > > #1) Mesh-over isn’t a normally used phrase I know of. Normally it’s > referred to either as mesh-under, where mesh routing is done at the layer > below IP (MAC basically), or route-over, where routing is done at the IP > layer. > > #2) The choice to pass the fragments all along as-is or not depends on a > lot of things. It’s more efficient in general to just pass the fragments > along, especially if you will only be using mesh-under. But if your code > might support route-over, you need to reassemble at every hop. So perhaps > the reasoning in Contiki is that because we support both, it’s easier to > just have one code-base. > > There are other trade-offs too. Reassembling at every hop would tell you > when you’ve lost a packet and are screwed, so can just stop forwarding the > frame. One could make the case this lessens the burden of suffering from a > malfunctioning/poorly linked node which never sends complete fragments, > since only the node closest to this malfunctioning node wastes it’s time > waiting for frames which never arrive. The rest of the network is shielded > from these incomplete frames. I’m not saying that is the reason to always > reassemble at every step, but there is advantages to each side… > > Warm Regards, > > -Colin O’Flynn > > *From:* Tommaso Pecorella [mailto:tpe...@me...] > *Sent:* January 12, 2012 6:23 PM > *To:* con...@li... > *Subject:* [Contiki-developers] 6LoWPAN fragmentation and reassembly > > Hi all, > > noobie question, but ... I'm puzzled about how reassembly is done in > 6LoWPAN. > > If I read right the code, all the nodes are reassembling a fragmented > packet, then sending it again (possibly fragmented). > > Any specific reason about not sending it as it is, (i.e., already > fragmented) and leaving the reassembly burden to the final destination ? > > Of course I'm referring to a mesh-over case. > > Thanks, > > > Tommaso > > > ----------------------------------------------------------------- > > Tommaso Pecorella - Ph.D. > > > > Assistant professor > > Dpt. Elettronica e Telecomunicazioni > > Università di Firenze > > > > CNIT - Università di Firenze Unit > > > > via di S. Marta 3 > > 50139, Firenze > > ITALY > > > > email: tom...@un... > > tom...@cn... > > > > phone : +39-055-4796412 > > mobile: +39-320-4379803 > > fax : +39-055-494569 > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > > http://p.sf.net/sfu/rsa-sfdev2dev2_______________________________________________ > Contiki-developers mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/contiki-developers > > > -------------------------------------------------------------- > > Thinking evolution: > "To be is to do" - Socrates > "To do is to be" - Sartre > "Do Be Do Be Do" - Sinatra > "Scooby Dooby Do" - Scooby Do > "Yaba Daba Doo!" - Fred Flintstone > > -------------------------------------------------------------- > > Tommaso Pecorella - Ph.D. > > Assistant professor > Dpt. Elettronica e Telecomunicazioni > Università di Firenze > > CNIT - Università di Firenze Unit > > via di S. Marta 3 > 50139, Firenze > ITALY > > email: tom...@un... > tom...@cn... > > phone : +39-055-4796412 > mobile: +39-320-4379803 > fax : +39-055-494569 > > > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Contiki-developers mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/contiki-developers > > |