Subject: [6tisch] implement 6top softcell negotiation with CoAP

From: Qin Wang <[email-masked]>
Date: Wed, 2 Apr 2014 11:08:32 -0700 (PDT)

Hi all,

I'm investigating if it is possible to implement the process of 6top softcell negotiation with CoAP. 

Take softcell create process as an example, and assume nodeB is a neighbor of nodeA. The following table includes (1) the negotiation process defined in current version of 6top sublayer, which consists of three steps; (2) implementation of the negotiation process with POST method; (3) implementation of the negotiation process with GET method. Both (2) and (3) correspond to the three steps described in (1)

  nodaA nodeB 
 
Create Softcell in current version of 6top sublayer 
Step1. send Soft Cell Reservation Request, including:
- BwIE, indicate m cells needed 
- ScheduleIE, indicate candidate cells, can be empty.   
Step2.   Upon receiving the request
(1)     create resource CellList[i]..CellList[i+m-1], 
(2)     send Soft Cell Reservation Response, including:
BwIE, indicate reserved cells
ScheduleIE, indicate the cells reserved 
Step3. Upon receiving the response, 
create resource CellList[j]..CellList[j+m-1]   
 
Implement the above procedure with POST, where C(*IE) represent the payload of the IE. 
Setp1. POST
Uri-path = 6t/SoftcellScheduler
Payload= C(BwIE) +C( ScheduleIE)   
  Upon receiving the packet,
response to POSTwith code=2.04 changed 
Step2-0   Call SoftcellScheduler to make softcell reservation and create resource CellList[i]..CellList[i+m-1], m is the number of cells reserved. 
Step2-1   POST
Uri-path =6t/CellList
Payload = the content of the CellList[i], but replace its RX with TX 
Step3-1. Upon receiving the packet,
response to POSTwith code=2.01 create   
Create CellList[j], and fill it with the payload   
Repeat step2-1 and step3-1 for m times.

Implement the above procedure with GET, where C(*IE) represent the payload of the IE 
Step1. GET
Uri-path = 6t/SoftcellScheduler
Payload= C(BwIE) + C(ScheduleIE)   
Step2.   Upon receiving the packet,
Call SoftcellScheduler to make softcell reservation and create resource CellList[i]..CellList[i+m-1] 
  Response to GET
Uri-path 6t/SoftcellScheduler
Payload =
 C(BwIE) 
+ CellList[i]..CellList[i+m-1], with TX replace RX in them 
Step3. Upon receiving the packet,
Create CellList[j]..CellList[j+m-1], and fill them with the payload   
 
In both of the implementations, a special kind of resource is introduced, i.e. SoftcellScheduler. The behavior of POST and GET on resource SoftcellScheduler is different from that on conventional MIB resource. I'm not sure if CoAP allows it or not.

If SoftcellScheduler is accepted as a legal resource, likely, the implementation with GET makes more sense. 

What do you think?

Thanks
Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 3 Apr 2014 05:35:19 +0200

Hi Qin,

that's a great exercise! I think that for the POST case the payload of the
response can include the updated object, if we represent the POSTed object
as having an empty CellList and after the update at the receiver side the
CellList is filled. So the POST case is very similar to the GET case, but
semantically makes more sense to POST (update) a resource.

what do you think?
X

2014-04-02 20:08 GMT+02:00 Qin Wang <[email-masked]>:

> Take softcell create process as an example, and assume nodeB is a neighbor
> of nodeA. The following table includes (1) the negotiation process defined
> in current version of 6top sublayer, which consists of three steps; (2)
> implementation of the negotiation process with POST method; (3)
> implementation of the negotiation process with GET method. Both (2) and (3)
> correspond to the three steps described in (1)
>
>
>  nodaA
>  nodeB
>
>   Step1.
>  send Soft Cell Reservation Request, including:
>   Step2.
>  Upon receiving the request
>   Setp1.
>  POST
> response to POST with code=2.04 changed
>   Step2-0
>
>  Call SoftcellScheduler to make softcell reservation and create resource
> CellList[i]..CellList[i+m-1], m is the number of cells reserved.
>   Step2-1
>
>  POST
> Uri-path =6t/CellList
> response to POST with code=2.01 create
>
>   *Repeat step2-1 and step3-1 for m times.*
>
>
> Implement the above procedure with *GET*, where C(*IE) represent the
> payload of the IE
>   Step1.
>  GET
>   Step2.
> In both of the implementations, a special kind of resource is introduced,
> i.e. SoftcellScheduler. The behavior of POST and GET on resource
> SoftcellScheduler is different from that on conventional MIB resource. I'm
> not sure if CoAP allows it or not.
>
> If SoftcellScheduler is accepted as a legal resource, likely, the
> implementation with GET makes more sense.
>
> What do you think?
>
> Thanks
> Qin
>
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 3 Apr 2014 06:46:15 -0700 (PDT)

Xavi,

I agree it is doable with POST functionally.

I have another concern about using POST, i.e. access control. I'm not sure how we will do the access control, only allowing parents write children, or allowing arbitrary node write its neighbors but depending on different resource.

What do you think?

Thanks
Qin
On Thursday, April 3, 2014 11:35 AM, Xavier Vilajosana <[email-masked]> wrote:
 
Hi Qin,

that's a great exercise! I think that for the POST case the payload of the response can include the updated object, if we represent the POSTed object as having an empty CellList and after the update at the receiver side the CellList is filled. So the POST case is very similar to the GET case, but semantically makes more sense to POST (update) a resource. 

what do you think?
X

Hi all,

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 3 Apr 2014 15:53:26 +0200

Hi Qin,

there are many options to regulate access to resources, I can think on
having access by node by resource, i.e a node is allowed to invoke a method
to a specific resource of a specific neighbor as web server do.

We need to look to what CoAP and ACE provide already for that matter.
X

2014-04-03 15:46 GMT+02:00 Qin Wang <[email-masked]>:

> I have another concern about using POST, i.e. access control. I'm not sure
> how we will do the access control, only allowing parents write children, or
> allowing arbitrary node write its neighbors but depending on different
> resource.
>
> What do you think?
>
> Thanks
> Qin
> CellList[i]..CellList[i+m-1]
>
>  Response to GET

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Thu, 3 Apr 2014 14:47:51 +0000

Xavi, Qin,

Another possible implementation strategy for access control is to have  an API such as "isParent(ip_addr *addr)”.

Assuming the parser is passed the source ip/mac we will need when it gets called from the 6top layer, this will allow the CoAP to identify the access it must allow for this request.

This will allow all access control policies to be contained within the CoAP parser, instead of being sprinkled across CoAP and 6top.

-raghuram

From: Xavier Vilajosana <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 3, 2014 at 6:53 AM
To: Qin Wang <[email-masked]<mailto:[email-masked]>>
Cc: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>, raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] implement 6top softcell negotiation with CoAP

Hi Qin,

there are many options to regulate access to resources, I can think on having access by node by resource, i.e a node is allowed to invoke a method to a specific resource of a specific neighbor as web server do.

2014-04-03 15:46 GMT+02:00 Qin Wang <[email-masked]<mailto:[email-masked]>>:
Xavi,

What do you think?

Thanks
Qin
On Thursday, April 3, 2014 11:35 AM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

what do you think?
X

2014-04-02 20:08 GMT+02:00 Qin Wang <[email-masked]<mailto:[email-masked]>>:
Hi all,

nodaA

nodeB

Step1.

Step2.

Step3.

Upon receiving the response,
create resource CellList[j]..CellList[j+m-1]

Setp1.

POST

Step2-0

Call SoftcellScheduler to make softcell reservation and create resource CellList[i]..CellList[i+m-1], m is the number of cells reserved.

Step2-1

POST
Uri-path =6t/CellList

Step3-1.

Step1.

GET

Step2.

Response to GET

Step3.

What do you think?

Thanks
Qin

---

From: Qin Wang <[email-masked]>
Date: Thu, 3 Apr 2014 11:06:23 -0700 (PDT)

Hi Raghuram,

I think it is good idea to put all access control policies within the CoAP parser. By calling 6top command READ.timesource, a node can know who its parent is.

Considering employing POST to implement the softcell negotiation process, I wonder if it is possible to define more flexible control policy. It is because the two nodes in the softcell negotiation process are not necessarily parent and child. Can we define the access control as a function of nodes' relationship and resource. For example, for CellList, only parent can POST to its children; for SoftcellScheduler, arbitrary node can POST to its neighbor.

What do you think?

Thanks
Qin

On Thursday, April 3, 2014 10:48 PM, Raghuram Sudhaakar (rsudhaak) <[email-masked]> wrote:
 
Xavi, Qin,

-raghuram

From: Xavier Vilajosana <[email-masked]>
Date: Thursday, April 3, 2014 at 6:53 AM
To: Qin Wang <[email-masked]>
Cc: Thomas Watteyne <[email-masked]>, raghuram sudhaakar <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [6tisch] implement 6top softcell negotiation with CoAP

Hi Qin, 

Xavi,
>>If SoftcellScheduler is accepted as a legal resource, likely, the implementation with GET makes more sense. 

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

---

From: Qin Wang <[email-masked]>
Date: Thu, 3 Apr 2014 12:54:25 -0700 (PDT)

Hi all,

According to the above discussion, I try to express the exercise in YANG model and CoAP. For applying CoAP methods directly, the previously introduced resource SoftCellScheduler is split into two parts, i.e. NegotiationSetting and NegotiationResult, 

  container NegotiationSetting {
      leaf OpCode {
         type enumeration {
            enum RESERVESOFTCELL;
            enum REMOVESOFTCELL;
         }
      }
      leaf RequiredBW {
         type uint8;
         description
         "number of softcells to be reserved or removed";
      }
      leaf SlotframeID {
         type uint8;
         description
         "indicate the Slotframe in which softcells will be reserved or removed";
      }
      leaf TrackID {
            type uint16;
            description
            "A TrackID points to a tuple (TrackOwnerAddr,InstanceID), where
            TrackOwnerAddr is the address of the node which initializes
            the process of creating the track, i.e., the owner of the
            track; and InstanceID is an instance identifier given by
            the owner of the track.";
      }
      List CandidateList {
         key "SlotOffset ChannelOffset";
         leaf SlotOffset{
            type uint16;
            description
            "The slotoffset.";
         }
         leaf ChannelOffset{
            type uint16;
            description
            "The channeloffset.";
         }
      } 
   }
   
   container NegotiationResult {
      leaf NumOfCells {
         type uint8;
         description
         "number of softcells actually reserved or removed"
      }
      
      List ResultedCells {
         key "SlotOffset ChannelOffset";
         leaf SlotOffset{
            type uint16;
            description
            "The slotoffset.";
         }
         leaf ChannelOffset{
            type uint16;
            description
            "The channeloffset.";
         }
      }
   }

      Node A                                                           Node B
       | CoAP Request                                                   |
       |------------------------------------------------->| 
       | POST /6t/NegotiationSetting                               |
       | payload:                                                          |
       | CBOR({Opcode=RESERVESOFTCELL, RequireBW,      |
       | SlotframeID, TrackID, CandidateList})                   |
       |                                                                      |
       |                                                CoAP response   |
       |<-------------------------------------------------|
       |                                                payload: empty  |
       |                                                                       |
       | CoAP request                                                    |
       |------------------------------------------------->|
       | GET /6t/NegotiationResult                                   |
       |                                                                      |
       |                                                CoAP response   |
       |<-------------------------------------------------|
       |                         assume scheduling does not finish,| 
       |                         payload: empty                         |
       |                                                                       |
       |                                                                       |
       |                 when scheduling finsih, CoAP response   |
       |<-------------------------------------------------|
       |                          payload:                                 |
       |                         CBOR(NumOfCells, ResultedCells)  |
       |                                                                      |

The above process implies that 
1) node B will call internal softcell scheduler module to fill NegotiationResult and local CellList just after the NegotiationSetting is set. 
2) node A will call a internal module to fill local CellList with the payload of  GET response packet upon receiving it.

I'm not very sure if it works based on CoAP. Looking forward to your feedback.

Thanks
Qin  
 
On Friday, April 4, 2014 2:06 AM, Qin Wang <[email-masked]> wrote:
 
Hi Raghuram,

What do you think?

Thanks
Qin

Xavi, Qin,

-raghuram

Hi Qin, 

Xavi,

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 4 Apr 2014 09:36:26 +0200

Hi Qin,

I think that the CoAP interaction can be shortened not requiring 2 requests.

