2.3.1 IPv6 over Low power WPAN (6lowpan)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-28


Geoffrey Mulligan <geoff.mulligan@invensysclimate.com>
Gabriel Montenegro <gab@sun.com>
Nandakishore Kushalnagar <nandakishore.kushalnagar@intel.com>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Thomas Narten <narten@us.ibm.com>

Mailing Lists:

General Discussion:
To Subscribe:

Description of Working Group:

Sensor Networks are networks of severely constrained devices.
These networks are fast becoming a reality.  Many
complex "closed standards" exist and more are being developed, but
none are being developed with an eye on Internet standards.

When building and deploying low cost low power and extremely
inexpensive network nodes such as those in sensor and telemetry
networks currently best exemplified by the IEEE 802.15.4 radio node,
it is import to recognize the major differences in these networks from
IP networks of the past:

  * Potentially 2 orders of magnitude more nodes
  * Severly limited code and ram space (e.g., highly
desirable to fit a stack in, say, 16K, using 8 bit processors)
  * Unobtrusive but very different user interface for configuration
(e.g., using gestures or interactions involving
the physical world)
  * Robustness and simplicity in routing or network fabric
  * Extremely aggressive power constraints (i.e., many of these
devices should run for months or years on batteries)

Currently no open standards exist to define:

  * IP adaption/Packet Formats and interoperability
  * Dynamically adaptive topologies
  * Addressing schemes/management
  * Network management
  * Routing
  * Security set-up/maintenance

