Net2WG/Notes/20071207
- page was renamed from Net2WG/Notes
Contents
Net2WG/Notes Meeting Notes
Agenda
* Commits * 6LowPAN * ZigBee * Collection
Participants
* Om, USC * Phil, Stanford * Rodrigo, UCB * Arsalan, UCB * Razvan, JHU * Mike, JHU * Matus, ETH
Discussion Notes
Commits
Om: Let’s talk about commits. I committed 2 changes…one I made the signature compatible for both link estimators. Two, I committed a fix to the CTP routing engine.
6LowPan
Matus: I committed the 6lowpan code, with the implementation for the mote and the daemon for the PC, along with a sample application. The sample application allows you to do ping, and listens on a sample port where it will echo responses.
Phil: I was looking at the code and I was concerned about the use of network types. Packets are automatically packed..as 16-bit words are not byte addressable on the msp430. So basically, stay away from the packed attribute and use nx structs.
Matus: I tried that, but it didn’t look as I had expected to, extra bytes were being interwoven.
Phil: We’ll take a look at the code, but nx structs were used for this, to be able to access things as structs without dealing with the byte aligned issues.
… Cross talk about merits of using nx-structs…
Matus: How difficult would it be to replace active messages with 6LowPAN? I just want to use 6LowPan and UDP ports, rather than active messages?
Razvan: I think it will require making changes in the internals, where only raw buffers are passed, rather than the active message structures. Technically, you could use active message structures and only use payloads, and demultiplex yourself.
Rodrigo: But Active messages are single-hop link layer messages, while 6LowPAN is a multihop end-to-end protocol. There is an interface mismatch.
Phil: So what is your concern?
Rodrigo: I’m just saying although they may look similar or interchangeable now, once IP has been introduced, I don’t think they are conceptually interchangeable anymore.
Matus: But aren’t they conceptually the same?
Rodrigo: No, multi-hop and single-hop are quite different, even if they are currently not exposed differently (which is a problem in my opinion).
Phil: I’m not sure from a UDP standpoint that this really makes that much of a difference for us. I mean certain interface details should be different (like acknowledgements and timing), but conceptually I’m not sure.
Rodrigo: You can make certain inferences from active messages (such as neighbors), that you can’t from IP messages.
Phil: 6LowPAN won’t have an active message send interface, nor will it have acknowledgements, at least not in the same format. I think Rodrigo’s point is well taken, that we shouldn’t make this look like Active messages, as they are not the same, although they may share some similarities.
Matus: Potentially we could introduce a compatibility layer component.
Rodrigo: Active message channels and UDP ports are similar, but I think it’s a mistake to say they’re the same.
Phil: My concern is the UDP client interface, which combines the send and receive interface, which might be good or bad, not sure, but we should at least talk about it.
- Cross talk about viability of this option, and different T2 mechanisms for supporting such a design methodology
Phil: So I think we can conclude that you can’t get AM to work alongside 6LowPAN because of an assumed packet format. So I think the consensus was, in TEP 125 I believe, that we would use a dispatch byte to allow the selection of a packet format. I think David Moss is a good person to talk with about this.
ZigBee
Om: Let’s move on to ZigBee. I believe Andrea is ready to start listing the files, and upload the files. We need to just discuss a directory breakdown, as we can’t have everything in one folder. A list of files should be on, hopefully by next week.
Collection
Om: Moving on, collection update. One of the problems that we had with the CTP protocol is that we’re seeing some duplicates and loops, much more so than Multihop LQI, on the USC testbed. We’re not quite sure why this is happens. If the estimator is agile, then it makes sense, but we’re seeing it even when the estimator isn’t agile.
Phil: I think a key takeaway is that we shouldn’t judge a protocol that is supposed to last for a long time simply by what it does in the first 10-30 minutes.
Om: What about stuff or next week? Rodrigo has beaconing frequency, look at the different alpha values on Mirage.
