© 2007 Cisco Systems, Inc. All rights reserved. 1 JP Vasseur - SENSORCOMM 2007 - Spain Why IP for...

© 2007 Cisco Systems, Inc. All rights reserved. 1JP Vasseur - SENSORCOMM 2007 - Spain

Why IP for Sensor Networks ?

SENSORCOMM 2007

JP Vasseur - Cisco Distinguished Engineer

[email protected]

© 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


Agenda








Conclusion


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

Health

Smart Home

Defense

High-Confidence Transport and assets tracking

Intelligent Building


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,


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)


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)

Sensors

Battery/Power

Mote:MicrocontrollerStorageRadioClock

Enclosure


A truly multi-dimensional issueDegree of mobility

Degre

e of

sca

labi

lity

Degree of constraints (link/node)

Smart cities

Connected Building

Industrial


Agenda








Conclusion


• 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


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


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


Agenda








Conclusion


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

IPeverywhere

Can we Make the “Internet of Things” a reality ?


A Challenging situation: the example of Routing

Current InternetNodes 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 NetworksNodes 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


Internet

L2N

L2N

TrueMesh

Wireless HART

ISA SP100.11a

Xmesh

Znet

MintRoute

MultiHop LQI

CENS Route

Smartmesh

TinyAODV

Honeywell

So far … WAS (Wait And See) - The current Trend


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)SNSN

SN

SN

SN

SN

SN

Issues with WAS (Wait And See)


Or … IP end to end

Internet

IP router !SNSN

SN

SN

SN

SN

SN

SN

Which does not mean a single flat domain of course


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


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


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


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.


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


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:


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)


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.


Agenda








Conclusion


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,

GEN OAM INT RTGAPS RAI TSVSEC

• Roughly 120 WGs• Long term problem handled by the IRTF

6lowpan


IPv6 over Low power WPAN (6LoWPAN)

Additional information is available at tools.ietf.org/wg/6lowpan

Chair(s):Carsten Bormann <[email protected]> Geoffrey Mulligan <[email protected]>

Internet Area Director(s):Jari Arkko <[email protected]> Mark Townsley <[email protected]>

Internet Area Advisor:Mark Townsley <[email protected]>

Secretary(ies):Christian Schumacher <[email protected]>

Mailing Lists:General Discussion: [email protected] Subscribe: [email protected] Body: subscribeArchive: https://www1.ietf.org/mailman/listinfo/6lowpan


RFC 4919 - LoWPANs Problem Statement

IEEE 802.15.4 Networks, characterized by: Significantly more devices than current networks

Severely limited code and ram space

highly desirable to fit the required code--MAC, IP and anything else needed t execute the embedded application-- in, for example, 32K of flash memory, using 8-bit microprocessors

Unobtrusive but very different user interface for configuration

using gestures or interactions involving the physical world

Robustness and simplicity in routing or network fabric

802.15.4 a, b, 2003, 2006, and maybe wibree

More in RFC 4919


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


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 ApplicationsProtocols 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.


The IETF and Sensor Networks

• Remember: Reuse whenever possible, Invent where needed

GEN OAM INT RTGAPS RAI TSVSEC

Reuse New Existing WG dealing with SNs


IETF & Sensor Nets: Standardization status New initiative on Routing for Sensor Networks

RSN => RL2N (Routing for Low Power and Lossy Networks):

RL2N new mailing list where the routing issues are discussed. Several large players have joined the initiative: https://www1.ietf.org/mailman/listinfo/rsn

Presentation in Chicago, plan to have a BOF in Vancouver.

In the works:Problem statement

Routing Requirement ID for Connected Home

Routing Requirements ID for Industrial applications

Survey on existing routing protocol applicability

Routing metrics for RL2N

In progress: Routing Requirements ID for Smart cities

Limited scope !


The End to End principles in a few words

• Concept arose in 1981 “END-TO-END ARGUMENTS IN SYSTEM DESIGN ” J.H. Saltzer, D.P. Reed and D.D. Clark

“Functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level”

• Careful thoughts must be given to where functions must be handled (low versus high layers): a performance trade-off

• Various examples of functions that should be handled by high layers are examined: delivery guarantees, security, duplicate, …

• Sometimes (mis)understood as “This leads to the model of a "dumb, minimal, network" with smart terminals”

•“Thus the end-to-end argument is not an absolute rule, but rather a guideline that helps in application and protocol design analysis; one must use some care to identify the end points to which the argument should be applied.”


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 …


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


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


What does that mean for Sensor Networks?

Internet

SN

SN

SN

SN

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, …


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.


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.

© 2007 Cisco Systems, Inc. All rights reserved. 1 JP Vasseur - SENSORCOMM 2007 - Spain Why IP for...

Documents

Transcript of © 2007 Cisco Systems, Inc. All rights reserved. 1 JP Vasseur - SENSORCOMM 2007 - Spain Why IP for...