From nobody Tue Aug 1 23:37:07 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A112126CB6; Tue, 1 Aug 2017 23:37:00 -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 TA86fAc6jtmO; Tue, 1 Aug 2017 23:36:58 -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 9FF7D124C27; Tue, 1 Aug 2017 23:36:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0BF282009E; Wed, 2 Aug 2017 02:38:48 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8A6F08076D; Wed, 2 Aug 2017 02:36:57 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, roll@ietf.org In-Reply-To: References: <150044138257.25233.12391471568614147773@ietfa.amsl.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 Archived-At: Subject: [Roll] ANIMA ACP -08 -- estimating depth of DODAG in storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 06:37:00 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: > [One detail however: >> The loop-count MUST be sete to 255. When an ACP node >> receives the M_FLOOD, it will have been reduced by the number of hops >> from the EST server. > I don't like that. The role of the loop count is loop prevention, > so it should be set to a reasonable upper bound on the "radius" > of the network. GRASP has two measures for loop detection, this > one and detection of duplicate session IDs, but that was > intentional redundancy.] If we were using RPL in non-storing mode, we'd get DAO messages from the leaves directly to the root indicating their parent. The DODAG root would therefore know exactly what the deepest leaf was. That would be the radius From=20the root to the furthest node, but of course discovery might happen = from edge to edge, so the longest path would therefore be 2x that size (up the tree to the top and down again). As we are using RPL in storing mode, the DAOs are summarized at each level, we won't know that information. That's kind too bad I think, because each node knows how deep it is, they just don't report it to the root in anyway. It would be easy to add a CHILD_MAX_RANK DAO option to the DAO packet. It wouldn't make it to the top unless all nodes supported it, but it still might be worth writing it down. Unless someone else can figure out a way with existing information for a DODAG root to know how deep the network is? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmBcwkACgkQgItw+93Q 3WVG1Qf+MNryOI1Db7kUJb63SzGVp8k55wvK2bVdc17//CRXwbgMuZ8attv5Vb82 UGRuOgezk84I5YU2fWtYdXZc6agpiSuVqp/TtRDCaWlYv8ymtWhGclb2ZnUXw7pl rOR39LKedociP78M2f5qdFQxYo9CJwyvut975d6uEdCtA/W42eFCUQ3OUNtReKUw 4ztSeO8QEWUWpwhaDqTTP0RY1eYGbQiFkzfEmGH69c9OC0Dbtp/3wsiNCX5Y5t2Z wn28TEpKKUM+Ykt/LHcVm6mFDdY3aSkIdQwsfZdZvYCE8xXe7wHidbZ65FWAyDMN q8uBX0igTmPVRv2iREqmpirlGLRIhg== =8Xsu -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 4 06:00:45 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D09132163 for ; Fri, 4 Aug 2017 06:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 VHismzvGW7d8 for ; Fri, 4 Aug 2017 06:00:42 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEE2131CE8 for ; Fri, 4 Aug 2017 06:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3126; q=dns/txt; s=iport; t=1501851637; x=1503061237; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H6jO0O2q6w7ocqgZnlBtiJHDHpSGPjhvUjs/lcdc2yo=; b=PypOf7ABHbqbnb/319Eb0KnLj99n5kn5sH6FLs9qQIUzmUIDT8cjMcHF G6XLVSsJK1iXt+r0d1SAV5rc865Qr/PkpuQ1IrhH3SUpupwnzYO3FzOJ6 5EH3OO5GAv/9VnEU0VhU4aL8cJ7S4HiS3g979W6QJBgfUUGf2mIoRxfSS Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAcb4RZ/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkbScHjgiQB4FulhUOggQhC4UbAoRHPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQMBATg0FwQCAQgRBAEBHwkHJwsUCQgCBAESCIoPAxUQsGWHMQ2EAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgyiCAoFMhQqCV4FiBBoPhgEFoAUCix6JBoIYhVi?= =?us-ascii?q?KYolejCMBHziBCncVSYUXHIFndocpgTCBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,321,1498521600"; d="scan'208";a="268228834" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 13:00:36 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v74D0aE1025400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 13:00:36 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Aug 2017 08:00:35 -0500 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.1210.000; Fri, 4 Aug 2017 08:00:35 -0500 From: "Pascal Thubert (pthubert)" To: "consultancy@vanderstok.org" , "Routing Over Low power and Lossy networks" , Ines Robles Thread-Topic: [Roll] rplinfo Thread-Index: AQHS/6NEv51YLwBSwEmY1pHRxPGzJaJZwscAgAACX4CAAAJ3AIAABH8AgBpzsbA= Date: Fri, 4 Aug 2017 13:00:24 +0000 Deferred-Delivery: Fri, 4 Aug 2017 13:00:21 +0000 Message-ID: References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <53ff58f630492909409429a1f49da504@xs4all.nl> In-Reply-To: <53ff58f630492909409429a1f49da504@xs4all.nl> 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.228.216.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] rplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 13:00:44 -0000 Dear all: Very soon, when 6lo ships rfc6775-update, we will have the tools we need fr= om the outside to enable interconnecting non-RPL-aware hosts as RPL leaves.= Leaves will need a certain level of 6lo but no knowledge of RPL. And RPL w= ill be able to register leaves with upgraded 6lo with a certain upgrade of = RPL as well. We'll need a new draft to specify the building of DAOs by the firs RPL rout= er on behalf of the leaves in both storing and non-storing (there's a E bit= to signal that already in RPL). The 6LR will have to be the first RPL rout= er, and the 6lo spec will give us the TID which maps to the path-sequence, = and the router will turn the periodic NS/NA into a periodic DAO. We may specify that similarly, the DAO reaching the RPL root can be used to= refresh the 6LBR in order to save the periodic DAR/DAC, but in order to do= that, the 6LBR will also have to be the RPL root. Separating them will req= uire additional signaling between the split functions, hopefully more a loc= al exchange than the DAR/DAC. Take care, Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok Sent: mardi 18 juillet 2017 13:49 To: Ines Robles Cc: Routing Over Low power and Lossy networks Subject: Re: [Roll] rplinfo Hi Ines, my suggestion: There is a LLN of connected nodes with IPv6 addresses and paths between the= m A subset of these nodes is RPL aware. These RPL aware nodes form a DODAG. The non RPL aware nodes are not part of the DODAG and cannot be leaves of t= he DODAG However, communication is possible between a rpl-aware node and a = non-rpl-aware node via link-local addresses at least. Peter Ines Robles schreef op 2017-07-18 13:32: > Yes, agree. >=20 > So, could we have a case where the leaf nodes do not accept DIO=20 > Messages like in the use cases? >=20 > Maybe we should define the features with more detail of a=20 > not-RPL-aware-leaf in the document. >=20 > 2017-07-18 13:23 GMT+02:00 peter van der Stok : >=20 >> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >> It can be a neighbour of a DODAG node but not a leaf in my=20 >> understanding >>=20 >> I understand that we can have it. Please someone correct me if I am=20 >> wrong. >>=20 >> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: >>=20 >> - A leaf node (only) does not ever participate as a RPL router. >>=20 >> - Support of a particular MOP encoding is not required >>=20 >> - Support of a particular OF is not required. >>=20 >> - A leaf node does not generally issue DIO messages, >>=20 >> - it may issue DAO and DIS messages. A leaf node accepts DIO=20 >> messages though it generally ignores DAO and DIS messages (not=20 >> applied in our case) >=20 > A leaf node accepts DIO messages and is thus RPL-aware in my=20 > understanding; >=20 > Peter _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Fri Aug 4 07:50:46 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323CB1321A1 for ; Fri, 4 Aug 2017 07:50:39 -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, FREEMAIL_FROM=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 (2048-bit key) header.d=gmail.com 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 jyCBaVaOTvOC for ; Fri, 4 Aug 2017 07:50:33 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 1D1E1131EA6 for ; Fri, 4 Aug 2017 07:50:33 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id v127so1243879itd.2 for ; Fri, 04 Aug 2017 07:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=3/1opQM9W+VLHhQ9WbM4vtXxa1pMrlABNmzsnu79tzo=; b=vQjliJ57uTMC7RLMDnyVcOVUnW/S5QmWyjdQzln/UX8LZCho725RWf28HM69DoRgK/ fISmpyqLNAPnFGhq5WPUEFUVpM/SyMc2AtkBBrUmzLMlIpsOmedjnTXFaGKVlRRjfkHD XYhFQ2DwLvQfsM1jra+yt5HMuJIhH6p3WFO8DKGi27TscRCPCbWYC0NMjtC9VAPjmbHK ot5+Y3/qJF6l/n0/VgFhjyRQ8MmWrm3RKsHzEG5oFR1wJmT6avx4q9h5U/kCqdpDO4Vr E9xETJXmzYddHOBpu1WX45cwtcf+blaGtZJcSZIjqNoLLvLiOX4K8CST8sGnyIXVGIUI Dbdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=3/1opQM9W+VLHhQ9WbM4vtXxa1pMrlABNmzsnu79tzo=; b=LW6alxa7DLMpq+ogFCTt8aRPV2oVeaJJ1ke5UCgFCzrdpwyS/jVMM9ZCGhFD4yZ8Br /KDw+txwWuko+AdvX+0zlFgSwjaLLabmKtah7mz+KOgOGMXoemGLO8CgREkEQg/ik2z/ tHuaLzZBJfmqJE0Xyt+k1IyulaXZW3x6SnMcR7Tozyjfd1QQ/PW8zcNhrA6rI30mHmFL UOpqvBVfdDThNZHUQvfn41I/MAvFEi2MkLNU+R8fg06yDd6nCYtFZhBK9Lnp+1SkF2H2 RI9GI/IoI2IvVQAk5c59NUfhtsazZ5Q3WNYsbt9efBHJ3vSRelB5Ja6ffSgOorbbXblK tlLw== X-Gm-Message-State: AIVw110eFRDbaFsvka1jPcN/tzIDbHRa9N4w7GBc+7Mqmj7BC1UOiQDh IHam0cLUy7UepkLW X-Received: by 10.36.65.205 with SMTP id b74mr2479338itd.122.1501858232162; Fri, 04 Aug 2017 07:50:32 -0700 (PDT) Received: from ubuntu-1604-lts.c.rjtmp-165304.internal (53.84.197.104.bc.googleusercontent.com. [104.197.84.53]) by smtp.gmail.com with ESMTPSA id e80sm776243ite.3.2017.08.04.07.50.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 07:50:31 -0700 (PDT) From: Rahul Jadhav X-Google-Original-From: Rahul Jadhav Date: Fri, 4 Aug 2017 14:50:27 +0000 (UTC) To: Routing Over Low power and Lossy networks cc: "consultancy@vanderstok.org" , Ines Robles In-Reply-To: Message-ID: References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <53ff58f630492909409429a1f49da504@xs4all.nl> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Roll] rplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 14:50:39 -0000 Hello Pascal, Please find my resp inline.. Regards, Rahul On Fri, 4 Aug 2017, Pascal Thubert (pthubert) wrote: > Dear all: > > Very soon, when 6lo ships rfc6775-update, we will have the tools we need from the outside to enable interconnecting non-RPL-aware hosts as RPL leaves. Leaves will need a certain level of 6lo but no knowledge of RPL. And RPL will be able to register leaves with upgraded 6lo with a certain upgrade of RPL as well. > > We'll need a new draft to specify the building of DAOs by the firs RPL router on behalf of the leaves in both storing and non-storing (there's a E bit to signal that already in RPL). The 6LR will have to be the first RPL router, and the 6lo spec will give us the TID which maps to the path-sequence, and the router will turn the periodic NS/NA into a periodic DAO. [RJ]: Yes this draft is needed and it will optimize the non-RPL-aware leaf node joining (as compared to using proxy NS/NA DAR/DAC). One of the thing that is missing is the DAO-ACK signalling to the non-RPL-aware leaf node i.e. if DAO-ACK is received with negative status then what should the first-6LR node send to the non-RPL-aware node? Should the first-6LR delay the NA response till the time DAO-ACK is returned? This has its own complexities. Note that DAO-ACK might be sent from the Root/parent-6LR regardless of 'K' bit in the DAO message. Thus this has to be handled. > > We may specify that similarly, the DAO reaching the RPL root can be used to refresh the 6LBR in order to save the periodic DAR/DAC, but in order to do that, the 6LBR will also have to be the RPL root. Separating them will require additional signaling between the split functions, hopefully more a local exchange than the DAR/DAC. [RJ]: Are you suggesting splitting it up in a way that there is different RPL signalling between 6LBR and multiple RPL roots? Or is it that 6LBR will initiate the DIO and RPL roots simply become 6LRs? The later approach has multiple issues. > > Take care, > > Pascal > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok > Sent: mardi 18 juillet 2017 13:49 > To: Ines Robles > Cc: Routing Over Low power and Lossy networks > Subject: Re: [Roll] rplinfo > > Hi Ines, > > my suggestion: > There is a LLN of connected nodes with IPv6 addresses and paths between them A subset of these nodes is RPL aware. > These RPL aware nodes form a DODAG. > The non RPL aware nodes are not part of the DODAG and cannot be leaves of the DODAG However, communication is possible between a rpl-aware node and a non-rpl-aware node via link-local addresses at least. > > Peter > > Ines Robles schreef op 2017-07-18 13:32: >> Yes, agree. >> >> So, could we have a case where the leaf nodes do not accept DIO >> Messages like in the use cases? >> >> Maybe we should define the features with more detail of a >> not-RPL-aware-leaf in the document. >> >> 2017-07-18 13:23 GMT+02:00 peter van der Stok : >> >>> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >>> It can be a neighbour of a DODAG node but not a leaf in my >>> understanding >>> >>> I understand that we can have it. Please someone correct me if I am >>> wrong. >>> >>> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: >>> >>> - A leaf node (only) does not ever participate as a RPL router. >>> >>> - Support of a particular MOP encoding is not required >>> >>> - Support of a particular OF is not required. >>> >>> - A leaf node does not generally issue DIO messages, >>> >>> - it may issue DAO and DIS messages. A leaf node accepts DIO >>> messages though it generally ignores DAO and DIS messages (not >>> applied in our case) >> >> A leaf node accepts DIO messages and is thus RPL-aware in my >> understanding; >> >> Peter > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Fri Aug 4 09:07:13 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0741323B3 for ; Fri, 4 Aug 2017 09:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 p0ufxAvFU6HV for ; Fri, 4 Aug 2017 09:07:10 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6049E1323B1 for ; Fri, 4 Aug 2017 09:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5025; q=dns/txt; s=iport; t=1501862830; x=1503072430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xRF97XiEtaKEb3HEmtwD9l/1Q6oCr9TpK40UYrhuX0Y=; b=ia6DgWJxDKnwHUzFZydoWBhNTNd3sUJW1auPDCqnBhxSib04lbUtT8C/ ymt8p1tswE81OWS/je1BjvGfDClV6V5x26iRd2B89My/ezfYtAjayv0CW Iho5IMLsBLTZS0n7ZAQqn42M9j/qFUSJ2BmpjcIHjIOgmQOsEosdlZeJk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAdm4RZ/51dJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1pkbScHjgiQB4FulhUOggQhC4UbAoRKPxgBAgEBAQEBAQFrKIUYAQE?= =?us-ascii?q?BAQIBAQFsCwUHBAIBCBEEAQEoBycLFAkIAgQOBQiKDwMNCBCxLYcyDYQBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDKIICgUyFCoJXgWIEGg+GAQWRO45KAoseiQa?= =?us-ascii?q?CGIVYimKJXowjAR84gQp3FUmFFxyBZ3aHKYEwgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,321,1498521600"; d="scan'208";a="464890330" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 16:07:09 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v74G79FL022043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 16:07:09 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Aug 2017 11:07:08 -0500 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.1210.000; Fri, 4 Aug 2017 11:07:08 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: Ines Robles Thread-Topic: [Roll] rplinfo Thread-Index: AQHS/6NEv51YLwBSwEmY1pHRxPGzJaJZwscAgAACX4CAAAJ3AIAABH8AgBpzsbCAAHbDgP//wEmw Date: Fri, 4 Aug 2017 16:06:39 +0000 Deferred-Delivery: Fri, 4 Aug 2017 16:06:19 +0000 Message-ID: <70092d356aa1481888920851d6b8bd6b@XCH-RCD-001.cisco.com> References: <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <53ff58f630492909409429a1f49da504@xs4all.nl> In-Reply-To: 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.228.216.25] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] rplinfo X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 16:07:12 -0000 I'm not suggesting to split, Rahul, but pointing the consequences if we did= . If we did, the 6LBR would do DAR/DAC, and the RPL root DAO/DIO. And the roo= t would need to signal to the 6LBR upon a DAO, e.g. a proxy DAR/DAC exchang= e. Note also that RPL does not have the OID.=20 Take care, Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Jadhav Sent: vendredi 4 ao=FBt 2017 16:50 To: Routing Over Low power and Lossy networks Cc: Ines Robles Subject: Re: [Roll] rplinfo Hello Pascal, Please find my resp inline.. Regards, Rahul On Fri, 4 Aug 2017, Pascal Thubert (pthubert) wrote: > Dear all: > > Very soon, when 6lo ships rfc6775-update, we will have the tools we need = from the outside to enable interconnecting non-RPL-aware hosts as RPL leave= s. Leaves will need a certain level of 6lo but no knowledge of RPL. And RPL= will be able to register leaves with upgraded 6lo with a certain upgrade o= f RPL as well. > > We'll need a new draft to specify the building of DAOs by the firs RPL ro= uter on behalf of the leaves in both storing and non-storing (there's a E b= it to signal that already in RPL). The 6LR will have to be the first RPL ro= uter, and the 6lo spec will give us the TID which maps to the path-sequence= , and the router will turn the periodic NS/NA into a periodic DAO. [RJ]: Yes this draft is needed and it will optimize the non-RPL-aware leaf = node joining (as compared to using proxy NS/NA DAR/DAC). One of the thing t= hat is missing is the DAO-ACK signalling to the non-RPL-aware leaf node i.e= . if DAO-ACK is received with negative status then what should the first-6L= R node send to the non-RPL-aware node? Should the first-6LR delay the NA re= sponse till the time DAO-ACK is returned? This has its own complexities. No= te that DAO-ACK might be sent from the Root/parent-6LR regardless of 'K' bi= t in the DAO message. Thus this has to be handled. > > We may specify that similarly, the DAO reaching the RPL root can be used = to refresh the 6LBR in order to save the periodic DAR/DAC, but in order to = do that, the 6LBR will also have to be the RPL root. Separating them will r= equire additional signaling between the split functions, hopefully more a l= ocal exchange than the DAR/DAC. [RJ]: Are you suggesting splitting it up in a way that there is different R= PL signalling between 6LBR and multiple RPL roots? Or is it that 6LBR will = initiate the DIO and RPL roots simply become 6LRs? The later approach has m= ultiple issues. > > Take care, > > Pascal > > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der=20 > Stok > Sent: mardi 18 juillet 2017 13:49 > To: Ines Robles > Cc: Routing Over Low power and Lossy networks > Subject: Re: [Roll] rplinfo > > Hi Ines, > > my suggestion: > There is a LLN of connected nodes with IPv6 addresses and paths between t= hem A subset of these nodes is RPL aware. > These RPL aware nodes form a DODAG. > The non RPL aware nodes are not part of the DODAG and cannot be leaves of= the DODAG However, communication is possible between a rpl-aware node and = a non-rpl-aware node via link-local addresses at least. > > Peter > > Ines Robles schreef op 2017-07-18 13:32: >> Yes, agree. >> >> So, could we have a case where the leaf nodes do not accept DIO=20 >> Messages like in the use cases? >> >> Maybe we should define the features with more detail of a=20 >> not-RPL-aware-leaf in the document. >> >> 2017-07-18 13:23 GMT+02:00 peter van der Stok : >> >>> section 2, rpl-not-capable; how can this node be a leaf of a DODAG. >>> It can be a neighbour of a DODAG node but not a leaf in my=20 >>> understanding >>> >>> I understand that we can have it. Please someone correct me if I am=20 >>> wrong. >>> >>> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only: >>> >>> - A leaf node (only) does not ever participate as a RPL router. >>> >>> - Support of a particular MOP encoding is not required >>> >>> - Support of a particular OF is not required. >>> >>> - A leaf node does not generally issue DIO messages, >>> >>> - it may issue DAO and DIS messages. A leaf node accepts DIO=20 >>> messages though it generally ignores DAO and DIS messages (not=20 >>> applied in our case) >> >> A leaf node accepts DIO messages and is thus RPL-aware in my=20 >> understanding; >> >> Peter > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Sun Aug 20 20:05:39 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273131200F3 for ; Sun, 20 Aug 2017 20:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=runbox.com 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 8Vav3f6ixNqr for ; Sun, 20 Aug 2017 20:05:35 -0700 (PDT) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (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 87EFC132386 for ; Sun, 20 Aug 2017 20:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Subject:From; bh=YKhF6R1x3CUn9aOv3uZNazTGtXRilBpQwVNqgAiBAxM=; b=GFnKFoVHlZEko524JXykMZcVxWBU3Gw728hdQCl4p9LE1mxJaTEfbN05hFOmtFTTUhe33R5oNX VNzCgzmFAnAQxwSI2g0GikEdseVsqpRIQAWuQKLDtZINfQaAKc4XySMspRFjDbRSACoAPsFmD/ABH ORhQ0cUP3RGJDm+peLytzE5cHAOqa+2wpyBh7APe0IEKbcnToeyMZ4GGY++sPsVVLDOV9KUzlXYwU 6Ql3IC6lOtj9t/qKkVda6Q+naxjV0YSXbvLkvET999hkFrheE93GTpRx765zQ4IWhy+VrOOOjCVwX dErRXEG8hYEMeb/8n/n1r7wIwyfVD7OPZegDg==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1djd1w-0008VY-G1 for roll@ietf.org; Mon, 21 Aug 2017 05:05:32 +0200 Received: from c-73-227-92-48.hsd1.ma.comcast.net ([73.227.92.48] helo=[10.52.33.6]) by mailfront10.runbox.com with esmtpsa (uid:798146 ) (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) id 1djd1t-0002UZ-05 for roll@ietf.org; Mon, 21 Aug 2017 05:05:29 +0200 From: Ken Bannister To: ROLL Message-ID: <2e79d9c2-2bf9-60e0-14a3-ebda70b4ce73@runbox.com> Date: Sun, 20 Aug 2017 23:05:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Roll] RPL visualization tools X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 03:05:38 -0000 Can anyone point me to tools that allow visualization of an RPL-based network? I'm particularly interested in open source solutions that accept live network data. I'd like to see the relationships between nodes, with rank values and objective function parameters. I'm aware of Foren6 and OpenVisualizer's web UI. Is there anything else? Thanks, Ken From nobody Sun Aug 20 20:59:29 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DC4132402 for ; Sun, 20 Aug 2017 20:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5] 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 U3fhgBrqRAUt for ; Sun, 20 Aug 2017 20:59:26 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 9B25E132400 for ; Sun, 20 Aug 2017 20:59:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.41,407,1498514400"; d="scan'208,217";a="234883556" Received: from mail-vk0-f50.google.com ([209.85.213.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 21 Aug 2017 05:59:23 +0200 Received: by mail-vk0-f50.google.com with SMTP id d124so46621051vkf.2 for ; Sun, 20 Aug 2017 20:59:23 -0700 (PDT) X-Gm-Message-State: AHYfb5hX0eWhRmnjMp9j5vsbGKJ2zZuaWKCvTlKIpD/Npsj76S6S9x66 FA5sm5x8+rr+Icuw9rkboRRcTk7vRg== X-Received: by 10.31.41.204 with SMTP id p195mr8872365vkp.80.1503287961923; Sun, 20 Aug 2017 20:59:21 -0700 (PDT) MIME-Version: 1.0 References: <2e79d9c2-2bf9-60e0-14a3-ebda70b4ce73@runbox.com> In-Reply-To: <2e79d9c2-2bf9-60e0-14a3-ebda70b4ce73@runbox.com> From: Thomas Watteyne Date: Mon, 21 Aug 2017 03:59:10 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="001a113ed596f73af905573b806d" Archived-At: Subject: Re: [Roll] RPL visualization tools X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 03:59:28 -0000 --001a113ed596f73af905573b806d Content-Type: text/plain; charset="UTF-8" Ken, I don't know of any else, but would be interested in learning. Thomas On Sun, 20 Aug 2017 at 20:05 Ken Bannister wrote: > Can anyone point me to tools that allow visualization of an RPL-based > network? I'm particularly interested in open source solutions that > accept live network data. I'd like to see the relationships between > nodes, with rank values and objective function parameters. > > I'm aware of Foren6 and OpenVisualizer's web UI. Is there anything else? > > Thanks, > Ken > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a113ed596f73af905573b806d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ken,
I don't know of any = else, but would be interested in learning.
Thomas
On Sun, 20 Aug 2017 at 20:05 Ken Ban= nister <kb2ma@runbox.com> wro= te:
Can anyone point me to tools th= at allow visualization of an RPL-based
network? I'm particularly interested in open source solutions that
accept live network data. I'd like to see the relationships between
nodes, with rank values and objective function parameters.

I'm aware of Foren6 and OpenVisualizer's web UI. Is there anything = else?

Thanks,
Ken

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--

Thomas Watteyne, P= hD
Research Scientist & Innovator, Inria
Sr Networking Design E= ng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
=
Co-chair= , IETF 6TiSCH

________________________________= _______
--001a113ed596f73af905573b806d-- From nobody Mon Aug 21 07:01:44 2017 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B987124207; Mon, 21 Aug 2017 07:01:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: roll-chairs@ietf.org, aretana@cisco.com, roll@ietf.org, maria.ines.robles@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150332410234.6884.2294093916545592277.idtracker@ietfa.amsl.com> Date: Mon, 21 Aug 2017 07:01:42 -0700 Archived-At: Subject: [Roll] roll - New Meeting Session Request for IETF 100 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:01:42 -0000 A new meeting session request has just been submitted by Ines Robles, a Chair of the roll working group. --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Ines Robles Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: 6man anima manet 6lo 6tisch core Second Priority: lpwan rtgarea t2trg lwig Third Priority: ace ipwave pce rtgwg intarea People who must be present: Michael Richardson Peter Van der Stok Alvaro Retana Ines Robles Resources Requested: Special Requests: Meetecho Support --------------------------------------------------------- From nobody Mon Aug 21 11:49:38 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79E11320C9 for ; Mon, 21 Aug 2017 11:49:35 -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, 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 uRrI0luSIOQj for ; Mon, 21 Aug 2017 11:49:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27AF01241FC for ; Mon, 21 Aug 2017 11:49:33 -0700 (PDT) Received: from dooku.sandelman.ca (modemcable017.184-58-74.mc.videotron.ca [74.58.184.17]) by relay.sandelman.ca (Postfix) with ESMTPS id 12B5A1F906 for ; Mon, 21 Aug 2017 18:49:31 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id A48791CCB; Mon, 21 Aug 2017 20:49:09 +0200 (CEST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: References: <2e79d9c2-2bf9-60e0-14a3-ebda70b4ce73@runbox.com> Comments: In-reply-to Thomas Watteyne message dated "Mon, 21 Aug 2017 03:59:10 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 21 Aug 2017 14:49:09 -0400 Message-ID: <5260.1503341349@dooku.sandelman.ca> Archived-At: Subject: Re: [Roll] RPL visualization tools X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 18:49:36 -0000 --=-=-= Content-Type: text/plain Thomas Watteyne wrote: > Ken, I don't know of any else, but would be interested in learning. Ken> Can anyone point me to tools that allow visualization of an ken> RPL-based network? What we need is a standard form for the data to be in! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZmyslAAoJEJVM4Vb9/EKQL2IH/2BMSP6iLiNerhGTcRAjEU/e bIZxqGWUqMpywN9Lf/l533KFUJJGZ4/qIIteLxBCp0Sbp5dalV4baPtMzC102L2E jkd9loPBEkprDzwafiSg7GosyZSLjP0MKq367A6vkXuNU5DS2agOmgHxY1jM3ubb MkQh/kGu1vElgGhOnHAL2DJFI0eUd/6qo0CyuZXhjBb6vk7jq8OxHO7OyLu7D12L TLQbLSpHj47eymaFEmX6tkdMkP555AbfGbMwnDUdfMS5n+KlaQ7LHe7ag2OTG6KM 8jYeLgdFPILKipZF/nzGl+7G8ww6ljAf5Q2E5ZLCrrF5qLyfqija5siQ2PsU8zc= =YwPs -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 21 16:41:47 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C01213219F for ; Mon, 21 Aug 2017 16:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 BXJCbgJsCsL5 for ; Mon, 21 Aug 2017 16:41:43 -0700 (PDT) Received: from atl4mhob08.registeredsite.com (atl4mhob08.registeredsite.com [209.17.115.46]) (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 7E26D13218F for ; Mon, 21 Aug 2017 16:41:43 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob08.registeredsite.com (8.14.4/8.14.4) with ESMTP id v7LNfeYu003956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 21 Aug 2017 19:41:40 -0400 Received: (qmail 9855 invoked by uid 0); 21 Aug 2017 23:41:40 -0000 X-TCPREMOTEIP: 73.207.234.73 X-Authenticated-UID: rturner@amalfisystems.com Received: from unknown (HELO ?10.0.1.45?) (rturner@amalfisystems.com@73.207.234.73) by 0 with ESMTPA; 21 Aug 2017 23:41:40 -0000 From: Randy Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 21 Aug 2017 19:40:36 -0400 References: <2e79d9c2-2bf9-60e0-14a3-ebda70b4ce73@runbox.com> <5260.1503341349@dooku.sandelman.ca> To: Routing Over Low power and Lossy networks In-Reply-To: <5260.1503341349@dooku.sandelman.ca> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Roll] RPL visualization tools X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 23:41:45 -0000 +1 - a standard format for exporting RPL topology info would be a good = start. R. > On Aug 21, 2017, at 2:49 PM, Michael Richardson = wrote: >=20 >=20 > Thomas Watteyne wrote: >> Ken, I don't know of any else, but would be interested in learning. >=20 >=20 > Ken> Can anyone point me to tools that allow visualization of = an > ken> RPL-based network? >=20 > What we need is a standard form for the data to be in! >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Aug 28 02:37:30 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B081A132811 for ; Mon, 28 Aug 2017 02:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 XK9ffpMTBQoV for ; Mon, 28 Aug 2017 02:37:28 -0700 (PDT) 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 02B871201F8 for ; Mon, 28 Aug 2017 02:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1898; q=dns/txt; s=iport; t=1503913047; x=1505122647; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5xuqcqrITxOahqC7zNr9ELCmEio/B4S3MDWURR0Bs4g=; b=NZl5rgpMIbawBdCjZmCV3YpfgZsi2o1u2lWYGn5OmwzYRxyJ87m9wAxT CAov8LZug+XvXwCNealQdJJYOTQQDUcwsMOxhR9Rk6QRoxgwbKsLhae+p lVBxz1NaxITVNtqIbL7x1VQJZuHAWY1/3RQGgApDHEMcNppqZ6nAU6opO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAAC546NZ/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjg2QFYFxliaCEiELgWCDOwKDcj8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGAEBAQECAQEBawEQBwQCAQgRBAEBAScHJwsUCQgCBBMIiiEIELQVi1oBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYMqggKBToFjgRqCDoRZhhAFkWyOeAKUO4IbhWa?= =?us-ascii?q?KcJY8AR84gQ13FUmHG3aJWYEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,441,1498521600"; d="scan'208";a="70224038" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 09:37:26 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7S9bQvl005579 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 28 Aug 2017 09:37:26 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 Aug 2017 04:37:26 -0500 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.1263.000; Mon, 28 Aug 2017 04:37:26 -0500 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] RPL visualization tools Thread-Index: AQHTGipiGBiVEv2CfUeMomwcGSZ0p6KOgywAgAD4qYCAAFFuAIAJvxuA Date: Mon, 28 Aug 2017 09:37:25 +0000 Deferred-Delivery: Mon, 28 Aug 2017 09:36:55 +0000 Message-ID: References: <2e79d9c2-2bf9-60e0-14a3-ebda70b4ce73@runbox.com> <5260.1503341349@dooku.sandelman.ca> In-Reply-To: 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.228.216.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] RPL visualization tools X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 09:37:30 -0000 Agreed, Randy. Please note that in non storing the root has all the information to build a= n internal representation of the usable DODAG, but - that is not true for storing - a child may not expose all its parents to the root though it may use them= to send traffic up - the siblings are not exposed There appears to be a need to provide more information to the root so it ca= n use it for its own purposes, e.g. route projection. There could also be a need for the root to export its topological knowledge= to an external PCE/NME. Finally, there is work at TEAS that may be leveraged to expose this, but TE= AS will not be aware of wireless specifics such as the value or the duratio= n of the coherence of a metric. cheers, Pascal -----Original Message----- From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Randy Turner Sent: mardi 22 ao=FBt 2017 01:41 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] RPL visualization tools +1 - a standard format for exporting RPL topology info would be a good star= t. R. > On Aug 21, 2017, at 2:49 PM, Michael Richardson w= rote: >=20 >=20 > Thomas Watteyne wrote: >> Ken, I don't know of any else, but would be interested in learning. >=20 >=20 > Ken> Can anyone point me to tools that allow visualization of an > ken> RPL-based network? >=20 > What we need is a standard form for the data to be in! >=20 > -- > Michael Richardson , Sandelman Software Works=20 > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jim.list@hotmail.com Tue Aug 29 11:52:13 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E56132C47 for ; Tue, 29 Aug 2017 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com 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 xKJCu9ftj2_M for ; Tue, 29 Aug 2017 11:52:11 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-sn1nam04olkn0802.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4c::802]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA17132955 for ; Tue, 29 Aug 2017 11:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n0h7udPWQTPrz1QkZIoXKUPNGIpiRoM/7mYE42Pi7XM=; b=gMlIbRIMePbAfgx76YROLrwWIVJOBXYFdgB4X144bLLU248NKQfj51XYgnD2n0fTNjt1g41kRrt3dn0+1M5XRKH7vB0ku7GXAA3nHFz/NINlq25ZeP7ukQdaEgBkR7OpIdYJvKMGdlJPKryFXlho2y6DrT7CY6FjcSGv+oMm+Sa109txp6ZZKeC4cZik/8qECfW6V64CPGvlLTBHfShwTDyLGGFHmDJQuYSNZjn+WRNgHGvI8mE5h/ZafcMxvrnAx9A1k35y7X8H6dIjTKlxTJK6RXzni7CGYZeI81EFzNqPp7+IxzIKiiHCFrq2l78UwQTNyFSFQPIipm/qUrnnHg== Received: from SN1NAM04FT010.eop-NAM04.prod.protection.outlook.com (10.152.88.59) by SN1NAM04HT045.eop-NAM04.prod.protection.outlook.com (10.152.88.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1385.11; Tue, 29 Aug 2017 18:51:52 +0000 Received: from CO2PR03MB2198.namprd03.prod.outlook.com (10.152.88.58) by SN1NAM04FT010.mail.protection.outlook.com (10.152.88.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1385.11 via Frontend Transport; Tue, 29 Aug 2017 18:51:52 +0000 Received: from CO2PR03MB2198.namprd03.prod.outlook.com ([10.166.92.21]) by CO2PR03MB2198.namprd03.prod.outlook.com ([10.166.92.21]) with mapi id 15.01.1385.010; Tue, 29 Aug 2017 18:51:52 +0000 From: James Ko To: "roll@ietf.org" Thread-Topic: MPL leaf node behaviour Thread-Index: AQHTIPdoOvPaLEa6KEWDiBVeON4mEA== Date: Tue, 29 Aug 2017 18:51:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:221CA9FA5B3291DDEB87E1F90D91617FEBA87EC40909367F2D46D088DA43ED7C; UpperCasedChecksum:016FA7E82DB9A5C033C88F4BEA03FA17402581D28DC61CF22B51BD3FE2414A43; SizeAsReceived:6793; Count:44 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [C3J225BFRH5PuBhyZExpuidRkpPhAO05] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT045; 6:S72cMd3wOd2GzZ1YjRTxxjFiUoQybwFp7EA+QooEohJijdhBrywHGQ9/qjKlGbhxfO9HveCWMmVqFlDrayF1yPdn/XxrcyCyr2S39wP3/Vov33OjHXtBsa3uc/fayWvQ6vEUTHLupxw6VeEuhLI7c4arvn+/vuv7nB2Qbst42fexvxRahMhAdN0vxsLQu+ulWlf6qTqj6ihhRy208HsqnO7ZGTL1Ql6lCxmY9F3NYENQC1Y8rLUEG+amXEfpmdYnizCTpAAtvFARUJDMauM11OJR574fb30EKLRdG3/slly0SWM5TVOynNWKl0nZbq/tyQRrei4Us4UzBUbPw/gCMw==; 5:vpQhJRdl86f1VFaqBZfnGtSlCeALz4mV6uuMM66NnA61dRNyC9W8vErXEpfH5hsv2TtVVF/bSUbYTGGn6eoKEkkpbv1qc13i23hrRANBtPTE6KAtEJdTlkbjN54wQynkmxmG6OjJKNItRjaqyzMe3w==; 24:NSJBV6MFZluJBvVbOxyGzkgcA15k+vwjNo7agNf6tfngcs2kw15D1uKFzW52a9sS5zY/JfQ/xW4dhLE5wPMbdkDzE/ZQ7PS4dfxeEgGGZ+U=; 7:RCdn8jI/uyHBSM9m0o8Ty3nnI8oxIH9aR+juBVJZOU9fsinJNFWQMhTH+K1VKCeeG6vxLksfsZurAF0wyGb2mIQotG6rjGv7+ZgD6sSUNTKHAdrJvDe0DJCkOQIdfLRNwfakRsquOiQ/W0yXykjPZ8+jMcu4yvfVKSbMUwSkESdMWZuUlR4NlcuhjiBNM0tE/zTkBnDY/EpW/frgaOerenGux6g7mC4qs4Txh4K7sgc= x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 0ed29291-0eaa-4b1f-84e6-08d4ef0f0378 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1NAM04HT045; x-ms-traffictypediagnostic: SN1NAM04HT045: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:SN1NAM04HT045; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1NAM04HT045; x-forefront-prvs: 0414DF926F x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT045; H:CO2PR03MB2198.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB21988E7723DCD47ADCBB95AEFD9F0CO2PR03MB2198namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 18:51:52.5829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT045 Archived-At: Subject: [Roll] MPL leaf node behaviour X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 19:21:18 -0000 --_000_CO2PR03MB21988E7723DCD47ADCBB95AEFD9F0CO2PR03MB2198namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable During testing of my implementation of MPL I found that the leaf nodes in a= mesh network (or the last MPL Forwarder to receive a multi-cast packet) wo= uld continue to retransmit at every trickle time 't', until expiration 'e' = is reached, since it does not receive the same number of 'consistent' trans= missions from a neighbour and count 'c' never reaches the consistency const= ant 'k'. Example with k =3D 2, seq [1], nodes Node <1> Node <2> Node <3> TX[1], c =3D 0 RX[1] from <1>, c =3D 0 RX[1] from <2>, c=3D1 TX[1], c =3D 0 RX[1] from <2>, c =3D 0 TX[1], c =3D 1 RX[1], from <1>, c =3D 1 TX[1], c =3D 0 RX[1] from <2>, c =3D 2 TX[1], c =3D 1 RX[1] from <2>, c =3D 1 RX[1] from <3>, c =3D 2 TX[1], c =3D 1 RX[1] from <3>, c =3D 3 TX[1], c =3D 1 RX[1] from <3>, c =3D 4 TX[1], c =3D 1 Node <3> would continue to retransmit [1] until 'e' expirations. Even if r= eactive forwarding is enabled (CONTROL_MSG_EXPIRATIONS !=3D 0) and a 'consi= stent' control message is received it does not increment 'c' for the data m= essages. The data message trickle is reset only for 'inconsistent' message= s identified by the control message. If the expirations 'e' is large, what, if any, strategies could be used to = prevent the leaf node from continuing to transmit since it never receive k = number of consistent transmissions? One possible strategy is if reactive forwarding is also enabled then a data= message should only be transmitted if 'c' < 'k' for both the data message = and the control message. Of course, this leaf node consistency problem also exists for the control m= essages following the trickle algorithm. James --_000_CO2PR03MB21988E7723DCD47ADCBB95AEFD9F0CO2PR03MB2198namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

