IPv6 Challenges for Embedded Systems István Gyürki 30.08.2011
AGENDA Introduction IPv6 why do we need it? Selecting the right TCP/IP stack Case study Conclusions Page 2
Company Profile Wireless Products for industrial use for B2B Customers Product Development Services for customer-specified electronic products 35 employees, 2 apprentices Founded 1994 Located in Bubikon / Zürcher Oberland Private Key Owners Slide 3
Why do we need IPv6? IPv4 address exhaustion Easier administration: No NAT, No DHCP, Stateless auto-configuration Performance: Optimized header structure better routing performance QoS: flow label Better Multicast and Anycast Security: Mandatory IPSec Mobility: Mobile IPv6 Page 4
IPv6 in resource limited appliances Target devices: Home appliances, like refrigerators and microwave ovens AV equipment Sensors, metering IPv6 Low Cost Network Appliances (LCNA) draft: Devices are not for general purpose, rather targeted at specific tasks. A device that has network functionality, but has limited resources dedicated for it: Memory Speed OS 8-32 bit MPU, 128..512 kb ROM, 16..512 kb RAM Page 5
Selecting a TCP/IP stack IP version support IPv4 IPv6 only IPv4/IPv6 dual stack IPv6 certification (Phase 1/2) - logos Licensing: Open source Commercial (closed source) Costs Page 6
Licensing and costs Careful evaluation of licensing is mandatory Open source licensing requirement examples: - Documentation must mention component - Advertisement materials mention component - Source code must be available upon request Closed source: Per Product / CPU / Architecture/ Platform / Unlimited licensing Basic products around 15-30 k$ Additional features 2-5 k$ each Page 7
Technical selection criteria Support for: CPU/MCU architecture, model Peripherials Operating system Single- or multithreaded operation Required resources Memory (static/dynamic) Processes Timers Synchronization primitives Required layers Physical and Data Link (Eth, PPP, etc.) Network (IPvx, ICMPvx, IGMP, IPSec) Application (DHCP, DNS, FTP, SSL) Page 8
Case study Hardware environment: STM32 32-bit micro, 72 MHz 64 kb RAM (option to 96 kb) 512 kb Flash Software environment: SEGGER embos real-time operating system IAR C/C++ compiler Networking requirements: Ethernet and PPP interfaces Limited number of connections: 1-2 TCP, 1-2 UDP connections, DHCP, ICMP No packet fragmentation No specific speed/throughput required High reliability and availability Page 9
Reference lwip IPv4 configuration Footprint: Code: 26 kb RW Data: 10.25 kb Stack: 1 kb Notes: RAM usage includes preallocated buffers (protocol buffers, interface descriptors, etc.) Fully static allocation from OS point-of-view (no need for malloc/free). lwip has built-in allocation for buffers and other structures, no memory fragmentation. Page 10
IPv6 candidates 4 commercial stacks: In this presentation referenced as: U, I, T, C 3 open source stacks: FreeBSD lwip Contiki For further information about them, please contact us. Page 11
IPv6 candidates pre-selection Commercial: 2 out of 4 stacks (T & C) dropped, according to the manufacturer, wouldn t work with targeted resources, reason is RAM size Open Source: FreeBSD: Dropped due to huge efforts of porting recent versions and foreseen memory requirements (Note: ecos FreeBSD) lwip: Dropped, only experimental IPv6 support Contiki: Phase 1 certified, dropped due to support, OS-specificness, future-proofness Page 12
Board Support Package for I & U Adapting to: Ethernet drivers (already existing) OS TCP/IP Stack Abstraction Layer Configuration and fine-tuning Porting application, tools: Porting basic socket-based functionality is easy Required efforts: 2-4 man-week per TCP/IP stack Page 13
Testing Ethernet: Basic tests are relatively easy using Link-local addresses with standard switch connecting devices PPP: No easy testing possible without real devices (entire infrastructure must support IPv6) IPv6 must be supported by modem, too (e.g. GPRS) No public mobile networks available for testing (yet) in CH Application: Native IPv4 application: netsh portproxy forwarding IPv4 traffic to the target (limitations depending on?) Porting test tools to use IPv6 Page 14
Results: resource usage Compared to reference IPv4 design Additional memory usage Reference Stack I Stack U Stack U IPv4+6 lwip v4 only IPv4+6 IPv4 Full cfg. Reduced cfg. RAM: + to reference 0 1219 1355 4752 4532 Flash: +to reference 0 46123 54576 131163 110570 Dynamically allocated memory used for: Buffers Protocol Control Blocks Interface, socket, message descriptors Reference Stack I Stack U Stack U IPv4+6 lwip v4 only IPv4+6 IPv4 Full cfg. Reduced cfg. Heap size (+ to ref.) 0 +10 kb 8 kb > +10kB > +10kB Task stacks (+ to ref.) 0 +0.5 kb + 0.3 kb?? Page 15
Results: internals Both TCP/IP stacks are relying on OS provided (or external) memory allocation (malloc, realloc, free) Size of some typical internal structures in bytes Reference IPv4 Stack I IPv4+6 Stack U IPv4 Network interface 56 424 392 Socket 68 136 504 TCP proto control block 160 92 252 Message 16 40 232 Page 16
Results: performance TCP write performance Test PC sending data continuously to target over TCP socket write 4k write 1k Stack I IPv6 byte/s 41000 39000 cpu load 95% 95% Stack U IPv4 byte/s 6600 6600 cpu load 15% 15% REFERENCE IPv4 b/s 43000 43000 cpu load 92% 92% Conclusion: No real difference between IPv4/IPv6 performance No difference in application performance Proper configuration is mandatory Page 17
Conclusion IPv6 support is realizable on the target system But with limitations in: Connections (number, type, packet size) Supported features (no IPsec, fragmentation, routing, etc.) Main bottleneck is RAM size: More memory: less limitations Route to embedded linux based devices Page 18
Your contact: István Gyürki Senior SW Engineer Direct: +41 55 253 2068 Mobile: +41 76 720 4653 istvan.gyuerki@neratec.com