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>
|