Why IP for Sensor Networks ? SENSORCOMM 2007

1. Why IP for Sensor Networks ?SENSORCOMM 2007 JP Vasseur - Cisco Distinguished Engineer jpv@cisco.com

2. Agenda • Sensor Networks today … A few facts: • Wide range of applications, • Proprietary worlds, • Technical challenges, • Multi-dimensional problem scope • The current Internet - A few design principles • Internet of Things = Internet + Sensor Networks • Sensor Networks at the IETF • Conclusion

3. Agenda • Sensor Networks today … A few facts: • Wide range of applications, • Proprietary worlds, • Technical challenges, • Multi-dimensional problem scope • The current Internet - A few design principles • Internet of Things = Internet + Sensor Networks • Sensor Networks at the IETF • Conclusion

4. Health Sensor Networks are everywhere …with an endless scope of applications Defense Energy Saving (I2E) Improve Productivity Predictive maintenance Enhance Safety & Security Intelligent Building Enable New Knowledge High-Confidence Transport and assets tracking Improve Food & H20 Healthcare Smart Home

5. New applications pretty much every day … but … • The number of proprietary solutions has literally exploded: Zigbee, Z-Wave, Xmesh, SmartMesh/TSMP, … at many layers (physical, MAC, L3) and most chip vendor claim to be compatible with their own standard • Many non-interoperable “solutions” addressing specific problems (“My application is specific” syndrome) • Different Architectures, • Different Protocols => Deployments are limited in scopeandscale,

6. Research and Sensor Networks • Research in Sensor Networks has been very active over the past decade, • Sensor Networks provide an infinite source of fairly complex problems (NP-Complete :-)) • Considerable number of solutions seeking for ultimate efficiency (e.g. “local” optimum)

7. Sensor Networks - Usually a constrained environment • Energy consumption is a major issue (for non powered sensors/controllers), • Limited processing power (CPU, memory), • Prone to failures => very dynamic topologies, • When mobile => increase the dynamic nature of topology, • Data processing may be required on the node itself, • Sometimes deployed in harsh environments, • Potentially deployed at very large scale, • Must be self-managed (auto-discovery, self-organizing networks)

8. A truly multi-dimensional issue Degree of mobility Smart cities Degree of constraints (link/node) Connected Building Industrial Degree of scalability

9. Agenda • Sensor Networks today … A few facts: • Wide range of applications, • Proprietary worlds, • Technical challenges, • Multi-dimensional problem scope • The current Internet - A few design principles • Internet of Things = Internet + Sensor Networks • Sensor Networks at the IETF • Conclusion

10. An impressive success • More than 1.2 billions users (18.9% of the population) • Usage growth: 244.7% • An extremely wide range of applications: Emails, Web, Voice, Video, TV, Mobility, …

11. A few key design principles of the Internet • What ? A Layered architecture => flexible, • Where ? The End to End design principle, • How ? Separation of the networks from the services: IP indifferent to PHY and applications, • Why ? The Internet as a platform for innovation. No central gatekeeper exerting control over the Internet. Source: Prepared statement of Vint Cerf - Feb ‘07

12. The IP protocol suite is based on open standard designed for interoperability, extensibility … as opposed to seeking for local optimums

13. Agenda • Sensor Networks today … A few facts: • Wide range of applications, • Proprietary worlds, • Technical challenges, • Multi-dimensional problem scope • The current Internet - A few design principles • Internet of Things = Internet + Sensor Networks • Sensor Networks at the IETF • Conclusion

14. IP everywhere The Internet will extend to billions of new devices Can we Make the “Internet of Things” a reality ? As IP becomes pervasive, devices that do not exist today will be connected to the Internet Users 2005 Forecast, Million Units Today's Internet 500 Computers Phones 1,500 Extended Internet Mobile Assets 350 Static Assets 375 Controllers 500 750 Smart Sensors Microprocessors and Microcontrollers 35,000 Source: Harbor Research, Inc., Forrester Research, Inc., IBSG

15. A Challenging situation: the example of Routing Sensor Networks Nodes are sensor/actuators&routers An order of magnitude larger in term of number of nodes, Links are highly unstable and Nodes die much more often, Nodes/Links are highly constrained Application-aware routing, in-Band processing is a MUST Current Internet Nodes are routers IGP with typically few hundreds of nodes, Links and nodes are stable, Nodes constraints or link bandwidth are typically non issues, Routing is not application-aware (MTR is a vanilla version of it)

16. So far … WAS (Wait And See) - The current Trend Honeywell Wireless HART TrueMesh Znet ISA SP100.11a Internet Smartmesh MintRoute Xmesh MultiHop LQI CENS Route TinyAODV L2N L2N

17. Issues with WAS (Wait And See) SN SN SN SN Internet Multi-protocol Gateway (IP-proxy, protocol translations) SN SN SN Haven’t we learnt from the past ? Remember SNA (DLSw), IPX, Vines, … • Management complexity • Lack of end to end routing consistency, Multi-topology routing, management, security, … • Migration may just not be possible for Sensor Networks after too much time

18. Or … IP end to end SN SN SN SN Internet SN SN IP router ! SN SN Which does not mean a single flat domain of course

19. The “Mesh Under” versus “Route Over” Debate or again “Why do we need IP” ? • Many times people have argued in favor of a layer-2 approach for Sensor Nets, at best with IP reachability, • Sensor Networks are made of a variety of links: wired and wireless, • Even for WSN, there won’t be a single “winner”: IEEE 802.15.4, LP Wifi, Wibree, … IP routing is a must for Sensor Networks

20. Combine “Mesh Under” and Route Over” IP Routing over 802.11s, 802.16J, 802.15.5, Zigbee • IP layer with no visibility on the layer 2 path characteristic • Makes “optimal” routing very difficult • Layer 2 path (IP links) change because of layer 2 rerouting (failure or reoptimization) lead to IP kink metric changes. How is this updated ? • Remember IP over ATM • There is still a need for an abstraction layer model but for Point to Point layer 2 links

21. Combine “Mesh Under” and Route Over” Another major challenge: multi-layer recovery • Require a multi-layer recovery approach • Current models are timer-based: • Needs to be conservative and most of the time bottom-up • Increased recovery time for failures non recoverable at layer 2 • Inter-layer collaborative approaches have been studied (e.g. IP over Optical) => definitively too complex for current Sensor Hardware

22. Can we make The Internet of Things a reality? YES ! With some effort … • Adapt existing protocols … do *not* reinvent the wheel and learn from the past • And when needed,design new protocols: Example ? Routing … (see next slides) • But preserve the fundamental openness of IP • IP is ubiquitous and Sensors are everywhere … Good match.

23. Can we make The Internet of Things a reality? YES ! With some effort (Cont) Do not try to find a solution to all potential problems: reduce the problem scope

24. Specify new IP protocols when needed Let’s face a reality: routing in Sensor Networks has unique requirements: • Routing in Sensor Networks is a MUST for energy saving (short distances => less energy to transmit) *and* to route around obstacles (including poor quality links), • Highly constrained devices • Harsh & dynamic environments: (variable link qualities, link/nodes fail at a rate significantly higher than within the Internet) • Small MTU (high error rate, limited buffer/bw) • Constraint routing is a MUST: take into account link *and* nodes properties and constraints (also unusual) • Deep power management: WSN in sleep mode most of the time

25. Specify new IP protocols when needed (Cont) • Highly heterogeneous capabilities • Structured traffic patterns: P2MP, MP2P but also more and more P2P • Multi-path and asymmetrical load balancing • Data aware routing: data aggregation along a dynamically computed path to a sink. • Self-Managed !!

26. Why can’t we use an existing routing protocol ? • Many IP routing protocols have been designed: RIP, OSPF,AODV, OLSR, DYMO, TBRPF But … • As pointed out Routing requirements for L2Ns are unique, • None of them satisfy the minimum set of requirements, • Some of them could be adapted/twisted/… but that means major protocol rework.

27. Agenda • Sensor Networks today … A few facts: • Wide range of applications, • Proprietary worlds, • Technical challenges, • Multi-dimensional problem scope • The current Internet - A few design principles • Internet of Things = Internet + Sensor Networks • Sensor Networks at the IETF • Conclusion

28. The Internet Engineering Task Force • IETF formed in 1986, • Not considered as important for some time :-) • Not government approved :-) • Involving people not companies • Motto: “We reject kings, presidents and voting. We believe in rough consensus and running code” Dave Clark (1992) • Organized in areas made of WGs, APS GEN OAM INT RTG RAI SEC TSV 6lowpan • Roughly 120 WGs • Long term problem handled by the IRTF

29. IPv6 over Low power WPAN (6LoWPAN) • Additional information is available at tools.ietf.org/wg/6lowpan • Chair(s): • Carsten Bormann <cabo@tzi.org>Geoffrey Mulligan <geoff-ietf@mulligan.org> • Internet Area Director(s): • Jari Arkko <jari.arkko@piuha.net>Mark Townsley <townsley@cisco.com> • Internet Area Advisor: • Mark Townsley <townsley@cisco.com> • Secretary(ies): • Christian Schumacher <schumacher@danfoss.com> • Mailing Lists: • General Discussion: 6lowpan@lists.ietf.orgTo Subscribe: 6lowpan-request@lists.ietf.orgIn Body: subscribeArchive: https://www1.ietf.org/mailman/listinfo/6lowpan

30. RFC 4919 - LoWPANs Problem Statement IEEE 802.15.4 Networks, characterized by: • Significantly more devices than current networks • Severely limited code and ram space • highly desirable to fit the required code--MAC, IP and anything else needed t execute the embedded application-- in, for example, 32K of flash memory, using 8-bit microprocessors • Unobtrusive but very different user interface for configuration • using gestures or interactions involving the physical world • Robustness and simplicity in routing or network fabric • 802.15.4 a, b, 2003, 2006, and maybe wibree • More in RFC 4919

31. RFC 4944: IPv6 over IEEE 802.15.4 • Describes the frame format for transmission of IPv6packets and the method of forming IPv6 link-local addresses andstatelessly autoconfigured addresses on IEEE 802.15.4 networks. • IPv6 requires that every link in the internet have an MTU of 1280 octets or greater and the MTU of 802.15.4 is 127 bytes => adaptation layer handling fragmentation • Worst case payload = 127 bytes - 25 (max frame overhead) - 21 (link layer security AES-CCM-128) = 81 bytes • Max payload application = 81 bytes - 40 (v6 header) - 8 (UDP) = 33 bytes • Notes: • Most applications of IEEE 802.15.4 will not use such largepackets • Small application payloads in conjunction withheader compression will produce packets that fitwithin a single IEEE 802.15.4 frame. • RFC 4944 defines two compression schemes: • HC1: IPv6 header compressed from 40 bytes to 3 bytes • HC2: UDP header compressed from 8 bytes to 4 bytes

32. WG Status • The Problem Statement document made RFC 4919 • The Format Document is to submitted to AD for publication • Re-chartering is underway. Proposed topics: • most important: ND and bootstrapping. • We do not want to change ND but optimize the packet usage. • Mobility will be very important there • 2) stateful Header Compression. • HC1 is stateless and a stateful could be useful • 3) Recommendations for 6lowpan Applications • Protocols for transport, L7, discovery, configuration and commissioning. • 4) security in a LoWPAN. • To define the threat model of 6lowpans and to document suitability of existing key management schemes and to discuss bootstrapping, installation, setup and commissioning issues.

33. The IETF and Sensor Networks • Remember: Reuse whenever possible, Invent where needed Reuse New Existing WG dealing with SNs APS GEN OAM INT RTG RAI SEC TSV

