IPv6 Challenges for Embedded Systems István Gyürki

Transcription

1 IPv6 Challenges for Embedded Systems István Gyürki

2 AGENDA Introduction IPv6 why do we need it? Selecting the right TCP/IP stack Case study Conclusions Page 2

3 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

4 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

5 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, kb ROM, kb RAM Page 5

6 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

7 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 k$ Additional features 2-5 k$ each Page 7

8 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

9 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

10 Reference lwip IPv4 configuration Footprint: Code: 26 kb RW Data: 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

11 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

12 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

13 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

14 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

15 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 Flash: +to reference 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.) kb 8 kb > +10kB > +10kB Task stacks (+ to ref.) kb kb?? Page 15

16 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 Socket TCP proto control block Message Page 16

17 Results: performance TCP write performance Test PC sending data continuously to target over TCP socket write 4k write 1k Stack I IPv6 byte/s cpu load 95% 95% Stack U IPv4 byte/s cpu load 15% 15% REFERENCE IPv4 b/s cpu load 92% 92% Conclusion: No real difference between IPv4/IPv6 performance No difference in application performance Proper configuration is mandatory Page 17

18 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

19 Your contact: István Gyürki Senior SW Engineer Direct: Mobile: