IETF Logo Mail Archive

Re: [6tisch] SeqNum definition in RFC8480 (6P)

Xavi Vilajosana Guillen <xvilajosana@uoc.edu> Wed, 24 April 2019 09:12 UTC

Return-Path: <xvilajosana@uoc.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 B225112023F for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 02:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu
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 Ez1ltDuEic_s for <6tisch@ietfa.amsl.com>; Wed, 24 Apr 2019 02:12:41 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 C3DB7120150 for <6tisch@ietf.org>; Wed, 24 Apr 2019 02:12:40 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id t4so16151847ljc.2 for <6tisch@ietf.org>; Wed, 24 Apr 2019 02:12:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=phy4bhmxsIF6/0e6Y8zkqbGgtBuzXqlygEYGMmOuZxA=; b=b0+ZS0fYshrd/LJLiRq7uHy/24VBVbs2P4Fc/wYhEy9Tu1BGkiTMmz9T+BnMMQufTC FzffzegORNFPUhCjtUh5klrDPUJmn8tpIAowwgwLjjqQEjRPGNsweLvhvP1SnEazlMdx aSBitxGiTjy0GIQJmWbKG60Qou+JmrpjVX8Jo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=phy4bhmxsIF6/0e6Y8zkqbGgtBuzXqlygEYGMmOuZxA=; b=bSiLsVauey9xa1eP/X4iFq0rO5bZxn/8+G2j7L59/ZQhMoajE2GeRsMiQwefjiqFFr YvNzny5VATtHSwCLWIv+jeiYTGwaqkSndVcesSE/5OkYwi1KRqFklKhEgfVsre7OfFPv C12cHh+WZ6gbpQGJvGkYbMy8oFFHRhsuXV3TZsfsNFAmIRq49uJPflsc5Q57gplcUlIz QOVo4QMNooioBt4nOm/yF0Bhc4J8S8+Wcs7PEaRYjvp/lIBY4mKbFaQpa9/BgyALE/lB xNNDxDCB9lqC3ZwLn1EmVrRpXMV5kBSHJ9TkIi5P9WiK8xhs0RjwvKoiQitEJiaxgl6e MvsA==
X-Gm-Message-State: APjAAAUEA+NuGh6OqpYk3UbGoWr1jWsP/ksrMg4hyWAO+dtBntTBdyy4 jhophiUET2LQ1cjfGBBLjleq/FeYR/AF50MvuNXDpg==
X-Google-Smtp-Source: APXvYqwa8FNTdWglkGop1+T/N67S7xvzCYIDezmHAO+T6rKwhTx17jwfPlEQx5lVfdU5y8iEYPOQtV+9i5Wod86jtic=
X-Received: by 2002:a2e:8693:: with SMTP id l19mr16305747lji.47.1556097158443; Wed, 24 Apr 2019 02:12:38 -0700 (PDT)
MIME-Version: 1.0
References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> <CAC9+vPgBUVjOiECs5ZL6c6PNkZ12X81=YThCs872VCbtJVb=uQ@mail.gmail.com> <c1e115ed-24c7-ed16-c776-bc2501e8a3b2@inria.fr>
In-Reply-To: <c1e115ed-24c7-ed16-c776-bc2501e8a3b2@inria.fr>
From: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Date: Wed, 24 Apr 2019 11:12:24 +0200
Message-ID: <CAC9+vPhs6FpVNvGA9vNe00RzZ5YND5-LvV3TCg=6dSwDsixshg@mail.gmail.com>
To: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Cc: tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005d86f40587431a3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/LldvnoXsLtR4l3jHcTjmqjtLo40>
Subject: Re: [6tisch] SeqNum definition in RFC8480 (6P)
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: Wed, 24 Apr 2019 09:12:45 -0000

Hi Yatch,

thanks for your response. see inline my comments.

Missatge de Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> del dia dt., 23
d’abr. 2019 a les 10:49:

> Hi Xavi,
>
> Thank you for your reply.
>
> On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:
> > When node B power cycles loses the last seen seqNum. Its stored value is
> then 0 and hence when it receives the request responds with the error and
> with the stored last seen seqnum (0).
> >
> > does it make sense?
>
> I don't think so... Why doesn't Node B just use SeqNum received from Node
> A for its response?
>
> Node A in Figure 31 would drop the response with SeqNum=0 at 6P layer
> because it is not considered as part of the transaction started by the
> request with SeqNum=88.
>

well SeqNum=0 is only possible after a reset or when the node boots. SeqNum
will always be different than 0 except for that occasions. So 6P can be
aware situation happening in the middle of a transaction.

We took that decision as we consider that Node B may have completely lost
the state, which is critical. Probably the option you mention would have
been also possible but we took that direction.

What is the issue you see with this?



> Again, the definition of SeqNum is:
>
> >    SeqNum:  The sequence number associated with the 6P Transaction.
> >          Used to match the 6P Request, 6P Response, and 6P Confirmation
> >          of the same 6P Transaction.
>
> Best,
> Yatch
>

regards
X

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajosana@uoc.edu <usuari@uoc.edu>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
­

v2.23.0 | Report a Bug | By Email