Pascal, On Thu, 2008-05-22 at 09:47 +0200, 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. > I'm not completely positive that this is true, but I do think that it is not in the scope of 6lowpan right now.
> 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 . > I have to disagree. While the system manager can choose some routing options, my understanding of the ISA100 DLL is that it does offer a mesh under layer 2. > 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'. And this still needs to be discussed in ISA100. I'm not sure that a NALP is the correct header and we have had this discussion in ISA100. I'm hoping that this will be corrected in a subsequent draft. > > 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 I don't think that these are all mandatory. The problem with the current ISA100 draft is that there was a clear statement that ISA100 would be compliant with 6lowpan and the application layer has chosen not to be compliant and to try to push changes into 6lowpan to make 6lowpan compliant with ISA100. There is some concern that has been expressed that we are prematurely optimizing the headers. I'm not convinced that the benefits of saving 3 bytes outweighs un-thought-of issues that might come about because of these optimizations. > - 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. I'm not sure that 6lowpan should specify this. I think that is what a nalp is for. The bits following it are unknown. I think that ISA100 should apply for a dispatch value and should include a dll header length so that it can be skipped. > - 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
