Outlook on IEEE ZigBee Implications IP Requirements IPv6 over Low Power WPAN (IEEE ) Conclusions. KRnet /21

Transcription

1 IPv6 over WPAN Soohong Daniel Park Mobile Convergence Laboratory, Digital Media R&D Center, SAMSUNG Electronics.

2 Contents Outlook on IEEE ZigBee Implications IP Requirements IPv6 over Low Power WPAN (IEEE ) Conclusions KRnet /21

3 IEEE MAC Overview Star and peer-to-peer topologies Employs 64-bit IEEE & 16-bit short addresses Ultimate network size can reach 2 64 nodes (more than we ll probably need Using local addressing, simple networks of more than 65,000 (2^16) nodes can be conf igured, with reduced address overhead Three devices specified Network Coordinator Full Function Device (FFD) Reduced Function Device (RFD) Simple frame structure Reliable delivery of data Association/disassociation AES-128 security CSMA-CA channel access Optional superframe structure with beacons GTS mechanism KRnet /21

4 IEEE Device Types Three device types Network Coordinator Maintains overall network knowledge; most sophisticated of the three types; most memory and computing power Full Function Device Carries full functionality and all features specified by the standard Additional memory, computing power make it ideal for a network router function Could also be used in network edge devices (where the network touches the real world) Reduced Function Device Carriers limited (as specified by the standard) functionality to control cost and complexity General usage will be in network edge devices All of these devices can be no more complicated than the transceiver, a simple 8- bit MCU and a pair of AAA batteries! KRnet /21

5 ZigBee Internet KRnet /21

6 ZigBee + IPv6 Stack Profile Nature of the IPv6 Stack Profile The IPv6 stack profile is new and not an extension of any existing stack profile. It provides a seamless way to incorporate IP into ZigBee networks such that the IP services are distributed throughout the network rather than concentrated within a single gateway/device. Goals Provide seamless connectivity between ZigBee and Internet devices and services. Allow for use of existing Internet data types and structures Allow for reuse of existing network software Allow use of existing Internet tools and services KRnet /21

7 Why IP Most of the IP based technologies already exist, well known and proven to be working. The pervasive nature of IP networks allows use of existing infrastructure. Intellectual property conditions for IP networking technology is either more favourable or at least better understood than proprietary and newer solutions. KRnet /21

8 Why IP New Radio Barriers Risk Mitigation to deployment New CSMA/CA MAC only CSMS/CA MAC plus GTS/Beaconing AODV New Network and IP AODV plus Cluster Tree New Sockets API and Zigbee SNMPAPI plus ZDOs New Application Vs. GTS: Guaranteed Time Slot ZDO: ZigBee Device Object KRnet /21

9 Why IPv6 More suitable for higher density Statelessness mandated No NAT necessary Possibility of adding innovative techniques such as location aware addressing IEEE 64 bit address subsumed into IPv6 address KRnet /21

10 6LoWPAN WG (IPv6 over Low Power WPAN) 1 st IETF-61 Intel, Invensys, Sun Microsystems - Survey on IPv6 adoption over IEEE Technical solution (Sub-IP concept) Phase I 1 st IETF-62 draft-ietf-6lowpan-problems-00 draft-ietf-6lowpan-format-00 2 nd IETF-63 General discussion 3 rd IETF-64 Security considerations Phase II 4 th IETF-65 Ready to the RFC Rechartering: IPv6 Bootstrapping, ND Optimization, Stateful Header Compression, Transport/Application analysis, Mesh routing, Security analysis KRnet /21

11 Problems and Motivations of 6LoWPAN No method exists to make IP run over IEEE networks Worst case.15.4 PDU 81 octets, IPv6 MTU requirements 1280 octets Stacking IP and above layers as is may not fit within one frame IPv6 40 octets, TCP 20 octets, UDP 8 octets + other layers (security, routing, etc) leaving few bytes for data Not all adhoc routing protocols may be immediately suitable for LoWPAN DSR may not fit within a packet, AODV needs more memory, etc Current service discovery methods bulky for LoWPAN Primarily XML based that needs computing, more memory, etc Limited configuration and management necessary Security for multi hop needs to be considered KRnet /21

12 Challenges of LoWPAN Analysis Impact Addressing Routing Security Network management Low power (1-2 years lifetime on batteries) Storage limitations, low overhead Periodic sleep aware routing, low overhead Simplicity (CPU usage), low overhead Periodic sleep aware management, low overhead Low cost (<$10/unit) Stateless address generation Small or no routing tables Ease of Use, simple bootstrapping Space constraints Low bandwidth (<300kbps) Compressed addresses Low routing overhead Low packet overhead Low network overhead High density (<2-4? units/sq ft) Large address space IPv6 Scalable and routable to *a node* Robust Easy to use and scalable IP network interaction Address routable from IP world Seamless IP routing Work end to end from IP network Compatible with SNMP, etc KRnet /21

13 6LoWPAN Goals Protocol data units may be as small as 81 bytes, far below IP and above In all cases, reuse existing protocols before creating new ones Address mismatch between MTU sizes of LoWPAN s and IPv6 Support stateless auto configuration of IPv6 addressing (location aware?) Specify header compression (use of existing and/or new techniques eg. header reconstruction, header short circuiting, etc) Define security mechanisms, security configuration and bootstrapping Specify network management (SNMP?) Specify routing suitable for LoWPAN networks (MANET?, topology aware, Below L3 or above L3?, etc) Specify methods to enable and disable IPv6 over LoWPAN. Specify hooks within routing layer to enable in network processing Specify light weight discovery mechanisms Specify any changes needed for L3 + layers Specify implementation considerations and BKM s of an IPv6 stack done rechartering Next phase KRnet /21

14 IPv6 Packet Transmission Transmission of IPv6 Packets over IEEE WPAN Networks Defines basic packet formats and sub-ip adaptation layer for transmission over 6lowpan Includes framing, adaptation, header compression, address generation, and packet delivery in mesh topology ZigBee ZDOs Application Layer ZigBee ZDOs ZigBee Applications Transport Layer 6LoWPAN (Phase II) ZigBee Applications IPv6/UDP Transport IPv6 ZigBee Network Layer ZigBee Network Layer Adaptation Layer 6LoWPAN (Phase I) MAC MAC MAC PHY PHY PHY ZigBee Stack ZigBee+IPv6 Stack 6LoWPAN Stack KRnet /21

15 6LoWPAN Header Format Tenets Define a *shim* layer below IP Fragmentation/Reassembly to satisfy IPv6 MTU of 1280 bytes Routing including mesh Header compression mechanisms Header reconstruction for intra PAN communication Header short circuiting Header configuration to enable/disable IPv6 Define a IPv6 LoWPAN Profile Address IPv6 node requirements Define L2/L3 interface mechanism Appropriate security services Routing considerations Network management with SNMP Implementation considerations Miscellaneous (may be subsequent drafts) Hooks from L3 for in network processing (especially critical for WSN) Transport layer (UDP / TCP) Security configuration Light weight discovery mechanisms More? Adaptation Data Link IPv6 packet KRnet /21

16 Frame Format and Adaptation Layer LF prot_type M rsv Payload (or Mesh Delivery Hdr)... LoWPAN unfragmented encapsulation header format LF prot_type M datagram_size datagram_tag Payload (or Mesh Delivery Hdr)... LoWPAN first fragment encapsulation header format LF datagram_offset M datagram_size datagram_tag Payload (or Mesh Delivery Hdr)... LF proto_type M rsv datagram_tag datagram_size datagram_offset : Link Fragmentation : 1-IPv6 / 2-HC : Mesh : reserved : same value for IP frag : size of the entire IP : frag. offset LF Position Unfragmented (Figure 1) 01 First Fragment (Figure 2) 10 Last Fragment (Figure 3) 11 Interior Fragment (Figure 3) Link Fragment Bit Pattern LoWPAN subsequent fragment(s) encapsulation header format O F Hops Left Originator Address, followed by......final Destination Address O : Originator Address, either 64bit (1) or 16bit (0) F : Final Destination Address, either 64bit (1) or 16bit (0) Mesh Delivery Field KRnet /21

17 6LoWPAN Header Compression Most common IPv6 header: IP version = IPv6 IPv6 source and destination both are link local Length inferred from IEEE header Traffic Class and Flow Label both are 0 Next Header = UDP, ICMP or TCP Only need to carry Hop Limit (8bits) This common case is highly compressible (HC1) 2 octets (HC1 and Hop Limit) instead of UDP header compression Source Port Destination Port Length Header s checksum (not compressed, carried in full) 4 octets instead of 8 Note: TCP, ICMP HC2 formats TBD HC1 Hop Limit HC2 KRnet /21

18 Encoding of IPv6 Header Fields for HC IPv6 source address (bits 0 and 1): 00: PI, II 01: PI, IC 10: PC, II 11: PC, IC IPv6 destination address (bits 2 and 3): 00: PI, II 01: PI, IC 10: PC, II 11: PC, IC Traffic Class and Flow Label (bit 4): 0: not compressed, full 8 bits for TC and 20 bits for FL are sent 1: Traffic Class and Flow Label are zero Next Header (bits 5 and 6): 00: not compressed, full 8 bits are sent 01: UDP 10: ICMP (further study) 11: TCP (further study) HC2 encoding(bit 7): 0: No more header compression bits 1: HC1 encoding immediately followed by more header compression bits per HC2 encoding format Version Traffic Class Flow Label Payload Length Next Header Hop Limit Source Address Destination Address TCP, UDP, ICMP... PI: Prefix carried in-line PC: Prefix compressed (link-local prefix assumed) II: Interface identifier carried in-line IC: Interface identifier elided (to be derived from the corresponding link-layer address. If applied to the destination interface identifier when routing in a mesh, the corresponding link-layer address is that found in the Final Destination field. KRnet /21

19 Encoding of IPv6 Header Fields for HC Source Destination Port Port Length Checksum data octets HC1 Hop Limit HC2 (sr)short_port+(dt)short_port+checksum The "HC2 encoding" for UDP is shown below (starting with bit 0 and ending at bit 7): UDP source port (bit 0): 0: Not compressed, carried "in-line" 1: Compressed to 4 bits. The actual 16-bit source port is obtained by calculating: P + short_port value. (P is a predetermined port number with value TBD. The short_port is expressed as a 4-bit value which is carried in-line ) UDP destination port (bit 1): 0: Not compressed, carried "in-line" 1: Compressed to 4 bits. The actual 16-bit destination port is obtained by calculating: P + short_port value. Length (bit 2): 0: not compressed, carried "in-line" 1: compressed, length computed from IPv6 header length information (similar to how the length of the header is calculated in TCP Reserved (bit 3 through 7) KRnet /21

20 Encoding of IPv6 Header Fields for HC Non-compressed IPv6 Fields Hop Limit (8-bit): always follow the encoding fields (HC1) Source address prefix (64-bit) and/or Interface identifier (64-bit) Destination address prefix (64-bit) and/or Interface identifier (64-bit) Traffic Class (8-bit) Flow Label (20-bit) Next Header (8-bit) TCP, UDP, ICMP... Non-compressed and partially compressed UDP fields Source port (partially compressed: P + short_port (4-bit)) Destination port (partially compressed: P + short_port(4-bit)) Length (compressed) Checksum (16-bit) KRnet /21

21 Conclusion IPv6 adaptation is newly defined by 6LoWPAN WG Simple IPv6 connectivity amongst IEEE nodes Mesh routing amongst FFDs IPv6 input toward ZigBee To capture the market requirements for IPv6 support within the ZigBee Standard 6LoWPAN s phase II IPv6 ND Optimization and bootstrapping Transport/Application analysis (TCP/UDP/SNMP ) Security analysis Mesh routing (AODV, DYMO, etc ) Stateful Header Compression (ROHC, etc ) Coexistence with Home Devices & interference analysis Home Gateway & Sensor nodes (IPv6 LoWPAN) IPv6 KRnet /21