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: 6lowpan@ietf.org >>>> 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: 6lowpan@ietf.org >>>>>>>>> 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 >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> >>>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan
