70 likes | 88 Views
This draft addresses the unique characteristics of low-power networks for efficient routing in 6LoWPAN environments. It highlights the need for energy optimization, simple protocols, and robustness in routing solutions.
E N D
Problem Statement and Requirements for 6LoWPAN Mesh Routing(draft-dokaspar-6lowpan-routreq-03) IETF-70 Vancouver Wednesday, December 5th 2007 1300 – 1500 Afternoon Session I Dominik Kaspar, Eunsook Kim, Carsten Bormann
Problem Statement Low-power characteristics: So far, existing routing protocols do not consider them much. Reasons: • Stringent requirements imposed by: • primary non-rechargeable batteries • small memory size, low bandwidth, slow processors, … • 6lowpans might be either transit-networks or stub-networks • at this moment, focus on stub-network case • A possibly simpler routing problem? • simplifying assumptions: no transit network, … • A possibly harder routing problem? • power-optimization, “data-aware” routing, harsh environment, … • 6lowpan nodes have sleep schedules • time synchronization is needed for efficient routing IETF-69 Chicago – 6LoWPAN
Design Space • “Mesh-under” • 6lowpan adaptation layer • IEEE 802.15.4 MAC addressing • “Route-over” • IP-layer routing Draft follows both perspectives IETF-69 Chicago – 6LoWPAN
Routing Requirements 6lowpan routing protocols should… • be simple and of low computational complexity • have a low routing state • restricted memory (e.g. 4 KBytes) • limited neighbor lists (e.g. 32 entries) • cause minimal power consumption • efficient use of control packets • packet transmission uses high energy in 6lowpan nodes • be loop-free • be robust to dynamic loss rates • loss rate (wireless) > loss rate (wired) • 6lowpan has more challenge on this due to limited resources. • allow for dynamically adaptive topologies and mobile nodes • route repair due to dying nodes • consider scalability ( draft-levis-rl2n-overview-protocols-02.txt) • no bottlenecks • no centralization • various device-types/roles: RFDs, FFDs, gateways, … IETF-69 Chicago – 6LoWPAN
Routing Requirements 6lowpan routing protocols should… • have energy-efficient neighbor discovery • how to define “neighbor” when many nodes are sleeping? • be reliable despite unresponsive nodes • consider nodes’ sleep schedules. • support various traffic patterns (P2P, MP2P, …) • provide auto-configuration after network setup (“plug-and-play”) • not use protocol control messages that create fragmentation of physical layer (PHY) frames. • have secured protocol control messages • routing in crucial situations: e.g. emergencies, alarm systems, … • support multiple roles (RFDs, FFDs, gateways, …) IETF-69 Chicago – 6LoWPAN
Technical Approaches • Avoiding “hello” messages for ND. • Using link-layer feedback for managing active neighbors. • Local route repair may be omitted. • Using MAC-layer feedback for node reliability estimation (RSSI, …). • Keep 16-bit and 64-bit addresses in routing tables for “mesh-under” routing. • … IETF-69 Chicago – 6LoWPAN
Discussion • Do we need to add more requirements? How about “Non-Requirements”? • Do we want to… • support multiple gateways? • require multiple paths / support load balancing? • rely on link-layer feedback? • build QoS-supported routing (slotted-link, …)? IETF-69 Chicago – 6LoWPAN