34. IETF & Sensor Nets: Standardization status • New initiative on Routing for Sensor Networks • RSN => RL2N (Routing for Low Power and Lossy Networks): • RL2N new mailing list where the routing issues are discussed. Several large players have joined the initiative: https://www1.ietf.org/mailman/listinfo/rsn • Presentation in Chicago, plan to have a BOF in Vancouver. • In the works: • Problem statement • Routing Requirement ID for Connected Home • Routing Requirements ID for Industrial applications • Survey on existing routing protocol applicability • Routing metrics for RL2N • In progress: Routing Requirements ID for Smart cities Limited scope !

35. The End to End principles in a few words • Concept arose in 1981 “END-TO-END ARGUMENTS IN SYSTEM DESIGN ” J.H. Saltzer, D.P. Reed and D.D. Clark “Functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level” • Careful thoughts must be given to where functions must be handled (low versus high layers): a performance trade-off • Various examples of functions that should be handled by high layers are examined: delivery guarantees, security, duplicate, … • Sometimes (mis)understood as “This leads to the model of a "dumb, minimal, network" with smart terminals” • “Thus the end-to-end argument is not an absolute rule, but rather a guideline that helps in application and protocol design analysis; one must use some care to identify the end points to which the argument should be applied.”

36. The End to End principles in a few words • A way to address concerns to maintain openness, increase reliability, preserve user choice, ease for innovation, • As the Internet developed, the end-to-end principle gradually widened to concerns about where best to put the state associated with applications in the Internet: in the network or at end nodes. The best example is the description in RFC 1958 [6]: This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e., information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible. Everything else should be done at the fringes. Pressures on the end-to-end principle in today's Internet • Lack of trust and emergence of new security models • New service models (achieve proper performance) • Data-ware routing, in-band processing in sensor networks …

37. Do we need to revisit the end to end principles ? • The “end to end” principles has proven to work very well for many applications but less appropriate for some applications (e.g. real-time (overhead due to end to end retransmissions)) • Adding function in lower layers highly beneficial for several applications: QoS, Unwanted traffic, Security • Care must be given to: • Layer violation creating dependencies that would make it impossible for the transport layer, for example, to do its work appropriately. • Another issue is the desire to insert more applications infrastructure into the network. See RFC 3724

38. What does that mean for Sensor Networks? • Dataware routing, in-band network processing are key functions that must be supported by the network • Most of the nodes are on sleep most of the time but the number of nodes is an order of magnitude larger than in the current Internet • Data content not always meaningful • Use of network resources can be very expensive (e.g. battery powered WSNs) • Data can be correlated to trigger network based actions

39. What does that mean for Sensor Networks? SN SN SN SN Public @ Internet SN IP-based SNs with in-band processing, … • Dataware routing, in-band network processing, at the edge of the extended Internet (private sub-Internet), • Functions limited in scope.

40. Conclusion (1) • Sensor networks have a tremendous number of opportunities but it is time to react and change the current “trend” (myriad of proprietary worlds), • The “WAS” approach will unavoidably lead to translation protocol gateways, complex tunneling, cross layer adaptations: a known dead-end. • We (hopefully) learnt from the past: open-based standard is KEY. IP is obvious the protocol, • The network layer must be independent of the Layer-1/2 (Sensor Nets are not made of a single type of L1/L2 !) • The pervasive nature of IP networks allows use of existing infrastructure.

41. Conclusion (2) • Device to device communication traffic will undoubtedly drastically increase in nature and in traffic volumes, • A Plethora of existing protocols/tools can be used: reuse as much as possible but also design new IP protocols when needed, • Security, • Naming, • Addressing • Discovery • OAM tools • An admittedly non-technical but important consideration is that intellectual property conditions for IP networking technology are either more favorable or at least better understood than proprietary and newer solutions. • And no this is a not a religious debate but a fundamental architectural choice.

42. Questions