IETF Logo Mail Archive

Re: [6lo] Adaption of ROLL for mesh-under

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 13 April 2017 19:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC5413161C for <6lo@ietfa.amsl.com>; Thu, 13 Apr 2017 12:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GU7wuB4hfrAI for <6lo@ietfa.amsl.com>; Thu, 13 Apr 2017 12:40:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931C413161A for <6lo@ietf.org>; Thu, 13 Apr 2017 12:40:31 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AC42420557; Thu, 13 Apr 2017 16:05:17 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 55714636BB; Thu, 13 Apr 2017 15:40:30 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Damm <bdamm@ssni.com>
cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
In-Reply-To: <1492101535983.82633@ssni.com>
References: <1491971619970.42705@ssni.com>, <CD3480AD-3934-4C9E-B6F3-E399A32BACC8@tzi.org> <3BE49481-8869-49DD-91A9-37CF7B532E2E@cisco.com> <11848.1492007709@obiwan.sandelman.ca> <355d3c67e7e64024961916debbaa4b6c@XCH-RCD-001.cisco.com>, <14548.1492095078@obiwan.sandelman.ca> <1492101535983.82633@ssni.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 13 Apr 2017 15:40:30 -0400
Message-ID: <16740.1492112430@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/7Rd3xTUChKPRfKFJrHyUEQwVpxY>
Subject: Re: [6lo] Adaption of ROLL for mesh-under
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 19:40:33 -0000

Benjamin Damm <bdamm@ssni.com> wrote:
    > Michael's assumptions regarding why are mostly correct. There are many
    > versions of the SSNI network, but the standard model is where the
    > continuously powered devices (CPDs) which are firmware-upgradable form
    > the core canopy and the majority of the device population, and various
    > battery-powered devices hang off of the canopy using whatever CPD
    > signals they can get. The CPDs are typically not significantly
    > constrained (they aren't constrained at all per rfc7228) but the BPDs
    > typically are, and they aren't all the same rfc7228 class. The
    > evolution is to allow standard Wi-SUN (route-over) devices join the
    > mesh, and potentially use some of the same RPL data structures,
    > messages, and algorithms where possible to reduce the private burden of
    > having non-standard routing structures and the various tooling and
    > expertise challenges that go with that.

Would you expect the the wi-sun devices to only link to the CPDs, or do they
also need to connect to the BPDs?

If the former (just CPDs), then you just need to incrementally upgrade the
CPDs in the field, and when they discover upstream CPDs that speak RPL
they join both PANIDs.   Then they just send DAOs for all their L2 connected
BPDs.
There are probably some ND issues to sort out, and maybe an (efficient!) ND
proxy is in order.  Basically the RPL becomes the "backbone" for the
mesh-under networks.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email