1. © 2007 Cisco Systems, Inc. All rights reserved. 1 JP Vasseur - SENSORCOMM 2007 - Spain Why IP for Sensor Networks ? SENSORCOMM 2007 JP Vasseur - Cisco Distinguished Engineer jpv@cisco.com

2. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 4 Sensor Networks are everywhere … with an endless scope of applications Enable New Knowledge Improve Productivity Healthcare Improve Food & H20 Energy Saving (I2E) Predictive maintenance Enhance Safety & Security Heal th Smart Home Defense High-Confidence Transport and assets tracking Intelligent Building

5. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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 scope and scale,

6. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 8 A truly multi-dimensional issue Degree of mobility Degree of scalability Degree of constraints (link/node) Smart cities Connected Building Industrial

9. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 10 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, … An impressive success

11. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 11  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. A few key design principles of the Internet Source: Prepared statement of Vint Cerf - Feb ‘07

12. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 12 The IP protocol suite is based on open standard designed for interoperability, extensibility … as opposed to seeking for local optimums

13. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 14 Computers Phones Mobile Assets Static Assets Controllers Smart Sensors Microprocessors and Microcontrollers Users 2005 Forecast, Million Units 500 1,500 350 375 500 750 35,000 Source: Harbor Research, Inc., Forrester Research, Inc., IBSG Today's Internet Extended Internet As IP becomes pervasive, devices that do not exist today will be connected to the Internet The Internet will extend to billions of new devices IP everywhere Can we Make the “Internet of Things” a reality ?

15. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 15 A Challenging situation: the example of Routing 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) 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

16. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 16 Internet L2N TrueMesh Wireless HART ISA SP100.11a Xmesh Znet MintRoute MultiHop LQI CENS Route Smart mesh TinyAODV Honeywell So far … WAS (Wait And See) - The current Trend

17. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 17 Internet 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 Multi-protocol Gateway (IP-proxy, protocol translations) SN Issues with WAS (Wait And See)

18. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 18 Or … IP end to end Internet IP router ! SN Which does not mean a single flat domain of course

19. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 24 Specify new IP protocols when needed  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 Let’s face a reality: routing in Sensor Networks has unique requirements:

25. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 25  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 !! Specify new IP protocols when needed (Cont)

26. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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, GENOAMINTRTGAPSRAITSVSEC Roughly 120 WGs Long term problem handled by the IRTF 6lowpan

29. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 29 IPv6 over Low power WPAN (6LoWPAN)  Additional information is available at tools.ietf.org/wg/6lowpantools.ietf.org/wg/6lowpan  Chair(s): Carsten Bormann Geoffrey Mulligan  Internet Area Director(s): Jari Arkko Mark Townsley  Internet Area Advisor: Mark Townsley  Secretary(ies): Christian Schumacher  Mailing Lists: General Discussion: 6lowpan@lists.ietf.org To Subscribe: 6lowpan-request@lists.ietf.org In Body: subscribe Archive: https://www1.ietf.org/mailman/listinfo/6lowpan6lowpan-request@lists.ietf.orghttps://www1.ietf.org/mailman/listinfo/6lowpan

30. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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 4919RFC 4919

31. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 31 RFC 4944: IPv6 over IEEE 802.15.4  Describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly 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 large packets Small application payloads in conjunction with header compression will produce packets that fit within 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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: 1)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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 33 The IETF and Sensor Networks Remember: Reuse whenever possible, Invent where needed GENOAMINTRTGAPSRAITSVSEC ReuseNewExisting WG dealing with SNs

34. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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” "dumb, minimal, network" “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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 39 What does that mean for Sensor Networks? Internet SN Dataware routing, in-band network processing, at the edge of the extended Internet (private sub-Internet), Functions limited in scope. Public @ IP-based SNs with in-band processing, …

40. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2007 - Spain 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. © 2007 Cisco Systems, Inc. All rights reserved. 42 JP Vasseur - SENSORCOMM 2007 - Spain Questions