Dominik Kaspar, Eunsook Kim, Carles Gomez, Carsten Bormann Problem Statement and Requirements for 6LoWPAN Mesh Routing (draft-dokaspar-6lowpan-routreq-04) IETF-71 Philladelphia Tuesday, March 11 2008 Dominik Kaspar, Eunsook Kim, Carles Gomez, Carsten Bormann

IETF-71 Philadelphia– 6lowpan Update (-04) Update in Problem Statement 6LoWPAN routing protocols should support multiple device types and roles. Handling sleeping nodes is very critical in 6LoWPANs, more than in traditional ad-hoc networks. A possibly simpler routing problem; 6LoWPANs might be either transit-networks or stub-networks. A possibly harder routing problem; routing in 6LoWPANs requires to consider power-optimization, harsh environment, data-aware routing, etc. These are not easy requirements to satisfy together Application-specific features affect the design of 6lowpan routing requirements and the corresponding solutions IETF-71 Philadelphia– 6lowpan

IETF-71 Philadelphia – 6lowpan Update (-04) Scenario Considerations are updated 6LoWPAN Communication Models Flooding (in very small networks) Data-aware routing (dissemination vs. gathering) Event-driven vs. query-based routing Geographic routing Probabilistic routing Hierarchical routing Network properties & Node properties are updated Node and gateway spatial distribution Traffic Patterns, Topology and Applications Transmission Range IETF-71 Philadelphia – 6lowpan

IETF-71 Philadelphia – 6lowpan Update (-04) Skeleton has changed Routing Requirements depending on the 6LoWPAN device types/roles Routing Requirements depending on types of 6LoWPAN applications Mesh-under specific requirements -> MAC coupled requirements IETF-71 Philadelphia – 6lowpan

IETF-71 Philadelphia – 6lowpan Update (-04) Role dependent requirements 6LoWPAN routing protocols SHOULD be simple and of low computational complexity 6LoWPAN routing protocols SHOULD have a low routing state. 6LoWPAN routing protocols SHOULD cause minimal power consumption, both in the efficient use of control packet and also in the process of packet forwarding after route establishment. Neighbor discovery for 6LoWPAN routing SHOULD be energy-efficient. 6LoWPAN routing protocols SHOULD be reliable despite unresponsive nodes. Application dependent requirements 6LoWPAN routing protocols SHOULD be robust to dynamic loss rates An important trait of LoWPAN devices is their unreliability due to limited system capabilities, and also because they might be closely coupled to the physical world with all its unpredictable variation(including RSSI and interference variation), noise, and asynchrony. 6LoWPAN routing protocols SHOULD allow for dynamically adaptive topologies and mobile nodes. 6LoWPAN routing protocols SHOULD be scalable 6LoWPAN protocol control messages SHOULD be secured. IETF-71 Philadelphia – 6lowpan

IETF-71 Philadelphia – 6lowpan Update (-04) MAC coupled requirements 6LoWPAN routing protocol control messages SHOULD not create fragmentation of physical layer (PHY) frames. For neighbor discovery, 6LoWPAN devices SHOULD avoid sending "Hello" messages. Instead, link-layer mechanisms (such as acknowledgments or beacon responses) MAY be utilized to keep track of active neighbors. In order to find energy-optimal routing paths, LoWPAN mesh routing protocols should minimize power consumption by utilizing a combination of the link quality indication (LQI) provided by the MAC layer and other measures, such as hop count. Variability of LQI withtime should be considered. The procedure of local repair and related control messages should not harm overall energy consumption from the routing protocols. Local repair (when possible) can help reducing loss rates, end-to-end delivery delays, and in successful cases a reduction of control overhead. IETF-71 Philadelphia – 6lowpan

IETF-71 Philadelphia – 6lowpan Next Step Will 6LoWPAN do the work for routing requirements? Good way to cooperate with ROLL work? What can be the next step of this work? IETF-71 Philadelphia – 6lowpan