Why IP for Sensor Networks ?


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • A LoWPAN is a simple low cost communication network that allows wireless connectivity in applications with limited power and relaxed throughput requirements. A LoWPAN typically includes devices that work together to connect the physical environment to real-world applications, e.g., wireless sensors. LoWPANs conform to the IEEE 802.15.4-2003 standard. [ ieee802.15.4 ]. Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application-- in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) * Robustness and simplicity in routing or network fabric A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The working group is expected to coordinate and interact with such groups. The working group has completed a problem statement/requirements RFC and an adaptation layer (IPv6 over 802.15.4) RFC. The working group has as its main objective to complete those topics and areas necessary for successful implementation interoperability. The required work includes items in the following (incomplete) list: * Addressing schemes and address management * Network management * Routing in dynamically adaptive topologies * Security, including set-up and maintenance * Application programming interface * Discovery (of devices, of services, etc) * Implementation considerations Whereas at least some of the above items are within the purview of the IETF, at this point it is not clear that all of them are. Accordingly, the 6LoWPAN working group will address a reduced, more focused set of objectives. Scope of 6lowpan: 1. Produce “6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations† to define the required optimizations to make IPv6 ND applicable in 6lowpans, given the fact that IPv6 ND is too expensive for the devices of 6lowpan and requires multicast. This document will define how to bootstrap a 6lowpan network and explore ND optimizations such as reusing the 802.15.4 network structure (use the coordinators), and obviate multicast by having devices talk to coordinators without creating a single point-of-failure, and changing the IPv6 ND multicast semantics. This document will be a proposed standard. 2. Produce “Problem Statement for Stateful Header Compression in 6lowpans† to document the problem of using stateful header compression (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of stateless header compression given the assumption that stateful header compression may be too complex. This document will determine if the assumption is correct and will be an informational document. 3. Produce “Recommendations for 6lowpan Applications† to define a set of recommendations of protocols to use for applications. The recommendations will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be an informational document. 4. Produce “6lowpan Mesh Routing† to evaluate different mesh routing protocols for use within 6lowpans. While most routing protocols are defined above the IP layer, 6lowpan requires a mesh routing protocol below the IP layer. “6lowpan Mesh Routing† may be several proposed standard documents. 5. Produce “6lowpan Security Analysis† to define the threat model of 6lowpans and to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be an informational document. The working group will reuse existing specifications whenever reasonable and possible. The working group will also serve as a venue for ongoing discussions on other topics related to the more complete list outlined above. Additional related milestones may be added in the future via a rechartering operation. Note: As may be obvious from its official name above, this particular working group will not work on IPv4 over IEEE 802.15.4 specifications. Given the limitations of the target devices, dual-stack deployments are not practical. Because of its higher potential for header compression, its support for the huge number of devices expected and of cleanly built-in features such as address autoconfiguration, IPv6 is the exclusive focus of the working group.
  • Some of the characteristics of LoWPANs are: A, b, 2003, 2006, and maybe wibree Small packet size. Given that the maximum physical layer packet is 127 bytes, the resulting maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively) leaves 81 octets for data packets. 2. Support for both 16-bit short or IEEE 64-bit extended media access control addresses. 3. Low bandwidth. Data rates of 250 kbps, 40 kbps and 20 kbps for each of the currently defined physical layers (2.4 GHz, 915 MHz and 868 MHz, respectively). 4. Topologies include star and mesh operation. 5. Low power. Typically, some or all devices are battery operated. 6. Low cost. These devices are typically associated with sensors, switches, etc. This drives some of the other characteristics such as low processing, low memory, etc. Numerical values for "low" elided on purpose since costs tend to change over time. 7. Large number of devices expected to be deployed during the life- time of the technology. This number is expected to dwarf the number of deployed personal computers, for example. 8. Location of the devices is typically not predefined, as they tend to be deployed in an ad-hoc fashion. Furthermore, sometimes the location of these devices may not be easily accessible. Additionally, these devices may move to new locations. 9. Devices within LoWPANs tend to be unreliable due to variety of reasons: uncertain radio connectivity, battery drain, device lockups, physical tampering, etc. 10. In many environments, devices connected to a LoWPAN may sleep for long periods of time in order to conserve energy, and are unable to communicate during these sleep periods.
  • My notes from IETF 68 Agenda bashing -> 9h10 Doc status ----------- Milestones both doc to IESG. PS approved to Informational. format: 2 items to be discussed today Item 1) datagram tag size. IESG review asked what's the formla for 10 bits? 18 bits enables up to 100Mbps bandwidth scalability, as explained on the list. This is the big change coming up. David Collar: Frag header is not a bad place because packet is large. other key: sender has to assign tag in order. Doc says source increment. Carsten: does not want the doc to Dave: 18 is unnatural for computers. Difference is reassembly end should be considered. Carsten: does doc imply a source maintain a per destination tag increment? If the counter is global, there's no way to force consecutive tags . Item 2) C: Prefix vs. PanID. text in the doc is ambiguous in that matter. Simple fix of removing the sentence that maps the PAN ID in the prefx which limited the enumber of prefixes on an interface. 2 ways to support multicast. Mcast needs a mesh routing underneath. Suggestion: make it more explicit so Mcast is used only if mesh routing is present. Mysterious P value for UDP port number. Where does it come from. Ask 16 port from IANA with special properties? Mark: There is an internal expert in IANA looking at UDP ports. Hard to get 16 consecutive ports. IESG support helps a lot. In the interest of expediency, make it configurable and decide later how auto configurable P can be. Window to publish opens right now. Geoff: The idea is to remove the text to say there is a require IANA action to assign P and say it can be Dworded (like Discovered, deranged, ...). ?: do we need to deal with dynamic discovery? Geoff: There MUST be a way to discover P when a node joins the PAN. HC1 is a MUST. Thoughts anybody for making it an option? Mark: MUST receive is fair (Postel Principle). The discussion if we decide to wait for IANA. can take us anywhere up to compression principles and there's no obvious result. Geoff: we can remove 10.3.2 and define in a later document. Erik Normark: Seems you end up with a you MUST implement that protocol that is not described. Either you defer the all thing or you remove the MUST support? Carsten: In ?AVT?, decided stop allocating number and protocols use dynamic payload types. If you have more than 16 possible protocols in a PAN, you need to adapt the 16 ports with the case at hand. We need coordination to do that mapping like a boostrapping configuration protocol. Knowing where the port NB range starts helps implementation. We can use 49152 to 65535 already allocated by IANA for dynamic ports. ?: we do know this does not apply to well known ports. Seems either we do not know which case we are optimizing for in which case we should wait. Do the most used potr leave in the well known site? Geoff: it is a set of ports and to be used as an oportunity to be more efficient, should be trivial to implement. Mark: An application that knows it can be used in a LoWPAN it would use the range even if he does not compress. But it needs to decompress as a receiver (trivial?). Carsten: needmore ML exchanges to find a value for P. Too bad we can not use 66666 :) Geoff: like 60666 but it's just me :) we need to check whether HC1 is a MAY send MUST receive. We can condense the changes in old news in the ML. Mark: rev the draft with Gabriel's changes. Carsten: We can have a revved draft tomorrow morning ?: back to 18 bits. C: Calculations I made said 4 more bits is enough. 16 bits ve us 10 MBps at MAC which is good enough. ?: the issue is about the capability to do tag matching. Matching 18 bits s much harder. rechartering ( ------------ Many things could be done. What needs to be nailed tsown to make sure we have Interop Carsten: In ancouver we discussed 5 items 1) most important: ND and bootstrapping. We do not want to change ND but optimize the packet usage. from there we know how a node finds its place in a lowpan. 2) stateful HC. HC1 is stateless and a stateful could be useful. 3) roadmap explaning how things fit together (non normative, "architecture" useful practical doc) More like "ways things work". 4) meshrouting document; The or a way or 2 ways to do mesh. Might reference other docs and explain the deltas like routing on 64 bits MAC addresses. MANET + stuff ? Stuff might be substantial. 5) security in a lowpan. So far assumed that security was there (15.4 or P security mechanisms) we need to look deeper into this. Carsten: Mobility will be very important for item 1) Geoff: Bootstrapping with or without coordinator? What if security is already in place? Zigbee faced the problem. We need a framework for explaining Bootstrapping. Mark: no pb to write an architecture doc in IET. Hapens all the time. Prof Kim: We had no opportunity to discuss that architecture to date. Too many protocols. Need unified framework. Need to discuss scenarios for 6LoWPAN. Multiple routers? Coordinators? Multiple PANs? Extension of existing doc. I propose a new item for rechartering. Which routing protocol is assumed? exploring the capability of the dispatch format for multiple routing protocols at different layers. Carsten: need to keep focus. Geoff: One goal is trying not byte off too much but choose a couple (2-3) topics, divide and conquer. ?: ND has an optimization work going on for SeND. Daniel Park: How to deal with SeND is a priority. Need an agreement frmo teh WG. ?: There was a consensus that it should SeND the 1st item Geoff: that was ND not SeND; SeND is critical of this; it is an aspect. Daniel: Shoul be handle in the security first. -- Pascal: not sure I got that Carsten: it's hard to finish any doc without referncing bootstrapping. Erik: The mike has feedback loop :) it would be nice for implementers that ND, bootstrap and SeND optimization be in a single documentation. There's more than suppressing messages. The expertise for the security part is different than the rest so there's a need for multiple skills for a same document. Assuming it is in the recharter :) ?: concerns with mobility merged with bootstrapping. Because of the goal of proposed standard. We dd not discuss how to deal with mobility on 6LoWPAN area. Many scenarios. I recommend it is a mobility be a separate item. Geoff: which mobility. Intra PAN? Carsten: everyone has different scenarios in mnd for Mobility. It is a vast landscape. Mark or David?: to narrow the list. We could use 'is the topic critical to get to the point that it enables the end device (interop). Mesh router first implement later is not necessarily a success. We can work with other WGs. We have the bits in the air (almost) that is 10% of the code. Geoff: we need people willing to work on it. G. KIM: about combining bootstra and ND. Agree with erik that we need a common outline. We have to think multiple bootstrap itesms together (multiple routers, sharing keys). Might include multiple scenarios eg. ND RA scheme. Multiple issues to bootstrap / Commissioning on top of pure ND. I agree with David about the criteria: What is the way of moving fwd to impact the industry. what is required on the routing protocol and then move fwd with interop quickly. Hee Jung KIM. People are cncerned about scenarios. We have to have concensus on scenarios we are working on. Carsten: which ones do you want? HJ. Kim data centric, events centric sensors networks. Carsten: there are books like that. We want a small number of them as benchmark. I tried to get good reqs since the beginning of the WG. Geoff let's try again, there are new faces here. Ki Hyung Kim: IPUSN (Ubiquitous Sensor Network) has started in Korea and mght be killer ap. Large scale sensor network. Pipelines traffic lights. items: integrated network management (SNMP based) scalability of sensor networks (extend the newrk mobility (mobile phones over the network with location based services offered by 6LoWPAN) Geoff: Im' going t SP100 tomorrow. Nicolas Chevrollier: could consider medical (health care) like body area network. David: need scenarios with a degree of layering. We need the features in details; design features and aspects. Ki Hyung Kim: One more thing. Last year, we built a test bed in Jeju Island. 802.11g WSN backbone. connected to meteo, managed from a single integrated platform (pseudo snmp). demonstrated that costline watching with IP was possible. It is important to show the connectivity extension over IP. Carsten: that's why we have item 3. about item 5, is that wise to have a document for that? Mark threat analyis is very important. Security review will ask you that, what's your security model? Geoff: what is that implementors need today. Maybe Mesh is not needed right now. Interesting topic. Carsten: You can not use dymo as is. We need to look at protocols and adapt them Pascal: maybe talk to MANEMO and get your requirements there. Mark: Looks like a minibof. David: what is the strategy? This group as a whole, BOFs with focus? Encourage temp use of options to move forward with attempts? What the strategy? Carsten: nobody mentioned the only protocol that does it all. Ian Chakeres: What interoperability are you looking for? Geoff: If we enable a number of routing protocols, vendors could pick and choose or not to. everyone comes up with a simulation, optimizing this and that (energy etc....) Need to converge to IP layer and s structure that enables Ian depends where you want to break up tye problems. If you leave it to implementors/vendors, you'll get no interop, (like 802.11s model). Geoff we might have a problem with a consensus with which 6LoWPAN MANET we'd use. Ian: MANET has consensus, one reactive and one proactive protocols. Can 6LoWPAN reach consensus on whether you want proactive or reactive. Mark: you brought up IEEE. There's a lot of routing experience at IETF. You'll need to quantify, clearly articulate the applicability of routing protocols if you let in more than one. There might be IRTF work if you need them. JP: statement says that the routing rotocol is below the IP layer. Can you elaborate? Erik: Question is where are the IP subnet boundaries. If you need that semantics it's a bit hard to manage like renumber when the topology changes. You have Dave Thaler draft about network models that you can use. Ian Chakeres: 6LoWPAN might operate over different phys but a single type for a give network. Correct? Geoff: originally, we wanted narrowing the problem so single phy. over a campus it could get multiple PHYs. I'm not sure I ready to answer that single PHY PAN question. Ian: Heterogeneous prevents teh mesh under model ?: device authentication. Is it security analysis? do we allow any sensor in at any time? ?: should be bootstrapping architecture. we do not havea solution right now. Geoff: 15.4 has semantics for associations and stuff. Do we mandate a 15.4 function for doing commissoning or joining, Dave: Current doc does not contemplate multiple PHYs. Places constraints like mac source / destination address. does not currently require any specific of the MAC. We can have mesh under and route over. Erik: mesh under vs. mobility. You can make your subnet bigger for instance. if you let in more than one. There might be IRTF work if you need them. market does not have to make wars to decide. Sorry I could not attend IETF 69 (saving dpt $)
  • Why IP for Sensor Networks ?

    1. 1. Why IP for Sensor Networks ? SENSORCOMM 2007 JP Vasseur - Cisco Distinguished Engineer [email_address]
    2. 2. Agenda <ul><li>Sensor Networks today … A few facts: </li></ul><ul><ul><li>Wide range of applications, </li></ul></ul><ul><ul><li>Proprietary worlds, </li></ul></ul><ul><ul><li>Technical challenges, </li></ul></ul><ul><ul><li>Multi-dimensional problem scope </li></ul></ul><ul><li>The current Internet - A few design principles </li></ul><ul><li>Internet of Things = Internet + Sensor Networks </li></ul><ul><li>Sensor Networks at the IETF </li></ul><ul><li>Conclusion </li></ul>
    3. 3. Agenda <ul><li>Sensor Networks today … A few facts: </li></ul><ul><ul><li>Wide range of applications, </li></ul></ul><ul><ul><li>Proprietary worlds, </li></ul></ul><ul><ul><li>Technical challenges, </li></ul></ul><ul><ul><li>Multi-dimensional problem scope </li></ul></ul><ul><li>The current Internet - A few design principles </li></ul><ul><li>Internet of Things = Internet + Sensor Networks </li></ul><ul><li>Sensor Networks at the IETF </li></ul><ul><li>Conclusion </li></ul>
    4. 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 Smart Home Defense High-Confidence Transport and assets tracking Intelligent Building Health
    5. 5. New applications pretty much every day … but … <ul><li>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 </li></ul><ul><li>Many non-interoperable “solutions” addressing specific problems (“ My application is specific” syndrome ) </li></ul><ul><ul><li>Different Architectures , </li></ul></ul><ul><ul><li>Different Protocols </li></ul></ul>=> Deployments are limited in scope and scale,
    6. 6. Research and Sensor Networks <ul><li>Research in Sensor Networks has been very active over the past decade, </li></ul><ul><li>Sensor Networks provide an infinite source of fairly complex problems (NP-Complete :-)) </li></ul><ul><li>Considerable number of solutions seeking for ultimate efficiency (e.g. “local” optimum) </li></ul>
    7. 7. Sensor Networks - Usually a constrained environment <ul><ul><li>Energy consumption is a major issue (for non powered sensors/controllers), </li></ul></ul><ul><ul><li>Limited processing power (CPU, memory), </li></ul></ul><ul><ul><li>Prone to failures => very dynamic topologies, </li></ul></ul><ul><ul><li>When mobile => increase the dynamic nature of topology, </li></ul></ul><ul><ul><li>Data processing may be required on the node itself, </li></ul></ul><ul><ul><li>Sometimes deployed in harsh environments, </li></ul></ul><ul><ul><li>Potentially deployed at very large scale, </li></ul></ul><ul><ul><li>Must be self-managed (auto-discovery, self-organizing networks) </li></ul></ul>
    8. 8. A truly multi-dimensional issue Degree of mobility Degree of scalability Degree of constraints (link/node) Smart cities Connected Building Industrial
    9. 9. Agenda <ul><li>Sensor Networks today … A few facts: </li></ul><ul><ul><li>Wide range of applications, </li></ul></ul><ul><ul><li>Proprietary worlds, </li></ul></ul><ul><ul><li>Technical challenges, </li></ul></ul><ul><ul><li>Multi-dimensional problem scope </li></ul></ul><ul><li>The current Internet - A few design principles </li></ul><ul><li>Internet of Things = Internet + Sensor Networks </li></ul><ul><li>Sensor Networks at the IETF </li></ul><ul><li>Conclusion </li></ul>
    10. 10. <ul><li>More than 1.2 billions users (18.9% of the population) </li></ul><ul><li>Usage growth: 244.7% </li></ul><ul><li>An extremely wide range of applications: Emails, Web, Voice, Video, TV, Mobility, … </li></ul>An impressive success
    11. 11. <ul><li>What ? A Layered architecture => flexible, </li></ul><ul><li>Where ? The End to End design principle, </li></ul><ul><li>How ? Separation of the networks from the services: IP indifferent to PHY and applications, </li></ul><ul><li>Why ? The Internet as a platform for innovation. No central gatekeeper exerting control over the Internet. </li></ul>A few key design principles of the Internet Source: Prepared statement of Vint Cerf - Feb ‘07
    12. 12. <ul><li>The IP protocol suite is based on open standard designed for interoperability , extensibility … as opposed to seeking for local optimums </li></ul>
    13. 13. Agenda <ul><li>Sensor Networks today … A few facts: </li></ul><ul><ul><li>Wide range of applications, </li></ul></ul><ul><ul><li>Proprietary worlds, </li></ul></ul><ul><ul><li>Technical challenges, </li></ul></ul><ul><ul><li>Multi-dimensional problem scope </li></ul></ul><ul><li>The current Internet - A few design principles </li></ul><ul><li>Internet of Things = Internet + Sensor Networks </li></ul><ul><li>Sensor Networks at the IETF </li></ul><ul><li>Conclusion </li></ul>
    14. 14. The Internet will extend to billions of new devices 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 Can we Make the “Internet of Things” a reality ? IP everywhere
    15. 15. A Challenging situation: the example of Routing <ul><li>Current Internet </li></ul><ul><ul><li>Nodes are routers </li></ul></ul><ul><ul><li>IGP with typically few hundreds of nodes, </li></ul></ul><ul><ul><li>Links and nodes are stable, </li></ul></ul><ul><ul><li>Nodes constraints or link bandwidth are typically non issues, </li></ul></ul><ul><ul><li>Routing is not application-aware (MTR is a vanilla version of it) </li></ul></ul><ul><li>Sensor Networks </li></ul><ul><ul><li>Nodes are sensor/actuators&routers </li></ul></ul><ul><ul><li>An order of magnitude larger in term of number of nodes, </li></ul></ul><ul><ul><li>Links are highly unstable and Nodes die much more often, </li></ul></ul><ul><ul><li>Nodes/Links are highly constrained </li></ul></ul><ul><ul><li>Application-aware routing, in-Band processing is a MUST </li></ul></ul>
    16. 16. So far … WAS (Wait And See) - The current Trend Internet L2N L2N TrueMesh Wireless HART ISA SP100.11a Xmesh Znet MintRoute MultiHop LQI CENS Route Smartmesh TinyAODV Honeywell
    17. 17. Issues with WAS (Wait And See) Internet <ul><li>Haven’t we learnt from the past ? Remember SNA (DLSw), IPX, Vines, … </li></ul><ul><li>Management complexity </li></ul><ul><li>Lack of end to end routing consistency, Multi-topology routing, management, security, … </li></ul><ul><li>Migration may just not be possible for Sensor Networks after too much time </li></ul>Multi-protocol Gateway (IP-proxy, protocol translations) SN SN SN SN SN SN SN
    18. 18. Or … IP end to end Internet IP router ! SN SN SN SN SN SN SN SN Which does not mean a single flat domain of course
    19. 19. The “Mesh Under” versus “Route Over” Debate or again “Why do we need IP” ? <ul><li>Many times people have argued in favor of a layer-2 approach for Sensor Nets, at best with IP reachability, </li></ul><ul><li>Sensor Networks are made of a variety of links: wired and wireless, </li></ul><ul><li>Even for WSN, there won’t be a single “winner”: IEEE 802.15.4, LP Wifi, Wibree, … </li></ul>IP routing is a must for Sensor Networks
    20. 20. Combine “Mesh Under” and Route Over” <ul><li>IP Routing over 802.11s, 802.16J, 802.15.5, Zigbee </li></ul><ul><li>IP layer with no visibility on the layer 2 path characteristic </li></ul><ul><li>Makes “optimal” routing very difficult </li></ul><ul><li>Layer 2 path (IP links) change because of layer 2 rerouting (failure or reoptimization) lead to IP kink metric changes. How is this updated ? </li></ul><ul><li>Remember IP over ATM </li></ul><ul><li>There is still a need for an abstraction layer model but for Point to Point layer 2 links </li></ul>
    21. 21. Combine “Mesh Under” and Route Over” <ul><li>Another major challenge: multi-layer recovery </li></ul><ul><li>Require a multi-layer recovery approach </li></ul><ul><li>Current models are timer-based: </li></ul><ul><ul><li>Needs to be conservative and most of the time bottom-up </li></ul></ul><ul><ul><li>Increased recovery time for failures non recoverable at layer 2 </li></ul></ul><ul><li>Inter-layer collaborative approaches have been studied (e.g. IP over Optical) => definitively too complex for current Sensor Hardware </li></ul>
    22. 22. Can we make The Internet of Things a reality? YES ! With some effort … <ul><li>Adapt existing protocols … do *not* reinvent the wheel and learn from the past </li></ul><ul><li>And when needed,design new protocols: </li></ul><ul><ul><li>Example ? Routing … (see next slides) </li></ul></ul><ul><li>But preserve the fundamental openness of IP </li></ul><ul><li>IP is ubiquitous and Sensors are everywhere … Good match. </li></ul>
    23. 23. Can we make The Internet of Things a reality? YES ! With some effort (Cont) <ul><li>Do not try to find a solution to all potential problems: reduce the problem scope </li></ul>
    24. 24. Specify new IP protocols when needed <ul><li>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), </li></ul><ul><li>Highly constrained devices </li></ul><ul><li>Harsh & dynamic environments : (variable link qualities, link/nodes fail at a rate significantly higher than within the Internet) </li></ul><ul><li>Small MTU ( high error rate, limited buffer/bw) </li></ul><ul><li>Constraint routing is a MUST: take into account link *and* nodes properties and constraints (also unusual) </li></ul><ul><li>Deep power management: WSN in sleep mode most of the time </li></ul>Let’s face a reality: routing in Sensor Networks has unique requirements:
    25. 25. <ul><li>Highly heterogeneous capabilities </li></ul><ul><li>Structured traffic patterns : P2MP, MP2P but also more and more P2P </li></ul><ul><li>Multi-path and asymmetrical load balancing </li></ul><ul><li>Data aware routing : data aggregation along a dynamically computed path to a sink. </li></ul><ul><li>Self-Managed !! </li></ul>Specify new IP protocols when needed (Cont)
    26. 26. Why can’t we use an existing routing protocol ? <ul><li>Many IP routing protocols have been designed: RIP, OSPF, AODV , OLSR , DYMO, TBRPF </li></ul><ul><li>But … </li></ul><ul><li>As pointed out Routing requirements for L2Ns are unique, </li></ul><ul><li>None of them satisfy the minimum set of requirements, </li></ul><ul><li>Some of them could be adapted/twisted/… but that means major protocol rework. </li></ul>
    27. 27. Agenda <ul><li>Sensor Networks today … A few facts: </li></ul><ul><ul><li>Wide range of applications, </li></ul></ul><ul><ul><li>Proprietary worlds, </li></ul></ul><ul><ul><li>Technical challenges, </li></ul></ul><ul><ul><li>Multi-dimensional problem scope </li></ul></ul><ul><li>The current Internet - A few design principles </li></ul><ul><li>Internet of Things = Internet + Sensor Networks </li></ul><ul><li>Sensor Networks at the IETF </li></ul><ul><li>Conclusion </li></ul>
    28. 28. The Internet Engineering Task Force <ul><li>IETF formed in 1986, </li></ul><ul><li>Not considered as important for some time :-) </li></ul><ul><li>Not government approved :-) </li></ul><ul><li>Involving people not companies </li></ul><ul><li>Motto: “ We reject kings, presidents and voting. We believe in rough consensus and running code ” Dave Clark (1992) </li></ul><ul><li>Organized in areas made of WGs, </li></ul>GEN OAM INT RTG APS RAI TSV SEC <ul><li>Roughly 120 WGs </li></ul><ul><li>Long term problem handled by the IRTF </li></ul>6lowpan
    29. 29. IPv6 over Low power WPAN (6LoWPAN) <ul><li>Additional information is available at tools.ietf.org/wg/6lowpan </li></ul><ul><li>Chair(s): </li></ul><ul><ul><li>Carsten Bormann < [email_address] .org> Geoffrey Mulligan < [email_address] .org> </li></ul></ul><ul><li>Internet Area Director(s): </li></ul><ul><ul><li>Jari Arkko < jari . [email_address] .net> Mark Townsley < [email_address] .com> </li></ul></ul><ul><li>Internet Area Advisor: </li></ul><ul><ul><li>Mark Townsley < [email_address] .com> </li></ul></ul><ul><li>Secretary(ies): </li></ul><ul><ul><li>Christian Schumacher < [email_address] .com> </li></ul></ul><ul><li>Mailing Lists: </li></ul><ul><ul><li>General Discussion: 6lowpan@lists.ietf.org To Subscribe: [email_address] In Body: subscribe Archive: https://www1.ietf.org/mailman/listinfo/6lowpan </li></ul></ul>
    30. 30. RFC 4919 - LoWPANs Problem Statement <ul><li>IEEE 802.15.4 Networks, characterized by: </li></ul><ul><li>Significantly more devices than current networks </li></ul><ul><li>Severely limited code and ram space </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Unobtrusive but very different user interface for configuration </li></ul><ul><ul><li>using gestures or interactions involving the physical world </li></ul></ul><ul><li>Robustness and simplicity in routing or network fabric </li></ul><ul><li>802.15.4 a, b, 2003, 2006, and maybe wibree </li></ul><ul><li>More in RFC 4919 </li></ul>
    31. 31. RFC 4944: IPv6 over IEEE 802.15.4 <ul><li>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. </li></ul><ul><li>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 </li></ul><ul><li>Worst case payload = 127 bytes - 25 (max frame overhead) - 21 (link layer security AES-CCM-128) = 81 bytes </li></ul><ul><li>Max payload application = 81 bytes - 40 (v6 header) - 8 (UDP) = 33 bytes </li></ul><ul><li>Notes: </li></ul><ul><ul><li>Most applications of IEEE 802.15.4 will not use such large packets </li></ul></ul><ul><ul><li>Small application payloads in conjunction with header compression will produce packets that fit within a single IEEE 802.15.4 frame. </li></ul></ul><ul><li>RFC 4944 defines two compression schemes: </li></ul><ul><ul><li>HC1: IPv6 header compressed from 40 bytes to 3 bytes </li></ul></ul><ul><ul><li>HC2: UDP header compressed from 8 bytes to 4 bytes </li></ul></ul>
    32. 32. WG Status <ul><li>The Problem Statement document made RFC 4919 </li></ul><ul><li>The Format Document is to submitted to AD for publication </li></ul><ul><li>Re-chartering is underway. Proposed topics: </li></ul><ul><ul><li>most important: ND and bootstrapping. </li></ul></ul><ul><ul><ul><li>We do not want to change ND but optimize the packet usage. </li></ul></ul></ul><ul><ul><ul><li>Mobility will be very important there </li></ul></ul></ul><ul><ul><li>2) stateful Header Compression. </li></ul></ul><ul><ul><li>HC1 is stateless and a stateful could be useful </li></ul></ul><ul><ul><li>3) Recommendations for 6lowpan Applications </li></ul></ul><ul><ul><li>Protocols for transport, L7, discovery, configuration and commissioning. </li></ul></ul><ul><ul><li>4) security in a LoWPAN. </li></ul></ul><ul><ul><li>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. </li></ul></ul>
    33. 33. The IETF and Sensor Networks <ul><li>Remember: Reuse whenever possible, Invent where needed </li></ul>GEN OAM INT RTG APS RAI TSV SEC Reuse New Existing WG dealing with SNs
    34. 34. IETF & Sensor Nets: Standardization status <ul><li>New initiative on Routing for Sensor Networks </li></ul><ul><li>RSN => RL2N (Routing for Low Power and Lossy Networks): </li></ul><ul><li>RL2N new mailing list where the routing issues are discussed. Several large players have joined the initiative: https://www1.ietf.org/mailman/listinfo/rsn </li></ul><ul><li>Presentation in Chicago, plan to have a BOF in Vancouver. </li></ul><ul><li>In the works: </li></ul><ul><ul><li>Problem statement </li></ul></ul><ul><ul><li>Routing Requirement ID for Connected Home </li></ul></ul><ul><ul><li>Routing Requirements ID for Industrial applications </li></ul></ul><ul><ul><li>Survey on existing routing protocol applicability </li></ul></ul><ul><ul><li>Routing metrics for RL2N </li></ul></ul><ul><ul><li>In progress: Routing Requirements ID for Smart cities </li></ul></ul>Limited scope !
    35. 35. The End to End principles in a few words <ul><li>Concept arose in 1981 “ END-TO-END ARGUMENTS IN SYSTEM DESIGN ” J.H. Saltzer, D.P. Reed and D.D. Clark </li></ul><ul><ul><li>“ 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 ” </li></ul></ul><ul><li>Careful thoughts must be given to where functions must be handled (low versus high layers): a performance trade-off </li></ul><ul><li>Various examples of functions that should be handled by high layers are examined: delivery guarantees, security, duplicate, … </li></ul><ul><li>Sometimes (mis)understood as “ This leads to the model of a &quot;dumb, minimal, network&quot; with smart terminals” </li></ul><ul><li>“ 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.” </li></ul>
    36. 36. The End to End principles in a few words <ul><li>A way to address concerns to maintain openness, increase reliability, preserve user choice, ease for innovation, </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Pressures on the end-to-end principle in today's Internet </li></ul><ul><ul><li>Lack of trust and emergence of new security models </li></ul></ul><ul><ul><li>New service models (achieve proper performance) </li></ul></ul><ul><ul><li>Data-ware routing, in-band processing in sensor networks … </li></ul></ul>
    37. 37. Do we need to revisit the end to end principles ? <ul><li>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)) </li></ul><ul><li>Adding function in lower layers highly beneficial for several applications: QoS, Unwanted traffic, Security </li></ul><ul><li>Care must be given to: </li></ul><ul><ul><li>Layer violation creating dependencies that would make it impossible for the transport layer, for example, to do its work appropriately. </li></ul></ul><ul><ul><li>Another issue is the desire to insert more applications infrastructure into the network. </li></ul></ul>See RFC 3724
    38. 38. What does that mean for Sensor Networks? <ul><li>Dataware routing, in-band network processing are key functions that must be supported by the network </li></ul><ul><li>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 </li></ul><ul><li>Data content not always meaningful </li></ul><ul><li>Use of network resources can be very expensive (e.g. battery powered WSNs) </li></ul><ul><li>Data can be correlated to trigger network based actions </li></ul>
    39. 39. What does that mean for Sensor Networks? Internet SN SN SN SN SN <ul><li>Dataware routing, in-band network processing, at the edge of the extended Internet (private sub-Internet), </li></ul><ul><li>Functions limited in scope. </li></ul>Public @ IP-based SNs with in-band processing, …
    40. 40. Conclusion (1) <ul><li>Sensor networks have a tremendous number of opportunities but it is time to react and change the current “trend” (myriad of proprietary worlds), </li></ul><ul><li>The “WAS” approach will unavoidably lead to translation protocol gateways, complex tunneling, cross layer adaptations: a known dead-end. </li></ul><ul><li>We (hopefully) learnt from the past: open-based standard is KEY. IP is obvious the protocol, </li></ul><ul><li>The network layer must be independent of the Layer-1/2 (Sensor Nets are not made of a single type of L1/L2 !) </li></ul><ul><li>The pervasive nature of IP networks allows use of existing infrastructure. </li></ul>
    41. 41. Conclusion (2) <ul><li>Device to device communication traffic will undoubtedly drastically increase in nature and in traffic volumes, </li></ul><ul><li>A Plethora of existing protocols/tools can be used: reuse as much as possible but also design new IP protocols when needed , </li></ul><ul><ul><li>Security, </li></ul></ul><ul><ul><li>Naming, </li></ul></ul><ul><ul><li>Addressing </li></ul></ul><ul><ul><li>Discovery </li></ul></ul><ul><ul><li>OAM tools </li></ul></ul><ul><li>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. </li></ul><ul><li>And no this is a not a religious debate but a fundamental architectural choice. </li></ul>
    42. 42. Questions