Re: [6tisch] Link Options bitmap in 6P Cell format

Thomas Watteyne <thomas.watteyne@inria.fr> Fri, 07 October 2016 13:13 UTC

Return-Path: <thomas.watteyne@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D11B12958D for <6tisch@ietfa.amsl.com>; Fri, 7 Oct 2016 06:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.395
X-Spam-Level:
X-Spam-Status: No, score=-9.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnu9IaTM_DiI for <6tisch@ietfa.amsl.com>; Fri, 7 Oct 2016 06:13:06 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1CAE1295AB for <6tisch@ietf.org>; Fri, 7 Oct 2016 06:13:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.31,308,1473112800"; d="scan'208,217";a="239840736"
Received: from mail-wm0-f48.google.com ([74.125.82.48]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 07 Oct 2016 15:13:03 +0200
Received: by mail-wm0-f48.google.com with SMTP id f193so4889065wmg.0 for <6tisch@ietf.org>; Fri, 07 Oct 2016 06:13:03 -0700 (PDT)
X-Gm-Message-State: AA6/9Rn+PxonEdEUNmPSSsYOQz63+cLWN5T4VT4h6R3KW4+HoUjCb2SXpVm7We9XuoQoiIbgIoDp4W0QZ47Png==
X-Received: by 10.28.39.133 with SMTP id n127mr20711673wmn.6.1475845983818; Fri, 07 Oct 2016 06:13:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.179.19 with HTTP; Fri, 7 Oct 2016 06:12:43 -0700 (PDT)
In-Reply-To: <CAC9+vPgVjVfZK+3ic6E0A9PFbTAy2sU6js_GXfBiBOAxjPLjcw@mail.gmail.com>
References: <CAMsDxWQ0MhopcM_8rbDEsiM2=k5JpTG8x+x3LMcRH_Dw-vBw9Q@mail.gmail.com> <1294757112.10022353.1475678742266@mail.yahoo.com> <22517.5664.440871.727991@fireball.acr.fi> <459643762.4806735.1475681274441@mail.yahoo.com> <CAMsDxWQbUSr1iMk2EVnRymQARnDkhkiz+5RD2SzSQ9Pe_h1fWg@mail.gmail.com> <1949504800.1496286.1475766481831.JavaMail.root@llavaneres.uoc.es> <CAC9+vPgVjVfZK+3ic6E0A9PFbTAy2sU6js_GXfBiBOAxjPLjcw@mail.gmail.com>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Fri, 07 Oct 2016 15:12:43 +0200
X-Gmail-Original-Message-ID: <CADJ9OA8oLTLAMFwAOA8ShzT9M56d-U4V8RwkQwP-nAWef1-orw@mail.gmail.com>
Message-ID: <CADJ9OA8oLTLAMFwAOA8ShzT9M56d-U4V8RwkQwP-nAWef1-orw@mail.gmail.com>
To: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Content-Type: multipart/alternative; boundary="001a114e16129bdb21053e462b14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/iya1kr8tWpnbq2kBj3S01CboaMw>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Tero Kivinen <kivinen@iki.fi>, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Subject: Re: [6tisch] Link Options bitmap in 6P Cell format
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
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" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2016 13:13:09 -0000

All,

I have captured this discussion at
https://trac.tools.ietf.org/wg/6tisch/trac/ticket/46, and am preparing a
summary slide for the interim meeting. Let's discuss there an conclude.

Thomas

On Thu, Oct 6, 2016 at 9:36 PM, Xavi Vilajosana Guillen <xvilajosana@uoc.edu
> wrote:

> Dear Qin,
> answering to this:
>
> "Does it mean the LinkOption-like flag will associated with a cell,
> instead of a transaction? In another word, the LinkOptions-like flag will
> be part of 6P Cell Format with slotOffset and channelOffset. "
>
> XV> this is something we can decide. We either bind it to thel 6P Cell
> Format with slotOffset and channelOffset., hence using 1 extra byte for
> each cell or we associate the linkOption to the whole list of cells
> (assuming that all the requested cells will have the same "options"). This
> will safe bytes at the cost of less flexibility.
>
> what is your opinion here?
> X
>
>
>
> 2016-10-06 17:06 GMT+02:00 Qin Wang <qinwang6top@yahoo.com>:
>
>> Xavi,
>>
>> I agree LinkOptions-like field will bring more flexibility. (I say
>> LinkOptiions-like field because IEEE802.15.4e does not has the LinkOptions
>> anymore as Tero mentioned.)
>>
>> I have a further question. Does it mean the LinkOption-like flag will
>> associated with a cell, instead of a transaction? In another word, the
>> LinkOptions-like flag will be part of 6P Cell Format with slotOffset and
>> channelOffset.
>>
>> Thanks
>> Qin
>>
>>
>>
>> On Wednesday, October 5, 2016 10:54 PM, Xavier Vilajosana <
>> xvilajosana@eecs.berkeley.edu> wrote:
>>
>>
>> Hi Qin,
>>
>> the LinkOptions makes it more flexible for future uses (as it opens more
>> options). I see the priority field for example also interesting.
>>
>> I agree however that we use 5-extra bits per requested cell and that the
>> timekeeping and priority fields are not in the scope as of today. Maybe
>> even 8 if we leave some reserved bits as 15.4.
>>
>> thoughts?
>> X
>>
>>
>> 2016-10-05 17:27 GMT+02:00 Qin Wang <qinwang6top@yahoo.com>:
>>
>> Hi Tero,
>>
>> Thank you for the update.
>>
>> According to my understanding, the flag used in 6P is trying to define
>> the communication direction of scheduled cell(s). So, I wonder if 2 bits
>> flag is enough.
>>
>> Thanks
>> Qin
>>
>>
>> On Wednesday, October 5, 2016 11:03 AM, Tero Kivinen <kivinen@iki.fi>
>> wrote:
>>
>>
>> Qin Wang writes:
>> > In IEEE802.15.4e, LinkOptions is defined as follows.
>>
>> This was changed in the 802.15.4-2015, i.e., the MLME and he PIB no
>> longer specify bit numbers for those infrmation, they provide the same
>> information in separate parameters (TxLink, RxLink, SharedLink,
>> TimekeepngLink, PriorityLink), or spearate PIB entries (macTxType,
>> macRxType, macLinkTimekeeping and macPriorityType).
>>
>> The TSCH Slotframe and Link IE do define field called Link Options and
>> splits it to bits as follows:
>>
>> +---------+---------+--------- ----+-------------+----------+ ----------+
>> | Bits: 0 |    1  |      2      |      3      |    4    |  5-7    |
>> +---------+---------+--------- ----+-------------+----------+ ----------+
>> | TX Link | RX Link | Shared Link | Timekeeping | Priority | Reserved |
>> +---------+---------+--------- ----+-------------+----------+ ----------+
>>         Figure 7-54 --Link Options field format
>>
>> Note, that there is new bit for Priority in there too. And as normally
>> this is LSB first so care should be taken when written to the IETF
>> draft...
>>
>>
>> > Is it what you are going to use? Then, another way is to use two bits to
>> > express TX/RX/Share. I'm not sure which way is better than another.
>>
>>
>> Two bits is not enough to define all different link types. The text in
>> 802.15.4-2015 defining the bits is:
>>
>>     The TX Link field shall be set to one if it is a TX link and
>>     shall be set to zero otherwise.
>>
>>     TX Shared links, indicated by the TX link field and Shared
>>     Link field both set to one, may be used by a joining device to
>>     send an Association Request command or higher layer message to
>>     the advertising device.
>>
>>     The RX Link field shall be set to one if the link is an RX
>>     link and shall be set to zero otherwise. RX links are used by
>>     a joining device to receive an Association Response command or
>>     higher layer message from an advertising device.
>>
>>     The Shared Link field shall be set to one if the link is a
>>     shared link and shall be set to zero otherwise. A shared link
>>     is one that uses contention to access the medium.
>>
>>     A link may be used as both a TX shared link and RX link.
>>
>>     The Timekeeping field shall be set to one if the link is to be
>>     used for clock synchronization and shall be set to zero
>>     otherwise. RX links shall have the Timekeeping field set to
>>     one.
>>
>>     The Priority field shall be set to one if the link is a
>>     priority channel access, as defined in 6.2.5.2, and shall be
>>     set to zero otherwise.
>> --
>> kivinen@iki.fi
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> Dr. Xavier Vilajosana Guillén­
> Research Professor
> Wireless Networks Research Group
> Internet Interdisciplinary Institute (IN3)
> Universitat Oberta de Catalunya­
>
> +34 646 633 681| xvilajosana@uoc.edu­ | Skype­: xvilajosana
> http://xvilajosana.org
> http://wine.rdi.uoc.edu/
>
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 5. Edifici B3
> 08860 Castelldefels (Barcelona)
>
>
>
> ­
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________