Hi Zach: The way I understand it:
ISA100.11a defines its own mesh header at the Data Link (DL) layer. Mesh header not considered to belong to 6LoWPAN in that architecture so we ignore it. Out of my head, ISA can forget about RFC 4944 if 6LoWPAN standardizes fragmentation, HC with ECN and Carsten's proposal to skip unknown headers. Note that ISA needs the current capabilities to compress addresses that are not EUI LLAs, the network hop limit and the transport checksum. ISA would also apreciate other work like asserting the need for fragment recovery and providing a solution if the need is established. Finally, ISA100.11a is open to leave the path computation to a L3 process, though it should probably be offline. For the current release, this is going to be unspecified and left to the implementation of the system manager, but hopefully a solution out of ROLL can be standardized in some future. Pascal >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zach Shelby >Sent: lundi 21 juillet 2008 09:15 >To: 6lowpan >Subject: Re: [6lowpan] Mesh-header, do we need it anymore? > >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? > > - Fragments are not reassembled at intermediate hops. > >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. > > - 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. > >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? > >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. > >- 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
