Slide #1IETF 71 – Roll WG – March 2008 Routing Requirements for Urban Sensor Networks draft-dohler-r2ln-routing-reqs-00.txt M. Dohler G. Madhusudan G. Chegaray T. Watteyne C. Jacquenet

Slide #2IETF 71 – Roll WG – March 2008 Outline Motivation and context Traffic characteristics Operational considerations Routing requirements Next steps

Slide #3IETF 71 – Roll WG – March 2008 Motivation Sensor networking becomes urban cornerstone technology –To improve living conditions –To assess compliance with environmental regulation Sensor usage includes –Smart metering –Waste disposal –Weather and pollution sensing

Slide #4IETF 71 – Roll WG – March 2008 Networking Context Wireless networking Tens of thousands of nodes –Sensors, actuators and access points Multi-functional devices –Actuators can serve as: Gateways (to access the Internet) Data sinks (to collect data from sensors) Data sources (to instruct other actuators in clustering environments)

Slide #5IETF 71 – Roll WG – March 2008 Traffic Characteristics Directional flows –Sensed data are sent by sensors to APs –APs send queries to sensors –Control data are sent by APs to actuators Regular and spontaneous –Periodic sensing and reporting –On-request sensing –Dynamic notifications (alerts) Sensed data are time and space correlated

Slide #6IETF 71 – Roll WG – March 2008 Operational Considerations Deployment in batches out-of-box –Pre-programmed capabilities –Customized by service providers –Heterogeneous technologies to cope with Addition and removal of nodes while network is in operation –Graceful notification and/or abrupt disappearance

Slide #7IETF 71 – Roll WG – March 2008 Basic Routing Requirements Support of unicast and multicast –Including "groupcast" (forwarding to a list of identified addressees in a given subnet) Scalability –Routing protocol(s) must accommodate 10,000+ nodes Constraint-based, context-aware routing –Energy, memory, CPU usage to be considered as routing metrics –Knowledge of flow directionality should be an asset Self-organizing capabilities –Self configuration and management Possibly triggered by external events

Slide #8IETF 71 – Roll WG – March 2008 More Requirements Latency –Shorter than reporting period for regular sensing –Application-compatible queried sensing Security –Authentication is required for sensing Need to preserve data integrity –Robustness against (D)DOS attacks

Slide #9IETF 71 – Roll WG – March 2008 Next Steps Update draft with elaboration on: –Node mobility –Traffic patterns Comments and suggestions are warmly encouraged Adopt draft as WG document?

Slide #10IETF 71 – Roll WG – March 2008 Backup

Slide #11IETF 71 – Roll WG – March 2008 MUST's The routing protocol MUST be scalable to be able to accommodate a very large and increasing number of nodes without deteriorating to-be-specified performance parameters below to-be-specified thresholds. The routing protocol MUST support parameter constrained routing, where examples of such parameters have been given in the previous paragraph. The routing protocol MUST provide a set of features including 0-configuration at network ramp-up, (network-internal) self-organization and configuration due to topological changes, ability to support (network-external) patches and configuration updates. For the latter, the protocol SHOULD support multicast and broadcast addressing. The protocol SHOULD also support the formation and identification of groups of field devices in the network. The routing protocol MUST support multicast, where the routing protocol MUST provide the ability to route a packet towards a single field device (unicast) or a set of devices, which explicitly (multicast) or implicitly (groupcast) belong to the same group/cast. The choice of the security solutions will have an impact onto routing protocols. To this end, routing protocols proposed in the context of Urban sensor networks MUST support integrity measures and SHOULD support confidentiality (security) measures.

Slide #12IETF 71 – Roll WG – March 2008 SHOULD's The routing protocol MUST provide a set of features including 0-configuration at network ramp-up, (network-internal) self-organization and configuration due to topological changes, ability to support (network-external) patches and configuration updates. For the latter, the protocol SHOULD support multicast and broadcast addressing. The protocol SHOULD also support the formation and identification of groups of field devices in the network. The routing protocol SHOULD support and utilize this fact to facilitate scalability and parameter constrained routing. The routing protocols proposed in U-L2N SHOULD support a variety of different devices without compromising the operability and energy efficiency of the network. Local network dynamics SHOULD NOT impact the entire network to be re-organized or re-reconfigured; however, the network SHOULD be locally optimized to cater for the encountered changes. Convergence and route establishment times SHOULD be significantly lower than the inverse of the smallest reporting cycle. The routing protocol is RECOMMENDED to support minimum latency for alert reporting and time-critical data queries. For regular data reporting, it SHOULD support latencies not exceeding a fraction of the inverse of the respective reporting cycle. The choice of the security solutions will have an impact onto routing protocols. To this end, routing protocols proposed in the context of U-L2Ns MUST support integrity measures and SHOULD support confidentiality (security) measures.

Slide #13IETF 71 – Roll WG – March 2008 Other Requirements SHOULD NOTs: –Local network dynamics SHOULD NOT impact the entire network to be re-organized or re-reconfigured; however, the network SHOULD be locally optimized to cater for the encountered changes. Convergence and route establishment times SHOULD be significantly lower than the inverse of the smallest reporting cycle. RECOMMENDEDs: –The routing protocol is RECOMMENDED to support minimum latency for alert reporting and time-critical data queries. For regular data reporting, it SHOULD support latencies not exceeding a fraction of the inverse of the respective reporting cycle.