Subject: Re: [6lowpan] Issue of the week

From: "Pieter De Mil" <[email-masked]>
Date: Wed, 6 Feb 2008 19:36:33 +0100 (CET)

Hi All,

> We have not had any lively discussion on this list for quite some time
> (actually we have not had ANY discussion on this list for quite some
> time)!  Vacation is over!
>
hmm, actually I'm in Tenerife on vacation now :-)

> Topic:  What 15.4 MAC functions / features should be used or relied upon
> or required by 6lowpan.
>
> Carsten reminded me that this was a topic of discussion at the last
> IETF.
>
> There were some suggestions that we should utilize some of the 15.4 MAC
> primitives for 6lowpan commissioning / bootstrapping.  Others insisted
> that we not require any of the 15.4 primitives.
>
> Let try to resolve this question.
>

Since 6lowpan is based on 802.15.4, why should we not use some of the 15.4
primitives?
I think the association/disassociation primitives can be used for the
commissioning and bootstrapping of the nodes.

best regards,
Pieter
_______________________________________________
6lowpan mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/6lowpan

---

From: Philip Levis <[email-masked]>
Date: Wed, 6 Feb 2008 10:53:35 -0800

> commissioning and bootstrapping of the nodes.

Because, in practice, many vendors use the 15.4 frame format and  
mechanisms as a link layer, but do not use its MAC layer. So assuming  
the MAC tie us closer to the link layer than may be necessary or  
advisable, and preclude adoption by a broad range of users.

Phil

---

From: Anthony Schoofs <[email-masked]>
Date: Thu, 7 Feb 2008 13:07:55 +0100

At the moment we do not use 802.15.4 primitives in our sensor network
deployments because we mainly have star networks of a few nodes with known
addresses and no need for scanning/association/network formation.... We are
going for larger-scale networks.

I wouldn't mind utilize 802.15.4 primitives for 6lowpan commissioning /
bootstrapping because 6lowpan is based on 802.15.4 and the present
primitives can do a lot, the processes are already defined and very often
already implemented in the nodes.

Anthony

Phil

---

From: Robert Cragie <[email-masked]>
Date: Thu, 07 Feb 2008 12:14:38 +0000

Some of the primitives will have to be used simply from the point of 
view of coexistence. At the very least, any 6lowpan network does not 
want to be using the same PAN ID on the same channel as another 
15.4-based network. This implies using the scanning primitives in 15.4 
to locate other networks in the vicinity. Correspondingly, any 6lowpan 
coordinator should be a good neighbour and should therefore start 
properly with the ability to respond with beacons which clearly identify 
the associated PAN as a 6lowpan PAN. It also makes some sense to use the 
15.4 association primitives to join the PAN through an appropriate 
neighbouring coordinator. It is possible not to use association but you 
will need alternative link establishment command frames to facilitate 
this. It is probably not necessary to use disassociation as the device 
is in-band at this point.

Robert

-- 
Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________ 

Geoff Mulligan wrote:
> [ Carsten and I are reviewing the discussion on the charter text to see
> where we are and if the text should be changed - next weeks topic!! ]
>
>         geoff
>
>
>

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 07 Feb 2008 08:13:54 -0800

I'm not convinced that this WG (or the IETF in general) is the 
appropriate place to specify MAC protocols. Requiring the use of 
specific MAC protocols is tantamount to specifying the protocol. W.r.t 
commissioning/bootstrapping, the way I see it is that the link-layer/MAC 
simply has a set of attributes, some of which 6LoWPAN utilizes (e.g. 
short-addrs, EUI-64, etc.).  These attributes must be configured 
somehow, but the specific way they get set is out of scope of this WG.

--
Jonathan Hui

---

From: Kris Pister <[email-masked]>
Date: Thu, 07 Feb 2008 09:53:28 -0800

Clearly we should not be specifying MAC protocols here, and there is a 
lot of energy and flux around the 15.4 MAC (e.g. the 15.4E working group 
is chartered to update it to make it capable of time synchronization and 
channel hopping). 
We have talked in this group about developing an abstraction for the MAC 
layer which allows us to capture the tradeoffs between, e.g., 
throughput, latency, and duty cycle available in many of the non-IEEE 
MAC implementations that use the 15.4 PHY.
Can we generate an explicit list of attributes as you suggest, including 
abstractions of some of these features that many/most of us use, but 
which are still not a part of the 15.4 MAC?

ksjp

---

From: Zach Shelby <[email-masked]>
Date: Thu, 07 Feb 2008 22:28:00 +0200

Hi,

Nice to see Geoff woke up the list, and that someone is really on 
vacation (no jealousy ;-).

I have to agree with Jonathan here. A set of attributes is the most 
appropriate in this case, and this makes it much easier to use 6lowpan 
over other link layers or minimal 802.15.4 implementations. For example 
I would definitely avoid explicit use of association/disassociation in 
beacon-enabled mode. Most deployments in our experience will use 
beaconless mode where those primitives are not available. ICMP can be 
used instead of MAC primitives for many purposes. I would prefer to 
leave the link-layer topology construction details to the 
implementation, some kind of network management entity separate from 
6lowpan and IETF standardization. For example with WiFi + IP 
implementations, the IETF does not take a stand on whether or how you 
configure your interface (ad-hoc mode, infrastructure mode, ap mode) nor 
manage it.

- Zach

-- 
Zach Shelby | CTO | +358 40 7796297
Sensinode Ltd.   www.sensinode.com
_______________________________________________
6lowpan mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 15 Feb 2008 00:32:11 -0800

Hello Geoff, Zach and all in this thread of discussion:

From the discussion, it seems we want some sort of L2 indication from
802.15.4 for bootstrapping and comissioning, but IETF is not quite
capable of defining those primitives.

I do agree that L2 primitives would be the easiest way to act for
commissioning in number of cases. I think 6lowpan wg can do the
following within the scope of IETF:

1. Identify the cases when L2 primitive is useful for commissioning
2. Provide a set of API which deals with L2 primitives or any other L2
specific methods to provide the necessary information to complete the
commissioning part. Note that then we do not have to define the L2
primitives and it can be left with the implementation.

Comments?

Thanks,
-Samita