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

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

3
Design Space

• Mesh-under
• 6lowpan adaptation layer
• IEEE 802.15.4 MAC addressing
• Route-over
• IP-layer routing
• ? Draft follows both perspectives

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) gt 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,
  

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, )

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.

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, )?