1 / 57

TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)

TinyOS – Time to ROLL (Routing over Low power and Lossy Networks). David E. Culler 1 st European TinyOS Technology Exchange TTX VI Feb 10, 2009. A decade ago…. Traditional Systems. Well established layers of abstractions Strict boundaries Ample resources

oriole
Télécharger la présentation

TinyOS – Time to ROLL (Routing over Low power and Lossy Networks)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TinyOS – Time to ROLL(Routing over Low power and Lossy Networks) David E. Culler 1st European TinyOS Technology Exchange TTX VI Feb 10, 2009

  2. A decade ago… ETTX

  3. Traditional Systems • Well established layers of abstractions • Strict boundaries • Ample resources • Independent Applications at endpoints communicate pt-pt through routers • Well attended Application Application User System Network Stack Transport Threads Network Address Space Data Link Files Physical Layer Drivers Routers ETTX

  4. by comparison, WSNs ... • Highly Constrained resources • processing, storage, bandwidth, power • Applications spread over many small nodes • self-organizing Collectives • highly integrated with changing environment and network • communication is fundamental • Concurrency intensive in bursts • streams of sensor data and network traffic • Robust • inaccessible, critical operation • Unclear where the boundaries belong • even HW/SW will move • => Provide a framework for: • Resource-constrained concurrency • Defining boundaries • Appl’n-specific processing and power management • allow abstractions to emerge ETTX

  5. Internet Research Perspective…then • “Resource constraints may cause us to give up the layered architecture.” • “Sheer numbers of devices, and their unattended deployment, will preclude reliance on broadcast communication or the configuration currently needed to deploy and operate networked devices.” • “There are significant robustness and scalability advantages to designing applications using localized algorithms.” • “Unlike traditional networks, a sensor node may not need an identity (e.g. address).” • “It is reasonable to assume that sensor networks can be tailored to the application at hand.” ETTX

  6. (including runtime) And Now: Complete IPv6 in TinyOS • Footprint, power, packet size, & bandwidth * Production implementation on TI msp430/cc2420 ETTX

  7. … and in Open Source ETTX

  8. and Power and Reliability … Data Rate Sensitivity (Router) Data Rate Sensitivity (Edge) Deployment Duty Cycle Deployment Reliability ETTX

  9. Where Did We Go Wrong? ETTX

  10. Networks Ethernet WiFi Serial links connect hosts and devices and other networks together Horizontally integrated Peripheral Interconnects USB, Firewire IDE / SCSI RS232,RS485 IRDA BlueTooth connect one or more devices to a host computer Vertically integrated Physical link to application ethernet wifi LoWPAN Internet – Networks of Networks vs ETTX

  11. hartcomm.org Which are real sensors nets like? Trending Monitoring Data Analytics Management Ethernet WiFi RS232 RS485 GPRS Controllers Operations Field Units ETTX

  12. A Network Starts with a Router ETTX

  13. zeevo BT Intel MOTE2 Intel iMOTE LWIM-III (UCLA) Intel/UCB dot BTNode Eyes Intel cf-mica trio Mica Telos XBOW mica XBOW mica2 XBOW cc-dot XBOW rene2 XBOW micaZ digital sun rain-mica Bosch cc-mica Dust Inc blue cc-TI Mote/TinyOS – let chaos reign WINS(UCLA/ROckwell) Intel rene’ SmartDust WeC Rene 00 01 02 03 04 05 06 07 97 98 99 LWIM Expedition NEST Cyber-Physical SENSIT CENS STC NETS/ NOSS DARPA 8 kB rom ½ kB ram 48 kB rom 10 kB ram 802.15.4 NSF ETTX

  14. 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 Deluge Drip Dip GAF SPIN GDI Redwoods North Sea Volcano Golden Gate Bridge Drain Flush Broadcast Storm TinyOS 0.6 PSFQ CODA RMST FPS Fusion MultihopLQI BVR CTP S4 MintRoute SP WooMAC S-MAC Aloha PS T-MAC B-MAC WiseMAC SCP-MAC PEDAMACS X-MAC And rain it did… Application Transport Network Link ETTX

  15. A Low-Power Standard Link • Low Transmit power, Low SNR, modest BW, Little Frames • Reined in the Phy Chaos, allowed MAC chaos to Reign ETTX

  16. Key Developments • Event Driven Execution closely tied to storage mgmt • reliable concurrency, small footprint, and low-power usage • Idle listening • Radio power: transmit ≈ receive≈ just listening • All the energy is consumed by listening for a packet to receive • E = P*Time => Turn radio on only when there is something to hear • Reliable routing on Low-Power & Lossy Links • Power, Range, Obstructions => multi-hop • Always at edge of SNR => loss happens => monitoring, retransmission, and local rerouting • Trickle – don’t flood (tx rate < 1/density, and < info change) • Connectivity is determined by physical points of interest, not network designer. May have huge number of neighbors, so … • never naively respond to a broadcast, re-broadcast very very politely ETTX

  17. 128 bits Prefix IID ICMPv6 IPv6 Base HbH Opt Routing Fragment Dst Opt Meanwhile: Key IPv6 Contributions • Large simple address • Network ID + Interface ID • Plenty of addresses, easy to allocate and manage • Autoconfiguration and Management • ICMPv6 • Integrated bootstrap and discovery • Neighbors, routers, DHCP • Protocol options framework • Plan for extensibility • Simplify for speed • MTU discovery with min • 6-to-4 translation for compatibility ETTX

  18. 40 B + options 1280 Bytes MIN 128 Bytes MAX IPv6 over 802.15.4: Not an obvious fit UDP datagram or TCP stream segment …, modbus, BacNET/IP, … , HTML, XML, …, ZCL transport header application payload Network packet net payload cls flow len hops NH src IP dst IP 16 B 16 B ? Link frame link payload len src UID ctrl dst UID chk ETTX

  19. 6LoWPAN adaptation layer Diverse Object and Data Models (HTML, XML, …, BacNet, …) 7: app Application (Telnet, FTP, SMTP, SNMP, HTTP) Transport (UDP/IP, TCP/IP) 4: xport Network (IP) 3: net 6LoWPAN Link 2: link Serial Modem X3T9.5 FDDI 802.3 Ethernet 802.5 Token Ring 802.11 WiFi 802.15.4 LoWPAN 802.11a WiFi 802.3a Ethernet 10b2 802.11b WiFi 802.3i Ethernet 10bT ISDN 802.11g WiFi Sonet 802.3y Ethernet 100bT 802.11n WiFi DSL 802.3ab Ethernet 1000bT GPRS 802.3an Ethernet 1G bT 1: phy ETTX

  20. in HC byte uncompressed IPv6 Header Compression • http://www.visi.com/~mjb/Drawings/IP_Header_v6.pdf v6 zero In 802.15.4 header derive from 802.15.4 header derive from 802.15.4 header ETTX

  21. 6LoWPAN – IP Header Optimization Network packet • Eliminate all fields in the IPv6 header that can be derived from the 802.15.4 header in the common case • Source address : derived from link address • Destination address : derived from link address • Length : derived from link frame length • Traffic Class & Flow Label : zero • Next header : UDP, TCP, or ICMP • Additional IPv6 options follow as options 40 B net payload cls flow len hops NH src IP dst IP Link frame 3 B len hops src UID ctrl dst UID chk 6LoWPAN adaptation header ETTX

  22. Energy Consumption Analysis * * Payload Δ Energy Δ for fixed payload ETTX

  23. Multi-Hop Communication => Routing • Short-range radios & Obstructions => Multi-hop Communication is often required • i.e. Routing and Forwarding • That is what IP does! • “Mesh-under”: multi-hop communication at the link layer • Still needs routing to other links or other PANs • “Route-over”: IP routing within the PAN => ROLL PAN ETTX

  24. IP Link ⇒ Broadcast Domain Structured Decomposition Retain strict modularity Some key cross-layer visibility IPv6 can support a semi-broadcast link with few changes Retain illusion even when always off Retain best-effort reliability over unreliable links Embedded IPv6 in Concept IP Link ⇒ Always On IP Link ⇒ “Reliable” ETTX

  25. ICMPv6 Hdr Router Adv Prefix Info RFC 4861 – Neighbor Discovery RFC 4862 – Stateless Addr Autoconf RFC 3315 – DHCPv6 Trickle AutoconfigurationConfiguring Large Numbers of Interfaces New Options Existing Options MHop Info ETTX

  26. 0x0023 0x0092 2001:abcd::23 2001:abcd::92 AutoconfigurationConfiguring Large Numbers of Interfaces Stateless RFC 4861 + 4862 DHCPv6 RFC 3315 Response Response Request 2001:abcd::23 Request 2001:abcd::92 ETTX

  27. Link Data Ack Media Management Control Remote Media Link Stats Local Media Routing & Forwarding Delivering datagrams over multiple hops with High reliability and Low Energy usage Net Forwarder Router ICMPv6 Routing Protocol Multicast Unicast Buffer Queue Send Manager Forwarding Table Routing Table Send Manager ETTX

  28. Default Routes Routing Table Routing Table Forwarding Table Cross-Fertilization of WSN and IETF ideas Discovering Links ICMPv6 Hdr Router Adv MHop Info Building a Connectivity Graph Low Routing Cost High Routing Cost Selecting the Next Hop • Default route • Hop-by-hop retry • Reroute on loss ETTX

  29. Forwarder UDP TCP Multicast Unicast Buffer Queue Send Manager Forwarding Table Send Manager Complete Embedded IPv6 Stack App HTTP Telnet SNMP DNS … DHCPv6 Tran Net Router ICMPv6 Autoconf Routing Protocol Routing Table Stateless Autoconf 6LoWPAN Adaptation Link Data Ack Media Management Control Remote Media Link Stats Local Media ETTX

  30. (including runtime) Adding up the pieces * Production implementation on TI msp430/cc2420 ETTX

  31. So what’s Next? ETTX

  32. Rein in the Chaos – by layers ETTX

  33. Y-A-MAC? • Yet-Another-MAC layer? • If it is REALLY going to be a standard • Interoperability ‘within the PAN’ requires compatible MACs. • 802.15.4 left a big hole • Beaconing doesn’t work • No low power defined for FFD • Perhaps the research community should stop “differentiating” and step forward to make one MAC stick • Frame formats are not “up for debate” • Visibility @ Link / Net Interface ETTX

  34. Routing - really • At layer 3 • Not 2, not 7, 3! • Implemented with routing table, forwarder, and well-defined protocols • Packets, States, Actions • ROLL working group in IETF • Application “requirements” • Excellent Protocol Survey • Entering actual work phase ETTX

  35. ROLL Internet Drafts • draft-ietf-roll-protocols-survey-052009-01-26   • draft-ietf-roll-terminology-00 2008-10-27   • draft-ietf-roll-building-routing-reqs-05 2009-02-04   • draft-ietf-roll-home-routing-reqs-062008-11-19   • draft-ietf-roll-indus-routing-reqs-042009-01-22   • draft-ietf-roll-urban-routing-reqs-032009-01-08  ETTX

  36. The Heart of ROLL ETTX

  37. Transport • Crazy not to support UDP and TCP • Do we enter a TCP for LLNs renaissance? • Do we define a new transport? • What is the “embedded sockets API?” ETTX

  38. Issues in Communication Abstraction • Names • What are they? • What do they mean? What is their scope? • How are they allocated? • How are they translated into useful properties • Address? Physical Resource? • Storage • Transmit • When can it be reused? How do you know? What do you do when it is full? • Receive • When is it allocated? Reclaimed? By whom? What happens when it overflows? • Asynchronous event • How do you know that something has arrived? ETTX

  39. Answers: Naming • TinyOS Active Messages • TOS_local_addr, 16 bits, only within “a network”, allocated at program download time • Scope limited to TOS_group, within PAN, Channel, and physical extent. • The standards that try to do it all with IEEE 802.15.4 16 bit short address are not much better • IP Architecture • Link name: IEEE 802.15.4 => EUID64 & SA16 • EUID64 globally unique, SA16 assigned to be unique over the PAN • Net name: IP address • Prefix | Interface Id • Must be unique within routability extent • Several IP address: Link Local, Global, Multicast, … • Service name: Port • Hostname Translated to IP by DNS ETTX

  40. Answers: Storage • TinyOS Active Messages • Sender app allocates send buffer, OS owns it till sendDone event • OS provides App with recv buffer, app must return it or a replacement • BSD Sockets • Sender app allocate buffer, copied to kernel on send • Receiver allocates buffer and passes pointer to kernel, kernel copies • Additional sets of buffer managed within the kernel • TinyOS Sockets ??? ETTX

  41. Example: UDP Interface interface Udp { command error_t bind( uint16_t port ); command uint16_t getMaxPayloadLength( const sockaddr_in6_t *to ); command error_t sendto( const void *buf, uint16_t len, const sockaddr_in6_t *to ); event void recvfrom( void *buf, uint16_t len, sockaddr_in6_t *from, link_metadata_t *metadata ); } • Wiring to a UDP interface is enough for sendto – no allocate • Standard Unix sockaddr_in6_t • Bind – associates the component that uses the interface with the port • Starts receiving whatever datagrams come in on it • Sendto sends a datagram from a buf to an IP destination • Neighbor, intra-PAN, inter-network (wherever it needs to go!) • Linklocal address is 1-hop neighbor • Pan-wide routable prefix • Error when not in network or overrun transmit resources • Recvfrom gets a buffer with a datagram and metadata about it • Able to fill the 15.4 frame without knowing details of header compression ETTX

  42. Example: UDP echo service configuration EchoUdpC { } implementation { components KernelC; components EchoUdpP as EchoP; EchoP.Boot -> KernelC.Boot; EchoP.Udp -> KernelC.Udp0; } module EchoUdpP { uses interface Boot, Udp; } implementation { event void Boot.booted() { call Udp.bind( ECHO_PORT ); /* bind to port 7 */ } event void Udp.recvfrom( void *buf, uint16_t len, sockaddr_in6_t *from, link_metadata_t *linkmsg ) { call Udp.sendto( buf, len, from ); /* echo msg back */ } } ETTX

  43. And what about TCP • UDP is a datagram transport • Essentially the same as AM • Fits naturally in event-driven model • Can use NesC platform independent data structure to have unambiguous packet formats without hton / ntoh error prone bit twiddling. • But TCP is a stream protocol… ETTX

  44. TCP Interface interface Tcp { command error_t bind(uint16_t port, uint8_t *buf, uint16_t bufsize); event bool accept( sockaddr_in6_t *to ); command error_t connect( const sockaddr_in6_t *to, uint8_t *buf, uint16_t bufsize ); event void connected(); command error_t send( const void *buf, uint16_t len ); event void acked(); event uint16_t recv( void *buf, uint16_t len ); command error_t close( bool force ); event void closed(); } • Transitions of the TCP protocol reflected as events • Recv per segment • Here, appln allocates send buffer but stack manages it. • Send is not split-phase (!!!) ETTX

  45. TCP echo server module EchoTcpP { uses interface Boot, Tcp; } implementation { uint8_t m_buf[ BUF_SIZE ]; /* Transmit buffer */ event void Boot.booted() { call Tcp.bind( ECHO_PORT, m_buf, sizeof(m_buf) ); } event bool Tcp.accept( sockaddr_in6_t *to ) { return TRUE; } event void Tcp.connected() { } event void Tcp.acked() { } event uint16_t Tcp.recv( void *buf, uint16_t len ) { return ( call Tcp.send( buf, len ) == SUCCESS ) : len ? 0; } event void Tcp.closed() { /* setup socket for new connection */ call Tcp.bind( ECHO_PORT, m_buf, sizeof(m_buf) ); } ETTX

  46. TCP Bind Start Timer Start Event-Driven Execution of Services Service request Fire recv ETTX

  47. Ready ReadDone Split-Phase Data Acquisition Sample Read ETTX

  48. Ready Examples - Tasks serviceReq notify Sample fired readDone fired ETTX

  49. HTTP event bool HttpTcp.accept( sockaddr_in6_t *to ) { serverState = LISTENING; return TRUE; } event void HttpTcp.connected() { serverState = CONNECTED; init_pump(); } event uint16_t HttpTcp.recv( void *inbuf, uint16_t len ) { if (httppump(inbuf,len)) { switch (http_method) { case HTTP_GET : signal Http.GETservice (url, uindex); break; case HTTP_POST: signal Http.POSTservice(url, uindex); break; default: call HttpTcp.close( FALSE ); } } return len; } command error_t Http.serviceDone() { call HttpTcp.close( FALSE ); return SUCCESS; } command error_t Http.send( const void *buf, uint16_t len ) { return call HttpTcp.send( buf, len ); } event void HttpTcp.acked() { } event void HttpTcp.closed(){call HttpTcp.bind(port, resp, respLen);} ETTX

  50. Resource Blueprint at the Top configuration WebSense { } implementation { components KernelC; components WebC as WebC; /* Web request service */ components HttpC as HttpC; /* TCP HTTP (port 80) service */ components new TimerMilliC() as HttpTimer; /* Protocol deadman */ components Msp430Adc12C; /* Hardware ADC abstraction */ components Msp430PortsC; /* Hardware IO Ports */ WebC.Http -> HttpC.Http; /* Protocol interface */ WebC.Boot -> KernelC.Boot; WebC.IPv6Addresses -> KernelC.IPv6Addresses; WebC.Time -> KernelC.GlobalTime; HttpC.HttpTcp -> KernelC.Tcp0; HttpC.IPv6Addresses -> KernelC.IPv6Addresses; HttpC.Timer -> HttpTimer; /* Digital inputs */ components new DigitalInC("Door") as Din0; WebC.Door -> Din0.DigitalIn; Din0.Pin -> Msp430PortsC.Port1[2]; Din0.PinInt -> Msp430PortsC.Port1Interrupt[2]; /* Analog inputs */ components TempIntC; WebC.Temp -> TempIntC.TempInt; TempIntC.ADC -> Msp430Adc12C.Msp430Adc12[INCH_10]; /* Internal temp */ components new AnalogInC(REFVCC, "Pot") as TrimPot; WebC.Pot -> TrimPot.Sensor; TrimPot.ADC -> Msp430Adc12C.Msp430Adc12[INCH_4 ]; } ETTX

More Related