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 _______________________________________
- [6tisch] Link Options bitmap in 6P Cell format Xavier Vilajosana
- Re: [6tisch] Link Options bitmap in 6P Cell format Qin Wang
- Re: [6tisch] Link Options bitmap in 6P Cell format Tero Kivinen
- Re: [6tisch] Link Options bitmap in 6P Cell format Qin Wang
- Re: [6tisch] Link Options bitmap in 6P Cell format Xavier Vilajosana
- Re: [6tisch] Link Options bitmap in 6P Cell format Qin Wang
- Re: [6tisch] Link Options bitmap in 6P Cell format Xavi Vilajosana Guillen
- Re: [6tisch] Link Options bitmap in 6P Cell format Thomas Watteyne