Hi Folks,
I have attached my unofficial meeting minutes, while we wait on the
official one.
I know Carsten had good notes on the charter items. I had the charter
listed as line
items and intended volunteers.
Regards,
-Samita
Schumacher Christian Peter Pii wrote:
Hi Kim
Unfortunately there doesn't seem to be any official minutes from the
interim meeting in January, and I assumed we only wanted to focus on a
few of these points. However, if you could provide some key-words for
these other items you mentioned, I would be happy to incorporate them
into the text.
Regards
Christian
------------------------------------------------------------------------
*From:* Ki-Hyung Kim [mailto:[EMAIL PROTECTED]
*Sent:* 7. marts 2006 13:57
*To:* Schumacher Christian Peter Pii
*Cc:* [email protected]
*Subject:* RE: [6lowpan] new 6lowpan charter
Hi, Schumacher,
As I remember, there were some additional rechartering items which we
had reached on consensus in the last interim meeting, such as mesh
routing protocols, service discovery, scalability (routing and
addressing) and management.
Is there anything I dont know during the time or any reason why we
cant move forward on these issues?
--
Ki-Hyung Kim
Associate Professor
Division of Information and Computer Engineering,
Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551, Fax: +82-31-219-2433
http://ilab.ajou.ac.kr/kkim86/index.htm
------------------------------------------------------------------------
*From:* Schumacher Christian Peter Pii [mailto:[EMAIL PROTECTED]
*Sent:* Tuesday, March 07, 2006 8:09 PM
*To:* [email protected]
*Subject:* [6lowpan] new 6lowpan charter
Hi.
During the 6lowpan interim meeting in January, the working group
discussed possible topics for a future rechartering of 6lowpan. Based
on available information from that meeting I've compiled the following
text, which is an edited version of the scope present in the current
6lowpan charter. Feedback is appreciated.
--- start of scope ---
Scope of 6lowpan:
Produce "Optimization of the Neighbor Discovery Protocol for 6lowpans"
to define how to apply the existing Neighbor Discovery protocol in a
6lowpan.
Produce "IPv6 over Low Power WPAN Security Analysis" to define the
assumptions for a security model for 6lowpan. This includes analysis
of threats, identify types of devices and define the levels of trust
between these devices.
Produce "6lowpan Co-existence with other Networks" to define how to
co-exist with other networks. This includes analysis of how to survive
interference caused by IEEE 802.11 based networks, and investigate how to
recognize and co-exist with other networks based on IEEE 802.15.4.
As such, the working group may also work on an informational document
to show how to apply an existing MANET protocol to LoWPANs (e.g.,
AODV, OLSR, DYMO, etc).
The working group will reuse existing specifications whenever
reasonable and possible.
The working group will also serve as a venue for ongoing discussions
on other topics related to the more complete list outlined above.
Additional related milestones may be added in the future via a
rechartering operation.
Note: As may be obvious from its official name above, this particular
working group will not work on IPv4 over IEEE 802.15.4 specifications.
Given the limitations of the target devices, dual-stack deployments
are not practical. Because of its higher potential for header
compression, its support for the huge number of devices expected and
of cleanly built-in features such as address autoconfiguration, IPv6
is the exclusive focus of the working group.
--- end of scope ---
Looking forward to receive your feedback.
Regards
Christian
PS: The original charter can be found at
http://www.ietf.org/html.charters/6lowpan-charter.html
------------------------------------------------------------------------
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
IETF meeting 1/27/06 6lowpan
-----
Summary:
6lowpan IETF interim meeting took place on 27th January at Menlopark, CA.
Main objective was to close remaining issues for the problem statement draft
and format draft. Several presentations were made at the meeting; the details
are discussed below. At the end the working group discussed future possible
work for re-chartering.
The following are grouped according to the presentations. Some comments are
also captured in the minutes, but not all of them.
6lowpan problem statement and goals - Nandu Kushalnagar
Security Consideration -
Need to fix the current text for security.
Comment on the list by Samita - concern about the IPSec tunnel mode within the
802.15.4 network for the limitation of 802.15.4 dataframe size.
Gabriel - Should fix the text by saying that IPSec gateway
can sit and tunnel in the internet side, but if we need to provide IPSEC
gatway in the 802.15.4 network, use different model like SSL.
Other comments: Could 802.15.4 link-layer security be used for in-PAN
communication.
Mark Townsley- Outline the two different models of security for gateway.
When to use tunnel mode and when to avoid with respect to
the type of network (6lowpan or non-6lowpan network).
Vipul - Can we mention protocols in the goals doc? dtls ?
Mark - Not in this document. IPSec is mentioned becuase of IPv6 IPSec
requirement for IPv6.
Consensus - no mention of SSL or specific mention of other security protocols
except IPSec because of its special requirement for IPv6.
This draft should go for Last call - use 4wks or so for review.
Chairs are going to estimate the last call date.
6lowPan interoperability with external networks - Prof. Kim
This proposal provides a Gateway architecture and addressing for connecting a
6lowpan network to the outside world(Internet).
Gateway architecture
=> A Router which reduces NS traffic as mentioned in ND-lowpan
draft
=> RA for default router setting in every devices
=> def gw routes packet to the externaletwork
=> Does it need an extra bit in adapatation layer for
identifying traffic
for external network?
Erik, Geoff : Don't see a need for an extra bit. L2 and L3 routing
should
take care of that.
Geoff/Alex : May be there needs to be more than one default
gateway
Erik : Then it would break redirect mechanisms - need to ignore
redirects
Prof Kim proposed a way of mapping IPv6 address to 16bit MAC
addrr (unique
per lowpan) then it sets a bit, default gw at the junction
translate 16bit MACaddr
to IPv6 addr and transfer. ( mapping table at the gw).
Carsten - ND optimization, adapatation layer function; where
should we
add more function to make IPv6 work efficiently on
802.15.4?
Erik/Gabe: Functional draft first and then optimization
Alex Sy - 64bit address, IPv6 addresses, short addresses, ND does
not
provide means for choosing addresses, what should be
done ?
Erik - We could approach in pieces ( conventional and
optimized) for
understanding the problems and make progress. Broadcast
might be
useful for some bootstrapping. The architecture should
consider
or distinguish two models - basic one with broadcast
and multicast
and the optimized model with reduced
broadcast/multicast.
GW architecture:
- Interop issues
- RA issues
Comments for format document: Michel Veillete
Problems:
Adaptation layer : insufficient guarantee of delivery and error
handling.
Transmission error on a single segment makes the protocol fail
- out of order pkt processing required
Header compression
- reduces overhead but increases complexity
Stream support - TCP model?
Where does IPv6 feature support stop? ICMPv6 support?
IPv6node ---Tiny IPv6 Proxy --- tiny IPv6 node
What can make IPv6 tiny?
Comments - Tiny IPv6 world is a very limited view of the world, we
want to approach this as an open solution which can be applied in
arrays
of devices for different purposes/usages.
6lowpan Header compression - requires states in the PAN - no
additional states
Today we talked about GW doing the header compression
In this solution, we need to build states in mesh.
Sequenced delivery - NAK?
Use TCP endpoint negotiation (Erik), set MSS for smaller value
for 802.15.4.
Gabe: Applications may be built differently
Rahul/Geoff: TCP has its own problem in lossy network
Erik: There is a solution - but complex; SACK.
Alex: Fragmentation puts a burden in CSMA network -
fragemntations
are not quite efficient in 802.15.4 network
Samita: Should we consider stating what kind of applications
we are
targeting in the goals doc?
Several folks commented(Geoff, Erik, Nandu, Gabe?)
Geoff: Perhaps we should have a separate BCP doc after these
two docs
are done.
Others: TCP can be speciifed, audio/video possible?
Conclusion: out of order delivery -- NAK, ACK packets mechanism needed.
6lowpan HC is simple - we know that it is different than ROHC.
The format document needs clarification on that;perhaps we
could
name it differently. Mention TCP in the format document(?).
- separate draft(informational) for IPv6 on sensors. This
draft
may address buffering requirement,
ICMPv6 error messages which carries big messages or
errors for other
unsupported upper layer protocols that these nodes don't
understand.
- Current charter does not support proxy approches. It might
be
useful to include proxy in the charter later.
After Michel's presentation we had lunch break. During lunch break, Roger Meike
from
Sun Microsystems Laboratories welcomed the working group members and gave a
short
talk on SunLabs Research prototype on sensor platforms that run JAVA on the
metal.
He also showed a demo on 802.15.4 controlled robo-wheeler. Michel Veillete and
Alex Sy
showed their company's products on radio and sensor devices. After lunch the
meeting
resumed with discussions around the neighbor discovery draft for 6lowpan.
IPv6 Neighbor Discovery related discussions by Erik Nordmark
It discussed different topology. Only star topology is described in IEEE
802.15.4.
802.15.4 does not define Mesh topology, but peer-to-peer topology.
The presentation discussed possible mesh topology that wg can agree upon.
How about full mesh and hybrid topologies? Who should assign IPv6 address in
different topological scenarios?
Simple optimizations (star tolpology, one co-ordinator)
Alex Sy pointed out that Pan co-ordinators are special co-ordinators - Pan
co-ordinators
are at the high-level address assigner(assigning PANID).
Co-ordinators assign addresses only - PAN ID bit tells who
is the true PAN co-ordinator.
The draft suggested optimizations for avoiding unnecessary packets in the
network
Avoid Multicast NS(in the draft)
Should it reduce Neighbor unreachability detection?
Carsten - need to have something like ICMP eror or RouteError
saying that dest addr(default router?) does not exist
Gabe - Can NUD be used to map error back since link layer does not
provide error back other than ACK- is there a need to have
a router error mechanism to transmit to the rfds and co-ordinators
that do not do routing
If we assume that L2 address of a node does not change for an IPv6
address
then we can avoid avoid NUD from host-to-host as well as router-to-host.
Other open issues:
Should the ND draft support both long and short addresses ? -Yes already
in farmat draft.
- Can we discover mechanism to discover L2 mechansim to discover
and update the mapping bet L2 short and long addr?
- Did not catch the timing issue that Gabe mentioned about NUD (anyone?)
ND to deal with both short and 64bit addr for linklayer?
The 16bit short address is not unique and it might change
frequently while the 64bit address is relatively stable.
Suggestion to Prof. Kim on GW interop by the chairs --
Take out ND part and work with ND draft authors
Write separate draft for header compression
ZigBee format compatibility -
Geoff :
ZigBee 1 PAN per channel
Beacon pattern for lowpan =6
Gabe suggests beacon for lowpan might be a separate draft
[Geoff - to fill in more data here.]
Format draft - Gabriel Montenegro
Draft changes as presneted in Vancuver
- PAN specific broadcast
16bit zeros + PAN ID -> address forming
unicast - both type of addr
Relax the MUST on both src and dst link-layer (current doc is fine)
version - leave it out
reassembly - 15sec time out
offset for reassembly now is multiple of 8
What is reassembly keyed on?
current : source, tag
Discussion: dest, size?
Mesh delivery header and constant overhead
802.15.4 allows mix of 16bit /64bit addr in mesh,
Should format allow mix of short and long src/dst addr?
Question:
What it meant by supporting broadcast to the mesh layer, ie.
adding 0xffff in the mesh layer header dest field (controlled
bcast)?
Is it same as PAN specific broadcast?
We need to support both short/long src/dst MACaddr in order to
support broadcast from a unicast 64bit addr
Discussion : We need to specify in the doc about *radio* layer, *mesh*
layer
broadcasts. Mesh should not preclude possiblity of
supporting
multicast in Mesh layer (EUI supports group addr capability)
mesh delivery layer - should we add support for both 16/64bit addr?
for broadcst ( 2 type bits, 6 hops left=64 hops)
- Answer: Yes
mesh multicast support -
Yes, it depends on whether the routing supports
it
Address management:
Pan co-ordinator is the ultimate authority
More info on PANID and on its role
Charter Discussion:(Carsten has good notes)
- ND Optimization is useful item for future to work on
- HC compression discussion in a separate document? (to be in wg?)
- End-to-end reliable data delivery (NAK, small MSS, small windows,
- Mesh layer routing
- Service Discovery (application)
Kim, Samita
- Naming service for Mesh Layer?
- assignment of addresses of different sizes
- name lookup issues
- Easy application configuration/provisioning
- Link-layer Address assignment
- Scalability
-Routing
- Addressing
-
- Security
- Key management
- Co-existence with other network
(surviving with 802.11: channel interference problem solution.
channel hopping and selecting a good channel dynamically when
there is an intereference)
Security Model
No Brainers
-- ND and optimizations thereof
-- Recommendations for TCP usage in 6lowpan
-- Recommendation for App?
-- Mesh Routing?
802.15.5 - routing for UWB?
Not-so-no brainers
-- Beacons (vs 802.21 and DNA)
Security
Key management for 15.4 security?
Recommended practices in this space
Who: Vipul, Daniel, Carsten
Mobility issues?
- Samita to submit new version of mobility draft.
- Another lowpan mobility draft is also available in the draft directory
WSN security - Gabriel Montenegro
Gabriel described his thoughts of Wireless sensor security mechanism
in mesh network - the idea was inspired by "resurrecting duckling" paper.
Sun Microsystems has IPR on this method.
Prof. Kim's presentation on Protocol scalability, Adhoc routing protocols and
Service discovery based on his internet drafts and research findings. His
adhoc routing protocol results are quite interesting. The details are on the
slides.
The meeting was adjourned at 7pm and many attendees including the chairs went
to have
dinner together.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
