Last Modified: 2004-10-28
<xmp> 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 gateway. 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 building. 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 Objects) -- 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 consideration 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 environment * 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 WPAN .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 networks. The .b standard opens a window for 6lowpan -- could add some requirements. 802.15.4b could be applicable for running IPv6 on it. * 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 short-circuiting...) Why IP? - Most of IP based technology already exists - pervasive nature of IP IPv6 - high density -> lots of addresses needed - statelessness - location aware addressing Comments: 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 service) 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 Compression? - Max Data payload of .15.4 is 102 - Need a adaptation layer as shim ( MTU consideration) 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 layer 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 IPv6 "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 UDP 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 socket/ioctl/serial fine interface serial interface: off-device communication compress in/uncompress out (raw ipv6 packets) not talking about PPP Reliable data transfer? TCP,??? Thomas- Try to stick to TCP IPv6/UDP - IPv6 - stateless autoconf/lots of addresses 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 attacks... 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 Internet 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 cabo: -- 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) Suggestion: 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. Question: 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 carefully designed. The devices that talk to the outside world has to be globally reachable and should run security above L2 level. T. Narten - IETF does not do profile usually, it might produce complex 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 portability 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 un-interoperabale ROHC chair- suggestion - use what to do and not to do. ( not re- charteting) list other groups in IETF (ROHC, MANET) which will be working together. ------------------------ 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. ------------------------ </xmp> |