Geoff Mulligan wrote: > Mark, > this is interesting news. This can save another byte and if there > would be no large push against this then compressing out another byte > would be good. > I can't promise anything, but 6lowpan certainly isn't the only place where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty much any UDP-based tunneling protocol running on a router in hardware at high scale or speeds is running into the same problem. I know of implementations today that zero out the UDP checksum, and IMHO a good implementation that is "liberal in what it accepts" would not drop the packet with a zero UDP checksum arriving over IPv6 (in fact, its annoying that one would even have to differentiate between IPv4 and IPv6 at all here if you ask me). > This is currently in the HC1g draft and would allow consistency between > 6lowpan and SP100. > I suppose that isn't a bad thing.
- Mark > geoff > > On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: > >> Geoff Mulligan wrote: >> >>> Aren't both abstractions equally valid? I think that the biggest issue >>> with a mesh under is that there is no one standard for it. ISA100 is >>> one; I have done another using AODVtiny; I think Jennic has one using >>> their mesh protocol and there are others. If IEEE had defined a >>> multi-hop L2 mesh then we could point at that and define a solution for >>> ND and bootstrapping and security and ... for it. >>> >>> The WG decided a couple of meetings ago that we would focus on solutions >>> for the Route Over abstraction. [If while we are doing this we can keep >>> in mind some of the issues w.r.t. mesh under that's good.] >>> >>> Somewhat independent from this is the HC1G draft that is important to >>> deal with since we do need a way to efficiently handle non-local >>> addresses. So as to remove the mesh under vs. route over issues from >>> the HC1G draft I would like to see the draft updated to remove the UDP >>> checksum optimization. >>> >>> >> I'm more optimistic about keeping the UDP checksum optimization. There >> are other forces at work which may relax the UDP checksum requirement in >> IPv6 in certain cases. So as long as you have well thought out >> reasoning, I wouldn't be afraid of keeping it in. >> >> - Mark >> >>> I would like to ask the WG if we should consider taking >>> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of >>> removing the UDP checksum compression. >>> >>> geoff >>> >>> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: >>> >>> >>>> Hi Pascal, >>>> >>>> So let's drop the mesh-under/route-over terminology for a second, I >>>> think they are confusing since everyone seems to have a different >>>> definition for those terms. >>>> >>>> What I am mainly concerned about is the kind of IP Link abstraction >>>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. >>>> 802.15.4 and possible others through a BbR), what I've been calling >>>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >>>> radio range of 802.15.4), what I've been calling route-over. My point >>>> to Mark's concern was that solutions to some work items within 6LoWPAN >>>> will be different depending on our IP Link abstraction. From what I >>>> understand, ISA100.11a has chosen option (i). But to your point below, >>>> using IP routing to provide connectivity between nodes within the same >>>> IP Link doesn't seem right to me, so it'd be great if you could help >>>> me see a path to get there. >>>> >>>> A lot of this confusion can be cleaned up within the 6LoWPAN >>>> architecture document. But I think Mark's concern still stands: >>>> whether or not we're focused on one or both of these IP Link >>>> abstractions. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >>>> >>>> >>>> >>>>> Hi: >>>>> >>>>> My understanding is that defining how mesh-under computes its routes >>>>> is >>>>> out of scope for the IETF overall. I'm not even sure we need to >>>>> document >>>>> requirements in that space. It's good that we push some requirements >>>>> to >>>>> ROLL on route-over, and that's certainly the right time to do so. >>>>> >>>>> To Jonathan: I do not completely agree that ISA100 is mesh under. The >>>>> routing is not specified and left to the system manager >>>>> implementation. >>>>> My personal hope is to promote a ROLL solution in ISA100.11a next >>>>> release. See >>>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>>>> >>>>> So the current release of ISA100.11a is at the same level as 6LoWPAN >>>>> on >>>>> the matter of routing. >>>>> >>>>> In a same fashion, ISA does not define the backbone operation, the >>>>> fragment recovery mechanism or the Explicit Congestion Notification. >>>>> For >>>>> all those features, there's a hope at ISA that the IETF will come up >>>>> with more generic solutions that they can apply. But time is running >>>>> out. >>>>> >>>>> 6LoWPAN hasn't produced anything for the last 6 months. At this rate, >>>>> ISA will have to define everything on its own and hopefully publish an >>>>> informational to this group. >>>>> >>>>> At the moment, the first draft of ISA100.11a is in letter ballot. The >>>>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >>>>> which >>>>> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN >>>>> so ISA is using NaLP headers starting with b'00'. >>>>> >>>>> What ISA needs from 6LoWPAN in very short term is in that order: >>>>> - promote Jonathan's draft as a convergence specification so ISA can >>>>> at >>>>> least use standard HC headers. >>>>> This enables: non-Link-Local-Address compression >>>>> Hops limit compression >>>>> UDP checksum compression >>>>> Better placement of HC2 >>>>> Which are all mandatory for ISA100.11a >>>>> - better define the NaLPs. >>>>> There should be a way to indicate to a 6LoWPAN node whether a NaLP >>>>> can >>>>> be skipped and what its length is. >>>>> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes >>>>> to report congestion. >>>>> - specify a fragment flow control and recovery protocol at the 6LoWPAN >>>>> Shim layer >>>>> There is no rocket science in any of this and it all could/should be >>>>> carried out swiftly. >>>>> >>>>> What ISA needs in longer term: >>>>> - define backbone operation when the backbone federates multiple >>>>> LoWPANs >>>>> into a single link (or subnet, TBD). >>>>> This is more theoretical work for us. Related to proxy ND, a new >>>>> registration protocols, multilink subnet, etc... >>>>> >>>>> Pascal >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >>>>>> >>>>>> >>>>> Behalf Of Jonathan Hui >>>>> >>>>> >>>>>> Sent: jeudi 22 mai 2008 00:20 >>>>>> To: Mark Townsley (townsley) >>>>>> Cc: [email protected] >>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>> >>>>>> >>>>>> Hi Mark: >>>>>> >>>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>>> >>>>>> >>>>>>>> - To your point on ND, this is precisely why the architecture draft >>>>>>>> is so important. We haven't given it as much attention lately, but >>>>>>>> it will help resolve the question your raise and many other >>>>>>>> questions in the future. For example, the architecture draft >>>>>>>> identifies two modes of operation: mesh-under and route-over. Both >>>>>>>> of which may require different ND mechanisms. This doesn't apply to >>>>>>>> just ND, but may apply questions of fragmentation, header >>>>>>>> compression, security, etc. >>>>>>>> >>>>>>>> >>>>>>> I worry about the under/over debate. It seems that with all the >>>>>>> effort and enthusiasm in ROLL, we might be well-served at the moment >>>>>>> by focusing on helping them be successful with route-over than >>>>>>> spending too much of our time on route-under. >>>>>>> >>>>>>> >>>>>> I worry too, especially since it will pull the WG in different >>>>>> directions. I'm with you on the preference for route-over, but others >>>>>> in this group feel strongly about mesh-under as well, especially >>>>>> since >>>>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>>>> personally been focused on developing route-over solutions while >>>>>> being >>>>>> conscious of supporting mesh-under when possible (evident with >>>>>> 6lowpan- >>>>>> hc). However, things will start to diverge when we start to talk >>>>>> about >>>>>> bootstrapping, ND, etc. So we should make a conscious decision of >>>>>> whether we're supporting one or both. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> >>>>>>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>>>> coordinators)") especially since the definition of such link >>>>>>>> mechanisms are still in motion within the IEEE. It seems more >>>>>>>> productive to me if we can develop mechanisms that are less >>>>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>>>> >>>>>>>> >>>>>>> I agree that we should develop mechanisms that could work >>>>>>> generically whenever possible. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> >>>>>>>> Rest of the charter looks good to me. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Mark: >>>>>>>>>> >>>>>>>>>> I think we need a work item (usually implicit) around the concept >>>>>>>>>> of >>>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>>>>>> aspects: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>>>>>> to >>>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>>>>>> given. >>>>>>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>>>>>> RFC >>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>>>>>> resolve >>>>>>>>>> for the most part. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager >>>>>>>>> >>>>>>>>> >>>>> to >>>>> >>>>> >>>>>>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>>>>>> interoperability. >>>>>>>>> >>>>>>>>> >>>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>>>>>> radio >>>>>>>>>> mesh exposes the network to congestion collapse, as described in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>> >>>>> >>>>>>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>>>>>> provide >>>>>>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>>>>>> flow >>>>>>>>>> control and recovery of fragments. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>>>>>> rather >>>>>>>>> than a transport layer issue? >>>>>>>>> >>>>>>>>> >>>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>>>>>> It >>>>>>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>>>>>> implement >>>>>>>>>> the concept in the IPv6 world. This partially falls under the >>>>>>>>>> first work >>>>>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>>>>> which is a >>>>>>>>>> stretch to the work item. More in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>> >>>>> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>>>>> before we >>>>>>>>> decide whether it needs to be proxied or not? >>>>>>>>> >>>>>>>>> - Mark >>>>>>>>> >>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Pascal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>>>>>>>>>> On >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Behalf Of Mark Townsley >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> (townsley) >>>>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>>>> To: [email protected] >>>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'd like to ask the group one final time for comments on the >>>>>>>>>>> proposed >>>>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>>>>> >>>>>>>>>>> As I said before, soon after the format document was published, >>>>>>>>>>> there >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>>>>>> existing >>>>>>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>>>>>> should be >>>>>>>>>>> in and out of the charter. Please do not construe not having a >>>>>>>>>>> charter >>>>>>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>>>>>> that need >>>>>>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>>>>>> before >>>>>>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>>>>>> discussions when creating new WG charters. >>>>>>>>>>> >>>>>>>>>>> - Mark >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> >>>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> > > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
