Subject: Re: [6lowpan] 6lowpan Digest, Vol 38, Issue 15

From: "Dhananjay Singh" <[email-masked]>
Date: Mon, 10 Mar 2008 13:28:47 +0900

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-masked] <[email-masked]> wrote:
>
> Send 6lowpan mailing list submissions to
>         [email-masked]
>
> 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-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> 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-masked]>
> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
> To: "Pascal Thubert (pthubert)" <[email-masked]>
> Cc: 6lowpan <[email-masked]>
> Message-ID: <[email-masked]>
> 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-masked]]
> >> 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-masked]>
> Subject: Re: [6lowpan] HC1g and HC2g
> To: "Pascal Thubert (pthubert)" <[email-masked]>
> Cc: Jay Werb <[email-masked]>, 6lowpan <[email-masked]>,
>         [email-masked]
> Message-ID: <[email-masked]>
> 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-masked]>
> Subject: [6lowpan] agenda
> To: 6lowpan <[email-masked]>
> Message-ID: <1204869162.24625.17.camel@dellx1>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>
> End of 6lowpan Digest, Vol 38, Issue 15
> ***************************************
>
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Philip Levis <[email-masked]>
Date: Mon, 10 Mar 2008 10:12:14 -0700

On Mar 9, 2008, at 9:28 PM, Dhananjay Singh wrote:

> Dear Friends,
> I am Dhananjay Singh from India 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

The tinyos lists (e.g., tinyos-help) might be a better place for this  
question (cc'd).

There is a 6lowpan stack in the TinyOS CVS tree; the plan is to  
include it in the next release (2.1). Note that currently, as  
written, it is not actually interoperable with other 6lowpan stacks.  
Doing so requires shifting TinyOS from T-Frames to I-Frames (TEP  
125), in order to respect the 6lowpan dispatch byte. This topic is on  
the core WG's agenda for next week. The implementation in tos/lib/net/ 
6lowpan currently implements most of 4944 on top of TinyOS's active  
message layer.

If you have questions about the implementation, you should email  
tinyos-help or the developer (Matus Harvan).

Phil