1. © 2007 Cisco Systems, Inc. All rights reserved. 1 JP Vasseur - SENSORCOMM 2008 - France “The Internet of Things – What if objects talked to each other ?” Sensorcomm 2008 France – August 2008 JP Vasseur - Cisco Distinguished Engineer jpv@cisco.com

2. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 2 1 year after SENSORCOMM 2007 …  Sensorcomm 2007 “Why IP for Sensor networks ?”  We are now seeing major and fast progress on many fronts: “Why IP for Sensor Networks ?” => “The Internet of things” New applications are emerging very quickly (e.g. Smart Grid) IP has proven to be light enough to run on highly constrained devices, Emergence of new LP L1/L2 technologies (LP Wifi, LP Bluetooth, PLC, …) advocating for an IP layered architecture, Quick progress on the standardization front (IETF, ISA) Formation of a new industrial alliance (IPSO)  On the dark side … We do see proposals for protocol translation gateway (as planned !) Research may want to have more papers on architectural issues

3. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 3 Internet L2N TrueMesh Wireless HART ISA SP100.11a Xmesh Znet MintRoute MultiHop LQI CENS Route Smart mesh TinyAODV Honeywell Most promoters of non-IP solutions have understood that IP was a MUST: they call this “IP convergence”: A protocol translation gateway ! Or Tunneling … So far … WAS (Wait And See) - The current Trend (IETF – 2007)

4. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 4 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, More and more key players agree that IP offers flexibility (layered architecture), interoperability, performances and a wide set of proven tools and protocols: the standard of choice for the Internet of Things !

5. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 5 The number of applications for Sensor Networks is endless New Knowledge Improve Productivity Healthcare Agricultural Energy Saving (I2E) Predictive maintenance Industrial Automation Heal th Smart Home Defense High-Confidence Transport and assets tracking Intelligent Building Smart Cities Smart Grid

6. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 6 Some applications have their own set of standards  Building Automation: BACNet (ASHRAE/ANSI): defines services (who is, I am, Who has, I have used for device and object discovery). Services such as Read-Property and Write-Property are used for data sharing. Devices acting on objects (Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Multi-State Input, Multi-State Output, Calendar, Event-Enrollment, File, Notification-Class, Group, Loop, Program, Schedule, Command, and Device.). Support a number of L1/L2 layers, including ARCNET, Ethernet, BACNET/IP, P2P/RS232/Master-Slave Token Ring over RS-485 and Lonwork. There is an over IP solution but IP is used as a layer 2 … Required BACNet routing. We’re working with several key players to redefine BACNet 2 in a more IP friendly way. LonWorks (ANSI/CEA-709.1-B): on twisted pair 78 KB/s, power line (3.6 and 5.4KB/s), FO, Infrared – Peer to Peer protocol for control command – 7 layer protocol stack.

7. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 7 Sensor Networks - Usually a constrained environment requiring adaptation Energy consumption is a major issue (for non powered sensors/controllers), Limited processing power (CPU, memory) (improved Hardware) 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 2008 - France 8 Can we make The Internet of Things a reality? YES ! With moderate effort … Do not try to find a solution to all potential problems: reduce the problem scope Adapt or reuse existing protocols … do not reinvent the wheel ! : DHCP-like, SNMP, …. Design new IP-based protocols when needed: Example ? Routing … (see next slides) Preserve the fundamental openness of IP IP is ubiquitous and Sensors are everywhere … Good match.

9. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 9 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:

10. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 10  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)

11. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 11 Routing for Smart Objects 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

12. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 12 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

13. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 13 Combine “Mesh Under” and Route Over”: again ? 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

14. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 14 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

15. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 15 IETF Update Reuse whenever possible, Invent where needed GENOAMINTRTGAPSRAITSVSEC ReuseExisting WG dealing with LLNs 6lowpanROLL

16. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 16 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

17. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 17 WG Status  The Problem Statement document made RFC 4919  The Format Document is RFC 4944  Just re-chartered: 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations” 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. 4. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, 5. Produce "6LoWPAN Security Analysis" Off-charter discussion on fragmentation,flow control, …

18. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 18 Routing Over Low power and Lossy Link (ROLL) WG  Working Group Formed in Jan 2008 http://www.ietf.org/html.charters/roll-charter.html Co-chairs: JP Vasseur (Cisco), David Culler (Arch Rock)  Work Items Routing Requirements ID for Connected Home Routing Requirements ID for Industrial applications Routing Requirements ID for Urban networks Routing Requirements ID for Building Automation Survey on existing routing protocol applicability Routing metrics for LLNs Routing for LLNs Architecture document  Active work with a good variety of participants  Already four WG documents as of May 2008. We did limit the scope !

19. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 19 Slides about the protocol survey ID (IETF-72)

20. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 20

21. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 21

22. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 22

23. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 23

24. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 24 IETF 72 – July 2008 - Dublin New Routing Metrics  Motivation of the document Unique characteristics of LLNs Typical routing metrics such as hop counts or link metrics are not sufficient for LLNs A new set of required link and node metrics suitable to LLNs needs to be specified  ROLL WG item Nov 2008 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard.  Classification of routing metrics Link versus Node metrics Qualitative versus quantitative Dynamic or static

25. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 25 IETF 72 – July 2008 - Dublin New Routing Metrics  Routing metrics for LLNs is a critical topic  Need to be cautious !!! May be tempting to define a plethora of metrics … but not always implementable and usable in a deployed network  Use of dynamic metrics have been studied and experimented in the past (ARPANET: first average delays, revised metrics)  Dynamic metrics => Use of energy …  The challenge is not to define metrics but to compute these metrics.  This first revision lists potential candidates

26. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 26 IETF 72 – July 2008 - Dublin A first list of Node and Link Routing Attributes  Node metric Computational resources Residual Energy (dynamic) Current workload (dynamic) Node latency Data Aggregation attribute Node degree Dynamicity Node reliability  Link metrics Bandwidth Reliability (Quality) Propagation delay Set of costs (missing from the ID)

27. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 27 ROLL: Next Steps  Try to Last Call all application specific routing requirements documents by September 2008  Call for a ROLL Interim WG meeting in October (TBC)  Draw a consensus

28. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 28 What about ZigBee, Z-Wave, and other proprietary protocols ?

29. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 29 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.”

30. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 30 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 …

31. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 31 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

32. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 32 One physical layer will not fit all  Different requirements (range, power, bandwidth, frequency band, media, security) Lead to different physical layers: Power line, 802.11, 802.11LP, 802.15.4, 802.3, 802.15.4a IP is the common abstraction layer

33. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 33 One solution: IP  IP is independent of the physical layer.  Does IP work on highly constrained devices (meaning small and with limited memory) such as a 16-bit micro- controller with tens of Kbytes of RAM and possibly battery operated?  Absolutely: this has been very successfully demonstrated and there ARE several deployments!  The suggested IP stack only needs about 4K RAM  Will there be new IP protocols? MANY of the existing IP protocols can be used with no cost such as SNMP and Ping New IP protocols will be implemented only when and where needed. IP everywhere

34. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 34 Work at the IETF  A lot of us are very active at the IETF: In the 6lowpan Working Group (IPv6 over low power radio) A new routing WG has been established - ROLL – which has been very active and has Cisco representative as co-chair  Also at ISA (defining a standard for machine to machine communication in industrial environments) - ISA just adopted IP for that implementation  In both those areas there is a strong momentum and new companies joining the effort!

35. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 35 Why do we need a new alliance?  The IETF defines protocols – Does no Marketing  Regular requests for white papers, lists of companies supporting IP for Smart Objects, and other marketing support  We care about the end-user

36. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 36 Proposal  Form a new Alliance promoting IP for Smart Objects (also known as “Sensor Networks” and “The Internet of Things”)

37. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 37 Objectives and Areas to Avoid  Objectives of the Alliance  Promote the use of IP in Smart Objects by publishing white papers, case studies, issuing technology press releases, providing updates on standards progress and other supporting marketing activities  Organize focused interoperability testing events  Areas to Avoid - the Alliance will NOT work on protocol specifications, algorithms, etc. – those activities will be done at the IETF !

38. © 2007 Cisco Systems, Inc. All rights reserved. JP Vasseur - SENSORCOMM 2008 - France 38 Conclusion  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 (unavoidably leading to translation protocol gateways, complex tunneling, cross layer adaptations) is now strongly questioned.  We (hopefully) learnt from the past: open-based standard is KEY. IP is obvious the protocol,  Strong momentum around IP is being built: fast progress at the IETF (6lowpan and ROLL), formation of a new industrial alliance promoting IP (IPSO),  Participation of the Research community is key.

39. © 2007 Cisco Systems, Inc. All rights reserved. 39 JP Vasseur - SENSORCOMM 2008 - France Questions