Hi,
Needless to say, I see that there may be some uses for the mesh header
in particular cases. Of course we need to keep it there for now. Later
on (2009 e.g) it should however really be checked if anyone is using it.
Maybe in order to clarify the viable use of the mesh header, and to
avoid confusion with route over, draft-culler-6lowpan-architecture-00
could describe when and how it should be used in more specifics. Now the
draft points out the limitations and realities of mesh header usage
quite well. Could it go one step further, and define one viable, useful
way to use the mesh header. The only time I see mesh under being useful
as we stand, is when the L2 technology already sets up a topology that
includes all needed forwarding information and messaging to maintain it.
802.15.4 in beacon mode, with a tree topology, achieves that. Why don't
we just limit the scope of mesh under for this case? Then we avoid tons
of ambiguity. I think this draft would be the place to at least
recommend this usage.
The problem I see is that the WG has put too much emphasis on mesh-under
in assumptions made in most drafts assuming it will be used most
often. Whereas in reality it will likely be the exception, used only in
cases like the one mentioned above. For routing between PANs, or without
sufficient L2 forwarding information - we should recommend route over
and work closely with ROLL to support that paradigm.
So I recommend that the architecture draft (and routereq draft) should
be more explicit:
1. For complete broadcast domains, nothing needed.
2. For full-featured 802.15.4 beacon-mode networks, in a strict tree
topology, forming a single PAN - you can use mesh under to form a single
IP link. We should also explain how to do it in sufficient detail (could
be done in dokaspar-6lowpan-routereq). ND optimizations should support
this setup of mesh under.
3. For anything else (e.g. ad-hoc 802.15.4 networks), we recommend the
use of L3 routing. For standardized routing algorithms see ROLL. ND
optimizations and future HC improvements (e.g. IPv6 routing header
compression suggested by Pascal) should support RO usage.
4. Experimentally you could use mesh-under with other L2 technologies or
setups that maintain sufficient forwarding information, or in
hybrid-mesh setups (note the dangers in hybrid-mesh from the
architecture doc).
- Zach
Geoff Mulligan wrote:
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
--
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
