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 &quot;sensor&quot; (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 &quot;low&quot; 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, &quot;architecture&quot; useful practical doc) More like &quot;ways things work&quot;. 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 ? SENSORCOMM 2007 JP Vasseur - Cisco Distinguished Engineer [email_address]
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
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 )
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
A Challenging situation: the example of Routing
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)
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
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
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.”
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 : 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 …
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.
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 ,
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.