Hi Pascal,
On 5/22/08 12:47 AM, "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> 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. Well you just saw my reply to the other email, we're in sync. 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 . > Considering the quick progress we hope to have something soon. > 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. Sharing your view. > > 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. This would be worth having a discussion on this, probably a specific thread. > - specify a fragment flow control and recovery protocol at the 6LoWPAN > Shim layer Will reply to this in another email thread. > 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). Mmmm "Subnet" please. > This is more theoretical work for us. Related to proxy ND, a new > registration protocols, multilink subnet, etc... Thanks. JP. > > 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
