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 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
