[6tisch] WG Action: Rechartered IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)

[The IESG]

The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG in the Internet
Area of the IETF has been rechartered. For additional information, please
contact the Area Directors or the WG Chairs.

IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
---
Current status: Active WG

Chairs:
  Pascal Thubert 
  Thomas Watteyne 

Assigned Area Director:
  Brian Haberman 

Internet Area Directors:
  Brian Haberman 
  Terry Manderson 
 
Mailing list:
  Address: 6tisch@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/6tisch
  Archive: https://mailarchive.ietf.org/arch/browse/6tisch/

Charter: https://datatracker.ietf.org/doc/charter-ietf-6tisch/

6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".

Background/Introduction:


Low-power and Lossy Networks (LLNs) interconnect a possibly large number
of resource-constrained nodes to form a wireless mesh network. The
6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at
various layers of the protocol stack, including an IPv6 adaptation
layer, a routing protocol and a web transfer protocol. This protocol
stack has been used with IEEE802.15.4 low-power radios.

The Timeslotted Channel Hopping (TSCH) mode was introduced in 2012 as an
amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4
standard. TSCH is the emerging standard for industrial automation and
process control LLNs, with a direct inheritance from WirelessHART and
ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the
further adoption of IPv6 in industrial standards and the convergence of
Operational Technology (OT) with Information Technology (IT).

The nodes in a IEEE802.15.4 TSCH network communicate by following a
Time Division Multiple Access (TDMA) schedule. A timeslot in this
schedule provides a unit of bandwidth that is allocated for
communication between neighbor nodes. The allocation can be programmed
such that the predictable transmission pattern matches the traffic. This
avoids idle listening, and extends battery lifetime for constrained
nodes. Channel-hopping improves reliability in the presence of narrow-
band interference and multi-path fading.

These techniques enable a new range of use cases for LLNs, including:
- Control loops in a wireless process control network, in which high
reliability and a fully deterministic behavior are required.
- Service Provider networks transporting data from different independent
clients, and for which an operator needs flow isolation and traffic
shaping.
- Networks comprising energy harvesting nodes, which require an
extremely low and predictable average power consumption.

IEEE802.15.4 only defines the link-layer mechanisms. It does not define
how the network communication schedule is built and matched to the
traffic requirements of the network.

Description of Working Group:
-

The Working Group will focus on enabling IPv6 over the TSCH mode of the
IEEE802.15.4 standard. The extent of the problem space for the WG is
one or more LLNs, possibly federated through a common backbone link
via one or more LLN Border Routers (LBRs). The WG will rely on, and if
necessary extend, existing mechanisms for authenticating LBRs.

Initially, the WG has limited its scope to distributed routing over a
static schedule using the Routing Protocol for LLNs (RPL) on the 
resulting network. This new charter allows for the dynamic allocation of 
cells and their exchange between adjacent peers to accommodate the 
available bandwidth to the variations of throughput in IP traffic.

The WG will continue working on securing the join process and making 
that fit within the constraints of high latency, low throughput and 
small frame sizes that characterize IEEE802.15.4 TSCH.

Additionally, IEEE802.15.4 TSCH being a deterministic MAC, it is 
envisioned that 6TiSCH will benefit from the work of DetNet WG to 
establish the so-called deterministic tracks. The group will define the 
objects and methods that need to be configured, and provide the 
associated requirements to DetNet.

The WG will interface with other appropriate groups in the IETF
Internet, Operations and Management, Routing and Security areas.

Work Items:
---

The group will:

- Produce a specification of the 6top sublayer that describes the 
protocol for neighbor nodes to negotiate adding/removing cells. This 
work will leverage cross participation from IEEE members including the 
IEEE 6TiSCH Interest Group (IG 6T) to define protocol elements and 
associated frame formats.

- Produce a specification for a default 6top Scheduling Function 
including the policy to enable distributed dynamic scheduling of 
timeslots for IP traffic. This may include the capability for nodes to 
appropriate chunks of the matrix without starving, or interfering with 
other 6TiSCH nodes. This particular work will focus on IP traffic since 
the work on tracks is not yet adva

Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

[Pascal Thubert (pthubert)]

Hello Tengfei

But if the ack is sent and not received then the parent does not allocate the 
cells and the child uses them...

And if a transaction hangs in the middle - say the child dies or is out of 
reach - then we'd have a deadlock.

No, as Xavi said we must plan for parallel transaction and roll back on error 
and time out.

Cheers,

Pascal

Le 4 mars 2016 ? 14:06, Tengfei Chang 
mailto:tengfei.ch...@gmail.com>> a ?crit :

Hi Pascal,

The parent should allocate cells only when it received the ACK of the response. 
If no ACK received, no cell will be allocated. This can be handled by state 
machine, though it doesn't support concurrency.

Tengfei

On Fri, Mar 4, 2016 at 12:37 PM, Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:
One issue with that, Tengfei, is if the 6p response is sent but not received.

The client will retry the request for the same need of bandwidth but will get a 
new set of cells.
The parent that allocates cells must correlate them with a request ID (token, 
sequence, whatever) in case that request is retried so as to respond with the 
same cells.

Take care,

Pascal

From: 6tisch [mailto:6tisch-boun...@ietf.org] 
On Behalf Of Tengfei Chang
Sent: jeudi 3 mars 2016 18:48
To: Prof. Diego Dujovne 
mailto:diego.dujo...@mail.udp.cl>>
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Hello Diego,

For the Token to identify the transaction, personally, if the idea is to 
identify a request and a response with a token,  it can be replaced by 
implementing a status machine, in which the status is able to identify the 
status of 6P transaction.

Here is a rough example which is able to explain how Status Machine works:

Initially the status of 6P can be set as 6P_IDLE.

For a mote sending 6p request:


  1.   after the 6p request is ready to be sent which contains the candidate 
cell, the status turns to 6P_REQUEST_INIT
  2.  after the request is sent, the status turns to 6P_REQUEST_WAITING_RESPONSE
  3.  after received the response from parent, mote sends ACK back and 
add/delete cell in schedule. The status turns to 6P_IDLE
For a mote received 6p request:

  1.  after receiving the 6p request, the mote turns status to 
6P_RECEIVED_REQUEST
  2.  when cells are selected or no cell is available, set status to 
6P_RESPONSE_TOBESENT
  3.  after sending the response and get the ACK, mote will add/delete cells in 
schedule and set status back to 6P_IDLE
If the mote will not process the next 6P request if the status is correct. Even 
if there are some issue that the mote stuck at one status, the timeout will 
reset the status to 6P_IDLE.

With this, one byte can be save, though it's not that much.
What do you think?

Tengfei

On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne 
mailto:diego.dujo...@mail.udp.cl>> wrote:
Dear all,
In order to continue the discussion we left
unfinished at the Interim meeting in March 26th, I
will open a number of threads to take action on several
pending issues for the drafts:

draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol)
draft-dujovne-6tisch-6top-sf0-00
- Regarding the use of a Token to identify transactions on
the 6top protocol, there was a proposal on the call to add
an 8-bit field to the packet header.
Do you agree with this solution?
Regards,
  Diego Dujovne

--
DIEGO DUJOVNE
Acad?mico Escuela de Ingenier?a en Inform?tica y Telecomunicaciones
Facultad de Ingenier?a UDP
www.ingenieria.udp.cl
(56 2) 676 8125

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

[Tengfei Chang]

Hi Pascal,

The parent should allocate cells only when it received the ACK of the
response. If no ACK received, no cell will be allocated. This can be
handled by state machine, though it doesn't support concurrency.

Tengfei

On Fri, Mar 4, 2016 at 12:37 PM, Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:

