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 =-
- Re: [6lo] Adaption of ROLL for mesh-under Benjamin Damm
- Re: [6lo] Adaption of ROLL for mesh-under Carsten Bormann
- [6lo] Adaption of ROLL for mesh-under Benjamin Damm
- Re: [6lo] Adaption of ROLL for mesh-under Pascal Thubert (pthubert)
- Re: [6lo] Adaption of ROLL for mesh-under Michael Richardson
- Re: [6lo] Adaption of ROLL for mesh-under Michael Richardson
- Re: [6lo] Adaption of ROLL for mesh-under Benjamin Damm
- Re: [6lo] Adaption of ROLL for mesh-under Michael Richardson
- Re: [6lo] Adaption of ROLL for mesh-under Pascal Thubert (pthubert)
- Re: [6lo] Adaption of ROLL for mesh-under Pascal Thubert (pthubert)