I don't think that we should or need to remove the mesh header. I think
that there is a use for it (Sun is using it with sunspots).
It would seem that you could use some layer 2 packet to determine
forwarding information and then use the mesh header to create a single
layer 2.5 link for all the nodes on the pan - I think that this is what
sun does.
I'm experimenting with passing the routing information inside the ip
packet and then still using the mesh header to create single link layer
in the pan (I guess this is a hybrid of route over and mesh under -
Route Over Mesh).
I do not want to see the mesh header deprecated.
geoff
On Mon, 2008-07-21 at 12:07 -0700, Jonathan Hui wrote:
> Hi Zach,
>
> On Jul 21, 2008, at 12:14 AM, Zach Shelby wrote:
> > Thanks for the feedback everyone. I'll just summarize here what
> > feedback I've gotten so far. Still waiting or more reasons we need
> > the mesh-header, and feedback from others who have implemented and
> > are using mesh-header forwarding.
> >
> > So far then we have 2 features the mesh-header allows:
> >
> > - Specification of intermediate destination (e.g. a particular BbR),
> > but this comes at the cost of mesh-header + HC dst address for
> > addressing outside the lowpan. Does the current BbR actually require
> > this wrt the primary router?
>
> Agreed. From what I understand, the current BbR draft makes one or
> multiple PANs appear as a single IPv6 link. As a result, the BbR draft
> assumes L2 forwarding and because packets transported over the
> backbone link do not carry the mesh addressing header, they must be
> reassembled at a single BbR before forwarding over the backbone.
>
> > - Fragments are not reassembled at intermediate hops.
>
> It's more appropriate to say that all fragments for a given datagram
> must follow the same path. Complete reassembly does not need to happen
> at every hop.
>
> > Are there some down-sides to doing IPv6 routing inside the lowpan?
> >
> > - Fragments must be "reassembled" at each router in the lowpan. Not
> > necessarily a bad thing, could allow for hop-by-hop recovery.
>
> In addition to hop-by-hop recovery, it's also easier to optimize L2
> for burst transmissions along a single path.
>
> > - We may have IPv6 ND issues if each node in the lowpan is an IPv6
> > router. We need to differentiate between lowpan IPv6 routers (LpR?)
> > and BbRs. IPv6 routers inside the lowpan should not e.g. send their
> > own RAs.
>
> I'm working on an ND draft that addresses this problem, but probably
> won't get it done in time for the meeting.
>
> > As far as I understand ISA100 could just as easily use HC to achieve
> > the routing options it has in mind. Geoff, Pascal, is this correct?
> >
> > Pete had a good point about not prematurely depreciating something
> > that works and is in use. However I would still like to hear who is
> > really using it. I have an understanding there is actually quite
> > equal implementation and deployment experience for both IPv6 routing
> > and mesh-header forwarding inside lowpans at this time. I would say
> > both work fine. However we don't have a standard algorithm for mesh
> > forwarding (and are not going to get it), so what happens when ROLL
> > algorithms come into use?
>
> Right. And from what we've seen so far, others that are defining L2
> forwarding mechanisms are circumventing the mesh addressing header by
> defining their own...
>
> > For example, our forwarding algorithm could just as easily store the
> > src+dst+hopcount in the IPv6 header using HC as in the mesh-header
> > as now without penalty. In practice in limited nodes lowpan and IPv6
> > are processed and implemented together, it is really a very small
> > implementation detail whether to look at the mesh-header or HC IPv6
> > header for the dst address, and then consult your routing table for
> > the next hop.
>
> That's pretty much what we do today. End nodes have to be able to
> generate/process IPv6 headers anyway. Needing to process the mesh
> addressing header only adds to the resource requirements.
>
> --
> Jonathan Hui
>
> >
> >
> > - Zach
> >
> >
> > --
> > Zach Shelby | Head of Research | +358 40 7796297
> > Sensinode Ltd. www.sensinode.com
> > _______________________________________________
> > 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