> One issue with that, Tengfei, is if the 6p response is sent but not
> received.
>
>
>
> The client will retry the request for the same need of bandwidth but will
> get a new set of cells.
>
> The parent that allocates cells must correlate them with a request ID
> (token, sequence, whatever) in case that request is retried so as to
> respond with the same cells.
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Tengfei
> Chang
> *Sent:* jeudi 3 mars 2016 18:48
> *To:* Prof. Diego Dujovne 
> *Cc:* 6tisch@ietf.org
> *Subject:* Re: [6tisch] 6P and Sf0 issue: Token to identify transactions
> in 6P
>
>
>
> Hello Diego,
>
>
>
> For the Token to identify the transaction, personally, if * the idea is
> to identify a request and a response with a token*,  it can be replaced
> by implementing a status machine, in which the status is able to identify
> the status of 6P transaction.
>
>
>
> Here is a rough example which is able to explain how Status Machine works:
>
>
>
> *Initially* the status of 6P can be set as 6P_IDLE.
>
>
>
> *For a mote sending 6p request:*
>
>
>
>1.  after the 6p request is ready to be sent which contains the
>candidate cell, the status turns to 6P_REQUEST_INIT
>2. after the request is sent, the status turns to
>6P_REQUEST_WAITING_RESPONSE
>3. after received the response from parent, mote sends ACK back and
>add/delete cell in schedule. The status turns to 6P_IDLE
>
> *For a mote received 6p request:*
>
>1. after receiving the 6p request, the mote turns status to
>6P_RECEIVED_REQUEST
>2. when cells are selected or no cell is available, set status to
>6P_RESPONSE_TOBESENT
>3. after sending the response and get the ACK, mote will add/delete
>cells in schedule and set status back to 6P_IDLE
>
> If the mote will not process the next 6P request if the status is correct.
> Even if there are some issue that the mote stuck at one status, the timeout
> will reset the status to 6P_IDLE.
>
>
>
> With this, one byte can be save, though it's not that much.
>
> What do you think?
>
>
>
> Tengfei
>
>
>
> On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
> Dear all,
> In order to continue the discussion we left
> unfinished at the Interim meeting in March 26th, I
> will open a number of threads to take action on several
> pending issues for the drafts:
>
> draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol)
> draft-dujovne-6tisch-6top-sf0-00
>
> - Regarding the use of a Token to identify transactions on
>
> the 6top protocol, there was a proposal on the call to add
>
> an 8-bit field to the packet header.
>
> Do you agree with this solution?
>
> Regards,
>
>   Diego Dujovne
>
>
>
> --
>
> DIEGO DUJOVNE
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

[Lijo Thomas]

Hi Diego,

 

 

Do we really require 3 transactions for 6P operations as mentioned.  

 

The second transaction from the parent contains all the required information  
for the task.

 

In case the 2nd packet is lost, the parent will schedule a RX link which will 
be unutilized for the time being and can be reallocated depending on the 
scheduling function.

 

But if the 3rd transaction is lost, the client will allocate the TX link  and 
will start transmitting packets.

 

So can we avoid the ACK packet(3rd transaction) from the client, or is there 
any added benefit. 

 

 

Thanks & Regards,

Lijo Thomas 

 

 

 

 

 

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: 03 March 2016 21:11
To: 6tisch@ietf.org
Subject: [6tisch] 6P and Sf0 issue: Piggybacking data packet with IE 
confirmation

 

Dear all,

Given that there is parent preference in cell
selection, a child-initiated transaction triggers a three-step

exchange:

1- Child sends request to Parent with whitelist/blacklist of slotoffsets

2- Parent selects cells

3- Child acknowledges and finishes the transaction

The main idea is to enable an optional Piggybacking of the IE on a

data packet to reduce the number of transmitted packets, but there

are latency concerns when the (data) traffic is low.

Is it worth to enable this option given the added complexity?

Regards,

Diego Dujovne


-- 

DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl  
(56 2) 676 8125


---
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
---

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

[Pascal Thubert (pthubert)]

One issue with that, Tengfei, is if the 6p response is sent but not received.

The client will retry the request for the same need of bandwidth but will get a 
new set of cells.
The parent that allocates cells must correlate them with a request ID (token, 
sequence, whatever) in case that request is retried so as to respond with the 
same cells.

Take care,

Pascal

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Tengfei Chang
Sent: jeudi 3 mars 2016 18:48
To: Prof. Diego Dujovne 
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Hello Diego,

For the Token to identify the transaction, personally, if the idea is to 
identify a request and a response with a token,  it can be replaced by 
implementing a status machine, in which the status is able to identify the 
status of 6P transaction.

Here is a rough example which is able to explain how Status Machine works:

Initially the status of 6P can be set as 6P_IDLE.

For a mote sending 6p request:


  1.   after the 6p request is ready to be sent which contains the candidate 
cell, the status turns to 6P_REQUEST_INIT
  2.  after the request is sent, the status turns to 6P_REQUEST_WAITING_RESPONSE
  3.  after received the response from parent, mote sends ACK back and 
