Subject: RE: [6lowpan] new 6lowpan charter

From: "Schumacher Christian Peter Pii" <[email-masked]>
Date: Tue, 7 Mar 2006 14:05:41 +0100

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-masked]] 
Sent: 7. marts 2006 13:57
To: Schumacher Christian Peter Pii
Cc: [email-masked]
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 don't know during the time or any reason why we
can't 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
<http://ilab.ajou.ac.kr/kkim86/index.htm>   

________________________________

From: Schumacher Christian Peter Pii [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2006 8:09 PM
To: [email-masked]
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
<http://www.ietf.org/html.charters/6lowpan-charter.html>  

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 07 Mar 2006 09:43:41 -0600

I am also for adding the cases where fully functional devices (FFD) not 
being sensor nodes and gateway protocols into the charter reflecting 
state-of-the-art in wireless sensor networks.

Thanks.

--behcet

---

From: Ki-Hyung Kim <[email-masked]>
Date: Wed, 8 Mar 2006 10:58:39 +0900

Hi Christian,

I am curious why the official minutes are not available yet, but there were
such items we had mentioned.

Anyway, the following items were discussed and summarized by Carsten(? If my
memory is correct) as rechartering items on the last interim meeting.

1) Mesh routing protocol

2) Service discovery

3) Scalability of 6lowpan (routing and addressing)

4) Mobility issues

5) Naming service for mesh layer

6) Gateway architecture (This item was discussed as "HC compression" on the
last meeting)

If you need polished statements for these items, let me know.

Regards,

--

Ki-Hyung Kim

Associate Professor

  _____  

From: Schumacher Christian Peter Pii [mailto:[email-masked]] 
Sent: Tuesday, March 07, 2006 10:06 PM
To: Ki-Hyung Kim
Cc: [email-masked]
Subject: RE: [6lowpan] new 6lowpan charter

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

  _____  

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 don't know during the time or any reason why we can't
move forward on these issues?

--

Ki-Hyung Kim

Associate Professor

  _____  

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

--- end of scope --- 

Regards 
Christian

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 08 Mar 2006 00:59:57 -0800

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:

> ------------------------------------------------------------------------
> *From:* Ki-Hyung Kim [mailto:[email-masked]]
> *Sent:* 7. marts 2006 13:57
> *To:* Schumacher Christian Peter Pii
> *Cc:* [email-masked]
> *Subject:* RE: [6lowpan] new 6lowpan charter
>
> Hi, Schumacher,
>
> 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
>
> ------------------------------------------------------------------------
>
> *From:* Schumacher Christian Peter Pii [mailto:[email-masked]]
> *Sent:* Tuesday, March 07, 2006 8:09 PM
> *To:* [email-masked]
> *Subject:* [6lowpan] new 6lowpan charter
>
> Hi.
>
> discussed possible topics for a future rechartering of 6lowpan. Based 
> on available information from that meeting I've compiled the following 
>------------------------------------------------------------------------
>

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.

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 08 Mar 2006 08:33:04 -0700

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:
> plain text document attachment (min.txt)

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 08 Mar 2006 08:40:00 -0700

The lack of minutes is probably my fault.  I dropped the ball.

Yes Carsten created a very good list of rechartering items with names by
the items.  I was hoping that it was on the wiki, but it doesn't seem to
be there yet.  If Carsten will forward it I will incorporate it in to
the meeting minutes and we can get on with that discussion.

Are there any comments on "problem statement" document?

	geoff

On Wed, 2006-03-08 at 10:58 +0900, Ki-Hyung Kim wrote:
> Hi Christian,
> 
> I am curious why the official minutes are not available yet, but there
> were such items we had mentioned.
> 
> Anyway, the following items were discussed and summarized by Carsten(?
> If my memory is correct) as rechartering items on the last interim
> meeting.
> 
>  
> 
> 1) Mesh routing protocol
> 
> 2) Service discovery
> 
> 6) Gateway architecture (This item was discussed as “HC compression”
> on the last meeting)
> 
>  
> 
> ______________________________________________________________________
> From:Schumacher Christian Peter Pii [mailto:[email-masked]] 
> ______________________________________________________________________
> From:Ki-Hyung Kim [mailto:[email-masked]] 
> Is there anything I don’t know during the time or any reason why we
> can’t move forward on these issues?
> 
>  
> 
>  
> 
>  
> 
> --
> 
> Ki-Hyung Kim
> 
> Associate Professor
> 
> ______________________________________________________________________
> From:Schumacher Christian Peter Pii [mailto:[email-masked]]

---

From: Carles Gómez <[email-masked]>
Date: Sat, 11 Mar 2006 13:54:29 +0100

Dear all,

I have a couple of doubts regarding the LOAD specification. Just in case I am 
missing something, I would like to expose them in the list. My doubts are:

1) WEAK_LQI_VALUE
*****************

In Section 3, page 4, the latest LOAD draft states that "The approach taken by 
LOAD avoids a route which contains weak links whose LQI is below certain 
threshold value (i.e. WEAK_LQI_VALUE)". On the other hand, the proposed 
default value for the WEAK_LQI_VALUE parameter is 8. 

However, according to the datasheet of the CC2400 radio chip (i.e. the one 
included in Crossbow's MICAz motes), LQI values range between 50 (bad quality) 
and 110 (good quality). We (and also other researchers) have conducted 
experiments which confirm this range of values. In consequence, it seems 
difficult that a link could have an LQI value below 8 (at least with MICAz 
motes).

Is it possible that proposing WEAK_LQI_VALUE equal to 8 comes from experiences 
with other platforms (i.e. not the MICAz ones)? Do you think a different 
default value for WEAK_LQI_VALUE could be proposed by default?
 
2) Sequence numbers
*******************

LOAD avoids usage of sequence numbers for the sake of simplicity, forcing that 
only the destination is allowed to generate RREP messages in order to avoid 
routing inconsistencies (loops, etc.). However, I would like to expose the 
following doubt.  

In Section 6.3, LOAD spec. states that: "When the destination receives a RREQ, 
it tries to find the entry of the same originator address and RREQ ID pair in 
the route request table. If the entry is found, the destination compares the 
route cost of the RREQ with the forward route cost of the entry. If the cost 
of the RREQ is better than (i.e. less than) that of the entry, the destination 
updates the reverse route to the originator in the routing table and generates 
a RREP in reply. If the cost of the RREQ is not less than that of the entry, 
the destination just discards the RREQ".

Let's consider the following network topology, where A transmits data to C. 
Let's assume all links are equal and have the same quality:

       B
    /     \
  A         C
    \      /
     D - E

According to the 'minimum hop while avoiding weak links' metric, the chosen 
path will be ABC.

Now, if the AB link is broken, A starts a new Route Discovery. There is one 
available path for transmitting data from A to C (ADEC) but since this path 
has a higher cost than the former (let's assume information about the old 
route hasn't yet expired at C), then C discards the RREQ according to Section 
6.3. In consequence, it would not be possible to use the available path.

Am I missing something? Would it be necessary to use sequence numbers to take 
into account, not only the routes cost but also their freshness?

Many thanks in advance.

With best regards,

Carles Gómez
Wireless Networks Group
Technical University of Catalonia (UPC)

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/