2. Proposed Charter -

      To define a minimal IPv6-based stack on IEEE 802.15.4 radios
      providing for a simple but sufficient mesh network, simple but
      extensible security model (read key management), and the basic
      packet/header formats, stack environment and L2/L3
      interface/control mechanisms. The working group will reuse
      (perhaps adapting) existing specifications whenever reasonable
      and possible.

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

    Meeting Minutes 6LoWPAN - 61  IETF 
    (In line with agenda) 
     Edited by:
     - Nandakishore Kushalnagar (nandakishore.kushalnagar@intel.com)
     Minutes by:
     - Samita Chakrabarti (samita.chakrabarti@eng.sun.com)
     - Carsten Bormann (cabo@tzi.org)

        * Preliminaries                          5 min 
        * Motivating Scenarios 
              o George.Karayannis@helicomm.com                 10 min 
                   George gave a brief overview of Helicomm.  
                   His company interests were in embedded systems, IEEE 
                   15.4, zigbee, IPv6.  
                   Helicomm leading embedded wireless networking 
                   platform, embedded modules, network gw, networking 
                   software and tools.  
                   Application areas -  
                   Home Control (well over 100k homes at end 2005) 
                   Meter Reading/Utilities – AMR - current use of GPRS 
                   Defense/Security (IP based video cameras – Sony)- 
                   low rate video.  
                   Rapid growth in network devices Japan, Korea, 
                   China(5-6M homes/year, .25M of these are high-end).  
                   Business in Asia, Cost effective, reliable.  
                   Expressed need for IP connectivity without IP 
                   His view is Zigbee and IPv6 were complementary -  
                   - Zigbee: interoperable & large/complex hybrid 
                   networks and  
                   - IPv6 can allow talk to back office etc.  
                   Showed stack of ipv6 and zigbee.  
                   Plans to use ipv6, aodv over zigbee. 
              o Geoff.Mulligan@invensysclimate.com               10 min 
                   Showed nearly 40 points of Invensys presence in a 
                   typical US home.  
                   Views .15.4 as strategic.  
                   Envisions lots of sensors (100s), many controls 
                   (10s) < $3.  
                   Internet connectivity is needed.  
                   60 % of the cost is pulling wires!  
                   Saves up to 5000 $ a day of "elevator time" for one 
                   Emphasized vision is not about "smart home" -- 
                   pejorative term, but more about convenient home!  
                   Efficiencies of proprietary systems will be overcome 
                   by technology advances within one development cycle.  
                   Why 15.4? 
                   - Inexpensive modules 
                   - Internet Connectivity 
                   - Open standards 
                   - 15.4 was "30 m" radio, devices now do "100 m".  
                   Zigbee – not ready for prime time, 64K (40 c 
                   difference between 64K parts and 32K parts impacts a 
                   lot when costs of devices are small).  
                   Other problems – complex, expensive, and untested, 
                   and not IP compatible.  
                   Barriers to deployment: 
                   -- new radio 
                   -- new mac (CSMA/CS plus GTS/Beaconing) guaranteed 
                   time slots 
                   -- new network, AODV plus Cluster Tree 
                   -- new API -- Zigbee API + ZDOs (Zigbee Device 
                   -- new applications 
                   better: CSMA/CA only MAC (MAC lite) 
                           AODV and IP 
                           Sockets and SNMP 
                   To v6 or not to v6 
                   - 10M - 50M devices per year 
                   - Devices have IEEE 64 IEEE addresses 
                   - Replace AODV in L2 layer with AODV over IPv6 
                   - Replace zigbee API with sockets and SNMP-lite 
                   - don't want DHCP servers etc. 
              o Brijesh Kumar <kumarb@research.panasonic.com>    10 min 
                   Use case scenario 
                   In this Brijesh presented smart home environment 
                   where there are three kinds of networks - home 
                   computing or home-office network, entertainment 
                   network and then utility control network which might 
                   be controlled by sensors. 
                   Both Star, p2p topology were presented as part of 
                   Zigbee topology 
                   - 802.15.3 "streaming" entertainment 
                   - 802.11 computing 
                   - 802.15.4 appliance/sensor control network 
                   Kinds of traffic: 
                   - periodic (auto-monitoring) 
                   - application defined rate (e.g., sensors) 
                   - intermittent data 
                   - application/external rate (light switch) 
                   Problem with L2 Addresses: 0-2 dst pan ID, 2-8 
                   address, sometimes not sent. He suggested that IPv4 
                   should be perhaps considered. Sees more issues with 
                   IPv6 than with IPv4 (and more complex impl) 
                   not a fixed network, 128 byte packet limitation 
                   going from 64 to 128 bit addresses is a 
                   Key Issues in running IPv6 over zigbee devices: 
                   - IP address mapping to MAC frames ARP/ND 
                   address assignment 
                   - DAD 
                   - MTU 
                   - DNS name resolution 
                   - Ip/Qos 
                   - HC 
                   - MC, BC 
                   - Energy efficient operation in ad-hoc routing 
        * Overview of IEEE 802.15.4 
              o JoseGutierrez@eaton.com                          10 min 
                   - CCB chair Zigbee 
                   Sees a problem with Lo naming as Lo could mean low 
                   cost as such named "LR-WPAN" in IEEE -- low-rate 
                   .4a: enhance physical layer with location 
                   information; new group, not the original team; 
                   secret: don't like it, because it's not really low 
                   cost, so they should have done it in .15.3 plan by 
                   November 2006 
                   .4b: "resolve ambiguities" = amend mistakes 
                   (standard got published despite mistakes) plan by 
                   Januar 2006 
                   Monique (new editor) got married 
                   Initially .15.4 was not designed to run on IP 
                   The .b standard opens a window for 6lowpan -- could 
                   add some requirements. 
                   802.15.4b could be applicable for running IPv6 on 
        * Introduction and Problem Statement                     15 min 
              o Nandu (nandakishore.kushalnagar@intel.com)
                  o Document: draft-6lowpan-goals-assumptions.txt 
                   - IPv6 only versus IPv4 also. 
                   - Coordination with others (IEEE, ZigBee, others?) 
                   Intel has been looking into sensor networks- it 
                   originally was looking into zigbee. But they now 
                   backed out because of lawyers' concern. 
                   What is LowPAN? 
                   - low cost, low power 
                   - Topology - star, mesh and combinations 
                   - it needs slightly different thinking than 
                   traditional thinking because of special requirements 
                   Challenges of LOwPAN: 
                   Presented Imapct analysis on addr, routing, sec, 
                   net. mgmt 
                   - low power 
                   - low cost 
                   - low bw 
                   - high density 
                   - IP network interaction 
                   Subtleties of IEEE802.15.4: 
                   - Small packet size MAC from 127 byte 
                                     MAC payload 102 bytes 
                                  With security 81 bytes 
                   Goals of lowPAN: 
                   - Look list inside the presentation 
                   - Header compression (header reconstruction e.g. 
                   from MAC header, header  
                   Why IP? 
                   - Most of IP based technology already exists 
                   - pervasive nature of IP 
                   - high density -> lots of addresses needed 
                   - statelessness 
                   - location aware addressing 
                   Brijesh - remove requirements for 15.3 or UWB for 
                   IETF purpose 
                   Robert M- stateless security is extremely expensive 
                   in IPv6. 
                   Chairs- we are talking about stateless autonf - not 
                             necessarily with security. 
        * IPv6 over IEEE 802.15.4                                15 min 
              o gab@sun.com 
              o Document: None yet. 
                   Why this document -  
                   - Ipv6 over Foo 
                   - Other examples of IETF drafts: IPv6 over Ethernet, 
                   PPP, ATM, IEEE1394 
                   Mar 2005 to IESG as PS (maybe some stuff 
                   experimental) CSMA/CA, not GTS (Guaranteed time 
                   Frame format not obvious; SNAP too expensive, may 
                   want to coordinate with IEEE. 
                   Frame format 
                   How to carry Ipv6 packets within 15.4 packets 
                   - Address generation, 3513 addressing arch works 
                   (but also: 16-bit address) 
                   - EUI-64 addr for IEEE 802.15.4 
                   - autoconf and linklocal addr 
                   Adaptation layer needed 
                   - Needed as min IPv6 MTU is 1280 
                   - What else should be done in the shim: Mesh, Header 
                   - Max Data payload of .15.4 is 102 
                   - Need a adaptation layer as shim ( MTU 
                   Should shim contain the following as well ?: 
                   - Layer 2 (sub-IP) mesh using, say AODV lite 
                   - Layer 3 mesh also possible(inter-PAN) 
                   - Header compression 
                   - Integration of L2/L3 headers into one single 
                   compressed header 
                   - Context build up via configuration phase 
                   - Header compression in a mesh scenario 
                     (may be context needs to be shared in the PAN) 
                   Koki(?) - How do we handle MTU ? A: shim/adaptation 
                   Chairs: we'll have to specify something, but many 
                   apps won't need this as they send really small data 
                   packets and sleep 99.9% of the time anyway. 
                   Brijesh - The 15.3 docs are about to be solidified- 
                   so the shim solution will not go in there. 
                   Chairs: There is no deliverable now. We called this 
                   "LoWPAN" because it's easier to say. 
                   Q: Schedule Mar 2005?  Impossible. 
                   A: Wanted to have an aggressive deadline.  
                   Q: Are nodes mobile or stable? 
                   A: we have a mobility problem, but not FMIP/HMIP-
                   stuff mobility, no need for a continuous stream 
                   following you; more like DNA but not mobileip, 15.4 
                   has some stuff here. 
        * An IPv6 Profile for IEEE 802.15.4                      15 min 
              o Geoff.Mulligan@invensysclimate.com 
              o Document: None yet. 
                   15.4 MAC lite (Q: "minimac?") 
                      where implemented, must be compliant 
                         no beaconing 
                         short addressing 
                      (full MAC is 16-20k for the MAC; > 50 % 
                   unnecessary)   do we need 16 bit addresses? 
                   "AODV tiny" 
                      not on top of IP here 
                      why not DSR? AODV code was available; somewhat 
                   compatible with Zigbee 
                      Joe Macker: MANET WG item for a baseline spec 
                      "stateless" header compression 
                      rather than ROHC, maintaining differentials. 
                      Has a solution for v6 headers down to 4 bytes. 
                      Have a requirement for flooding, not necessarily       
                   user data 
                      Bernard: partitioning and healing?  
                         A: yes, self-healing 
                      telemetry data 
                      reliable UDP? 
                   "SNMP static" really SNMP lite, no ASN.1 
                      static OIDs 
                      "compatible packet format" 
                      manage radio, talk to sensor, turn something on 
                   and off  
                      fine interface 
                      serial interface: off-device communication 
                      compress in/uncompress out (raw ipv6 packets) 
                      not talking about PPP 
                   Reliable data transfer? 
                         Thomas- Try to stick to TCP 
                   IPv6/UDP - IPv6 - stateless autoconf/lots of 
                   UDP - telemetry data/no streams 
                   Putting it all together: 
                   MAC/AODV 8K 
                   + IPv6/UDP/Serial 12K ("unoptimized") 
                   complete stack < 20K for FFD 
                   for RFD under 16K 
                   we do have running code doing this today... 
                   Bob: You did not list key management 
                   (15.4 has shared key...) 
                   What are your expectations? 
                   Geoff: Security is critical 
                   all we need is layer 2 security 
                   "nuisance security" against smoke detector 
                   door locks and gas valves may need more security 
                   Setup -- send key unencrypted 
                   be secure after that... 
                   Question from co-chair Manet  
                   - requirement of flooding/multicast? 
                   - We need to be in sync in requirements of routing 
                   in this group 
                   Q: Will the network be partitioned ?  
                   A: - Yes. 
        * Draft of a Charter                                     10 min 
              o Chairs 
                   Problem statement Jan (I) 
                   Encaps Mar (PS) 
                   Profile Jun (BCP or informational?) 
                   other: UWB, lightweight discovery, secure 
                   bootstrapping -> recharter 
        * Open Discussion                                        20 min 
              o Chairs 
    Alain Durand: are they going to talk to the Internet? v6 or v4? 
    Gabriel: 90 % will stay in the PAN, 10 % will reach beyond. 
    and the other device will be v6 
    Keith Moore: most of the devices will be "send only" 
    Nandu: wireless sensor networks (actuation and transducers), Some 
    of these are push or pull - 
    Keith Moore: < 32K and addressable from anywhere? 
    Gabriel: minimal devices may not be able to talk across the 
    Keith: do authentication to avoid running down batteries  
    protected network behind a gateway 
    Tom Narten: Problem and Encaps is fine, profile: Hmm. 
    Profile is often not about interoperability, but about marketing 
    Tom: e.g., API 
    -- don't talk about future charter 
    -- list WGs you want to talk to 
    Thomas Narten, AD and Robert M. asked 
    What kind of security was critical in the charter. 
    Answer from the chairs: 
    L2 security is OK. Need to avoid 
    nuisance level security 
    (need to work on security groups to apply more security 
     for door knobs or gas valve) 
    Discuss security and take it to 14.b as well 
    Question at the microphone: 
    Will the devices talk to the Internet or not? 
    If the sensor talks to a device other side of 
    internet - should it talk IPv6 to the other device? yes. 
    How do you talk to the other devices in Internet with 32K devices. 
    Ans - 16K-32K may not talk to outside the local network. 
    Comment - It is unreasonable assumption that the devices will not 
              talk to the device in the internet. It has to be 
              designed. The devices that talk to the outside world has 
              to be globally reachable and should run security above L2 
    T. Narten - IETF does not do profile usually, it might produce 
                or marketing type doc. 
    Jose G. - UWB is not low cost - does not match with v6lowPAN naming 
    Ans -     UWB is just an example 
    George -  Concern that no voice in the network. Issue of 
    Gab -    Voice on the network does not mean voIP. 
    Brijesh K - Use profile as best current practices not as profile... 
    Chairs -- It is either BCP or informational 
    T. Narten - It is dangerous to profile and make it an 
                informational - people put different things and become 
    ROHC chair- 
               suggestion - use what to do and not to do. ( not re-
               list other groups in IETF (ROHC, MANET) which will be 
    Thomas Narten polled for BOF attendees' opinion. 
    People thought it was interesting work to pursue and many raised 
    hands to 
    contribute in the working group.  



IPv6 Over IEEE 802.15.4 IETF ‘6lowpan’ BOF Session 10 November 2004
The View from Mt Invensys
Issues and Requirements of IP over Low Power WPAN
LR-WPAN Standards Work IEEE 802.15 Task Groups 4a and 4b
6LoWPAN (Introduction, Problem Statement & Goals)
Transmission of IPv6 Packets over IEEE 802.15.4
6LoWPan Profile