IEEE 802.15 -12-0347-00-0l2r

1. IEEE 802.15-12-0347-00-0l2r • Project: IEEE 802.15 Layer 2 Routing Interest Group • Submission Title:Mesh Under Routing in a 15.4e/6LoWPAN Stack • Date Submitted: 13 July, 2012 • Source:Jonathan Simon, Linear Technology • Address: 30695 Huntwood Ave, Hayward CA • E-Mail: jsimon@linear.com • Re:Layer 2 Mesh Routing • Abstract:Discussion of using Header IE’s to encapsulate Mesh Routing information • Purpose:Discussion • Notice: This document has been prepared to assist the IEEE 802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. • Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. Motivation • Why Mesh-under? • If the goal is to build an extremely low power, reliable, 802.15.4-based wireless mesh networks, energy should be spent on data communications, not route discovery. • The primary advantage of a mesh-under approach is it allows routes to be centrally managed – there is no device overhead for route discovery and maintenance, since L2 connectivity is the only thing that needs to be forwarded to the mesh controller. • Other approaches (802.15.5, 6LoWPAN RPL) push route management to the constrained, low power device. • Marriage to other standards • Mesh under approaches have been disfavored as “proprietary” – desire for operation with L3 standards has pushed routing into the 15.4 network – but an Ethernet IP network and a 802.15.4 low-power network have different constraints.

3. Problems marrying 802.15.4 to 6LoWPAN • RFC 4944/6282 require that first byte after MAC header be a dispatch byte defining the first 6LoWPAN header. • RFC 4944 only provides for a mesh header that contains a 4-bit “TTL” and addressing info, but no real routing (a broadcast header can be used for flooding) or other features. • For low power operation, overhead spent on sending messages to multi-hop peers for route discovery is energy wasted. • Mesh routing and IP routing may have different considerations – if you’re going through a border router anyway, why not tailor routing to what you’re actually routing over.

4. L2 routing using Header Information Elements • The Header Information Element (IE) is considered part of the L2 header, so it works from a 6LoWPAN dispatch perspective. • IE’s are just Tag/Length/Value descriptors – easy to add into a header, and possible for devices to ignore if unrecognized. • 15.4e defines “unmanaged” IE spaces, so an IE can be created without rev’ing the standard. Consensus on what should be in a header can be reached, and evaluated in a compliant network, then formalized into a currently reserved IE. • Route management becomes an L7 problem. L2 encapsulates and uses route information, but doesn’t have to generate or maintain it. • Allows for mix of L2 and L3 routing – bridge mesh-under and route-over.

5. Sample Mesh Headers • Header IE descriptor: Length, ID (e.g. 0x19), type = 0 • Mesh control – Encodes addressing and routing field sizes • TTL – for limiting/measuring mesh hops • Transport - controls end-to-end acknowledgement or other options (such as security) • Address fields – Mesh Source and Destination • Routing fields – Graph or Source route list, or labels in a label-switching network • Header IE terminator – needed if payload follows