IETF Logo Mail Archive

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

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Tue, 23 April 2019 08:49 UTC

Return-Path: <yasuyuki.tanaka@inria.fr>
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 53DB01200FA for <6tisch@ietfa.amsl.com>; Tue, 23 Apr 2019 01:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 kid1L7uI560S for <6tisch@ietfa.amsl.com>; Tue, 23 Apr 2019 01:49:50 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 EF9C61200A2 for <6tisch@ietf.org>; Tue, 23 Apr 2019 01:49:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,385,1549926000"; d="scan'208";a="379775875"
Received: from wifi-pro-82-172.paris.inria.fr (HELO [128.93.82.172]) ([128.93.82.172]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 Apr 2019 10:49:48 +0200
Cc: yasuyuki.tanaka@inria.fr, tisch <6tisch@ietf.org>
To: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
References: <03CD9F4A-D6CD-44D2-AFF4-9F005ED409E8@inria.fr> <CAC9+vPgBUVjOiECs5ZL6c6PNkZ12X81=YThCs872VCbtJVb=uQ@mail.gmail.com>
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Message-ID: <c1e115ed-24c7-ed16-c776-bc2501e8a3b2@inria.fr>
Date: Tue, 23 Apr 2019 10:49:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CAC9+vPgBUVjOiECs5ZL6c6PNkZ12X81=YThCs872VCbtJVb=uQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/idYrhW9KhJrfkVEXWmcja1vLWL8>
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: Tue, 23 Apr 2019 08:49:53 -0000

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.

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

v2.23.0 | Report a Bug | By Email