During testing of my implementation of MPL I found that the leaf nodes i= n a mesh network (or the last MPL Forwarder to receive a multi-cast packet)= would continue to retransmit at every trickle time 't', until expiration '= e' is reached, since it does not receive the same number of 'consistent' transmissions from a neighbour and= count 'c' never reaches the consistency constant 'k'.


Example with k =3D 2, seq [1], nodes <n>

Node <1>
 Node <2>
 Node <3>
TX[1], c =3D 0
 RX[1] from <1>, c =3D 0
RX[1] from <2>, c=3D1
 TX[1], c =3D 0
 RX[1] from <2>, c =3D 0
TX[1],  c =3D 1
 RX[1], from <1>, c =3D 1
 TX[1], c =3D 0
RX[1] from <2>, c =3D 2
 TX[1], c =3D 1
 RX[1] from <2>, c =3D 1

RX[1] from <3>, c =3D 2
 TX[1], c =3D 1

RX[1] from <3>,  c =3D 3
 TX[1], c =3D 1

RX[1] from <3>,  c =3D 4
 TX[1], c =3D 1




Node <3> would continue to retransmit [1] until 'e' expirati= ons.  Even if reactive forwarding is enabled (CONTROL_MSG_EXPIRATIONS = !=3D 0) and a 'consistent' control message is received it does not incremen= t 'c' for the data messages.  The data message trickle is reset only for 'inconsistent' messages identified by the contro= l message.


If the expirations 'e' is large, what, if any, strategies could be= used to prevent the leaf node from continuing to transmit since it never r= eceive k number of consistent transmissions?


One possible strategy is if reactive forwarding is also enabled th= en a data message should only be transmitted if 'c' < 'k' for both the d= ata message and the control message.


Of course, this leaf node consistency problem also exists for the = control messages following the trickle algorithm.


James


--_000_CO2PR03MB21988E7723DCD47ADCBB95AEFD9F0CO2PR03MB2198namp_-- From nobody Wed Aug 30 00:11:50 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C6C132DD4 for ; Wed, 30 Aug 2017 00:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1pCsWlKIq0LR for ; Wed, 30 Aug 2017 00:11:47 -0700 (PDT) Received: from lb3-smtp-cloud8.xs4all.net (lb3-smtp-cloud8.xs4all.net [194.109.24.29]) (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 018BB132DD8 for ; Wed, 30 Aug 2017 00:11:46 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:216]) by smtp-cloud8.xs4all.net with ESMTPA id mxA8diZkfcQyLmxA8d3KAm; Wed, 30 Aug 2017 09:11:45 +0200 Received: from 83-161-161-241.mobile.xs4all.nl ([83.161.161.241]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 30 Aug 2017 09:11:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 30 Aug 2017 09:11:44 +0200 From: peter van der Stok To: Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: References: Message-ID: <109cc707217eef50b9a48b9eb6b353c4@xs4all.nl> X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfITY6/tovABODcvSo2pnFk7ZAw+ltrUnFdxILBApKSKLgZXEY4kbI2V2K61vL1fgVm3UwOIcMq4n3joJ4QPAnh9lB6t3Cw3EHPFPni4JPmTXicDRqlDs eS1yJtwusxj1lhXJRbP2B12EJVqq8m3UU8ZZTWgFXdyRYjsPGJeYmeBCQCVjGj2zQEVMBzJORyklxU/tsvAzRO2V4HBv6g217sI= Archived-At: Subject: Re: [Roll] MPL leaf node behaviour X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 07:11:50 -0000 Hi James, Does TX[1] mean the sending of message 1? When is the new interval started? c should be reset to 0; I don't see that happening. And yes, MPL continues sending till the maximum number of events is reached or the message is too old. Is node 1 the seed; does it resend as well? Setting the max number of events to for example 2 will help, but is reliability assured then? At the edges of the network you may expect atypical behavior compared to the behavior of the other nodes related to the evolution of c value. Peter James Ko schreef op 2017-08-29 20:51: > During testing of my implementation of MPL I found that the leaf nodes > in a mesh network (or the last MPL Forwarder to receive a multi-cast > packet) would continue to retransmit at every trickle time 't', until > expiration 'e' is reached, since it does not receive the same number > of 'consistent' transmissions from a neighbour and count 'c' never > reaches the consistency constant 'k'. > > Example with k = 2, seq [1], nodes > > Node <1> > Node <2> > Node <3> > > TX[1], c = 0 > RX[1] from <1>, c = 0 > > RX[1] from <2>, c=1 > TX[1], c = 0 > RX[1] from <2>, c = 0 > > TX[1], c = 1 > RX[1], from <1>, c = 1 > TX[1], c = 0 > > RX[1] from <2>, c = 2 > TX[1], c = 1 > RX[1] from <2>, c = 1 > > RX[1] from <3>, c = 2 TX[1], c = 1 > > RX[1] from <3>, c = 3 > TX[1], c = 1 > > RX[1] from <3>, c = 4 TX[1], c = 1 > > Node <3> would continue to retransmit [1] until 'e' expirations. Even > if reactive forwarding is enabled (CONTROL_MSG_EXPIRATIONS != 0) and a > 'consistent' control message is received it does not increment 'c' for > the data messages. The data message trickle is reset only for > 'inconsistent' messages identified by the control message. > > If the expirations 'e' is large, what, if any, strategies could be > used to prevent the leaf node from continuing to transmit since it > never receive k number of consistent transmissions? > > One possible strategy is if reactive forwarding is also enabled then a > data message should only be transmitted if 'c' < 'k' for both the data > message and the control message. > > Of course, this leaf node consistency problem also exists for the > control messages following the trickle algorithm. > > James > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 30 00:50:04 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7FC132386 for ; Wed, 30 Aug 2017 00:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com 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 Ga2GT6StVlkG for ; Wed, 30 Aug 2017 00:49:49 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010016.outbound.protection.outlook.com [40.92.10.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93971326FE for ; Wed, 30 Aug 2017 00:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aa2dVzC1La+/o1GiFyIWSX3oAsXBM07CjNMIQXrG8ns=; b=NnnO3ZACevlP6oHmXZVRnYnAgzWldKyXllo7oJxfD82EjxjlRDCfetr4G7YTSIH1GdD84ZoqRQSnkS3oDooDJ0GRSRXKJO0YyVqKP3MKuNgZtzXgzYCe6BqET9RMi3qg8lnQ36y/s3Ek/ppfyfNKetW6wLWjo2yi0Uk3LyzRaGAqcJUno5sVUlu5z/hcwhwUMwMsNO2XYqH/66Jk5kbQWrCHhiXz3qMS9zgavtosxQKUbgwvWpnKc6AhQLMXCI7jy/hpG8tey8Xv4TnClTFri3xsO1HsxdfsHlkAj/Zb7eeDGrHi8vbYUONqDD7YYebORqR8/InzLSX+r8ypwSbDwQ== Received: from CO1NAM04FT022.eop-NAM04.prod.protection.outlook.com (10.152.90.56) by CO1NAM04HT222.eop-NAM04.prod.protection.outlook.com (10.152.90.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1341.15; Wed, 30 Aug 2017 07:49:47 +0000 Received: from CO2PR03MB2198.namprd03.prod.outlook.com (10.152.90.58) by CO1NAM04FT022.mail.protection.outlook.com (10.152.90.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1385.11 via Frontend Transport; Wed, 30 Aug 2017 07:49:47 +0000 Received: from CO2PR03MB2198.namprd03.prod.outlook.com ([10.166.92.21]) by CO2PR03MB2198.namprd03.prod.outlook.com ([10.166.92.21]) with mapi id 15.01.1385.010; Wed, 30 Aug 2017 07:49:47 +0000 From: James Ko To: Routing Over Low power and Lossy networks , "consultancy@vanderstok.org" Thread-Topic: [Roll] MPL leaf node behaviour Thread-Index: AQHTIPdoOvPaLEa6KEWDiBVeON4mEKKcfIkAgAAKobY= Date: Wed, 30 Aug 2017 07:49:47 +0000 Message-ID: References: , <109cc707217eef50b9a48b9eb6b353c4@xs4all.nl> In-Reply-To: <109cc707217eef50b9a48b9eb6b353c4@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:5F9BFBDBEEB6EC896711622D5E24698D1BA94444E091B4FC04124402C3DE3627; UpperCasedChecksum:B27A7EB8883726AC1BD7BB6039FAADB8D8093EAFB0CB960324DB879139511EA1; SizeAsReceived:7083; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [Ei/axijBqW0fW9qfePZxhQ9n33Qj0vYz] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM04HT222; 6:o3MtGf1OQYnENOfDirpIJx6oB6ahF8jpSbiIV9NXXr4FazM1XWqh8MMn0IE0XF2cXvC2LATuwU+n5qWFzzQjNZpKx9SDnh5F7RX6QmqiZ72aRMRhC7zJR34lrAhDiNVQnPDmxSJoW0BoZlSDm4iIjW656LFwSD2r1hNRSO5SAeOxCG4JuXKlsfTrxgW17FOhFJH/XeFbWAKZnot/3JXDsHFyEHruqzyS2EiYpNUGmPLPB/txgkcfDdx+NZeWEc7EuY2LYt4GpO4u8UW6uAIAo+/uAf9QNECnFl0njI3HdzKDHr0f/33vIPRCR2PLWTSN7m6W33IGEbkha5Yhv/Uwbg==; 5:vZ+xnh0MqxTpzJDDolgUtVv4zQY72IIwvX0cIllt8t89AMsCb+qyKVBdsBqbmIcbwxx7QKBsN5XX4MIzyEZzVqw9Y35Oliy+ScPk1qdTjdZc61mGV1ByGRs8y+YzXN5c9Lg7HzMJMNSkUOyOW/6VpA==; 24:FQfkVt+TWv84c/6cCBOYxKGzDoHOnY1HNdwQ2glUvYuctNRW74O5JYqctlhmjUNhQ0ZnHxyLWawHWi2Warr4Qw1dXuYUIDD/oyZBM9eguz8=; 7:kg7cSptoPqNxRBLdiL+fWKm68dE7B05P9zluAtmz7SzYlRmLI6PUjLguhTvD5p2Lshu2toc4JN/2+rZQGhMAXqP01GUtaPcaGWyhEOy+tdKjRZ1J4DAGJ+POyQuVV7XP04aga4nu6oAFOgUTNtX6KaBWLLMwU19Tfdr110D3/2x5Crb+Tn77Fsfz+b+UoG8HvvHo8hsoeLGqesAtbdEo/42o62DRcjgSlAw0YgABj0s= x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: ced4676c-fa1f-4ffa-fb38-08d4ef7bafc1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CO1NAM04HT222; x-ms-traffictypediagnostic: CO1NAM04HT222: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:CO1NAM04HT222; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO1NAM04HT222; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT222; H:CO2PR03MB2198.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2198C455FB6A3727108F82C0FD9C0CO2PR03MB2198namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 07:49:47.3105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT222 Archived-At: Subject: Re: [Roll] MPL leaf node behaviour X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 07:49:52 -0000 --_000_CO2PR03MB2198C455FB6A3727108F82C0FD9C0CO2PR03MB2198namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Yes. TX[1] is data message with sequence number 1. The new interval is started with node 1 sending message 1. Node 2 receivin= g msg 1 and retransmitting it. c is set to 0 on first TX/RX and reset if a= n inconsistent transmission is received. There are no inconsistent transmi= ssions shown in my example. For each consistent message received the count= c increases but the edge node doesn't receive the same number of consisten= t transmissions as the other nodes. For low powered nodes at the edges of the network this atypical behavior wo= uld unnecessarily consume power and bandwidth. Are there recommended it be= st practice strategies for edge nodes to achieve c>=3Dk. James From: peter van der Stok Sent: Wednesday, August 30, 00:11 Subject: Re: [Roll] MPL leaf node behaviour To: Routing Over Low power and Lossy networks Hi James, Does TX[1] mean the sending of message 1? When is the new interva= l started? c should be reset to 0; I don't see that happening. And yes, MPL= continues sending till the maximum number of events is reached or the mess= age is too old. Is node 1 the seed; does it resend as well? Setting the max= number of events to for example 2 will help, but is reliability assured th= en? At the edges of the network you may expect atypical behavior compared t= o the behavior of the other nodes related to the evolution of c value. Pete= r James Ko schreef op 2017-08-29 20:51: > During testing of my implementati= on of MPL I found that the leaf nodes > in a mesh network (or the last MPL = Forwarder to receive a multi-cast > packet) would continue to retransmit at= every trickle time 't', until > expiration 'e' is reached, since it does n= ot receive the same number > of 'consistent' transmissions from a neighbour= and count 'c' never > reaches the consistency constant 'k'. > > Example wi= th k =3D 2, seq [1], nodes > > Node > Node > Node > > TX[1], c =3D 0 > RX[1= ] from , c =3D 0 > > RX[1] from , c=3D1 > TX[1], c =3D 0 > RX[1] from , c = =3D 0 > > TX[1], c =3D 1 > RX[1], from , c =3D 1 > TX[1], c =3D 0 > > RX[1]= from , c =3D 2 > TX[1], c =3D 1 > RX[1] from , c =3D 1 > > RX[1] from , c = =3D 2 TX[1], c =3D 1 > > RX[1] from , c =3D 3 > TX[1], c =3D 1 > > RX[1] fr= om , c =3D 4 TX[1], c =3D 1 > > Node would continue to retransmit [1] until= 'e' expirations. Even > if reactive forwarding is enabled (CONTROL_MSG_EXP= IRATIONS !=3D 0) and a > 'consistent' control message is received it does n= ot increment 'c' for > the data messages. The data message trickle is reset= only for > 'inconsistent' messages identified by the control message. > > = If the expirations 'e' is large, what, if any, strategies could be > used t= o prevent the leaf node from continuing to transmit since it > never receiv= e k number of consistent transmissions? > > One possible strategy is if rea= ctive forwarding is also enabled then a > data message should only be trans= mitted if 'c' < 'k' for both the data > message and the control message. > = > Of course, this leaf node consistency problem also exists for the > contr= ol messages following the trickle algorithm. > > James > __________________= _____________________________ > Roll mailing list > Roll@ietf.org > https:/= /www.ietf.org/mailman/listinfo/roll _______________________________________= ________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listi= nfo/roll --_000_CO2PR03MB2198C455FB6A3727108F82C0FD9C0CO2PR03MB2198namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Peter,

Yes.  TX[1] is data message with sequence number 1.
The new interval is started with node 1 sending message 1.  Node 2 rec= eiving msg 1 and retransmitting it.  c is set to 0 on first TX/RX and = reset if an inconsistent transmission is received.  There are no incon= sistent transmissions shown in my example.  For each consistent message received the count c increases but the edge node d= oesn't receive the same number of consistent transmissions as the other nod= es.

For low powered nodes at the edges of the network this atypical behavior wo= uld unnecessarily consume power and bandwidth.  Are there recommended = it best practice strategies for edge nodes to achieve c>=3Dk.

James



From: peter van der Stok
Sent: Wednesday, August 30, 00:11
Subject: Re: [Roll] MPL leaf node behaviour
To: Routing Over Low power and Lossy networks


Hi James, Does TX[1] mean the sending of message 1? When is the new interva= l started? c should be reset to 0; I don't see that happening. And yes, MPL= continues sending till the maximum number of events is reached or the mess= age is too old. Is node 1 the seed; does it resend as well? Setting the max number of events to for example 2 = will help, but is reliability assured then? At the edges of the network you= may expect atypical behavior compared to the behavior of the other nodes r= elated to the evolution of c value. Peter James Ko schreef op 2017-08-29 20:51: > During testing of my impl= ementation of MPL I found that the leaf nodes > in a mesh network (or th= e last MPL Forwarder to receive a multi-cast > packet) would continue to= retransmit at every trickle time 't', until > expiration 'e' is reached, since it does not receive the same number = > of 'consistent' transmissions from a neighbour and count 'c' never >= ; reaches the consistency constant 'k'. > > Example with k =3D 2, seq= [1], nodes > > Node > Node > Node > > TX[1], c =3D 0 > RX[1] from , c =3D 0 > > RX[1] from , c=3D1 > TX[1], c =3D= 0 > RX[1] from , c =3D 0 > > TX[1], c =3D 1 > RX[1], from , c = =3D 1 > TX[1], c =3D 0 > > RX[1] from , c =3D 2 > TX[1], c =3D = 1 > RX[1] from , c =3D 1 > > RX[1] from , c =3D 2 TX[1], c =3D 1 &= gt; > RX[1] from , c =3D 3 > TX[1], c =3D 1 > > RX[1] from , c =3D 4 TX[1], c =3D 1 > > Node would= continue to retransmit [1] until 'e' expirations. Even > if reactive fo= rwarding is enabled (CONTROL_MSG_EXPIRATIONS !=3D 0) and a > 'consistent= ' control message is received it does not increment 'c' for > the data messages. The data message trickle is reset only for > 'i= nconsistent' messages identified by the control message. > > If the e= xpirations 'e' is large, what, if any, strategies could be > used to pre= vent the leaf node from continuing to transmit since it > never receive k number of consistent transmissions? > >= ; One possible strategy is if reactive forwarding is also enabled then a &g= t; data message should only be transmitted if 'c' < 'k' for both the dat= a > message and the control message. > > Of course, this leaf node consistency problem also exists for the > control messag= es following the trickle algorithm. > > James > __________________= _____________________________ > Roll mailing list > Roll@ietf.org >= ; https://www.ietf.org/mailman/listinfo/roll ______________________________= _________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll=

--_000_CO2PR03MB2198C455FB6A3727108F82C0FD9C0CO2PR03MB2198namp_-- From nobody Wed Aug 30 02:50:25 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0A1326FE for ; Wed, 30 Aug 2017 02:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Mpohl0eH2ucy for ; Wed, 30 Aug 2017 02:50:21 -0700 (PDT) Received: from mx-b.polytechnique.fr (mx-b.polytechnique.fr [129.104.30.15]) by ietfa.amsl.com (Postfix) with ESMTP id B3AE01323F7 for ; Wed, 30 Aug 2017 02:50:20 -0700 (PDT) Received: from zimbra.polytechnique.fr (zimbra.polytechnique.fr [129.104.69.30]) by mx-b.polytechnique.fr (tbp 5.3.2/2.0.7) with ESMTP id v7U9Ptgr020188 for ; Wed, 30 Aug 2017 11:25:56 +0200 Received: from localhost (localhost [127.0.0.1]) by zimbra.polytechnique.fr (Postfix) with ESMTP id C6BC07200DE for ; Wed, 30 Aug 2017 11:25:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.polytechnique.fr Received: from zimbra.polytechnique.fr ([127.0.0.1]) by localhost (zimbra.polytechnique.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Vcn1vFrrZSnp for ; Wed, 30 Aug 2017 11:25:55 +0200 (CEST) Received: from [129.104.125.4] (webmail.polytechnique.fr [129.104.30.43]) by zimbra.polytechnique.fr (Postfix) with ESMTPSA id 66E1C7200B4 for ; Wed, 30 Aug 2017 11:25:55 +0200 (CEST) From: Juan-Antonio Cordero-Fuertes Content-Type: multipart/alternative; boundary="Apple-Mail=_A842CB1B-CC05-41A0-B643-6876C1788F27" Message-Id: <40BA2151-B63C-404C-BC75-3DED34A20291@polytechnique.edu> Date: Wed, 30 Aug 2017 11:25:55 +0200 To: roll@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Roll] On draft-ietf-roll-aodv-rpl-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 09:50:23 -0000 --Apple-Mail=_A842CB1B-CC05-41A0-B643-6876C1788F27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Concerning draft-ietf-roll-aodv-rpl-01, I have some comments / = questions: 1) Route discovery in AODV-RPL from OrigNode to TargNode is performed by = forming temporary paired DODAGs at OrigNode and TargNode (secs. 3 and = 4); these DODAGs are formed by multicasting RREQ-Instance and = RREP-Instance messages over the sensor network, respectively.=20 It is known that multicasting in wireless multi-hop ad hoc networks, and = in particular LLNs as those expected to use (Asymmetric) AODV-P2P-RPL, = is likely to lead to collisions and packet losses, more frequent as the = network is more dense, and jittering mechanisms (Inf. RFC 5148 [2]) have = been proposed in the IETF and implemented in MANET protocols using = multicasting or broadcasting, to reduce the probability of such = collisions. Route discovery in reactive routing protocols over LLNs is one of the = cases in which multicast RREQ collisions may severely degrade protocol = performance, and jittering may be helpful to reduce the number of = collisions. The use of random jittering mechanisms as proposed in RFC5148 [2] in = reactive route discovery may distort the routing metrics and lead to the = discovery and installation of suboptimal routes, as a result of the = "delay inversion" effect (sec. 3.1 [1]). However, this effect can be = alleviated with simple, easy-to-implement modifications of the original = jitter mechanism, also specified and evaluated in [1] (secs. 3.2, 3.3, 4 = and 5). Since packet collisions are inherent to route discoveries based on = multicast in LLNs, it may be helpful to address the problem in the draft = specification itself, and provide pointers to (or directly describe) = mechanisms to alleviate their impact by using optimized jittering = techniques. 2) I observe that Experimental RFC6997 [4] is mentioned as a normative = reference for this draft, for which the intended status is Standards = Track, although this practice is discouraged, if I understand correctly = (RFC2026 [2]). Is there any reason to keep RFC6997 as a normative = reference in this case? I mention this because my previous comment would = need to be applied as well to RFC6997, as "parent" of the draft, if used = as a normative reference to the intented-Standard = draft-ietf-roll-aodv-rpl-01 -- but would not be necessary for an = Experimental RFC.=20 Thanks a lot, Juan Antonio Cordero, PhD =C3=89cole polytechnique, Paris References [1] Juan Antonio Cordero, J. Yi, T. Clausen: An Adaptive Jitter = Mechanism for Reactive Route Discovery in Sensor Networks. Sensors = (Basel). 2014 Aug; 14(8): 14440=E2=80=9314471. doi:10.3390/s140814440 [2] RFC 5148, Informational [3] RFC 2026, BCP [4] RFC 6997, Experimental= --Apple-Mail=_A842CB1B-CC05-41A0-B643-6876C1788F27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Concerning draft-ietf-roll-aodv-rpl-01, I have some comments = / questions:

1) Route = discovery in AODV-RPL from OrigNode to TargNode is performed by = forming temporary paired DODAGs at OrigNode and TargNode (secs. 3 and = 4); these DODAGs are formed by multicasting RREQ-Instance and = RREP-Instance messages over the sensor network, respectively. 

It is known that multicasting in wireless = multi-hop ad hoc networks, and in particular LLNs as those expected to = use (Asymmetric) AODV-P2P-RPL, is likely to lead to collisions and = packet losses, more frequent as the network is more dense, and jittering = mechanisms (Inf. RFC 5148 [2]) have been proposed in the IETF and = implemented in MANET protocols using multicasting or broadcasting, to = reduce the probability of such collisions.

Route discovery in reactive routing protocols over LLNs is = one of the cases in which multicast RREQ collisions may severely degrade = protocol performance, and jittering may be helpful to reduce the number = of collisions.

The use of random jittering = mechanisms as proposed in RFC5148 [2] in reactive route discovery may = distort the routing metrics and lead to the discovery and installation = of suboptimal routes, as a result of the "delay inversion" effect (sec. = 3.1 [1]). However, this effect can be alleviated with simple, = easy-to-implement modifications of the original jitter mechanism, also = specified and evaluated in [1] (secs. 3.2, 3.3, 4 and 5).

Since packet collisions are inherent to route = discoveries based on multicast in LLNs, it may be helpful to address the = problem in the draft specification itself, and provide pointers to (or = directly describe) mechanisms to alleviate their impact by using = optimized jittering techniques.

2) I observe that Experimental RFC6997 [4] is mentioned = as a normative reference for this draft, for which the intended status = is Standards Track, although this practice is discouraged, if I = understand correctly (RFC2026 [2]). Is there any reason to keep RFC6997 = as a normative reference in this case? I mention this because my = previous comment would need to be applied as well to RFC6997, as = "parent" of the draft, if used as a normative reference to the = intented-Standard draft-ietf-roll-aodv-rpl-01 -- but would not be = necessary for an Experimental RFC. 

Thanks a lot,

Juan Antonio = Cordero, PhD
=C3=89cole polytechnique, Paris

References

[1] Juan Antonio Cordero, J. Yi, T. Clausen: An Adaptive = Jitter Mechanism for Reactive Route Discovery in Sensor Networks. = Sensors (Basel). 2014 Aug; 14(8): 14440=E2=80=9314471. = doi:10.3390/s140814440
[2] RFC 5148, Informational
[3] RFC 2026, BCP
[4] RFC 6997, = Experimental= --Apple-Mail=_A842CB1B-CC05-41A0-B643-6876C1788F27-- From nobody Thu Aug 31 07:38:50 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965DF132E0E for ; Thu, 31 Aug 2017 07:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mfbSqCdisZ2z for ; Thu, 31 Aug 2017 07:38:46 -0700 (PDT) Received: from smtp.unipi.it (smtp2.unipi.it [131.114.21.21]) by ietfa.amsl.com (Postfix) with ESMTP id 90EA2132E0C for ; Thu, 31 Aug 2017 07:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.unipi.it (Postfix) with ESMTP id 4153941C6F; Thu, 31 Aug 2017 16:38:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at unipi.it Received: from r22401pc (cng4.iet.unipi.it [131.114.58.100]) (Authenticated User) by smtp.unipi.it (Postfix) with ESMTPSA id AEF2D40B89; Thu, 31 Aug 2017 16:38:39 +0200 (CEST) Reply-To: From: "Enzo Mingozzi" To: Date: Thu, 31 Aug 2017 16:38:41 +0200 Organization: University of Pisa Message-ID: <016601d32266$d72681f0$857385d0$@iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: it Thread-Index: AdMiZga7usTaRq4OQsCk3dA3936+rg== X-Antivirus: Avast (VPS 170831-4, 31/08/2017), Outbound message X-Antivirus-Status: Clean Archived-At: Subject: [Roll] CFP EWSN 2018 Deadline 11 Sept 2017 Intl Conf Embedded Wireless Systems & Networks - Madrid, Spain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 14:38:49 -0000 Dear all, Please see below the Call for Papers for the International Conference on Embedded Wireless Systems and Networks (EWSN) 2018. We look forward to = your paper submissions. Best regards, Enzo Mingozzi ------------------------------------------------------------------------ EWSN 2018, International Conference on Embedded Wireless Systems and Networks February 14-16, 2018, Madrid, Spain https://ewsn2018.networks.imdea.org=20 in-cooperation with ACM SIG on Embedded Systems Best Paper Award sponsored by the IEEE Computer Society Technical = Committee on Simulation (TCSIM) ------------------------------------------------------------------------ *PAPER REGISTRATION DEADLINE: SEPTEMBER 6, 2017* *FULL MANUSCRIPT DUE: SEPTEMBER 11, 2017* ------------------------------------------------------------------------ The International Conference on Embedded Wireless Systems and Networks (EWSN) is a highly selective single-track international conference = focusing on premier research results at the intersection of embedded systems and wireless networking - an area of highest relevance for visionary technologies such as the Internet of Things and Cyber-Physical Systems = as well as applications such as Industry 4.0, Smart Production, Smart = Cities, and Connected Cars. The featured topic of the 2018 edition of EWSN is "Sustainable Embedded Wireless Systems", with contributions that aim to contain the energy = cost and the carbon footprint of embedded wireless systems. This builds on = top of the successful EWSN 2016 and EWSN 2017 editions featuring the topic of "Dependability". Sustainable embedded wireless systems will operate on = top of reliable, safe, and secure systems studied in past editions. Topics = such as energy-efficient wireless networking technologies and architectures, backscatter communication, adaptation of embedded systems supplied by variable renewable energy sources, wireless power transfer as well as application of embedded wireless systems to increase the energy = efficiency of smart homes, smart buildings, and smart cities are welcome. Topics = not related to "Sustainable Embedded Wireless Systems" are equally welcome = as long as they fall into the scope of the conference, as described below.=20 AWARDS AND EDITORIAL FOLLOW-UP ------------------------------------------------------------------------ Papers presented at the Conference will be considered for a Best Paper Award, sponsored by the IEEE Computer Society Technical Committee on Simulation (TCSIM). Papers of particular merit will be selected to be fast-tracked to ACM Transactions on Sensor Networks. PAPER SUBMISSION AND PUBLICATION ------------------------------------------------------------------------ EWSN 2018 is a highly selective conference. We will only accept for = review original papers that have not been previously published and are=20 not currently under review by any other conference or journal. The conference solicits both full technical papers, and short papers=20 describing validated early ideas. We will adopt a double-blind review process, where the names of authors and their affiliations are unknown = to reviewers until the end of the review process. We will also provide = authors the possibility of a rebuttal before final decisions are made. Authors = must make a good faith effort to anonymize their submissions such that the = author identities are not disclosed to the reviewers. You can find detailed submission instructions at: https://ewsn2018.networks.imdea.org/call-for-papers.html=20 *Submission implies the willingness of at least one author to attend the conference and present the paper. Accepted papers will be included in = the proceedings of EWSN 2018 and indexed in the ACM digital library* IMPORTANT DATES ------------------------------------------------------------------------ - Paper registration: September 6, 2017=20 - Paper submission: September 11, 2017=20 - Authors rebuttal deadline: November 13, 2017=20 - Notification of acceptance: December 1, 2017=20 WORKSHOPS AND AFFILIATED EVENTS: ------------------------------------------------------------------------ EWSN 2018 will host the MadCom and RED-IOT workshops, and also feature a sustainability competition, a poster and demo session, and one panel of renowned experts on "Testbeds and trials for 5G deployments". Please = visit the conference website for further details. ORGANIZING COMMITTEE ------------------------------------------------------------------------ GENERAL CHAIRS Domenico Giustiniano, IMDEA Networks Institute, Spain. Dimitrios Koutsonikolas, University at Buffalo, SUNY, USA. VICE GENERAL CHAIR Albert Banchs, UC3M, Spain. TPC CHAIRS Enzo Mingozzi, University of Pisa, Italy. Kaushik Roy Chowdhury, Northeastern University, USA. WORKSHOP CHAIRS David Malone, Hamilton Institute, Ireland. Cristina Cano, Universitat Oberta de Catalunya, Spain. Elias Tragos, NUI Galway, Ireland. George Oikonomou, University of Bristol, UK. POSTER & DEMO CHAIRS Karin Anna Hummel, JKU Linz, Austria. Andreas Reinhardt, TU Clausthal, Germany. PANEL CHAIR Valerio Frascolla, Intel, Germany. COMPETITION CHAIRS Carlo Boano, TU Graz, Austria. Pablo Serrano, UC3M, Spain. Markus Schuss, TU Graz, Austria. LOCAL ARRANGEMENTS CHAIR Paolo Casari, IMDEA Networks Institute, Spain. REGISTRATION CHAIR Maurizio Rea, IMDEA Networks Institute, Spain. PUBLICITY CHAIRS Marco Cattani, TU Graz, Austria. Asun Santamar=EDa, UPM, Spain. Zhi Sun, University at Buffalo, SUNY, USA. Cong Wang, City University of Hong Kong, Hong Kong. PUBLICATIONS CHAIR Christian Renner, TUHH, Germany. WEB CHAIR Swetank Kumar Saha, University at Buffalo, SUNY, USA. From nobody Thu Aug 31 08:05:45 2017 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862D2132E06 for ; Thu, 31 Aug 2017 08:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URG_BIZ=0.573, URIBL_BLOCKED=0.001] autolearn=no 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 8_L2gCUotg35 for ; Thu, 31 Aug 2017 08:05:36 -0700 (PDT) Received: from lb1-smtp-cloud7.xs4all.net (lb1-smtp-cloud7.xs4all.net [194.109.24.24]) (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 517AB13292E for ; Thu, 31 Aug 2017 08:05:36 -0700 (PDT) Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:195]) by smtp-cloud7.xs4all.net with ESMTPA id nR2Edd6ECAr7rnR2Ed56bE; Thu, 31 Aug 2017 17:05:34 +0200 Received: from 83-161-161-241.mobile.xs4all.nl ([83.161.161.241]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 31 Aug 2017 17:05:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 31 Aug 2017 17:05:33 +0200 From: peter van der Stok To: e.mingozzi@iet.unipi.it, Routing Over Low power and Lossy networks Organization: vanderstok consultancy Reply-To: consultancy@vanderstok.org Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <016601d32266$d72681f0$857385d0$@iet.unipi.it> References: <016601d32266$d72681f0$857385d0$@iet.unipi.it> Message-ID: X-Sender: stokcons@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfBH4O2+5bqI1u6MTF/XoJgaGVHLUxOhXHA/L8vp2CaNLhuZ0xdb7yvQyIDkOYdx6rvLKjLFsrlo5TJyWxVps4jSMfotwPhSeyDYeCOYQ7RLaTcEkRGHi JVPCkiPAoj8sm0qwHWO8MsQYCBTofwm0iDDrvTLjr3oGjnxmC2Qigw6vKcZAzCB2cpsLzjTiXztvG29wuSCtlcxa84fMeS5m0GWbbGr2uWVeY7FKc5ONPua+ Archived-At: Subject: Re: [Roll] CFP EWSN 2018 Deadline 11 Sept 2017 Intl Conf Embedded Wireless Systems & Networks - Madrid, Spain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 15:05:44 -0000 Dear users of this mailing list, It is good practice to ask the WG chairs permission to distribute CFP for conferences and other manifestations. That has not happened for this CFP. We would have denied the permission, because we consider the distribution of CFP misuse of the mailing list. Where will it end when everybody misuses this mailing list for his favored conference CFP. So, urgent request: DO NOT distribute CFP on this ML unless explicit authorization has been received from the co-chairs. Peter Enzo Mingozzi schreef op 2017-08-31 16:38: > Dear all, > > Please see below the Call for Papers for the International Conference > on > Embedded Wireless Systems and Networks (EWSN) 2018. We look forward to > your > paper submissions. > > Best regards, > Enzo Mingozzi > > ------------------------------------------------------------------------ > EWSN 2018, International Conference on Embedded Wireless Systems and > Networks > February 14-16, 2018, Madrid, Spain > > https://ewsn2018.networks.imdea.org > > in-cooperation with ACM SIG on Embedded Systems > Best Paper Award sponsored by the IEEE Computer Society Technical > Committee > on Simulation (TCSIM) > ------------------------------------------------------------------------ > *PAPER REGISTRATION DEADLINE: SEPTEMBER 6, 2017* > *FULL MANUSCRIPT DUE: SEPTEMBER 11, 2017* > ------------------------------------------------------------------------ > The International Conference on Embedded Wireless Systems and Networks > (EWSN) is a highly selective single-track international conference > focusing > on premier research results at the intersection of embedded systems and > wireless networking - an area of highest relevance for visionary > technologies such as the Internet of Things and Cyber-Physical Systems > as > well as applications such as Industry 4.0, Smart Production, Smart > Cities, > and Connected Cars. > > The featured topic of the 2018 edition of EWSN is "Sustainable Embedded > Wireless Systems", with contributions that aim to contain the energy > cost > and the carbon footprint of embedded wireless systems. This builds on > top of > the successful EWSN 2016 and EWSN 2017 editions featuring the topic of > "Dependability". Sustainable embedded wireless systems will operate on > top > of reliable, safe, and secure systems studied in past editions. Topics > such > as energy-efficient wireless networking technologies and architectures, > backscatter communication, adaptation of embedded systems supplied by > variable renewable energy sources, wireless power transfer as well as > application of embedded wireless systems to increase the energy > efficiency > of smart homes, smart buildings, and smart cities are welcome. Topics > not > related to "Sustainable Embedded Wireless Systems" are equally welcome > as > long as they fall into the scope of the conference, as described below. > > AWARDS AND EDITORIAL FOLLOW-UP > ------------------------------------------------------------------------ > Papers presented at the Conference will be considered for a Best Paper > Award, sponsored by the IEEE Computer Society Technical Committee on > Simulation (TCSIM). Papers of particular merit will be selected to be > fast-tracked to ACM Transactions on Sensor Networks. > > PAPER SUBMISSION AND PUBLICATION > ------------------------------------------------------------------------ > EWSN 2018 is a highly selective conference. We will only accept for > review > original papers that have not been previously published and are > not currently under review by any other conference or journal. The > conference solicits both full technical papers, and short papers > describing validated early ideas. We will adopt a double-blind review > process, where the names of authors and their affiliations are unknown > to > reviewers until the end of the review process. We will also provide > authors > the possibility of a rebuttal before final decisions are made. Authors > must > make a good faith effort to anonymize their submissions such that the > author > identities are not disclosed to the reviewers. You can find detailed > submission instructions at: > https://ewsn2018.networks.imdea.org/call-for-papers.html > > *Submission implies the willingness of at least one author to attend > the > conference and present the paper. Accepted papers will be included in > the > proceedings of EWSN 2018 and indexed in the ACM digital library* > > IMPORTANT DATES > ------------------------------------------------------------------------ > - Paper registration: September 6, 2017 > - Paper submission: September 11, 2017 > - Authors rebuttal deadline: November 13, 2017 > - Notification of acceptance: December 1, 2017 > > WORKSHOPS AND AFFILIATED EVENTS: > ------------------------------------------------------------------------ > EWSN 2018 will host the MadCom and RED-IOT workshops, and also feature > a > sustainability competition, a poster and demo session, and one panel of > renowned experts on "Testbeds and trials for 5G deployments". Please > visit > the conference website for further details. > > ORGANIZING COMMITTEE > ------------------------------------------------------------------------ > GENERAL CHAIRS > Domenico Giustiniano, IMDEA Networks Institute, Spain. > Dimitrios Koutsonikolas, University at Buffalo, SUNY, USA. > > VICE GENERAL CHAIR > Albert Banchs, UC3M, Spain. > > TPC CHAIRS > Enzo Mingozzi, University of Pisa, Italy. > Kaushik Roy Chowdhury, Northeastern University, USA. > > WORKSHOP CHAIRS > David Malone, Hamilton Institute, Ireland. > Cristina Cano, Universitat Oberta de Catalunya, Spain. > Elias Tragos, NUI Galway, Ireland. > George Oikonomou, University of Bristol, UK. > > POSTER & DEMO CHAIRS > Karin Anna Hummel, JKU Linz, Austria. > Andreas Reinhardt, TU Clausthal, Germany. > > PANEL CHAIR > Valerio Frascolla, Intel, Germany. > > COMPETITION CHAIRS > Carlo Boano, TU Graz, Austria. > Pablo Serrano, UC3M, Spain. > Markus Schuss, TU Graz, Austria. > > LOCAL ARRANGEMENTS CHAIR > Paolo Casari, IMDEA Networks Institute, Spain. > > REGISTRATION CHAIR > Maurizio Rea, IMDEA Networks Institute, Spain. > > PUBLICITY CHAIRS > Marco Cattani, TU Graz, Austria. > Asun Santamaría, UPM, Spain. > Zhi Sun, University at Buffalo, SUNY, USA. > Cong Wang, City University of Hong Kong, Hong Kong. > > PUBLICATIONS CHAIR > Christian Renner, TUHH, Germany. > > WEB CHAIR > Swetank Kumar Saha, University at Buffalo, SUNY, USA. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll