Re: [6tsch] Fwd: 6TiSCH: about join priority in IEEE802.15.4e

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 18 September 2013 15:16 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8762911E81AD for <6tsch@ietfa.amsl.com>; Wed, 18 Sep 2013 08:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g5fLWiFX7mE for <6tsch@ietfa.amsl.com>; Wed, 18 Sep 2013 08:16:12 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8918D11E8221 for <6tsch@ietf.org>; Wed, 18 Sep 2013 08:16:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21995; q=dns/txt; s=iport; t=1379517372; x=1380726972; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FOobc3D4C2dItymbHn4sAlsu5POCfccFRH3c2EaVe6s=; b=JgGszaOm0oZOSOG1knPbeXR+vKerwd4ePxiIXssAqofkcUuSADfwUsdi PBe+Fc9i+QGbu1tTIInS8lxcnGGizar0DLNbwt1Nfu54sgUONH9Xmxc/E v4sw3Yvpe6hwX6Qj/Sy2e/5Sa/uqmW3NV4721IvVYbsLW2+twlIBqX+T6 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsgGAEfDOVKtJV2b/2dsb2JhbABOCQMOgjVEOFK4YogOOIEbFnSCJQEBAQQBAQEaEEELEAIBCBEBAgEBAQsdBycLFAMGCAIEAQ0FCBKHaQy6S44ZAQQQgQggAQsBBAYBBguDDYEAA4VOk1yQRYJlP4FxOQ
X-IronPort-AV: E=Sophos; i="4.90,929,1371081600"; d="scan'208,217"; a="261226748"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 18 Sep 2013 15:16:11 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8IFGB7t010902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 15:16:11 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.197]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 10:16:11 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "xvilajosana@eecs.berkeley.edu" <xvilajosana@eecs.berkeley.edu>, Thomas Watteyne <watteyne@eecs.berkeley.edu>
Thread-Topic: [6tsch] Fwd: 6TiSCH: about join priority in IEEE802.15.4e
Thread-Index: AQHOtH0jOOewzfMeZEiCLzRZdxKx75nLmQdA
Date: Wed, 18 Sep 2013 15:16:10 +0000
Deferred-Delivery: Wed, 18 Sep 2013 15:15:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD84147C9EA@xmb-rcd-x01.cisco.com>
References: <CADJ9OA9_FjWzaCPznoq0zwUTvNH99e67-y39F98uofh5DC63xA@mail.gmail.com> <0657BDCA-2F2A-4D30-B6C8-86132595BEAE@linear.com> <CADJ9OA90K4Rd_yBUCZ98Nd-zgBFjzAOivnNdoztBMYrBZ7vusA@mail.gmail.com> <CALEMV4Y0XhWnWzyq_rp8dco5y8Kxp1ujxUbXGNNxVz9Wcpc-Rg@mail.gmail.com>
In-Reply-To: <CALEMV4Y0XhWnWzyq_rp8dco5y8Kxp1ujxUbXGNNxVz9Wcpc-Rg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.100.213]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84147C9EAxmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] Fwd: 6TiSCH: about join priority in IEEE802.15.4e
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2013 15:16:17 -0000

Hello Xavi

I hope so. As you point out, it is the intention of the DAGRank() is to obtain an octet that is monotonically incrementing with the depth.
So I agree it is a perfect match for the join priority and that is  what I documented in the latest architecture in the repo based on the last 2 calls.

https://bitbucket.org/6tsch/draft-thubert-6tsch-architecture/src/faeea553413ba1f5be89cf7d9edb549b837ebe27/draft-thubert-6tsch-architecture-03.txt?at=master#cl-667

I'd appreciate you have a look to review my text there : )

cheers,

Pascal

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Xavier Vilajosana Guillen
Sent: mercredi 18 septembre 2013 16:41
To: Thomas Watteyne
Cc: 6TSCH
Subject: Re: [6tsch] Fwd: 6TiSCH: about join priority in IEEE802.15.4e

Hi Thomas,

when you say the "the "integer" portion of the rank in the join priority," you mean the result of the DAGRank(rank) function?
Cheers
Xavi

On Tue, Sep 17, 2013 at 6:59 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> wrote:
All,

Please find below an e-mail exchange I had with Jonathan Simon, co-editor of the IEEE802.15.4e standard. He is confirming that driving the join priority field in the enhanced beacons from an upper layer does not break standards-compliance, which is great news.

His second point is also very interesting: we could use just the "integer" portion of the rank in the join priority, so that the value announced is roughly equivalent to a hop count.

Would that work?

Thomas
---------- Forwarded message ----------
From: Jonathan Simon <jsimon@linear.com<mailto:jsimon@linear.com>>
Date: Tue, Sep 17, 2013 at 10:14 AM
Subject: Re: 6TiSCH: about join priority in IEEE802.15.4e
To: Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>>

Thomas -  The join priority was intended to be used in the way you describe.  Note that join priority is described somewhat vaguely in the text - the spec does not say what to use it for other beyond a MAC management layer function of selecting a prospective parent, and no service primitives are described to set or change it.   The spec does not use the proscriptive "shall" or "must" language, and I certainly intended it as a default in absence of other upper layer methods to manage it.

So as to 1), updating the join priority to reflect a node's actual position in the network rather than its "birth" position is a good idea.  WirelessHART has this capability.
For 2),  the important thing is that all devices in the network should be using join priority in the same way to avoid confusion. Making the objective function scale in integer hops seems intuitive and simple and matches the default description, but if each device was n "hops" from its parent, it would serve the same purpose.

Hope this answers your questions. Feel free to forward this to the 6TiSCH group.

Jonathan
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936<tel:%28510%29%20400-2936>
(510) 489-3799<tel:%28510%29%20489-3799> FAX
jsimon@linear.com<mailto:jsimon@linear.com>

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936<tel:%28510%29%20400-2936>, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

On Sep 12, 2013, at 12:53 PM, Thomas Watteyne wrote:


Jonathan,

We are discussing the interaction between IEEE802.15.4e and the RPL routing protocol in the 6TiSCH group (see minutes last call at [1]).

We have some questions about the "Join Priority" field in the IEEE802.15.4e EB, in particular about how much an upper layer (6top [2]) can influence its value. We want to make sure that we do not break compliance with the IEEE802.15.4e standard.

For reference, this is the text in IEEE802.15.4e (p.90):

The 1-octet Join Priority field can be used by a joining device to select among beaconing devices when multiple beacons are heard. The PAN coordinator's join priority is zero. A lower value of join priority indicates that the device is the preferred one to connect to. The beaconing device's join priority is the lowest join priority heard when it joined the network plus one.

We have the following discussions:

  1.  After a node has joined, it might be moving to a different topological location. In that case, it should update the Join Priority it is announcing. Luckily, RPL maintains the node's rank, a concept very similar to join priority.
Question: Can we have the 6top change the priority announced by IEEE802.15.4e to the RPL rank (or a number calculated from the RPL rank) after the node has joined?
  2.  RPL is very flexible about how rank is calculated. Depending on the Objective Function used, the rank can be calculated differently. In particular, the difference of the rank between a node and routing parent can be different from 1.
Question: Can the join priority announced by node and its parent be different by more than 1?
Your input is very welcome,

Thomas

[1] https://bitbucket.org/6tsch/meetings/wiki/130906_webex
[2] http://tools.ietf.org/html/draft-wang-6tsch-6top-00



_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch