Re: [6tisch] 6top-interface-04

Qin Wang <qinwang6top@yahoo.com> Wed, 30 September 2015 20:00 UTC

Return-Path: <qinwang6top@yahoo.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0E31A8A10 for <6tisch@ietfa.amsl.com>; Wed, 30 Sep 2015 13:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.709
X-Spam-Level:
X-Spam-Status: No, score=-2.709 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 4DToaPjB6pdn for <6tisch@ietfa.amsl.com>; Wed, 30 Sep 2015 13:00:11 -0700 (PDT)
Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E77E1A8987 for <6tisch@ietf.org>; Wed, 30 Sep 2015 13:00:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1443643210; bh=Te/hpOgEak8JMYNK+jqbVGet6+xwL1h4rPv8qiDBQsk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=qX7zULuLpsV/4RASXho1DpBwoo6puSWI1SvyNt21bEyV8lZSevB1+5VBPqYRD4+nXiq+1rBfdWw2dwvhB4JcIvvmas20eB0fCTshCP6xiY8gkDgiiWDX33GZxw4klxldkMXziUv5D9e6aah/deeIvPdqBiJM/HK9NG+aPc9c66fZbnV1ePEa3VTgjuIUAaK0epDjazsDsGtGlWGmU9bqf2lKL9cOcNvvcDqfxiTVccyTo1tg0i+L6GHqDmeS1u9rSqTCSwqt2YdmTlEf8KXSsP9GPfWIZXoDakC97drbu4z9XJ2UXKZGnKzdak9VcyvUR67RIdXGZMXMOPB6Viz+1w==
Received: from [98.139.170.181] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 30 Sep 2015 20:00:10 -0000
Received: from [98.139.215.254] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 30 Sep 2015 20:00:10 -0000
Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 30 Sep 2015 20:00:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 681091.1514.bm@omp1067.mail.bf1.yahoo.com
X-YMail-OSG: EhLC2I4VM1mOwIZidYzoKV.eafcNj8DQWnkXZGZ3jqJkRAbSVw.yuASLmo5fagp 2zV7y9_A2HpUfeAD0faPcFlHC4zGVyWe6rKZJMybR4beTTUawkwCu9gZECbU8f5sHxXr_hOW8Z0f gqkV_aLzofMmD3dTioHrK6m1_QqxSro.xVYJEa7Uz.6zbZ0G1mG0q9BrklNN8LL1I4oOLcjVzNn1 8oo38Fgn3X1ezdBzDEM2YkGHeSIh8CCdNmFYxu.P5Lp93sm0tjHtjUcO7IPEC7pvLiFyQ_xKONSQ GZRr_4MVR0T9R6eCsSRxzEL_ZScEzhMfTGEs48sffU5OpV32rPaObQQIaimWBWRWUhAT9CkDR0JC fr9Bp8H7y7ZrIY3Kun2tieyZ_HORnrjGLUpgELfjowBg8D_OgDLhcdFgwWG9OqrxttSE2sFAcYuj VfyGxU1nFMO.VzZpSL3ydC99Ghz03nn5pMdNp7ePoOKM7qsw4n8QLr84m
Received: by 76.13.26.110; Wed, 30 Sep 2015 20:00:10 +0000
Date: Wed, 30 Sep 2015 19:59:54 +0000
From: Qin Wang <qinwang6top@yahoo.com>
To: Tero Kivinen <kivinen@iki.fi>
Message-ID: <667241035.3421143.1443643194071.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <22028.9972.425668.251992@fireball.acr.fi>
References: <22028.9972.425668.251992@fireball.acr.fi>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3421142_958600883.1443643194067"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/0A5a7C1TZVPLNfKmaef6Ang4_AE>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "Turner, Randy" <Randy.Turner@landisgyr.com>
Subject: Re: [6tisch] 6top-interface-04
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Qin Wang <qinwang6top@yahoo.com>
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: Wed, 30 Sep 2015 20:00:13 -0000

Hi Tero,
You raised a good question, i.e. how to define a cell for broadcast in 6top.
(1) I think 6top needs a way to define broadcast cell. A sender can not assume or know if the message transmitted in a TX cell will be received by all other nodes even if its nodeAddr is set to oxffff, because sender cannot know others TSCH schedule. Thus, there must be some bitmap in the sender to tell TSCH scheduler whether the TX cell is a Unicast cell or Broardcast Cell, i.e. neighbors are listening or not sure.
(2) It is indeed that IEEE80.15.4e uses LinkType to indicate if the cell is for Advertisement, but does not say it cannot be used to broadcast other message as you said. Thus, I wonder if 6top, as a sublayer, can take advantage of LinkType to define the broadcast cell, and let the content of broadcast come from broadcast Queue, EB or other broadcast message.
What do you think?
ThanksQin
 


     On Wednesday, September 30, 2015 2:16 PM, Tero Kivinen <kivinen@iki.fi> wrote:
   

 Qin Wang writes:
> In the IEEE802.15.4e, there are two attributes related with a cell, i.e.
> LinkOption and LinkType. LinkOption indicates TX, RX, Shared, or Timekeeping;
> and LinkType indicates Normal or Advertising. According to my understanding,
> if the attributes of a cell are set as LinkOption = TX and LinkType=
> ADVERTISING, then the cell can be used as Broadcast cell. Make sense?

LinkType of ADVERTISING means that this link is used to send enhanced
beacons out. There can be other broadcast traffic going out than
enhanced beacons, so I do not think you can only claim that
ADVERTISING links are broadcast cells. 

    ADVERTISING = 1, and indicates the link may be used to send an
    Enhanced beacon.

and

    ADVERTISE links may be used to send Enhanced beacons as the
    result of the MAC receiving a MLME-BEACON.request.

I would assume that broadcast link is something that is defined so
that all devices are listening that, i.e. where the listeners have RX
bit on, and nodeAddr for the sender is set to 0xffff. I do not think
linkType has anything to do with that, but as 6top-interface-04 does
not define what broadcast link/cell means, it is impossible to say.
-- 
kivinen@iki.fi