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

Xavi Vilajosana Guillen <xvilajosana@uoc.edu> Thu, 06 October 2016 19:36 UTC

Return-Path: <xvilajosana@uoc.edu>
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 971CF12940D for <6tisch@ietfa.amsl.com>; Thu, 6 Oct 2016 12:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu
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 ZmIpOXyAMwQn for <6tisch@ietfa.amsl.com>; Thu, 6 Oct 2016 12:36:35 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8C6127071 for <6tisch@ietf.org>; Thu, 6 Oct 2016 12:36:34 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id l13so1647710itl.1 for <6tisch@ietf.org>; Thu, 06 Oct 2016 12:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mRXOLGV6LJtpf9yZSzi21RRrMIhVLnPD78fEKTxkQ7Q=; b=Db7h0434qjyrS+FiAF8bmZLfdckDTPfzXw/9qSqz2UmW2Nm5d8gLe0DY0BpqCXCOTo p7+HePmOvaJbxlt2/fWQb9I5MgseSU0nAW5d2MMEvXBApxyZEpg/CsWFRsCYOPxXxQYg gV0xREnoPkskG0eTzJbwLQao4D7Wwt/R2bdyU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mRXOLGV6LJtpf9yZSzi21RRrMIhVLnPD78fEKTxkQ7Q=; b=WOAmlpot66KGgfnu9aNazLkusjOw+BkzzvbZOhD2l6TjxcjHJplOWz7Wt4wrOWaKC7 j7o622f/TaB0Usq+MdMeux4ZwAE23V9AdfH9gMISzdDl4MvOe3IOllHqqE9OpFpm5Mdx fcsAPf0/4ltIY5tQq1g0AH/HxibCzmbxGXAXJ7Gs1NMwJgx0v0lnGJ6zYQxnwLmfr1Ma ECPMTccssTuplsJdGcwz7jKopRATJry19I63lGBsIIhLvPTL7Lh4RHUI8Fxnw6I8ABIU giARpj0mzLyJv1CgAYYfoKv2hyqxcvzbYzXb3KPeuJ7eYxyOPTwa8HYtXw3qiBqsT5zz udZQ==
X-Gm-Message-State: AA6/9RnVgB5qsCBvKUIz4/DRW+E5T0yvBem72grniKrbIErXCcljTXjCOvazCuma+ybFUZFZqhZHfSWpy4VEdqHj
X-Received: by 10.36.253.200 with SMTP id m191mr14418336ith.35.1475782594028; Thu, 06 Oct 2016 12:36:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.152.149 with HTTP; Thu, 6 Oct 2016 12:36:33 -0700 (PDT)
In-Reply-To: <1949504800.1496286.1475766481831.JavaMail.root@llavaneres.uoc.es>
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>
From: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Date: Thu, 06 Oct 2016 21:36:33 +0200
Message-ID: <CAC9+vPgVjVfZK+3ic6E0A9PFbTAy2sU6js_GXfBiBOAxjPLjcw@mail.gmail.com>
To: Qin Wang <qinwang6top@yahoo.com>
Content-Type: multipart/alternative; boundary="94eb2c0361e248c46e053e376927"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/KhAM-qnWwiX31GTYOFQ2UDAMnY4>
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: Thu, 06 Oct 2016 19:36:37 -0000

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)



­