If anyone else has any notes taken during the meeting, Carsten, could
you please forward them to me soon and I will create some office meeting
minutes.
If I don't get anything in the next couple of days, I'll use Samita's
and some of my own.
Thanks,
geoff
On Wed, 2006-03-08 at 00:59 -0800, Samita Chakrabarti wrote:
> 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
> >
> >
>
> plain text document attachment (min.txt)
> 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
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
