Yes let me participate to the next 6TiSCH interim. I'll be also at the plugtest. Will be much easier over voice ;) Thanks, Simon
On Wed, Jan 20, 2016 at 8:54 AM, Pascal Thubert (pthubert) <[email protected]> wrote: > Our messages crossed, Simon. > >> - IPv6 stack interacting with the adaptation layer > > I'm not sure I agree with that (see my other mail), but if you're correct I > really what to dig that and fix it. Please read the other email I just sent > and if you still see that the mapping is not there then please refine what > the issue is exactly. > > >> - No one-to-one mapping between a RH3-6LoRH and a RH3 > > We can reconstruct an RH0 form from RH3 and from RH3-6LoRH, and recompress an > RH0 into both as well. I fail to see what the problem is though I do hope > that implementations never need to play that game. When the packet goes up > the stack, the RH3-6LoRH should be gone, removed by the last router (which > may be collocated). > > Would you be willing to participate to the next 6TiSCH interim? We'll discuss > that topic since it impacts the plugtest. > > Cheers, > > Pascal > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Simon Duquennoy >> Sent: mercredi 20 janvier 2016 08:44 >> To: Michael Richardson <[email protected]> >> Cc: Pascal Thubert (pthubert) <[email protected]>; [email protected]; >> Routing Over Low power and Lossy networks <[email protected]>; Tengfei Chang >> <[email protected]>; [email protected] >> Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH >> >> Right, I'm using the wrong wording, I counted RFC6554 as RPL, sorry for the >> confusion. >> >> What I don't like: >> - IPv6 stack interacting with the adaptation layer >> - No one-to-one mapping between a RH3-6LoRH and a RH3 >> >> If I'm not mistaken, everything else in 6lowpan offers this one-to-one >> mapping, and that allows the IPv6 stack to work independently of 6lowpan >> (i.e. the same stack runs both in 6lowpan environment or not). >> I also find this property nice, conceptually, as one can produce any >> IPv6 packet and easily derive its compressed form, and back. One header >> maps to one compressed header with all its fields compressed, etc. >> >> If I'm the only one to think this is an issue, I'm ready to close the issue. >> >> Thanks, >> Simon >> >> >> On Tue, Jan 19, 2016 at 11:06 PM, Michael Richardson >> <[email protected]> wrote: >> > >> > Simon Duquennoy <[email protected]> wrote: >> > > Not really. It was rather my view of the architecture that differs a >> > > bit from what you describe in your previous mail. >> > >> > okay. >> > >> > > For me RPL produces the RH3 and then passes the packet down the >> stack >> > > for compression. Or for incoming packets, first there is >> > > decompression, then the IPv6 packet with its headers and extension >> > > headers are passed up to RPL etc. If find it odd to force upper >> > layers >> > > to work on 6lowpan compressed formats. >> > >> > RPL is the thing in RFC6550, a routing protocol, that runs over ICMP ND >> messages. >> > >> > I think the thing you are describing is the IPv6 stack, and you don't >> > like that the IPv6 stack has to interact with the link adaptation layer. >> > >> > -- >> > Michael Richardson <[email protected]>, Sandelman Software >> Works >> > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
