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

Tengfei Chang <> Thu, 03 March 2016 17:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF3271B2AC1 for <>; Thu, 3 Mar 2016 09:47:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.501
X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_DBL_ABUSE_BOTCC=2.5] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OHZN3_nxqBnt for <>; Thu, 3 Mar 2016 09:47:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E66A21B2ABE for <>; Thu, 3 Mar 2016 09:47:53 -0800 (PST)
Received: by with SMTP id b72so21287164ywe.0 for <>; Thu, 03 Mar 2016 09:47:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=bcB1J5pAaANSv8fMSpSZvvIIapbDtouzJIhgZrmEYHk=; b=i2WBaHfTRNE86gHPSQ9SDdvOKywHekxETaWaVJ3523Ewd6g1I30U6QJu/ZAfwAn1Jq Ihnu19xn8eKpcw/RQM/0UudaHVetfO8hD6aMnfB6zsO4VpvIbdtCibxK9zoYalm9/LwZ UJZ9/paPzzzCBcrBgrYiEgAv7+kBoTRR55uA9bVBVh/QUjb9qdNaXBZ+fNYgKvCB2YnE 84ziIjWfy/Y/O2/KEp780SNEQt0O7wlAsC2v+MOb6UUgZ6rqE9Em8mVbLyfuouaH+anr nuxYwzxaWhtFQy8i6M5x6UkMp8sxBs2l2HS5w2rdK7NOwqK1Jb4Kv7sOy2f0k2T3TnVE CfIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bcB1J5pAaANSv8fMSpSZvvIIapbDtouzJIhgZrmEYHk=; b=Xe2Vz5s7pZWAggfMTgBhaky7tZRpVWnzWHBSNCH8IC6MRM8Gk8KpdSAxTQQvxK3nub 3TRxRlihyUq0jKbTGufpJjxe+fv9mU6CH+9xaetqC2m2evsCyhcbHlNXpmc/Ki/BVjE/ FnXHgqIXUGTykm0YCDQpSWSi0GL1ZB5K349j92Q6nln0BRj8HEkfCH6beUeU2pAB/RNx DGbj0hzwuS80Ll+t3+HKUBD/w7IilMpeN3m/m3bjoYOYrfAxbudFRqwXYyAKfx3hEsJH x3FL7k5Oqyd0sPcSKXYRCOdz7IwheomfMDhTuFWnexwdDsqHBv/gYMqpuaBqxRb0LbnG f8BQ==
X-Gm-Message-State: AD7BkJKmYKCOAKwnjdVSYuvYGL+97Y7DIWx4EbljFPDbHW2pOPhwTaRkCl48A/mzJsdm5uHUcN7ZYzKD/7q5Rw==
MIME-Version: 1.0
X-Received: by with SMTP id x5mr1918924ywd.229.1457027273211; Thu, 03 Mar 2016 09:47:53 -0800 (PST)
Received: by with HTTP; Thu, 3 Mar 2016 09:47:53 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Thu, 03 Mar 2016 18:47:53 +0100
Message-ID: <>
From: Tengfei Chang <>
To: "Prof. Diego Dujovne" <>
Content-Type: multipart/alternative; boundary="001a114fc1540c6217052d28995e"
Archived-At: <>
Cc: "" <>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Mar 2016 17:47:55 -0000

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
   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
   2. when cells are selected or no cell is available, set status to
   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?


On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <> 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
> --
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> (56 2) 676 8125
> _______________________________________________
> 6tisch mailing list