1 / 7

Problem Statement and Requirements for 6LoWPAN Mesh Routing (draft-dokaspar-6lowpan-routreq-03)

Problem Statement and Requirements for 6LoWPAN Mesh Routing (draft-dokaspar-6lowpan-routreq-03). IETF-70 Vancouver Wednesday, December 5 th 2007 1300 – 1500 Afternoon Session I Dominik Kaspar, Eunsook Kim, Carsten Bormann. Problem Statement. Low-power characteristics:

evag
Download Presentation

Problem Statement and Requirements for 6LoWPAN Mesh Routing (draft-dokaspar-6lowpan-routreq-03)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

More Related