Subject: [6lo] Fwd: Re: 6lowpan MIB

From: peter van der Stok <[email-masked]>
Date: Fri, 07 Feb 2014 12:19:57 +0100

In principle you are right that PANID belongs in IEEE 802.15.4 MIB
But it is referenced for the definition of the lowpan in RFC4944; for 
example:

"This MUST be done such that the broadcast frames
    are only heeded by devices within the specific PAN of the link in
    question. "

As such I thought it fitted in a LOWPAN MIB.

Greetings,

Peter

Juergen Schoenwaelder schreef op 2014-02-07 12:07:
> On Fri, Feb 07, 2014 at 11:47:14AM +0100, peter van der Stok wrote:
>> Dear authors,
>> 
>> In the IEEE 802.15.4 the PANID determines the lowpan. Can the PANID
>> be added to the MIB?
>> A similar function is provided by SSID for 802.11.
>> 
>> I am not familiar if other technologies considered by 6lo such as
>> lobac or btle provide a similar identifier to identify multiple
>> networks over the same channel.
> 
> I am not sure I understand your request. Right now, the MIB module
> only has scalar counters for the 6lowpan layer, regardless the
> interfaces attached to the 6lowpan layer. The PANID is an IEEE
> 802.15.4 layer addressing concept and hence it belongs to a MIB module
> covering the 802.15.4 layer. Perhaps you are looking for an IEEE
> 802.15.4 MIB module and not an extension of the LOWPAN-MIB?
> 
> /js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Feb 2014 12:39:50 +0100

On Fri, Feb 07, 2014 at 12:19:57PM +0100, peter van der Stok wrote:
> But it is referenced for the definition of the lowpan in RFC4944;
> for example:
> 

Sure, RFC 4944 talks about PAN IDs. But that does not automatically
imply that the LOWPAN-MIB module has to as well. RFC 4944 also says
(in the same paragraph):

  This document assumes that a PAN maps to a specific IPv6 link.

This means the underlying link/interface is associated with a PAN.
For unicast, the distinction is also implicit if you turn PAN scoped
short addresses into Interface Identifiers following RFC 4944.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: peter van der Stok <[email-masked]>
Date: Fri, 07 Feb 2014 14:41:39 +0100

Hi Juergen,

Next question, sorry to insist.
A node can have several interfaces; I can imagine that a router has 2 or 
more lowpan interfaces.
I don't see the interface appearing in your MIB, (unless I skipped 
over).
Wouldn't it be better to have the lowpan statistics per interface?

Peter

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Feb 2014 16:38:23 +0100

On Fri, Feb 07, 2014 at 02:41:39PM +0100, peter van der Stok wrote:
> A node can have several interfaces; I can imagine that a router has
> 2 or more lowpan interfaces.

Because more is better? The basic IP layer statistics are not per
interface and I followed that model. The 6lowpan implementations I
looked at did not track over which interfaces packets were coming that
the 6lowpan layer was processing. I do not think per interface 6lowpan
statistics are needed. The general interface statistics should be
sufficient to determine what the interfaces are doing in general.
Lets not forget that we are talking about constrained devices.

/js

---

From: peter van der Stok <[email-masked]>
Date: Fri, 07 Feb 2014 18:38:00 +0100

It certainly is not: more is better.
And yes, we are discussing small devices mostly.

But, I was thinking of a router device using the lowpan MIB.
The behavior on one link may be quite different from the behavior on 
another link; Links may use different channels or even different 
wireless PHYs.
I thought it was useful to be able to distinguish between interfaces.

The amount of data to a small device with one interface will not 
increase significantly if interface number is added to the MIB, I 
expect.

Peter

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Feb 2014 19:41:27 +0100

> I thought it was useful to be able to distinguish between interfaces.

I think we should not do this at this point in time. I believe
system-wide statistics are currently sufficient. The IP-MIB had
system-wide counters only from its origin in the late 1980s until 2006
when interface specific counters were added.

> increase significantly if interface number is added to the MIB, I

If you follow the IP-MIB approach, you double the data. And if you do
not provide system-wide counters and only interface specific counters,
you increase the traffic needed to fetch interface-specific counters
and to sum them up to determine whether there is a LOWPAN related
problem.

I believe we should follow the evolution of the IP-MIB, that is start
with system-wide counters. If we eventually face lots of systems with
many LOWPAN interfaces and we know a differentiation is needed, we add
interface specific counters.  At the moment, I am not convinced this
is necessary.

/js

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 7 Feb 2014 10:49:30 -0800

Jürgen,

if we follow this approach, would there be any backwards compatibility
issues (in case we later add management per interface)? How was that done
in the IP-MIB module? Can this functionality simply be added, or would it
have to replace the MIB module?

Thanks
Ulrich

On Fri, Feb 7, 2014 at 10:41 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Feb 2014 19:50:45 +0100

> have to replace the MIB module?

You can simply add additional objects.

/js

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 7 Feb 2014 10:59:32 -0800

Thanks.

Peter, is there currently any concrete industrial need for multiple 6lowpan
interface management? The router case you mention is only then relevant if
there are multiple interfaces using the 6lowpan stack (unlike having
multiple interfaces, but only one of them using 6lowpan).
I understand Jürgen's worry about increased complexity and overhead.

Regards
Ulrich

---

From: peter van der Stok <[email-masked]>
Date: Mon, 10 Feb 2014 09:15:54 +0100

Hi Juergen,

thanks for the explantion. I did not expect doubling the data even if 
there is only one interface present.

When there are no other people with clear wishes, I think we should stay 
with the global counters.

I have no specific use case. I was extrapolating triggered by the 
multicast scope discussion in Roll.

Peter

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Feb 2014 02:07:31 +0000

Hello Peter,

Are you considering a scenario when a router has multiple 6lo interfaces?

I think that's a very good point.  '6lo' supports multiple L2 technologies where RFC4944 was defined for 802.15.4. Thus it is  normal that a router can have multiple 6lo interfaces [ BTLE and ZigBEee] or BTLE and an Ethernet Interface with software 6lowpan driver or a Wifi interface with a 6lowpan driver for processing the 6lowpan data received over a wired line from the 6lo network node.

Juergen, Will the 6lowpan-mib document address this scenario ?  [ can we add 6lo interface information to the MIB structure?]

Thanks,
-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Friday, February 07, 2014 9:38 AM
To: [email-masked]; [email-masked]
Subject: Re: [6lo] Fwd: Re: 6lowpan MIB

But, I was thinking of a router device using the lowpan MIB.
The behavior on one link may be quite different from the behavior on another link; Links may use different channels or even different wireless PHYs.
I thought it was useful to be able to distinguish between interfaces.

The amount of data to a small device with one interface will not increase significantly if interface number is added to the MIB, I expect.

Peter

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Feb 2014 02:15:14 +0000

Hi Juergen,

 > I believe we should follow the evolution of the IP-MIB, that is start with system-wide counters. If we eventually face lots of systems with many LOWPAN  >interfaces and we know a differentiation is needed, we add interface specific counters.  At the moment, I am not convinced this is necessary.

-- 
[SC>]  Originally if we consider one single L2 technology for 6lo I agree that per-interface information is not needed.
             But is it possible to add  optional fields for  the interface(type, id) in the 6lowpan MIB to reflect '6lo' properties?
            '6lo'  in fact is supported for multiple Link-layer technologies.
If it is optional, implementations choose what they can implement and deploy. 

Thanks,
-Samita

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Feb 2014 08:21:08 +0100

The question is not whether it is possible but whether it is needed.
And it does not matter whether there are multiple link-layer
technologies or not. You can of course have multiple interfaces of the
same technology. The LOWPAN-MIB avoids to be interface type specific
for a good reason.

/js