Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 09 August 2019 17:58 UTC

Return-Path: <kaduk@mit.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 7E760120041; Fri, 9 Aug 2019 10:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ySukEQmQaB3X; Fri, 9 Aug 2019 10:58:03 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 EE910120019; Fri, 9 Aug 2019 10:58:02 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x79HvuK0029319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Aug 2019 13:57:59 -0400
Date: Fri, 09 Aug 2019 12:57:56 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Tero Kivinen <kivinen@iki.fi>
Cc: The IESG <iesg@ietf.org>, shwetha.bhandari@gmail.com, 6tisch@ietf.org, 6tisch-chairs@ietf.org, draft-ietf-6tisch-architecture@ietf.org
Message-ID: <20190809175755.GR59807@kduck.mit.edu>
References: <156523675061.8257.3166819796531461415.idtracker@ietfa.amsl.com> <23884.39664.259560.559115@fireball.acr.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <23884.39664.259560.559115@fireball.acr.fi>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/l1ce1NI_991wCvmMkH1fxLyu3Wo>
Subject: Re: [6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-architecture-24: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
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, 09 Aug 2019 17:58:05 -0000

On Fri, Aug 09, 2019 at 12:58:08AM +0300, Tero Kivinen wrote:
> Benjamin Kaduk via Datatracker writes:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > Section 4.3.4 asserts:
> > 
> >    [...]                                      We'll note that the Join
> >    Priority is now specified between 0 and 0x3F leaving 2 bits in the
> >    octet unused in the IEEE Std. 802.15.4e specification.  After
> >    consultation with IEEE authors, it was asserted that 6TiSCH can make
> >    a full use of the octet to carry an integer value up to 0xFF.
> > 
> > I'm extremely reluctant to publish this text in the IETF stream without
> > a citation.
> 
> IEEE Std 802.15.4-2015 says:
> 
> ----------------------------------------------------------------------
> 7.4.4.2 TSCH Synchronization IE
> 
> The TSCH Synchronization IE Content field shall be formatted as
> illustrated in Figure 7-50.
> 
>           +-------------+---------------+
> 	  |  Octets: 5  |       1       |
>           +-------------+---------------+
> 	  |     ASN     |  Join Metric  |
>           +-------------+---------------+
> 
>      Figure 7-50 -- TSCH Synchronization IE Content field format
> 	   
> The ASN field contains the ASN corresponding to the timeslot in which
> the enhanced beacon is sent. The ASN is used as the Frame Counter for
> security operations if enabled.
> 
> The Join Metric field is an unsigned integer and shall be set to
> macJoinMetric.
> ----------------------------------------------------------------------
> 
> And
> 
> ----------------------------------------------------------------------
> 
> Section 8.4.2.2 TSCH-specific MAC PIB attributes
> 
> ...
> 
>        Table 8-83 -- TSCH-specific MAC PIB attributes
> 
> Attribute	Type     Range       Description                     Default
> ...
> macJoinMetric	Integer	 0x00–0xff   The sum of one and the	     1
> 			 	     value of the Join Metric
> 				     field from the TSCH
> 			 	     Synchronization IE, 7.4.4.2,
> 			 	     received in the Enhanced Beacon
> 			 	     frame used by the device
> 				     joining the network. If the
> 				     device is the an endpoint, the
> 				     value shall be set to zero.
> 
> ----------------------------------------------------------------------
> 
> So it is very clear that Join Metric can be any number between
> 0x00-0xff. 

Great news; I see that Pascal will update the text/reference.

> >    scheduled cell:  A cell which is assigned a neighbor MAC address
> >                (broadcast address is also possible), and one or more of
> >                the following flags: TX, RX, shared, timeskeeping.  A
> > 
> > "timeskeeping" does not seem to be defined anywhere.
> 
> Timekeeping comes from the IEEE Std 802.15.4-2015 Section 7.4.4.3 TSCH
> Slotframe and Link IE:
> 
> ----------------------------------------------------------------------
>    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.

Ah, so it's just a typo and not a term of art.  Thanks!

-Ben