Subject: [6tisch] 6top Data Model vs 6top API

From: Qin Wang <[email-masked]>
Date: Wed, 20 Nov 2013 22:26:55 +0800

Hi all,

In the current version of 6top draft
http://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-00.txt, we
define 6top API with a set of commands, by which upper layer can access
6top MIB, IEEE802.15.4e TSCH PIB, and some but not all of IEEE802.15.4 PIB.
You can find more detail in the attached file, which is prepared for the
coming Friday Call.

Here are my questions:
(1) Should upper layer be allowed to access MAC layer PIB directly?
(2) What is the coverage of 6top data model, what is the relationship
between 6top data model and 6top API?
(3) Is it suitable to use Yang model to express such kind of data model and
how?

I think possible answers to the first two questions are:
(1) Allow upper layer to access PIB defined in IEEE802.15.4-2011 directly,
but not allow upper layer to access the PIB added by TSCH in
IEEE802.15.4e-2012.
(2) 6top data model will cover 6top MIB and all of the attributes defined
by both IEEE802.15.4-2011 and IEEE802.15.4e TSCH, but 6top API only
provides commands for upper layer to access 6top MIB and the attributes
added by TSCH.

What do you think? Any comment and suggestion is welcome.

Thanks
Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 20 Nov 2013 20:38:28 -0800

Qin,

I believe you are asking the hardest question there is. I personally have
little experience with YANG, so please don't hesitate to refute/correct
anything.

*(1) Should upper layer be allowed to access MAC layer PIB directly? *

What exactly do you mean by "accessing". I see a node as having resources
on which you can perform CRUD operations (Create, Read, Update, Delete). If
we are talking about the ability to Create/Update/Delete, we obviously need
to ensure that changing a particular attribute does not interfere with the
operation of 6top.

That being said, the divide you propose is probably the right one:
separating 15.4 and 15.4e-specific PIB elements.

Does this mean you would replace call to e.g. the security GET/SET commands
by "raw" access to the 15.4 PIB?

*(2) What is the coverage of 6top data model, what is the relationship
between 6top data model and 6top API?*

AFAIK, YANG (http://tools.ietf.org/html/rfc6020) allows you to define state
data, configuration data, and remote procedure calls. I'm copy-pasting the
definitions from RFC6020:

configuration data:
   The set of writable data that is required to transform
   a system from its initial default state into its current
   state.

state data:
   The additional data on a system that is not configuration
   data such as read-only status information and collected
   statistics.

RPC:
   Remote Procedure Call

The goal of this exercise is to express the 6top interface in YANG. This
means finding the subset of functionality that are best described as
"data", and some that are best described as "rpc".

>From talking to Mehmet Ersue (co-chair NETCONF) in Vancouver, people have a
tendency to overload the RPC. His recommendation is, if you can express
some functionality as data, don't use rpc.

For our case, it looks like most of the functionality we are looking for
lends itself well to simple CRUD operations (add link, remove neighbor,
update tie source neighbor), so I would imagine the YANG model would
contain mostly data elements.

As highlighted by Xavi a couple of calls ago, we (certainly I) don't feel
comfortable enough with YANG yet. Any YANG aficionados who could extend a
helping hand?

*(3) Is it suitable to use Yang model to express such kind of data model
and how?*

Hmm. I believe I went a bit overboard in the previous answer, which also
covers this question.

Thomas

On Wed, Nov 20, 2013 at 6:26 AM, Qin Wang <[email-masked]> wrote:

> (3) Is it suitable to use Yang model to express such kind of data model
> and how?
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Wed, 20 Nov 2013 21:52:00 -0800

Hi all,

looking 1) from another perspective. As we want 6top to be able to operate
and be an interface for network management protocols, we have to ask
ourselves if having a 6top layer that only offers configuration options to
TSCH MAC layer MIB is useful and complete. I think that most of the problem
will fall into the YANG Model data representation, i.e. Should this model
cover all MIB attributes on L2?

Related to that, how this is done on other stacks and protocol suites?
Zigbee? ISA100.11a?, etc.. I assume that the management layer is able to
configure everything on L2 no?

My opinion on that is that at Data Model level we should address all MIB
elements. At API/interface level only those related to TSCH and 6top MIB as
implementers will bypass other calls to the corresponding L2 interfaces not
related to TSCH.

Besides, +1 on having a tutorial/overview about YANG. Any expert?

On Wed, Nov 20, 2013 at 8:38 PM, Thomas Watteyne <[email-masked]
> wrote:

