[6lowpan] 6lowpan interim meeting minutes REQUEST

[Geoff Mulligan <[e-mail]>]

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:[e-mail]]
> > *Sent:* 7. marts 2006 13:57
> > *To:* Schumacher Christian Peter Pii
> > *Cc:* [e-mail]
> > *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: [phone], Cel: [phone], Fax: [phone]
> >
> > http://ilab.ajou.ac.kr/kkim86/index.htm
> >
> > ------------------------------------------------------------------------
> >
> > *From:* Schumacher Christian Peter Pii [mailto:[e-mail]]
> > *Sent:* Tuesday, March 07, 2006 8:09 PM
> > *To:* [e-mail]
> > *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
> >[e-mail]
> >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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/6lowpan


_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan