[6tisch] follow up LIST cmd 6P

Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> Tue, 06 September 2016 08:36 UTC

Return-Path: <xvilajosana@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DF67312B16D for <6tisch@ietfa.amsl.com>; Tue, 6 Sep 2016 01:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GgQiULUKOEA5 for <6tisch@ietfa.amsl.com>; Tue, 6 Sep 2016 01:36:17 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 235D312B15C for <6tisch@ietf.org>; Tue, 6 Sep 2016 01:36:17 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id g62so140864425lfe.3 for <6tisch@ietf.org>; Tue, 06 Sep 2016 01:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=LEBrn5Xcp1l7rBkFYezIr9CBuxwP+wzAkQAlQsQFcjc=; b=PDBkR2CB2OXtNc39fHKTJb1ljjtrw2IqqRuW446dXC4JsFflWQ+BOgq3f566lLUdqu +jtQY8Iebq5S8Flkt+XmjQvQ1BsisrSzNuDxi4t8bZJUbWYMSsKrUTUxmwwwSkKZYAMI 7kz5ls71BiByu0rvVh5nmmZ/We6l/+kp5p6JFZFKIu1g6heUQu0dwp5OECZaV0FaoCNc AczWhIffxaVtHktDOXinXAaHFAxwSLrXCsVIeYCx/tAdacelOh3C7CntowSPLnj+5XbU cvPpt6+boTd6NhFDUbn9PjyVlxoL9NNezwK594mY8chGVYgYV2k8Y71w8T1h3dX4E4ev QAWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=LEBrn5Xcp1l7rBkFYezIr9CBuxwP+wzAkQAlQsQFcjc=; b=FLwcWRkhJ5n06gXA52QpM/JWBrPSKqd0qEtwd11z0mPvcUTB5Lx5p+ffJnkQxuWr/u XYCcgRMTwtV9fXZfV1B/4pQUCpnJ3x5IO/K9fAyy4qNPj86i2QTTjPLgc+buF1pswh2Y e8VZFcHOmPr3jVHadSkPWpX6ZUOLT6HLdJ4cNMytn/asuDyr3SnbA2e0WLy+A4vTwsrt 8omOob4cNh/YAhDDE/p+rioBO6K2dpkv0ubbC2RLC/r0LzHWKaRLzEg95mtGe0/YRG8H TLpybc6ePKxrgKwyyiLzVMJa+/l4LGFEAsqzy/lYWM/IKucKQ/kEF/+Pwyrez/MTupR3 l37Q==
X-Gm-Message-State: AE9vXwMk1S1JLVKMir+Dsu/EItEGYB8nfDvNrrkrAN3rAQap92L5+MfK9JXalCG1toO72N7vmggCu4vWWRmT7Q==
X-Received: by with SMTP id g196mr6300990lfb.123.1473150974937; Tue, 06 Sep 2016 01:36:14 -0700 (PDT)
MIME-Version: 1.0
Sender: xvilajosana@gmail.com
Received: by with HTTP; Tue, 6 Sep 2016 01:36:14 -0700 (PDT)
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Date: Tue, 06 Sep 2016 10:36:14 +0200
X-Google-Sender-Auth: VeQaXmATVdE9_vD3oqYusgbG5qA
Message-ID: <CAMsDxWTSj3Yyu8wo5=p52DBycLS9pKAO263on24=z+R-FsTqDg@mail.gmail.com>
To: "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="001a114154368fd3aa053bd2b085"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/qFitQe3mc-CfSpFCROlWTmos9j8>
Subject: [6tisch] follow up LIST cmd 6P
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: Tue, 06 Sep 2016 08:36:20 -0000


according to our discussion during the last 6TiSCH meeting I want to follow
up Tero's proposal for the LIST cmd.

here you will find his initial proposal

As a summary, the proposal enables 6P list to return a best effort set of
cells, this is as many as can be fitted in a packet below a maximum. This
makes the list command robust to the presence of other IEs in the packet
(which sometimes may be present and some times don't and hence would make
two identical requests to succeed or fail. With this approach LIST is
independent of the remaining space in the packet)

I follow up the discussion by proposing these changes to 6P.

1- change numCells field to numCells_max as follow:

                        1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |Version|  Code |    SFID       | SeqNum|GAB|GBA|   Metadata
         Metadata    |            Offset             |   numCells_max


numCells_max:  The maximum number of requested cells.  Less cells
         than numCells_max can be returned if they do not fit in the

Then I propose the following text

4.3.10.  Listing Cells

   When a node A issues a LIST_AB or LIST_BA command, it specifies:

   o  Through the "Offset" field, the offset of the first cell to be
      present in the returned list.  The cell ordering policy is defined
      by the SF.
   o  Through the "numCells_max" field, the maximum number of cells to
      be present in the reponse.  If numCells_max cannot be fitted in the
      packet less cells will be returned.

   When receiving a LIST_AB command, node B returns the cells that are
   scheduled from A to B in its schedule (i.e. receive cells from node
   A).  When receiving a LIST_BA command, node B returns the cells that
   are scheduled from B to A in its schedule (i.e. transmit cells to
   node A).  The RECOMMENDED format of each 6P Cell is defined in
   Section 4.2.5.  The SF MAY redefine the format of the CellList field.

   Depending on how many cells node B has in its schedule which match the
   LIST_AB or LIST_BA request, the cellList returned in the 6P Response
   contains between 0 and numCells_max cells:

   o  If node B has more than Offset+numCells cells, the cellList it
      returns contains exactly numCells cells as long as the cellList
      fits in the packet.  Otherwise it returns a cellList containing
      the maximum number of cells that fit in the packet.
   o  If node B has N cells, where Offset<N and N<Offset+numCells_max
      cells, the cellList it returns contains exactly N-Offset cells.
      If that number of cells do not fit in the packet, the cellList
      containing the maximum number of cells that fit in the packet is
   o  If node B has less than Offset cells, the cellList it returns is

Please, raise any pros and cons you may find in this approach.