Node A                                                           Node B
       | CoAP Request                                                  |
       |------------------------------------------------->    |
       | POST /6t/NegotiationSetting                             |
       | payload:                                                          |
       | CBOR({Opcode=RESERVESOFTCELL, RequireBW,|
       | SlotframeID, TrackID, CandidateList})                |
       |
     |
       |                                                CoAP response   |
       |<-------------------------------------------------    |
       |                                                payload:           |
       |                         CBOR(NumOfCells, ResultedCells)|
       |
    |

Note that the response can be piggybacked in the ACK  if the computation
can be done fastly, if not the response can travel in a separate response
message.
See section 2.2 of coap draft
https://tools.ietf.org/html/draft-ietf-core-coap-18#section-2.2

what do you think?
X

2014-04-03 21:54 GMT+02:00 Qin Wang <[email-masked]>:

> Hi all,
>
> According to the above discussion, I try to express the exercise in YANG
> model and CoAP. For applying CoAP methods directly, the previously
> introduced resource SoftCellScheduler is split into two parts, i.e.
> NegotiationSetting and NegotiationResult,
>
>       Node A
> Node B
>        | payload:
>  |
>        |
>    |
>        |
>     |
>        |
>    |
>        |
>     |
>        |
>     |
>        |                          payload:
>   |
>        |
>    |
> 1) node B will call internal softcell scheduler module to fill
> NegotiationResult and local CellList just after the NegotiationSetting is
> set.
> 2) node A will call a internal module to fill local CellList with the
> payload of  GET response packet upon receiving it.
>
> I think it is good idea to put all access control policies within the CoAP
> parser. By calling 6top command READ.timesource, a node can know who its
> parent is.
>
> Considering employing POST to implement the softcell negotiation process,
> I wonder if it is possible to define more flexible control policy. It is
> because the two nodes in the softcell negotiation process are not
> necessarily parent and child. Can we define the access control as a
> function of nodes' relationship and resource. For example, for CellList,
> only parent can POST to its children; for SoftcellScheduler, arbitrary node
> can POST to its neighbor.
>
> What do you think?
>
> Thanks
> Qin
>
>
>  Another possible implementation strategy for access control is to have
>  an API such as "isParent(ip_addr *addr)".
>
>  Assuming the parser is passed the source ip/mac we will need when it
> gets called from the 6top layer, this will allow the CoAP to identify the
> access it must allow for this request.
>
>  This will allow all access control policies to be contained within the
> CoAP parser, instead of being sprinkled across CoAP and 6top.
>
>  -raghuram
>
> Cc: Thomas Watteyne <[email-masked]>, raghuram sudhaakar <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
>  I have another concern about using POST, i.e. access control. I'm not
> sure how we will do the access control, only allowing parents write
> children, or allowing arbitrary node write its neighbors but depending on
> different resource.
>
>  What do you think?
>
>  Thanks
>  Qin
>  that's a great exercise! I think that for the POST case the payload of
> the response can include the updated object, if we represent the POSTed
> object as having an empty CellList and after the update at the receiver
> side the CellList is filled. So the POST case is very similar to the GET
> case, but semantically makes more sense to POST (update) a resource.
>
>  what do you think?
> X
>
>
>  Take softcell create process as an example, and assume nodeB is a
> neighbor of nodeA. The following table includes (1) the negotiation process
> defined in current version of 6top sublayer, which consists of three steps;
> (2) implementation of the negotiation process with POST method; (3)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Apr 2014 08:50:03 -0400

Qin Wang <[email-masked]> wrote:
    > Considering employing POST to implement the softcell negotiation process, I
    > wonder if it is possible to define more flexible control policy. It is because
    > the two nodes in the softcell negotiation process are not necessarily parent
    > and child. Can we define the access control as a function of nodes'

What is their relationship if it isn't parent/child?  Are we talking two generations?

We are rapidly getting to the point where it appears that any node on the
mesh might want to adjust the schedule of any other node.    

I think that we can perhaps deal with authorization for nodes which are
directly connected. (I'd call that "zero hops", but maybe some would say "one hop")
If we go beyond that, then I think that we must have an authorization third
party, at which point, one might as well have a PCE.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Qin Wang <[email-masked]>
Date: Fri, 4 Apr 2014 06:59:00 -0700 (PDT)

Xavi,

I understand the piggybacked process. The reason I use POST and then GET, instead of only POST, is that I assume the negotiation process will work on two resources i.e. NegotiationSetting and NegotiationResoult, instead one, e.g SoftcellScheduler in the first email. The disadvantage to use both POST and GET is costing one more communication, but I think having two resources will be clearer logically and better fit the CoAP methods than having one resource. What do you think?

Thanks
Qin
On Friday, April 4, 2014 5:12 PM, Xavier Vilajosana <[email-masked]> wrote:
 
Hi Qin,

Node A                                                           Node B
       | CoAP Request                                                  |

Note that the response can be piggybacked in the ACK  if the computation can be done fastly, if not the response can travel in a separate response message. 
See section 2.2 of coap draft
https://tools.ietf.org/html/draft-ietf-core-coap-18#section-2.2

what do you think?
X

Hi all,

---

From: Qin Wang <[email-masked]>
Date: Fri, 4 Apr 2014 07:24:56 -0700 (PDT)

Hi Michael,

Unlike the process of assigning a hardcell in a chunk to a child by a parent, the softcell negotiation process will be conducted by a pair of nodes directly connected, and the node who initiates the softcell negotiation process (nodeA) can be any node. 

But, nodeA does not write its neighbor's (nodeB's) schedule directly, instead, nodeA only writes NeigotiationSetting of nodeB, which will trigger nodeB to schedule some cells and write its own schedule, i.e. CellList in nodeB's MIB. And then, after nodeA gets the information about the new scheduled cells from nodeB, nodeA will adjust its own schedule.

Make sense?

Thanks
Qin
On Friday, April 4, 2014 8:50 PM, Michael Richardson <[email-masked]> wrote:

Qin Wang <[email-masked]> wrote:
    > Considering employing POST to implement the softcell negotiation process, I
    > wonder if it is possible to define more flexible control policy. It is because
    > the two nodes in the softcell negotiation process are not necessarily parent
    > and child. Can we define the access control as a function of nodes'

---

From: Michael Richardson <[email-masked]>
Date: Fri, 04 Apr 2014 11:51:27 -0400

Qin Wang <[email-masked]> wrote:
    > But, nodeA does not write its neighbor's (nodeB's) schedule directly, instead,
    > nodeA only writes NeigotiationSetting of nodeB, which will trigger nodeB to
    > schedule some cells and write its own schedule, i.e. CellList in nodeB's MIB.
    > And then, after nodeA gets the information about the new scheduled cells from
    > nodeB, nodeA will adjust its own schedule.

okay, but nodeA still needs some kind of authorization into nodeB, just not,
in this case, a hardcell write permission.

---

From: Pat Kinney <[email-masked]>
Date: Fri, 4 Apr 2014 11:51:10 -0500

Shouldn't it be implicit that when a 6tisch node joins a 6tisch network it's authorizing neighboring nodes to negotiate cell scheduling with itself?

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On Apr 4, 2014, at 10:51 AM, Michael Richardson <[email-masked]> wrote:

---

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Apr 2014 15:29:54 -0400

Pat Kinney <[email-masked]> wrote:
    > Shouldn't it be implicit that when a 6tisch node joins a 6tisch network
    > it's authorizing neighboring nodes to negotiate cell scheduling with
    > itself? 

You tell me.  

1) how can a node that another node is a neighbour?   don't forget mobility,
   and don't forget about wormhole and sinkhole attacks.

2) given an industrial situation, with a series of installers who come and
   go, and who may not all be fully trusted by the plant operator,
   (I'm not making this up; see section 2 of rpl-industrial-applicability-02)
   is there some advantage to being able to program neighbour cells?

   Consider an installer that wants to skimp on those expensive high-gain
   antenna, powered relay/router nodes (the ones that require that they spend
   3 days pulling electrical power through the plant), could they achieve the
   specified deterministic performance by taking many more slots than they
   ought to have?

    > IEEE 802.15 WG vice chair, TG chair

I'm just leaving your credentials here, because I think you have more
connection to the people in the field than I do.   

Do you really trust EVERY SINGLE NODE in that link?
On the subnet?  
At the site?