Clone wiki

meetings / 140415_webex_6top

Minutes Webex 15 April, 6top call 6TiSCH WG

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Thomas Watteyne

Attendance (alphabetically)

  1. Qin Wang
  2. Raghuram Sudhaakar
  3. Thomas Watteyne
  4. Xavi Vilajosana

%============ template ===========

  1. Pouria Zand
  2. Raghuram Sudhaakar

%============ template ===========

Action items


(1) in the security call yesterday (minutes at, which I will send to ML today), we discussed distributed management, and the security aspects. The security DT would like to know which neighbor should have the right to modify a node's schedule. Only the set of RPL parents?

(2)the OTF authors (I'm CC'ing Diego) would like to know whether it is possible to extend the 6top interface. I would like that to be generic, so that other extension modules (such as OTF) can be added to the interface when/if needed.

(3) exercise on implementing 6top negotiation with YANG and CoAP

(4) using CoAP to implement 6top management interface - How to express node address? use uri-host or not? IP address or MAC address? - Need observer function? use uri-port? - How to fragment data to fit IE payload size? use CoAP block?

(5) 6top-to-6top Access Control model.

(6) How to express 6top MIB and IEEE802.15.4 PIB in YANG? (comments from Juergen)


  • [08.06] meeting starts

security group discussion;

who we should authorize to talk t who. Parent to children only or? or keep it generic. -if parent child only, then RPL security might work -QW: from L3 point of view we only need Parent Child communication. At L2 however we need node to node communication, any. -TW: From security group point of view centralized approaches (PCE to nodes) is a wellknown case, distributed in contrast is morre open as there are many options. Distribution of keys, network wide, neighbor to neighbor keys.. etc.. -Do we need any node in a neighborhood to talk to all its neighbors? -Parent-child relationship may change, it is dynamic, mesh approach. -If security tight to RPL then RPL can handle parent-child relations.

QW; parent child, child to parent, any 6top to any 6top. We need two of this three. Xavi: what do we mean by parent-child? TW: all node in parent set


Key distribution is the challenge as there is not a central entity that can be trusted. Parent-children can be handled by RPL.

We conclude that any node in the network after joining will be in a parent-child relation as it will acquire a rank. Therefore 6top only needs parent-child and child-parent communication.

OTF Question; Can the 6top interface be extended? Need a mechanism to extend it transparently from 6top. Extension of MIB. The resources that 6top manages can be extended. OTF can be seen as an extension of the 6top model. It is within the same layer.

Allowing extending resources, we also allow other to extend commands. Extended resources can extend their set of commands.

15.4e has only GET and SET and the command only can operate on any attribute on the PIB.

Options; for each resource (MIB) one command set only one generic command set for all MIB

What matters is the yang model and list of resources. The mapping to 6top commands is not a very important aspect. All extensions are behind an extension resource. e.g. /e .- /e/otf will be in the otf world. How to layer them? otf is not adding anything so it is part of it. Not another layer, it is an extra resource in the yang model. Same layer.


/6t/e is the extension scope. Getting the /e returns the list of extensions in that node. Then 6t/e/otf/xxx to modify resource xxx in otf

for the Interface draft a new resource needs to be added, which is the extension resource. When getting that resource, this returns the list of extensions in the mote. (Discovery)

Mechanism to have the extension MUST be in the interface draft (generic) the OTF draft describes the extension of the YANG model for the use in the OTF scope.

how do we express the extension (generic) in the yang model? what are the attributes? it only has one attribute which is the uuid, so it can be uniquely indentified. This resource can only be GET to do service discovery Extension will be placed as sub resources in that resource. e.g. 6t/e/otf/xxx

only method to be added is get Extensions from an interface draft point of view.

ACTIONS: QW starts and forwards the text to others in the group so we can review.