> Does this mean you would replace call to e.g. the security GET/SET
> commands by "raw" access to the 15.4 PIB?
>
> AFAIK, YANG (http://tools.ietf.org/html/rfc6020) allows you to define
> state data, configuration data, and remote procedure calls. I'm
> copy-pasting the definitions from RFC6020:
>
> configuration data:
> From talking to Mehmet Ersue (co-chair NETCONF) in Vancouver, people have
> a tendency to overload the RPC. His recommendation is, if you can express
>> (1) Allow upper layer to access PIB defined in IEEE802.15.4-2011
>> directly, but not allow upper layer to access the PIB added by TSCH in
>> IEEE802.15.4e-2012.

---

From: Qin Wang <[email-masked]>
Date: Thu, 21 Nov 2013 23:00:03 +0800

Thomas,

Your understanding on 1) is exactly what I mean.

I agree with Xavi that Data Model should include 6top MIB and all of
attributes in L2 PIB defined in 15.4 and 15.4e TSCH, and 6top API only CRUD
those related to TSCH and 6top MIB.

In another word, it means the data expressed in YANG will include all of
the data in 6top MIB and in L2 PIB. Then, the problem is what should be the
RFC in YANG model. I guess there are several approaches.
(1) RFC includes 6top API and SET/GET of 15.4. And the management entity
maps the RFC to 6top API and SET/GET of 15.4 directly.
(2) RFC are general CRUD regardless the operated data belonging to 6topMIB,
15.4ePIB, or 15.4PIB. And the management entity is responsible to translate
the CRUD to 6top API or 15.4SET/GET accordingly.
(3) RFC are general SET/GET, and CREATE/READ/UPDATE/DELETE is the value of
a variable. And the management entity is responsible to translate to 6top
API or 15.4SET/GET accordingly.

Just thought.

+1 on having a talk about YANG.

Thanks
Qin

On Thu, Nov 21, 2013 at 1:52 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> On Wed, Nov 20, 2013 at 8:38 PM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Qin,
>>
>>> (2) 6top data model will cover 6top MIB and all of the attributes
>>> defined by both IEEE802.15.4-2011 and IEEE802.15.4e TSCH, but 6top API only

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 22 Nov 2013 04:02:33 +0100

Hi Qin,

I see more 3) the RFC defines the general YANG Model and how to access 6top
API and how to map it to 15.4e TSCH related attributes. Other attributes
from 15.4 should be accessed by the management layer directly without
interfering with 6top (unless they are related to TSCH).

do you see anything strange on that approach?
X

On Thu, Nov 21, 2013 at 4:00 PM, Qin Wang <[email-masked]> wrote:

> (2) RFC are general CRUD regardless the operated data belonging to
> 6topMIB, 15.4ePIB, or 15.4PIB. And the management entity is responsible to
> translate the CRUD to 6top API or 15.4SET/GET accordingly.
>> looking 1) from another perspective. As we want 6top to be able to
>> operate and be an interface for network management protocols, we have to
>> ask ourselves if having a 6top layer that only offers configuration options
>> to TSCH MAC layer MIB is useful and complete. I think that most of the
>> problem will fall into the YANG Model data representation, i.e. Should this
>> model cover all MIB attributes on L2?
>>
>>> I believe you are asking the hardest question there is. I personally
>>> have little experience with YANG, so please don't hesitate to
>>> refute/correct anything.
>>>
>>> What exactly do you mean by "accessing". I see a node as having
>>> resources on which you can perform CRUD operations (Create, Read, Update,
>>> Delete). If we are talking about the ability to Create/Update/Delete, we
>>> obviously need to ensure that changing a particular attribute does not
>>> interfere with the operation of 6top.
>>>
>>> From talking to Mehmet Ersue (co-chair NETCONF) in Vancouver, people
>>> have a tendency to overload the RPC. His recommendation is, if you can
>>> express some functionality as data, don't use rpc.
>>>
>>> As highlighted by Xavi a couple of calls ago, we (certainly I) don't
>>> feel comfortable enough with YANG yet. Any YANG aficionados who could
>>> extend a helping hand?
>>>

---

From: Qin Wang <[email-masked]>
Date: Fri, 22 Nov 2013 23:24:47 +0800

Xavi,

There is one thing I'm not very sure. In our discussion, we often use
"management layer" or "management entity" as something to process the
management message and interact with 6top, or 15.4 as you mentioned above.
But, where is the "management layer" or "management entity" in the protocol
stack? Is it in the 6top scope, or out of 6top scope?

Thanks
Qin

On Fri, Nov 22, 2013 at 11:02 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> Hi Qin,
>
> I see more 3) the RFC defines the general YANG Model and how to access
> 6top API and how to map it to 15.4e TSCH related attributes. Other
> attributes from 15.4 should be accessed by the management layer directly
> without interfering with 6top (unless they are related to TSCH).
>
>> (3) RFC are general SET/GET, and CREATE/READ/UPDATE/DELETE is the value
>> of a variable. And the management entity is responsible to translate to
>> 6top API or 15.4SET/GET accordingly.
>>
>> Just thought.
>>
>>>> The goal of this exercise is to express the 6top interface in YANG.
>>>> This means finding the subset of functionality that are best described as
>>>> For our case, it looks like most of the functionality we are looking
>>>> for lends itself well to simple CRUD operations (add link, remove neighbor,
>>>> *(3) Is it suitable to use Yang model to express such kind of data
>>>> model and how?*
>>>>
>>>> Hmm. I believe I went a bit overboard in the previous answer, which
>>>> also covers this question.
>>>>
>>>> Thomas
>>>>
>>>>> (3) Is it suitable to use Yang model to express such kind of data
>>>>> model and how?
>>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 22 Nov 2013 17:06:32 -0800

Qin,

This is a term I have been considering very "generic". Since we are driving
towards a combination of management mechanisms, I believe where the
"management" comes from depends on the mechanism you are using.

For me:
- the "management entity" could be an algorithm local to the node (e.g.
OTF), a distributed scheduling policy (e.g. RSVP-like), a node multiple
hops away, a host on the Internet, etc.
- the "mamagement layer" sits somewhere in the stack above 6top, and drives
it. Example are CoAP, RSVP-like, etc.

Xavi, is your definition similar?

Thomas

On Fri, Nov 22, 2013 at 7:24 AM, Qin Wang <[email-masked]> wrote:

>>>> My opinion on that is that at Data Model level we should address all
>>>> MIB elements. At API/interface level only those related to TSCH and 6top
>>>> MIB as implementers will bypass other calls to the corresponding L2
>>>> interfaces not related to TSCH.
>>>>
>>>>> On Wed, Nov 20, 2013 at 6:26 AM, Qin Wang <[email-masked]>wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-wang-6tisch-6top-00.txt,
>>>>>> we define 6top API with a set of commands, by which upper layer can access

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 22 Nov 2013 22:10:06 -0800

Hi Thomas,

I am in your line. For me management is somehow vertical as it involves
actions at different layers but for simplicity we can image it somewhere
around L4.

regards!
Xavi

On Fri, Nov 22, 2013 at 5:06 PM, Thomas Watteyne <[email-masked]

> Qin,
>
> This is a term I have been considering very "generic". Since we are
> driving towards a combination of management mechanisms, I believe where the
> - the "mamagement layer" sits somewhere in the stack above 6top, and
> drives it. Example are CoAP, RSVP-like, etc.
>
>>>> In another word, it means the data expressed in YANG will include all
>>>> of the data in 6top MIB and in L2 PIB. Then, the problem is what should be
>>>> the RFC in YANG model. I guess there are several approaches.
>>>> (1) RFC includes 6top API and SET/GET of 15.4. And the management
>>>> entity maps the RFC to 6top API and SET/GET of 15.4 directly.
>>>>>> *(2) What is the coverage of 6top data model, what is the
>>>>>> relationship between 6top data model and 6top API?*
>>>>>>
>>>>>> AFAIK, YANG (http://tools.ietf.org/html/rfc6020) allows you to
>>>>>> define state data, configuration data, and remote procedure calls. I'm
>>>>>>> (2) What is the coverage of 6top data model, what is the
>>>>>>> relationship between 6top data model and 6top API?

---

From: Qin Wang <[email-masked]>
Date: Mon, 25 Nov 2013 10:20:07 +0800

Hi Xavi and Thomas,

I agree your the definition of management entity and management layer.

Then, take CoAP as an example of upper layer which includes management
entity. If we allow upper layer manage 15.4 PIB directly, and use 6top API
to manage 6top MIB and TSCH PIB, it will require the management entity in
CoAP translate its PUSH/GET to MLME-SET/MLME-GET if the resource is 15.4
PIB, and to 6top commands if the resource belongs to 6top (including TSCH
PIB), respectively. Correct?

Thanks
Qin

On Sat, Nov 23, 2013 at 2:10 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> On Fri, Nov 22, 2013 at 5:06 PM, Thomas Watteyne <
>>>>> (3) RFC are general SET/GET, and CREATE/READ/UPDATE/DELETE is the
>>>>> value of a variable. And the management entity is responsible to translate
>>>>> to 6top API or 15.4SET/GET accordingly.
>>>>>
>>>>> Just thought.
>>>>>
>>>>>> Related to that, how this is done on other stacks and protocol
>>>>>> suites? Zigbee? ISA100.11a?, etc.. I assume that the management layer is
>>>>>> able to configure everything on L2 no?
>>>>>>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Mon, 25 Nov 2013 11:58:57 +0100

Hi Qin, yes I completely agree on your way of seeing this.

regards,
Xavi

On Mon, Nov 25, 2013 at 3:20 AM, Qin Wang <[email-masked]> wrote:

>>>>> On Thu, Nov 21, 2013 at 4:00 PM, Qin Wang <[email-masked]>wrote:
>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>>>> I believe you are asking the hardest question there is. I
>>>>>>>> personally have little experience with YANG, so please don't hesitate to
>>>>>>>> refute/correct anything.
>>>>>>>>
>>>>>>>> From talking to Mehmet Ersue (co-chair NETCONF) in Vancouver,
>>>>>>>> people have a tendency to overload the RPC. His recommendation is, if you
>>>>>>>> can express some functionality as data, don't use rpc.
>>>>>>>>
>>>>>>>> For our case, it looks like most of the functionality we are
>>>>>>>> looking for lends itself well to simple CRUD operations (add link, remove
>>>>>>>> neighbor, update tie source neighbor), so I would imagine the YANG model
>>>>>>>> would contain mostly data elements.
>>>>>>>>
>>>>>>>> As highlighted by Xavi a couple of calls ago, we (certainly I)
>>>>>>>> don't feel comfortable enough with YANG yet. Any YANG aficionados who could
>>>>>>>> extend a helping hand?
>>>>>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 25 Nov 2013 17:31:32 -0800

One quick follow-up on this definition, since we don't want to end with
inaccuracies. Strictly speaking, each layer can have a management entity as
part of it, which can offer some interface. One example is IEEE802.15.4's
MLME (MAC sublayer management entity).

What we are talking about is a different layer which uses the 6top API.
Calling it "management layer" is confusing, since it might refer to the
management part of 6top, not a separate layer.

I suggest we use a different term. scheduling layer/entity?

Thomas

On Mon, Nov 25, 2013 at 2:58 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

>>>>>> I see more 3) the RFC defines the general YANG Model and how to
>>>>>> access 6top API and how to map it to 15.4e TSCH related attributes. Other
>>>>>>> In another word, it means the data expressed in YANG will include
>>>>>>> all of the data in 6top MIB and in L2 PIB. Then, the problem is what should
>>>>>>> be the RFC in YANG model. I guess there are several approaches.
>>>>>>>> My opinion on that is that at Data Model level we should address
>>>>>>>> all MIB elements. At API/interface level only those related to TSCH and
>>>>>>>> 6top MIB as implementers will bypass other calls to the corresponding L2
>>>>>>>>> The goal of this exercise is to express the 6top interface in
>>>>>>>>> YANG. This means finding the subset of functionality that are best
>>>>>>>>> described as "data", and some that are best described as "rpc".
>>>>>>>>>
>>>>>>>>> Hmm. I believe I went a bit overboard in the previous answer,
>>>>>>>>> which also covers this question.
>>>>>>>>>
>>>>>>>>> Thomas
>>>>>>>>>

---

From: Qin Wang <[email-masked]>
Date: Tue, 26 Nov 2013 12:45:55 +0800

How about Operation layer/entity?

Qin

On Tue, Nov 26, 2013 at 9:31 AM, Thomas Watteyne <[email-masked]

>>>>> - the "management entity" could be an algorithm local to the node
>>>>> (e.g. OTF), a distributed scheduling policy (e.g. RSVP-like), a node
>>>>> multiple hops away, a host on the Internet, etc.
>>>>> On Fri, Nov 22, 2013 at 7:24 AM, Qin Wang <[email-masked]>wrote:
>>>>>
>>>>>> Xavi,
>>>>>>
>>>>>>>> I agree with Xavi that Data Model should include 6top MIB and all
>>>>>>>> of attributes in L2 PIB defined in 15.4 and 15.4e TSCH, and 6top API only
>>>>>>>> CRUD those related to TSCH and 6top MIB.
>>>>>>>>
>>>>>>>>>> That being said, the divide you propose is probably the right
>>>>>>>>>> one: separating 15.4 and 15.4e-specific PIB elements.
>>>>>>>>>>
>>>>>>>>>> Does this mean you would replace call to e.g. the security
>>>>>>>>>> GET/SET commands by "raw" access to the 15.4 PIB?
>>>>>>>>>>
>>>>>>>>>> *(3) Is it suitable to use Yang model to express such kind of
>>>>>>>>>> data model and how?*
>>>>>>>>>>
>>>>>>>>>>> (3) Is it suitable to use Yang model to express such kind of
>>>>>>>>>>> data model and how?
>>>>>>>>>>>
>>>>>>>>>>> (2) 6top data model will cover 6top MIB and all of the
>>>>>>>>>>> attributes defined by both IEEE802.15.4-2011 and IEEE802.15.4e TSCH, but
>>>>>>>>>>> 6top API only provides commands for upper layer to access 6top MIB and the
>>>>>>>>>>> attributes added by TSCH.
>>>>>>>>>>>