IETF Logo Mail Archive

Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 04 March 2016 11:16 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660F11B36D5 for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 03:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.6
X-Spam-Level:
X-Spam-Status: No, score=-12.6 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 VNVSU-cYZ7sS for <6tisch@ietfa.amsl.com>; Fri, 4 Mar 2016 03:16:32 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B62E1B36D4 for <6tisch@ietf.org>; Fri, 4 Mar 2016 03:16:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10170; q=dns/txt; s=iport; t=1457090192; x=1458299792; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=m09KZR9qUnJn4SS2hHRllQSAIRFlonL6Dva8OJb9reA=; b=ON70CT0/W7/Rg0hjvoZGItbPjcR+PjC3Bzcr+6xWedtfwmbQ3ptNSLW4 DCXu4PlLRQc2kiVbxnoAFkH6QOwlLt25+O/8C6spJU939yoY+F5FvibmY NG/cP1VxE8m7cS7DhShoSt+xVjuMXcwyxCEpGTi7ciUa+p9+15/vF7Lyk s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ALAgBTadlW/5BdJa1dgm5MUm0GujEBDYFqHYVyAhyBFTgUAQEBAQEBAWQnhEEBAQEEIwocQAIBCBEEAQEoAwICAjAUCQgCBAESCIgarhKOfAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGF4Q8hBI8IIJKgToFkniEKQGGSIcYgWmNF45RAR4BAUKDZGqHZz1+AQEB
X-IronPort-AV: E=Sophos; i="5.22,535,1449532800"; d="scan'208,217"; a="79564001"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2016 10:55:25 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u24AtPHh018763 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 10:55:25 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 04:55:24 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 04:55:24 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>, "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
Thread-Index: AQHRdWd9mPlo3b5EL0mbn7Lc1YhGE59JHHNA
Date: Fri, 04 Mar 2016 10:55:11 +0000
Deferred-Delivery: Fri, 4 Mar 2016 10:54:22 +0000
Message-ID: <db9afb0eddea42239c7203e29af6fdc1@XCH-RCD-001.cisco.com>
References: <CAH7SZV-wE=mhNm9DM6_xigGeGQD352XjNzNc=c7JewHvUvBxbw@mail.gmail.com>
In-Reply-To: <CAH7SZV-wE=mhNm9DM6_xigGeGQD352XjNzNc=c7JewHvUvBxbw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.5]
Content-Type: multipart/alternative; boundary="_000_db9afb0eddea42239c7203e29af6fdc1XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/XSfKK1svlJDsHrsy_ltbh8IBvcw>
Subject: Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Mar 2016 11:16:34 -0000

Hello Diego:

One suggestion would be that when a node attempts to join, the parent immediately grants a set of cells for the join process from a limited pool (to avoid DDOS). These cells are to be released at the end of the join and are there to boost the bandwidth for that critical phase.

Cheers,

Pascal

From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 3 mars 2016 17:12
To: 6tisch@ietf.org
Subject: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot

Dear all,
            Although it was discussed, there is no specification
on the 6top behaviour at boot. The discussion point here is if the
6top messages shall be transmitted on minimal cells until
the slotframe 1 (SFR1) has been populated enough to support
the transactions.
          - The use of minimal is optional. In case minimal is used,
the decision on when to switch is out of scope?
          - In case minimal is not used, shall we specify another
mechanism to enable 6top to transmit messages?
Thanks!
Regards,
                                             Diego Dujovne

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125

v2.23.0 | Report a Bug | By Email