Dear Friends, I am Dhananjay Singh from I*ndia but now a days* i am doing my research work at in Ubiquitous Sensor Laboratory, Dongseo University Busan Korea Friends, i am working on ip-based Wirelesss Sensor Networks so i have to need 6lowpan stack for telosb mode on tinyos2.02 OS firstly i want to test communication between two teloseb modes.if anybody have stack code on 6lowpan then let me know....... thanks in advance! with best regard's Dan
On 3/8/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Send 6lowpan mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/6lowpan > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 6lowpan digest..." > > > Today's Topics: > > 1. Re: Compressing HC1 and HC2 into HC3 (Jonathan Hui) > 2. Re: HC1g and HC2g (Jonathan Hui) > 3. agenda (Geoff Mulligan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 06 Mar 2008 15:48:40 -0800 > From: Jonathan Hui <[EMAIL PROTECTED]> > Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > To: "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> > Cc: 6lowpan <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Hi Pascal, > > I've asked for a time slot to talk about HCx and will incorporate stuff > we've been discussing so far. We can bring up the discussion of further > compressing the HC's there as well. > > -- > Jonathan Hui > > > Pascal Thubert (pthubert) wrote: > > Hi Jonathan: > > > > I'm can't wait to see the proposal that saves the 3 additional bytes as > > we discussed turn into a WG doc, and that would be the priority. I'm > > also concerned that the 3 bytes be elided when the addresses are link > > local because that's the current use in ISA100, though I'm pretty sure > > we could use HC1G there. > > > > I think that the work on compressing the HCs themselves is also > > important because each byte in the headers is a percentage of > > battery-life (or something). And that's mostly orthogonal work. They > > intersect if: > > > > - we need to delay HC3 till HC1's are well defined > > - We're missing dispatch bits. > > > > So I still wish to have the question discussed in Philly if that's > > possible within constraints... > > > > Pascal > > > >> -----Original Message----- > >> From: Jonathan Hui [mailto:[EMAIL PROTECTED] > >> Sent: jeudi 6 mars 2008 17:29 > >> To: Pascal Thubert (pthubert) > >> Cc: 6lowpan > >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 > >> > >> > >> Hi Pascal, > >> > >> Given that it looks like we can include two of your three proposals > > into > >> HC1g, I'm not so sure whether defining a new format adds that much > >> benefit. Adding the ability to elide the UDP checksum and the hop limit > >> into HC1g already provides 3 bytes of savings. Compared to your > > proposed > >> modifications to HC1g, HC3 only saves one byte (which you've observed). > >> I'll put this idea out now, but I believe HC1g has the potential to > >> supersede HC1+HC2. Really, we should rename HC1g to be something like > >> HCx since it's not really specific to routable addresses. > >> > >> My alternative proposal is as follows: > >> - Use the HCx format for both link-local and non-link-local > > communication. > >> - Define a dispatch HCl when communicating with link-local addresses. > >> - Define a dispatch HCr when communicating with routable addresses. > >> > >> The reason why I'm pushing for a single format is that I believe the > >> most optimized code will work with the format directly to save RAM and > >> code. That means that 6LoWPAN nodes generally do not expand compressed > >> datagrams into uncompressed datagrams and the other way around. Thus, > > it > >> involves more than just the encoder/decoder functions and could involve > >> the entire stack (including the application). > >> > >> What do you/others think? > >> > >> -- > >> Jonathan Hui > >> > >> > >> Pascal Thubert (pthubert) wrote: > >>> Hi Jonathan and all: > >>> > >>> I'd wish to move forward on the original subject for this thread. > >>> > >>> Basically the question is whether it is worth consuming a dispatch > > for > >>> an HC3 that would represent the best case of what HC1 and HC2 can > >>> compress. > >>> > >>> Pros: saves one byte in the headers and a fast path in the code > >>> Cons: Additional encoding complexity and one dispatch. > >>> > >>> On the side, there's a compression mechanism coming up for ULA/GLO > >>> (HC1g). > >>> Can we make HC3 ready for that upcoming mechanism? Should we wait? > >>> > >>> I'll ask Geoff if some discussion can happen in Philly to conclude on > >>> the topic. > >>> > >>> Pascal > > > ------------------------------ > > Message: 2 > Date: Thu, 06 Mar 2008 15:51:59 -0800 > From: Jonathan Hui <[EMAIL PROTECTED]> > Subject: Re: [6lowpan] HC1g and HC2g > To: "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> > Cc: Jay Werb <[EMAIL PROTECTED]>, 6lowpan <[email protected]>, > [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Hi Pascal, > > Pascal Thubert (pthubert) wrote: > >> Rather than having the Next > >> Hop field be in potentially three different places, how about this > > idea: > >> Leave the L4C bit in HC1 as before, but rename it to NHC for > > next-header > >> compression (if NHC is 0, then the Next Header field is carried inline > >> and no HC2 header appears; if NHC is 1, then an HC2 header follows). > >> Then we define a HC2_UDP as follows: > >> > >> 0 1 2 3 4 5 6 7 > >> +-+-+-+-+-+-+-+-+ > >> |0|S|P|C| rsv | > >> +-+-+-+-+-+-+-+-+ > >> > >> The difference here is that we fix the first bit as '0' for UDP and > >> leave compression mechanisms for other Next Header values undefined for > >> now. As we define new NHC compression mechanisms, they can be added by > >> setting the first bit to '1' and some other bit-pattern following. It's > >> a huffman-style encoding, but we're just assuming that UDP is going to > >> be the most common case, so we give it the best case. > >> > >> I've also taken out the 'L' option, opting to say that UDP length > > should > >> always be elided and derived from lower layers, just as we've done with > >> the IP header. > > > > [Pascal] I love it. Note that it's too bad that UDP comes first in this > > encoding though it needs few bits... So the hop limit compression now > > resides in one of the 2 freed NH bits and the other one is reserved, > > right? > > It is too bad that UDP needs only a few bits. But there are ways to > utilize those extra bits :-). If you mean the hop limit compression > resides in one of the freed HLIM bits, then that's correct. > > -- > Jonathan Hui > > > ------------------------------ > > Message: 3 > Date: Thu, 06 Mar 2008 22:52:42 -0700 > From: Geoff Mulligan <[EMAIL PROTECTED]> > Subject: [6lowpan] agenda > To: 6lowpan <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > The agenda for the 6lowpan wg meeting has been posted to ietf.org. > > Sorry for it being late. I actually posted earlier, but forgot to send > out this message. > > geoff > > > > > ------------------------------ > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > > > End of 6lowpan Digest, Vol 38, Issue 15 > *************************************** >
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