add/delete cell in schedule. The status turns to 6P_IDLE
For a mote received 6p request:

  1.  after receiving the 6p request, the mote turns status to 
6P_RECEIVED_REQUEST
  2.  when cells are selected or no cell is available, set status to 
6P_RESPONSE_TOBESENT
  3.  after sending the response and get the ACK, mote will add/delete cells in 
schedule and set status back to 6P_IDLE
If the mote will not process the next 6P request if the status is correct. Even 
if there are some issue that the mote stuck at one status, the timeout will 
reset the status to 6P_IDLE.

With this, one byte can be save, though it's not that much.
What do you think?

Tengfei

On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne 
mailto:diego.dujo...@mail.udp.cl>> wrote:
Dear all,
In order to continue the discussion we left
unfinished at the Interim meeting in March 26th, I
will open a number of threads to take action on several
pending issues for the drafts:

draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol)
draft-dujovne-6tisch-6top-sf0-00
- Regarding the use of a Token to identify transactions on
the 6top protocol, there was a proposal on the call to add
an 8-bit field to the packet header.
Do you agree with this solution?
Regards,
  Diego Dujovne

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: Statistics for SFs and Relocation

[Pascal Thubert (pthubert)]

I’d support that, Diego

If the visible operation of the device depends on it and that influences the 
interoperation, it is good to document a base way of doing things.

Cheers,

Pascal

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 3 mars 2016 20:26
To: 6tisch@ietf.org
Subject: [6tisch] 6P and Sf0 issue: Statistics for SFs and Relocation

Dear all,
   Given the requirements to build SFs exposed
in the 6tisch sublayer draft, there is no specification
on how to obtain the statistics and calculate and build
the metrics used to decide when to add/delete/relocate
cells. The draft asks only for the set of rules.
  SF0 defines an algorithm using specific values
as thresholds and rules for adding/removing cells and
uses PDR and a simple decision rule to decide which
cell to relocate.  However, this may not be the case
for the other (possibly more complex) SFs, where
metrics based on statistics could be included.
   Shall we include a section on the description
of how to calculate the specific statistics used on each
SF, or just leave this out of scope to the implementer?
My point of view is that statistics should be specified
in order to be able to interoperate between different
implementations of the same SF.
What do you think?
Thank you,
  Diego Dujovne


--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot

[Pascal Thubert (pthubert)]

Hello Diego:

One suggestion would be that when a node attempts to join, the parent 
immediately grants a set of cells for the join process from a limited pool (to 
avoid DDOS). These cells are to be released at the end of the join and are 
there to boost the bandwidth for that critical phase.

Cheers,

Pascal

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 3 mars 2016 17:12
To: 6tisch@ietf.org
Subject: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot

Dear all,
Although it was discussed, there is no specification
on the 6top behaviour at boot. The discussion point here is if the
6top messages shall be transmitted on minimal cells until
the slotframe 1 (SFR1) has been populated enough to support
the transactions.
  - The use of minimal is optional. In case minimal is used,
the decision on when to switch is out of scope?
  - In case minimal is not used, shall we specify another
mechanism to enable 6top to transmit messages?
Thanks!
Regards,
 Diego Dujovne

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: IANA IDs

[Pascal Thubert (pthubert)]

Hello Diego:

You need a IANA section where you detail which registries you create and which 
you add to.
Then you need to enumerate the entries that you need, as you do below.

You may suggest values to help interop till you make RFC, but the IANA will 
have the final word and implementations may need to be updated.

In this particular case, we have discussed where the IE space comes from but I 
have not seen a final conclusion on that. In particular (quoting Thomas in the 
attached mail) we have on the table “Choice 2, the ID is allocated to IETF via 
IANA. There is a defined process to obtain a Payload Group ID 
(http://www.ieee802.org/15/ANA.html), it basically starts with a formal request 
from an IANA officer.  There are only 8 addresses left before going onto 
extended addresses, so we really need to make sure that each of the 8 addresses 
will be properly used.”

If we are sure we’ll need the ID regardless of this particular draft, then we 
may issue a short draft to request it from IANA. As Thomas indicated, we need a 
very solid justification. It would be good to discuss this at the interim next 
Friday to prepare for any request / question to the 6TiSHC SG or WG15 who are 
meeting in Macao the week after.

CC’ing Brian in case I missed something?

Cheers,

Pascal

From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 3 mars 2016 17:54
To: 6tisch@ietf.org
Subject: [6tisch] 6P and Sf0 issue: IANA IDs

Dear 6tisch chairs,
I would like to know which are the steps
to request IDs to IANA, since we need at least the following
ones:

IANA_IETF_IE_GROUP_ID
IANA_6TOP_SUBIE_ID
IANA_6TOP_6P_VERSION
6P command identifiers
6P Return Codes
IANA_SFID_SF0
Are they independent of the draft/RFC status? Do we have
to wait until the drafts get into the standardization track?

Regards,
   Diego Dujovne



--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
--- Begin Message ---
Pat,
I suggest we discuss this at the meeting this Friday. I will start a thread on 
the ML. OK for me to copy-paste the following:

The best way to determine which of these alternatives to use is to define what 
is required of the IE and how is it used:


Choice 1, the vendor specific ID is already defined in the standard and needs 
no further action from 6tisch.  It uses the Payload IE Group ID = 0x2 followed 
by 3 octets of the Vendor’s OUI.  Two options here are to request an OUI from 
the IEEE RAC, or request a company ID from the IEEE RAC.  Regardless, the 
vendor specific ID adds 3 octets to the IE, which is not a problem if the IE is 
seldom used, such as configuring the network.


Choice 2, the ID is allocated to IETF via IANA. There is a defined process to 
obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html), it basically 
starts with a formal request from an IANA officer.  There are only 8 addresses 
left before going onto extended addresses, so we really need to make sure that 
each of the 8 addresses will be properly used.


Choice 3, the ESDU IE is meant to send a message to another node, it has no 
inherent formatting, the other node must already understand how to use the 
information.


If the 6tisch group chooses choice 2, we’ll need a request from IANA.

Thomas

On Fri, Jan 29, 2016 at 1:48 AM, 
pat.kin...@kinneyconsultingllc.com 
mailto:pat.kin...@kinneyconsultingllc.com>> 
wrote:


   Thanks for your reply Thomas;

   Firstly, as far as the formatting goes, it would be good for the group to 
entertain any other format.  If there are no other formats proposed, then the 
recommended one is the de facto format.  If another format is proposed then the 
WG should agree on a method to decide.

   Secondly, for a unique Payload IE Group ID to be used by 6tisch, there are 
at least three alternatives: 1) use the vendor specific ID stated in the 
802.15.4 standard, 2) request a Payload IE to be assigned to IETF via IANA, and 
3) use the Encapsulated Service Data Unit (ESDU) IE ID stated in the 802.15.4 
standard.

   The best way to determine which of these alternatives to use is to define 
what is required of the IE and how is it used:

   Choice 1, the vendor specific ID is already defined in the standard and 
needs no further action from 6tisch.  It uses the Payload IE Group ID = 0x2 
followed by 3 octets of the Vendor’s OUI.  Two options here are to request an 
OUI from the IEEE RAC, or request a company ID from the IEEE RAC.  Regardless, 
the vendor specific ID adds 3 octets to the IE, which is not a problem if the 
IE is seldom used, such as configuring the network.

   Choice 2, the ID is allocated to IETF via IANA. There is a defined process 
to obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html), it basically 
starts with a formal request from an 

Re: [6tisch] 6P and Sf0 issue: Examples of error handling

[Tengfei Chang]

Hello Diego,

*For IANA_6TOP_CMD_ROLLBACK command: *

I think I understand what you are trying to solve. But using
IANA_6TOP_CMD_ROLLBACK
has another issue: how to decide when to send the command. I think this is
the same question for setting the value of 6P_TIMEOUT.
Also if a transaction timeout because of bad link quality or lost
connection, sending another packet is not a good idea.

*For Retry handling:*

First, I think whether retry or not is a decision made by scheduling
function. For 6P, it just forwards this message to upper layer (such as SF0)

If retries are required, I think it makes sense that retrying within a
transaction.

What do you think?

Tengfei

On Thu, Mar 3, 2016 at 9:41 PM, Prof. Diego Dujovne <
diego.dujo...@mail.udp.cl> wrote:

> Dear all,
>One of the sections I would like to add to
> the SF0 draft is the examples of error handling.
>
> One example could be Timeout handling:
> When a transaction times out, either a packet is lost,
> the destination node lost connectivity or it is too busy
> to answer on time.
> Consequence: The transaction, in any stage, should
> be rolled back by both ends.
> Here, both nodes are expected to Timeout.
> Section 3.6.2 of the sublayer draft "Aborting a
> 6P transaction", cannot be used, since in this case
> there is no response.
> I propose to issue a rollback command such as
> "IANA_6TOP_CMD_ROLLBACK" to the destination
> node using the same token from the original transaction,
> and do not wait for an answer.
> This enables the source node to try a new transaction
> before the destination node times out, thus reducing
> delay.
>
> Would you agree in adding this command to reduce
> delay?
>
> Another issue should be Retry handling, in case of
> timeout.
> Do we allow retries within a transaction?
> If we allow retries, the maximum number of retries before
> considering a transaction failed should be configured on
> the SF.
>
> Thank you.
> Regards,
>
> Diego Dujovne
>
>
> --
> DIEGO DUJOVNE
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

[Tengfei Chang]

Hi Xavi,

Thanks for explanation! It makes sense for me.

Xavi, Diego, All,

Does the token indicates the ID of one transaction? How this 8-bits value
changes during a transaction/multiple transaction? It would be helpful if
there is some martial showing how the token works with 6p. Let me know if
there is also a discussion somewhere which I can trace. Thanks!

Tengfei

On Thu, Mar 3, 2016 at 8:23 PM, Xavier Vilajosana <
xvilajos...@eecs.berkeley.edu> wrote:

> Hi Tengfei,
>
> if we want (now or in the future) to support asynchronous responses (such
> as the piggybacking case or if we want to aggregate confirmations) then the
> token is handy. If we think that this mechanism will always be synchronous
> and that concurrency will not be allowed then the state machine works.
>
> my 2 cents :)
> X
>
>
> 2016-03-03 18:47 GMT+01:00 Tengfei Chang :
>
>> Hello Diego,
>>
>> For the Token to identify the transaction, personally, if *the idea is
>> to identify a request and a response with a token*,  it can be replaced
>> by implementing a status machine, in which the status is able to identify
>> the status of 6P transaction.
>>
>> Here is a rough example which is able to explain how Status Machine works:
>>
>> *Initially* the status of 6P can be set as 6P_IDLE.
>>
>> *For a mote sending 6p request:*
>>
>>
>>1.  after the 6p request is ready to be sent which contains the
>>candidate cell, the status turns to 6P_REQUEST_INIT
>>2. after the request is sent, the status turns to
>>6P_REQUEST_WAITING_RESPONSE
>>3. after received the response from parent, mote sends ACK back and
>>add/delete cell in schedule. The status turns to 6P_IDLE
>>
>> *For a mote received 6p request:*
>>
>>1. after receiving the 6p request, the mote turns status to
>>6P_RECEIVED_REQUEST
>>2. when cells are selected or no cell is available, set status to
>>6P_RESPONSE_TOBESENT
>>3. after sending the response and get the ACK, mote will add/delete
>>cells in schedule and set status back to 6P_IDLE
>>
>> If the mote will not process the next 6P request if the status is
>> correct. Even if there are some issue that the mote stuck at one status,
>> the timeout will reset the status to 6P_IDLE.
>>
>> With this, one byte can be save, though it's not that much.
>> What do you think?
>>
>> Tengfei
>>
>> On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <
>> diego.dujo...@mail.udp.cl> wrote:
>>
>>> Dear all,
>>> In order to continue the discussion we left
>>> unfinished at the Interim meeting in March 26th, I
>>> will open a number of threads to take action on several
>>> pending issues for the drafts:
>>>
>>> draft-wang-6tisch-6top-sublayer-04 (which will be renamed to
>>> 6top-protocol)
>>> draft-dujovne-6tisch-6top-sf0-00
>>>
>>> - Regarding the use of a Token to identify transactions on
>>> the 6top protocol, there was a proposal on the call to add
>>> an 8-bit field to the packet header.
>>>
>>> Do you agree with this solution?
>>>
>>> Regards,
>>>
>>>   Diego Dujovne
>>>
>>> --
>>> DIEGO DUJOVNE
>>> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
>>> Facultad de Ingeniería UDP
>>> www.ingenieria.udp.cl
>>> (56 2) 676 8125
>>>
>>> ___
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch