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
