From abr@sdesigns.dk Thu Oct 1 04:52:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5033E3A67E3 for ; Thu, 1 Oct 2009 04:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INwSBWOm2AUk for ; Thu, 1 Oct 2009 04:52:08 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 20E303A62C1 for ; Thu, 1 Oct 2009 04:52:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Oct 2009 13:53:32 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429AC4@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Discussion yesterday Thread-Index: AcpCXFWQdOzc0fnfRj+78+MFVDWBawALJ/yw References: From: "Anders Brandt" To: "JP Vasseur" , "roll WG" Subject: Re: [Roll] RPL Discussion yesterday X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 01 Oct 2009 11:52:09 -0000 Hi Just wanted to confirm the experience of a productive meeting. After having been somewhat worried over a lot of features still solving just one third of the identified requirements, I am now more confident that we will actually be able to bring ideas and solutions together for a full solution. Thus, I just want to remind us all on the most prominent topics to address just after the 5 topics listed by JP: A) P2MP 1) The meeting clarified that nodes MUST NOT be assigned new address if radio phenomena cause nodes to re-attach to a parent in a neighbor sub-DAG. 2) The consequence of A1) is that a router may potentially have to hold a number of explicit /128 entries that are to be propagated all the way to the top. B) P2P 1) In home and building application spaces, there is a need for reactive network re-discovery, so that a controller may re-gain access to an actuator within (significantly less than) a second. Example: If a light module is unreachable from the most recent set of parents, the triggle timer based system of advertisements may cause the module to wait potentially for hours before announcing its presence to a new parent. 2) One way to address B1) is to introduce an AODV-style discovery mechanism. This mechanism should be limited to 4 or 5 repeater hops but not tied to DAG topologies. 3) Source routing may be the best candidate for traversing the mesh along paths not following - or allowed by -=20 the DAG. 4) Due to B3) the AODV principles may have to be adjusted to determine source routed paths via up 4 hops - of course using the same routing stack which is already part of RPL; But now with a direction bit for nodes not having to swap the routing stack in order to return a response the same way from where they just got a request. With JP's optimism I guess this is done 4 weeks from now? Cheers, Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 1. oktober 2009 07:59 To: roll WG Subject: [Roll] RPL Discussion yesterday Dear all, We had an extremely production and fruitful interim meeting yesterday, and there was a strong consensus on several key simplifications of RPL, we're most definitely on the right track. Since several implementations are on the way, we agreed to produce a new revision of RPL extremely quickly and the author team is already working on them. Basically 1) Major editorial clean-up: eliminate redundant text, the protocol overview section should be more high level. 2) RPL specifies how to build a (colored) DAG where the color simply reflect a set of constraints and metrics determined by the OCP. The decisions on whether a node should join more than one DAG is administratively determined and will be discussed in applicability statement. 3) The decision was also made to clarify the use of the sequence number + make complex operation of DAG merging/.... optional 4) We will keep unchanged the NA-DAO model that allows to support nodes with extremely limited memory (thanks to source routing) and nodes that can store routing tables. Various clarifications are required (see the minutes to be posted soon). 5) Add the FSM to the document. Time Line ... within two weeks. Challenging but doable considering how productive the WG is ;-) Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Oct 1 06:13:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F85A3A6A45 for ; Thu, 1 Oct 2009 06:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.087 X-Spam-Level: X-Spam-Status: No, score=-10.087 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5U0skCzh8BH for ; Thu, 1 Oct 2009 06:13:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8CD3E3A69A2 for ; Thu, 1 Oct 2009 06:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3778; q=dns/txt; s=amsiport01001; t=1254402911; x=1255612511; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20My=20notes=20from=20the=20meeting|Date: =20Thu,=201=20Oct=202009=2015:15:02=20+0200|Message-ID: =20<6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.ci sco.com>|To:=20"Tim=20Winter"=20|Cc:=20" IETF=20ROLL"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AC3CD83.4080309@acm.org>|References:=20 <4AC3CD83.4080309@acm.org>; bh=aTQBRLkaZNtx7nwDodtMBtCekzYLWuDKl+VIn99/49w=; b=mS6L1pHiESSaQwOqS5/MXpsVLLTMGQXXivJs7aM/m+AtzjzcIMOpVbhB v37U90Sfo7P0n9OaN2E1+mbZgj0OOlWR2ofx/SpHbrdUpByl384XTA7gY bC3aQp4VQHYtN5VgOTVqVZQh0MlCFnlWm0sJM8bNfxuLYGWkVQrE0KnPB 4=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pthubert@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAAANIxEqQ/uCKe2dsb2JhbACabRYkBqMUiFsBj1MGgimCAIFT X-IronPort-AV: E=Sophos;i="4.44,487,1249257600"; d="scan'208";a="50696792" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2009 13:15:09 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91DF9W2030877; Thu, 1 Oct 2009 15:15:09 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n91DF9Ih025491; Thu, 1 Oct 2009 13:15:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 15:15:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Oct 2009 15:15:02 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> In-Reply-To: <4AC3CD83.4080309@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: My notes from the meeting Thread-Index: AcpCFWuWPnoK6m4LReSwHaIh5XVXMwAdUz4A References: <4AC3CD83.4080309@acm.org> From: "Pascal Thubert (pthubert)" To: "Tim Winter" X-OriginalArrivalTime: 01 Oct 2009 13:15:09.0648 (UTC) FILETIME=[33978D00:01CA4299] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3778; t=1254402909; x=1255266909; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20My=20notes=20from=20the=20meeting |Sender:=20; bh=aTQBRLkaZNtx7nwDodtMBtCekzYLWuDKl+VIn99/49w=; b=Av5oW8UWS3yt9z2f/IO/TOJAgq8W6dSXkpVnZ7wNniyqwuTW1W92mmCfwo CDynLAywVgncl54U2rv/1moM+X8dMQX4Kpod/0W22PlRwvivWl28gR2ob4QN NoJEC7N3h8; Cc: IETF ROLL Subject: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 01 Oct 2009 13:13:47 -0000 Hi Tim (and all): Please find my annotated notes on the changes that were proposed at the interim in ROLLE: 1) Multi Topology Routing (MTR) is adopted as a base spec to handle heterogeneous requirements A topology is defined by where it goes (destination, default) and how to get there (OCP/OF, metrics) We need in the intro to say that topologies controlled by ship-in-the-night instances of the protocol. TopoID=3D=3D instanceID is indicated in all control messages, and encoded in the flow label in all packets Requires provisioning when using other than the default topology. Default topo is topoID 0. In general all nodes are expected to participate at least to that one. Passed the intro, the text will (mostly) only need to explain to what happens within one instance. Much of that is hopefully very close to the current text :) 2) Proposal to make (1 instance =3D=3D 1 DAG) RPL requires that a DAG be rooted at one destination. The root heartbeats the protocol, eg increases the sequence. Proposal is doable when there's a backbone link; one of the roots plays the role of a virtual rank 0 over the backbone But some other case do not have a IPv6 link as a backbone. Eg: multiple sinks that are GW and terminate IPv6. So 1 instance =3D=3D 1 DAG is not compatible with the current operation Actually 1 instance =3D=3D n DAGs improves jump opportunities and reduces churn by divide/conquer. 3) The sequence number becomes the way we fix loops The detach / reattach local recovery becomes only an option. The hold up and down timers become also optional Orphans that cannot jump in another DAG have to wait for the next sequence (stimulate one with RS)? Until then they need to advertise an infinite rank to poison anyway. Need to write down the FSM states and transitions clearly. =09 4) need to make sure that we say that even in source route, routers issue NA-DAO for self 5) Need to add text on loop and loop recovery Sibling are proven valuable. Sibling loops could be prevented adequately by simply preventing 2 sibling hops. NA-DAO loops can also be blocked by RPF if we know that we receive from inwards something we'd send inwards.=20 If a router stamps its rank in a packet and says if it is sending up, sibling or down, detection is real easy.=20 My take here is that there's room in the flow label for this: Flags: 4 bits. inwards vs. outwards; from sibling or not. Rank: 1 octet InstanceID : 1 octet InstanceID would set by the source of the packet or the first router. Whether mutable TBD. Flags and rank are mutable, updated by each router on the way, zeroed out for crypto operations=09 6) P2P optimization not fully addressed Discussed the use of mcast to locate nodes at app level and trigger the routing Discussed on-demand reactive protocol, source route cost vs. routing table size. =09 I also noted that DADR appears to give great results. The memory requirement augments with the flow (pps) and reduces with the max loop Round Trip Time (s). It seems ideal in low latency and low throughput, and it might fix a loop before the protocol does and prevent loss. If the packets are delayed over the max expected loop RTT, though, the loop goes undetected.=20 I also wondered what happens when some nodes play the DADR game along the way and some do not. My take: - DADR applies to a subset of cases, so it can hardly be mandatory on all types of devices. Optional could be good if we can provide an applicability statement. - DADR does not work for some loops so a more brutal detection -that does not fix but at least discards packets and triggers routing - is still needed (like the one proposed in 5). Cheers, Pascal From jvasseur@cisco.com Thu Oct 1 10:07:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22273A68D5 for ; Thu, 1 Oct 2009 10:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.691 X-Spam-Level: X-Spam-Status: No, score=-9.691 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H47WJ0oXCIoo for ; Thu, 1 Oct 2009 10:07:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6230928C120 for ; Thu, 1 Oct 2009 10:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=2445; q=dns/txt; s=amsiport01001; t=1254416933; x=1255626533; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20P roposed=20RPL=20plan|Date:=20Thu,=201=20Oct=202009=2019:0 8:50=20+0200|Message-Id:=20<6549FDD7-0396-4DBC-91B3-8DAFF 8DC4D10@cisco.com>|To:=20roll=20WG=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20|References: =20; bh=l1nksjHVUHbTRzDGUYjIiVgE8PWtYujGD2d5MHPaGys=; b=HN+wZHfcWS+cgyEkff5qvIf8znWEGJdau/boAjrvTd+k04D9weh+s8BE W8UV/78V1/qCdscided0TcYOOskqFr6eSV8WfWBiLdPpyCCTwlQBl/YGc n5K9qRQfjB61H7kYf1/+ZJ8PaxB0LMA37MyZJH5SJjVHOJvvpAbctCD6g E=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAAAt/xEqQ/uCKe2dsb2JhbACabhYkBqQ6iFsBj04GhCk X-IronPort-AV: E=Sophos;i="4.44,488,1249257600"; d="scan'208";a="50715846" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2009 17:08:52 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91H8q1t020814 for ; Thu, 1 Oct 2009 19:08:52 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n91H8qNs005962 for ; Thu, 1 Oct 2009 17:08:52 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 19:08:52 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 19:08:51 +0200 Message-Id: <6549FDD7-0396-4DBC-91B3-8DAFF8DC4D10@cisco.com> From: JP Vasseur To: roll WG In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Oct 2009 19:08:50 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 01 Oct 2009 17:08:51.0589 (UTC) FILETIME=[D951F350:01CA42B9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16922.000 X-TM-AS-Result: No--18.634900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2445; t=1254416932; x=1255280932; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Proposed=20RPL=20plan |Sender:=20; bh=l1nksjHVUHbTRzDGUYjIiVgE8PWtYujGD2d5MHPaGys=; b=H9Ul0SAzvSd2zaKE+nZeWsszon/EwxQWR7yS/b0nHfT6bojrFuWblKfJRq jBakWXlAhpqTw+gOBhHUwnAhoAwJtNvJ6svs+UhFOmTqaW7deQo2A9z25rY5 ty9o87D6eR; Subject: [Roll] Proposed RPL plan X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 01 Oct 2009 17:07:28 -0000 Dear all, First of all, I would like to re-iterate the fruitful consensus that we reached yesterday on many items. The authors' team had another discussion with the objective to propose a plan. Here it is: Rev-03 (early next week) will be purely editorial. The Protocol Overview will be shortened, redundant text will be removed and the document will be slightly reorganized for the sake of clarity. Rev-04 is the revision that should lead us to a fairly stabilize protocol version explicitly covering the items 2), 3) 4) and 5) below. More specifically, we will send out an email to propose several options for 3) early next week. PLEASE provide feed-back, comments and suggestions. The goal is to have rev-04 out for Oct 19. Rev-05 will cover security. Thanks to all of you, we continue to progress really well. JP. The authors On Oct 1, 2009, at 7:59 AM, JP Vasseur wrote: > Dear all, > > We had an extremely production and fruitful interim meeting > yesterday, and there was a strong consensus on several key > simplifications of RPL, we're most definitely on the right track. > Since several implementations are on the way, we agreed to produce a > new revision of RPL extremely quickly and the author team is already > working on them. > > Basically > > 1) Major editorial clean-up: eliminate redundant text, the protocol > overview section should be more high level. > 2) RPL specifies how to build a (colored) DAG where the color simply > reflect a set of constraints and metrics determined by the OCP. The > decisions on whether a node should join more than one DAG is > administratively determined and will be discussed in applicability > statement. > 3) The decision was also made to clarify the use of the sequence > number + make complex operation of DAG merging/.... optional > 4) We will keep unchanged the NA-DAO model that allows to support > nodes with extremely limited memory (thanks to source routing) and > nodes that can store routing tables. Various clarifications are > required (see the minutes to be posted soon). > 5) Add the FSM to the document. > > Time Line ... within two weeks. Challenging but doable considering > how productive the WG is ;-) > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From sung.lee@us.fujitsu.com Thu Oct 1 15:01:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BB63A6840 for ; Thu, 1 Oct 2009 15:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R26vQ1SzFcay for ; Thu, 1 Oct 2009 15:01:03 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 01FB23A6954 for ; Thu, 1 Oct 2009 15:01:02 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n91M3Mit006635 for ; Thu, 1 Oct 2009 15:03:22 -0700 (PDT) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n91M3M65006632 for ; Thu, 1 Oct 2009 15:03:22 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.8/8.13.8) with ESMTP id n91M2SC8007188 for ; Thu, 1 Oct 2009 15:02:28 -0700 (PDT) Received: from [10.157.253.52] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n91M2RF20082 for ; Thu, 1 Oct 2009 15:02:27 -0700 (PDT) Message-ID: <4AC526EC.4060503@us.fujitsu.com> Date: Thu, 01 Oct 2009 18:02:20 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] interim minutes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 01 Oct 2009 22:01:03 -0000 All, I have noticed several of you sent notes of summary. Sorry I have not followed up on it yet as I took minutes. I will post minutes by the end of this week after cleaning up my verbose notes into concise minutes. I will work on it on my flight to the states tomorrow. :-) I too wanted to express that interim meeting was very productive. I just read Pascal's comments on DADR. I will also address it by the end of this weekend. Thank you, Sung From jabeille@cisco.com Fri Oct 2 06:34:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9343A68AB for ; Fri, 2 Oct 2009 06:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbPOYjjCcJFU for ; Fri, 2 Oct 2009 06:34:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5F0093A68A1 for ; Fri, 2 Oct 2009 06:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=5029; q=dns/txt; s=amsiport01001; t=1254490547; x=1255700147; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[Roll]=20My=20notes=20from=20the =20meeting|Date:=20Fri,=202=20Oct=202009=2015:35:44=20+02 00|Message-ID:=20|To:=20"Pascal=20Thubert=20(pthuber t)"=20,=0D=0A=20=20=20=20=20=20=20=20 "Tim=20Winter"=20|Cc:=20"IETF=20ROLL"=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<6A2A459175DABE4BB11DE2026AA50A5D54AA6F@X MB-AMS-107.cisco.com>|References:=20<4AC3CD83.4080309@acm .org>=20<6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-1 07.cisco.com>; bh=XSdqSKFTz6dnxltemFlvUFPWarY2/AJZ6SEGTrsood8=; b=hK51NxBqnm7mtS5VWIl96vt6G/gGwDWFRJ6/z9P3iMQoaiiBwJBIPJ4w /NHmwD71XDWZ+C6rnt8svcw4Efqk11H5qGu+b/L7f5pigliK6e8YdxA1U 8q2FDg/GhwDULf9/s1r8o22w83qrrnvfZ/4ok0lZjhRtMiFSvta43/fEj U=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jabeille@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIAACeexUqQ/uCLe2dsb2JhbACacgEBFiQGpCqIWwGPKAaCKYIDgVY X-IronPort-AV: E=Sophos;i="4.44,494,1249257600"; d="scan'208";a="50792391" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2009 13:35:45 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n92DZj0V005306; Fri, 2 Oct 2009 15:35:45 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n92DZkk3009124; Fri, 2 Oct 2009 13:35:46 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 15:35:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 15:35:44 +0200 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] My notes from the meeting Thread-Index: AcpCFWuWPnoK6m4LReSwHaIh5XVXMwAdUz4AADZ9HjA= References: <4AC3CD83.4080309@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "Tim Winter" X-OriginalArrivalTime: 02 Oct 2009 13:35:46.0136 (UTC) FILETIME=[3F026580:01CA4365] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5029; t=1254490546; x=1255354546; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[Roll]=20My=20notes=20from=20the=20meet ing |Sender:=20; bh=XSdqSKFTz6dnxltemFlvUFPWarY2/AJZ6SEGTrsood8=; b=RrEfRpIswzg+2HekyrwP5OM8AXvb1sA5AgQXaPrqh3ONeBmKUDvNPh/yj1 S/KaUwQ2X0rnnAJoALTbbauCBFiRtLoW4TSnsmkOqULTD+iA9Tu5FObl45VF RMq/f5vxNt; Cc: IETF ROLL Subject: Re: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Oct 2009 13:34:22 -0000 Hi Pascal, all, Thanks for the notes. One thing about point 1. My understanding is that we agreed that there was no concept of "default" DAG, or "white DAG". As JP said RPL will define one (colored) DAG, but what the color means and how it is used is out of scope of the spec. The proposal that RPL defines a "default DAG" concept, and especially the need for all nodes to belong to it, was rejected as far as I understood and should be treated if needed in a separate document. Was my understanding correct? Best, Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: jeudi 1 octobre 2009 15:15 > To: Tim Winter > Cc: IETF ROLL > Subject: [Roll] My notes from the meeting >=20 > Hi Tim (and all): >=20 > Please find my annotated notes on the changes that were=20 > proposed at the interim in ROLLE: >=20 > 1) Multi Topology Routing (MTR) is adopted as a base spec to=20 > handle heterogeneous requirements > A topology is defined by where it goes (destination,=20 > default) and how to get there (OCP/OF, metrics) > We need in the intro to say that topologies controlled=20 > by ship-in-the-night instances of the protocol. > TopoID=3D=3D instanceID is indicated in all control=20 > messages, and encoded in the flow label in all packets > Requires provisioning when using other than the default=20 > topology. > Default topo is topoID 0. In general all nodes are=20 > expected to participate at least to that one. > Passed the intro, the text will (mostly) only need to=20 > explain to what happens within one instance. > Much of that is hopefully very close to the current text :) >=20 > 2) Proposal to make (1 instance =3D=3D 1 DAG) > RPL requires that a DAG be rooted at one destination.=20 > The root heartbeats the protocol, eg increases the sequence. > Proposal is doable when there's a backbone link; one of=20 > the roots plays the role of a virtual rank 0 over the backbone > But some other case do not have a IPv6 link as a backbone. Eg: > multiple sinks that are GW and terminate IPv6. > So 1 instance =3D=3D 1 DAG is not compatible with the=20 > current operation > Actually 1 instance =3D=3D n DAGs improves jump=20 > opportunities and reduces churn by divide/conquer. >=20 > 3) The sequence number becomes the way we fix loops > The detach / reattach local recovery becomes only an=20 > option. The hold up and down timers become also optional > Orphans that cannot jump in another DAG have to wait=20 > for the next sequence (stimulate one with RS)? > Until then they need to advertise an infinite rank to=20 > poison anyway. > Need to write down the FSM states and transitions clearly. > =09 > 4) need to make sure that we say that even in source route,=20 > routers issue NA-DAO for self >=20 > 5) Need to add text on loop and loop recovery > Sibling are proven valuable. Sibling loops could be=20 > prevented adequately by simply preventing 2 sibling hops. > NA-DAO loops can also be blocked by RPF if we know that=20 > we receive from inwards something we'd send inwards.=20 > If a router stamps its rank in a packet and says if it=20 > is sending up, sibling or down, detection is real easy.=20 > My take here is that there's room in the flow label for this: >=20 > Flags: 4 bits. inwards vs. outwards; from=20 > sibling or not. > Rank: 1 octet > InstanceID : 1 octet >=20 > InstanceID would set by the source of the packet or the=20 > first router. Whether mutable TBD. > Flags and rank are mutable, updated by each router on the way, > zeroed out for crypto operations=09 >=20 > 6) P2P optimization not fully addressed > Discussed the use of mcast to locate nodes at app level=20 > and trigger the routing > Discussed on-demand reactive protocol, source route cost vs. > routing table size. > =09 > I also noted that DADR appears to give great results. The=20 > memory requirement augments with the flow (pps) and reduces=20 > with the max loop Round Trip Time (s). It seems ideal in low=20 > latency and low throughput, and it might fix a loop before=20 > the protocol does and prevent loss. If the packets are=20 > delayed over the max expected loop RTT, though, the loop goes=20 > undetected.=20 > I also wondered what happens when some nodes play the DADR=20 > game along the way and some do not. >=20 > My take: > - DADR applies to a subset of cases, so it can hardly be=20 > mandatory on all types of devices. Optional could be good if=20 > we can provide an applicability statement. > - DADR does not work for some loops so a more brutal=20 > detection -that does not fix but at least discards packets=20 > and triggers routing - is still needed (like the one proposed in 5). >=20 > Cheers, >=20 >=20 > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jvasseur@cisco.com Fri Oct 2 07:09:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE223A688B for ; Fri, 2 Oct 2009 07:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.704 X-Spam-Level: X-Spam-Status: No, score=-9.704 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okIGdDvQFH2V for ; Fri, 2 Oct 2009 07:09:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5FAED28C0F6 for ; Fri, 2 Oct 2009 07:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=5534; q=dns/txt; s=amsiport01001; t=1254492637; x=1255702237; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20My=20notes=20from=20the=20meeting|Date:=20F ri,=202=20Oct=202009=2016:10:34=20+0200|Message-Id:=20<5E 92BF81-1F51-4D1D-A8C0-934903289208@cisco.com>|To:=20Julie n=20Abeille=20(jabeille)=20|Cc:=20"Pa scal=20Thubert=20(pthubert)"=20,=0D =0A=20=20=20=20=20=20=20=20"Tim=20Winter"=20,=20IETF=20ROLL=20|Mime-Version:=201.0 =20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20<4AC3CD83.4080309@acm.org>=20<6A2A459175DA BE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com>=20; bh=lzNbgdUj6RZcq0xkASeQGZQjZRjNM1Uji/aHFET3/fo=; b=jazabm+WHot9xTXIdS/ciYjTDG8MRDcBG79CQlePvbXJ5SkVwlykubDy 17Vp/eI1P1cIMock4vc4OlooDy4BW4b2lS43ynOrhIP0oCCwKkUCrU6fI WViUYfteqCa5vd8Ban8Dh/+gBFtfYgvJ3pEMYTpbf+BDay0woi+8dB2wk I=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIAAFumxUqQ/uCLe2dsb2JhbACacgEBFiQGpEaIWwGPJgaCKQiBe4FW X-IronPort-AV: E=Sophos;i="4.44,494,1249257600"; d="scan'208";a="50796157" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2009 14:10:36 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n92EAal9015035; Fri, 2 Oct 2009 16:10:36 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n92EAZqa019614; Fri, 2 Oct 2009 14:10:36 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:10:36 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:10:35 +0200 Message-Id: <5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Oct 2009 16:10:34 +0200 References: <4AC3CD83.4080309@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Oct 2009 14:10:35.0508 (UTC) FILETIME=[1C5F4340:01CA436A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16922.007 X-TM-AS-Result: No--49.130300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5534; t=1254492636; x=1255356636; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20My=20notes=20from=20the=20meet ing |Sender:=20; bh=lzNbgdUj6RZcq0xkASeQGZQjZRjNM1Uji/aHFET3/fo=; b=lF9sFpf1GZRCuE9IU/8vyUdk8cGwuYWh+uwpldIsKUKpgWs1jBDOFdVtwV bnDy2D4fwjNtk2Gs9RgDCMVvWOtLTDYXPK/sAqnx8WkyNRZG379Ut4XTAN41 phKAIXMIQM; Cc: IETF ROLL Subject: Re: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Oct 2009 14:09:15 -0000 Hi Julien, On Oct 2, 2009, at 3:35 PM, Julien Abeille (jabeille) wrote: > Hi Pascal, all, > > Thanks for the notes. One thing about point 1. My understanding is > that > we agreed that there was no concept of "default" DAG, or "white > DAG". As > JP said RPL will define one (colored) DAG, but what the color means > and > how it is used is out of scope of the spec. The proposal that RPL > defines a "default DAG" concept, and especially the need for all nodes > to belong to it, was rejected as far as I understood and should be > treated if needed in a separate document. > > Was my understanding correct? > Yes absolutely. In fact what defines the color of the DAG is the OCP. The decision to join one of multiple DAG (instance of RPL) is a local policy decision of the node. A separate ID will define the tagging mechanism used to identify to which DAG the packet belongs to, similarly to MTR. Cheers. JP. > Best, > Julien > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of Pascal Thubert (pthubert) >> Sent: jeudi 1 octobre 2009 15:15 >> To: Tim Winter >> Cc: IETF ROLL >> Subject: [Roll] My notes from the meeting >> >> Hi Tim (and all): >> >> Please find my annotated notes on the changes that were >> proposed at the interim in ROLLE: >> >> 1) Multi Topology Routing (MTR) is adopted as a base spec to >> handle heterogeneous requirements >> A topology is defined by where it goes (destination, >> default) and how to get there (OCP/OF, metrics) >> We need in the intro to say that topologies controlled >> by ship-in-the-night instances of the protocol. >> TopoID== instanceID is indicated in all control >> messages, and encoded in the flow label in all packets >> Requires provisioning when using other than the default >> topology. >> Default topo is topoID 0. In general all nodes are >> expected to participate at least to that one. >> Passed the intro, the text will (mostly) only need to >> explain to what happens within one instance. >> Much of that is hopefully very close to the current text :) >> >> 2) Proposal to make (1 instance == 1 DAG) >> RPL requires that a DAG be rooted at one destination. >> The root heartbeats the protocol, eg increases the sequence. >> Proposal is doable when there's a backbone link; one of >> the roots plays the role of a virtual rank 0 over the backbone >> But some other case do not have a IPv6 link as a backbone. Eg: >> multiple sinks that are GW and terminate IPv6. >> So 1 instance == 1 DAG is not compatible with the >> current operation >> Actually 1 instance == n DAGs improves jump >> opportunities and reduces churn by divide/conquer. >> >> 3) The sequence number becomes the way we fix loops >> The detach / reattach local recovery becomes only an >> option. The hold up and down timers become also optional >> Orphans that cannot jump in another DAG have to wait >> for the next sequence (stimulate one with RS)? >> Until then they need to advertise an infinite rank to >> poison anyway. >> Need to write down the FSM states and transitions clearly. >> >> 4) need to make sure that we say that even in source route, >> routers issue NA-DAO for self >> >> 5) Need to add text on loop and loop recovery >> Sibling are proven valuable. Sibling loops could be >> prevented adequately by simply preventing 2 sibling hops. >> NA-DAO loops can also be blocked by RPF if we know that >> we receive from inwards something we'd send inwards. >> If a router stamps its rank in a packet and says if it >> is sending up, sibling or down, detection is real easy. >> My take here is that there's room in the flow label for this: >> >> Flags: 4 bits. inwards vs. outwards; from >> sibling or not. >> Rank: 1 octet >> InstanceID : 1 octet >> >> InstanceID would set by the source of the packet or the >> first router. Whether mutable TBD. >> Flags and rank are mutable, updated by each router on the way, >> zeroed out for crypto operations >> >> 6) P2P optimization not fully addressed >> Discussed the use of mcast to locate nodes at app level >> and trigger the routing >> Discussed on-demand reactive protocol, source route cost vs. >> routing table size. >> >> I also noted that DADR appears to give great results. The >> memory requirement augments with the flow (pps) and reduces >> with the max loop Round Trip Time (s). It seems ideal in low >> latency and low throughput, and it might fix a loop before >> the protocol does and prevent loss. If the packets are >> delayed over the max expected loop RTT, though, the loop goes >> undetected. >> I also wondered what happens when some nodes play the DADR >> game along the way and some do not. >> >> My take: >> - DADR applies to a subset of cases, so it can hardly be >> mandatory on all types of devices. Optional could be good if >> we can provide an applicability statement. >> - DADR does not work for some loops so a more brutal >> detection -that does not fix but at least discards packets >> and triggers routing - is still needed (like the one proposed in 5). >> >> Cheers, >> >> >> Pascal >> _______________________________________________ >> 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 pthubert@cisco.com Fri Oct 2 07:34:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804183A6A47 for ; Fri, 2 Oct 2009 07:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.096 X-Spam-Level: X-Spam-Status: No, score=-10.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHBsvlNBdcy5 for ; Fri, 2 Oct 2009 07:34:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D7F2C3A69E6 for ; Fri, 2 Oct 2009 07:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3318; q=dns/txt; s=amsiport01001; t=1254494167; x=1255703767; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20My=20notes=20from=20the =20meeting|Date:=20Fri,=202=20Oct=202009=2016:35:56=20+02 00|Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@ XMB-AMS-107.cisco.com>|To:=20"JP=20Vasseur=20(jvasseur)" =20,=0D=0A=20=20=20=20=20=20=20=20"Ju lien=20Abeille=20(jabeille)"=20|Cc: =20"Tim=20Winter"=20,=20"IETF=20ROLL"=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<5E92BF81-1F51-4D1D-A8C0-934903289208@cis co.com>|References:=20<4AC3CD83.4080309@acm.org>=20<6A2A4 59175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> =20=20<5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.co m>; bh=dco7pgIGDg801MkFLQGDRkmdnmIL0Gc/YuFgADLoatA=; b=KtFYP+eLJvcYCFiEShW5QwCwx8Bncx2oqGMlk033pP+jOCZ5XWpsyIBY wTXZKq6t599EU6hjRbRcrlYsuBJl0aDFEWFIy58mPHlBNzDWK18jlIMCs d/WGtZstgDIPSM5rY+RAWAtOGYq41RguFAYfxymitFpWCyf/5pIwWZaJW I=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pthubert@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIAADesxUqQ/uCLe2dsb2JhbACacgEBFiQGpFGIWwGPJgaCMYF7gVY X-IronPort-AV: E=Sophos;i="4.44,494,1249257600"; d="scan'208";a="50799109" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Oct 2009 14:36:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n92Ea5RB022506; Fri, 2 Oct 2009 16:36:05 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n92Ea5Rj027907; Fri, 2 Oct 2009 14:36:05 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:36:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Oct 2009 16:35:56 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.cisco.com> In-Reply-To: <5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] My notes from the meeting Thread-Index: AcpDahzeaY6Mld8sQp+Tzis01t+slgAAMEVw References: <4AC3CD83.4080309@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> <5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 02 Oct 2009 14:36:05.0802 (UTC) FILETIME=[AC7F98A0:01CA436D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3318; t=1254494165; x=1255358165; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20My=20notes=20from=20the=20meet ing |Sender:=20; bh=dco7pgIGDg801MkFLQGDRkmdnmIL0Gc/YuFgADLoatA=; b=Lu1hhfzXBr9CdihwXk2BJi8wxWS9lZ4NtwGSnWPL3Xl123Jwssbo3uTIsz J9eWjwc0BAvFrfh03icskNmCSEaUqTPNXGTzkp2UwDG9eUG3oWVK14o2Bo+r l8OsLqDq/L; Cc: IETF ROLL Subject: Re: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Oct 2009 14:34:40 -0000 Hi Julien and JP >> Thanks for the notes. One thing about point 1. My understanding is >> that >> we agreed that there was no concept of "default" DAG, or "white >> DAG". As >> JP said RPL will define one (colored) DAG, but what the color means >> and >> how it is used is out of scope of the spec. The proposal that RPL >> defines a "default DAG" concept, and especially the need for all nodes >> to belong to it, was rejected as far as I understood and should be >> treated if needed in a separate document. >> >> Was my understanding correct? >> > >Yes absolutely. In fact what defines the color of the DAG is the OCP. >The decision to join one of multiple DAG (instance of RPL) is a local >policy decision of the node. >A separate ID will define the tagging mechanism used to identify to >which DAG the packet belongs >to, similarly to MTR. Well, there is such a concept though it does not meet the eye. Our spec must be self contained and the other specs are extensions. We need to specify the field where the instanceID will appear. Otherwise the instance extensions would not be compatible. And we need to specify a value to put in that field. RPL will work with a zero as the default. At that point we need to think about what happens to a router that has RPL but no extension. If we do not say anything, such a router mixed with a router that support instanceID will loop. So there must be a minimum support in the base spec about instance. That minimum must handle the case where a packet comes in with a color as well as the operation for processing RPL packets for colored DAG. If the minimum support is instance zero, a node that implements only the RPL base MUST ignore RPL PDUs for non zero instances. As JP says that's an OCP behavior, and we'll have to add an instance filter to OCP0. That also means that when processing a packet of any color, this node will forward it against the instance 0. To avoid loops, the default node must thus zero out the tag. =09 That makes instance 0 the default topology... QED ;)=20 Pascal > >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>> Behalf Of Pascal Thubert (pthubert) >>> Sent: jeudi 1 octobre 2009 15:15 >>> To: Tim Winter >>> Cc: IETF ROLL >>> Subject: [Roll] My notes from the meeting >>> >>> Hi Tim (and all): >>> >>> Please find my annotated notes on the changes that were >>> proposed at the interim in ROLLE: >>> >>> 1) Multi Topology Routing (MTR) is adopted as a base spec to >>> handle heterogeneous requirements >>> A topology is defined by where it goes (destination, >>> default) and how to get there (OCP/OF, metrics) >>> We need in the intro to say that topologies controlled >>> by ship-in-the-night instances of the protocol. >>> TopoID=3D=3D instanceID is indicated in all control >>> messages, and encoded in the flow label in all packets >>> Requires provisioning when using other than the default >>> topology. >>> Default topo is topoID 0. In general all nodes are >>> expected to participate at least to that one. >>> Passed the intro, the text will (mostly) only need to >>> explain to what happens within one instance. >>> Much of that is hopefully very close to the current text :) >>> From mcr@marajade.sandelman.ca Fri Oct 2 07:37:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 084D228C10A for ; Fri, 2 Oct 2009 07:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmfmq9zMEmrr for ; Fri, 2 Oct 2009 07:37:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 3E79428C0F7 for ; Fri, 2 Oct 2009 07:37:24 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.198]) by relay.sandelman.ca (Postfix) with ESMTPS id AFC2C34286 for ; Fri, 2 Oct 2009 14:42:33 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 2701B4E7EC for ; Fri, 2 Oct 2009 10:38:51 -0400 (EDT) X-Message-Flag: You should stop using Outlook. Switch to Thunderbird. From: Michael Richardson To: ROLL WG X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 02 Oct 2009 10:38:50 -0400 Message-ID: <27019.1254494330@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: [Roll] minor comments on rpl-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Oct 2009 14:37:26 -0000 re: 5.3.1. DAG Discovery Rules There are 11 rules. I think we have spent some significant time discussing some of the rules. I wonder if it might be worth naming the rules in some way. i.e. 7. (Freedom to Jump Rule) A node may jump from its current DAG into any different DAG if .... 8. (Nodes are Unstable When Jumping Rule) If a node has selected a new set of DAG parents but has not moved yet (because it is waiting for DAG Hop timer to elapse), the node is unstable MUST NOT send RA-DIOs for that DAG. ^AND {Q: for which DAG? the one it is leaving, or the one it is joining?} or perhaps: 7. A node may jump from its current DAG into any different DAG if ... 7.1. A node may have to wait for a DAG Hop timer to elapse before it jumps to another DAG. This allows the new higher parts (closer to the sink) of the DAG to move first, thus allowing stepped DAG .... -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@marajade.sandelman.ca Fri Oct 2 14:35:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793433A68D0 for ; Fri, 2 Oct 2009 14:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftx0mXVaN6jE for ; Fri, 2 Oct 2009 14:35:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 705A73A67EF for ; Fri, 2 Oct 2009 14:35:02 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [66.78.97.66]) by relay.sandelman.ca (Postfix) with ESMTPS id F016134285; Fri, 2 Oct 2009 21:40:02 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 4C7BB4E803; Fri, 2 Oct 2009 16:50:05 -0400 (EDT) From: Michael Richardson To: roll WG X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 02 Oct 2009 16:50:05 -0400 Message-ID: <19905.1254516605@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: [Roll] loops due to membership in multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 02 Oct 2009 21:35:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On the jabber during Wednesday's meeting (I was listening on the voice bridge), Tim Winter asked something, and a light went on in my head. (Probably, my observation is not news to many, but I suspect that it may be a source of some mis-understanding) I heard many people on the list suggest that having multiple DAGs could cause loops. Tim's comments made me understand how this could happen, so let me start by presenting a diagram. (I copied it from someone else's email) [Outlook people, use a fixed font] DAG-A (OCP=1) DAG-B (OCP=2) X | A A / \ / B-C B / \ \ D E E \ / / F F | Y (arrows (arrows point up) all point down) Let's assume that DAG-A has X as the root, and provides general service, while DAG-B has Y as the root, and provides "mains-power only, low-latency" service. Node D has a packet to send. It didn't join the DAG-B because it didn't need that service. It sends a packet out, and it goes along the link to B. B sees the packet, is sure that it knows a better way along DAG-B, and sends it to E. E sends to F, and F does what? F is part of DAG-A and DAG-B. If it sends with DAG-A, it goes back to D (and there is a loop). If it sends with DAG-B, then it's okay, but, we have the same situation on A as well. (My example is probably not designed right to explain things well enough, perhaps someone can improve the example) ** My assumption up to now was that if you want to use DAG-A, that D would ** have put something into the IPv6 flow label, to indicate things, but I ** don't see anything in any document that says this. (Does not have to be flow label. It could also be done with a per-hop routing options: a source route, or could be MPLS stack, or could be ethernet VLAN tags even...) - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSsZneICLcPvd0N1lAQKTwwf9HZpFyNDRQoie1ZwC2FKtAvbeFz+QYAf4 mtsGDlpCRxBAX8+ZGe5xUo6aNfay3FsTW76tjKapiPuKNQOYaNKd4hL6r12JkEqE re4vlUo7wf6t0W4VWXTHA17TegtxgMJCxqWxZQupiylzthcbNAy+jcTBHZKqJS8x YFy6gjBRZNXIebMMjZ/RNOD3GIAub2rNj6Z/uZgj6Km9sHCRUFuorL8wRtwJEEUD Mrnav5UTnonqDY9fYi+OJb8sV4gsd1TUWhNLv6kvGXk0J0cRjOecxSmYqBGW3Qf5 2WXE/aKjkfhNIwGn3GOQxgQ3ycUN5bxq4e+Ek8kOAMZDYET/jm70TQ== =b2yD -----END PGP SIGNATURE----- From prvs=520c6ee4b=mukul@uwm.edu Sat Oct 3 11:44:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CDF3A6A09 for ; Sat, 3 Oct 2009 11:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoypH2MGbYeh for ; Sat, 3 Oct 2009 11:44:04 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 37D833A69F1 for ; Sat, 3 Oct 2009 11:43:38 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 03 Oct 2009 13:45:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 420EFC085C8; Sat, 3 Oct 2009 13:45:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIMmBGjg28kJ; Sat, 3 Oct 2009 13:45:09 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1EDB3C085A0; Sat, 3 Oct 2009 13:45:09 -0500 (CDT) Date: Sat, 3 Oct 2009 13:45:09 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <503515698.14016391254595509004.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1878566310.14015941254595180836.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] DAG hop timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 03 Oct 2009 18:44:27 -0000 Hi Pascal Current RPL specs require a separate DAG hop timer for each neighbor in held_up state. All these timers are stopped as soon as one of the timers fires. There is no guarantee that the timer for the neighbor with minimum rank will fire first. If the timer for some other neighbor fires first, the node will have to wait for next RA from minimum-rank neighbor to include it as a parent. How about running just one timer. When a neighbor with lower rank is discovered, the current timer is stopped and restarted with a delay proportional to this lower rank. This ensures that the neighbor with lowest rank will be chosen as parent. Also, only one timer will be required. Thanks Mukul From prvs=520c6ee4b=mukul@uwm.edu Sat Oct 3 14:03:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9C53A69FF for ; Sat, 3 Oct 2009 14:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylW5p0Ff4SAP for ; Sat, 3 Oct 2009 14:03:39 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 8B9AB3A69FE for ; Sat, 3 Oct 2009 14:03:39 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 03 Oct 2009 16:05:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6710BC085D0 for ; Sat, 3 Oct 2009 16:05:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rYO5RsgSZxr for ; Sat, 3 Oct 2009 16:05:09 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 46DBDC085C8 for ; Sat, 3 Oct 2009 16:05:09 -0500 (CDT) Date: Sat, 3 Oct 2009 16:05:09 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <719358156.14031061254603909201.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1436506877.14030931254603820491.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] one DAG per RPL instance X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 03 Oct 2009 21:03:40 -0000 Hi all, I was wondering if people with experience in writing code for memory/CPU constrained devices can comment on this: If a device has to join multiple DAGs, does it make a difference (from the perspective of memory requirement and execution efficiency) whether the device runs a single RPL process (supporting all the DAGs) or multiple RPL processes (each supporting just one DAG). Thanks Mukul From jvasseur@cisco.com Sun Oct 4 00:06:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5E428C114 for ; Sun, 4 Oct 2009 00:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.717 X-Spam-Level: X-Spam-Status: No, score=-9.717 tagged_above=-999 required=5 tests=[AWL=0.882, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9TVnH+iWzD0 for ; Sun, 4 Oct 2009 00:06:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6B6EC28C110 for ; Sun, 4 Oct 2009 00:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=734; q=dns/txt; s=amsiport01001; t=1254640102; x=1255849702; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20one=20DAG=20per=20RPL=20instance|Date:=20Su n,=204=20Oct=202009=2009:06:43=20+0200|Message-Id:=20|To:=20Mukul =20Goyal=20|Cc:=20roll=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20<7193 58156.14031061254603909201.JavaMail.root@mail02.pantherli nk.uwm.edu>|References:=20<719358156.14031061254603909201 .JavaMail.root@mail02.pantherlink.uwm.edu>; bh=4272LWXnHKu+b/mRxan0XWgUPBVwEK9YGFK/tjDtuKQ=; b=GU2f6KOqj10NSbm2nvAf1X7wo8k92eWQlQUz1gWYhuL+CiKoXt0RLYwc e66B5HaZudDERkX0TWB4RHWXM820uCbwC/7D4J5pINz/6f3HWA17TMv3o Z+hx3COmHdtv4RgngsEgsc3QuI7pFXUKID0G/Na+JFffXZEn8TNjPMwif I=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAAOvmx0qQ/uCKe2dsb2JhbACadgEBFiQGnk6IYQGOBgaEKooh X-IronPort-AV: E=Sophos;i="4.44,501,1249257600"; d="scan'208";a="50867889" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 04 Oct 2009 07:08:20 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n9478KOS013576; Sun, 4 Oct 2009 09:08:20 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9478Knv014624; Sun, 4 Oct 2009 07:08:20 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Oct 2009 09:08:20 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Oct 2009 09:08:19 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <719358156.14031061254603909201.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 4 Oct 2009 09:06:43 +0200 References: <719358156.14031061254603909201.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 04 Oct 2009 07:08:19.0257 (UTC) FILETIME=[739DAA90:01CA44C1] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16926.005 X-TM-AS-Result: No--10.748600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=734; t=1254640100; x=1255504100; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20one=20DAG=20per=20RPL=20instan ce |Sender:=20; bh=4272LWXnHKu+b/mRxan0XWgUPBVwEK9YGFK/tjDtuKQ=; b=Bk148HQqOmOodexpTWeppnauERo1p3ttlKNvPZzyd+M8gLw9Yaocz97U+u GJtC6EgXN2+oaUyas5gqultfB8EBVNQ/hlABgkV3CBkS9atxA3aMehq4cS5q z0/J8b+JtR; Cc: roll Subject: Re: [Roll] one DAG per RPL instance X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 04 Oct 2009 07:06:50 -0000 Hi, On Oct 3, 2009, at 11:05 PM, Mukul Goyal wrote: > Hi all, > > I was wondering if people with experience in writing code for memory/ > CPU constrained devices can comment on this: If a device has to join > multiple DAGs, does it make a difference (from the perspective of > memory requirement and execution efficiency) whether the device runs > a single RPL process (supporting all the DAGs) or multiple RPL > processes (each supporting just one DAG). > It does make a difference but if coded right, a very minor difference. Thanks, JP. > Thanks > Mukul > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=52171bf0c=mukul@uwm.edu Sun Oct 4 10:06:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C71F3A6985 for ; Sun, 4 Oct 2009 10:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGSYzccnvlo3 for ; Sun, 4 Oct 2009 10:06:16 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id A7EE93A6951 for ; Sun, 4 Oct 2009 10:06:16 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 04 Oct 2009 12:07:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E0A2EC085CB for ; Sun, 4 Oct 2009 12:07:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv5XOaD5UViH for ; Sun, 4 Oct 2009 12:07:48 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C11ACC085C8 for ; Sun, 4 Oct 2009 12:07:48 -0500 (CDT) Date: Sun, 4 Oct 2009 12:07:48 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <115505976.14107241254676068702.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] PathDigest X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 04 Oct 2009 17:06:32 -0000 PathDigest allows a node to let its children know if the DAG structure above has changed. I am not sure why do we need a 32-bit field for this purpose. Won't a single bit flag suffice? Set the flag if my own parent set has changed since the last DIO or if the latest DIO from a parent has the flag set. Thanks Mukul From prvs=52171bf0c=mukul@uwm.edu Sun Oct 4 10:41:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F7E3A69A0 for ; Sun, 4 Oct 2009 10:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb9K7PSUylNm for ; Sun, 4 Oct 2009 10:41:25 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 0746B3A693D for ; Sun, 4 Oct 2009 10:41:24 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 04 Oct 2009 12:42:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id CFF48C085D0 for ; Sun, 4 Oct 2009 12:42:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewsbp7seBGwQ for ; Sun, 4 Oct 2009 12:42:56 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6A107C085D1 for ; Sun, 4 Oct 2009 12:42:56 -0500 (CDT) Date: Sun, 4 Oct 2009 12:42:56 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <374606814.14111761254678176353.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <115505976.14107241254676068702.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] PathDigest X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 04 Oct 2009 17:41:26 -0000 OK. Sorry for asking too soon. 32-bit PathDigest value is to protect against loss of RAs. 1-bit flag wont work if the RA carrying the flag does not reach a child. Mukul ----- Original Message ----- From: "Mukul Goyal" To: "roll" Sent: Sunday, October 4, 2009 12:07:48 PM GMT -06:00 US/Canada Central Subject: [Roll] PathDigest PathDigest allows a node to let its children know if the DAG structure above has changed. I am not sure why do we need a 32-bit field for this purpose. Won't a single bit flag suffice? Set the flag if my own parent set has changed since the last DIO or if the latest DIO from a parent has the flag set. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sun Oct 4 22:32:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5648A3A697F for ; Sun, 4 Oct 2009 22:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiOoNdN+Qi-v for ; Sun, 4 Oct 2009 22:32:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7E8FA3A67D6 for ; Sun, 4 Oct 2009 22:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4664; q=dns/txt; s=amsiport01001; t=1254720867; x=1255930467; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20loops=20due=20to=20membe rship=20in=20multiple=20DAGs|Date:=20Mon,=205=20Oct=20200 9=2007:34:19=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE 2026AA50A5D5A21E4@XMB-AMS-107.cisco.com>|To:=20"Michael =20Richardson"=20,=20"roll=20WG"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<19905.1254516605@marajade.sandelman.ca> |References:=20<19905.1254516605@marajade.sandelman.ca>; bh=ZgyZm/3YSzNiYDzqtiFPYA+zyF075z5Tw/O9PUhRI7s=; b=TIJDXjwsoZlfu3RllygXa+yrc3JJfc0QVeZc/gRAl003kdCWsdCfGNSD 6M6QFTbJboTYFAEVAozAGvCoTkVQ/GrP90AYTgcdDi+Pol4KPirDwgzWa SjHds/rUDh8GuMjsgQoieavbIiFsAfWZyRjvr4hyLlKevCcgLR98tPCV2 E=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pthubert@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUAACciyUqQ/uCKe2dsb2JhbACadwEBFiQGngOIYQFLjHsGhCqBVg X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208";a="50899714" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 05:34:25 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n955YPsG011473; Mon, 5 Oct 2009 07:34:25 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n955YPG9002299; Mon, 5 Oct 2009 05:34:25 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 07:34:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Oct 2009 07:34:19 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D5A21E4@XMB-AMS-107.cisco.com> In-Reply-To: <19905.1254516605@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] loops due to membership in multiple DAGs Thread-Index: AcpDqGwC3GAsrtxLTgK5ROecn5OqOQB0NarQ References: <19905.1254516605@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "roll WG" X-OriginalArrivalTime: 05 Oct 2009 05:34:25.0158 (UTC) FILETIME=[7FD82260:01CA457D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4664; t=1254720865; x=1255584865; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20loops=20due=20to=20membership= 20in=20multiple=20DAGs |Sender:=20; bh=ZgyZm/3YSzNiYDzqtiFPYA+zyF075z5Tw/O9PUhRI7s=; b=m0zSKtxilMUJjO68LFZUaiNlXcpF8RMyt5JfkYnQsXxIvTPzBRuiQyjHjB RzyXkbZvqx83nqo9RDEU7rNFdK0WKGMS5qug7F0LDczo/4YqFMjZXdg/YiN0 EwQBCtwdZu; Subject: Re: [Roll] loops due to membership in multiple DAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 05:32:54 -0000 Hi Richard: I think we're on the same line. If you look up the 'MTR' in this list you might find additional discussion on this. My understanding is that the group decided to go to multiple instances operated as ship in the night. What the RPL spec describes is what happens within one instance and should be enough for a simple operation. An extension spec will describe the multiple instances - that should not be too thick. RPL will be written so as to enable a node that implements only one instance to cooperate with nodes implementing multiple instances. We'll have to describe how a packet is marked to follow that instance so as to be compatible with multiple instances.=20 DAGs within one instance are mutually exclusive, IOW A node can only belong to one DAG for one instance. DAGs from different instances are not exclusive and nodes can participate to multiple instance. Whether a packet can leave an instance to join another one will be a policy decision. The policy must be loopless, for instance by making a strict hierarchy of instances. Multiple Instances will probably require quite a bit of administration, to match the flows and instance ID, and distribute the policies. More in "My notes from the meeting" Cheers, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson >Sent: vendredi 2 octobre 2009 22:50 >To: roll WG >Subject: [Roll] loops due to membership in multiple DAGs > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >On the jabber during Wednesday's meeting (I was listening on the voice >bridge), Tim Winter asked something, and a light went on in my head. > >(Probably, my observation is not news to many, but I suspect that it may >be a source of some mis-understanding) > >I heard many people on the list suggest that having multiple DAGs could >cause loops. Tim's comments made me understand how this could happen, >so let me start by presenting a diagram. (I copied it from someone >else's email) [Outlook people, use a fixed font] > > DAG-A (OCP=3D1) DAG-B (OCP=3D2) > > X > | > A A > / \ / > B-C B > / \ \ > D E E > \ / / > F F > | > Y > (arrows (arrows > point up) all point down) > >Let's assume that DAG-A has X as the root, and provides general service, >while DAG-B has Y as the root, and provides "mains-power only, >low-latency" service. > >Node D has a packet to send. It didn't join the DAG-B because it didn't >need that service. It sends a packet out, and it goes along the link to >B. B sees the packet, is sure that it knows a better way along DAG-B, >and sends it to E. E sends to F, and F does what? > >F is part of DAG-A and DAG-B. If it sends with DAG-A, it goes back to D >(and there is a loop). If it sends with DAG-B, then it's okay, but, we >have the same situation on A as well. > >(My example is probably not designed right to explain things well >enough, perhaps someone can improve the example) > >** My assumption up to now was that if you want to use DAG-A, that D would >** have put something into the IPv6 flow label, to indicate things, but I >** don't see anything in any document that says this. > >(Does not have to be flow label. It could also be done with a per-hop >routing options: a source route, or could be MPLS stack, or could be >ethernet VLAN tags even...) > >- -- >] He who is tired of Weird Al is tired of life! | firewalls [ >] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ >] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > > > > > > > > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.9 (GNU/Linux) >Comment: Finger me for keys > >iQEVAwUBSsZneICLcPvd0N1lAQKTwwf9HZpFyNDRQoie1ZwC2FKtAvbeFz+QYAf4 >mtsGDlpCRxBAX8+ZGe5xUo6aNfay3FsTW76tjKapiPuKNQOYaNKd4hL6r12JkEqE >re4vlUo7wf6t0W4VWXTHA17TegtxgMJCxqWxZQupiylzthcbNAy+jcTBHZKqJS8x >YFy6gjBRZNXIebMMjZ/RNOD3GIAub2rNj6Z/uZgj6Km9sHCRUFuorL8wRtwJEEUD >Mrnav5UTnonqDY9fYi+OJb8sV4gsd1TUWhNLv6kvGXk0J0cRjOecxSmYqBGW3Qf5 >2WXE/aKjkfhNIwGn3GOQxgQ3ycUN5bxq4e+Ek8kOAMZDYET/jm70TQ=3D=3D >=3Db2yD >-----END PGP SIGNATURE----- >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Sun Oct 4 22:49:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6973A68E7 for ; Sun, 4 Oct 2009 22:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31sWUhzxzKdj for ; Sun, 4 Oct 2009 22:49:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8F77D3A688B for ; Sun, 4 Oct 2009 22:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1761; q=dns/txt; s=amsiport01001; t=1254721876; x=1255931476; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20one=20DAG=20per=20RPL=20 instance|Date:=20Mon,=205=20Oct=202009=2007:51:10=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D5A21E7@XM B-AMS-107.cisco.com>|To:=20"JP=20Vasseur=20(jvasseur)"=20 ,=0D=0A=20=20=20=20=20=20=20=20"Mukul =20Goyal"=20|Cc:=20"roll"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted -printable|In-Reply-To:=20|References:=20<719358156.14031061254603 909201.JavaMail.root@mail02.pantherlink.uwm.edu>=20; bh=aJ4fxW/jWMGUVIjzOFHcoCxzoXeZsFGgQSV0wIo2EqU=; b=mrIAjHGGHJSUtIeDa114sTRZ9Y0i+XLYJ3PyUJ2BOqTLWoJQ+8Q1OZqP FlwX6Fk+aLQa0Oo+ei7Zsia5YYsAG8cpHhLrcSmFLsDTiLBIBbPtxh84Q IG7EBGq1MgzGCojKzFD64E7Z/t2a7q7jD49TYI2I/qxXV++Xwx2sA0rvF 4=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pthubert@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUAAKolyUqQ/uCKe2dsb2JhbACadwEBFiQGngGIYQGNSgaEKooh X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208";a="50900413" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 05:51:14 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n955pESI014130; Mon, 5 Oct 2009 07:51:14 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n955pE86004920; Mon, 5 Oct 2009 05:51:14 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 07:51:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Oct 2009 07:51:10 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D5A21E7@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] one DAG per RPL instance Thread-Index: AcpEwY1vNBUcGDUzQ5K850RbskT+SQAvC2Gw References: <719358156.14031061254603909201.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "Mukul Goyal" X-OriginalArrivalTime: 05 Oct 2009 05:51:14.0509 (UTC) FILETIME=[D976DFD0:01CA457F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1761; t=1254721874; x=1255585874; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20one=20DAG=20per=20RPL=20instan ce |Sender:=20; bh=aJ4fxW/jWMGUVIjzOFHcoCxzoXeZsFGgQSV0wIo2EqU=; b=qihXy4n67/kHLRdIinaqL4D/m/dwBin3/z03o5kDpwDFqykKhigvOP48UA 5NFhpjcL7WY7+C5N7XOrwQFzG2Rsvzst0Ju+ko2MjnVu42oJoCDlYy2nItmX 9eFBfa4XXK; Cc: roll Subject: Re: [Roll] one DAG per RPL instance X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 05:49:43 -0000 > >On Oct 3, 2009, at 11:05 PM, Mukul Goyal wrote: > >> Hi all, >> >> I was wondering if people with experience in writing code for memory/ >> CPU constrained devices can comment on this: If a device has to join >> multiple DAGs, does it make a difference (from the perspective of >> memory requirement and execution efficiency) whether the device runs >> a single RPL process (supporting all the DAGs) or multiple RPL >> processes (each supporting just one DAG). >> > >It does make a difference but if coded right, a very minor difference. Agreed. Instances are contexts that run the same code and operate as ship in the night. The additional work will have to do with instance transition policies, but policies are already present in the OCP for a single instance. The price to pay will probably be more in terms of: - battery. It appears that the control cost (memory, protocol exchanges) is multiplied by the number of instances. - admin. As soon as you have multiple instances, you have to distribute your instance IDs, policies, etc... As opposed to implementation complexity. Note: We've had a lot of confusion mentioning multiple DAGs. There can be multiple DAGs within an instance (mutually exclusive) or serving different instances. It appears that your question is really about serving multiple instances and it will certainly help if we adopt a common language for the concept. Cheers, Pascal > >JP. > > >> Thanks >> Mukul >> >> _______________________________________________ >> 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 jabeille@cisco.com Mon Oct 5 02:56:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27A73A6921 for ; Mon, 5 Oct 2009 02:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.938 X-Spam-Level: X-Spam-Status: No, score=-9.938 tagged_above=-999 required=5 tests=[AWL=0.661, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a9wHVJ8fRTB for ; Mon, 5 Oct 2009 02:56:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3A8D83A68C9 for ; Mon, 5 Oct 2009 02:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=5483; q=dns/txt; s=amsiport01001; t=1254736690; x=1255946290; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[Roll]=20My=20notes=20from=20the =20meeting|Date:=20Mon,=205=20Oct=202009=2011:58:06=20+02 00|Message-ID:=20|To:=20"Pascal=20Thubert=20(pthuber t)"=20,=0D=0A=20=20=20=20=20=20=20=20 "JP=20Vasseur=20(jvasseur)"=20|Cc:=20 "Tim=20Winter"=20,=20"IETF=20ROLL"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@X MB-AMS-107.cisco.com>|References:=20<4AC3CD83.4080309@acm .org>=20<6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-1 07.cisco.com>=20=20<5E92BF81-1F51-4D1D-A8C0-93490328 9208@cisco.com>=20<6A2A459175DABE4BB11DE2026AA50A5D5A1FB4 @XMB-AMS-107.cisco.com>; bh=3nIfgg2HbAN4uWpDCZUNe2pqcVrZBunYPSsvMr88foA=; b=RoKcM60qwkoq5OjOwOtUyZSAsLT0/khPqqqXSlkz3G/BWYnHo1asQBj1 m/6nZdj9KTkFojdt546gGcL+utdNERDX/z/Z8bI5jMSbOW9EMjlCEDks2 vh5Tql98+iKcCSUjeSeqJESzyLntfUGnX+xBZcPR+973f+k7pLKkHFUFm k=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=jabeille@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUAAEJgyUqQ/uCLe2dsb2JhbACadwEBFiQGnnyIYQGNWwaCMIF6gVY X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208";a="50931553" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 09:58:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n959w8iV032048; Mon, 5 Oct 2009 11:58:08 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n959w8ZB002233; Mon, 5 Oct 2009 09:58:08 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 11:58:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Oct 2009 11:58:06 +0200 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] My notes from the meeting Thread-Index: AcpDahzeaY6Mld8sQp+Tzis01t+slgAAMEVwAI05FoA= References: <4AC3CD83.4080309@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> <5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 05 Oct 2009 09:58:08.0401 (UTC) FILETIME=[573B6810:01CA45A2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5483; t=1254736688; x=1255600688; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jabeille@cisco.com; z=From:=20=22Julien=20Abeille=20(jabeille)=22=20 |Subject:=20RE=3A=20[Roll]=20My=20notes=20from=20the=20meet ing |Sender:=20; bh=3nIfgg2HbAN4uWpDCZUNe2pqcVrZBunYPSsvMr88foA=; b=LcNkhhZK7CAGRqvtKtLBHDMdg7VMIvdxKKZAUkgdCw+d9DkwGwbM8iAnYS lDXerpe4uKl4fZwNggI3aH3IULoonVEp+MRYcKyfzeknPlSmFI+2F++d6yw1 iBVCvKi2wX; Cc: IETF ROLL Subject: Re: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 09:56:37 -0000 Hi Pascal, all, See inline. > -----Original Message----- > From: Pascal Thubert (pthubert)=20 > Sent: vendredi 2 octobre 2009 16:36 > To: JP Vasseur (jvasseur); Julien Abeille (jabeille) > Cc: Tim Winter; IETF ROLL > Subject: RE: [Roll] My notes from the meeting >=20 > Hi Julien and JP >=20 > >> Thanks for the notes. One thing about point 1. My understanding is=20 > >> that we agreed that there was no concept of "default" DAG,=20 > or "white=20 > >> DAG". As JP said RPL will define one (colored) DAG, but what the=20 > >> color means and how it is used is out of scope of the spec. The=20 > >> proposal that RPL defines a "default DAG" concept, and=20 > especially the=20 > >> need for all nodes to belong to it, was rejected as far as I=20 > >> understood and should be treated if needed in a separate document. > >> > >> Was my understanding correct? > >> > > > >Yes absolutely. In fact what defines the color of the DAG is the OCP. > >The decision to join one of multiple DAG (instance of RPL)=20 > is a local=20 > >policy decision of the node. > >A separate ID will define the tagging mechanism used to identify to=20 > >which DAG the packet belongs to, similarly to MTR. >=20 > Well, there is such a concept though it does not meet the eye. >=20 > Our spec must be self contained and the other specs are=20 > extensions. We need to specify the field where the instanceID=20 > will appear. Otherwise the instance extensions would not be=20 > compatible.=20 [Julien] 100% Agreed > And we need to specify a value to put in that=20 > field. RPL will work with a zero as the default. [Julien] not clear to me if this is needed, e.g. IPv6 RFC2460 defines a Hop Limit field, but does not define any value. Other specs (e.g. ND RFC4861) define values for specific messages. What does a default value concept add here? >=20 > At that point we need to think about what happens to a router=20 > that has RPL but no extension. If we do not say anything,=20 > such a router mixed with a router that support instanceID=20 > will loop.=20 [Julien] the router that supports just RPL will keep packets in the same DAG, will not use simblings. Hence there will be no loop. > So there must be a minimum support in the base=20 > spec about instance. That minimum must handle the case where=20 > a packet comes in with a color as well as the operation for=20 > processing RPL packets for colored DAG. >=20 [Julien] Every DAG is colored as agreed in the meeting. "0", "white", or "default" is a color, with no different meaning than "1", "blue" as agreed in the meeting. > If the minimum support is instance zero, [Julien] we did not say that there was support for only one instance ID, because we did not give a specific meaning to 0. Hence a RPL only router will know how to forward along the same DAG. > a node that=20 > implements only the RPL base MUST ignore RPL PDUs for non=20 > zero instances. As JP says that's an OCP behavior, and we'll=20 > have to add an instance filter to OCP0. That also means that=20 > when processing a packet of any color, this node will forward=20 > it against the instance 0. To avoid loops, the default node=20 > must thus zero out the tag. > =09 > That makes instance 0 the default topology... QED ;)=20 [Julien] looks like a loop ;-): 0 is the default, hence RPL only routers do not support something else than 0, hence every router must support 0. We do not have this issue if we do not define a "default" concept, or at least if we define a default value, that has no semantic difference with other values. I feel we should move forward based on what was agreed, and avoid redicussing points that were agreed on. The importance of defining in RPL a white DAG that is semanticaly different from the colored ones was not agreed in the meeting. There was a strong consensus that there will be colors, but each with the same importance (no special meaning for some values), and that it was admin's responsibility to configure it properly if required. I think we should stick to this.=20 Best, Julien > =20 > Pascal > > > >> > >>> -----Original Message----- > >>> From: roll-bounces@ietf.org=20 > [mailto:roll-bounces@ietf.org] On Behalf=20 > >>> Of Pascal Thubert (pthubert) > >>> Sent: jeudi 1 octobre 2009 15:15 > >>> To: Tim Winter > >>> Cc: IETF ROLL > >>> Subject: [Roll] My notes from the meeting > >>> > >>> Hi Tim (and all): > >>> > >>> Please find my annotated notes on the changes that were=20 > proposed at=20 > >>> the interim in ROLLE: > >>> > >>> 1) Multi Topology Routing (MTR) is adopted as a base spec=20 > to handle=20 > >>> heterogeneous requirements > >>> A topology is defined by where it goes (destination, > >>> default) and how to get there (OCP/OF, metrics) > >>> We need in the intro to say that topologies controlled by=20 > >>> ship-in-the-night instances of the protocol. > >>> TopoID=3D=3D instanceID is indicated in all control messages, and = > >>> encoded in the flow label in all packets > >>> Requires provisioning when using other than the default=20 > topology. > >>> Default topo is topoID 0. In general all nodes are expected to=20 > >>> participate at least to that one. > >>> Passed the intro, the text will (mostly) only need to=20 > explain to=20 > >>> what happens within one instance. > >>> Much of that is hopefully very close to the current text :) > >>> >=20 >=20 From abr@sdesigns.dk Mon Oct 5 04:49:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74893A69C0 for ; Mon, 5 Oct 2009 04:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.793, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlbQLVQQP3Oj for ; Mon, 5 Oct 2009 04:49:21 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 56C2328C1A4 for ; Mon, 5 Oct 2009 04:49:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Oct 2009 13:50:53 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429AEC@zensys17.zensys.local> In-Reply-To: <27019.1254494330@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] minor comments on rpl-02 Thread-Index: AcpDbhRLn7HtQxIQQ9W5aZ/Qf0kTxQCQ4ETw References: <27019.1254494330@marajade.sandelman.ca> From: "Anders Brandt" To: "Michael Richardson" , "ROLL WG" Subject: Re: [Roll] minor comments on rpl-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 11:49:21 -0000 Thanks Michael! Adding these small headers (Freedom to Jump Rule), (Nodes are Unstable When Jumping Rule) just increases the readability so much. I really think we should consider such sub-headers for every rule. We should be able to make this so simple that the reader gets the big picture from scanning the table of contents. Cheers, Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: 2. oktober 2009 16:39 To: ROLL WG Subject: [Roll] minor comments on rpl-02 re: 5.3.1. DAG Discovery Rules There are 11 rules. I think we have spent some significant time discussing some of the rules. I wonder if it might be worth naming the rules in some way. i.e. 7. (Freedom to Jump Rule) A node may jump from its current DAG into any different DAG if .... 8. (Nodes are Unstable When Jumping Rule)=09 If a node has selected a new set of DAG parents but has not moved yet (because it is waiting for DAG Hop timer to elapse), the node is unstable MUST NOT send RA-DIOs for that DAG. ^AND {Q: for which DAG? the one it is leaving, or the one it is joining?} or perhaps: 7. A node may jump from its current DAG into any different DAG if ... 7.1. A node may have to wait for a DAG Hop timer to elapse before it jumps to another DAG. This allows the new higher parts (closer to the sink) of the DAG to move first, thus allowing stepped DAG .... --=20 ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Oct 5 04:51:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD59228C1A8 for ; Mon, 5 Oct 2009 04:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.73 X-Spam-Level: X-Spam-Status: No, score=-9.73 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTwCnEVur9HV for ; Mon, 5 Oct 2009 04:51:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6368A28C1A4 for ; Mon, 5 Oct 2009 04:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=15375; q=dns/txt; s=amsiport01001; t=1254743580; x=1255953180; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20My=20notes=20from=20the=20meeting|Date:=20M on,=205=20Oct=202009=2013:50:56=20+0200|Message-Id:=20<7F 28747C-89B6-4D6A-89FD-122CA656953A@cisco.com>|To:=20Julie n=20Abeille=20(jabeille)=20|Cc:=20"Pa scal=20Thubert=20(pthubert)"=20,=0D =0A=20=20=20=20=20=20=20=20"Tim=20Winter"=20,=20"IETF=20ROLL"=20|Mime-Version:=201 .0=20(Apple=20Message=20framework=20v936)|In-Reply-To:=20 |References:=20<4AC3CD83.4080309@acm.org>=20<6A2A459 175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com>=20 =20<5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> =20<6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.ci sco.com>=20; bh=Zf49QSq3+979gPF461ZIqRm9xtTODzY2FzK6MpTIcJw=; b=GtjcPyWDqcqhQGpVtzk4dHBhFXR1pR5LfCS+mmW819H8QkDb4sgIai8+ QPc8wYqEkAUWS2HszX1e+j8NcZ4h0sHG4YwAUeQ5O6cHk4G1EWjVD5g95 7Nt7KBC3jFw9H20nLfGcOj2lXHzv04Lirgcs1GKS4ulImv6aQXFjAatCw 8=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (partially verified [15342 bytes] [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUAADd7yUqQ/uCLe2dsb2JhbACCKC2YIgEBFiQGnkyIYQGNdgaEKoFW X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208,217";a="50951245" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 11:52:59 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n95BqwaH012465; Mon, 5 Oct 2009 13:52:58 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n95BqxxG017075; Mon, 5 Oct 2009 11:52:59 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 13:52:58 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 13:52:57 +0200 Message-Id: <7F28747C-89B6-4D6A-89FD-122CA656953A@cisco.com> From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-108--589133472 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Oct 2009 13:50:56 +0200 References: <4AC3CD83.4080309@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> <5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Oct 2009 11:52:58.0070 (UTC) FILETIME=[61CB7760:01CA45B2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15342; t=1254743578; x=1255607578; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20My=20notes=20from=20the=20meet ing |Sender:=20; bh=fUxnFx0VStd19BsrIOaNqAsLzxcTFeFrv9SePYjOUYc=; b=JmMTIkdFnMOK+BJ17tzxNL6dgAWtVjxHjBC215PFQbKRcETakI7qtHp5pN gk9SXYUcx+JxHtgiri6Ms5cCruisoeI2IyQFJU3NW0yC9U2rLukHOmIAwMow dtJ6Foxbuv; Cc: IETF ROLL Subject: Re: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 11:51:28 -0000 --Apple-Mail-108--589133472 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit [snip] >> [snip] >> At that point we need to think about what happens to a router >> that has RPL but no extension. If we do not say anything, >> such a router mixed with a router that support instanceID >> will loop. > [Julien] the router that supports just RPL will keep packets in the > same > DAG, will not use simblings. Hence there will be no loop. >> So there must be a minimum support in the base >> spec about instance. That minimum must handle the case where >> a packet comes in with a color as well as the operation for >> processing RPL packets for colored DAG. >> > [Julien] Every DAG is colored as agreed in the meeting. "0", > "white", or > "default" is a color, with no different meaning than "1", "blue" as > agreed in the meeting. >> If the minimum support is instance zero, > [Julien] we did not say that there was support for only one instance > ID, > because we did not give a specific meaning to 0. Hence a RPL only > router > will know how to forward along the same DAG. >> a node that >> implements only the RPL base MUST ignore RPL PDUs for non >> zero instances. As JP says that's an OCP behavior, and we'll >> have to add an instance filter to OCP0. That also means that >> when processing a packet of any color, this node will forward >> it against the instance 0. To avoid loops, the default node >> must thus zero out the tag. >> >> That makes instance 0 the default topology... QED ;) > [Julien] looks like a loop ;-): 0 is the default, hence RPL only > routers > do not support something else than 0, hence every router must > support 0. > We do not have this issue if we do not define a "default" concept, > or at > least if we define a default value, that has no semantic difference > with > other values. > > I feel we should move forward based on what was agreed, and avoid > redicussing points that were agreed on. The importance of defining in > RPL a white DAG that is semanticaly different from the colored ones > was > not agreed in the meeting. There was a strong consensus that there > will > be colors, but each with the same importance (no special meaning for > some values), and that it was admin's responsibility to configure it > properly if required. I think we should stick to this. > Yes, to make it even more simple. White is a color. If one wants to define white as being unconstrained, then fine. Falling back to different colored DAG is a matter of local policy although we may want to define mechanisms later on to make sure that packets do not move back and forth. Cheers. JP. > Best, > Julien >> > >> Pascal >>> >>>> >>>>> -----Original Message----- >>>>> From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf >>>>> Of Pascal Thubert (pthubert) >>>>> Sent: jeudi 1 octobre 2009 15:15 >>>>> To: Tim Winter >>>>> Cc: IETF ROLL >>>>> Subject: [Roll] My notes from the meeting >>>>> >>>>> Hi Tim (and all): >>>>> >>>>> Please find my annotated notes on the changes that were >> proposed at >>>>> the interim in ROLLE: >>>>> >>>>> 1) Multi Topology Routing (MTR) is adopted as a base spec >> to handle >>>>> heterogeneous requirements >>>>> A topology is defined by where it goes (destination, >>>>> default) and how to get there (OCP/OF, metrics) >>>>> We need in the intro to say that topologies controlled by >>>>> ship-in-the-night instances of the protocol. >>>>> TopoID== instanceID is indicated in all control messages, and >>>>> encoded in the flow label in all packets >>>>> Requires provisioning when using other than the default >> topology. >>>>> Default topo is topoID 0. In general all nodes are expected to >>>>> participate at least to that one. >>>>> Passed the intro, the text will (mostly) only need to >> explain to >>>>> what happens within one instance. >>>>> Much of that is hopefully very close to the current text :) >>>>> >> >> --Apple-Mail-108--589133472 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable [snip]

[snip]

At that point we need = to think about what happens to a router
that has RPL but no extension. If we do not say anything, =
such a router mixed with a = router that support instanceID
will loop.
[Julien] the router that = supports just RPL will keep packets in the same
DAG, will not use = simblings. Hence there will be no loop.
So = there must be a minimum support in the base
spec about instance. That minimum must handle the case = where
a packet comes in with = a color as well as the operation for
processing RPL packets for colored = DAG.

[Julien] = Every DAG is colored as agreed in the meeting. "0", "white", = or
"default" is a color, with no different meaning than "1", "blue" = as
agreed in the meeting.
If the minimum = support is instance zero,
[Julien] we did not say that = there was support for only one instance ID,
because we did not give a = specific meaning to 0. Hence a RPL only router
will know how to = forward along the same DAG.
a node that =
implements only the RPL base = MUST ignore RPL PDUs for non
zero instances. As JP says that's an OCP behavior, and = we'll
have to add an instance = filter to OCP0. That also means that
when processing a packet of any color, this node will = forward
it against the = instance 0. To avoid loops, the default node =
must thus zero out the = tag.
=
That makes instance 0 = the default topology... QED ;)
[Julien] looks like a = loop ;-): 0 is the default, hence RPL only routers
do not support = something else than 0, hence every router must support 0.
We do not = have this issue if we do not define a "default" concept, or at
least = if we define a default value, that has no semantic difference = with
other values.

I feel we should move forward based on what = was agreed, and avoid
redicussing points that were agreed on. The = importance of defining in
RPL a white DAG that is semanticaly = different from the colored ones was
not agreed in the meeting. There = was a strong consensus that there will
be colors, but each with the = same importance (no special meaning for
some values), and that it was = admin's responsibility to configure it
properly if required. I think = we should stick to this. =


Yes, to make it even more = simple. White is a color. If one wants to define white as = being
unconstrained, then fine. Falling back to different = colored DAG is a matter of local policy
although we may want = to define mechanisms later on to make sure that packets do = not
move back and = forth.

Cheers.

JP.
=
Best,
Julien


Pascal


-----Original = Message-----
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] = On Behalf
Of = Pascal Thubert = (pthubert)
Sent: jeudi 1 octobre 2009 = 15:15
To: Tim = Winter
Cc: IETF = ROLL
Subject: [Roll] My notes from = the = meeting

Hi Tim (and = all):

Please find my annotated notes = on the changes that were =
proposed at
the interim in = ROLLE:

1) Multi Topology Routing (MTR) = is adopted as a base spec =
to handle
heterogeneous = requirements
A topology is defined by where it = goes = (destination,
default) and how to get there = (OCP/OF, = metrics)
We need in the intro to say that = topologies controlled by =
ship-in-the-night instances of = the = protocol.
TopoID=3D=3D instanceID is = indicated in all control messages, and =
encoded in the flow label in all = packets
Requires provisioning when using = other than the default =
topology.
Default topo is topoID 0. In = general all nodes are expected to =
participate at least to that = one.
Passed the intro, the text will = (mostly) only need to =
explain to
what happens within one = instance.
Much of that is hopefully very = close to the current text = :)




<= /html>= --Apple-Mail-108--589133472-- From jvasseur@cisco.com Mon Oct 5 04:51:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22EB28C1B9 for ; Mon, 5 Oct 2009 04:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.742 X-Spam-Level: X-Spam-Status: No, score=-9.742 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8IpL3XxZklE for ; Mon, 5 Oct 2009 04:51:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9B51B28C1BA for ; Mon, 5 Oct 2009 04:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=15375; q=dns/txt; s=amsiport01001; t=1254743587; x=1255953187; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20My=20notes=20from=20the=20meeting|Date:=20M on,=205=20Oct=202009=2013:53:04=20+0200|Message-Id:=20|To:=20Julie n=20Abeille=20(jabeille)=20|Cc:=20"Pa scal=20Thubert=20(pthubert)"=20,=0D =0A=20=20=20=20=20=20=20=20"Tim=20Winter"=20,=20"IETF=20ROLL"=20|Mime-Version:=201 .0=20(Apple=20Message=20framework=20v936)|In-Reply-To:=20 |References:=20<4AC3CD83.4080309@acm.org>=20<6A2A459 175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com>=20 =20<5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> =20<6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.ci sco.com>=20; bh=8mKJc18t8fyg8Nbl9DGuwYrnGYQSjec5XVIFMOSP4d0=; b=oSPydpjRsNj2LogSm/3VVK+7Sm6AlyAeW914DNHFlrUEoGrT6LMgz1Ee ArsjLL95alFa813RhQw7uWbf8dZHfeobCJDwQ1TtwDL7U2dnJct0rCVHJ 0DfymsjVmSNjAwQI3LlqyGUobt5WNTnEU1+/xgZ+m2L+sT0ZUgaaDo8iM w=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (partially verified [15342 bytes] [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUAADd7yUqQ/uCKe2dsb2JhbACCKC2YIgEBFiQGnkyIYQGNdgaEKoFW X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208,217";a="50951271" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 05 Oct 2009 11:53:06 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n95Br6oR007991; Mon, 5 Oct 2009 13:53:06 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n95Br6f6017120; Mon, 5 Oct 2009 11:53:06 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 13:53:06 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 13:53:05 +0200 Message-Id: From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-109--589006451 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 5 Oct 2009 13:53:04 +0200 References: <4AC3CD83.4080309@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> <5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 05 Oct 2009 11:53:05.0508 (UTC) FILETIME=[663A6A40:01CA45B2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15342; t=1254743586; x=1255607586; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20My=20notes=20from=20the=20meet ing |Sender:=20; bh=yLjBU+9ohQmvfsU68pLbjFYHQW2eBHU7vBii3W6uiVo=; b=pElixiDeW6niuopG1CXbNO1+F9Zw9awDo3z/yTXYkAWva5gyEl7h2kPrbF WEYr36gzVkziFN/plmqUrsZWIQdKYCAZ0oFbvt3AxeiItzQ9R2OZ+9CtOFAO TmhNwTsw7/; Cc: IETF ROLL Subject: Re: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 11:51:33 -0000 --Apple-Mail-109--589006451 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit [snip] >> [snip] >> At that point we need to think about what happens to a router >> that has RPL but no extension. If we do not say anything, >> such a router mixed with a router that support instanceID >> will loop. > [Julien] the router that supports just RPL will keep packets in the > same > DAG, will not use simblings. Hence there will be no loop. >> So there must be a minimum support in the base >> spec about instance. That minimum must handle the case where >> a packet comes in with a color as well as the operation for >> processing RPL packets for colored DAG. >> > [Julien] Every DAG is colored as agreed in the meeting. "0", > "white", or > "default" is a color, with no different meaning than "1", "blue" as > agreed in the meeting. >> If the minimum support is instance zero, > [Julien] we did not say that there was support for only one instance > ID, > because we did not give a specific meaning to 0. Hence a RPL only > router > will know how to forward along the same DAG. >> a node that >> implements only the RPL base MUST ignore RPL PDUs for non >> zero instances. As JP says that's an OCP behavior, and we'll >> have to add an instance filter to OCP0. That also means that >> when processing a packet of any color, this node will forward >> it against the instance 0. To avoid loops, the default node >> must thus zero out the tag. >> >> That makes instance 0 the default topology... QED ;) > [Julien] looks like a loop ;-): 0 is the default, hence RPL only > routers > do not support something else than 0, hence every router must > support 0. > We do not have this issue if we do not define a "default" concept, > or at > least if we define a default value, that has no semantic difference > with > other values. > > I feel we should move forward based on what was agreed, and avoid > redicussing points that were agreed on. The importance of defining in > RPL a white DAG that is semanticaly different from the colored ones > was > not agreed in the meeting. There was a strong consensus that there > will > be colors, but each with the same importance (no special meaning for > some values), and that it was admin's responsibility to configure it > properly if required. I think we should stick to this. > Yes, to make it even more simple. White is a color. If one wants to define white as being unconstrained, then fine. Falling back to different colored DAG is a matter of local policy although we may want to define mechanisms later on to make sure that packets do not move back and forth. Cheers. JP. > Best, > Julien >> > >> Pascal >>> >>>> >>>>> -----Original Message----- >>>>> From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf >>>>> Of Pascal Thubert (pthubert) >>>>> Sent: jeudi 1 octobre 2009 15:15 >>>>> To: Tim Winter >>>>> Cc: IETF ROLL >>>>> Subject: [Roll] My notes from the meeting >>>>> >>>>> Hi Tim (and all): >>>>> >>>>> Please find my annotated notes on the changes that were >> proposed at >>>>> the interim in ROLLE: >>>>> >>>>> 1) Multi Topology Routing (MTR) is adopted as a base spec >> to handle >>>>> heterogeneous requirements >>>>> A topology is defined by where it goes (destination, >>>>> default) and how to get there (OCP/OF, metrics) >>>>> We need in the intro to say that topologies controlled by >>>>> ship-in-the-night instances of the protocol. >>>>> TopoID== instanceID is indicated in all control messages, and >>>>> encoded in the flow label in all packets >>>>> Requires provisioning when using other than the default >> topology. >>>>> Default topo is topoID 0. In general all nodes are expected to >>>>> participate at least to that one. >>>>> Passed the intro, the text will (mostly) only need to >> explain to >>>>> what happens within one instance. >>>>> Much of that is hopefully very close to the current text :) >>>>> >> >> --Apple-Mail-109--589006451 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable [snip]

[snip]

At that point we need = to think about what happens to a router
that has RPL but no extension. If we do not say anything, =
such a router mixed with a = router that support instanceID
will loop.
[Julien] the router that = supports just RPL will keep packets in the same
DAG, will not use = simblings. Hence there will be no loop.
So = there must be a minimum support in the base
spec about instance. That minimum must handle the case = where
a packet comes in with = a color as well as the operation for
processing RPL packets for colored = DAG.

[Julien] = Every DAG is colored as agreed in the meeting. "0", "white", = or
"default" is a color, with no different meaning than "1", "blue" = as
agreed in the meeting.
If the minimum = support is instance zero,
[Julien] we did not say that = there was support for only one instance ID,
because we did not give a = specific meaning to 0. Hence a RPL only router
will know how to = forward along the same DAG.
a node that =
implements only the RPL base = MUST ignore RPL PDUs for non
zero instances. As JP says that's an OCP behavior, and = we'll
have to add an instance = filter to OCP0. That also means that
when processing a packet of any color, this node will = forward
it against the = instance 0. To avoid loops, the default node =
must thus zero out the = tag.
=
That makes instance 0 = the default topology... QED ;)
[Julien] looks like a = loop ;-): 0 is the default, hence RPL only routers
do not support = something else than 0, hence every router must support 0.
We do not = have this issue if we do not define a "default" concept, or at
least = if we define a default value, that has no semantic difference = with
other values.

I feel we should move forward based on what = was agreed, and avoid
redicussing points that were agreed on. The = importance of defining in
RPL a white DAG that is semanticaly = different from the colored ones was
not agreed in the meeting. There = was a strong consensus that there will
be colors, but each with the = same importance (no special meaning for
some values), and that it was = admin's responsibility to configure it
properly if required. I think = we should stick to this. =


Yes, to make it even more = simple. White is a color. If one wants to define white as = being
unconstrained, then fine. Falling back to different = colored DAG is a matter of local policy
although we may want = to define mechanisms later on to make sure that packets do = not
move back and = forth.

Cheers.

JP.
=
Best,
Julien


Pascal


-----Original = Message-----
From: roll-bounces@ietf.org =
[mailto:roll-bounces@ietf.org] = On Behalf
Of = Pascal Thubert = (pthubert)
Sent: jeudi 1 octobre 2009 = 15:15
To: Tim = Winter
Cc: IETF = ROLL
Subject: [Roll] My notes from = the = meeting

Hi Tim (and = all):

Please find my annotated notes = on the changes that were =
proposed at
the interim in = ROLLE:

1) Multi Topology Routing (MTR) = is adopted as a base spec =
to handle
heterogeneous = requirements
A topology is defined by where it = goes = (destination,
default) and how to get there = (OCP/OF, = metrics)
We need in the intro to say that = topologies controlled by =
ship-in-the-night instances of = the = protocol.
TopoID=3D=3D instanceID is = indicated in all control messages, and =
encoded in the flow label in all = packets
Requires provisioning when using = other than the default =
topology.
Default topo is topoID 0. In = general all nodes are expected to =
participate at least to that = one.
Passed the intro, the text will = (mostly) only need to =
explain to
what happens within one = instance.
Much of that is hopefully very = close to the current text = :)




<= /html>= --Apple-Mail-109--589006451-- From pthubert@cisco.com Mon Oct 5 06:49:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DFF28C1D0 for ; Mon, 5 Oct 2009 06:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.122 X-Spam-Level: X-Spam-Status: No, score=-8.122 tagged_above=-999 required=5 tests=[AWL=-1.523, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zzAcygOP0CN for ; Mon, 5 Oct 2009 06:49:09 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1B7CD3A68BB for ; Mon, 5 Oct 2009 06:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7453; q=dns/txt; s=sjiport05001; t=1254750644; x=1255960244; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20My=20notes=20from=20the =20meeting|Date:=20Mon,=205=20Oct=202009=2015:50:14=20+02 00|Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D5A25C4@ XMB-AMS-107.cisco.com>|To:=20"Julien=20Abeille=20(jabeill e)"=20,=0D=0A=20=20=20=20=20=20=20=20 "JP=20Vasseur=20(jvasseur)"=20|Cc:=20 "Tim=20Winter"=20,=20"IETF=20ROLL"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20<4AC3CD83.4080309@acm .org>=20<6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-1 07.cisco.com>=20=20<5E92BF81-1F51-4D1D-A8C0-93490328 9208@cisco.com>=20<6A2A459175DABE4BB11DE2026AA50A5D5A1FB4 @XMB-AMS-107.cisco.com>=20; bh=Pq5ldwDBngruBzffIJSoiBNrW2YW3INo0az5HWFolrY=; b=FDzGEXBbUjGSpAANVLFgGR5wrJrVEkazB9u+wbwgnOLijM6l/4WqZLFt x4xjOQEj2fzoY+NllunS4uMF16Y5ShSJoEvjiDi5Uzq8Mssnd5Q0FvizZ e2Rj07JCuZhnNduCPX4BBUPMintz81mf2JHXgYmkO+yIVyfxzuFguwqqP I=; Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=pthubert@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO+VyUqrR7MV/2dsb2JhbAC7NohhAY13BoIwgXqBVg X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208";a="97437262" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2009 13:50:30 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n95DoUko011381; Mon, 5 Oct 2009 06:50:30 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n95DoPwW016901; Mon, 5 Oct 2009 13:50:30 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 15:50:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Oct 2009 15:50:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D5A25C4@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] My notes from the meeting Thread-Index: AcpDahzeaY6Mld8sQp+Tzis01t+slgAAMEVwAI05FoAABBYZEA== References: <4AC3CD83.4080309@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D54AA6F@XMB-AMS-107.cisco.com> <5E92BF81-1F51-4D1D-A8C0-934903289208@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D5A1FB4@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 05 Oct 2009 13:50:23.0805 (UTC) FILETIME=[C9614ED0:01CA45C2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7453; t=1254750630; x=1255614630; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20My=20notes=20from=20the=20meet ing |Sender:=20; bh=Pq5ldwDBngruBzffIJSoiBNrW2YW3INo0az5HWFolrY=; b=J8NWenrCfVxVcEUC5YbxziLEufiUUdP1NhK0iLpaiYzyrnunoJO9eaJ3rv bpZGFNA6yiGje3voUCYOnsEUQJP4welEcwogMZnl0Mv8cPYlKtQIIWsCy0Ou EYYH8l8sfakqes4STq6LR9K4YbL1FdtqAxL11tWgxBrTqlhf2GJq8=; Cc: IETF ROLL Subject: Re: [Roll] My notes from the meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 13:49:10 -0000 Hi Julien: Seems something was lost en-route. I try again.=20 >> And we need to specify a value to put in that >> field. RPL will work with a zero as the default. >[Julien] not clear to me if this is needed,=20 If what you have is mind is to allow an RPL-base deployment to use a non-zero value, I'm all with you. The need for a default value comes from the "autonomicity" requirement, IOW the capability to work with zero or minimum configuration. We cannot force some administration on every node just to specify which color it would operate in any given deployment, can we? So you configure nothing, you get instance 0. Would you agree if the terms are to default the instance field to zero in the absence of administrative override?=20 Note that this is very different from making it reserved and thus forced to zero. >> At that point we need to think about what happens to a router >> that has RPL but no extension. If we do not say anything, >> such a router mixed with a router that support instanceID >> will loop. >[Julien] the router that supports just RPL will keep packets in the same DAG, ... A RPL-base node will do what it can with the means in the base spec and its own policies.=20 I think that the base spec must at least specify where the color is in the packet, and that a router that forwards a packet along a given DAG must make sure that the color in the packet matches the color of that DAG.=20 >[Julien] ... , will not use simblings. Hence Hum... If such words exist in the spec that must be fixed. Certainly the current spec enables siblings and that's quite unrelated with multiple instances. Cheers - and many thanks for the ride to the station after the interim :) Pascal >-----Original Message----- >From: Julien Abeille (jabeille) >Sent: lundi 5 octobre 2009 11:58 >To: Pascal Thubert (pthubert); JP Vasseur (jvasseur) >Cc: 'Tim Winter'; 'IETF ROLL' >Subject: RE: [Roll] My notes from the meeting > >Hi Pascal, all, > >See inline. > >> -----Original Message----- >> From: Pascal Thubert (pthubert) >> Sent: vendredi 2 octobre 2009 16:36 >> To: JP Vasseur (jvasseur); Julien Abeille (jabeille) >> Cc: Tim Winter; IETF ROLL >> Subject: RE: [Roll] My notes from the meeting >> >> Hi Julien and JP >> >> >> Thanks for the notes. One thing about point 1. My understanding is >> >> that we agreed that there was no concept of "default" DAG, >> or "white >> >> DAG". As JP said RPL will define one (colored) DAG, but what the >> >> color means and how it is used is out of scope of the spec. The >> >> proposal that RPL defines a "default DAG" concept, and >> especially the >> >> need for all nodes to belong to it, was rejected as far as I >> >> understood and should be treated if needed in a separate document. >> >> >> >> Was my understanding correct? >> >> >> > >> >Yes absolutely. In fact what defines the color of the DAG is the OCP. >> >The decision to join one of multiple DAG (instance of RPL) >> is a local >> >policy decision of the node. >> >A separate ID will define the tagging mechanism used to identify to >> >which DAG the packet belongs to, similarly to MTR. >> >> Well, there is such a concept though it does not meet the eye. >> >> Our spec must be self contained and the other specs are >> extensions. We need to specify the field where the instanceID >> will appear. Otherwise the instance extensions would not be >> compatible. >[Julien] 100% Agreed > >> And we need to specify a value to put in that >> field. RPL will work with a zero as the default. >[Julien] not clear to me if this is needed, e.g. IPv6 RFC2460 defines a Hop Limit field, but does not define >any value. Other specs (e.g. ND RFC4861) define values for specific messages. >What does a default value concept add here? >> >> At that point we need to think about what happens to a router >> that has RPL but no extension. If we do not say anything, >> such a router mixed with a router that support instanceID >> will loop. >[Julien] the router that supports just RPL will keep packets in the same DAG, will not use simblings. Hence >there will be no loop. >> So there must be a minimum support in the base >> spec about instance. That minimum must handle the case where >> a packet comes in with a color as well as the operation for >> processing RPL packets for colored DAG. >> >[Julien] Every DAG is colored as agreed in the meeting. "0", "white", or "default" is a color, with no >different meaning than "1", "blue" as agreed in the meeting. >> If the minimum support is instance zero, >[Julien] we did not say that there was support for only one instance ID, because we did not give a specific >meaning to 0. Hence a RPL only router will know how to forward along the same DAG. >> a node that >> implements only the RPL base MUST ignore RPL PDUs for non >> zero instances. As JP says that's an OCP behavior, and we'll >> have to add an instance filter to OCP0. That also means that >> when processing a packet of any color, this node will forward >> it against the instance 0. To avoid loops, the default node >> must thus zero out the tag. >> >> That makes instance 0 the default topology... QED ;) >[Julien] looks like a loop ;-): 0 is the default, hence RPL only routers do not support something else than 0, >hence every router must support 0. We do not have this issue if we do not define a "default" concept, or at >least if we define a default value, that has no semantic difference with other values. > >I feel we should move forward based on what was agreed, and avoid redicussing points that were agreed on. The >importance of defining in RPL a white DAG that is semanticaly different from the colored ones was not agreed >in the meeting. There was a strong consensus that there will be colors, but each with the same importance (no >special meaning for some values), and that it was admin's responsibility to configure it properly if required. >I think we should stick to this. > >Best, >Julien >> > >> Pascal >> > >> >> >> >>> -----Original Message----- >> >>> From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf >> >>> Of Pascal Thubert (pthubert) >> >>> Sent: jeudi 1 octobre 2009 15:15 >> >>> To: Tim Winter >> >>> Cc: IETF ROLL >> >>> Subject: [Roll] My notes from the meeting >> >>> >> >>> Hi Tim (and all): >> >>> >> >>> Please find my annotated notes on the changes that were >> proposed at >> >>> the interim in ROLLE: >> >>> >> >>> 1) Multi Topology Routing (MTR) is adopted as a base spec >> to handle >> >>> heterogeneous requirements >> >>> A topology is defined by where it goes (destination, >> >>> default) and how to get there (OCP/OF, metrics) >> >>> We need in the intro to say that topologies controlled by >> >>> ship-in-the-night instances of the protocol. >> >>> TopoID=3D=3D instanceID is indicated in all control messages, = and >> >>> encoded in the flow label in all packets >> >>> Requires provisioning when using other than the default >> topology. >> >>> Default topo is topoID 0. In general all nodes are expected to >> >>> participate at least to that one. >> >>> Passed the intro, the text will (mostly) only need to >> explain to >> >>> what happens within one instance. >> >>> Much of that is hopefully very close to the current text :) >> >>> >> >> From pthubert@cisco.com Mon Oct 5 07:32:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6273A69E9 for ; Mon, 5 Oct 2009 07:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.097 X-Spam-Level: X-Spam-Status: No, score=-8.097 tagged_above=-999 required=5 tests=[AWL=-1.498, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDV7n6+aIdkF for ; Mon, 5 Oct 2009 07:32:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 689E53A69E8 for ; Mon, 5 Oct 2009 07:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1902; q=dns/txt; s=sjiport01001; t=1254753226; x=1255962826; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20DAG=20hop=20timers|Date:=20Mon, =205=20Oct=202009=2016:33:27=20+0200|Message-ID:=20<6A2A4 59175DABE4BB11DE2026AA50A5D5A2618@XMB-AMS-107.cisco.com> |To:=20"Mukul=20Goyal"=20|Cc:=20"roll"=20< roll@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20base64|In-Reply-To:=20<5035 15698.14016391254595509004.JavaMail.root@mail02.pantherli nk.uwm.edu>|References:=20<1878566310.1401594125459518083 6.JavaMail.root@mail02.pantherlink.uwm.edu>=20<503515698. 14016391254595509004.JavaMail.root@mail02.pantherlink.uwm .edu>; bh=Ux3e2TPHILe03cGzg8gs+yPrl95uxgNfiAM31gFVVFQ=; b=mKUCv1XgUdqZ4iQMoG1vlaiR28pCqW2BpVU1bSgnqDY24M4gexZr0Ot8 RjOSXEz0AbGNjKmamLCw2pFspgsIP4vTsWCeKDg/tRtbTqIxDZr4sSSuH K/ER5RHxQJUTf6RHSsiIOeUh5BddwZYFKtTueLn4H4QNMbOAZ5D3eyrDE 0=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=pthubert@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAMKgyUqrR7MV/2dsb2JhbACZSaIYiGEBjXkGhCqKIQ X-IronPort-AV: E=Sophos;i="4.44,505,1249257600"; d="scan'208";a="251058530" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 05 Oct 2009 14:33:46 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n95EXkB8010177; Mon, 5 Oct 2009 07:33:46 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n95EXWCs028507; Mon, 5 Oct 2009 14:33:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 16:33:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Oct 2009 16:33:27 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D5A2618@XMB-AMS-107.cisco.com> In-Reply-To: <503515698.14016391254595509004.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAG hop timers Thread-Index: AcpEWbLdrdNL981HRGWnIhJvEr1jSQBbiAIg References: <1878566310.14015941254595180836.JavaMail.root@mail02.pantherlink.uwm.edu> <503515698.14016391254595509004.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 05 Oct 2009 14:33:33.0774 (UTC) FILETIME=[D11F36E0:01CA45C8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1902; t=1254753226; x=1255617226; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20DAG=20hop=20timers |Sender:=20; bh=Ux3e2TPHILe03cGzg8gs+yPrl95uxgNfiAM31gFVVFQ=; b=uIDpIp9Yln3abajFPZl7Y0QFufILd/NLSO54n86pqVzFMmuulujLamTBUQ 0//ABAWZYlCiIRr+4e5rVtBFP3Cn8vqrOxB9V5J1NDjJh4n41CcYzeZx6TOu 2q8GL4QFSNFjJgzsyuP9aFBrxrWipeKn8bn/8TuKrG6IWgI4UoPfs=; Cc: roll Subject: Re: [Roll] DAG hop timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 14:32:12 -0000 SGkgTXVrdWwsDQoNClllcywgdGhhdCBpcyBjb25jZXB0dWFsbHkgaWRlbnRpY2FsLiBUaGVyZSdz IGEgcmVhbCBuZWVkIGZvciBvbmUgdGltZXIgcGVyIERBRyB0aGF0IHRoZSBub2RlIG1pZ2h0IHdh bnQgdG8ganVtcCBvbnRvLiANCg0KV2hlbiBhIHRpbWVyIGVsYXBzZXMsIHRoZSBub2RlIGpvaW5z IHRoZSBiZXN0IHBvc2l0aW9uIHRoYXQgaXQga25vd3Mgb2YgaW4gdGhlIG5ldyBEQUcuIFRoYXQg Y2FuIGJlIGRvbmUgYmVjYXVzZSByZWdhcmRsZXNzIG9mIHRoZSBjYW5kaWRhdGUgcGFyZW50IGZv ciB3aGljaCB0aGUgdGltZXIgZmlyZWQgdGhhdCBqdXN0IGVsYXBzZWQsIHRoZSBub2RlIGlzIG5v dyBhbGxvd2VkIHRvIGpvaW4gdGhhdCBEQUcuIFNpbmNlIG1vdmluZyBpbndhcmRzIGNhbiBiZSBk b25lIHdpdGhvdXQgZGVsYXkgdGhlIG5vZGUgY2FuIHBpY2sgdGhlIGJlc3QgcG9zaXRpb24gaXQg c2VlcyByaWdodCBhd2F5Lg0KDQpQYXNjYWwNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogTXVrdWwgR295YWwgW21haWx0bzptdWt1bEB1d20uZWR1XQ0KPlNlbnQ6IHNhbWVk aSAzIG9jdG9icmUgMjAwOSAyMDo0NQ0KPlRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+ Q2M6IHJvbGwNCj5TdWJqZWN0OiBEQUcgaG9wIHRpbWVycw0KPg0KPkhpIFBhc2NhbA0KPg0KPkN1 cnJlbnQgUlBMIHNwZWNzIHJlcXVpcmUgYSBzZXBhcmF0ZSBEQUcgaG9wIHRpbWVyIGZvciBlYWNo IG5laWdoYm9yIGluIGhlbGRfdXAgc3RhdGUuIEFsbCB0aGVzZSB0aW1lcnMgYXJlDQo+c3RvcHBl ZCBhcyBzb29uIGFzIG9uZSBvZiB0aGUgdGltZXJzIGZpcmVzLiBUaGVyZSBpcyBubyBndWFyYW50 ZWUgdGhhdCB0aGUgdGltZXIgZm9yIHRoZSBuZWlnaGJvciB3aXRoIG1pbmltdW0NCj5yYW5rIHdp bGwgZmlyZSBmaXJzdC4gSWYgdGhlIHRpbWVyIGZvciBzb21lIG90aGVyIG5laWdoYm9yIGZpcmVz IGZpcnN0LCB0aGUgbm9kZSB3aWxsIGhhdmUgdG8gd2FpdCBmb3IgbmV4dCBSQQ0KPmZyb20gbWlu aW11bS1yYW5rIG5laWdoYm9yIHRvIGluY2x1ZGUgaXQgYXMgYSBwYXJlbnQuDQo+DQo+SG93IGFi b3V0IHJ1bm5pbmcganVzdCBvbmUgdGltZXIuIFdoZW4gYSBuZWlnaGJvciB3aXRoIGxvd2VyIHJh bmsgaXMgZGlzY292ZXJlZCwgdGhlIGN1cnJlbnQgdGltZXIgaXMgc3RvcHBlZA0KPmFuZCByZXN0 YXJ0ZWQgd2l0aCBhIGRlbGF5IHByb3BvcnRpb25hbCB0byB0aGlzIGxvd2VyIHJhbmsuIFRoaXMg ZW5zdXJlcyB0aGF0IHRoZSBuZWlnaGJvciB3aXRoIGxvd2VzdCByYW5rDQo+d2lsbCBiZSBjaG9z ZW4gYXMgcGFyZW50LiBBbHNvLCBvbmx5IG9uZSB0aW1lciB3aWxsIGJlIHJlcXVpcmVkLg0KPg0K PlRoYW5rcw0KPk11a3VsDQoNCg== From prvs=522a1fddd=mukul@uwm.edu Mon Oct 5 07:54:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC793A69F2 for ; Mon, 5 Oct 2009 07:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R6VwDdP1E4a for ; Mon, 5 Oct 2009 07:54:57 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 67B763A699C for ; Mon, 5 Oct 2009 07:54:57 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 05 Oct 2009 09:56:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 2B6F8C085CB; Mon, 5 Oct 2009 09:56:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBYmZqomLUF2; Mon, 5 Oct 2009 09:56:32 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 04A80C085A0; Mon, 5 Oct 2009 09:56:32 -0500 (CDT) Date: Mon, 5 Oct 2009 09:56:31 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1497040052.14351291254754591929.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1541019777.14351081254754575635.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] DAG hop timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 05 Oct 2009 14:56:30 -0000 Pascal This sounds good. Cheers Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "roll" Sent: Monday, October 5, 2009 9:33:27 AM GMT -06:00 US/Canada Central Subject: RE: DAG hop timers Hi Mukul, Yes, that is conceptually identical. There's a real need for one timer per DAG that the node might want to jump onto. When a timer elapses, the node joins the best position that it knows of in the new DAG. That can be done because regardless of the candidate parent for which the timer fired that just elapsed, the node is now allowed to join that DAG. Since moving inwards can be done without delay the node can pick the best position it sees right away. Pascal >-----Original Message----- >From: Mukul Goyal [mailto:mukul@uwm.edu] >Sent: samedi 3 octobre 2009 20:45 >To: Pascal Thubert (pthubert) >Cc: roll >Subject: DAG hop timers > >Hi Pascal > >Current RPL specs require a separate DAG hop timer for each neighbor in held_up state. All these timers are >stopped as soon as one of the timers fires. There is no guarantee that the timer for the neighbor with minimum >rank will fire first. If the timer for some other neighbor fires first, the node will have to wait for next RA >from minimum-rank neighbor to include it as a parent. > >How about running just one timer. When a neighbor with lower rank is discovered, the current timer is stopped >and restarted with a delay proportional to this lower rank. This ensures that the neighbor with lowest rank >will be chosen as parent. Also, only one timer will be required. > >Thanks >Mukul From root@core3.amsl.com Mon Oct 5 17:45:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B0D2C3A6916; Mon, 5 Oct 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091006004501.B0D2C3A6916@core3.amsl.com> Date: Mon, 5 Oct 2009 17:45:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 06 Oct 2009 00:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: Routing Protocol for Low Power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-03.txt Pages : 93 Date : 2009-10-05 Low Power and Lossy Networks (LLNs) are made largely of constrained nodes (with limited processing power, memory, and sometimes energy when they are battery operated). These routers are interconnected by lossy links, most of the time supporting only low data rates, that are usually fairly unstable with relatively low packet delivery rates. Another characteristic of such networks is that the traffic patterns are not simply unicast, but in many cases point-to- multipoint or multipoint-to-point. Furthermore such networks may potentially comprise a large number of nodes, up to several dozens or hundreds or more nodes in the network. These characteristics offer unique challenges to a routing solution: the IETF ROLL Working Group has defined application-specific routing requirements for a Low Power and Lossy Network (LLN) routing protocol. This document specifies the Routing Protocol for Low Power and Lossy Networks (RPL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-05174232.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Mon Oct 5 21:54:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F0D3A6A62 for ; Mon, 5 Oct 2009 21:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.765 X-Spam-Level: X-Spam-Status: No, score=-9.765 tagged_above=-999 required=5 tests=[AWL=0.832, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLE3b4i7KL9K for ; Mon, 5 Oct 2009 21:54:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BBDD73A6890 for ; Mon, 5 Oct 2009 21:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=9374; q=dns/txt; s=amsiport01001; t=1254804980; x=1256014580; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20F wd:=20I-D=20Action:draft-ietf-roll-rpl-03.txt=20|Date:=20 Tue,=206=20Oct=202009=2006:56:17=20+0200|Message-Id:=20<7 3D646BC-BB56-4D1A-9E05-C49996CCF804@cisco.com>|To:=20IETF =20ROLL=20|Mime-Version:=201.0=20(Apple=20 Message=20framework=20v936)|References:=20<20091006004501 .B0D2C3A6916@core3.amsl.com>; bh=L2FtuIP9XfHG5N3TtWUKF2O6pz2DInD2mntZQgL3IIo=; b=cDd7fosRJgJ4z/eX5HJS1eNYINyYmwZaRKrZYp4S0dKpSJ96esDVS697 hnS3d87INGogNiYPRvnuJtTRDuA1bb0vD66hKaFxIwjmAQstB3zv60pN9 5xR1eF0QIitERf1XkGSO3ZRKYloR3BQbibYiMKl6Nz+gidPGFuEhUFvWM w=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (partially verified [9341 bytes] [TEST]) header.i=jvasseur@cisco.com X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloAAFVqykqQ/uCLe2dsb2JhbACCJS+YIwIWJAafe4hhAY5zBoQq X-IronPort-AV: E=Sophos;i="4.44,511,1249257600"; d="scan'208,217";a="51025087" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Oct 2009 04:56:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n964uIge032404 for ; Tue, 6 Oct 2009 06:56:18 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n964uIFm016030 for ; Tue, 6 Oct 2009 04:56:18 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 06:56:18 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 06:56:18 +0200 Message-Id: <73D646BC-BB56-4D1A-9E05-C49996CCF804@cisco.com> From: JP Vasseur To: IETF ROLL Content-Type: multipart/alternative; boundary=Apple-Mail-176--527612733 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Oct 2009 06:56:17 +0200 References: <20091006004501.B0D2C3A6916@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 06 Oct 2009 04:56:18.0357 (UTC) FILETIME=[5737BE50:01CA4641] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9341; t=1254804978; x=1255668978; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20I-D=20Action=3Adraft-ietf-roll-rpl-03. txt=20 |Sender:=20; bh=YXUsd/chbtQBTsAlay1oTk2qZbRqwtqpQt/uvyOx2d8=; b=Iu3Ykzq3ddFkekdiWpiXNr72Bq99Pe/+ejT//4X5WHDs697c3h6zCX6/0U W5bd9EMQQ/13Q9oRP9iOcQor49R4duTPlBal3VlADcdob/xFiHVXtLhDV6yd xntsUH7sSW; Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-rpl-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 06 Oct 2009 04:54:45 -0000 --Apple-Mail-176--527612733 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, As planned this version is purely editorial (thanks Tim !). Stay tuned, several questions will be sent out to the list shortly to tackle a series of important design decisions for revision 04. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 6, 2009 2:45:01 AM CEDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-rpl-03.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : RPL: Routing Protocol for Low Power and Lossy > Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-03.txt > Pages : 93 > Date : 2009-10-05 > > Low Power and Lossy Networks (LLNs) are made largely of constrained > nodes (with limited processing power, memory, and sometimes energy > when they are battery operated). These routers are interconnected by > lossy links, most of the time supporting only low data rates, that > are usually fairly unstable with relatively low packet delivery > rates. Another characteristic of such networks is that the traffic > patterns are not simply unicast, but in many cases point-to- > multipoint or multipoint-to-point. Furthermore such networks may > potentially comprise a large number of nodes, up to several dozens or > hundreds or more nodes in the network. These characteristics offer > unique challenges to a routing solution: the IETF ROLL Working Group > has defined application-specific routing requirements for a Low Power > and Lossy Network (LLN) routing protocol. This document specifies > the Routing Protocol for Low Power and Lossy Networks (RPL). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-176--527612733 Content-Type: multipart/mixed; boundary=Apple-Mail-177--527612733 --Apple-Mail-177--527612733 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

As = planned this version is purely editorial (thanks Tim = !).

Stay tuned, several questions will be sent = out to the list shortly to tackle a series of important design decisions = for revision = 04.

Thanks.

JP.
=
Begin forwarded message:

Date: October 6, 2009 2:45:01 AM = CEDT
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-ietf-roll-rpl-03.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : RPL: = Routing Protocol for Low Power and Lossy Networks
Author(s) =       : T. Winter, et al.
Filename =        : = draft-ietf-roll-rpl-03.txt
Pages =           : = 93
= Date =            : = 2009-10-05

Low Power and Lossy Networks (LLNs) are made largely = of constrained
nodes (with limited processing power, memory, and = sometimes energy
when they are battery operated).  These routers = are interconnected by
lossy links, most of the time supporting only = low data rates, that
are usually fairly unstable with relatively low = packet delivery
rates.  Another characteristic of such networks = is that the traffic
patterns are not simply unicast, but in many = cases point-to-
multipoint or multipoint-to-point.  Furthermore = such networks may
potentially comprise a large number of nodes, up to = several dozens or
hundreds or more nodes in the network.  These = characteristics offer
unique challenges to a routing solution: the = IETF ROLL Working Group
has defined application-specific routing = requirements for a Low Power
and Lossy Network (LLN) routing = protocol.  This document specifies
the Routing Protocol for Low = Power and Lossy Networks (RPL).

A URL for this Internet-Draft = is:
ht= tp://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-03.txt

In= ternet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-177--527612733 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-10-05174232.I-D@ietf.org>

--Apple-Mail-177--527612733 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-177--527612733-- --Apple-Mail-176--527612733-- From jvasseur@cisco.com Wed Oct 7 11:06:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A538E28C186 for ; Wed, 7 Oct 2009 11:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5lGQxOHOySf for ; Wed, 7 Oct 2009 11:06:23 -0700 (PDT) Received: from syd-iport-2.cisco.com (syd-iport-2.cisco.com [64.104.193.197]) by core3.amsl.com (Postfix) with ESMTP id 0A0F43A6821 for ; Wed, 7 Oct 2009 11:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=5846; q=dns/txt; s=sydiport02001; t=1254938884; x=1256148484; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R PL=20Metric=20ID|Date:=20Wed,=207=20Oct=202009=2020:07:52 =20+0200|Message-Id:=20|To:=20IETF=20ROLL=20|Cc:=20 "???[??????]"=20,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Messag e=20framework=20v936); bh=t3VCBPb3m0epQpscQnzLUa9LvcBQpQwy0VcPzlEK+1Y=; b=MY02UggvuRLuZLZ5mTqX0/o6xwoR4R2et2qqnHRoVsdQmz6p9d1sn2lw vAleI8nH3n0swARZ71xeUCI14HT17frzfDcDLX/+QTKXR4UvoW2qprftD n8No/D5TQx+iv1CqTg77aO8Kbye79bks4jTEI2JYcxSL+QFbp4zmKG0aE I=; Authentication-Results: syd-iport-2.cisco.com; dkim=pass (partially verified [5813 bytes] [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFABt2zEoKS+eh/2dsb2JhbACCJTC7dYhjAY9ABoImggQ X-IronPort-AV: E=Sophos;i="4.44,520,1249257600"; d="scan'208,217";a="58881593" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-2.cisco.com with ESMTP; 07 Oct 2009 18:07:57 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n97I7u0X018189; Thu, 8 Oct 2009 02:07:56 +0800 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n97I7tL5003386; Wed, 7 Oct 2009 18:07:56 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 23:37:55 +0530 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Oct 2009 23:37:54 +0530 Message-Id: From: JP Vasseur To: IETF ROLL Content-Type: multipart/alternative; boundary=Apple-Mail-278--393717938 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 7 Oct 2009 20:07:52 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 07 Oct 2009 18:07:54.0663 (UTC) FILETIME=[17A2A370:01CA4779] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5813; t=1254938876; x=1255802876; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20RPL=20Metric=20ID |Sender:=20; bh=WKd3Sx/ntGCFOYSkK505CTb4lWRWLZfjS5w/4eTZrdg=; b=KcMZC2lVfBkSUxSRpcbGb1HYDAhpc+3LzEw56RB8iat3KpH5PWeghgoXBk UsIhgINH0VKAldgr4xwO51tHM8Jrv540qfLiL69XJfcxsdmNt3mb7BCsmE8/ yGtZgmNxSz9PHNMVQyRnU84Gtj8NVnQS3iYy7jiIE/dISCV9Fh6so=; Cc: Kris Pister Subject: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2009 18:06:24 -0000 --Apple-Mail-278--393717938 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, We would appreciate your feed-back on RPL routing metrics. Now that RPL is stabilizing it is time to move forward with the METRIC I-D. The next revision will be a major one, with packet encoding, processing rules, etc. We discussed and agreed some time ago on several links and nodes metrics (also required according to our requirement IDs). Still, there are a few metrics for which we would like to know whether you think that they should be specified. 4.2. Latency As with throughput, the latency of many LLN MAC sub-layers can be varied over many orders of magnitude, again with a corresponding change in current consumption. Some LLN MACs will allow the latency to be adjusted globally on the subnet, or on a link-by-link basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link. For efficient operation, nodes must be able to report the range of latency that their links can handle, and the currently available latency. 4.3. Link reliability In LLNs, link reliability is degraded by external interference and multi-path interference. Multipath typically affects both directions on the link equally, whereas external interference is sometimes uni- directional. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rate can generally be measured directly, and other metrics (e.g. bit error rate, mean time between failures) are typically derived from that. In addition: Node Memory resources: Memory is a critical node resources in presence of constrained nodes. Is there a need to report node memory resources as a routing metric/ constraint ? Node CPU resources: CPU duty cycle for virtually all LLN applications to date is well below 10%, and the trend in low power embedded systems is to more capable processors rather than less. Computational speed is not expected to be a limiting factor in routing in LLNs. Is there a need to report node CPU resources as a routing metric/constraint ? Link Security metrics Thanks for your feed-back. JP, Mijeon, Kris. --Apple-Mail-278--393717938 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

We = would appreciate your feed-back on RPL routing = metrics.

Now that RPL is stabilizing it is time = to move forward with the METRIC I-D. The next revision will be a major = one, with packet encoding, processing rules, = etc.

We discussed and agreed some time ago on = several links and nodes metrics (also required according to our = requirement IDs).

Still, there are a few = metrics for which we would like to know whether you think that they = should be specified.

4.2. =  Latency

   = As with throughput, the latency of many LLN MAC sub-layers can = be
   varied over many orders of magnitude, = again with a corresponding
   change in = current consumption.  Some LLN MACs will allow the = latency
   to be adjusted globally on the = subnet, or on a link-by-link basis, or
   not = at all.  Some will insist that it be fixed for a given link, = but
   allow it to be variable from link to = link.  For efficient operation,
   nodes = must be able to report the range of latency that their = links
   can handle, and the currently = available latency.

4.3. =  Link = reliability

   In LLNs, = link reliability is degraded by external interference = and
   multi-path interference. =  Multipath typically affects both = directions
   on the link equally, whereas = external interference is sometimes uni-
   = directional.  Time scales vary from milliseconds to days, and = are
   often periodic and linked to human = activity.  Packet error rate can
   = generally be measured directly, and other metrics (e.g. bit = error
   rate, mean time between failures) = are typically derived from that.

In = addition:

Node Memory = resources:

Memory is a critical node = resources in presence of constrained nodes. Is there a need to report = node memory resources as a routing metric/constraint = ?

Node CPU resources:
CPU duty = cycle for virtually all LLN applications to date is well below 10%, and = the trend in low power embedded systems is to more capable processors = rather than less. Computational speed is not expected to be a limiting = factor in routing in LLNs. Is there a need to report node CPU resources = as a routing metric/constraint ?

Link = Security metrics

Thanks for your = feed-back.

JP, Mijeon, = Kris.
= --Apple-Mail-278--393717938-- From mcr@marajade.sandelman.ca Wed Oct 7 12:29:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7A43A6A04 for ; Wed, 7 Oct 2009 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_20=-0.74, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSS9mqeg+xIx for ; Wed, 7 Oct 2009 12:29:14 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 441EA3A6939 for ; Wed, 7 Oct 2009 12:28:51 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.236.169]) by relay.sandelman.ca (Postfix) with ESMTPS id 0415C3428A for ; Wed, 7 Oct 2009 19:34:36 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 27F0A4E7F7 for ; Wed, 7 Oct 2009 15:30:31 -0400 (EDT) From: Michael Richardson To: IETF ROLL In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 07 Oct 2009 15:30:31 -0400 Message-ID: <762.1254943831@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2009 19:29:15 -0000 >>>>> "JP" == JP Vasseur writes: JP> We discussed and agreed some time ago on several links and nodes JP> metrics (also required according to our requirement IDs). JP> Still, there are a few metrics for which we would like to know JP> whether you think that they should be specified. If I understand your question, you are asking if the protocol should carry these fields in the DIOs, and transmitted through the DAG? Or are you asking if these things should be configured into the node (somehow? operator?) and taken into account. Or are you asking if RPL has to somehow measure these things for each on-link peer ("cousin"?), such that it can be taken into account? JP> Node CPU resources: CPU duty cycle for virtually all LLN JP> applications to date is well below 10%, and the trend in low JP> power embedded systems is to more capable processors rather than JP> less. Computational speed is not expected to be a limiting JP> factor in routing in LLNs. Is there a need to report node CPU JP> resources as a routing metric/constraint ? I.e. it's better to be a sleepy hare, than a slow-plodding-tortoise. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From prvs=5248a3d4b=mukul@uwm.edu Wed Oct 7 12:39:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1185B3A6A9C for ; Wed, 7 Oct 2009 12:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxyOUccifNoi for ; Wed, 7 Oct 2009 12:39:16 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 381603A6A84 for ; Wed, 7 Oct 2009 12:39:05 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 07 Oct 2009 14:40:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 35515C085D3; Wed, 7 Oct 2009 14:40:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TBYqUex0o-j; Wed, 7 Oct 2009 14:40:44 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C2BCCC085D1; Wed, 7 Oct 2009 14:40:44 -0500 (CDT) Date: Wed, 7 Oct 2009 14:40:44 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2009 19:39:47 -0000 I think both latency and reliability are important metrics.=20 I am sort of negative on using memory/CPU availability as metric or constra= int. They seem like local factors to me. If a node is running low on memory= /CPU, it can simply not participate in routing. Thanks Mukul =20 ----- Original Message ----- From: "JP Vasseur" To: "IETF ROLL" Cc: "Kris Pister" Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada Central Subject: [Roll] RPL Metric ID Dear all,=20 We would appreciate your feed-back on RPL routing metrics.=20 Now that RPL is stabilizing it is time to move forward with the METRIC I-D.= The next revision will be a major one, with packet encoding, processing ru= les, etc.=20 We discussed and agreed some time ago on several links and nodes metrics (a= lso required according to our requirement IDs).=20 Still, there are a few metrics for which we would like to know whether you = think that they should be specified.=20 4.2. =C2=A0Latency=20 =C2=A0=C2=A0 As with throughput, the latency of many LLN MAC sub-layers can= be=20 =C2=A0=C2=A0 varied over many orders of magnitude, again with a correspondi= ng=20 =C2=A0=C2=A0 change in current consumption. =C2=A0Some LLN MACs will allow = the latency=20 =C2=A0=C2=A0 to be adjusted globally on the subnet, or on a link-by-link ba= sis, or=20 =C2=A0=C2=A0 not at all. =C2=A0Some will insist that it be fixed for a give= n link, but=20 =C2=A0=C2=A0 allow it to be variable from link to link. =C2=A0For efficient= operation,=20 =C2=A0=C2=A0 nodes must be able to report the range of latency that their l= inks=20 =C2=A0=C2=A0 can handle, and the currently available latency.=20 4.3. =C2=A0Link reliability=20 =C2=A0=C2=A0 In LLNs, link reliability is degraded by external interference= and=20 =C2=A0=C2=A0 multi-path interference. =C2=A0Multipath typically affects bot= h directions=20 =C2=A0=C2=A0 on the link equally, whereas external interference is sometime= s uni-=20 =C2=A0=C2=A0 directional. =C2=A0Time scales vary from milliseconds to days,= and are=20 =C2=A0=C2=A0 often periodic and linked to human activity. =C2=A0Packet erro= r rate can=20 =C2=A0=C2=A0 generally be measured directly, and other metrics (e.g. bit er= ror=20 =C2=A0=C2=A0 rate, mean time between failures) are typically derived from t= hat.=20 In addition:=20 Node Memory resources:=20 Memory is a critical node resources in presence of constrained nodes. Is th= ere a need to report node memory resources as a routing metric/constraint ?= =20 Node CPU resources:=20 CPU duty cycle for virtually all LLN applications to date is well below 10%= , and the trend in low power embedded systems is to more capable processors= rather than less. Computational speed is not expected to be a limiting fac= tor in routing in LLNs. Is there a need to report node CPU resources as a r= outing metric/constraint ?=20 Link Security metrics=20 Thanks for your feed-back.=20 JP, Mijeon, Kris.=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Wed Oct 7 12:49:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE3C28C1D7; Wed, 7 Oct 2009 12:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zH6gpOTrEZq; Wed, 7 Oct 2009 12:49:49 -0700 (PDT) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by core3.amsl.com (Postfix) with ESMTP id CFD8C28C1E3; Wed, 7 Oct 2009 12:49:48 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKSszxQIJ36WvCTM4fz8xHIe96Ux00XRQt@postini.com; Wed, 07 Oct 2009 12:51:30 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009100714520558-1378734 ; Wed, 7 Oct 2009 14:52:05 -0500 In-Reply-To: MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 7 Oct 2009 14:51:08 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 10/07/2009 02:51:13 PM, Serialize complete at 10/07/2009 02:51:13 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/07/2009 02:52:05 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/07/2009 02:52:20 PM, Serialize complete at 10/07/2009 02:52:20 PM Content-Type: multipart/related; boundary="=_related 006D0D5286257648_=" Cc: IETF ROLL , roll-bounces@ietf.org, Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2009 19:49:50 -0000 This is a multipart message in MIME format. --=_related 006D0D5286257648_= Content-Type: multipart/alternative; boundary="=_alternative 006D0D5286257648_=" --=_alternative 006D0D5286257648_= Content-Type: text/plain; charset="US-ASCII" JP, I am not sure what you're asking, but I 'll hazard a guess. Let me know if my comments make sense. I believe you are saying that the Metrics ID specifies some minimization strategies and are asking if we should add additional strategies for 1) latency and 2) link reliability. As for latency, I am presuming this would be analogous to a QoS strategy. That is move packets from point 'a' to point 'b' in the minimal amount of time. The Building Requirements called out a QoS requirement to assure high priority packets (e.g. Fire Alarms) could traverse the LLN faster than other messages. As for Link Reliability, I also vote 'yes'. I am presume that Link Reliability is akin to ETX. That is moving packets from point 'a' to point 'b' with the best possible change of success of arrival with no errors. So I think I have answered your questions. If not, please let me know. Jerry JP Vasseur Sent by: roll-bounces@ietf.org 10/07/2009 01:08 PM To IETF ROLL cc Kris Pister Subject [Roll] RPL Metric ID Dear all, We would appreciate your feed-back on RPL routing metrics. Now that RPL is stabilizing it is time to move forward with the METRIC I-D. The next revision will be a major one, with packet encoding, processing rules, etc. We discussed and agreed some time ago on several links and nodes metrics (also required according to our requirement IDs). Still, there are a few metrics for which we would like to know whether you think that they should be specified. 4.2. Latency As with throughput, the latency of many LLN MAC sub-layers can be varied over many orders of magnitude, again with a corresponding change in current consumption. Some LLN MACs will allow the latency to be adjusted globally on the subnet, or on a link-by-link basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link. For efficient operation, nodes must be able to report the range of latency that their links can handle, and the currently available latency. 4.3. Link reliability In LLNs, link reliability is degraded by external interference and multi-path interference. Multipath typically affects both directions on the link equally, whereas external interference is sometimes uni- directional. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rate can generally be measured directly, and other metrics (e.g. bit error rate, mean time between failures) are typically derived from that. In addition: Node Memory resources: Memory is a critical node resources in presence of constrained nodes. Is there a need to report node memory resources as a routing metric/constraint ? Node CPU resources: CPU duty cycle for virtually all LLN applications to date is well below 10%, and the trend in low power embedded systems is to more capable processors rather than less. Computational speed is not expected to be a limiting factor in routing in LLNs. Is there a need to report node CPU resources as a routing metric/constraint ? Link Security metrics Thanks for your feed-back. JP, Mijeon, Kris._______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006D0D5286257648_= Content-Type: text/html; charset="US-ASCII"
JP,

I am not sure what you're asking, but I 'll hazard a guess.  Let me know if my comments make sense.

I believe you are saying that the Metrics ID specifies some minimization strategies and are asking if we should add additional strategies for 1) latency and 2) link reliability.

As for latency, I am presuming this would be analogous to a QoS strategy.  That is move packets from point 'a'  to point 'b' in the minimal amount of time.  The Building Requirements called out a QoS requirement to assure high priority packets (e.g. Fire Alarms) could traverse the LLN faster than other messages.

As for Link Reliability, I also vote 'yes'.  I am presume that Link Reliability is akin to ETX.  That is moving packets from point 'a' to point 'b' with the best possible change of success of arrival with no errors.

So I think I have answered your questions.  If not, please let me know.

Jerry






JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

10/07/2009 01:08 PM

To
IETF ROLL <roll@ietf.org>
cc
Kris Pister <kpister@dustnetworks.com>
Subject
[Roll] RPL Metric ID





Dear all,

We would appreciate your feed-back on RPL routing metrics.

Now that RPL is stabilizing it is time to move forward with the METRIC I-D. The next revision will be a major one, with packet encoding, processing rules, etc.

We discussed and agreed some time ago on several links and nodes metrics (also required according to our requirement IDs).

Still, there are a few metrics for which we would like to know whether you think that they should be specified.

4.2.  Latency

   As with throughput, the latency of many LLN MAC sub-layers can be
   varied over many orders of magnitude, again with a corresponding
   change in current consumption.  Some LLN MACs will allow the latency
   to be adjusted globally on the subnet, or on a link-by-link basis, or
   not at all.  Some will insist that it be fixed for a given link, but
   allow it to be variable from link to link.  For efficient operation,
   nodes must be able to report the range of latency that their links
   can handle, and the currently available latency.

4.3.  Link reliability

   In LLNs, link reliability is degraded by external interference and
   multi-path interference.  Multipath typically affects both directions
   on the link equally, whereas external interference is sometimes uni-
   directional.  Time scales vary from milliseconds to days, and are
   often periodic and linked to human activity.  Packet error rate can
   generally be measured directly, and other metrics (e.g. bit error
   rate, mean time between failures) are typically derived from that.

In addition:

Node Memory resources:

Memory is a critical node resources in presence of constrained nodes. Is there a need to report node memory resources as a routing metric/constraint ?

Node CPU resources:
CPU duty cycle for virtually all LLN applications to date is well below 10%, and the trend in low power embedded systems is to more capable processors rather than less. Computational speed is not expected to be a limiting factor in routing in LLNs. Is there a need to report node CPU resources as a routing metric/constraint ?

Link Security metrics

Thanks for your feed-back.

JP, Mijeon, Kris._______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006D0D5286257648_=-- --=_related 006D0D5286257648_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0BD003B00BCFFE34006D0D5286257648> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 006D0D5286257648_=-- From prvs=5248a3d4b=mukul@uwm.edu Wed Oct 7 13:24:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59EA3A6845 for ; Wed, 7 Oct 2009 13:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHsIwOxO+YXP for ; Wed, 7 Oct 2009 13:24:14 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id B6D6D28C1E9 for ; Wed, 7 Oct 2009 13:24:06 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 07 Oct 2009 15:25:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id CD811C085CB; Wed, 7 Oct 2009 15:25:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BARlrZ9Vo54p; Wed, 7 Oct 2009 15:25:46 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 666BAC085A0; Wed, 7 Oct 2009 15:25:46 -0500 (CDT) Date: Wed, 7 Oct 2009 15:25:46 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <242971368.15581641254947146329.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D5A21E7@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] one DAG per RPL instance X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 07 Oct 2009 20:24:15 -0000 Pascal, Quoting from your post: "(RPL) Instances are contexts that run the same code and operate as ship in the night." Could you please explain what do you mean by "ship in the night". I have never heard this phrase before. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" , "Mukul Goyal" Cc: "roll" Sent: Monday, October 5, 2009 12:51:10 AM GMT -06:00 US/Canada Central Subject: RE: [Roll] one DAG per RPL instance > >On Oct 3, 2009, at 11:05 PM, Mukul Goyal wrote: > >> Hi all, >> >> I was wondering if people with experience in writing code for memory/ >> CPU constrained devices can comment on this: If a device has to join >> multiple DAGs, does it make a difference (from the perspective of >> memory requirement and execution efficiency) whether the device runs >> a single RPL process (supporting all the DAGs) or multiple RPL >> processes (each supporting just one DAG). >> > >It does make a difference but if coded right, a very minor difference. Agreed. Instances are contexts that run the same code and operate as ship in the night. The additional work will have to do with instance transition policies, but policies are already present in the OCP for a single instance. The price to pay will probably be more in terms of: - battery. It appears that the control cost (memory, protocol exchanges) is multiplied by the number of instances. - admin. As soon as you have multiple instances, you have to distribute your instance IDs, policies, etc... As opposed to implementation complexity. Note: We've had a lot of confusion mentioning multiple DAGs. There can be multiple DAGs within an instance (mutually exclusive) or serving different instances. It appears that your question is really about serving multiple instances and it will certainly help if we adopt a common language for the concept. Cheers, Pascal > >JP. > > >> Thanks >> Mukul >> >> _______________________________________________ >> 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 wintert@acm.org Wed Oct 7 15:42:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F9553A67ED for ; Wed, 7 Oct 2009 15:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.833 X-Spam-Level: X-Spam-Status: No, score=-97.833 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nszuiCghSR4P for ; Wed, 7 Oct 2009 15:42:19 -0700 (PDT) Received: from web57602.mail.re1.yahoo.com (web57602.mail.re1.yahoo.com [66.196.100.84]) by core3.amsl.com (Postfix) with SMTP id 483883A686B for ; Wed, 7 Oct 2009 15:42:19 -0700 (PDT) Received: (qmail 34951 invoked by uid 60001); 7 Oct 2009 22:43:56 -0000 Message-ID: <490465.34054.qm@web57602.mail.re1.yahoo.com> X-YMail-OSG: etGQOMIVM1nQ0gh5pQ_WJH32Ragnv7mHoRv4q4HUG8yGq9Eg1gdwGTuoUcqFrRVkgcvysYPePFss8YoGR9eFrwjvkzJVoGoOLxx_xSzwSGmlPqtLrrSmwulatSXpdg5bvyv87U0fWjzXpa5S9NQL3rIyDGSh9kFdX78yoDJw4Mxhez2c6qZrm.KYenijddKabzINJfo91EmKaVTQixaEY1PCT2X4ION6MvqU3PTJc3VCnJsIlAmPzO6_QCGz50I.adSAMbAYekEGtoub0DiZ2qiCelXMRnofDMGgBc9REASXynJ4tBEk3SnCXRHbd3DFmDCCM7ixIpRn6txH66QG0aEqdnUSkHdAzr8f3xFOPlvfEAvjdJHHCbHkLQc- Received: from [206.83.249.194] by web57602.mail.re1.yahoo.com via HTTP; Wed, 07 Oct 2009 15:43:56 PDT X-RocketYMMF: zekemullet X-Mailer: YahooMailClassic/7.0.14 YahooMailWebService/0.7.347.3 Date: Wed, 7 Oct 2009 15:43:56 -0700 (PDT) From: Tim Winter To: roll@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: wintert@acm.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:42:20 -0000 WG, As discussed at the interim meeting, implementer feedback has indicated that the RPL protocol as proposed appears complex, both in description and actual FSM. Our plan of action is to, by end of month, deliver a -04 that will contain actual (non-editorial) changes. The intent of this mail is a poll over a period of 2 weeks, to help design the functional changes. In this spirit, we would like the WG to work on the following questions: Question A: Should RPL make use of the currently proposed local repair mechanism (DAG splitting and merging)? [NO implies that DAG repairs shall be coordinated globally with the use of DAG Sequence Number; the related mechanisms are to be expanded for -04] Question B: Should RPL make use of a hold-up timer and related states/procedures to reduce churn by coordinating the DAG merge? [NO implies RPL allows nodes to move (jump) between DAGs with little coordination to reduce complexity of specification/ implementation (perhaps w/ Optional hold-up mechanism)]. Question C: Should RPL make use of a hold-down timer and related states/procedures to limit flapping when removing DAG Parents / leaving DAGs [NO implies RPL allows nodes to freely remove/add DAG Parents as and when they are able in order to reduce complexity of specification/implementation (perhaps w/ Optional hold-down mechanism). WG, we expect that this thread will contain a lot of interesting related discussion, but in your comments please do also be sure to try and address the initial questions A, B, and C so as to help us better capture the WG position on these issues. Please note that A, B, and C are to some degree orthogonal, e.g. `No Local Repair' to Question A does not necessarily imply a particular disposition toward the Hold-Up mechanism in Question B. Thanks, RPL Authors Some examples, derived from the present draft, are provided below: ------------------------------------------------------------------------ Example: Local Repair with Hold-Up state : : : : : : (A) (A) (A) |\ | | | `-----. | | | \ | | (B) (C) (B) (C) (B) | | \ | | `-----. | | \ (D) (D) (C) | | | (D) -1- -2- -3- Figure 1: DAG Maintenance Consider the example depicted in Figure 1-1. In this example, Node (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is also an undirected sibling link between Nodes (B) and (C). In this example, Node (C) may safely forward to Node (A) without creating a loop. Node (C) may not safely forward to Node (D), contained within it's own sub-DAG, without creating a loop. Node (C) may forward to Node (B) in some cases, e.g. the link (C)->(A) is temporarily unavailable, but with some chance of creating a loop (e.g. if multiple nodes in a set of siblings start forwarding `sideways' in a cycle) and requiring the intervention of additional mechanisms to detect and break the loop. Consider the case where Node (C) hears a RA-DIO message from a Node (Z) at a lesser rank and superior position in the DAG than node (A). Node (C) may safely undergo the process to evict node (A) from its DAG parent set and attach directly to Node (Z) without creating a loop, because its rank will decrease. Now consider the case where the link (C)->(A) becomes nonviable, and node (C) must move to a deeper rank within the DAG: o Node (C) must first detach from the DAG by removing Node (A) from its DAG parent set, leaving an empty DAG parent set. Node (C) becomes the root of its own floating, less preferred, DAG. o Node (D), hearing a modified RA-DIO message from Node (C), follows Node (C) into the floating DAG. This is depicted in Figure 1-2. In general, any node with no other options in the sub-DAG of Node (C) will follow Node (C) into the floating DAG, maintaining the structure of the sub-DAG. o Node (C) hears a RA-DIO message from Node (B) and determines it is able to rejoin the grounded DAG by reattaching at a deeper rank to Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in the Hold-Up state) to coordinate this move. o The timer expires and Node (C) adds Node (B) to its DAG parent set. Node (C) has now safely moved deeper within the grounded DAG without creating any loops. Node (D), and any other sub-DAG of Node (C), will hear the modified RA-DIO message sourced from Node (C) and follow Node (C) in a coordinated manner to reattach to the grounded DAG. The final DAG is depicted in Figure 1-3 ------------------------------------------------------------------------ Example: Global Repair with Sequence Number / No Held-Up State : : : : : : (A) (A) (A) |\ | | | `-----. | | | \ | | (B) (C) (B) (C) (B) | \ | `-----. | \ (D) (D) (C) (D) -1- -2- -3- Figure 2: DAG Maintenance Consider the example depicted in Figure 2-1, similar to that depicted in Figure 1. Let there be a sequence number associated with the DAG, as originated from the DAG root, with value N. Initially all nodes have received DAG Sequence Number N. The following example offers one possible Global Repair scenario to give a high level idea, please note that there are details that would remain to be worked out if the WG heads in this direction. Now consider the case where the link (C)->(A) becomes nonviable, and node (C) must move to a deeper rank within the DAG: o Node (C) must first detach from the DAG by removing Node (A) from its DAG parent set, leaving an empty DAG parent set. At this point Node (C) is not associated with any DAG [TBD -- Alternately Node (C) remains associated with the DAG at rank infinity]. o Node (D) may possibly learn that Node (C) is no longer associated with any DAG and itself becomes unassociated [TBD Node (D) may also retain a sub-DAG relationship with Node (C)]. Let Node (C) and (D) both be free from any DAG, but remember the Sequence Number N associated with their original DAG. This is depicted in Figure 2-2. o Node (C) and (D) will now be willing to reattach to the original DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering connectivity to the original DAG and advertising a sequence number N+1. Since Node (C) and (D) are no longer members of the original DAG, only a node who is still a member of the original DAG may possibly present the sequence number N+1. Such a node who presents N+1 must clearly have another path to the DAG root other than via (C) and (D) and thus may offer a loop-avoiding attachment point. o [TBD] The DAG Root may periodically issue sequence number increments, causing the issue of N+1 o [TBD] The broken link (C)->(A) may be detected through some other means, and signalled to or cause a trigger at the DAG Root, causing the issue of N+1 o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and determine it is able to rejoin the original DAG by immediately reattaching j to Node (B) (No hold-up state in this example. The DAG is now as depicted in Figure 2-3 o Node (C) may then subsequently send RA-DIO with DAG Sequence number N+1, allowing Node (D) to reattach (not depicted). ------------------------------------------------------------------------ From prvs=525560042=mukul@uwm.edu Wed Oct 7 19:14:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E3C3A6898 for ; Wed, 7 Oct 2009 19:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo5eiZvy0kZr for ; Wed, 7 Oct 2009 19:14:29 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id D8CA73A6828 for ; Wed, 7 Oct 2009 19:14:28 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 07 Oct 2009 21:16:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 78F71C085D8; Wed, 7 Oct 2009 21:16:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgwikQRRhIU3; Wed, 7 Oct 2009 21:16:09 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1652DC085D0; Wed, 7 Oct 2009 21:16:09 -0500 (CDT) Date: Wed, 7 Oct 2009 21:16:08 -0500 (CDT) From: Mukul Goyal To: wintert@acm.org Message-ID: <2075692059.15703491254968168922.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1297722337.15692691254965832688.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 02:15:02 -0000 I would like to make the following comments: 1) Dag hop timer is just a way to avoid reducing the rank frequently. Frequent reduction of rank is bad if it means frequent generation of RA-DIO. It is not a loop avoidance mechanism. 2) Now, dag hop time can be used as a loop "avoidance" mechanism if it is used as a wait time that is long enough to allow hopefully all the nodes in my sub-dag to leave my sub-dag knowing that I am leaving the DAG. So at the end of the wait time, if a neighbor still claims to be on the DAG, it is "hopefully" (but not "certainly") not in my sub-dag. So, the correct way to use dag hop time would be: a) wait for the dag hop time and ignore the RA-DIOs from the neighbors during this time; b) when wait time is over, I can choose any neighbor that still is in the DAG as my parent Whether the dag hop timer is used as current RPL specs say or in the manner described above, their use should be optional. 3) increasing the rank only on receiving a new seq_no from root prevents loops. Now, the problem is that a node may have to wait for an nondeterministic long time before receiving a new seq_no and increasing its rank. I think this problem is best left unsolved in the base specs. Here are some possible solutions though: a) One solution would be to propagate info about any link_loss event in the DAG back to the root so that it can increment the seq_no. This solution fails the scalability test. As the DAG size increases, too many control packets would be generated to let the root know about the link_loss events and subsequent generation of new RA-DIOs by all the nodes in the DAG. It may be failing one of the criteria mentioned in the survey ID since a local event needs to be flooded globally (to the roots of all the DAGs that may be affected). b) Another simple solution would be to require (fixed) periodic update of seq_no by the DAG root. This solution gives a better upper bound on the delay in increasing the rank but may also result in generation of too many RA-DIOs (or even RA-DIO storms). Thanks Mukul ----- Original Message ----- From: "Tim Winter" To: roll@ietf.org Sent: Wednesday, October 7, 2009 5:43:56 PM GMT -06:00 US/Canada Central Subject: [Roll] RPL Design Questions WG, As discussed at the interim meeting, implementer feedback has indicated that the RPL protocol as proposed appears complex, both in description and actual FSM. Our plan of action is to, by end of month, deliver a -04 that will contain actual (non-editorial) changes. The intent of this mail is a poll over a period of 2 weeks, to help design the functional changes. In this spirit, we would like the WG to work on the following questions: Question A: Should RPL make use of the currently proposed local repair mechanism (DAG splitting and merging)? [NO implies that DAG repairs shall be coordinated globally with the use of DAG Sequence Number; the related mechanisms are to be expanded for -04] Question B: Should RPL make use of a hold-up timer and related states/procedures to reduce churn by coordinating the DAG merge? [NO implies RPL allows nodes to move (jump) between DAGs with little coordination to reduce complexity of specification/ implementation (perhaps w/ Optional hold-up mechanism)]. Question C: Should RPL make use of a hold-down timer and related states/procedures to limit flapping when removing DAG Parents / leaving DAGs [NO implies RPL allows nodes to freely remove/add DAG Parents as and when they are able in order to reduce complexity of specification/implementation (perhaps w/ Optional hold-down mechanism). WG, we expect that this thread will contain a lot of interesting related discussion, but in your comments please do also be sure to try and address the initial questions A, B, and C so as to help us better capture the WG position on these issues. Please note that A, B, and C are to some degree orthogonal, e.g. `No Local Repair' to Question A does not necessarily imply a particular disposition toward the Hold-Up mechanism in Question B. Thanks, RPL Authors Some examples, derived from the present draft, are provided below: ------------------------------------------------------------------------ Example: Local Repair with Hold-Up state : : : : : : (A) (A) (A) |\ | | | `-----. | | | \ | | (B) (C) (B) (C) (B) | | \ | | `-----. | | \ (D) (D) (C) | | | (D) -1- -2- -3- Figure 1: DAG Maintenance Consider the example depicted in Figure 1-1. In this example, Node (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is also an undirected sibling link between Nodes (B) and (C). In this example, Node (C) may safely forward to Node (A) without creating a loop. Node (C) may not safely forward to Node (D), contained within it's own sub-DAG, without creating a loop. Node (C) may forward to Node (B) in some cases, e.g. the link (C)->(A) is temporarily unavailable, but with some chance of creating a loop (e.g. if multiple nodes in a set of siblings start forwarding `sideways' in a cycle) and requiring the intervention of additional mechanisms to detect and break the loop. Consider the case where Node (C) hears a RA-DIO message from a Node (Z) at a lesser rank and superior position in the DAG than node (A). Node (C) may safely undergo the process to evict node (A) from its DAG parent set and attach directly to Node (Z) without creating a loop, because its rank will decrease. Now consider the case where the link (C)->(A) becomes nonviable, and node (C) must move to a deeper rank within the DAG: o Node (C) must first detach from the DAG by removing Node (A) from its DAG parent set, leaving an empty DAG parent set. Node (C) becomes the root of its own floating, less preferred, DAG. o Node (D), hearing a modified RA-DIO message from Node (C), follows Node (C) into the floating DAG. This is depicted in Figure 1-2. In general, any node with no other options in the sub-DAG of Node (C) will follow Node (C) into the floating DAG, maintaining the structure of the sub-DAG. o Node (C) hears a RA-DIO message from Node (B) and determines it is able to rejoin the grounded DAG by reattaching at a deeper rank to Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in the Hold-Up state) to coordinate this move. o The timer expires and Node (C) adds Node (B) to its DAG parent set. Node (C) has now safely moved deeper within the grounded DAG without creating any loops. Node (D), and any other sub-DAG of Node (C), will hear the modified RA-DIO message sourced from Node (C) and follow Node (C) in a coordinated manner to reattach to the grounded DAG. The final DAG is depicted in Figure 1-3 ------------------------------------------------------------------------ Example: Global Repair with Sequence Number / No Held-Up State : : : : : : (A) (A) (A) |\ | | | `-----. | | | \ | | (B) (C) (B) (C) (B) | \ | `-----. | \ (D) (D) (C) (D) -1- -2- -3- Figure 2: DAG Maintenance Consider the example depicted in Figure 2-1, similar to that depicted in Figure 1. Let there be a sequence number associated with the DAG, as originated from the DAG root, with value N. Initially all nodes have received DAG Sequence Number N. The following example offers one possible Global Repair scenario to give a high level idea, please note that there are details that would remain to be worked out if the WG heads in this direction. Now consider the case where the link (C)->(A) becomes nonviable, and node (C) must move to a deeper rank within the DAG: o Node (C) must first detach from the DAG by removing Node (A) from its DAG parent set, leaving an empty DAG parent set. At this point Node (C) is not associated with any DAG [TBD -- Alternately Node (C) remains associated with the DAG at rank infinity]. o Node (D) may possibly learn that Node (C) is no longer associated with any DAG and itself becomes unassociated [TBD Node (D) may also retain a sub-DAG relationship with Node (C)]. Let Node (C) and (D) both be free from any DAG, but remember the Sequence Number N associated with their original DAG. This is depicted in Figure 2-2. o Node (C) and (D) will now be willing to reattach to the original DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering connectivity to the original DAG and advertising a sequence number N+1. Since Node (C) and (D) are no longer members of the original DAG, only a node who is still a member of the original DAG may possibly present the sequence number N+1. Such a node who presents N+1 must clearly have another path to the DAG root other than via (C) and (D) and thus may offer a loop-avoiding attachment point. o [TBD] The DAG Root may periodically issue sequence number increments, causing the issue of N+1 o [TBD] The broken link (C)->(A) may be detected through some other means, and signalled to or cause a trigger at the DAG Root, causing the issue of N+1 o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and determine it is able to rejoin the original DAG by immediately reattaching j to Node (B) (No hold-up state in this example. The DAG is now as depicted in Figure 2-3 o Node (C) may then subsequently send RA-DIO with DAG Sequence number N+1, allowing Node (D) to reattach (not depicted). ------------------------------------------------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Oct 7 22:27:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78993A6890 for ; Wed, 7 Oct 2009 22:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.789 X-Spam-Level: X-Spam-Status: No, score=-9.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnIC7itHQFST for ; Wed, 7 Oct 2009 22:27:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 752343A6855 for ; Wed, 7 Oct 2009 22:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=184; q=dns/txt; s=amsiport01001; t=1254979779; x=1256189379; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R OL=20Meeting=20IETF-76|Date:=20Thu,=208=20Oct=202009=2007 :29:35=20+0200|Message-Id:=20|To:=20IETF=20ROLL=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit; bh=ohHuiukThJw2j9KCyalHqMKATJqAeFh5xnkjM/KW2Os=; b=BJPih51+4oYnRCrymXpgAUaiJIenSSp/NEcVBve4DqURPDZzCtI6S2VF NNTqQJi6CyY7k6WXKITl9imgZvyrL9znmqCTFwLwp0rjsvq1SoudglbYR mQywIGN7CBtqI9Crsz8KIpyJ0yYM3sm6g8sGrnR/S+qivN+28UAjh00Hx U=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAALcVzUqQ/uCWe2dsb2JhbACafgEBFiQGpGaYGYQqBA X-IronPort-AV: E=Sophos;i="4.44,523,1249257600"; d="scan'208";a="51232741" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 05:29:37 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n985Tbb7003467 for ; Thu, 8 Oct 2009 05:29:37 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:29:36 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:29:36 +0200 Message-Id: From: JP Vasseur To: IETF ROLL Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 07:29:35 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Oct 2009 05:29:36.0359 (UTC) FILETIME=[52F22770:01CA47D8] Subject: [Roll] ROL Meeting IETF-76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 05:27:59 -0000 Dear all, Just to let you know that there will be a ROLL WG meeting at IETF-76, we just do not know when yet. The final agenda will be published by Oct 16. Thanks. JP. From jvasseur@cisco.com Wed Oct 7 22:51:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B7228C202 for ; Wed, 7 Oct 2009 22:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3kd73AgPFcs for ; Wed, 7 Oct 2009 22:51:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1D6F428C1F1 for ; Wed, 7 Oct 2009 22:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=14001; q=dns/txt; s=amsiport01001; t=1254981176; x=1256190776; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Thu,=208=20Oct=20 2009=2007:50:52=20+0200|Message-Id:=20<26DE166F-0295-4509 -9DDB-9213DE49FE6F@cisco.com>|To:=20Jerald.P.Martocci@jci .com|Cc:=20IETF=20ROLL=20,=20Kris=20Pister =20,=0D=0A=20=20=20=20=20=20=20 =20"???[??????]"=20|Mime-Version:=201.0=20( Apple=20Message=20framework=20v936)|In-Reply-To:=20|References:=20; bh=IkjmyI0/JUSdYaI3YomTO8FPilfzE+xnbQ83aL2Vorc=; b=ig5E1ghJeJYZ/XHLVn16P6+ptLL3PZCPicHcuH0pDxj3E0QbtVvhKMA0 +BxfamMnGvXV8d7wIXy1GqMT1aPzhIrW4Ltpa4TFQ5gjbBDIdoCXYhZbl DW0rIf/vXJ4YOMPxwP45CtkQeX+8nHDHMs6/zNRVKsVJYvcOZjim1U2HQ k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkAAJIbzUqQ/uCWe2dsb2JhbACCJi8hmAgBARYkBqRZmBuCJoIEBA X-IronPort-AV: E=Sophos;i="4.44,523,1249257600"; d="scan'208,217";a="51233549" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 05:52:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n985qspA006612; Thu, 8 Oct 2009 05:52:54 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:52:54 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:52:53 +0200 Message-Id: <26DE166F-0295-4509-9DDB-9213DE49FE6F@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-311--351538052 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 07:50:52 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Oct 2009 05:52:53.0298 (UTC) FILETIME=[93962120:01CA47DB] Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 05:51:16 -0000 --Apple-Mail-311--351538052 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Oct 7, 2009, at 9:51 PM, Jerald.P.Martocci@jci.com wrote: > > JP, > > I am not sure what you're asking, but I 'll hazard a guess. Let me > know if my comments make sense. > > I believe you are saying that the Metrics ID specifies some > minimization strategies and are asking if we should add additional > strategies for 1) latency and 2) link reliability. > That's right. This document specifies the list of metric used by RPL to build the DAG (parent selection). > As for latency, I am presuming this would be analogous to a QoS > strategy. That is move packets from point 'a' to point 'b' in the > minimal amount of time. The Building Requirements called out a QoS > requirement to assure high priority packets (e.g. Fire Alarms) could > traverse the LLN faster than other messages. > Yes, I would just like to clarify something here. We are not discussing QoS, which strictly speaking refers to the set of mechanisms used along the forwarding path (scheduling, congestion management such as RED, ...) once the path is computed. For example, you could compute the DAG based on a reliability metrics and provide differentiated QoS to traffic forwarded along this path. The question here is whether we should use a QoS metric to build the DAG and if yes what should be the metric. Several IETF ago, we agreed that queueing delays were not a good idea due to their high fluctuation. Furthermore, it does not make much sense when nodes have 1 packet buffer ... This is why the proposal was here to use latency in order to reflect the MAC latency, which may indeed vary by an order of magnitude. > As for Link Reliability, I also vote 'yes'. I am presume that Link > Reliability is akin to ETX. That is moving packets from point 'a' > to point 'b' with the best possible change of success of arrival > with no errors. Right. In the implementations that you deployed, did you use such "QoS" and reliability metric ? In which units ? Thanks. JP. > > > So I think I have answered your questions. If not, please let me > know. > > Jerry > > > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 10/07/2009 01:08 PM > > To > IETF ROLL > cc > Kris Pister > Subject > [Roll] RPL Metric ID > > > > > > Dear all, > > We would appreciate your feed-back on RPL routing metrics. > > Now that RPL is stabilizing it is time to move forward with the > METRIC I-D. The next revision will be a major one, with packet > encoding, processing rules, etc. > > We discussed and agreed some time ago on several links and nodes > metrics (also required according to our requirement IDs). > > Still, there are a few metrics for which we would like to know > whether you think that they should be specified. > > 4.2. Latency > > As with throughput, the latency of many LLN MAC sub-layers can be > varied over many orders of magnitude, again with a corresponding > change in current consumption. Some LLN MACs will allow the > latency > to be adjusted globally on the subnet, or on a link-by-link > basis, or > not at all. Some will insist that it be fixed for a given link, > but > allow it to be variable from link to link. For efficient > operation, > nodes must be able to report the range of latency that their links > can handle, and the currently available latency. > > 4.3. Link reliability > > In LLNs, link reliability is degraded by external interference and > multi-path interference. Multipath typically affects both > directions > on the link equally, whereas external interference is sometimes > uni- > directional. Time scales vary from milliseconds to days, and are > often periodic and linked to human activity. Packet error rate can > generally be measured directly, and other metrics (e.g. bit error > rate, mean time between failures) are typically derived from that. > > In addition: > > Node Memory resources: > > Memory is a critical node resources in presence of constrained > nodes. Is there a need to report node memory resources as a routing > metric/constraint ? > > Node CPU resources: > CPU duty cycle for virtually all LLN applications to date is well > below 10%, and the trend in low power embedded systems is to more > capable processors rather than less. Computational speed is not > expected to be a limiting factor in routing in LLNs. Is there a need > to report node CPU resources as a routing metric/constraint ? > > Link Security metrics > > Thanks for your feed-back. > > JP, Mijeon, Kris._______________________________________________ > 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 --Apple-Mail-311--351538052 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Oct 7, 2009, at 9:51 PM, Jerald.P.Martocci@jci.com = wrote:


JP,
=
I am not sure what you're = asking, but I 'll hazard a guess.  Let me know if my comments make = sense.

I believe = you are saying that the Metrics ID specifies some minimization = strategies and are asking if we should add additional strategies for 1) = latency and 2) link reliability.
=

That's right. This document = specifies the list of metric used by RPL to build the DAG (parent = selection).

As for latency, I am presuming this would be = analogous to a QoS strategy.  That is move packets from point 'a' =  to point 'b' in the minimal amount of time.  The Building = Requirements called out a QoS requirement to assure high priority = packets (e.g. Fire Alarms) could traverse the LLN faster than other = messages.


Yes, I would = just like to clarify something here. We are not discussing QoS, which = strictly speaking refers to the set of mechanisms used along the = forwarding path (scheduling, congestion management such as RED, ...) = once the path is computed. For example, you could compute the DAG based = on a reliability metrics and provide differentiated QoS to traffic = forwarded along this path.

The question here is = whether we should use a QoS metric to build the DAG and if yes what = should be the metric. Several IETF ago, we agreed that queueing delays = were not a good idea due to their high fluctuation. Furthermore, it does = not make much sense when nodes have 1 packet buffer = ... 

This is why the proposal was here to = use latency in order to reflect the MAC latency, which may indeed vary = by an order of magnitude. 

As for Link Reliability, I also vote = 'yes'.  I am presume that Link Reliability is akin to ETX. =  That is moving packets from point 'a' to point 'b' with the best = possible change of success of arrival with no = errors.

Right. 

=
In the implementations that you deployed, did you use such = "QoS" and reliability metric ? In which units = ?

Thanks.

JP.

<= blockquote type=3D"cite">

So= I think I have answered your questions.  If not, please let me = know.

Jerry =



= <mime-attachment.jpeg>


JP Vasseur <jvasseur@cisco.com> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">10/07/2009 01:08 PM =

To
IETF ROLL <roll@ietf.org>
cc
Kris Pister <kpister@dustnetworks.com><= /font>
Subject
[Roll] RPL Metric = ID

=



Dear = all,

We would appreciate your feed-back = on RPL routing metrics.

Now that RPL is = stabilizing it is time to move forward with the METRIC I-D. The next = revision will be a major one, with packet encoding, processing rules, = etc.

We discussed and agreed some time = ago on several links and nodes metrics (also required according to our = requirement IDs).

Still, there are a = few metrics for which we would like to know whether you think that they = should be specified.

4.2. =  Latency

   As = with throughput, the latency of many LLN MAC sub-layers can = be
   varied over many = orders of magnitude, again with a corresponding
   change in current consumption.  Some LLN = MACs will allow the latency
  =  to be adjusted globally on the subnet, or on a link-by-link basis, = or
   not at all. =  Some will insist that it be fixed for a given link, but =
   allow it to be variable from link = to link.  For efficient operation,
   nodes must be able to report the range of = latency that their links
  =  can handle, and the currently available latency.
=
4.3.  Link reliability
=
   In LLNs, link reliability is = degraded by external interference and
   multi-path interference.  Multipath = typically affects both directions
   on the link equally, whereas external = interference is sometimes uni-
  =  directional.  Time scales vary from milliseconds to days, and = are
   often periodic and = linked to human activity.  Packet error rate can =
   generally be measured directly, and = other metrics (e.g. bit error
  =  rate, mean time between failures) are typically derived from = that.

In addition:
=
Node Memory resources:

Memory is a critical node resources in presence of = constrained nodes. Is there a need to report node memory resources as a = routing metric/constraint ?

Node CPU = resources:
CPU duty cycle for virtually = all LLN applications to date is well below 10%, and the trend in low = power embedded systems is to more capable processors rather than less. = Computational speed is not expected to be a limiting factor in routing = in LLNs. Is there a need to report node CPU resources as a routing = metric/constraint ?

Link Security = metrics

Thanks for your = feed-back.

JP, Mijeon, = Kris._______________________________________________
Roll = mailing list
Roll@ietf.org
= https://www.ietf.org/m= ailman/listinfo/roll
 =
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-311--351538052-- From jvasseur@cisco.com Wed Oct 7 22:51:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07D228C1E2 for ; Wed, 7 Oct 2009 22:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.81 X-Spam-Level: X-Spam-Status: No, score=-9.81 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LONoZAhSk0GI for ; Wed, 7 Oct 2009 22:51:15 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3C32228C200 for ; Wed, 7 Oct 2009 22:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3364; q=dns/txt; s=amsiport01001; t=1254981177; x=1256190777; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Thu,=208=20Oct=20 2009=2007:52:27=20+0200|Message-Id:=20|To:=20Mukul=20Goyal=20|Cc:=20Kris=20Pister=20,=20IETF=20ROLL=20|Mime-Version:=201.0 =20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<174347 7406.15552751254944444717.JavaMail.root@mail02.pantherlin k.uwm.edu>|References:=20<1743477406.15552751254944444717 .JavaMail.root@mail02.pantherlink.uwm.edu>; bh=rs5/Y32PFvho5W1JWBOXOeuaIct9OUEpXybM3UGgUCw=; b=c0S6GkmXzznIqwN1vlUvPNTV5GzD9/4A8vHWo37AwPuj1IH3AWgSIkqK MX9HL90LXOmpXRAo3k++QllBdBmxZcnpMhCOGoGXRRZJ3XnB8rJZeDkT3 l6b8Zu1H9u/GghSLHLF+rATmtuKoUWFvsBOZcv2t/aFSIVFUZY1DtRdz8 o=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAAJIbzUqQ/uCWe2dsb2JhbACafgEBFiQGpFmYG4ImggQEii4 X-IronPort-AV: E=Sophos;i="4.44,523,1249257600"; d="scan'208";a="51233551" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 05:52:56 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n985quIA006615; Thu, 8 Oct 2009 05:52:56 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:52:55 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:52:55 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 07:52:27 +0200 References: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Oct 2009 05:52:55.0392 (UTC) FILETIME=[94D5A600:01CA47DB] Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 05:51:16 -0000 Hi Mukul, On Oct 7, 2009, at 9:40 PM, Mukul Goyal wrote: > I think both latency and reliability are important metrics. > OK thanks for the feed-backs. The most obvious and common reliability is ETX. Any preference for the latency? > I am sort of negative on using memory/CPU availability as metric or > constraint. They seem like local factors to me. If a node is running > low on memory/CPU, it can simply not participate in routing. And we already have an "overload" bit. Thanks. JP. > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "IETF ROLL" > Cc: "Kris Pister" > Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Metric ID > > > Dear all, > > > We would appreciate your feed-back on RPL routing metrics. > > > Now that RPL is stabilizing it is time to move forward with the > METRIC I-D. The next revision will be a major one, with packet > encoding, processing rules, etc. > > > We discussed and agreed some time ago on several links and nodes > metrics (also required according to our requirement IDs). > > > Still, there are a few metrics for which we would like to know > whether you think that they should be specified. > > > 4.2. Latency > > > > As with throughput, the latency of many LLN MAC sub-layers can be > varied over many orders of magnitude, again with a corresponding > change in current consumption. Some LLN MACs will allow the > latency > to be adjusted globally on the subnet, or on a link-by-link > basis, or > not at all. Some will insist that it be fixed for a given link, > but > allow it to be variable from link to link. For efficient > operation, > nodes must be able to report the range of latency that their links > can handle, and the currently available latency. > > > 4.3. Link reliability > > > In LLNs, link reliability is degraded by external interference and > multi-path interference. Multipath typically affects both > directions > on the link equally, whereas external interference is sometimes > uni- > directional. Time scales vary from milliseconds to days, and are > often periodic and linked to human activity. Packet error rate can > generally be measured directly, and other metrics (e.g. bit error > rate, mean time between failures) are typically derived from that. > > > In addition: > > > Node Memory resources: > > > Memory is a critical node resources in presence of constrained > nodes. Is there a need to report node memory resources as a routing > metric/constraint ? > > > Node CPU resources: > CPU duty cycle for virtually all LLN applications to date is well > below 10%, and the trend in low power embedded systems is to more > capable processors rather than less. Computational speed is not > expected to be a limiting factor in routing in LLNs. Is there a need > to report node CPU resources as a routing metric/constraint ? > > > Link Security metrics > > > Thanks for your feed-back. > > > JP, Mijeon, Kris. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Oct 7 22:51:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E75B28C20B for ; Wed, 7 Oct 2009 22:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.82 X-Spam-Level: X-Spam-Status: No, score=-9.82 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BOEw4NoN5as for ; Wed, 7 Oct 2009 22:51:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1053128C201 for ; Wed, 7 Oct 2009 22:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=14060; q=dns/txt; s=amsiport01001; t=1254981178; x=1256190778; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Thu,=208=20Oct=20 2009=2007:52:55=20+0200|Message-Id:=20<74CC1129-9A39-4698 -95B0-99A2EF7D2929@cisco.com>|To:=20Jerald.P.Martocci@jci .com|Cc:=20IETF=20ROLL=20,=20Kris=20Pister =20,=0D=0A=20=20=20=20=20=20=20 =20"???[??????]"=20|Mime-Version:=201.0=20( Apple=20Message=20framework=20v936)|In-Reply-To:=20|References:=20; bh=rdNv7Sj42eig4603WyEjpsrLxRWGfeNMuC8tzmj0ys0=; b=X1aeQ45pSiUD6tlBsLmf2Vnkts+TK6il3eYlXM+U0jhxKZlIkQmz0lD7 diycTcKVpTqPW+YVvw93yB6eDnP5X3Pk3TSbNi4BxRsTMltbx//cy+f+F +IQwJsTxbQmnMKuDYxpscV4VKkudm1I35ZHbrSuwmXbrRGJgQwG5eAcyu M=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkAAJIbzUqQ/uCWe2dsb2JhbACCJi8hmAgBARYkBqRZmBuCJoIEBA X-IronPort-AV: E=Sophos;i="4.44,523,1249257600"; d="scan'208,217";a="51233553" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 05:52:57 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n985qv4Y006624; Thu, 8 Oct 2009 05:52:57 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:52:57 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:52:56 +0200 Message-Id: <74CC1129-9A39-4698-95B0-99A2EF7D2929@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-312--351414769 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 07:52:55 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Oct 2009 05:52:56.0548 (UTC) FILETIME=[95860A40:01CA47DB] Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 05:51:18 -0000 --Apple-Mail-312--351414769 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Oct 7, 2009, at 9:51 PM, Jerald.P.Martocci@jci.com wrote: > > JP, > > I am not sure what you're asking, but I 'll hazard a guess. Let me > know if my comments make sense. > > I believe you are saying that the Metrics ID specifies some > minimization strategies and are asking if we should add additional > strategies for 1) latency and 2) link reliability. > That's right. This document specifies the list of metric used by RPL to build the DAG (parent selection). > As for latency, I am presuming this would be analogous to a QoS > strategy. That is move packets from point 'a' to point 'b' in the > minimal amount of time. The Building Requirements called out a QoS > requirement to assure high priority packets (e.g. Fire Alarms) could > traverse the LLN faster than other messages. > Yes, I would just like to clarify something here. We are not discussing QoS, which strictly speaking refers to the set of mechanisms used along the forwarding path (scheduling, congestion management such as RED, ...) once the path is computed. For example, you could compute the DAG based on a reliability metrics and provide differentiated QoS to traffic forwarded along this path. The question here is whether we should use a QoS metric to build the DAG and if yes what should be the metric. Several IETF ago, we agreed that queueing delays were not a good idea due to their high fluctuation. Furthermore, it does not make much sense when nodes have 1 packet buffer ... This is why the proposal was here to use latency in order to reflect the MAC latency, which may indeed vary by an order of magnitude. > As for Link Reliability, I also vote 'yes'. I am presume that Link > Reliability is akin to ETX. That is moving packets from point 'a' > to point 'b' with the best possible change of success of arrival > with no errors. Right. In the implementations that you deployed, did you use such "QoS" and reliability metric ? In which units ? Thanks. JP. > > > So I think I have answered your questions. If not, please let me > know. > > Jerry > > > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 10/07/2009 01:08 PM > > To > IETF ROLL > cc > Kris Pister > Subject > [Roll] RPL Metric ID > > > > > > Dear all, > > We would appreciate your feed-back on RPL routing metrics. > > Now that RPL is stabilizing it is time to move forward with the > METRIC I-D. The next revision will be a major one, with packet > encoding, processing rules, etc. > > We discussed and agreed some time ago on several links and nodes > metrics (also required according to our requirement IDs). > > Still, there are a few metrics for which we would like to know > whether you think that they should be specified. > > 4.2. Latency > > As with throughput, the latency of many LLN MAC sub-layers can be > varied over many orders of magnitude, again with a corresponding > change in current consumption. Some LLN MACs will allow the > latency > to be adjusted globally on the subnet, or on a link-by-link > basis, or > not at all. Some will insist that it be fixed for a given link, > but > allow it to be variable from link to link. For efficient > operation, > nodes must be able to report the range of latency that their links > can handle, and the currently available latency. > > 4.3. Link reliability > > In LLNs, link reliability is degraded by external interference and > multi-path interference. Multipath typically affects both > directions > on the link equally, whereas external interference is sometimes > uni- > directional. Time scales vary from milliseconds to days, and are > often periodic and linked to human activity. Packet error rate can > generally be measured directly, and other metrics (e.g. bit error > rate, mean time between failures) are typically derived from that. > > In addition: > > Node Memory resources: > > Memory is a critical node resources in presence of constrained > nodes. Is there a need to report node memory resources as a routing > metric/constraint ? > > Node CPU resources: > CPU duty cycle for virtually all LLN applications to date is well > below 10%, and the trend in low power embedded systems is to more > capable processors rather than less. Computational speed is not > expected to be a limiting factor in routing in LLNs. Is there a need > to report node CPU resources as a routing metric/constraint ? > > Link Security metrics > > Thanks for your feed-back. > > JP, Mijeon, Kris._______________________________________________ > 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 --Apple-Mail-312--351414769 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Oct 7, 2009, at 9:51 PM, Jerald.P.Martocci@jci.com = wrote:


JP,
=
I am not sure what you're = asking, but I 'll hazard a guess.  Let me know if my comments make = sense.

I believe = you are saying that the Metrics ID specifies some minimization = strategies and are asking if we should add additional strategies for 1) = latency and 2) link reliability.
=

That's right. This document = specifies the list of metric used by RPL to build the DAG (parent = selection).

As for latency, I am presuming this would be = analogous to a QoS strategy.  That is move packets from point 'a' =  to point 'b' in the minimal amount of time.  The Building = Requirements called out a QoS requirement to assure high priority = packets (e.g. Fire Alarms) could traverse the LLN faster than other = messages.


Yes, I would = just like to clarify something here. We are not discussing QoS, which = strictly speaking refers to the set of mechanisms used along the = forwarding path (scheduling, congestion management such as RED, ...) = once the path is computed. For example, you could compute the DAG based = on a reliability metrics and provide differentiated QoS to traffic = forwarded along this path.

The question here is = whether we should use a QoS metric to build the DAG and if yes what = should be the metric. Several IETF ago, we agreed that queueing delays = were not a good idea due to their high fluctuation. Furthermore, it does = not make much sense when nodes have 1 packet buffer = ... 

This is why the proposal was here to = use latency in order to reflect the MAC latency, which may indeed vary = by an order of magnitude. 

As for Link Reliability, I also vote = 'yes'.  I am presume that Link Reliability is akin to ETX. =  That is moving packets from point 'a' to point 'b' with the best = possible change of success of arrival with no = errors.

Right. 

=
In the implementations that you deployed, did you use such = "QoS" and reliability metric ? In which units = ?

Thanks.

JP.

<= blockquote type=3D"cite">

So= I think I have answered your questions.  If not, please let me = know.

Jerry =



= <mime-attachment.jpeg>


JP Vasseur <jvasseur@cisco.com> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">10/07/2009 01:08 PM =

To
IETF ROLL <roll@ietf.org>
cc
Kris Pister <kpister@dustnetworks.com><= /font>
Subject
[Roll] RPL Metric = ID

=



Dear = all,

We would appreciate your feed-back = on RPL routing metrics.

Now that RPL is = stabilizing it is time to move forward with the METRIC I-D. The next = revision will be a major one, with packet encoding, processing rules, = etc.

We discussed and agreed some time = ago on several links and nodes metrics (also required according to our = requirement IDs).

Still, there are a = few metrics for which we would like to know whether you think that they = should be specified.

4.2. =  Latency

   As = with throughput, the latency of many LLN MAC sub-layers can = be
   varied over many = orders of magnitude, again with a corresponding
   change in current consumption.  Some LLN = MACs will allow the latency
  =  to be adjusted globally on the subnet, or on a link-by-link basis, = or
   not at all. =  Some will insist that it be fixed for a given link, but =
   allow it to be variable from link = to link.  For efficient operation,
   nodes must be able to report the range of = latency that their links
  =  can handle, and the currently available latency.
=
4.3.  Link reliability
=
   In LLNs, link reliability is = degraded by external interference and
   multi-path interference.  Multipath = typically affects both directions
   on the link equally, whereas external = interference is sometimes uni-
  =  directional.  Time scales vary from milliseconds to days, and = are
   often periodic and = linked to human activity.  Packet error rate can =
   generally be measured directly, and = other metrics (e.g. bit error
  =  rate, mean time between failures) are typically derived from = that.

In addition:
=
Node Memory resources:

Memory is a critical node resources in presence of = constrained nodes. Is there a need to report node memory resources as a = routing metric/constraint ?

Node CPU = resources:
CPU duty cycle for virtually = all LLN applications to date is well below 10%, and the trend in low = power embedded systems is to more capable processors rather than less. = Computational speed is not expected to be a limiting factor in routing = in LLNs. Is there a need to report node CPU resources as a routing = metric/constraint ?

Link Security = metrics

Thanks for your = feed-back.

JP, Mijeon, = Kris._______________________________________________
Roll = mailing list
Roll@ietf.org
= https://www.ietf.org/m= ailman/listinfo/roll
 =
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

= --Apple-Mail-312--351414769-- From jvasseur@cisco.com Wed Oct 7 22:56:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8E43A67D4 for ; Wed, 7 Oct 2009 22:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.83 X-Spam-Level: X-Spam-Status: No, score=-7.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 422eTMJ95810 for ; Wed, 7 Oct 2009 22:56:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9C6DD3A67BE for ; Wed, 7 Oct 2009 22:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=2310; q=dns/txt; s=sjiport03001; t=1254981467; x=1256191067; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Thu,=208=20Oct=20 2009=2007:57:44=20+0200|Message-Id:=20|To:=20Michael=20Richardson =20|Cc:=20IETF=20ROLL=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20<762. 1254943831@marajade.sandelman.ca>|References:=20=20=20<762.1254943 831@marajade.sandelman.ca>; bh=xtE4HhIPL7PByns7/UzipviJlFUxBM/p/dWs+XwP7Tg=; b=dD1+hiewiI8zwVh8QQnoSPNNzEhQeR/CGl40tHc6fvC1dLSYZVFRCakK 5qpFI3tdEYyguzfP6O/frMvF/v1jVMo5DsOxmSXsRM2VrXwS2cOxqT2KM 0pQyXXb/fNvq22uqvazj1dgATK1NZwBuDSqmIDSUQagv6ayXWIAbM8zuR E=; Authentication-Results: sj-iport-3.cisco.com; dkim=pass (signature verified [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEYczUqrR7PD/2dsb2JhbADAJohjASsIGI5mBoJDCIFf X-IronPort-AV: E=Sophos;i="4.44,523,1249257600"; d="scan'208";a="195321465" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Oct 2009 05:57:47 +0000 Received: from rcdn-core-6.cisco.com (rcdn-core-6.cisco.com [173.37.93.157]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n985vk74013505; Wed, 7 Oct 2009 22:57:46 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id n985vk02005591; Thu, 8 Oct 2009 05:57:46 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:57:45 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 07:57:45 +0200 Message-Id: From: JP Vasseur To: Michael Richardson In-Reply-To: <762.1254943831@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 07:57:44 +0200 References: <762.1254943831@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Oct 2009 05:57:45.0475 (UTC) FILETIME=[41BCCD30:01CA47DC] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16934.003 X-TM-AS-Result: No--16.022600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2310; t=1254981467; x=1255845467; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20RPL=20Metric=20ID |Sender:=20; bh=xtE4HhIPL7PByns7/UzipviJlFUxBM/p/dWs+XwP7Tg=; b=lRGukrrMgMUk/GxUPOltbW6gsED3/bUBKCcUJWECX27mlySct6BYlQGn4w uDhQo3swgICc7Ovy3UUZLVGlneFxk4pvu/Om8zVzWVWr65K01yTCt305pcWe 04Q1JJLSz1; Cc: IETF ROLL Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 05:56:06 -0000 Hi Michael, On Oct 7, 2009, at 9:30 PM, Michael Richardson wrote: > >>>>>> "JP" == JP Vasseur writes: > JP> We discussed and agreed some time ago on several links and > nodes > JP> metrics (also required according to our requirement IDs). > > JP> Still, there are a few metrics for which we would like to know > JP> whether you think that they should be specified. > > If I understand your question, you are asking if the protocol should > carry these fields in the DIOs, and transmitted through the DAG? > Or are you asking if these things should be configured into the node > (somehow? operator?) and taken into account. This is already specified in RPL: metrics are carried in the DAG Metric Container and used during parent selection process according to the OF. So the question is whether we should have metrics reflecting link latency, reliability, ... > Or are you asking if RPL has to somehow measure these things for each > on-link peer ("cousin"?), such that it can be taken into account? > The local per-link metric is also taken into account. Upon receiving a RA-DIO, a node will take into account the advertised metric, OF, rank and also local link characteristics. > JP> Node CPU resources: CPU duty cycle for virtually all LLN > JP> applications to date is well below 10%, and the trend in low > JP> power embedded systems is to more capable processors rather > than > JP> less. Computational speed is not expected to be a limiting > JP> factor in routing in LLNs. Is there a need to report node CPU > JP> resources as a routing metric/constraint ? > > I.e. it's better to be a sleepy hare, than a slow-plodding-tortoise. > Thanks. JP. > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Thu Oct 8 00:45:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4EF4F28C20E; Thu, 8 Oct 2009 00:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091008074501.4EF4F28C20E@core3.amsl.com> Date: Thu, 8 Oct 2009 00:45:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-terminology-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 07:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Terminology in Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-ietf-roll-terminology-02.txt Pages : 8 Date : 2009-10-08 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-terminology-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-08003820.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Thu Oct 8 00:47:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8A028C21B for ; Thu, 8 Oct 2009 00:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.814 X-Spam-Level: X-Spam-Status: No, score=-9.814 tagged_above=-999 required=5 tests=[AWL=0.783, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZVMobcQiQfS for ; Thu, 8 Oct 2009 00:47:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 03F2728C20E for ; Thu, 8 Oct 2009 00:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=8438; q=dns/txt; s=amsiport01001; t=1254988138; x=1256197738; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20F wd:=20I-D=20Action:draft-ietf-roll-terminology-02.txt=20 |Date:=20Thu,=208=20Oct=202009=2009:48:54=20+0200 |Message-Id:=20|To:=20IETF=20ROLL=20|Mime-Version: =201.0=20(Apple=20Message=20framework=20v936)|References: =20<20091008074501.4EF4F28C20E@core3.amsl.com>; bh=rN25PHJmmWB6lkV4CFex+q51wwaw9ZCy//Rtnv2kPmo=; b=U3W0kB5uKGVviJ2TpkZVHZMayfXlKdpuh2icZnSYOaAKYZcDXqjk34/U 9lpT9rLCRNncN1YQl4Oy+W95hdP6MP3m6tfMeM5nyuffIXl9llatTIEBW 2IJfx7ygiLCaisArF0nYCfkoHhMC9yWRinrmadCVKpgbELU6fY2k1KzZw Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQAAIc2zUqQ/uCWe2dsb2JhbACCJi+YKQEBFiQGpQiYH4QqBA X-IronPort-AV: E=Sophos;i="4.44,524,1249257600"; d="scan'208,217";a="51241860" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 07:48:56 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n987muqP000247 for ; Thu, 8 Oct 2009 07:48:56 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 09:48:56 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 09:48:55 +0200 Message-Id: From: JP Vasseur To: IETF ROLL Content-Type: multipart/alternative; boundary=Apple-Mail-333--344455525 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 09:48:54 +0200 References: <20091008074501.4EF4F28C20E@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Oct 2009 07:48:55.0966 (UTC) FILETIME=[C9A8F3E0:01CA47EB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16934.003 X-TM-AS-Result: No--22.187200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-terminology-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 07:47:17 -0000 --Apple-Mail-333--344455525 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit for the most part a refresh, adding the P2P, P2MP, MP2P terminology since it is used in several ROLL documents. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 8, 2009 9:45:01 AM CEDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-terminology-02.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Terminology in Low power And Lossy Networks > Author(s) : J. Vasseur > Filename : draft-ietf-roll-terminology-02.txt > Pages : 8 > Date : 2009-10-08 > > The documents defines a terminology for discussing routing > requirements and solutions for networks referred to as Low power and > Lossy Networks (LLN). A LLN is typically composed of many embedded > devices with limited power, memory, and processing resources > interconnected by a variety of links. There is a wide scope of > application areas for LLNs, including industrial monitoring, building > automation (e.g. Heating, Ventilating, Air Conditioning, lighting, > access control, fire), connected home, healthcare, environmental > monitoring, urban sensor networks, energy management, assets > tracking, refrigeration. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-333--344455525 Content-Type: multipart/mixed; boundary=Apple-Mail-334--344455524 --Apple-Mail-334--344455524 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable for the most part a refresh, = adding the P2P, P2MP, MP2P terminology since it is used in several ROLL = documents.

Thanks.

JP.

Begin forwarded message:

Date: October 8, 2009 9:45:01 AM = CEDT
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-ietf-roll-terminology-02.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : = Terminology in Low power And Lossy Networks
Author(s) =       : J. Vasseur
Filename =        : = draft-ietf-roll-terminology-02.txt
Pages =           : 8
Date =            : = 2009-10-08

The documents defines a terminology for discussing = routing
requirements and solutions for networks referred to as Low = power and
Lossy Networks (LLN).  A LLN is typically composed of = many embedded
devices with limited power, memory, and processing = resources
interconnected by a variety of links.  There is a wide = scope of
application areas for LLNs, including industrial monitoring, = building
automation (e.g.  Heating, Ventilating, Air = Conditioning, lighting,
access control, fire), connected home, = healthcare, environmental
monitoring, urban sensor networks, energy = management, assets
tracking, refrigeration.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-02.t= xt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-334--344455524 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-10-08003820.I-D@ietf.org>

--Apple-Mail-334--344455524 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-334--344455524-- --Apple-Mail-333--344455525-- From pthubert@cisco.com Thu Oct 8 04:18:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962A128C100 for ; Thu, 8 Oct 2009 04:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8rqpLUPse7Z for ; Thu, 8 Oct 2009 04:18:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id ED4533A67B3 for ; Thu, 8 Oct 2009 04:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4062; q=dns/txt; s=amsiport01001; t=1255000840; x=1256210440; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20one=20DAG=20per=20RPL=20 instance|Date:=20Thu,=208=20Oct=202009=2013:20:33=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D614C3B@XM B-AMS-107.cisco.com>|To:=20"Mukul=20Goyal"=20|Cc:=20"roll"=20,=20"JP=20Vasseur=20(jv asseur)"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20base64|In-Reply-To:=20<2429 71368.15581641254947146329.JavaMail.root@mail02.pantherli nk.uwm.edu>|References:=20<6A2A459175DABE4BB11DE2026AA50A 5D5A21E7@XMB-AMS-107.cisco.com>=20<242971368.155816412549 47146329.JavaMail.root@mail02.pantherlink.uwm.edu>; bh=12wZ5TjwNPCwpPUCDVpc34I/BVc1u2AisQYvwNpZrLk=; b=GLDqIf1cldExE6A2lN6cqmWOkrRvVR7+NGZHdhCV00w2Nde9c4Y1YABd 6sz8Q/mgoEtvT6ttwhcQdl6u5KKEqv2GPwYmc7Na34ZtTAxdz0U//dvgi o7TvTW8ON4d5qzk/sZQ6+X58jV/03RONIGh+RQigFjT3W+2rIuIZK6mEv 4=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8AAL9nzUqQ/uCWe2dsb2JhbACZUIEwAQEWJAalNZgghCoEijw X-IronPort-AV: E=Sophos;i="4.44,525,1249257600"; d="scan'208";a="51268600" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 11:20:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n98BKc3G013671; Thu, 8 Oct 2009 11:20:38 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 13:20:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 8 Oct 2009 13:20:33 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D614C3B@XMB-AMS-107.cisco.com> In-Reply-To: <242971368.15581641254947146329.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] one DAG per RPL instance Thread-Index: AcpHjY3cjw6Ske+UTxCDICHSxfs3KgAer+bA References: <6A2A459175DABE4BB11DE2026AA50A5D5A21E7@XMB-AMS-107.cisco.com> <242971368.15581641254947146329.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 08 Oct 2009 11:20:38.0653 (UTC) FILETIME=[5D0D2AD0:01CA4809] Cc: roll Subject: Re: [Roll] one DAG per RPL instance X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 11:18:59 -0000 U29ycnkgTXVrdWw6DQoNCkkgbWVhbnQgdGhhdCB0aGUgaW5zdGFuY2VzIGxpdmUgbGlrZSAyIHNo aXBzIGNyb3NzaW5nIGluIHRoZSBuaWdodCBhbmQgbmV2ZXIgcmVhbGl6aW5nIHRoYXQgdGhlIG90 aGVyIHNoaXAgcGFzc2VkIGJ5LiBUaGlzIGlzIHdoYXQgMiBkaWZmZXJlbnQgcHJvdG9jb2xzLCBz YXkgUklQIGFuZCBPU1BGIHdvdWxkIGRvLiBXaGV0aGVyIHRoZSByZXN1bHQgb2Ygb25lIGluc3Rh bmNlIGdldHMgcmVkaXN0cmlidXRlZCBpbiBhbm90aGVyIGlzIGEgbWF0dGVyIG9mIGRlcGxveW1l bnQgcG9saWN5IGFuZCBvdXRzaWRlIHRoZSBzY29wZSBvZiBSUEwuDQoNClBhc2NhbA0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3Vs QHV3bS5lZHVdDQo+U2VudDogbWVyY3JlZGkgNyBvY3RvYnJlIDIwMDkgMjI6MjYNCj5UbzogUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPkNjOiByb2xsOyBKUCBWYXNzZXVyIChqdmFzc2V1cikN Cj5TdWJqZWN0OiBSZTogW1JvbGxdIG9uZSBEQUcgcGVyIFJQTCBpbnN0YW5jZQ0KPg0KPlBhc2Nh bCwNCj4NCj5RdW90aW5nIGZyb20geW91ciBwb3N0Og0KPg0KPiIoUlBMKSBJbnN0YW5jZXMgYXJl IGNvbnRleHRzIHRoYXQgcnVuIHRoZSBzYW1lIGNvZGUgYW5kIG9wZXJhdGUgYXMNCj5zaGlwIGlu IHRoZSBuaWdodC4iDQo+DQo+Q291bGQgeW91IHBsZWFzZSBleHBsYWluIHdoYXQgZG8geW91IG1l YW4gYnkgInNoaXAgaW4gdGhlIG5pZ2h0Ii4gSSBoYXZlIG5ldmVyIGhlYXJkIHRoaXMgcGhyYXNl IGJlZm9yZS4NCj4NCj5UaGFua3MNCj5NdWt1bA0KPg0KPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCj5Gcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2Nv LmNvbT4NCj5UbzogIkpQIFZhc3NldXIgKGp2YXNzZXVyKSIgPGp2YXNzZXVyQGNpc2NvLmNvbT4s ICJNdWt1bCBHb3lhbCIgPG11a3VsQFVXTS5FRFU+DQo+Q2M6ICJyb2xsIiA8cm9sbEBpZXRmLm9y Zz4NCj5TZW50OiBNb25kYXksIE9jdG9iZXIgNSwgMjAwOSAxMjo1MToxMCBBTSBHTVQgLTA2OjAw IFVTL0NhbmFkYSBDZW50cmFsDQo+U3ViamVjdDogUkU6IFtSb2xsXSBvbmUgREFHIHBlciBSUEwg aW5zdGFuY2UNCj4NCj4+DQo+Pk9uIE9jdCAzLCAyMDA5LCBhdCAxMTowNSBQTSwgTXVrdWwgR295 YWwgd3JvdGU6DQo+Pg0KPj4+IEhpIGFsbCwNCj4+Pg0KPj4+IEkgd2FzIHdvbmRlcmluZyBpZiBw ZW9wbGUgd2l0aCBleHBlcmllbmNlIGluIHdyaXRpbmcgY29kZSBmb3IgbWVtb3J5Lw0KPj4+IENQ VSBjb25zdHJhaW5lZCBkZXZpY2VzIGNhbiBjb21tZW50IG9uIHRoaXM6IElmIGEgZGV2aWNlIGhh cyB0byBqb2luDQo+Pj4gbXVsdGlwbGUgREFHcywgZG9lcyBpdCBtYWtlIGEgZGlmZmVyZW5jZSAo ZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YNCj4+PiBtZW1vcnkgcmVxdWlyZW1lbnQgYW5kIGV4ZWN1 dGlvbiBlZmZpY2llbmN5KSB3aGV0aGVyIHRoZSBkZXZpY2UgcnVucw0KPj4+IGEgc2luZ2xlIFJQ TCBwcm9jZXNzIChzdXBwb3J0aW5nIGFsbCB0aGUgREFHcykgb3IgbXVsdGlwbGUgUlBMDQo+Pj4g cHJvY2Vzc2VzIChlYWNoIHN1cHBvcnRpbmcganVzdCBvbmUgREFHKS4NCj4+Pg0KPj4NCj4+SXQg ZG9lcyBtYWtlIGEgZGlmZmVyZW5jZSBidXQgaWYgY29kZWQgcmlnaHQsIGEgdmVyeSBtaW5vciBk aWZmZXJlbmNlLg0KPg0KPkFncmVlZC4gSW5zdGFuY2VzIGFyZSBjb250ZXh0cyB0aGF0IHJ1biB0 aGUgc2FtZSBjb2RlIGFuZCBvcGVyYXRlIGFzDQo+c2hpcCBpbiB0aGUgbmlnaHQuIFRoZSBhZGRp dGlvbmFsIHdvcmsgd2lsbCBoYXZlIHRvIGRvIHdpdGggaW5zdGFuY2UNCj50cmFuc2l0aW9uIHBv bGljaWVzLCBidXQgcG9saWNpZXMgYXJlIGFscmVhZHkgcHJlc2VudCBpbiB0aGUgT0NQIGZvciBh DQo+c2luZ2xlIGluc3RhbmNlLg0KPg0KPlRoZSBwcmljZSB0byBwYXkgd2lsbCBwcm9iYWJseSBi ZSBtb3JlIGluIHRlcm1zIG9mOg0KPi0gYmF0dGVyeS4gSXQgYXBwZWFycyB0aGF0IHRoZSBjb250 cm9sIGNvc3QgKG1lbW9yeSwgcHJvdG9jb2wgZXhjaGFuZ2VzKQ0KPmlzIG11bHRpcGxpZWQgYnkg dGhlIG51bWJlciBvZiBpbnN0YW5jZXMuDQo+LSBhZG1pbi4gQXMgc29vbiBhcyB5b3UgaGF2ZSBt dWx0aXBsZSBpbnN0YW5jZXMsIHlvdSBoYXZlIHRvIGRpc3RyaWJ1dGUNCj55b3VyIGluc3RhbmNl IElEcywgcG9saWNpZXMsIGV0Yy4uLg0KPkFzIG9wcG9zZWQgdG8gaW1wbGVtZW50YXRpb24gY29t cGxleGl0eS4NCj4NCj5Ob3RlOiBXZSd2ZSBoYWQgYSBsb3Qgb2YgY29uZnVzaW9uIG1lbnRpb25p bmcgbXVsdGlwbGUgREFHcy4gVGhlcmUgY2FuDQo+YmUgbXVsdGlwbGUgREFHcyB3aXRoaW4gYW4g aW5zdGFuY2UgKG11dHVhbGx5IGV4Y2x1c2l2ZSkgb3Igc2VydmluZw0KPmRpZmZlcmVudCBpbnN0 YW5jZXMuIEl0IGFwcGVhcnMgdGhhdCB5b3VyIHF1ZXN0aW9uIGlzIHJlYWxseSBhYm91dA0KPnNl cnZpbmcgbXVsdGlwbGUgaW5zdGFuY2VzIGFuZCBpdCB3aWxsIGNlcnRhaW5seSBoZWxwIGlmIHdl IGFkb3B0IGENCj5jb21tb24gbGFuZ3VhZ2UgZm9yIHRoZSBjb25jZXB0Lg0KPg0KPkNoZWVycywN Cj4NCj5QYXNjYWwNCj4NCj4+DQo+PkpQLg0KPj4NCj4+DQo+Pj4gVGhhbmtzDQo+Pj4gTXVrdWwN Cj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4+PiBSb2xsQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+Pg0KPj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5Sb2xsIG1haWxpbmcgbGlzdA0KPj5S b2xsQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9s bA0K From Jerald.P.Martocci@jci.com Thu Oct 8 06:18:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1881028C1A7 for ; Thu, 8 Oct 2009 06:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.388 X-Spam-Level: X-Spam-Status: No, score=-6.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxDD7BH2oTTB for ; Thu, 8 Oct 2009 06:18:23 -0700 (PDT) Received: from exprod8og110.obsmtp.com (exprod8og110.obsmtp.com [64.18.3.100]) by core3.amsl.com (Postfix) with ESMTP id DBB4C28C162 for ; Thu, 8 Oct 2009 06:18:22 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob110.postini.com ([64.18.7.12]) with SMTP ID DSNKSs3m/IScF+M+XMQ9kItLF80UA/KyoGwc@postini.com; Thu, 08 Oct 2009 06:20:05 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009100808200239-1081516 ; Thu, 8 Oct 2009 08:20:02 -0500 In-Reply-To: <26DE166F-0295-4509-9DDB-9213DE49FE6F@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 8 Oct 2009 08:19:33 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 10/08/2009 08:19:47 AM, Serialize complete at 10/08/2009 08:19:47 AM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/08/2009 08:20:02 AM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/08/2009 08:20:20 AM, Serialize complete at 10/08/2009 08:20:20 AM Content-Type: multipart/alternative; boundary="=_alternative 004933B886257649_=" Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 13:18:25 -0000 This is a multipart message in MIME format. --=_alternative 004933B886257649_= Content-Type: text/plain; charset="US-ASCII" JP, Thanks for the response. Per your question, our current implementation uses standard ZigBee algorithms. ZigBee bases path costs on RSSI only. While nice and simple; unfortunately we feel this approach doesn't necessarily pick the best communication paths, only the ones that have a strong signal. Mukul did a lot of simulation work for us on this and helped drive us to this conclusion. Our product was developed and deployed in 2006. We used what is termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has developed the 'ZigBee PRO' stack which will in time subsume the ZigBee Stack. ZigBee PRO selects paths based on the best symmetric path found. I believe asymmetric paths are discarded or only used as a last resort. Unfortunately, I have no empirical or simulation data on this metric. Maybe Richard can provide some insight on this approach since I believe it was championed by Ember. Jerry JP Vasseur 10/08/2009 12:53 AM To Jerald.P.Martocci@jci.com cc IETF ROLL , Kris Pister , "???[??????]" Subject Re: [Roll] RPL Metric ID Hi Jerry, On Oct 7, 2009, at 9:51 PM, Jerald.P.Martocci@jci.com wrote: JP, I am not sure what you're asking, but I 'll hazard a guess. Let me know if my comments make sense. I believe you are saying that the Metrics ID specifies some minimization strategies and are asking if we should add additional strategies for 1) latency and 2) link reliability. That's right. This document specifies the list of metric used by RPL to build the DAG (parent selection). As for latency, I am presuming this would be analogous to a QoS strategy. That is move packets from point 'a' to point 'b' in the minimal amount of time. The Building Requirements called out a QoS requirement to assure high priority packets (e.g. Fire Alarms) could traverse the LLN faster than other messages. Yes, I would just like to clarify something here. We are not discussing QoS, which strictly speaking refers to the set of mechanisms used along the forwarding path (scheduling, congestion management such as RED, ...) once the path is computed. For example, you could compute the DAG based on a reliability metrics and provide differentiated QoS to traffic forwarded along this path. The question here is whether we should use a QoS metric to build the DAG and if yes what should be the metric. Several IETF ago, we agreed that queueing delays were not a good idea due to their high fluctuation. Furthermore, it does not make much sense when nodes have 1 packet buffer ... This is why the proposal was here to use latency in order to reflect the MAC latency, which may indeed vary by an order of magnitude. As for Link Reliability, I also vote 'yes'. I am presume that Link Reliability is akin to ETX. That is moving packets from point 'a' to point 'b' with the best possible change of success of arrival with no errors. Right. In the implementations that you deployed, did you use such "QoS" and reliability metric ? In which units ? Thanks. JP. So I think I have answered your questions. If not, please let me know. Jerry JP Vasseur Sent by: roll-bounces@ietf.org 10/07/2009 01:08 PM To IETF ROLL cc Kris Pister Subject [Roll] RPL Metric ID Dear all, We would appreciate your feed-back on RPL routing metrics. Now that RPL is stabilizing it is time to move forward with the METRIC I-D. The next revision will be a major one, with packet encoding, processing rules, etc. We discussed and agreed some time ago on several links and nodes metrics (also required according to our requirement IDs). Still, there are a few metrics for which we would like to know whether you think that they should be specified. 4.2. Latency As with throughput, the latency of many LLN MAC sub-layers can be varied over many orders of magnitude, again with a corresponding change in current consumption. Some LLN MACs will allow the latency to be adjusted globally on the subnet, or on a link-by-link basis, or not at all. Some will insist that it be fixed for a given link, but allow it to be variable from link to link. For efficient operation, nodes must be able to report the range of latency that their links can handle, and the currently available latency. 4.3. Link reliability In LLNs, link reliability is degraded by external interference and multi-path interference. Multipath typically affects both directions on the link equally, whereas external interference is sometimes uni- directional. Time scales vary from milliseconds to days, and are often periodic and linked to human activity. Packet error rate can generally be measured directly, and other metrics (e.g. bit error rate, mean time between failures) are typically derived from that. In addition: Node Memory resources: Memory is a critical node resources in presence of constrained nodes. Is there a need to report node memory resources as a routing metric/constraint ? Node CPU resources: CPU duty cycle for virtually all LLN applications to date is well below 10%, and the trend in low power embedded systems is to more capable processors rather than less. Computational speed is not expected to be a limiting factor in routing in LLNs. Is there a need to report node CPU resources as a routing metric/constraint ? Link Security metrics Thanks for your feed-back. JP, Mijeon, Kris._______________________________________________ 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 --=_alternative 004933B886257649_= Content-Type: text/html; charset="US-ASCII"

JP,

Thanks for the response.

Per your question, our current implementation uses standard ZigBee algorithms.  ZigBee bases path costs on RSSI only.  While nice and simple; unfortunately we feel this approach doesn't necessarily pick the best communication paths, only the ones that have a strong signal.  Mukul did a lot of simulation work for us on this and helped drive us to this conclusion.

Our product was developed and deployed in 2006.  We used what is termed the 'ZigBee 2006 Stack'.  Since that time, ZigBee has developed the 'ZigBee PRO' stack which will in time subsume the ZigBee Stack.  ZigBee PRO selects paths based on the best symmetric path found.  I believe asymmetric paths are discarded or only used as a last resort.  Unfortunately, I have no empirical or simulation data on this metric.  Maybe Richard can provide some insight on this approach since I believe it was championed by Ember.

Jerry



JP Vasseur <jvasseur@cisco.com>

10/08/2009 12:53 AM

To
Jerald.P.Martocci@jci.com
cc
IETF ROLL <roll@ietf.org>, Kris Pister <kpister@dustnetworks.com>, "???[??????]" <mjkim@kt.com>
Subject
Re: [Roll] RPL Metric ID





Hi Jerry,

On Oct 7, 2009, at 9:51 PM, Jerald.P.Martocci@jci.com wrote:


JP,

I am not sure what you're asking, but I 'll hazard a guess.  Let me know if my comments make sense.

I believe you are saying that the Metrics ID specifies some minimization strategies and are asking if we should add additional strategies for 1) latency and 2) link reliability.


That's right. This document specifies the list of metric used by RPL to build the DAG (parent selection).

As for latency, I am presuming this would be analogous to a QoS strategy.  That is move packets from point 'a'  to point 'b' in the minimal amount of time.  The Building Requirements called out a QoS requirement to assure high priority packets (e.g. Fire Alarms) could traverse the LLN faster than other messages.


Yes, I would just like to clarify something here. We are not discussing QoS, which strictly speaking refers to the set of mechanisms used along the forwarding path (scheduling, congestion management such as RED, ...) once the path is computed. For example, you could compute the DAG based on a reliability metrics and provide differentiated QoS to traffic forwarded along this path.

The question here is whether we should use a QoS metric to build the DAG and if yes what should be the metric. Several IETF ago, we agreed that queueing delays were not a good idea due to their high fluctuation. Furthermore, it does not make much sense when nodes have 1 packet buffer ...

This is why the proposal was here to use latency in order to reflect the MAC latency, which may indeed vary by an order of magnitude.

As for Link Reliability, I also vote 'yes'.  I am presume that Link Reliability is akin to ETX.  That is moving packets from point 'a' to point 'b' with the best possible change of success of arrival with no errors.

Right.

In the implementations that you deployed, did you use such "QoS" and reliability metric ? In which units ?

Thanks.

JP.



So I think I have answered your questions.  If not, please let me know.

Jerry



<mime-attachment.jpeg>

JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

10/07/2009 01:08 PM


To
IETF ROLL <roll@ietf.org>
cc
Kris Pister <kpister@dustnetworks.com>
Subject
[Roll] RPL Metric ID







Dear all,

We would appreciate your feed-back on RPL routing metrics.

Now that RPL is stabilizing it is time to move forward with the METRIC I-D. The next revision will be a major one, with packet encoding, processing rules, etc.

We discussed and agreed some time ago on several links and nodes metrics (also required according to our requirement IDs).

Still, there are a few metrics for which we would like to know whether you think that they should be specified.

4.2.  Latency

  As with throughput, the latency of many LLN MAC sub-layers can be
  varied over many orders of magnitude, again with a corresponding
  change in current consumption.  Some LLN MACs will allow the latency
  to be adjusted globally on the subnet, or on a link-by-link basis, or
  not at all.  Some will insist that it be fixed for a given link, but
  allow it to be variable from link to link.  For efficient operation,
  nodes must be able to report the range of latency that their links
  can handle, and the currently available latency.

4.3.  Link reliability

  In LLNs, link reliability is degraded by external interference and
  multi-path interference.  Multipath typically affects both directions
  on the link equally, whereas external interference is sometimes uni-
  directional.  Time scales vary from milliseconds to days, and are
  often periodic and linked to human activity.  Packet error rate can
  generally be measured directly, and other metrics (e.g. bit error
  rate, mean time between failures) are typically derived from that.

In addition:

Node Memory resources:

Memory is a critical node resources in presence of constrained nodes. Is there a need to report node memory resources as a routing metric/constraint ?

Node CPU resources:
CPU duty cycle for virtually all LLN applications to date is well below 10%, and the trend in low power embedded systems is to more capable processors rather than less. Computational speed is not expected to be a limiting factor in routing in LLNs. Is there a need to report node CPU resources as a routing metric/constraint ?

Link Security metrics

Thanks for your feed-back.

JP, Mijeon, Kris._______________________________________________
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

--=_alternative 004933B886257649_=-- From jvasseur@cisco.com Thu Oct 8 07:09:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B5023A689E for ; Thu, 8 Oct 2009 07:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.824 X-Spam-Level: X-Spam-Status: No, score=-9.824 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3p1OZ97auGV for ; Thu, 8 Oct 2009 07:09:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 38D2B3A693A for ; Thu, 8 Oct 2009 07:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=19030; q=dns/txt; s=amsiport01001; t=1255011085; x=1256220685; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Thu,=208=20Oct=20 2009=2016:10:42=20+0200|Message-Id:=20<50BD53A1-952E-4BFA -B68B-4943292F1364@cisco.com>|To:=20"jerald.p.martocci@jc i.com=20Martocci"=20,=0D=0A=20 =20=20=20=20=20=20=20Richard=20Kelsey=20|Cc:=20Kris=20Pister=20,=20"???[??????]"=20,=0D=0A=20=20=20=20=20 =20=20=20IETF=20ROLL=20|Mime-Version:=201. 0=20(Apple=20Message=20framework=20v936)|In-Reply-To:=20< OF2195F88E.78EDA444-ON86257649.00483AA6-86257649.004933EB @jci.com>|References:=20; bh=7Gcxbe9DUUvjbN17xXhiLA/gpfXShylpLyzmIjJjfn8=; b=PkEqo1t+OltyTqAzbO9fCeOXEMGX7VHmEfni6VG/vUEzq98eKFsrE3sq +DDjayKW6UHRVeW5SfUQXzXYDbmazhoVTfrbVa2mhVJnqUa61ooMKvYOZ XxDbj/7HiTMhJ87FBCEbe3haiNfp91WOovfr8jF3Zl32Bl+a3GCNqVk7f s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMAAJePzUqQ/uCWe2dsb2JhbACCJi8hmAoBARYkBqZzmBqCJoIEBA X-IronPort-AV: E=Sophos;i="4.44,525,1249257600"; d="scan'208,217";a="51287595" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 08 Oct 2009 14:11:23 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n98EBN4x006935; Thu, 8 Oct 2009 14:11:23 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 16:11:22 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 16:11:22 +0200 Message-Id: <50BD53A1-952E-4BFA-B68B-4943292F1364@cisco.com> From: JP Vasseur To: "jerald.p.martocci@jci.com Martocci" , Richard Kelsey In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-361--321547556 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 16:10:42 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 08 Oct 2009 14:11:22.0208 (UTC) FILETIME=[36AF9E00:01CA4821] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16934.007 X-TM-AS-Result: No--28.718700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 14:09:45 -0000 --Apple-Mail-361--321547556 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Oct 8, 2009, at 3:19 PM, Jerald.P.Martocci@jci.com wrote: > > > JP, > > Thanks for the response. > > Per your question, our current implementation uses standard ZigBee > algorithms. ZigBee bases path costs on RSSI only. While nice and > simple; unfortunately we feel this approach doesn't necessarily pick > the best communication paths, only the ones that have a strong > signal. Mukul did a lot of simulation work for us on this and > helped drive us to this conclusion. I see, thanks. At least you will get a reliability metric. > > Our product was developed and deployed in 2006. We used what is > termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has > developed the 'ZigBee PRO' stack which will in time subsume the > ZigBee Stack. ZigBee PRO selects paths based on the best symmetric > path found. I believe asymmetric paths are discarded or only used > as a last resort. Unfortunately, I have no empirical or simulation > data on this metric. Maybe Richard can provide some insight on this > approach since I believe it was championed by Ember. Richard ? Thanks Jerry. JP. > > Jerry > > > > JP Vasseur > 10/08/2009 12:53 AM > > To > Jerald.P.Martocci@jci.com > cc > IETF ROLL , Kris Pister , > "???[??????]" > Subject > Re: [Roll] RPL Metric ID > > > > > > Hi Jerry, > > On Oct 7, 2009, at 9:51 PM, Jerald.P.Martocci@jci.com wrote: > > > JP, > > I am not sure what you're asking, but I 'll hazard a guess. Let me > know if my comments make sense. > > I believe you are saying that the Metrics ID specifies some > minimization strategies and are asking if we should add additional > strategies for 1) latency and 2) link reliability. > > > That's right. This document specifies the list of metric used by RPL > to build the DAG (parent selection). > > As for latency, I am presuming this would be analogous to a QoS > strategy. That is move packets from point 'a' to point 'b' in the > minimal amount of time. The Building Requirements called out a QoS > requirement to assure high priority packets (e.g. Fire Alarms) could > traverse the LLN faster than other messages. > > > Yes, I would just like to clarify something here. We are not > discussing QoS, which strictly speaking refers to the set of > mechanisms used along the forwarding path (scheduling, congestion > management such as RED, ...) once the path is computed. For example, > you could compute the DAG based on a reliability metrics and provide > differentiated QoS to traffic forwarded along this path. > > The question here is whether we should use a QoS metric to build the > DAG and if yes what should be the metric. Several IETF ago, we > agreed that queueing delays were not a good idea due to their high > fluctuation. Furthermore, it does not make much sense when nodes > have 1 packet buffer ... > > This is why the proposal was here to use latency in order to reflect > the MAC latency, which may indeed vary by an order of magnitude. > > As for Link Reliability, I also vote 'yes'. I am presume that Link > Reliability is akin to ETX. That is moving packets from point 'a' > to point 'b' with the best possible change of success of arrival > with no errors. > > Right. > > In the implementations that you deployed, did you use such "QoS" and > reliability metric ? In which units ? > > Thanks. > > JP. > > > > So I think I have answered your questions. If not, please let me > know. > > Jerry > > > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 10/07/2009 01:08 PM > > > To > IETF ROLL > cc > Kris Pister > Subject > [Roll] RPL Metric ID > > > > > > > > Dear all, > > We would appreciate your feed-back on RPL routing metrics. > > Now that RPL is stabilizing it is time to move forward with the > METRIC I-D. The next revision will be a major one, with packet > encoding, processing rules, etc. > > We discussed and agreed some time ago on several links and nodes > metrics (also required according to our requirement IDs). > > Still, there are a few metrics for which we would like to know > whether you think that they should be specified. > > 4.2. Latency > > As with throughput, the latency of many LLN MAC sub-layers can be > varied over many orders of magnitude, again with a corresponding > change in current consumption. Some LLN MACs will allow the latency > to be adjusted globally on the subnet, or on a link-by-link basis, > or > not at all. Some will insist that it be fixed for a given link, but > allow it to be variable from link to link. For efficient operation, > nodes must be able to report the range of latency that their links > can handle, and the currently available latency. > > 4.3. Link reliability > > In LLNs, link reliability is degraded by external interference and > multi-path interference. Multipath typically affects both > directions > on the link equally, whereas external interference is sometimes uni- > directional. Time scales vary from milliseconds to days, and are > often periodic and linked to human activity. Packet error rate can > generally be measured directly, and other metrics (e.g. bit error > rate, mean time between failures) are typically derived from that. > > In addition: > > Node Memory resources: > > Memory is a critical node resources in presence of constrained > nodes. Is there a need to report node memory resources as a routing > metric/constraint ? > > Node CPU resources: > CPU duty cycle for virtually all LLN applications to date is well > below 10%, and the trend in low power embedded systems is to more > capable processors rather than less. Computational speed is not > expected to be a limiting factor in routing in LLNs. Is there a need > to report node CPU resources as a routing metric/constraint ? > > Link Security metrics > > Thanks for your feed-back. > > JP, Mijeon, Kris._______________________________________________ > 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 > --Apple-Mail-361--321547556 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Oct 8, 2009, at 3:19 PM, Jerald.P.Martocci@jci.com = wrote:



JP, =

Thanks for the = response.

Per your = question, our current implementation uses standard ZigBee algorithms. =  ZigBee bases path costs on RSSI only.  While nice and simple; = unfortunately we feel this approach doesn't necessarily pick the best = communication paths, only the ones that have a strong signal. =  Mukul did a lot of simulation work for us on this and helped drive = us to this conclusion.

I = see, thanks. At least you will get a reliability = metric.


Our product was developed and deployed in 2006. =  We used what is termed the 'ZigBee 2006 Stack'.  Since that = time, ZigBee has developed the 'ZigBee PRO' stack which will in time = subsume the ZigBee Stack.  ZigBee PRO selects paths based on the = best symmetric path found.  I believe asymmetric paths are = discarded or only used as a last resort.  Unfortunately, I have no = empirical or simulation data on this metric.  Maybe Richard can = provide some insight on this approach since I believe it was championed = by Ember.

Richard = ?

Thanks = Jerry.

JP.

=
Jerry


=
JP Vasseur <jvasseur@cisco.com> =

10/08/2009 12:53 = AM

To
Jerald.P.Martocci@jci.com
cc
IETF ROLL <roll@ietf.org>, Kris Pister <kpister@dustnetworks.com>,= "???[??????]" <mjkim@kt.com>
Subject
Re: [Roll] RPL Metric = ID

=



Hi = Jerry,

On Oct 7, 2009, at 9:51 PM, = Jerald.P.Martocci@jci.com wrote:


JP,

I am not sure what you're asking, = but I 'll hazard a guess.  Let me know if my comments make = sense.

I believe you are saying that the Metrics ID = specifies some minimization strategies and are asking if we should add = additional strategies for 1) latency and 2) link = reliability.


That's right. This document specifies the list of metric used = by RPL to build the DAG (parent selection).

As for latency, I am presuming this would = be analogous to a QoS strategy.  That is move packets from point = 'a'  to point 'b' in the minimal amount of time.  The Building = Requirements called out a QoS requirement to assure high priority = packets (e.g. Fire Alarms) could traverse the LLN faster than other = messages.


Yes, I would just like to clarify something here. We are not = discussing QoS, which strictly speaking refers to the set of mechanisms = used along the forwarding path (scheduling, congestion management such = as RED, ...) once the path is computed. For example, you could compute = the DAG based on a reliability metrics and provide differentiated QoS to = traffic forwarded along this path.

The = question here is whether we should use a QoS metric to build the DAG and = if yes what should be the metric. Several IETF ago, we agreed that = queueing delays were not a good idea due to their high fluctuation. = Furthermore, it does not make much sense when nodes have 1 packet buffer = ...

This is why the proposal was here = to use latency in order to reflect the MAC latency, which may indeed = vary by an order of magnitude.

As for Link Reliability, I also vote 'yes'.  I = am presume that Link Reliability is akin to ETX.  That is moving = packets from point 'a' to point 'b' with the best possible change of = success of arrival with no errors.

Right.=

In the implementations that you = deployed, did you use such "QoS" and reliability metric ? In which units = ?

Thanks.

JP.



So I think I have answered your = questions.  If not, please let me know. =

Jerry


=
<mime-attachment.jpeg>

=
JP Vasseur = <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

10/07/2009 01:08 PM=


=
To
IETF ROLL = <roll@ietf.org> =
cc
Kris Pister <kpister@dustnetworks.com> =
Subject
[Roll] RPL Metric = ID


=

=



Dear all,

We would = appreciate your feed-back on RPL routing metrics.

Now that RPL = is stabilizing it is time to move forward with the METRIC I-D. The next = revision will be a major one, with packet encoding, processing rules, = etc.

We discussed and agreed some time ago on several links = and nodes metrics (also required according to our requirement IDs).
=
Still, there are a few metrics for which we would like to know = whether you think that they should be specified.

4.2. =  Latency

  As with throughput, the latency of = many LLN MAC sub-layers can be
  varied over many = orders of magnitude, again with a corresponding
  = change in current consumption.  Some LLN MACs will allow the = latency
  to be adjusted globally on the subnet, or on = a link-by-link basis, or
  not at all.  Some will = insist that it be fixed for a given link, but
  allow = it to be variable from link to link.  For efficient operation, =
  nodes must be able to report the range of latency that = their links
  can handle, and the currently available = latency.

4.3.  Link reliability

=   In LLNs, link reliability is degraded by external interference = and
  multi-path interference.  Multipath = typically affects both directions
  on the link = equally, whereas external interference is sometimes uni-
=   directional.  Time scales vary from milliseconds to days, = and are
  often periodic and linked to human activity. =  Packet error rate can
  generally be measured = directly, and other metrics (e.g. bit error
  rate, = mean time between failures) are typically derived from that.
=
In addition:

Node Memory resources:

= Memory is a critical node resources in presence of constrained nodes. Is = there a need to report node memory resources as a routing = metric/constraint ?

Node CPU resources:
CPU duty = cycle for virtually all LLN applications to date is well below 10%, and = the trend in low power embedded systems is to more capable processors = rather than less. Computational speed is not expected to be a limiting = factor in routing in LLNs. Is there a need to report node CPU resources = as a routing metric/constraint ?

Link Security metrics =

Thanks for your feed-back.

JP, Mijeon, = Kris._______________________________________________
Roll = mailing list
= Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= /font>

= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
=

= --Apple-Mail-361--321547556-- From alexandru.petrescu@gmail.com Thu Oct 8 07:17:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C4028C191 for ; Thu, 8 Oct 2009 07:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.025 X-Spam-Level: X-Spam-Status: No, score=-0.025 tagged_above=-999 required=5 tests=[AWL=-1.801, BAYES_20=-0.74, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2ms+99oN5I9 for ; Thu, 8 Oct 2009 07:17:11 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 7305028C1FB for ; Thu, 8 Oct 2009 07:17:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n98EIkib001634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Oct 2009 16:18:46 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n98EIk0m032391; Thu, 8 Oct 2009 16:18:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n98EIkOZ025881; Thu, 8 Oct 2009 16:18:46 +0200 Message-ID: <4ACDF4C6.5020109@gmail.com> Date: Thu, 08 Oct 2009 16:18:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 14:17:12 -0000 Hi JP, I am attracted by the subject of the mail, it is about Metric I-D (Internet Draft). However, I am not sure what are you asking for? Please see below feedback I'm interested in. JP Vasseur a écrit : > Dear all, > > We would appreciate your feed-back on RPL routing metrics. > > Now that RPL is stabilizing it is time to move forward with the METRIC > I-D. The next revision will be a major one, with packet encoding, > processing rules, etc. > > We discussed and agreed some time ago on several links and nodes metrics > (also required according to our requirement IDs). I really am not sure there was agreement on the link metrics. I suggested several times a way to encode the link metrics and there didn't seem to be universal agreement, only some. I still suggest to have link metrics taken into account by ICMP, routing protocols _and_ RPL. These link metrics would express the energy needed to send a certain amount of bytes on a certain interface, or on a certain path. The exression would be made in Joules, as single-precision 32bit floats, with two values: min and max. Like this: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Max Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Min Link Energy | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Type: > > TBA (see [ICMPv6parms]) > > Energy Metric Option for IPv6 Link. > > Length: > > Decimal 10. > > > Reserved: > > Set to zero by sender and ignored by receiver. > > > Max Link Energy > > Single-precision 32bit floating point number in binary > interchange format (see [IEEE754-2008] and [IEC60559-2.0]), a > C 'float' type (see [ISOIEC-C99]), and in network byte order. > The value represents the maximum energy, expressed in Joules, > necessary to send a packet of size 1280 bytes on this link. > > Min Link Energy > > Single-precision floating point number representing the > minimum energy, expressed in Joules, necessary to send 1280 > bytes on this link. Alex From prvs=525560042=mukul@uwm.edu Thu Oct 8 07:58:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50B4028C286 for ; Thu, 8 Oct 2009 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40f-rFyCJ+KV for ; Thu, 8 Oct 2009 07:58:04 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id B2C9F28C277 for ; Thu, 8 Oct 2009 07:58:03 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 08 Oct 2009 09:59:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 02523C085E1; Thu, 8 Oct 2009 09:59:40 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCIEENiW4bQC; Thu, 8 Oct 2009 09:59:39 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7F42BC085E0; Thu, 8 Oct 2009 09:59:39 -0500 (CDT) Date: Thu, 8 Oct 2009 09:59:39 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <1365080139.15840341255013979397.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <942252777.15804511255010677788.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 14:58:05 -0000 JP If we want to use ETX as the reliability metric, it should be ETX at the network layer. It should be related to the packet loss rate L (as observed by the network layer) as follows: ETX = 1/(1-L). I dont really have preferences for the latency. I may have objections if you have some preferences. :) Mukul ----- Original Message ----- From: "JP Vasseur" To: "Mukul Goyal" Cc: "Kris Pister" , "IETF ROLL" Sent: Thursday, October 8, 2009 12:52:27 AM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL Metric ID Hi Mukul, On Oct 7, 2009, at 9:40 PM, Mukul Goyal wrote: > I think both latency and reliability are important metrics. > OK thanks for the feed-backs. The most obvious and common reliability is ETX. Any preference for the latency? > I am sort of negative on using memory/CPU availability as metric or > constraint. They seem like local factors to me. If a node is running > low on memory/CPU, it can simply not participate in routing. And we already have an "overload" bit. Thanks. JP. > > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "IETF ROLL" > Cc: "Kris Pister" > Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada > Central > Subject: [Roll] RPL Metric ID > > > Dear all, > > > We would appreciate your feed-back on RPL routing metrics. > > > Now that RPL is stabilizing it is time to move forward with the > METRIC I-D. The next revision will be a major one, with packet > encoding, processing rules, etc. > > > We discussed and agreed some time ago on several links and nodes > metrics (also required according to our requirement IDs). > > > Still, there are a few metrics for which we would like to know > whether you think that they should be specified. > > > 4.2. Latency > > > > As with throughput, the latency of many LLN MAC sub-layers can be > varied over many orders of magnitude, again with a corresponding > change in current consumption. Some LLN MACs will allow the > latency > to be adjusted globally on the subnet, or on a link-by-link > basis, or > not at all. Some will insist that it be fixed for a given link, > but > allow it to be variable from link to link. For efficient > operation, > nodes must be able to report the range of latency that their links > can handle, and the currently available latency. > > > 4.3. Link reliability > > > In LLNs, link reliability is degraded by external interference and > multi-path interference. Multipath typically affects both > directions > on the link equally, whereas external interference is sometimes > uni- > directional. Time scales vary from milliseconds to days, and are > often periodic and linked to human activity. Packet error rate can > generally be measured directly, and other metrics (e.g. bit error > rate, mean time between failures) are typically derived from that. > > > In addition: > > > Node Memory resources: > > > Memory is a critical node resources in presence of constrained > nodes. Is there a need to report node memory resources as a routing > metric/constraint ? > > > Node CPU resources: > CPU duty cycle for virtually all LLN applications to date is well > below 10%, and the trend in low power embedded systems is to more > capable processors rather than less. Computational speed is not > expected to be a limiting factor in routing in LLNs. Is there a need > to report node CPU resources as a routing metric/constraint ? > > > Link Security metrics > > > Thanks for your feed-back. > > > JP, Mijeon, Kris. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Thu Oct 8 08:03:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D68E28C29A for ; Thu, 8 Oct 2009 08:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rMAJlZmUVFp for ; Thu, 8 Oct 2009 08:03:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6E0D928C28E for ; Thu, 8 Oct 2009 08:03:08 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Oct 2009 11:05:53 -0400 Date: Thu, 08 Oct 2009 11:03:22 -0400 Message-Id: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> To: Jerald.P.Martocci@jci.com In-reply-to: (Jerald.P.Martocci@jci.com) From: Richard Kelsey References: X-OriginalArrivalTime: 08 Oct 2009 15:05:53.0973 (UTC) FILETIME=[D4CF5650:01CA4828] Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 15:03:09 -0000 Jerry, From: Jerald.P.Martocci@jci.com Date: Thu, 8 Oct 2009 08:19:33 -0500 Per your question, our current implementation uses standard ZigBee algorithms. ZigBee bases path costs on RSSI only. No, ZigBee's path costs are based on the probability of packet reception over the link. See Section 3.6.3.1 of the ZigBee spec. RSSI above the noise floor could be used to estimate that probability, of course. Raw RSSI doesn't tell you very much. Our product was developed and deployed in 2006. We used what is termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has developed the 'ZigBee PRO' stack which will in time subsume the ZigBee Stack. ZigBee PRO selects paths based on the best symmetric path found. I believe asymmetric paths are discarded or only used as a last resort. Not quite. ZigBee PRO only requires that the cost assigned to an asymmetric link be the worse of the two unidirectional costs. Unfortunately, I have no empirical or simulation data on this metric. Maybe Richard can provide some insight on this approach since I believe it was championed by Ember. Ember and Mitsubishi proposed the solution that was adopted (exchanging link costs with neighbors). The actual problem that it solved was first raised by Ghulam Bhatti of Mitsubishi, if I remember correctly. Under certain circumstances having the two ends of a link use different costs could cause ZigBee's P2P routing to consistently fail to discover a route. The problem was fairly fundamental to ZigBee's P2P mechanism, and given the other advantages of identifying asymmetries and knowing more about your local neighborhood, ZigBee added a feature where nodes inform their neighbors of their link costs. This seems like something that could be done at the link layer. -Richard Kelsey From pal@cs.stanford.edu Thu Oct 8 09:07:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0195E28C2B4 for ; Thu, 8 Oct 2009 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pATjT5Ri8pSk for ; Thu, 8 Oct 2009 09:07:27 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 11FBB28C1B2 for ; Thu, 8 Oct 2009 09:07:27 -0700 (PDT) Received: from dnab4222bb.stanford.edu ([171.66.34.187]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MvvYC-0002vA-PN; Thu, 08 Oct 2009 09:09:09 -0700 Message-Id: <0E985639-0382-47B6-9F89-50C7CFA28CAD@cs.stanford.edu> From: Philip Levis To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Oct 2009 09:08:40 -0700 References: X-Mailer: Apple Mail (2.936) X-Scan-Signature: 323acaff36744e8473855e70acc36bcb Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 08 Oct 2009 16:07:28 -0000 On Oct 8, 2009, at 6:19 AM, Jerald.P.Martocci@jci.com wrote: > > > JP, > > Thanks for the response. > > Per your question, our current implementation uses standard ZigBee > algorithms. ZigBee bases path costs on RSSI only. While nice and > simple; unfortunately we feel this approach doesn't necessarily pick > the best communication paths, only the ones that have a strong > signal. Mukul did a lot of simulation work for us on this and > helped drive us to this conclusion. Path selection based purely on RSSI (or any other PHY parameter) also suffers from biased sampling. It could be that all received packets have a high RSSI, but only half the packets are received. Interference (high I, leading to low SINR on some packets) or highly variable channels (high variance in S, leading to low SINR on some packets) can cause this. The result is a protocol uses poor paths because it doesn't know better[1]. Note that this kind of behavior typically doesn't show up in simulation, as most simulators limit themselves to gaussian-based analytical models of the channel and don't consider external interference. The standard solution is to use link-layer delivery rates to supplement the physical layer parameters. E.g., one can try another path after a few failures[2] or use link layer delivery rates to dynamically calculate costs[3]. > > Our product was developed and deployed in 2006. We used what is > termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has > developed the 'ZigBee PRO' stack which will in time subsume the > ZigBee Stack. ZigBee PRO selects paths based on the best symmetric > path found. I believe asymmetric paths are discarded or only used > as a last resort. Unfortunately, I have no empirical or simulation > data on this metric. Maybe Richard can provide some insight on this > approach since I believe it was championed by Ember. For a path to be asymmetric, it must have at least one asymmetric link. My experience is that asymmetric links are of limited use for LLNs. Because LLNs are lossy, they tend to have single-hop acknowledgment schemes, either at the link layer or at the network layer. Single-hop acknowledgments don't work well in asymmetric links. Yes, the acknowledgments are shorter and so the ARR (acknowledgment reception rate) can be higher than the PRR (packet reception rate), but this window is so narrow and the complexity needed to use it is significant enough that asymmetric links are more an intellectual curiosity rather than something of significant value to exploit. Phil [1] R. Fonseca, O. Gnawali, K. Jamieson, and P. Levis. "Four Bit Wireless Link Estimation." In the Proceedings of the 6th Workshop on Hot Topics in Networking (HotNets-VI), 2007. [2] J. Hui and D. Culler. "IP is dead, long live IP for wireless sensor networks." In the 6th ACM Conference on Embedded Networked Sensor Systems (SenSys), 2008. [3] O. Gnawali, R. Fonseca, K. Jamieson, D. Moss and P. Levis. "Collection Tree Protocol." To appear in the 7th ACM Conference on Embedded Networked Sensor Systems (SenSys), 2009. From jvasseur@cisco.com Fri Oct 9 02:34:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D697F3A67E5 for ; Fri, 9 Oct 2009 02:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.751 X-Spam-Level: X-Spam-Status: No, score=-6.751 tagged_above=-999 required=5 tests=[AWL=-2.318, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5Sv+2QiG3vf for ; Fri, 9 Oct 2009 02:34:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BC27C3A698F for ; Fri, 9 Oct 2009 02:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3445; q=dns/txt; s=sjiport01001; t=1255080963; x=1256290563; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Fri,=209=20Oct=20 2009=2011:35:58=20+0200|Message-Id:=20<42382722-B852-4B20 -A3D3-4C2E4C4FF871@cisco.com>|To:=20Alexandru=20Petrescu =20|Cc:=20IETF=20ROLL=20,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20v9 36)|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4ACDF4C6.5020109@gmail.com>|References: =20=20<4A CDF4C6.5020109@gmail.com>; bh=SKD23irnL45thyE3JvL8CShAT/BNWom6QG+4rXvS3T8=; b=VgCuCDA3fYgOI00ndNIvbkr2/SxN9rhiyfcAVzI4RuIoTKTyxEGTNlcn d/+5oUgOGO27YjfU/AHeQdA8K9NfbjVxb2j78y0ZdlqeWKNWCcwgsHsok zQIkYftBkKt25lv2tu7OqerginJEc5+x4yfiyf4uQQjB1a6Pi/tZCT5lI 4=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKOgzkqrR7Ht/2dsb2JhbADCJIkQCI8sgkMIgV8EgVg X-IronPort-AV: E=Sophos;i="4.44,531,1249257600"; d="scan'208";a="253413022" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2009 09:36:03 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n999Znqj013688; Fri, 9 Oct 2009 09:36:02 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:35:59 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:35:59 +0200 Message-Id: <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4ACDF4C6.5020109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 11:35:58 +0200 References: <4ACDF4C6.5020109@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Oct 2009 09:35:59.0197 (UTC) FILETIME=[E89DF8D0:01CA48C3] Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 09:34:19 -0000 Hi Alex, On Oct 8, 2009, at 4:18 PM, Alexandru Petrescu wrote: > Hi JP, > > I am attracted by the subject of the mail, it is about Metric I-D =20 > (Internet Draft). However, I am not sure what are you asking for? Which metric should be defined for RPL (link and node). Note that we =20 have several metrics already defined, but still a few TBD. > Please see below feedback I'm interested in. > > JP Vasseur a =E9crit : >> Dear all, >> We would appreciate your feed-back on RPL routing metrics. >> Now that RPL is stabilizing it is time to move forward with the =20 >> METRIC I-D. The next revision will be a major one, with packet =20 >> encoding, processing rules, etc. >> We discussed and agreed some time ago on several links and nodes =20 >> metrics (also required according to our requirement IDs). > > I really am not sure there was agreement on the link metrics. I =20 > suggested several times a way to encode the link metrics and there =20 > didn't seem to be universal agreement, only some. > > I still suggest to have link metrics taken into account by ICMP, =20 > routing protocols _and_ RPL. Not sure why you refer to ICMP here but back to RPL ... > These link metrics would express the energy needed to send a certain =20= > amount of bytes on a certain interface, or on a certain path. The =20 > exression would be made in Joules, as single-precision 32bit floats, =20= > with two values: min and max. Like this: > Yes I do remember the discussion ... but I cannot see how this would =20 be helpful. Indeed, even if a node receives two RA-DIO messages from =20 parents that reports path-1 with energy G1 and path-2 with energy G2 =20 (we can discuss the packet format later on), in which way would that =20 help in the path selection process? It might very well be that the =20 past that consumes the most energy is to the one that is preferable ? Thanks. JP. >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Max Link Energy | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Min Link Energy | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Type: >> TBA (see [ICMPv6parms]) >> Energy Metric Option for IPv6 Link. >> Length: >> Decimal 10. >> Reserved: >> Set to zero by sender and ignored by receiver. >> Max Link Energy >> Single-precision 32bit floating point number in binary >> interchange format (see [IEEE754-2008] and =20 >> [IEC60559-2.0]), a >> C 'float' type (see [ISOIEC-C99]), and in network byte =20 >> order. >> The value represents the maximum energy, expressed in =20 >> Joules, >> necessary to send a packet of size 1280 bytes on this link. >> Min Link Energy >> Single-precision floating point number representing the >> minimum energy, expressed in Joules, necessary to send 1280 >> bytes on this link. > > Alex > > From jvasseur@cisco.com Fri Oct 9 02:40:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896403A6867 for ; Fri, 9 Oct 2009 02:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.806 X-Spam-Level: X-Spam-Status: No, score=-7.806 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qosHMzhydgxT for ; Fri, 9 Oct 2009 02:40:48 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F153B3A672F for ; Fri, 9 Oct 2009 02:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3035; q=dns/txt; s=sjiport01001; t=1255081352; x=1256290952; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Fri,=209=20Oct=20 2009=2011:42:26=20+0200|Message-Id:=20|To:=20Richard=20Kelsey=20|Cc:=20Jerald.P.Martocci@jci.com, =20roll@ietf.org,=20kpister@dustnetworks.com |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20<87lj jmapxh.fsf@kelsey-ws.hq.ember.com>|References:=20=20<87ljjmapxh.fsf@kelsey-ws.hq.ember.com>; bh=eBuguf3q+elj+qTSpzDQqQCj6gcGf2ppEcZ+kX9KtIs=; b=eh/RhM+HtCXY8H6PJgxCBq20Iw7flC1axeqC68NrwKONY/KxbTDBGk5z V2cXEv+s+41NNVRCWRiOvxm2jyGB7ZR3wXzaEVP0+68Ds7RvIbYmZl9NH 79MsrWBzMyVhxZ/qROJTrVZN6Bho2FcPnuywmxWeq7eXRhKAxuAFC6Vni Y=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPuizkqrR7H+/2dsb2JhbADCGIkQCI8sgkMIgV8E X-IronPort-AV: E=Sophos;i="4.44,531,1249257600"; d="scan'208";a="253414578" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 09 Oct 2009 09:42:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n999gPfj018712; Fri, 9 Oct 2009 09:42:32 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:42:28 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:42:27 +0200 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 11:42:26 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Oct 2009 09:42:27.0764 (UTC) FILETIME=[D0389740:01CA48C4] Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 09:40:49 -0000 Hi Richard, On Oct 8, 2009, at 5:03 PM, Richard Kelsey wrote: > Jerry, > > From: Jerald.P.Martocci@jci.com > Date: Thu, 8 Oct 2009 08:19:33 -0500 > > Per your question, our current implementation uses standard ZigBee > algorithms. ZigBee bases path costs on RSSI only. > > No, ZigBee's path costs are based on the probability of > packet reception over the link. See Section 3.6.3.1 of the > ZigBee spec. RSSI above the noise floor could be used to > estimate that probability, of course. Raw RSSI doesn't tell > you very much. > Right. What we need to define is metric that describes the probability of packet delivery ratio along the path. Since RPL is a distance vector, we would use a cumulative metric. Of course, each node should filter out the transient error rate and periodicity of the metric update should be limited to avoid routing metric but this not specific to the reliability metric. It is true for all dynamic metrics. The objective is thus to define a cumulative reliability metric reflecting the probability of success path delivery, in units independent of the Link layer. Local mechanisms to filter out local transient phenomena are left to implementation specific decisions. Make sense ? > Our product was developed and deployed in 2006. We used what is > termed > the 'ZigBee 2006 Stack'. Since that time, ZigBee has developed the > 'ZigBee PRO' stack which will in time subsume the ZigBee Stack. > ZigBee > PRO selects paths based on the best symmetric path found. I believe > asymmetric paths are discarded or only used as a last resort. > > Not quite. ZigBee PRO only requires that the cost assigned > to an asymmetric link be the worse of the two unidirectional > costs. Makes sense. We had a discussion on this too, and it was decided not to take it into account for the time being. > > Unfortunately, I have no empirical or simulation data on this > metric. Maybe Richard can provide some insight on this approach > since I believe it was championed by Ember. > > Ember and Mitsubishi proposed the solution that was adopted > (exchanging link costs with neighbors). The actual problem > that it solved was first raised by Ghulam Bhatti of > Mitsubishi, if I remember correctly. Under certain > circumstances having the two ends of a link use different > costs could cause ZigBee's P2P routing to consistently fail > to discover a route. The problem was fairly fundamental to > ZigBee's P2P mechanism, and given the other advantages of > identifying asymmetries and knowing more about your local > neighborhood, ZigBee added a feature where nodes inform > their neighbors of their link costs. This seems like > something that could be done at the link layer. > Yes. JP. > -Richard Kelsey > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Fri Oct 9 02:44:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C8C3A67B8 for ; Fri, 9 Oct 2009 02:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.791 X-Spam-Level: X-Spam-Status: No, score=-7.791 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqka-gO6UOGy for ; Fri, 9 Oct 2009 02:44:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AC0333A672F for ; Fri, 9 Oct 2009 02:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=4310; q=dns/txt; s=sjiport05001; t=1255081598; x=1256291198; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Fri,=209=20Oct=20 2009=2011:44:35=20+0200|Message-Id:=20|To:=20Mukul=20Goyal=20|Cc:=20Kris=20Pister=20,=20IETF=20ROLL=20|Mime-Version:=201.0 =20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<136508 0139.15840341255013979397.JavaMail.root@mail02.pantherlin k.uwm.edu>|References:=20<1365080139.15840341255013979397 .JavaMail.root@mail02.pantherlink.uwm.edu>; bh=EEpFf2PV/bgC0gIbyvSp4GwyWrHZV339t0lzU5SxiGg=; b=kJ8U7Uvuc5FUC+A/3w3cYrPUZ0FPD+bElfp2CNgJOlvs/kLlFDIoegsT bxa4gbNla3a7gZY175Ih2ctA8ytO5wj4RdpIwAFIxU5y56Ci09EvQ5/Dm o6kvHlbUt/nIYXnpqmzjpHqFHrfGFXejo+3KnOt2qub7F0aE/CUAuJyY2 0=; Authentication-Results: sj-iport-5.cisco.com; dkim=pass (signature verified [TEST]) header.i=jvasseur@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMSizkqrR7PD/2dsb2JhbADCEYhkAY9ZBoImggSKQw X-IronPort-AV: E=Sophos;i="4.44,531,1249257600"; d="scan'208";a="98083086" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2009 09:46:37 +0000 Received: from rcdn-core-6.cisco.com (rcdn-core-6.cisco.com [173.37.93.157]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n999kcp7013902; Fri, 9 Oct 2009 02:46:38 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id n999kZhW003864; Fri, 9 Oct 2009 09:46:38 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:46:36 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:46:36 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <1365080139.15840341255013979397.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 11:44:35 +0200 References: <1365080139.15840341255013979397.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Oct 2009 09:46:36.0205 (UTC) FILETIME=[644DADD0:01CA48C5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4310; t=1255081598; x=1255945598; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20RPL=20Metric=20ID |Sender:=20; bh=EEpFf2PV/bgC0gIbyvSp4GwyWrHZV339t0lzU5SxiGg=; b=bNnVmgfbvo46pESlKDYTByIhhukRjCzpxNuTSNE9+5g94cbxF+lYrRyOdt 7XgwYf5HnrAn9frujevc/0yzvo5D+DKV/7o1Z+XOYDkfpQv/4JS24xtGv38X uJSbyFtDMV; Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 09:44:55 -0000 Hi Mukul, On Oct 8, 2009, at 4:59 PM, Mukul Goyal wrote: > JP > > If we want to use ETX as the reliability metric, it should be ETX at > the network layer. It should be related to the packet loss rate L > (as observed by the network layer) as follows: ETX = 1/(1-L). Yes, with some variations though since L is not always reported by the link layer (in the absence of ACK). > > I dont really have preferences for the latency. I may have > objections if you have some preferences. :) Sure ;-) Cheers. JP. > > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "Kris Pister" , "IETF ROLL" > > Sent: Thursday, October 8, 2009 12:52:27 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Metric ID > > Hi Mukul, > > On Oct 7, 2009, at 9:40 PM, Mukul Goyal wrote: > >> I think both latency and reliability are important metrics. >> > > OK thanks for the feed-backs. > The most obvious and common reliability is ETX. > Any preference for the latency? > >> I am sort of negative on using memory/CPU availability as metric or >> constraint. They seem like local factors to me. If a node is running >> low on memory/CPU, it can simply not participate in routing. > > And we already have an "overload" bit. > > Thanks. > > JP. > >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "IETF ROLL" >> Cc: "Kris Pister" >> Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada >> Central >> Subject: [Roll] RPL Metric ID >> >> >> Dear all, >> >> >> We would appreciate your feed-back on RPL routing metrics. >> >> >> Now that RPL is stabilizing it is time to move forward with the >> METRIC I-D. The next revision will be a major one, with packet >> encoding, processing rules, etc. >> >> >> We discussed and agreed some time ago on several links and nodes >> metrics (also required according to our requirement IDs). >> >> >> Still, there are a few metrics for which we would like to know >> whether you think that they should be specified. >> >> >> 4.2. Latency >> >> >> >> As with throughput, the latency of many LLN MAC sub-layers can be >> varied over many orders of magnitude, again with a corresponding >> change in current consumption. Some LLN MACs will allow the >> latency >> to be adjusted globally on the subnet, or on a link-by-link >> basis, or >> not at all. Some will insist that it be fixed for a given link, >> but >> allow it to be variable from link to link. For efficient >> operation, >> nodes must be able to report the range of latency that their links >> can handle, and the currently available latency. >> >> >> 4.3. Link reliability >> >> >> In LLNs, link reliability is degraded by external interference and >> multi-path interference. Multipath typically affects both >> directions >> on the link equally, whereas external interference is sometimes >> uni- >> directional. Time scales vary from milliseconds to days, and are >> often periodic and linked to human activity. Packet error rate can >> generally be measured directly, and other metrics (e.g. bit error >> rate, mean time between failures) are typically derived from that. >> >> >> In addition: >> >> >> Node Memory resources: >> >> >> Memory is a critical node resources in presence of constrained >> nodes. Is there a need to report node memory resources as a routing >> metric/constraint ? >> >> >> Node CPU resources: >> CPU duty cycle for virtually all LLN applications to date is well >> below 10%, and the trend in low power embedded systems is to more >> capable processors rather than less. Computational speed is not >> expected to be a limiting factor in routing in LLNs. Is there a need >> to report node CPU resources as a routing metric/constraint ? >> >> >> Link Security metrics >> >> >> Thanks for your feed-back. >> >> >> JP, Mijeon, Kris. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Fri Oct 9 02:44:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D823A67AA for ; Fri, 9 Oct 2009 02:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.777 X-Spam-Level: X-Spam-Status: No, score=-9.777 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu7mQsjIjczM for ; Fri, 9 Oct 2009 02:44:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6AC6528C0F6 for ; Fri, 9 Oct 2009 02:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=4295; q=dns/txt; s=amsiport01001; t=1255081602; x=1256291202; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Fri,=209=20Oct=20 2009=2011:46:38=20+0200|Message-Id:=20|To:=20Mukul=20Goyal=20|Cc:=20Kris=20Pister=20,=20IETF=20ROLL=20|Mime-Version:=201.0 =20(Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<136508 0139.15840341255013979397.JavaMail.root@mail02.pantherlin k.uwm.edu>|References:=20<1365080139.15840341255013979397 .JavaMail.root@mail02.pantherlink.uwm.edu>; bh=M0FF5KfH3KTtRa34i+qkmKThfYuCk/v4qJ6ciFD6UJ0=; b=D6TJI4Nzu51W8XnSd5v66ySRyRwpPl3UtVWLkXYg+YnOum5tFqubt/Bz wXgI95xoKPW8zgtgloi85Exr07iFy0h+ic1vMSmtUqKKch11qhXigA1RZ iNM1olfOLDDVKYW6KaFDFGk9MYqGMvSoRZOsW9pkA7pBcppLzBXrF6rCR o=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4AAPuizkqQ/uCWe2dsb2JhbACbAwEBFiQGplOYRIImggQEij8 X-IronPort-AV: E=Sophos;i="4.44,531,1249257600"; d="scan'208";a="51359264" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2009 09:46:40 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n999ke4P026344; Fri, 9 Oct 2009 09:46:40 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:46:40 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 11:46:39 +0200 Message-Id: From: JP Vasseur To: Mukul Goyal In-Reply-To: <1365080139.15840341255013979397.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 11:46:38 +0200 References: <1365080139.15840341255013979397.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 09 Oct 2009 09:46:39.0439 (UTC) FILETIME=[663B25F0:01CA48C5] Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 09:44:59 -0000 Hi Mukul, On Oct 8, 2009, at 4:59 PM, Mukul Goyal wrote: > JP > > If we want to use ETX as the reliability metric, it should be ETX at > the network layer. It should be related to the packet loss rate L > (as observed by the network layer) as follows: ETX = 1/(1-L). Yes, with some variations though since L is not always reported by the link layer (in the absence of ACK). > > I dont really have preferences for the latency. I may have > objections if you have some preferences. :) Sure ;-) Cheers. JP. > > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "Mukul Goyal" > Cc: "Kris Pister" , "IETF ROLL" > > Sent: Thursday, October 8, 2009 12:52:27 AM GMT -06:00 US/Canada > Central > Subject: Re: [Roll] RPL Metric ID > > Hi Mukul, > > On Oct 7, 2009, at 9:40 PM, Mukul Goyal wrote: > >> I think both latency and reliability are important metrics. >> > > OK thanks for the feed-backs. > The most obvious and common reliability is ETX. > Any preference for the latency? > >> I am sort of negative on using memory/CPU availability as metric or >> constraint. They seem like local factors to me. If a node is running >> low on memory/CPU, it can simply not participate in routing. > > And we already have an "overload" bit. > > Thanks. > > JP. > >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "IETF ROLL" >> Cc: "Kris Pister" >> Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada >> Central >> Subject: [Roll] RPL Metric ID >> >> >> Dear all, >> >> >> We would appreciate your feed-back on RPL routing metrics. >> >> >> Now that RPL is stabilizing it is time to move forward with the >> METRIC I-D. The next revision will be a major one, with packet >> encoding, processing rules, etc. >> >> >> We discussed and agreed some time ago on several links and nodes >> metrics (also required according to our requirement IDs). >> >> >> Still, there are a few metrics for which we would like to know >> whether you think that they should be specified. >> >> >> 4.2. Latency >> >> >> >> As with throughput, the latency of many LLN MAC sub-layers can be >> varied over many orders of magnitude, again with a corresponding >> change in current consumption. Some LLN MACs will allow the >> latency >> to be adjusted globally on the subnet, or on a link-by-link >> basis, or >> not at all. Some will insist that it be fixed for a given link, >> but >> allow it to be variable from link to link. For efficient >> operation, >> nodes must be able to report the range of latency that their links >> can handle, and the currently available latency. >> >> >> 4.3. Link reliability >> >> >> In LLNs, link reliability is degraded by external interference and >> multi-path interference. Multipath typically affects both >> directions >> on the link equally, whereas external interference is sometimes >> uni- >> directional. Time scales vary from milliseconds to days, and are >> often periodic and linked to human activity. Packet error rate can >> generally be measured directly, and other metrics (e.g. bit error >> rate, mean time between failures) are typically derived from that. >> >> >> In addition: >> >> >> Node Memory resources: >> >> >> Memory is a critical node resources in presence of constrained >> nodes. Is there a need to report node memory resources as a routing >> metric/constraint ? >> >> >> Node CPU resources: >> CPU duty cycle for virtually all LLN applications to date is well >> below 10%, and the trend in low power embedded systems is to more >> capable processors rather than less. Computational speed is not >> expected to be a limiting factor in routing in LLNs. Is there a need >> to report node CPU resources as a routing metric/constraint ? >> >> >> Link Security metrics >> >> >> Thanks for your feed-back. >> >> >> JP, Mijeon, Kris. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Fri Oct 9 05:53:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F5B3A68F4 for ; Fri, 9 Oct 2009 05:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.08 X-Spam-Level: X-Spam-Status: No, score=-10.08 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWvVo4M6E5Lr for ; Fri, 9 Oct 2009 05:53:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2BE373A6A5F for ; Fri, 9 Oct 2009 05:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=13556; q=dns/txt; s=amsiport01001; t=1255092936; x=1256302536; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20A=20proposal=20for=20Traffic=20Loop=20a voidance,=20detection=20and=20recovery|Date:=20Fri,=209 =20Oct=202009=2014:55:27=20+0200|Message-ID:=20<6A2A45917 5DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com>|To: =20"roll"=20|MIME-Version:=201.0; bh=BSEbH+/S+BioSn91MzE+AM5yLw8ivtgFBKq01vflZdA=; b=F/f6APm1GAKpJmo/3W1MwBJO0h+76fdgCLkiQNsnJHBZKjHSgAwZtzlN s6Mf4LQuEe0pbz6EyfC8KdBO7VKXia+pR5lYiSFhRZkggvkS1alOwxZI4 M/blc/IoprsThxq1nplVpYk/3x/MNMK7T1CIDuFY+XCNvQaJJr/k49x8i 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAAI3PzkqQ/uCWe2dsb2JhbACCKC2YLwEBFiQGpnyYS4QqBA X-IronPort-AV: E=Sophos;i="4.44,532,1249257600"; d="scan'208,217";a="51382622" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Oct 2009 12:55:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n99CtYDR010585 for ; Fri, 9 Oct 2009 12:55:34 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 14:55:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA48DF.CA4C457D" Date: Fri, 9 Oct 2009 14:55:27 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A proposal for Traffic Loop avoidance, detection and recovery Thread-Index: AcpI38YJNSAY8kjXTsKOwOCWOlF41w== From: "Pascal Thubert (pthubert)" To: "roll" X-OriginalArrivalTime: 09 Oct 2009 12:55:34.0235 (UTC) FILETIME=[CA4BC2B0:01CA48DF] Subject: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 12:53:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA48DF.CA4C457D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi: =20 It seems widely accepted in this group that Loop avoidance in the control place should be kept simple but completed by a detection mechanism associated to the packets. This approach had been validated in CTP and DADR.=20 =20 After a number of discussions, here is a proposal. The proposal uses some info that is placed in the packet in the flow label. It assumes that the flow label is reserved for the purpose of RPL and node interaction. In the flow label we place: =20 Outwards : 1 bit Sibling : 1 bit Rank_error : 1 bit DAO_Error : 1 bit Rank : 8 bit Instance ID : 8 bit =20 Instance forwarding Instance IDs is used to avoid loops between DAGs from different origins. =20 InstanceID is placed by the source in the flow label. It MUST matched the DAG instance onto which the packet is placed by a router. The router MAY either change the instanceID to match the DAG that it is using for this packet or discard the packet. That decision is policy based. Default policy TBD.=20 =20 Idea? =20 DAG inconsistency loop detection The DAG is inconsistent is the packet direction does not match the rank relationship.=20 =20 A host MUST set the rank to FF. A router MUST place its rank in the flow label.=20 A node emitting a packet must reset the Rank_error bit and the Outwards bit. A router MUST also reset the Outwards bit if it is using the default route inwards, either via a sibling or a parent, and set the bit if it is using a DAO route, either via a sibling or a child. =20 A receiver detects an inconsistency if it receives a packet going inwards from a source with a lesser Rank, or outwards with a higher rank. =20 Upon inconsistency, if the Rank_error bit was not set then the Rank_error bit is set. If it was set the packet is discarded. This is done to cover a rare re-sequencing of the DAG. =20 Sibling loop avoidance A simple rule is that a packet may not make 2 sibling hops in a row. =20 When a host sends a packet or a router forwards to a non sibling, the Sibling bit must be reset. When a router forwards to a sibling: if the Sibling bit was not set then the Sibling bit is set. If it was set then the packet is discarded.=20 =20 DAO inconsistency loop detection A "parent" has an outwards DAO route that is a remnant from an obsolete DAO via a "child" but the "child" does not have a matching DOA state.=20 =20 In a general manner, a packet that goes outwards should never go inwards again. So rather than routing inwards a packet with the Outwards bit set, the router MUST discard the packet. If DAO recovery is in place, then the router MAY send it back to the source. =20 DAO inconsistency loop recovery A Router that supports recovery uses a packet to recursively explore and cleanup the obsolete paths. =20 The "child" router that detects the DAO inconsistency SHOULD set the DAO_Error bit and return the packet to the parent that passed it. =20 Upon a packet with a DAO bit set, the parent MUST remove the routing states that caused forwarding to the child that passed it, clear DAO_Error bit and send the packet again. =20 =20 Opinions? (fire at will) =20 Pascal ------_=_NextPart_001_01CA48DF.CA4C457D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi:

 

It seems widely accepted in this group that Loop = avoidance in the control place should be kept simple but completed by a detection mechanism associated to the packets. This approach had been validated in = CTP and DADR.

 

After a number of discussions, here is a proposal. = The proposal uses some info that is placed in the packet in the flow = label.

It assumes that the flow label is reserved for the = purpose of RPL and node interaction. In the flow label we place:

 

Outwards        = ;    : 1 bit

Sibling        =            : 1 bit

Rank_error =         : 1 bit

DAO_Error       &nbs= p;  : 1 bit

Rank      =             &= nbsp;   : 8 bit

Instance = ID         : 8 bit

 

Instance = forwarding

Instance IDs is used to avoid loops between DAGs = from different origins.

 

InstanceID is placed by the source in the flow = label. It MUST matched the DAG instance onto which the packet is placed by a = router. The router MAY either change the instanceID to match the DAG that it is = using for this packet or discard the packet. That decision is policy based. = Default policy TBD.

 

Idea?

 

DAG inconsistency = loop detection

The DAG is inconsistent is the packet direction = does not match the rank relationship.

 

A host MUST set the rank to FF. A router MUST place = its rank in the flow label.

A node emitting a packet must reset the Rank_error = bit and the Outwards bit.

A router MUST also reset the Outwards bit if it is = using the default route inwards, either via a sibling or a parent, and set the bit = if it is using a DAO route, either via a sibling or a child.

 

A receiver detects an inconsistency if it receives = a packet going inwards from a source with a lesser Rank, or outwards with a = higher rank.

 

Upon inconsistency, if the Rank_error bit was not = set then the Rank_error bit is set. If it was set the packet is discarded. This is = done to cover a rare re-sequencing of the DAG.

 

Sibling loop = avoidance

A simple rule is that a packet may not make 2 = sibling hops in a row.

 

When a host sends a packet or a router forwards to = a non sibling, the Sibling bit must be reset.

When a router forwards to a sibling: if the Sibling = bit was not set then the Sibling bit is set. If it was set then the packet is discarded.

 

DAO inconsistency = loop detection

A “parent” has an outwards DAO route = that is a remnant from an obsolete DAO via a “child” but the = “child” does not have a matching DOA state.

 

In a general manner, a packet that goes outwards = should never go inwards again. So rather than routing inwards a packet with the = Outwards bit set, the router MUST discard the packet. If DAO recovery is in = place, then the router MAY send it back to the source.

 

DAO inconsistency = loop recovery

A Router that supports recovery uses a packet to = recursively explore and cleanup the obsolete paths.

 

The “child” router that detects the DAO inconsistency SHOULD set the DAO_Error bit and return the packet to the = parent that passed it.

 

Upon a packet with a DAO bit set, the parent MUST = remove the routing states that caused forwarding to the child that passed it, clear = DAO_Error bit and send the packet again.

 

 

Opinions? (fire at will)

 

Pascal

------_=_NextPart_001_01CA48DF.CA4C457D-- From jabeille@cisco.com Fri Oct 9 06:12:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF8728C149 for ; Fri, 9 Oct 2009 06:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.004 X-Spam-Level: X-Spam-Status: No, score=-8.004 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LanRsuZBXmT for ; Fri, 9 Oct 2009 06:12:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B647D28C0FD for ; Fri, 9 Oct 2009 06:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=3521; q=dns/txt; s=sjiport06001; t=1255094075; x=1256303675; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20NA=20to=20transport=20DAO|Date:=20Fri, =209=20Oct=202009=2015:14:18=20+0200|Message-ID:=20 |To:=20"IETF=20ROLL"=20|MIME-Version:=201. 0; bh=RLFRygjk8TrSYPnGyaB7H21k6Hp7wC2ZHNW8/Yhpjng=; b=eIVsMQXHoFNg4TVv/NPffX5dphbPSjOE0E/vCP7ZZEALTmZ/oDxvgrPT OEhSczjPq/0PxO4TqLbROm8x+n80zwCwAaav+QOmMtomrJr86zJPrH3uC 2QcSh/k4C1SG/DYrhk4NzS9mYdXU1OZHdQe1alY9dgpZustrEO3vW4wrh s=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgEAG/UzkqrR7Ht/2dsb2JhbACCKC2/fJhHhCoE X-IronPort-AV: E=Sophos;i="4.44,532,1249257600"; d="scan'208,217";a="405409531" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Oct 2009 13:14:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n99DEXmh016031 for ; Fri, 9 Oct 2009 13:14:35 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 15:14:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA48E2.705B513A" Date: Fri, 9 Oct 2009 15:14:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NA to transport DAO Thread-Index: AcpI4mhaXa/jhwrTREaNzQiSmyXg3w== From: "Julien Abeille (jabeille)" To: "IETF ROLL" X-OriginalArrivalTime: 09 Oct 2009 13:14:31.0258 (UTC) FILETIME=[7003B3A0:01CA48E2] Subject: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 13:12:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA48E2.705B513A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have concerns about the use of NA to transport DAOs for the following reasons: - NAs are not routing messages - unsolicited NAs are not very frequent, hence using them for DAOs is not really piggybacking. We do not gain a lot by using them - NA are already pretty overloaded messages: they are used in 3 procedures, namely address resolution, NUD and DAD - NA processing is implementation wise complex enough because of the point above - implementation wise, coupling RPL with ND makes code much more complex. - the target address field in the NA uses 16 bytes without bringing a lot of value to RPL. =20 I think using a new ICMP message to carry DAOs would be much better. =20 What do people think? Best, Julien ------_=_NextPart_001_01CA48E2.705B513A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I have = concerns=20 about the use of NA to transport DAOs for the following=20 reasons:
- NAs = are not=20 routing messages
- = unsolicited NAs=20 are not very frequent, hence using them for DAOs is not really = piggybacking. We=20 do not gain a lot by using them
- NA = are already=20 pretty overloaded messages: they are used in 3 procedures, namely = address=20 resolution, NUD and DAD
- NA = processing is=20 implementation wise complex enough because of the point=20 above
- = implementation=20 wise, coupling RPL with ND makes code much more = complex.
- the = target address=20 field in the NA uses 16 bytes without bringing a lot of value to=20 RPL.
 
I = think using a new=20 ICMP message to carry DAOs would be much better.
 
What = do people=20 think?
Best,
Julien
------_=_NextPart_001_01CA48E2.705B513A-- From wintert@acm.org Fri Oct 9 07:06:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9814A28C11E for ; Fri, 9 Oct 2009 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1fdWy+e7pUa for ; Fri, 9 Oct 2009 07:06:32 -0700 (PDT) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id 7C08228C11A for ; Fri, 9 Oct 2009 07:06:32 -0700 (PDT) Received: (qmail 74873 invoked from network); 9 Oct 2009 14:08:14 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 09 Oct 2009 07:08:14 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: O_wYvXoVM1l.aT2TxR_wQOa8LuCaJwmd8j.QX_hl4bj8F5owvi8Lwst9aKaS.4bIUk4r_ohGBLYvPo9pS1ytLY9RaZ_Mcr3sd3yLxleK8z0YLXXJadmFkmYWa2Ev0xbd_xQiBn2Aoehe407l4K4aYFHs_e9uaOoIV09_jl4IgfTluXxK0W8YDwcYnDI0QltYpw7LuRymRLpYE75__CdTLib3Ad5ydht8iuot8.OI6svhwZjXJJSM4dfiTj0_qGl2rC2LEi2FmLGiHIcX6BCGbSPBxksG37Uag4R3CpWdZz0EDnil3iF1PLwDANjAatlj8P9YaDwcQFFJvKBlcXfRPgEJtPAvy6MSiU9r2KdTEnOOdLxgQ6sfVzRhGpDnkLyUjgX9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ACF43CC.2020303@acm.org> Date: Fri, 09 Oct 2009 10:08:12 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 14:06:33 -0000 Mukul Goyal wrote: > I think both latency and reliability are important metrics. > > +1 > I am sort of negative on using memory/CPU availability as metric or constraint. They seem like local factors to me. If a node is running low on memory/CPU, it can simply not participate in routing. > > Exposing an exaggerated rank might also be an option. -Tim > Thanks > Mukul > > ----- Original Message ----- > From: "JP Vasseur" > To: "IETF ROLL" > Cc: "Kris Pister" > Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada Central > Subject: [Roll] RPL Metric ID > > > Dear all, > > > We would appreciate your feed-back on RPL routing metrics. > > > Now that RPL is stabilizing it is time to move forward with the METRIC I-D. The next revision will be a major one, with packet encoding, processing rules, etc. > > > We discussed and agreed some time ago on several links and nodes metrics (also required according to our requirement IDs). > > > Still, there are a few metrics for which we would like to know whether you think that they should be specified. > > > 4.2. Latency > > > > As with throughput, the latency of many LLN MAC sub-layers can be > varied over many orders of magnitude, again with a corresponding > change in current consumption. Some LLN MACs will allow the latency > to be adjusted globally on the subnet, or on a link-by-link basis, or > not at all. Some will insist that it be fixed for a given link, but > allow it to be variable from link to link. For efficient operation, > nodes must be able to report the range of latency that their links > can handle, and the currently available latency. > > > 4.3. Link reliability > > > In LLNs, link reliability is degraded by external interference and > multi-path interference. Multipath typically affects both directions > on the link equally, whereas external interference is sometimes uni- > directional. Time scales vary from milliseconds to days, and are > often periodic and linked to human activity. Packet error rate can > generally be measured directly, and other metrics (e.g. bit error > rate, mean time between failures) are typically derived from that. > > > In addition: > > > Node Memory resources: > > > Memory is a critical node resources in presence of constrained nodes. Is there a need to report node memory resources as a routing metric/constraint ? > > > Node CPU resources: > CPU duty cycle for virtually all LLN applications to date is well below 10%, and the trend in low power embedded systems is to more capable processors rather than less. Computational speed is not expected to be a limiting factor in routing in LLNs. Is there a need to report node CPU resources as a routing metric/constraint ? > > > Link Security metrics > > > Thanks for your feed-back. > > > JP, Mijeon, Kris. > _______________________________________________ > 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 richard.kelsey@ember.com Fri Oct 9 07:06:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCBD228C11A for ; Fri, 9 Oct 2009 07:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-1.872, BAYES_50=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDWUJr3X3+sb for ; Fri, 9 Oct 2009 07:06:57 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B9C223A685E for ; Fri, 9 Oct 2009 07:06:56 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 10:09:44 -0400 Date: Fri, 09 Oct 2009 10:07:11 -0400 Message-Id: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 09 Oct 2009 14:09:44.0665 (UTC) FILETIME=[26F57C90:01CA48EA] Subject: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 14:06:57 -0000 Below is a discourse on the reliability characteristics of 802.15.4 and similar digital radios and what this means for link metrics. Even if the goal is to maximize something other than reliability, you still need the links to be reasonably reliable in order to reduce churn and because no matter what the metric, broken routes have little utility. Non-radio links, or other types of radios, will have very different characteristics. This may make it difficult to have a good relibility metric that is independent of the link layer. ---------------- Digital radios 802.15.4 and similar digital radios have the property that packet reliability falls off fairly quickly over a short range of signal quality. A link that is working very reliabily, with near 100% packet delivery, may degrade quickly with only a small increase in the local radio noise or small change in the physical environment. For example, a link with consistent, near-100% reliability may disappear entirely if one of the radios is moved as little as a few cm. Very crudely, the packet reliability graph looks something like this: 100% ______________________ / 50% / / 0%________________/ increasing signal-to-noise (SNR) ratio --> Nearby radios can be far off to the right on this graph. As the local environment changes, the SNR for any particular link moves up and down (left and right on the graph). This only matters if the change is sufficient to move the link's current SNR into the vicinity of the cliff. If so, the link may lose a significant percentage of packets. If not, almost all packets are delivered. Links at the cliff or to the left are useless. Even if some packets are getting through, a very small change in the environment can break the link completely. All links well to the right are all essentially equivalent; they can be expected to work every time. Links just to the right of the cliff are questionable; they work now but their future performance is uncertain. 100% ______________________ / 50% / / 0%________________/ <---- useless --------|---- okay -----|--- good ---> In the short term, packet reliability measurements cannot distinguish between okay and good links, because the short term differences in reliability are not significant. They can be distinguished by comparing the RSSI of incoming packets with the current noise floor. Counting chip errors can help, as chip errors show up somewhat before packets start to be lost. Whether or not they show up far enough to the right to be used to tell the difference between 'good' and 'okay' links is not clear. ---------------- What does this mean for link reliability metrics? One point is that tracking observed packet reliability is of limited use. In the short term 'okay' links may look just like 'good' links and longer term averages may not react quickly enough to be useful. The main point is that, if you stick to good links, you will probably do all right just using hop count. All good links will have about the same success rates in the short or long term. The trick is to tell the good links from the merely okay ones. I believe that the white bit in the four-bit link estimator [1], has the effect of keeping traffic mostly on good links. Good links have few chip errors, okay links will likely have more. It appears that the four-bit link estimator does not do any averaging of the white bit. It would be interesting to determine how much of its performance is due to the use of the white bit and how much to its ETX estimation, and if it could be improved by averaging the white bit over time. The 'okay' links cannot be ignored, as they are actually working at the moment and may be the only thing keeping the network connected. Any additive metric has to define how many good links are equivalent to one okay one. This isn't easy to do, because we would really prefer to use an okay link only if there is no path using only good links. Except in very unusual topologies, it is unlikely that you will ever be faced with a choice between one okay link and, say, five good ones. The simplest metric that maintains this distinction would be the number of good links and the number of okay ones, kept as separate values, with the okay link count having precedence over the good link count (the good counts are only considered if the okay counts are equal). More fine-grained metrics are obviously possible, and are likely to provide some benefit, so long as they strongly prefer good links over okay ones. -Richard Kelsey [1] R. Fonseca, O. Gnawali, K. Jamieson, and P. Levis. "Four Bit Wireless Link Estimation." In the Proceedings of the 6th Workshop on Hot Topics in Networking (HotNets-VI), 2007. From richard.kelsey@ember.com Fri Oct 9 07:27:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C9093A6A2E for ; Fri, 9 Oct 2009 07:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjjD+PzDADR6 for ; Fri, 9 Oct 2009 07:27:54 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 872B728C11A for ; Fri, 9 Oct 2009 07:27:54 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 10:30:42 -0400 Date: Fri, 09 Oct 2009 10:28:08 -0400 Message-Id: <87hbu8bq13.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <0E985639-0382-47B6-9F89-50C7CFA28CAD@cs.stanford.edu> (message from Philip Levis on Thu, 8 Oct 2009 09:08:40 -0700) From: Richard Kelsey References: <0E985639-0382-47B6-9F89-50C7CFA28CAD@cs.stanford.edu> X-OriginalArrivalTime: 09 Oct 2009 14:30:42.0741 (UTC) FILETIME=[14D4A650:01CA48ED] Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 14:27:55 -0000 From: Philip Levis Date: Thu, 8 Oct 2009 09:08:40 -0700 My experience is that asymmetric links are of limited use for LLNs. Because LLNs are lossy, they tend to have single-hop acknowledgment schemes, either at the link layer or at the network layer. Single-hop acknowledgments don't work well in asymmetric links. Yes, the acknowledgments are shorter and so the ARR (acknowledgment reception rate) can be higher than the PRR (packet reception rate), but this window is so narrow and the complexity needed to use it is significant enough that asymmetric links are more an intellectual curiosity rather than something of significant value to exploit. I completely agree. In addition, if the routing layer assumes that links are bidirectional, it is important that the any link quality measurement not make the same assumption. In other words, either the link layer or routing layer has to take asymmetries into account. -Richard Kelsey From jhui@archrock.com Fri Oct 9 08:03:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A9728C11E for ; Fri, 9 Oct 2009 08:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbrrh7EU0vwx for ; Fri, 9 Oct 2009 08:03:28 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 0065528C13A for ; Fri, 9 Oct 2009 08:03:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id C9DB6AF9BB; Fri, 9 Oct 2009 08:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBDoWdzokyuJ; Fri, 9 Oct 2009 08:05:08 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id A573BAF9AA; Fri, 9 Oct 2009 08:05:08 -0700 (PDT) Message-Id: <8DEDF576-B215-4993-98A3-29BF8AE2601A@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87hbu8bq13.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 08:05:07 -0700 References: <0E985639-0382-47B6-9F89-50C7CFA28CAD@cs.stanford.edu> <87hbu8bq13.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 15:03:28 -0000 In general, I agree with both Phil and Richard, but asymmetric links are a bit ill-defined in this discussion. The implicit meaning in seems to have been that communication is "good" in one direction while "bad" in the reverse. Instead, I'd prefer to make a stronger statement and say that the routing metrics should project symmetric information about the links - meaning that the computed cost of using the link in one direction is the same as in the reverse direction. Obviously, this is more natural in some metrics (reliability, signal strength) than others (latency, energy). But, in my experience, relying on symmetric information when it is natural to do so does simplify the routing problem. -- Jonathan Hui On Oct 9, 2009, at 7:28 AM, Richard Kelsey wrote: > From: Philip Levis > Date: Thu, 8 Oct 2009 09:08:40 -0700 > > My experience is that asymmetric links are of limited use for > LLNs. Because LLNs are lossy, they tend to have single-hop > acknowledgment schemes, either at the link layer or at the network > layer. Single-hop acknowledgments don't work well in asymmetric > links. > Yes, the acknowledgments are shorter and so the ARR (acknowledgment > reception rate) can be higher than the PRR (packet reception rate), > but this window is so narrow and the complexity needed to use it is > significant enough that asymmetric links are more an intellectual > curiosity rather than something of significant value to exploit. > > I completely agree. In addition, if the routing layer > assumes that links are bidirectional, it is important that > the any link quality measurement not make the same assumption. > In other words, either the link layer or routing layer has > to take asymmetries into account. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=52646f13d=mukul@uwm.edu Fri Oct 9 08:51:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5725528C101 for ; Fri, 9 Oct 2009 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_20=-0.74, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgky2+ESJ-6Y for ; Fri, 9 Oct 2009 08:51:52 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id E22FB28C149 for ; Fri, 9 Oct 2009 08:51:51 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 09 Oct 2009 10:53:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 2BB15C085D3; Fri, 9 Oct 2009 10:53:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNH1wGj93DIZ; Fri, 9 Oct 2009 10:53:35 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 063E0C085A0; Fri, 9 Oct 2009 10:53:35 -0500 (CDT) Date: Fri, 9 Oct 2009 10:53:34 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <235757746.16320661255103614862.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 15:52:06 -0000 Some time back, we did the following calculations: 1) use standard formulae to obtain bit error rates (for O-QPSK under AWGN, Raleigh and Rician fading models) for different SNR values 2) convert bit error rates to symbol error rates (using the Hamming distance among valid symbol codes (32 chip long) 802.15.4 uses) 3) convert symbol error rates to packet error rates (assuming 127 byte packets) The resulting graphs with SNR on x-axis and bit/symbol/packet error rates on y-axis can be seen towards the end of: www.cs.uwm.edu/~mukul/rssi.doc They basically confirm what Richard said about the rapid change in packet error rates with slight change in SNR. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: roll@ietf.org Sent: Friday, October 9, 2009 9:07:11 AM GMT -06:00 US/Canada Central Subject: [Roll] reliability metrics for digital radios Below is a discourse on the reliability characteristics of 802.15.4 and similar digital radios and what this means for link metrics. Even if the goal is to maximize something other than reliability, you still need the links to be reasonably reliable in order to reduce churn and because no matter what the metric, broken routes have little utility. Non-radio links, or other types of radios, will have very different characteristics. This may make it difficult to have a good relibility metric that is independent of the link layer. ---------------- Digital radios 802.15.4 and similar digital radios have the property that packet reliability falls off fairly quickly over a short range of signal quality. A link that is working very reliabily, with near 100% packet delivery, may degrade quickly with only a small increase in the local radio noise or small change in the physical environment. For example, a link with consistent, near-100% reliability may disappear entirely if one of the radios is moved as little as a few cm. Very crudely, the packet reliability graph looks something like this: 100% ______________________ / 50% / / 0%________________/ increasing signal-to-noise (SNR) ratio --> Nearby radios can be far off to the right on this graph. As the local environment changes, the SNR for any particular link moves up and down (left and right on the graph). This only matters if the change is sufficient to move the link's current SNR into the vicinity of the cliff. If so, the link may lose a significant percentage of packets. If not, almost all packets are delivered. Links at the cliff or to the left are useless. Even if some packets are getting through, a very small change in the environment can break the link completely. All links well to the right are all essentially equivalent; they can be expected to work every time. Links just to the right of the cliff are questionable; they work now but their future performance is uncertain. 100% ______________________ / 50% / / 0%________________/ <---- useless --------|---- okay -----|--- good ---> In the short term, packet reliability measurements cannot distinguish between okay and good links, because the short term differences in reliability are not significant. They can be distinguished by comparing the RSSI of incoming packets with the current noise floor. Counting chip errors can help, as chip errors show up somewhat before packets start to be lost. Whether or not they show up far enough to the right to be used to tell the difference between 'good' and 'okay' links is not clear. ---------------- What does this mean for link reliability metrics? One point is that tracking observed packet reliability is of limited use. In the short term 'okay' links may look just like 'good' links and longer term averages may not react quickly enough to be useful. The main point is that, if you stick to good links, you will probably do all right just using hop count. All good links will have about the same success rates in the short or long term. The trick is to tell the good links from the merely okay ones. I believe that the white bit in the four-bit link estimator [1], has the effect of keeping traffic mostly on good links. Good links have few chip errors, okay links will likely have more. It appears that the four-bit link estimator does not do any averaging of the white bit. It would be interesting to determine how much of its performance is due to the use of the white bit and how much to its ETX estimation, and if it could be improved by averaging the white bit over time. The 'okay' links cannot be ignored, as they are actually working at the moment and may be the only thing keeping the network connected. Any additive metric has to define how many good links are equivalent to one okay one. This isn't easy to do, because we would really prefer to use an okay link only if there is no path using only good links. Except in very unusual topologies, it is unlikely that you will ever be faced with a choice between one okay link and, say, five good ones. The simplest metric that maintains this distinction would be the number of good links and the number of okay ones, kept as separate values, with the okay link count having precedence over the good link count (the good counts are only considered if the okay counts are equal). More fine-grained metrics are obviously possible, and are likely to provide some benefit, so long as they strongly prefer good links over okay ones. -Richard Kelsey [1] R. Fonseca, O. Gnawali, K. Jamieson, and P. Levis. "Four Bit Wireless Link Estimation." In the Proceedings of the 6th Workshop on Hot Topics in Networking (HotNets-VI), 2007. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Fri Oct 9 09:05:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90EED28C112 for ; Fri, 9 Oct 2009 09:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPNbwUqNDbNM for ; Fri, 9 Oct 2009 09:05:08 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 92D6A3A6A50 for ; Fri, 9 Oct 2009 09:05:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 8616FAF9BE; Fri, 9 Oct 2009 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4QQeGxep6fj; Fri, 9 Oct 2009 09:06:49 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id B765AAF9C2; Fri, 9 Oct 2009 09:06:48 -0700 (PDT) Message-Id: <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 09:06:47 -0700 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 16:05:09 -0000 Hi Richard, I agree that it is useful to discern between "okay" and "good" links. On Oct 9, 2009, at 7:07 AM, Richard Kelsey wrote: > I believe that the white bit in the four-bit link estimator > [1], has the effect of keeping traffic mostly on good links. > Good links have few chip errors, okay links will likely have > more. It appears that the four-bit link estimator does not > do any averaging of the white bit. It would be interesting > to determine how much of its performance is due to the use > of the white bit and how much to its ETX estimation, and if > it could be improved by averaging the white bit over time. The current tinyos-2.x implementation on the TI CC2420 uses the radio's chip correlation feedback. It doesn't use the RSSI, let alone compare it to the current noise floor. As you suspected, the implementation also does not do any averaging over time and given that CC2420's chip correlation value has high variability, averaging is likely to help. But in my experience, chip correlation is still a better measure of PRR than SNR. Said differently, chip correlation does not adequately distinguish "okay" and "good" links well. > The 'okay' links cannot be ignored, as they are actually > working at the moment and may be the only thing keeping the > network connected. Any additive metric has to define how > many good links are equivalent to one okay one. This isn't > easy to do, because we would really prefer to use an okay > link only if there is no path using only good links. Except > in very unusual topologies, it is unlikely that you will > ever be faced with a choice between one okay link and, say, > five good ones. Mostly agree with this. One practical concern we have run into with utilizing "okay" links is that network deployment/maintenance becomes more complex for the end-user. If "okay" links are required for connectivity, the network will appear to function well at times but not others. For some end-users, it may be better not to function at all if "okay" links is all you have when joining a network. > The simplest metric that maintains this distinction would be > the number of good links and the number of okay ones, kept > as separate values, with the okay link count having > precedence over the good link count (the good counts are > only considered if the okay counts are equal). More > fine-grained metrics are obviously possible, and are likely > to provide some benefit, so long as they strongly prefer > good links over okay ones. Maintaining the distinction seems like a reasonable approach. -- Jonathan Hui From alexandru.petrescu@gmail.com Fri Oct 9 10:37:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB0F28C1F8 for ; Fri, 9 Oct 2009 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZIMN4Hu7Nk8 for ; Fri, 9 Oct 2009 10:37:50 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 1F99928C1E0 for ; Fri, 9 Oct 2009 10:37:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n99HdOt8008747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Oct 2009 19:39:25 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n99HdOm0015966; Fri, 9 Oct 2009 19:39:24 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n99HdOnk027363; Fri, 9 Oct 2009 19:39:24 +0200 Message-ID: <4ACF754C.2000604@gmail.com> Date: Fri, 09 Oct 2009 19:39:24 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 17:37:51 -0000 JP Vasseur a écrit : > Hi Richard, > > On Oct 8, 2009, at 5:03 PM, Richard Kelsey wrote: > >> Jerry, >> >> From: Jerald.P.Martocci@jci.com Date: Thu, 8 Oct 2009 08:19:33 >> -0500 >> >> Per your question, our current implementation uses standard ZigBee >> algorithms. ZigBee bases path costs on RSSI only. >> >> No, ZigBee's path costs are based on the probability of packet >> reception over the link. See Section 3.6.3.1 of the ZigBee spec. >> RSSI above the noise floor could be used to estimate that >> probability, of course. Raw RSSI doesn't tell you very much. >> > > Right. What we need to define is metric that describes the > probability of packet delivery ratio along the path. JP, that is your definition of what's needed and I respectfully disagree. PAcket delivery ratio is something which equals "best effort" i.e. it has no number quantifying it. Energy? Energy is something different, and doesn't relate to "best effort" - it can be quantified. Alex Since RPL is a > distance vector, we would use a cumulative metric. Of course, each > node should filter out the transient error rate and periodicity of > the metric update should be limited to avoid routing metric but this > not specific to the reliability metric. It is true for all dynamic > metrics. > > The objective is thus to define a cumulative reliability metric > reflecting the probability of success path delivery, in units > independent of the Link layer. Local mechanisms to filter out local > transient phenomena are left to implementation specific decisions. > > Make sense ? > > >> Our product was developed and deployed in 2006. We used what is >> termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has >> developed the 'ZigBee PRO' stack which will in time subsume the >> ZigBee Stack. ZigBee PRO selects paths based on the best symmetric >> path found. I believe asymmetric paths are discarded or only used >> as a last resort. >> >> Not quite. ZigBee PRO only requires that the cost assigned to an >> asymmetric link be the worse of the two unidirectional costs. > > Makes sense. We had a discussion on this too, and it was decided not > to take it into account for the time being. > >> >> Unfortunately, I have no empirical or simulation data on this >> metric. Maybe Richard can provide some insight on this approach >> since I believe it was championed by Ember. >> >> Ember and Mitsubishi proposed the solution that was adopted >> (exchanging link costs with neighbors). The actual problem that it >> solved was first raised by Ghulam Bhatti of Mitsubishi, if I >> remember correctly. Under certain circumstances having the two >> ends of a link use different costs could cause ZigBee's P2P routing >> to consistently fail to discover a route. The problem was fairly >> fundamental to ZigBee's P2P mechanism, and given the other >> advantages of identifying asymmetries and knowing more about your >> local neighborhood, ZigBee added a feature where nodes inform their >> neighbors of their link costs. This seems like something that >> could be done at the link layer. >> > > Yes. > > JP. > >> -Richard Kelsey >> >> _______________________________________________ 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 alexandru.petrescu@gmail.com Fri Oct 9 10:52:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDDA128C19A for ; Fri, 9 Oct 2009 10:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqtB77fMpyl7 for ; Fri, 9 Oct 2009 10:52:09 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id A5FC328C0F0 for ; Fri, 9 Oct 2009 10:52:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n99Hrk1D015960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Oct 2009 19:53:46 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n99Hrk9m016766; Fri, 9 Oct 2009 19:53:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n99Hrj6i028891; Fri, 9 Oct 2009 19:53:46 +0200 Message-ID: <4ACF78A9.8040405@gmail.com> Date: Fri, 09 Oct 2009 19:53:45 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> In-Reply-To: <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 17:52:10 -0000 Hi JP, JP Vasseur a écrit : > Hi Alex, > > On Oct 8, 2009, at 4:18 PM, Alexandru Petrescu wrote: > >> Hi JP, >> >> I am attracted by the subject of the mail, it is about Metric I-D >> (Internet Draft). However, I am not sure what are you asking for? > > Which metric should be defined for RPL (link and node). Note that we > have several metrics already defined, but still a few TBD. Do you have a metric which says "energy needed to send a packet on an interface"? I don't think you do. I think your draft briefly alludes to energy cost of sending and receiving packets (presumably on a link), but falls short in defining one as such. To cite your draft: > Raw power and energy values are meaningless without knowledge of the > energy cost of sending and receiving packets Yet the table of contents says: > 4. Link Metrics and Attributes . . . . . . . . . . . . . . . . . 8 > 4.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.3. Link reliability . . . . . . . . . . . . . . . . . . . . . 9 > 4.4. Link Coloring . . . . . . . . . . . . . . . . . . . . . . 9 Where is the link energy metric I am proposing and of which your draft seems to be hinting at? >> I still suggest to have link metrics taken into account by ICMP, >> routing protocols _and_ RPL. > > Not sure why you refer to ICMP here but back to RPL ... BEcause I think it would be good if a metric invented for one protocol could be reused by another protocol. >> These link metrics would express the energy needed to send a >> certain amount of bytes on a certain interface, or on a certain >> path. The exression would be made in Joules, as single-precision >> 32bit floats, with two values: min and max. Like this: >> > > Yes I do remember the discussion ... but I cannot see how this would > be helpful. Indeed, even if a node receives two RA-DIO messages from > parents that reports path-1 with energy G1 and path-2 with energy G2 > (we can discuss the packet format later on), in which way would that > help in the path selection process? It might very well be that the > path that consumes the most energy is to the one that is preferable ? > That's indeed tricky. I would let the definition of what is more preferable to some intelligent logic depending on the programmer of the context. We could struggle to compare a path with high energy cost yet low hopcount cost to a path with low energy cost yet high hopcount cost. Is P1 preferable over P2 or vice-versa? I think this is a question to which one can't answer without knowing the deployment context. It is exactly like the node's decision upon reception of a default route RA from two different routers - this decision is not imposed by the specifier, but by the specific context where this happens. Yours, Alex > > > Thanks. > > JP. > >>> 0 1 2 3 0 1 >>> 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Reserved | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Max Link Energy | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Min Link Energy | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Type: TBA (see [ICMPv6parms]) Energy Metric Option for IPv6 >>> Link. Length: Decimal 10. Reserved: Set to zero by sender and >>> ignored by receiver. Max Link Energy Single-precision 32bit >>> floating point number in binary interchange format (see >>> [IEEE754-2008] and [IEC60559-2.0]), a C 'float' type (see >>> [ISOIEC-C99]), and in network byte order. The value represents >>> the maximum energy, expressed in Joules, necessary to send a >>> packet of size 1280 bytes on this link. Min Link Energy >>> Single-precision floating point number representing the minimum >>> energy, expressed in Joules, necessary to send 1280 bytes on this >>> link. >> >> Alex >> >> > > From richard.kelsey@ember.com Fri Oct 9 11:14:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ACC228C15D for ; Fri, 9 Oct 2009 11:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuaEodw50of1 for ; Fri, 9 Oct 2009 11:13:59 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6D7843A67E2 for ; Fri, 9 Oct 2009 11:13:59 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 14:16:48 -0400 Date: Fri, 09 Oct 2009 14:14:13 -0400 Message-Id: <87bpkgbfka.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: X-OriginalArrivalTime: 09 Oct 2009 18:16:48.0084 (UTC) FILETIME=[AA67B940:01CA490C] Cc: roll@ietf.org Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 18:14:00 -0000 Julien, Date: Fri, 9 Oct 2009 15:14:18 +0200 From: "Julien Abeille (jabeille)" I have concerns about the use of NA to transport DAOs for the following reasons: - NAs are not routing messages - unsolicited NAs are not very frequent, hence using them for DAOs is not really piggybacking. We do not gain a lot by using them - NA are already pretty overloaded messages: they are used in 3 procedures, namely address resolution, NUD and DAD - NA processing is implementation wise complex enough because of the point above - implementation wise, coupling RPL with ND makes code much more complex. - the target address field in the NA uses 16 bytes without bringing a lot of value to RPL. I think using a new ICMP message to carry DAOs would be much better. What do people think? I agree that the choice of NA for DAOs needs some justification, at least. Besides a new ICMP, UDP to a well-known port is another option. -Richard Kelsey From pal@cs.stanford.edu Fri Oct 9 11:29:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F143A68DA for ; Fri, 9 Oct 2009 11:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxwQbNWJAzsM for ; Fri, 9 Oct 2009 11:29:14 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 871793A6827 for ; Fri, 9 Oct 2009 11:29:14 -0700 (PDT) Received: from [198.202.202.22] (helo=[172.19.170.99]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MwKEx-0007sD-2O; Fri, 09 Oct 2009 11:30:59 -0700 Message-Id: From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 10:20:05 -0700 References: <6A2A459175DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 56af2f4f3392d0c6288551f912431bb1 Cc: roll Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 18:29:15 -0000 On Oct 9, 2009, at 5:55 AM, Pascal Thubert (pthubert) wrote: > Hi: > > It seems widely accepted in this group that Loop avoidance in the =20 > control place should be kept simple but completed by a detection =20 > mechanism associated to the packets. This approach had been =20 > validated in CTP and DADR. > > After a number of discussions, here is a proposal. The proposal uses =20= > some info that is placed in the packet in the flow label. > It assumes that the flow label is reserved for the purpose of RPL =20 > and node interaction. In the flow label we place: > > Outwards : 1 bit > Sibling : 1 bit > Rank_error : 1 bit > DAO_Error : 1 bit > Rank : 8 bit > Instance ID : 8 bit > > Instance forwarding > Instance IDs is used to avoid loops between DAGs from different =20 > origins. > > InstanceID is placed by the source in the flow label. It MUST =20 > matched the DAG instance onto which the packet is placed by a =20 > router. The router MAY either change the instanceID to match the DAG =20= > that it is using for this packet or discard the packet. That =20 > decision is policy based. Default policy TBD. > > Idea? > > DAG inconsistency loop detection > The DAG is inconsistent is the packet direction does not match the =20 > rank relationship. > > A host MUST set the rank to FF. A router MUST place its rank in the =20= > flow label. > A node emitting a packet must reset the Rank_error bit and the =20 > Outwards bit. > A router MUST also reset the Outwards bit if it is using the default =20= > route inwards, either via a sibling or a parent, and set the bit if =20= > it is using a DAO route, either via a sibling or a child. > > A receiver detects an inconsistency if it receives a packet going =20 > inwards from a source with a lesser Rank, or outwards with a higher =20= > rank. > > Upon inconsistency, if the Rank_error bit was not set then the =20 > Rank_error bit is set. If it was set the packet is discarded. This =20 > is done to cover a rare re-sequencing of the DAG. > > Sibling loop avoidance > A simple rule is that a packet may not make 2 sibling hops in a row. > > When a host sends a packet or a router forwards to a non sibling, =20 > the Sibling bit must be reset. > When a router forwards to a sibling: if the Sibling bit was not set =20= > then the Sibling bit is set. If it was set then the packet is =20 > discarded. > > DAO inconsistency loop detection > A =93parent=94 has an outwards DAO route that is a remnant from an =20 > obsolete DAO via a =93child=94 but the =93child=94 does not have a = matching =20 > DOA state. > > In a general manner, a packet that goes outwards should never go =20 > inwards again. So rather than routing inwards a packet with the =20 > Outwards bit set, the router MUST discard the packet. If DAO =20 > recovery is in place, then the router MAY send it back to the source. > > DAO inconsistency loop recovery > A Router that supports recovery uses a packet to recursively explore =20= > and cleanup the obsolete paths. > > The =93child=94 router that detects the DAO inconsistency SHOULD set = the =20 > DAO_Error bit and return the packet to the parent that passed it. > > Upon a packet with a DAO bit set, the parent MUST remove the routing =20= > states that caused forwarding to the child that passed it, clear =20 > DAO_Error bit and send the packet again. > I advocate taking a more extreme approach: remove the current sequence =20= number loop prevention mechanisms from the draft. Currently, RPL is trying to have it both ways. It's using sequence =20 numbers to prevent (not just avoid) loops caused by increasing in =20 rank. However, by allowing nodes to choose siblings, RPL still =20 requires a loop detection mechanism in data packets. If there is a =20 mechanism to detect loops with data packets, then there is no need to =20= have rules on when nodes can increase rank: the decision of whether to =20= do so or not is a performance design choice. When we started designing CTP, we tried using sequence numbers as DSDV =20= does. The logic to handle all of the edge cases was non-trivial. In =20 particular, if node A has move to sequence number N+1, but its child B =20= is still on sequence number N, then on receiving a packet from child =20 B, A must forward it with tree N. That is, A must maintain two trees. =20= Overall, the edge cases were complex, required a good deal of code, =20 and had a lot of tricky edge cases. Furthermore, the prospect of being =20= floating until a sequence number increment created a difficult tension =20= between the longest interval a DAG could be floating and the cost of =20 periodically flooding DAG sequence number updates. If there is a way to detect and repair loops in the data path, then =20 this tension disappears. Loops become an efficiency problem, due to =20 the extra messages they send. Correspondingly, may protocols have an =20 inventive to follow the loop prevention guidelines in -03, if doing so =20= leads to overall better efficiency. But such algorithms and policies =20 are RECOMMENDED or OPTIONAL performance optimizations on top of a =20 specification, not part of the specification itself (e.g., think RFC =20 2581). In summary, I'd argue, that for the sake of simplicity in required =20 mechanisms, and flexibility in future implementation designs, that RPL =20= should either: 1) Disallow routing through siblings 2) Allow routing through nodes of higher rank I personally think 2) is a better approach, based on my experiences, =20 as it can remove the need for periodic sequence number increments. But =20= I think that the current half-way position is worse than either 1) or =20= 2): it has the worst of both worlds. If we make sequence number-based DAG control OPTIONAL, then I'd argue =20= we should elide it from the main RPL document. Keep the core =20 specification simple. Phil= From pal@cs.stanford.edu Fri Oct 9 12:20:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C073A67FC for ; Fri, 9 Oct 2009 12:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZFa2gObEPen for ; Fri, 9 Oct 2009 12:20:19 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 61E9F3A68CC for ; Fri, 9 Oct 2009 12:20:19 -0700 (PDT) Received: from [198.202.202.22] (helo=[172.19.170.99]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MwL2Q-0005Vu-Id; Fri, 09 Oct 2009 12:22:04 -0700 Message-Id: From: Philip Levis To: Mukul Goyal In-Reply-To: <235757746.16320661255103614862.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 9 Oct 2009 12:21:52 -0700 References: <235757746.16320661255103614862.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 19:20:20 -0000 On Oct 9, 2009, at 8:53 AM, Mukul Goyal wrote: > Some time back, we did the following calculations: > > 1) use standard formulae to obtain bit error rates (for O-QPSK under > AWGN, Raleigh and Rician fading models) for different SNR values > 2) convert bit error rates to symbol error rates (using the Hamming > distance among valid symbol codes (32 chip long) 802.15.4 uses) > 3) convert symbol error rates to packet error rates (assuming 127 > byte packets) > > The resulting graphs with SNR on x-axis and bit/symbol/packet error > rates on y-axis can be seen towards the end of: > > www.cs.uwm.edu/~mukul/rssi.doc > > They basically confirm what Richard said about the rapid change in > packet error rates with slight change in SNR. Yes, the curve is sharp. Figure 8 in this paper[1] shows the curve found from direct measurements on two 15.4 nodes using a shielded environment and a variable attenuator. It shows a similarly sharp curve (theory and practice agree). But be careful -- both the analysis and measurement assume that there is no interference, something which an LLN cannot assume. It is possible to have a very high SINR and a poor packet reception ratio. While very small swings in signal strength can make wireless links transition from poor to good or vice versa, interference can easily have a much more gradual effect. Phil [1] Kannan Srinivasan, Prabal Dutta, Arsalan Tavakoli, and Philip Levis. "An Empirical Study of Low-Power Wireless." To appear in "ACM Transactions on Sensor Networks." http://sing.stanford.edu/pubs/tosn.pdf From richard.kelsey@ember.com Fri Oct 9 13:21:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6023A65A6 for ; Fri, 9 Oct 2009 13:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnk6Jcu309hx for ; Fri, 9 Oct 2009 13:21:36 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B988C28C0F8 for ; Fri, 9 Oct 2009 13:21:36 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 16:24:25 -0400 Date: Fri, 09 Oct 2009 16:21:50 -0400 Message-Id: <87ab00l3mp.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Fri, 9 Oct 2009 10:20:05 -0700) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 09 Oct 2009 20:24:25.0665 (UTC) FILETIME=[7EADDB10:01CA491E] Cc: roll@ietf.org Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 09 Oct 2009 20:21:37 -0000 From: Philip Levis Date: Fri, 9 Oct 2009 10:20:05 -0700 When we started designing CTP, we tried using sequence numbers as DSDV does. The logic to handle all of the edge cases was non-trivial. In particular, if node A has move to sequence number N+1, but its child B is still on sequence number N, then on receiving a packet from child B, A must forward it with tree N. That is, A must maintain two trees. A can safely forward the packet to its current, N+1, parent. No looping can occur. Overall, the edge cases were complex, required a good deal of code, and had a lot of tricky edge cases. I don't follow you. As I understand and use the sequence number algorithm, a node only needs to maintain one parent (tree) or set of parents (DAG). The only requirement is that a node not advertise a sequence number more recent than any of its parents. Packets are forwarded to any current parent. Where do the tricky edge cases come in? To take the example above, all of A's parents must be at N+1 or higher. Transitively, all of A's ancestors must be at N+1 or higher. Because B is at N, B cannot be an ancestor of A. In summary, I'd argue, that for the sake of simplicity in required mechanisms, and flexibility in future implementation designs, that RPL should either: 1) Disallow routing through siblings 2) Allow routing through nodes of higher rank I personally think 2) is a better approach, based on my experiences, as it can remove the need for periodic sequence number increments. But I think that the current half-way position is worse than either 1) or 2): it has the worst of both worlds. I pretty much agree with you, except that I think 1) is the better approach. -Richard Kelsey From jvasseur@cisco.com Fri Oct 9 23:21:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA1233A67AB for ; Fri, 9 Oct 2009 23:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.787 X-Spam-Level: X-Spam-Status: No, score=-9.787 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Xojv2UJZdXt for ; Fri, 9 Oct 2009 23:21:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2C7923A677C for ; Fri, 9 Oct 2009 23:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3850; q=dns/txt; s=amsiport01001; t=1255155811; x=1256365411; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Sat,=2010=20Oct =202009=2008:23:27=20+0200|Message-Id:=20<2F8F6405-4B87-4 A62-9040-717A5D956B42@cisco.com>|To:=20Alexandru=20Petres cu=20|Cc:=20Richard=20Kelse y=20,=20roll@ietf.org,=0D=0A=20 =20=20=20=20=20=20=20kpister@dustnetworks.com |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4ACF754C.2000604@gmail.com>|References: =20=09<87ljjmapxh.fsf@kelsey-ws.hq.ember.com> =20=20<4A CF754C.2000604@gmail.com>; bh=5jQQfOFVSY2ig3Ag79hCrzRXItb1okH0C6C0lDXjEWc=; b=kjCAs5CBPjeoAFYTGZAqXuyhcv0a1buBm1QhomNzLa87meluJ2BKLhD2 1O/jcA0oNF7hP+QN2gmOhQl8uhBNhRh7Kmj/eC+e+EbWIsoys1ibARK/M abqs4wcN44hOj6ALKwIt8o8hVTJ2Te7+ZEdAFlAm9frHmbJQRdjC0qh+l s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQAAJrFz0qQ/uCWe2dsb2JhbACbDAEBFiQGpVeJDwiPAIJFCIFgBA X-IronPort-AV: E=Sophos;i="4.44,536,1249257600"; d="scan'208";a="51437242" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2009 06:23:29 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9A6NTHp015092; Sat, 10 Oct 2009 06:23:29 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 08:23:29 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 08:23:28 +0200 Message-Id: <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4ACF754C.2000604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 08:23:27 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Oct 2009 06:23:28.0662 (UTC) FILETIME=[2E5FF360:01CA4972] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16938.003 X-TM-AS-Result: No--25.933500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 10 Oct 2009 06:21:46 -0000 Hi Alex, On Oct 9, 2009, at 7:39 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi Richard, >> On Oct 8, 2009, at 5:03 PM, Richard Kelsey wrote: >>> Jerry, >>> From: Jerald.P.Martocci@jci.com Date: Thu, 8 Oct 2009 08:19:33 >>> -0500 >>> Per your question, our current implementation uses standard ZigBee =20= >>> algorithms. ZigBee bases path costs on RSSI only. >>> No, ZigBee's path costs are based on the probability of packet >>> reception over the link. See Section 3.6.3.1 of the ZigBee spec. >>> RSSI above the noise floor could be used to estimate that >>> probability, of course. Raw RSSI doesn't tell you very much. >> Right. What we need to define is metric that describes the >> probability of packet delivery ratio along the path. > > JP, that is your definition of what's needed and I respectfully =20 > disagree. > How can you disagree without knowing what is needed ;-) (smiley). There is a consensus that a reliability metric is needed (note that we =20= are not limited to radio links). Several metrics have been used for years such as ETX. > PAcket delivery ratio is something which equals "best effort" i.e. =20 > it has no number quantifying it. > > Energy? Energy is something different, and doesn't relate to "best =20= > effort" - it can be quantified. > > Alex > > > Since RPL is a >> distance vector, we would use a cumulative metric. Of course, each >> node should filter out the transient error rate and periodicity of >> the metric update should be limited to avoid routing metric but this >> not specific to the reliability metric. It is true for all dynamic >> metrics. >> The objective is thus to define a cumulative reliability metric =20 >> reflecting the probability of success path delivery, in units >> independent of the Link layer. Local mechanisms to filter out local >> transient phenomena are left to implementation specific decisions. >> Make sense ? >>> Our product was developed and deployed in 2006. We used what is >>> termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has >>> developed the 'ZigBee PRO' stack which will in time subsume the >>> ZigBee Stack. ZigBee PRO selects paths based on the best symmetric >>> path found. I believe asymmetric paths are discarded or only used >>> as a last resort. >>> Not quite. ZigBee PRO only requires that the cost assigned to an >>> asymmetric link be the worse of the two unidirectional costs. >> Makes sense. We had a discussion on this too, and it was decided not >> to take it into account for the time being. >>> Unfortunately, I have no empirical or simulation data on this =20 >>> metric. Maybe Richard can provide some insight on this approach =20 >>> since I believe it was championed by Ember. >>> Ember and Mitsubishi proposed the solution that was adopted =20 >>> (exchanging link costs with neighbors). The actual problem that it >>> solved was first raised by Ghulam Bhatti of Mitsubishi, if I >>> remember correctly. Under certain circumstances having the two >>> ends of a link use different costs could cause ZigBee's P2P routing >>> to consistently fail to discover a route. The problem was fairly >>> fundamental to ZigBee's P2P mechanism, and given the other >>> advantages of identifying asymmetries and knowing more about your >>> local neighborhood, ZigBee added a feature where nodes inform their >>> neighbors of their link costs. This seems like something that >>> could be done at the link layer. >> Yes. >> JP. >>> -Richard Kelsey >>> _______________________________________________ Roll mailing list = Roll@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ Roll mailing list = Roll@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/roll > > From jvasseur@cisco.com Fri Oct 9 23:27:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728603A6828 for ; Fri, 9 Oct 2009 23:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.713 X-Spam-Level: X-Spam-Status: No, score=-8.713 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXkUKEvtQ1+N for ; Fri, 9 Oct 2009 23:27:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A4A793A672E for ; Fri, 9 Oct 2009 23:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=5049; q=dns/txt; s=amsiport01001; t=1255156140; x=1256365740; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20I-D|Date:=20Sat,=2010=20Oct =202009=2008:26:56=20+0200|Message-Id:=20|To:=20Alexandru=20Petres cu=20|Cc:=20IETF=20ROLL=20< roll@ietf.org>,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20 v936)|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4ACF78A9.8040405@gmail.com>|References: =20=20<4A CDF4C6.5020109@gmail.com>=20<42382722-B852-4B20-A3D3-4C2E 4C4FF871@cisco.com>=20<4ACF78A9.8040405@gmail.com>; bh=/4OXbH8KiuPOqXI6X55Y5ntcF0teUP4y0ufYrkzPp54=; b=KWzsp8niPw1Q3IkW5LQwD4umUYMf3RjpgWJqtZ39QzVxSKl3AsJITnGm cRu4k+JunCETb8obM1bj3jP1zL5v4Loq4H2AzGJDPuQxh+uUaKwgur+WN VSx7ZSoWWJvuUyuU6+dOLWWJwg8ISbe98j1ez9jMpjqexjxGO0H9yXPkg I=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQAAMbGz0qQ/uCWe2dsb2JhbACbDAEBFiQGpVqJDwiPAIJFCIFgBIFY X-IronPort-AV: E=Sophos;i="4.44,536,1249257600"; d="scan'208";a="51437336" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2009 06:28:58 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9A6Sw3t015539; Sat, 10 Oct 2009 06:28:58 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 08:28:58 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 08:28:58 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4ACF78A9.8040405@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 08:26:56 +0200 References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Oct 2009 06:28:58.0229 (UTC) FILETIME=[F2CFE250:01CA4972] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16938.003 X-TM-AS-Result: No--8.681600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 10 Oct 2009 06:27:15 -0000 Hi Alex, On Oct 9, 2009, at 7:53 PM, Alexandru Petrescu wrote: > Hi JP, > > JP Vasseur a =E9crit : >> Hi Alex, >> On Oct 8, 2009, at 4:18 PM, Alexandru Petrescu wrote: >>> Hi JP, >>> I am attracted by the subject of the mail, it is about Metric I-D =20= >>> (Internet Draft). However, I am not sure what are you asking for? >> Which metric should be defined for RPL (link and node). Note that =20 >> we have several metrics already defined, but still a few TBD. > > Do you have a metric which says "energy needed to send a packet on an > interface"? I don't think you do. I think your draft briefly alludes > to energy cost of sending and receiving packets (presumably on a =20 > link), > but falls short in defining one as such. > > To cite your draft: >> Raw power and energy values are meaningless without knowledge of the >> energy cost of sending and receiving packets > > Yet the table of contents says: The draft has not been updated for quite some time, since we were =20 waiting to progress first on RPL of course. The next revision will be significantly fleshed out. >> 4. Link Metrics and =20 >> Attributes . . . . . . . . . . . . . . . . . 8 >> 4.1. =20 >> Throughput . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 4.2. =20 >> Latency . . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 4.3. Link =20 >> reliability . . . . . . . . . . . . . . . . . . . . . 9 >> 4.4. Link =20 >> Coloring . . . . . . . . . . . . . . . . . . . . . . 9 > > Where is the link energy metric I am proposing and of which your draft > seems to be hinting at? > >>> I still suggest to have link metrics taken into account by ICMP, =20 >>> routing protocols _and_ RPL. >> Not sure why you refer to ICMP here but back to RPL ... > > BEcause I think it would be good if a metric invented for one protocol > could be reused by another protocol. Ah ... why not, but this is not an objective. > >>> These link metrics would express the energy needed to send a =20 >>> certain amount of bytes on a certain interface, or on a certain =20 >>> path. The exression would be made in Joules, as single-precision =20= >>> 32bit floats, with two values: min and max. Like this: >> Yes I do remember the discussion ... but I cannot see how this =20 >> would be helpful. Indeed, even if a node receives two RA-DIO =20 >> messages from parents that reports path-1 with energy G1 and path-2 =20= >> with energy G2 (we can discuss the packet format later on), in =20 >> which way would that help in the path selection process? It might =20 >> very well be that the path that consumes the most energy is to the =20= >> one that is preferable ? > That's indeed tricky. I would let the definition of what is more > preferable to some intelligent logic depending on the programmer of =20= > the > context. > > We could struggle to compare a path with high energy cost yet low > hopcount cost to a path with low energy cost yet high hopcount cost. =20= > Is > P1 preferable over P2 or vice-versa? > > I think this is a question to which one can't answer without knowing =20= > the > deployment context. > Well at least we need one example where it could be useful. I can't =20 find of any personally. What matters is how much of energy left you have, not how much of =20 energy you may consume, no ? Thanks. JP. > It is exactly like the node's decision upon reception of a default =20 > route > RA from two different routers - this decision is not imposed by the > specifier, but by the specific context where this happens. > > Yours, > > Alex > >> Thanks. >> JP. >>>> 0 1 2 3 0 1 >>>> 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type | Length | Reserved | +-+-+-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Max Link Energy | +-+-+-+-+-+-+-+-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Min Link Energy | +-+-+-+-+-+-+-+-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> Type: TBA (see [ICMPv6parms]) Energy Metric Option for IPv6 Link. =20= >>>> Length: Decimal 10. Reserved: Set to zero by sender and ignored =20 >>>> by receiver. Max Link Energy Single-precision 32bit floating =20 >>>> point number in binary interchange format (see [IEEE754-2008] and =20= >>>> [IEC60559-2.0]), a C 'float' type (see [ISOIEC-C99]), and in =20 >>>> network byte order. The value represents the maximum energy, =20 >>>> expressed in Joules, necessary to send a packet of size 1280 =20 >>>> bytes on this link. Min Link Energy Single-precision floating =20 >>>> point number representing the minimum energy, expressed in =20 >>>> Joules, necessary to send 1280 bytes on this >>>> link. >>> Alex > > From jvasseur@cisco.com Fri Oct 9 23:27:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAC93A672E for ; Fri, 9 Oct 2009 23:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.71 X-Spam-Level: X-Spam-Status: No, score=-8.71 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srlSyp3PxPhK for ; Fri, 9 Oct 2009 23:27:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 550D83A6857 for ; Fri, 9 Oct 2009 23:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=5044; q=dns/txt; s=amsiport01001; t=1255156145; x=1256365745; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20I-D|Date:=20Sat,=2010=20Oct =202009=2008:29:01=20+0200|Message-Id:=20|To:=20Alexandru=20Petres cu=20|Cc:=20IETF=20ROLL=20< roll@ietf.org>,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20 v936)|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4ACF78A9.8040405@gmail.com>|References: =20=20<4A CDF4C6.5020109@gmail.com>=20<42382722-B852-4B20-A3D3-4C2E 4C4FF871@cisco.com>=20<4ACF78A9.8040405@gmail.com>; bh=prrM1fWxeSmt+v18+qE8tq9V1Ti2yz7KC6iWpxD6kqg=; b=qeIZcKtut/yRo8KAOk0grXqT2NQED3CYrWgNh+XOdk6mnJ79s42TpPt9 1Yo23l8YQuLnCVtpSQXbcCglJb5OX6HB5hulwWrITz2UoSd1/pT9wVG21 EVcoIVmZ+BRg7uIRWfkyLVaQtHIWp1bhoB80Gg1jvdXPPdZAFttCkUBAy 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQAAMbGz0qQ/uCWe2dsb2JhbACbDAEBFiQGpVqJDwiPAIJFCIFgBIFY X-IronPort-AV: E=Sophos;i="4.44,536,1249257600"; d="scan'208";a="51437348" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Oct 2009 06:29:04 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9A6T4wq015567; Sat, 10 Oct 2009 06:29:04 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 08:29:04 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Oct 2009 08:29:04 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4ACF78A9.8040405@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 08:29:01 +0200 References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Oct 2009 06:29:04.0151 (UTC) FILETIME=[F6578270:01CA4972] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16938.003 X-TM-AS-Result: No--8.681600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 10 Oct 2009 06:27:20 -0000 Hi Alex, On Oct 9, 2009, at 7:53 PM, Alexandru Petrescu wrote: > Hi JP, > > JP Vasseur a =E9crit : >> Hi Alex, >> On Oct 8, 2009, at 4:18 PM, Alexandru Petrescu wrote: >>> Hi JP, >>> I am attracted by the subject of the mail, it is about Metric I-D =20= >>> (Internet Draft). However, I am not sure what are you asking for? >> Which metric should be defined for RPL (link and node). Note that =20 >> we have several metrics already defined, but still a few TBD. > > Do you have a metric which says "energy needed to send a packet on an > interface"? I don't think you do. I think your draft briefly alludes > to energy cost of sending and receiving packets (presumably on a =20 > link), > but falls short in defining one as such. > > To cite your draft: >> Raw power and energy values are meaningless without knowledge of the >> energy cost of sending and receiving packets > > Yet the table of contents says: The draft has not been updated for quite some time, since we were =20 waiting to progress first on RPL of course. The next revision will be significantly fleshed out. >> 4. Link Metrics and =20 >> Attributes . . . . . . . . . . . . . . . . . 8 >> 4.1. =20 >> Throughput . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 4.2. =20 >> Latency . . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 4.3. Link =20 >> reliability . . . . . . . . . . . . . . . . . . . . . 9 >> 4.4. Link =20 >> Coloring . . . . . . . . . . . . . . . . . . . . . . 9 > > Where is the link energy metric I am proposing and of which your draft > seems to be hinting at? > >>> I still suggest to have link metrics taken into account by ICMP, =20 >>> routing protocols _and_ RPL. >> Not sure why you refer to ICMP here but back to RPL ... > > BEcause I think it would be good if a metric invented for one protocol > could be reused by another protocol. Ah ... why not, but this is not an objective. > >>> These link metrics would express the energy needed to send a =20 >>> certain amount of bytes on a certain interface, or on a certain =20 >>> path. The exression would be made in Joules, as single-precision =20= >>> 32bit floats, with two values: min and max. Like this: >> Yes I do remember the discussion ... but I cannot see how this =20 >> would be helpful. Indeed, even if a node receives two RA-DIO =20 >> messages from parents that reports path-1 with energy G1 and path-2 =20= >> with energy G2 (we can discuss the packet format later on), in =20 >> which way would that help in the path selection process? It might =20 >> very well be that the path that consumes the most energy is to the =20= >> one that is preferable ? > That's indeed tricky. I would let the definition of what is more > preferable to some intelligent logic depending on the programmer of =20= > the > context. > > We could struggle to compare a path with high energy cost yet low > hopcount cost to a path with low energy cost yet high hopcount cost. =20= > Is > P1 preferable over P2 or vice-versa? > > I think this is a question to which one can't answer without knowing =20= > the > deployment context. > Well at least we need one example where it could be useful. I can't =20 find of any personally. What matters is how much of energy left you have, not how much of =20 energy you may consume, no ? Thanks. JP. > It is exactly like the node's decision upon reception of a default =20 > route > RA from two different routers - this decision is not imposed by the > specifier, but by the specific context where this happens. > > Yours, > > Alex > >> Thanks. >> JP. >>>> 0 1 2 3 0 1 >>>> 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type | Length | Reserved | +-+-+-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Max Link Energy | +-+-+-+-+-+-+-+-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Min Link Energy | +-+-+-+-+-+-+-+-+-+-=20= >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> Type: TBA (see [ICMPv6parms]) Energy Metric Option for IPv6 Link. =20= >>>> Length: Decimal 10. Reserved: Set to zero by sender and ignored =20 >>>> by receiver. Max Link Energy Single-precision 32bit floating =20 >>>> point number in binary interchange format (see [IEEE754-2008] and =20= >>>> [IEC60559-2.0]), a C 'float' type (see [ISOIEC-C99]), and in =20 >>>> network byte order. The value represents the maximum energy, =20 >>>> expressed in Joules, necessary to send a packet of size 1280 =20 >>>> bytes on this link. Min Link Energy Single-precision floating =20 >>>> point number representing the minimum energy, expressed in =20 >>>> Joules, necessary to send 1280 bytes on this >>>> link. >>> Alex > > From prvs=5278a2b7b=mukul@uwm.edu Sat Oct 10 07:55:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82073A6958 for ; Sat, 10 Oct 2009 07:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOuH8vLE0rBf for ; Sat, 10 Oct 2009 07:55:22 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 7DEBE3A685F for ; Sat, 10 Oct 2009 07:55:22 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 10 Oct 2009 09:57:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 8B089C085CB; Sat, 10 Oct 2009 09:57:07 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nlb7Ujc6Ei-j; Sat, 10 Oct 2009 09:57:07 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 231E8C085DE; Sat, 10 Oct 2009 09:57:07 -0500 (CDT) Date: Sat, 10 Oct 2009 09:57:07 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1443022293.16564611255186627055.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1999865098.16564421255186501838.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 10 Oct 2009 14:55:41 -0000 Philip I agree with you. Loop avoidance/prevention/detection should not be in the = base specs. Another positive implication of your approach would be that 'ra= nk', rather than being a loop avoidance mechanism, would simply be the cost= to reach the dag root under the routing metrics being used. Lets agree tha= t we dont want to solve "count to infinity" problem in base specs. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Pascal Thubert (pthubert)" Cc: "roll" Sent: Friday, October 9, 2009 12:20:05 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and re= covery On Oct 9, 2009, at 5:55 AM, Pascal Thubert (pthubert) wrote: > Hi: > > It seems widely accepted in this group that Loop avoidance in the =20 > control place should be kept simple but completed by a detection =20 > mechanism associated to the packets. This approach had been =20 > validated in CTP and DADR. > > After a number of discussions, here is a proposal. The proposal uses =20 > some info that is placed in the packet in the flow label. > It assumes that the flow label is reserved for the purpose of RPL =20 > and node interaction. In the flow label we place: > > Outwards : 1 bit > Sibling : 1 bit > Rank_error : 1 bit > DAO_Error : 1 bit > Rank : 8 bit > Instance ID : 8 bit > > Instance forwarding > Instance IDs is used to avoid loops between DAGs from different =20 > origins. > > InstanceID is placed by the source in the flow label. It MUST =20 > matched the DAG instance onto which the packet is placed by a =20 > router. The router MAY either change the instanceID to match the DAG =20 > that it is using for this packet or discard the packet. That =20 > decision is policy based. Default policy TBD. > > Idea? > > DAG inconsistency loop detection > The DAG is inconsistent is the packet direction does not match the =20 > rank relationship. > > A host MUST set the rank to FF. A router MUST place its rank in the =20 > flow label. > A node emitting a packet must reset the Rank_error bit and the =20 > Outwards bit. > A router MUST also reset the Outwards bit if it is using the default =20 > route inwards, either via a sibling or a parent, and set the bit if =20 > it is using a DAO route, either via a sibling or a child. > > A receiver detects an inconsistency if it receives a packet going =20 > inwards from a source with a lesser Rank, or outwards with a higher =20 > rank. > > Upon inconsistency, if the Rank_error bit was not set then the =20 > Rank_error bit is set. If it was set the packet is discarded. This =20 > is done to cover a rare re-sequencing of the DAG. > > Sibling loop avoidance > A simple rule is that a packet may not make 2 sibling hops in a row. > > When a host sends a packet or a router forwards to a non sibling, =20 > the Sibling bit must be reset. > When a router forwards to a sibling: if the Sibling bit was not set =20 > then the Sibling bit is set. If it was set then the packet is =20 > discarded. > > DAO inconsistency loop detection > A =E2=80=9Cparent=E2=80=9D has an outwards DAO route that is a remnant fr= om an =20 > obsolete DAO via a =E2=80=9Cchild=E2=80=9D but the =E2=80=9Cchild=E2=80= =9D does not have a matching =20 > DOA state. > > In a general manner, a packet that goes outwards should never go =20 > inwards again. So rather than routing inwards a packet with the =20 > Outwards bit set, the router MUST discard the packet. If DAO =20 > recovery is in place, then the router MAY send it back to the source. > > DAO inconsistency loop recovery > A Router that supports recovery uses a packet to recursively explore =20 > and cleanup the obsolete paths. > > The =E2=80=9Cchild=E2=80=9D router that detects the DAO inconsistency SHO= ULD set the =20 > DAO_Error bit and return the packet to the parent that passed it. > > Upon a packet with a DAO bit set, the parent MUST remove the routing =20 > states that caused forwarding to the child that passed it, clear =20 > DAO_Error bit and send the packet again. > I advocate taking a more extreme approach: remove the current sequence =20 number loop prevention mechanisms from the draft. Currently, RPL is trying to have it both ways. It's using sequence =20 numbers to prevent (not just avoid) loops caused by increasing in =20 rank. However, by allowing nodes to choose siblings, RPL still =20 requires a loop detection mechanism in data packets. If there is a =20 mechanism to detect loops with data packets, then there is no need to =20 have rules on when nodes can increase rank: the decision of whether to =20 do so or not is a performance design choice. When we started designing CTP, we tried using sequence numbers as DSDV =20 does. The logic to handle all of the edge cases was non-trivial. In =20 particular, if node A has move to sequence number N+1, but its child B =20 is still on sequence number N, then on receiving a packet from child =20 B, A must forward it with tree N. That is, A must maintain two trees. =20 Overall, the edge cases were complex, required a good deal of code, =20 and had a lot of tricky edge cases. Furthermore, the prospect of being =20 floating until a sequence number increment created a difficult tension =20 between the longest interval a DAG could be floating and the cost of =20 periodically flooding DAG sequence number updates. If there is a way to detect and repair loops in the data path, then =20 this tension disappears. Loops become an efficiency problem, due to =20 the extra messages they send. Correspondingly, may protocols have an =20 inventive to follow the loop prevention guidelines in -03, if doing so =20 leads to overall better efficiency. But such algorithms and policies =20 are RECOMMENDED or OPTIONAL performance optimizations on top of a =20 specification, not part of the specification itself (e.g., think RFC =20 2581). In summary, I'd argue, that for the sake of simplicity in required =20 mechanisms, and flexibility in future implementation designs, that RPL =20 should either: 1) Disallow routing through siblings 2) Allow routing through nodes of higher rank I personally think 2) is a better approach, based on my experiences, =20 as it can remove the need for periodic sequence number increments. But =20 I think that the current half-way position is worse than either 1) or =20 2): it has the worst of both worlds. If we make sequence number-based DAG control OPTIONAL, then I'd argue =20 we should elide it from the main RPL document. Keep the core =20 specification simple. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=5278a2b7b=mukul@uwm.edu Sat Oct 10 09:30:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3FEC28C0DE for ; Sat, 10 Oct 2009 09:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcjE7l2CIiSW for ; Sat, 10 Oct 2009 09:30:16 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id D17FB28C0D6 for ; Sat, 10 Oct 2009 09:30:15 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 10 Oct 2009 11:32:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id B4DBBC085C8; Sat, 10 Oct 2009 11:32:02 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puAHG67ITX+r; Sat, 10 Oct 2009 11:32:02 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 79541C085A0; Sat, 10 Oct 2009 11:32:02 -0500 (CDT) Date: Sat, 10 Oct 2009 11:32:02 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <985674239.16574561255192322411.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1241945725.16574101255192127411.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] DAG hop timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 10 Oct 2009 16:30:16 -0000 Pascal Now that we agree on having just one DAG hop timer, here is a further suggestion: Right now, the DAG hop timer is scheduled to fire after a delay that is proportional to the rank of the candidate parent (lets call it rank) whose RA-DIO triggers the starting of the timer. DAG hop timer value = random number between rank*DagDelay and (rank+1)*DagDelay If DAG hop timer is expected to help in loop avoidance, the node (say A) should generate a new RA-DIO advertising its own floating DAG when it starts the DAG hop timer. All the children nodes will hopefully receive this RA-DIO and decide whether to kick node A out of the parent set or leave the current DAG and join A's floating DAG. As soon as they make this decision, they will generate their RA-DIO either immediately or within I_min interval, where I_min is the minimum trickle timer value. So, the nodes at level 'n' in A's sub-dag are expected to generate new RA-DIOs within n*I_min interval. So, node A can expect to receive an RA-DIO from a neighbor within few multiples of I_min if that neighbor was in its sub-DAG. So, I would think that DAG hop timer value should be a safe multiple of I_min (independent of the dag rank of the candidate parent). I understand that the decision to make DAG hop timer value proportional to candidate parent's rank was influenced by the desire to: 1) make a node join the DAG at minimum possible rank and 2) allow nodes at lower rank to join before the nodes at higher rank If we are not resetting the DAG hop timer every time we come to know of a lower ranked candidate, we already agreed to give up on the second objective above. If we make DAG hop timer value a safe multiple of I_min (independent of the dag rank of the candidate parent that cause the timer to start), objective (1) above is still achievable to roughly the same degree as with current way of setting up DAG hop timer. What do folks think? Thanks Mukul PS: I am not implying that DAG hop timers should be in base specs. I believe that this feature is a useful OPTION. ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "roll" Sent: Monday, October 5, 2009 9:33:27 AM GMT -06:00 US/Canada Central Subject: RE: DAG hop timers Hi Mukul, Yes, that is conceptually identical. There's a real need for one timer per DAG that the node might want to jump onto. When a timer elapses, the node joins the best position that it knows of in the new DAG. That can be done because regardless of the candidate parent for which the timer fired that just elapsed, the node is now allowed to join that DAG. Since moving inwards can be done without delay the node can pick the best position it sees right away. Pascal >-----Original Message----- >From: Mukul Goyal [mailto:mukul@uwm.edu] >Sent: samedi 3 octobre 2009 20:45 >To: Pascal Thubert (pthubert) >Cc: roll >Subject: DAG hop timers > >Hi Pascal > >Current RPL specs require a separate DAG hop timer for each neighbor in held_up state. All these timers are >stopped as soon as one of the timers fires. There is no guarantee that the timer for the neighbor with minimum >rank will fire first. If the timer for some other neighbor fires first, the node will have to wait for next RA >from minimum-rank neighbor to include it as a parent. > >How about running just one timer. When a neighbor with lower rank is discovered, the current timer is stopped >and restarted with a delay proportional to this lower rank. This ensures that the neighbor with lowest rank >will be chosen as parent. Also, only one timer will be required. > >Thanks >Mukul From pal@cs.stanford.edu Sat Oct 10 12:10:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533F828C0EE for ; Sat, 10 Oct 2009 12:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuSlEUalSpsA for ; Sat, 10 Oct 2009 12:10:10 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 974003A6830 for ; Sat, 10 Oct 2009 12:10:10 -0700 (PDT) Received: from [76.75.8.40] (helo=[172.17.143.249]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MwhMD-0006Im-VJ; Sat, 10 Oct 2009 12:11:58 -0700 Message-Id: <54371184-51BD-41C8-AF29-7739DA2267D9@cs.stanford.edu> From: Philip Levis To: Richard Kelsey In-Reply-To: <87ab00l3mp.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 10 Oct 2009 12:11:54 -0700 References: <6A2A459175DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com> <87ab00l3mp.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 10 Oct 2009 19:10:11 -0000 On Oct 9, 2009, at 1:21 PM, Richard Kelsey wrote: > From: Philip Levis > Date: Fri, 9 Oct 2009 10:20:05 -0700 > > When we started designing CTP, we tried using sequence numbers as > DSDV > does. The logic to handle all of the edge cases was non-trivial. In > particular, if node A has move to sequence number N+1, but its > child B > is still on sequence number N, then on receiving a packet from child > B, A must forward it with tree N. That is, A must maintain two > trees. > > A can safely forward the packet to its current, N+1, parent. > No looping can occur. Node A is version N. Node B is version N. Node A forwards a packet to node B. Node A receives a beacon with N+1. Node A sends a beacon with N+1, which node B hears. Node B forwards the packet to node A. Assuming that the sequence number space is stable, the problem will of course work itself out. But in some initial tests, we found that loops such as these (note this is just two nodes, when using sequence number increments you can have routes with very high stretch while the network reconfigures) could significantly increase the cost (transmissions/delivery). A couple of heuristics can help. E.g., if you have sequence number N when you receive a packet, then you should forward that packet as if you were still number N. Phil From mcr@marajade.sandelman.ca Sat Oct 10 17:59:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B791C3A67B2 for ; Sat, 10 Oct 2009 17:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[AWL=-1.811, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ2KGeo-9ltU for ; Sat, 10 Oct 2009 17:59:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B08793A67C1 for ; Sat, 10 Oct 2009 17:59:50 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.198]) by relay.sandelman.ca (Postfix) with ESMTPS id 35DBF3428F for ; Sun, 11 Oct 2009 01:05:56 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 217174E7F9 for ; Sat, 10 Oct 2009 21:01:37 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <87bpkgbfka.fsf@kelsey-ws.hq.ember.com> References: <87bpkgbfka.fsf@kelsey-ws.hq.ember.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Sat, 10 Oct 2009 21:01:37 -0400 Message-ID: <19409.1255222897@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 11 Oct 2009 00:59:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Richard" == Richard Kelsey writes: Richard> I agree that the choice of NA for DAOs needs some Richard> justification, at least. Besides a new ICMP, UDP to a Richard> well-known port is another option. Maybe a different ICMP, but a UDP is probably not a good idea. I know that people have lots of bad experiences in v4 with things not TCP or UDP (often due to some comodity operating systems making it very hard to do anything different -- my history is IPsec, and multicast), but this is a greenfield IPv6 situation. We should not have to break the architecture at this point. I am curious about those who believe that processing the DAOs is going to be hard. Last week I put up some test code to determine how hard this was going to be in a Linux kernel -- the Linux kernel processes RA in the kernel directly (vs the *BSD kernels, where rtsold does the work). I have no idea what other systems do, but the following code was enough for me to see all ND and RS/RA packets in userland, without any modifications to the kernel. main() { int s = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6); char b[2048]; int len, n; if(s < 0) { perror("socket"); exit(10); } n=0; while((len = recv(s, b, 2048, 0)) >= 0) { printf("\nPacket(%u,%u):\n", n, len); hexdump(b, 0, len); n++; } perror("recv"); } - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStEuboCLcPvd0N1lAQKPQQf+LuWGVchwOu5yg127+5d2rz8+LiyZws+V o6tW1HXox1HarXnj+tJkLG9v5ibtymxxIBUxP4Y78ly92r2fqkYfM8mshol9Jnpq HXOD0sMDd1Tlvm1PILzqAhHiZmQkkYSJ7TupLQs/qs736TSjBIdvrVZuEmysbkzr 9QZlhBimYA6vAKZncq+pMple7zvXIuRe4atbHWTL84PLqtTYsCfHxVsLhanqTu/K G/DJsjj9zKrvUHXC33c1+wF0YTjWe/eFwS4RH4g4SMcF8noy6L7TaBdlvajjoI2F rq/THV9TkHOTo5koOrt5DtzDl4C9X1AcODVeeGc01g0xE1KklQnF7g== =CVIa -----END PGP SIGNATURE----- From pthubert@cisco.com Sun Oct 11 23:23:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C5A28C100 for ; Sun, 11 Oct 2009 23:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20th+56xmhDb for ; Sun, 11 Oct 2009 23:23:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 35F453A6407 for ; Sun, 11 Oct 2009 23:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8832; q=dns/txt; s=amsiport01001; t=1255328634; x=1256538234; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Mon,=2012=20Oct=202009=2008:23:48=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XM B-AMS-107.cisco.com>|To:=20"Julien=20Abeille=20(jabeille) "=20,=0D=0A=20=20=20=20=20=20=20=20"I ETF=20ROLL"=20|MIME-Version:=201.0 |In-Reply-To:=20|References:=20; bh=TOe0ayFfTyVnIIbrDLmJR8m+AfZELCRlTgXUUWdcTiU=; b=goPx9JZrz98c+CtK8EYkylz40RrKrEFKSb7mT53ZwwYAefqegHjJzH5d fpgnR0f3qrNlXVrnJLmWs70w0DF/5R6t5HO3GvDYnadTYDl9HXAMvgQA6 ez1RXU+/AvVvTKzNn9/RX62ka2jMapUzN/w0J4jDagbnupQiHmV+RVo6f c=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0AAJpo0kqQ/uCWe2dsb2JhbACCKCyYOAEBFiQGo2mWUYQtBA X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208,217";a="51499140" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 06:23:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9C6NrKl004152 for ; Mon, 12 Oct 2009 06:23:53 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 08:23:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4B04.91C12C03" Date: Mon, 12 Oct 2009 08:23:48 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpI4mhaXa/jhwrTREaNzQiSmyXg3wCIVvlw References: From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "IETF ROLL" X-OriginalArrivalTime: 12 Oct 2009 06:23:53.0180 (UTC) FILETIME=[91D099C0:01CA4B04] Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 06:23:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4B04.91C12C03 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Julien, =20 When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our options into those messages.=20 They create a tighter coupling between the router and the node, which appears beneficial to the NA DAO process. =20 In the meantime, we made the conscious decision to bind RPL onto ND though we wish to be opened to other bindings. The overloading you are discussing is truly there.=20 In one hand it can be seen as adding complexity. In the other as a way to save control messages. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: vendredi 9 octobre 2009 15:14 To: IETF ROLL Subject: [Roll] NA to transport DAO =20 Hi all, =20 I have concerns about the use of NA to transport DAOs for the following reasons: - NAs are not routing messages - unsolicited NAs are not very frequent, hence using them for DAOs is not really piggybacking. We do not gain a lot by using them - NA are already pretty overloaded messages: they are used in 3 procedures, namely address resolution, NUD and DAD - NA processing is implementation wise complex enough because of the point above - implementation wise, coupling RPL with ND makes code much more complex. - the target address field in the NA uses 16 bytes without bringing a lot of value to RPL. =20 I think using a new ICMP message to carry DAOs would be much better. =20 What do people think? Best, Julien ------_=_NextPart_001_01CA4B04.91C12C03 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Julien,

 

When 6LoWPAN ND becomes a standard, I’m all in = favor to adapting our options into those messages.

They create a tighter coupling between the router and the = node, which appears beneficial to the NA DAO process.

 

In the meantime, we made the conscious decision to bind = RPL onto ND though we wish to be opened to other bindings.

The overloading you are discussing is truly there. =

In one hand it can be seen as adding complexity. In the = other as a way to save control messages.

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Julien Abeille (jabeille)
Sent: vendredi 9 octobre 2009 15:14
To: IETF ROLL
Subject: [Roll] NA to transport DAO

 

Hi all,

 

I have concerns about the use of NA to transport DAOs for the following = reasons:

- NAs are not routing messages

- unsolicited NAs are not very frequent, hence using them for DAOs is not = really piggybacking. We do not gain a lot by using them

- NA are already pretty overloaded messages: they are used in 3 = procedures, namely address resolution, NUD and DAD

- NA processing is implementation wise complex enough because of the = point above

- implementation wise, coupling RPL with ND makes code much more = complex.

- the target address field in the NA uses 16 bytes without bringing a lot = of value to RPL.

 

I think using a new ICMP message to carry DAOs would be much = better.

 

What do people think?

Best,<= o:p>

Julien=

------_=_NextPart_001_01CA4B04.91C12C03-- From pthubert@cisco.com Mon Oct 12 00:21:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2636228C0FA for ; Mon, 12 Oct 2009 00:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.998 X-Spam-Level: X-Spam-Status: No, score=-8.998 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_50=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+EH3M-AS3Ca for ; Mon, 12 Oct 2009 00:21:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 71FCA28C0F0 for ; Mon, 12 Oct 2009 00:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=5030; q=dns/txt; s=amsiport01001; t=1255332093; x=1256541693; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20DAG=20hop=20timers|Date:=20Mon, =2012=20Oct=202009=2009:21:31=20+0200|Message-ID:=20<6A2A 459175DABE4BB11DE2026AA50A5D66DAE8@XMB-AMS-107.cisco.com> |To:=20"Mukul=20Goyal"=20|Cc:=20"roll"=20< roll@ietf.org>|MIME-Version:=201.0 |Content-Transfer-Encoding:=20base64|In-Reply-To:=20<9856 74239.16574561255192322411.JavaMail.root@mail02.pantherli nk.uwm.edu>|References:=20<1241945725.1657410125519212741 1.JavaMail.root@mail02.pantherlink.uwm.edu>=20<985674239. 16574561255192322411.JavaMail.root@mail02.pantherlink.uwm .edu>; bh=stpZMNsEhyMxpfYHv/eoj1CJmse5iqCWR4GSq8tTbpM=; b=ewO9uEfrToX2tM75gwf9VY82OlkMqnU89yrb2/7JM1aYefAXdPsug4o9 K28MwM5qITRGXhNSCsHPUSmYIEijogTOI1GufYMFF+H/mrJ74D3l+gNdQ dac90D3DZufWNV8LDDnh/f2nwv9A1o24dd0WY9NMr1N/60DMH/MUsZsNc s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksAAH910kqQ/uCWe2dsb2JhbACZXIExAQEWJAajb5ZVhC0EilY X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208";a="51503323" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 07:21:31 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9C7LVKk016923; Mon, 12 Oct 2009 07:21:31 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 09:21:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 x-cr-puzzleid: {BB32BEC3-4CAC-4E04-9BA3-B839D462D1F1} x-cr-hashedpuzzle: BFNO BM0x BZ37 Ba0Q ECLf Epie GU1J GW5D GiJ3 IFsi I2US MQkV Nx6P O98u Pt+9 Qj7A; 2; bQB1AGsAdQBsAEAAdQB3AG0ALgBlAGQAdQA7AHIAbwBsAGwAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {BB32BEC3-4CAC-4E04-9BA3-B839D462D1F1}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 12 Oct 2009 06:53:37 GMT; UgBFADoAIABEAEEARwAgAGgAbwBwACAAdABpAG0AZQByAHMA Content-class: urn:content-classes:message Date: Mon, 12 Oct 2009 09:21:31 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66DAE8@XMB-AMS-107.cisco.com> In-Reply-To: <985674239.16574561255192322411.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAG hop timers Thread-Index: AcpJxzSuIwks7/D4S+23inLxox82pwBPW0IA References: <1241945725.16574101255192127411.JavaMail.root@mail02.pantherlink.uwm.edu> <985674239.16574561255192322411.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 12 Oct 2009 07:21:31.0402 (UTC) FILETIME=[9F1366A0:01CA4B0C] Cc: roll Subject: Re: [Roll] DAG hop timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 07:21:34 -0000 SGkgTXVrdWw6DQoNCj5SaWdodCBub3csIHRoZSBEQUcgaG9wIHRpbWVyIGlzIHNjaGVkdWxlZCB0 byBmaXJlIGFmdGVyIGEgZGVsYXkgdGhhdCBpcyBwcm9wb3J0aW9uYWwgdG8gdGhlIHJhbmsgb2Yg dGhlDQo+Y2FuZGlkYXRlIHBhcmVudCAobGV0cyBjYWxsIGl0IHJhbmspIHdob3NlIFJBLURJTyB0 cmlnZ2VycyB0aGUgc3RhcnRpbmcgb2YgdGhlIHRpbWVyLg0KDQpDb3JyZWN0LCB0aG91Z2ggYW5v dGhlciBjb25zZXF1ZW5jZSBvZiBtYWtpbmcgdGhlIHJhbmsgZGVjaW1hbCBzaG91bGQgYmUgdGhh dCB0aGUgdGltZXIgc2hvdWxkIHJlYWxseSBkZXBlbmQgb24gc2VsZidzIGZpbmFsIHJhbmsuDQoN Cj5EQUcgaG9wIHRpbWVyIHZhbHVlID0gcmFuZG9tIG51bWJlciBiZXR3ZWVuIHJhbmsqRGFnRGVs YXkgYW5kIChyYW5rKzEpKkRhZ0RlbGF5DQo+DQo+SWYgREFHIGhvcCB0aW1lciBpcyBleHBlY3Rl ZCB0byBoZWxwIGluIGxvb3AgYXZvaWRhbmNlLCB0aGUgbm9kZSAoc2F5IEEpIHNob3VsZCBnZW5l cmF0ZSBhIG5ldyBSQS1ESU8NCj5hZHZlcnRpc2luZyBpdHMgb3duIGZsb2F0aW5nIERBRyB3aGVu IGl0IHN0YXJ0cyB0aGUgREFHIGhvcCB0aW1lci4gQWxsIHRoZSBjaGlsZHJlbiBub2RlcyB3aWxs IGhvcGVmdWxseQ0KPnJlY2VpdmUgdGhpcyBSQS1ESU8gYW5kIGRlY2lkZSB3aGV0aGVyIHRvIGtp Y2sgbm9kZSBBIG91dCBvZiB0aGUgcGFyZW50IHNldCBvciBsZWF2ZSB0aGUgY3VycmVudCBEQUcg YW5kIGpvaW4NCj5BJ3MgZmxvYXRpbmcgREFHLiBBcyBzb29uIGFzIHRoZXkgbWFrZSB0aGlzIGRl Y2lzaW9uLCB0aGV5IHdpbGwgZ2VuZXJhdGUgdGhlaXIgUkEtRElPIGVpdGhlciBpbW1lZGlhdGVs eSBvcg0KPndpdGhpbiBJX21pbiBpbnRlcnZhbCwgd2hlcmUgSV9taW4gaXMgdGhlIG1pbmltdW0g dHJpY2tsZSB0aW1lciB2YWx1ZS4gU28sIHRoZSBub2RlcyBhdCBsZXZlbCAnbicgaW4gQSdzIHN1 Yi0NCj5kYWcgYXJlIGV4cGVjdGVkIHRvIGdlbmVyYXRlIG5ldyBSQS1ESU9zIHdpdGhpbiBuKklf bWluIGludGVydmFsLg0KDQpJIHN1c3BlY3QgdGhhdCBjb3VsZCBiZSBkb25lIGJ1dCBJJ20gdW5z dXJlIHdoYXQgaXMgaW1wcm92ZWQgYnkgdGhlIHByb3Bvc2VkIGNoYW5nZS4gRG8geW91IHRoaW5r IHRoYXQgdGhpcyB3b3VsZCBzYXZlIGNodXJuIG9yIGJhdHRlcnk/IA0KDQpXaXRoIHRoZSBjdXJy ZW50IHNwZWMsIGlmIHRoZSBub2RlIEEgc3RpbGwgaGFzIGEgZm9yd2FyZGluZyBwYXRoIGFsb25n IHRoZSBjdXJyZW50IERBRywgaXQgaXMgVU5TVEFCTEUgYW5kIHJlZnJhaW5zIGZyb20gc2F5aW5n IGFueXRoaW5nLiBTbyBwYWNrZXRzIGtlZXAgZmxvd2luZyBhbG9uZyB0aGUgY3VycmVudCBEQUcg d2hlcmVhcyBkZXRhY2hpbmcgYWxzbyB3b3VsZCBtZWFuIG5vIHBhY2tldCBmb3J3YXJkaW5nIHRp bGwganVtcC4gV2hlbiBpdCBqdW1wcywgQSBhZHZlcnRpc2VzIGl0cyBuZXcgcG9zaXRpb24gYW5k IG5vZGUgaW4gdGhlIHN1Yi1EQUcgdGhhdCB3aXNoIHRvIGZvbGxvdyBjYW4gZG8gc28gaW1tZWRp YXRlbHkgYW5kIHdpdGhvdXQgYSBsb29wLiBPbmUgY291bGQgdGhpbmsgb2YgaGF2aW5nIGEgdGlt ZXIgdGhlcmUgdG9vIGJ1dCBvbmUgcmF0aW9uYWxlIGlzIChhZ2FpbikgdG8gYXZvaWQgcGFja2V0 IGxvc3Mgc28gdGhlIHNsaWdodCByaXNrIG9mIGNodXJuIGlzIGFjY2VwdGVkLg0KDQo+U28sIG5v ZGUgQSBjYW4gZXhwZWN0IHRvIHJlY2VpdmUgYW4gUkEtRElPIGZyb20gYSBuZWlnaGJvciB3aXRo aW4gZmV3IG11bHRpcGxlcyBvZiBJX21pbiBpZiB0aGF0IG5laWdoYm9yIHdhcw0KPmluIGl0cyBz dWItREFHLiBTbywgSSB3b3VsZCB0aGluayB0aGF0IERBRyBob3AgdGltZXIgdmFsdWUgc2hvdWxk IGJlIGEgc2FmZSBtdWx0aXBsZSBvZiBJX21pbiAoaW5kZXBlbmRlbnQgb2YNCj50aGUgZGFnIHJh bmsgb2YgdGhlIGNhbmRpZGF0ZSBwYXJlbnQpLg0KPg0KPkkgdW5kZXJzdGFuZCB0aGF0IHRoZSBk ZWNpc2lvbiB0byBtYWtlIERBRyBob3AgdGltZXIgdmFsdWUgcHJvcG9ydGlvbmFsIHRvIGNhbmRp ZGF0ZSBwYXJlbnQncyByYW5rIHdhcw0KPmluZmx1ZW5jZWQgYnkgdGhlIGRlc2lyZSB0bzoNCj4x KSBtYWtlIGEgbm9kZSBqb2luIHRoZSBEQUcgYXQgbWluaW11bSBwb3NzaWJsZSByYW5rIGFuZA0K PjIpIGFsbG93IG5vZGVzIGF0IGxvd2VyIHJhbmsgdG8gam9pbiBiZWZvcmUgdGhlIG5vZGVzIGF0 IGhpZ2hlciByYW5rDQoNCkNvcnJlY3QuIEFzIGEgc2lkZSBlZmZlY3QsIGl0IGFsc28gY292ZXJz IHRoZSAodHJpY2tsZWQpIHNwcmVhZGluZyBvZiBhIGRldGFjaGluZyBSQSwgYXQgbGVhc3Qgb3Zl ciBsaW5lIG9mIHNpZ2h0Lg0KDQo+SWYgd2UgYXJlIG5vdCByZXNldHRpbmcgdGhlIERBRyBob3Ag dGltZXIgZXZlcnkgdGltZSB3ZSBjb21lIHRvIGtub3cgb2YgYSBsb3dlciByYW5rZWQgY2FuZGlk YXRlLCB3ZSBhbHJlYWR5DQo+YWdyZWVkIHRvIGdpdmUgdXAgb24gdGhlIHNlY29uZCBvYmplY3Rp dmUgYWJvdmUuDQoNCkknbSBub3Qgc2VlaW5nIHlvdSBoZXJlLiBXZSBhZ3JlZWQgdGhhdCB0aGVy ZSdzIGEgcHJhY3RpY2FsIG5lZWQgZm9yIG9ubHkgb25lIHRpbWVyIHBlciB0YXJnZXQgREFHIHRo b3VnaCB0aGUgc3BlYyBkZXNjcmliZXMgdGhhdCBhcyBvbmUgdGltZXIgcGVyIHBhcmVudC4gSWYg dGhlIGEgbmV3IGNhbmRpZGF0ZSBwb3BzIHVwIHRoYXQgd291bGQgYmUgZ2V0IHRoaXMgbm9kZSB0 byBhIHNob3J0ZXIgcmFuayB3aXRoIGEgc2hvcnRlciB0aW1lciwgYW4gaW1wbGVtZW50YXRpb24g dGhhdCB1c2VzIG9ubHkgb25lIHRpbWVyIG11c3QgZW11bGF0ZSB0aGF0IGJ5IHNob3J0ZW5pbmcg dGhlIGV4aXN0aW5nIHRpbWVyIGR1cmF0aW9uLg0KDQo+DQo+SWYgd2UgbWFrZSBEQUcgaG9wIHRp bWVyIHZhbHVlIGEgc2FmZSBtdWx0aXBsZSBvZiBJX21pbiAoaW5kZXBlbmRlbnQgb2YgdGhlIGRh ZyByYW5rIG9mIHRoZSBjYW5kaWRhdGUgcGFyZW50DQo+dGhhdCBjYXVzZSB0aGUgdGltZXIgdG8g c3RhcnQpLCBvYmplY3RpdmUgKDEpIGFib3ZlIGlzIHN0aWxsIGFjaGlldmFibGUgdG8gcm91Z2hs eSB0aGUgc2FtZSBkZWdyZWUgYXMgd2l0aA0KPmN1cnJlbnQgd2F5IG9mIHNldHRpbmcgdXAgREFH IGhvcCB0aW1lci4NCj4NCg0KVGhpcyBtaWdodCBiZSB0cnVlLiBJIGNvdWxkIGJ1eSB0aGF0IHRo aXMgd29ya3MgaW5kZXBlbmRlbnRseSBvZiB0aGUgZGlzY3Vzc2lvbiBhYm92ZS4gDQpCdXQga2Vl cCBpbiBtaW5kIHRoYXQgdGhlIG1haW4gb2JqZWN0aXZlIGlzIHRvIHJlZHVjZSBjaHVybi4gWW91 ciBwb2ludHMgMSkgYW5kIDIpIGFyZSB0aGUgc3RyYXRlZ3kgdG8gcmVtb3ZlIHRoZSBjaHVybiwg bm90IHRoZSBnb2FsIHRvIGJlIGFjaGlldmVkLg0KDQpXaXRoIHRoZSB0aW1lciwgdGhlIG5ldyBz aGFwZSBvZiB0aGUgcmVzdWx0aW5nIERBRyBzcHJlYWRzIG91dCBsaWtlIGEgd2F2ZS4gDQoNCllv dSdyZSBpbiBhIGdyZWF0IHBvc2l0aW9uIHRvIHNpbXVsYXRlIHRoZSBjaHVybiB3aXRoIGFuZCB3 aXRob3V0IHRoZSBkYWcgaG9wIHRpbWVyLiANCkkgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIGJlIGEg a2V5IGRhdGEgdG8gZW5hYmxlIGFuIGluZm9ybWVkIGRlY2lzaW9uIGZvciB0aGUgcnVubmluZyBw b2xsLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0K From jabeille@cisco.com Mon Oct 12 01:04:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06443A6781 for ; Mon, 12 Oct 2009 01:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kykFx0xEEr3d for ; Mon, 12 Oct 2009 01:04:53 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 537323A67FF for ; Mon, 12 Oct 2009 01:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=12659; q=dns/txt; s=amsiport01001; t=1255334693; x=1256544293; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Mon,=2012=20Oct=202009=2010:04:47=20+0200 |Message-ID:=20|To:=20"Pascal=20Thubert=20(pthubert) "=20,=0D=0A=20=20=20=20=20=20=20=20"I ETF=20ROLL"=20|MIME-Version:=201.0 |In-Reply-To:=20<6A2A459175DABE4BB11DE2026AA50A5D66DAAC@X MB-AMS-107.cisco.com>|References:=20=20<6A2A459175DA BE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com>; bh=bmonaTm/E+kKGplAIcaQ5G2gScXOzDM83BOyLa4PRyA=; b=mpCkdyP9nyHhzt1RT/iergmqDUD/jLD3jLPldiTxH9UlsS5YhDlZ8AgX 4yEOxy3i9aTNJhfeHQj85C5pZBDDCSZhjw+fafnxyXi6lhpT+sigOWmt5 CGCoSCcnflC+exPOwcaMNHJsBJSjTthC31yyU3MOzW3hXjFlazCJ1CCss Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0AANl/0kqQ/uCWe2dsb2JhbACCKSyYNgEBFiQGo3WWUIQtBA X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208,217";a="51508319" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 08:04:50 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9C84oGo000971 for ; Mon, 12 Oct 2009 08:04:50 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10:04:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4B12.AC1F8512" Date: Mon, 12 Oct 2009 10:04:47 +0200 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpI4mhaXa/jhwrTREaNzQiSmyXg3wCIVvlwAAN/tZA= References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , "IETF ROLL" X-OriginalArrivalTime: 12 Oct 2009 08:04:50.0301 (UTC) FILETIME=[AC23EAD0:01CA4B12] Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 08:04:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4B12.AC1F8512 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, all, =20 as I said unsolicited NAs are not frequent if ever sent. Timing constraints are very different and totally decoupled for a NA and a DAO, hence the savings in terms of control messages will be pretty small. The added complexity will be important. This is enough for me to disquilify the use of NAs. =20 regarding 6lowpan, again (I think this has been said many times), RPL is not a protocol for 802.15.4.=20 =20 Best, Julien =20 ________________________________ From: Pascal Thubert (pthubert)=20 Sent: lundi 12 octobre 2009 08:24 To: Julien Abeille (jabeille); IETF ROLL Subject: RE: [Roll] NA to transport DAO =09 =09 Hi Julien, =20 When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our options into those messages.=20 They create a tighter coupling between the router and the node, which appears beneficial to the NA DAO process. =20 In the meantime, we made the conscious decision to bind RPL onto ND though we wish to be opened to other bindings. The overloading you are discussing is truly there.=20 In one hand it can be seen as adding complexity. In the other as a way to save control messages. =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: vendredi 9 octobre 2009 15:14 To: IETF ROLL Subject: [Roll] NA to transport DAO =20 Hi all, =20 I have concerns about the use of NA to transport DAOs for the following reasons: - NAs are not routing messages - unsolicited NAs are not very frequent, hence using them for DAOs is not really piggybacking. We do not gain a lot by using them - NA are already pretty overloaded messages: they are used in 3 procedures, namely address resolution, NUD and DAD - NA processing is implementation wise complex enough because of the point above - implementation wise, coupling RPL with ND makes code much more complex. - the target address field in the NA uses 16 bytes without bringing a lot of value to RPL. =20 I think using a new ICMP message to carry DAOs would be much better. =20 What do people think? Best, Julien ------_=_NextPart_001_01CA4B12.AC1F8512 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Pascal, all,
 
as I said unsolicited NAs are not frequent if = ever sent.=20 Timing constraints are very different and totally decoupled for a NA and = a DAO,=20 hence the savings in terms of control messages will be pretty small. The = added=20 complexity will be important. This is enough for me to disquilify the = use of=20 NAs.
 
regarding 6lowpan, again (I think this has been = said many=20 times), RPL is not a protocol for 802.15.4.
 
Best,
Julien
 

From: Pascal Thubert (pthubert)=20
Sent: lundi 12 octobre 2009 08:24
To: Julien = Abeille=20 (jabeille); IETF ROLL
Subject: RE: [Roll] NA to transport=20 DAO

Hi=20 Julien,

 

When=20 6LoWPAN ND becomes a standard, I’m all in favor to adapting our = options into=20 those messages.

They=20 create a tighter coupling between the router and the node, which = appears=20 beneficial to the NA DAO process.

 

In=20 the meantime, we made the conscious decision to bind RPL onto ND = though we=20 wish to be opened to other bindings.

The=20 overloading you are discussing is truly there.

In=20 one hand it can be seen as adding complexity. In the other as a way to = save=20 control messages.

 

Pascal

From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 Julien Abeille (jabeille)
Sent: vendredi 9 octobre 2009=20 15:14
To: IETF ROLL
Subject: [Roll] NA to = transport=20 DAO

 

Hi=20 all,

 

I have = concerns=20 about the use of NA to transport DAOs for the following=20 reasons:

- NAs are = not=20 routing messages

- = unsolicited NAs=20 are not very frequent, hence using them for DAOs is not really = piggybacking.=20 We do not gain a lot by using them

- NA are = already=20 pretty overloaded messages: they are used in 3 procedures, namely = address=20 resolution, NUD and DAD

- NA = processing is=20 implementation wise complex enough because of the point=20 above

- = implementation=20 wise, coupling RPL with ND makes code much more=20 complex.

- the = target=20 address field in the NA uses 16 bytes without bringing a lot of value = to=20 RPL.

 

I think = using a new=20 ICMP message to carry DAOs would be much = better.

 

What do = people=20 think?

Best,

Julien

------_=_NextPart_001_01CA4B12.AC1F8512-- From jabeille@cisco.com Mon Oct 12 01:10:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0982D3A681F for ; Mon, 12 Oct 2009 01:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.698 X-Spam-Level: X-Spam-Status: No, score=-9.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-E00qQCNtf4 for ; Mon, 12 Oct 2009 01:10:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7BA013A6811 for ; Mon, 12 Oct 2009 01:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=3448; q=dns/txt; s=amsiport01001; t=1255335020; x=1256544620; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Mon,=2012=20Oct=202009=2010:10:16=20+0200 |Message-ID:=20|To:=20"Michael=20Richardson"=20,=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<19409.1255222897@marajade.sandelman.ca> |References:=20<87bpkgbfka.fsf@kelsey-ws.hq.ember.co m>=20=20<19409.1255222897@marajade.sandelman.ca>; bh=GAAuG5hWCzliqp1k6Avz5tjtCihZGmPtluCDWGg88rA=; b=ukou1LdYSXkK3682DjHDSEiIGA7GWutwr79BJjUinG3C1JFlcDloEhuZ fQPcMhBTXYYLPvtpYxMHmPUhcWi34y7X8lW0Mc1K7UYRsEseB0BbPn60A ujQ9jTYXJezIU1DnTmISgcrwn2oTKgT+6LKfCJRUkWZ6r4KpgZ3OmZfK1 E=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAADaB0kqQ/uCWe2dsb2JhbACbCgEBFiQGo3mJL40ihC0EgVg X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208";a="51508859" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 08:10:18 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9C8AITY002672; Mon, 12 Oct 2009 08:10:18 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10:10:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 10:10:16 +0200 Message-ID: In-Reply-To: <19409.1255222897@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpKDmlBRJzSp+qcSBe4+J3NSDCagABBGnsg References: <87bpkgbfka.fsf@kelsey-ws.hq.ember.com> <19409.1255222897@marajade.sandelman.ca> From: "Julien Abeille (jabeille)" To: "Michael Richardson" , X-OriginalArrivalTime: 12 Oct 2009 08:10:18.0536 (UTC) FILETIME=[6FC89A80:01CA4B13] Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 08:10:21 -0000 Hi Michael,=20 Thanks for your answer, comments inline. > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Michael Richardson > Sent: dimanche 11 octobre 2009 03:02 > To: roll@ietf.org > Subject: Re: [Roll] NA to transport DAO >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > >>>>> "Richard" =3D=3D Richard Kelsey = writes: > Richard> I agree that the choice of NA for DAOs needs some > Richard> justification, at least. Besides a new ICMP, UDP to a > Richard> well-known port is another option. >=20 > Maybe a different ICMP, but a UDP is probably not a good idea. >=20 Agreed=20 > I know that people have lots of bad experiences in v4 with=20 > things not TCP or UDP (often due to some comodity operating=20 > systems making it very hard to do anything different -- my=20 > history is IPsec, and multicast), > but this is a greenfield IPv6 situation. We should not have to break > the architecture at this point. >=20 > I am curious about those who believe that processing the DAOs=20 > is going to be hard. Last week I put up some test code to=20 > determine how hard this was going to be in a Linux kernel --=20 > the Linux kernel processes RA in the kernel directly (vs the=20 > *BSD kernels, where rtsold does the work). >=20 > I have no idea what other systems do, but the following code=20 > was enough for me to see all ND and RS/RA packets in=20 > userland, without any modifications to the kernel. >=20 What having the code in userland with NAs does is that the NAs are processed twice, once by the kernel for DAD, NUD, address resolution, once in userland for RPL. Not sure we can conclude it is easy to build a clean software architecture for RPL in Linux. Besides, Linux/BSD will not be the OS on many smart objects. On standard smart objects OSes it will be much more complex. Best, Julien > main() > { > int s =3D socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6); > char b[2048]; > int len, n; >=20 > if(s < 0) { > perror("socket"); > exit(10); > } >=20 > n=3D0; > while((len =3D recv(s, b, 2048, 0)) >=3D 0) { > printf("\nPacket(%u,%u):\n", n, len); > hexdump(b, 0, len); > n++; > } > perror("recv"); > } >=20 >=20 >=20 > - --=20 > ] He who is tired of Weird Al is tired of life! =20 > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON =20 > |net architect[ > ] mcr@sandelman.ottawa.on.ca=20 > http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video=20 > > then sign the petition.=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys >=20 > iQEVAwUBStEuboCLcPvd0N1lAQKPQQf+LuWGVchwOu5yg127+5d2rz8+LiyZws+V > o6tW1HXox1HarXnj+tJkLG9v5ibtymxxIBUxP4Y78ly92r2fqkYfM8mshol9Jnpq > HXOD0sMDd1Tlvm1PILzqAhHiZmQkkYSJ7TupLQs/qs736TSjBIdvrVZuEmysbkzr > 9QZlhBimYA6vAKZncq+pMple7zvXIuRe4atbHWTL84PLqtTYsCfHxVsLhanqTu/K > G/DJsjj9zKrvUHXC33c1+wF0YTjWe/eFwS4RH4g4SMcF8noy6L7TaBdlvajjoI2F > rq/THV9TkHOTo5koOrt5DtzDl4C9X1AcODVeeGc01g0xE1KklQnF7g=3D=3D > =3DCVIa > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From zach@sensinode.com Mon Oct 12 01:27:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA5E53A6855 for ; Mon, 12 Oct 2009 01:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6TqXnv+ca9a for ; Mon, 12 Oct 2009 01:27:45 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 708CF3A6899 for ; Mon, 12 Oct 2009 01:27:44 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9C8Rc8U015923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Oct 2009 11:27:38 +0300 Message-Id: <3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> From: Zach Shelby To: "Julien Abeille (jabeille)" In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 11:27:39 +0300 References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 08:27:46 -0000 Hi, On Oct 12, 2009, at 11:04 , Julien Abeille (jabeille) wrote: > Hi Pascal, all, > > as I said unsolicited NAs are not frequent if ever sent. Timing =20 > constraints are very different and totally decoupled for a NA and a =20= > DAO, hence the savings in terms of control messages will be pretty =20 > small. The added complexity will be important. This is enough for me =20= > to disquilify the use of NAs. I understand the concern there for RFC4861. > regarding 6lowpan, again (I think this has been said many times), =20 > RPL is not a protocol for 802.15.4. Huh? Apples and oranges. We are not talking about 802.15.4. RPL is an IP routing protocol, and it *must* be useable in 6LoWPAN =20 IPv6 networks as well. An alternative binding to draft-ietf-6lowpan-nd =20= messages should be defined of course as Pascal mentioned below. And =20 here the advantages of this are even greater. In 6LoWPAN-ND we do have =20= periodic NR/NC messages which are not overloaded. This reminds me - in the next version of RPL we need a section to =20 specifically discuss the use of RPL in LoWPANs. The current text =20 assumes the LLN is a collection of normal IPv6 links and that RFC4861 =20= is used. In a LoWPAN we have a flat network (no prefix assignment to =20 LLN Routers) and 6lowpan-nd instead of RFC4861. It is pretty confusing =20= to read if someone new is trying to figure out how to apply this is a =20= LoWPAN... Zach > > Best, > Julien > > > From: Pascal Thubert (pthubert) > Sent: lundi 12 octobre 2009 08:24 > To: Julien Abeille (jabeille); IETF ROLL > Subject: RE: [Roll] NA to transport DAO > > Hi Julien, > > When 6LoWPAN ND becomes a standard, I=92m all in favor to adapting our = =20 > options into those messages. > They create a tighter coupling between the router and the node, =20 > which appears beneficial to the NA DAO process. > > In the meantime, we made the conscious decision to bind RPL onto ND =20= > though we wish to be opened to other bindings. > The overloading you are discussing is truly there. > In one hand it can be seen as adding complexity. In the other as a =20 > way to save control messages. > > Pascal > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Julien Abeille (jabeille) > Sent: vendredi 9 octobre 2009 15:14 > To: IETF ROLL > Subject: [Roll] NA to transport DAO > > Hi all, > > I have concerns about the use of NA to transport DAOs for the =20 > following reasons: > - NAs are not routing messages > - unsolicited NAs are not very frequent, hence using them for DAOs =20 > is not really piggybacking. We do not gain a lot by using them > - NA are already pretty overloaded messages: they are used in 3 =20 > procedures, namely address resolution, NUD and DAD > - NA processing is implementation wise complex enough because of the =20= > point above > - implementation wise, coupling RPL with ND makes code much more =20 > complex. > - the target address field in the NA uses 16 bytes without bringing =20= > a lot of value to RPL. > > I think using a new ICMP message to carry DAOs would be much better. > > What do people think? > Best, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From pthubert@cisco.com Mon Oct 12 03:06:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5721028C17C for ; Mon, 12 Oct 2009 03:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr3AkSSXgGt9 for ; Mon, 12 Oct 2009 03:06:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C676728C175 for ; Mon, 12 Oct 2009 03:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4589; q=dns/txt; s=amsiport01001; t=1255342016; x=1256551616; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Mon,=2012=20Oct=202009=2012:06:44=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XM B-AMS-107.cisco.com>|To:=20"Zach=20Shelby"=20,=0D=0A=20=20=20=20=20=20=20=20"Julien=20Abeille =20(jabeille)"=20|Cc:=20"IETF=20ROLL" =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<3310086F-D3CF-431D-B112-EEB907519BAC@sen sinode.com>|References:=20=20<6A2A459175DABE4BB11DE2 026AA50A5D66DAAC@XMB-AMS-107.cisco.com>=20=20<331008 6F-D3CF-431D-B112-EEB907519BAC@sensinode.com>; bh=cWUWYROESMifpDAhkCEfh8dhayKO4hP76td9p4bZQEM=; b=Ahtb/u13oHMfI4PwNqU+v+dSv4gVlLmwJGu/45neVvCaL0Jk8yAIqGwm G+cfhWlrTc8u8ncrpWDnybdD8FsklXixe6u4T16+DTuRKK/ZNTLS2fCy8 SxLifCME8d7KkdQB4uN7NL4Nu+7B3/hxu9EL6UkOtSRsTdyJiYaqit6P2 w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAO+b0kqQ/uCWe2dsb2JhbACWP4RLAQEWJAakO5ZehC0EgVg X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208";a="51524288" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 10:06:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CA6sXc014500; Mon, 12 Oct 2009 10:06:54 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 12:06:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 12:06:44 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> In-Reply-To: <3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLFeCDdqQiULIjRnmtBSYJZ4LuKgADOiag References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> From: "Pascal Thubert (pthubert)" To: "Zach Shelby" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 12 Oct 2009 10:06:54.0313 (UTC) FILETIME=[B9977590:01CA4B23] Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 10:06:57 -0000 Hi Zach We are in perfect line. At the moment, RPL would impose NS/NA between 6LoWPAN routers to expose the host routes. At some point in the future, considering that LoWPANs are an obvious target for RPL, we should be able to define the binding over the LowPAN ND. What we really need to move forward there is for ND to progress to RFC quickly so we can refer to it.=20 I think it would be good for this list that you update us on the progress there. What would be the plan for last call? Cheers, Pascal >-----Original Message----- >From: Zach Shelby [mailto:zach@sensinode.com] >Sent: lundi 12 octobre 2009 10:28 >To: Julien Abeille (jabeille) >Cc: Pascal Thubert (pthubert); IETF ROLL >Subject: Re: [Roll] NA to transport DAO > >Hi, > >On Oct 12, 2009, at 11:04 , Julien Abeille (jabeille) wrote: > >> Hi Pascal, all, >> >> as I said unsolicited NAs are not frequent if ever sent. Timing >> constraints are very different and totally decoupled for a NA and a >> DAO, hence the savings in terms of control messages will be pretty >> small. The added complexity will be important. This is enough for me >> to disquilify the use of NAs. > >I understand the concern there for RFC4861. > >> regarding 6lowpan, again (I think this has been said many times), >> RPL is not a protocol for 802.15.4. > >Huh? Apples and oranges. We are not talking about 802.15.4. > >RPL is an IP routing protocol, and it *must* be useable in 6LoWPAN >IPv6 networks as well. An alternative binding to draft-ietf-6lowpan-nd >messages should be defined of course as Pascal mentioned below. And >here the advantages of this are even greater. In 6LoWPAN-ND we do have >periodic NR/NC messages which are not overloaded. > >This reminds me - in the next version of RPL we need a section to >specifically discuss the use of RPL in LoWPANs. The current text >assumes the LLN is a collection of normal IPv6 links and that RFC4861 >is used. In a LoWPAN we have a flat network (no prefix assignment to >LLN Routers) and 6lowpan-nd instead of RFC4861. It is pretty confusing >to read if someone new is trying to figure out how to apply this is a >LoWPAN... > >Zach > >> >> Best, >> Julien >> >> >> From: Pascal Thubert (pthubert) >> Sent: lundi 12 octobre 2009 08:24 >> To: Julien Abeille (jabeille); IETF ROLL >> Subject: RE: [Roll] NA to transport DAO >> >> Hi Julien, >> >> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our >> options into those messages. >> They create a tighter coupling between the router and the node, >> which appears beneficial to the NA DAO process. >> >> In the meantime, we made the conscious decision to bind RPL onto ND >> though we wish to be opened to other bindings. >> The overloading you are discussing is truly there. >> In one hand it can be seen as adding complexity. In the other as a >> way to save control messages. >> >> Pascal >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of Julien Abeille (jabeille) >> Sent: vendredi 9 octobre 2009 15:14 >> To: IETF ROLL >> Subject: [Roll] NA to transport DAO >> >> Hi all, >> >> I have concerns about the use of NA to transport DAOs for the >> following reasons: >> - NAs are not routing messages >> - unsolicited NAs are not very frequent, hence using them for DAOs >> is not really piggybacking. We do not gain a lot by using them >> - NA are already pretty overloaded messages: they are used in 3 >> procedures, namely address resolution, NUD and DAD >> - NA processing is implementation wise complex enough because of the >> point above >> - implementation wise, coupling RPL with ND makes code much more >> complex. >> - the target address field in the NA uses 16 bytes without bringing >> a lot of value to RPL. >> >> I think using a new ICMP message to carry DAOs would be much better. >> >> What do people think? >> Best, >> Julien >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >-- >http://www.sensinode.com >http://zachshelby.org - My blog "On the Internet of Things" >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND > >This e-mail and all attached material are confidential and may contain >legally privileged information. If you are not the intended recipient, >please contact the sender and delete the e-mail from your system >without producing, distributing or retaining copies thereof. > > From alexandru.petrescu@gmail.com Mon Oct 12 03:39:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686EB3A68EA for ; Mon, 12 Oct 2009 03:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19xbZNY8I0yc for ; Mon, 12 Oct 2009 03:39:15 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 162CD3A6998 for ; Mon, 12 Oct 2009 03:39:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CAd3Dh006560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 12:39:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CAd3Gm002634; Mon, 12 Oct 2009 12:39:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CAd2et003795; Mon, 12 Oct 2009 12:39:03 +0200 Message-ID: <4AD30746.9040807@gmail.com> Date: Mon, 12 Oct 2009 12:39:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 10:39:16 -0000 Hi JP, JP Vasseur a écrit : > Hi Alex, > > On Oct 9, 2009, at 7:53 PM, Alexandru Petrescu wrote: > >> Hi JP, >> >> JP Vasseur a écrit : >>> Hi Alex, >>> On Oct 8, 2009, at 4:18 PM, Alexandru Petrescu wrote: >>>> Hi JP, >>>> I am attracted by the subject of the mail, it is about Metric I-D >>>> (Internet Draft). However, I am not sure what are you asking for? >>> Which metric should be defined for RPL (link and node). Note that we >>> have several metrics already defined, but still a few TBD. >> >> Do you have a metric which says "energy needed to send a packet on an >> interface"? I don't think you do. I think your draft briefly alludes >> to energy cost of sending and receiving packets (presumably on a link), >> but falls short in defining one as such. >> >> To cite your draft: >>> Raw power and energy values are meaningless without knowledge of the >>> energy cost of sending and receiving packets >> >> Yet the table of contents says: > > The draft has not been updated for quite some time, since we were > waiting to progress first on RPL of course. > The next revision will be significantly fleshed out. I hope the results of this will be to continue to mention energy cost of at least sending packets. And not to remove this text. >> We could struggle to compare a path with high energy cost yet low >> hopcount cost to a path with low energy cost yet high hopcount cost. Is >> P1 preferable over P2 or vice-versa? >> >> I think this is a question to which one can't answer without knowing the >> deployment context. >> > > Well at least we need one example where it could be useful. I can't find > of any personally. Here is one: -- -- |R1| |R2| -- -- | | | | | | | | \ ---- / |Host| ---- R1 and R2 send two different RAs. Each pretends to be a default router (non-zero Router Lifetime) and send different "link energy metrics" to Host. Host has thus a choice between R1 and R2 based on that link energy metric. What do you think about this use case? > What matters is how much of energy left you have, not how much of energy > you may consume, no ? In a sense yes, makes think of "node" energy metrics. I think it is also importnat for the nodes to know in advance how much energy they need in order to send a packet on a certain link. Alex From cabo@tzi.org Mon Oct 12 03:41:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F018D28C194 for ; Mon, 12 Oct 2009 03:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQNoPhmZrGVj for ; Mon, 12 Oct 2009 03:41:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id ABBF028C193 for ; Mon, 12 Oct 2009 03:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9CAemC4015866; Mon, 12 Oct 2009 12:40:48 +0200 (CEST) Received: from [10.0.1.198] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 0E710B481; Mon, 12 Oct 2009 12:40:48 +0200 (CEST) From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> Message-Id: <34F62F89-EDEF-431E-B267-B37D388CFB95@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 12:40:47 +0200 X-Mailer: Apple Mail (2.936) Cc: IETF ROLL , Geoffrey Mulligan Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 10:41:01 -0000 On Oct 12, 2009, at 12:06, Pascal Thubert (pthubert) wrote: > What would be the plan for last call? The most recent update, draft-ietf-6lowpan-nd-06.txt, was posted on 2009-09-21. This resolves all issues in the issue tracker; there are currently no outstanding issues in the tracker. I believe we could go to WGLC now. Issuing a WGLC may be a good way to trigger some additional review, in particular from outside the WG. (Procedural note: As I'm a co-author, the other 6LoWPAN WG chair will have to issue the WGLC.) Gruesse, Carsten From alexandru.petrescu@gmail.com Mon Oct 12 03:56:55 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7D528C19B for ; Mon, 12 Oct 2009 03:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6DAUufWzI0n for ; Mon, 12 Oct 2009 03:56:54 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 2148228C183 for ; Mon, 12 Oct 2009 03:56:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CAuiT9014021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 12:56:44 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CAuiu3005664; Mon, 12 Oct 2009 12:56:44 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CAuhAv008219; Mon, 12 Oct 2009 12:56:44 +0200 Message-ID: <4AD30B6B.3030802@gmail.com> Date: Mon, 12 Oct 2009 12:56:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> In-Reply-To: <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] ETX metric (was: RPL Metric ID) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 10:56:55 -0000 JP Vasseur a écrit : [...] > There is a consensus that a reliability metric is needed (note that > we are not limited to radio links). Several metrics have been used > for years such as ETX. I strongly disagree on using ETX. ETX relies on probabilities ("a Bernoulli trial"), i.e. it is not as hard data as hopcount is. ETX does not relate directly to the energy consumed per packet. It may have a positive influence on it, but it does not depend on it. ETX is unnecessarily complex due to taking into account the re-transmissions, i.e. noisy environments. ETX claims to be additive ("ETX of a route is the sum of ETX of each link") but probabilities are not as additive (20% success rate on a link and 30% success rate on another link don't make for 50% path success rate, but for 30% success rate - the least common denominator). I suggest using a link metric which is simply the energy quantity needed to send an IP packet of size 1280 bytes, on a particular link, full success rate. Alex Argumentation based on paper: De Couto, Aguayo, Bicket and Morris, "A HighThroughput Path Metric for MultiHop Wireless Routing", MIT CSAIL, ACM MobiCom '03, 2003. > >> PAcket delivery ratio is something which equals "best effort" i.e. >> it has no number quantifying it. >> >> Energy? Energy is something different, and doesn't relate to "best >> effort" - it can be quantified. >> >> Alex >> >> >> Since RPL is a >>> distance vector, we would use a cumulative metric. Of course, >>> each node should filter out the transient error rate and >>> periodicity of the metric update should be limited to avoid >>> routing metric but this not specific to the reliability metric. >>> It is true for all dynamic metrics. The objective is thus to >>> define a cumulative reliability metric reflecting the probability >>> of success path delivery, in units independent of the Link >>> layer. Local mechanisms to filter out local transient phenomena >>> are left to implementation specific decisions. Make sense ? >>>> Our product was developed and deployed in 2006. We used what >>>> is termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has >>>> developed the 'ZigBee PRO' stack which will in time subsume >>>> the ZigBee Stack. ZigBee PRO selects paths based on the best >>>> symmetric path found. I believe asymmetric paths are discarded >>>> or only used as a last resort. Not quite. ZigBee PRO only >>>> requires that the cost assigned to an asymmetric link be the >>>> worse of the two unidirectional costs. >>> Makes sense. We had a discussion on this too, and it was decided >>> not to take it into account for the time being. >>>> Unfortunately, I have no empirical or simulation data on this >>>> metric. Maybe Richard can provide some insight on this >>>> approach since I believe it was championed by Ember. Ember and >>>> Mitsubishi proposed the solution that was adopted (exchanging >>>> link costs with neighbors). The actual problem that it solved >>>> was first raised by Ghulam Bhatti of Mitsubishi, if I remember >>>> correctly. Under certain circumstances having the two ends of >>>> a link use different costs could cause ZigBee's P2P routing to >>>> consistently fail to discover a route. The problem was fairly >>>> fundamental to ZigBee's P2P mechanism, and given the other >>>> advantages of identifying asymmetries and knowing more about >>>> your local neighborhood, ZigBee added a feature where nodes >>>> inform their neighbors of their link costs. This seems like >>>> something that could be done at the link layer. >>> Yes. JP. >>>> -Richard Kelsey _______________________________________________ >>>> 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 jvasseur@cisco.com Mon Oct 12 04:06:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3633A699F for ; Mon, 12 Oct 2009 04:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJIdeOJRoLyT for ; Mon, 12 Oct 2009 04:06:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5EF503A67E5 for ; Mon, 12 Oct 2009 04:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=4517; q=dns/txt; s=amsiport01001; t=1255345569; x=1256555169; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20ETX=20metric=20(was:=20[Roll]=20RPL=20Metric=20ID) |Date:=20Mon,=2012=20Oct=202009=2013:06:05=20+0200 |Message-Id:=20<1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisc o.com>|To:=20Alexandru=20Petrescu=20|Cc:=20Richard=20Kelsey=20,=20roll@ietf.org,=0D=0A=20=20=20=20=20=20=20=20kpist er@dustnetworks.com|Mime-Version:=201.0=20(Apple=20Messag e=20framework=20v936)|Content-Transfer-Encoding:=20quoted -printable|In-Reply-To:=20<4AD30B6B.3030802@gmail.com> |References:=20=09<87ljjmapxh.fsf@kelsey-ws.hq. ember.com>=20=20<4ACF754C.2000604@gmail.com>=20<2F8F6405-4B87-4A62 -9040-717A5D956B42@cisco.com>=20<4AD30B6B.3030802@gmail.c om>; bh=fxFOg+SrX4buMUWnLcyQ+eS21T/u0ptLU8Dfolm51HM=; b=Gm2VrujmHCUTqlwk+xYw/oflmmMqpR2o0isfZS2KC+BQgQBnoUgsCIp7 S7e3I3R7w1dFpNcmI6xsBn4V+A0A9FYb1JmwiDtUDK/G5WcBTC/G5DEIK dSKXKM5fC31kX7NPTfiMHreBxiHTkx+ekaBR3PdWfHK+60iTqfdqGsoCH w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAAAmq0kqQ/uCWe2dsb2JhbACbDAEBFiQGpDSJDwiNRIJFCIFgBA X-IronPort-AV: E=Sophos;i="4.44,545,1249257600"; d="scan'208";a="51531934" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 11:06:07 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CB67Gj005312; Mon, 12 Oct 2009 11:06:07 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:06:07 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:06:07 +0200 Message-Id: <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AD30B6B.3030802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 13:06:05 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 11:06:07.0148 (UTC) FILETIME=[FF3F0EC0:01CA4B2B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.005 X-TM-AS-Result: No--31.518900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] ETX metric (was: RPL Metric ID) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 11:06:10 -0000 On Oct 12, 2009, at 12:56 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : > [...] >> There is a consensus that a reliability metric is needed (note that =20= >> we are not limited to radio links). Several metrics have been used =20= >> for years such as ETX. > > I strongly disagree on using ETX. > > ETX relies on probabilities ("a Bernoulli trial"), i.e. it is not as > hard data as hopcount is. > > ETX does not relate directly to the energy consumed per packet. It =20= > may > have a positive influence on it, but it does not depend on it. > > ETX is unnecessarily complex due to taking into account the > re-transmissions, i.e. noisy environments. > > ETX claims to be additive ("ETX of a route is the sum of ETX of each > link") but probabilities are not as additive (20% success rate on a =20= > link > and 30% success rate on another link don't make for 50% path success > rate, but for 30% success rate - the least common denominator). > Thanks for your input. Let's see what other say. I personally like the ETX. > I suggest using a link metric which is simply the energy quantity =20 > needed > to send an IP packet of size 1280 bytes, on a particular link, full > success rate. But not only the use of energy is very much arguable but it does not =20 reflect the link quality, a must in LLN. What would you prefer then for the quality =20 metric ? Thanks. JP. > > Alex > > Argumentation based on paper: > De Couto, Aguayo, Bicket and Morris, "A HighThroughput Path Metric for > MultiHop Wireless Routing", MIT CSAIL, ACM MobiCom '03, 2003. > >>> PAcket delivery ratio is something which equals "best effort" i.e. =20= >>> it has no number quantifying it. >>> Energy? Energy is something different, and doesn't relate to "best >>> effort" - it can be quantified. >>> Alex >>> Since RPL is a >>>> distance vector, we would use a cumulative metric. Of course, =20 >>>> each node should filter out the transient error rate and =20 >>>> periodicity of the metric update should be limited to avoid =20 >>>> routing metric but this not specific to the reliability metric. =20 >>>> It is true for all dynamic metrics. The objective is thus to =20 >>>> define a cumulative reliability metric reflecting the probability >>>> of success path delivery, in units independent of the Link >>>> layer. Local mechanisms to filter out local transient phenomena >>>> are left to implementation specific decisions. Make sense ? >>>>> Our product was developed and deployed in 2006. We used what is =20= >>>>> termed the 'ZigBee 2006 Stack'. Since that time, ZigBee has >>>>> developed the 'ZigBee PRO' stack which will in time subsume the =20= >>>>> ZigBee Stack. ZigBee PRO selects paths based on the best =20 >>>>> symmetric path found. I believe asymmetric paths are discarded >>>>> or only used as a last resort. Not quite. ZigBee PRO only =20 >>>>> requires that the cost assigned to an asymmetric link be the =20 >>>>> worse of the two unidirectional costs. >>>> Makes sense. We had a discussion on this too, and it was decided =20= >>>> not to take it into account for the time being. >>>>> Unfortunately, I have no empirical or simulation data on this =20 >>>>> metric. Maybe Richard can provide some insight on this approach =20= >>>>> since I believe it was championed by Ember. Ember and Mitsubishi =20= >>>>> proposed the solution that was adopted (exchanging link costs =20 >>>>> with neighbors). The actual problem that it solved was first =20 >>>>> raised by Ghulam Bhatti of Mitsubishi, if I remember correctly. =20= >>>>> Under certain circumstances having the two ends of a link use =20 >>>>> different costs could cause ZigBee's P2P routing to consistently =20= >>>>> fail to discover a route. The problem was fairly >>>>> fundamental to ZigBee's P2P mechanism, and given the other =20 >>>>> advantages of identifying asymmetries and knowing more about =20 >>>>> your local neighborhood, ZigBee added a feature where nodes =20 >>>>> inform their neighbors of their link costs. This seems like =20 >>>>> something that could be done at the link layer. >>>> Yes. JP. >>>>> -Richard Kelsey _______________________________________________ >>>>> 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 mdurvy@cisco.com Mon Oct 12 04:32:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97ED43A6836 for ; Mon, 12 Oct 2009 04:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKXB4ERg0etK for ; Mon, 12 Oct 2009 04:32:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AE72B3A68D0 for ; Mon, 12 Oct 2009 04:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=6096; q=dns/txt; s=amsiport01001; t=1255347129; x=1256556729; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DAO |Date:=20Mon,=2012=20Oct=202009=2013:32:06=20+0200 |Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XM B-AMS-103.cisco.com>|To:=20"Pascal=20Thubert=20(pthubert) "=20,=0D=0A=20=20=20=20=20=20=20=20"Z ach=20Shelby"=20,=0D=0A=20=20=20=20 =20=20=20=20"Julien=20Abeille=20(jabeille)"=20|Cc:=20"IETF=20ROLL"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<6A2A459175DABE4BB11DE2026AA50A5 D66DC8C@XMB-AMS-107.cisco.com>|References:=20<6A2A45 9175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> =20<6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.ci sco.com>; bh=dFi+TbEqhaAemahlUpA7kgmpawDq0EXxRS8uIYHtgjE=; b=UadelnxduuBvXxx8u7nDWn4q5pvtD8ZSHA831Jyp7ylGtpkDbtDG1xIr HeB+rZ3yN5EtOf7jQo3CzNHOZNSJY0llrhPTUWGZUkfRnaV7tztVtO+J0 UeQ9kKoA16Jqk3pNJKgRF5HoTCZhbRDcu2VnMj/CZI8KXUg9nrASbx1ZI o=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAABew0kqQ/uCWe2dsb2JhbACWP4RMAQEWJAakLJZehC0EgVg X-IronPort-AV: E=Sophos;i="4.44,545,1249257600"; d="scan'208";a="51534979" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 11:32:07 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CBW7oU014169; Mon, 12 Oct 2009 11:32:07 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:32:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 13:32:06 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLFeCDdqQiULIjRnmtBSYJZ4LuKgADOiagAAJ4a8A= References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "Zach Shelby" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 12 Oct 2009 11:32:07.0775 (UTC) FILETIME=[A173D6F0:01CA4B2F] Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 11:32:10 -0000 Hi All, I perfectly agree with Julien's arguments. Quoting from RFC 4861: "7.2.6. Sending Unsolicited Neighbor Advertisements In some cases, a node may be able to determine that its link-layer address has changed (e.g., hot-swap of an interface card) and may wish to inform its neighbors of the new link-layer address quickly. In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited Neighbor Advertisement messages to the all-nodes multicast address. These advertisements MUST be separated by at least RetransTimer seconds..." Do we really want to impose these constrains to the sending of DAO? I don't think so... The goal of NAs is to update neighbor caches and I don't see any logic in wanting to reuse these messages for routing. In addition, I don't think this group should care or make any assumptions on the adaptation layer running below IPv6 as each of them has it specificities and RPL should remain as generic as possible. Best, Mathilde=20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: lundi, 12. octobre 2009 12:07 To: Zach Shelby; Julien Abeille (jabeille) Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO Hi Zach We are in perfect line. At the moment, RPL would impose NS/NA between 6LoWPAN routers to expose the host routes. At some point in the future, considering that LoWPANs are an obvious target for RPL, we should be able to define the binding over the LowPAN ND. What we really need to move forward there is for ND to progress to RFC quickly so we can refer to it.=20 I think it would be good for this list that you update us on the progress there. What would be the plan for last call? Cheers, Pascal >-----Original Message----- >From: Zach Shelby [mailto:zach@sensinode.com] >Sent: lundi 12 octobre 2009 10:28 >To: Julien Abeille (jabeille) >Cc: Pascal Thubert (pthubert); IETF ROLL >Subject: Re: [Roll] NA to transport DAO > >Hi, > >On Oct 12, 2009, at 11:04 , Julien Abeille (jabeille) wrote: > >> Hi Pascal, all, >> >> as I said unsolicited NAs are not frequent if ever sent. Timing=20 >> constraints are very different and totally decoupled for a NA and a=20 >> DAO, hence the savings in terms of control messages will be pretty=20 >> small. The added complexity will be important. This is enough for me=20 >> to disquilify the use of NAs. > >I understand the concern there for RFC4861. > >> regarding 6lowpan, again (I think this has been said many times), RPL >> is not a protocol for 802.15.4. > >Huh? Apples and oranges. We are not talking about 802.15.4. > >RPL is an IP routing protocol, and it *must* be useable in 6LoWPAN >IPv6 networks as well. An alternative binding to draft-ietf-6lowpan-nd=20 >messages should be defined of course as Pascal mentioned below. And=20 >here the advantages of this are even greater. In 6LoWPAN-ND we do have=20 >periodic NR/NC messages which are not overloaded. > >This reminds me - in the next version of RPL we need a section to=20 >specifically discuss the use of RPL in LoWPANs. The current text=20 >assumes the LLN is a collection of normal IPv6 links and that RFC4861=20 >is used. In a LoWPAN we have a flat network (no prefix assignment to=20 >LLN Routers) and 6lowpan-nd instead of RFC4861. It is pretty confusing=20 >to read if someone new is trying to figure out how to apply this is a=20 >LoWPAN... > >Zach > >> >> Best, >> Julien >> >> >> From: Pascal Thubert (pthubert) >> Sent: lundi 12 octobre 2009 08:24 >> To: Julien Abeille (jabeille); IETF ROLL >> Subject: RE: [Roll] NA to transport DAO >> >> Hi Julien, >> >> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our=20 >> options into those messages. >> They create a tighter coupling between the router and the node, which >> appears beneficial to the NA DAO process. >> >> In the meantime, we made the conscious decision to bind RPL onto ND=20 >> though we wish to be opened to other bindings. >> The overloading you are discussing is truly there. >> In one hand it can be seen as adding complexity. In the other as a=20 >> way to save control messages. >> >> Pascal >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 >> Of Julien Abeille (jabeille) >> Sent: vendredi 9 octobre 2009 15:14 >> To: IETF ROLL >> Subject: [Roll] NA to transport DAO >> >> Hi all, >> >> I have concerns about the use of NA to transport DAOs for the=20 >> following reasons: >> - NAs are not routing messages >> - unsolicited NAs are not very frequent, hence using them for DAOs is >> not really piggybacking. We do not gain a lot by using them >> - NA are already pretty overloaded messages: they are used in 3=20 >> procedures, namely address resolution, NUD and DAD >> - NA processing is implementation wise complex enough because of the=20 >> point above >> - implementation wise, coupling RPL with ND makes code much more=20 >> complex. >> - the target address field in the NA uses 16 bytes without bringing a >> lot of value to RPL. >> >> I think using a new ICMP message to carry DAOs would be much better. >> >> What do people think? >> Best, >> Julien >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >-- >http://www.sensinode.com >http://zachshelby.org - My blog "On the Internet of Things" >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND > >This e-mail and all attached material are confidential and may contain=20 >legally privileged information. If you are not the intended recipient,=20 >please contact the sender and delete the e-mail from your system=20 >without producing, distributing or retaining copies thereof. > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Oct 12 04:45:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C042F3A69B6 for ; Mon, 12 Oct 2009 04:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5Scq9Q82TXC for ; Mon, 12 Oct 2009 04:45:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0D4413A69B2 for ; Mon, 12 Oct 2009 04:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3976; q=dns/txt; s=amsiport01001; t=1255347948; x=1256557548; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Mon,=2012=20Oct =202009=2013:45:44=20+0200|Message-Id:=20<1AA77E89-F83F-4 BFD-92FF-657E4C9B9739@cisco.com>|To:=20Tim=20Winter=20|Cc:=20roll@ietf.org|Mime-Version:=201.0=20 (Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4ACF43 CC.2020303@acm.org>|References:=20<1743477406.15552751254 944444717.JavaMail.root@mail02.pantherlink.uwm.edu>=20<4A CF43CC.2020303@acm.org>; bh=g/v3u5meI0QDL2YlvzKgMFHTbvmQgz0HKwJmjM4t6cg=; b=Su1NqQbu82kYId/fjOYtBs2I7qoxcRsJSzSDqv/hFw2mYG9NdQ67ri6h LcmDndNqMWV/KvmLhRHwvBK4Z6oG36gtN5hDpOe/DTXF6jfUw9blfgeKg /dIlc2GvS5O7IJ7IMna1LBW+/6aILAsakOgh8ZNSTIX1MB550g6/BAy3y k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAAJuz0kqQ/uCWe2dsb2JhbACbCwEBFiQGpByWYIImggcE X-IronPort-AV: E=Sophos;i="4.44,545,1249257600"; d="scan'208";a="51536830" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 11:45:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CBjlwo019273; Mon, 12 Oct 2009 11:45:47 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:45:47 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 13:45:46 +0200 Message-Id: <1AA77E89-F83F-4BFD-92FF-657E4C9B9739@cisco.com> From: JP Vasseur To: Tim Winter In-Reply-To: <4ACF43CC.2020303@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 13:45:44 +0200 References: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu> <4ACF43CC.2020303@acm.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 11:45:46.0850 (UTC) FILETIME=[89A8C420:01CA4B31] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.005 X-TM-AS-Result: No--18.729000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 11:45:49 -0000 On Oct 9, 2009, at 4:08 PM, Tim Winter wrote: > Mukul Goyal wrote: >> I think both latency and reliability are important metrics. >> > +1 > We have a good consensus to have both latency and reliability. We now need to agree on the units. Unit for latency ? Unit for ETX (I propose to use the ETX): thoughts ? >> I am sort of negative on using memory/CPU availability as metric or >> constraint. They seem like local factors to me. If a node is >> running low on memory/CPU, it can simply not participate in routing. >> >> > Exposing an exaggerated rank might also be an option. > Indeed, although we have planned to use an Overload bit since we may not want all nodes to trigger a DAG recomputation but only to not send traffic until the bit is cleared. Cheers. JP. > -Tim >> Thanks >> Mukul >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "IETF ROLL" >> Cc: "Kris Pister" >> Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada >> Central >> Subject: [Roll] RPL Metric ID >> >> >> Dear all, >> >> We would appreciate your feed-back on RPL routing metrics. >> >> Now that RPL is stabilizing it is time to move forward with the >> METRIC I-D. The next revision will be a major one, with packet >> encoding, processing rules, etc. >> >> We discussed and agreed some time ago on several links and nodes >> metrics (also required according to our requirement IDs). >> >> Still, there are a few metrics for which we would like to know >> whether you think that they should be specified. >> >> 4.2. Latency >> >> >> As with throughput, the latency of many LLN MAC sub-layers can >> be varied over many orders of magnitude, again with a >> corresponding change in current consumption. Some LLN MACs will >> allow the latency to be adjusted globally on the subnet, or on a >> link-by-link basis, or not at all. Some will insist that it be >> fixed for a given link, but allow it to be variable from link to >> link. For efficient operation, nodes must be able to report the >> range of latency that their links can handle, and the currently >> available latency. >> >> 4.3. Link reliability >> >> In LLNs, link reliability is degraded by external interference >> and multi-path interference. Multipath typically affects both >> directions on the link equally, whereas external interference is >> sometimes uni- directional. Time scales vary from milliseconds >> to days, and are often periodic and linked to human activity. >> Packet error rate can generally be measured directly, and other >> metrics (e.g. bit error rate, mean time between failures) are >> typically derived from that. >> >> In addition: >> >> Node Memory resources: >> >> Memory is a critical node resources in presence of constrained >> nodes. Is there a need to report node memory resources as a routing >> metric/constraint ? >> >> Node CPU resources: CPU duty cycle for virtually all LLN >> applications to date is well below 10%, and the trend in low power >> embedded systems is to more capable processors rather than less. >> Computational speed is not expected to be a limiting factor in >> routing in LLNs. Is there a need to report node CPU resources as a >> routing metric/constraint ? >> >> Link Security metrics >> >> Thanks for your feed-back. >> >> JP, Mijeon, Kris. _______________________________________________ >> 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 zach@sensinode.com Mon Oct 12 04:47:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE9F3A69B9 for ; Mon, 12 Oct 2009 04:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbJa79N82qqF for ; Mon, 12 Oct 2009 04:47:40 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EF5A23A69B8 for ; Mon, 12 Oct 2009 04:47:39 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9CBlW9A012302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Oct 2009 14:47:33 +0300 Message-Id: <83C69310-3C03-4018-9E29-2CCDAFDC0079@sensinode.com> From: Zach Shelby To: "Mathilde Durvy (mdurvy)" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 14:47:34 +0300 References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 11:47:41 -0000 On Oct 12, 2009, at 14:32 , Mathilde Durvy (mdurvy) wrote: > > In addition, I don't think this group should care or make any > assumptions on the adaptation layer running below IPv6 as each of them > has it specificities and RPL should remain as generic as possible. > You mean you would like to assign a /64 to every LoWPAN Router in the =20= LLN... And then how about we bind DAOs to NAs in the LoWPAN as well =20 (if RPL binds to ND)? 6LoWPAN is not just an adaptation layer, it does have network =20 architectural aspects as well. The link model is different, and we run =20= 6LoWPAN-ND on that link. RPL doesn't need technical changes to =20 account for the adaptation layer. Just an applicability statement of =20 how it can be used inside a LoWPAN is sufficient. Considering the =20 majority of us will likely use RPL in LoWPANs - it would be insane not =20= to mention it.... - Zach > Best, > Mathilde > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of > Pascal Thubert (pthubert) > Sent: lundi, 12. octobre 2009 12:07 > To: Zach Shelby; Julien Abeille (jabeille) > Cc: IETF ROLL > Subject: Re: [Roll] NA to transport DAO > > Hi Zach > > We are in perfect line. At the moment, RPL would impose NS/NA between > 6LoWPAN routers to expose the host routes. > > At some point in the future, considering that LoWPANs are an obvious > target for RPL, we should be able to define the binding over the =20 > LowPAN > ND. What we really need to move forward there is for ND to progress to > RFC quickly so we can refer to it. > > I think it would be good for this list that you update us on the > progress there. What would be the plan for last call? > > Cheers, > > Pascal > >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: lundi 12 octobre 2009 10:28 >> To: Julien Abeille (jabeille) >> Cc: Pascal Thubert (pthubert); IETF ROLL >> Subject: Re: [Roll] NA to transport DAO >> >> Hi, >> >> On Oct 12, 2009, at 11:04 , Julien Abeille (jabeille) wrote: >> >>> Hi Pascal, all, >>> >>> as I said unsolicited NAs are not frequent if ever sent. Timing >>> constraints are very different and totally decoupled for a NA and a >>> DAO, hence the savings in terms of control messages will be pretty >>> small. The added complexity will be important. This is enough for me >>> to disquilify the use of NAs. >> >> I understand the concern there for RFC4861. >> >>> regarding 6lowpan, again (I think this has been said many times), =20= >>> RPL > >>> is not a protocol for 802.15.4. >> >> Huh? Apples and oranges. We are not talking about 802.15.4. >> >> RPL is an IP routing protocol, and it *must* be useable in 6LoWPAN >> IPv6 networks as well. An alternative binding to draft-ietf-6lowpan-=20= >> nd >> messages should be defined of course as Pascal mentioned below. And >> here the advantages of this are even greater. In 6LoWPAN-ND we do =20 >> have >> periodic NR/NC messages which are not overloaded. >> >> This reminds me - in the next version of RPL we need a section to >> specifically discuss the use of RPL in LoWPANs. The current text >> assumes the LLN is a collection of normal IPv6 links and that RFC4861 >> is used. In a LoWPAN we have a flat network (no prefix assignment to >> LLN Routers) and 6lowpan-nd instead of RFC4861. It is pretty =20 >> confusing >> to read if someone new is trying to figure out how to apply this is a >> LoWPAN... >> >> Zach >> >>> >>> Best, >>> Julien >>> >>> >>> From: Pascal Thubert (pthubert) >>> Sent: lundi 12 octobre 2009 08:24 >>> To: Julien Abeille (jabeille); IETF ROLL >>> Subject: RE: [Roll] NA to transport DAO >>> >>> Hi Julien, >>> >>> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our >>> options into those messages. >>> They create a tighter coupling between the router and the node, =20 >>> which > >>> appears beneficial to the NA DAO process. >>> >>> In the meantime, we made the conscious decision to bind RPL onto ND >>> though we wish to be opened to other bindings. >>> The overloading you are discussing is truly there. >>> In one hand it can be seen as adding complexity. In the other as a >>> way to save control messages. >>> >>> Pascal >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of Julien Abeille (jabeille) >>> Sent: vendredi 9 octobre 2009 15:14 >>> To: IETF ROLL >>> Subject: [Roll] NA to transport DAO >>> >>> Hi all, >>> >>> I have concerns about the use of NA to transport DAOs for the >>> following reasons: >>> - NAs are not routing messages >>> - unsolicited NAs are not very frequent, hence using them for DAOs =20= >>> is > >>> not really piggybacking. We do not gain a lot by using them >>> - NA are already pretty overloaded messages: they are used in 3 >>> procedures, namely address resolution, NUD and DAD >>> - NA processing is implementation wise complex enough because of the >>> point above >>> - implementation wise, coupling RPL with ND makes code much more >>> complex. >>> - the target address field in the NA uses 16 bytes without =20 >>> bringing a > >>> lot of value to RPL. >>> >>> I think using a new ICMP message to carry DAOs would be much better. >>> >>> What do people think? >>> Best, >>> Julien >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may =20 >> contain >> legally privileged information. If you are not the intended =20 >> recipient, >> please contact the sender and delete the e-mail from your system >> without producing, distributing or retaining copies thereof. >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From jvasseur@cisco.com Mon Oct 12 05:46:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06B128C19C for ; Mon, 12 Oct 2009 05:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.979 X-Spam-Level: X-Spam-Status: No, score=-9.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jusq0MD2GMJb for ; Mon, 12 Oct 2009 05:46:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E832628C18E for ; Mon, 12 Oct 2009 05:46:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=7145; q=dns/txt; s=amsiport01001; t=1255351580; x=1256561180; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20reliability=20metrics=20for=20digital=20rad ios|Date:=20Mon,=2012=20Oct=202009=2014:46:18=20+0200 |Message-Id:=20<2863E9BF-442B-4F7C-8415-1BE4192DE977@cisc o.com>|To:=20Richard=20Kelsey=20|Cc:=20roll@ietf.org|Mime-Version:=201.0=20(Apple=20Mess age=20framework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<87iqeobr00.fsf@kelsey-ws.hq.ember.com> |References:=20<87iqeobr00.fsf@kelsey-ws.hq.ember.com>; bh=a+5579E5+t25zfOlZ/UImg4w/+9MuHVwNaoYCbbuYCA=; b=YcOiRM+q1lfMY6BI7aQ/5shmSaWknLKD7macaTHDbwiYyUYRzjb6zups qRxNfkczWU1cOwvqshpXgW5NDnCeWYBhT0+VWXWZbWPcuocQl9UaCKZoi M8PxWs0+362AUrT+OQopuF615EtagSXbyGn5RSEvZZ/vx042qxeDHSNQa E=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAKvB0kqQ/uCWe2dsb2JhbACbDAEBFiQGpC+WY4I8gXEE X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="51543357" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 12:46:19 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CCkJb1007851; Mon, 12 Oct 2009 12:46:19 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:46:19 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:46:18 +0200 Message-Id: <2863E9BF-442B-4F7C-8415-1BE4192DE977@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 14:46:18 +0200 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 12:46:18.0498 (UTC) FILETIME=[FE4A4620:01CA4B39] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 12:46:22 -0000 Hi Richard, On Oct 9, 2009, at 4:07 PM, Richard Kelsey wrote: > Below is a discourse on the reliability characteristics of > 802.15.4 and similar digital radios and what this means for > link metrics. Even if the goal is to maximize something > other than reliability, you still need the links to be > reasonably reliable in order to reduce churn and because no > matter what the metric, broken routes have little utility. > Yes, just to make sure that we are in line, there are two orthogonal aspects here: 1) Link UP/DOWN: if indeed, the link quality crosses some threshold it can be put in DOWN state locally by the node 2) If the Link stays in DOWN state for some period of time, the node may decide to update the metrics in its RA-DIO. > Non-radio links, or other types of radios, will have very > different characteristics. This may make it difficult to > have a good relibility metric that is independent of the > link layer. Yes but ... RPL is L3 thus we want path to be calculated according the link reliability (and I think that we all agree on this requirement), this is what we need to do. And I agree, this is not easy, the idea is to have a good enough way to abstract the link reliability using a single metric. The way to compute that metric is implementation specific and L2 dependent, which is fine. > > ---------------- > Digital radios > > 802.15.4 and similar digital radios have the property that > packet reliability falls off fairly quickly over a short > range of signal quality. A link that is working very > reliabily, with near 100% packet delivery, may degrade > quickly with only a small increase in the local radio noise > or small change in the physical environment. For example, a > link with consistent, near-100% reliability may disappear > entirely if one of the radios is moved as little as a few > cm. Absolutely. Note that this is also true for some PLC links in some conditions. And the goal is not to provide near real time information but a trend. I looked at many traces and one can clearly see a trend for each of them. WE now need to find the right unit. > > Very crudely, the packet reliability graph looks something > like this: > > 100% ______________________ > / > 50% / > / > 0%________________/ > > increasing signal-to-noise (SNR) ratio --> > > Nearby radios can be far off to the right on this graph. > Right. We want to provide a macroscopic view, over some period of time. If the link flaps, this should not filter out, if this becomes fairly common over some period of time, we want to reflect this. > As the local environment changes, the SNR for any particular > link moves up and down (left and right on the graph). This > only matters if the change is sufficient to move the link's > current SNR into the vicinity of the cliff. If so, the link > may lose a significant percentage of packets. If not, > almost all packets are delivered. > > Links at the cliff or to the left are useless. Even if some > packets are getting through, a very small change in the > environment can break the link completely. All links well > to the right are all essentially equivalent; they can be > expected to work every time. Links just to the right of the > cliff are questionable; they work now but their future > performance is uncertain. > > 100% ______________________ > / > 50% / > / > 0%________________/ > > <---- useless --------|---- okay -----|--- good ---> > Yes, this might be a way to represent the quality, with a simple 4-bit flag. Alternatively we can use the ETX value derived from L2, thanks to probing, ... > In the short term, packet reliability measurements cannot > distinguish between okay and good links, because the short > term differences in reliability are not significant. They > can be distinguished by comparing the RSSI of incoming > packets with the current noise floor. Counting chip errors > can help, as chip errors show up somewhat before packets > start to be lost. Whether or not they show up far enough to > the right to be used to tell the difference between 'good' > and 'okay' links is not clear. > > ---------------- > What does this mean for link reliability metrics? > > One point is that tracking observed packet reliability is of > limited use. In the short term 'okay' links may look just > like 'good' links and longer term averages may not react > quickly enough to be useful. > > The main point is that, if you stick to good links, you will > probably do all right just using hop count. All good links > will have about the same success rates in the short or long > term. The trick is to tell the good links from the merely > okay ones. > > I believe that the white bit in the four-bit link estimator > [1], has the effect of keeping traffic mostly on good links. > Good links have few chip errors, okay links will likely have > more. It appears that the four-bit link estimator does not > do any averaging of the white bit. It would be interesting > to determine how much of its performance is due to the use > of the white bit and how much to its ETX estimation, and if > it could be improved by averaging the white bit over time. > > The 'okay' links cannot be ignored, as they are actually > working at the moment and may be the only thing keeping the > network connected. Any additive metric has to define how > many good links are equivalent to one okay one. This isn't > easy to do, because we would really prefer to use an okay > link only if there is no path using only good links. Except > in very unusual topologies, it is unlikely that you will > ever be faced with a choice between one okay link and, say, > five good ones. Well that depends ... the local policy function may say "prefer good links" except if the hop count is reduced by 50% then try to use OK links. > > The simplest metric that maintains this distinction would be > the number of good links and the number of okay ones, kept > as separate values, with the okay link count having > precedence over the good link count (the good counts are > only considered if the okay counts are equal). Right > More > fine-grained metrics are obviously possible, and are likely > to provide some benefit, so long as they strongly prefer > good links over okay ones. > Should we try to use the ETX and couple it with filtering to get the result of distinguishing OK links with Good links ? Cheers. JP. > -Richard Kelsey > > [1] R. Fonseca, O. Gnawali, K. Jamieson, and P. Levis. "Four > Bit Wireless Link Estimation." In the Proceedings of the 6th > Workshop on Hot Topics in Networking (HotNets-VI), 2007. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Oct 12 05:50:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2EB3A69C0 for ; Mon, 12 Oct 2009 05:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.392 X-Spam-Level: X-Spam-Status: No, score=-10.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWLDs2tIksqK for ; Mon, 12 Oct 2009 05:50:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E772B3A63EC for ; Mon, 12 Oct 2009 05:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=2525; q=dns/txt; s=amsiport01001; t=1255351806; x=1256561406; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Mon,=2012=20Oct =202009=2014:50:02=20+0200|Message-Id:=20|To:=20Jonathan=20Hui=20< jhui@archrock.com>|Cc:=20Richard=20Kelsey=20,=20roll@ietf.org,=0D=0A=20=20=20=20=20=20 =20=20kpister@dustnetworks.com|Mime-Version:=201.0=20(App le=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<8DEDF5 76-B215-4993-98A3-29BF8AE2601A@archrock.com>|References: =20=20<0E985639-0382-47B6-9F89-50C7CFA28CAD@cs. stanford.edu>=20<87hbu8bq13.fsf@kelsey-ws.hq.ember.com> =20<8DEDF576-B215-4993-98A3-29BF8AE2601A@archrock.com>; bh=/oxdl35yxlNyENsBCxVb6nQfZiWz+z9yzhQ8wt7H7qQ=; b=Rwdu970Ae6Cu/eW7fbic3HuWXibDKmIQr1YwRX1FHCn5/6Nx5PvGeX6X 3eIjUHx0UTBWXooQLwyphrLKnaPwhFjO1QDxlXKpwIOYai/cIlt6FjCtG hDJeIB279XaysfuMdchIlusmmWI3UqjNLE5oqgiVbJrrNGrJj/PtCPBSG w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAObC0kqQ/uCWe2dsb2JhbACbDAEBFiQGpD+JDwiNTIJFCIFgBA X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="51543693" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 12:50:04 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CCo4SB008871; Mon, 12 Oct 2009 12:50:04 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:50:04 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:50:03 +0200 Message-Id: From: JP Vasseur To: Jonathan Hui In-Reply-To: <8DEDF576-B215-4993-98A3-29BF8AE2601A@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 14:50:02 +0200 References: <0E985639-0382-47B6-9F89-50C7CFA28CAD@cs.stanford.edu> <87hbu8bq13.fsf@kelsey-ws.hq.ember.com> <8DEDF576-B215-4993-98A3-29BF8AE2601A@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 12:50:03.0344 (UTC) FILETIME=[844F0D00:01CA4B3A] Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 12:50:06 -0000 On Oct 9, 2009, at 5:05 PM, Jonathan Hui wrote: > > In general, I agree with both Phil and Richard, but asymmetric links > are a bit ill-defined in this discussion. The implicit meaning in > seems to have been that communication is "good" in one direction > while "bad" in the reverse. Instead, I'd prefer to make a stronger > statement and say that the routing metrics should project symmetric > information about the links - meaning that the computed cost of > using the link in one direction is the same as in the reverse > direction. Obviously, this is more natural in some metrics > (reliability, signal strength) than others (latency, energy). But, > in my experience, relying on symmetric information when it is > natural to do so does simplify the routing problem. on the other hand, if a link is indeed highly asymmetrical in term of reliability for example, wouldn't we want to look at the reliability metric in the direction of interest ? By the way, what is your preference in term of units ? Thanks. JP. > > -- > Jonathan Hui > > On Oct 9, 2009, at 7:28 AM, Richard Kelsey wrote: > >> From: Philip Levis >> Date: Thu, 8 Oct 2009 09:08:40 -0700 >> >> My experience is that asymmetric links are of limited use for >> LLNs. Because LLNs are lossy, they tend to have single-hop >> acknowledgment schemes, either at the link layer or at the network >> layer. Single-hop acknowledgments don't work well in asymmetric >> links. >> Yes, the acknowledgments are shorter and so the ARR (acknowledgment >> reception rate) can be higher than the PRR (packet reception rate), >> but this window is so narrow and the complexity needed to use it is >> significant enough that asymmetric links are more an intellectual >> curiosity rather than something of significant value to exploit. >> >> I completely agree. In addition, if the routing layer >> assumes that links are bidirectional, it is important that >> the any link quality measurement not make the same assumption. >> In other words, either the link layer or routing layer has >> to take asymmetries into account. >> >> -Richard Kelsey >> _______________________________________________ >> 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 richard.kelsey@ember.com Mon Oct 12 05:55:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD9428C1C8 for ; Mon, 12 Oct 2009 05:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAdU0mu8Xb-f for ; Mon, 12 Oct 2009 05:55:38 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4E86F28C1C3 for ; Mon, 12 Oct 2009 05:55:38 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 08:56:44 -0400 Date: Mon, 12 Oct 2009 08:53:58 -0400 Message-Id: <87aazwbwnt.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <54371184-51BD-41C8-AF29-7739DA2267D9@cs.stanford.edu> (message from Philip Levis on Sat, 10 Oct 2009 12:11:54 -0700) From: Richard Kelsey References: <6A2A459175DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com> <87ab00l3mp.fsf@kelsey-ws.hq.ember.com> <54371184-51BD-41C8-AF29-7739DA2267D9@cs.stanford.edu> X-OriginalArrivalTime: 12 Oct 2009 12:56:44.0213 (UTC) FILETIME=[733ECE50:01CA4B3B] Cc: roll@ietf.org Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 12:55:39 -0000 From: Philip Levis Date: Sat, 10 Oct 2009 12:11:54 -0700 On Oct 9, 2009, at 1:21 PM, Richard Kelsey wrote: > From: Philip Levis > Date: Fri, 9 Oct 2009 10:20:05 -0700 > > When we started designing CTP, we tried using sequence numbers as > DSDV > does. The logic to handle all of the edge cases was non-trivial. In > particular, if node A has move to sequence number N+1, but its > child B > is still on sequence number N, then on receiving a packet from child > B, A must forward it with tree N. That is, A must maintain two > trees. > > A can safely forward the packet to its current, N+1, parent. > No looping can occur. Node A is version N. Node B is version N. Node A forwards a packet to node B. Node A receives a beacon with N+1. Node A sends a beacon with N+1, which node B hears. Node B forwards the packet to node A. Personally, I wouldn't call this a loop. At no time is there a loop in the directed graph formed by the routing tables. In a network where links are changing, packets are going to backtrack across links on occasion. Assuming that the sequence number space is stable, the problem will of course work itself out. But in some initial tests, we found that loops such as these (note this is just two nodes, when using sequence number increments you can have routes with very high stretch while the network reconfigures) could significantly increase the cost (transmissions/delivery). Hmm. We have never had a problem with this. Normally we see the sequence number updates travel faster along the better routes, which are the faster/more reliable paths, which in turn causes the updates to settle quickly. I would guess that the difference comes down to timing. The longer the intervals between RA-DIO transmissions, the longer it will take things to settle down. Out of curiosity, what was the minimum trickle delay in your tests? I can see that it would be more of a issue with a metric that is unrelated to latency or reliability. This would remove any correlation between the paths taken by the sequence number updates and the desired paths. Note that this is specific to the sequence number updates; any gradient protocol where the routing information propogates differently than the data packets is going to have problems with churn. A couple of heuristics can help. E.g., if you have sequence number N when you receive a packet, then you should forward that packet as if you were still number N. I think that this would be a mistake. What if the old path is broken? The point to doing the update is to create newer, more reliable paths. Better would be to delay transmitting a packet if its gradient is in flux, similar to what CTP does. -Richard Kelsey ---------------- This message and the information it contains are the proprietary and confidential property of Ember Corporation and may be privileged. If you are not the intended recipient, please do not read, copy, disclose or distribute its contents to any party, and notify the sender immediately. From jvasseur@cisco.com Mon Oct 12 06:09:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C5BB28C100 for ; Mon, 12 Oct 2009 06:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXTD19aOihMB for ; Mon, 12 Oct 2009 06:09:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 99EAE3A63EC for ; Mon, 12 Oct 2009 06:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=7375; q=dns/txt; s=amsiport01001; t=1255352979; x=1256562579; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20A=20proposal=20for=20Traffic=20Loop=20avoid ance,=20detection=20and=20recovery|Date:=20Mon,=2012=20Oc t=202009=2015:09:36=20+0200|Message-Id:=20<9AB3344B-91A7- 464B-BBD8-F3DF9DB7F8A8@cisco.com>|To:=20Mukul=20Goyal=20< mukul@UWM.EDU>|Cc:=20Philip=20Levis=20,=20roll=20|Mime-Version:=201.0=20(Apple =20Message=20framework=20v936)|Content-Transfer-Encoding: =20quoted-printable|In-Reply-To:=20<1443022293.1656461125 5186627055.JavaMail.root@mail02.pantherlink.uwm.edu> |References:=20<1443022293.16564611255186627055.JavaMail. root@mail02.pantherlink.uwm.edu>; bh=XE4TcknGojMBJ1CHgByhrug9vRDnDbsZ6jUYeyD4xZk=; b=KXIqeUvVb7EIFHnS4+dw4nAHTh5z+8dEeAy5GvKajsm5t6hnNHdvhjT5 Kv2to69DTYDk1wPT6WPLr6hA853yUraDGD6wnsQLBlpDgXHjtm6CfhCVp 9ZrGWFVgrnjCkWB98UGFCONv3rJDFed7zdMqoJGkwquBxRC6KU8qs3cCt 4=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAE7H0kqQ/uCWe2dsb2JhbACbDAEBFiQGpFuWZ4QtBIpW X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="51545985" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 13:09:37 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CD9bpL015444; Mon, 12 Oct 2009 13:09:37 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:09:37 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:09:36 +0200 Message-Id: <9AB3344B-91A7-464B-BBD8-F3DF9DB7F8A8@cisco.com> From: JP Vasseur To: Mukul Goyal In-Reply-To: <1443022293.16564611255186627055.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 15:09:36 +0200 References: <1443022293.16564611255186627055.JavaMail.root@mail02.pantherlink.uwm.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 13:09:37.0031 (UTC) FILETIME=[3FE17970:01CA4B3D] Cc: roll Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 13:09:40 -0000 Hi Mukul, On Oct 10, 2009, at 4:57 PM, Mukul Goyal wrote: > Philip > > I agree with you. Loop avoidance/prevention/detection should not be =20= > in the base specs. Another positive implication of your approach =20 > would be that 'rank', rather than being a loop avoidance mechanism, =20= > would simply be the cost to reach the dag root under the routing =20 > metrics being used. Lets agree that we dont want to solve "count to =20= > infinity" problem in base specs. > We just do not want to look simple by having another simplistic core =20 spec augmented with a number of other mechanisms defined in other =20 specs. I think that we should adopt one approach and document all of =20 its aspects in the core spec. Thanks. JP. > Thanks > Mukul > > ----- Original Message ----- > From: "Philip Levis" > To: "Pascal Thubert (pthubert)" > Cc: "roll" > Sent: Friday, October 9, 2009 12:20:05 PM GMT -06:00 US/Canada Central > Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection =20= > and recovery > > > On Oct 9, 2009, at 5:55 AM, Pascal Thubert (pthubert) wrote: > >> Hi: >> >> It seems widely accepted in this group that Loop avoidance in the >> control place should be kept simple but completed by a detection >> mechanism associated to the packets. This approach had been >> validated in CTP and DADR. >> >> After a number of discussions, here is a proposal. The proposal uses >> some info that is placed in the packet in the flow label. >> It assumes that the flow label is reserved for the purpose of RPL >> and node interaction. In the flow label we place: >> >> Outwards : 1 bit >> Sibling : 1 bit >> Rank_error : 1 bit >> DAO_Error : 1 bit >> Rank : 8 bit >> Instance ID : 8 bit >> >> Instance forwarding >> Instance IDs is used to avoid loops between DAGs from different >> origins. >> >> InstanceID is placed by the source in the flow label. It MUST >> matched the DAG instance onto which the packet is placed by a >> router. The router MAY either change the instanceID to match the DAG >> that it is using for this packet or discard the packet. That >> decision is policy based. Default policy TBD. >> >> Idea? >> >> DAG inconsistency loop detection >> The DAG is inconsistent is the packet direction does not match the >> rank relationship. >> >> A host MUST set the rank to FF. A router MUST place its rank in the >> flow label. >> A node emitting a packet must reset the Rank_error bit and the >> Outwards bit. >> A router MUST also reset the Outwards bit if it is using the default >> route inwards, either via a sibling or a parent, and set the bit if >> it is using a DAO route, either via a sibling or a child. >> >> A receiver detects an inconsistency if it receives a packet going >> inwards from a source with a lesser Rank, or outwards with a higher >> rank. >> >> Upon inconsistency, if the Rank_error bit was not set then the >> Rank_error bit is set. If it was set the packet is discarded. This >> is done to cover a rare re-sequencing of the DAG. >> >> Sibling loop avoidance >> A simple rule is that a packet may not make 2 sibling hops in a row. >> >> When a host sends a packet or a router forwards to a non sibling, >> the Sibling bit must be reset. >> When a router forwards to a sibling: if the Sibling bit was not set >> then the Sibling bit is set. If it was set then the packet is >> discarded. >> >> DAO inconsistency loop detection >> A =93parent=94 has an outwards DAO route that is a remnant from an >> obsolete DAO via a =93child=94 but the =93child=94 does not have a = matching >> DOA state. >> >> In a general manner, a packet that goes outwards should never go >> inwards again. So rather than routing inwards a packet with the >> Outwards bit set, the router MUST discard the packet. If DAO >> recovery is in place, then the router MAY send it back to the source. >> >> DAO inconsistency loop recovery >> A Router that supports recovery uses a packet to recursively explore >> and cleanup the obsolete paths. >> >> The =93child=94 router that detects the DAO inconsistency SHOULD set = the >> DAO_Error bit and return the packet to the parent that passed it. >> >> Upon a packet with a DAO bit set, the parent MUST remove the routing >> states that caused forwarding to the child that passed it, clear >> DAO_Error bit and send the packet again. >> > > I advocate taking a more extreme approach: remove the current sequence > number loop prevention mechanisms from the draft. > > Currently, RPL is trying to have it both ways. It's using sequence > numbers to prevent (not just avoid) loops caused by increasing in > rank. However, by allowing nodes to choose siblings, RPL still > requires a loop detection mechanism in data packets. If there is a > mechanism to detect loops with data packets, then there is no need to > have rules on when nodes can increase rank: the decision of whether to > do so or not is a performance design choice. > > When we started designing CTP, we tried using sequence numbers as DSDV > does. The logic to handle all of the edge cases was non-trivial. In > particular, if node A has move to sequence number N+1, but its child B > is still on sequence number N, then on receiving a packet from child > B, A must forward it with tree N. That is, A must maintain two trees. > Overall, the edge cases were complex, required a good deal of code, > and had a lot of tricky edge cases. Furthermore, the prospect of being > floating until a sequence number increment created a difficult tension > between the longest interval a DAG could be floating and the cost of > periodically flooding DAG sequence number updates. > > If there is a way to detect and repair loops in the data path, then > this tension disappears. Loops become an efficiency problem, due to > the extra messages they send. Correspondingly, may protocols have an > inventive to follow the loop prevention guidelines in -03, if doing so > leads to overall better efficiency. But such algorithms and policies > are RECOMMENDED or OPTIONAL performance optimizations on top of a > specification, not part of the specification itself (e.g., think RFC > 2581). > > In summary, I'd argue, that for the sake of simplicity in required > mechanisms, and flexibility in future implementation designs, that RPL > should either: > > 1) Disallow routing through siblings > 2) Allow routing through nodes of higher rank > > I personally think 2) is a better approach, based on my experiences, > as it can remove the need for periodic sequence number increments. But > I think that the current half-way position is worse than either 1) or > 2): it has the worst of both worlds. > > If we make sequence number-based DAG control OPTIONAL, then I'd argue > we should elide it from the main RPL document. Keep the core > specification simple. > > Phil > _______________________________________________ > 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 alexandru.petrescu@gmail.com Mon Oct 12 06:22:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045623A6403 for ; Mon, 12 Oct 2009 06:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaV+MXnY6jgF for ; Mon, 12 Oct 2009 06:22:02 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id E5A863A63EC for ; Mon, 12 Oct 2009 06:22:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CDLqTx032730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 15:21:52 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CDLqLs016410; Mon, 12 Oct 2009 15:21:52 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CDLpYR014025; Mon, 12 Oct 2009 15:21:52 +0200 Message-ID: <4AD32D6F.7090406@gmail.com> Date: Mon, 12 Oct 2009 15:21:51 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> In-Reply-To: <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 13:22:03 -0000 JP Vasseur a écrit : > > On Oct 12, 2009, at 12:56 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : [...] >>> There is a consensus that a reliability metric is needed (note >>> that we are not limited to radio links). Several metrics have >>> been used for years such as ETX. >> >> I strongly disagree on using ETX. >> >> ETX relies on probabilities ("a Bernoulli trial"), i.e. it is not >> as hard data as hopcount is. >> >> ETX does not relate directly to the energy consumed per packet. It >> may have a positive influence on it, but it does not depend on it. >> >> >> ETX is unnecessarily complex due to taking into account the >> re-transmissions, i.e. noisy environments. >> >> ETX claims to be additive ("ETX of a route is the sum of ETX of >> each link") but probabilities are not as additive (20% success rate >> on a link and 30% success rate on another link don't make for 50% >> path success rate, but for 30% success rate - the least common >> denominator). >> > > Thanks for your input. Let's see what other say. I personally like > the ETX. > >> I suggest using a link metric which is simply the energy quantity >> needed to send an IP packet of size 1280 bytes, on a particular >> link, full success rate. > > But not only the use of energy is very much arguable Arguable? "Low power networks" in ROLL title is not about link energy? > but it does not reflect the link quality, a must in LLN. What would > you prefer then for the quality metric ? I think a common link quality metric is impossible to define consensually, especially in case of heterogeneous links. On the other hand, the energy Joules needed to send a fixed-size packet seems easier to grasp as a common metric. Alex From jvasseur@cisco.com Mon Oct 12 06:31:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17E828C1CF for ; Mon, 12 Oct 2009 06:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxnhaCs9O+SI for ; Mon, 12 Oct 2009 06:31:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7997128C1BF for ; Mon, 12 Oct 2009 06:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=5792; q=dns/txt; s=amsiport01001; t=1255354316; x=1256563916; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20I-D|Date:=20Mon,=2012=20Oct =202009=2015:27:39=20+0200|Message-Id:=20<919800CD-E8BC-4 33F-8206-0B3190376DBB@cisco.com>|To:=20Alexandru=20Petres cu=20|Cc:=20IETF=20ROLL=20< roll@ietf.org>,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20 v936)|In-Reply-To:=20<4AD30746.9040807@gmail.com> |References:=20=20<4ACDF4C6.5020109@gmail.com>=20<42382722-B852-4B 20-A3D3-4C2E4C4FF871@cisco.com>=20<4ACF78A9.8040405@gmail .com>=20 =20<4AD30746.9040807@gmail.com>; bh=OIZr6QipadukJ3pro/Z4PaCXArEA7iqTWDsr1Bi9OKY=; b=ERvq8jL/TXxo7DmzFQ/+MitJUSohZn1ZoRWXR0VMasQNSkQ6rCiqJzVp eUyCHky8Oj8kQy5KpuJIm9u5RAi7aHB33ag9TtJHmC/2IWt8ZfbBV4bW2 TJz8gRFzuWC0Ofld/9bmwEYjRY9T1/mxVIhvoclA6W+lUghw/jdKpUOG1 Y=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMAAEHM0kqQ/uCWe2dsb2JhbACCKCyYOAEBFiQGpGaWZoQtBA X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208,217";a="51548856" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 13:31:54 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CDVsOZ023508; Mon, 12 Oct 2009 13:31:54 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:31:54 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:31:54 +0200 Message-Id: <919800CD-E8BC-433F-8206-0B3190376DBB@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AD30746.9040807@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-20-21468841 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 15:27:39 +0200 References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> <4AD30746.9040807@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 13:31:54.0228 (UTC) FILETIME=[5CE98B40:01CA4B40] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--10.580900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 13:31:57 -0000 --Apple-Mail-20-21468841 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Alex, > [snip] >>> We could struggle to compare a path with high energy cost yet low >>> hopcount cost to a path with low energy cost yet high hopcount >>> cost. Is >>> P1 preferable over P2 or vice-versa? >>> >>> I think this is a question to which one can't answer without >>> knowing the >>> deployment context. >>> >> Well at least we need one example where it could be useful. I can't >> find of any personally. > > Here is one: > -- -- > |R1| |R2| > -- -- > | | > | | > | | > | | > \ ---- / > |Host| > ---- > > R1 and R2 send two different RAs. Each pretends to be a default > router (non-zero Router Lifetime) and send different "link energy > metrics" to Host. Link energy relates to which link ? > Host has thus a choice between R1 and R2 based on that link energy > metric. > > What do you think about this use case? > >> What matters is how much of energy left you have, not how much of >> energy you may consume, no ? > > In a sense yes, makes think of "node" energy metrics. > > I think it is also importnat for the nodes to know in advance how > much energy they need in order to send a packet on a certain link. > > Alex > > --Apple-Mail-20-21468841 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Alex,

[snip]

We = could struggle to compare a path with high energy cost yet = low
hopcount cost to a path with low energy cost yet high = hopcount cost. Is
P1 preferable over P2 or = vice-versa?

I think this is a question to = which one can't answer without knowing = the
deployment = context.

Well= at least we need one example where it could be useful. I can't find of = any personally.

Here is one:
=             &n= bsp;        -- =        --
=             &n= bsp;       |R1| =      |R2|
=             &n= bsp;        -- =        --
=             &n= bsp;         | =        |
=             &n= bsp;         | =        |
=             &n= bsp;         | =        |
=             &n= bsp;         | =        |
=             &n= bsp;          \ ---- = /
=             &n= bsp;           |Hos= t|
=             &n= bsp;           &nbs= p;----

R1 and R2 send two different RAs.  Each pretends to = be a default router (non-zero Router Lifetime) and send different "link = energy metrics" to Host. =  

Link energy relates to = which link ?

Host  has thus = a choice between R1 and R2 based on that link energy metric.

What = do you think about this use case?

What = matters is how much of energy left you have, not how much of energy you = may consume, no ?

In a sense yes, makes think of = "node" energy metrics.

I think it is also importnat for the nodes = to know in advance how much energy they need in order to send a packet = on a certain = link.

Alex



= --Apple-Mail-20-21468841-- From jvasseur@cisco.com Mon Oct 12 06:32:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D2228C1CF for ; Mon, 12 Oct 2009 06:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.496 X-Spam-Level: X-Spam-Status: No, score=-8.496 tagged_above=-999 required=5 tests=[AWL=-1.897, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0fAIpP5fqzB for ; Mon, 12 Oct 2009 06:32:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8A81328C1BF for ; Mon, 12 Oct 2009 06:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=2243; q=dns/txt; s=sjiport06001; t=1255354326; x=1256563926; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20ETX=20metric|Date:=20Mon,=2012=20Oct=202009=2015:29: 56=20+0200|Message-Id:=20<1B65245C-1BC6-4ECB-9CE9-7778466 8DC8B@cisco.com>|To:=20Alexandru=20Petrescu=20|Cc:=20Richard=20Kelsey=20,=20roll@ietf.org,=0D=0A=20=20=20=20=20=20 =20=20kpister@dustnetworks.com|Mime-Version:=201.0=20(App le=20Message=20framework=20v936) |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AD32D6F.7090406@gmail.com>|References: =20=09<87ljjmapxh.fsf@kelsey-ws.hq.ember.com> =20=20<4A CF754C.2000604@gmail.com>=20<2F8F6405-4B87-4A62-9040-717A 5D956B42@cisco.com>=20<4AD30B6B.3030802@gmail.com>=20<1D9 3951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com>=20<4AD32D6F. 7090406@gmail.com>; bh=9h3kznLsmFKD4LttSmqzoO3xIJN8+lCUjuGs7h+Vmck=; b=txZZr3VLTXD01dWjmrqoMDAUt+SyZ9ylZ+yG8yDVv8T4dxrXuW+ul5Q4 hDSfQpIXq2E5dLZWQyTAJGvnc6ZLlmoKT1zeE8IPQ9angmbXQPoDAgcFc G/Geif1yZZTcYwhcIU+RctTq1vtuw6p/UaoqvAdaALsWLHqEvi42usyr+ I=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAK7M0kqrRN+K/2dsb2JhbADAM4kPCI1PgkUIgWAE X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="407358567" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 12 Oct 2009 13:32:06 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9CDVjwJ017744; Mon, 12 Oct 2009 13:32:05 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:31:57 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:31:57 +0200 Message-Id: <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AD32D6F.7090406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 15:29:56 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 13:31:57.0713 (UTC) FILETIME=[5EFD5010:01CA4B40] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--13.461500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 13:32:06 -0000 On Oct 12, 2009, at 3:21 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 12, 2009, at 12:56 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : [...] >>>> There is a consensus that a reliability metric is needed (note =20 >>>> that we are not limited to radio links). Several metrics have =20 >>>> been used for years such as ETX. >>> I strongly disagree on using ETX. >>> ETX relies on probabilities ("a Bernoulli trial"), i.e. it is not =20= >>> as hard data as hopcount is. >>> ETX does not relate directly to the energy consumed per packet. It >>> may have a positive influence on it, but it does not depend on it. >>> ETX is unnecessarily complex due to taking into account the re-=20 >>> transmissions, i.e. noisy environments. >>> ETX claims to be additive ("ETX of a route is the sum of ETX of =20 >>> each link") but probabilities are not as additive (20% success rate >>> on a link and 30% success rate on another link don't make for 50% =20= >>> path success rate, but for 30% success rate - the least common =20 >>> denominator). >> Thanks for your input. Let's see what other say. I personally like =20= >> the ETX. >>> I suggest using a link metric which is simply the energy quantity =20= >>> needed to send an IP packet of size 1280 bytes, on a particular =20 >>> link, full success rate. >> But not only the use of energy is very much arguable > > Arguable? > > "Low power networks" in ROLL title is not about link energy? > But the objective of the RPL is to provide you the best path according =20= to some metrics. I may have a path requiring more energy than another one but if it =20 goes across main powered nodes, this may be the preferable path. Node energy is different and covered in the ID. >> but it does not reflect the link quality, a must in LLN. What would >> you prefer then for the quality metric ? > > I think a common link quality metric is impossible to define =20 > consensually, especially in case of heterogeneous links. > > On the other hand, the energy Joules needed to send a fixed-size =20 > packet seems easier to grasp as a common metric. But they are completely different metrics ! JP. > > Alex > > From jvasseur@cisco.com Mon Oct 12 06:32:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F8E28C1E5 for ; Mon, 12 Oct 2009 06:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.224 X-Spam-Level: X-Spam-Status: No, score=-8.224 tagged_above=-999 required=5 tests=[AWL=-1.626, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7yvd9R3KBNX for ; Mon, 12 Oct 2009 06:32:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DAD2B28C1BF for ; Mon, 12 Oct 2009 06:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=5792; q=dns/txt; s=sjiport01001; t=1255354330; x=1256563930; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20I-D|Date:=20Mon,=2012=20Oct =202009=2015:31:56=20+0200|Message-Id:=20<566F6D97-376E-4 D36-8602-A3E2808F4682@cisco.com>|To:=20Alexandru=20Petres cu=20|Cc:=20IETF=20ROLL=20< roll@ietf.org>,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20 v936)|In-Reply-To:=20<4AD30746.9040807@gmail.com> |References:=20=20<4ACDF4C6.5020109@gmail.com>=20<42382722-B852-4B 20-A3D3-4C2E4C4FF871@cisco.com>=20<4ACF78A9.8040405@gmail .com>=20 =20<4AD30746.9040807@gmail.com>; bh=W95shl5vnlbVd0MoNFpZo5KCvRsf0fHCNW2STYXLkho=; b=dJB+7EQHSWFMeOXunxQtvY3y13Px5NEuz0KHOpEym/87qoAJOgRmPrAY 9KFChkWP+qT7Zz4sovzippM2M7StqEvTOd1s7rCFE5bU/Feczz0wxEUrm mnLKE/E5INWKgFE7vR6bw5Ur4t6BMTCCvypLYwRxH6o95aHzj/7hfhVyJ w=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEAEHM0kqrRN+K/2dsb2JhbACCKCy9YJZmhC0E X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208,217";a="254571200" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2009 13:32:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9CDW8s6017985; Mon, 12 Oct 2009 13:32:10 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:32:00 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 15:32:00 +0200 Message-Id: <566F6D97-376E-4D36-8602-A3E2808F4682@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AD30746.9040807@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-22-21726304 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 15:31:56 +0200 References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> <4AD30746.9040807@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 13:32:00.0119 (UTC) FILETIME=[606C7070:01CA4B40] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--10.580900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 13:32:12 -0000 --Apple-Mail-22-21726304 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Alex, > [snip] >>> We could struggle to compare a path with high energy cost yet low >>> hopcount cost to a path with low energy cost yet high hopcount >>> cost. Is >>> P1 preferable over P2 or vice-versa? >>> >>> I think this is a question to which one can't answer without >>> knowing the >>> deployment context. >>> >> Well at least we need one example where it could be useful. I can't >> find of any personally. > > Here is one: > -- -- > |R1| |R2| > -- -- > | | > | | > | | > | | > \ ---- / > |Host| > ---- > > R1 and R2 send two different RAs. Each pretends to be a default > router (non-zero Router Lifetime) and send different "link energy > metrics" to Host. Link energy relates to which link ? > Host has thus a choice between R1 and R2 based on that link energy > metric. > > What do you think about this use case? > >> What matters is how much of energy left you have, not how much of >> energy you may consume, no ? > > In a sense yes, makes think of "node" energy metrics. > > I think it is also importnat for the nodes to know in advance how > much energy they need in order to send a packet on a certain link. > > Alex > > --Apple-Mail-22-21726304 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Alex,

[snip]

We = could struggle to compare a path with high energy cost yet = low
hopcount cost to a path with low energy cost yet high = hopcount cost. Is
P1 preferable over P2 or = vice-versa?

I think this is a question to = which one can't answer without knowing = the
deployment = context.

Well= at least we need one example where it could be useful. I can't find of = any personally.

Here is one:
=             &n= bsp;        -- =        --
=             &n= bsp;       |R1| =      |R2|
=             &n= bsp;        -- =        --
=             &n= bsp;         | =        |
=             &n= bsp;         | =        |
=             &n= bsp;         | =        |
=             &n= bsp;         | =        |
=             &n= bsp;          \ ---- = /
=             &n= bsp;           |Hos= t|
=             &n= bsp;           &nbs= p;----

R1 and R2 send two different RAs.  Each pretends to = be a default router (non-zero Router Lifetime) and send different "link = energy metrics" to Host. =  

Link energy relates to = which link ?

Host  has thus = a choice between R1 and R2 based on that link energy metric.

What = do you think about this use case?

What = matters is how much of energy left you have, not how much of energy you = may consume, no ?

In a sense yes, makes think of = "node" energy metrics.

I think it is also importnat for the nodes = to know in advance how much energy they need in order to send a packet = on a certain = link.

Alex



= --Apple-Mail-22-21726304-- From alexandru.petrescu@gmail.com Mon Oct 12 07:00:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B2A28C1E3 for ; Mon, 12 Oct 2009 07:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DZv1g+TQ-u1 for ; Mon, 12 Oct 2009 07:00:27 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id D52EE28C1E0 for ; Mon, 12 Oct 2009 07:00:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CE0JIv012326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 16:00:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CE0Jdi028860; Mon, 12 Oct 2009 16:00:19 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CE0JeT029392; Mon, 12 Oct 2009 16:00:19 +0200 Message-ID: <4AD33673.8030400@gmail.com> Date: Mon, 12 Oct 2009 16:00:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> <4AD30746.9040807@gmail.com> <919800CD-E8BC-433F-8206-0B3190376DBB@cisco.com> In-Reply-To: <919800CD-E8BC-433F-8206-0B3190376DBB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:00:27 -0000 JP Vasseur a écrit : > Hi Alex, > >> [snip] > >>>> We could struggle to compare a path with high energy cost yet low >>>> hopcount cost to a path with low energy cost yet high hopcount cost. Is >>>> P1 preferable over P2 or vice-versa? >>>> >>>> I think this is a question to which one can't answer without knowing the >>>> deployment context. >>>> >>> Well at least we need one example where it could be useful. I can't >>> find of any personally. >> >> Here is one: >> -- -- >> |R1| |R2| >> -- -- >> | | >> | | >> | | >> | | >> \ ---- / >> |Host| >> ---- >> >> R1 and R2 send two different RAs. Each pretends to be a default >> router (non-zero Router Lifetime) and send different "link energy >> metrics" to Host. > > Link energy relates to which link ? Link energy metric in RA relates to the link on which that RA is sent. One RA is typically sent on a single link. In the above figure there are two links. Is this ok? Alex From alexandru.petrescu@gmail.com Mon Oct 12 07:04:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7454E28C1FC for ; Mon, 12 Oct 2009 07:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBnU-6xTHCbq for ; Mon, 12 Oct 2009 07:04:25 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7FD28C1EC for ; Mon, 12 Oct 2009 07:04:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CE4EVn026115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 16:04:14 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CE4EmT030274; Mon, 12 Oct 2009 16:04:14 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CE4D9v014999; Mon, 12 Oct 2009 16:04:14 +0200 Message-ID: <4AD3375D.8020101@gmail.com> Date: Mon, 12 Oct 2009 16:04:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> In-Reply-To: <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:04:26 -0000 JP Vasseur a écrit : > > On Oct 12, 2009, at 3:21 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 12, 2009, at 12:56 PM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : [...] >>>>> There is a consensus that a reliability metric is needed (note that >>>>> we are not limited to radio links). Several metrics have been used >>>>> for years such as ETX. >>>> I strongly disagree on using ETX. >>>> ETX relies on probabilities ("a Bernoulli trial"), i.e. it is not as >>>> hard data as hopcount is. >>>> ETX does not relate directly to the energy consumed per packet. It >>>> may have a positive influence on it, but it does not depend on it. >>>> ETX is unnecessarily complex due to taking into account the >>>> re-transmissions, i.e. noisy environments. >>>> ETX claims to be additive ("ETX of a route is the sum of ETX of each >>>> link") but probabilities are not as additive (20% success rate >>>> on a link and 30% success rate on another link don't make for 50% >>>> path success rate, but for 30% success rate - the least common >>>> denominator). >>> Thanks for your input. Let's see what other say. I personally like >>> the ETX. >>>> I suggest using a link metric which is simply the energy quantity >>>> needed to send an IP packet of size 1280 bytes, on a particular >>>> link, full success rate. >>> But not only the use of energy is very much arguable >> >> Arguable? >> >> "Low power networks" in ROLL title is not about link energy? >> > > But the objective of the RPL is to provide you the best path according > to some metrics. Yes. > I may have a path requiring more energy than another one but if it goes > across main powered nodes, this may be the preferable path. I agree. The same argument applies to a potentially newly defined "link quality" metric and wired links substituting for the mains-powered node. I.e.: I may have a path requiring less quality than another one but if it goes across wired links, this may be the preferable path. > Node energy is different and covered in the ID. > >>> but it does not reflect the link quality, a must in LLN. What would >>> you prefer then for the quality metric ? >> >> I think a common link quality metric is impossible to define >> consensually, especially in case of heterogeneous links. >> >> On the other hand, the energy Joules needed to send a fixed-size >> packet seems easier to grasp as a common metric. > > But they are completely different metrics ! I agree: link-energy metrics and link-quality metrics are different. Would it hurt if both were discussed and included in the draft? Alex > > JP. > >> >> Alex >> >> > > From jvasseur@cisco.com Mon Oct 12 07:05:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4519528C1EC for ; Mon, 12 Oct 2009 07:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU5mn40JCoDO for ; Mon, 12 Oct 2009 07:05:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B70A228C203 for ; Mon, 12 Oct 2009 07:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3237; q=dns/txt; s=amsiport01001; t=1255356348; x=1256565948; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Mon,=2012=20Oct=202009 =2016:05:45=20+0200|Message-Id:=20|To:=20Alexandru=20Petrescu=20|Cc:=20roll@ietf.org,=20kpist er@dustnetworks.com|Mime-Version:=201.0=20(Apple=20Messag e=20framework=20v936)|Content-Transfer-Encoding:=20quoted -printable|In-Reply-To:=20<4AD3375D.8020101@gmail.com> |References:=20=09<87ljjmapxh.fsf@kelsey-ws.hq. ember.com>=20=20<4ACF754C.2000604@gmail.com>=20<2F8F6405-4B87-4A62 -9040-717A5D956B42@cisco.com>=20<4AD30B6B.3030802@gmail.c om>=20<1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com>=20 <4AD32D6F.7090406@gmail.com>=20<1B65245C-1BC6-4ECB-9CE9-7 7784668DC8B@cisco.com>=20<4AD3375D.8020101@gmail.com>; bh=oIMTUNTOX2kMxIVm7K8gnqd4rXW1QHK/1aV2TnlGeSs=; b=FpKJz3b3dynDkzuS+g5baAv5MDSx5Dj2eYxNNFc3vm7JkjFvvCC+1PSe 0aWsaZirbzIfR2qdrOlJgbBLhTkndJkjUOBTntIw/VmCMXfxvCc1UVD01 rTKhR6VgBFoDnb0q7HjE1bVYFhkxjyiwI53Xy30dpVT6I/DH66tBdIBkJ 4=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAC/U0kqQ/uCWe2dsb2JhbACbDAEBFiQGpFWJDwiNVIJFCIFgBA X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="51553477" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 14:05:47 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CE5keI006228; Mon, 12 Oct 2009 14:05:46 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:05:46 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:05:46 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AD3375D.8020101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 16:05:45 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <4AD3375D.8020101@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 14:05:46.0411 (UTC) FILETIME=[18300FB0:01CA4B45] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--14.427300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:05:49 -0000 On Oct 12, 2009, at 4:04 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 12, 2009, at 3:21 PM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Oct 12, 2009, at 12:56 PM, Alexandru Petrescu wrote: >>>>> JP Vasseur a =E9crit : [...] >>>>>> There is a consensus that a reliability metric is needed (note =20= >>>>>> that we are not limited to radio links). Several metrics have =20 >>>>>> been used for years such as ETX. >>>>> I strongly disagree on using ETX. >>>>> ETX relies on probabilities ("a Bernoulli trial"), i.e. it is =20 >>>>> not as hard data as hopcount is. >>>>> ETX does not relate directly to the energy consumed per packet. =20= >>>>> It >>>>> may have a positive influence on it, but it does not depend on it. >>>>> ETX is unnecessarily complex due to taking into account the re-=20 >>>>> transmissions, i.e. noisy environments. >>>>> ETX claims to be additive ("ETX of a route is the sum of ETX of =20= >>>>> each link") but probabilities are not as additive (20% success =20 >>>>> rate >>>>> on a link and 30% success rate on another link don't make for =20 >>>>> 50% path success rate, but for 30% success rate - the least =20 >>>>> common denominator). >>>> Thanks for your input. Let's see what other say. I personally =20 >>>> like the ETX. >>>>> I suggest using a link metric which is simply the energy =20 >>>>> quantity needed to send an IP packet of size 1280 bytes, on a =20 >>>>> particular link, full success rate. >>>> But not only the use of energy is very much arguable >>> >>> Arguable? >>> >>> "Low power networks" in ROLL title is not about link energy? >>> >> But the objective of the RPL is to provide you the best path =20 >> according to some metrics. > > Yes. > >> I may have a path requiring more energy than another one but if it =20= >> goes across main powered nodes, this may be the preferable path. > > I agree. The same argument applies to a potentially newly defined =20= > "link quality" metric and wired links substituting for the mains-=20 > powered node. > > I.e.: I may have a path requiring less quality than another one but =20= > if it goes across wired links, this may be the preferable path. > >> Node energy is different and covered in the ID. >>>> but it does not reflect the link quality, a must in LLN. What would >>>> you prefer then for the quality metric ? >>> >>> I think a common link quality metric is impossible to define =20 >>> consensually, especially in case of heterogeneous links. >>> >>> On the other hand, the energy Joules needed to send a fixed-size =20 >>> packet seems easier to grasp as a common metric. >> But they are completely different metrics ! > > I agree: link-energy metrics and link-quality metrics are different. > > Would it hurt if both were discussed and included in the draft? > Not at all. As a matter of fact we will have more than one. The =20 question is whether one can make use of the link energy metric. Thanks. JP. > Alex > > > >> JP. >>> >>> Alex >>> >>> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Mon Oct 12 07:08:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98743A6885 for ; Mon, 12 Oct 2009 07:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqMQRscda4xf for ; Mon, 12 Oct 2009 07:08:29 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C5BF328C1B7 for ; Mon, 12 Oct 2009 07:08:28 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CE83Xl030809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 16:08:03 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CE83xX031449; Mon, 12 Oct 2009 16:08:03 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CE83AM016568; Mon, 12 Oct 2009 16:08:03 +0200 Message-ID: <4AD33843.8080301@gmail.com> Date: Mon, 12 Oct 2009 16:08:03 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <4AD3375D.8020101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org, kpister@dustnetworks.com Subject: Re: [Roll] link-energy metric (was: ETX metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:08:30 -0000 JP Vasseur a écrit : > > On Oct 12, 2009, at 4:04 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 12, 2009, at 3:21 PM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> On Oct 12, 2009, at 12:56 PM, Alexandru Petrescu wrote: >>>>>> JP Vasseur a écrit : [...] >>>>>>> There is a consensus that a reliability metric is needed (note >>>>>>> that we are not limited to radio links). Several metrics have >>>>>>> been used for years such as ETX. >>>>>> I strongly disagree on using ETX. >>>>>> ETX relies on probabilities ("a Bernoulli trial"), i.e. it is not >>>>>> as hard data as hopcount is. >>>>>> ETX does not relate directly to the energy consumed per packet. It >>>>>> may have a positive influence on it, but it does not depend on it. >>>>>> ETX is unnecessarily complex due to taking into account the >>>>>> re-transmissions, i.e. noisy environments. >>>>>> ETX claims to be additive ("ETX of a route is the sum of ETX of >>>>>> each link") but probabilities are not as additive (20% success rate >>>>>> on a link and 30% success rate on another link don't make for 50% >>>>>> path success rate, but for 30% success rate - the least common >>>>>> denominator). >>>>> Thanks for your input. Let's see what other say. I personally like >>>>> the ETX. >>>>>> I suggest using a link metric which is simply the energy quantity >>>>>> needed to send an IP packet of size 1280 bytes, on a particular >>>>>> link, full success rate. >>>>> But not only the use of energy is very much arguable >>>> >>>> Arguable? >>>> >>>> "Low power networks" in ROLL title is not about link energy? >>>> >>> But the objective of the RPL is to provide you the best path >>> according to some metrics. >> >> Yes. >> >>> I may have a path requiring more energy than another one but if it >>> goes across main powered nodes, this may be the preferable path. >> >> I agree. The same argument applies to a potentially newly defined >> "link quality" metric and wired links substituting for the >> mains-powered node. >> >> I.e.: I may have a path requiring less quality than another one but if >> it goes across wired links, this may be the preferable path. >> >>> Node energy is different and covered in the ID. >>>>> but it does not reflect the link quality, a must in LLN. What would >>>>> you prefer then for the quality metric ? >>>> >>>> I think a common link quality metric is impossible to define >>>> consensually, especially in case of heterogeneous links. >>>> >>>> On the other hand, the energy Joules needed to send a fixed-size >>>> packet seems easier to grasp as a common metric. >>> But they are completely different metrics ! >> >> I agree: link-energy metrics and link-quality metrics are different. >> >> Would it hurt if both were discussed and included in the draft? >> > > Not at all. As a matter of fact we will have more than one. The question > is whether one can make use of the link energy metric. That is a good question deserving discussion: how to make use of a link-energy metric. Alex From maxence.dalmais@insa-lyon.fr Mon Oct 12 06:57:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29F0B28C1BD for ; Mon, 12 Oct 2009 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8w4z4fn404j for ; Mon, 12 Oct 2009 06:57:47 -0700 (PDT) Received: from smtp.insa-lyon.fr (criges14.insa-lyon.fr [134.214.76.242]) by core3.amsl.com (Postfix) with ESMTP id 183923A67DB for ; Mon, 12 Oct 2009 06:57:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 21E35F1322 for ; Mon, 12 Oct 2009 15:57:44 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNA-SM8cOISe for ; Mon, 12 Oct 2009 15:57:41 +0200 (CEST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: mdalmais1) by smtp.insa-lyon.fr (Postfix) with ESMTPSA id 76194F1341 for ; Mon, 12 Oct 2009 15:57:41 +0200 (CEST) Received: by fg-out-1718.google.com with SMTP id d23so1025967fga.13 for ; Mon, 12 Oct 2009 06:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.139.91 with SMTP id s27mr425600hbs.84.1255355860218; Mon, 12 Oct 2009 06:57:40 -0700 (PDT) In-Reply-To: References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> From: Maxence Dalmais Date: Mon, 12 Oct 2009 15:57:20 +0200 Message-ID: To: JP Vasseur , roll@ietf.org Content-Type: multipart/alternative; boundary=001485f6cd1a1d749c0475bd50c3 X-Mailman-Approved-At: Mon, 12 Oct 2009 07:19:57 -0700 Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:19:33 -0000 --001485f6cd1a1d749c0475bd50c3 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, "Low power networks" in ROLL title is not about link energy? >> >> > But the objective of the RPL is to provide you the best path according to > some metrics. > I may have a path requiring more energy than another one but if it goes > across main powered nodes, this may be the preferable path. > Node energy is different and covered in the ID. > I agree with you, but maybe something is missing: Title is too about lossy network. Loss in wireless network is due to noise. Sure one could argue that noise is a layer 2 (not 3) problem but that argumentation won't make RPL better. The fact is that sending a high energy cost packet won't be a problem for a mains powered node, but it will induce noise and impact the links of the entire network. Maxence. --001485f6cd1a1d749c0475bd50c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,


"Low power networks" in ROLL title is not about link energy?


But the objective of the RPL is to provide you the best path according to s= ome metrics.
I may have a path requiring more energy than another one but if it goes across main powered nodes, this may be the preferable path.
Node energy is different and covered in the ID.

=

I agree with you, but maybe something is missing:
Title is too about lossy network. Loss in wireless network is due to noise. Sure one could argue that noise is a layer 2 (not 3) problem but that argumentation won't make RPL better.
The fact is that sending a high energy cost packet won't be a problem for a mains powered node, but it will induce noise and impact the links of the entire network.

Maxence. --001485f6cd1a1d749c0475bd50c3-- From jvasseur@cisco.com Mon Oct 12 07:24:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DECB3A6929 for ; Mon, 12 Oct 2009 07:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.086 X-Spam-Level: X-Spam-Status: No, score=-8.086 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac-K56jNyvEV for ; Mon, 12 Oct 2009 07:24:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5EFC93A68CE for ; Mon, 12 Oct 2009 07:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1236; q=dns/txt; s=sjiport01001; t=1255357461; x=1256567061; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Mon,=2012=20Oct=202009 =2016:12:18=20+0200|Message-Id:=20<9520C3BF-A9A0-45F2-907 9-E3C7BB7C8469@cisco.com>|To:=20Maxence=20Dalmais=20|Cc:=20roll@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20=20=20<87ljjmapxh.fsf@kelsey-ws. hq.ember.com>=20=20=20<4ACF754C.2000604@gmail.com>=20<2F8F6405-4B8 7-4A62-9040-717A5D956B42@cisco.com>=20=20<4AD30B6B.303080 2@gmail.com>=20<1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisc o.com>=20=20<4AD32D6F.7090406@gmail.com>=20<1B65245C-1BC6 -4ECB-9CE9-77784668DC8B@cisco.com>=20=20=20; bh=GlfbxBbWRJ0scKZACIvzCD+0ADriSb13knYAJC5vB6c=; b=AQ7csIzXxVh4RA7oFiBI0X56PG/cCn4XWZo7tAYoV6DXCm/VTCta3kTY 8H9is+O7qCs6kyfengUkQyqayD1k5UDPX626KISLBIg7M3B96Ii8h8Udm Fg/ejwLzQfdlN9zuAlQ5G4H9kVGQW/Lo5nejc+g9kep9FXdhN5pbgRV+x Q=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABvZ0kqrR7H+/2dsb2JhbADAN5ZuhC0E X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="254596297" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2009 14:24:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9CEOEGR013364; Mon, 12 Oct 2009 14:24:20 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:24:17 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:24:17 +0200 Message-Id: <9520C3BF-A9A0-45F2-9079-E3C7BB7C8469@cisco.com> From: JP Vasseur To: Maxence Dalmais In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 16:12:18 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 14:24:17.0066 (UTC) FILETIME=[AE3090A0:01CA4B47] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--9.320400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:24:21 -0000 Hi Maxence, On Oct 12, 2009, at 3:57 PM, Maxence Dalmais wrote: > Hi JP, > > > "Low power networks" in ROLL title is not about link energy? > > > But the objective of the RPL is to provide you the best path > according to some metrics. > I may have a path requiring more energy than another one but if it > goes across main powered nodes, this may be the preferable path. > Node energy is different and covered in the ID. > > > I agree with you, but maybe something is missing: > Title is too about lossy network. Loss in wireless network is due to > noise. Sure one could argue that noise is a layer 2 (not 3) problem > but that argumentation won't make RPL better. Indeed. Note that "lossy" also applies to PLC links but we're in sync. > The fact is that sending a high energy cost packet won't be a > problem for a mains powered node, but it will induce noise and > impact the links of the entire network. That is a second order effect though and not true for PLC link. It is bit of a stretch to choose a low energy path, because of a high energy path may cause increase noise along that path thus leading to more errors ... don't you think ? Thanks. JP. > > Maxence. From jvasseur@cisco.com Mon Oct 12 07:24:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5691D28C20C for ; Mon, 12 Oct 2009 07:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.086 X-Spam-Level: X-Spam-Status: No, score=-8.086 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqykm51gtVya for ; Mon, 12 Oct 2009 07:24:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3009A28C207 for ; Mon, 12 Oct 2009 07:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1236; q=dns/txt; s=sjiport06001; t=1255357464; x=1256567064; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Mon,=2012=20Oct=202009 =2016:18:18=20+0200|Message-Id:=20|To:=20Maxence=20Dalmais=20|Cc:=20roll@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20=20=20<87ljjmapxh.fsf@kelsey-ws. hq.ember.com>=20=20=20<4ACF754C.2000604@gmail.com>=20<2F8F6405-4B8 7-4A62-9040-717A5D956B42@cisco.com>=20=20<4AD30B6B.303080 2@gmail.com>=20<1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisc o.com>=20=20<4AD32D6F.7090406@gmail.com>=20<1B65245C-1BC6 -4ECB-9CE9-77784668DC8B@cisco.com>=20=20=20; bh=GlfbxBbWRJ0scKZACIvzCD+0ADriSb13knYAJC5vB6c=; b=Plkh01SOT43nYnlOSDTdVt16CT9iDla3QhXoCD+XvGp7ykJHNSxO/KOI y0vbN7JPdnjMHf+mjJ0ziMSj755XRhaUI6hxaKnE85tN971QQjc9tPLcl iPzzfJmASBBu7TB2uKapX6OX7r549nj2DAFnBEAUjJ2+Jue7hGZWitKt4 s=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJLZ0kqrR7H+/2dsb2JhbADAO5ZuhC0E X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="407393791" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 12 Oct 2009 14:24:23 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9CENwal013046; Mon, 12 Oct 2009 14:24:23 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:24:18 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:24:18 +0200 Message-Id: From: JP Vasseur To: Maxence Dalmais In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 16:18:18 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 14:24:18.0347 (UTC) FILETIME=[AEF407B0:01CA4B47] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--9.320400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:24:23 -0000 Hi Maxence, On Oct 12, 2009, at 3:57 PM, Maxence Dalmais wrote: > Hi JP, > > > "Low power networks" in ROLL title is not about link energy? > > > But the objective of the RPL is to provide you the best path > according to some metrics. > I may have a path requiring more energy than another one but if it > goes across main powered nodes, this may be the preferable path. > Node energy is different and covered in the ID. > > > I agree with you, but maybe something is missing: > Title is too about lossy network. Loss in wireless network is due to > noise. Sure one could argue that noise is a layer 2 (not 3) problem > but that argumentation won't make RPL better. Indeed. Note that "lossy" also applies to PLC links but we're in sync. > The fact is that sending a high energy cost packet won't be a > problem for a mains powered node, but it will induce noise and > impact the links of the entire network. That is a second order effect though and not true for PLC link. It is bit of a stretch to choose a low energy path, because of a high energy path may cause increase noise along that path thus leading to more errors ... don't you think ? Thanks. JP. > > Maxence. From jvasseur@cisco.com Mon Oct 12 07:24:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704DC28C1FE for ; Mon, 12 Oct 2009 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.086 X-Spam-Level: X-Spam-Status: No, score=-8.086 tagged_above=-999 required=5 tests=[AWL=-1.487, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UBqA9-FGm8P for ; Mon, 12 Oct 2009 07:24:28 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BB13128C213 for ; Mon, 12 Oct 2009 07:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1236; q=dns/txt; s=amsiport01001; t=1255357468; x=1256567068; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Mon,=2012=20Oct=202009 =2016:20:18=20+0200|Message-Id:=20|To:=20Maxence=20Dalmais=20|Cc:=20roll@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20=20=20<87ljjmapxh.fsf@kelsey-ws. hq.ember.com>=20=20=20<4ACF754C.2000604@gmail.com>=20<2F8F6405-4B8 7-4A62-9040-717A5D956B42@cisco.com>=20=20<4AD30B6B.303080 2@gmail.com>=20<1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisc o.com>=20=20<4AD32D6F.7090406@gmail.com>=20<1B65245C-1BC6 -4ECB-9CE9-77784668DC8B@cisco.com>=20=20=20; bh=GlfbxBbWRJ0scKZACIvzCD+0ADriSb13knYAJC5vB6c=; b=XnmYu8bmhbHmqndgktcFllSEKslqPfFb8Q2/3Kr2V6/gIG7Xtb2mRIla JXhytqJx4DF2r62bR3ZuE/6DTBm8djMccmdnRaqLyHdNqxmBgjvZZXma0 4eBgZDnF1uoJVhsPYigKtvKF+fRgFGGflz2upWlan1NedmDCjpVxln6XG k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAABvZ0kqQ/uCWe2dsb2JhbACbDAEBFiQGpGmWboQtBA X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="51555886" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 14:24:21 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CEOLGG012931; Mon, 12 Oct 2009 14:24:21 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:24:20 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:24:20 +0200 Message-Id: From: JP Vasseur To: Maxence Dalmais In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 16:20:18 +0200 References: <87ljjmapxh.fsf@kelsey-ws.hq.ember.com> <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 14:24:20.0768 (UTC) FILETIME=[B0657200:01CA4B47] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--9.320400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:24:28 -0000 Hi Maxence, On Oct 12, 2009, at 3:57 PM, Maxence Dalmais wrote: > Hi JP, > > > "Low power networks" in ROLL title is not about link energy? > > > But the objective of the RPL is to provide you the best path > according to some metrics. > I may have a path requiring more energy than another one but if it > goes across main powered nodes, this may be the preferable path. > Node energy is different and covered in the ID. > > > I agree with you, but maybe something is missing: > Title is too about lossy network. Loss in wireless network is due to > noise. Sure one could argue that noise is a layer 2 (not 3) problem > but that argumentation won't make RPL better. Indeed. Note that "lossy" also applies to PLC links but we're in sync. > The fact is that sending a high energy cost packet won't be a > problem for a mains powered node, but it will induce noise and > impact the links of the entire network. That is a second order effect though and not true for PLC link. It is bit of a stretch to choose a low energy path, because of a high energy path may cause increase noise along that path thus leading to more errors ... don't you think ? Thanks. JP. > > Maxence. From richard.kelsey@ember.com Mon Oct 12 07:27:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0AF28C1FE for ; Mon, 12 Oct 2009 07:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U8ZRyw1Mu8n for ; Mon, 12 Oct 2009 07:27:54 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 0740E28C18A for ; Mon, 12 Oct 2009 07:27:53 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10:29:00 -0400 Date: Mon, 12 Oct 2009 10:26:14 -0400 Message-Id: <878wfgbse1.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <2863E9BF-442B-4F7C-8415-1BE4192DE977@cisco.com> (message from JP Vasseur on Mon, 12 Oct 2009 14:46:18 +0200) From: Richard Kelsey References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <2863E9BF-442B-4F7C-8415-1BE4192DE977@cisco.com> X-OriginalArrivalTime: 12 Oct 2009 14:29:00.0213 (UTC) FILETIME=[56F55E50:01CA4B48] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:27:55 -0000 JP, From: JP Vasseur Date: Mon, 12 Oct 2009 14:46:18 +0200 > Below is a discourse on the reliability characteristics of > 802.15.4 and similar digital radios and what this means for > link metrics. Even if the goal is to maximize something > other than reliability, you still need the links to be > reasonably reliable in order to reduce churn and because no > matter what the metric, broken routes have little utility. Yes, just to make sure that we are in line, there are two orthogonal aspects here: 1) Link UP/DOWN: if indeed, the link quality crosses some threshold it can be put in DOWN state locally by the node 2) If the Link stays in DOWN state for some period of time, the node may decide to update the metrics in its RA-DIO. My point is that the key metric for reliability is not the RTX for a message right now, or any similar metric, but an estimate of the stability of the link itself. We need to preferentially use stable links. This is independent of what a node does when a link actually does stop working. > Non-radio links, or other types of radios, will have very > different characteristics. This may make it difficult to > have a good relibility metric that is independent of the > link layer. Yes but ... RPL is L3 thus we want path to be calculated according the link reliability (and I think that we all agree on this requirement), this is what we need to do. And I agree, this is not easy, the idea is to have a good enough way to abstract the link reliability using a single metric. The way to compute that metric is implementation specific and L2 dependent, which is fine. There may not be a single metric that we can use. In particular, for 802.15.4 radios, both stability and latency/power must be taken into account. We have to strongly prefer links that are stable (to avoid churn) and links between always-on devices (to minimize battery use and latency). These may be specific to 802.15.4, but they are the overriding concerns for those networks. I do not see how they can be collapsed into a single value. A single metric is possible, but it will likely have to contain distinct stability and power/latency values. Should we try to use the ETX and couple it with filtering to get the result of distinguishing OK links with Good links ? I do not see how ETX can capture the desired information. ETX averaged over the short term can't measure long term stability. ETX averaged over the long term can't tell you which links are currently usable. I am not sure what you mean by 'filtering' here. -Richard Kelsey From richard.kelsey@ember.com Mon Oct 12 07:33:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF23E3A6814 for ; Mon, 12 Oct 2009 07:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m4ei2+DErWf for ; Mon, 12 Oct 2009 07:33:49 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 1469B3A672F for ; Mon, 12 Oct 2009 07:33:48 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 10:34:55 -0400 Date: Mon, 12 Oct 2009 10:32:09 -0400 Message-Id: <877hv0bs46.fsf@kelsey-ws.hq.ember.com> To: Jonathan Hui In-reply-to: <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> (message from Jonathan Hui on Fri, 9 Oct 2009 09:06:47 -0700) From: Richard Kelsey References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> X-OriginalArrivalTime: 12 Oct 2009 14:34:55.0432 (UTC) FILETIME=[2AAF7C80:01CA4B49] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:33:50 -0000 Jonathan, From: Jonathan Hui Date: Fri, 9 Oct 2009 09:06:47 -0700 > The 'okay' links cannot be ignored, as they are actually > working at the moment and may be the only thing keeping the > network connected. Any additive metric has to define how > many good links are equivalent to one okay one. This isn't > easy to do, because we would really prefer to use an okay > link only if there is no path using only good links. Except > in very unusual topologies, it is unlikely that you will > ever be faced with a choice between one okay link and, say, > five good ones. Mostly agree with this. One practical concern we have run into with utilizing "okay" links is that network deployment/maintenance becomes more complex for the end-user. If "okay" links are required for connectivity, the network will appear to function well at times but not others. For some end-users, it may be better not to function at all if "okay" links is all you have when joining a network. It make sense to ignore 'okay' links when deploying a network or determining long-term connectivity. The whole point is that reliability depends on having some margin for link degradation. By the same token, when it comes to actually forwarding packets, we cannot afford to ignore links that have degraded since the network was deployed. -Richard Kelsey From jvasseur@cisco.com Mon Oct 12 07:38:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453453A690F for ; Mon, 12 Oct 2009 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.936 X-Spam-Level: X-Spam-Status: No, score=-9.936 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTETiv6RG6Ma for ; Mon, 12 Oct 2009 07:38:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3B4A928C1E2 for ; Mon, 12 Oct 2009 07:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=18418; q=dns/txt; s=amsiport01001; t=1255358282; x=1256567882; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20NA=20to=20transport=20DAO|Date:=20Mon,=2012 =20Oct=202009=2016:37:52=20+0200|Message-Id:=20<16C5E9A7- 9C7C-446D-A4C0-DACEAD5B1906@cisco.com>|To:=20Julien=20Abe ille=20(jabeille)=20|Cc:=20"Pascal=20 Thubert=20(pthubert)"=20,=0D=0A=20=20 =20=20=20=20=20=20"IETF=20ROLL"=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|In-Reply-To:=20|References:=20=20<6A2A459175 DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com>=20; bh=WDEMdmafd91F+XTcx2APp2HvsZQPgqe77dMTApVr42Q=; b=uJ//457kX4HpmkWnKB0EiqwxQG+QaMNvMhdIu6gKvgpCT3pkZnxERS9c 0wO7J1I6OVh90x2ZgVXRXOELUEyPo6Je6dbD8qUlUNG0mJyFPVZrhNLGZ ra+SCGN3ltK8z2Z5Ai5a+waluwNxLaq933YB8rQKAZmEd0Rbp0q+5/UQR Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAAKDc0kqQ/uCWe2dsb2JhbACCKSuYOAEBFiQGpGaWb4QtBA X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208,217";a="51557020" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 14:37:54 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CEbsl3016370 for ; Mon, 12 Oct 2009 14:37:54 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:37:54 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 16:37:53 +0200 Message-Id: <16C5E9A7-9C7C-446D-A4C0-DACEAD5B1906@cisco.com> From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-31-25682444 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 16:37:52 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 14:37:53.0353 (UTC) FILETIME=[94BC1390:01CA4B49] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16942.007 X-TM-AS-Result: No--29.883700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 14:38:03 -0000 --Apple-Mail-31-25682444 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Oct 12, 2009, at 10:04 AM, Julien Abeille (jabeille) wrote: > Hi Pascal, all, > > as I said unsolicited NAs are not frequent if ever sent. Timing =20 > constraints are very different and totally decoupled for a NA and a =20= > DAO, hence the savings in terms of control messages will be pretty =20 > small. The added complexity will be important. This is enough for me =20= > to disquilify the use of NAs. > The argument makes sense. WG, thoughts ? > regarding 6lowpan, again (I think this has been said many times), =20 > RPL is not a protocol for 802.15.4. > For sure. JP. > Best, > Julien > > > From: Pascal Thubert (pthubert) > Sent: lundi 12 octobre 2009 08:24 > To: Julien Abeille (jabeille); IETF ROLL > Subject: RE: [Roll] NA to transport DAO > > Hi Julien, > > When 6LoWPAN ND becomes a standard, I=92m all in favor to adapting our = =20 > options into those messages. > They create a tighter coupling between the router and the node, =20 > which appears beneficial to the NA DAO process. > > In the meantime, we made the conscious decision to bind RPL onto ND =20= > though we wish to be opened to other bindings. > The overloading you are discussing is truly there. > In one hand it can be seen as adding complexity. In the other as a =20 > way to save control messages. > > Pascal > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf =20= > Of Julien Abeille (jabeille) > Sent: vendredi 9 octobre 2009 15:14 > To: IETF ROLL > Subject: [Roll] NA to transport DAO > > Hi all, > > I have concerns about the use of NA to transport DAOs for the =20 > following reasons: > - NAs are not routing messages > - unsolicited NAs are not very frequent, hence using them for DAOs =20 > is not really piggybacking. We do not gain a lot by using them > - NA are already pretty overloaded messages: they are used in 3 =20 > procedures, namely address resolution, NUD and DAD > - NA processing is implementation wise complex enough because of the =20= > point above > - implementation wise, coupling RPL with ND makes code much more =20 > complex. > - the target address field in the NA uses 16 bytes without bringing =20= > a lot of value to RPL. > > I think using a new ICMP message to carry DAOs would be much better. > > What do people think? > Best, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-31-25682444 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Oct 12, 2009, = at 10:04 AM, Julien Abeille (jabeille) wrote:

Hi Pascal, all,
 
as I said unsolicited NAs are not frequent = if ever sent. Timing constraints are very different and totally = decoupled for a NA and a DAO, hence the savings in terms of control = messages will be pretty small. The added complexity will be important. = This is enough for me to disquilify the use of = NAs.
 

The argument makes sense.

WG, thoughts = ?

regarding 6lowpan, again (I think this has been said many = times), RPL is not a protocol for 802.15.4.
 

For sure.

JP.

Best,
Julien
 

From: Pascal Thubert = (pthubert) 
Sent: lundi 12 octobre 2009 = 08:24
To: Julien Abeille (jabeille); = IETF ROLL
Subject: RE: [Roll] NA to transport = DAO

Hi = Julien,
When = 6LoWPAN ND becomes a standard, I=92m all in favor to adapting our = options into those messages.
They create a tighter coupling = between the router and the node, which appears beneficial to the NA DAO = process.
In = the meantime, we made the conscious decision to bind RPL onto ND though = we wish to be opened to other bindings.
The overloading you are discussing = is truly there.
In = one hand it can be seen as adding complexity. In the other as a way to = save control messages.
 
Pascal
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille = (jabeille)
Sent: vendredi 9 octobre 2009 = 15:14
To: IETF= ROLL
Subject: [Roll] NA to transport = DAO
Hi = all,
I have concerns about the use of = NA to transport DAOs for the following = reasons:
- NAs are = not routing messages
- NA are already pretty = overloaded messages: they are used in 3 procedures, namely address = resolution, NUD and DAD
- = implementation wise, coupling RPL with ND makes code much more = complex.
- the target = address field in the NA uses 16 bytes without bringing a lot of value to = RPL.
I think using a new ICMP message = to carry DAOs would be much = better.
What do people = think?
Roll@ietf.org
>> regarding 6lowpan, again (I think this has been said many times), RPL >> is not a protocol for 802.15.4. >> > > For sure. > > JP. > >> Best, >> Julien >> >> >> ------------------------------------------------------------------------ >> *From:* Pascal Thubert (pthubert) >> *Sent:* lundi 12 octobre 2009 08:24 >> *To:* Julien Abeille (jabeille); IETF ROLL >> *Subject:* RE: [Roll] NA to transport DAO >> >> Hi Julien, >> >> When 6LoWPAN ND becomes a standard, I’m all in favor to adapting >> our options into those messages. >> They create a tighter coupling between the router and the node, >> which appears beneficial to the NA DAO process. >> >> In the meantime, we made the conscious decision to bind RPL onto >> ND though we wish to be opened to other bindings. >> The overloading you are discussing is truly there. >> In one hand it can be seen as adding complexity. In the other as a >> way to save control messages. >> >> Pascal >> *From:* roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] *On Behalf Of *Julien Abeille >> (jabeille) >> *Sent:* vendredi 9 octobre 2009 15:14 >> *To:* IETF ROLL >> *Subject:* [Roll] NA to transport DAO >> >> Hi all, >> >> I have concerns about the use of NA to transport DAOs for the >> following reasons: >> - NAs are not routing messages >> - unsolicited NAs are not very frequent, hence using them for DAOs >> is not really piggybacking. We do not gain a lot by using them >> - NA are already pretty overloaded messages: they are used in 3 >> procedures, namely address resolution, NUD and DAD >> - NA processing is implementation wise complex enough because of >> the point above >> - implementation wise, coupling RPL with ND makes code much more >> complex. >> - the target address field in the NA uses 16 bytes without >> bringing a lot of value to RPL. >> >> I think using a new ICMP message to carry DAOs would be much better. >> >> What do people think? >> Best, >> Julien >> >> _______________________________________________ >> 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 mdurvy@cisco.com Mon Oct 12 08:30:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77F93A63C9 for ; Mon, 12 Oct 2009 08:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrF4degLkX1I for ; Mon, 12 Oct 2009 08:30:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B5C5F3A69CB for ; Mon, 12 Oct 2009 08:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=4330; q=dns/txt; s=amsiport01001; t=1255361442; x=1256571042; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DAO |Date:=20Mon,=2012=20Oct=202009=2017:30:39=20+0200 |Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F91EE73C3BF@XM B-AMS-103.cisco.com>|To:=20"Alexandru=20Petrescu"=20,=0D=0A=20=20=20=20=20=20=20=20" JP=20Vasseur=20(jvasseur)"=20|Cc:=20" IETF=20ROLL"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AD34399.4080906@gmail.com>|References: =20=09<6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AM S-107.cisco.com>=09<16C5E9A7-9C7C-446D-A4C0-DACEAD5B 1906@cisco.com>=20<4AD34399.4080906@gmail.com>; bh=mEZV2U/y0slyPG1X0RMOArl9Em1rG9Wedv61wQjtyTg=; b=ksOtE1+8LZ3NN6nDF2jkUQw94XoJz9ydBrxFw65cxjUBb4DeL0XLb9QW 6cYRs0O3Mw14aUECTsPALnK4gJbhtPV9DVBGdTs5tS2EfoQpfDeUIoOLF caB32sx9VAByNHlFrCZ28vh1yKGspTOia5mO+jnC8Jt2/I01XPrZbvkRA 8=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAFfo0kqQ/uCWe2dsb2JhbACbDAEBFiQGpGmWfYQtBA X-IronPort-AV: E=Sophos;i="4.44,546,1249257600"; d="scan'208";a="51563640" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 15:30:41 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CFUfvp004484; Mon, 12 Oct 2009 15:30:41 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 17:30:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 17:30:39 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE73C3BF@XMB-AMS-103.cisco.com> In-Reply-To: <4AD34399.4080906@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLTDGnBYUmMQrORvyHqGVOx8cl3gABEumw References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <16C5E9A7-9C7C-446D-A4C0-DACEAD5B1906@cisco.com> <4AD34399.4080906@gmail.com> From: "Mathilde Durvy (mdurvy)" To: "Alexandru Petrescu" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 12 Oct 2009 15:30:41.0075 (UTC) FILETIME=[F4D81830:01CA4B50] Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 15:30:43 -0000 Hi Alex, I think there is a misunderstanding. We want to run IP on the nodes and = hence use NA in address resolution, etc. However, we believe that using NA for routing traffic is not = appropriate. Or in other word NA should only be used to update the = neighbor cache not the routing table... Best, Mathilde=20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Alexandru Petrescu Sent: lundi, 12. octobre 2009 16:56 To: JP Vasseur (jvasseur) Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO JP Vasseur a =E9crit : >=20 > On Oct 12, 2009, at 10:04 AM, Julien Abeille (jabeille) wrote: >=20 >> Hi Pascal, all, >> =20 >> as I said unsolicited NAs are not frequent if ever sent. Timing=20 >> constraints are very different and totally decoupled for a NA and a=20 >> DAO, hence the savings in terms of control messages will be pretty=20 >> small. The added complexity will be important. This is enough for me=20 >> to disquilify the use of NAs. >> =20 >=20 > The argument makes sense. >=20 > WG, thoughts ? My thought is completely different. I believe we haven't explored enough the possibilities of running = typical IP on a node, i.e. node send NAs. The tradeoffs of node not sending NAs are not completely understood = (delegate the NA sending to another entity? what's the cost of doing = this? other entity doing "NA storms"?). I may be well behind the current thinking, but that's my thought. Alex >=20 >> regarding 6lowpan, again (I think this has been said many times), RPL = >> is not a protocol for 802.15.4. >> =20 >=20 > For sure. >=20 > JP. >=20 >> Best, >> Julien >> =20 >> >> = ------------------------------------------------------------------------ >> *From:* Pascal Thubert (pthubert)=20 >> *Sent:* lundi 12 octobre 2009 08:24 >> *To:* Julien Abeille (jabeille); IETF ROLL >> *Subject:* RE: [Roll] NA to transport DAO >> >> Hi Julien, >> =20 >> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting >> our options into those messages. >> They create a tighter coupling between the router and the node, >> which appears beneficial to the NA DAO process. >> =20 >> In the meantime, we made the conscious decision to bind RPL onto >> ND though we wish to be opened to other bindings. >> The overloading you are discussing is truly there. >> In one hand it can be seen as adding complexity. In the other as = a >> way to save control messages. >> =20 >> Pascal >> *From:* roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] *On Behalf Of *Julien Abeille >> (jabeille) >> *Sent:* vendredi 9 octobre 2009 15:14 >> *To:* IETF ROLL >> *Subject:* [Roll] NA to transport DAO >> =20 >> Hi all, >> =20 >> I have concerns about the use of NA to transport DAOs for the >> following reasons: >> - NAs are not routing messages >> - unsolicited NAs are not very frequent, hence using them for = DAOs >> is not really piggybacking. We do not gain a lot by using them >> - NA are already pretty overloaded messages: they are used in 3 >> procedures, namely address resolution, NUD and DAD >> - NA processing is implementation wise complex enough because of >> the point above >> - implementation wise, coupling RPL with ND makes code much more >> complex. >> - the target address field in the NA uses 16 bytes without >> bringing a lot of value to RPL. >> =20 >> I think using a new ICMP message to carry DAOs would be much = better. >> =20 >> What do people think? >> Best, >> Julien >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=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 alexandru.petrescu@gmail.com Mon Oct 12 08:46:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FA628C1DF for ; Mon, 12 Oct 2009 08:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyiVDb4eWvDK for ; Mon, 12 Oct 2009 08:46:49 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 5CB723A63C9 for ; Mon, 12 Oct 2009 08:46:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CFkKxE014533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 17:46:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CFkKsM025416; Mon, 12 Oct 2009 17:46:20 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CFkKwV002421; Mon, 12 Oct 2009 17:46:20 +0200 Message-ID: <4AD34F4C.90409@gmail.com> Date: Mon, 12 Oct 2009 17:46:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Mathilde Durvy (mdurvy)" References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <16C5E9A7-9C7C-446D-A4C0-DACEAD5B1906@cisco.com> <4AD34399.4080906@gmail.com> <8A977BDC5A7B0E429B0F521E8D6F91EE73C3BF@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE73C3BF@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 15:46:50 -0000 Mathilde Durvy (mdurvy) a écrit : > Hi Alex, > > I think there is a misunderstanding. We want to run IP on the nodes > and hence use NA in address resolution, etc. However, we believe that > using NA for routing traffic is not appropriate. Or in other word NA > should only be used to update the neighbor cache not the routing > table... Hmm... in this sense I tend to agree with your oppinion, NA not to update the routing table. Would RA be better appropriate to update the routing table? In a certain context of a star-like topoology I consider, I consider RA is appropriate to update routing table entries. (the previous mail discarding the use of NA based on timing constraints is not relevant IMHO, because NA timing can be tuned to one's like). Alex > > Best, Mathilde > > -----Original Message----- From: roll-bounces@ietf.org > [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: > lundi, 12. octobre 2009 16:56 To: JP Vasseur (jvasseur) Cc: IETF ROLL > Subject: Re: [Roll] NA to transport DAO > > JP Vasseur a écrit : >> On Oct 12, 2009, at 10:04 AM, Julien Abeille (jabeille) wrote: >> >>> Hi Pascal, all, >>> >>> as I said unsolicited NAs are not frequent if ever sent. Timing >>> constraints are very different and totally decoupled for a NA and >>> a DAO, hence the savings in terms of control messages will be >>> pretty small. The added complexity will be important. This is >>> enough for me to disquilify the use of NAs. >>> >> The argument makes sense. >> >> WG, thoughts ? > > My thought is completely different. > > I believe we haven't explored enough the possibilities of running > typical IP on a node, i.e. node send NAs. > > The tradeoffs of node not sending NAs are not completely understood > (delegate the NA sending to another entity? what's the cost of doing > this? other entity doing "NA storms"?). > > I may be well behind the current thinking, but that's my thought. > > Alex > >>> regarding 6lowpan, again (I think this has been said many times), >>> RPL is not a protocol for 802.15.4. >>> >> For sure. >> >> JP. >> >>> Best, Julien >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Pascal Thubert (pthubert) *Sent:* lundi 12 octobre 2009 >>> 08:24 *To:* Julien Abeille (jabeille); IETF ROLL *Subject:* RE: >>> [Roll] NA to transport DAO >>> >>> Hi Julien, >>> >>> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting >>> our options into those messages. They create a tighter coupling >>> between the router and the node, which appears beneficial to the >>> NA DAO process. >>> >>> In the meantime, we made the conscious decision to bind RPL onto >>> ND though we wish to be opened to other bindings. The overloading >>> you are discussing is truly there. In one hand it can be seen as >>> adding complexity. In the other as a way to save control >>> messages. >>> >>> Pascal *From:* roll-bounces@ietf.org >>> [mailto:roll-bounces@ietf.org] *On >>> Behalf Of *Julien Abeille (jabeille) *Sent:* vendredi 9 octobre >>> 2009 15:14 *To:* IETF ROLL *Subject:* [Roll] NA to transport DAO >>> >>> Hi all, >>> >>> I have concerns about the use of NA to transport DAOs for the >>> following reasons: - NAs are not routing messages - unsolicited >>> NAs are not very frequent, hence using them for DAOs is not >>> really piggybacking. We do not gain a lot by using them - NA are >>> already pretty overloaded messages: they are used in 3 >>> procedures, namely address resolution, NUD and DAD - NA >>> processing is implementation wise complex enough because of the >>> point above - implementation wise, coupling RPL with ND makes >>> code much more complex. - the target address field in the NA uses >>> 16 bytes without bringing a lot of value to RPL. >>> >>> I think using a new ICMP message to carry DAOs would be much >>> better. >>> >>> What do people think? Best, Julien >>> >>> _______________________________________________ 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 alexandru.petrescu@gmail.com Mon Oct 12 08:51:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4993028C226 for ; Mon, 12 Oct 2009 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZMA6lECXHTk for ; Mon, 12 Oct 2009 08:51:52 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id E646328C1EC for ; Mon, 12 Oct 2009 08:51:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9CFpnOv018457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Oct 2009 17:51:49 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9CFpm6q026255; Mon, 12 Oct 2009 17:51:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9CFpmhl020655; Mon, 12 Oct 2009 17:51:48 +0200 Message-ID: <4AD35094.1030805@gmail.com> Date: Mon, 12 Oct 2009 17:51:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <16C5E9A7-9C7C-446D-A4C0-DACEAD5B1906@cisco.com> <4AD34399.4080906@gmail.com> <8A977BDC5A7B0E429B0F521E8D6F91EE73C3BF@XMB-AMS-103.cisco.com> <4AD34F4C.90409@gmail.com> In-Reply-To: <4AD34F4C.90409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 15:51:53 -0000 Alexandru Petrescu a écrit : > Mathilde Durvy (mdurvy) a écrit : >> Hi Alex, >> >> I think there is a misunderstanding. We want to run IP on the nodes >> and hence use NA in address resolution, etc. However, we believe that >> using NA for routing traffic is not appropriate. Or in other word NA >> should only be used to update the neighbor cache not the routing >> table... > > Hmm... in this sense I tend to agree with your oppinion, NA not to > update the routing table. > > Would RA be better appropriate to update the routing table? In a > certain context of a star-like topoology I consider, I consider RA is > appropriate to update routing table entries. > > (the previous mail discarding the use of NA based on timing constraints > is not relevant IMHO, because NA timing can be tuned to one's like). Sorry, following up my own post, I wanted _also_ to say that I have nothing against another routing protocol carrying the routing information, being that OSPF, BGP, RIP. And if they aren't suitable for ROLL then another routing protocol, RPL. If asked to distinguish between them my first criterion is re-usability. Alex > > Alex > >> >> Best, Mathilde >> >> -----Original Message----- From: roll-bounces@ietf.org >> [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: >> lundi, 12. octobre 2009 16:56 To: JP Vasseur (jvasseur) Cc: IETF ROLL >> Subject: Re: [Roll] NA to transport DAO >> >> JP Vasseur a écrit : >>> On Oct 12, 2009, at 10:04 AM, Julien Abeille (jabeille) wrote: >>> >>>> Hi Pascal, all, >>>> >>>> as I said unsolicited NAs are not frequent if ever sent. Timing >>>> constraints are very different and totally decoupled for a NA and >>>> a DAO, hence the savings in terms of control messages will be >>>> pretty small. The added complexity will be important. This is >>>> enough for me to disquilify the use of NAs. >>>> >>> The argument makes sense. >>> >>> WG, thoughts ? >> >> My thought is completely different. >> >> I believe we haven't explored enough the possibilities of running >> typical IP on a node, i.e. node send NAs. >> >> The tradeoffs of node not sending NAs are not completely understood >> (delegate the NA sending to another entity? what's the cost of doing >> this? other entity doing "NA storms"?). >> >> I may be well behind the current thinking, but that's my thought. >> >> Alex >> >>>> regarding 6lowpan, again (I think this has been said many times), >>>> RPL is not a protocol for 802.15.4. >>>> >>> For sure. >>> >>> JP. >>> >>>> Best, Julien >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> *From:* Pascal Thubert (pthubert) *Sent:* lundi 12 octobre 2009 >>>> 08:24 *To:* Julien Abeille (jabeille); IETF ROLL *Subject:* RE: >>>> [Roll] NA to transport DAO >>>> >>>> Hi Julien, >>>> >>>> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our >>>> options into those messages. They create a tighter coupling >>>> between the router and the node, which appears beneficial to the >>>> NA DAO process. >>>> >>>> In the meantime, we made the conscious decision to bind RPL onto ND >>>> though we wish to be opened to other bindings. The overloading >>>> you are discussing is truly there. In one hand it can be seen as >>>> adding complexity. In the other as a way to save control >>>> messages. >>>> >>>> Pascal *From:* roll-bounces@ietf.org >>>> [mailto:roll-bounces@ietf.org] *On >>>> Behalf Of *Julien Abeille (jabeille) *Sent:* vendredi 9 octobre >>>> 2009 15:14 *To:* IETF ROLL *Subject:* [Roll] NA to transport DAO >>>> >>>> Hi all, >>>> >>>> I have concerns about the use of NA to transport DAOs for the >>>> following reasons: - NAs are not routing messages - unsolicited >>>> NAs are not very frequent, hence using them for DAOs is not >>>> really piggybacking. We do not gain a lot by using them - NA are >>>> already pretty overloaded messages: they are used in 3 procedures, >>>> namely address resolution, NUD and DAD - NA >>>> processing is implementation wise complex enough because of the >>>> point above - implementation wise, coupling RPL with ND makes >>>> code much more complex. - the target address field in the NA uses >>>> 16 bytes without bringing a lot of value to RPL. >>>> >>>> I think using a new ICMP message to carry DAOs would be much >>>> better. >>>> >>>> What do people think? Best, Julien >>>> >>>> _______________________________________________ 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 >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Mon Oct 12 09:58:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 978F73A68E4 for ; Mon, 12 Oct 2009 09:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l233j2UOTHip for ; Mon, 12 Oct 2009 09:58:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9EA543A63C9 for ; Mon, 12 Oct 2009 09:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=6765; q=dns/txt; s=amsiport01001; t=1255366694; x=1256576294; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Mon,=2012=20Oct=202009=2018:58:06=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66DF95@XM B-AMS-107.cisco.com>|To:=20"Mathilde=20Durvy=20(mdurvy)" =20,=0D=0A=20=20=20=20=20=20=20=20"Zach =20Shelby"=20,=0D=0A=20=20=20=20=20 =20=20=20"Julien=20Abeille=20(jabeille)"=20|Cc:=20"IETF=20ROLL"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<8A977BDC5A7B0E429B0F521E8D6F91E E73C1EF@XMB-AMS-103.cisco.com>|References:=20<6A2A45 9175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> =20<6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.ci sco.com>=20<8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AM S-103.cisco.com>; bh=OM9hf+a5aqWnMOWa9Uo2MM+VEdmQG4eSSTpAEWKpxj4=; b=Y0IA9HD2boYNcmZTs87EC/Zh0eEPfBFEHN6KOQEt98ECi/YUiSlQBid7 s+OHdUnkhs1Hu0soxUpTBM3xk3uu3GN8DLLkofIxrqElTU/5gRlo5pRjC i8kGYDOu53To7yn6DXl9Akr6F8at4q0rf6i9Yrr6WeifUKvzZBjA0K+P2 Q=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEAAHD90kqQ/uCWe2dsb2JhbACWQIRNAQEWJAakV5cBhC0EgVg X-IronPort-AV: E=Sophos;i="4.44,547,1249257600"; d="scan'208";a="51571815" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 16:58:12 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CGwCnZ029399; Mon, 12 Oct 2009 16:58:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 18:58:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Oct 2009 18:58:06 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66DF95@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLFeCDdqQiULIjRnmtBSYJZ4LuKgADOiagAAJ4a8AAC/ADAA== References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "Zach Shelby" , "Julien Abeille (jabeille)" X-OriginalArrivalTime: 12 Oct 2009 16:58:12.0653 (UTC) FILETIME=[2F074DD0:01CA4B5D] Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 16:58:15 -0000 Hi Mathilde; The binding is like a transport. We'll define a different binding but it's still the same generic protocol. Like you can ping over UDP it's still ping.=20 And RPL does not do NA multicast for DAO, but for the specific case of hosts that would participate to the game. Then again the LoWPAN model is a better fit. Pascal >-----Original Message----- >From: Mathilde Durvy (mdurvy) >Sent: lundi 12 octobre 2009 13:32 >To: Pascal Thubert (pthubert); Zach Shelby; Julien Abeille (jabeille) >Cc: IETF ROLL >Subject: RE: [Roll] NA to transport DAO > >Hi All, > >I perfectly agree with Julien's arguments. Quoting from RFC 4861: > > "7.2.6. Sending Unsolicited Neighbor Advertisements > > In some cases, a node may be able to determine that its link-layer > address has changed (e.g., hot-swap of an interface card) and may > wish to inform its neighbors of the new link-layer address quickly. > In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT > unsolicited Neighbor Advertisement messages to the all-nodes > multicast address. These advertisements MUST be separated by at > least RetransTimer seconds..." > >Do we really want to impose these constrains to the sending of DAO? I don't think so... >The goal of NAs is to update neighbor caches and I don't see any logic in wanting to reuse these messages for >routing. > >In addition, I don't think this group should care or make any assumptions on the adaptation layer running >below IPv6 as each of them has it specificities and RPL should remain as generic as possible. > >Best, >Mathilde > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) >Sent: lundi, 12. octobre 2009 12:07 >To: Zach Shelby; Julien Abeille (jabeille) >Cc: IETF ROLL >Subject: Re: [Roll] NA to transport DAO > >Hi Zach > >We are in perfect line. At the moment, RPL would impose NS/NA between 6LoWPAN routers to expose the host >routes. > >At some point in the future, considering that LoWPANs are an obvious target for RPL, we should be able to >define the binding over the LowPAN ND. What we really need to move forward there is for ND to progress to RFC >quickly so we can refer to it. > >I think it would be good for this list that you update us on the progress there. What would be the plan for >last call? > >Cheers, > >Pascal > >>-----Original Message----- >>From: Zach Shelby [mailto:zach@sensinode.com] >>Sent: lundi 12 octobre 2009 10:28 >>To: Julien Abeille (jabeille) >>Cc: Pascal Thubert (pthubert); IETF ROLL >>Subject: Re: [Roll] NA to transport DAO >> >>Hi, >> >>On Oct 12, 2009, at 11:04 , Julien Abeille (jabeille) wrote: >> >>> Hi Pascal, all, >>> >>> as I said unsolicited NAs are not frequent if ever sent. Timing >>> constraints are very different and totally decoupled for a NA and a >>> DAO, hence the savings in terms of control messages will be pretty >>> small. The added complexity will be important. This is enough for me >>> to disquilify the use of NAs. >> >>I understand the concern there for RFC4861. >> >>> regarding 6lowpan, again (I think this has been said many times), RPL >>> is not a protocol for 802.15.4. >> >>Huh? Apples and oranges. We are not talking about 802.15.4. >> >>RPL is an IP routing protocol, and it *must* be useable in 6LoWPAN >>IPv6 networks as well. An alternative binding to draft-ietf-6lowpan-nd >>messages should be defined of course as Pascal mentioned below. And >>here the advantages of this are even greater. In 6LoWPAN-ND we do have >>periodic NR/NC messages which are not overloaded. >> >>This reminds me - in the next version of RPL we need a section to >>specifically discuss the use of RPL in LoWPANs. The current text >>assumes the LLN is a collection of normal IPv6 links and that RFC4861 >>is used. In a LoWPAN we have a flat network (no prefix assignment to >>LLN Routers) and 6lowpan-nd instead of RFC4861. It is pretty confusing >>to read if someone new is trying to figure out how to apply this is a >>LoWPAN... >> >>Zach >> >>> >>> Best, >>> Julien >>> >>> >>> From: Pascal Thubert (pthubert) >>> Sent: lundi 12 octobre 2009 08:24 >>> To: Julien Abeille (jabeille); IETF ROLL >>> Subject: RE: [Roll] NA to transport DAO >>> >>> Hi Julien, >>> >>> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting our >>> options into those messages. >>> They create a tighter coupling between the router and the node, which >>> appears beneficial to the NA DAO process. >>> >>> In the meantime, we made the conscious decision to bind RPL onto ND >>> though we wish to be opened to other bindings. >>> The overloading you are discussing is truly there. >>> In one hand it can be seen as adding complexity. In the other as a >>> way to save control messages. >>> >>> Pascal >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> Of Julien Abeille (jabeille) >>> Sent: vendredi 9 octobre 2009 15:14 >>> To: IETF ROLL >>> Subject: [Roll] NA to transport DAO >>> >>> Hi all, >>> >>> I have concerns about the use of NA to transport DAOs for the >>> following reasons: >>> - NAs are not routing messages >>> - unsolicited NAs are not very frequent, hence using them for DAOs is >>> not really piggybacking. We do not gain a lot by using them >>> - NA are already pretty overloaded messages: they are used in 3 >>> procedures, namely address resolution, NUD and DAD >>> - NA processing is implementation wise complex enough because of the >>> point above >>> - implementation wise, coupling RPL with ND makes code much more >>> complex. >>> - the target address field in the NA uses 16 bytes without bringing a >>> lot of value to RPL. >>> >>> I think using a new ICMP message to carry DAOs would be much better. >>> >>> What do people think? >>> Best, >>> Julien >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >>-- >>http://www.sensinode.com >>http://zachshelby.org - My blog "On the Internet of Things" >>Mobile: +358 40 7796297 >> >>Zach Shelby >>Head of Research >>Sensinode Ltd. >>Kidekuja 2 >>88610 Vuokatti, FINLAND >> >>This e-mail and all attached material are confidential and may contain >>legally privileged information. If you are not the intended recipient, >>please contact the sender and delete the e-mail from your system >>without producing, distributing or retaining copies thereof. >> >> > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From sung.lee@us.fujitsu.com Mon Oct 12 10:27:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B5928C28C for ; Mon, 12 Oct 2009 10:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGRwPJe0a34v for ; Mon, 12 Oct 2009 10:27:13 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 7234128C280 for ; Mon, 12 Oct 2009 10:27:13 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9CHS8DD029255 for ; Mon, 12 Oct 2009 10:28:08 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9CHS8Bm029252 for ; Mon, 12 Oct 2009 10:28:08 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id n9CHRDHP009784 for ; Mon, 12 Oct 2009 10:27:13 -0700 (PDT) Received: from [10.157.253.51] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n9CHRCF00419 for ; Mon, 12 Oct 2009 10:27:12 -0700 (PDT) Message-ID: <4AD366EA.1040601@us.fujitsu.com> Date: Mon, 12 Oct 2009 13:27:06 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 17:27:14 -0000 I am with Philip. Our experience also shows that 2) Allow routing through nodes of higher rank with loop detection and repair in the data path works pretty well. Regards, Sung roll-request@ietf.org wrote: > Message: 2 > Date: Fri, 9 Oct 2009 10:20:05 -0700 > From: Philip Levis > Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection > and recovery > To: Pascal Thubert (pthubert) > Cc: roll > Message-ID: > Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; > delsp=yes > > > On Oct 9, 2009, at 5:55 AM, Pascal Thubert (pthubert) wrote: > > >> Hi: >> >> It seems widely accepted in this group that Loop avoidance in the >> control place should be kept simple but completed by a detection >> mechanism associated to the packets. This approach had been >> validated in CTP and DADR. >> >> After a number of discussions, here is a proposal. The proposal uses >> some info that is placed in the packet in the flow label. >> It assumes that the flow label is reserved for the purpose of RPL >> and node interaction. In the flow label we place: >> >> Outwards : 1 bit >> Sibling : 1 bit >> Rank_error : 1 bit >> DAO_Error : 1 bit >> Rank : 8 bit >> Instance ID : 8 bit >> >> Instance forwarding >> Instance IDs is used to avoid loops between DAGs from different >> origins. >> >> InstanceID is placed by the source in the flow label. It MUST >> matched the DAG instance onto which the packet is placed by a >> router. The router MAY either change the instanceID to match the DAG >> that it is using for this packet or discard the packet. That >> decision is policy based. Default policy TBD. >> >> Idea? >> >> DAG inconsistency loop detection >> The DAG is inconsistent is the packet direction does not match the >> rank relationship. >> >> A host MUST set the rank to FF. A router MUST place its rank in the >> flow label. >> A node emitting a packet must reset the Rank_error bit and the >> Outwards bit. >> A router MUST also reset the Outwards bit if it is using the default >> route inwards, either via a sibling or a parent, and set the bit if >> it is using a DAO route, either via a sibling or a child. >> >> A receiver detects an inconsistency if it receives a packet going >> inwards from a source with a lesser Rank, or outwards with a higher >> rank. >> >> Upon inconsistency, if the Rank_error bit was not set then the >> Rank_error bit is set. If it was set the packet is discarded. This >> is done to cover a rare re-sequencing of the DAG. >> >> Sibling loop avoidance >> A simple rule is that a packet may not make 2 sibling hops in a row. >> >> When a host sends a packet or a router forwards to a non sibling, >> the Sibling bit must be reset. >> When a router forwards to a sibling: if the Sibling bit was not set >> then the Sibling bit is set. If it was set then the packet is >> discarded. >> >> DAO inconsistency loop detection >> A ?parent? has an outwards DAO route that is a remnant from an >> obsolete DAO via a ?child? but the ?child? does not have a matching >> DOA state. >> >> In a general manner, a packet that goes outwards should never go >> inwards again. So rather than routing inwards a packet with the >> Outwards bit set, the router MUST discard the packet. If DAO >> recovery is in place, then the router MAY send it back to the source. >> >> DAO inconsistency loop recovery >> A Router that supports recovery uses a packet to recursively explore >> and cleanup the obsolete paths. >> >> The ?child? router that detects the DAO inconsistency SHOULD set the >> DAO_Error bit and return the packet to the parent that passed it. >> >> Upon a packet with a DAO bit set, the parent MUST remove the routing >> states that caused forwarding to the child that passed it, clear >> DAO_Error bit and send the packet again. >> >> > > I advocate taking a more extreme approach: remove the current sequence > number loop prevention mechanisms from the draft. > > Currently, RPL is trying to have it both ways. It's using sequence > numbers to prevent (not just avoid) loops caused by increasing in > rank. However, by allowing nodes to choose siblings, RPL still > requires a loop detection mechanism in data packets. If there is a > mechanism to detect loops with data packets, then there is no need to > have rules on when nodes can increase rank: the decision of whether to > do so or not is a performance design choice. > > When we started designing CTP, we tried using sequence numbers as DSDV > does. The logic to handle all of the edge cases was non-trivial. In > particular, if node A has move to sequence number N+1, but its child B > is still on sequence number N, then on receiving a packet from child > B, A must forward it with tree N. That is, A must maintain two trees. > Overall, the edge cases were complex, required a good deal of code, > and had a lot of tricky edge cases. Furthermore, the prospect of being > floating until a sequence number increment created a difficult tension > between the longest interval a DAG could be floating and the cost of > periodically flooding DAG sequence number updates. > > If there is a way to detect and repair loops in the data path, then > this tension disappears. Loops become an efficiency problem, due to > the extra messages they send. Correspondingly, may protocols have an > inventive to follow the loop prevention guidelines in -03, if doing so > leads to overall better efficiency. But such algorithms and policies > are RECOMMENDED or OPTIONAL performance optimizations on top of a > specification, not part of the specification itself (e.g., think RFC > 2581). > > In summary, I'd argue, that for the sake of simplicity in required > mechanisms, and flexibility in future implementation designs, that RPL > should either: > > 1) Disallow routing through siblings > 2) Allow routing through nodes of higher rank > > I personally think 2) is a better approach, based on my experiences, > as it can remove the need for periodic sequence number increments. But > I think that the current half-way position is worse than either 1) or > 2): it has the worst of both worlds. > > If we make sequence number-based DAG control OPTIONAL, then I'd argue > we should elide it from the main RPL document. Keep the core > specification simple. > > Phil > > ------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > End of Roll Digest, Vol 21, Issue 21 > ************************************ > From jvasseur@cisco.com Mon Oct 12 11:16:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A403A6950 for ; Mon, 12 Oct 2009 11:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.997 X-Spam-Level: X-Spam-Status: No, score=-7.997 tagged_above=-999 required=5 tests=[AWL=-1.398, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRLTvtqtUL9Y for ; Mon, 12 Oct 2009 11:16:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9813A28C23E for ; Mon, 12 Oct 2009 11:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=7454; q=dns/txt; s=sjiport06001; t=1255371367; x=1256580967; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20NA=20to=20transport=20DAO|Date:=20Mon,=2012 =20Oct=202009=2020:16:04=20+0200|Message-Id:=20<966A42CE- 0D99-416E-BD75-2AE5DAE8F312@cisco.com>|To:=20Pascal=20Thu bert=20(pthubert)=20|Cc:=20"Mathilde =20Durvy=20(mdurvy)"=20,=0D=0A=20=20=20 =20=20=20=20=20"Zach=20Shelby"=20,=0D =0A=20=20=20=20=20=20=20=20"Julien=20Abeille=20(jabeille) "=20,=0D=0A=20=20=20=20=20=20=20=20IE TF=20ROLL=20|Mime-Version:=201.0=20(Apple =20Message=20framework=20v936)|Content-Transfer-Encoding: =207bit|In-Reply-To:=20<6A2A459175DABE4BB11DE2026AA50A5D6 6DF95@XMB-AMS-107.cisco.com>|References:=20<6A2A4591 75DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com>=20< 6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco. com>=20<8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-10 3.cisco.com>=20<6A2A459175DABE4BB11DE2026AA50A5D66DF95@XM B-AMS-107.cisco.com>; bh=m5Qrax7V6Z9V/wcxsQV/1+fkhGUx+UYiq5QEBGqbWFw=; b=f0pXeWOmi6XD07MQ+Qti9dfzE2F/SxrTvzgKQdx7io7Nwtv52YQMTXMX 3GiCuVFeBN4kSwMAJbEnM2HOVIEEsW0tXI1cZhl3vecWUZEF9ncfLNgS3 JhsM2canlfdymIQMwG+ciRS0UEgY+w1G86bVZtFmhVM2HaPWvIvqeKw0r E=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkJAHwP00qrR7Hu/2dsb2JhbACWQKk7lwqELQSBWA X-IronPort-AV: E=Sophos;i="4.44,547,1249257600"; d="scan'208";a="407567301" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 12 Oct 2009 18:16:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9CIG6EJ007150; Mon, 12 Oct 2009 18:16:06 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 20:16:05 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 20:16:05 +0200 Message-Id: <966A42CE-0D99-416E-BD75-2AE5DAE8F312@cisco.com> From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66DF95@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 20:16:04 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D66DF95@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 18:16:05.0397 (UTC) FILETIME=[10337450:01CA4B68] Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 18:16:08 -0000 On Oct 12, 2009, at 6:58 PM, Pascal Thubert (pthubert) wrote: > Hi Mathilde; > > The binding is like a transport. We'll define a different binding but > it's still the same generic protocol. Like you can ping over UDP it's > still ping. > > And RPL does not do NA multicast for DAO, but for the specific case of > hosts that would participate to the game. it does Mcast NA for DOA ... > Then again the LoWPAN model is > a better fit. RRR ... what do you mean by LoWPAN model ???? Cheers. JP. > > Pascal > >> -----Original Message----- >> From: Mathilde Durvy (mdurvy) >> Sent: lundi 12 octobre 2009 13:32 >> To: Pascal Thubert (pthubert); Zach Shelby; Julien Abeille (jabeille) >> Cc: IETF ROLL >> Subject: RE: [Roll] NA to transport DAO >> >> Hi All, >> >> I perfectly agree with Julien's arguments. Quoting from RFC 4861: >> >> "7.2.6. Sending Unsolicited Neighbor Advertisements >> >> In some cases, a node may be able to determine that its link-layer >> address has changed (e.g., hot-swap of an interface card) and may >> wish to inform its neighbors of the new link-layer address quickly. >> In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT >> unsolicited Neighbor Advertisement messages to the all-nodes >> multicast address. These advertisements MUST be separated by at >> least RetransTimer seconds..." >> >> Do we really want to impose these constrains to the sending of DAO? I > don't think so... >> The goal of NAs is to update neighbor caches and I don't see any >> logic > in wanting to reuse these messages for >> routing. >> >> In addition, I don't think this group should care or make any > assumptions on the adaptation layer running >> below IPv6 as each of them has it specificities and RPL should remain > as generic as possible. >> >> Best, >> Mathilde >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of > Pascal Thubert (pthubert) >> Sent: lundi, 12. octobre 2009 12:07 >> To: Zach Shelby; Julien Abeille (jabeille) >> Cc: IETF ROLL >> Subject: Re: [Roll] NA to transport DAO >> >> Hi Zach >> >> We are in perfect line. At the moment, RPL would impose NS/NA between > 6LoWPAN routers to expose the host >> routes. >> >> At some point in the future, considering that LoWPANs are an obvious > target for RPL, we should be able to >> define the binding over the LowPAN ND. What we really need to move > forward there is for ND to progress to RFC >> quickly so we can refer to it. >> >> I think it would be good for this list that you update us on the > progress there. What would be the plan for >> last call? >> >> Cheers, >> >> Pascal >> >>> -----Original Message----- >>> From: Zach Shelby [mailto:zach@sensinode.com] >>> Sent: lundi 12 octobre 2009 10:28 >>> To: Julien Abeille (jabeille) >>> Cc: Pascal Thubert (pthubert); IETF ROLL >>> Subject: Re: [Roll] NA to transport DAO >>> >>> Hi, >>> >>> On Oct 12, 2009, at 11:04 , Julien Abeille (jabeille) wrote: >>> >>>> Hi Pascal, all, >>>> >>>> as I said unsolicited NAs are not frequent if ever sent. Timing >>>> constraints are very different and totally decoupled for a NA and a >>>> DAO, hence the savings in terms of control messages will be pretty >>>> small. The added complexity will be important. This is enough for >>>> me >>>> to disquilify the use of NAs. >>> >>> I understand the concern there for RFC4861. >>> >>>> regarding 6lowpan, again (I think this has been said many times), > RPL >>>> is not a protocol for 802.15.4. >>> >>> Huh? Apples and oranges. We are not talking about 802.15.4. >>> >>> RPL is an IP routing protocol, and it *must* be useable in 6LoWPAN >>> IPv6 networks as well. An alternative binding to draft- >>> ietf-6lowpan-nd >>> messages should be defined of course as Pascal mentioned below. And >>> here the advantages of this are even greater. In 6LoWPAN-ND we do >>> have >>> periodic NR/NC messages which are not overloaded. >>> >>> This reminds me - in the next version of RPL we need a section to >>> specifically discuss the use of RPL in LoWPANs. The current text >>> assumes the LLN is a collection of normal IPv6 links and that >>> RFC4861 >>> is used. In a LoWPAN we have a flat network (no prefix assignment to >>> LLN Routers) and 6lowpan-nd instead of RFC4861. It is pretty >>> confusing >>> to read if someone new is trying to figure out how to apply this >>> is a >>> LoWPAN... >>> >>> Zach >>> >>>> >>>> Best, >>>> Julien >>>> >>>> >>>> From: Pascal Thubert (pthubert) >>>> Sent: lundi 12 octobre 2009 08:24 >>>> To: Julien Abeille (jabeille); IETF ROLL >>>> Subject: RE: [Roll] NA to transport DAO >>>> >>>> Hi Julien, >>>> >>>> When 6LoWPAN ND becomes a standard, I'm all in favor to adapting >>>> our >>>> options into those messages. >>>> They create a tighter coupling between the router and the node, > which >>>> appears beneficial to the NA DAO process. >>>> >>>> In the meantime, we made the conscious decision to bind RPL onto ND >>>> though we wish to be opened to other bindings. >>>> The overloading you are discussing is truly there. >>>> In one hand it can be seen as adding complexity. In the other as a >>>> way to save control messages. >>>> >>>> Pascal >>>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >>>> Behalf >>>> Of Julien Abeille (jabeille) >>>> Sent: vendredi 9 octobre 2009 15:14 >>>> To: IETF ROLL >>>> Subject: [Roll] NA to transport DAO >>>> >>>> Hi all, >>>> >>>> I have concerns about the use of NA to transport DAOs for the >>>> following reasons: >>>> - NAs are not routing messages >>>> - unsolicited NAs are not very frequent, hence using them for DAOs > is >>>> not really piggybacking. We do not gain a lot by using them >>>> - NA are already pretty overloaded messages: they are used in 3 >>>> procedures, namely address resolution, NUD and DAD >>>> - NA processing is implementation wise complex enough because of >>>> the >>>> point above >>>> - implementation wise, coupling RPL with ND makes code much more >>>> complex. >>>> - the target address field in the NA uses 16 bytes without bringing > a >>>> lot of value to RPL. >>>> >>>> I think using a new ICMP message to carry DAOs would be much >>>> better. >>>> >>>> What do people think? >>>> Best, >>>> Julien >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> -- >>> http://www.sensinode.com >>> http://zachshelby.org - My blog "On the Internet of Things" >>> Mobile: +358 40 7796297 >>> >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti, FINLAND >>> >>> This e-mail and all attached material are confidential and may >>> contain >>> legally privileged information. If you are not the intended >>> recipient, >>> please contact the sender and delete the e-mail from your system >>> without producing, distributing or retaining copies thereof. >>> >>> >> >> _______________________________________________ >> 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 richard.kelsey@ember.com Mon Oct 12 11:34:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A1C28C299 for ; Mon, 12 Oct 2009 11:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocv7FiAl81Gc for ; Mon, 12 Oct 2009 11:34:05 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 40D1F28C298 for ; Mon, 12 Oct 2009 11:34:05 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 14:35:11 -0400 Date: Mon, 12 Oct 2009 14:32:25 -0400 Message-Id: <871vl8bgzq.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Fri, 9 Oct 2009 12:21:52 -0700) From: Richard Kelsey References: <235757746.16320661255103614862.JavaMail.root@mail02.pantherlink.uwm.edu> X-OriginalArrivalTime: 12 Oct 2009 18:35:11.0573 (UTC) FILETIME=[BB600850:01CA4B6A] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 18:34:06 -0000 From: Philip Levis Date: Fri, 9 Oct 2009 12:21:52 -0700 Yes, the curve is sharp. Figure 8 in this paper[1] shows the curve found from direct measurements on two 15.4 nodes using a shielded environment and a variable attenuator. It shows a similarly sharp curve (theory and practice agree). But be careful -- both the analysis and measurement assume that there is no interference, something which an LLN cannot assume. It is possible to have a very high SINR and a poor packet reception ratio. While very small swings in signal strength can make wireless links transition from poor to good or vice versa, interference can easily have a much more gradual effect. I am sorry, but I am not sure what you are saying. What is the property of interference that causes this more gradual effect? -Richard Kelsey From jvasseur@cisco.com Mon Oct 12 12:20:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024473A691D for ; Mon, 12 Oct 2009 12:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.961 X-Spam-Level: X-Spam-Status: No, score=-9.961 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjw5vr7bJs7j for ; Mon, 12 Oct 2009 12:20:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 957C93A682C for ; Mon, 12 Oct 2009 12:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1574; q=dns/txt; s=amsiport01001; t=1255375241; x=1256584841; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20I-D|Date:=20Mon,=2012=20Oct =202009=2016:14:24=20+0200|Message-Id:=20|To:=20Alexandru=20Petres cu=20|Cc:=20IETF=20ROLL=20< roll@ietf.org>,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20 v936)|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AD33673.8030400@gmail.com>|References: =20=20<4A CDF4C6.5020109@gmail.com>=20<42382722-B852-4B20-A3D3-4C2E 4C4FF871@cisco.com>=20<4ACF78A9.8040405@gmail.com>=20=20<4AD30746. 9040807@gmail.com>=20<919800CD-E8BC-433F-8206-0B3190376DB B@cisco.com>=20<4AD33673.8030400@gmail.com>; bh=KFL8U7Fw6dq6153VdhBQXT/QnOXq06HD3uZSFuH7Y2A=; b=rgccSfnMtKk86HC6MUZer8VKiRTXee8s7DWttlV6D7olYX3/rVtmPYC7 4bzToSMpGVsANEcoQCx3idm+SPZusXFDBqeXctMdHCvk8q3lIttyXXw/m Ow8IRXFKNbo4y5n1hlTtEUdXzOX3l1t6omOiiBjYdBPa+jIWztS4IF06S w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8AAD4e00qQ/uCWe2dsb2JhbABDmkoBARYkBqQjlxCELQQ X-IronPort-AV: E=Sophos;i="4.44,547,1249257600"; d="scan'208";a="51579177" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 19:20:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CJKeM9023540; Mon, 12 Oct 2009 19:20:40 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:20:40 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:20:39 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AD33673.8030400@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 16:14:24 +0200 References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> <4AD30746.9040807@gmail.com> <919800CD-E8BC-433F-8206-0B3190376DBB@cisco.com> <4AD33673.8030400@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 19:20:39.0598 (UTC) FILETIME=[15679CE0:01CA4B71] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16944.001 X-TM-AS-Result: No--7.121600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 19:20:42 -0000 On Oct 12, 2009, at 4:00 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi Alex, >>> [snip] >>>>> We could struggle to compare a path with high energy cost yet low >>>>> hopcount cost to a path with low energy cost yet high hopcount =20 >>>>> cost. Is >>>>> P1 preferable over P2 or vice-versa? >>>>> >>>>> I think this is a question to which one can't answer without =20 >>>>> knowing the >>>>> deployment context. >>>>> >>>> Well at least we need one example where it could be useful. I =20 >>>> can't find of any personally. >>> >>> Here is one: >>> -- -- >>> |R1| |R2| >>> -- -- >>> | | >>> | | >>> | | >>> | | >>> \ ---- / >>> |Host| >>> ---- >>> >>> R1 and R2 send two different RAs. Each pretends to be a default =20 >>> router (non-zero Router Lifetime) and send different "link energy =20= >>> metrics" to Host. >> Link energy relates to which link ? > > Link energy metric in RA relates to the link on which that RA is =20 > sent. One RA is typically sent on a single link. > Yes but how would you expect "host" to use that information to select =20= the router ? It may very well be that the router offering the lower energy cost end =20= up following a high energy path. > In the above figure there are two links. > > Is this ok? > > Alex > From jvasseur@cisco.com Mon Oct 12 12:20:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A533A682C for ; Mon, 12 Oct 2009 12:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.001 X-Spam-Level: X-Spam-Status: No, score=-10.001 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiTtgOe9cBD3 for ; Mon, 12 Oct 2009 12:20:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6412A3A68D2 for ; Mon, 12 Oct 2009 12:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1574; q=dns/txt; s=amsiport01001; t=1255375242; x=1256584842; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20I-D|Date:=20Mon,=2012=20Oct =202009=2016:16:25=20+0200|Message-Id:=20<2560CED0-A6E5-4 D25-8192-1955D36A49F0@cisco.com>|To:=20Alexandru=20Petres cu=20|Cc:=20IETF=20ROLL=20< roll@ietf.org>,=20Kris=20Pister=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20 v936)|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AD33673.8030400@gmail.com>|References: =20=20<4A CDF4C6.5020109@gmail.com>=20<42382722-B852-4B20-A3D3-4C2E 4C4FF871@cisco.com>=20<4ACF78A9.8040405@gmail.com>=20=20<4AD30746. 9040807@gmail.com>=20<919800CD-E8BC-433F-8206-0B3190376DB B@cisco.com>=20<4AD33673.8030400@gmail.com>; bh=KFL8U7Fw6dq6153VdhBQXT/QnOXq06HD3uZSFuH7Y2A=; b=vYMyNGq7Ogjf155+OUZwDdynlQzSDgdWShDtyZHhxtIWcc1uSmxvZSvq oxrYCHvii8q8LyWRwtdJMSy316NxOME9S5rzORdkwyaW57xwufNAA/mov ifFF9ErBBIBCmqpu9sl5xBoAGDlHs6upk7VOm3TFf5VSh93QfqCyEZx4W 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8AAD4e00qQ/uCWe2dsb2JhbABDmkoBARYkBqQjlxCELQQ X-IronPort-AV: E=Sophos;i="4.44,547,1249257600"; d="scan'208";a="51579179" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 19:20:42 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CJKfVf023544; Mon, 12 Oct 2009 19:20:41 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:20:41 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Oct 2009 21:20:41 +0200 Message-Id: <2560CED0-A6E5-4D25-8192-1955D36A49F0@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AD33673.8030400@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 16:16:25 +0200 References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> <4AD30746.9040807@gmail.com> <919800CD-E8BC-433F-8206-0B3190376DBB@cisco.com> <4AD33673.8030400@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Oct 2009 19:20:41.0489 (UTC) FILETIME=[16882810:01CA4B71] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16944.001 X-TM-AS-Result: No--7.121600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 19:20:42 -0000 On Oct 12, 2009, at 4:00 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> Hi Alex, >>> [snip] >>>>> We could struggle to compare a path with high energy cost yet low >>>>> hopcount cost to a path with low energy cost yet high hopcount =20 >>>>> cost. Is >>>>> P1 preferable over P2 or vice-versa? >>>>> >>>>> I think this is a question to which one can't answer without =20 >>>>> knowing the >>>>> deployment context. >>>>> >>>> Well at least we need one example where it could be useful. I =20 >>>> can't find of any personally. >>> >>> Here is one: >>> -- -- >>> |R1| |R2| >>> -- -- >>> | | >>> | | >>> | | >>> | | >>> \ ---- / >>> |Host| >>> ---- >>> >>> R1 and R2 send two different RAs. Each pretends to be a default =20 >>> router (non-zero Router Lifetime) and send different "link energy =20= >>> metrics" to Host. >> Link energy relates to which link ? > > Link energy metric in RA relates to the link on which that RA is =20 > sent. One RA is typically sent on a single link. > Yes but how would you expect "host" to use that information to select =20= the router ? It may very well be that the router offering the lower energy cost end =20= up following a high energy path. > In the above figure there are two links. > > Is this ok? > > Alex > From prvs=529ad3749=mukul@uwm.edu Mon Oct 12 12:49:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F953A67D7 for ; Mon, 12 Oct 2009 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RSwQtIRkbTe for ; Mon, 12 Oct 2009 12:49:32 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id AED873A6403 for ; Mon, 12 Oct 2009 12:49:32 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 12 Oct 2009 14:49:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D85ADC085D5; Mon, 12 Oct 2009 14:49:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXpmS+phEJvo; Mon, 12 Oct 2009 14:49:31 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 9C4B1C085CB; Mon, 12 Oct 2009 14:49:31 -0500 (CDT) Date: Mon, 12 Oct 2009 14:49:31 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <959698589.17138931255376971538.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <62177247.17134971255376728328.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] DAG hop timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 19:49:49 -0000 Hi Pascal, Please see inline. >>DAG hop timer value = random number between rank*DagDelay and (rank+1)*DagDelay >> >>If DAG hop timer is expected to help in loop avoidance, the node (say A) should generate a new RA-DIO >>advertising its own floating DAG when it starts the DAG hop timer. All the children nodes will hopefully >>receive this RA-DIO and decide whether to kick node A out of the parent set or leave the current DAG and join >>A's floating DAG. As soon as they make this decision, they will generate their RA-DIO either immediately or >>within I_min interval, where I_min is the minimum trickle timer value. So, the nodes at level 'n' in A's sub- >>dag are expected to generate new RA-DIOs within n*I_min interval. >I suspect that could be done but I'm unsure what is improved by the proposed change. Do you think >that this would save churn or battery? I am suggesting making DAG hop time independent of the dag rank of the nodes. It will allow DAG rank increase operations (if you dont want to depend on new seqno from root) to take place in a shorter and more predictable time frame. But, I am not trying to reduce churn or increase the battery life. >With the current spec, if the node A still has a forwarding path along the current DAG, it is >UNSTABLE and refrains from saying anything. So packets keep flowing along the current DAG whereas >detaching also would mean no packet forwarding till jump. When it jumps, A advertises its new >position and node in the sub-DAG that wish to follow can do so immediately and without a loop. One >could think of having a timer there too but one rationale is (again) to avoid packet loss so the >slight risk of churn is accepted. I think there is some communication gap here. If node A does not detach itself from the dag before increasing its rank, it may end up choosing a node in its sub-dag as its parent, thereby creating a loop. So, it seems to me that detaching from the dag is must before increasing one's rank (unless rank is increased on receiving a newer seqno). But the need to quickly increase the rank is another justification to make DAG hop time independent of the rank. >>I understand that the decision to make DAG hop timer value proportional to candidate parent's rank was >>influenced by the desire to: >>1) make a node join the DAG at minimum possible rank and >>2) allow nodes at lower rank to join before the nodes at higher rank >Correct. As a side effect, it also covers the (trickled) spreading of a detaching RA, at least >over line of sight. Not sure what you meant. Please elaborate. >>If we are not resetting the DAG hop timer every time we come to know of a lower ranked candidate, we already >>agreed to give up on the second objective above. >I'm not seeing you here. We agreed that there's a practical need for only one timer per target DAG >though the spec describes that as one timer per parent. If the a new candidate pops up that would >be get this node to a shorter rank with a shorter timer, an implementation that uses only one >timer must emulate that by shortening the existing timer duration. OK. So I misunderstood you earlier. You were indeed supporting that a node restart its DAG hop timer on finding a candidate with smaller rank. >> >>If we make DAG hop timer value a safe multiple of I_min (independent of the dag rank of the candidate parent >>that cause the timer to start), objective (1) above is still achievable to roughly the same degree as with >>current way of setting up DAG hop timer. >> >This might be true. I could buy that this works independently of the discussion above. >But keep in mind that the main objective is to reduce churn. Your points 1) and 2) are the >strategy to remove the churn, not the goal to be achieved. >With the timer, the new shape of the resulting DAG spreads out like a wave. Again, please explain in more details what you mean by "DAG spreads out like a wave". Sorry for asking for too many explanations! >You're in a great position to simulate the churn with and without the dag hop timer. >I think that this would be a key data to enable an informed decision for the running poll. I am going to simulate the following 3 ways of joining a new DAG (which also covers the case where a node detaches from the old dag in order to join it at a higher rank): 1) wait for new seqno from root 2) do not wait for new seqno but use dag hop timer: a) where dag hop time is proportional to candidate's rank (and dag hop timer restarts when a node comes to know of a lower rank candidate) b) where dag hop time is fixed (few multiples of I_min) Performance metrics would be number of control messages (RA-DIOs) generated by the node and its children in the old sub-dag and the overall delay in the process. I have to think more carefully about the simulation scenarios. Thanks Mukul From mcr@marajade.sandelman.ca Mon Oct 12 13:39:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0ED03A6836 for ; Mon, 12 Oct 2009 13:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0TAinmtiJQs for ; Mon, 12 Oct 2009 13:39:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 011093A67FD for ; Mon, 12 Oct 2009 13:39:46 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.198]) by relay.sandelman.ca (Postfix) with ESMTPS id 16B773428F for ; Mon, 12 Oct 2009 20:44:13 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id BB5DC4E7FD for ; Mon, 12 Oct 2009 16:39:45 -0400 (EDT) From: Michael Richardson To: IETF ROLL In-Reply-To: <16C5E9A7-9C7C-446D-A4C0-DACEAD5B1906@cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <16C5E9A7-9C7C-446D-A4C0-DACEAD5B1906@cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 12 Oct 2009 16:39:45 -0400 Message-ID: <3806.1255379985@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 20:39:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "JP" == JP Vasseur writes: >> as I said unsolicited NAs are not frequent if ever sent. Timing >> constraints are very different and totally decoupled for a NA and >> a DAO, hence the savings in terms of control messages will be >> pretty small. The added complexity will be important. This is >> enough for me to disquilify the use of NAs. JP> The argument makes sense. JP> WG, thoughts ? Unless the DAO's eliminate the need to send NDs, then a node has to send some-new-ICMPv6 with DAOs, and then also send NDs, I think. (or 6lowpan-nd, which I am ignorant about). The argument that NAs are not frequent enough does not work for me. If we need to send a DAO more often, then we need to send whatever they are contained in more often, and NAs are not harmful. Unless I'm crazy, it's more expensive (powerwise, etc.) to send two kinds of packets than it is to send one kind. An argument that inserting DAOs into NAs is hard in some environment (please specify which system), might work for me. An argument that we do not need to otherwise send NAs in all RPL environments would also convince me. >> I think using a new ICMP message to carry DAOs would be much >> better. I do not object to this, but I want to do it for the right reason. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStOUEICLcPvd0N1lAQIpuQf/djvL3ryzhN2z//j0XKfXJafWrBbFmTxV z16EzVBVpkljcvpOM+xdZifmEFNywKOko2fkWlV6TEMNya+wzlIFbOAKJncXw98R 5kiy96HV3cOHnz5cOjzPIqpuJzTz+/dgqAean2EOPWr8KJruDvXzpg574zbZGEAU OCtAmKadQliBYbJhFJVBKCKH64p3X5e9PzKI/HoduYQK6mnYBjfoCS05G7tY8EYk t9rdAZsXn33mGsiBJjJpyI3lq+uc+IcPyhjpRsvABWhkZifZKU+EMX9exCd4Ae2p Q7e4IQnQjSNaoSvZC/0C5sqXntwuFBt+xx8ABCEYATHcoHnA/xiDsA== =yRaA -----END PGP SIGNATURE----- From mcr@marajade.sandelman.ca Mon Oct 12 13:45:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522CC3A6971 for ; Mon, 12 Oct 2009 13:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdJ9GemDGnOS for ; Mon, 12 Oct 2009 13:45:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 4B2F53A6836 for ; Mon, 12 Oct 2009 13:45:34 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.198]) by relay.sandelman.ca (Postfix) with ESMTPS id 0FD6D34297 for ; Mon, 12 Oct 2009 20:50:01 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id D87014E7FD for ; Mon, 12 Oct 2009 16:45:33 -0400 (EDT) From: Michael Richardson To: IETF ROLL In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE73C3BF@XMB-AMS-103.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <16C5E9A7-9C7C-446D-A4C0-DACEAD5B1906@cisco.com> <4AD34399.4080906@gmail.com> <8A977BDC5A7B0E429B0F521E8D6F91EE73C3BF@XMB-AMS-103.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 12 Oct 2009 16:45:33 -0400 Message-ID: <4542.1255380333@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 20:45:35 -0000 >>>>> "Mathilde" == Mathilde Durvy <(mdurvy)" > writes: Mathilde> Hi Alex, Mathilde> I think there is a misunderstanding. We want to run IP on Mathilde> the nodes and hence use NA in address resolution, etc. Mathilde> However, we believe that using NA for routing traffic is Mathilde> not appropriate. Or in other word NA should only be used Mathilde> to update the neighbor cache not the routing table... I believe that we want to send as few packets as possible. It's okay if they are a bit bigger, as that generally does not cost very much. NA *is* a routing protocol. It tells you what route to use to reach neighbours. Some OSs (4.4BSD+) go so far as to have combined layer-2 and layer-3 reachability into a single table. (Linux does something similar, but it's not as clear) lox-[~] mcr 1047 %uname -a NetBSD lox.sandelman.ottawa.on.ca 3.1 NetBSD 3.1 ... lox-[~] mcr 1048 %netstat -rn -f inet6 Routing tables Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/104 ::1 UGRS 0 876847 - lo0 => ::/96 ::1 UGRS 0 0 - lo0 => default 2001:4830:1217:3::1 UGS 1 8760603 - ex0 ::1 ::1 UH 14 592769 33192 lo0 2001:4830:1217:3::1 00:80:c8:ca:76:6c UHL 1 32349 - ex0 2001:4830:1217:3::178 00:c0:4f:96:43:0f UHL 1 294 - lo0 2607:f0b0:f:3::1 00:80:c8:ca:76:6c UHL 0 3428 - ex0 2607:f0b0:f:3::178 00:c0:4f:96:43:0f UHL 1 0 - lo0 2607:f0b0:f:3:2c0:4fff:fe96:430f 00:c0:4f:96:43:0f UHL 0 0 - lo0 -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@marajade.sandelman.ca Mon Oct 12 13:52:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF05128C1A8 for ; Mon, 12 Oct 2009 13:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxd8+ejQm4kt for ; Mon, 12 Oct 2009 13:52:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 12AA528C15B for ; Mon, 12 Oct 2009 13:52:36 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.198]) by relay.sandelman.ca (Postfix) with ESMTPS id D80B334291 for ; Mon, 12 Oct 2009 20:57:02 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id AD6B44E7FD for ; Mon, 12 Oct 2009 16:52:35 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <87bpkgbfka.fsf@kelsey-ws.hq.ember.com> <19409.1255222897@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 12 Oct 2009 16:52:35 -0400 Message-ID: <5434.1255380755@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 20:52:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Julien" == Julien Abeille <(jabeille)" > writes: >> I have no idea what other systems do, but the following code was >> enough for me to see all ND and RS/RA packets in userland, >> without any modifications to the kernel. Julien> What having the code in userland with NAs does is that the Julien> NAs are processed twice, once by the kernel for DAD, NUD, Julien> address resolution, once in userland for RPL. Not sure we It seems pretty trivial to me. The packet is processed by two components, yes. Each piece processes a different part of the packet. If anything, this may be a win if the processor has a big data cache, but otherwise, I have no understanding of why it is an issue. Julien> can conclude it is easy to build a clean software Julien> architecture for RPL in Linux. Besides, Linux/BSD will not Julien> be the OS on many smart objects. On standard smart objects Julien> OSes it will be much more complex. Again, please tell me what the constraint is. Are you really telling me that you expect light switches to have *MORE* code than my laptop or an Android-based phone? I would think that they will have *simpler* (operating) systems, where essentially all processing is done in a single context. The only situation I can see where adding RPL processing will be difficult is if you have a very simple embedded operating system, which *does* have an IPv6 stack, and for which you do not have access to the source code. I will be surprised if, regardless of how DAOs are transported if your IPv6 stack is sufficiently bug-free to enable you do to RPL at all. Please educate me. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStOXEICLcPvd0N1lAQKFTgf+ODhPzVp61NRzWSbqi8GwRnJQOoCU8/4G Fcw8770Qw/5VZxhVGNNSBOl5jlTTXDfNzsJF3G90F1KKD7zT/03kONj23rJKnbSH LhMfawLJbCJynhZcntWjyTmyokAeYjwZkK8uBtDY17adWfDsQrt3B4VHC+cCA50I MAj/UMlBFr9777abxJKmqP8T/+Z9ATnstVA6oY9B6GSPVM7ks9PwamRCjAahzrgQ foXDWsZNbi34jAoUn97wodfhIwnTafLdww12zORNbUOcJPw3Tbm18WTtgiiztVFf iBiwLI3KtFKpgvQq21GKnZNbH70bA/tsjpkoVWBLTzwT2KpJlHwo3Q== =6mXd -----END PGP SIGNATURE----- From mcr@marajade.sandelman.ca Mon Oct 12 14:13:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC5E3A67FD for ; Mon, 12 Oct 2009 14:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y9R50ei62HF for ; Mon, 12 Oct 2009 14:13:54 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 068113A6859 for ; Mon, 12 Oct 2009 14:13:54 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.198]) by relay.sandelman.ca (Postfix) with ESMTPS id DB2D13428F for ; Mon, 12 Oct 2009 21:18:20 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 716C14E7FD for ; Mon, 12 Oct 2009 17:13:53 -0400 (EDT) From: Michael Richardson To: IETF ROLL In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com> <3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 12 Oct 2009 17:13:53 -0400 Message-ID: <7991.1255382033@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 21:13:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> We are in perfect line. At the moment, RPL would impose Pascal> NS/NA between 6LoWPAN routers to expose the host routes. I have just read 6lowpan-nd-06.txt Some things immediately jump out at me: 1) small packets are much more common, so DAOs may not fit into ND. 2) multicast is not assumed, so the Whiteboard is used. 3) nodes that are sleepy, are not going to be useful as members of an RPL DAG, so really, it's about RPL between the Edge Routers. It seems to me therefore that the only nodes in a 6lowpan that can participate in a RPL DAG would be the edge router that runs a Whiteboard. I think you capture this in your above sentence. I do not think that the 6LoWPAN routers will be speaking NR/NC between themselves along their "backbone", but I could be wrong. I also think that some other people may be thinking that many more 6LoWPAN nodes will participate in RPL than just the edge routers. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/ iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw== =FpQB -----END PGP SIGNATURE----- From Jerald.P.Martocci@jci.com Mon Oct 12 14:22:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4472D28C135; Mon, 12 Oct 2009 14:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvw2CmH6SkBs; Mon, 12 Oct 2009 14:22:13 -0700 (PDT) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by core3.amsl.com (Postfix) with ESMTP id A394D3A67FD; Mon, 12 Oct 2009 14:22:12 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKStOd/WNOiTA16yknRCYXHwWlvre1/RdC@postini.com; Mon, 12 Oct 2009 14:22:14 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009101216215799-132117 ; Mon, 12 Oct 2009 16:21:57 -0500 In-Reply-To: <7991.1255382033@marajade.sandelman.ca> MIME-Version: 1.0 To: Michael Richardson X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Mon, 12 Oct 2009 16:21:54 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 10/12/2009 04:22:00 PM, Serialize complete at 10/12/2009 04:22:00 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/12/2009 04:21:57 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/12/2009 04:22:10 PM, Serialize complete at 10/12/2009 04:22:10 PM Content-Type: multipart/alternative; boundary="=_alternative 00755C8F8625764D_=" Cc: IETF ROLL , roll-bounces@ietf.org Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 21:22:14 -0000 This is a multipart message in MIME format. --=_alternative 00755C8F8625764D_= Content-Type: text/plain; charset="US-ASCII" I guess I am one of those people that think that other 6LoWPAN nodes must participate in RPL. Unless I am missing something RPL is the only game in town regarding meshing of wireless sensors. If they are not in RPL is there another means that they can use to form mesh connectivity to get to the LBR? Jerry Michael Richardson Sent by: roll-bounces@ietf.org 10/12/2009 04:13 PM To IETF ROLL cc Subject Re: [Roll] NA to transport DAO -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> We are in perfect line. At the moment, RPL would impose Pascal> NS/NA between 6LoWPAN routers to expose the host routes. I have just read 6lowpan-nd-06.txt Some things immediately jump out at me: 1) small packets are much more common, so DAOs may not fit into ND. 2) multicast is not assumed, so the Whiteboard is used. 3) nodes that are sleepy, are not going to be useful as members of an RPL DAG, so really, it's about RPL between the Edge Routers. It seems to me therefore that the only nodes in a 6lowpan that can participate in a RPL DAG would be the edge router that runs a Whiteboard. I think you capture this in your above sentence. I do not think that the 6LoWPAN routers will be speaking NR/NC between themselves along their "backbone", but I could be wrong. I also think that some other people may be thinking that many more 6LoWPAN nodes will participate in RPL than just the edge routers. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/ iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw== =FpQB -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 00755C8F8625764D_= Content-Type: text/html; charset="US-ASCII"
I guess I am one of those people that think that other 6LoWPAN nodes must participate in RPL.  Unless I am missing something RPL is the only game in town regarding meshing of wireless sensors.  If they are not in RPL is there another means that they can use to form mesh connectivity to get to the LBR?

Jerry





Michael Richardson <mcr@sandelman.ca>
Sent by: roll-bounces@ietf.org

10/12/2009 04:13 PM

To
IETF ROLL <roll@ietf.org>
cc
Subject
Re: [Roll] NA to transport DAO





-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Pascal" == Pascal Thubert <(pthubert)" <pthubert@cisco.com>> writes:
   Pascal> We are in perfect line. At the moment, RPL would impose
   Pascal> NS/NA between 6LoWPAN routers to expose the host routes.

I have just read 6lowpan-nd-06.txt

Some things immediately jump out at me:
    1) small packets are much more common, so DAOs may not fit into ND.
    2) multicast is not assumed, so the Whiteboard is used.
    3) nodes that are sleepy, are not going to be useful as members of
                an RPL DAG, so really, it's about RPL between the Edge Routers.

It seems to me therefore that the only nodes in a 6lowpan that can
participate in a RPL DAG would be the edge router that runs a
Whiteboard.

I think you capture this in your above sentence.   I do not think that
the 6LoWPAN routers will be speaking NR/NC between themselves along
their "backbone", but I could be wrong.

I also think that some other people may be thinking that many more
6LoWPAN nodes will participate in RPL than just the edge routers.

- --
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                               then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N
j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX
bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp
GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo
aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/
iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw==
=FpQB
-----END PGP SIGNATURE-----
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 00755C8F8625764D_=-- From pal@cs.stanford.edu Mon Oct 12 14:54:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0FD3A67EA for ; Mon, 12 Oct 2009 14:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qjx8cAJYGa6F for ; Mon, 12 Oct 2009 14:54:22 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 8EFAD3A68A1 for ; Mon, 12 Oct 2009 14:54:22 -0700 (PDT) Received: from [76.75.8.40] (helo=[172.17.143.249]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MxSqU-0000gh-Ud; Mon, 12 Oct 2009 14:54:23 -0700 Message-Id: From: Philip Levis To: Richard Kelsey In-Reply-To: <878wfgbse1.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 14:54:06 -0700 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <2863E9BF-442B-4F7C-8415-1BE4192DE977@cisco.com> <878wfgbse1.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 21:54:23 -0000 On Oct 12, 2009, at 7:26 AM, Richard Kelsey wrote: > My point is that the key metric for reliability is not the > RTX for a message right now, or any similar metric, but an > estimate of the stability of the link itself. We need to > preferentially use stable links. If the DAG can reconfigure very quickly, then the need to prefer stable links disappears. E.g., there's a paper appearing in SenSys this year (Bursty Traffic over Bursty Links) that finds using very transient links can reduce path length and improve throughput. If the DAG cannot reconfigure or repair quickly, then stable links are important. But by constraining a protocol to only using stable links, we would lose any possible benefits of rapid recovery. This seems like putting the horse before the cart. Phil From pal@cs.stanford.edu Mon Oct 12 14:58:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63543A67EA for ; Mon, 12 Oct 2009 14:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtUBt5oMLB2y for ; Mon, 12 Oct 2009 14:58:28 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 7672D3A6958 for ; Mon, 12 Oct 2009 14:57:59 -0700 (PDT) Received: from [76.75.8.40] (helo=[172.17.143.249]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MxStz-0000op-TD; Mon, 12 Oct 2009 14:58:00 -0700 Message-Id: From: Philip Levis To: Richard Kelsey In-Reply-To: <871vl8bgzq.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 14:57:58 -0700 References: <235757746.16320661255103614862.JavaMail.root@mail02.pantherlink.uwm.edu> <871vl8bgzq.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 21:58:28 -0000 On Oct 12, 2009, at 11:32 AM, Richard Kelsey wrote: > From: Philip Levis > Date: Fri, 9 Oct 2009 12:21:52 -0700 > > Yes, the curve is sharp. Figure 8 in this paper[1] shows the curve > found from direct measurements on two 15.4 nodes using a shielded > environment and a variable attenuator. It shows a similarly sharp > curve (theory and practice agree). > > But be careful -- both the analysis and measurement assume that > there > is no interference, something which an LLN cannot assume. It is > possible to have a very high SINR and a poor packet reception ratio. > While very small swings in signal strength can make wireless links > transition from poor to good or vice versa, interference can easily > have a much more gradual effect. > > I am sorry, but I am not sure what you are saying. > What is the property of interference that causes this > more gradual effect? I am an 802.15.4 transmitter. I have an 802.11b transmitter that uses X % of the channel, such that Y% of transmitted 802.15.4 packets are clobbered by 802.11. X may be smaller, greater, or equal to Y, depending on all kinds of effects. But the two are proportional, and as X can range from zero to close to 100%... Put another way, a lightly utilized 802.11b network might cause a few losses, while a heavily utilized one could cause many losses. And this can change quickly. The same is true for other unlicensed frequency bands, where there can be analog and/or digital interferers. Phil From maxence.dalmais@insa-lyon.fr Mon Oct 12 15:09:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39B3228C1E6 for ; Mon, 12 Oct 2009 15:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.212 X-Spam-Level: X-Spam-Status: No, score=0.212 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5UTZ2ftZPZE for ; Mon, 12 Oct 2009 15:09:38 -0700 (PDT) Received: from smtp.insa-lyon.fr (criges14.insa-lyon.fr [134.214.76.242]) by core3.amsl.com (Postfix) with ESMTP id 9EC9E3A67EA for ; Mon, 12 Oct 2009 15:09:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 15A63F12C1 for ; Tue, 13 Oct 2009 00:09:38 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQh-thhKpjgG for ; Tue, 13 Oct 2009 00:09:37 +0200 (CEST) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: mdalmais1) by smtp.insa-lyon.fr (Postfix) with ESMTPSA id 7789FF12B9 for ; Tue, 13 Oct 2009 00:09:37 +0200 (CEST) Received: by fxm28 with SMTP id 28so7905785fxm.42 for ; Mon, 12 Oct 2009 15:09:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.130.150 with SMTP id 22mr439984hbj.59.1255385376930; Mon, 12 Oct 2009 15:09:36 -0700 (PDT) In-Reply-To: <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> From: Maxence Dalmais Date: Tue, 13 Oct 2009 00:09:15 +0200 Message-ID: To: JP Vasseur Content-Type: multipart/alternative; boundary=001485f6c86a72bcde0475c42fc0 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 22:09:39 -0000 --001485f6c86a72bcde0475c42fc0 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, >> >> The fact is that sending a high energy cost packet won't be a problem for >> a mains powered node, but it will induce noise and impact the links of the >> entire network. >> >> That is a second order effect though and not true for PLC link. It is bit >> of a stretch to choose a low energy path, because of a high energy path may >> cause increase noise along that path thus leading to more errors ... don't >> you think ? >> >> >> Personnaly I don't think. >> >> Using high energy path will include more errors to others transmissions, >> ie increase retransmissions, ie increase the ETX metric. This may involve >> modifications in the chosen path. >> > > you are basically saying that we should not use high energy links .... > > I am saying that when using wireless links, a node should be aware that his communication could interfere with other communication. Less powered is the transmission signal, less noise is seen by neighbours. A low powered node will also need less energy to communicate in a less noisy environnement. So, it appears to me logical that when others metrics are egals to choose the less power needed links. As said somewhere else, the final metric should be a computation of different metrics. I think that including the energy cost in the computation could be a little great idea. Yes but how would you expect "host" to use that information to select the > router ? > It may very well be that the router offering the lower energy cost end up > following a high energy path. > [In [Roll] RPL Metric I-D from JP Vasseur to Alexandru Petrescu about link energy information in RA ] That means that we need end-to-end energy-cost metric to balance the route. Maybe we need 2. The first being a sum of product of the power consumption to send the packet with the needs to save energy (ie the mains powered nodes won't be include having a nul needs to save energy). End-2-End Energy Cost Metric = sum for i in 0 to path_length : powerConsumption (i,i+1) * savingEnergyNeeds(i) The second one is more subject to discussion. Experimentation results of such an idea could help to make a choice. The idea is to get a representation for the inconvenience to other nodes to transmit a packet on the specific link. This is very different from the classical best effort, but maybe one of the first think to do to improve quality in Lossy wireless Network is to reduce the perceived noise. Here is my point of view, Maxence. HI Maxence, > > > On Oct 12, 2009, at 5:00 PM, Maxence Dalmais wrote: > > Hi JP, >> >> >> The fact is that sending a high energy cost packet won't be a problem for >> a mains powered node, but it will induce noise and impact the links of the >> entire network. >> >> That is a second order effect though and not true for PLC link. It is bit >> of a stretch to choose a low energy path, because of a high energy path may >> cause increase noise along that path thus leading to more errors ... don't >> you think ? >> >> >> Personnaly I don't think. >> >> Using high energy path will include more errors to others transmissions, >> ie increase retransmissions, ie increase the ETX metric. This may involve >> modifications in the chosen path. >> > > you are basically saying that we should not use high energy links .... > > > Maybe we could think that we don't need to take energy path into account >> the because ETX will automatically adapt to this. >> > > that is the aim of using ETX > > > But having a highly dynamic ETX may cause others trouble, don't you think >> ? >> > > of course, this is true for ALL dynamic metrics. > > > Maybe, energy path has to be taken in count in RPL to avoid the need of a >> very dynamic ETX and retransmissions. >> >> I think that when designing a new specialized protocol, we shouldn't be >> affraid of developing new idea. >> >> > we're not afraid ;-) but we learned from experience (look at the dynamic > metric of ARPANET 2). > - Hide quoted text - > > > Does anyone have experience with such an altruistic routing protocol ? > > Cheers, > > Maxence. > --001485f6c86a72bcde0475c42fc0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,



The fact is that sending a high energy cost packet won't be a problem f= or a mains powered node, but it will induce noise and impact the links of t= he entire network.

That is a second order effect though and not true for PLC link. It is bit o= f a stretch to choose a low energy path, because of a high energy path may = cause increase noise along that path thus leading to more errors ... don= 9;t you think ?


Personnaly I don't think.

Using high energy path will include more errors to others transmissions, ie= increase retransmissions, ie increase the ETX metric. This may involve mod= ifications in the chosen path.

you are basically saying that we should not use high energy links ....
=


I am saying that when using wireless links,= a node should be aware that his communication could interfere with other communication.
Less powered= is the transmission signal, less noise is seen by neighbours.
A low powered node will also need less energy to communicate in a less nois= y environnement.

So, it appears to me logical that when others metri= cs are egals to choose the less power needed links.

As said somewher= e else, the final metric should be a computation of different metrics.
I think that including the energy cost in the computation could be a little= great idea.


Yes but how would you expect "host" to use that information to se= lect the router ?
It may very well be that the router offering the lower energy cost end up f= ollowing a high energy path.
[In [Roll] RP= L Metric I-D from JP Vasseur=A0to Alexandru Petrescu ab= out link energy information in RA ]

That means that we need end-to-end energy-cost metric to balance = the route.
Maybe we need 2. The first being a sum of product of the powe= r consumption to send the packet with the needs to save energy (ie the main= s powered nodes won't be include having a nul needs to save energy). End-2-End Energy Cost Metric =3D sum for i in 0 to path_length : powerConsu= mption (i,i+1) * savingEnergyNeeds(i)

The second one is more subject= to discussion. Experimentation results of such an idea could help to make = a choice.
The idea is to get a representation for the inconvenience to other nodes to= transmit a packet on the specific link.
This is very different from the= classical best effort, but maybe one of the first think to do to improve q= uality in Lossy wireless Network is to reduce the perceived noise.

Here is my point of view,

Maxence.


HI Maxence,


On Oct 12, 2009, at 5:00 PM, Maxence Dalmais wrote:

Hi JP,


The fact is that sending a high energy cost packet won't be a problem for a mains powered node, but it will induce noise and impact the links of the entire network.

That is a second order effect though and not true for PLC link. It is bit of a stretch to choose a low energy path, because of a high energy path may cause increase noise along that path thus leading to more errors ... don't you think ?


Personnaly I don't think.

Using high energy path will include more errors to others transmissions, ie increase retransmissions, ie increase the ETX metric. This may involve modifications in the chosen path.

you are basically saying that we should not use high energy links ....


Maybe we could think that we don't need to take energy path into accoun= t the =A0because ETX will automatically adapt to this.

that is the aim of using ETX


But having a highly dynamic ETX may cause others trouble, don't you thi= nk =A0?

of course, this is true for ALL dynamic metrics.


Maybe, energy path has to be taken in count in RPL to avoid the need of a v= ery dynamic ETX and retransmissions.

I think that when designing a new specialized protocol, we shouldn't be= affraid of developing new idea.


we're not afraid ;-) but we learned from experience (look at the dynami= c metric of ARPANET 2).
- Hide quoted text -


Does anyone have experience with such an altruistic routing protocol ?
<= br> Cheers,

Maxence.

--001485f6c86a72bcde0475c42fc0-- From tzeta.tsao@ekasystems.com Mon Oct 12 15:48:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51353A689E for ; Mon, 12 Oct 2009 15:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76+nOHXOdD5l for ; Mon, 12 Oct 2009 15:48:14 -0700 (PDT) Received: from smtp108.biz.mail.re2.yahoo.com (smtp108.biz.mail.re2.yahoo.com [206.190.52.47]) by core3.amsl.com (Postfix) with SMTP id 066083A67EA for ; Mon, 12 Oct 2009 15:48:13 -0700 (PDT) Received: (qmail 81416 invoked from network); 12 Oct 2009 22:48:13 -0000 Received: from unknown (HELO ?192.168.0.182?) (tzeta.tsao@209.48.242.70 with plain) by smtp108.biz.mail.re2.yahoo.com with SMTP; 12 Oct 2009 22:48:12 -0000 X-Yahoo-SMTP: 18Fc8ICswBBVPDv5exrrk3k0phuhQJtGVVI9vm7eGXDtosryT8s- X-YMail-OSG: 2YviFyYVM1lzhvy7mWn.zuFXo2Lju.R24KT3j3.NYg987PPP2lRBJV_jRnhzMg5wJIR.ejnmltTlRnuFIqhEopEUnpXio.KgX50n3zLYx6cPKZ02cpZsXXx7fHalS9o3jMk.QjJQcfpvJjHjROoh73hNjy.6WMWTRmWbNS0NnViwrNQxGcn6nUkJDEaWtk5NDqn8ngr4hyEiGC5yh8lYZjCrEJLuXwXb5OeNIoN5iDUB651_Ea5dPKHVziLplvxnEhUq5iEo8SrRZTH9RFHpDc0yr0b2Ch8LY1z0bzcPH.Scoj2GjUZhuGFM2KrVRdR8t_X5AyoX5KWH3Q3pYpYX99YuwYEqogrD X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD3B1F1.5040601@ekasystems.com> Date: Mon, 12 Oct 2009 18:47:13 -0400 From: Tzeta Tsao User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Richard Kelsey References: <235757746.16320661255103614862.JavaMail.root@mail02.pantherlink.uwm.edu> <871vl8bgzq.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <871vl8bgzq.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 22:48:15 -0000 Hi Richard, I wonder if SNR is as useful when the noise is not AWGN, and similarly SINR. In addition, there are factors such as coding, even if only repetition code, to take into account when translating BER to packet error rate. Of course, the question eventually is still the reliability of the link metric. The metric could be stringent to retain only very good links, suitable maybe for larger networks. Or, the threshold could be lower allowing the use of less reliable links, suitable maybe for smaller networks. My 2c. Regards, Tzeta Richard Kelsey wrote: > From: Philip Levis > Date: Fri, 9 Oct 2009 12:21:52 -0700 > > Yes, the curve is sharp. Figure 8 in this paper[1] shows the curve > found from direct measurements on two 15.4 nodes using a shielded > environment and a variable attenuator. It shows a similarly sharp > curve (theory and practice agree). > > But be careful -- both the analysis and measurement assume that there > is no interference, something which an LLN cannot assume. It is > possible to have a very high SINR and a poor packet reception ratio. > While very small swings in signal strength can make wireless links > transition from poor to good or vice versa, interference can easily > have a much more gradual effect. > > I am sorry, but I am not sure what you are saying. > What is the property of interference that causes this > more gradual effect? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Mon Oct 12 15:57:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 884EA3A68F3 for ; Mon, 12 Oct 2009 15:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-Ce1ACeeU1D for ; Mon, 12 Oct 2009 15:57:16 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 136763A689E for ; Mon, 12 Oct 2009 15:57:15 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 46523D480FF; Tue, 13 Oct 2009 00:57:11 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id F1E1FD48165; Tue, 13 Oct 2009 00:57:08 +0200 (CEST) Message-ID: <4AD3B443.9010401@gmail.com> Date: Tue, 13 Oct 2009 00:57:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <4ACDF4C6.5020109@gmail.com> <42382722-B852-4B20-A3D3-4C2E4C4FF871@cisco.com> <4ACF78A9.8040405@gmail.com> <4AD30746.9040807@gmail.com> <919800CD-E8BC-433F-8206-0B3190376DBB@cisco.com> <4AD33673.8030400@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091012-0, 12/10/2009), Outbound message X-Antivirus-Status: Clean Cc: IETF ROLL , Kris Pister Subject: Re: [Roll] RPL Metric I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 22:57:17 -0000 JP Vasseur a écrit : > > On Oct 12, 2009, at 4:00 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> Hi Alex, >>>> [snip] >>>>>> We could struggle to compare a path with high energy cost yet low >>>>>> hopcount cost to a path with low energy cost yet high hopcount >>>>>> cost. Is >>>>>> P1 preferable over P2 or vice-versa? >>>>>> >>>>>> I think this is a question to which one can't answer without >>>>>> knowing the >>>>>> deployment context. >>>>>> >>>>> Well at least we need one example where it could be useful. I can't >>>>> find of any personally. >>>> >>>> Here is one: >>>> -- -- >>>> |R1| |R2| >>>> -- -- >>>> | | >>>> | | >>>> | | >>>> | | >>>> \ ---- / >>>> |Host| >>>> ---- >>>> >>>> R1 and R2 send two different RAs. Each pretends to be a default >>>> router (non-zero Router Lifetime) and send different "link energy >>>> metrics" to Host. >>> Link energy relates to which link ? >> >> Link energy metric in RA relates to the link on which that RA is sent. >> One RA is typically sent on a single link. >> > > Yes but how would you expect "host" to use that information to select > the router ? By using some local intelligence knobs. If the knobs are up saying "use the default router on the link involving the least energy consumption" then do so. > It may very well be that the router offering the lower energy cost end > up following a high energy path. Yes. But in very many cases the end node can't choose paths based on any parameter, not only energy (well, except RSVP). The notion of 'default' router itself is such. When the host receives an RA from a router pretending to be a default router there is no guarantee for the host that that router offers a shortest path to a certain destination (IP hopcount metric). My PDA with a 3G and a WiFi interface: I have no idea which offers the shortest path to gmail.com. I just pick the interface which is sure to lead to the Internet. If I need an interface to a link which consumes less then I pick the interface which has just received an RA telling it how little it is supposed to consume. Same with MTU: when host reads an RA telling it the MTU is 1280 it has no guarantee that the entire path is 1280 - often the intermediary links to the final destination offer larger-than-1280 MTU, typically the backhaul links. Thus I propose to have the same kind of behaviour for the energy metric for link in RA, as we have for default routers and with MTU. Later we can see about link energy metric for routing protocols. (as Path MTU Discovery is for MTU of paths). Alex > >> In the above figure there are two links. >> >> Is this ok? >> >> Alex >> > > From jvasseur@cisco.com Mon Oct 12 19:48:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412EC3A683B for ; Mon, 12 Oct 2009 19:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.057 X-Spam-Level: X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlSAGyPpVqgu for ; Mon, 12 Oct 2009 19:48:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0D21C3A6782 for ; Mon, 12 Oct 2009 19:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=12951; q=dns/txt; s=amsiport01001; t=1255402117; x=1256611717; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Tue,=2013=20Oct=202009 =2004:48:34=20+0200|Message-Id:=20<993C9EBE-CF52-4645-A9A D-6F31FE2C2215@cisco.com>|To:=20Maxence=20Dalmais=20|Cc:=20roll@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|In-Reply-To:=20|References:=20=20<4AD30B6 B.3030802@gmail.com>=20<1D93951F-F2CF-46C4-B14A-2FD251D0E 715@cisco.com>=20=20<4AD32D6F.7090406@gmail.com>=20<1B652 45C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com>=20=20=20=20 =20=20=20=20=20<783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco. com>=20; bh=sT2RDwLZPEoh49mcqc78MuGhirjZE3eC2Mw5g/pHIu0=; b=HXUSqoCsPrB/i6dd8kFuB6bGeR48VGjjyHy97LLDxQLHM80aaGGkYEWA iNMYx2yl2KrHqUy2ELTi8kpe4ptPTy9caTb7N7H5X3xkzA5Sh5p83QKzx 8zYagwPOvldHiphuIc7B9j56uvQPKOecj9QbKkH6GRYV8v6nYzT419T/j E=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAALiH00qQ/uCWe2dsb2JhbACCJS+YOAEBFiQGo0iJDwiOL4JFCIFgBA X-IronPort-AV: E=Sophos;i="4.44,548,1249257600"; d="scan'208,217";a="51595030" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 02:48:35 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D2mZeX026830; Tue, 13 Oct 2009 02:48:35 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 04:48:35 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 04:48:34 +0200 Message-Id: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> From: JP Vasseur To: Maxence Dalmais In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-64-69523660 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 04:48:34 +0200 References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 02:48:34.0756 (UTC) FILETIME=[A83F4840:01CA4BAF] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 02:48:38 -0000 --Apple-Mail-64-69523660 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Maxence, On Oct 13, 2009, at 12:09 AM, Maxence Dalmais wrote: > Hi JP, > > > > The fact is that sending a high energy cost packet won't be a > problem for a mains powered node, but it will induce noise and > impact the links of the entire network. > > That is a second order effect though and not true for PLC link. It > is bit of a stretch to choose a low energy path, because of a high > energy path may cause increase noise along that path thus leading to > more errors ... don't you think ? > > > Personnaly I don't think. > > Using high energy path will include more errors to others > transmissions, ie increase retransmissions, ie increase the ETX > metric. This may involve modifications in the chosen path. > > you are basically saying that we should not use high energy links .... > > > > I am saying that when using wireless links, a node should be aware > that his communication could interfere with other communication. > Less powered is the transmission signal, less noise is seen by > neighbours. > A low powered node will also need less energy to communicate in a > less noisy environnement. > Bear in mind, that you do not know this environment so this may lead you to an incorrect conclusion. The real metric is the link reliability, which reflect the properties of the environment. Furthermore, this does not apply to PLC links. > So, it appears to me logical that when others metrics are egals to > choose the less power needed links. > > As said somewhere else, the final metric should be a computation of > different metrics. This is the objective function. JP. > I think that including the energy cost in the computation could be a > little great idea. > > > Yes but how would you expect "host" to use that information to > select the router ? > It may very well be that the router offering the lower energy cost > end up following a high energy path. > [In [Roll] RPL Metric I-D from JP Vasseur to Alexandru Petrescu > about link energy information in RA ] > > That means that we need end-to-end energy-cost metric to balance the > route. > Maybe we need 2. The first being a sum of product of the power > consumption to send the packet with the needs to save energy (ie the > mains powered nodes won't be include having a nul needs to save > energy). > End-2-End Energy Cost Metric = sum for i in 0 to path_length : > powerConsumption (i,i+1) * savingEnergyNeeds(i) > > The second one is more subject to discussion. Experimentation > results of such an idea could help to make a choice. > The idea is to get a representation for the inconvenience to other > nodes to transmit a packet on the specific link. > This is very different from the classical best effort, but maybe one > of the first think to do to improve quality in Lossy wireless > Network is to reduce the perceived noise. > > Here is my point of view, > > Maxence. > > > HI Maxence, > > > On Oct 12, 2009, at 5:00 PM, Maxence Dalmais wrote: > > Hi JP, > > > The fact is that sending a high energy cost packet won't be a > problem for a mains powered node, but it will induce noise and > impact the links of the entire network. > > That is a second order effect though and not true for PLC link. It > is bit of a stretch to choose a low energy path, because of a high > energy path may cause increase noise along that path thus leading to > more errors ... don't you think ? > > > Personnaly I don't think. > > Using high energy path will include more errors to others > transmissions, ie increase retransmissions, ie increase the ETX > metric. This may involve modifications in the chosen path. > > you are basically saying that we should not use high energy links .... > > > Maybe we could think that we don't need to take energy path into > account the because ETX will automatically adapt to this. > > that is the aim of using ETX > > > But having a highly dynamic ETX may cause others trouble, don't you > think ? > > of course, this is true for ALL dynamic metrics. > > > Maybe, energy path has to be taken in count in RPL to avoid the need > of a very dynamic ETX and retransmissions. > > I think that when designing a new specialized protocol, we shouldn't > be affraid of developing new idea. > > > we're not afraid ;-) but we learned from experience (look at the > dynamic metric of ARPANET 2). > - Hide quoted text - > > > Does anyone have experience with such an altruistic routing protocol ? > > Cheers, > > Maxence. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-64-69523660 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Maxence,

On Oct 13, 2009, at 12:09 AM, Maxence Dalmais = wrote:

Hi JP,



= The fact is that sending a high energy cost packet won't be a problem = for a mains powered node, but it will induce noise and impact the links = of the entire network.

That is a second order effect though and = not true for PLC link. It is bit of a stretch to choose a low energy = path, because of a high energy path may cause increase noise along that = path thus leading to more errors ... don't you think ?


= Personnaly I don't think.

Using high energy path will include = more errors to others transmissions, ie increase retransmissions, ie = increase the ETX metric. This may involve modifications in the chosen = path.

you are basically saying that we = should not use high energy links ....

=

I am saying that when using wireless = links, a node should be aware that his communication could interfere = with other communication.
Less powered is the transmission signal, = less noise is seen by neighbours.
A low powered node will also need = less energy to communicate in a less noisy = environnement.




So, it appears to me logical that when others = metrics are egals to choose the less power needed links.

As said = somewhere else, the final metric should be a computation of different = metrics.

This is the = objective function.

JP.

I think that including = the energy cost in the computation could be a little great = idea.


Yes but how = would you expect "host" to use that information to select the router = ?
It may very well be that the router offering the lower energy cost = end up following a high energy path.
[In [Roll] RPL Metric I-D from JP = Vasseur to = Alexandru Petrescu about link energy = information in RA ]

That means that we need end-to-end = energy-cost metric to balance the route.
Maybe we need 2. The first = being a sum of product of the power consumption to send the packet with = the needs to save energy (ie the mains powered nodes won't be include = having a nul needs to save energy).
End-2-End Energy Cost Metric =3D = sum for i in 0 to path_length : powerConsumption (i,i+1) * = savingEnergyNeeds(i)

The second one is more subject to = discussion. Experimentation results of such an idea could help to make a = choice.
The idea is to get a representation for the inconvenience to = other nodes to transmit a packet on the specific link.
This is very = different from the classical best effort, but maybe one of the first = think to do to improve quality in Lossy wireless Network is to reduce = the perceived noise.

Here is my point of = view,

Maxence.


HI = Maxence,


= On Oct 12, 2009, at 5:00 PM, Maxence Dalmais wrote:

Hi JP,

=
The fact is that sending a high energy cost packet won't be a = problem for a mains powered node, but it will induce noise and impact = the links of the entire network.

That is a second order effect = though and not true for PLC link. It is bit of a stretch to choose a low = energy path, because of a high energy path may cause increase noise = along that path thus leading to more errors ... don't you think ?
=

Personnaly I don't think.

Using high energy path will = include more errors to others transmissions, ie increase = retransmissions, ie increase the ETX metric. This may involve = modifications in the chosen path.

you are basically saying that we should = not use high energy links ....


Maybe we could think that we don't need to = take energy path into account the  because ETX will automatically = adapt to this.

that is the aim of using ETX


But having a highly dynamic ETX may cause = others trouble, don't you think  ?

of course, this is true for ALL dynamic = metrics.


=
= Maybe, energy path has to be taken in count in RPL to avoid the need of = a very dynamic ETX and retransmissions.

I think that when = designing a new specialized protocol, we shouldn't be affraid of = developing new idea.


we're not afraid ;-) but we learned from = experience (look at the dynamic metric of ARPANET 2).
- Hide quoted text -


Does anyone have experience with such an altruistic = routing protocol ?

Cheers,

= Maxence.

= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-64-69523660-- From jvasseur@cisco.com Mon Oct 12 19:53:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39D73A683D; Mon, 12 Oct 2009 19:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.089 X-Spam-Level: X-Spam-Status: No, score=-10.089 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8DX24-D6UKV; Mon, 12 Oct 2009 19:53:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E69F43A683B; Mon, 12 Oct 2009 19:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=8766; q=dns/txt; s=amsiport01001; t=1255402410; x=1256612010; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20NA=20to=20transport=20DAO|Date:=20Tue,=2013 =20Oct=202009=2004:53:27=20+0200|Message-Id:=20|To:=20Jerald.P.Mar tocci@jci.com|Cc:=20Michael=20Richardson=20,=20IETF=20ROLL=20,=0D=0A=20=20=20=20 =20=20=20=20roll-bounces@ietf.org|Mime-Version:=201.0=20( Apple=20Message=20framework=20v936)|In-Reply-To:=20|References:=20; bh=M0GmPg605ikhpn1VUnz3WZqWoCyVTZPADjWYJG9rOW4=; b=BUpVV512ryfdDeWe7eIshRsq/v+zbM2/jl+EBEp8emyubNio7mBd/XOQ kyAFZ3RTOhmHnl2WhK02+c6ht24uLdubmQwUrAukTu+6sDa6SWQaEVOb6 o7k39uIEtpB0ign9cRgMUPw89VuBPzDysVc2iK8pPJNJ5CSyTfTQBISLc U=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4AAOOI00qQ/uCWe2dsb2JhbACCJS8hhG2TKgEBFiQGo0qJL44VhC0EgVg X-IronPort-AV: E=Sophos;i="4.44,548,1249257600"; d="scan'208,217";a="51595094" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 02:53:28 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D2rSN8027217; Tue, 13 Oct 2009 02:53:28 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 04:53:28 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 04:53:27 +0200 Message-Id: From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-66-69816688 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 04:53:27 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 02:53:27.0885 (UTC) FILETIME=[56F737D0:01CA4BB0] Cc: roll-bounces@ietf.org, IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 02:53:31 -0000 --Apple-Mail-66-69816688 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 12, 2009, at 11:21 PM, Jerald.P.Martocci@jci.com wrote: > > I guess I am one of those people that think that other 6LoWPAN nodes > must participate in RPL. Unless I am missing something RPL is the > only game in town regarding meshing of wireless sensors. If they > are not in RPL is there another means that they can use to form mesh > connectivity to get to the LBR? You interpretation is of course correct. JP. > > Jerry > > > > > > Michael Richardson > Sent by: roll-bounces@ietf.org > 10/12/2009 04:13 PM > > To > IETF ROLL > cc > Subject > Re: [Roll] NA to transport DAO > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>>>> "Pascal" == Pascal Thubert <(pthubert)" > > writes: > Pascal> We are in perfect line. At the moment, RPL would impose > Pascal> NS/NA between 6LoWPAN routers to expose the host routes. > > I have just read 6lowpan-nd-06.txt > > Some things immediately jump out at me: > 1) small packets are much more common, so DAOs may not fit into > ND. > 2) multicast is not assumed, so the Whiteboard is used. > 3) nodes that are sleepy, are not going to be useful as members of > an RPL DAG, so really, it's about RPL between the > Edge Routers. > > It seems to me therefore that the only nodes in a 6lowpan that can > participate in a RPL DAG would be the edge router that runs a > Whiteboard. > > I think you capture this in your above sentence. I do not think that > the 6LoWPAN routers will be speaking NR/NC between themselves along > their "backbone", but I could be wrong. > > I also think that some other people may be thinking that many more > 6LoWPAN nodes will participate in RPL than just the edge routers. > > - -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N > j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX > bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp > GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo > aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/ > iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw== > =FpQB > -----END PGP SIGNATURE----- > _______________________________________________ > 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 --Apple-Mail-66-69816688 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 12, 2009, = at 11:21 PM, Jerald.P.Martocci@jci.com = wrote:


I guess I am one = of those people that think that other 6LoWPAN nodes must participate in = RPL.  Unless I am missing something RPL is the only game in town = regarding meshing of wireless sensors.  If they are not in RPL is = there another means that they can use to form mesh connectivity to get = to the LBR?

You = interpretation is of course = correct.

JP.

=
Jerry





Michael Richardson <mcr@sandelman.ca> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">10/12/2009 04:13 PM =

To
IETF ROLL <roll@ietf.org>
cc
Subject
Re: [Roll] NA to transport = DAO

=



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=

>>>>> "Pascal" =3D=3D Pascal Thubert = <(pthubert)" <pthubert@cisco.com>> = writes:
   Pascal> We are in perfect line. At the = moment, RPL would impose
   Pascal> NS/NA between = 6LoWPAN routers to expose the host routes.

I have just read = 6lowpan-nd-06.txt

Some things immediately jump out at me:
=     1) small packets are much more common, so DAOs may not fit = into ND.
    2) multicast is not assumed, so the = Whiteboard is used.
    3) nodes that are sleepy, are not = going to be useful as members of
          =       an RPL DAG, so really, it's about RPL between the = Edge Routers.

It seems to me therefore that the only nodes in a = 6lowpan that can
participate in a RPL DAG would be the edge router = that runs a
Whiteboard.

I think you capture this in your = above sentence.   I do not think that
the 6LoWPAN routers will = be speaking NR/NC between themselves along
their "backbone", but I = could be wrong.

I also think that some other people may be = thinking that many more
6LoWPAN nodes will participate in RPL than = just the edge routers.

- --
]       He who = is tired of Weird Al is tired of life!         =   |  firewalls  [
]   Michael Richardson, = Sandelman Software Works, Ottawa, ON    |net architect[
] = mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on= .ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.c= om/watch?v=3Dkzx1ycLXQSE>
          =                     =  then sign the petition.
-----BEGIN PGP SIGNATURE-----
= Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys
=
= iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N
= j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX
= bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp
= GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo
= aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/
= iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw=3D=3D
= =3DFpQB
-----END PGP SIGNATURE-----
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
 =
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-66-69816688-- From wintert@acm.org Mon Oct 12 20:16:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A98C3A6A0C for ; Mon, 12 Oct 2009 20:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.018 X-Spam-Level: X-Spam-Status: No, score=-98.018 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FF_IHOPE_YOU_SINK=2.166, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9htB30Z2oz5h for ; Mon, 12 Oct 2009 20:16:33 -0700 (PDT) Received: from smtp102.prem.mail.ac4.yahoo.com (smtp102.prem.mail.ac4.yahoo.com [76.13.13.41]) by core3.amsl.com (Postfix) with SMTP id DCF7D3A6840 for ; Mon, 12 Oct 2009 20:16:32 -0700 (PDT) Received: (qmail 45973 invoked from network); 13 Oct 2009 03:16:26 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp102.prem.mail.ac4.yahoo.com with SMTP; 12 Oct 2009 20:16:26 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: 41Icn_YVM1kMBxRQR3xO1gFfy6QiQ_nZBfsJygLj3LBlmVS65pnYNqtEJXysa1KeF5fXfT2ljSdb6zWt.nIR_9fcy9KjcZ50Dl__Nh.bgMuK8dDlkcEqcbN7zphfV6JlN22E12Rwh.8g5f2q7ON3ArnwgrUkSRaNzNnOUW8WisF01TKhbL13LkWtaOMP1PUYLlSLRwVZnVgzWX85Wfa_WtBCpcc._xc1RKUZmhiFqFHXVYAR9rKFhEGf.xJbS7Wzxn3.jXHb8msvxYihVRUxclWOCJskpKaEX80ksfjYfUznebiTqXXhQT_iwn4MWGGYYvACMyVSBfUDmq88_TnZsek61uGTY1rI9jHiedqb_RPaQZRFfJhRthBd6g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD3F102.8010601@acm.org> Date: Mon, 12 Oct 2009 23:16:18 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 03:16:34 -0000 WG, Please do let us know what you are thinking w/ regard to the design Questions A, B, & C below. We hope to include your feedback into the next revision of the document, with FSM descriptions as well. Thanks, - RPL Authors As discussed at the interim meeting, implementer feedback has indicated that the RPL protocol as proposed appears complex, both in description and actual FSM. Our plan of action is to, by end of month, deliver a -04 that will contain actual (non-editorial) changes. The intent of this mail is a poll over a period of 2 weeks, to help design the functional changes. In this spirit, we would like the WG to work on the following questions: Question A: Should RPL make use of the currently proposed local repair mechanism (DAG splitting and merging)? [NO implies that DAG repairs shall be coordinated globally with the use of DAG Sequence Number; the related mechanisms are to be expanded for -04] Question B: Should RPL make use of a hold-up timer and related states/procedures to reduce churn by coordinating the DAG merge? [NO implies RPL allows nodes to move (jump) between DAGs with little coordination to reduce complexity of specification/ implementation (perhaps w/ Optional hold-up mechanism)]. Question C: Should RPL make use of a hold-down timer and related states/procedures to limit flapping when removing DAG Parents / leaving DAGs [NO implies RPL allows nodes to freely remove/add DAG Parents as and when they are able in order to reduce complexity of specification/implementation (perhaps w/ Optional hold-down mechanism). WG, we expect that this thread will contain a lot of interesting related discussion, but in your comments please do also be sure to try and address the initial questions A, B, and C so as to help us better capture the WG position on these issues. Please note that A, B, and C are to some degree orthogonal, e.g. `No Local Repair' to Question A does not necessarily imply a particular disposition toward the Hold-Up mechanism in Question B. Thanks, RPL Authors Some examples, derived from the present draft, are provided below: ------------------------------------------------------------------------ Example: Local Repair with Hold-Up state : : : : : : (A) (A) (A) |\ | | | `-----. | | | \ | | (B) (C) (B) (C) (B) | | \ | | `-----. | | \ (D) (D) (C) | | | (D) -1- -2- -3- Figure 1: DAG Maintenance Consider the example depicted in Figure 1-1. In this example, Node (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is also an undirected sibling link between Nodes (B) and (C). In this example, Node (C) may safely forward to Node (A) without creating a loop. Node (C) may not safely forward to Node (D), contained within it's own sub-DAG, without creating a loop. Node (C) may forward to Node (B) in some cases, e.g. the link (C)->(A) is temporarily unavailable, but with some chance of creating a loop (e.g. if multiple nodes in a set of siblings start forwarding `sideways' in a cycle) and requiring the intervention of additional mechanisms to detect and break the loop. Consider the case where Node (C) hears a RA-DIO message from a Node (Z) at a lesser rank and superior position in the DAG than node (A). Node (C) may safely undergo the process to evict node (A) from its DAG parent set and attach directly to Node (Z) without creating a loop, because its rank will decrease. Now consider the case where the link (C)->(A) becomes nonviable, and node (C) must move to a deeper rank within the DAG: o Node (C) must first detach from the DAG by removing Node (A) from its DAG parent set, leaving an empty DAG parent set. Node (C) becomes the root of its own floating, less preferred, DAG. o Node (D), hearing a modified RA-DIO message from Node (C), follows Node (C) into the floating DAG. This is depicted in Figure 1-2. In general, any node with no other options in the sub-DAG of Node (C) will follow Node (C) into the floating DAG, maintaining the structure of the sub-DAG. o Node (C) hears a RA-DIO message from Node (B) and determines it is able to rejoin the grounded DAG by reattaching at a deeper rank to Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in the Hold-Up state) to coordinate this move. o The timer expires and Node (C) adds Node (B) to its DAG parent set. Node (C) has now safely moved deeper within the grounded DAG without creating any loops. Node (D), and any other sub-DAG of Node (C), will hear the modified RA-DIO message sourced from Node (C) and follow Node (C) in a coordinated manner to reattach to the grounded DAG. The final DAG is depicted in Figure 1-3 ------------------------------------------------------------------------ Example: Global Repair with Sequence Number / No Held-Up State : : : : : : (A) (A) (A) |\ | | | `-----. | | | \ | | (B) (C) (B) (C) (B) | \ | `-----. | \ (D) (D) (C) (D) -1- -2- -3- Figure 2: DAG Maintenance Consider the example depicted in Figure 2-1, similar to that depicted in Figure 1. Let there be a sequence number associated with the DAG, as originated from the DAG root, with value N. Initially all nodes have received DAG Sequence Number N. The following example offers one possible Global Repair scenario to give a high level idea, please note that there are details that would remain to be worked out if the WG heads in this direction. Now consider the case where the link (C)->(A) becomes nonviable, and node (C) must move to a deeper rank within the DAG: o Node (C) must first detach from the DAG by removing Node (A) from its DAG parent set, leaving an empty DAG parent set. At this point Node (C) is not associated with any DAG [TBD -- Alternately Node (C) remains associated with the DAG at rank infinity]. o Node (D) may possibly learn that Node (C) is no longer associated with any DAG and itself becomes unassociated [TBD Node (D) may also retain a sub-DAG relationship with Node (C)]. Let Node (C) and (D) both be free from any DAG, but remember the Sequence Number N associated with their original DAG. This is depicted in Figure 2-2. o Node (C) and (D) will now be willing to reattach to the original DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering connectivity to the original DAG and advertising a sequence number N+1. Since Node (C) and (D) are no longer members of the original DAG, only a node who is still a member of the original DAG may possibly present the sequence number N+1. Such a node who presents N+1 must clearly have another path to the DAG root other than via (C) and (D) and thus may offer a loop-avoiding attachment point. o [TBD] The DAG Root may periodically issue sequence number increments, causing the issue of N+1 o [TBD] The broken link (C)->(A) may be detected through some other means, and signalled to or cause a trigger at the DAG Root, causing the issue of N+1 o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and determine it is able to rejoin the original DAG by immediately reattaching j to Node (B) (No hold-up state in this example. The DAG is now as depicted in Figure 2-3 o Node (C) may then subsequently send RA-DIO with DAG Sequence number N+1, allowing Node (D) to reattach (not depicted). ------------------------------------------------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Oct 12 20:49:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7B133A6828 for ; Mon, 12 Oct 2009 20:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sm0aD881poM1 for ; Mon, 12 Oct 2009 20:49:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 617973A6783 for ; Mon, 12 Oct 2009 20:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3546; q=dns/txt; s=amsiport01001; t=1255405759; x=1256615359; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20reliability=20metrics=20for=20digital=20rad ios|Date:=20Tue,=2013=20Oct=202009=2005:49:15=20+0200 |Message-Id:=20<9567FCFF-8110-4699-99DA-13D486C28F5B@cisc o.com>|To:=20Richard=20Kelsey=20|Cc:=20roll@ietf.org|Mime-Version:=201.0=20(Apple=20Mess age=20framework=20v936)|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<878wfgbse1.fsf@kelsey-ws.hq.ember.com> |References:=20<87iqeobr00.fsf@kelsey-ws.hq.ember.com>=20 <2863E9BF-442B-4F7C-8415-1BE4192DE977@cisco.com>=20<878wf gbse1.fsf@kelsey-ws.hq.ember.com>; bh=ykw8dW+X/jFjBgtjLv8vkWLhTCsEOls3N7bl1Z5i+/0=; b=j5h5eRl9nDlbvSXxpExf3huglWdqpDUTAx8BQ+L26JTDayxwmrhAgfdI gK1xj4mursOOdaphb/jvEg8/9eamO/9VG/1UBpop39q/J44z7BqPSAed1 Fjjsl5apP7JWgQfn7+hBDHG0/pAOs72jbfSKbw0wiAjS6IJ/n9KzYGdLs I=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUAANGV00qQ/uCWe2dsb2JhbACbDAEBFiQGozWJDwiOL4JFCIFgBA X-IronPort-AV: E=Sophos;i="4.44,549,1249257600"; d="scan'208";a="51596516" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 03:49:17 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D3nHMU004657; Tue, 13 Oct 2009 03:49:17 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 05:49:16 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 05:49:16 +0200 Message-Id: <9567FCFF-8110-4699-99DA-13D486C28F5B@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <878wfgbse1.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 05:49:15 +0200 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <2863E9BF-442B-4F7C-8415-1BE4192DE977@cisco.com> <878wfgbse1.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 03:49:16.0115 (UTC) FILETIME=[22AA9230:01CA4BB8] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 03:49:18 -0000 Hi Richard, On Oct 12, 2009, at 4:26 PM, Richard Kelsey wrote: > JP, > > From: JP Vasseur > Date: Mon, 12 Oct 2009 14:46:18 +0200 > >> Below is a discourse on the reliability characteristics of >> 802.15.4 and similar digital radios and what this means for >> link metrics. Even if the goal is to maximize something >> other than reliability, you still need the links to be >> reasonably reliable in order to reduce churn and because no >> matter what the metric, broken routes have little utility. > > Yes, just to make sure that we are in line, there are two > orthogonal aspects here: > 1) Link UP/DOWN: if indeed, the link quality crosses some threshold > it can be put in DOWN state locally by the node > 2) If the Link stays in DOWN state for some period of time, the > node may decide to update the metrics in its RA-DIO. > > My point is that the key metric for reliability is not the > RTX for a message right now, or any similar metric, but an > estimate of the stability of the link itself. We need to > preferentially use stable links. > > This is independent of what a node does when a link actually > does stop working. > Completely agreeing with you. >> Non-radio links, or other types of radios, will have very >> different characteristics. This may make it difficult to >> have a good relibility metric that is independent of the >> link layer. > > Yes but ... RPL is L3 thus we want path to be calculated > according the link reliability (and I think that we all > agree on this requirement), this is what we need to > do. And I agree, this is not easy, the idea is to have a > good enough way to abstract the link reliability using a > single metric. The way to compute that metric is > implementation specific and L2 dependent, which is fine. > > There may not be a single metric that we can use. In > particular, for 802.15.4 radios, both stability and > latency/power must be taken into account. We have to > strongly prefer links that are stable (to avoid churn) and > links between always-on devices (to minimize battery use and > latency). These may be specific to 802.15.4, but they are > the overriding concerns for those networks. I do not see > how they can be collapsed into a single value. A single > metric is possible, but it will likely have to contain > distinct stability and power/latency values. Again agreeing ... and the metric ID is specifying a set of metrics. In any case, applications will require different metric according to the OF and an OF may require multiple metrics. > > Should we try to use the ETX and couple it with filtering > to get the result of distinguishing OK links with Good > links ? > > I do not see how ETX can capture the desired information. > ETX averaged over the short term can't measure long term > stability. ETX averaged over the long term can't tell > you which links are currently usable. I am not sure what > you mean by 'filtering' here. I meant two things: 1) There are many ways to compute the ETX (implementation specific) 2) Short transient issues may not have to be captured by the ETX: some transient events may be filtered out by a node. What is your preference in term of reliability metric ? Thanks. JP. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jhui@archrock.com Mon Oct 12 22:09:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B403A68F0 for ; Mon, 12 Oct 2009 22:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbOlfGjkDKBj for ; Mon, 12 Oct 2009 22:09:53 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 0AF9E3A6818 for ; Mon, 12 Oct 2009 22:09:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 53774AF90F; Mon, 12 Oct 2009 22:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y98iFCduo5c1; Mon, 12 Oct 2009 22:09:49 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-110-10.dsl.pltn13.pacbell.net [71.142.110.10]) by mail.sf.archrock.com (Postfix) with ESMTP id 83B61AF91A; Mon, 12 Oct 2009 22:09:49 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87aazwbwnt.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 12 Oct 2009 22:09:48 -0700 References: <6A2A459175DABE4BB11DE2026AA50A5D6152BA@XMB-AMS-107.cisco.com> <87ab00l3mp.fsf@kelsey-ws.hq.ember.com> <54371184-51BD-41C8-AF29-7739DA2267D9@cs.stanford.edu> <87aazwbwnt.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection and recovery X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 05:09:55 -0000 On Oct 12, 2009, at 5:53 AM, Richard Kelsey wrote: > From: Philip Levis > Date: Sat, 10 Oct 2009 12:11:54 -0700 > > Assuming that the sequence number space is stable, the problem > will of > course work itself out. But in some initial tests, we found that > loops > such as these (note this is just two nodes, when using sequence > number > increments you can have routes with very high stretch while the > network reconfigures) could significantly increase the cost > (transmissions/delivery). > > Hmm. We have never had a problem with this. Normally we > see the sequence number updates travel faster along the > better routes, which are the faster/more reliable paths, > which in turn causes the updates to settle quickly. > I would guess that the difference comes down to timing. > The longer the intervals between RA-DIO transmissions, the > longer it will take things to settle down. Out of curiosity, > what was the minimum trickle delay in your tests? Using sequence numbers to establish an event-horizon is, of course, not new in the wireless space. DSDV proposed using sequence numbers for the purpose of avoiding loops 15 years ago. The difference in opinion here may come from subtle differences in how we view the sequence number propagation - these differences can have a fairly significant change in the overall behavior. In particular, one of the criticisms often associated with the use of sequence numbers it that they encourage long, unstable links. This, of course, does occur when naively using the first received beacon of the latest sequence number to select the primary parent. Doing so often chooses routes that utilize long but intermittent links - possibly resulting in high stretch and/or churn. Conservatively allowing sequence numbers to only propagate along "good" links but not "okay" links may produce more stable paths, but requires other mechanisms to utilize the "long" links. I do think sequence numbers can be powerful for loop avoidance and dealing with the count-to-infinity issue, but I also think that sequence number state must be refreshed periodically for the mechanism to remain simple and work well (a significant cost for some networks). I do believe count-to-infinity is a significant issue we should be concerned about, more so because of the energy cost rather than convergence time. So far, the loop detection/recovery mechanisms don't really solve the count-to-infinity problem. -- Jonathan Hui From pthubert@cisco.com Tue Oct 13 00:19:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF533A6923 for ; Tue, 13 Oct 2009 00:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.196 X-Spam-Level: X-Spam-Status: No, score=-9.196 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG2STXId70kc for ; Tue, 13 Oct 2009 00:19:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 099F53A6831 for ; Tue, 13 Oct 2009 00:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=14399; q=dns/txt; s=amsiport01001; t=1255418342; x=1256627942; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20RPL=20Design=20Questions |Date:=20Tue,=2013=20Oct=202009=2009:16:29=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66E0AD@XM B-AMS-107.cisco.com>|To:=20"Tim=20Winter"=20,=20"ROLL=20WG"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<4AD3F102.8010601@acm.org>|References:=20 <4AD3F102.8010601@acm.org>; bh=h1ciePHixBvUhnxQDSog3BNN/+Q8druPYfnmqtkskDg=; b=Ii0/tYhfbgTyTcT6Tbvp2HmcFAt8u9KUgCrh3Qa+8vT2kGs8OmoxlELJ dGduW6tvO0ltZ8x59AA4BBt3Idqmy9jnmkMkg/G7bxgE0Xxrmnbmb3SfB dGvQbGlS4zUnqQmruRmxClaXZpUqPQN9Gd7m7SoLl4rzcUVpmlvUEfiZu k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUAAP/G00qQ/uCWe2dsb2JhbACbDAEBFiQGoyuXXIQtBA X-IronPort-AV: E=Sophos;i="4.44,550,1249257600"; d="scan'208";a="51606740" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 07:19:00 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D7J0i7010132; Tue, 13 Oct 2009 07:19:00 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:19:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 09:16:29 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E0AD@XMB-AMS-107.cisco.com> In-Reply-To: <4AD3F102.8010601@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Design Questions Thread-Index: AcpLs5Tx2qwYAp7fTHKnpZ7vNgEWpQAGfPIQ References: <4AD3F102.8010601@acm.org> From: "Pascal Thubert (pthubert)" To: "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 13 Oct 2009 07:19:00.0437 (UTC) FILETIME=[6F81B850:01CA4BD5] Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 07:19:03 -0000 Hi: I think Tim did a great job at keeping the question text simple. Thinking about his own answer on this, one might wonder what the actual cost of things is and how things are related. The good news is that as far as I can see, the 3 items of the poll are not related: - one could bypass the DAG hop Timer mechanism and still allow the split/merge mechanism that is used for loop avoidance. The result will probably be more runtime churn and more battery consumption. - Alternatively one could ignore the split/merge and stay there, simply advertising infinity to poison the broken path, and yet, the DAG hop timer would be useful to avoid churn as the new DAG is constructed to restore connectivity. - and the hold down is orthogonal, rather related of the validation process that takes place before a parent can be used at all. Even better, it appears that a network that incorporates mixed behaviors still works correctly. If I'm correct on that, then it could be possible to make those things optional, like having a fully capable node and a more constrained node's behavior, and then enable a policies in the former to more or less act as the latter. The other aspect of the question is the real cost associated to the listed items. Question A:=20 ------------ Feature benefit: When this mechanism is in place, a DAG can detach and still enable local (P2P) connectivity. There are use cases for that, though not really obvious in our requirement drafts. So obviously we'd be losing that sort of connectivity if the mechanism Implementation cost: When a node detaches, it should in theory keep some history of its previous DAGs as long as those DAGs live, so as to never jump back in the same DAG, same sequence but at a higher rank. That would be perfect loop avoidance. But that's not what the spec does. The spec attempts to mark the wrong landing sites by route poisoning and then allows any jump after a reasonable time. So the implementation cost at the end of the day is one timer, and a bit of logic to decide whether that timer should be armed at all. The current text allows overloading the DAG Hop Timer for that purpose (that's Q 2). Question B: Feature benefit: This is all about churn. There are occasions like a new sequence or a DAG accident (new root inserted or removed, split/merge...) where a DAG and sometimes neighboring nodes are impacted. If we leave it to chance, nodes will reposition a number of times before things settle, causing churn and battery depletion. This timer delays things and forces the changes to spread like a wave in one pass from the root out. Implementation cost: In theory that's one timer per parent that this node wants to jump to. In terms of implementation, this can be reduced to one timer per DAG that the node might want to jump to, and even further reduced to one timer at all if the implementation only keeps track of the most preferred DAG onto which it could jump. Note that the doc allows the node to use the same timer for Q A). The feature also requires to pass the DAG base period in the DIO. Question C)=20 Feature benefit: A node that has poor history is blacklisted. This prevents it to be reconsidered as a parent for a configurable period of time. This method avoid periodic churn and black out, or at least makes that period a lot longer. Implementation cost: In theory one timer per blacklisted node, and some data structure per blacklisted node. In practice, an implementation can use a single periodic timer and a list of the blacklisted nodes. It can for instance maintain a counter per listed node that is incremented at each tick. When the increment reaches a threshold, the node is removed from the blasklist. My vote is YES to all the questions. Keep them in the base spec.=20 And allow for a fallback behavior in the real constrained devices if that can cohabit as I think it does. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter >Sent: mardi 13 octobre 2009 05:16 >To: ROLL WG >Subject: [Roll] RPL Design Questions > >WG, > >Please do let us know what you are thinking w/ regard to the design >Questions A, B, & C below. We hope to include your feedback into the next >revision of the document, with FSM descriptions as well. > >Thanks, > >- RPL Authors > > > > As discussed at the interim meeting, implementer feedback has > indicated that the RPL protocol as proposed appears complex, both in > description and actual FSM. > > Our plan of action is to, by end of month, deliver a -04 that will > contain actual (non-editorial) changes. The intent of this mail is > a poll over a period of 2 weeks, to help design the functional > changes. > > In this spirit, we would like the WG to work on the following > questions: > > Question A: Should RPL make use of the currently proposed local > repair mechanism (DAG splitting and merging)? > > [NO implies that DAG repairs shall be coordinated globally with > the use of DAG Sequence Number; the related mechanisms are to > be expanded for -04] > > Question B: Should RPL make use of a hold-up timer and related > states/procedures to reduce churn by coordinating the DAG merge? > > [NO implies RPL allows nodes to move (jump) between DAGs with > little coordination to reduce complexity of specification/ > implementation (perhaps w/ Optional hold-up mechanism)]. > > Question C: Should RPL make use of a hold-down timer and related > states/procedures to limit flapping when removing DAG Parents / > leaving DAGs > > [NO implies RPL allows nodes to freely remove/add DAG Parents > as and when they are able in order to reduce complexity of > specification/implementation (perhaps w/ Optional hold-down > mechanism). > > WG, we expect that this thread will contain a lot of interesting > related discussion, but in your comments please do also be sure to > try and address the initial questions A, B, and C so as to help us > better capture the WG position on these issues. Please note that A, > B, and C are to some degree orthogonal, e.g. `No Local Repair' to > Question A does not necessarily imply a particular disposition toward > the Hold-Up mechanism in Question B. > > Thanks, > > RPL Authors > > > > Some examples, derived from the present draft, are provided below: > > ------------------------------------------------------------------------ > > Example: Local Repair with Hold-Up state > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | | \ > | | `-----. > | | \ > (D) (D) (C) > | > | > | > (D) > > -1- -2- -3- > > > Figure 1: DAG Maintenance > > Consider the example depicted in Figure 1-1. In this example, Node > (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of > Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is > also an undirected sibling link between Nodes (B) and (C). > > In this example, Node (C) may safely forward to Node (A) without > creating a loop. Node (C) may not safely forward to Node (D), > contained within it's own sub-DAG, without creating a loop. Node (C) > may forward to Node (B) in some cases, e.g. the link (C)->(A) is > temporarily unavailable, but with some chance of creating a loop > (e.g. if multiple nodes in a set of siblings start forwarding > `sideways' in a cycle) and requiring the intervention of additional > mechanisms to detect and break the loop. > > Consider the case where Node (C) hears a RA-DIO message from a Node > (Z) at a lesser rank and superior position in the DAG than node (A). > Node (C) may safely undergo the process to evict node (A) from its > DAG parent set and attach directly to Node (Z) without creating a > loop, because its rank will decrease. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. Node (C) > becomes the root of its own floating, less preferred, DAG. > > o Node (D), hearing a modified RA-DIO message from Node (C), follows > Node (C) into the floating DAG. This is depicted in Figure 1-2. > In general, any node with no other options in the sub-DAG of Node > (C) will follow Node (C) into the floating DAG, maintaining the > structure of the sub-DAG. > > o Node (C) hears a RA-DIO message from Node (B) and determines it is > able to rejoin the grounded DAG by reattaching at a deeper rank to > Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in > the Hold-Up state) to coordinate this move. > > o The timer expires and Node (C) adds Node (B) to its DAG parent > set. Node (C) has now safely moved deeper within the grounded DAG > without creating any loops. Node (D), and any other sub-DAG of > Node (C), will hear the modified RA-DIO message sourced from Node > (C) and follow Node (C) in a coordinated manner to reattach to the > grounded DAG. The final DAG is depicted in Figure 1-3 > > > ------------------------------------------------------------------------ > > Example: Global Repair with Sequence Number / No Held-Up State > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | \ > | `-----. > | \ > (D) (D) (C) > > > > (D) > > -1- -2- -3- > > > Figure 2: DAG Maintenance > > Consider the example depicted in Figure 2-1, similar to that depicted > in Figure 1. Let there be a sequence number associated with the DAG, > as originated from the DAG root, with value N. Initially all nodes > have received DAG Sequence Number N. The following example offers one > possible Global Repair scenario to give a high level idea, please > note that there are details that would remain to be worked out if the > WG heads in this direction. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. At this > point Node (C) is not associated with any DAG [TBD -- Alternately > Node (C) remains associated with the DAG at rank infinity]. > > o Node (D) may possibly learn that Node (C) is no longer associated > with any DAG and itself becomes unassociated [TBD Node (D) may > also retain a sub-DAG relationship with Node (C)]. Let Node (C) > and (D) both be free from any DAG, but remember the Sequence > Number N associated with their original DAG. This is depicted in > Figure 2-2. > > o Node (C) and (D) will now be willing to reattach to the original > DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering > connectivity to the original DAG and advertising a sequence number > N+1. Since Node (C) and (D) are no longer members of the original > DAG, only a node who is still a member of the original DAG may > possibly present the sequence number N+1. Such a node who > presents N+1 must clearly have another path to the DAG root other > than via (C) and (D) and thus may offer a loop-avoiding attachment > point. > > o [TBD] The DAG Root may periodically issue sequence number > increments, causing the issue of N+1 > > o [TBD] The broken link (C)->(A) may be detected through some other > means, and signalled to or cause a trigger at the DAG Root, > causing the issue of N+1 > > o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and > determine it is able to rejoin the original DAG by immediately > reattaching j to Node (B) (No hold-up state in this example. The > DAG is now as depicted in Figure 2-3 > > o Node (C) may then subsequently send RA-DIO with DAG Sequence > number N+1, allowing Node (D) to reattach (not depicted). > > ------------------------------------------------------------------------ > >_______________________________________________ >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 hrogge@googlemail.com Tue Oct 13 01:11:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFB628C0E7 for ; Tue, 13 Oct 2009 01:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KzWTd5N4HBC for ; Tue, 13 Oct 2009 01:11:16 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id D6FB63A677C for ; Tue, 13 Oct 2009 01:11:15 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so2301617eye.51 for ; Tue, 13 Oct 2009 01:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=QO/1LFQicKlEW3Pcwgc+GeJKVtVEPiIJ3CAvtEziXVQ=; b=M2GnQgS9vCUgx6yfgiOJUzYqb3DuU7ylkqy7DwYhYxL74pUh3sLvJ5k8w8uw4R0xyS raXWTWQqKuXZ2BrXdnUF/rZwB9Y+OsYgtYfttW/9ou/7I/ePO5/R140byfQ0aOIdP2NM OoZnNVr0hA40W2GEBnao/2onMy14ZBXTi41Fg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=D7HsoTxwFV6PJWH0W6YwUHxpwPQx1m8WRYZlUUUl3s/2TtW4547nQ4ghijtaPz3XKR xZiAclrfCmtrZmjeZ/ZlO1D2l3KfXPlB32Kq17wvhv2cZpM0ESjxifB7robVpP6YprXX MY15V7nopDH+2JBXjDKbRpEzeBgXSCNU+mMWY= Received: by 10.210.2.16 with SMTP id 16mr8221372ebb.31.1255421473630; Tue, 13 Oct 2009 01:11:13 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 10sm2474578eyd.30.2009.10.13.01.11.12 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Oct 2009 01:11:12 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Tue, 13 Oct 2009 10:11:05 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> In-Reply-To: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1646028.sfSsZTNQtT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910131011.11371.hrogge@googlemail.com> Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 08:11:17 -0000 --nextPart1646028.sfSsZTNQtT Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Am Dienstag 13 Oktober 2009 04:48:34 schrieb JP Vasseur: > > I am saying that when using wireless links, a node should be aware > > that his communication could interfere with other communication. > > Less powered is the transmission signal, less noise is seen by > > neighbours. > > A low powered node will also need less energy to communicate in a > > less noisy environnement. >=20 > Bear in mind, that you do not know this environment so this may lead > you to an incorrect conclusion. > The real metric is the link reliability, which reflect the properties > of the environment. We have a similar discussion about metrics in the Manet-WG. Different kind = of=20 metrics seem to be useful in different enviroments. Signal strength seem to= be=20 a good indicator for a "bad" link, but in praxis (especially with incorrect= =20 signal strengt estimation of consumer hardware) sometimes links with low=20 signal strength are better than others with higher signal strength. On the= =20 other side ETX might be easy to implement on any kind of layer-2 hardware, = but=20 is only a rough estimation of the "link quality" which does not consider lo= ng=20 time link statistics (stability, variance, ...) or transmission speed. Metrics for wireless networks are still being researched without "final=20 perfect metric" in sight, so ROLL should keep metric IDs for futher metric= =20 types. But you should put at least ONE easy to implement metric into the ba= sic=20 WG document. The problem of OLSRv1 (as an example) was that it did NOT incl= ude=20 any metric except hopcount in it's basic document, so most people using OLS= R=20 for their projects (who do NOT research metrics for mesh networks) just use= =20 hopcount metrics and think that OLSR does not work. So the question about a metric for ROLL should not only be "what's the best= =20 metric for our networks" but "what metric is simple enough that everyone ca= n=20 implement it on any kind of hardware". > > As said somewhere else, the final metric should be a computation of > > different metrics. >=20 > This is the objective function. Yes, a good metric "post processing" (including long term statistical analy= sis=20 of a links different metrics) can be a good thing to enhance the quality of= =20 the "link cost" estimation. Henning Rogge --nextPart1646028.sfSsZTNQtT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEUEABECAAYFAkrUNh8ACgkQcenvcwAcHWdK4QCYyKkJ/SbM4CeeT5o/pDl4OVTA LwCeO9hTuK5oC0W4qz0t3ksAvl3K+J0= =DYet -----END PGP SIGNATURE----- --nextPart1646028.sfSsZTNQtT-- From abr@sdesigns.dk Tue Oct 13 02:12:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E703A67F1 for ; Tue, 13 Oct 2009 02:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfseH3eclRcg for ; Tue, 13 Oct 2009 02:12:09 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id D5C6D3A67A6 for ; Tue, 13 Oct 2009 02:12:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 11:12:09 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429B26@zensys17.zensys.local> In-Reply-To: <1AA77E89-F83F-4BFD-92FF-657E4C9B9739@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Metric ID Thread-Index: AcpLMaFx0qU67zOBSIu533J0boXUAgAsZ8tQ References: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu><4ACF43CC.2020303@acm.org> <1AA77E89-F83F-4BFD-92FF-657E4C9B9739@cisco.com> From: "Anders Brandt" To: "JP Vasseur" , "Tim Winter" Cc: roll@ietf.org Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 09:12:10 -0000 > Mukul Goyal wrote: >> I think both latency and reliability are important metrics. Same for me. One word of warning on the energy discussion: It seems like the assumption is that the routing protocol should manage the number of transmitted packets in order to ensure that the energy consumption is distributed among more nodes. There is however a caveat here: >From our experience, a radio uses energy. Period. Receiving uses the same as transmitting - the difference is just which amplifiers use the energy. Thus, the way to use less energy is to use the radio less - i.e. sleep some of the time. Which again translates into higher latency to reach such nodes. Obviously, there is something to save, since a radio may quickly determine if it is the intended recipient of a packet and return to sleep again OR receive the entire packet and stay awake to forward the packet on to another node in the network. Thus, what I am trying to say is: Unless the lower layers have a smart way of quickly returning to sleep (which some technologies have) the routing protocol will keep all nodes awake within direct range - and they will all use power for listening = =3D> nothing gained from distributing the traffic. Can battery-powered 802.15.4. nodes quickly return to sleep if they are not the intended recipient? If not, the energy metric may be rather useless (?) Cheers, Anders =20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 12. oktober 2009 13:46 To: Tim Winter Cc: roll@ietf.org Subject: Re: [Roll] RPL Metric ID On Oct 9, 2009, at 4:08 PM, Tim Winter wrote: > Mukul Goyal wrote: >> I think both latency and reliability are important metrics. >> > +1 > We have a good consensus to have both latency and reliability. We now need to agree on the units. Unit for latency ? Unit for ETX (I propose to use the ETX): thoughts ? >> I am sort of negative on using memory/CPU availability as metric or=20 >> constraint. They seem like local factors to me. If a node is running=20 >> low on memory/CPU, it can simply not participate in routing. >> >> > Exposing an exaggerated rank might also be an option. > Indeed, although we have planned to use an Overload bit since we may not want all nodes to trigger a DAG recomputation but only to not send traffic until the bit is cleared. Cheers. JP. > -Tim >> Thanks >> Mukul >> ----- Original Message ----- >> From: "JP Vasseur" >> To: "IETF ROLL" >> Cc: "Kris Pister" >> Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada=20 >> Central >> Subject: [Roll] RPL Metric ID >> >> >> Dear all, >> >> We would appreciate your feed-back on RPL routing metrics. >> >> Now that RPL is stabilizing it is time to move forward with the=20 >> METRIC I-D. The next revision will be a major one, with packet=20 >> encoding, processing rules, etc. >> >> We discussed and agreed some time ago on several links and nodes=20 >> metrics (also required according to our requirement IDs). >> >> Still, there are a few metrics for which we would like to know=20 >> whether you think that they should be specified. >> >> 4.2. Latency >> >> >> As with throughput, the latency of many LLN MAC sub-layers can =20 >> be varied over many orders of magnitude, again with a =20 >> corresponding change in current consumption. Some LLN MACs will =20 >> allow the latency to be adjusted globally on the subnet, or on a =20 >> link-by-link basis, or not at all. Some will insist that it be =20 >> fixed for a given link, but allow it to be variable from link to =20 >> link. For efficient operation, nodes must be able to report the =20 >> range of latency that their links can handle, and the currently =20 >> available latency. >> >> 4.3. Link reliability >> >> In LLNs, link reliability is degraded by external interference =20 >> and multi-path interference. Multipath typically affects both =20 >> directions on the link equally, whereas external interference is =20 >> sometimes uni- directional. Time scales vary from milliseconds =20 >> to days, and are often periodic and linked to human activity. =20 >> Packet error rate can generally be measured directly, and other =20 >> metrics (e.g. bit error rate, mean time between failures) are =20 >> typically derived from that. >> >> In addition: >> >> Node Memory resources: >> >> Memory is a critical node resources in presence of constrained nodes. >> Is there a need to report node memory resources as a routing=20 >> metric/constraint ? >> >> Node CPU resources: CPU duty cycle for virtually all LLN applications >> to date is well below 10%, and the trend in low power embedded=20 >> systems is to more capable processors rather than less. >> Computational speed is not expected to be a limiting factor in=20 >> routing in LLNs. Is there a need to report node CPU resources as a=20 >> routing metric/constraint ? >> >> Link Security metrics >> >> Thanks for your feed-back. >> >> JP, Mijeon, Kris. _______________________________________________ >> 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Tue Oct 13 02:54:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF6B3A680B; Tue, 13 Oct 2009 02:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rf+MqQFtaPQF; Tue, 13 Oct 2009 02:54:19 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 2A4C03A692B; Tue, 13 Oct 2009 02:54:18 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4BEB.224B6008" Date: Tue, 13 Oct 2009 11:54:19 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429B28@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLsFzQT0z2VyA0T/GPSf4Daz+g0wAOYdlQ References: From: "Anders Brandt" To: "JP Vasseur" , Cc: roll-bounces@ietf.org, IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 09:54:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4BEB.224B6008 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Needless to say I also consider myself one of those people... =20 As discussed in the interim meeting, p2p mesh support is actually required in 50% of the requirement drafts forming the base of this working group. In IETF terms, Nodes MUST be able to use (somewhat optimized) p2p to communicate internally and MAY need to talk to an LBR. =20 - Anders ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 13. oktober 2009 04:53 To: Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; IETF ROLL Subject: Re: [Roll] NA to transport DAO On Oct 12, 2009, at 11:21 PM, Jerald.P.Martocci@jci.com wrote: I guess I am one of those people that think that other 6LoWPAN nodes must participate in RPL. Unless I am missing something RPL is the only game in town regarding meshing of wireless sensors. If they are not in RPL is there another means that they can use to form mesh connectivity to get to the LBR?=20 =09 You interpretation is of course correct. JP. Jerry=20 =09 =09 =09 =09 =09 =09 Michael Richardson =20 Sent by: roll-bounces@ietf.org=20 10/12/2009 04:13 PM=20 To IETF ROLL =09 cc =09 Subject Re: [Roll] NA to transport DAO=09 =09 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =09 =09 >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > writes: Pascal> We are in perfect line. At the moment, RPL would impose Pascal> NS/NA between 6LoWPAN routers to expose the host routes. =09 I have just read 6lowpan-nd-06.txt =09 Some things immediately jump out at me: 1) small packets are much more common, so DAOs may not fit into ND. 2) multicast is not assumed, so the Whiteboard is used. 3) nodes that are sleepy, are not going to be useful as members of an RPL DAG, so really, it's about RPL between the Edge Routers. =09 It seems to me therefore that the only nodes in a 6lowpan that can participate in a RPL DAG would be the edge router that runs a Whiteboard. =09 I think you capture this in your above sentence. I do not think that the 6LoWPAN routers will be speaking NR/NC between themselves along their "backbone", but I could be wrong. =09 I also think that some other people may be thinking that many more 6LoWPAN nodes will participate in RPL than just the edge routers. =09 - --=20 ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys =09 iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/ iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw=3D=3D =3DFpQB -----END PGP SIGNATURE----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =09 ------_=_NextPart_001_01CA4BEB.224B6008 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Needless to say I also consider myself one of = those=20 people...
 
As discussed in the interim meeting, p2p mesh = support is=20 actually required in 50% of the requirement drafts forming the base of = this=20 working group.
In IETF terms,
Nodes MUST be able to use (somewhat optimized) = p2p to=20 communicate internally and MAY need to talk to an = LBR.
 
- Anders

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur
Sent:=20 13. oktober 2009 04:53
To: = Jerald.P.Martocci@jci.com
Cc:=20 roll-bounces@ietf.org; IETF ROLL
Subject: Re: [Roll] NA to = transport=20 DAO



------_=_NextPart_001_01CA4BEB.224B6008-- From jvasseur@cisco.com Tue Oct 13 03:18:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FAC3A6945; Tue, 13 Oct 2009 03:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.11 X-Spam-Level: X-Spam-Status: No, score=-8.11 tagged_above=-999 required=5 tests=[AWL=-1.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhyTlWDOnDvS; Tue, 13 Oct 2009 03:18:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A906B3A680C; Tue, 13 Oct 2009 03:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=10136; q=dns/txt; s=sjiport06001; t=1255429086; x=1256638686; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20F wd:=20[recipe]=20Doodle=20poll:=20Smart=20Grid=20Bar=20Bo f=20at=20IETF=2076|Date:=20Tue,=2013=20Oct=202009=2012:17 :51=20+0200|Message-Id:=20|To:=20IETF=20ROLL=20,=20 6lowpan=20<6lowpan@ietf.org>,=206lowapp@ietf.org|Cc:=20re cipe@ietf.org|Mime-Version:=201.0=20(Apple=20Message=20fr amework=20v936)|References:=20; bh=4zcA0TYmVcvWwkGS0XP+vFQYlZUG9xSvg90QHUDnLyQ=; b=nxkYlucTj3CZYyPXliLtslJ94LPQ+eUpborkemk+iNoVYrd0ScDrgB+4 39stIiSfOkFX7gwSICKnaXe/X2zpw5fU/TAH+dRVb5XnF82qgmQpL9VP3 gXlaowewPke7vnvpoEYTKI9TkX8UTSISD5g/ZAMusz9CZ5kslD5dwBKeF 0=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAHvw00qrR7Hu/2dsb2JhbACCJxUYu0iXbIQtBA X-IronPort-AV: E=Sophos;i="4.44,550,1249257600"; d="scan'208,217";a="408091713" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 10:18:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9DAI4sT026575; Tue, 13 Oct 2009 10:18:05 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:17:52 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:17:52 +0200 Message-Id: From: JP Vasseur To: IETF ROLL , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-156-96480763 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 12:17:51 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 10:17:52.0219 (UTC) FILETIME=[6C25B2B0:01CA4BEE] Cc: recipe@ietf.org Subject: [Roll] Fwd: [recipe] Doodle poll: Smart Grid Bar Bof at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 10:18:06 -0000 --Apple-Mail-156-96480763 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit A BAR BOF many of you should be interested in. Thanks. JP. Begin forwarded message: > From: "Polk, William T." > Date: October 13, 2009 3:45:52 AM CEDT > To: Fred Baker , David R Oran , > Richard Shockey , Russ Housley >, Leslie Daigle , Sean Turner , > Paul Hoffman , Henning Schulzrinne >, Phil Roberts , "peter@peter-dambier.de" >, "dcrocker@bbiw.net" , Hiroshi Esaki >, Michael Dillon , Brian E Carpenter >, Ralph Droms , Michael Dillon >, IESG IESG , IAB IAB , > "recipe@ietf.org" , Peny Yang > > Cc: "St. Pierre, James A." , "Dodson, > Donna F." , "Su, David H." > , "Golmie, Nada T." > Subject: [recipe] Doodle poll: Smart Grid Bar Bof at IETF 76 > > > Folks, > > I would like to organize a BAR BOF at IETF 76 in Hiroshima to > discuss the US Smart Grid effort. IETF protocols will be an > important component of a successful and evolutionary Smart Grid, and > NIST is looking to the IETF for leadership. To enable participation > by NIST/ITL Management, I would like to hold the BAR BOF either > Wednesday or Thursday night. > > NIST attendees will provide some background/history of the Smart > Grid efforts but the primary goal of this session is to determine > whether there is sufficient interest in the community to take on > work in this area. If there is interest, scoping of appropriate IETF > contributions, and strategies for organizing the response would also > be fruitful topic areas. > > I am sending this email directly to any IETFers that have (to my > knowledge) previously indicated interest in Smart Grid. I am also > sending this message to the IESG, IAB, recipe@ietf.org, and ipaction@nist.gov > email lists. Please feel free to forward this email to anyone else > that you think I may have missed. > > If you are interested in attending the BOF, please indicate your > preference using the following doodle poll: > > http://www.doodle.com/q5nusbhpqfnf75yh > > Thanks, > > Tim Polk > _______________________________________________ > recipe mailing list > recipe@ietf.org > https://www.ietf.org/mailman/listinfo/recipe --Apple-Mail-156-96480763 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable A BAR BOF many of you should be = interested = in.

Thanks.

JP.

Begin forwarded message:

From: = "Polk, William T." <william.polk@nist.gov>=
Date: October 13, 2009 3:45:52 AM = CEDT
To: Fred Baker <fred@cisco.com>, David R Oran = <oran@cisco.com>, Richard = Shockey <richard@shockey.us>, Russ = Housley <housley@vigilsec.com>, = Leslie Daigle <daigle@isoc.org>, Sean Turner = <turners@ieca.com>, Paul = Hoffman <paul.hoffman@vpnc.org>, = Henning Schulzrinne <hgs@cs.columbia.edu>, Phil = Roberts <roberts@isoc.org>, = "peter@peter-dambier.de" = <peter@peter-dambier.de>, = "dcrocker@bbiw.net" <dcrocker@bbiw.net>, Hiroshi = Esaki <hiroshi@wide.ad.jp>, Michael = Dillon <wavetossed@googlemail.com>= ;, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ralph Droms <rdroms@cisco.com>, Michael = Dillon <wavetossed@googlemail.com>= ;, IESG IESG <iesg@ietf.org>, = IAB IAB <iab@iab.org>, "recipe@ietf.org" <recipe@ietf.org>, Peny Yang = <peng.yang.chn@gmail.com>
Cc: "St. Pierre, James A." <james.st.pierre@nist.gov>,= "Dodson, Donna F." <donna.dodson@nist.gov>, = "Su, David H." <david.su@nist.gov>, "Golmie, = Nada T." <nada.golmie@nist.gov>
Subject: [recipe] Doodle poll: Smart Grid Bar = Bof at IETF 76


Folks,

= I would like to = organize a BAR BOF at IETF 76 in Hiroshima to discuss the US Smart Grid = effort.  IETF protocols will be an important component of a = successful and evolutionary Smart Grid, and NIST is looking to the IETF = for leadership. To enable participation by NIST/ITL Management, I would = like to hold the BAR BOF either Wednesday or Thursday night.

= NIST attendees will provide some background/history of the Smart Grid = efforts but the primary goal of this session is to determine whether = there is sufficient interest in the community to take on work in this = area. If there is interest, scoping of appropriate IETF contributions, = and strategies for organizing the response would also be fruitful topic = areas.

= I am sending this = email directly to any IETFers that have (to my knowledge) previously = indicated interest in Smart Grid.  I am also sending this message = to the IESG, IAB, recipe@ietf.org, and = ipaction@nist.gov email lists. =  Please feel free to forward this email to anyone else that you = think I may have missed.

If you are interested in attending the = BOF, please indicate your preference using the following doodle = poll:

=       http://www.doodle.com/q5nu= sbhpqfnf75yh

= Thanks,

= Tim Polk
= _______________________________________________
recipe mailing = list
recipe@ietf.org
https://www.ietf.or= g/mailman/listinfo/recipe

= --Apple-Mail-156-96480763-- From abr@sdesigns.dk Tue Oct 13 03:22:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E7B3A6855 for ; Tue, 13 Oct 2009 03:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FRT_LOLITA1=1.865] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPMsb9Fjf9NI for ; Tue, 13 Oct 2009 03:22:09 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 2116E3A6A1A for ; Tue, 13 Oct 2009 03:22:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 12:22:09 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01429B29@zensys17.zensys.local> In-Reply-To: <200910131011.11371.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ETX metric Thread-Index: AcpL3ME5awiYdCuTQwGhHoBUxSJVfwAEPzHg References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> <200910131011.11371.hrogge@googlemail.com> From: "Anders Brandt" To: "Henning Rogge" , Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 10:22:10 -0000 Henning Rogge wrote: >... So the question about a metric for ROLL should not only be "what's the best metric for our networks" but >"what metric is simple enough that everyone can implement it on any kind of hardware".=20 Good pragmatic approach to reality. >... On the other side ETX might be easy to implement on any kind of layer-2 hardware, but is only a rough >estimation of the "link quality" which does not consider long time link statistics (stability, variance, ...) >or transmission speed. I have seen other people on this thread indicating that RSSI measurements tell a rather polluted truth. This is also our experience. Translated to the real world, ETX information based on the number of received Acks from lower layers is a cheap and often sufficient metric. ETX actually could be a good candidate for a default metric working _FAIRLY_GOOD_ in most environments on most hardware platforms. - Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Henning Rogge Sent: 13. oktober 2009 10:11 To: roll@ietf.org Subject: Re: [Roll] ETX metric Am Dienstag 13 Oktober 2009 04:48:34 schrieb JP Vasseur: > > I am saying that when using wireless links, a node should be aware=20 > > that his communication could interfere with other communication. > > Less powered is the transmission signal, less noise is seen by=20 > > neighbours. > > A low powered node will also need less energy to communicate in a=20 > > less noisy environnement. >=20 > Bear in mind, that you do not know this environment so this may lead=20 > you to an incorrect conclusion. > The real metric is the link reliability, which reflect the properties=20 > of the environment. We have a similar discussion about metrics in the Manet-WG. Different kind of metrics seem to be useful in different enviroments. Signal strength seem to be a good indicator for a "bad" link, but in praxis (especially with incorrect signal strengt estimation of consumer hardware) sometimes links with low signal strength are better than others with higher signal strength. On the other side ETX might be easy to implement on any kind of layer-2 hardware, but is only a rough estimation of the "link quality" which does not consider long time link statistics (stability, variance, ...) or transmission speed. Metrics for wireless networks are still being researched without "final perfect metric" in sight, so ROLL should keep metric IDs for futher metric types. But you should put at least ONE easy to implement metric into the basic WG document. The problem of OLSRv1 (as an example) was that it did NOT include any metric except hopcount in it's basic document, so most people using OLSR for their projects (who do NOT research metrics for mesh networks) just use hopcount metrics and think that OLSR does not work. So the question about a metric for ROLL should not only be "what's the best metric for our networks" but "what metric is simple enough that everyone can implement it on any kind of hardware". > > As said somewhere else, the final metric should be a computation of=20 > > different metrics. >=20 > This is the objective function. Yes, a good metric "post processing" (including long term statistical analysis of a links different metrics) can be a good thing to enhance the quality of the "link cost" estimation. Henning Rogge From Adrian.Farrel@huawei.com Tue Oct 13 03:34:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A80673A68C7 for ; Tue, 13 Oct 2009 03:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9PBza6i9Ddm for ; Tue, 13 Oct 2009 03:34:22 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id C2BB03A68AE for ; Tue, 13 Oct 2009 03:34:22 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRG00DPY81BYD@usaga03-in.huawei.com> for roll@ietf.org; Tue, 13 Oct 2009 05:34:23 -0500 (CDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRG005RQ819U6@usaga03-in.huawei.com> for roll@ietf.org; Tue, 13 Oct 2009 05:34:23 -0500 (CDT) Date: Tue, 13 Oct 2009 11:34:15 +0100 From: Adrian Farrel To: roll@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: "Polk, William T." Subject: [Roll] Smart Grid Bar Bof at IETF 76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 10:34:23 -0000 Hi, Please see the attached from Security AD (and NIST employee) Tim Polk. If this is something that would be of direct interest to you, please consider completing the Doodle poll. Thanks, Adrian ----- Original Message ----- From: "Polk, William T." To: "Fred Baker" ; "David R Oran" ; "Richard Shockey" ; "Russ Housley" ; "Leslie Daigle" ; "Sean Turner" ; "Paul Hoffman" ; "Henning Schulzrinne" ; "Phil Roberts" ; ; ; "Hiroshi Esaki" ; "Michael Dillon" ; "Brian E Carpenter" ; "Ralph Droms" ; "Michael Dillon" ; "IESG IESG" ; "IAB IAB" ; ; "Peny Yang" Cc: "St. Pierre, James A." ; "Dodson, Donna F." ; "Su, David H." ; "Golmie, Nada T." Sent: Tuesday, October 13, 2009 2:45 AM Subject: Doodle poll: Smart Grid Bar Bof at IETF 76 Folks, I would like to organize a BAR BOF at IETF 76 in Hiroshima to discuss the US Smart Grid effort. IETF protocols will be an important component of a successful and evolutionary Smart Grid, and NIST is looking to the IETF for leadership. To enable participation by NIST/ITL Management, I would like to hold the BAR BOF either Wednesday or Thursday night. NIST attendees will provide some background/history of the Smart Grid efforts but the primary goal of this session is to determine whether there is sufficient interest in the community to take on work in this area. If there is interest, scoping of appropriate IETF contributions, and strategies for organizing the response would also be fruitful topic areas. I am sending this email directly to any IETFers that have (to my knowledge) previously indicated interest in Smart Grid. I am also sending this message to the IESG, IAB, recipe@ietf.org, and ipaction@nist.gov email lists. Please feel free to forward this email to anyone else that you think I may have missed. If you are interested in attending the BOF, please indicate your preference using the following doodle poll: http://www.doodle.com/q5nusbhpqfnf75yh Thanks, Tim Polk From adam@sics.se Tue Oct 13 03:39:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F803A6839 for ; Tue, 13 Oct 2009 03:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaVbiowIOKYi for ; Tue, 13 Oct 2009 03:39:50 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 4DD0E3A67E6 for ; Tue, 13 Oct 2009 03:39:50 -0700 (PDT) Received: from [10.1.1.254] (unknown [10.1.1.254]) by letter.sics.se (Postfix) with ESMTP id A21AA400D9; Tue, 13 Oct 2009 12:39:50 +0200 (CEST) Message-ID: <4AD458EF.3090600@sics.se> Date: Tue, 13 Oct 2009 12:39:43 +0200 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Anders Brandt References: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu><4ACF43CC.2020303@acm.org> <1AA77E89-F83F-4BFD-92FF-657E4C9B9739@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429B26@zensys17.zensys.local> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429B26@zensys17.zensys.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 10:39:51 -0000 Anders Brandt wrote: > Can battery-powered 802.15.4. nodes quickly return to sleep if they are > not the intended recipient? Some can, but the biggest energy savings is in mechanisms that keep the radio off for most of the time, and switch it on to listen for traffic from neighbors. These mechanisms are typically layered on top of 802.15.4, although I believe there is ongoing work in the 802.15.4 wg to put such mechanisms into the standard. There are several techniques to do this, and the most common is called low-power listening (LPL) in which nodes turn on their radio at regular intervals to listen for a packet in the air. If there is a packet in the air (and it is addressed to the node), it switches on the radio for a longer time to receive the packet. Before sending a packet, a sender sends a preamble (typically a string of packets) to wake up the receiver. Thus with such mechanisms there is an energy penalty for packet transmissions, but the energy is spent both by the sender and the receiver. /adamn -- Adam Dunkels , +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ From richard.kelsey@ember.com Tue Oct 13 05:25:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D323A67A2 for ; Tue, 13 Oct 2009 05:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhvFjd1U9hsV for ; Tue, 13 Oct 2009 05:24:59 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6286F28C171 for ; Tue, 13 Oct 2009 05:24:59 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 08:26:06 -0400 Date: Tue, 13 Oct 2009 08:23:17 -0400 Message-Id: <87ws2za3ey.fsf@kelsey-ws.hq.ember.com> To: "Anders Brandt" In-reply-to: <6D9687E95918C04A8B30A7D6DA805A3E01429B29@zensys17.zensys.local> (abr@sdesigns.dk) From: Richard Kelsey References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> <200910131011.11371.hrogge@googlemail.com> <6D9687E95918C04A8B30A7D6DA805A3E01429B29@zensys17.zensys.local> X-OriginalArrivalTime: 13 Oct 2009 12:26:06.0619 (UTC) FILETIME=[565DF6B0:01CA4C00] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 12:25:00 -0000 Date: Tue, 13 Oct 2009 12:22:09 +0200 From: "Anders Brandt" Henning Rogge wrote: > ... On the other side ETX might be easy to implement on any kind > of layer-2 hardware, but is only a rough estimation of the "link > quality" which does not consider long time link statistics > (stability, variance, ...) or transmission speed. I have seen other people on this thread indicating that RSSI measurements tell a rather polluted truth. This is also our experience. I agree with you about raw RSSI. On the other hand, combining raw RSSI with sampled noise measurement to get a measured SNR (or SINR) does much better. It gives some idea of the margin available on the link. Translated to the real world, ETX information based on the number of received Acks from lower layers is a cheap and often sufficient metric. I and at least some others have not found this to work well for 802.15.4, in that ETX isn't stable enough to be a good predictor except in the very short term. I am aware that there disagreement on this :-). -Richard Kelsey From hrogge@googlemail.com Tue Oct 13 05:45:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA6528C187 for ; Tue, 13 Oct 2009 05:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a70Jlw8VMe45 for ; Tue, 13 Oct 2009 05:45:05 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 0FEF728C17E for ; Tue, 13 Oct 2009 05:45:04 -0700 (PDT) Received: by ewy4 with SMTP id 4so3318277ewy.37 for ; Tue, 13 Oct 2009 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=kfCBMTOtnpAAFUWIhnhMhAxiHvE/Ztgf9UgMTc41vkg=; b=nlfXZ36kdCCftNS+bpagcv0rh7oKUy7TirXJYG6QRRwREmnCX3rDYdJPlUKpOoLWAG gb16vE57C08aUestGgAsWFTU5QeqL4+aaeZAuPKsxnw7uNd9VoHXdLosLBwLvUTw0zKB Kp7mFwbozW384XH+yTk2lxxstt6lUiN9YPaIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=XyZxmP8/YJE+xoH0Mndem0hSTP4zc2ng9dVxCXtyXs+GgsSN3GucD2tSfF3/IT15n+ 38+oJWZlcme52q+CRJzL0TGfPe0j0KvdtiNuOoBT/lXRzRbs7HKV4W4yTGz8qRPEAqvI Ddmd5OE5vwwYvtBvlOpsaV+vozGxc8En1IZEI= Received: by 10.210.15.14 with SMTP id 14mr5564006ebo.49.1255437903001; Tue, 13 Oct 2009 05:45:03 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 23sm3000667eya.10.2009.10.13.05.45.01 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Oct 2009 05:45:01 -0700 (PDT) From: Henning Rogge To: Richard Kelsey Date: Tue, 13 Oct 2009 14:44:55 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <6D9687E95918C04A8B30A7D6DA805A3E01429B29@zensys17.zensys.local> <87ws2za3ey.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87ws2za3ey.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart41850737.bHLvPuWy2O"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910131445.00284.hrogge@googlemail.com> Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 12:45:06 -0000 --nextPart41850737.bHLvPuWy2O Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Am Dienstag 13 Oktober 2009 14:23:17 schrieb Richard Kelsey: > > > ... On the other side ETX might be easy to implement on any kind > > > of layer-2 hardware, but is only a rough estimation of the "link > > > quality" which does not consider long time link statistics > > > (stability, variance, ...) or transmission speed. >=20 > > I have seen other people on this thread indicating that RSSI > > measurements tell a rather polluted truth. This is also our > > experience. >=20 > I agree with you about raw RSSI. On the other hand, > combining raw RSSI with sampled noise measurement to get a > measured SNR (or SINR) does much better. It gives some idea > of the margin available on the link. >=20 > > Translated to the real world, ETX information based on > > the number of received Acks from lower layers is a cheap > > and often sufficient metric. >=20 > I and at least some others have not found this to work well > for 802.15.4, in that ETX isn't stable enough to be a good > predictor except in the very short term. I am aware that > there disagreement on this :-). My experience comes from 802.11, so we have more range compared to 802.15.4. If all 802.15.4 implementations have a good RSSI and noise/interference lev= el=20 measurement, this might be the better default metric for ROLL. 802.11 implementations sometimes have a poor, ugly or non-existant RSSI=20 measurement, and noise/interference level measurement is worse. That's why = I=20 would not suggest signal-strength/SNIR based metrics for WLAN. I'm not sure= =20 how well 802.15.4 do the necessary measurements. Henning --nextPart41850737.bHLvPuWy2O Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkrUdkwACgkQcenvcwAcHWewvwCfTngkfZTDG+Glx7F1ya9lfPux ld0An1taysY1LWoHv17ZBd2o2AgffsSL =g1Mz -----END PGP SIGNATURE----- --nextPart41850737.bHLvPuWy2O-- From jvasseur@cisco.com Tue Oct 13 06:35:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F194528C2C8 for ; Tue, 13 Oct 2009 06:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.035 X-Spam-Level: X-Spam-Status: No, score=-8.035 tagged_above=-999 required=5 tests=[AWL=-1.436, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfapINGg7tz2 for ; Tue, 13 Oct 2009 06:35:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DD25828C1A4 for ; Tue, 13 Oct 2009 06:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3119; q=dns/txt; s=sjiport01001; t=1255440940; x=1256650540; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Tue,=2013=20Oct=202009 =2015:33:35=20+0200|Message-Id:=20<1D32F82C-EC00-40EA-93B 7-A32B625C45E6@cisco.com>|To:=20Henning=20Rogge=20|Cc:=20roll@ietf.org,=20Maxence=20Dalmais =20|Mime-Version:=201.0=20( Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<200910 131011.11371.hrogge@googlemail.com>|References:=20=20=20<993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.c om>=20<200910131011.11371.hrogge@googlemail.com>; bh=7UuDdbINpVXzk3X/Dtn+5mfwjuYu4KU/pduDsLEE33M=; b=IDfYiCks6jJvK8Pa19P1ymteH50hobess0DmW3QnTzczxDtHV3Z/KwAM KwT7a28fAgW3jjYPYyh9nbek+Z3iiSA3cuegOu0V/kkllbZQhk/A5Nh9u NUcHuYg129lsEgqZGbCHxDCjIdozck+rHjayVhr4Sxr/t0LUv6hVWxN1N c=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOMe1EqrR7Ht/2dsb2JhbADACJd7hC0EgVs X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="255174910" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 13:35:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DDZdC7018907; Tue, 13 Oct 2009 13:35:40 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:35:37 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:35:36 +0200 Message-Id: <1D32F82C-EC00-40EA-93B7-A32B625C45E6@cisco.com> From: JP Vasseur To: Henning Rogge In-Reply-To: <200910131011.11371.hrogge@googlemail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 15:33:35 +0200 References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> <200910131011.11371.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 13:35:36.0730 (UTC) FILETIME=[0BF267A0:01CA4C0A] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 13:35:40 -0000 Hi Henning, On Oct 13, 2009, at 10:11 AM, Henning Rogge wrote: > Am Dienstag 13 Oktober 2009 04:48:34 schrieb JP Vasseur: >>> I am saying that when using wireless links, a node should be aware >>> that his communication could interfere with other communication. >>> Less powered is the transmission signal, less noise is seen by >>> neighbours. >>> A low powered node will also need less energy to communicate in a >>> less noisy environnement. >> >> Bear in mind, that you do not know this environment so this may lead >> you to an incorrect conclusion. >> The real metric is the link reliability, which reflect the properties >> of the environment. > We have a similar discussion about metrics in the Manet-WG. > Different kind of > metrics seem to be useful in different enviroments. Signal strength > seem to be > a good indicator for a "bad" link, but in praxis (especially with > incorrect > signal strengt estimation of consumer hardware) sometimes links with > low > signal strength are better than others with higher signal strength. > On the > other side ETX might be easy to implement on any kind of layer-2 > hardware, but > is only a rough estimation of the "link quality" which does not > consider long > time link statistics (stability, variance, ...) or transmission speed. > > Metrics for wireless networks are still being researched without > "final > perfect metric" in sight, so ROLL should keep metric IDs for futher > metric > types. Adding metric will not be an issue, just a new codepoint. What you said, what we need is a "good" enough mono-dimensional reliability metric to start with. > But you should put at least ONE easy to implement metric into the > basic > WG document. > The problem of OLSRv1 (as an example) was that it did NOT include > any metric except hopcount in it's basic document, so most people > using OLSR > for their projects (who do NOT research metrics for mesh networks) > just use > hopcount metrics and think that OLSR does not work. > > So the question about a metric for ROLL should not only be "what's > the best > metric for our networks" but "what metric is simple enough that > everyone can > implement it on any kind of hardware". > I fully agree with your approach. Yes, what we have done so far (in the new revision to be posted) is to define one mandatory metric (hop count) and have all other ones optional. May be "hop count" is one the one that we will keep as mandatory but the spirit is to have a set of metrics people can decide to use based on the OF. We still need to define the one reliability metric that we will be using. >>> As said somewhere else, the final metric should be a computation of >>> different metrics. >> >> This is the objective function. > Yes, a good metric "post processing" (including long term > statistical analysis > of a links different metrics) can be a good thing to enhance the > quality of > the "link cost" estimation. Thanks for the useful feed-back. JP. > > Henning Rogge From jvasseur@cisco.com Tue Oct 13 06:35:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FCD128C1A4 for ; Tue, 13 Oct 2009 06:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.966 X-Spam-Level: X-Spam-Status: No, score=-7.966 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTef-pCCVwiB for ; Tue, 13 Oct 2009 06:35:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3290928C1AB for ; Tue, 13 Oct 2009 06:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3819; q=dns/txt; s=sjiport01001; t=1255440940; x=1256650540; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Tue,=2013=20Oct=202009 =2015:34:26=20+0200|Message-Id:=20<1672E21C-7501-40F7-912 2-035F7ED1D177@cisco.com>|To:=20Anders=20Brandt=20|Cc:=20"Henning=20Rogge"=20,=20|Mime-Version:=201.0=20(Apple=20Mes sage=20framework=20v936)|Content-Transfer-Encoding:=207bi t|In-Reply-To:=20<6D9687E95918C04A8B30A7D6DA805A3E01429B2 9@zensys17.zensys.local>|References:=20<993C 9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com>=20<2009101310 11.11371.hrogge@googlemail.com>=20<6D9687E95918C04A8B30A7 D6DA805A3E01429B29@zensys17.zensys.local>; bh=V35UkQt8Jd9QNqt0leewk2ycMNpmCa0/FCYtXK/DyLQ=; b=caHVAE6PsWacswWLRODntM3fJvOT1+SNPbSthcBTlRXLUSfQ7csWjpm0 vkD17sL8Vs0INgghntohKWYsPKnlQn3mjI49gU9bO8gVmWuoPfIto1o2a Rb3OGCez3foMOsmSbnw8LchtdzuQEol7CqBGcNIaiTWgmVd5NSJReaqhn E=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOMe1EqrR7Ht/2dsb2JhbADACJd7hC0EgVs X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="255174912" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 13:35:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DDZLti018523; Tue, 13 Oct 2009 13:35:40 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:35:38 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:35:38 +0200 Message-Id: <1672E21C-7501-40F7-9122-035F7ED1D177@cisco.com> From: JP Vasseur To: Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429B29@zensys17.zensys.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 15:34:26 +0200 References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> <200910131011.11371.hrogge@googlemail.com> <6D9687E95918C04A8B30A7D6DA805A3E01429B29@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 13:35:38.0292 (UTC) FILETIME=[0CE0BF40:01CA4C0A] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 13:35:40 -0000 On Oct 13, 2009, at 12:22 PM, Anders Brandt wrote: > Henning Rogge wrote: > >> ... So the question about a metric for ROLL should not only be >> "what's > the best metric for our networks" but >> "what metric is simple enough that everyone can implement it on any > kind of hardware". > > Good pragmatic approach to reality. > >> ... On the other side ETX might be easy to implement on any kind of > layer-2 hardware, but is only a rough >> estimation of the "link quality" which does not consider long time >> link > statistics (stability, variance, ...) >> or transmission speed. > > I have seen other people on this thread indicating that RSSI > measurements tell a rather polluted truth. > This is also our experience. > Translated to the real world, ETX information based on the number of > received Acks from lower layers is a cheap and often sufficient > metric. > > ETX actually could be a good candidate for a default metric working > _FAIRLY_GOOD_ in most environments on most hardware platforms. > Thanks for the feed-back. That is also my feeling. > - Anders > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > Henning Rogge > Sent: 13. oktober 2009 10:11 > To: roll@ietf.org > Subject: Re: [Roll] ETX metric > > Am Dienstag 13 Oktober 2009 04:48:34 schrieb JP Vasseur: >>> I am saying that when using wireless links, a node should be aware >>> that his communication could interfere with other communication. >>> Less powered is the transmission signal, less noise is seen by >>> neighbours. >>> A low powered node will also need less energy to communicate in a >>> less noisy environnement. >> >> Bear in mind, that you do not know this environment so this may lead >> you to an incorrect conclusion. >> The real metric is the link reliability, which reflect the properties >> of the environment. > We have a similar discussion about metrics in the Manet-WG. Different > kind of metrics seem to be useful in different enviroments. Signal > strength seem to be a good indicator for a "bad" link, but in praxis > (especially with incorrect signal strengt estimation of consumer > hardware) sometimes links with low signal strength are better than > others with higher signal strength. On the other side ETX might be > easy > to implement on any kind of layer-2 hardware, but is only a rough > estimation of the "link quality" which does not consider long time > link > statistics (stability, variance, ...) or transmission speed. > > Metrics for wireless networks are still being researched without > "final > perfect metric" in sight, so ROLL should keep metric IDs for futher > metric types. But you should put at least ONE easy to implement metric > into the basic WG document. The problem of OLSRv1 (as an example) was > that it did NOT include any metric except hopcount in it's basic > document, so most people using OLSR for their projects (who do NOT > research metrics for mesh networks) just use hopcount metrics and > think > that OLSR does not work. > > So the question about a metric for ROLL should not only be "what's the > best metric for our networks" but "what metric is simple enough that > everyone can implement it on any kind of hardware". > >>> As said somewhere else, the final metric should be a computation of >>> different metrics. >> >> This is the objective function. > Yes, a good metric "post processing" (including long term statistical > analysis of a links different metrics) can be a good thing to enhance > the quality of the "link cost" estimation. > > Henning Rogge > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Tue Oct 13 06:35:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3546E28C2EE for ; Tue, 13 Oct 2009 06:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.035 X-Spam-Level: X-Spam-Status: No, score=-8.035 tagged_above=-999 required=5 tests=[AWL=-1.436, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4KhQtUKROgQ for ; Tue, 13 Oct 2009 06:35:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 414B828C2CE for ; Tue, 13 Oct 2009 06:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3119; q=dns/txt; s=amsiport01001; t=1255440943; x=1256650543; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Tue,=2013=20Oct=202009 =2015:35:40=20+0200|Message-Id:=20<389DB2FB-DE03-476B-A6E 6-11228A006982@cisco.com>|To:=20Henning=20Rogge=20|Cc:=20roll@ietf.org,=20Maxence=20Dalmais =20|Mime-Version:=201.0=20( Apple=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<200910 131011.11371.hrogge@googlemail.com>|References:=20=20=20<993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.c om>=20<200910131011.11371.hrogge@googlemail.com>; bh=7UuDdbINpVXzk3X/Dtn+5mfwjuYu4KU/pduDsLEE33M=; b=Mc9hGrYCNelWrnqb/OzgWd4o5Mt8NbxCRioTQTFrxOxzzTk7Z2VFaD7d fG8eqRqDvKIAuz3B0WHjSPWhrWEmwmJamdfk/3e/ftKiD2iZsD4NRFFcp mMfKumQfNpWBZ6/PDGNk2W3CefTv0SipAurx3sopMXgTsIy7Q5C+002sl 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAAOMe1EqQ/uCWe2dsb2JhbACbDgEBFiQGpDiXe4QtBIFb X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="51663680" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 13:35:41 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DDZfCE011279; Tue, 13 Oct 2009 13:35:41 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:35:41 +0200 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:35:40 +0200 Message-Id: <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> From: JP Vasseur To: Henning Rogge In-Reply-To: <200910131011.11371.hrogge@googlemail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 15:35:40 +0200 References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> <200910131011.11371.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 13 Oct 2009 13:35:40.0714 (UTC) FILETIME=[0E5250A0:01CA4C0A] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 13:35:43 -0000 Hi Henning, On Oct 13, 2009, at 10:11 AM, Henning Rogge wrote: > Am Dienstag 13 Oktober 2009 04:48:34 schrieb JP Vasseur: >>> I am saying that when using wireless links, a node should be aware >>> that his communication could interfere with other communication. >>> Less powered is the transmission signal, less noise is seen by >>> neighbours. >>> A low powered node will also need less energy to communicate in a >>> less noisy environnement. >> >> Bear in mind, that you do not know this environment so this may lead >> you to an incorrect conclusion. >> The real metric is the link reliability, which reflect the properties >> of the environment. > We have a similar discussion about metrics in the Manet-WG. > Different kind of > metrics seem to be useful in different enviroments. Signal strength > seem to be > a good indicator for a "bad" link, but in praxis (especially with > incorrect > signal strengt estimation of consumer hardware) sometimes links with > low > signal strength are better than others with higher signal strength. > On the > other side ETX might be easy to implement on any kind of layer-2 > hardware, but > is only a rough estimation of the "link quality" which does not > consider long > time link statistics (stability, variance, ...) or transmission speed. > > Metrics for wireless networks are still being researched without > "final > perfect metric" in sight, so ROLL should keep metric IDs for futher > metric > types. Adding metric will not be an issue, just a new codepoint. What you said, what we need is a "good" enough mono-dimensional reliability metric to start with. > But you should put at least ONE easy to implement metric into the > basic > WG document. > The problem of OLSRv1 (as an example) was that it did NOT include > any metric except hopcount in it's basic document, so most people > using OLSR > for their projects (who do NOT research metrics for mesh networks) > just use > hopcount metrics and think that OLSR does not work. > > So the question about a metric for ROLL should not only be "what's > the best > metric for our networks" but "what metric is simple enough that > everyone can > implement it on any kind of hardware". > I fully agree with your approach. Yes, what we have done so far (in the new revision to be posted) is to define one mandatory metric (hop count) and have all other ones optional. May be "hop count" is one the one that we will keep as mandatory but the spirit is to have a set of metrics people can decide to use based on the OF. We still need to define the one reliability metric that we will be using. >>> As said somewhere else, the final metric should be a computation of >>> different metrics. >> >> This is the objective function. > Yes, a good metric "post processing" (including long term > statistical analysis > of a links different metrics) can be a good thing to enhance the > quality of > the "link cost" estimation. Thanks for the useful feed-back. JP. > > Henning Rogge From pthubert@cisco.com Tue Oct 13 06:47:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51DF28C1BF for ; Tue, 13 Oct 2009 06:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.856 X-Spam-Level: X-Spam-Status: No, score=-9.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGtZ-S8nMT0J for ; Tue, 13 Oct 2009 06:47:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 379E228C181 for ; Tue, 13 Oct 2009 06:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2497; q=dns/txt; s=amsiport01001; t=1255441658; x=1256651258; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Tue,=2013=20Oct=202009=2015:47:35=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66E346@XM B-AMS-107.cisco.com>|To:=20"Michael=20Richardson"=20,=20"IETF=20ROLL"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<7991.1255382033@marajade.sandel man.ca>|References:=20<6A2A459175DABE4BB11DE2026AA50 A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D- B112-EEB907519BAC@sensinode.com><6A2A459175DABE4BB11DE202 6AA50A5D66DC8C@XMB-AMS-107.cisco.com>=20=20<7991.12553820 33@marajade.sandelman.ca>; bh=EyIvCMGjYB6LKEDIYcVEaZ2G7dtE4yK/wRowdfR2Bpk=; b=SXqFIsIgASlYvPKZmFEi3PgYBUwNsYZeQqkva2fXMGVEq6+64I2aOE7y 9zXciTuJbOBaYwVLdta4Dw7WTOCi+LaE5VPipFXKFBWKNjgpNcy5bVHsT i+VHoswAzHsvWmdp0TXXVXS84m0HdlfYMAKkkxuJNiQm8fSrTlnfh3vNN 8=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAADsh1EqQ/uCWe2dsb2JhbACbDgEBFiQGpDqXfIQtBIFb X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="51664925" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 13:47:35 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DDlZVr014561; Tue, 13 Oct 2009 13:47:35 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:47:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 15:47:35 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E346@XMB-AMS-107.cisco.com> In-Reply-To: <7991.1255382033@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLgOsdPk9ZiXEyTryij26NNaXOIgAhxNDA References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com><6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> <7991.1255382033@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "IETF ROLL" X-OriginalArrivalTime: 13 Oct 2009 13:47:35.0679 (UTC) FILETIME=[B87950F0:01CA4C0B] Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 13:47:37 -0000 Hi Richard > >Some things immediately jump out at me: > 1) small packets are much more common, so DAOs may not fit into ND. This is a non issue. IPv6 on any link requires an MTU of at least 1280.=20 6LoWPAN provides a fragmentation mechanism for those link layers that could hold the IPv6 MTU in a frame. Above the IPv6 MTU, you can still fragment the ND packet using IPv6 fragmentation. This is more common than you might think, as traditional ND packets can get real big, for instance in the presence of SeND. > 2) multicast is not assumed, so the Whiteboard is used. The routers could still use NS/NA between them but that makes little sense I agree. RPL routers use NA as unicast to their parent, a role that 6LoWPAN NR can perfectly play > 3) nodes that are sleepy, are not going to be useful as members of > an RPL DAG, so really, it's about RPL between the Edge Routers. In my mind the edge router is usually also the root for a RPL DAG. I agree that a node that exposes itself as a router must be able to get packets from nodes, and hold packets for next hops till they are awake to get them. So obviously, being a router will cause additional drain.=20 >From there, multiple strategies are possible, and I like the one whereby the router role can roll - ;) The current draft does not provide means to automate that strategy. It is also possible to deploy power-savvy routers to provide a mesh coverage. The protocol provides the means but how they are used is up to deployment... >It seems to me therefore that the only nodes in a 6lowpan that can >participate in a RPL DAG would be the edge router that runs a >Whiteboard. RPL is the prime protocol for a route-over 6LoWPAN network. So we must make it work, and hopefully it does. >I think you capture this in your above sentence. I do not think that >the 6LoWPAN routers will be speaking NR/NC between themselves along >their "backbone", but I could be wrong. Any 6LoWPAN node joins and stays in the LoWPAN using NR/NC with at least one router. If the node is itself a RPL router, it makes sense that it joins via its selected parents. Guess what, now we have a perfectly natural binding for our DAO. Hardly a surprise though seems there are a number of people that participate to both WGs. >I also think that some other people may be thinking that many more >6LoWPAN nodes will participate in RPL than just the edge routers. Hopefully :) Pascal From pthubert@cisco.com Tue Oct 13 06:48:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A15B28C142; Tue, 13 Oct 2009 06:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.93 X-Spam-Level: X-Spam-Status: No, score=-7.93 tagged_above=-999 required=5 tests=[AWL=-1.332, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4hCL-vvijQ4; Tue, 13 Oct 2009 06:48:43 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 35EDC28C1EF; Tue, 13 Oct 2009 06:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=18892; q=dns/txt; s=sjiport05001; t=1255441725; x=1256651325; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Tue,=2013=20Oct=202009=2015:47:29=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66E347@XM B-AMS-107.cisco.com>|To:=20"Anders=20Brandt"=20,=0D=0A=20=20=20=20=20=20=20=20"JP=20Vasseur=20(jv asseur)"=20,=0D=0A=20=20=20=20=20=20 =20=20|Cc:=20,=20"IETF=20ROLL"=20|MIME-Version: =201.0|In-Reply-To:=20<6D9687E95918C04A8B30A7D6DA805A3E01 429B28@zensys17.zensys.local>|References:=20=20<6D9687E9 5918C04A8B30A7D6DA805A3E01429B28@zensys17.zensys.local>; bh=Hsw7tzJyMh3tIJRRL9BEYxIbcBv8ctEJhYXm8+YRZ9s=; b=nnNlpDUj7c/5RUxvhrBuJabpORouD6mjfHIaCCNU1tRPgYofwQB/hYC6 B2F1IPk0ij5PQ5q2HCoLQnRBhltFghpYYXIm0YIv43x6l/fLiXmM91wlL kwAUu4gDdhuUZLX6CDp9B8nsrGk72EqZbt0fTpxoOpcjyUS/5a4UIp0Fq M=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAGci1EqrRN+K/2dsb2JhbACCJy29U4kvjk2ELQSBWw X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208,217";a="98534750" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 13 Oct 2009 13:47:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9DDlZ48029782; Tue, 13 Oct 2009 13:47:41 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 15:47:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4C0B.B8AB5E61" Date: Tue, 13 Oct 2009 15:47:29 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E347@XMB-AMS-107.cisco.com> In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429B28@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLsFzQT0z2VyA0T/GPSf4Daz+g0wAOYdlQAAhFSQA= References: <6D9687E95918C04A8B30A7D6DA805A3E01429B28@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Anders Brandt" , "JP Vasseur (jvasseur)" , X-OriginalArrivalTime: 13 Oct 2009 13:47:36.0290 (UTC) FILETIME=[B8D68C20:01CA4C0B] Cc: roll-bounces@ietf.org, IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 13:48:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4C0B.B8AB5E61 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Me too : ) =20 The only thing that blocks us right now from allowing (6loWPAN ND) NR as an alternate to (RFC4861) NA for the purpose of DAO is the draft status of the draft, not even last call yet. But if that clarifies we can allow either for the time being and see how things evolves. Or we could replace NA with NR right away and reconsider if things do not work out for the 6LoWPAN draft. This thread was started for that purpose after all... =20 Advice? =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Brandt Sent: mardi 13 octobre 2009 11:54 To: JP Vasseur (jvasseur); Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; IETF ROLL Subject: Re: [Roll] NA to transport DAO =20 Needless to say I also consider myself one of those people... =20 As discussed in the interim meeting, p2p mesh support is actually required in 50% of the requirement drafts forming the base of this working group. In IETF terms, Nodes MUST be able to use (somewhat optimized) p2p to communicate internally and MAY need to talk to an LBR. =20 - Anders =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: 13. oktober 2009 04:53 To: Jerald.P.Martocci@jci.com Cc: roll-bounces@ietf.org; IETF ROLL Subject: Re: [Roll] NA to transport DAO =20 On Oct 12, 2009, at 11:21 PM, Jerald.P.Martocci@jci.com wrote: I guess I am one of those people that think that other 6LoWPAN nodes must participate in RPL. Unless I am missing something RPL is the only game in town regarding meshing of wireless sensors. If they are not in RPL is there another means that they can use to form mesh connectivity to get to the LBR?=20 =20 You interpretation is of course correct. =20 JP. Jerry=20 Michael Richardson =20 Sent by: roll-bounces@ietf.org=20 10/12/2009 04:13 PM=20 To IETF ROLL =20 cc =09 Subject Re: [Roll] NA to transport DAO =20 =09 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > writes: Pascal> We are in perfect line. At the moment, RPL would impose Pascal> NS/NA between 6LoWPAN routers to expose the host routes. I have just read 6lowpan-nd-06.txt Some things immediately jump out at me: 1) small packets are much more common, so DAOs may not fit into ND. 2) multicast is not assumed, so the Whiteboard is used. 3) nodes that are sleepy, are not going to be useful as members of an RPL DAG, so really, it's about RPL between the Edge Routers. It seems to me therefore that the only nodes in a 6lowpan that can participate in a RPL DAG would be the edge router that runs a Whiteboard. I think you capture this in your above sentence. I do not think that the 6LoWPAN routers will be speaking NR/NC between themselves along their "backbone", but I could be wrong. I also think that some other people may be thinking that many more 6LoWPAN nodes will participate in RPL than just the edge routers. - --=20 ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.=20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/ iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw=3D=3D =3DFpQB -----END PGP SIGNATURE----- _______________________________________________ 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 =20 ------_=_NextPart_001_01CA4C0B.B8AB5E61 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Me too : )

 

The only thing that blocks us right now from allowing = (6loWPAN ND) NR as an alternate to (RFC4861) NA for the purpose of DAO is the = draft status of the draft, not even last call yet. But if that clarifies we = can allow either for the time being and see how things evolves. Or we could = replace NA with NR right away and reconsider if things do not work out for the = 6LoWPAN draft. This thread was started for that purpose after = all…

 

Advice?

 

Pascal

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Anders Brandt
Sent: mardi 13 octobre 2009 11:54
To: JP Vasseur (jvasseur); Jerald.P.Martocci@jci.com
Cc: roll-bounces@ietf.org; IETF ROLL
Subject: Re: [Roll] NA to transport DAO

 

Needless to say I also consider myself one of those = people...

 

As discussed in the interim meeting, p2p mesh support is = actually required in 50% of the requirement drafts forming the base of this = working group.

In IETF terms,

Nodes MUST be able to use (somewhat optimized) p2p to = communicate internally and MAY need to talk to an LBR.

 

- Anders

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: 13. oktober 2009 04:53
To: Jerald.P.Martocci@jci.com
Cc: roll-bounces@ietf.org; IETF ROLL
Subject: Re: [Roll] NA to transport DAO

 

On Oct 12, 2009, at 11:21 PM, Jerald.P.Martocci@jci.com = wrote:




I = guess I am one of those people that think that other 6LoWPAN nodes must participate = in RPL.  Unless I am missing something RPL is the only game in town = regarding meshing of wireless sensors.  If they are not in RPL is there = another means that they can use to form mesh connectivity to get to the = LBR?

 

You interpretation is of course = correct.

 

JP.




Jerry =




Michael Richardson <mcr@sandelman.ca> =
Sent = by: roll-bounces@ietf.org =

10/12/2009 04:13 PM

To=

IETF ROLL <roll@ietf.org> =

cc=

Subject=

Re: [Roll] NA to transport DAO

 




-----BEGIN PGP SIGNED = MESSAGE-----
Hash: SHA1


>>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" <pthubert@cisco.com>> writes:
   Pascal> We are in perfect line. At the moment, RPL = would impose
   Pascal> NS/NA between 6LoWPAN routers to expose the = host routes.

I have just read 6lowpan-nd-06.txt

Some things immediately jump out at me:
    1) small packets are much more common, so DAOs may not = fit into ND.
    2) multicast is not assumed, so the Whiteboard is = used.
    3) nodes that are sleepy, are not going to be useful = as members of
                an RPL DAG, = so really, it's about RPL between the Edge Routers.

It seems to me therefore that the only nodes in a 6lowpan that = can
participate in a RPL DAG would be the edge router that runs = a
Whiteboard.

I think you capture this in your above sentence.   I do not = think that
the 6LoWPAN routers will be speaking NR/NC between themselves = along
their "backbone", but I could be wrong.

I also think that some other people may be thinking that many = more
6LoWPAN nodes will participate in RPL than just the edge = routers.

- --
]       He who is tired of Weird Al is tired of life! =           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON =    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.o= n.ca/ |device driver[
  Kyoto Plus: watch the video <http://www.youtube.= com/watch?v=3Dkzx1ycLXQSE>
                  =              then sign the petition. =
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5E9N=
j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpX=
bnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp=
GB+QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo=
aWKWXI9DfhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/=
iZxrOjTeS6ZeK4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw=3D=3D
= =3DFpQB
-----END PGP SIGNATURE-----
_______________________________________________
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

 

------_=_NextPart_001_01CA4C0B.B8AB5E61-- From hrogge@googlemail.com Tue Oct 13 06:53:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C883A68BF for ; Tue, 13 Oct 2009 06:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYuU3iFLf1mm for ; Tue, 13 Oct 2009 06:53:56 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 028733A67B8 for ; Tue, 13 Oct 2009 06:53:55 -0700 (PDT) Received: by ewy4 with SMTP id 4so3388778ewy.37 for ; Tue, 13 Oct 2009 06:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=tXvv/Gv3mIst1o6z3njM6p1ji7M7seX4853zt7qxpO0=; b=hkGIwMUMxpWw94Qx0Ri0ctJEQxLdTnGm+HQ80yOY43isW/p0lfy9NdSHW7R+kvRMHX VhIc4P9bWv8nLXbejNk85d6D9a56SICcDcyKCxUkHJxCeUidUAJ/BHf5R3rZe4iudoRq 4o/o7O0nw71/KLaa9aroAp+Fk4Kt57D2m39l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=yBUOmyxl+JiPsUs1/+7SrL5fTmmQ+0GJ/+APps7G362lW8pa2wWZtMRHi3YnryG5Fr uQ/DAYV4TKHnUuMRps6vQ5PtijB41CON3+LauoYuDu7ymxBlq7bOxcV7lGn80VXehy5e 1i4zIk8ZI3LJfQoYm9QMUX4p97Nbw1K4bAG3c= Received: by 10.216.90.131 with SMTP id e3mr344961wef.69.1255442034762; Tue, 13 Oct 2009 06:53:54 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 10sm450990eyz.2.2009.10.13.06.53.48 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Oct 2009 06:53:48 -0700 (PDT) From: Henning Rogge To: JP Vasseur Date: Tue, 13 Oct 2009 15:53:43 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> In-Reply-To: <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart44840022.uiBaKsQu3h"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910131553.47834.hrogge@googlemail.com> Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 13:53:57 -0000 --nextPart44840022.uiBaKsQu3h Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Dienstag 13 Oktober 2009 15:35:40 schrieb JP Vasseur: > > So the question about a metric for ROLL should not only be "what's > > the best metric for our networks" but "what metric is simple enough that > > everyone can implement it on any kind of hardware". >=20 > I fully agree with your approach. >=20 > Yes, what we have done so far (in the new revision to be posted) is to > define one mandatory metric (hop count) and have all other ones optional. > May be "hop count" is one the one that we will keep as mandatory but the > spirit is to have a set of metrics people can decide to use based on the = OF. OLSRv1 did the same way and it shaped the conclusion "OLSR is crap" or "OLS= R=20 does not work" in huge parts of the industry. Hop count metrics can be call= ed=20 "use worst link" metrics for wireless networks, because it tries to optimiz= e=20 for the LONGEST links possible, which will be (most likely) worst links you= r=20 network knows. With OLSR and 802.11 you can summarize it "Hopcount does not work in real=20 networks outside the lab". There are some special cases how you can improve= =20 hopcount, but most times you will still get a poor performance and your=20 protocol will be blamed. Unless 802.15.4 is totally different (I don't think so) I would strongly=20 suggest thinking about something better than hopcount for your mandatory=20 metric. At least that's the message I can tell from OLSR. Henning Rogge =2D- Those who cannot learn from history are doomed to repeat it. --nextPart44840022.uiBaKsQu3h Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkrUhmsACgkQcenvcwAcHWcpNQCdE0/+SV0ztWFWNbDDdT5Er0us x8kAn3Pf/BtisN0/KJ7PRu8ji1FxdeAk =zJgD -----END PGP SIGNATURE----- --nextPart44840022.uiBaKsQu3h-- From pthubert@cisco.com Tue Oct 13 07:16:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA5928C192 for ; Tue, 13 Oct 2009 07:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.809 X-Spam-Level: X-Spam-Status: No, score=-7.809 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJ9I1W0gCYTN for ; Tue, 13 Oct 2009 07:16:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2F7A328C232 for ; Tue, 13 Oct 2009 07:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1065; q=dns/txt; s=sjiport06001; t=1255443386; x=1256652986; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Tue,=2013=20Oct=202009=2016:16:03=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66E382@XM B-AMS-107.cisco.com>|To:=20"JP=20Vasseur=20(jvasseur)"=20 |Cc:=20"Mathilde=20Durvy=20(mdurvy)" =20,=0D=0A=20=20=20=20=20=20=20=20"Zach =20Shelby"=20,=0D=0A=20=20=20=20=20 =20=20=20"Julien=20Abeille=20(jabeille)"=20,=0D=0A=20=20=20=20=20=20=20=20"IETF=20ROLL"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<966A42CE-0D99-416E-BD75-2AE5DAE8F312@cis co.com>|References:=20<6A2A459175DABE4BB11DE2026AA50 A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D- B112-EEB907519BAC@sensinode.com>=20<6A2A459175DABE4BB11DE 2026AA50A5D66DC8C@XMB-AMS-107.cisco.com>=20<8A977BDC5A7B0 E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com>=20<6A2A4 59175DABE4BB11DE2026AA50A5D66DF95@XMB-AMS-107.cisco.com> =20<966A42CE-0D99-416E-BD75-2AE5DAE8F312@cisco.com>; bh=9RHoXy5v+iWuZRFg1kSmFMz4ir1PjxOKKUL/FCxEaB4=; b=Nonf+Sl99UXehZo1y6Nt5N6BqUR4sW18PZRnic7s3cJfBzlch90QGs6z pB/0XfZIqsxLNu19bPLKe+Ox68XQbCcoREYJySX3Tr5EX95iyx+78eD8l MzODwr2pMKkCDFUmniIadyEDQMgSjgrvzllFHkIE0KV1XYykc5sexHXOg 4=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALoo1EqrRN+J/2dsb2JhbADAH5gAhC0EgVs X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="408239633" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 13 Oct 2009 14:16:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9DEGAEC002447; Tue, 13 Oct 2009 14:16:22 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 16:16:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 16:16:03 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E382@XMB-AMS-107.cisco.com> In-Reply-To: <966A42CE-0D99-416E-BD75-2AE5DAE8F312@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpLaBCaOfe6vyMpTF25SlOCc9nSWwAponOg References: <6A2A459175DABE4BB11DE2026AA50A5D66DAAC@XMB-AMS-107.cisco.com><3310086F-D3CF-431D-B112-EEB907519BAC@sensinode.com> <6A2A459175DABE4BB11DE2026AA50A5D66DC8C@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE73C1EF@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D66DF95@XMB-AMS-107.cisco.com> <966A42CE-0D99-416E-BD75-2AE5DAE8F312@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 13 Oct 2009 14:16:10.0191 (UTC) FILETIME=[B66715F0:01CA4C0F] Cc: IETF ROLL Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 14:16:24 -0000 Hi JP, >> The binding is like a transport. We'll define a different binding but >> it's still the same generic protocol. Like you can ping over UDP it's >> still ping. >> >> And RPL does not do NA multicast for DAO, but for the specific case of >> hosts that would participate to the game. > >it does Mcast NA for DOA ... > >> Then again the LoWPAN model is >> a better fit. > >RRR ... what do you mean by LoWPAN model ???? Oups, I meant 6LoWPAN ND model vs. the RFC 4861 model from which we reuse NA.=20 The NR/NC model is a better fit for transporting DAO than NA is, because it creates a registration relationship that's fit for registering a route as well. Like NEMO registers a prefix over MIPv6 if you wish. Basically we can benefit from the fact that the state of the route can be strongly coupled with the state of the registration. We use NA because in traditional ND that's probably the best we have to express the child to parent relationship. But I certainly agree with Julien that it's far from perfect.=20 Pascal From pthubert@cisco.com Tue Oct 13 07:57:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A9928C310 for ; Tue, 13 Oct 2009 07:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.409 X-Spam-Level: X-Spam-Status: No, score=-7.409 tagged_above=-999 required=5 tests=[AWL=-1.410, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUyX06QhOm6M for ; Tue, 13 Oct 2009 07:57:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 994F128C218 for ; Tue, 13 Oct 2009 07:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=9103; q=dns/txt; s=rtpiport01001; t=1255445845; x=1256655445; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20Informed=20move=20[was:=20A=20proposal =20for=20Traffic=20Loop=20avoidance,detection=20and=20rec overy]|Date:=20Tue,=2013=20Oct=202009=2016:56:48=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66E3F0@XM B-AMS-107.cisco.com>|To:=20"Sung=20Lee"=20,=20|Cc:=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4AD366EA.1040601@us.fujitsu.com >|References:=20=20<4AD366EA.1040601@us.fujitsu.com>; bh=buvGCuUsxhAJvNyiU5aSfllwkNCiGTOF5pD/4/h/0Iw=; b=XQ3EbJMfP1QjNRl+QeUeNs+/LUGI/zpInTxHlVOzpMGAtrrb15lXVqrC ag2+1lqagybSsTMWtyMI5s1tCtdD1VvOZ/VdS1pA0IEsWDgqj8umFom08 04me8+FVc5IJv4wS3S5wqF7WjZmk55OL9ZawB0sNTKNb3WhE1n8Q2l4hu A=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKMx1EqtJV2a/2dsb2JhbADAY5d6hC0Eil4 X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="62787501" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 13 Oct 2009 14:57:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id n9DEuxDq017137; Tue, 13 Oct 2009 14:57:06 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 16:56:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 16:56:48 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E3F0@XMB-AMS-107.cisco.com> In-Reply-To: <4AD366EA.1040601@us.fujitsu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Informed move [was: A proposal for Traffic Loop avoidance, detection and recovery] Thread-Index: AcpLYUFDAHaordGuSsG2vkrQwLtk8gApLu/w References: <4AD366EA.1040601@us.fujitsu.com> From: "Pascal Thubert (pthubert)" To: "Sung Lee" , X-OriginalArrivalTime: 13 Oct 2009 14:56:59.0254 (UTC) FILETIME=[6A287160:01CA4C15] Cc: roll@ietf.org Subject: [Roll] Informed move [was: A proposal for Traffic Loop avoidance, detection and recovery] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 14:57:25 -0000 Hi Sung and Phil; Option 2) is close in spirit to what the current draft is doing.=20 =20 Routing through higher rank has the same risk as moving to higher rank; maybe a loop, maybe not; loop detection will help figure.=20 The draft actually allows moving to a higher rank but there's a catch. Whereas a node can reattach right away to obtain a better rank, it needs to play a little dance that includes detach, wait & see before it can attach at a higher rank.=20 The dance is not aimed at avoiding loops completely.=20 It just tries to bend the stats and lowers the odds of using the wrong guy, by marking proactively some unsafe landing spots before making a risky move. This is done by poisoning the route via self over the self's subDAG. A side effect is to reduce the traffic that will take a risky path and the chances to count to infinity. Route poisoning is completed by the rule that a parent that goes down should be eliminated.=20 RPL as it stands today certainly does not provide the level of guarantee that DUAL would over a rather fixed topology. So at the end of the day, we do end up routing through nodes of higher ranks and do need a loop detection. The question is where we place the bar, and I am one of those of think that the poisoning brings along more benefit on the battery than cost in missed forwarding opportunities. We might be less conservative when we have a better description of our loop detection mechanism. To get there, it is especially important that the two of you comment on the proposal from original thread on detection and recovery. Thanks in advance, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Sung Lee >Sent: lundi 12 octobre 2009 19:27 >To: roll@ietf.org >Subject: Re: [Roll] A proposal for Traffic Loop avoidance,detection and recovery > >I am with Philip. >Our experience also shows that > 2) Allow routing through nodes of higher rank > > with loop detection and repair in the data path works pretty well. > >Regards, >Sung > > >roll-request@ietf.org wrote: >> Message: 2 >> Date: Fri, 9 Oct 2009 10:20:05 -0700 >> From: Philip Levis >> Subject: Re: [Roll] A proposal for Traffic Loop avoidance, detection >> and recovery >> To: Pascal Thubert (pthubert) >> Cc: roll >> Message-ID: >> Content-Type: text/plain; charset=3DWINDOWS-1252; format=3Dflowed; >> delsp=3Dyes >> >> >> On Oct 9, 2009, at 5:55 AM, Pascal Thubert (pthubert) wrote: >> >> >>> Hi: >>> >>> It seems widely accepted in this group that Loop avoidance in the >>> control place should be kept simple but completed by a detection >>> mechanism associated to the packets. This approach had been >>> validated in CTP and DADR. >>> >>> After a number of discussions, here is a proposal. The proposal uses >>> some info that is placed in the packet in the flow label. >>> It assumes that the flow label is reserved for the purpose of RPL >>> and node interaction. In the flow label we place: >>> >>> Outwards : 1 bit >>> Sibling : 1 bit >>> Rank_error : 1 bit >>> DAO_Error : 1 bit >>> Rank : 8 bit >>> Instance ID : 8 bit >>> >>> Instance forwarding >>> Instance IDs is used to avoid loops between DAGs from different >>> origins. >>> >>> InstanceID is placed by the source in the flow label. It MUST >>> matched the DAG instance onto which the packet is placed by a >>> router. The router MAY either change the instanceID to match the DAG >>> that it is using for this packet or discard the packet. That >>> decision is policy based. Default policy TBD. >>> >>> Idea? >>> >>> DAG inconsistency loop detection >>> The DAG is inconsistent is the packet direction does not match the >>> rank relationship. >>> >>> A host MUST set the rank to FF. A router MUST place its rank in the >>> flow label. >>> A node emitting a packet must reset the Rank_error bit and the >>> Outwards bit. >>> A router MUST also reset the Outwards bit if it is using the default >>> route inwards, either via a sibling or a parent, and set the bit if >>> it is using a DAO route, either via a sibling or a child. >>> >>> A receiver detects an inconsistency if it receives a packet going >>> inwards from a source with a lesser Rank, or outwards with a higher >>> rank. >>> >>> Upon inconsistency, if the Rank_error bit was not set then the >>> Rank_error bit is set. If it was set the packet is discarded. This >>> is done to cover a rare re-sequencing of the DAG. >>> >>> Sibling loop avoidance >>> A simple rule is that a packet may not make 2 sibling hops in a row. >>> >>> When a host sends a packet or a router forwards to a non sibling, >>> the Sibling bit must be reset. >>> When a router forwards to a sibling: if the Sibling bit was not set >>> then the Sibling bit is set. If it was set then the packet is >>> discarded. >>> >>> DAO inconsistency loop detection >>> A ?parent? has an outwards DAO route that is a remnant from an >>> obsolete DAO via a ?child? but the ?child? does not have a matching >>> DOA state. >>> >>> In a general manner, a packet that goes outwards should never go >>> inwards again. So rather than routing inwards a packet with the >>> Outwards bit set, the router MUST discard the packet. If DAO >>> recovery is in place, then the router MAY send it back to the source. >>> >>> DAO inconsistency loop recovery >>> A Router that supports recovery uses a packet to recursively explore >>> and cleanup the obsolete paths. >>> >>> The ?child? router that detects the DAO inconsistency SHOULD set the >>> DAO_Error bit and return the packet to the parent that passed it. >>> >>> Upon a packet with a DAO bit set, the parent MUST remove the routing >>> states that caused forwarding to the child that passed it, clear >>> DAO_Error bit and send the packet again. >>> >>> >> >> I advocate taking a more extreme approach: remove the current sequence >> number loop prevention mechanisms from the draft. >> >> Currently, RPL is trying to have it both ways. It's using sequence >> numbers to prevent (not just avoid) loops caused by increasing in >> rank. However, by allowing nodes to choose siblings, RPL still >> requires a loop detection mechanism in data packets. If there is a >> mechanism to detect loops with data packets, then there is no need to >> have rules on when nodes can increase rank: the decision of whether to >> do so or not is a performance design choice. >> >> When we started designing CTP, we tried using sequence numbers as DSDV >> does. The logic to handle all of the edge cases was non-trivial. In >> particular, if node A has move to sequence number N+1, but its child B >> is still on sequence number N, then on receiving a packet from child >> B, A must forward it with tree N. That is, A must maintain two trees. >> Overall, the edge cases were complex, required a good deal of code, >> and had a lot of tricky edge cases. Furthermore, the prospect of being >> floating until a sequence number increment created a difficult tension >> between the longest interval a DAG could be floating and the cost of >> periodically flooding DAG sequence number updates. >> >> If there is a way to detect and repair loops in the data path, then >> this tension disappears. Loops become an efficiency problem, due to >> the extra messages they send. Correspondingly, may protocols have an >> inventive to follow the loop prevention guidelines in -03, if doing so >> leads to overall better efficiency. But such algorithms and policies >> are RECOMMENDED or OPTIONAL performance optimizations on top of a >> specification, not part of the specification itself (e.g., think RFC >> 2581). >> >> In summary, I'd argue, that for the sake of simplicity in required >> mechanisms, and flexibility in future implementation designs, that RPL >> should either: >> >> 1) Disallow routing through siblings >> 2) Allow routing through nodes of higher rank >> >> I personally think 2) is a better approach, based on my experiences, >> as it can remove the need for periodic sequence number increments. But >> I think that the current half-way position is worse than either 1) or >> 2): it has the worst of both worlds. >> >> If we make sequence number-based DAG control OPTIONAL, then I'd argue >> we should elide it from the main RPL document. Keep the core >> specification simple. >> >> Phil >> >> ------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> End of Roll Digest, Vol 21, Issue 21 >> ************************************ >> > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Oct 13 09:01:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F48628C22C for ; Tue, 13 Oct 2009 09:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxEcFIc3jHZb for ; Tue, 13 Oct 2009 09:01:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 22EBB28C22A for ; Tue, 13 Oct 2009 09:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3445; q=dns/txt; s=amsiport01001; t=1255449708; x=1256659308; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20ETX=20metric|Date:=20Tue ,=2013=20Oct=202009=2018:01:41=20+0200|Message-ID:=20<6A2 A459175DABE4BB11DE2026AA50A5D66E45C@XMB-AMS-107.cisco.com >|To:=20"Henning=20Rogge"=20,=0D =0A=20=20=20=20=20=20=20=20"JP=20Vasseur=20(jvasseur)"=20 |Cc:=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<200910131553.47834.hrogge@googlemail.com >|References:=20<200910131011.11371.hrogge@goog lemail.com><389DB2FB-DE03-476B-A6E6-11228A006982@cisco.co m>=20<200910131553.47834.hrogge@googlemail.com>; bh=vSAHotiWEwc+kBGmZVmWxjGSTQKQuqRSpCXC19iDGRc=; b=J5kwAdhAKZ9ORpVjBHlVomsdEzGkgaBiCkKQDLxBbaXd2McSuD5Ko8nI O7eH6veG6+pxLZIGhX264gy35jLUyULkZE9Durwxfd0/kZu5YUZidip7+ gAOPYlt3dsyRiupio/wk9Uqz1+pegm/d9jxmdFB7gtJkPL+0RXFlLKOjX k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAAN9A1EqQ/uCWe2dsb2JhbACbDQEBFiQGpUCXfoQtBIFb X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="51681193" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 16:01:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9DG1kbB000467; Tue, 13 Oct 2009 16:01:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 18:01:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 18:01:41 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E45C@XMB-AMS-107.cisco.com> In-Reply-To: <200910131553.47834.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ETX metric Thread-Index: AcpMDKM6+cJLHvlFQKO3ExXoVWMY2wADijAQ References: <200910131011.11371.hrogge@googlemail.com><389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> From: "Pascal Thubert (pthubert)" To: "Henning Rogge" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 13 Oct 2009 16:01:46.0216 (UTC) FILETIME=[76F7C680:01CA4C1E] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 16:01:50 -0000 Hi Henning. Good to hear from you :) We also called that syndrome the 'Worst Path First'. I think the name was introduced by Teco quite a long time ago. The trick to make it work outside the Lab is to filter out any packet that does not have metrics like RSSI above a quality threshold and blacklist peers that show a poor history. Like a WIFI AP that does not associate or drops association with nodes under a certain signal strength. RPL requires an abstract peer link evaluation though it does not say how that is done and it has the hold down feature. I got good results with an emulation of LMI's N392/N393 that computes a loss ratio. But there must be a great many other strategies so that least each hop is rated 'good enough' and the network is not stretched too far. I'm unsure whether we should specify how that's done, since it might be L2 dependent. And even if one can alleviate the WPF syndrome, the end result is that paths cannot be compared for their end to end metric thus are not optimized. =20 RPL is a bit more subtle than meet the eye from JP's summarized description. It provides a default increment per hop (4), but the node can play around that increment to reflect the quality of the link (1..16). So we can advertise something that's a lot closer to the link's quality and thus optimize something that's dependent on the objective. OCP0 (the arch default) increments by 4 so it really relies on the link evaluation. Maybe we could allow to play around the 4 value within the 1..16 range but then we cannot really specify how that is done since that sort of thing is left to the metrics draft. Cheers, Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Henning Rogge >Sent: mardi 13 octobre 2009 15:54 >To: JP Vasseur (jvasseur) >Cc: roll@ietf.org >Subject: Re: [Roll] ETX metric > >Am Dienstag 13 Oktober 2009 15:35:40 schrieb JP Vasseur: >> > So the question about a metric for ROLL should not only be "what's >> > the best metric for our networks" but "what metric is simple enough >> > that everyone can implement it on any kind of hardware". >> >> I fully agree with your approach. >> >> Yes, what we have done so far (in the new revision to be posted) is to >> define one mandatory metric (hop count) and have all other ones optional. >> May be "hop count" is one the one that we will keep as mandatory but >> the spirit is to have a set of metrics people can decide to use based on the OF. > >OLSRv1 did the same way and it shaped the conclusion "OLSR is crap" or "OLSR does not work" in huge parts of >the industry. Hop count metrics can be called "use worst link" metrics for wireless networks, because it tries >to optimize for the LONGEST links possible, which will be (most likely) worst links your network knows. > >With OLSR and 802.11 you can summarize it "Hopcount does not work in real networks outside the lab". There are >some special cases how you can improve hopcount, but most times you will still get a poor performance and your >protocol will be blamed. > >Unless 802.15.4 is totally different (I don't think so) I would strongly suggest thinking about something >better than hopcount for your mandatory metric. At least that's the message I can tell from OLSR. > >Henning Rogge > >-- Those who cannot learn from history are doomed to repeat it. From richard.kelsey@ember.com Tue Oct 13 09:04:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F3628C239 for ; Tue, 13 Oct 2009 09:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usTeu7WrHjKw for ; Tue, 13 Oct 2009 09:04:23 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8249F3A6405 for ; Tue, 13 Oct 2009 09:04:23 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 12:05:25 -0400 Date: Tue, 13 Oct 2009 12:02:35 -0400 Message-Id: <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> To: Henning Rogge In-reply-to: <200910131553.47834.hrogge@googlemail.com> (message from Henning Rogge on Tue, 13 Oct 2009 15:53:43 +0200) From: Richard Kelsey References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> X-OriginalArrivalTime: 13 Oct 2009 16:05:25.0619 (UTC) FILETIME=[F9BE0430:01CA4C1E] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 16:04:24 -0000 From: Henning Rogge Date: Tue, 13 Oct 2009 15:53:43 +0200 Am Dienstag 13 Oktober 2009 15:35:40 schrieb JP Vasseur: > Yes, what we have done so far (in the new revision to be posted) is to > define one mandatory metric (hop count) and have all other ones optional. > May be "hop count" is one the one that we will keep as mandatory but the > spirit is to have a set of metrics people can decide to use based on the OF. OLSRv1 did the same way and it shaped the conclusion "OLSR is crap" or "OLSR does not work" in huge parts of the industry. Hop count metrics can be called "use worst link" metrics for wireless networks, because it tries to optimize for the LONGEST links possible, which will be (most likely) worst links your network knows. With OLSR and 802.11 you can summarize it "Hopcount does not work in real networks outside the lab". There are some special cases how you can improve hopcount, but most times you will still get a poor performance and your protocol will be blamed. Unless 802.15.4 is totally different (I don't think so) I would strongly suggest thinking about something better than hopcount for your mandatory metric. At least that's the message I can tell from OLSR. Those who cannot learn from history are doomed to repeat it. We have to be careful not to learn the wrong lesson. Hopcount without careful link assessment definitely doesn't work. Hopcount limited to stable, symmetric links is a different beast entirely. For example, consider the Cost/PL column in table 1 of [1], which gives the average transmissions per link. For most of the networks it is very close to 1 and it never goes above 2. That's puts ETX pretty close to hopcount for those networks, if routing is limited to links with good ETX. So let me propose a reliability metric with two hopcounts, one for 'good' links and the other for 'okay' ones. To make it more concrete: 'Good' links have a current ETX < 1.5 and are expected to stay working throughout a maximum RA-DIO interval (which I think is given by 2^(DIOIntervalMin + DIOIntervalDoublings)) 99% of the time. 'Okay' links have an ETX < 3.0 and are expected to be working throughout a maximum RA-DIO interval 80% of the time. When comparing, five 'good' hops would be equivalent of one 'okay' one. I pulled the numbers (1.5, 99%, 3.0, 80% and five) out of thin air. Real values would have to be chosen with care. -Richard Kelsey [1] Omprakash Gnawali, Rodrigo Fonseca, Kyle Jamieson, David Moss, and Philip Levis "Collection Tree Protocol." Technical Report SING-09-01 From jhui@archrock.com Tue Oct 13 09:10:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167D228C172 for ; Tue, 13 Oct 2009 09:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFUmZuwcDri6 for ; Tue, 13 Oct 2009 09:10:03 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 056513A67EF for ; Tue, 13 Oct 2009 09:10:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 59ECFAF83E; Tue, 13 Oct 2009 09:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POKhZ2tcA-mu; Tue, 13 Oct 2009 09:10:00 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 13505AF83C; Tue, 13 Oct 2009 09:10:00 -0700 (PDT) Message-Id: <91A78980-BEC5-4F94-89C3-D31BC9D1BA9E@archrock.com> From: Jonathan Hui To: Anders Brandt In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429B26@zensys17.zensys.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 09:09:58 -0700 References: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu><4ACF43CC.2020303@acm.org> <1AA77E89-F83F-4BFD-92FF-657E4C9B9739@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429B26@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: [Roll] Duty-Cycling Radios (was: Re: RPL Metric ID) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 16:10:04 -0000 On Oct 13, 2009, at 2:12 AM, Anders Brandt wrote: > One word of warning on the energy discussion: > It seems like the assumption is that the routing protocol should > manage > the number of transmitted packets in order to ensure that the energy > consumption is distributed among more nodes. > > There is however a caveat here: > From our experience, a radio uses energy. Period. > Receiving uses the same as transmitting - the difference is just which > amplifiers use the energy. > Thus, the way to use less energy is to use the radio less - i.e. sleep > some of the time. Which again translates into higher latency to reach > such nodes. Obviously, there is something to save, since a radio may > quickly determine if it is the intended recipient of a packet and > return > to sleep again OR receive the entire packet and stay awake to forward > the packet on to another node in the network. You're right. There is a fundamental tradeoff between energy consumption vs. expected communication latency and/or throughput when using a particular radio technology. > Thus, what I am trying to say is: > Unless the lower layers have a smart way of quickly returning to sleep > (which some technologies have) the routing protocol will keep all > nodes > awake within direct range - and they will all use power for > listening => > nothing gained from distributing the traffic. > Can battery-powered 802.15.4. nodes quickly return to sleep if they > are > not the intended recipient? > If not, the energy metric may be rather useless (?) Specific to 802.15.4, it is possible to enable/disable the receiver with a period on the order of a couple hundred milliseconds and achieve an effective duty-cycle of far less than 1%. The link simply appears as if it has lower throughput. Expected latency will increase proportionally, but the particular factors depends on whether or not you can coordinate the duty-cycle schedules to match the routes (or vice versa). In any case, 802.15.4e is working on incorporating at least two duty- cycling techniques. The first is a channel-sampling approach that utilizes short chirp packets in the general case but incorporates scheduling to reduce transmission overhead. You can find details of the approach being used in Chapter 4 of [1]. The second is a time- slotted approach where nodes have to synchronize schedules with their neighbors before they can communicate with them. In both cases, the net effect is that they make the link appear as if it is up all the time, just with lower throughput and higher latency. The challenge with respect to energy is that they shift energy costs in different ways. [1] http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-116.pdf -- Jonathan Hui From mcr@marajade.sandelman.ca Tue Oct 13 09:41:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76A9228C219 for ; Tue, 13 Oct 2009 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0NtvjVi0LBs for ; Tue, 13 Oct 2009 09:41:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id A9C963A68A9 for ; Tue, 13 Oct 2009 09:41:47 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 3B5353428C for ; Tue, 13 Oct 2009 16:46:14 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A88294E7FB for ; Tue, 13 Oct 2009 12:41:43 -0400 (EDT) From: Michael Richardson To: IETF ROLL In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 13 Oct 2009 12:41:43 -0400 Message-ID: <21375.1255452103@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 16:41:49 -0000 (You'll want to edit your mailer to not reply to SMTP from addresses, as you CC'ed roll-bounces@ietf.org, which you certainly do not want to do) >>>>> "Jerald" == Jerald P Martocci writes: Jerald> I guess I am one of those people that think that other Jerald> 6LoWPAN nodes must participate in RPL. Unless I am missing Jerald> something RPL is the only game in town regarding meshing of Jerald> wireless sensors. If they are not in RPL is there another Jerald> means that they can use to form mesh connectivity to get to Jerald> the LBR? As far as I can tell 6LoWPAN-nd and RPL are somewhat complementary, and somewhat overlapping. >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: >> Some things immediately jump out at me: 1) small packets are much >> more common, so DAOs may not fit into ND. Pascal> This is a non issue. IPv6 on any link requires an MTU of at Pascal> least 1280. 6LoWPAN provides a fragmentation mechanism for Pascal> those link layers that could hold the IPv6 MTU in a frame. Pascal> Above the IPv6 MTU, you can still fragment the ND packet Pascal> using IPv6 fragmentation. This is more common than you Pascal> might think, as traditional ND packets can get real big, for Pascal> instance in the presence of SeND. Uhm, the fact that 6LoWPAN provides a fragmentation mechanism is not important. What this means is that a single ND packet now takes multiple packets. One of the arguments against putting DAOs in the ND is that they do not go often enough, and therefore we would have to send more ND packets, which means more energy. If in fact the ND will be fragmented by the layer-2 for delivery, then we might well be better off to send the more frequent DAOs in their own packet, ideally one which 6LoWPAN can carry without fragmentation. That's a win because then the much larger ND packets (yes, I am very familiar with SeND), can be sent less often. >> 2) multicast is not assumed, so the Whiteboard is used. Pascal> The routers could still use NS/NA between them but that Pascal> makes little sense I agree. RPL routers use NA as unicast to Pascal> their parent, a role that 6LoWPAN NR can perfectly play Yes, we can certainly put DAOs on the NR/NC, once you know about the parent. But, what's the point of running RPL on that node? It can not talk to any other nodes unless they can also see the same whiteboard, which means that the nodes can not have children. >> 3) nodes that are sleepy, are not going to be useful as members >> of an RPL DAG, so really, it's about RPL between the Edge >> Routers. Pascal> In my mind the edge router is usually also the root for a Pascal> RPL DAG. I agree that this is reasonable. What I do not understand is how/why you would run both RPL and 6LoWPAN on the other nodes. If they have connectivity to the edge router to be able to send it updates for the Whiteboard, then you have... well.. connectivity. (look at diagram on page 13 of nd-06.txt) If you do not have connectivity to the Whiteboard/EdgeRouter, and you are trying to use RPL to reach it (which I think a lot of people want to do), then you need to broadcast/multicast a DAO somehow, such that you can find a parent with a DAG to join. But, to do that, you need at least a link-scope address to use (which I think you need to do DAD on, right? or does one skip that for link-scope addresses...), and you need to be able to multicast/broadcast. 6LoWPAN provided the whiteboard because multicast didn't work, so it seems like you can not put RPL on nodes that aren't directly connected to the whiteboard. And if you have a node that can run RPL, then it doesn't need 6LoWPAN either. >> It seems to me therefore that the only nodes in a 6lowpan that >> can participate in a RPL DAG would be the edge router that runs a >> Whiteboard. Pascal> RPL is the prime protocol for a route-over 6LoWPAN Pascal> network. So we must make it work, and hopefully it does. I agree that we all want it to work. I'm just not sure that we do not have an impedance mismatch here. I'm not a 6LoWPAN expert (and none of my consulting customers wanted me to be). new acronym: IANA6L. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jhui@archrock.com Tue Oct 13 09:46:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562C728C2C1 for ; Tue, 13 Oct 2009 09:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5xlK-H3j3W4 for ; Tue, 13 Oct 2009 09:46:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 843B228C247 for ; Tue, 13 Oct 2009 09:46:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 09C02AF83C; Tue, 13 Oct 2009 09:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlQTf7zuR09p; Tue, 13 Oct 2009 09:45:57 -0700 (PDT) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 10E3FAF83B; Tue, 13 Oct 2009 09:45:57 -0700 (PDT) Message-Id: From: Jonathan Hui To: Richard Kelsey In-Reply-To: <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 13 Oct 2009 09:45:56 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 16:46:01 -0000 On Oct 13, 2009, at 9:02 AM, Richard Kelsey wrote: > We have to be careful not to learn the wrong lesson. > Hopcount without careful link assessment definitely doesn't > work. Hopcount limited to stable, symmetric links is a > different beast entirely. For example, consider the Cost/PL > column in table 1 of [1], which gives the average > transmissions per link. For most of the networks it is very > close to 1 and it never goes above 2. That's puts ETX > pretty close to hopcount for those networks, if routing is > limited to links with good ETX. I agree. The challenge is that we really do want to minimize the number of transmissions to reach the destination, modulo details that are specific to the link protocol. Simple hop count didn't work because of the tension between wanting to only use only 'good' links, but also utilizing 'okay' links, or even 'bad' links when necessary to keep the network connected an functioning. > So let me propose a reliability metric with two hopcounts, > one for 'good' links and the other for 'okay' ones. To make > it more concrete: > > 'Good' links have a current ETX < 1.5 and are expected to > stay working throughout a maximum RA-DIO interval (which I > think is given by 2^(DIOIntervalMin + DIOIntervalDoublings)) > 99% of the time. > > 'Okay' links have an ETX < 3.0 and are expected to be > working throughout a maximum RA-DIO interval 80% of the time. As I mentioned before, I do think the distinction of 'good' and 'okay' links is a useful one, and I like that it distills information into simple concepts. In general, a number of parameters (ETX, RSSI, SNR, SINR, chip correlation) will be used to discern between 'good', 'okay', and 'bad' links. What parameters may be used depends on the particular hardware/software capabilities of each node. How those parameters are computed depends on the particular implementation as well (sampling methods, time scales, etc). I'm not convinced that ETX as defined should be THE reliability metric simply because it's not good at discerning between 'good' and 'okay' links, but I am convinced that it is a useful input. > When comparing, five 'good' hops would be equivalent of one > 'okay' one. > > I pulled the numbers (1.5, 99%, 3.0, 80% and five) out of > thin air. Real values would have to be chosen with care. And these numbers will be, like it or not, dependent on the properties of the particular radio hardware, link protocols, software implementation, etc. Better to give some general guidelines of what a 'good' vs. 'okay' vs. 'bad' link is and guide implementations best we can. -- Jonathan Hui From richard.kelsey@ember.com Tue Oct 13 11:21:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E5B28C1C3 for ; Tue, 13 Oct 2009 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz7Y6juqCJVx for ; Tue, 13 Oct 2009 11:21:56 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 229B728C1BC for ; Tue, 13 Oct 2009 11:21:56 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 14:23:03 -0400 Date: Tue, 13 Oct 2009 14:20:14 -0400 Message-Id: <87my3v9mw1.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Mon, 12 Oct 2009 14:54:06 -0700) From: Richard Kelsey References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <2863E9BF-442B-4F7C-8415-1BE4192DE977@cisco.com> <878wfgbse1.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 13 Oct 2009 18:23:03.0901 (UTC) FILETIME=[340FD8D0:01CA4C32] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 13 Oct 2009 18:21:57 -0000 From: Philip Levis Date: Mon, 12 Oct 2009 14:54:06 -0700 On Oct 12, 2009, at 7:26 AM, Richard Kelsey wrote: > My point is that the key metric for reliability is not the > RTX for a message right now, or any similar metric, but an > estimate of the stability of the link itself. We need to > preferentially use stable links. If the DAG can reconfigure very quickly, then the need to prefer stable links disappears. E.g., there's a paper appearing in SenSys this year (Bursty Traffic over Bursty Links) that finds using very transient links can reduce path length and improve throughput. That's an interesting paper, but I think it supports my point that the core routing needs to use stable links when possible. In the paper they set up a base tree using stable links and then opportunistically skip ahead using transient links as available. Distinguishing between stable and bursty links is the key to what they are doing. If the DAG cannot reconfigure or repair quickly, then stable links are important. But by constraining a protocol to only using stable links, we would lose any possible benefits of rapid recovery. This seems like putting the horse before the cart. I do not think anyone has proposed that we constrain the protocol to only using stable links. I do think that attempting to have at least a tree of stable links is important. One possibility would be to have the preferred parent be one connected by a strong link, but allow other parents to use less stable, and hopefully longer, links. This would allow a middle ground between reliability and efficiency. -Richard Kelsey From pthubert@cisco.com Wed Oct 14 03:33:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F7128C1A1; Wed, 14 Oct 2009 03:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.3 X-Spam-Level: X-Spam-Status: No, score=-9.3 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4dp9yVEffCP; Wed, 14 Oct 2009 03:33:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EB57428C14B; Wed, 14 Oct 2009 03:33:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8857; q=dns/txt; s=amsiport01001; t=1255516398; x=1256725998; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20NA=20to=20transport=20DA O|Date:=20Wed,=2014=20Oct=202009=2012:33:07=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D66E79E@XM B-AMS-107.cisco.com>|To:=20"Michael=20Richardson"=20,=20"IETF=20ROLL"=20,=0D=0A =20=20=20=20=20=20=20=20"6lowpan"=20<6lowpan@ietf.org> |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<21375.1255452103@marajade.sande lman.ca>|References:=20=20<21375.1255452103@mar ajade.sandelman.ca>; bh=pvZBock4206ChoxYKtqjRk6w7WjM9gbgQyc1nsiXvuU=; b=OavLn8oEtmvmERQf16ZqfOhtRcHUqqTDMktgDDw/jzenio8dvddvYz68 rtdbSreRNxcTAkSPpp23fhUkTKQRMbMCbSygVyRPFdb4Y0+/PV09c7Qo6 40Z2EdHyaN7M/LLwjBXGsfoz97vHOo0bm13KTPBnsRPy/kMeBg0y8tvOs I=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkAAPdF1UqQ/uCWe2dsb2JhbACbBwEBFiQGpGKYW4QtBIFb X-IronPort-AV: E=Sophos;i="4.44,556,1249257600"; d="scan'208";a="51752146" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 10:33:13 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EAXDCh011960; Wed, 14 Oct 2009 10:33:13 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:33:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 12:33:07 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E79E@XMB-AMS-107.cisco.com> In-Reply-To: <21375.1255452103@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] NA to transport DAO Thread-Index: AcpMJBVUcIQ8qULNRgatnkcX97Y/iAAdXOww References: <21375.1255452103@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , "IETF ROLL" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 14 Oct 2009 10:33:12.0961 (UTC) FILETIME=[BB5D8710:01CA4CB9] Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 14 Oct 2009 10:33:18 -0000 Hi Michael Thanks a lot for this discussion :) >(You'll want to edit your mailer to not reply to SMTP from addresses, as >you CC'ed roll-bounces@ietf.org, which you certainly do not want to do) > >>>>>> "Jerald" =3D=3D Jerald P Martocci = writes: > Jerald> I guess I am one of those people that think that other > Jerald> 6LoWPAN nodes must participate in RPL. Unless I am missing > Jerald> something RPL is the only game in town regarding meshing of > Jerald> wireless sensors. If they are not in RPL is there another > Jerald> means that they can use to form mesh connectivity to get to > Jerald> the LBR? > >As far as I can tell 6LoWPAN-nd and RPL are somewhat complementary, and >somewhat overlapping. 6lowpan-ND was designed with route over in mind from day 1, that was part of the Dublin vote. And one of the objectives of the authors has always been to make those 2 work together. You'll find that some of the authors are actually working on both drafts in parallel. Now we (and I assume my own responsibility there) might have missed something on the way. But I'm certainly interested in discussing and fixing anything that might be an issue between the 2, and hear more about the overlap that you found. It is high time since we will probably be asking for WGLC very soon. At the moment, the issues I'm aware of are: - RPL does not mention NR/NC. There's a point where it should enable the use of those messages as an alternate or a replacement to NA unicast - ND does not impose that nodes should send NA multicast after NR/NC flow though the new RPL P2P expects it? Anything else we should concentrate on? >>>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > writes: > >> Some things immediately jump out at me: 1) small packets are much > >> more common, so DAOs may not fit into ND. > > Pascal> This is a non issue. IPv6 on any link requires an MTU of at > Pascal> least 1280. 6LoWPAN provides a fragmentation mechanism for > Pascal> those link layers that could hold the IPv6 MTU in a frame. > Pascal> Above the IPv6 MTU, you can still fragment the ND packet > Pascal> using IPv6 fragmentation. This is more common than you > Pascal> might think, as traditional ND packets can get real big, for > Pascal> instance in the presence of SeND. > >Uhm, the fact that 6LoWPAN provides a fragmentation mechanism is not >important. What this means is that a single ND packet now takes >multiple packets. One of the arguments against putting DAOs in the ND >is that they do not go often enough, and therefore we would have to send >more ND packets, which means more energy. I'm sure you mean multiple frames for one ND packet. And yes, the frames being small in 15.4, there's a point where you need multiple of them, and there's overhead etc... This is a real issue certainly at L2 but there's nothing IP can do about it, and whether you call the packet a NA or something else will not make a difference there.=20 My point was that L3 cannot and does not make a difference so from that standpoint, it is a non issue. What we must clearly do for DAO as for anything else is try to be concise in our protocol. After that, some additional technology might be specifically put in place over certain links for additional blocking or compression, like 6LoWPAN HC for instance. > >If in fact the ND will be fragmented by the layer-2 for delivery, then >we might well be better off to send the more frequent DAOs in their own >packet, ideally one which 6LoWPAN can carry without fragmentation. >That's a win because then the much larger ND packets (yes, I am very >familiar with SeND), can be sent less often. > > >> 2) multicast is not assumed, so the Whiteboard is used. > > Pascal> The routers could still use NS/NA between them but that > Pascal> makes little sense I agree. RPL routers use NA as unicast to > Pascal> their parent, a role that 6LoWPAN NR can perfectly play > >Yes, we can certainly put DAOs on the NR/NC, once you know about the >parent. > >But, what's the point of running RPL on that node? It can not talk to >any other nodes unless they can also see the same whiteboard, which >means that the nodes cannot have children. > > >> 3) nodes that are sleepy, are not going to be useful as members > >> of an RPL DAG, so really, it's about RPL between the Edge > >> Routers. > > Pascal> In my mind the edge router is usually also the root for a > Pascal> RPL DAG. > >I agree that this is reasonable. > >What I do not understand is how/why you would run both RPL and 6LoWPAN >on the other nodes. If they have connectivity to the edge router to be >able to send it updates for the Whiteboard, then you >have... well.. connectivity. > >(look at diagram on page 13 of nd-06.txt) > >If you do not have connectivity to the Whiteboard/EdgeRouter, and you >are trying to use RPL to reach it (which I think a lot of people want to >do), then you need to broadcast/multicast a DAO somehow, such that you >can find a parent with a DAG to join. You right. In route-over, most of the nodes might need a DAG to reach the white board. IOW they are not in direct line of sight and attach to a router deep in the DAG. As you figure, the lucky ones that are will attach to the white board. The brd/mlt cast is that of RA-DIO. >But, to do that, you need at least a link-scope address to use (which I >think you need to do DAD on, right? or does one skip that for link-scope >addresses...), and you need to be able to multicast/broadcast. > >6LoWPAN provided the whiteboard because multicast didn't work, so it >seems like you can not put RPL on nodes that aren't directly >connected to the whiteboard. And if you have a node that can run RPL, >then it doesn't need 6LoWPAN either. Note: In route-over, the link local address is only used over one radio hop but its uniqueness is checked on the whole subnet - the larger non transitive link that might incorporate a backbone and multiple RPL DAGs, e.g. the whole diagram on page 13 of nd-06.txt - by the whiteboard. Here's how it could go if we bind RPL over NR/NC:=20 1) As the DAG forms, a RPL router discovers its parents. If the ND operation on the link is based on NR/NC then it makes sense for the OCP to favor a parent that can reach a whiteboard so that a single NR can be used for RPL DAOs and to maintain the registration of its own addresses at the same time. 2) Then the router obtains a link local and a global address using the whiteboard via its parent(s). The parent is already part of the DAG so it can relay the registration. The DAOs for the router's prefixes if it has any are included in the NR. So would be the fact that the node is a router, so that parents disable address filtering upon acceptance by the whiteboard. 3) Upon successful completion from the white board, the parent installs a binding to the address, and a route to the prefix via the address. For a global address it could do either way, my take is bind the link local to the mac address for address resolution, and for anything (global addresses, prefixes and mcast DAOs) install routes via the link local.=20 4) The parent also sets up RPL as to add the router's prefix (and/or address) information in its own DAOs. 5) The parent sends a successful completion to the router 6) The router now owns its address(es), the right to be a router, can send its owns RA-DIOs indicating that it can reach the whiteboard, and the process recurses Note: Extending 6LoWPAN ND for RPL is relatively consequent piece of work, similar in essence to what NEMO is to MIPv6. This will require a new draft for sure. At the moment, what we really need from 6LoWPAN ND is to enable this as we see it coming.=20 Potentially, this could mean that we need to enable the capability to bind additional stuff in a same NS and probably couple the global and the link local binding in a single message. We also need to think of adding a 'router' bit to change the source address validation. That discussion belongs to the 6LoWPAN list... > > >> It seems to me therefore that the only nodes in a 6lowpan that > >> can participate in a RPL DAG would be the edge router that runs a > >> Whiteboard. > > Pascal> RPL is the prime protocol for a route-over 6LoWPAN > Pascal> network. So we must make it work, and hopefully it does. > >I agree that we all want it to work. >I'm just not sure that we do not have an impedance mismatch here. > >I'm not a 6LoWPAN expert (and none of my consulting customers wanted me >to be). >new acronym: IANA6L. ? sorry I missed that Pascal From emmanuel.baccelli@gmail.com Wed Oct 14 06:53:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FD73A67F5 for ; Wed, 14 Oct 2009 06:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o120U8shsJd3 for ; Wed, 14 Oct 2009 06:53:30 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 644373A69FD for ; Wed, 14 Oct 2009 06:53:23 -0700 (PDT) Received: by gxk4 with SMTP id 4so11964465gxk.8 for ; Wed, 14 Oct 2009 06:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=QJewlAhLtIU3O9EbcNakUB5OB6N185MkKgvs0GIKJwY=; b=P0BjAVsAe7MB2ZIY8buRmoLdprS2yghce4KRVmiDnl6xHhsTuXygOQNfaUcj/JOiJI +iIOLWpQZ1zAQqrGP7OU4MluL4lNyUjmoGolWpFd2JO8xC7DKst/fsyyguUjYUxP7m4a GSptB9AxNq6yVHKDS1s5usILiXSJy7Z78zNvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=Iw3nE6egYbO//elREYnIxQpmORoMYq84zMFiF0RofqUf/QrvBD/2L19WiulrqgiKtA e7Zo7mjNVBIwza0gqPQStExZh0cSd6q5Xpuj+czXKxDdTks+hw/6DwCWiej6dcEEzayY 64usKwrc1TFUteTBLl8qNT0jG+1nB3df5t58o= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.91.97.9 with SMTP id z9mr5150103agl.46.1255528402140; Wed, 14 Oct 2009 06:53:22 -0700 (PDT) From: Emmanuel Baccelli Date: Wed, 14 Oct 2009 15:53:02 +0200 X-Google-Sender-Auth: d929491ea71427c3 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=0016e64098c66a3f250475e57c39 Subject: [Roll] feedback on draft-ietf-roll-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 14 Oct 2009 13:53:32 -0000 --0016e64098c66a3f250475e57c39 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here are some comments I have about the new version of the RPL draft (draft-ietf-roll-rpl-03). General comment: the document is still 100 pages long, similar to -02, and does not take into account the consensus reached at the interim meeting in Geneva, regarding the needed simplification of the draft. I think that at this point, just like we discussed at the interim, we should revamp the structure of the doc. Aiming to steer in that direction, here are some initial, more detailed, comments on the document up to section 4: # Section 1.1: the "core set of functionalities" are not explicitely listed. I think they must be in order to effectively revamp the structure. Just saying: "being able to operate in the most severe environment" is too vague. What exactly do we want to be able to do in such environment? Communication between sensors? Communication from sensor to sink? Communication from sink to sensor? With what QoS? This needs to be very explicit at this point. It will help the whole document a lot. I think at this point we could bluntly say something like: " In this specification, we focus on: - enabling communication from sensors to a well-known destination, - enabling the formation of paths towards this destination that optimize a given metric, - the choice of which metric to use is outside of the scope of this document. " # Section 2 I am wondering if some of the terms are unecessary at this point. In particular, DAG siblings. Since siblings introduce quite a tricky complexity/benefit trade-off, I would be in favor of getting rid of these in the core RPL document. This could be a welcomed simplification. # Sections 3.1.1. up to 3.1.3. I think these sections should be collapsed in a new Applicability section. By the way, I still have a hard time understanding what is meant by "constraint-based" routing. Are we sure this document is where we want to talk about this in the core RPL document anyways? # Section 3.2: The first paragraphs should be collapsed in the above mentionned Applicability section. # Section 3.2.1: "RPL constructs one or more DAGs". The consensus is that the core RPL document should specify how to build a single DAG to reach a single destination. This may be used to simplify the document a bit. # Sections 3.2.1.2 and 3.2.1.4 : These can proabably be trimmed down since we should just talking about one DAG in the document. # Section 3.2.2. Ideally, I still think such communication, from sink to sensor, is a different matter that should be addressed in a companion document... This would make the core RPL document focused, clearer and shorter. # Section 3.3. This section can be made much shorter, especially if we do not consider siblings. # Section 3.5. This section is either saying too much or saying not enough. So either we expand on the subject of "reactive" behavior, or we just do not mention it at this point. # Section 4. Part of this section should be collapsed in the new Applicability section. The rest may be out of scope (probably more part of the metrics document?) Regards, Emmanuel --0016e64098c66a3f250475e57c39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Here are some comments I have about t= he new version of the RPL draft (draft-ietf-roll-rpl-03).

General comment: the document is still 100 pages long, similar to -= 02, and does not take into account the consensus reached at the interim mee= ting in Geneva, regarding the needed simplification of the draft.=A0

I think that at this point, just like we discussed at t= he interim, we should revamp the structure of the doc. Aiming to steer in t= hat direction, here are some initial, more detailed, comments on the docume= nt up to section 4:

# Section 1.1:=A0
the "core set of funct= ionalities" are not explicitely listed. I think they must be in order = to effectively revamp the structure. Just saying: "being able to opera= te in the most severe environment" is too vague. What exactly do we wa= nt to be able to do in such environment? Communication between sensors? Com= munication from sensor to sink? Communication from sink to sensor? With wha= t QoS? This needs to be very explicit at this point. It will help the whole= document a lot.=A0

I think at this point we could bluntly say something li= ke:=A0
"
In this specification, we focus on:
=
- enabling communication from sensors to a well-known destination,
- enabling the formation of paths towards this destination that optimi= ze a given metric,
- the choice of which metric to use is outside= of the scope of this document.
"

# Section 2
I am wondering if some of the terms are unecessary at= this point. In particular, DAG siblings. Since siblings introduce quite a = tricky complexity/benefit trade-off, I would be in =A0favor of getting rid = of these in the core RPL document. This could be a welcomed simplification.=


# Sections 3.1.1. up to 3.1.3.=A0
<= div>I think these sections should be collapsed in a new Applicability secti= on. By the way, I still have a hard time understanding what is meant by &qu= ot;constraint-based" routing. Are we sure this document is where we wa= nt to talk about this in the core RPL document anyways?

# Section 3.2:=A0
The first paragraphs should= be collapsed in the above mentionned Applicability section.

=
# Section 3.2.1:=A0
"RPL constructs one or more D= AGs". The consensus is that the core RPL document should specify how t= o build a single DAG to reach a single destination. This may be used to sim= plify the document a bit.

# Sections 3.2.1.2 and 3.2.1.4 :=A0
These can= proabably be trimmed down since we should just talking about one DAG in th= e document.

# Section 3.2.2.
Ideally, I = still think such communication, from sink to sensor, is a different matter = that should be addressed in a companion document... This would make the cor= e RPL document focused, clearer and shorter.

# Section 3.3.
This section can be made much = shorter, especially if we do not consider siblings.

# Section 3.5.
This section is either saying too much or saying= not enough. So either we expand on the subject of "reactive" beh= avior, or we just do not mention it at this point.

# Section 4.
Part of this section should be c= ollapsed in the new Applicability section. The rest may be out of scope (pr= obably more part of the metrics document?)


Regards,
Emmanuel
--0016e64098c66a3f250475e57c39-- From anders.jagd@ekasystems.com Wed Oct 14 13:29:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289B83A6898 for ; Wed, 14 Oct 2009 13:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y94edJ4-rKwN for ; Wed, 14 Oct 2009 13:29:41 -0700 (PDT) Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by core3.amsl.com (Postfix) with SMTP id 9BC0E3A682B for ; Wed, 14 Oct 2009 13:29:40 -0700 (PDT) Received: (qmail 57517 invoked from network); 14 Oct 2009 20:29:41 -0000 Received: from unknown (HELO AndersLaptop) (anders.jagd@209.48.242.70 with login) by smtp110.biz.mail.re2.yahoo.com with SMTP; 14 Oct 2009 20:29:41 -0000 X-Yahoo-SMTP: Z9nti1.swBBshEkcTT58JGsSW0GG0Kgu_9V27Bc_1Irb1gnWTbAo X-YMail-OSG: PCOZt8cVM1lPYw6X05S4i.7PQT.7eMiD1.j.BXyGPCFeHtSua_1LxYczbxYD2zJ7Uugxb7cKtZzERa4KBJDuAiWSv9CuRISQvLLMa6wcZuXgCulkG8lQWd1ZTbdjhZ6aVXwSrNs6DYLkG9K0Af94PcT8tJPWH_NcLslkaYCeOg.tZgGQ8YkL_jMUHjqCcIg7gmwv.pSiFaFmmKOAG.aP1vmLS2GZohBd5j4mjTdnG1Fu280WjK1EosTglIKEHOq6jpS_hG8mk.Xhh0tL8cQXCoYKdnQERgZnCkMsnpzzhQ6yGcq5q5e5NJdblNEaq_6t X-Yahoo-Newman-Property: ymail-3 From: "Anders Jagd" To: Date: Wed, 14 Oct 2009 16:29:41 -0400 Organization: Eka Systems Message-ID: <000301ca4d0d$0f71a4a0$2e54ede0$@jagd@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpNDQ76o/ppScGtSP+c0WnjD1l6MA== Content-Language: en-us Subject: [Roll] Review of rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 14 Oct 2009 20:29:42 -0000 Roll mailing list, I recently started monitoring this mailing list as well as catching up on RPL, specifically draft-ietf-roll-rpl-03. Through this mail, I would like to offer my "first time reader" feedback. I am aware of various mail threads addressing some of the below topics. I have tried not to repeat comments/questions made by others, and it is generally not my intention to reopen old debates. However, being new to this list, I am less than 100% in sync with all previous discussions, and thus run the risk of repeating old comments. In these cases, please feel free to refer me to the "FAQ" :) BTW, my name is Anders Jagd, and I work for Eka Systems. Here goes: Section 1.1 319 each instantiation of the protocol to be optimized in terms of 320 required code space. It must be noted that RPL is not restricted Suggest change to "required code space and other limited computation resources" Section 2 407 each DAG that a node is a member of, the node will maintain a 408 set of DAG siblings. If a node is a member of multiple DAGs Suggest change to "may maintain a set of DAG siblings" Section 3.3.1 Should RPL discourage "soft greediness", where a node initially joining a DAG chooses to enter at a higher rank than it could have done ? Section 3.3.4 1263 has subsequently cleaned up the state. This loop happens when a no- 1264 DAO was missed till a heartbeat cleans up all states. The DAO loop General comment: Document includes some "forward references". In this example "no-DAO" has not been defined previously. Section 5.1.1 1545 Length: 8-bit unsigned integer set to 4 when there is no suboption. 1546 The length of the option (including the type and length fields "4" does not match Figure 1 (Figure one has 4.5 "8 octet units") 1662 The following values MUST NOT change during the propagation of RA-DIO 1663 messages outwards along the DAG: Type, Length, G, DAGPreference, 1664 DAGDelay and DAGID. All other fields of the RA-DIO message are 1665 updated at each hop of the propagation. List not complete - what about D, A, Sequence number, DIOIntDouble, DIOIntMin ? Section 5.1.1 (general) - Do we need 8 bit for sequence number ? - Do we need 8 bit for DAGPreference ? - Is one byte enough for DAGRank ? - Do we need BootTimeRandom, NodePref at all, and if so, do they need to be so big ? I understand the collision scenario with associated "risk window", but do we need this tie-breaker, as opposed to simply discarding everything within risk window regardless of any tie-breaker ? If the answer is "yes, we need it", then should we at least consider making it less costly (less bits ?) - Can we come up with less "expensive" PathDigest ? Meaning less than 32 bit, and something less computationally intensive than CRC. Also, do we need PathDigest at all, given that we have the "D" bit to trigger DA ? - DAGRank: Is rank of root "typically 1" or "always 1" ? Document not quite consistent. Since a root could "exaggerate" it's rank, I assume "typically" is correct, but 5.3.1 seems to indicate otherwise: 2040 1. A node that does not have any DAG parents in a DAG is the root 2041 of its own floating DAG. It's rank is 1. A node will end up in Section 5.1.1.1.5 1803 The Destination Prefix suboption has an alignment requirement of 1804 4n+1. Its format is as follows: "4n+1" is a bit unclear to me. Section 5.2.2 1913 it is expected to produce a different and unique DAGID for each of 1914 the multiple DAGs. Suggest change: "expected to" to be replaced with "MUST" Section 5.3.1 2099 rank, or whatever metrics the LLN cares to use. A node may jump Suggest change: "whatever metric the LLN cares to use" replaced by "metrics defined by the OCP" Section 5.3.2.2 2227 If the other DAG is now empty of candidate parents, then 2228 directly follow SRC into the new DAG by adding it as a DAG Could the node have another choice (jumping to a parent in a third DAG) ? 2252 described in Section 5.3. When a node adds another node to its set 2253 of candidate parents, the node becomes attached to the DAG through 2254 the parent node. Not exactly - the new node simply becomes another "candidate parent" Section 5.3.3 2302 overhead and saving energy consumption (which is of utmost 2303 importance for battery-operated nodes). Suggest to delete "(which is of .....)" (Not to say it is not true, but may not belong in section 5) 2344 (2^DIOIntervalMin)ms. The default value is 2345 DEFAULT_DIO_INTERVAL_MIN. Suggest to clarify that the default at this point is simply given a "name". This (I assume) to facilitate later reference to this when actual values are discussed. Section 5.3.4.1. Resetting the Trickle Timer It wasn't obvious to me at first that this is all done in order to limit the amount of localized traffic/congestion due to broadcasts from parent nodes (i.e. "make children be quiet if their parents are talking a lot", if I understand it correctly). May want to clarify for sake of readability. Section 5.7 2490 preferred DAG parent and its rank. At that time any 2491 remaining DAG parents of greater rank than this node must Shouldn't it be "greater than or equal rank" ? Section 5.7.1 2534 A new DAG is discovered upon receiving a RA message with or without a 2535 DIO. The node joins the DAG by selecting the source of the RA It took me a while to realize this must be coming from a "non RPL" node. Suggest to clarify for readability (incl. the whole "rank 0" concept). 2553 The duration of the DAG Hop timer depends on the DAG Delay of the new 2554 DAG and on the rank of candidate parent that triggers it: (candidates 2555 rank + random) * candidate's DAG_delay (where 0 <= random < 1). It 2556 is randomized in order to limit collisions and synchronizations. I understand "random" may be important in order to manage nodes that somehow get in sync. But I suggest "random" may also be difficult/"expensive" to implement (sure, it doesn't say how random it has to be, but still). I believe I understand the intention behind making the timer depend on the "candidate rank that would be achieved in DAG"; in the sense that it allows for other/better parents to be discovered within this time. However, could we somehow avoid "random" ? How is this impacted by the ongoing thread regarding use of "Sequence number" vs "Hop timer" ? Section 5.7.3. Collision As discussed above, can this "risk window" be handled less expensively ? (less bits in RA-DIO for "tie-breaker" or no "tie-breaker" at all) Section 5.7.4 2623 A node is instable when it is prepared to shortly replace a set of 2624 DAG parents in order to jump to a different DAGID. This happens Suggest to rephrase (node jumps to a different DAG, not a different DAGID) Section 5.8.1 2695 o The OF scans all the candidate neighbors on the possible 2696 interfaces to check whether they can act as an attachment router Suggest to replace "attachment router" with "router" 2702 o The OF computes self's rank by adding the step of rank to that 2703 candidate to the rank of that candidate. The step of rank is 2704 estimated as follows: Suggest to replace "estimated" with "based upon" 2757 * Candidate neighbors that are of worse rank than self are 2758 ignored 2759 2760 * Candidate neighbors of a better rank than self (non-siblings) 2761 are preferred For completeness: There is no description of handling of "Candidate neighbors of same rank" (siblings) Also, suggest to replace "worse rank" with "higher rank". Section 5.8.2 2766 corresponding to OCP codepoint 0. This is a very simple reference to 2767 help design more complex Objective Functions. In particular, the This makes it sound like OCP-0 is merely a "template". It is of course more than that, being the "default" OCP. 2773 This document specifies a default objective metric, called OF0, and 2774 using the OCP 0. OF0 is the default objective function of RPL, and Is OFO "default objective metric" or "default objective function" (acronym matches neither) Section 5.8.2.2 2819 4. If none are grounded then a DAG with a more preferred 2820 administrative preference is better. Is this DAGPreference from RA-DIO ? (unclear to me) Section 5.9.2.1 3183 o A counter of retries to count how many RA-DIO messages were sent 3184 on the interface to the advertising neighbor without reachability 3185 confirmation for the prefix. At this point it may not be quite clear to the reader that this is related to requesting a DA but not receiving it (if I understand correctly). Suggest to clarify. Section 5.9.2.4 3369 o Destination advertisement operation stopped: All entries in the 3370 abstract lists are freed. All the routes learned from NA-DAO 3371 messages are removed. Why would a node stop DA operation once commenced ? Section 7.1.2 3677 A RPL implementation SHOULD allow configuring the following routing 3678 protocol parameters, which are further described in Section 5.1.1: I don't think PathDigest belongs in this list (nothing to configure, it is by definition initialized to zero by root) 3715 DAG Hop Timer: A RPL implementation MUST provide the ability to Wouldn't it be more precise to describe configuration of DagDelay, since "Hop Timer" is based on DagDelay. Section 7.1.5 3771 o The Remove timer "Remove timer" or "DestroyTimer" ? (Document seems to be inconsistent) /Anders (Jagd) From jvasseur@cisco.com Wed Oct 14 15:55:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B06323A6902 for ; Wed, 14 Oct 2009 15:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvKyZniI-G+x for ; Wed, 14 Oct 2009 15:55:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6B2503A688B for ; Wed, 14 Oct 2009 15:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=6157; q=dns/txt; s=sjiport06001; t=1255560931; x=1256770531; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Metric=20ID|Date:=20Wed,=2014=20Oct =202009=2012:53:01=20-0700|Message-Id:=20<398C7109-CC53-4 90D-8175-638BF76DCE25@cisco.com>|To:=20"Anders=20Brandt" =20|Cc:=20"Tim=20Winter"=20,=20|Mime-Version:=201.0=20(Apple=20Me ssage=20framework=20v936)|Content-Transfer-Encoding:=207b it|In-Reply-To:=20<6D9687E95918C04A8B30A7D6DA805A3E01429B 26@zensys17.zensys.local>|References:=20<1743477406.15552 751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu> <4ACF43CC.2020303@acm.org>=20<1AA77E89-F83F-4BFD-92FF-657 E4C9B9739@cisco.com>=20<6D9687E95918C04A8B30A7D6DA805A3E0 1429B26@zensys17.zensys.local>; bh=9K/uHAuvFGY4Liw41MH5YJL7eD+87tQJfJ6DfhJ5F7o=; b=JKhMB77rZBh2u79Cnz4mXKzFqOS2NZhPVcRqReST2u4Nh5lIzgM6HFGw y2AFptCT39JjIqK1N9eLeA/dpV+mMqUnUEeYdej87aS9xq5cXf1DLeymU c/dbHqZnC5yAS267+08PXhg5oX/29ZdGEi5IE5OwvRzbQctmvlzD4zy+0 A=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIEABv01UqrR7Ht/2dsb2JhbABCwHGYb4InggcE X-IronPort-AV: E=Sophos;i="4.44,561,1249257600"; d="scan'208";a="409496076" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2009 22:55:31 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EMtW8q014728; Wed, 14 Oct 2009 22:55:32 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 15:55:32 -0700 Received: from [10.2.33.66] ([10.21.69.24]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 15:55:31 -0700 Message-Id: <398C7109-CC53-490D-8175-638BF76DCE25@cisco.com> From: JP Vasseur To: "Anders Brandt" In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01429B26@zensys17.zensys.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 12:53:01 -0700 References: <1743477406.15552751254944444717.JavaMail.root@mail02.pantherlink.uwm.edu><4ACF43CC.2020303@acm.org> <1AA77E89-F83F-4BFD-92FF-657E4C9B9739@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01429B26@zensys17.zensys.local> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 14 Oct 2009 22:55:31.0469 (UTC) FILETIME=[6E6283D0:01CA4D21] Cc: roll@ietf.org Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 14 Oct 2009 22:55:30 -0000 Hi, On Oct 13, 2009, at 11:12 AM, Anders Brandt wrote: >> Mukul Goyal wrote: >>> I think both latency and reliability are important metrics. > > Same for me. > > One word of warning on the energy discussion: > It seems like the assumption is that the routing protocol should > manage > the number of transmitted packets in order to ensure that the energy > consumption is distributed among more nodes. that would be the objective by using node energy level, which may be useful for SOME networks (not all for sure). > > There is however a caveat here: > From our experience, a radio uses energy. Period. > Receiving uses the same as transmitting - the difference is just which > amplifiers use the energy. > Thus, the way to use less energy is to use the radio less - i.e. sleep > some of the time. Which again translates into higher latency to reach > such nodes. Obviously, there is something to save, since a radio may > quickly determine if it is the intended recipient of a packet and > return > to sleep again OR receive the entire packet and stay awake to forward > the packet on to another node in the network. > > Thus, what I am trying to say is: > Unless the lower layers have a smart way of quickly returning to sleep > (which some technologies have) the routing protocol will keep all > nodes > awake within direct range - and they will all use power for > listening => > nothing gained from distributing the traffic. > Can battery-powered 802.15.4. nodes quickly return to sleep if they > are > not the intended recipient? > If not, the energy metric may be rather useless (?) I saw Adam answered already. JP. > > Cheers, > Anders > > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > JP Vasseur > Sent: 12. oktober 2009 13:46 > To: Tim Winter > Cc: roll@ietf.org > Subject: Re: [Roll] RPL Metric ID > > > On Oct 9, 2009, at 4:08 PM, Tim Winter wrote: > >> Mukul Goyal wrote: >>> I think both latency and reliability are important metrics. >>> >> +1 >> > > We have a good consensus to have both latency and reliability. We now > need to agree on the units. > > Unit for latency ? > > Unit for ETX (I propose to use the ETX): thoughts ? > >>> I am sort of negative on using memory/CPU availability as metric or >>> constraint. They seem like local factors to me. If a node is running >>> low on memory/CPU, it can simply not participate in routing. >>> >>> >> Exposing an exaggerated rank might also be an option. >> > > Indeed, although we have planned to use an Overload bit since we may > not > want all nodes to trigger a DAG recomputation but only to not send > traffic until the bit is cleared. > > Cheers. > > JP. > >> -Tim >>> Thanks >>> Mukul >>> ----- Original Message ----- >>> From: "JP Vasseur" >>> To: "IETF ROLL" >>> Cc: "Kris Pister" >>> Sent: Wednesday, October 7, 2009 1:07:52 PM GMT -06:00 US/Canada >>> Central >>> Subject: [Roll] RPL Metric ID >>> >>> >>> Dear all, >>> >>> We would appreciate your feed-back on RPL routing metrics. >>> >>> Now that RPL is stabilizing it is time to move forward with the >>> METRIC I-D. The next revision will be a major one, with packet >>> encoding, processing rules, etc. >>> >>> We discussed and agreed some time ago on several links and nodes >>> metrics (also required according to our requirement IDs). >>> >>> Still, there are a few metrics for which we would like to know >>> whether you think that they should be specified. >>> >>> 4.2. Latency >>> >>> >>> As with throughput, the latency of many LLN MAC sub-layers can >>> be varied over many orders of magnitude, again with a >>> corresponding change in current consumption. Some LLN MACs will >>> allow the latency to be adjusted globally on the subnet, or on a >>> link-by-link basis, or not at all. Some will insist that it be >>> fixed for a given link, but allow it to be variable from link to >>> link. For efficient operation, nodes must be able to report the >>> range of latency that their links can handle, and the currently >>> available latency. >>> >>> 4.3. Link reliability >>> >>> In LLNs, link reliability is degraded by external interference >>> and multi-path interference. Multipath typically affects both >>> directions on the link equally, whereas external interference is >>> sometimes uni- directional. Time scales vary from milliseconds >>> to days, and are often periodic and linked to human activity. >>> Packet error rate can generally be measured directly, and other >>> metrics (e.g. bit error rate, mean time between failures) are >>> typically derived from that. >>> >>> In addition: >>> >>> Node Memory resources: >>> >>> Memory is a critical node resources in presence of constrained >>> nodes. > >>> Is there a need to report node memory resources as a routing >>> metric/constraint ? >>> >>> Node CPU resources: CPU duty cycle for virtually all LLN >>> applications > >>> to date is well below 10%, and the trend in low power embedded >>> systems is to more capable processors rather than less. >>> Computational speed is not expected to be a limiting factor in >>> routing in LLNs. Is there a need to report node CPU resources as a >>> routing metric/constraint ? >>> >>> Link Security metrics >>> >>> Thanks for your feed-back. >>> >>> JP, Mijeon, Kris. _______________________________________________ >>> 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 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wintert@acm.org Wed Oct 14 17:34:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1693A6403 for ; Wed, 14 Oct 2009 17:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.308 X-Spam-Level: X-Spam-Status: No, score=-100.308 tagged_above=-999 required=5 tests=[AWL=2.290, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l+Tc67oTrRA for ; Wed, 14 Oct 2009 17:34:35 -0700 (PDT) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id EF8633A63EC for ; Wed, 14 Oct 2009 17:34:34 -0700 (PDT) Received: (qmail 35205 invoked from network); 15 Oct 2009 00:34:34 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 14 Oct 2009 17:34:34 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: KFRtTD8VM1m3X_jqbxgredQb5QluvjdpKle8v7DoIotcN_VJ1EULgCQcRfAx4xDbcAj2NNbuONVIhggexKdcLZdN.hEDIk64Lv.jgOtUugklFDvpFCX9_KLccHp0_nLSzPxlSJi_xxGaXS3nS_anVtiV8e0v7bt_Nj89CVBOI4mDMu8uVPa8eEbNATs2PnpVgGcQlNziLGhueLLyq96SuvirN3EmS8pEEL1wQgddkcZiLJkOzt0SiO4hD7LNDrrZjed8brszfUVgbNAKkfAJysssp9.ZkgiUoc3Xd0tw8nA4b3FhmgxoE39gmqgksvyFWsIJWbcNsxsBZJJuPCtrIbH.al0By4yMawTrRU28OKRw527nbQjSOB8JhQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD66E17.7040509@acm.org> Date: Wed, 14 Oct 2009 20:34:31 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Emmanuel Baccelli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] feedback on draft-ietf-roll-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 00:34:36 -0000 Hi Emmanuel, Thanks for preparing this feedback. We will work to incorporate your comments into the upcoming revision -04. A bit more inline below: Regards, -Tim Emmanuel Baccelli wrote: > Hi all, > > Here are some comments I have about the new version of the RPL draft > (draft-ietf-roll-rpl-03). > > General comment: the document is still 100 pages long, similar to -02, > and does not take into account the consensus reached at the interim > meeting in Geneva, regarding the needed simplification of the draft. > > I think that at this point, just like we discussed at the interim, we > should revamp the structure of the doc. Aiming to steer in that > direction, here are some initial, more detailed, comments on the > document up to section 4: > > # Section 1.1: > the "core set of functionalities" are not explicitely listed. I think > they must be in order to effectively revamp the structure. Just saying: > "being able to operate in the most severe environment" is too vague. > What exactly do we want to be able to do in such environment? > Communication between sensors? Communication from sensor to sink? > Communication from sink to sensor? With what QoS? This needs to be very > explicit at this point. It will help the whole document a lot. > > I think at this point we could bluntly say something like: > " > In this specification, we focus on: > - enabling communication from sensors to a well-known destination, > - enabling the formation of paths towards this destination that optimize > a given metric, > - the choice of which metric to use is outside of the scope of this > document. > " > > # Section 2 > I am wondering if some of the terms are unecessary at this point. In > particular, DAG siblings. Since siblings introduce quite a tricky > complexity/benefit trade-off, I would be in favor of getting rid of > these in the core RPL document. This could be a welcomed simplification. > > > # Sections 3.1.1. up to 3.1.3. > I think these sections should be collapsed in a new Applicability > section. By the way, I still have a hard time understanding what is > meant by "constraint-based" routing. Are we sure this document is where > we want to talk about this in the core RPL document anyways? > > # Section 3.2: > The first paragraphs should be collapsed in the above mentionned > Applicability section. Thanks for the suggestion. > > # Section 3.2.1: > "RPL constructs one or more DAGs". The consensus is that the core RPL > document should specify how to build a single DAG to reach a single > destination. This may be used to simplify the document a bit. This will be reflected in -04. > > # Sections 3.2.1.2 and 3.2.1.4 : > These can proabably be trimmed down since we should just talking about > one DAG in the document. > > # Section 3.2.2. > Ideally, I still think such communication, from sink to sensor, is a > different matter that should be addressed in a companion document... > This would make the core RPL document focused, clearer and shorter. Im not so sure this can be removed from the core document- the sink to sensor (outward) flow seems important to many applications, and provides the basis for the base P2P scheme supported by RPL as well. It is true that not all applications/deployments may use the functionality, but in support of interoperation all implementations should understand it. > > # Section 3.3. > This section can be made much shorter, especially if we do not consider > siblings. > > # Section 3.5. > This section is either saying too much or saying not enough. So either > we expand on the subject of "reactive" behavior, or we just do not > mention it at this point. Hmm.. I think you are right - this is getting a bit too detailed for section 3. > > # Section 4. > Part of this section should be collapsed in the new Applicability > section. The rest may be out of scope (probably more part of the metrics > document?) > > > Regards, > Emmanuel > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed Oct 14 18:07:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16AA3A682E for ; Wed, 14 Oct 2009 18:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtkostIIPjL4 for ; Wed, 14 Oct 2009 18:07:30 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 323B63A6359 for ; Wed, 14 Oct 2009 18:07:30 -0700 (PDT) Received: from [198.202.202.22] (helo=[172.19.130.65]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyEoT-0005qy-Fs; Wed, 14 Oct 2009 18:07:32 -0700 Message-Id: From: Philip Levis To: Sung Lee In-Reply-To: <4AB9F844.60603@us.fujitsu.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 16:06:35 -0700 References: <4AAA5CE0.9060008@us.fujitsu.com> <4AB0C269.3090203@cttc.es> <4AB3D4A1.60805@eecs.berkeley.edu> <4AB9F844.60603@us.fujitsu.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: roll@ietf.org Subject: Re: [Roll] Determining DADR Contributions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 01:07:30 -0000 On Sep 23, 2009, at 3:28 AM, Sung Lee wrote: > Mischa, Thomas, and ROLL WG members, > > We have *very preliminary* results from DADR implementation over > 802.15.4, indoor experiments. > Please note that these are preliminary results and we are continuing > with our experiments. More complete results for indoor and outdoor > will > be shared before the interim meeting. > > Some facts: > > * This summarizes the indoor, multi-floor office building experiment. > * Dimension of the building is roughly 30m x 20m, 2 floors involved > * There were several active WLAN APs (interference from 802.11 > present). Sung, What 802.15.4 channel did you use, and what 802.11 channels did the APs use? Phil From pal@cs.stanford.edu Wed Oct 14 18:13:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A033A6403 for ; Wed, 14 Oct 2009 18:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgwazDWFzjkq for ; Wed, 14 Oct 2009 18:13:52 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D8AD13A6359 for ; Wed, 14 Oct 2009 18:13:52 -0700 (PDT) Received: from [198.202.202.22] (helo=[172.19.130.65]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyEue-0006Ua-Mk; Wed, 14 Oct 2009 18:13:55 -0700 Message-Id: From: Philip Levis To: Jonathan Hui In-Reply-To: <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 18:13:48 -0700 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 1c1d34d4ae2aac1d1f929c6f17b0cb0c Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 01:13:53 -0000 On Oct 9, 2009, at 9:06 AM, Jonathan Hui wrote: > > Hi Richard, > > I agree that it is useful to discern between "okay" and "good" links. > > On Oct 9, 2009, at 7:07 AM, Richard Kelsey wrote: >> I believe that the white bit in the four-bit link estimator >> [1], has the effect of keeping traffic mostly on good links. >> Good links have few chip errors, okay links will likely have >> more. It appears that the four-bit link estimator does not >> do any averaging of the white bit. It would be interesting >> to determine how much of its performance is due to the use >> of the white bit and how much to its ETX estimation, and if >> it could be improved by averaging the white bit over time. > > The current tinyos-2.x implementation on the TI CC2420 uses the > radio's chip correlation feedback. It doesn't use the RSSI, let > alone compare it to the current noise floor. As you suspected, the > implementation also does not do any averaging over time and given > that CC2420's chip correlation value has high variability, averaging > is likely to help. But in my experience, chip correlation is still > a better measure of PRR than SNR. Said differently, chip > correlation does not adequately distinguish "okay" and "good" links > well. Right -- the assumption is that the real link estimation is with packets. Receiving a packet with a very high chip correlation index means that the link *at that time* had a high SNR, meaning it is likely a good enough link to try (white bit set). If the white bit isn't set, then a link has to go through a little bit of packet-based estimation before CTP Noe will try using it. > >> The 'okay' links cannot be ignored, as they are actually >> working at the moment and may be the only thing keeping the >> network connected. Any additive metric has to define how >> many good links are equivalent to one okay one. This isn't >> easy to do, because we would really prefer to use an okay >> link only if there is no path using only good links. Except >> in very unusual topologies, it is unlikely that you will >> ever be faced with a choice between one okay link and, say, >> five good ones. > > Mostly agree with this. One practical concern we have run into with > utilizing "okay" links is that network deployment/maintenance > becomes more complex for the end-user. If "okay" links are required > for connectivity, the network will appear to function well at times > but not others. For some end-users, it may be better not to > function at all if "okay" links is all you have when joining a > network. I agree that it's reasonable for an implementation to heavily favor "good" links over "okay" links (tradeoff potential efficiency for stability), or discard the use of okay links altogether. However, user/ application preference of behavior in the presence of only OK links should be left out of the protocol specification. Some applications would prefer "don't work unreliably" and others would prefer "do your best." Phil From wintert@acm.org Wed Oct 14 18:14:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A3E3A682E for ; Wed, 14 Oct 2009 18:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.453 X-Spam-Level: X-Spam-Status: No, score=-101.453 tagged_above=-999 required=5 tests=[AWL=1.145, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYEF7R-SjVZK for ; Wed, 14 Oct 2009 18:14:29 -0700 (PDT) Received: from smtp102.prem.mail.ac4.yahoo.com (smtp102.prem.mail.ac4.yahoo.com [76.13.13.41]) by core3.amsl.com (Postfix) with SMTP id 85DCA3A6403 for ; Wed, 14 Oct 2009 18:14:29 -0700 (PDT) Received: (qmail 92773 invoked from network); 15 Oct 2009 01:14:29 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp102.prem.mail.ac4.yahoo.com with SMTP; 14 Oct 2009 18:14:29 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: v3l5jMsVM1kRLQpqhUgKhxtE18uyWzugevUmb3ndfr_FZunLLpVO4KIbp9tmxwr3FMTDM3n_dIWCbDi9fFh5OibYMPCIndA04GkP_9ujf89lb7M8cTpOMpFzIC4TrVMekpA2BJuP4_1DCkS4CsNjpQ.fg6RXH4ikYmlGKBvXMS.AP2FRDJJ59hCTGTuQYxO7c50LjlqiVGYkIKHu_7LsTi9tmixdiK6dPtnMd4yW.ZyhSp9BZnD7w5waSeBS0EC230BQci3FzeAwczb43OlaXF67flICy0PLCFehPkvGdssh2vRc6AltR3zURxcC4xfmRovnwaSzlk21jzUlKRxX01WfWFA9xhvu6Rbbak5ccSs0SSueZU7Akcr7tIKqYDNnxisoJ9jJwg7A6W4LmODAbQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD67774.1010804@acm.org> Date: Wed, 14 Oct 2009 21:14:28 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Anders Jagd References: <000301ca4d0d$0f71a4a0$2e54ede0$@jagd@ekasystems.com> In-Reply-To: <000301ca4d0d$0f71a4a0$2e54ede0$@jagd@ekasystems.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Review of rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 01:14:31 -0000 Thanks Anders, We will work to incorporate your feedback into the upcoming -04. Some more comments inline below: Regards, -Tim Anders Jagd wrote: > Roll mailing list, > > I recently started monitoring this mailing list as well as catching up on > RPL, specifically draft-ietf-roll-rpl-03. Through this mail, I would like to > offer my "first time reader" feedback. > > I am aware of various mail threads addressing some of the below topics. I > have tried not to repeat comments/questions made by others, and it is > generally not my intention to reopen old debates. However, being new to this > list, I am less than 100% in sync with all previous discussions, and thus > run the risk of repeating old comments. In these cases, please feel free to > refer me to the "FAQ" :) > > BTW, my name is Anders Jagd, and I work for Eka Systems. > > Here goes: > > Section 1.1 > > 319 each instantiation of the protocol to be optimized in terms of > 320 required code space. It must be noted that RPL is not restricted > > Suggest change to "required code space and other limited computation > resources" > > Section 2 > > 407 each DAG that a node is a member of, the node will maintain a > 408 set of DAG siblings. If a node is a member of multiple DAGs > > Suggest change to "may maintain a set of DAG siblings" > > Section 3.3.1 > > Should RPL discourage "soft greediness", where a node initially joining a > DAG chooses to enter at a higher rank than it could have done ? > > Section 3.3.4 > > 1263 has subsequently cleaned up the state. This loop happens when a no- > 1264 DAO was missed till a heartbeat cleans up all states. The DAO loop > > General comment: Document includes some "forward references". > In this example "no-DAO" has not been defined previously. > > Section 5.1.1 > > 1545 Length: 8-bit unsigned integer set to 4 when there is no suboption. > 1546 The length of the option (including the type and length fields > > "4" does not match Figure 1 (Figure one has 4.5 "8 octet units") > > 1662 The following values MUST NOT change during the propagation of RA-DIO > 1663 messages outwards along the DAG: Type, Length, G, DAGPreference, > 1664 DAGDelay and DAGID. All other fields of the RA-DIO message are > 1665 updated at each hop of the propagation. > > List not complete - what about D, A, Sequence number, DIOIntDouble, > DIOIntMin ? Indeed- A, SeqNum, DIO... should be unchanged. Nodes should be free to tweak `D', e.g. from modifying their parent set > > Section 5.1.1 (general) > > - Do we need 8 bit for sequence number ? > > - Do we need 8 bit for DAGPreference ? I would agree probably not. 256 levels of DAG preference does seem a bit excessive in practice ;) > > - Is one byte enough for DAGRank ? > > - Do we need BootTimeRandom, NodePref at all, and if so, do they need to > be so big ? > > I understand the collision scenario with associated "risk window", but do we > need this tie-breaker, as opposed to simply discarding everything within > risk window regardless of any tie-breaker ? If the answer is "yes, we need > it", then should we at least consider making it less costly (less bits ?) > > - Can we come up with less "expensive" PathDigest ? > > Meaning less than 32 bit, and something less computationally intensive than > CRC. Also, do we need PathDigest at all, given that we have the "D" bit to > trigger DA ? Hmm... I think you may be onto something. One thing to consider is that `PathDigest' could be much longer lived as compared to the D bit, e.g. in case of loss a modified PathDigest can be observed over several sequence numbers, while a `D bit' would typically only remain set during one NA-DAO cycle. But there is definitely something here to consider... > > - DAGRank: Is rank of root "typically 1" or "always 1" ? > > Document not quite consistent. Since a root could "exaggerate" it's rank, I > assume "typically" is correct, but 5.3.1 seems to indicate otherwise: > > 2040 1. A node that does not have any DAG parents in a DAG is the root > 2041 of its own floating DAG. It's rank is 1. A node will end up in > > Section 5.1.1.1.5 > > 1803 The Destination Prefix suboption has an alignment requirement of > 1804 4n+1. Its format is as follows: > > "4n+1" is a bit unclear to me. This is obsolete, wrong, and will be updated (we had added a control octet for preference anyway that padded the option header out to a multiple of 4 bytes and removed the need for `+1') > > Section 5.2.2 > > 1913 it is expected to produce a different and unique DAGID for each of > 1914 the multiple DAGs. > > Suggest change: "expected to" to be replaced with "MUST" > > Section 5.3.1 > > 2099 rank, or whatever metrics the LLN cares to use. A node may jump > > Suggest change: "whatever metric the LLN cares to use" replaced by > "metrics defined by the OCP" > > Section 5.3.2.2 > > 2227 If the other DAG is now empty of candidate parents, then > 2228 directly follow SRC into the new DAG by adding it as a DAG > > Could the node have another choice (jumping to a parent in a third DAG) ? > > 2252 described in Section 5.3. When a node adds another node to its set > 2253 of candidate parents, the node becomes attached to the DAG through > 2254 the parent node. > > Not exactly - the new node simply becomes another "candidate parent" > > Section 5.3.3 > > 2302 overhead and saving energy consumption (which is of utmost > 2303 importance for battery-operated nodes). > > Suggest to delete "(which is of .....)" > (Not to say it is not true, but may not belong in section 5) > > 2344 (2^DIOIntervalMin)ms. The default value is > 2345 DEFAULT_DIO_INTERVAL_MIN. > > Suggest to clarify that the default at this point is simply given a > "name". This (I assume) to facilitate later reference to this when actual > values are discussed. > > Section 5.3.4.1. Resetting the Trickle Timer > > It wasn't obvious to me at first that this is all done in order to limit > the amount of localized traffic/congestion due to broadcasts from parent > nodes (i.e. "make children be quiet if their parents are talking a lot", if > I understand it correctly). May want to clarify for sake of readability. > > Section 5.7 > > 2490 preferred DAG parent and its rank. At that time any > 2491 remaining DAG parents of greater rank than this node must > > Shouldn't it be "greater than or equal rank" ? > > Section 5.7.1 > > 2534 A new DAG is discovered upon receiving a RA message with or without a > 2535 DIO. The node joins the DAG by selecting the source of the RA > > It took me a while to realize this must be coming from a "non RPL" node. > Suggest to clarify for readability (incl. the whole "rank 0" concept). > > 2553 The duration of the DAG Hop timer depends on the DAG Delay of the new > 2554 DAG and on the rank of candidate parent that triggers it: (candidates > 2555 rank + random) * candidate's DAG_delay (where 0 <= random < 1). It > 2556 is randomized in order to limit collisions and synchronizations. > > I understand "random" may be important in order to manage nodes that > somehow get in sync. But I suggest "random" may also be > difficult/"expensive" to implement (sure, it doesn't say how random it has > to be, but still). I believe I understand the intention behind making the > timer depend on the "candidate rank that would be achieved in DAG"; in the > sense that it allows for other/better parents to be discovered within this > time. However, could we somehow avoid "random" ? > > How is this impacted by the ongoing thread regarding use of "Sequence > number" vs "Hop timer" ? > > Section 5.7.3. Collision > > As discussed above, can this "risk window" be handled less expensively ? > (less bits in RA-DIO for "tie-breaker" or no "tie-breaker" at all) > > Section 5.7.4 > > 2623 A node is instable when it is prepared to shortly replace a set of > 2624 DAG parents in order to jump to a different DAGID. This happens > > Suggest to rephrase (node jumps to a different DAG, not a different DAGID) > > Section 5.8.1 > > 2695 o The OF scans all the candidate neighbors on the possible > 2696 interfaces to check whether they can act as an attachment router > > Suggest to replace "attachment router" with "router" > > 2702 o The OF computes self's rank by adding the step of rank to that > 2703 candidate to the rank of that candidate. The step of rank is > 2704 estimated as follows: > > Suggest to replace "estimated" with "based upon" > > 2757 * Candidate neighbors that are of worse rank than self are > 2758 ignored > 2759 > 2760 * Candidate neighbors of a better rank than self (non-siblings) > 2761 are preferred > > For completeness: There is no description of handling of "Candidate > neighbors of same rank" (siblings) > > Also, suggest to replace "worse rank" with "higher rank". > > Section 5.8.2 > > 2766 corresponding to OCP codepoint 0. This is a very simple reference to > 2767 help design more complex Objective Functions. In particular, the > > This makes it sound like OCP-0 is merely a "template". It is of course > more than that, being the "default" OCP. > > 2773 This document specifies a default objective metric, called OF0, and > 2774 using the OCP 0. OF0 is the default objective function of RPL, and > > Is OFO "default objective metric" or "default objective function" (acronym > matches neither) > > Section 5.8.2.2 > > 2819 4. If none are grounded then a DAG with a more preferred > 2820 administrative preference is better. > > Is this DAGPreference from RA-DIO ? (unclear to me) Yes- we will make it more clear > > Section 5.9.2.1 > > 3183 o A counter of retries to count how many RA-DIO messages were sent > 3184 on the interface to the advertising neighbor without reachability > 3185 confirmation for the prefix. > > At this point it may not be quite clear to the reader that this is related > to requesting a DA but not receiving it (if I understand correctly). > Suggest to clarify. > In -04 we will go for some FSM embodiment that should hopefully make this much more clear. > Section 5.9.2.4 > > 3369 o Destination advertisement operation stopped: All entries in the > 3370 abstract lists are freed. All the routes learned from NA-DAO > 3371 messages are removed. > > Why would a node stop DA operation once commenced ? > > Section 7.1.2 > > 3677 A RPL implementation SHOULD allow configuring the following routing > 3678 protocol parameters, which are further described in Section 5.1.1: > > I don't think PathDigest belongs in this list (nothing to configure, it is > by definition initialized to zero by root) > > 3715 DAG Hop Timer: A RPL implementation MUST provide the ability to > > Wouldn't it be more precise to describe configuration of DagDelay, since > "Hop Timer" is based on DagDelay. > > Section 7.1.5 > > 3771 o The Remove timer > > "Remove timer" or "DestroyTimer" ? (Document seems to be inconsistent) > > /Anders (Jagd) > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Wed Oct 14 18:15:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB04D3A67AB for ; Wed, 14 Oct 2009 18:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOFKkdKrPRC8 for ; Wed, 14 Oct 2009 18:15:55 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id DD4D03A6403 for ; Wed, 14 Oct 2009 18:15:55 -0700 (PDT) Received: from [198.202.202.22] (helo=[172.19.130.65]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyEwg-0006as-3f; Wed, 14 Oct 2009 18:15:58 -0700 Message-Id: <1ECB76A8-8892-4C3D-A90D-8B6E7155DB04@cs.stanford.edu> From: Philip Levis To: wintert@acm.org In-Reply-To: <490465.34054.qm@web57602.mail.re1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 18:15:54 -0700 References: <490465.34054.qm@web57602.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 1423d2bdf1536ba32d3e1b7a7c800682 Cc: roll@ietf.org Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 01:15:56 -0000 On Oct 7, 2009, at 3:43 PM, Tim Winter wrote: > WG, > > As discussed at the interim meeting, implementer feedback has > indicated that the RPL protocol as proposed appears complex, both in > description and actual FSM. > > Our plan of action is to, by end of month, deliver a -04 that will > contain actual (non-editorial) changes. The intent of this mail is > a poll over a period of 2 weeks, to help design the functional > changes. > > In this spirit, we would like the WG to work on the following > questions: > > Question A: Should RPL make use of the currently proposed local > repair mechanism (DAG splitting and merging)? > > [NO implies that DAG repairs shall be coordinated globally > with > the use of DAG Sequence Number; the related mechanisms are to > be expanded for -04] YES. > > Question B: Should RPL make use of a hold-up timer and related > states/procedures to reduce churn by coordinating the DAG merge? > > [NO implies RPL allows nodes to move (jump) between DAGs with > little coordination to reduce complexity of specification/ > implementation (perhaps w/ Optional hold-up mechanism)]. NO. > > Question C: Should RPL make use of a hold-down timer and related > states/procedures to limit flapping when removing DAG Parents / > leaving DAGs > > [NO implies RPL allows nodes to freely remove/add DAG Parents > as and when they are able in order to reduce complexity of > specification/implementation (perhaps w/ Optional hold-down > mechanism). NO. In my opinion, currently the draft specifies too many mechanisms designed to improve efficiency, with little experimental evidence on their comparative tradeoffs or value (if any). They are based on a conceptual model of wireless that may or may not hold. I think the specification should focus on the requirements for interoperability between different implementations, not perceived optimizations. Just my 2c. Phil From sung.lee@us.fujitsu.com Wed Oct 14 19:22:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4D53A6924 for ; Wed, 14 Oct 2009 19:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWo6PNIag2bq for ; Wed, 14 Oct 2009 19:22:59 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 18CBC3A67AB for ; Wed, 14 Oct 2009 19:22:59 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9F2NsWb002834; Wed, 14 Oct 2009 19:23:54 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9F2NsEB002828; Wed, 14 Oct 2009 19:23:54 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id n9F2Mvvg009604; Wed, 14 Oct 2009 19:22:57 -0700 (PDT) Received: from [10.157.253.52] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n9F2MuF23631; Wed, 14 Oct 2009 19:22:56 -0700 (PDT) Message-ID: <4AD68772.4070903@us.fujitsu.com> Date: Wed, 14 Oct 2009 22:22:42 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <4AAA5CE0.9060008@us.fujitsu.com> <4AB0C269.3090203@cttc.es> <4AB3D4A1.60805@eecs.berkeley.edu> <4AB9F844.60603@us.fujitsu.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Determining DADR Contributions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 02:23:00 -0000 Philip, > What 802.15.4 channel did you use, > and what 802.11 channels did the APs use? Here is the information you asked. IEEE802.11b Center freq.: 2.484GHz (14 ch, Japanese use only) there are few coexistence systems. IEEE802.15.4 Center freq.: 2.405GHz (11 ch) less interference because 802.11 does not use same center frequent band (2.412GHz (1ch)) Please let us know if you have any questions. Best regards, Sung Philip Levis wrote: > > On Sep 23, 2009, at 3:28 AM, Sung Lee wrote: > >> Mischa, Thomas, and ROLL WG members, >> >> We have *very preliminary* results from DADR implementation over >> 802.15.4, indoor experiments. >> Please note that these are preliminary results and we are continuing >> with our experiments. More complete results for indoor and outdoor >> will >> be shared before the interim meeting. >> >> Some facts: >> >> * This summarizes the indoor, multi-floor office building experiment. >> * Dimension of the building is roughly 30m x 20m, 2 floors involved >> * There were several active WLAN APs (interference from 802.11 >> present). > > Sung, > > What 802.15.4 channel did you use, and what 802.11 channels did the > APs use? > > Phil From anders.jagd@ekasystems.com Wed Oct 14 21:04:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CD73A693D for ; Wed, 14 Oct 2009 21:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.264 X-Spam-Level: * X-Spam-Status: No, score=1.264 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT2nVZrK8Q2D for ; Wed, 14 Oct 2009 21:04:09 -0700 (PDT) Received: from smtp101.biz.mail.re2.yahoo.com (smtp101.biz.mail.re2.yahoo.com [68.142.229.215]) by core3.amsl.com (Postfix) with SMTP id D9A3B3A696A for ; Wed, 14 Oct 2009 21:04:08 -0700 (PDT) Received: (qmail 42275 invoked from network); 15 Oct 2009 04:04:09 -0000 Received: from unknown (HELO PavilionLaptop) (anders.jagd@68.110.232.114 with login) by smtp101.biz.mail.re2.yahoo.com with SMTP; 15 Oct 2009 04:04:09 -0000 X-Yahoo-SMTP: Z9nti1.swBBshEkcTT58JGsSW0GG0Kgu_9V27Bc_1Irb1gnWTbAo X-YMail-OSG: Ouf_llcVM1lBokqKPGtFoNMZZBvp0IXbYji1uXv4SMzapzB0MFn9qUDq01iEy3ZpfNgzCaoBJuTyCuY1nqxHbY_Hc.bxzcecCsJLfMQU7NHNu8oVu9ZSBWVgbYIqu5zl.27d97ZQEzskq8RJMOeseHZWE50WVe0Myht3JuplME2WgHdK6DrcUBrE9X9a2a3mnW0Upj9qbWl2O7CU4g2CsqKs5m1wJNPxQcq_n8pEF5wXP_XWJkDCcTkHWjst88bxwlEn0mD5Ez02elimCu_tej3U1lGk6ZhK3F_aR7T_H1.qItaR9BGJkHzbXZA1MmB6bw-- X-Yahoo-Newman-Property: ymail-3 From: "Anders Jagd" To: "'Tim Winter'" References: <000301ca4d0d$0f71a4a0$2e54ede0$@jagd@ekasystems.com> <4AD67774.1010804@acm.org> In-Reply-To: <4AD67774.1010804@acm.org> Date: Thu, 15 Oct 2009 00:04:07 -0400 Organization: Eka Systems Message-ID: <000001ca4d4c$8b8430f0$a28c92d0$@jagd@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpNNNfwfwFI2IzzS8uSpwRdY84cYwAFKJjQ Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] Review of rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 04:04:09 -0000 Tim, True, so I guess 'D' bit is not the solution. It still seems to me that 32 bit + CRC calculation is a pretty steep price to pay to reliably signal downstream that something has changed upstream. Something should be doable with a byte or less. For example: Each node could maintain a local "sequence number" (a few bits), which it inserts into RA-DIO messages. If a change is detected, this is signaled to the child nodes by incrementing the sequence number. A child node, upon seeing a change in parent sequence number, may now take appropriate action, including incrementing its own sequence number for further outward/downstream signaling. A few bit should suffice. If say 4 bits are in use, a child would have to miss 15 consecutive sequence number changes (and receive the 16th) for it to miss out on the message of change. /Anders > > - Can we come up with less "expensive" PathDigest ? > > Meaning less than 32 bit, and something less computationally intensive than > CRC. Also, do we need PathDigest at all, given that we have the "D" bit to > trigger DA ? Hmm... I think you may be onto something. One thing to consider is that `PathDigest' could be much longer lived as compared to the D bit, e.g. in case of loss a modified PathDigest can be observed over several sequence numbers, while a `D bit' would typically only remain set during one NA-DAO cycle. But there is definitely something here to consider... From jhui@archrock.com Wed Oct 14 21:48:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FC63A6932 for ; Wed, 14 Oct 2009 21:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIBziFCfQb9U for ; Wed, 14 Oct 2009 21:48:34 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 0BD163A6828 for ; Wed, 14 Oct 2009 21:48:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 0D464AF83E; Wed, 14 Oct 2009 21:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqtdzQvAQET2; Wed, 14 Oct 2009 21:48:30 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id 1A6A5AF83B; Wed, 14 Oct 2009 21:48:30 -0700 (PDT) Message-Id: <824070F1-DC8B-46B2-ACDE-38E83181B0DE@archrock.com> From: Jonathan Hui To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:48:27 -0700 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 04:48:35 -0000 On Oct 14, 2009, at 6:13 PM, Philip Levis wrote: > Right -- the assumption is that the real link estimation is with > packets. Receiving a packet with a very high chip correlation index > means that the link *at that time* had a high SNR, meaning it is > likely a good enough link to try (white bit set). If the white bit > isn't set, then a link has to go through a little bit of packet- > based estimation before CTP Noe will try using it. My experience with chip correlation is that it can be a leading indicator of packet loss, but it's ability to discern 'good' links from 'okay' links is limited. In the end, I think a 'link classifier' should use whatever information it can get - that leads me to want a metric that doesn't really have a 'unit' but instead identifies a 'class'. > I agree that it's reasonable for an implementation to heavily favor > "good" links over "okay" links (tradeoff potential efficiency for > stability), or discard the use of okay links altogether. However, > user/application preference of behavior in the presence of only OK > links should be left out of the protocol specification. Some > applications would prefer "don't work unreliably" and others would > prefer "do your best." Of course. I just wanted to say that there are times when you want to ignore and other times you don't want to ignore 'okay' links. -- Jonathan Hui From d.sturek@att.net Wed Oct 14 22:40:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0175F3A6951 for ; Wed, 14 Oct 2009 22:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.785 X-Spam-Level: * X-Spam-Status: No, score=1.785 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOWnODPmYA0m for ; Wed, 14 Oct 2009 22:40:24 -0700 (PDT) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id EE9533A68C2 for ; Wed, 14 Oct 2009 22:40:23 -0700 (PDT) Received: (qmail 11317 invoked from network); 15 Oct 2009 05:40:25 -0000 Received: from (d.sturek@202.130.198.12 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 14 Oct 2009 22:40:23 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: HmXS0awVM1mI9JxBIzXidRutIzLtSkZweLyLbEHfMA5jD0FJyRpSJDy37GPRkdy.Jbnhl13fA.ONSj6o6.PEDISB0cr6E12YbWM3W7Efi_U01c15RL_q_Yw2IlN_FX8tsVFw1oLkBpdqBcqWFURY2_.2Ck.zgtW8Ehoe.7QvNPFWLorhz3h.Btt_Mcz7Ugfu8PUD5ESmrHejvIX3E5f6RZ.QeuWrvvpCu5_WXZ6O0lT7sA9tmibsbEI5iG20dZ7TFFFiOuo2erpLVAX4iGc- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'roll'" Date: Wed, 14 Oct 2009 22:40:14 -0700 Message-ID: <001b01ca4d59$fb2451d0$f16cf570$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CA4D1F.4EC579D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpNWffhfAA2T5pDTMy62r9pU+lQzQ== Content-Language: en-us Subject: [Roll] Question on Multi-Homing in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 05:40:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001C_01CA4D1F.4EC579D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A question on RPL -03: Is Multi-Homing supported? Here is the use case: 1) In a Smart Energy setting, the Smart Meter is assumed to have one prefix. Some collection of devices join this network and can communicate to the meter and via the meter to the utility headend 2) The customer also owns a router connected to an ISP. Let's suppose the ISP is providing IPv6 service with a separate prefix. Here are the questions: 1) Within a DAG, could devices be Multi-Homed or are they required to have a single prefix? 2) Are there any limitations or suggestions on how address assignment should be handled with respect to the two prefix address spaces. 3) If we would like the same devices to be able to communicate to the meter/headend and then also to the internet via the customers ISP, would: a. There need to be DAGs supporting separate prefix addresses? b. Can the devices in a single DAG support multihomed devices? Would all devices in a given DAG need to be multihomed the same way? Don ------=_NextPart_000_001C_01CA4D1F.4EC579D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A question on RPL -03:   Is Multi-Homing supported?  Here is the use case:

1)       In a Smart Energy setting, the Smart Meter = is assumed to have one prefix.   Some collection of devices join = this network and can communicate to the meter and via the meter to the = utility headend

2)      The customer also owns a router connected to an ISP.  Let’s suppose the ISP is providing IPv6 service with a separate prefix.

 

Here are the questions:

1)       Within a DAG, could devices be Multi-Homed = or are they required to have a single prefix?

2)      Are there any limitations or suggestions on how = address assignment should be handled with respect to the two prefix address = spaces.

3)      If we would like the same devices to be able to communicate to the meter/headend and then also to the internet via the customers ISP, would:

a.       = There need to be DAGs supporting separate prefix addresses?

b.      = Can the devices in a single DAG support multihomed devices?  Would all = devices in a given DAG need to be multihomed the same way?

Don

 

------=_NextPart_000_001C_01CA4D1F.4EC579D0-- From pal@cs.stanford.edu Wed Oct 14 23:28:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF493A6818 for ; Wed, 14 Oct 2009 23:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHoTwpV6Gq6J for ; Wed, 14 Oct 2009 23:28:38 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id AC5153A67A6 for ; Wed, 14 Oct 2009 23:28:38 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyJpJ-0004kc-Cr; Wed, 14 Oct 2009 23:28:41 -0700 Message-Id: From: Philip Levis To: Maxence Dalmais In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:30:02 -0700 References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 06:28:39 -0000 On Oct 12, 2009, at 3:09 PM, Maxence Dalmais wrote: > > I am saying that when using wireless links, a node should be aware > that his communication could interfere with other communication. > Less powered is the transmission signal, less noise is seen by > neighbours. It also means that it's more greatly affected by interference from neighbors: there is no free lunch. > A low powered node will also need less energy to communicate in a > less noisy environnement. In low-power wireless chipsets, CMOS dominates power costs. E.g., a chip that draws 60mW transmits at 1mW. Reducing transmit power typically does not conserve much energy. > So, it appears to me logical that when others metrics are egals to > choose the less power needed links. I don't know of any strong experimental evidence supporting this conclusion. Can you point me at some? Phil From pal@cs.stanford.edu Wed Oct 14 23:28:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9403A6890 for ; Wed, 14 Oct 2009 23:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VA-B3gHhXb1 for ; Wed, 14 Oct 2009 23:28:40 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2741B3A67A6 for ; Wed, 14 Oct 2009 23:28:40 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyJpL-0004kc-5W; Wed, 14 Oct 2009 23:28:43 -0700 Message-Id: <2B1F50AA-4B8B-443E-86BD-5A85FC667F3E@cs.stanford.edu> From: Philip Levis To: Henning Rogge In-Reply-To: <200910131011.11371.hrogge@googlemail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:31:34 -0700 References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> <200910131011.11371.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 06:28:41 -0000 On Oct 13, 2009, at 1:11 AM, Henning Rogge wrote: > > So the question about a metric for ROLL should not only be "what's > the best > metric for our networks" but "what metric is simple enough that > everyone can > implement it on any kind of hardware". I agree. Well put! :) Phil From pal@cs.stanford.edu Wed Oct 14 23:28:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD503A6983 for ; Wed, 14 Oct 2009 23:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksvlnz+OEN5U for ; Wed, 14 Oct 2009 23:28:43 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 0723C3A68CE for ; Wed, 14 Oct 2009 23:28:43 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyJpM-0004kc-3E; Wed, 14 Oct 2009 23:28:46 -0700 Message-Id: <98A33FF2-61A1-480A-B78C-DEB4D7AB2323@cs.stanford.edu> From: Philip Levis To: Henning Rogge In-Reply-To: <200910131553.47834.hrogge@googlemail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:33:41 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: c34b9e52c8715c7e60548704bd659ba6 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 06:28:44 -0000 On Oct 13, 2009, at 6:53 AM, Henning Rogge wrote: > Unless 802.15.4 is totally different (I don't think so) I would > strongly > suggest thinking about something better than hopcount for your > mandatory > metric. At least that's the message I can tell from OLSR. I agree -- hopcount is a non-starter. It is only useful if you can filter links based on a more expressive quality metric (ETX, etc.); but since you require such a metric, it's better to use it than a filtered proxy. Phil From pal@cs.stanford.edu Wed Oct 14 23:28:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF393A68CE for ; Wed, 14 Oct 2009 23:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOQdtA+PlJBn for ; Wed, 14 Oct 2009 23:28:44 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 389163A6982 for ; Wed, 14 Oct 2009 23:28:44 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyJpP-0004kc-5y for roll@ietf.org; Wed, 14 Oct 2009 23:28:47 -0700 Message-Id: <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> From: Philip Levis To: roll ROLL In-Reply-To: <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:49:10 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 06:28:45 -0000 I think we should keep in mind that RPL must work across multiple link layers. E.g.: A -- 900MHz --> B -- 2.4GHz --> C ETX is a commonly used metric, but typically under two simplifying assumptions: 1) Routes are composed of a single link layer 2) The link layer has a static bitrate If you break either assumption, it doesn't work well. ETT (expected time of transmission) can address 2), but not 1). I'm wary of encoding a metric as a hard quantity. For example, quantifying the metric as uJ breaks when nodes have differential energy capacities. What we really want is a more abstract notion of cost, which a particular device can use to, in a very simple way, express its own tradeoffs. It is critical that exactly how devices calculate this value remain unspecified. My first thought would be a quantification of how much of a node's "lifetime" a packet would cost. Such a cost can consider both the receiver and transmitter. E.g., given its particular low power algorithms and expected lifetime, how much would sending to this destination consume? (I try to avoid using the word "link.") I don't think that a single metric will be sufficient; besides some notion of cost (hopcount, ETX, ETT, etc.), the other metric that is critical in many applications is latency. These two -- cost and latency -- can cover a large portion of the application design space, and provide a sound basis for the basic specification. Thoughts? Phil From pal@cs.stanford.edu Thu Oct 15 00:44:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F203A6962 for ; Thu, 15 Oct 2009 00:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjVy+0chjPHf for ; Thu, 15 Oct 2009 00:44:45 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 4FECC3A6961 for ; Thu, 15 Oct 2009 00:44:45 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyJpR-0004kc-MX for roll@ietf.org; Wed, 14 Oct 2009 23:28:50 -0700 Message-Id: <4545989A-F9FE-4C7A-B387-520CE19A4A2A@cs.stanford.edu> From: Philip Levis To: roll ROLL Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Oct 2009 21:53:58 -0700 References: <4AD62BAE.2010409@stanford.edu> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 50c535147b6e7155177bcd7d65214eb3 Subject: [Roll] Fwd: [netseminar] Reminder : Stanford Networking Seminar, Thur Oct 15, Omprakash Gnawali X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 07:44:46 -0000 Apologies for sending this so last minute. Since there's been a lot of =20= discussion of the strengths and weaknesses of CTP's mechanisms on the =20= list, I thought folks in the Bay Area might be interested in hearing =20 Om talk about it. Everyone is welcome. :) Phil Begin forwarded message: > From: Yiannis Yiakoumis > Date: October 14, 2009 12:51:10 PM PDT > To: netseminar@lists.stanford.edu, = clean-slate-seminar@lists.stanford.edu > Subject: [netseminar] Reminder : Stanford Networking Seminar, Thur =20 > Oct 15, Omprakash Gnawali > > Stanford Networking Seminar Announcement > http://netseminar.stanford.edu/ > > Title: The makings of CTP Noe: A robust, reliable, and efficient =20 > routing > protocol for wireless sensor networks. > > Speaker: Omprakash Gnawali, Stanford > > When: 12:15 PM, Thursday October 15th, 2009 > Where: Gates 104 > http://forum.stanford.edu/visitors/directions/gates.php > > Lunch will be available at 11:45AM. > > About the talk: > > This talk describes the challenges in designing a sensor network > routing protocol and presents CTP Noe, a widely-used collection > routing protocol, to understand the key design features that make it > robust, reliable, and efficient while remaining platform independent. > > Collection Tree Protocols (CTP) compute anycast routes to a single or > a small number of designated sinks (destinations) in a wireless sensor > network. Despite the critical importance of collection to almost every > wireless sensor networks deployed to monitor the environment > (buildings, rivers, forests, shipping containers, agriculture farms, > etc.), prior to CTP, no collection layer was available that met the > goals of robust, reliable, and efficient routing while remaining > platform independent. CTP Noe advances the design of wireless sensor > network protocol using three key ideas to meet those goals. First, it > uses agile and accurate link estimator using information from the > physical, link, and network layers. Second, it uses adaptive beacons > to minimize control overhead without sacrificing agility to topology > changes. Finally, it uses datapath validation of routing > inconsistencies to quickly detect and repair loops. CTP Noe has been > used on numerous deployments and tested on 12 different testbeds > ranging in size from 20=96310 nodes, comprising seven platforms, and = six > different link layers, on both interference-free and > interference-prone channels. In all cases, CTP Noe delivers > 90% of > packets, frequently achieving 99.9%. This talk describes how the three > mechanisms (agile link estimation, adaptive beaconing, and datapath > validation) together allow CTP Noe to work in such a wide range of > settings and platforms, adapt to the physical, link, and network layer > dynamics, and still offer highly-reliable and energy-efficient data > delivery to the data collection sinks in the network. > > About the speaker: > > Omprakash Gnawali is a postdoctoral fellow in the Computer Science > department at Stanford University. His research interests are network > protocols and distributed systems, and their application to wireless > and sensor networks. His past research has led to the design and > implementation of a widely-used open-source sensor network routing > protocol called CTP. He was also involved in the design, development, > and deployment of various low-power wireless sensor networks. He > received his Ph.D in Computer Science from the University of Southern > California and Masters and Bachelors degrees in Computer Science and > Engineering from the Massachusetts Institute of Technology. > > --++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D= --++**=3D=3D--++**=3D=3D > netseminar mailing list > netseminar@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/netseminar > > --++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D--++**=3D=3D= --++**=3D=3D > clean-slate-seminar mailing list > clean-slate-seminar@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/clean-slate-seminar > From mdurvy@cisco.com Thu Oct 15 01:44:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D40A3A67D4 for ; Thu, 15 Oct 2009 01:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.74 X-Spam-Level: X-Spam-Status: No, score=-9.74 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok1XKjFuETPc for ; Thu, 15 Oct 2009 01:44:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C16333A679C for ; Thu, 15 Oct 2009 01:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=3421; q=dns/txt; s=amsiport01001; t=1255596282; x=1256805882; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[Roll]=20feedback=20on=20draft-ietf-r oll-rpl-03|Date:=20Thu,=2015=20Oct=202009=2010:44:38=20+0 200|Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F91EE7AAB29 @XMB-AMS-103.cisco.com>|To:=20"Emmanuel=20Baccelli"=20,=0D=0A=20=20=20=20=20=20=20=20" ROLL=20WG"=20|MIME-Version:=201.0 |In-Reply-To:=20|References:=20; bh=BTgP/iVHMlRQjoTsSNj961WVaPG4rX31s7HkpJp0sz4=; b=JKrg+IsXEY5dgQnmerl/7Ayx4ce08QUJMwCv6GiSVJBcq6djk9QTnpmc mHcALyTpVSE/5xphrtqJMaG8zu+GYGYrvlm/fLZ8n4LHNqB6vWFJymQnB 3Tw9ybUIkiEbgepLwHvMlGbwHsQUU0pF02xGIs7yP1TuFd5iAef69JGQV w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAAACd+1kqQ/uCWe2dsb2JhbACCKC2YQAEBFiQGpRSYaoQwBA X-IronPort-AV: E=Sophos;i="4.44,565,1249257600"; d="scan'208,217";a="51859865" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2009 08:44:40 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9F8ieXL001365; Thu, 15 Oct 2009 08:44:40 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 10:44:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA4D73.BBF23AD5" Date: Thu, 15 Oct 2009 10:44:38 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE7AAB29@XMB-AMS-103.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] feedback on draft-ietf-roll-rpl-03 Thread-Index: AcpM1b5VyRvwmoJESSuhV+CSLpiQcwAnA3nA References: From: "Mathilde Durvy (mdurvy)" To: "Emmanuel Baccelli" , "ROLL WG" X-OriginalArrivalTime: 15 Oct 2009 08:44:40.0855 (UTC) FILETIME=[BC42C270:01CA4D73] Subject: Re: [Roll] feedback on draft-ietf-roll-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 08:44:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4D73.BBF23AD5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Emmanuel, =20 I very much agree with your comments. Especially with the two points below that could reduce a lot the complexity. # Section 2 I am wondering if some of the terms are unecessary at this point. In particular, DAG siblings. Since siblings introduce quite a tricky complexity/benefit trade-off, I would be in favor of getting rid of these in the core RPL document. This could be a welcomed simplification. Agree, for me siblings are note part of the core. =20 # Section 3.2.1:=20 "RPL constructs one or more DAGs". The consensus is that the core RPL document should specify how to build a single DAG to reach a single destination. This may be used to simplify the document a bit.=20 Agree. I think what is needed are just procedures to join a DAG and leave a DAG. =20 Best, Mathilde=20 ------_=_NextPart_001_01CA4D73.BBF23AD5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Emmanuel,
 
I very much agree with your comments. = Especially with the=20 two points below that could reduce a lot the = complexity.

# Section 2
I am wondering if some of the terms are unecessary at this point. = In=20 particular, DAG siblings. Since siblings introduce quite a tricky=20 complexity/benefit trade-off, I would be in  favor of getting rid = of these=20 in the core RPL document. This could be a welcomed simplification.
Agree,=20 for me siblings are note part of the core.
 
 # Section = 3.2.1: 
"RPL constructs one or more DAGs". The consensus is that the core = RPL=20 document should specify how to build a single DAG to reach a single = destination.=20 This may be used to simplify the document a bit. 
Mathilde 
------_=_NextPart_001_01CA4D73.BBF23AD5-- From maxence.dalmais@insa-lyon.fr Thu Oct 15 01:54:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331F43A67A8 for ; Thu, 15 Oct 2009 01:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxMX85sRM01r for ; Thu, 15 Oct 2009 01:54:16 -0700 (PDT) Received: from smtp.insa-lyon.fr (criges14.insa-lyon.fr [134.214.76.242]) by core3.amsl.com (Postfix) with ESMTP id 0FCB93A67A1 for ; Thu, 15 Oct 2009 01:54:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 64D66F1376 for ; Thu, 15 Oct 2009 10:54:18 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmic2s15M+aH for ; Thu, 15 Oct 2009 10:54:18 +0200 (CEST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: mdalmais1) by smtp.insa-lyon.fr (Postfix) with ESMTPSA id 80673F1390 for ; Thu, 15 Oct 2009 10:54:17 +0200 (CEST) Received: by fg-out-1718.google.com with SMTP id d23so312493fga.13 for ; Thu, 15 Oct 2009 01:54:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.139.91 with SMTP id s27mr782514hbs.84.1255596856563; Thu, 15 Oct 2009 01:54:16 -0700 (PDT) In-Reply-To: References: <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> From: Maxence Dalmais Date: Thu, 15 Oct 2009 10:53:56 +0200 Message-ID: To: Philip Levis Content-Type: multipart/alternative; boundary=001485f6cd1a9dd9870475f56c96 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 08:54:20 -0000 --001485f6cd1a9dd9870475f56c96 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil , I am saying that when using wireless links, a node should be aware that his >> communication could interfere with other communication. >> Less powered is the transmission signal, less noise is seen by neighbours. >> > > It also means that it's more greatly affected by interference from > neighbors: there is no free lunch. > Could you please be more clear? I'm not sure I understand quite well. > > A low powered node will also need less energy to communicate in a less >> noisy environnement. >> > > In low-power wireless chipsets, CMOS dominates power costs. E.g., a chip > that draws 60mW transmits at 1mW. Reducing transmit power typically does not > conserve much energy. > Thank you for this information. But keep this assumption as it assumes that hardware will not evolve in coming years. I totally aggre with you to say that we need an abstract notion of cost. But I think that we can not consider only the receiver and transmitter but that we have to consider all the nodes on which the transmission has an (good or bad) effect. Sure, there will be a huge difference between wireless and wired links. A good effect of a high powered transmission from a main node to another node could be seen if some nodes are using ambient radio radiation to stay up. For each nodes, the cost will be different depending if the node is involved in the transmission in receiving, routing, or not directly involved but in being affected by it. Maxence. --001485f6cd1a9dd9870475f56c96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Phil ,

I am saying that when using wireless links, a node should be aware that his= communication could interfere with other communication.
Less powered is the transmission signal, less noise is seen by neighbours.<= br>

It also means that it's more greatly affected by interference from neig= hbors: there is no free lunch.

=A0
Could you please be more clear?
I'm not sure I unde= rstand quite well.

=A0

A low powered node will also need less energy to communicate in a less nois= y environnement.

In low-power wireless chipsets, CMOS dominates power costs. E.g., a chip th= at draws 60mW transmits at 1mW. Reducing transmit power typically does not = conserve much energy.


Thank you for this information.
But keep this assumption as it assumes= that hardware will not evolve in coming years.

I totally aggr= e with you to say that we need an abstract notion of cost.
But I think t= hat we can not consider only the receiver and transmitter but that we have = to consider all the nodes on which the transmission has an (good or bad) ef= fect. Sure, there will be a huge difference between wireless and wired link= s.

A good effect of a high powered transmission from a main node to anothe= r node could be seen if some nodes are using ambient radio radiation to sta= y up.
For each nodes, the cost will be different depending if the node i= s involved in the transmission in receiving, routing, or not directly invol= ved but in being affected by it.

Maxence.

--001485f6cd1a9dd9870475f56c96-- From mdurvy@cisco.com Thu Oct 15 02:17:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51BE3A686B for ; Thu, 15 Oct 2009 02:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.863 X-Spam-Level: X-Spam-Status: No, score=-7.863 tagged_above=-999 required=5 tests=[AWL=-1.264, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hgag+OZXJ3m for ; Thu, 15 Oct 2009 02:17:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 68B883A67D4 for ; Thu, 15 Oct 2009 02:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=2041; q=dns/txt; s=rtpiport02001; t=1255598273; x=1256807873; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[Roll]=20=20Review=20of=20rpl-03 |Date:=20Thu,=2015=20Oct=202009=2011:17:50=20+0200 |Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F91EE7AAB84@XM B-AMS-103.cisco.com>|To:=20"Anders=20Jagd"=20,=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<000301ca4d0d$0f71a4a0$2e54ede0$@jagd@eka systems.com>|References:=20<000301ca4d0d$0f71a4a0$2e54ede 0$@jagd@ekasystems.com>; bh=xXaV7QGn+RsxretrP2BMAFFNs73/jdTgEgEV0sCHAWw=; b=mKkUVsrE7eDx/0Se6X6FnbrAezXWbdlbIdCo3SCoSQTilG/CrJQ10tHa YgHvlQTGLfi/l5BYtOMQOENmT52mddo9JiIG2CWbCYnevRvcv8ARH5xFA PgYdbGv7gL+u8I0L52M4WoD3UcNoYJBsCtpd1yZdnV8DvFALATYNSFJOl M=; Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC6F1kqtJV2a/2dsb2JhbADAcZhmhDAE X-IronPort-AV: E=Sophos;i="4.44,565,1249257600"; d="scan'208";a="63214741" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 15 Oct 2009 09:17:52 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id n9F9Hkjo009892; Thu, 15 Oct 2009 09:17:52 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 11:17:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2009 11:17:50 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE7AAB84@XMB-AMS-103.cisco.com> In-Reply-To: <000301ca4d0d$0f71a4a0$2e54ede0$@jagd@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Review of rpl-03 Thread-Index: AcpNDQ76o/ppScGtSP+c0WnjD1l6MAAZuAEA References: <000301ca4d0d$0f71a4a0$2e54ede0$@jagd@ekasystems.com> From: "Mathilde Durvy (mdurvy)" To: "Anders Jagd" , X-OriginalArrivalTime: 15 Oct 2009 09:17:51.0648 (UTC) FILETIME=[5EDDAA00:01CA4D78] Subject: Re: [Roll] Review of rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 09:17:51 -0000 Hi Anders, I very much agree with your comments on Section 5.1.1. My general feeling is that we are including way to much information in the base RA-DIO option. The RA header is already 16bytes + 32bytes by RA Prefix advertised. Right now the RA-DIO option is 36 bytes (without sub-options).=20 > - Do we need 8 bit for DAGPreference ? [Mathilde] The DAGPreference seems not to be mentioned much in the current draft. Do we really need a DAGPreference at all? Can't a node base it's decision to join a DAG on the OCP only? > - Do we need BootTimeRandom, NodePref at all, and if so, do they need to be so big ?=20 > I understand the collision scenario with associated "risk window", but do we need this tie-breaker, as opposed to simply discarding everything within risk window regardless of any tie-breaker ? If the answer is "yes, we need it", then should we at least consider making it less costly (less bits ?) [Mathilde] I agree. Having 32 bits in every RA just to avoid unlikely collisions is in my opinion not needed. I would remove the BootTimeRandom and the NodePreference. I like your approach of discarding everything within the risk window. > - Can we come up with less "expensive" PathDigest ?=20 > Meaning less than 32 bit, and something less computationally intensive than CRC. Also, do we need PathDigest at all, given that we have the "D" bit to trigger DA ? [Mathilde] My impression is that we can remove the PathDigest. The only place where the PathDigest is mentioned (outside of the RA-DIO format) is Section 5.9.2.1. =20 "Destination advertisements may also be scheduled for sending when the PathDigest of the RA-DIO message has changed".=20 This seems a weak reason to had an overhead of 32bit in every RA-DIO Concerning the DIOIntervalDoubling and the DIOIntervalMin, I would propose to use default values. Here too, in my opinion, there is no need to include these values in every RA. If an implementation wants to do so, I would propose a sub-option. Best, Mathilde From mdurvy@cisco.com Thu Oct 15 04:22:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99AAA3A692C for ; Thu, 15 Oct 2009 04:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.495 X-Spam-Level: X-Spam-Status: No, score=-8.495 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwFYSzH4bb9E for ; Thu, 15 Oct 2009 04:22:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E3A073A68FC for ; Thu, 15 Oct 2009 04:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=8655; q=dns/txt; s=amsiport01001; t=1255605744; x=1256815344; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20Candidate=20neighbors|Date:=20Thu,=2015=20O ct=202009=2013:22:21=20+0200|Message-ID:=20<8A977BDC5A7B0 E429B0F521E8D6F91EE7AACE9@XMB-AMS-103.cisco.com>|To:=20|MIME-Version:=201.0; bh=9WMSvll4xnSXyOWZ7AMVG+BRLItNuH780r3UAuA9WDY=; b=VqQk52jYllA26vacz71hJWCygqtqgKnl1lQnR+iG0pwIe56pgoxpamGC KNXgbb2Aaevfs7AgX/K3dvDZ8DFE1lm05oJ1vsMo3xdtb453bLSdw1wiw I6JacwHSfKrOPo284KA8arDk4c7D6cSyfWAIL2KHAhNRSZ0YYjTIbrJBc 0=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgAAHui1kqQ/uCWe2dsb2JhbACCKSwhmB8BARYkBqVMmF0ChC4E X-IronPort-AV: E=Sophos;i="4.44,566,1249257600"; d="gif'147?scan'147,208,217,147";a="51881319" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Oct 2009 11:22:22 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9FBMM6b028797 for ; Thu, 15 Oct 2009 11:22:22 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 13:22:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA4D89.C3F28067" Date: Thu, 15 Oct 2009 13:22:21 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE7AACE9@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Candidate neighbors Thread-Index: AcpNicNBpeCtGxHYTlaotvx1oJIeYw== From: "Mathilde Durvy (mdurvy)" To: X-OriginalArrivalTime: 15 Oct 2009 11:22:23.0040 (UTC) FILETIME=[C4299C00:01CA4D89] Subject: [Roll] Candidate neighbors X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 11:22:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA4D89.C3F28067 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA4D89.C3F28067" ------_=_NextPart_002_01CA4D89.C3F28067 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 I'm trying to understand better the need for 'candidate neighbors'. My current understanding is that 'candidate parents' (RPL) are a subset = of 'candidate neighbors' (RPL) which are themselves a subset of = 'neighbors' (ND). My question is, do we really need to maintain 'candidate neighbors' in = addition to 'neighbors' and 'candidate parents'? If yes what should be the data structure and corresponding fields for = 'candidate neighbors'? Section 5.2.1 gives very little details... I have a feeling that 'candidate neighbors' could simply be the set of = REACHABLE 'neighbors' and be associated with a DAG once they become = candidate parents. =20 Best, Mathilde =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_002_01CA4D89.C3F28067 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
I'm = trying to=20 understand better the need for 'candidate = neighbors'.
Agree.=20 I think what is needed are just procedures to join a DAG and = leave a=20 DAG.  

Best,
On Oct 12, 2009, at 11:21 PM, Jerald.P.Martocci@jci.com=20 wrote:


I guess I = am one of=20 those people that think that other 6LoWPAN nodes must participate in = RPL.=20  Unless I am missing something RPL is the only game in town = regarding=20 meshing of wireless sensors.  If they are not in RPL is there = another=20 means that they can use to form mesh connectivity to get to the = LBR?=20

You interpretation is of course correct.

JP.


Jerry=20





Michael = Richardson=20 <mcr@sandelman.ca>=20
Sent by: roll-bounces@ietf.org

10/12/2009 04:13 PM =

To
 IETF ROLL <roll@ietf.org> =
cc
Subject
 Re: [Roll] NA to = transport=20 DAO

=




<= FONT=20 size=3D2>-----BEGIN PGP SIGNED MESSAGE-----
Hash:=20 SHA1


>>>>> "Pascal" =3D=3D Pascal Thubert=20 <(pthubert)" <pthubert@cisco.com>>=20 writes:
   Pascal> We are in perfect line. At the = moment, RPL=20 would impose
   Pascal> NS/NA between 6LoWPAN routers = to=20 expose the host routes.

I have just read = 6lowpan-nd-06.txt

Some=20 things immediately jump out at me:
    1) small packets = are much=20 more common, so DAOs may not fit into ND.
    2) = multicast is not=20 assumed, so the Whiteboard is used.
    3) nodes that are = sleepy,=20 are not going to be useful as members of
      =    =20       an RPL DAG, so really, it's about RPL between the = Edge=20 Routers.

It seems to me therefore that the only nodes in a = 6lowpan that=20 can
participate in a RPL DAG would be the edge router that runs=20 a
Whiteboard.

I think you capture this in your above = sentence.=20   I do not think that
the 6LoWPAN routers will be speaking = NR/NC=20 between themselves along
their "backbone", but I could be = wrong.

I=20 also think that some other people may be thinking that many = more
6LoWPAN=20 nodes will participate in RPL than just the edge routers.

- -- =
]=20       He who is tired of Weird Al is tired of life! =  =20         |  firewalls  [
]   = Michael=20 Richardson, Sandelman Software Works, Ottawa, ON    |net=20 architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.o= n.ca/=20 |device driver[
  Kyoto Plus: watch the video <http://www.youtube.= com/watch?v=3Dkzx1ycLXQSE>
 =20                     =  =20        then sign the petition.
-----BEGIN PGP=20 SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger = me for=20 = keys

iQEVAwUBStOcCICLcPvd0N1lAQKH2wf9E88fL2LMjiDu3MyJpWMRHfoQUEKl5= E9N
j05PD4nhtRGlJ+IMjMyXYK0a4BjkFGxRq5iD00RP/m338shvmjSjhxOeMHSpUIpXbnb8Jql4guPerrUnzmxCpOI52y4igNxXWb5Y2HTuMHBWLNjMZtDUeCp+wXBy+ZIp
GB+= QYWw7dC6gVxXanTqVxyx8e33nI1AfAdHYq+8amHJVtCy1dpIPQtNa19krV0wo
aWKWXI9D= fhqQNLed/8g+p1sFY0r2GxG7ZL4W9ZyZZgwC2Dmkzt9BlfwG32W7JC9/
iZxrOjTeS6ZeK= 4DktBQzdmqjzXpMSDpB3/NmdaY/OgsiXokAPsI+bw=3D=3D
=3DFpQB
-----END=20 PGP = SIGNATURE-----
_______________________________________________
Roll= =20 mailing list
Roll@ietf.org
https://www.ietf.org/= mailman/listinfo/roll

____________________________= ___________________
Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
My current = understanding is=20 that 'candidate parents' (RPL) are a subset of 'candidate neighbors' = (RPL) which=20 are themselves a subset of 'neighbors' (ND).
My = question is, do=20 we really need to maintain 'candidate neighbors' in addition to = 'neighbors' and=20 'candidate parents'?
If yes = what should=20 be the data structure and corresponding fields for 'candidate = neighbors'?=20 Section 5.2.1 gives very little details...
I have = a feeling=20 that 'candidate neighbors' could simply be the set of REACHABLE = 'neighbors' and=20 be associated with a DAG once they become candidate=20 parents.
 
Best,
Mathilde
 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_002_01CA4D89.C3F28067-- ------_=_NextPart_001_01CA4D89.C3F28067 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA4D89.C3F28067 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA4D89.C3F28067-- From jvasseur@cisco.com Thu Oct 15 06:15:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BF13A68D3 for ; Thu, 15 Oct 2009 06:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1MBZ+gMT7js for ; Thu, 15 Oct 2009 06:15:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1FFAE3A680F for ; Thu, 15 Oct 2009 06:15:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=3703; q=dns/txt; s=sjiport06001; t=1255612552; x=1256822152; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20reliability=20metrics=20for=20digital=20rad ios|Date:=20Thu,=2015=20Oct=202009=2006:15:51=20-0700 |Message-Id:=20|To:=20Philip=20Levis=20|Cc: =20Jonathan=20Hui=20,=20roll@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20<87iqeobr00.fsf@kelsey-ws.hq.ember.com>=20 <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com>=20
; bh=U6yW92W3hTg5LLAraOBs9jsEZX5ytt/1CuYiqHDZkjw=; b=lRPQsgDijGp74CotzBF1LN6kJLNYNj1lhy30ipvYpdvdxEMxQykVNvhO kuu2WQMhGWbPCUCEaoljLYf6yZ5DMxhdnqbUnJizUceBqCpffpb7UHtDG Pn6iMV9O0fQVxu+JBoUaJelVyaEWZ3sH4X+jxOuq3pSoGxGLeB9GoE1sQ 0=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKu91kqrR7Hu/2dsb2JhbADBSphYgj6BcgSKbg X-IronPort-AV: E=Sophos;i="4.44,566,1249257600"; d="scan'208";a="409952004" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2009 13:15:51 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9FDFqb7024466; Thu, 15 Oct 2009 13:15:52 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:15:52 -0700 Received: from [10.2.33.66] ([10.21.69.26]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:15:51 -0700 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 06:15:51 -0700 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Oct 2009 13:15:51.0682 (UTC) FILETIME=[9E6DEE20:01CA4D99] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 13:15:50 -0000 On Oct 14, 2009, at 6:13 PM, Philip Levis wrote: > > On Oct 9, 2009, at 9:06 AM, Jonathan Hui wrote: > >> >> Hi Richard, >> >> I agree that it is useful to discern between "okay" and "good" links. >> >> On Oct 9, 2009, at 7:07 AM, Richard Kelsey wrote: >>> I believe that the white bit in the four-bit link estimator >>> [1], has the effect of keeping traffic mostly on good links. >>> Good links have few chip errors, okay links will likely have >>> more. It appears that the four-bit link estimator does not >>> do any averaging of the white bit. It would be interesting >>> to determine how much of its performance is due to the use >>> of the white bit and how much to its ETX estimation, and if >>> it could be improved by averaging the white bit over time. >> >> The current tinyos-2.x implementation on the TI CC2420 uses the >> radio's chip correlation feedback. It doesn't use the RSSI, let >> alone compare it to the current noise floor. As you suspected, the >> implementation also does not do any averaging over time and given >> that CC2420's chip correlation value has high variability, >> averaging is likely to help. But in my experience, chip >> correlation is still a better measure of PRR than SNR. Said >> differently, chip correlation does not adequately distinguish >> "okay" and "good" links well. > > Right -- the assumption is that the real link estimation is with > packets. Receiving a packet with a very high chip correlation index > means that the link *at that time* had a high SNR, meaning it is > likely a good enough link to try (white bit set). If the white bit > isn't set, then a link has to go through a little bit of packet- > based estimation before CTP Noe will try using it. > >> >>> The 'okay' links cannot be ignored, as they are actually >>> working at the moment and may be the only thing keeping the >>> network connected. Any additive metric has to define how >>> many good links are equivalent to one okay one. This isn't >>> easy to do, because we would really prefer to use an okay >>> link only if there is no path using only good links. Except >>> in very unusual topologies, it is unlikely that you will >>> ever be faced with a choice between one okay link and, say, >>> five good ones. >> >> Mostly agree with this. One practical concern we have run into >> with utilizing "okay" links is that network deployment/maintenance >> becomes more complex for the end-user. If "okay" links are >> required for connectivity, the network will appear to function well >> at times but not others. For some end-users, it may be better not >> to function at all if "okay" links is all you have when joining a >> network. > > I agree that it's reasonable for an implementation to heavily favor > "good" links over "okay" links (tradeoff potential efficiency for > stability), or discard the use of okay links altogether. However, > user/application preference of behavior in the presence of only OK > links should be left out of the protocol specification. Some > applications would prefer "don't work unreliably" and others would > prefer "do your best." > Fully agree ! What we need to define though is how to define the metric used to characterize good, OK and bad links, with a unit. That could be as simple as a flag, could be ETX, or other forms of metric. The "how" the metric is computed is left to implementation and also depends on the link layer of course. JP. > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Oct 15 06:18:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEAE3A687F for ; Thu, 15 Oct 2009 06:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw8+b-kiLK5r for ; Thu, 15 Oct 2009 06:18:47 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 62B8F3A680F for ; Thu, 15 Oct 2009 06:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1857; q=dns/txt; s=sjiport02001; t=1255612730; x=1256822330; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20reliability=20metrics=20for=20digital=20rad ios|Date:=20Thu,=2015=20Oct=202009=2006:18:49=20-0700 |Message-Id:=20|To:=20Jonathan=20Hui=20|Cc:=20P hilip=20Levis=20,=20roll@ietf.org |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20<8240 70F1-DC8B-46B2-ACDE-38E83181B0DE@archrock.com> |References:=20<87iqeobr00.fsf@kelsey-ws.hq.ember.com>=20 <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com>=20
=20<82 4070F1-DC8B-46B2-ACDE-38E83181B0DE@archrock.com>; bh=RgY9IT8TSnW+p9Odvu45DVpe5pZy3nycutnF62ggEbk=; b=rp6+Crgwyts1Byshvm8YgAjodJipf1sNdViQ0mE9+IpRygA3M2YXVc+S pV500gJ6FAFRUOmnnGpC2ao6hR8LwW/BJFMA2uhQqxsDkbCwtyyCnrZF+ 9uZIZ8u2h1MRP8F7c/sSAnM/ZkUbYLYyd7uHw2MmLRJlfxYVuVOJ74QPo 4=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJu+1kqrR7H+/2dsb2JhbADBVJhThDAE X-IronPort-AV: E=Sophos;i="4.44,566,1249257600"; d="scan'208";a="214778603" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 15 Oct 2009 13:18:50 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9FDIojl000236; Thu, 15 Oct 2009 13:18:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:18:50 -0700 Received: from [10.2.33.66] ([10.21.69.26]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:18:50 -0700 Message-Id: From: JP Vasseur To: Jonathan Hui In-Reply-To: <824070F1-DC8B-46B2-ACDE-38E83181B0DE@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 06:18:49 -0700 References: <87iqeobr00.fsf@kelsey-ws.hq.ember.com> <99A78265-7AC3-4741-A70A-D07FF3538001@archrock.com> <824070F1-DC8B-46B2-ACDE-38E83181B0DE@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Oct 2009 13:18:50.0216 (UTC) FILETIME=[08D80E80:01CA4D9A] Cc: roll@ietf.org Subject: Re: [Roll] reliability metrics for digital radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 13:18:48 -0000 On Oct 14, 2009, at 9:48 PM, Jonathan Hui wrote: > > On Oct 14, 2009, at 6:13 PM, Philip Levis wrote: > >> Right -- the assumption is that the real link estimation is with >> packets. Receiving a packet with a very high chip correlation index >> means that the link *at that time* had a high SNR, meaning it is >> likely a good enough link to try (white bit set). If the white bit >> isn't set, then a link has to go through a little bit of packet- >> based estimation before CTP Noe will try using it. > > My experience with chip correlation is that it can be a leading > indicator of packet loss, but it's ability to discern 'good' links > from 'okay' links is limited. In the end, I think a 'link > classifier' should use whatever information it can get - that leads > me to want a metric that doesn't really have a 'unit' but instead > identifies a 'class'. That is the flag approach that I was referring to. Classification should then be left to implementation. > >> I agree that it's reasonable for an implementation to heavily favor >> "good" links over "okay" links (tradeoff potential efficiency for >> stability), or discard the use of okay links altogether. However, >> user/application preference of behavior in the presence of only OK >> links should be left out of the protocol specification. Some >> applications would prefer "don't work unreliably" and others would >> prefer "do your best." > > Of course. I just wanted to say that there are times when you want > to ignore and other times you don't want to ignore 'okay' links. > True. Should be dictated by circumstances and OF. Cheers. JP. > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Oct 15 06:22:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A5F3A6971 for ; Thu, 15 Oct 2009 06:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.592 X-Spam-Level: X-Spam-Status: No, score=-6.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HN1jSLPjszjP for ; Thu, 15 Oct 2009 06:22:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C495E3A687E for ; Thu, 15 Oct 2009 06:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=2016; q=dns/txt; s=sjiport02001; t=1255612931; x=1256822531; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Thu,=2015=20Oct=202009 =2006:22:10=20-0700|Message-Id:=20|To:=20Philip=20Levis=20|Cc:=20roll=20ROLL=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|In-Reply-To:=20<6DCB CDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> |References:=20=20<200910131011.11371.hrogge@go oglemail.com>=20<389DB2FB-DE03-476B-A6E6-11228A006982@cis co.com>=20<200910131553.47834.hrogge@googlemail.com>=20<8 7r5t79t9g.fsf@kelsey-ws.hq.ember.com>=20<6DCBCDE6-1415-44 E3-A613-A02F9F839255@cs.stanford.edu>; bh=zo5FMjx7LtB4dk0rJcgj4M3cTp+HduxaaLkNCrmzpsk=; b=JpbHqRQ4fYLuUQ2hMiKlAmAcSHmch0fqSqrxkj9+Io7j3VbBsy0twD4+ zjprX4FWpTvOlgPMFEICoEEdxylBorAtmMUCOABK7rSGuDdHD45yIgWTm on80bNnwXWgMyKg0lPvZ8YBx75NMxske/uFQVnNzjL3QnbNPPgNsIUcTw s=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJu+1kqrR7Hu/2dsb2JhbADBVJhThDAEim4 X-IronPort-AV: E=Sophos;i="4.44,566,1249257600"; d="scan'208";a="214780177" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 15 Oct 2009 13:22:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9FDMBG2000840; Thu, 15 Oct 2009 13:22:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:22:10 -0700 Received: from [10.2.33.66] ([10.21.69.26]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:22:10 -0700 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 06:22:10 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Oct 2009 13:22:10.0609 (UTC) FILETIME=[80499A10:01CA4D9A] Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 13:22:09 -0000 On Oct 14, 2009, at 9:49 PM, Philip Levis wrote: > I think we should keep in mind that RPL must work across multiple > link layers. E.g.: > > A -- 900MHz --> B -- 2.4GHz --> C > > ETX is a commonly used metric, but typically under two simplifying > assumptions: > > 1) Routes are composed of a single link layer > 2) The link layer has a static bitrate > > If you break either assumption, it doesn't work well. ETT (expected > time of transmission) can address 2), but not 1). > Not sure I would agree on this statement though. Being based on probing it's not link layer dependent. > I'm wary of encoding a metric as a hard quantity. For example, > quantifying the metric as uJ breaks when nodes have differential > energy capacities. What we really want is a more abstract notion of > cost, which a particular device can use to, in a very simple way, > express its own tradeoffs. It is critical that exactly how devices > calculate this value remain unspecified. > > My first thought would be a quantification of how much of a node's > "lifetime" a packet would cost. Such a cost can consider both the > receiver and transmitter. E.g., given its particular low power > algorithms and expected lifetime, how much would sending to this > destination consume? (I try to avoid using the word "link.") Ah you're moving to a different subject (still important) energy, that will be addressed in the draft. > > I don't think that a single metric will be sufficient; besides some > notion of cost (hopcount, ETX, ETT, etc.), the other metric that is > critical in many applications is latency. These two -- cost and > latency -- can cover a large portion of the application design > space, and provide a sound basis for the basic specification. Also covered. Stay tuned. > > Thoughts? > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Oct 15 06:23:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4562C3A6949 for ; Thu, 15 Oct 2009 06:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkdMjCVH9mSQ for ; Thu, 15 Oct 2009 06:23:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D682D28C0F4 for ; Thu, 15 Oct 2009 06:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1046; q=dns/txt; s=sjiport06001; t=1255612990; x=1256822590; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20ETX=20metric|Date:=20Thu,=2015=20Oct=202009 =2006:23:10=20-0700|Message-Id:=20|To:=20Philip=20Levis=20|Cc:=20Maxence=20Dalmais=20,=20roll@ietf.org|Mime-Version:=201.0=20(App le=20Message=20framework=20v936) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20 |References:=20=20<4AD30B6B.3030802@gmail.com> =20<1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com>=20=20 <4AD32D6F.7090406@gmail.com>=20<1B65245C-1BC6-4ECB-9CE9-7 7784668DC8B@cisco.com>=20=20=20=20=20=20=20=20=20<783087 DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com>=20=20; bh=jLCyG1Tyr4ko8Aka4oaZ7Hp5fc6utKOVhsk7mdiltjs=; b=txOZvpop8Rm9Nz3Gd3b1I3mm1YCuGtst7wFRbhzqSgII0OoVC2zuFzJs qEowdNdA7HawVBgnQv32IClvEGTGxYScqI2+Fk7bOylyN8hhg6dgs/KAl ZmRklKcAEyMkYysjPfoLVBLraeDa9FaoCliF3FbdJLPyEjlwRZxFnb4FI 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANi+1kqrR7Hu/2dsb2JhbADBUphThDAEim4 X-IronPort-AV: E=Sophos;i="4.44,566,1249257600"; d="scan'208";a="409957580" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2009 13:23:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9FDNBfO001744; Thu, 15 Oct 2009 13:23:11 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:23:10 -0700 Received: from [10.2.33.66] ([10.21.69.26]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:23:10 -0700 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 06:23:10 -0700 References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Oct 2009 13:23:10.0547 (UTC) FILETIME=[A4036A30:01CA4D9A] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 13:23:37 -0000 On Oct 14, 2009, at 9:30 PM, Philip Levis wrote: > > On Oct 12, 2009, at 3:09 PM, Maxence Dalmais wrote: > >> >> I am saying that when using wireless links, a node should be aware >> that his communication could interfere with other communication. >> Less powered is the transmission signal, less noise is seen by >> neighbours. > > It also means that it's more greatly affected by interference from > neighbors: there is no free lunch. > >> A low powered node will also need less energy to communicate in a >> less noisy environnement. > > In low-power wireless chipsets, CMOS dominates power costs. E.g., a > chip that draws 60mW transmits at 1mW. Reducing transmit power > typically does not conserve much energy. I have the same data. > >> So, it appears to me logical that when others metrics are egals to >> choose the less power needed links. > > I don't know of any strong experimental evidence supporting this > conclusion. Can you point me at some? > And same conclusion. > Phil From jvasseur@cisco.com Thu Oct 15 06:26:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E6528C0E0 for ; Thu, 15 Oct 2009 06:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.594 X-Spam-Level: X-Spam-Status: No, score=-6.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBBJEzwstHVL for ; Thu, 15 Oct 2009 06:26:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B634D3A687E for ; Thu, 15 Oct 2009 06:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=11643; q=dns/txt; s=sjiport06001; t=1255613209; x=1256822809; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20Roll=20post=20from=20thomas@thomasclausen.org=20requ ires=20approval|Date:=20Thu,=2015=20Oct=202009=2006:26:49 =20-0700|Message-Id:=20|To:=20roll=20ROLL=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|In-Reply-To:=20|References:=20; bh=qGtRPLosk0Wos+a323BD1YePbcThCkSkXGKFjX5Bu9Q=; b=awufXEu6oouUw2ZY18duc9b8NFWqET6zDcA4r7EEx9IiLyUvHpFd6h5Y jX3Mi+cpg257x24sistfpzSWd9XDtdQMBENwuo9U9eMfplp8MF6eRKRUZ PhuW2YXLToFNzyhtsc0/Ulk7TwkDVFGAOif267LbXq9xgQ4nFsIihH30h M=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAAPA1kqrR7Hu/2dsb2JhbACCKC2+fYkcjzeCMiGBXQQ X-IronPort-AV: E=Sophos;i="4.44,566,1249257600"; d="scan'208,217";a="409960097" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2009 13:26:49 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9FDQne3005763 for ; Thu, 15 Oct 2009 13:26:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:26:49 -0700 Received: from [10.2.33.66] ([10.21.69.26]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 06:26:49 -0700 Message-Id: From: JP Vasseur To: roll ROLL In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-71-280618802 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 06:26:49 -0700 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Oct 2009 13:26:49.0597 (UTC) FILETIME=[2693CAD0:01CA4D9B] Subject: Re: [Roll] Roll post from thomas@thomasclausen.org requires approval X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 13:26:47 -0000 --Apple-Mail-71-280618802 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 15, 2009, at 1:47 AM, roll-owner@ietf.org wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: Roll@ietf.org > From: thomas@thomasclausen.org > Subject: Re: [Roll] feedback on draft-ietf-roll-rpl-03 > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > https://www.ietf.org/mailman/admindb/roll > > to approve or deny the request. > > From: Thomas Heide Clausen > Date: October 15, 2009 1:47:31 AM PDT > To: "Mathilde Durvy (mdurvy)" > Cc: "Emmanuel Baccelli" , "ROLL WG" > > Subject: Re: [Roll] feedback on draft-ietf-roll-rpl-03 > > > My 2 cents... > > On Oct 15, 2009, at 10:44 AM, Mathilde Durvy (mdurvy) wrote: > >> Hi Emmanuel, >> >> I very much agree with your comments. Especially with the two >> points below that could reduce a lot the complexity. >> >> # Section 2 >> I am wondering if some of the terms are unecessary at this point. >> In particular, DAG siblings. Since siblings introduce quite a >> tricky complexity/benefit trade-off, I would be in favor of >> getting rid of these in the core RPL document. This could be a >> welcomed simplification. >> Agree, for me siblings are note part of the core. > > +1 -1 ;-) Actually this is not so bad ... yes you need a loop detection mechanism or just limit the TTL for the moment. > >> >> # Section 3.2.1: >> "RPL constructs one or more DAGs". The consensus is that the core >> RPL document should specify how to build a single DAG to reach a >> single destination. This may be used to simplify the document a bit. >> Agree. I think what is needed are just procedures to join a DAG and >> leave a DAG. >> > > +1 Oh yes, we already reached a consensus on this in the WG. Applicability statements are there to explain how to use more than one. There will be another ID to identify the DAG, discuss jump DAG, out of the core spec. Thanks. JP. > > Thomas > >> Best, >> Mathilde >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > > > From: roll-request@ietf.org > Subject: confirm aad2cecadd356bf492342e8c066ec13ebeca7fdf > > > If you reply to this message, keeping the Subject: header intact, > Mailman will discard the held message. Do this if the message is > spam. If you reply to this message and include an Approved: header > with the list password in it, the message will be approved for posting > to the list. The Approved: header can also appear in the first line > of the body of the reply.If you reply to this message, keeping the > Subject: header intact, > Mailman will discard the held message. Do this if the message is > spam. If you reply to this message and include an Approved: header > with the list password in it, the message will be approved for posting > to the list. The Approved: header can also appear in the first line > of the body of the reply. > --Apple-Mail-71-280618802 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 15, 2009, = at 1:47 AM, roll-owner@ietf.org= wrote:

As list administrator, your authorization is requested for = the
following mailing list posting:

   List: =    Roll@ietf.org
=    From:    thomas@thomasclausen.org
=    Subject: Re: [Roll] feedback on = draft-ietf-roll-rpl-03
   Reason:  Post by = non-member to a members-only list

At your convenience, = visit:

   https://www.ietf.org/ma= ilman/admindb/roll

to approve or deny the = request.

From: Thomas Heide Clausen <thomas@thomasclausen.org><= br>
Date: October 15, 2009 1:47:31 AM PDT
To: "Mathilde Durvy = (mdurvy)" <mdurvy@cisco.com>
=
Cc: "Emmanuel Baccelli" = <Emmanuel.Baccelli@inria.fr&= gt;, "ROLL WG" <roll@ietf.org>
Subject: = Re: [Roll] feedback on = draft-ietf-roll-rpl-03


My 2 = cents...

On Oct 15, 2009, at 10:44 AM, Mathilde Durvy = (mdurvy) wrote:

Hi Emmanuel,
 
I very much agree with your comments. = Especially with the two points below that could reduce a lot the = complexity.

# Section 2
=
I am wondering if some of the terms are unecessary at this point. = In particular, DAG siblings. Since siblings introduce quite a tricky = complexity/benefit trade-off, I would be in  favor of getting rid = of these in the core RPL document. This could be a welcomed = simplification.
Agree, for me siblings are = note part of the core.
=

+1

-1 ;-) Actually this is not so bad ... yes you = need a loop detection mechanism or just limit the TTL for the = moment.


 
 # Section 3.2.1: 
=
"RPL constructs one or more DAGs". The consensus is that the core = RPL document should specify how to build a single DAG to reach a single = destination. This may be used to simplify the document a bit. 
Agree. I think what is needed are just procedures = to join a DAG and leave a = DAG.  


+1

Oh = yes, we already reached a consensus on this in the WG. Applicability = statements are there to explain how to use more than one. There will be = another ID to identify the DAG, discuss jump DAG, out of the core = spec.

Thanks.

JP.
<= br>
Best,
=
Mathilde 
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



Subject: = confirm = aad2cecadd356bf492342e8c066ec13ebeca7fdf


If = you reply to this message, keeping the Subject: header = intact,
Mailman will discard the held message.  Do this if the = message is
spam.  If you reply to this message and include an = Approved: header
with the list password in it, the message will be = approved for posting
to the list.  The Approved: header can also = appear in the first line
of the body of the reply.If you reply to = this message, keeping the Subject: header intact,
Mailman will = discard the held message.  Do this if the message is
spam. =  If you reply to this message and include an Approved: = header
with the list password in it, the message will be approved for = posting
to the list.  The Approved: header can also appear in = the first line
of the body of the = reply.


= --Apple-Mail-71-280618802-- From sung.lee@us.fujitsu.com Thu Oct 15 07:20:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9B83A6926 for ; Thu, 15 Oct 2009 07:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRuedh7zkegh for ; Thu, 15 Oct 2009 07:20:21 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 5C6B63A68E2 for ; Thu, 15 Oct 2009 07:20:21 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9FELLqf005017 for ; Thu, 15 Oct 2009 07:21:21 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9FELL8U005011 for ; Thu, 15 Oct 2009 07:21:21 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id n9FEKNaL029702 for ; Thu, 15 Oct 2009 07:20:23 -0700 (PDT) Received: from [10.157.253.51] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n9FEKMF14734 for ; Thu, 15 Oct 2009 07:20:22 -0700 (PDT) Message-ID: <4AD72F96.6030800@us.fujitsu.com> Date: Thu, 15 Oct 2009 10:20:06 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 14:20:22 -0000 JP and WG members, This may be considered link reliability. But in our experience, we found the following information very helpful in improving the stability of network and also (and you could say) in avoiding loops as well. We use what we call 'W' (weight). When we forward data packet, we require per-hop ACK. When we receive ACK, we adjust the new W to be old W -1 (W_new = W_old - 1). When we don't receive ACK, we adjust the new W to be old W + 1 (W_old = W_old +1). When we detect a loop, we adjust the W value to MAX. We have experimented MAX value based on real system, MAX value of 10 seems to be a good value to start with. Now this can be combined with other metric values you are all discussing. We have experimented quite a lot with combing several metrics with the above weight in determining the path, which so far seems to work in our system. For instance, the other metric values you are discussing (such as link quality, RSSI, and/or everything else - please note this can be as simple as hop count, RSSI, or whatever the WG determines) can be used with along with W value to determine. I am interested in what the WG thinks of using this 'W' as part of metric for RPL. Best regards, Sung roll-request@ietf.org wrote: > Message: 1 > Date: Wed, 7 Oct 2009 20:07:52 +0200 > From: JP Vasseur > Subject: [Roll] RPL Metric ID > To: IETF ROLL > Cc: Kris Pister > Message-ID: > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > DelSp="yes" > > Dear all, > > We would appreciate your feed-back on RPL routing metrics. > > Now that RPL is stabilizing it is time to move forward with the METRIC > I-D. The next revision will be a major one, with packet encoding, > processing rules, etc. > > We discussed and agreed some time ago on several links and nodes > metrics (also required according to our requirement IDs). > > Still, there are a few metrics for which we would like to know whether > you think that they should be specified. > > 4.2. Latency > > As with throughput, the latency of many LLN MAC sub-layers can be > varied over many orders of magnitude, again with a corresponding > change in current consumption. Some LLN MACs will allow the latency > to be adjusted globally on the subnet, or on a link-by-link basis, > or > not at all. Some will insist that it be fixed for a given link, but > allow it to be variable from link to link. For efficient operation, > nodes must be able to report the range of latency that their links > can handle, and the currently available latency. > > 4.3. Link reliability > > In LLNs, link reliability is degraded by external interference and > multi-path interference. Multipath typically affects both > directions > on the link equally, whereas external interference is sometimes uni- > directional. Time scales vary from milliseconds to days, and are > often periodic and linked to human activity. Packet error rate can > generally be measured directly, and other metrics (e.g. bit error > rate, mean time between failures) are typically derived from that. > > In addition: > > Node Memory resources: > > Memory is a critical node resources in presence of constrained nodes. > Is there a need to report node memory resources as a routing metric/ > constraint ? > > Node CPU resources: > CPU duty cycle for virtually all LLN applications to date is well > below 10%, and the trend in low power embedded systems is to more > capable processors rather than less. Computational speed is not > expected to be a limiting factor in routing in LLNs. Is there a need > to report node CPU resources as a routing metric/constraint ? > > Link Security metrics > > Thanks for your feed-back. > > JP, Mijeon, Kris. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > End of Roll Digest, Vol 21, Issue 11 > ************************************ > From richard.kelsey@ember.com Thu Oct 15 07:28:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49313A693F for ; Thu, 15 Oct 2009 07:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GphqfAgNbGiA for ; Thu, 15 Oct 2009 07:28:37 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 830603A6914 for ; Thu, 15 Oct 2009 07:28:37 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 10:29:48 -0400 Date: Thu, 15 Oct 2009 10:26:50 -0400 Message-Id: <87d44oag2d.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> (message from Philip Levis on Wed, 14 Oct 2009 21:49:10 -0700) From: Richard Kelsey References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> X-OriginalArrivalTime: 15 Oct 2009 14:29:48.0135 (UTC) FILETIME=[F2C2EF70:01CA4DA3] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 14:28:41 -0000 From: Philip Levis Date: Wed, 14 Oct 2009 21:49:10 -0700 I think we should keep in mind that RPL must work across multiple link layers. E.g.: A -- 900MHz --> B -- 2.4GHz --> C Or maybe a PLC link or two. ETX is a commonly used metric, but typically under two simplifying assumptions: 1) Routes are composed of a single link layer 2) The link layer has a static bitrate If you break either assumption, it doesn't work well. ETT (expected time of transmission) can address 2), but not 1). I'm wary of encoding a metric as a hard quantity. For example, quantifying the metric as uJ breaks when nodes have differential energy capacities. What we really want is a more abstract notion of cost, which a particular device can use to, in a very simple way, express its own tradeoffs. It is critical that exactly how devices calculate this value remain unspecified. I would agree that this is true as far as ROLL and the IETF is concerned. More concrete and layer-specific specifications can, and probably will, be produced by other organzations. My first thought would be a quantification of how much of a node's "lifetime" a packet would cost. Such a cost can consider both the receiver and transmitter. E.g., given its particular low power algorithms and expected lifetime, how much would sending to this destination consume? (I try to avoid using the word "link.") An 'available bandwidth' metric works for this. For a battery powered device you know the desired lifetime, the amount of energy in the battery, and how much of this will be consumed by the device itself. The leftover energy, divided by the desired lifetime and the cost of sending and receiving, gives the bandwidth the device can donate to the network. This works for energy scavenging devices as well, assuming that the scavenging rate is predictable. I don't think that a single metric will be sufficient; besides some notion of cost (hopcount, ETX, ETT, etc.), the other metric that is critical in many applications is latency. These two -- cost and latency -- can cover a large portion of the application design space, and provide a sound basis for the basic specification. I think three metrics are needed: - latency - bandwidth (which subsumes energy limits, as above) - reliability The units for the first two are straightforward. The third is a puzzler. -Richard Kelsey From sung.lee@us.fujitsu.com Thu Oct 15 08:06:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBDD63A6985 for ; Thu, 15 Oct 2009 08:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9N8V15ZoZWo for ; Thu, 15 Oct 2009 08:06:19 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 44B0E3A689F for ; Thu, 15 Oct 2009 08:06:19 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9FF7Fxl018994; Thu, 15 Oct 2009 08:07:15 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9FF7EvN018989; Thu, 15 Oct 2009 08:07:14 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id n9FF6Hn7006170; Thu, 15 Oct 2009 08:06:17 -0700 (PDT) Received: from [10.157.253.52] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n9FF6FF16315; Thu, 15 Oct 2009 08:06:15 -0700 (PDT) Message-ID: <4AD73A51.10501@us.fujitsu.com> Date: Thu, 15 Oct 2009 11:05:53 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <4AAA5CE0.9060008@us.fujitsu.com> <4AB0C269.3090203@cttc.es> <4AB3D4A1.60805@eecs.berkeley.edu> <4AB9F844.60603@us.fujitsu.com> <4AD68772.4070903@us.fujitsu.com> In-Reply-To: <4AD68772.4070903@us.fujitsu.com> Content-Type: multipart/mixed; boundary="------------070807020607090609010008" Cc: roll@ietf.org Subject: Re: [Roll] Determining DADR Contributions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 15:06:21 -0000 This is a multi-part message in MIME format. --------------070807020607090609010008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Philip, Here is some additional information from our team in Japan. > IEEE802.15.4 > Center freq.: 2.405GHz (11 ch) > less interference because 802.11 does not use same center frequent band > (2.412GHz (1ch)) Center freq. of 1ch(IEEE802.11b/g) is 2.412GHz and bandwidth of the signal about 22MHz like the attached file. http://en.wikipedia.org/wiki/IEEE_802.11 Then, 2.400GHz-2.424GHz is used for the WiFi 1ch. Therefore, the WiFi(1ch) causes interference on IEEE802.15.4(11cn) in a strict sense. > less interference because 802.11 does not use same center frequent band I should have said "a little interference from the IEEE 802.11(1ch)". Regards, Sung Sung Lee wrote: > Philip, > >> What 802.15.4 channel did you use, and what 802.11 channels did the >> APs use? > > Here is the information you asked. IEEE802.11b > Center freq.: 2.484GHz (14 ch, Japanese use only) > there are few coexistence systems. > > IEEE802.15.4 > Center freq.: 2.405GHz (11 ch) > less interference because 802.11 does not use same center frequent band > (2.412GHz (1ch)) > > Please let us know if you have any questions. > Best regards, > Sung > > > > Philip Levis wrote: >> >> On Sep 23, 2009, at 3:28 AM, Sung Lee wrote: >> >>> Mischa, Thomas, and ROLL WG members, >>> >>> We have *very preliminary* results from DADR implementation over >>> 802.15.4, indoor experiments. >>> Please note that these are preliminary results and we are continuing >>> with our experiments. More complete results for indoor and outdoor >>> will >>> be shared before the interim meeting. >>> >>> Some facts: >>> >>> * This summarizes the indoor, multi-floor office building experiment. >>> * Dimension of the building is roughly 30m x 20m, 2 floors involved >>> * There were several active WLAN APs (interference from 802.11 >>> present). >> >> Sung, >> >> What 802.15.4 channel did you use, and what 802.11 channels did the >> APs use? >> >> Phil > > --------------070807020607090609010008 Content-Type: image/png; name="2.4 GHz Wi-Fi channels.png" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="2.4 GHz Wi-Fi channels.png" iVBORw0KGgoAAAANSUhEUgAAAyAAAADHCAYAAADh2TfPAAAABGdBTUEAALGPC/xhBQAAAAFz UkdCAK7OHOkAAAAgY0hSTQAAeiYAAICEAAD6AAAAgOgAAHUwAADqYAAAOpgAABdwnLpRPAAA AAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAl2cEFnAAADIAAAAMcA py3jKwAAgABJREFUeNrsvXdYk+f7//1O2HtvlCkICKiIKIjiwrpH3a3Vj+vrqFWrtnXUUffe s3XvWesWF+4tMkRA9t4QQsjO+fzRX+7HuEVG2t6v4+jRw5DkPnPNc13nxSEiAgsLCwsLCwsL CwsLSx3AZZuAhYWFhYWFhYWFhYU1QFhYWFhYWFhYWFhYWAOEhYWFhYWFhYWFhYWFNUBYWFhY WFhYWFhYWFgDhIWFhYWFhYWFhYWFhTVAWFhYWFhYWFhYWFhYA4SFhYWFhYWFhYWFhTVAWFhY WFhYWFhYWFhYWAOEhYWFhYWFhYWFhYU1QFhYWFhYWFhYWFhYWFgDhIWFhYWFhYWFhYWFNUBY WFhYWFhYWFhYWFgDhIWFhYWFhYWFhYWFhTVAWFhYWFhYWFhYWFhYA4SFhYWFhYWFhYWFhYU1 QFhYWFhYWFhYWFhYWAOEhYWFhYWFhYWFhYU1QFhYWFhYWFhYWFhYWFgDhIWFhYWFhYWFhYWF NUBYWFhYWFhYWFhYWFhYA4SFhYWFhYWFhYWFhTVAWFhYWFhYWFhYWFhYA4SFhYWFhYWFhYWF hYU1QFhYWFhYWFhYWFhYWAOEhYWFhYWFhYWFhYXlc9Bkm4CFhYWFhYWFheWfTnl5OSIjI8Hl ctG+fXsYGRnV6fNLSkpw9epVGBoaon379tDX12c75T1wiIjYZqg/eDweLl++DIlEAkNDQ3To 0AHGxsZqJ6dUKkVUVBSSkpLg4eGB5s2bQ1NT/ezXrKws3L17F8bGxggKCoKFhYVa9rtUKsWt W7eQl5cHAwMDdOnSRe0WqpiYGMTExDD/dnd3R1BQEDgcjlrJKRaLcePGDRQXFyMgIABeXl5q JV9FRQWuXbsGgUCg8rqDgwNCQ0PVah6Vl5fj4cOHKCkpQYsWLdCoUSO1628AyMjIwOPHj6Gn p4fWrVvD3NxcLeRKS0vDvXv3QESwt7dHu3btoKGhASJCQkICYmNj4ejoiBYtWkBbW7ve5Hz1 6hUePXoEIoKjoyPCwsIgl8tx7do1FBYWgsvlIiQkBE5OTvUmY2VlJW7cuAEej/fW3lhQUIB7 9+6By+UiKCgItra29SZneno67t27B4VCARsbG3Ts2BFcLhcymQwxMTGIj4+Hu7s7mjZtCl1d 3X+8zlJSUoIbN25AJBLB0tISYWFhzO8iIjx58gSJiYnQ1tZG+/btYWVlVavySCQSxMXFIT4+ Hp6entDS0kL37t2hpaWFK1euoFGjRnXaPg8fPkRoaCjc3NwQERGBBg0asIru+yCWeiUuLo4M DAwIADk5OVFiYqLaySgSiWjlypVka2tLAMjOzo7Wr19PEolEreSMioqitm3bEpfLJQMDA+rZ syclJSWpZb8/fPiQ7O3tCQA1aNCAMjMz1Uo+hUJBU6dOJQDMfyNGjCCpVKp2bXnhwgUyNzcn W1tbunPnjtrJFx8fz8wd5X8cDofmzp1LMplMbeTMyMigAQMGkKmpKWlra5OHhwcdPnyYFAqF WrXn5cuXqVmzZgSAdHR0qHfv3pSenq4Wsu3Zs4fp4/DwcKqqqiKFQkEnT54kT09PAkBWVla0 YsUKEovF9Sbn5s2bGTl79OhBCoWCRCIRBQUFEQDS0NCgI0eO1GtbpqSkkJubGwEgFxcXSkhI YPbMdu3akYaGBmlqalL79u0pNja23uTcv38/05bt2rUjiURCMpmMduzYQXZ2dkyfz549mwQC wT9eZ3nw4AGZm5sTAAoKCqKCggLmb9nZ2cwYMjExoXv37tWqLGVlZTRjxgxmfe3Rowc9ePCA HBwcyNnZuV72/wcPHpC2tjZ5eXmp3b6ubrBnQOoZMzMz9OzZE5qamuBy1bM7YmJisHLlSlRU VCA4OBiFhYVYv349kpOT1UZGhUKBY8eO4fnz5xg1ahR8fX1x9uxZHDlyBOoW5JNKpdi7dy8K CgoAQC37XSaToby8HJqammjfvj2GDx+OsLAwtZO1srISv//+O8rKyvDdd9+hdevWateWpqam +PbbbzFy5EimDV1cXDBo0CBoaGiojZznzp3DiRMnEBAQgPnz5yMlJQV79+59K3JTn5SWlmLh woWIiopCSEgIHB0dcebMGRw8eFAt5PPw8EBwcDAAgMPhgMPhIDc3F4sXL0ZmZibCw8Mhk8mw fPlyREVF1Zuc3t7eCAwMZOQEAA0NDXTv3h2WlpaM7PWJsbExwsPDoa+vz8iiUCiwdetW3Lx5 E15eXnBzc8ONGzewY8cOKBSKepHT3d0dbdq0Uenz0tJSHDp0CJqampg6dSqkUinWrl2Lx48f /+N1Fmtra3Ts2BGampoqY4SI8Ndff+H58+fgcDi1vlcoFArs3LkT69atg1wux5AhQxAQEPDW fl9VVaUyNsRiMaRSKUQiEfh8PkQiEeRyOSorKyEQCKBQKJj/A4BQKASfz4dMJoNYLIZYLFb5 fpFIhMrKSrXTM/4JsAZIPWNvb4+ffvoJOjo6ajuA8/LyoFAo4OnpialTp0JfXx98Ph+VlZVq IyOHw8G4ceNw7do1tG3bFgqFAhwOBzKZTO3a89mzZ7h69So6dOigtv1eVVWFV69eQaFQID8/ HzY2NujcubPaGSC3bt3CtWvXYG5uDiMjI0RHR9ebIvI+7OzssHLlSmzevBnOzs4gIvTu3Rse Hh5qJaeWlha0tbVRXl6OtLQ0cDgcaGlpqdX45PP5KCgogKamJqZNm4ZevXqBiBAbGwu5XF7v 8rVu3Rrffvst828NDQ08f/4cL168gL+/P37//Xd069YNpaWlePToUb3JGRYWhoEDB6q8pqmp iR9//BGurq5qMYcsLS3x/fffw9TUFEQEDocDsViMpKQkGBsbY+zYsejevTsAIDs7u976v1Wr Vip9TkQwMTHB1q1bsXv3bhgbG0NTUxPa2tpqmc74ubi4uOD//u//3tq7cnNzceDAAbRs2RKm pqa1PoZ4PB5Onz4NqVSKSZMm4cCBA5g1axaTDsblcnH27Fl0794dmzdvhkwmQ3x8PL777juM Hz8eP/zwA0JDQ7Fo0SI8e/YM3bp1w3fffYd169ahS5cuWLt2LXg8HubMmYOwsDCsW7cOw4YN w7Bhw5CYmAgiwo0bNzBgwAC0b98ey5YtA4/H+1f0cV3BHkJXA9RNYXqTtm3b4saNG9DW1sa5 c+cgFArh6empVrmNHA4HDRs2hLm5OaZPn45Hjx7B29sbX3/9tVotCBKJBHv27IG7uzs6deqE Gzdu1Im3qDqLe0lJCYyMjJCYmIiXL19CKBRi1apV9Zq7/jpSqRR//fUXKioqYGpqihUrVmDX rl3Ytm0bwsPD1W4eRUZG4tSpU7C2tsbgwYPV7gxVr169cP78efz11194+vQprKysMHz4cBga GqqNjMbGxnBwcMCrV69w+vRpJCcng8PhwNbWVm3m0OtKGREhNzcXYrEYZmZmMDMzg62tLXMm RF3kfH0vUieD8/W9kYigo6ODrVu3QigUQkNDA//73//A4XDQtm1baGlpqU1bamtro3HjxkhP T8eCBQsAAKNHj0ZAQMC/Vmc5deoUBAIBpkyZgl9++QVisbhWI7zl5eUoLi4Gh8NB06ZNweVy oa2tzawDRUVFWL16NXJzc5GZmYmvvvoKu3btwrFjx6ChoQFdXV0IBAI0adIEfD4fsbGxqKqq QmRkJEpLS5GRkYEOHTogPT0dz549Q2ZmJsrLyyGTyRAYGIiwsDCMGTMGWlpa4HK5mDt3LkxM TNCiRQtWqf1E2AgIy0cxNTVFkyZNmJCnkZERvv/+e9jY2KiNjEQEhUIBLpeLvn37wtPTEwUF BXj27JlabagvX77EhQsXYGBggKioKCgUCvD5fDx9+lSt5DQ3N8ehQ4dw9+5d/Pzzz9DS0sL5 8+dRXFysNjJWVFTg3r170NbWxoIFCzBkyBCkpaXh9OnTauENfx2RSIRjx46hoqICPXv2hL+/ v9rN8wcPHiAqKgoeHh7o1q0bxGIxzp49q1aRTjMzM0ydOhXNmjXD1atX8ejRI+jq6qJjx45q 6XnkcDjQ0dEBAMjlcmadAsC8zvIZCguXCzc3N/j4+ODMmTOIiopCly5dMGDAALWSU9nPjo6O +Pbbb2FiYoJHjx4hLS3tX9cnHA4HRUVFOHDgAHR1dREbGwuBQACJRIIHDx5AIpHUynM1NDQY A+fNTAcOhwNNTU2MHz8ednZ2yM/PR05ODu7evQsA6Ny5M5M2x+VyGSegoaEhZs6cCUtLS4hE IggEAuYZX3/9NXr27AngbwfdX3/9hZSUFJSUlKCgoAAymQxnzpyBUChkJyprgLDUJMXFxZg5 cybS0tIwZcoUdO3aVa0iNyKRCNu2bcNvv/2GwMBAtGzZEiUlJbh9+7ZaKaPFxcUoLi7G8ePH sX//figUCpSWluLixYtq1Z5lZWXQ1dWFnZ0dbGxswOVyYWRkVK9exjdRKBSQSqXgcDiwtraG iYkJgL/TdNTNAImOjsalS5dgbGyMwYMHq53yqVAocOPGDWRmZqJ58+b47rvvIJfLceHCBeTk 5KiVrD179sTZs2fRv39/EBGCgoLQqlUrtVw3iQhubm4wNTVFWloaoqKiEB8fDy6XCz8/P3Zj qSbnzp3D2rVr0axZM8yePZuZ++piJL169Qq//PILLl++jIkTJ8LOzg4xMTF4/vz5v9IAKSsr Q2ZmJh49eoS1a9dCIBBAKBTizJkzEIlEtfJcExMTWFpagogQERGB3NxcpKenQyQSgYhgZmb2 VuUxqVQKADAwMHjnXqajowNfX993/s3d3V2l2lpJSQkAwMLCAl9//TW++eYbZh1i07A+DTYF S402KnU9AyIWi7Fx40acO3cORIQ9e/bg+vXr2LVrF1xdXdVjIGtqIjo6Gjt27MCePXsgEAig qakJT09PtUpvcnJywuTJkyEUCpGTk4PTp09DR0cHrVq1UqtF6+zZs1i0aBEMDAyQn58PIsKg QYPUptypcgPq0KEDtm7dih9++AFisRg6OjoICgpSK0NJKpXiwIEDyMvLQ+/evREUFKR+nigu F97e3tDV1cXZs2dx48YNCAQCtGzZEpaWlmqn8PB4PFy8eBGampoYOXKkWsmoXMeVXnBfX1+E hYXh9OnTGDRoEIqLi9G4cWPmsLo6yKnOe9Gb8rx48QKzZ89mvM6jRo1Ct27dsHbtWrVpSw0N DZw9exZJSUmwt7dHXl4ebG1t1Wa/rMl+USr748ePR1lZGcrLy3H8+HFIJBKEhITUWsquiYkJ Ro4ciefPn+OPP/5AREQEmjdvjkmTJjFyKVMKiQgGBgZo2bIlnj59ikuXLjH77et99+ZnXv+7 XC5XcRK2b98ee/bsYQoIPX/+HMHBwdDV1VW7VEbWAGH5oPJsbW0NCwsLtaqKo5x858+fx5Ej R2BmZgbg79SX8vJytfIya2lp4ccff0RVVRWuXLmCBg0aYPDgwRgxYoRaGSDu7u5YsmQJAODJ kyd49uwZTExMEB4ernaGkr+/P549ewZnZ2cMGTIE48aNU6vxqa2tjWnTpkEikeDixYuwsrLC kCFDMGzYMLUy5tLT0/HgwQM4ODio3ZmK1xk4cCDKy8tx4MABFBQUYODAgZg2bZra3aUjk8lw 6tQpVFRUoHv37kxahLqgr68Pa2trZr00NjbGwoULoaOjg9u3byMkJAQzZ86s8/sJ3sTAwADW 1tYwNTVVMe7Mzc1hbW2tFlE6TU1NWFpaQkdHB5qamqioqMCmTZtQUFAAa2trKBQKlJSU1Hua 4Ot9TkRwcXHB6tWrsXz5csTHxyMkJAQTJ05Ey5Yt/xU6i7a2NqytrWFubg4OhwNLS0vMnTsX AJCZmYnnz5+jsrISvXv3rtW7TwYOHAiZTIZdu3YhMTERDRs2hJGRETNmdHR0mCiJvr4+Ro0a hejoaMhkMri7u+Pq1aswMTGBtrY2rKysoK2tDW1tbVhaWkImk0FLSwsmJiawtraGgYEBjI2N YW1tDX19fXTr1g3z58/Hvn37cPr0aXTs2BHh4eHg8/mMPqeulU3VxpnEXkRY/4jFYuTm5kJD QwN2dnZq5b0F/r70ic/nqyh1mpqasLe3VztZhUIh8vPzoaOjo1YHU9+FSCRCXl4euFwuHBwc 1O5QMp/PR1FREfT09Jg0LHWdP3l5edDW1lbLPq+qqmJKLjs4OKjNIf73ORwKCgpQVVUFW1tb tbzFV1mZTSgUwtjYuNYvOvtcKioqUFRUBH19fdja2jLrpkAgQFFREYyNjdUiklheXo6SkhIY GBgwqSUKhQK5ubmQSCSwtraud2NZIpEgLy8PHA4HdnZ2zKH+N51fhoaG9XomUdnnenp6sLOz Y/q8tLQUZWVlMDc3ZwzSfwPKfVa55r7umJJKpcjNzYVCoYCdnV2dXL5YUlICHo8HKysr6Ojo MGPGwsICJSUlkMvlsLe3h46ODgoLC5mCBspCK0ZGRigoKACHw4GVlRWKiopARLC1tQWPx0Nl ZSUsLCwglUpRUVEBMzMzmJubg4iQn58PsVgMGxsb6OnpQSQSITc3F1paWrCzs1PLC5tZA4SF hYWFhYWFhYWF5T8HGx9iYWFhYWFhYWFhYWENEBYWFhYWFhYWFhYW1gBhYWFhYWFhYWFhYWFh DZB/C2VlZWp/M7pIJAKPx1NrGUtLS9+6nEgdUd6sqs4IhUK1uozuffD5fFRVVam1jDKZDKWl pe/9W1lZmVqUb5TJZO+d41KpFGVlZfUuIxGhtLRU7ddLpZzqdjfNu+bPu+5sUN6doC5UVla+ ddkbEanVOkpEKCkp+c+UYpXL5e9d1/4tezVLzcMez68FcnJycPbsWaSmpiI0NBSdOnWCnp7e Rz/39OlTpKSkoH///sjIyMDu3bshEonQq1cvpmZ8Wloajh8/jrKyMnTq1Alt27atViUqIkJS UhLOnDmD0tJS9OzZE0FBQR8ts6pQKHDhwgW4ubnBz88P165dQ0REBCwsLDBy5EhYWVnh5MmT uH//PoC/yzpqaGhAS0sLgwYNQpMmTT5ZxoqKCpw9exZRUVFo0qQJ+vTpo1Iy8n1kZ2fj+vXr GDBgADQ1NVFWVoZz584hOjoazZo1Q+/evZnqLmVlZbh48SKioqLg5+eHHj16fHa1kqKiIpw/ fx4vXrxAYGAgunbtCiMjo49+LiEhAY8fP8bgwYMBAIWFhThx4gTS0tIQHByMr776Cnp6enjw 4AFOnTrFKFrKG2C7d++OkJCQT1Yo7927hytXrsDQ0BB9+/aFh4fHRz8nFouxb98+dOrUCYaG hpBKpbh16xauXLkCZ2dn9OvXD9bW1swzbt++jUuXLsHKygr9+vX77Lr3crkc9+/fR0REBPT1 9dGnTx94enp+tKxuVVUVjh49ip49e0JfXx9SqRR37txBREQEGjRogH79+sHW1hZJSUnYu3cv xGIx05YcDgfBwcHo3r37J5cZTklJwbFjx1BZWYnw8HCEhIR8UrWT27dvg4jQoUOHt/527949 CAQCdO3alRkf586dQ1lZGbp27YpWrVp9dkWVtLQ0HDt2DDweD507d0ZoaOhHv4OIcO7cOVhb W7/zrorr16/D0NAQ/v7+2LZtG/Lz81Xmuq2tLYYPH/7J86i0tBQXLlxg5mf37t0/6WK52NhY xMfHY9CgQcz4O3ToEGJiYgAALVu2RP/+/cHlclFaWoo///wTL1++RIsWLdCjR4/PrvBUVFSE M2fO4OXLl2jdujW6dev2Set6fHw8oqOjMWTIEGaMHzlyBM+fPwcRISAgAAMGDMD58+dx+/Zt lbbU09PDoEGD0Lhx40+SUTk/L1++DFtbW/Tr1w/Ozs6f1AcnTpzAgAEDVKoWPXr0CBEREZg8 eTKzpkkkEty8eRPXr1+HjY0N+vTp80nPeNOpce3aNdy6dQvOzs7o06cP7O3tP8lhc+zYMXz9 9dcqbX/p0iU8f/4cU6dOha6uLqKjo3Ho0CHG6NPQ0ACXy0VISAi6dev2yZXyCgoKcPz4cWRk ZKBNmzbo0qXLJ1V1io2NRXJyMrp164Y//vgD6enpKv1qbm6O7777DmZmZrh+/Tpu3boFGxsb DBo0CHZ2dvWmu+Tm5uKvv/5Camoq2rVrh86dO39SOWblhb8dO3Zk+kk534KDgxEeHv7OinqZ mZm4desWs1dX19h79eoVbty4gVevXsHGxgYdOnSAt7f3J83P2kIkEmHfvn149eoViAgcDgeD Bw9GQEAAqyT/P9gISA1TXFyMn376CbGxsTA1NWVuvP6YJ6SwsBDz589Hbm4uuFwuhEIhuFwu Dh48iBcvXgD4+z6BWbNmoaCgAAYGBti9ezcuXLhQLTkTEhIwe/ZslJSUQE9PD1u2bEFkZORH P3fz5k2sX78e2traICKIRCIUFBRg165djJdcU1MT5ubmMDc3h76+Pvbv349nz54xiuqnIBaL sXLlSkRERMDc3ByPHj3CunXrPnqralVVFVatWoWYmBjo6OigqqoKS5YsQWRkJMzNzXHr1i1s 2bIFMpkMIpEIy5Ytw6VLl2BmZoZbt25h7dq1kEgkn+WNmzNnDm7fvg0zMzNcvnwZW7du/ahH p6KiAkuWLEFCQgK0tLRQVlaGX3/9lRk3Z8+exd69e6FQKFTa08zMDFevXsXp06c/6/K1s2fP Yvny5dDR0QGfz8e8efOYTfFDC/upU6dw6NAhGBgYAADOnz+P9evXw8DAAI8fP8bSpUsZZf7E iRPYuHEj9PX1UVJSgsWLFyM7O/uzxuWFCxewZMkSaGlpQSAQYP78+UhJSfmo0fLHH3/gypUr zCYXERGBNWvWQF9fH1FRUVi8eDGEQiE0NTWZEooWFhaIjo7G/v37YWho+MlKyatXrzBz5kyU lpZCT08PO3bswJUrVz76uZcvX2LhwoXv9IQnJCRg8eLFzDqRkJCAn3/+GcXFxdDX18e6detw 7dq1z2rL1NRUzJw5kykJu3PnTly8ePGTHCHKu2reJDo6GkuXLmXGh76+PtOWfD4fGzduhEgk YsbLx6iqqsKiRYtw9epVmJmZ4dq1a1i/fv1Hve75+flYsGCBSnlwpdNGV1cXFhYWMDIyApfL hUAgwMKFC3H//n2Ym5vj2rVr2L59+2d5XXk8HubNm4fHjx/D3NwcFy5cwK5duz4afSksLMSC BQtQXl7OyJmdnY1du3ZBS0uLkZPD4UBPT4+Z53p6ejh69CjzvE/l6NGj2LJlCwwNDVFYWIgl S5YgLy/vo86J7du348KFCypKYnZ2NubNm4fy8nKmdDQR4dChQ9i4cSMMDQ2Rm5uLBQsWMGWm PwWFQoEtW7Zg165dMDExQXJyMhYvXvzRqJpynp85c0ZFzpSUFCxbtgxSqZRRYjkcDkxNTZmx ee/ePRw8eBCWlpaffEdQaWkpfv31V8THx8PU1BSnT5/+5L18wYIFKCoqAofDgZGRESOHXC7H 77//jtzcXJiYmGDv3r3YtWsXDA0NkZWVhSVLllQ7kvClFBUVYfbs2Xj58iVMTU1x4sQJHDly 5KO/NzExEQsXLmTmU1VVFZYvX46nT5/C1NQUp06dwoEDB96aKwKBAMuXL8eLFy+qXZpcoVDg +PHjmDhxIpKSkmBubg4+n49ly5bhzp071frOpKQk7NixA3w+/4vak8/n4+jRo+Dz+Sr6EIuq ksFSgzx69IgmTZpEPB6PiIiePn1Kw4YNY/79LiorK+n7778nPT09OnnyJPN6QUEBtW3bli5c uEBERGfOnKFffvmFZDIZERFdunSJRo4cSVKp9LPl3Lt3L82dO5cUCgUREZ04cYJ+/vln5rvf RUJCAvn6+pKrqyvl5OQwr//5558UGBhIxcXFb33mzz//pJYtW9LDhw8/S76srCwaPXo0paam EhFRYWEhff3115SQkPDez8jlclqzZg3p6urSvHnziIgoKSmJvv32W8rLyyMioszMTPr2228p OzubsrKyaNSoUZSZmUlERDk5OTR8+HBKS0v7ZDkTExNp3LhxlJ+fT0REycnJNHjwYOZ570Is FtO8efNIV1eXtm7dSkREjx8/pvHjx1N5eTkREcXExFD//v2ptLRU5bOPHz+mVq1aqYyTjyGX y2nOnDl06tQp5rW5c+fSkSNHPvi5Bw8ekLu7O/Xq1YsEAgHJ5XJatmwZ8z0vXrygkJAQKigo IIlEQj/99BMzVhUKBU2ePJkOHz78yXIqFAqaP38+HT16lHntt99+o/3793/wc5cvXyZzc3Ma OnQoSSQSUigUtGrVKuZ7EhMTKTg4WGXMKvu7Y8eOtHr16g+O+zc5fvw4zZ07l+RyORERnT59 msaNG/fB7ygsLKSuXbuSkZERPXnyROVvZWVl9PXXX5OpqSkzT44ePUoLFixQmZ+zZ8/+LDlP nz5Ns2bNYj5z/vx5Gj169AfXi7S0NGrXrh01aNCAkpOT32qvsLAwMjc3p7i4OJW/yWQymj59 OvXv359KSko+WcbU1FQaPXo00zeZmZk0fPhwZk6+C6FQSJMnTyYtLS36888/mdd37NhBvXr1 opcvX6r8xpcvX9KYMWOooKCAeWa/fv0oOzv7k+V89uwZjRgxgsrKypjvHDZsGBUVFX1wns+Y MYO0tLTo2LFjzOt79uyhbt26UXx8PEkkknd+9uTJkxQUFPTWWPkQQqGQfvzxR7py5QoznyZM mPDRteLw4cNkZmZGY8aMeauN27dvT7m5uczrIpGIpk6dSteuXSMiIqlUSlOnTqVLly59spwV FRU0adIkZqwLhUIaOXIk3b59+4OfO3HiBFlYWNDw4cOZeVFRUUFDhgyh7t27M2vnm6SkpFC7 du1o06ZNzOc+hYcPH9KECROooqKCiIieP39OAwYMeO9zlL9lwoQJxOVyVdYxJcuXL6cuXbpQ dnY2VVVV0ahRo+ju3bvMeBk/fjxdv369XnSXmzdv0tixY6mqqorZa0aOHMn8/ndRVFRE3bt3 J0NDQ3r06BHT3j169KD09HQiIvrrr79owoQJJBKJVPak5cuXk46ODi1atKjaMsfHx1P79u3p zJkzKmtjZmYmZWVlVes79+/fT19//TUJBIIvas+0tDTq3bs3vXr1ilWM3wObglXDNGrUCD// /DMTrlbmdL/P66JQKLB37148efIETk5OKmHo7OxsVFVVoWHDhgCAVq1aoWXLlkyaSElJCTgc TrVufVbevK38bHFxMeM5ehclJSVYtWoVdHR0YG5uruLhzM3NhZ2d3VspDa9evcLKlSsxevRo BAYGfpZ85ubmmDNnDhwdHZmIgVgs/mCKzOXLl3H27Fk4OTkxF2vZ2dlh4cKFTPSlvLwcIpEI XC4XZmZmmD17NhwcHBiPRWVl5WddZGdvb4+ZM2cyl6FVVFRALpd/8DtOnTqFq1evwtHRkenb Ro0aYdasWTA2NmbkVCgUKt9TXFyMJUuWoF27dujRo8cny8jhcDBq1ChGRolEguLi4g/KmJaW huXLl0NTUxOmpqbQ0tICh8PBxIkToa2tjczMTNy8eRNBQUEwNjYGl8vFhAkTmGeIRCJUVFR8 dnrg8OHDmciOTCZDcXEx3Nzc3vv+Fy9eYO3atbC2toaRkRHjAf2///s/aGtrIysrCzdv3kSL Fi1U0veEQiFWrFgBKysr/O9///usG97btm2Ltm3bMu1XUlKiMpfeFYpfv349ysvL4ezsrCKH WCzGhg0bkJGRAQsLC2YOtWvXDmFhYSrzUy6Xf9ZcDw4ORqtWrT55vaioqMDq1atRWVkJd3d3 lTQogUCAtWvXQigUwsnJ6a0UqePHj+PWrVvYvn37Z3nsbWxsMGvWLCbtpKKiAgKB4L39oVwv Hzx4ABsbG2adFYlEiI2NRVpaGr777ju0bNkS8+bNg5WVFRwcHPDrr78y40p57upz+tzNzQ3z 589n+q6srAwSieSDch44cAC3b99WkVMikSA6OhpZWVkYPnw4AgICMH/+fJVL9BISErB+/XqM HDkSzZs3/2QZNTU18cMPPzBrnVAoREVFxQdTWx4+fIhdu3bBysoK7u7uTJTjzz//xO7du+Hj 44OdO3eif//+aNy4MTQ1NfH9998z+5RIJEJpaelntaWuri5+/PFH5juqqqpQVVX1QTmfPn2K 33//HZaWlmjUqBE4HA4UCgUOHjyIkydPolWrVtiyZQuGDRvG7BnKcbtkyRK4urpixIgRnzV/ PDw8MGvWLJV0XSJ677qpHJsxMTFwcXF5K0J96dIlHDp0CGvXroWDgwOkUilmzZrF7D8CgeCj /VWbNGnSBHPmzGHSlpRnM973e5VrV2lpKZycnJi5YWVlBSsrK0ydOhX29vZITk7Gd999pxLl uHDhAi5evKiyV1eHhw8fonHjxujWrZvKGGzQoAGAv1MSlWnBDRs2xODBg2FpaYmKigps27YN NjY2ePnyJRo3bozBgwejoKAAe/fuRWZmJnbv3o0xY8aAx+Ph8OHDSE9PR/fu3dGuXTtoamri 7t27ePz4MQQCAVxcXDBw4ECVvisqKkJ+fj4yMzMhkUigq6sLR0dH7Nq1C3K5HPn5+QgPD0dw cDDu3LmDCxcuwN7eHkOGDGHmcG5uLk6dOoXExES0a9cOhYWFCA0Nhbe3N06ePAk/Pz80btwY Z86cAZ/Px5AhQyCVSnH9+nVcunQJXl5eGDx4MExNTVFaWoq9e/fC0tIScXFx8Pf3R//+/aGt rY2ysjKcOnUKL168QNu2bdG8eXMcP34cPXr0gKenJ0QiEbZu3YomTZqgc+fObAqWumJqagoH BwdwOBykpaVh8eLFCAgIeG9KgjKd5n//+x/09PRU8qYLCgogk8mYzd7KyorZqGJiYrB161Z0 6tTpsxZ/Jba2tswgv3//Pg4ePIiwsLB3LjYSiQQbNmyAXC5H9+7d4e7urpJb+fLlS7i4uKgo mwKBACtWrICXlxeGDBny2UaSvr4+nJycoKGhAR6Ph+XLl6so7G8SHx+P9evXo3///nBxcYGL iwuAv2/IdXZ2BpfLRXFxMZYvX45GjRrBysoKurq6cHFxAZfLRUlJCZYsWQIHB4fPWhANDQ3R sGFDcLlcFBQUYN68efDw8HivEvbo0SPs3LkTI0aMYELzAGBiYgJHR0dwOBxkZ2djxYoVCAoK YhQXuVyO7du3QyQS4YcffviskDWHw4GzszMMDAygUCiwe/duvHz58r25qJWVlVi5ciW8vLwQ GhoKQ0NDaGpqgsPhwNDQEDKZDGvXrsWpU6cwfPhw6OrqQkNDA05OTtDX14dCocCuXbuQnp6O oKCgz5bT0NAQCoUC+/btQ3R09HuN15KSEixfvhwhISEIDg6Gvb09o2Arv2PDhg04cuQIhg8f rhL+/uuvv3D//n38/PPPn33mx9rampk7T58+xc6dO9G5c+d3zh2lkhQXF4chQ4aoGCBEhJMn T+LZs2cYO3YsHBwcGFlsbGyYZ9y9exf79+9HSEjIZxnHr68Xz58/x/bt29G5c+d3rhfK1BDl eTB9fX1mjiv7My0tDQMHDoSrqytjKCsV5i1btmDs2LHw9/f/7Hnu4uICDoeDoqIiLFmyBM7O zu9N14yMjMSff/6J8ePHo2HDhozBq1AoMG7cOFy9ehV79uxBdnY2Ll26BAAwMjJCgwYNwOVy UVhYiGXLlsHHx+ezUhiNjY3h5OTEKAUrVqxAs2bN3nsm7c6dOzh69CjGjRsHJycnRk65XI4x Y8bg6tWr2L9/PwoLC3H+/HmVdXP16tVwc3PDN99881nrpqamJpycnKCnpwe5XI4dO3YgPz8f LVu2fOf7c3JysHTpUnTr1g2Ojo6wsLBgXt++fTt69uyJgQMHIi8vDzNnzkRubi40NDTg6uoK XV1dSKVSbN68GUVFRZ91tk9LSwvOzs7Q1taGWCzGsmXLIBKJ3nvOJT8/H0uWLEHnzp3RsGFD Zs1MTEzE9u3bMWzYMPTr1w8vXrzAL7/8wqQwERGOHDmCpKQkzJgx45PTAt+1l2dmZmLFihVo 1arVe88OXbt2DSdOnMDw4cPfcibm5uZi3bp16NevH9q2bcu0g6urK3R0dCCRSLBp0yYIhUL4 +PjUi+5ibm7OKO5paWlYu3YtWrVq9c52U6biPX/+HEOHDoWLiwuzdnE4HHTu3BlBQUEwMDCA k5MTevTowYzl2NhYbNy4EQMHDoSLi8tnnx96nbKyMvj6+r5zTVPKOG/ePJiZmSE9PR2rVq1C VVUViouLsXHjRhw7dgzm5uY4dOgQnj17Bh0dHcjlcjg7O6Nhw4YoLS3Fjz/+iNu3b8PR0RE7 duxAREQEs4fs2rWLcWa+uTaXlZXh1atXmDNnDsaOHYslS5agqKgIBw4cwKVLl2BsbAwjIyOc PHkSc+bMgbGxMbO2VFZWoqCgAL/88gsyMjJga2uLDRs2YM6cOSgoKIBYLMbx48dRWFgI4O/U 6Fu3bgEAduzYgSVLlsDOzg6JiYlYv349JBIJMjMzsXDhQly4cAFmZmbYu3cv4uPjIZVKsWzZ Mly5cgWOjo54/Pgx8vPz8fjxYxw/fhzA3+f+9u/f/1nOJTYFqx4pKCigoUOHUr9+/aiwsPCd 74mLi6NOnTrRiRMn6MqVKxQQEKCSunPw4EEKCgpiwv6vpy106dKFJk2aRHw+/4vkjImJoXbt 2tHcuXNVQqRvhiR79uxJaWlpNH78eJo6dSoTypZKpdS3b19asGCBSirNrl27KDQ09IMpU59C VVUVzZw5k8LCwig+Pv69YeBhw4bRqlWrKD4+nvz9/enp06cq7ykvL6eJEydSt27d3krvqKys pAkTJlCrVq0oJSWlWnKWl5fThAkTqFOnTkzo+U3S09Ope/futH37dnry5An5+fm91T7K3zJg wAAmrYuI6OrVq9SqVasvCs8rFAo6evQoubm5qaSEvI5UKqVly5ZR//79KSsri0aOHEnLly9/ 63tKS0tpy5YttGTJEpV0F4VCQUeOHKFmzZqppMd8LqdOnSI3Nzc6ePDge1MdZs+eTaNGjaK8 vDzq16/fWyllCoWCysrKaMeOHfTbb78x6S4vXryg1q1b0+7duz8rJeNd6XcdO3ak6dOnvzdc f+PGDQoPD6dHjx7RunXrqE+fPiQUComI6O7du9SxY0e6desWHThwgAYOHPjW98TExFDz5s3p p59+eu/8/BjJyckUHh5OU6ZMocrKyvemt3Ts2JFiY2Np4cKFNHjwYCal4eLFi9SlSxeKjo6m xYsX05AhQ0gsFhMREZ/PpzFjxtDo0aO/KGWhoqKCxowZQ23atHnv/ElISKCvvvqKjh07RpGR kRQeHv7eVMclS5bQxIkTVV7j8Xg0fvx46tat23uf8TGKiopo+PDhNGDAACal601evXpF3bp1 o4MHD9Ldu3epU6dO7033WrVqlUrq07Zt2yg0NJQSExO/aJ7v37+fmjVrRufOnXvne/h8Po0d O5Z+/PFHysrKolatWjHz9fDhw/Tdd98xacPKVKGLFy+qpNBs27aNGjVqRBEREdWSUyqV0qZN m8jf358iIyPf+R6BQEATJkygSZMmUU5ODoWEhDBr17Zt22jixInMuCsuLqauXbvSnTt3mJSp 4ODgz0oDfV/65NChQ2nQoEHv7fOEhATq1q0bnTp1ii5dukQtW7Zk1m9leuq7UmqV6YubNm2i wMBARvb6JCcnh77++muVlMN3pWuFh4fTw4cPaePGjdSrVy8mdWvv3r1M+plCoaAFCxYwY0up F61bt45iY2PJ39+foqOjqy3rxo0bad26de/8G4/Ho3bt2tH48eMpNjaWIiMjqV27dhQVFUVR UVHk4+ND9+/fJyKiGTNm0MWLF0mhUND48eNp165dzNrn7OxMx48fp7i4OFq6dClNmjSJRCIR ffPNN/Tzzz+/V7ajR4/SgAEDqLCwkEpKSojH41FBQQEFBwczacwCgYA6d+5Mo0aNopiYGLpz 5w6FhYXRgwcP6ODBg/T9998za+2WLVvI3Nycnj17RgUFBdSmTRuKj48nqVRKQ4cOpXnz5lFZ WRkFBwfT1KlTKTY2liIiIqhLly6UlJRE169fp8aNG9OLFy9IKpXS6NGj6fbt25ScnExdu3Zl dJ+qqioSCoV09OhRat++PSUlJVHv3r1pyZIlTNoxm4KlxlRUVGDhwoWorKzEpk2bGO/X6xQX F+O3335DXFwczp49i7y8PGRkZCAyMpKpilRQUABHR0cVD4TSG2VnZ4cFCxZ8diWX10lOTsbk yZPh5+eHn3766a1qF0SEO3fuYN68eTAwMMCiRYtw8+ZNWFlZISkpiQnNVVZWqljGsbGx2LFj B6ZPnw5PT89qyyeVSrFlyxbcunUL69atg5eX11vvqaqqwsqVK/Hnn3+iqqoKd+/eRWZmJi5d ugRfX19oaWlBKBRi0aJFiImJwbZt2xgvjzK6s2nTJjx58gSbNm367KpNylSH1atXIyEhAZs3 b2Y8pW+OieXLl+Phw4cwMTHB+fPnkZ2djatXr8Ld3R0aGhqoqKjAokWLUFZWhk2bNjHe69zc XKxcuRK9e/dGu3btqt2eN2/exMqVKzF58mT079//nd76c+fOYeXKlfD29sbcuXNx69YtFBQU 4JtvvoFEIkFJSQlatGgBMzMzNGnSBL///jskEgkTelYe/p48eTL69OlTLTnv3LmDZcuWYcKE CcxceNNbv3//fmzcuBEtWrTAzz//jNu3b0NbWxudOnVivEeBgYEwNTWFr68vIiMjIZFIIJFI sHbtWvj7+2PQoEHVSl9UpkfOnDkTbm5umDt37jsPFyYmJjKe4+3bt+P58+fg8Xh4+vQpHB0d MX36dGRlZWHPnj2IiYlBWVkZrl+/zqTXZWRkYM6cOWjWrBlmz579SdVo3iQ3NxczZ85EgwYN MH/+/Hd6M2NiYvDbb79BLpdj/fr1ePz4MSQSCeLi4qCpqYlZs2aBx+Nhw4YNePz4MWQyGZ4/ f46WLVvi6NGjSEpKwh9//FHtA5ZisRjr169HXFzce+dPcXExfvnlFzx+/BhWVlbIzs5mqoT9 73//Q15eHmxsbJgobFVVlUoURSgUYtWqVUhKSsKmTZve+YxPWddnz56NvLw8bNu27Z1RmtLS UsyaNQsPHjyAubk58vLy8OLFC5w5cwZjxoxBfn6+ipwCgYD5nufPn2Pfvn2YOnXqJ1Woex8X LlzAhg0bMH36dHTv3v2d6+ru3btx7NgxtGnTBr/88guSk5Nx5coVhIeHQyQSwcXFhYlycblc aGlpMdWflFXStm/fjl9//bVaKRlEhOPHj2Pv3r1MWumbyGQy7N27F4cOHUJwcDB+/vlnJCUl 4cqVK+jatSskEgmaNGnCjDtNTU0YGxvD0NAQfD4fy5cvR+vWrdG3b99qtyWPx8Nvv/0GPp+P zZs3v7PPCwsLMWfOHDx48ACWlpbIyclBWloarl+/jiFDhjDVzTZs2PBWtFWhUGD//v3Yvn07 li5d+slVDWuLkpISzJgxAwqFAkuWLHlnhO/Vq1f45ZdfkJ2djR07diA6OhplZWV4/PgxQkND mSpxymiIQCBAXFwcunTpguXLl+Ps2bOQSCSIjIxk9mpvb+9qpZ45OTnh999/V0lbel03qKys xJMnTzBp0iRm7yAi5ObmwtbWFm5ubhAKhSgpKYGhoSHEYjEEAgETvVKm3W3atAkcDgcymQyh oaEQi8UQCoXvzchQpnR7e3ur6H8lJSUwNTVFo0aNmHWJz+cjOjoaP/zwA6OTKN9rZ2fHZDtw uVxYW1vDysoKFRUVTJRcmQbZpEkT8Pl85Ofn4969e4iKimIKhSgrAZqZmcHe3h4CgQAKhQJm ZmYQCASQy+XM2FRGvtu2bYs//vgDP//8M3g8Hr799tvPisB/UtSWNRdqFj6fj4ULF+L8+fOY N28eioqKoKGhAXt7e2RkZOD+/fvo378/RCIRunfvjk6dOkEul+Po0aPw8/NjFGAiQlxcHFxc XJiJWVBQgClTpiAuLg6LFy9GWloaiKhaYbHs7GxMmTIFeXl5mDZtGl69egU3NzcYGRnh5s2b 0NLSQuvWraGhoYGZM2eCiMDj8XD//n0EBwczaWGVlZUQiUTMRCwrK8OKFSsQEhLyWecU3pX2 tWXLFqxevRqTJk0Ch8NBeno6nJycUFlZiTNnzqB79+4gIjRt2hRr166FXC7Hw4cP0bBhQzRt 2hRcLhcikQgbNmzAzp07MXv2bAiFQuTk5MDBwQESiQTbt2/Hpk2b8MMPP4DL5SIrK0vFQPkY IpEI69atw+7du/Hzzz9DIBAgIyMDTk5OKCoqwqVLl9C/f3+IxWK0adMGzZs3h0wmw8WLF9Go USN4e3uDy+WCz+dj/vz5+PPPPzFv3jyUlJRAW1sbFhYWWL16NUxNTTF27NhqLwD379/H5MmT 0bhxYwQEBODly5do1KgRtLS0cPbsWbi4uMDLywsmJiZYvnw55HI5cnNzUVlZicDAQBgYGCAl JQXz5s3DpEmTYG9vj71798LNzQ06OjogIly/fh2TJk1CUFAQPDw88OLFC3h4eHzWOZDHjx9j 0qRJcHV1RVBQEBISEuDu7g5tbW2cP38ejo6O8PLygqOjI1avXg25XI60tDRwuVwEBQVBT08P SUlJmDlzJr7//ns0aNAAu3fvhouLC3R0dLB79268evUKu3btqnaJxpycHHz//fdIS0vDiBEj 8OrVK7i6usLU1BQxMTHIzs5Gt27dIJVKMXr0aCgUCojFYsTFxSEwMBC2traQSCQYM2YMZDIZ JBIJYmNj4ebmxqQj5OTk4Mcff0R2djbGjh2LtLQ0FaXwU8jLy8MPP/zAVNhKSUmBs7MzzM3N cffuXYjFYnTo0AEKhQI//PADFAoFqqqqcOvWLbRv3x6mpqYoLy/HxIkToVAoIBQK8fz5czRv 3hzW1tZ49uwZ9uzZgylTpjDnB6pjfGzatAnbt2/HtGnToFAokJ2dDUdHR+Tm5uLevXvo1asX xGIx+vbti+7du0Mmk+H06dOws7NDkyZNUFJSglmzZsHHxwcdOnRASkoK7t+/z1TyEgqFWL58 OXbt2oVffvkFAoGAecanIhAIsGzZMpw8eRKLFi1CaWkp9PX1YWNjg/z8fNy+fZuRs2fPnggP D4dMJsO5c+dgY2MDPz8/lJeXY86cOfDw8ECnTp2QkZGBW7du4bfffgOPx8OyZcsQHByMnj17 VjebAZcvX8YPP/yAsLAwuLq6Ij4+Hh4eHpDL5Th+/Dg6deoEExMTODk5YeXKlZDL5YiNjYWJ iQlT5jkwMBARERE4ffo07O3tcfnyZUgkEvj7+4OIcPXqVcyYMQNt27aFh4cHEhMT4ebm9skK pEKhwJkzZzB79mz06tULVlZWePnyJTw9PSGXy3Hs2DGEhYXBwsICjo6OjJzx8fEwNDRE69at oaWlhcDAQOzYsQPOzs4wMTHB5cuX4eTkBHd3d/zxxx8oKSnBsmXLqmW4Kw3OX3/9FWfPnmWq WmlpacHW1hbZ2dm4e/cu+vXrx+zlXbp0Yfrcx8cHHh4eSElJwYYNGzBixIi3Ul6VDp+ZM2cy 7aBcS6qTVv2lKCu9Xbt2DStWrEBeXh60tLRgaWmJzMxMPH36FD179oREIsGoUaOgUCggkUgQ Hx+PFi1awM7ODhwOB05OTjh06BBMTExQVlaG58+fY/bs2RCLxQgICICXlxdTbt3Z2Rn+/v7V 3tdCQ0Nx4sQJTJ06FcOGDYOVlRXKy8tRXl6O8PBwtGrVCnZ2dmjdujWSk5Ph4eEBPz8/XL9+ Hdra2jAwMACfz8erV69gbGyMyspKpKWlMYaXq6srWrRogaFDh0JHRwc5OTno1q0b5HI55HI5 k+r9LoqKit5K88zPz4dQKGS+39DQEK1atYKpqSlCQ0ORkpICV1dXBAQEMGcHL1++DCLC77// DgcHB5iamqKkpIRxuCodbp6enjA3N0f79u3h5eUFf39/ZGRkwNvbGy4uLjhx4gSTip2fnw8e jwd9fX2YmJjAyMgIv//+O9q1awepVIpWrVrB1tYWoaGhWLp0KbZs2fJZetGnojF//vz5rNlQ Y+lsuHTpEo4dOwYdHR28ePECERERsLa2RpMmTVBYWIioqCgEBATA3Nwc/v7+CAgIQIsWLZCR kYHAwEDGayyXy3Hr1i34+PigefPmkEqlOHHiBK5cuQJdXV08efIEERERaNy48QcnwfuU5iNH juDevXvQ09PDw4cPcfv2bTRr1gy2trbMwSpvb280aNAAzZs3ZxaO1NRUjBo1ijkYrPxNffv2 ZQ53lZWVYdSoUZ+dW/86UVFR2L59OzQ1NZGZmYmIiAiIxWKEhISgqqoKERER8PPzg5WVFXx9 fdG8eXO0aNGCseRHjhwJDQ0NPHjwAPv27YOuri7S0tIQEREBAwMDNG/eHE+fPsWOHTugoaGB 9PR0REREQFdXFy1atPgsb/3u3buhra2N5ORkREREQEdHB4GBgSgvL8f9+/fRrFkzmJubq8hZ XFwMZ2dnfPfddwD+Pgt05MgR6OnpIT4+HpcuXYKlpSU8PT2RnZ2Nb775ptq5ssXFxdi8eTNy cnIgEolw48YNJCcnIzQ0FHp6erh58yYMDAyYszPK/m7YsCFSUlIwffp02NrawsbGBtra2jh2 7BguXrwIX19fjBkzBiYmJigoKMCmTZtQXFyMqqoqXL9+HfHx8ejQocMnK/qlpaXYvHkzc2jv xo0bSExMRGhoKPT19XH79m3o6OjA3d0djRo1YtrS1tYWxcXFmDZtGkxMTGBtbQ09PT0cP34c 58+fh7e3N8aNGwdjY2Okpqaic+fOn9XHbxrGR48eRWRkJHR1dfHo0SNcvXoVvr6+aNCgAZKS kvDq1Su0aNECNjY2TFsGBAQgJSUFffr0QcuWLWFhYYFmzZohICAAgYGByM7ORqdOndCxY0eI xWIcOnQIt27dgpaWFh4+fIi7d+8y8/NT5Tx+/DiuXbvGrBdXrlyBl5cXnJ2d8eLFC5SVlaFJ kyawtbVl5PT19UVMTAxGjBgBPz8/lb81bdoUKSkpGDhwIJo2bYrMzEzY29tjwIAB1VaYlGei NDU1kZqaqjI/i4qK8PDhQ5X1Utnn5eXl8Pb2xsCBA6Gnpwd7e3s8fPgQ+/fvR3Z2NsaMGYN2 7dqBy+Xi7t272LNnD3R0dJg5qq2t/cljQKFQ4ObNmzhy5AgMDAyQmJjIrOs+Pj4oKSnB/fv3 0bx587fk5PP5aNSoEYYMGcIcQn38+DH279+P9PR0jBw5Eh07dkRlZSV4PB5GjBhR7TzrvLw8 bNy4EeXl5eDz+bh+/ToSExPRoUMHaGho4MaNG3Bzc4O1tTU8PT0ZGXV0dCAQCDB16lTo6ekx Z4eOHz+OY8eOwdHREVOmTIGdnR1ycnKwceNGlJWVoaKiAteuXUNeXh7atm37yefSUlNTsX79 esbzfPXqVeTm5qJjx44gIkRGRsLZ2Rk2NjYqcurr64PH42HatGnQ19eHnZ0dDAwMcODAAVy4 cIGZ50ZGRkhKSkLfvn3h6+tbrbZUKBS4cuUKjh07Bj09Pbx48YK536hJkyYoKCjAvXv3EBQU BAsLCzRt2pSRs6CgAAEBAejRowfy8vKgra2N4cOHv2UIpaenY+vWrRAKheDxeLh69SqKiooQ Ghparbu9vgS5XI7Lly/jzz//hJGREeLi4hAREQFnZ2c0atQIeXl5ePbsGQICAmBnZ8esCS1a tEBKSgp69eqFVq1aAQDc3d1RXFyMnTt3Ijk5GcOHD0enTp1gYGCgsgdKJBJYWVlhxIgR1TZA dHV1ERwcDD6fj2PHjuGvv/5CZmYmPDw80KxZMzRo0ADXrl3DyZMnIZPJ0LZtW9jZ2SE6Ohq6 urro0qULysrK8OLFC/To0QNyuRyPHj1C7969YWpqCmtraxARDh8+jNu3b8PZ2RktW7aEVCrF s2fP0Llz53dmuCgzDho3bqwSzUxOTkZmZiZ69eoFXV1d5txWZGQkjh8/DrFYjNDQUNjb28PR 0RG6urrYtGkTEhMToampCUNDQwwYMABmZmbQ0tLC1q1bkZqaigkTJqBNmzbMudYzZ87gr7/+ gkKhQLt27WBlZYWbN2/C0dERoaGhKCgowPPnz9GtWzdYWFigYcOGOHfuHM6dOwcHBwc0a9YM RIQbN25AQ0NDpThBTcKh/8pVnXWEUCh8q86/cqAREeRy+Ts9RcrKTK8v4iKRiLnET3nnxvu+ +3MNJaFQqFKXm8PhMIeJla+/uSgoPbk6OjrM3+RyOcRiMXR1dZnXPlT163MUPYlEAg6Hw9Qh 19LSYhZxZRWbN58jkUhARMz7xGIxpFKpyvdoa2tDW1v7nc9Q/u1zPLhvfr+Ojg7TZ+/rb+Xd GUo5RSLRW/cSKL+nJjYXoVCoIqOGhgZ0dXXB4XAglUrB5XLfUiLlcjkkEolKfytllcvl0NfX Z9pfLpczd7Qon8HlcqGnp/fJY+FjcspkMuYirzc/J5VKoaOjo/IspZx6eno1Fjp+3zzU09Nj 5g4RvSUjEUEsFkNTU/O940FDQ4NZJz40P79ETuV68SE5RSIRtLW1P+tv1eVD8/ND80c5b1+f H8rx8/o68bFnfI7TRjn+Pmeev0tOZaRJU1Pzky61+1RkMhmzrrxrDr5vzZTJZJBKpcw8e3MN NjAwYF5X3p/0ejtoamq+Nfc+hFQqhVgsfus7lG3xuXKKxWLIZDKV9agm9qAPrckfW9uVaWsf kuV9bVmTY+JLf+/HdJcPrWvKanbv+z1v7tU1pXu9Of+V4+31/fT1ZysjOcpIvlKfeb3PlOux MoX1XbrQu9rzzXZ53xhWjoV37flVVVXgcrlYsmQJ0tPTsWfPHuaZ72tj5dx9/fuUc05bW5vZ 21+XQyKRQCqVMvtlbGwsRo0ahfnz56Nbt261MuZYA4SFhYWFhYWFhYVFDSEi/Pjjj9DX18fi xYtr/XlisRg//vgjqqqqsHXr1lozitkzICwsLCwsLCwsLCxqiEwmg42NTZ2VaE5NTQWPx8OU KVNqNSLHRkBYWFhYWFhYWFhY1JT3pUrXlsEjl8trLD2ONUDUCKFQiOjoaEil0g++z9PT870X ctUF6enpyMrK+uj7PDw8VG7yrUskEgmeP3/O5D6/D319ffj7+9fbLbPZ2dlIS0v76PtcXV2Z m3Hrg5ycHKSmpn7wPbq6uvD39/+sHPqaXhyjo6NRVVX1wffp6OigadOm9SZnQUEBkpKSPvq+ Bg0afNFlXF+CQqFATEwM+Hz+B9+npaUFf3//WjmI+KlyxsbGoqKi4oPvs7Ozq3ZFrpqgtLQU L168+Oj7bG1tmVKc9UFcXBzKyso++B4ulwt/f/8vKvX+JfB4PMTGxuJjKoqlpeU7S7TXFQkJ CSgqKvqwosXhwNfXl6ke+W9ALpcjOjoaAoHgg+/T1tZG06ZNa12ZZfkHwl4ZWPckJyeTg4MD 6ejoMP9pa2ur/FtHR+eti9Xqmrlz574l07vk3LdvX71emuTm5vaWjG/K2bx5cyovL683OVet WvVJbblx48Z67fONGzd+VE5PT8/3XshVF5SXl1OzZs0+2pZubm6Um5tbb3Lu27fvk/p87ty5 9SZjVVUVhYaGflROR0dHSk5Orjc5RSIRtW/f/qPzfPLkyfU6f86fP0+6urof7fNx48bVm4xy uZx69er10bY0MzOjJ0+e1Juct27dIiMjo4/KOXTo0Hrt82+//faj88fQ0JBu3rz5r9JjKioq qEWLFh8d6y4uLpSVlVXre8L7LlmtScrKyupVj/i3wUZA6gGBQIA7d+4wF85kZmZi+vTpGD16 NMLDw5n3NW/evF694QkJCXj16hXz799//x1nz57FuHHjVKoiNG3atFZqRH8KIpEId+7cgVAo ZLzOyjKNq1atYu5NMDIyQkhISJ2XN1SSnJyMly9fMv8uKirCjz/+iJ49e2LgwIHM6z4+PtW6 DLGmSE1NVfHgHj16FOfOncOaNWuYcoP6+vpo06ZNvXm0pFIp7t69y3jtKyoq8OOPPyI4OBgj R45k3qenp8eUJqwPsrKy8Pz5c+bfFy5cwLZt29CzZ0+MGTOGeb1Ro0Zo3LhxvXkx7927h/Ly cua1y5cvY9euXVi5ciVzv4+2tjbatGnzzosM6yoCcv/+fZSWlgL4+5DkTz/9BGdnZ0ydOpV5 n7Ozc7VLr9ZU1OvRo0fMv+/cuYO1a9diyZIlKpeyNmzYEP7+/vXldMSjR49QWFjIRBTnzZuH uLg4LF26FN7e3gD+rkAXHBz8zsvo6oKSkhI8ePCAqQb37NkzzJ8/H4GBgZgzZw5TvcfOzq7a ZbVrgqdPnyI3N5f5d0xMDBYsWIBZs2Yxd39wOBy0bt0aFhYW/xo9RiaT4e7du0xUks/nY9q0 aQgMDFRZ33R1ddGmTZtai56KRCLMnz8fnTp1QqdOnQD8nWWSmJiIwsJCmJqawtvbWyWSl5aW BoFAAB8fH3A4HCgUCsTHx8PY2PiDlwvu378flZWVGD9+PKvIshGQfwcJCQlkaGhIu3btUms5 p06dSgBo27ZtaitjZmYmWVpakru7O5WVlamtnLm5uWRtbU1LlixR6z5fvHgxWVtb12sk4VO8 Us7OzjRjxgy1bstt27YRAJo6dapay7lz504yMjKihIQEtZVRLBZT06ZNafjw4WrdlidPniRd Xd16jSR8DIVCQe3btycul0v37t1TWzmvXLlCAKhnz55q3eeRkZGko6NDly9f/k/pMTwej9zc 3Op8fbt+/ToNGjSI8vPziYgoKiqKvvvuO+rduzd17dqVevbsSYMGDaLz58+TVColIqLZs2fT yJEjSaFQMHtIx44daffu3R981oULF2jcuHEkEolYxbUGYKtgqYknQemNVGeUnih1llPZlkT0 Vk1zdZTz9bse1LnP1b0tiUjt21I5b/4pcrJ9/t9qS3Vf25WyEVGN3PNR23Kq+37+b5iTMpkM Z86cQZcuXWBjY4OcnBzMnTsXoaGh+O6772BhYQE+n4+TJ08iMjKSieLyeDx4eXkxY6iiogL5 +fkfvejVw8MDBQUFKC0thZ2dHau8fiGsAcLCwsLCwsLCwvKPIjc3FwUFBWjfvj2Av28fd3Bw wA8//MCkCJuZmWH06NEQCAQwMDCAUChEfn4+9PT0cObMGQB/p2SJRCJYW1tDIBDg7t27zEXQ HA4HDRs2hI+PD0xNTWFsbIyKigrWAGENEBYWFhYWFhYWlv8ayvOK9vb2AP4+TxsYGMgYH/T/ bnCn/3frORGhqqoKubm5KC8vR2JiIoC/K65pamrC0tISJSUlOHjwIMrKyhAVFQUul4vt27fD x8eHuan+YxVMWVgDhIWFhYWFhYWF5V9IYWEhvL29mVLrcrlcpdT+/fv3sWTJEkilUmhqamL1 6tXQ1taGg4MD1q5dyxgujx49wsaNG2FkZAQzMzPs2bMHd+7cwbhx4zBx4kSEh4eDw+FALpdD IpHUWzGbfxtctglYWFhYWFhYWFj+SYhEIpXKYo6Ojnj27BkToXB1dcW0adPQvHlz5Ofnw9jY GDweDyYmJjAyMgKHwwGHw0FhYSGMjIyYSl0ZGRlYuHAhOnbsiBEjRoDL/VtVLi0tRXl5eb1V hmMNEBYWFhYWFhYWFpZ65vXD/h06dEBqaiq2bt2KoqIimJubw8rKCsnJyRg2bBjs7OyQl5cH LperUkY+MTERGhoa0NHRAY/Hw9y5c6GtrY1p06ZBQ0ODeUZiYiJsbW1hZmbGNnwNwKZgsbCw sLCwsLCw/KPQ09NDVlYW8+8GDRpg/vz52LBhA86ePQsigrGxMdq2bYvRo0eDw+EgKysLBgYG TNoWEYHP58PV1RUymQy7du3CmTNnYG9vj1GjRkFLSws///wz2rZti5s3b8LHx4f5LAtrgLCw sLCwsLCwsPyHsLOzw4ULFyASiZgLZ5s3b47NmzcjMTERQqEQDRs2hKOjI1Nyt1evXpDL5Spl nEeNGgU9PT1wOBx89dVXaN26NVNSWENDA56enkhNTUV6ejpGjx7NNjxrgLCwsLCwsLCwsPwX 8fLygpaWFvLz8+Hs7My8bmBggObNm7/XaHkdZZnd17/zTRQKBXbu3Ak/Pz+4u7uzDc8aICws LCwsLCwsLP9FrK2tMXjwYBgYGNTqcxQKBQICAuDm5sYcSGdhDRAWFhYWFhYWFpb/GNra2uje vXvtK8qamsxlhyw1B2vKsbCwsLCwsLCwsLCwBsh/CQ0Njb874x8S2vunyKlsV3Xm9YNwbJ9/ WT//U9qS7fP/Hurc5xoaGox8/4Q+V97dwPY5C8s/GzYFq5YgIshkMohEIohEIgiFQub/crkc 5eXlUCgUAIC0tDRIJBLExsbi6tWrICJmAdPX14e+vj40NTWZ0nEGBgbQ1dWFpqamyq2fXyIr n88Hl8uFgYEBs3CWlJQgNjYWDRs2hKurq0ot7MjISHh6ejIHuhQKBbKzsyGVStGgQYNaKVMn k8lQWVkJfX19lRJ6r169Ql5eHpo2bcq8r6qqCvfu3YOZmRmaNWvGXDAkFAqRnp4OMzMz2NjY 1MomUVVVBZlMBkNDQ2ZDF4vFeP78OTQ0NFTkLCwsRGRkJKytreHl5aXS9oWFhXB0dISRkVGN y6hQKMDn86GlpQV9fX3m9aKiIsTHx6Nhw4ZwcXGBQqGAVCpFQkICkpKS4OXlBVtbW+Y7MjMz IZfL4eTkVCNj8c35I5FIIBKJUFVVBYlEAoFAALlcjoqKCuayKR6PB4FAgNTU1Lfmj7a2NoyM jKChoQF9fX3o6uoy/9fS0oKmpmaNjIF39blQKERUVBQMDAzg6+vLzPf8/HxERkbC1tYWnp6e zPOLiopQUlKCBg0a1EpOMxGhoqIC2trazHwAgJycHCQlJaFRo0ZwdHSEQqGARCJBfHw88vPz 4efnx1z2JZfLkZmZCQ6HgwYNGtSKka/sZyMjI2ZMyeVyxMXFobKyEs2aNWPmD5/Px507d6Cv rw8/Pz/m/QKBABkZGbC2toalpWWtrPF8Ph8KhQLGxsZMH1ZUVCA6OhoWFhbw8vKCQqGATCZD VlYWKisr4erqyhyWJSIUFBSgvLwcTk5OKn1SU+ulVCqFWCyGQCBg/q9QKFBZWQmhUAgiglwu R1FRERQKBR4+fIiqqioQETgcDjQ1NWFsbAwNDQ3o6empzB9tbW1oaWnVyPwRi8UQCoUwNDRU 6fOYmBiIRCIEBAQw87qsrAw3b96EsbEx/Pz8mDFYUVGBnJwc2NjYwNzcvNb6nMPhqOyTPB4P 0dHRsLKyQuPGjUFEkEqlSE9Px7Vr1+Dh4YEGDRowfZ6bm4vKyko4OTkxlZvUHYlEgsrKShgZ GTG3gMvlcsTHx4PH46nMSYFAgHv37kFLSwtNmzZl3q/cey0tLWFpackaaCzgkHJWs1QLkUiE iooKFBcXo7CwEMnJycjNzUVJSQl4PB7y8vJQWFgIImIWew6HA6lUCgcHBxgaGjIbqZ6ensrl ODk5OaiqqoKmpiaIiJnIenp6aNCgAQwNDWFhYQFzc3M0atQITk5OsLS0hLm5OWO0vKmApKSk oKCgAP7+/jA0NAQApKen4/vvv4eLiwuWLVvGKD+XL1/GL7/8gjFjxmD8+PH4888/cfPmTUil UhQWFmLUqFHo2rUrs7jMnDkT0dHR2LhxI5o0acIo0tu2bYOFhQWGDx/ObLLKRfpdhopQKERc XBx0dXXh4+PDKHQnT57EmjVrMHnyZAwcOBAAIJVKsWjRIty8eRNr1qyBi4sLVq1aBYFAgLKy MmhpaWHevHnMBvDy5UuMHz8evr6+Kr/18ePHOH78OHr27InQ0FCVTfz1tn+dgoICJCYmwt3d Hfb29ozsP/30E9LS0rBu3TqmYkZWVhYmTJgAa2trrF69GgCwevVqaGhoID4+HoGBgZgyZQrz nP3792PdunWYMWMGBg8ezGwCBw4cQE5ODkaOHAkHBweVDUJDQ+MthVChUCAxMRHl5eVo2rQp 0/4JCQmYNGkSWrZsiV9//ZXZCP/66y8sXboUo0ePxujRoxEREYHr16/D2NgYT58+xejRo5k+ r6ysxNSpU5Gamoo//vgDLi4uAIDs7Gzs2LED7u7uGDJkCPOblMrY630ukUjA5/NRWlqKwsJC ZGRkIDU1FaWlpSgtLUVxcTFyc3MZ5V0mk4HD4UAikcDa2hrm5uZQKBRvKdbK221LS0uhra0N ImI8vVpaWnBwcICZmRnMzc1hbm7OGNlWVlawsLCAkZHRO8dmXl4ekpOT0bhxY1hZWTFKycyZ M5GTk4P169czFVWSk5MxYcIEeHl5YcmSJYiKisLx48cBALm5uejYsSNGjx7NzNNNmzZhz549 WLx4Mbp06cKsL7t370ZJSQnGjh0La2trlfnzLgVQLpcjISEBVVVV8Pf3Z37HkydP8NNPPyEs LAyzZs1innvo0CFs3LgR//d//4cRI0bg/v37OH78OHR0dJCamoqZM2cyRnNJSQmmTJmCyspK bN68mRn36enp2LlzJ3x9fdGvXz/mu9/V568rczExMbC2tkajRo2Y969fvx7Hjx9nbiJWjrUp U6YgNzcXa9euhZubG9asWQOFQoHU1FSYmppizpw5MDY2BgDcuXMHU6dORbdu3TB37lxmXly4 cAG3b9/GwIEDGaVJuY4oFe43ycjIQGZmJry9vRlDrKSkBN9//z1kMhk2b97M9MuTJ08wefJk tG/fHvPmzcOLFy9w4MABeHp64tKlS+jZsydGjBjB9NOyZctw8uRJrFq1Ch06dGCM2Z07d0Ii kWDkyJHMpWfv6nOlwldWVobCwkJkZmYiNTUVJSUlKC0tBY/HQ1ZWFoRCocr8kUql0NXVZcZq ZWUlY0Ar20AoFCI7O5vZf5TzR0NDA3Z2dirzx8HBAY0aNYK1tTUsLCxgbGz8TuW6vLwccXFx cHBwYNYLmUyGtWvX4vz581i+fDmCgoIYxX7SpEkQCATYuHEj+Hw+tmzZAgMDA2RnZ8PR0RGz Zs1i9rHLly9jzpw5GDp0KCZPngwulwsiwrlz53Dv3j189913KhWO3tfnRIS0tDTk5OTAz88P JiYmzJz9/vvvYWZmhtWrVzO3YT948ADTpk3DV199hVmzZjEX4RkZGSE6OhpDhw5l9iuZTIZF ixbh0qVLWLduHVq1asUYT9u2bYO+vj6GDx/OOJ2ICBKJBFpaWnUSnaqsrERcXBxMTEzQuHFj cDgcEBF27NiBP/74A7/99huz/gsEAkydOhUZGRlYv349nJycsGrVKlhYWCAuLg5cLhcLFixg 5szDhw8xadIkhIeHY968ecy+cOPGDURERKB///4ICAhQ6R8A79x7WVgD5D+HRCJBcXExsrKy EBMTg1evXjEKk0gkgo6ODszNzWFiYgITExNYW1vDzc0N5ubmMDIyYiIXenp64HK5MDQ0ZDZm 5UR/c4MWi8WQy+UQCASQSqWoqKhgPD2pqamoqKgAj8dDWVkZSkpKoKmpCRsbG7i4uMDBwQG+ vr7w9PSEra0ttLW1MWfOHKSlpWHNmjVwc3NjNoWbN2/C1tYWAQEBKhtQbm4ubGxsmEVeuTBU VFSoKGlEhKysLJSWlsLT05NRBMvLy7Fu3TpwOBxMmzaN+Z5Hjx5h27Zt8Pf3R0BAAJo2bcr8 LT4+HuPHj2cUJaVRlpSUhBcvXqB58+ZwcnJi5CktLYVAIICdnZ3KZlJRUQGFQgETExNmw1Z6 8/X09ODq6sos6k+ePMG2bdvQvXt39O3bl1EQtm3bhqdPn+Krr76Cl5cXYxAREbZv347du3dj 3rx56NatG7PBKI20kJAQZiNRKBTIy8uDrq4usyArXy8rK4Ourq6K17u0tBRpaWmMUamUZ9++ fYiKisLkyZOZ/issLMSyZcugo6ODDh06wM/PDzY2NswmPnnyZPB4PBXluLS0FDdv3oSTkxOa Nm2q4rUvLCyElZWVSmREKBSiqqoKxsbGzIZAREhNTQWfz4eXlxfTT/n5+Vi3bh0sLS3x/fff M4pIZGQk9uzZg9atW8PExASxsbHIyspCcnIyqqqqAACWlpYwMjKCqakpjIyM4OHhAVtbWxgb GzPzxcDAgInWKb/7XfOnqqqK8eZWVVVBLBaDz+eDz+ejsLAQSUlJ4PF4KC8vR3l5OQoKCqCp qQl9fX14enqiYcOG8Pb2hpeXF+zt7WFmZoatW7fi8OHDWLFiBWOoSiQS3Lp1CwDQunVrph/l cjlyc3NhYGCg4pFVKBQoLy9nPMlKlAqkm5sbo3RKJBL88ccfSEhIwPTp05n+S09Px4oVK2Bh YYGwsDD4+fkxBlFRURHGjx8PPT09rFmzhnk9Ly8P9+/fh6urK/z9/Zk5UVlZiZKSEtjY2KjI IxQKIRQKYWJiwijwCoUCKSkpEIlE8PT0ZOb/68bX2LFjmdcvXryIo0ePok2bNvD19UWzZs2Y v928eRO//PILhg4diokTJzLz6tmzZ8jMzETr1q2ZaBsRobCwEAqFAtbW1iqGdnl5ObhcLoyM jJjfVFVVhcTERJiamsLZ2Zl5/dq1azh69Ci++eYbtGvXjvmd69atQ3Z2Nr766iv4+PjA1dWV 6cOlS5fixo0bWLRoEVq3bs18JjIyEjo6OggJCWHGvlQqRW5uLkxMTBgFVbku8Hg8lTGrnCtZ WVlo1KgR836RSITff/8daWlpmDFjBhNlfvXqFVatWgVXV1d4eHggLi4OmZmZSElJQVlZGRQK BczMzGBkZAQzMzMYGhrCzc0N9vb2MDExgZGRERPB0NDQgLa2NmOwKdvn9Tkkk8mYNVQoFDIR FD6fj5KSEiQkJDBzh8/no7i4GGKxGDo6OmjUqBEaNGgANzc3+Pv7o2HDhrCwsMD169cxb948 TJgwAcOHDweHw4FCocCjR49QUFCA4OBgZrwSEfLz88HhcGBtba2igJeXl0NDQ0MlOiwQCJCY mAgbGxvGOUNEOHv2LM6cOYMxY8Ywxg2fz8eKFSvA4/HQpUsXeHt7MwaRWCzGwoUL8fjxY6xe vZpxplVWVuLGjRswMzNDUFAQsw5KJBLk5eUx+/zr+oJyn3zdsZibm4v8/Hx4eHgwe55AIMCG DRsgEAgwZcoUZs2Pi4vDmjVr0LZtWwwbNqzGIo5KJ4Uyoqick3fu3MGsWbPQo0cP5hZwIkJs bCySk5PRqlUrxumgXLOkUilsbW1VZOPxeOBwOCpzUigUIiEh4a05efv2bezfvx9ff/0143gR i8XYtGkTMjIyVNY9FtYA+c8glUpRUFCAhIQE3L9/H0lJSXj58iWEQiHs7Oxgb28PV1dX+Pn5 wc7Ojgn9vhnJqE3kcjlKS0tRXl4OoVCIoqIipKam4uTJk4iOjoaNjQ1kMhlMTEzg7+8PW1tb BAUFISgoSGWDrG2UYX9tbW3o6uoiOzsbhw4dwqlTp2Bra4s1a9bA2dkZBw8eRExMDLp164aA gABmg6wLlB7GqqoqGBkZgcvl4s6dOzh06BAePHiA/v3746effkJFRQW2bNkCHR0d9O7dGy4u LnV6M6pSoVYoFDA0NIRQKMSpU6dw4MABFBcXY9WqVQgLC8OjR49w9OhRBAYGon379rC2tq7T sLdCoUBxcTFSU1Px8OFDXLlyBZGRkTA2NmYUI3t7e8TGxkJHRwc///wzvL29GSWtLmRVRk9K SkogFApRXl6OzMxMRERE4Nq1azA1NQURMWlUVlZW8PPzQ9u2bWFnZ1dnOfMKhYIx0gwNDcHj 8XDs2DEcPnwYUqkUy5cvR3BwMCIjI3Hu3Dm0adOGUebqss/lcrlKNDcxMRH79u3D+fPn4e/v j/Xr10NPTw87d+5EYWEhevbsicaNG9d6Gc03549YLIZYLIaRkREUCgUiIiJw4MABREdHY8aM GRg+fDjS09Px+++/w9nZGV27dn3LwVEX8Hg8pKWl4dGjR7hz5w7Onz8PLpcLNzc3ODg4wMHB ATk5OcjLy8OkSZPQoUMHGBoaQldXt87OwAkEAsb4KCkpQU5ODu7fv48///wTOjo60NDQgI6O Dry8vODo6Ag3Nze0a9cOLi4udebdJiKIRCJIJBIYGxtDKpXi4sWLOHjwINLS0jBt2jQMHjwY iYmJ2LlzJxo3bozw8HDY2dnV6VlCZerb6wr+kSNH4OjoiD59+jBG+unTp/HkyRMMHz4cHh4e n7TGvZ66XFRUhHHjxsHQ0BDr1q1jHB5KHcLc3FzF6VjXv1sul+PatWuIiorCt99+yxiUGRkZ jOOyf//+dT4fWVgDpFYRCoVITU3FgwcPcOfOHcTExEChUDDe0MDAQLi7u8PR0RHGxsb1PgFy cnLw888/w9bWFkuWLGEWmLKyMpSWlkJTUxM5OTmIiorCkydPkJiYCD6fD3t7e/j5+aF9+/Zo 2rQpbGxsanWhvXr1KtauXYtx48ahZ8+eKt4gTU1NJif01KlTOHfuHH744QcmRUIsFiMnJwdW Vla1ch5CiVgsxsqVK/Hs2TOsXbuWibJIpVLk5OTA0tIShoaGqKiowOrVqyGVSvHzzz8zIfqS khLw+Xw4ODjU6saanJyMmTNnwsvLC7/++ivzrDefHxMTg40bNyIkJIRJ+1AoFMjKyoKOjk6t nIGRSCTIzs7GkydPcOvWLTx9+hSVlZVwcHCAh4cHgoKC4OnpiQYNGsDMzAza2to4evQorl27 hqlTpzIpEkKhkMnnrs0+FwgEWLZsGTIyMrBq1SomlUYoFCI/Px8aGhooLCxEQkICHj9+jKSk JOTn50NbWxsBAQFo164dAgMD0aBBg1rt84SEBMyePRtBQUGYPn06Y/gUFxczDhFNTU08fPgQ O3bsQN++fdGjRw9mM8/KymJSNmvTIDl06BD27t2LWbNmMREGZcTGwMAAVlZWkEql+OOPPxAd HY2ff/6Z8TwLBALk5ubC3t6+Vg2SiooKLFiwAPn5+Vi/fj3jbRYIBMjLy4O9vT309fWRl5eH tWvXwszMDNOnT2f6t7CwEEKhEI6OjjW+ZioUChQUFCA6OhqRkZF49OgRCgsLYWFhAQ8PDwQG BqJJkyZo2LAhLC0toauri5s3b2L//v0YPHgwOnXqxPR5dnY2DAwMau0MjFLe3bt34+zZs1iw YAH8/f2Z1zMzM6GpqYmysjK8evUKDx8+xMuXL5GdnQ0A8PX1RUhICIKDg+Hq6qoSca1pSkpK MHv2bHC5XKxYsUIl8lBUVAQ7Ozvo6OggPT0dq1atgqenJyZMmMBEAPLz80FEsLW1rfeD+kSE iIgIHDlyBN988w3T51KpFNnZ2TAzM1NxLv7555/YunUrpk+fjvDwcAB/R7cyMzNhZGTERJz+ CRQUFGDNmjUwMjLCtGnTmEyL4uJiCAQCODg4sEYJa4D8s5BIJHj16hVu3ryJyMhIJCYmwszM DP7+/mjbti18fX3h4OBQp166d8Hn85GcnMyEs5UT7+TJk2jWrBlatGjxwcVRLpejpKQEKSkp uH//Ph4+fIiUlBRoaGigefPm6NatG1q2bMmk71R3cczOzgaPx4OHhwdjED19+hRxcXHo3Lmz Sgj3XchkMpVFJDU1Ff/3f/+HwMBA/PrrrzVyWFMsFiM5ORkGBgbMoVCxWIzz588zqUwfe45c LldRQPbt24fNmzdj5syZ6NOnT430eVlZGTIyMuDs7MxsKjk5Obh06RKaN2+Opk2bflChVJ45 ej3FatKkScjKysK2bdsY5e9Lvd5ZWVm4ffs2IiIi8OLFC+jo6MDDwwNt27ZFixYt4OzszBhq 7+vz16vxxMXFYcKECWjXrh1+/fXXGokwKfvczMxM5czO2bNnYWpqirCwsI8+p6KiAunp6Xj4 8CHu3r2LhIQESKVS+Pn5oWPHjggJCUHDhg2/SDEtLi5GTk4O3N3dmTUnMzMT165dQ6tWrd55 U++H+pzH42H8+PHM+Yovmd+vK57p6emQSCRo1KgRo6jdvXsXWVlZCA8PV0k1/JR5fv/+fUya NAl9+vTBzJkza0S5FwqFSE5OhqWlJZPKJBAIcO7cOVhbW6NNmzYfNByJCAqFgpGFiLB+/Xoc PnwYq1atUjkv9qWK1ZMnTxAREYGnT5+iqqoKHh4eaNmyJYKDg+Hu7g5zc/P3ru9yuRxcLlel iMXEiROhoaGhYmR96TxPTU0FEcHd3R1cLhcKhQJXr15FRUUFOnfu/ME5rmz7nJwcPH/+HDdu 3EBCQgKKi4vh7u6O9u3bo1OnTnBzc/uiDILKykqkpKTAzs6OcSiUl5fj7NmzcHV1RatWrT44 tpTnzZRtLZfLsWTJEkRGRmLVqlUqZ4fqkzf7PDs7G9988w2sra3x+++/M/vFo0ePkJaWhg4d OvyjjI1PnZMAsH37duzatQtLlixhzo2xsAaIWpOXl4fIyEicP38esbGxMDc3R0hICDp16gRv b+86T1/42Ia/evVqHD9+HGvWrEGbNm1qRCHLysrC/fv3ceXKFbx48QJ6enro2LEjunXrBj8/ v89W9ouLizF+/HhoaWlh48aNH1VCPgWZTIaYmBiIxWIEBgYyhyKzsrKgUCiqVY3n2rVrmDZt GoYPH84cWKwJYyEqKgoNGjRgDtWKxWKkpaUxh5s/93cvWrQIERER2Lhxo8oBvS9ZvNPS0pCa mooWLVowm1RxcTEKCgrg5ub2yZVZysrK8OjRI5w+fRqPHz+GpqYmmjdvji5duiAgIAC2trbV 9kZJJBJERUUBAFq0aMEouGlpadDU1ISjo+Nn99n58+cxd+5cTJo0iYkIfem4zMvLQ3R0NCIi IvDw4UPIZDIEBgaib9++1UpzlEqlmDdvHm7duoUdO3bA29u7Rvo8ISEB+fn5aNmyJWPUKA/p u7q6fraBl56ejrFjx8LNzQ2rV6+uEe+1SCTC06dPoauri+bNmzPnA5KTk6Grq1utPj9y5AhW rFiBGTNmYMiQITWyFhcWFiI6Oho+Pj6MIVtZWYnU1FQ4OTl9VAl/3Th6/vw5zpw5g9u3b0Mg EMDPzw/h4eFo2bIlGjZsWG1FXKFQICEhAYWFhQgKCmLW8fz8fPB4PLi6un52xE55Nq9NmzaY N2/eFzsFiIiptHj16lXcv38fxcXF8PPzQ48ePRAWFsacAfqc79y1axc2bNiARYsWqUTbv1RX iI2Nhb+/P2PA8/l8ZGdnMwVh6puUlBT0798fdnZ2OHjwIJNWlZubC5FIBCcnp39EafrqOm2i oqLQuHFjpuCMMpvFwcGhTtPNWT5vwv6nkEqlFBMTQ/Pnz6fQ0FDy8/OjCRMm0MWLF6moqEht 5CwvL6e0tDSSSqVERKRQKCgxMZFiYmJIIpHU+PPEYjElJSXRli1bqHfv3uTt7U39+/enI0eO UEFBwTs/I5fLKTs7mwoLC5nXRCIRPXv2jDIyMkihUNRa+8hkMlqwYAGFhYVRbGzsB98rEoko LS2NKisrmdeKioro8ePHVF5eXqv9mJ2dTZ07d6YJEyaoPP9dlJWVUWZmJsnlcpU+f/HiRa30 +eucPXuW/P39adeuXR98n0KhoLS0NNq4cSOFh4eTt7c3ffPNN3Ts2DHKzs5mZK8NJBIJ/fTT T9S+fXtKTEz84HuFQiGlp6eTUChkXsvLy6OnT58Sn8+vcdnkcjllZWXRoUOHaOjQoeTj40Nd unShbdu2UVpa2nvnQklJiUq7yeVySkhIoJcvXzJzv7Y4cuQINW/enE6fPv3RuZadnU2lpaXM a5WVlfT48WPKy8urVRmFQiFNmDCBwsPDKSMj44PvFQgElJqaSiKRiHktMzOTnj59SgKBoFbl jI2NpdatW9Mvv/zy0blaWFhIBw8epAEDBpCXlxf16NGDNm7cSAkJCbU+z3fv3k2BgYF07dq1 j+6TaWlpKusjj8ejx48fq6z3NUlxcTFdunSJvv/+e2revDm1bduW5s6dS9HR0e+dC3w+n9LS 0lTaLSMjg549e0ZVVVW12paPHz+mkJAQWrNmTa2ue++bk1lZWVRcXKwyJ588eaIyJxUKBa1e vZqaN29ON2/e/E/peikpKdSxY0eaOXOmyprAoj78ZwwQkUhEd+7coYkTJ5KPjw+Fh4fT1q1b 6dWrVySTydRK1oqKCpowYQL16dOHSkpK6vz5fD6fbt26RT/88AMFBARQu3btaMOGDZSVlaXy vufPn1ObNm1o48aNtWpsfGgjj4yMVDEcpVIpicViFcVw8+bNFBoaSk+ePKlzGeVyOcXFxdHd u3dVNkmxWKwy7kpKSmjEiBH0v//9r1YU5I8hEAjozp07FB8fryK7cuFWKBQUHx9P8+bNo5Yt W1JwcDAtXLiQoqKi6nRxz83NpatXr6psvG/2uVQqpbVr11KbNm0oLi6uzttSLBbT8+fPafHi xdSmTRsKCAigefPmUWxsrEqf5+bm0sCBA+n777+vdQX5fevM7du3KTk5WUWxeVNxO3/+PIWE hNDRo0frZT3Mzs6mGzduqCjDYrFYpc8lEgnNnTuXwsLCKCUlpV4cW1FRUfTo0SOmjxUKhYoB nJGRQRs3bqR27dpR06ZNaerUqXTz5s06ne/l5eV08+ZNSk9PV+nzN+fwX3/9RQEBAXTu3Lk6 b0uZTEYpKSm0detW6tKlC/n6+tKECRPo7t27Kn0uEolo2rRp1Lt3b8rNza1zOSUSCT158oSe P3/O7H8KhYJEIlGt74c3btygoKCgjzqMlI6ta9euUXZ29gf7/N+GTCaj6OhoevjwIbP31lX/ sHwa//oULKlUigcPHmD37t14/PgxmjRpgoEDByIsLIwJUaobAoEAV65cgbOzM/z8/Ort0Juy 5Oaff/6J06dPQ1NTEwMGDEDfvn3h6OiIjIwMPH78GKGhoTWSV14T3Lx5E/v27cPYsWMRFBQE hUKBmzdvQiKRoF27dmpx8ZNMJsO2bduQl5eHqVOnwtLSEhUVFbh69So8PT3h7e2tFql/eXl5 WLx4MVxdXVFeXo4LFy7AxMQE3377Lbp06fLRszx1xYULF3Dy5ElMnjwZfn5+kMvliIyMBIfD QZs2beq0Qtmb5Obm4tKlSzh+/Djy8/MRHh6OYcOGwcfHBzweD9euXYOvry8aNWqkFn2empqK lStXomPHjvj666/B4XAQExOD5ORktG/fXm3WzFOnTuH8+fOYPn06vLy8IJPJcPHiRZiYmCA4 OFgtDqJWVVVh2bJl4HK50NfXx6lTp8DhcNCnTx/069cPbm5uanHzeExMDNauXYsBAwYw5cSj oqKQnZ2NsLCwWi0C8THKy8tx69Yt7Nu3Dy9fvkSbNm3w3XffITAwEBwOB5cvX4aVlRUCAwPV oi3Ly8uxdOlSODg4YOzYsbW237x48YI5U1mdSxefPn2K9evXY/jw4f+pMxNCoRC//fYb9PT0 MGXKlDqtssnyH0rBksvl9OTJE5owYQI1adKEvv32W7p27Vqth2WrE5k5ceIEHTx4sNZTLr6E R48eUbNmzcjGxoaCg4Np69atKl5odUChUNDx48fJwcGB9u3bp7ZtWVVVRRMmTKCAgAAV77O6 ERMTQ76+vmRgYEBfffUVnThxQu36XC6X0+7du8nBwYHOnDmjtm2ZnZ1Nffr0ISMjI2rWrBnN nz+/Xjz1HyMqKoq8vLzo119/VbvI8Ot9vnHjRnJycqIbN26obZ/n5eVRnz59SFNTk1q2bElr 1659K4qsDty5c4ccHBzot99+U1vPMI/Ho2nTppGJiQl5eHjQuHHjKCoqSu3kFIvFtHv3bpo/ f36Npfemp6fTunXrajSam5OTQ7Nnz6bDhw//pzzuMpmMjhw5QlOnTqWcnBw2BFHP/CvrlWVl ZWHHjh3466+/4ObmhrVr1yIkJKRGqifVNMobswcPHqw2B97fRVxcHCwtLTFv3jzm5usTJ05g 0qRJ+Oqrr+rs3pMPIRKJcPv2bXTv3h3du3dnXufz+aioqKjTexs+dljw5cuXmDBhAlOFiohQ UFAALS2tGjm4/yWUlZXhyJEj2Lt3L6ytrTF9+nT06NED5ubmTPlGGxsbtehzPp+PK1euYNCg QQgLC2Ne5/F4zOWU6jCvcnNzUVVVhZUrV0JfXx+7du3C+fPnMXr0aPTv379aXsxacEbh1q1b 8PDwwLfffsscWJVIJCgoKICNjU29RpNeH583btzAsGHDmIvllH1eVVUFW1vbeu1zsViMiIgI bNq0CWVlZVi6dCkGDx4MR0dHZiwYGhqqhfdVoVDgwoULCAwMxDfffKNyaVxxcXG93H3yvqyA zMxMTJ48GYGBgfjjjz8wbNgw9O7dG//3f//HHDyub7S1tTFixAimqh/w/19Iqrwc8nPn5OnT p3HhwgWmhG5NYG9vj4ULFzIVv5QRu6KiolopL60uaGhoYNCgQejfvz+jCyj3Xj09vU8uIMHC RkDeorKykg4dOkShoaHUrl07OnToEPF4PLWWWSwWU15eXq0fPvxSysvLVc5aJCYm0rRp08jD w4P+97//ffQgeF1FQIqKit467H3z5k1q3bo1nTp1Sm2iXvn5+SoRL5lMRrNnz6ZevXpRWlpa vXmHIiMjqVu3buTr60tr1qx5K7c6OzubOnXqRIsWLVLJx65Pb3hubu5bZyjOnj1LISEhdPHi RbXoc6FQSPn5+cxh1by8PFqzZg01a9aMunbtSjdu3FCLiENZWZnKYXOlB7Zjx460cuVKtYjS ymQyys/PVzlfQUR0+PBhCg4Oprt379abbLGxsfS///2PfHx8aMaMGW8VSxCLxTRx4kQaNmxY vZzvexeFhYVveevj4+MpLCyM1q5dqxZREalUSvn5+cyaw+Px6PDhwxQaGkohISF08OBBtctu UMLn82no0KE0YcKEaukj75qTtcH9+/cpMDCQdu/e/Z/ywiuLm/Tt25fy8/PZsEQdojF//vz5 /wZDKi4uDnPmzMGBAwfQr18/LFq0CMHBwWrhpVUik8lw/vx53Lp1C76+vtDQ0ICGhgYMDQ3V yuNQWlqK33//HUKhkLkjQ1dXV6XUpoWFBTp27Ah/f39cv34d+/btg1wuh6enZ521eWxsLHbv 3g1XV1cYGRmBw+Go3Pb6uqx6enqwsbGpkXsvPgeJRILjx48jKioKTZo0AZfLhaamJgwNDVWi MVwulykn7OHhUeeemOzsbKxevRpr166Fj48PVqxYgd69e7+V/62vr8/I6ePjU+e3BD958gQH DhyAl5cX9PX1weFwYGRk9FZJUWtra+jq6sLKyooZw3XpAT906BCePHmCZs2agcPhMH2u9DAb GhqidevWaNOmDRISErB161YUFBTAy8urznLuc3JysH37dhgZGTFnuHR1dd+KFCsvENTX10fj xo3rtM8VCgVu3LiB06dPw8fHBzo6OuByuTA0NHzLM29jYwN9fX00bNiQufOjLiNxu3fvxsyZ M6GtrY1FixZh5MiRb927wOVy4ejoCLlcDh8fn1q9fO9dpKenY/PmzbCysmJkMzAweOusgrGx MSwsLGBoaAgvL686jSjJ5XLcuHEDZ86cga+vL7S1tZk+V449HR0dNGnSBOHh4SgvL8fvv/+O 6OhouLi4qM15RCVaWlpMVEE5hj+0Dm/btg16enrMGH7XnKwNzM3Nmcst67rP6zsqYm9vDy6X Cx8fn3q/742NgPyDqKqqov3795O/vz/16NGD7ty5U+cl8T6V7Oxs6tq1K61atUqtz3ucPXuW wsPD6fbt25/sodmwYQM1adKEBg0aVCeVhyQSCc2ZM4eGDx9erfLJVVVVb3lQa4OUlBTq1KkT bd269bPHpVwuJz6fX6uecblcTteuXaN27dpR69at6eTJk59dHUUikdRJJR+hUEhjxoyh8ePH V8uTWFd9/vLlS/rqq6/ojz/++OQo6PHjxykkJIQ6dOhA165dq5M1bNeuXdSxY0dKSEioVuT2 Y2Wla8p7PGTIEJo+fXq1PNxVVVW1Xu0nLi6OhgwZQk2aNKE1a9ZQWVlZteZ5XfT5xo0bqWvX rh8tY/2+Pq+LeV5SUkLDhg2jX3/99ZP6TqFQ0P3796lPnz7k5+dHBw4cUPsKTzKZjPh8/lvR pT179lDHjh3VIqNAuebWR4W++kahUNTZnPwv8482QDIzM2nixInk4eFBK1asULsDsu8KI+fl 5alF6srHNv3i4uLPDr0/efKE+vTpQwEBAbR///5a/Z0KhYJKSkqqrQSdPHmShg0bVuuHwCUS CeXn51crxU4gENCsWbNo2bJltaI483g8WrlyJTVu3JimTJlCqamp1VbAhg4dSlevXq31TSE/ P7/afb5z504aN25crR8+FIlEVFhY+NmbV1paGn3//ffUuHFjWrp0aa2nj/J4vGqndjx79oyG DBnyyU6KLzGQCwoKqmV8yOVy2r59O/3www+1cneFWCymw4cPU9OmTalfv3708OHDan1PcXEx jRkzhnbu3FnraXhlZWXVPhx948YN6tu3Lz179qzWlfPCwsLPNiJKSkpo1apV5OXlRRMnTqTM zEy13WNzc3NpzJgxdOTIkbfmpLqk5hERXbp0ib799lt6+fLlf0oxLisro1GjRtHmzZvVthjH v4F/bArWvXv3MHHiRJSWlmLFihUYMmSI2oXOBAIBYmNjYWJi8s4wsrqQm5uL3NxcmJubg8Ph QFtbm0lv+dyDbV26dIFAIMDWrVtRWFiIpk2b1kj4WC6XIzExEXK5nEll0dPTq/ahWA0NDbx4 8QKurq7M4dCaoLKyEjExMTA1NYWWltYXpdhxuVxUVVUhMzMTLVu2rNGSjq9evcKcOXNw9epV TJs2DVOmTIGlpWW1D15mZmZCR0cHPj4+NRa6l8lkiIuLA4fDgYGBATgcDgwNDavd51wuF69e vYKHhwesra1rrC3LysqQmJgIU1NTaGpqQlNTk5H3czA1NUXHjh1hYWGBHTt2MGXDa6ooQVpa GgoLC5l+1tHRqfbc1NLSQmJiIvT19eHj41NjbSmVShEdHQ0tLS1mDTIwMPjsW7sBMDepJyQk wMfHp0aLOxQVFWHp0qXYtm0bBg0ahIULF8Ld3b3abVleXo6ysjI0b968Wr/1fSmLKSkp4PP5 zE3Qurq61V5HdHR0kJGRAQsLi2r/1nchEokQHx8PPT09JsXOwMDgsw+/6+npoXXr1mjcuDGO HTuGCxcuwMXFBQ0bNlQ7/UVTUxNFRUWIjY2Fra0trK2tweFwvmhO1lb6WFJSEho0aKCW7Vib /VNZWYnCwkK0aNGixuYkyz88BUsqldLBgwfJ39+fxo4dW28Hdj/F+7Zq1SoKCgqqtme5Ligs LKSuXbvSjBkzauwgvEwmowsXLlDLli3p66+/rlaKx5tcvXqVWrRoUaMXY8nl8hoNscpkMlq6 dCmFhYWpXPpUE99bkwdBb926RcHBwRQeHk5Pnz6tsehETXuKzp49S15eXnT9+vUabcua7HOJ RELjxo2j3r1712gE9unTp9S1a1cKCQmhW7duffH3paSkUPv27WnFihU1GpGq6T4/ceIE+fr6 1mhkpab7PDExkb7++mtq1qwZnT17tsbSaaVSaY3O8+joaGrRosUnpwJ+6ppZ032+adMmatOm jcolqF9Keno6jRw5kry9venAgQNqWeQlMzOT2rdvT9OnT1fri/Fqep/8p+mb7KWFbASE8S6v WLECGzZswKhRozBr1qwa9WTWsGEHkUiEr776Cr6+vmpR/vV9XmYdHR18/fXXNeYh5HK5aNSo EVq3bo2IiAicOHECjRo1+iIPSmVlJby8vNC5c+caKwXK4XAYL7VEIsH9+/ehoaHxReUxxWIx unfvDk9PzxqLBHC5XOa78vLy8Pz5c9jY2Hy2h1Aul+Po0aOYPXs2WrVqhVWrVsHDw6PG2vL1 sobPnj1DaWkprKysqt0OAoEAzZo1Q4cOHWqsFOjrbVlVVYW7d+/CwMCg2tFThUIBsViMfv36 wcXFpcb63M7ODh07dkRaWho2bdoEMzMzeHl5VXsdUXrBBwwYUGOR4tf7XKFQ4MmTJ6ioqHjr 4PXnyhkaGoo2bdrUWKT49T6vqKjA3bt3YWpqWi1P87179zBp0iTo6elh06ZNaNOmTY2t7a/L mZSUhKSkJOZwbHUjC3Z2dujVq1eNedXf7PPHjx9DJBJ9URnpiooKhIWFISAgoMbaUhlNBID1 69eDz+ejWbNmalFG+vW9wszMDIMGDYKxsTFevXqFlJQU2NraqpW+8Po+KZPJcPfuXXA4nP9E ydrX52RmZiZevHgBW1vbf22ZYjYC8h6Kiorohx9+IE9PTzp8+LBaH+Jm+f/Jz8+n77//nvz9 /enUqVNq60mpqKig/v3703fffafWZ3Tu379PPj4+n11SWCQS0apVq8jJyYmWLVtW6weIf/vt N+rYsaNaX/ZUVFREvXr1ojlz5qhtnm9lZSWtWrWKPDw8aNWqVXVyiL66nsIZM2ZQ27Zt1bqU ZVZWFoWFhdGiRYs+q89lMhmdPHmSfHx8aPz48ZSXl1ercp46dYoCAgJq/YzNlyAWi2natGnU rVs3tTq38Ga/HT9+nDw9PWncuHHVKlhSV+zfv5/8/Pzo+fPnaiujSCSiYcOG0YgRI/5zh9Mj IiLI399fbUq7sxGQOiI/Px/Tp09HTEwM1q9fjx49eqhdRIGI8OjRI7x48QIuLi5qG/EQCAQ4 d+4cNDQ06uTCO0NDQ7Rt25Y5q2NmZvZJ5VtTUlJw48YNODk51YnXSltbG82aNYOjoyNcXV0/ ycMhl8tx8+ZNpKSkwNXVtU76z8bGBs2aNUPDhg0/2dNcWVmJ5cuX48CBA5gzZw7Gjh1bo+dJ 3kWTJk3g4eEBZ2fnTy7LHB8fj8jISLi6utZJzq2+vj7Tlo6Ojp8UvZDJZIiIiEBBQUGd5ERr a2ujZcuWMDExwdq1a1FWVoagoKCPzomysjIcP34cpqamTP5/bXsKmzRpAhcXFzRq1OiT+zwu Lg63b9+Gm5tbnVx4Z2RkhKZNm35Wn8vlchw8eBBz5szB119/jQULFtT62uni4oLGjRvDycnp k/uvsLAQZ8+ehbW1dZ2ch9TQ0ECTJk1gb28Pd3f3T1qniQjR0dF4+vQp3Nzcan2f5HK58Pb2 RpMmTXDgwAE8e/YMLVq0qJdLIHk8Hk6fPg0DAwOYmZm99Xc3Nzd4e3vDyclJLS6pfBeampoI CAiAk5MTGjZsqBaXVNYVjo6O8PT0/Ky9l+UfHgFJTU2lIUOGUIcOHdTaM1BYWEjdunWjpUuX qnW+5Llz56hJkybVrtjyJZ6TFStWkKurK23cuPGDOblyuZx++eUXGjhwoFpfJJmTk0Ph4eG0 Zs0atZWxoqKCZsyYQU2aNKFTp06pbT6rXC6ncePG0ejRo+ukvOuXrEehoaF04MCBOm+fCxcu kJ+fH82cOfOjbbRnzx5q27atWlevqayspFGjRtHEiRPVtmyqWCym7du3U+PGjWnjxo1qG4Ei Ilq+fDm1adOGsrKy1FZGHo9HQ4cOpblz59Z51PHZs2cUFhZGffv2rZezo8eOHaPQ0FC1KbHL wlLfqLUBkpycTF27dqWwsDC1n7RCoZAeP3782TXg65rc3Fx6+PBhvaSwSSQS2rNnD7OZv88I USgU9PLlS0pPT6+3dlIoFHT58mWKjo5+73uqqqooOjq6Tmrjv4/y8nI6f/48FRQUvNP4mD59 OgUEBFBkZGS9jruEhASKiIj4YHpbXFxcrae2fAiZTEZXr16lFy9efFCBevr0ab0popcvXyY/ Pz+aNWvWB42Q9PR0SkpKqleD88WLF3T//v33OmQkEgnFxsbWSoncz1m3L1269E6FVCwW05o1 a8gDP5eKAABISklEQVTV1ZW2bNlSrweZs7Oz6dy5c1RRUfHBOVYXdzB9iAcPHtDdu3c/2OfP nj2rt1SopKQk6tGjB/Xt27fO95esrCx6+fLlJ8/JzMxMunjxolo7ZBQKBT148OCD8/zfSl5e Hv31119q7SRlDZAv6Nz+/ftTWFhYvS+qLDWr5O3bt48aN25MmzdvVtuzPAqFgubMmUO9e/eu 9l0JdUFhYSF16dLlrepG6mR8EBGdP3+eXFxc6MaNG2rbllKplMaNG0fdunX7oKJX3yiNkE+J hNQnf/75J7Vp00atnUcCgYBGjRpFAwcOVGlLmUxGf/zxB7m5udW78aE0zn19fWnHjh1qvb5v 376dWrdurbbVKYn+dmwqjZCMjAy1lTM6OpqCg4PpzJkzat3n69atI19fX7Vuy9oyZoOCgmjP nj2sYldN1PIMSEFBAWbMmIGioiJs3LixRuvM1+SZj7i4OKSmpn5yLnF9IBKJcOvWLWhra6tF XqkyV9zY2BjLli2DhYUFfH19kZ+fX+3qTrVV+cPf3x9OTk5wdnaGlpYWiAixsbEoLCyEjY2N WvSvgYEBvL290bBhQzg4OAD4u7rK8uXLce7cOaxbtw7t2rVTi/zZxo0bo1GjRkz+c1ZWFp49 ewYHBwe1qCrC5XLh5+eHhg0bwt3dnenz58+fo7S0VG0q7rm5ucHd3R2bN29GYWEhQkJCIBaL ce/ePRgaGkJfX18t5GzQoAFcXFzg5OQEIyMjAH/fRfL48WM4OTmpxTk5LS0t+Pv7w8rKCh4e HtDU1IRCocChQ4ewYsUKTJkyBaNHj673ewAsLS3h5+cHFxcX2NraMud87ty5AwsLi1o/0/Wp eHp6ws3NDS4uLkzlrcTERKSlpcHOzk4t9klzc3MEBQXhzz//xP379xEaGlorZ2aqqqpw/fp1 6OnpVWvvtbS0ZNb2ujivWV0aNWoEV1dXeHp6qtUdJnUxjpo2bQpHR0e10QfYMyBfCI/Ho3Hj xlFISIhaRz5KSkqoffv2tGDBArWuE33p0iXy9vam+/fvq5VcYrGYVqxYQc7OznTq1CmaMWMG DR06tF7TmT6Gsm77zp071dqLv2rVKvL29qbTp0+rrZxisZiGDx9OgwYNUuu8+qSkJAoMDKzz Mx+fwtmzZ8nZ2ZlWr15Ne/fupXbt2lFycrLatqVQKKSRI0eqfaW506dPk5ubG23YsEEt7494 3fPcunVrtb7xm8/n04ABA9Sy0lxUVBS1adOGxowZU+3b4T/EiRMnqGnTph9M42VhYSMgaoJY LMbixYtx7do1rF+/HgEBAWpruCkUCjg6OqJnz54wNDRUayMzODgYrVu3Vqva1RoaGggMDASP x8O2bdvQunVrjBs3DnZ2dupqqCMjIwPu7u7o2rWrWnp6iAiHDh3C4sWLMWvWLAwePFhtI3NF RUXQ0NDAd999p7Z3+cjlcqSnp8Pb2xs9evRQqzsEAMDd3R0WFhZYtWoVbGxsMGnSpBq9ib6m yc7OhqGhIb755hu19ejev38fU6ZMQc+ePTFt2rRPruZV1/D5fJSWlmLAgAHw8vJSyz4nIuTl 5cHMzAz9+vVTu3sjbG1t4eXlhU2bNqG4uBihoaE1Gn3ncDjo0KEDmjVrViPRPh6Ph/LychgY GKjtHCciFBQUQC6Xq01Urq5Q3pxuZGSktv2jbqhNrViFQoF9+/bh2LFjWLhwIYKDg9W64QwM DNC1a1e1D725u7ujY8eO9Z5C8C60tbUxY8YMhISE4NKlS2p9uY9EIsGGDRvw8uVLtS2RGBkZ icWLF0Mul8PZ2VmtF8GzZ8/ir7/+qpMSsdWlqqoKW7ZsQXJycp2UNf3sxZvLxdChQzFhwgSc P38eIpFIbct/A8Dhw4dx5syZd5YgVQeSk5Mxc+ZMpKenw87OTq0VqNjYWGzZsgVaWlpqPc+P HDmCK1euqO2lda1bt8bSpUvx119/4cCBA1AoFDX23V5eXggODq6xfe3OnTsYO3YsUlNT1ba/ 5XI51q1bhwULFkAsFv+nlOmEhASMHDkSjx8/Zi2LT0RtIiBXr17Fb7/9hsmTJ2PIkCFquZHK 5XLweDxoa2ur9UYvFAohEonU1nunpKysDHp6eggKCsKlS5dw/fp1dOrUSW1y2IG/733g8XjQ 19eHsbEx8vPz0bJlS7Wrf56YmIhJkyYhNDQUffv2hYWFRZ3dTfKpEBF4PB64XC7Mzc1RWlqK xo0bq51yIpVKUVFRAUNDQ+jo6CAnJwchISFqN+crKyuhUCjQokULJCcnY9euXWjbti0sLS3V RkaFQoHy8nJoaWnB2toamZmZaNasmdpFjUtKSjB16lQQEX744QcYGxvD19dX7fqcz+dDLpfD zMwMZWVlcHBwQIMGDdRKRoVCgdLSUujo6MDU1BTp6ekIDAxUq3X9dZT31qxbtw6NGjWCu7v7 F81JqVRaK9FSMzMzlJeXw8XFRW2jxlwuF4aGhqisrISfn5/a6yA1ibGxMYqLi2Fpaal2e6/a og55YImJidSiRQuaPn262uaDKxT/X3vvGRfVtf3/fwaGMgxdmoCAVAUURewxsSUauSaaaK5e E0153Vw1+o0mlqjRGKMxMWpiNFGjogb1YkMsWIMRWxSUJqD03uswTGHK2f8H/uEXr6iUKVvZ 74fAHNbsffY5e+211mdx5PDhw+Tjjz+mWmpXIpGQzz77jOzYsYPq3L+UlBTyxhtvkISEBEII IUlJSWTAgAFk1apV1OSHq9VqsnPnTvLvf/+bSKXSlvuANurq6sj06dPJuHHj9Cpj+yxu375N 3n33XZKZmUmtjSqVivz4449k7ty5Lfn/NM55RUUFmT59OomIiCCEEFJeXk4mTJhA3n77bapU 2y5cuEDeeustqntTNDU1kRUrVpA+ffq0PI9opLi4mMyaNYtcuHCB6mf76dOnyZQpU0h5eflz k4sulUrJggULyJAhQ0hGRkaHrlFdXU3effddcujQIZbcz2C0Ab0f74hEIqxduxYODg74/PPP qQ17E0JQXFyMvn37Ul3zIRKJIJfL0adPH6od38LCQri4uLR0kw4KCsLKlStx4MABREVFUTPn ubm5CAkJaTnJoS3dQaVS4ZdffsH9+/fx3XfftSjk0EhRURHc3NyorfMBHqbaFRcXY/DgwS1R LhpTXCoqKgAAffv2BQA4Ojriu+++Q0FBAbZs2QKlUklNZM7f359qFZ+oqCgcO3YMa9asQf/+ /am1s7y8HGZmZvD19aX62Z6bm4s+ffpQnV75vwgEAixbtgz29vb4+uuvUV9f3+5rlJaWghDS siYZDAbFERCVSkW+//57EhgYSO7cuUO1p8ZxHJHJZNQ321GpVC2n9TQjl8sfi3QolUry9ddf k5CQEGp6BzQ2NrY656mpqWTv3r16V+06c+YM8fb2blWlieM4cv78eRITE0PFKb5cLm9VVai+ vp7s3buX5OTkULHOpVJpq3OekpJCfv/9dyqitEqlstV1fvToUeLj40POnDlDxfqRyWStznlF RQUJCwsjJSUlerUvNTWV9OvXj3z11Vet9iSKj48nR48epSIqq1AoWrVDoVCQQ4cOUaN0KJVK Wx3LkpISsn37dr02nnwW8fHxJCAggPzwww/tVu160prU1ro6dOgQSUxMpPo9X1BQQMLCwkhN TU2XOtlXq9Xk4MGD5ObNmyzMQWsE5Nq1a9i3bx8+++wzBAcHU+2o8Xg8mJqaUl37ATxUl3oe tLhNTEwey5Pl8/mYN28eXF1dsWbNGjQ0NOjdTqFQ2OqcNzU14ZdfftFrwVlOTg7WrVuHqVOn 4p133mn1ns3MzMTmzZs7dKKnjTlvTQyBx+MhKioKERERVKxzgUDQ6pyLRCJs2LABycnJereT z+e3us7ffPNNvP3221izZg0VxaqmpqZPnPMjR47g9OnTerOtoaEBa9euRY8ePTB//vxW67pq a2uxZcsWKsbSyMio1doCHo+HuLg4bNu2DQqFgopoQmtjyXEc9u/fT02EuzUGDBiAJUuWYM+e Pbhy5YpG1qS2nlM3btxAWFgYNdHOJ0WUf/vtN1y9erXLHe7fu3cP69evh1QqZZGOJ93HhBCi j39cWVmJ9957D25ubvj555+p3TTn5ORArVZTHfZWKpVISkqCp6cn1akO1dXVyMrKwsCBA59a xH337l189NFH+PjjjzFnzhydp8Dcv38fxsbG8PLyeuLfqNVq3Lt3D927d9eLEppcLsfChQuR kZGBQ4cOPTH1qr6+Hjk5OQgMDNRLQWBFRQXKy8ufWdCbm5sLpVIJPz8/vb0szMzMnjrnKpUK CQkJ8PDw0EsRqFwuR1JSEgIDA5+aBlpeXo733nsPvr6+2LRpk87TWgsLC1FbW4ugoKCnrt2M jAzw+fynjrm2IIRgx44d2L59O3bv3o1BgwY9cQOVmpoKLy8vvYglNDY2IjExEcHBwU9VYqus rERJSQmCgoL0ckiWl5eHhoYGBAUFPXXMU1NTIRQKqS7Slclk+PTTT1FQUIDw8PCnrnWZTIb7 9+/D19dX56nZpaWlqKmpQUBAALUHoxzHIT09HTY2Ni2NcrsKVVVVLSncNCt86hV9pQmtXr2a BAcHU12QWldXR9566y3y448/Uh3Gio2NJcHBweTu3btUp7AtX76cTJky5ZkpLBzHkR07dpC+ ffvqPMRcUVFBxowZQ3bt2kX1nB85coR4e3uTy5cvU2ujQqEgn376KXn//fepbuiWk5NDhg8f TmWzwb9z4MAB8tJLL5GCgoJn/u2lS5eIj48POXbsmM5Trj788EMyb968VtNwaCEpKYn07duX bN68mepGsnv27CEjRoygWlyisbGRvPPOO+TLL7+keizbQ3Z2Nhk4cCBZtWrVU+/jqKgoMnz4 cCrSRxmM5w29yPDeuHED69evxxdffIGRI0dSfRJSW1uLyZMnU11QV1JSAjc3N7z66qvUycP+ r53jx49/5oknj8eDn58frl+/jps3b2L8+PE6awLX2NgIQghCQ0PbfOJJCAHHcTo7hcrPz8fi xYsxceJEvP/++23+v2q1umV8dYFarUZRUREmTZrULqlQlUql0xO92tpa8Hg8TJkypc1Sobqe cwAoKytDSEgIBg4c+Mz/6+7ujpqaGoSHh+O1117T2em9UqmESCTCP/7xDzg7O7frXtHVWDY2 NmLp0qWwsrLC6tWr2xwh4jhO53Oem5uL4cOHIzg4uM3rVq1Wg8fj6WydKxQK1NfXY/LkyW2W gNbH+mkPtra2sLCwwG+//YZ+/fq1iKX8L9XV1ejduzeGDh2q1++iUql0OucdjTrqcp3ThK7X JIuAPIH6+nry5ptvkpkzZxKJRMJcQMYTiYuLI3379iXh4eFU21lYWEiWL19OsrOztf6/lEol Wbp0KRk+fHi7C3hPnz5NfvjhByKXy6kdS7lcTlauXEkuXbpE9ZxnZGSQVatWkeLiYmptLC4u JsOHDydLly6lOhrR2NhI1qxZQ65du6aT/7d//37i7+/f7gLRpKQksnz5clJVVUX1vblr1y7y +++/t7uIWpfU1dWR9evXUy17LJFIyIcffkjefvttIhKJqLVTrVaTbdu2kYMHD1ItklNeXk6+ +OILkp6e3uX2MseOHSNhYWFUP4f1gc5d0cjISOTn5+Pzzz+ntjERgw4GDBiAqVOnYvv27Sgs LKTWToFAgJSUFPz1119a/19xcXE4efIk5s+f364T5mY7z549i9LSUmrH0tDQEFKpFOHh4S0R GxoRCoW4efMm1V1vXVxc8OmnnyIqKgpxcXHU2mlkZISSkhJERUWBaLkksaioCL/++iveeecd DB48uF2fNTMzQ2xsLO7cuUP1c9PIyAiHDh2CSCSi1kZjY2NkZ2fjjz/+oNZGMzMzzJ8/HxkZ GYiMjKTWTh6PB0IIDh48iMbGRqrfkxkZGYiOju6KB/04fvw46urq2Mbu7/cuIborQi8sLMSU KVPw1ltvYcmSJdSG4tLS0sBxHNW9NJqamhAXFwc/Pz9qu6ICD9NG7t27h9GjR3coPaykpART pkzB+PHj8eWXX2qtmCs+Ph5mZmYICAjo0OdLSkpauj1rC4lEgpkzZ0IoFGLnzp3tFm5QKpXI z8+Hq6urVkUfCgsLUVZW1qZUodaora1FVVUVfH19tRay5jgOd+7cgY2NDXx8fDp0jfz8fFhY WGhV+KGxsRE3btzA0KFDYWlp2e7PS6VSfPzxx+A4Drt27XpqIXNnyM7ORmVlJYYMGdLhOZdI JFrt6q1Wq7F27VqcO3cOR48ebff/IoQgPz8f1tbWsLGx0ZqdIpEISUlJHe4eLpfLUVhYiJ49 e7aqQKYpMjIyUFNTg2HDhnXo81VVVVAqle0+SNElHMdh48aNOHnyJA4dOgR3d3dIJBLcvHkT gwYN0oswwZPeDSUlJfD09KQ6Dbu4uBgcxz0xpe1FpampqaUPlq7SyZ8HDHS5kPft2wc+n4+Z M2dS63yIRCIsWrQI165do3ri4uPjsWDBAqpPswkh2LZtG3bs2AGVStWha7i4uGD27Nk4fvw4 UlNTtWJnZWUlli9f3qlTYhcXF607gufPn0d6ejrmzZvXIQfCyMgIPj4+WnU+1Go1Nm/ejLCw MHAc16Fr2Nraws/PT6v5skVFRfjss8+QmJjY4Wt4eHhoXXUuKioKq1ev7rAktZmZGT799FPc u3cP58+f19rL9dtvv0VERESHIxi2trZadT4AIDU1FREREZg7d26H/hePx0PPnj216nwAwJEj R7BmzRpIJJIOfd7U1BS+vr5adT6kUilWrlyJ6OjoDs+5vb091c4HABgYGODdd9+FgYEB9u7d C0IIYmJisGLFCtTW1lJjp1AohK+vL9XOBwC4urp2OecDeChB7+3tzZyP/0FnRejp6elYvXo1 PvnkE7zyyivUDohCoYBCoUBoaCjVhec1NTVwdXXFmDFjqH7oVFdXY/z48Z2SXfT09MSVK1eQ l5eHsWPHajwKIpfLIRAIMH78+E5LKRJCQAjR+Oa5pqYGy5Ytw4gRIzTiwDc7B5q2kxCCqqoq jBs3rtMbSm0WLcpkMggEAoSGhnY6FZTjOK3MOfAwMhASEoIBAwZ0eBycnJxQUFCAU6dOYeLE iRp3QDmOg1gsxoQJEzrd5V5bxckKhQLr1q0Dn8/H8uXLOy1NrK31AzyUUR40aBD69+/f6etr a/2oVCpIJBK88cYbbS481/UzU1NYWFiAz+dj9+7dGDNmDAwNDeHv79/haJ+2eR4KvWkXIdAm HMexYvS/3QhaR6VSkUWLFpHXX3+d1NbWssobRrs5ffo08fX1JVevXqXazuTkZLJx40ZSV1en 0euGhYWRwMBAcv/+/U5fi+M4EhERQY4dO0a1bGZtbS35+uuvSVpaGtVzfvPmTbJhwwbS2NhI ddF83759qZeXrqioIBs3biS5ubkan6NevXqR6OhojVwvNjaWbNmyhYoO6U977/70008kJiaG 6jnPz88na9asoVrQoba2lrz22mtk4cKFVBf3y2QysnXrVuo7cGdlZZGvv/6aekEHbQkGnD9/ nm3qdFWEnpaWhgsXLuCjjz7Sevia8WIyZswY9O/fH7t370ZTUxO1dvL5fBw/fhz379/XaBRp //79mDx5skYaYvJ4PFRUVODo0aNUd2k1NDREcnIybty4QfW9yePxcOrUKeTn51Nro4+PD6ZO nYr9+/ejsrKSWjuNjY1x/fp1jc65QqHA3r17ERgYqLHou0wmw4kTJ1BeXk71fVlYWIjIyMgO p0Pq6pl58eJFqtOebWxsMHv2bJw/fx4pKSlUPzNzcnJw+vRpqkU8mlPZ7t2716X2MTweD+Xl 5di7dy/VHexfmAiISqUin3/+OfnHP/5BtZSdSCQi9+7do/p0gxBCCgoKSGFhIdU2KpVKkpaW Rurr6zV63YsXLxI/Pz+NRUFqa2vJvXv3NCpdqFKpSEpKika/e3P0IyMjQ2PXrK+vJ+np6RqT BZTL5SQ5OVnjUYCCggKNnoxWV1eTrKwsjc558/3e0NCgsWvm5ORovPlcdnY26devH/ntt980 dtqalJREpFKpRu3Mzc1tt8R0W6IfZ8+e1dg15XI5SU9P15iUvFqtJhkZGaS6ulqjY1ldXU0y MzM1FumUSqUkPT1do1LeHMeRBw8ekNLSUqrfa4mJiaRfv35kwYIFVO8TysrKqG+MqK37/Xmg pqaGpKamvjBNO6mOgGRmZiImJgbvv/9+h1RcdMXhw4fx5ZdfQiaTUWujRCLBsmXLcOrUKaqd 2qSkJMyZM0fjJ8IvvfQSgoKCEB4erpHTg7CwMHz77bcaPYkwNDREnz59NKaOUlNTgwMHDmDy 5Mnw9vbWmJ1WVlbo3bu3xuqHbt68iU8++UTjJ8Jubm5wcXHRyLU4jsOWLVuwdetWjZ4O8vl8 +Pv7w8LCQiPXKy8vx9y5czV+Iuzp6YlJkybhv//9r0bkIGNjY/H5559rvBi3Z8+eGitOViqV +P333xEYGIiXX35ZYzaamJigd+/eGpOSLyoqwrx58zolitAa3bp1g4+Pj8Zyzk+ePInFixd3 WBThSafCfn5+na4f0ia1tbVYtWoVXFxc8OeffyIzM5NaW52cnDpVc6kLDAwM4Ovrq3URDxqx tbVFQEAAqwOBllWwCCGIiIiAra0txo4dS/1NMW3aNKp7k6jVagQGBmLEiBHU31hjx47V+ENQ IBBgxowZuH37NtLT0zt9PTMzM0yZMgUmJibUjmNMTAwqKysxffp0qgv2jI2NMWXKFI05C9p6 Htnb22Ps2LFUCzeo1WoMGDAAgwYN0uh1eTwepk6disrKSly6dEkjzvbbb7/d6SJkbZKamoqr V6+2yFfTzMsvv4zAwECqbTQ2NsaECRO6XCq1UqnE4MGDsWrVKtjb2+O///0v1WltDMbzgFb7 gBQUFGDy5Mn45JNP8NFHH1E9EM3KEbR7pSqVinqpveYHszY2zCKRCP/617/Qv39/rFmzplP/ Q5tjqVKpcObMGfj5+aF3794duoZEIsG//vUv9OzZExs3btSKrRUVFbh8+TJCQ0M7FaHU5pwD wI0bN9DY2IjXXnutU2tUm3OuVCpx4sQJhISEdMr5Jv+/Qow2et5wHIclS5agoKAA+/fv79SB S7Oai7aemdeuXQPHcR2u2+A4DitWrEBSUhIiIiK00rNBJpMhMjISI0aM6JS8qDbnHHiYiZCU lIRJkyZ1SgpUrVaDx+NpbZ1fuHAB3bp1Q0hICHWHF83zs3v3bvz666+IjIyEh4cHte/h9PR0 ZGRkYOLEidTuGQghOHXqFNzc3NC/f/8utfnOy8tDQkICJkyYoFVpfJrR6pHq2bNnYWRkhNdf f536gTA0NHwuQmK0Ox/Nm1BtvaCsrKzw1ltv4fz58ygqKqJ2LDmOw+nTp7Fnz54On5Tdvn0b GRkZmD59utZsra+vx4YNG5CQkEDtnANAYmIifvjhh053d9bmnKtUKhw5cgTh4eGdOxXi8bS2 ETUwMMDUqVNx//79Tndx1/aBTXx8PNavX9/h7s4lJSW4fPkypk6dqrWGcSqVCvv27cPJkyep nXPgYdO/TZs2ISsrq9PvSW2u89jYWPz0009QKBRUvdP+Pj8TJkyAsbGx1vrqaIrCwkJ8++23 KC4uptZGjuMQExODsLAwqovmtbUmv/32W6SlpaGrorU+ICKRCGvWrMGrr76K0NBQajf3crkc TU1N1DeIEYvFWn9JdRa1Wg2xWAwTExOtzrejoyOOHTsGa2trBAcHt/vzEokECoVCq3NuaGgI d3d32Nvbd0i5Sq1W46effoKVlRX+85//aG3jbGVlBScnJ/j6+sLW1rbdn1cqlZBKpTA2Ntbq nLu6usLJyQm9evXqUIM1qVQKlUql1eZsRkZG8PT0hKurK9zd3dv9eUIIGhoaYGRkpNVNnp2d Ha5du4a8vDyMHz++3f+rqakJjY2Nne6l8Sx69OgBBwcH+Pv7d+i5FxERgYSEBCxfvlxr9Ycm JiZwd3eHu7s7XF1dO7QBE4vF4PP5Wp3zbt26oUePHvD29u5Qr6OmpiZIpVKtp6t6enrC0dER Pj4+VKScEkJQV1f3yJo0NzdHQUEBLl68iDfffFPr66CjODg4wMnJCb1796b2hN3AwABubm5w cHCAt7d3l6qLsLW1haurK3x8fLR2QEI92qpuP3fuHPHz8yMJCQnUVuCrVCry7bffkp07d1Kt FFBUVERmzZpF4uLiqLYzOjqazJ07V+v9EDiOI8uXLyfjxo1rt9pUU1MTWbp0KfVznpmZSYKC gsiRI0eotjMiIoIsW7ZMo6o4mkYikZDFixeTiIgIqscyNTWVzJgxgxQUFGj9fx07doz079+f ZGVltXvt7dy5kyxdupRqJaCGhgYSGhpKVq5cqVHFM00THx9P3n//faoVoNRqNdm6dStZs2YN 1WOpDR48eEDeeecdkp2d/cjPk5KSiL+/v8b6yjAYTAVLg2Hpo0ePYsCAAQgICKDW+ZLL5UhP T6e6iBJ4mEpQXV0NBwcHqu1MS0uDlZWV1k/JeDweJk2ahMLCwnarxkgkEhQUFFCtuAIAf/zx B8zNzTXWt0Bbp4OJiYng8/lUpwaKRCJkZmZSXSAPAPn5+eA4rkMn1O3l5ZdfhomJSbvTSNRq NbKzs+Hk5ES1KMLdu3eRk5ODiRMnUm1nRkYGAGhMQU1b7/MHDx5QP+faoLCwEDweD9bW1o/8 vHfv3ggJCcHp06ehUqnAYDA6sJfTRhF6Tk4O3nzzTXz11VeYOnUq1Ruo8vJydOvWjeoULLlc DpFIBAcHB6pDlLW1teDz+TqRW5bJZJg1axbc3Nzw/ffftzlFQ61Wo6qqCt26ddNqOs7fKSoq gkAgaLOj29DQgGnTpmHQoEH46quvdDLnSqUSeXl5cHd3b5cDWVVVBVNTU51toOrq6iCVStvl TKhUKlRXV8Pe3l5nKYwlJSUwNzdvV2i9sbERCoWiQ6lwHXn2rV69Grdv38bRo0fbNX9VVVUQ CoU6UwysqqqCXC5Hjx492rzGlyxZgvz8fISHh+vETkII8vLyYGdn167nn0gkglqt1smcNz83 y8vL0aNHjzYfGhBCUFVVBUtLS52lG1VWVkKtVuv9oEgikUAqlcLe3v6x3x07dgxr165FZGQk 1bK3YrEYFRUV8PT0pNqBLCsrA5/Pb3WsX2TkcjmKi4vh4eHxXNT4ahKt3I1XrlyBubk59XKx PB4P3bt3p77+w9TUFI6OjtTnR9ra2uqs14tAIMDrr7+O2NhYlJWVtflzhoaGcHJy0pnzQQjB jh078P3337e5yO7evXvIzc3Vae1UTU0NZs+ejatXr7brc/b29jo9vf3zzz8xe/ZsVFdXt/kz fD4fTk5OOnM+mvuN/Prrr2jP+Y65ubnONqI8Hg+hoaEoKSlpdzdie3t7ncqVnz17FgsWLIBY LG7T35eXl+PGjRuYOHGizuxUqVT46quvsGfPnnZ9zsrKSmdzDjyMss2ePbtdMuY8Hg8ODg46 rXU4deoUFi9erPe+XEKh8Ikb4uHDh8PU1BRXrlyh+r18//59fPjhh8jNzaXazj179mDVqlVd rkN4aWkp5syZg7t376KroXEHpKmpCWfPnsUrr7wCR0dHMBja4uWXX4ZcLsft27epdnIHDBgA Y2PjNqlhEUJw4cIF+Pj4wN/fX2d22tjYYMyYMdSnE/Tp0wfu7u5UNww1MDBASEgI1Go1iPZU zjtNQEAAPDw8cO7cOart7NOnD9zc3NDU1NSmv799+zaUSqVGGw+2xckdO3Ys1eMIAM7Ozujb t2+bnTl9ERgYCDMzM+rUsP6Oo6Mjhg4ditOnT0Mul1Nrp4eHBwYOHEi1jQAwYsQIWFhYdDkH pFloo6Nqf88zGk/BSktLw7vvvovNmzdj1KhR1H7xK1euwMDAQKcvqfYik8kQHR2NAQMGoGfP ntTaWVBQgLt37+If//iHTqNJSqUSn3zyCTiOw/bt258a1SCE4OLFi7CwsMCwYcN0Oj5qtRpN TU1tOo2tqanBpEmTMHnyZHz22Wc6tbOpqQk8Hq9Nc/jgwQNkZGQgNDRU52FjmUwGExOTZ6YT cByHixcvwtbWVuNN/TQ553V1dTh37hzGjx+v09NwAPj5559x/PhxREZGPrMrcWJiInJzc/HW W2/pNBpLCEFTU1Ob1PXUajXmzZsHlUqF7du36/TeVKvVUKvVbVo/VVVViImJwfjx4x+rL9DF Ojc0NGzT2CQkJKC8vByvv/66zudcKpXCzMxML5F/kUiE48ePY+LEiU9NCbp06RIWLlyIw4cP U13vKpPJYGxsTLWKJsdxaGpqgqmpaZfrEi6Xy2FoaKizzAxa0HgE5Nq1a7CyskK/fv2onuyN Gzfi1q1bVE/OgwcP8M0336CiooJqO0+ePImDBw/qXMfbyMgI48aNQ2JiIkpLS5/6txKJBL/8 8otewpyGhoZtTgVJSUlBVVUVxowZo3M7TUxM2uxAhoeH48SJE3rpBiwQCNqUyywSifDjjz/i /v37VM95YmIiNm3a1OkeJx3hlVdeQU1NDVJSUp65Ofj9998RHR2t83XO4/HavCkpKyvD3bt3 MX78eJ07xoaGhm1ePzExMdiyZQukUqle1nlbxkalUuG3337DxYsXdR7Z4fF4EAqFetuIJiUl YcuWLairq3vq34WEhMDGxgaxsbFUv6MFAgHVzgfwMHIsEAi6nPMBPEyz72rOB6DhPiByuRwb NmzAwIEDdX5i0t7TFaFQiNGjR8PGxobaySGEoGfPnhgxYgT1N+eQIUP0UohnZmaGgwcPwtfX 95kpS5aWlhg1apTeNLcJIU9dE4QQ7Nq1CyqVCv/5z3/0NufPsrN5czJ06FC9Reaau3A/63tY Wlpi9OjROlGW6uhYchyH3r17Izg4WOebBEtLS1y+fBkSiQSjR49+6t/y+XwMGzasUx2/tT2W ly5dws2bN/Hpp5/qPLLQ3nuzf//+CAoK0kthcFvGEgCMjY0xevRovSkwttVObThAnp6eGDx4 8FOdNVNTU2RkZCAuLg6TJk2iuoi42YmkfYPflvXzIqKve/2FcUCys7Oxe/dufPTRR/D29qb3 Sxsaonfv3lQ7H8BDacaAgADqnQ9XV9c2K9RoGqFQiNu3b6O4uBivv/76E1/mhoaG8PPz05vz oVQqsWfPHhBC4Ozs3OrfiEQibN68GWPGjMHIkSP1Ymd+fj527doFf3//pzav8vb21ttGFHhY pJqYmIjAwMAnPrSNjIzg7++vN+dDLpfjt99+g7m5+VPTOGxtbdGrVy+9nFAaGRmhrKwMly9f xqRJk55YaNy8IetIsz1NceLECaSlpT3xoEGtVmPnzp2wsrLCjBkz9LKxF4vF2LJlCxwdHZ+a 0qbvZnvJyck4duwY+vTp88T3C4/Hg7e3t15VicLDw1FaWgofHx+d/l9ra2sEBAQ806Hg8XhQ q9U4cuQIxo0b98w0Rn1y69YtnDlzBv369aM2GsJxHHbu3Am5XN6hZq7PM+np6Thw4AD69u1L vTCSptDo0y8+Ph58Ph9BQUFgMHS1gRo1ahQSEhJQWVlJ9elG8wvgSWRlZaG0tFSvvT9kMhkO Hz6MzMxMquc9Pz8fEREReklhac/L9OLFi7h48SLVY/nSSy+hoqKipScFreTk5CAiIuKJhck1 NTW4c+cORo4cqbeT6OZas+vXr1M9lvX19YiIiKA+vffBgwc4evSoXlI920pQUBDMzMwQFxdH 9VjW1tYiPDwcNTU1VL8n7969i+joaOoFHTRNQ0MDDh8+jMLCwi7znTUWAVGr1fjxxx/Ro0cP vPPOO9SGkpRKJerr66nPNWxsbGwpvKT5YVFbWwsjIyO9nqiYmJjgv//9LwYOHNhqSpBCoUBD Q4Nei9uaIzB+fn5PVIeLiopCSUkJ5syZo1PJy79jbW2N3r17w8/PD0KhsNVNdXV1dZuKwLWJ h4cHevXqBQ8Pj1btkMvlEIvFT43i6MI57tWrF3r37v3EHjBisRgcx+k1ymlmZobIyEhYW1tj 8ODBrc55fX09jI2N9T7ngYGB6NGjR6vrOC4uDidOnMD8+fP1psBoYmLSMudPEhRorivQ55zb 29ujd+/e8Pb2bvW0Va1WQyQStanwX5v4+voiICAAzs7OOrOjsbERSqWyzafQQqEQ8fHxKCoq emoUXt90794dvXr1gpeXF7VZFQYGBujVqxf8/Pyobxasaezs7BAUFAQvLy+9vf91Pt+aulB1 dTUyMjIwYsQIqpvdXL16FYsWLYJEIqHWRrVajXXr1uHQoUNU3zzFxcVYsGCB3k9O3d3d4enp iRs3brT6+/Pnz+Prr79us4yntujVqxf69OnT6u8UCgWuX7+OoKAgnfVSedKmeeTIkU9Mu8jN zcXcuXORl5en17F0cnLCiBEjnnjSffToUaxfv17vMp79+/dHr169Wv2dVCrFl19+iXPnzunV RmtrawwdOhSxsbGtSmDev38f8+fPR0lJiV7tdHFxwZAhQ574frlx4wY8PDzg5eWlVzsHDx78 RBvEYjEWLFiAmzdv6tVGoVCIV1555Ynpibdv38bixYtRW1urVzt79OiBAQMG6Mz5kMvl+Oab bxAZGdmuTfOIESOQkJCg9/F6GhYWFhg9erROe/h01OmkWcRIWwgEAgwbNkxvaeLPtQPy4MED yGQyBAcHU/2FKyoqYG5uTnWOnVKpRFVVlU4bvHXU6RSLxXq3UygUIjAwEImJia32hygqKoKF hQXVBYKVlZXIzc196gaLBmpra6FQKPRWV9FW8vPzYW5uTvWcS6VSVFVV6a3Atxkej4dhw4ah qKioVTW55g7FNM+5XC5HSkoKBg4cSPUGq7GxEQ0NDXo9ZGgLpaWlUKvVVEfgtYFMJkNFRQWc nJza9bl+/fpBqVTqRXGPwXhe0VgfkJ9//hmnTp1CVFQU1S8qsVgMtVqtN4WU9mxILS0tqQ7F NTU1QSQSwd7eXu/pbOfOncOyZctw4sSJx9KwGhoaQAih4mRBKpWioaHhsc72f/zxBxYsWICo qCgqBBwqKythYmLy2JjJ5XKIRCI4ODjofc7VajXKysrg6Oj4WEpBc2ogDU58Y2MjZDIZ7Ozs HhkztVqN2tpa2NjY6N1Rys7OxuTJk7Fp0ya89tprj23KpFIpFQW2KpUK5eXlcHJyemTMcnNz MWnSJGzYsAHjx4/Xu5319fVQKpWPRRLVajWqqqpgZ2en9zknhLS8Z/43VbGxsREKhULnfWla Q6FQoKamBo6Ojlo/nOE4DjU1NbC2tm5XmlJjYyPeeOMNTJw4EQsXLqT2nU0IQVlZGWxtbane W8jlctTX18PBwYHqAzlt0HxI3loK9IuGRmZWpVLhr7/+wqBBg6gfNAsLC+qdD+Bhd0za8wBN TEyo2IgCD8O2hBA8ePDgsd9ZWlpSE9aMi4vD/PnzHysEvHPnDnr27ElF3ishBNu2bcPWrVsf KwQ0NTV9zHnSF1VVVZg7dy4SEhIe+52trS01EcSYmBh88cUXj3WfNjQ0hL29PRVRmu7du8PN za3VsRQIBNSo+5SUlODjjz/GvXv3Hvl5RkYGBAIB/Pz8qLDz9OnT+OKLLx6LyBoaGj7mPOkL pVKJpUuX4vjx44/9ztzcnArnA3iYAjh79mzk5+drf0NkYAB7e/t210gIhUL0798fd+7cgUql ovadLZVKsWTJEpw9e5bqvUVKSgpmz56NsrKyLuV8KJVKfPXVVzh8+HCX+L4acUBqamqQl5eH Pn36dEn9Zob+cXZ2hpeXF27fvk29Y2loaPiIepNCoUBSUhICAgKoSB/h8XhwcnKCTCajWn1G KBTC2dmZaiUs4KFMtbGxsd7rUZ6GmZkZ+vXrh/j4+FbrQGjBwsIC3bp1e6yG7+7du3BycqKm cLVHjx4wMjKieiz5fD58fHyoXz9OTk5wcnJCY2MjtTbyeDwMHDgQmZmZVNeBmJiYUD+WANCt WzeYm5tTf29qY00GBARQPz8aWzeaSMG6fv065s6di4MHDz6xyJYGkpOTW1RKaEWhUCA+Ph4B AQFUR2pKS0tRWFiIQYMGUREiJYRg2bJlKCoqQlhYGExMTEAIQUJCAqysrKjpS8NxHBoaGmBh YdGiHFZWVoYpU6bg008/xTvvvEOFnXK5HE1NTY9EjgoKClBVVaXTotBnIRKJYGpq2pKrrlar kZCQAEdHR732KfnfOW+ulWpeKyKRCAkJCVRFjQ8cOIBffvkFJ06caMmBz8jIgEgkwqBBg6h5 9ohEIggEgpY6PoVCgZkzZ8LT0xPr1q2j4t5Uq9UQi8WwsrJqsae+vh6pqakYOHAgNbUVUqm0 pTFvM1lZWZDJZOjbty9Vc25mZqZV9SaxWIxbt25hyJAhHYqepqSkYObMmdi+fTuGDh1K7btb IpGAx+NRXStFCEF9fT0sLS2p7+CuaWQyGdRqNfV1lppAIzvHrKwsCIVCvTWjawtNTU345ptv ntqHgQbu37+PhQsXoqioiGo7jxw5gs2bN1Nzqvv3E6jm9CaZTIZ169bh0qVL9Cw4AwNYW1s/ 8lAtLCxEQ0MDAgICqLHT1NT0sbS1ffv2YefOnVSlGFhZWT2ymWtoaMCXX35JVSTMwMAAVlZW jzjqKSkpWLFiBaqrq6mxMzg4GFKpFLm5uS2bgN27d+O3336jSpPfysrqERGRmpoaZGRkUOUY Gxoawtra+hF7Ll68iJUrVz6WiqdPzMzMHnE+1Go1Nm3ahIiICKreN1ZWVlqXjk1JScGiRYs6 3E+qR48eEAqF1BeiC4VC6pWweDwebGxsupzzATxMee0KzgcAaCQRNTk5GQEBAVQrexgYGGD0 6NFUneQ96UE7Y8YMqp05APD09ISTkxNVamLe3t6QSCQoLi6Gs7MzDAwM8NJLL2HYsGFUj2Vm Zibs7e2p1z0PCAhAcHAw1cpSfD4f48ePR//+/akeSzs7O8yaNUvvClh/x8nJCUKhELm5uS1r JigoCBYWFlSn1paUlIDjOL3L7z4Ld3d3vPfee1TLbDYf5Pj6+na5jZ+trS2mTZvWbgWsZiwt LeHu7o7U1FQQQlg6OoPxrOdNZ1OwpFIp3nzzTYwfPx6ff/451V+WPRQ0O5bNLyxaqK6uxpQp U/Dhhx9i5syZAB6mv9CmotHQ0IArV65g1KhRsLCwwGeffYbGxkb8+uuvVG3uMzMzUVlZiWHD hsHAwIDKseQ4DtevX4ebmxs8PDyoXed1dXW4efMmRo0a1XL6SNt4qlQq/Pvf/4ZQKMTWrVvB 4/GoHEuVSoXLly/D398frq6uCAsLw759+xAZGfnEho/6oLKyEomJiRg5ciTVcrbJyckghFDd e6GpqQl//vkngoODtea0E0JACOnUmvz5559x5swZnDx5Uq9NUJ/FrVu3YG5ujsDAQGptlMvl uHr1KkJCQqgRRNDlmlQqlQgJCXmhv2en3351dXUQi8Xw8fGh39tizodGx5K28bSysoKLiwvS 0tJaHCQaJfwqKiqwYsUKpKamQqFQID8/H927d6cusnD58mVs3LixpRCQxrFUqVTYs2fPI6oh NK7zsrIyrFy5EpmZmf/v4UvZeDYXJRcUFLQ07aRxLBUKBTZt2tSSWpmXlwcnJyfqIgv5+flY vXq1TtSbOkN0dDQ2bNgAtVpNrY1SqRTr16/Hn3/+qdV3WmfXpJubG6qrq6kuRAeAgwcPYt++ fVSlVv4vIpEI33//Pf76668ut786d+4cNmzYQLVwiUbeOZp4yMrl8ufCAXkeeF6iNDTaaWRk BFdXV5SWlkKpVFLbbNLFxQUffPABHBwcUFdXh/LycsyYMYM6O5tPbpsdI1rn/O233245YaZ1 /bi4uODjjz+mRs72SXh4eCA6OrqluJ9GTE1N8dFHH6FHjx5QqVTIz8+Hr6+v1msE2ou3tzfe fffdFseI1ntz7NixcHNza4l40eh4Wlpa4oMPPoCnpyfV68fb2xs8Hg/FxcVwcXGh1s6pU6dS 7yRZW1tj5syZ1IiJ6HpNdokeKKSTHD58mAwcOJBUVVURWlGpVGT//v0kNjaW0ExZWRn57rvv SGVlJdV2xsbGkt9//52o1WrqbDt48CAZNGgQKSkpIWFhYeTGjRtUjiHHcYQQQhITE4m/vz+5 e/cu1XZGR0dTO+fNyGQysnXrVpKSkkL1+snOziYbN24k9fX11NmWkJBA+vbtSxISEkh0dDQ5 evQo1WNZW1tLhgwZQg4dOkS1nSkpKeSnn34iMpmMWhs5jiNHjhwhFy9eJF2NgoICsmnTJlJb W9up61RVVZEhQ4aQgwcPEgaD8XQ67V4VFRXBwcGB6gJ0uVyOQ4cOIT09nWpnMDs7G0eOHKFe A/r8+fP466+/qAzfuru7QyaTobi4GCdPnkRhYSGVY9h8wlheXg4+n/9Yx2Ta7Lxw4QLi4uKo vi/r6+sRERFBffOq5ORkXLhwgcoeEc2nbkVFRTh//jxu3bpF9VjW1NRAIpHA2dmZajv/+usv nDt3juomdSqVCocPH6ZexUkb3L9/H0ePHm1JPewozY2OS0pKwGAwnk6nUrAIIUhKSkKvXr2o C3//HVNTUyxfvpx6lZRevXph06ZNcHV1pdrO6dOng8fjUSmRZ2dnB47jIJVKsXjxYmo6Iz9p /WRlZcHNzQ02NjbU2ggAM2fOhEAgoDYkTAiBlZUV1q1bR1X/gv+F4zgMGjQIzs7OVM65lZUV bGxsUFxcjA8++ICabvJPmvPS0lIIBAKq010IIRgzZgyCgoKo6fnS2n1paGiIRYsWUf3+0ZZw Q9++ffHDDz90+iCouc9YVlYW9enUz0u6N43iJ7r63jTW2lLjgMjlclRWViI4OJjqQTI0NMTL L79M/WTY2dlh5MiR1NtJc7NJOzs7ODo6oqioCO+99x61dhYWFuLIkSNITk6Gk5MTtfn2Z86c QUNDA5U1Ks3IZDL8+uuvGDt2LF555RVq7czKysLJkycxe/Zsajd5pqam8PLyQlpaGubOnUvt WEokEuzatQsVFRUQCoXUOvBJSUmIjY3F7NmzqT4AO378OIRCISZMmECtjfX19di2bRumT5+u 8bHs3r27xmTQvby8EBkZiaamJmqf6xzHYe/evfD09MSoUaOonfPS0lLs378fH3zwQYflkZ9X jh07BkII/vnPf76w37FTbqVUKoVEIqE2fYTR9WjejOTk5FBtp0gkwoEDB5CRkQE7Oztqe2uk pqbi/PnzVKtxqFQqXL9+nfrUkfr6ekRGRqKqqopaG/l8Prp3746amhqqVZGamppw/PhxXLt2 DdbW1tRGFoqLi3Hs2DHU1dVRO5bNmQx//PEH1etHLpcjOjoaDx48oNpOBwcHyGQyqlOpeTwe /vzzT+oVpmQyGS5duoTi4uIut5e5d+8ezp49S7VSWaffN519oXIcB3d3d+pvYpVKRXU6AfCw P4RAIKA6nU2tVkMikVDbnMzY2Bg2NjaoqKiAWCymds69vLywdu1abN68meqTnRkzZqC4uBhS qRRGRkZUzrm5uTlWrlwJMzMzyGQyavX3/f398d1330EgEECpVFK7zm1tbVFdXY3Kykpqm2Na W1vju+++w/bt22FgYEBtn40RI0bA0tKS2j46zZvRWbNmQSwWo7GxkdouzHZ2dti4cSO8vb01 7oCJRCKYm5tr5CDI3t4eSqUSYrGYqr40/zvnS5cupXqvATzsLv/NN99Qr36mDWbNmoWGhoYX +jt26mlYUVEBiURCVTff1jh69Ci2b98OjuOotVEikeDLL79EbGws1WOZkpKCRYsWoaamhs4b 2sAAtra2iIyMxO7du6k9PTAzM8PgwYOhUCiofri6ubmB4zisXr0aEomE2pdpcHAwTp48id9/ /53asRQKhejduzdWrlyJrKwsau10dnZGSkoKvvvuu04X5WpznQ8dOhTGxsZwd3enNgXYysoK Xl5eWLJkCXJzc6mdc19fX5SUlGDt2rVUiiMAD6Nzw4cPh6Ojo0avW1NTg4ULF2osgtrc06my spLqd3mfPn3Qq1cvqm00NjbG8OHDu1wjQuChpDPt5Q16dUDq6urA5/Opjyzk5ORAIpFQPZFN TU2oqKig/marqalBaWkplQXof3+ZNjY2Uh+6rKurQ319PfW9IZqbjdJ8b6pUKpSWllKvINfY 2Ijy8nKqbWx2Ouvr66m2UyaTIScnh/oIvEgkojrtrpmioiLU1tZ2uYJfqVSK6upqjaUcWlpa QqlUUr/OGQy9Hyp05sMNDQ0wNjaGmZkZ1V9y7ty51Cs+WFtb4/vvv9f46Y6mGTx4MLZt2wZr a2tqbezWrRs8PDwwadIkque8eYNHuwPft29fBAQEUL3OCSH48MMPqW9aZWVlhQ0bNmg8jUST WFhYwM7ODtOmTaM2tQl4GDVubGyk/nTU0dERGzZsQM+ePam1keM4vPbaa5g0aRLVh0tyuRwq lUqjaWLdu3fHzz//rDEpZzMzM5iZmUEsFlN9X3IcB5FIBCsrK6qdTqlUCrVaTf17UhvzI5FI YGZmRvWa7AyduusaGhrA5/OpVXr4+wuAdgUFAwMDeHh4UJu//vfNiYeHB9UbewsLC/D5fGoL u5uJjY2FWCymtoAWeHh6+80331AfnUtISMCuXbuoflATQhAWFoY//viD6txroVAIgUBA9X0J AHfv3kVRUVFLp3Fa53zv3r24d+8e1fdmRUUF1q1bR/2mOSYmBmvXrtVoaqCRkRF69uypMWfb 2NgYxsbG1I9ldnY2FixYQH2Bd1RUFNasWUO1KIY2qK6uxuLFi1/ovjydckBEIhHs7OxeWO+M 8XzSXCBPs3IT8PBkhxBCtdPJ4/Egl8upVvEBHooj5OXlUVun0oxCoUBZWRnV6YEmJibg8XgQ iUTUrx+lUkn9AVhDQwO1NXN/d5Sqq6shlUqpXz8lJSVU13OamJjAxMQEMpmM7s2fgQEaGhqo n3OlUomioqIu54DweDyUlZVR/07rDPzO3hgeHh7UKynk5ubC2dmZ6heVTCZDWVkZ9WoPZWVl MDIyolbdA3jYy0CpVFL/YPXz84OrqyvVqU2Wlpb4v//7P+o7TQcHB+Pzzz+nup6Gx+NhxowZ qK6upjqaZGlpCT6fT20xcjMBAQFwcXGhOjWDx+Nh2rRp1I+ls7MzPvvsM+rraV5//XUMGzZM o4c2UqkUtbW1GuvNY2hoCBMTE+odeG9vb/z888/UNz6eOnUqxo0bB2Nj4y7lgNjb22P79u0v dAF+pxyQBw8eIDc3Fxs2bKD2hSqVShEdHY2QkBCqc3Bzc3ORnJyM0NBQqhfaxYsXYW1tjUGD BlFrY1VVFaqqqvDrr79S3fwrOTkZEokE27Zto3bOCSG4cuUKbG1tERQURO1YisViREdH49VX X6XaCcnIyEB+fj7Gjh1LbeS4qakJJSUlCA8Pp7qfTnFxMSoqKrB3716qHeQ7d+6goqICoaGh 1NqoVCoRFRWFfv36wcfHh2qHjsfjaTQCkpWVhezsbLz66qsaS9utrKzE1atX8cMPP1A/loQQ qiOy2pjz5wEejwdTU1P885//pD7K2+HvSDpx5y1atAibNm0Cg8FgMBgMBoPB0AxGRkaIi4tD v379Xsjv1yl3f/bs2RAKhVCpVOxOYTAYDAaDwWAwNICpqSn1AkqdoVMREAaDwWAwGAwGg8Fo DwZsCBgMBoPBYDAYDAZzQBgMBoPBYDAYDAZzQBgMhmaoq6vrkvrmDLoRi8XIy8ujvncFg8Fg MJgDwmAw2smOHTvwxhtvsI0egypOnTqFoUOHUi0hymAwGAzmgDAYjA4gFotRWVnZ5fTNGXQj lUpRUVFBfSM1BoPBYDAHhMFgtJPmBku0NqRjdE2a70eau7UzGAwG4/mGz4aAwdAfKpUKDx48 QHV1NRsMBhWUlJSwQWAwGAwGc0AYjBcRAwMDVFZWIjQ0lJ02M6hBoVCwQWAwGAwGc0AYjBd2 AfL5cHFxAZ/PliKDDurq6lgUhMFgMBjMAWEwXkQ4joOdnR1OnToFR0dHNiAMKti/fz/+7//+ jw0Eg8FgMJgDwmC8iBgYGMDS0hKWlpZsMBhUIBAI2CAwGAwGQ7v7HzYEDIZ+4DgOarUahBA2 GAxqaL4fmTw0g8FgMJgDwmC8YLi5uWHAgAEwMjJig6ElmIPXfhwcHDBw4ED07NmTDQaDwWAw tAKPsLczg6EXlEolVCoVTE1Nu4QKVklJCYqKimBtbQ0vL6/HHK/GxkZkZ2dDpVLBy8sLNjY2 z7ymVCpFbm4uAgMDH/sdIQSxsbEIDAyEnZ0dgP8ne2xlZYUePXq0/K1EIkFaWho8PDzg4ODQ pe9LlUoFhUIBPp8PY2NjtlAZDAaDoXFYBITB0BNGRkYQCAQvvPOhVCqxb98+hIaGYtSoUXjt tdcwb948lJWVtfxNWloa3n//fYwZMwajR4/GpEmTcP78+WdGL/Lz87Fv3z5IpdLHfldcXIxt 27ahqqqq5Wfl5eWYPn06Dh069MjfJiUlITQ0FFeuXOny9yWfz4eZmRlzPhgMBoPBHBAGg/F8 cvv2baxatQqDBw9GeHg45syZgxMnTmDnzp0ghKCxsRErV65EXl4eNm7ciF9++QUAsGLFCpSW lj712nfv3sWZM2dQVFT0yM85jkNYWBhu3LgBuVze8vOqqipUVFTA2dn5kb+vqqqCQCCAm5sb mzAGg8FgMLQMU8FiMBhaJSYmBpaWlli9ejW6d+8OjuNw7949XL58GStWrEBubi7i4+Oxbt06 zJw5EwBgbW2NWbNmITs7Gy4uLq1eV6lUIjY2Fjk5OYiPj4efn1/L75KTk7F37140NTU90liv pqYGQqEQXl5ej1yrpqYGAoEA3bp1YxPGYDAYDAZzQBgMxvMKIQQhISHw8/ODvb09gIeF4QBg Y2MDAwMDWFhYYOnSpRg1alTL59RqNYRCIczMzJ547ZKSEsTHx8Pe3h6XL1/GtGnTwOfzIZfL sW/fPhgYGIDP56OhoaHlM7W1tVAoFEhJSYFEImn5eWxsLPh8PiwsLCCXyx/7PSEE3bt3h5+f HwwMWOCYwWAwGAzmgDAYDCrh8XgIDQ19ZCMfGRmJGzduYNOmTTA0NETPnj0xb968lr8pLCzE Tz/9hFdeeQX+/v5PvHZcXBzkcjnmzZuHCxcuoLy8HK6uroiJiUFOTg7mzJmDjRs3PuKA5OTk QKFQIDIyEoaGhi02JSUlwcvLC1ZWVsjLy8M///lPlJWVgcfjQaVSwd7eHjt27ICvry+bVAaD wWAwmAPCYDCeFy5fvoy1a9fi448/xsSJEx/7fVVVFZYtWwYjIyN8/fXXEAqFrV5HrVYjNjYW fn5+mDp1Ks6cOYPU1FSYm5tjz549CA0NhY+PD2QyGQoLCwE8rAvJycnBiBEjEB4eDhMTEwCA TCbDtGnT4OjoCBMTEzg5OWHHjh3gOA5XrlzB3r17sWTJEkyYMKHFaWEwGAwGg8EcEAaDQTnX rl3D0qVLERoaioULF7Y4AM3U1tZi+fLlLepV/1un8XcqKipw69Yt/Otf/4Knpyf69euHS5cu oaioCHK5HFOnTkVmZiYIIaivrwfwsGakoaEB9vb2MDU1bXEmOI6DTCZD9+7dYWBgABsbG4wb Nw7p6em4efMm5s2bhzlz5oDPZ49LBoPBYDA0AUtmZjAYWufOnTtYtmwZRo0ahdWrVz9W29HQ 0IA1a9YgMzMTW7duRZ8+fZ56vYSEBNTW1mLEiBEwNDTEyy+/jJiYGPz000+YOXMm7OzsYGxs DENDw5ZaDqVSCbFYDFtb20fqOMRiMSorK2Fra9vys7y8PCxduhQhISFYvHjxY84Sg8FgMBgM 5oAwGAxKSU1Nxbx589DQ0IA+ffrg0qVLOHfuHGprawE8bCa4fv16HDhwAMOHD0dBQQFOnTqF tLS0Vq/HcRxiYmLg4eHRonw1aNAgiMVi+Pr6YsKECQAAgUAAQ0NDSKVSEEIgFotRXFwMJyen R3qvNEvzdu/eHcBDRazFixcjIyMDAQEB+OOPP3Dq1KmWVC4Gg8FgMBidg+UUMBgMrZGZmYlF ixYhMTERBgYG+M9//gNCCFxcXBAVFQUzMzNs2bIF27dvh0wmw48//ojNmzeDx+Phq6++QkBA wGPXrK2txa1btzBy5EhYWloCAJydnfHGG28gNDS05WcCgQACgQAqlQqEEFRXV0MqlaJnz56P XK+urg42Njbw9vaGVCrFjz/+iPPnz0OlUmH+/PkghIDH4yE8PJz1CWEwGAwGQwPwyLNaDTMY DEYHKS8vR1ZW1mM/FwgECAwMBI/Hw7179yCTyR59MPF48PLyaolK/B2ZTIa0tDS4ubnBwcEB wEMlq7y8PDg6OrYUrjc1NSEpKQnW1tbw9fWFWCxGRkYGfHx8YG1t3XK9mpoa5OXlwd/fHzwe D2lpaY/ZAwD+/v6sTwiDwWAwGMwBYTAYDAaDwWAwGM8TrAaEwWAwGAwGg8FgMAeEwWAwGAwG g8FgMAeEwWAwGAwGg8FgMJgDwmAwGAwGg8FgMJgDwmAwGAwGg8FgMBjMAWEwGAwGg8FgMBjM AWEwGAwGg8FgMBjMAWEwGAwGg8FgMBgM5oAwGAwGg8FgMBgM5oAwGAwGg8FgMBgMBnNAGAwG g8FgMBgMBnNAGAwGg8FgMBgMBnNAGAwGg8FgMBgMBoM5IAwGg8FgMBgMBuN55P8DhHDLZ0ht pMAAAAAASUVORK5CYII= --------------070807020607090609010008-- From pal@cs.stanford.edu Thu Oct 15 09:44:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0E203A69E9 for ; Thu, 15 Oct 2009 09:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYKNR8fRbIuJ for ; Thu, 15 Oct 2009 09:44:00 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id E4DBE3A69B2 for ; Thu, 15 Oct 2009 09:44:00 -0700 (PDT) Received: from dnab422286.stanford.edu ([171.66.34.134]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyTQq-0002jP-BJ; Thu, 15 Oct 2009 09:44:04 -0700 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 09:02:34 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 16:44:01 -0000 On Oct 15, 2009, at 6:22 AM, JP Vasseur wrote: > > On Oct 14, 2009, at 9:49 PM, Philip Levis wrote: > >> I think we should keep in mind that RPL must work across multiple >> link layers. E.g.: >> >> A -- 900MHz --> B -- 2.4GHz --> C >> >> ETX is a commonly used metric, but typically under two simplifying >> assumptions: >> >> 1) Routes are composed of a single link layer >> 2) The link layer has a static bitrate >> >> If you break either assumption, it doesn't work well. ETT (expected >> time of transmission) can address 2), but not 1). >> > > Not sure I would agree on this statement though. Being based on > probing it's not link layer dependent. You can of course use ETX in a link-independent way. It just leads to possibly very bizarre route choices. E.g., choose a very slow, high power link that requires one transmission over a very fast, low-power link that requires 2 transmissions. ETT breaks when you have a fast very high power link and a slower low power link. Nominally, one goal of ETT and ETX is to minimize the space-time that packets occupy a wireless channel. When different link layers have very different transmit ranges (space), they stop being accurate units for this purpose. Did I understand you correctly? Phil From pal@cs.stanford.edu Thu Oct 15 09:44:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1123A69E9 for ; Thu, 15 Oct 2009 09:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZanf6QzB1Ms for ; Thu, 15 Oct 2009 09:44:01 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 96DFC3A69E8 for ; Thu, 15 Oct 2009 09:44:01 -0700 (PDT) Received: from dnab422286.stanford.edu ([171.66.34.134]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyTQq-0002jP-UB; Thu, 15 Oct 2009 09:44:05 -0700 Message-Id: From: Philip Levis To: Sung Lee In-Reply-To: <4AD72F96.6030800@us.fujitsu.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 09:05:23 -0700 References: <4AD72F96.6030800@us.fujitsu.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: roll@ietf.org Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 16:44:02 -0000 On Oct 15, 2009, at 7:20 AM, Sung Lee wrote: > JP and WG members, > > This may be considered link reliability. > But in our experience, we found the following information very helpful > in improving the stability of network and also (and you could say) in > avoiding loops as well. > > We use what we call 'W' (weight). > When we forward data packet, we require per-hop ACK. > When we receive ACK, we adjust the new W to be old W -1 (W_new = > W_old - 1). > When we don't receive ACK, we adjust the new W to be old W + 1 > (W_old = > W_old +1). > When we detect a loop, we adjust the W value to MAX. > > We have experimented MAX value based on real system, MAX value of 10 > seems to be a good value to start with. > > Now this can be combined with other metric values you are all > discussing. We have experimented quite a lot with combing several > metrics with the above weight in determining the path, which so far > seems to work in our system. > For instance, the other metric values you are discussing (such as link > quality, RSSI, and/or everything else - please note this can be as > simple as hop count, RSSI, or whatever the WG determines) can be used > with along with W value to determine. > > I am interested in what the WG thinks of using this 'W' as part of > metric for RPL. Sung, I think the general approach of directly measuring the datapath is a great way to have fast and accurate link estimation. CTP's 4-bit link estimator (4B) has some similarities to what you describe, although it smoothes estimates much more: I'd be concerned about excessive instability in the above algorithm, as note that you can't measure a link you're not using. Have you read the 4-bit paper? You can find it at http://sing.stanford.edu/singpubs.html Phil From pal@cs.stanford.edu Thu Oct 15 09:44:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078AA3A69EA for ; Thu, 15 Oct 2009 09:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MGs5tVRR9y6 for ; Thu, 15 Oct 2009 09:44:02 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 295C53A69B2 for ; Thu, 15 Oct 2009 09:44:02 -0700 (PDT) Received: from dnab422286.stanford.edu ([171.66.34.134]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyTQr-0002jP-E5; Thu, 15 Oct 2009 09:44:05 -0700 Message-Id: From: Philip Levis To: Richard Kelsey In-Reply-To: <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 09:09:12 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 16:44:03 -0000 On Oct 13, 2009, at 9:02 AM, Richard Kelsey wrote: > > Those who cannot learn from history are doomed to repeat it. > > We have to be careful not to learn the wrong lesson. > Hopcount without careful link assessment definitely doesn't > work. Hopcount limited to stable, symmetric links is a > different beast entirely. For example, consider the Cost/PL > column in table 1 of [1], which gives the average > transmissions per link. For most of the networks it is very > close to 1 and it never goes above 2. That's puts ETX > pretty close to hopcount for those networks, if routing is > limited to links with good ETX. Richard, I fear this assertion might misrepresent the data. An average cost of <2 does not by any means suggest that there are no links with cost >2. It could be that 80% of links have a cost of 1 and 20% have a cost of 4. Phil From pal@cs.stanford.edu Thu Oct 15 09:48:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484CD3A67B8 for ; Thu, 15 Oct 2009 09:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM3k53uHyFpg for ; Thu, 15 Oct 2009 09:48:52 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 9691628C114 for ; Thu, 15 Oct 2009 09:48:51 -0700 (PDT) Received: from dnab422286.stanford.edu ([171.66.34.134]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyTVW-00038j-U5; Thu, 15 Oct 2009 09:48:55 -0700 Message-Id: From: Philip Levis To: Sung Lee In-Reply-To: <4AD73A51.10501@us.fujitsu.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 09:48:57 -0700 References: <4AAA5CE0.9060008@us.fujitsu.com> <4AB0C269.3090203@cttc.es> <4AB3D4A1.60805@eecs.berkeley.edu> <4AB9F844.60603@us.fujitsu.com> <4AD68772.4070903@us.fujitsu.com> <4AD73A51.10501@us.fujitsu.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6b0537b5faa14548adc1759647fcb4de Cc: roll@ietf.org Subject: Re: [Roll] Determining DADR Contributions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 16:48:53 -0000 On Oct 15, 2009, at 8:05 AM, Sung Lee wrote: > > Philip, > > Here is some additional information from our team in Japan. > > > IEEE802.15.4 > > Center freq.: 2.405GHz (11 ch) > > less interference because 802.11 does not use same center frequent > band > > (2.412GHz (1ch)) > > Center freq. of 1ch(IEEE802.11b/g) is 2.412GHz and bandwidth of the > signal > about 22MHz like the attached file. > http://en.wikipedia.org/wiki/IEEE_802.11 > > Then, 2.400GHz-2.424GHz is used for the WiFi 1ch. > Therefore, the WiFi(1ch) causes interference on IEEE802.15.4(11cn) > in a strict sense. > > > less interference because 802.11 does not use same center > frequent band > > I should have said "a little interference from the IEEE 802.11(1ch)". > Regards, > Sung Thanks! Those kinds of details are really helpful. Yeah, there's definitely interference with those two settings. Phil From wintert@acm.org Thu Oct 15 10:23:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5441A3A67EF for ; Thu, 15 Oct 2009 10:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.835 X-Spam-Level: X-Spam-Status: No, score=-101.835 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8lvmPP74U7v for ; Thu, 15 Oct 2009 10:23:45 -0700 (PDT) Received: from smtp106.prem.mail.ac4.yahoo.com (smtp106.prem.mail.ac4.yahoo.com [76.13.13.45]) by core3.amsl.com (Postfix) with SMTP id 5F1FD3A67C0 for ; Thu, 15 Oct 2009 10:23:45 -0700 (PDT) Received: (qmail 61611 invoked from network); 15 Oct 2009 17:23:45 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp106.prem.mail.ac4.yahoo.com with SMTP; 15 Oct 2009 10:23:44 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: ii1gDHIVM1m0WKHQqj0c1UmocSn_VW2vsIguSIt0jHE5hIuRm05piFROj2amb.lIGaMTF6.HVDwdhRACB4hDP6u2LOxh4CCxTHgmdOx8Ux4.lR8VO9bU0OU2mMtxW_F.MvmR4Rxbgn9ARfGeA2OCnOXmV_gxCA1FiaLmXuvPMjW7KiZdOVwEwOFoipJgDD0xp7y4ScSlh75EdvYMsyhVZ481rJBt4tiP_8KtlNxt3hyj6.Nlcz7gaKpolXNIQqVrvYXrx6UP39meJnNDnL8rdrwu3fqG3mCrKKbgfpovjbun6Nzl.Q_BjoN4svcctE3ztXNv4Jd_leVnHG5AKhD6U9y8fVU- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AD75A9F.6070803@acm.org> Date: Thu, 15 Oct 2009 13:23:43 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 17:23:46 -0000 WG, There has been some feedback regarding the implications of using Neighbor Discovery RA/NA to carry DIO/DAO for RPL. The functionality provided by DIO/DAO may be seen as a natural extension to ND, but there are concerns regarding the implications of overloading ND for use by RPL. Another option would be to request the allocation of ICMP messages to transport the DIO/DAO. What do you think? 1) Let RPL use RA/NA for DIO/DAO transport 2) Allocate 2 new ICMP messages for DIO/DAO and operate independent of ND Please do keep in mind that this would serve as a base recommendation for the core protocol, and does not necessarily preclude that another implementation-specific binding outside of the scope of RPL (e.g. 6LowPAN) may do things differently. Thanks, -RPL Authors From anders.jagd@ekasystems.com Thu Oct 15 10:27:30 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296FF3A69F7 for ; Thu, 15 Oct 2009 10:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37CkpvSzbYAw for ; Thu, 15 Oct 2009 10:27:29 -0700 (PDT) Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by core3.amsl.com (Postfix) with SMTP id 299313A6869 for ; Thu, 15 Oct 2009 10:27:29 -0700 (PDT) Received: (qmail 34690 invoked from network); 15 Oct 2009 17:27:30 -0000 Received: from (anders.jagd@209.48.242.70 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 15 Oct 2009 10:27:30 -0700 PDT X-Yahoo-SMTP: 0HbgGv6swBAyDM4W_iY9jImykUMHKYOyMTAwyHNWIF768PM- X-YMail-OSG: Vn8whJ0VM1mrvQL3wcGusdf6wlaMMjHuNcgdbe9DmAkAaNoTzjAq_m9zEIWA952hhKfTeWaSjbbEYaA2QkRi58Shv18ZMp2urdITn3dWXV7IvrC7XdMbKrsXsX4mvMfyEYabsAoa5awsIBvSy56ntI172TAOI1HKcTwK3_RW5kj.R2MuAyZseI5iM0wCd4w8LnB9dt8EXMG9YFRFZgycASmNoHmIAWoYyz1Wo3T7x.oXWMLdHmcuZIgFsWLJk3UrDv6ZAMZfLf0f_7X.TJQDh4fxuNX6JmmWOerDPl9ll1kVS5rSk1lMpkrE3gE4cXNJ X-Yahoo-Newman-Property: ymail-3 From: "Anders Jagd" To: Date: Thu, 15 Oct 2009 13:27:27 -0400 Organization: Eka Systems Message-ID: <000901ca4dbc$c566f5d0$5034e170$@jagd@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpNvMQZ043KuHqiR9qz7kyxgMGqBQ== Content-Language: en-us Cc: roll@ietf.org Subject: [Roll] Ew: RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 17:27:30 -0000 Tim, As for your questions: >Question A: Should RPL make use of the currently proposed local ... >Question B: Should RPL make use of a hold-up timer and related ... >Question C: Should RPL make use of a hold-down timer and related ... A+B: My opinion would be that a Sequence number/"Heartbeat" scheme generally provides a more reliable, efficient, and simple method compared to timer based approaches. Determining reasonable settings for timer(s) may prove difficult, and no matter what value is chosen, there is no guarantee that the scheme achieves the intended goal, rather a likelihood. Not that I am in general against "likelihoods", as long as they are not "too small" (not good enough), neither "too large" (too expensive/conservative) - something not trivial to achieve, in particular since nodes/roots rarely/never have complete atomic snapshots in time of the full DAG, and even if they did, the DAG could be quite unbalanced with a mix of short and long branches. After deciding on (or occasionally adjusting) proper timer values, those values then have to be propagated. As of 03 this is through RA-DIO. It does appear a bit wasteful to continuously broadcast values that typically are quite static. However, new nodes need to be informed, so if it is not done regularly through RA-DIO, some other way would have to be defined, basically some signaling scheme. Either way, this sounds "expensive". The sequence number approach has little to no timers involved; as soon as a new sequence number is observed, a node is good to go (merge). It appears to basically be a semi "self-timed" approach ("semi" since root, but only root, may need a timer for triggering the heartbeat). How frequently should this heartbeat (sequence number increment) then happen ? Again, we run into the "too short/too long" discussion. But what if a node wishing to merge into a DAG (and thus needing to see a new SQN), could be allowed to request the root to increment the sequence number ? If any other heartbeat trigger is required, it could probably be chosen quite conservatively, and the value certainly would not have to be propagated. Bursts of such "increment SQN" requests could be reduced by some form of aggregation: Any node issuing or forwarding a "SQN update request" would stop forwarding other such requests (drop them) until it sees a new SQN. C: I think some form of mechanism to limit flapping is important, but again, I would ask how to determine and configure/propagate a proper timer value. Can we somehow base it on the heartbeat instead (maybe multiple heartbeats) ? /Anders From anders.jagd@ekasystems.com Thu Oct 15 10:36:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD2F28C15A for ; Thu, 15 Oct 2009 10:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPl+MGVGER8H for ; Thu, 15 Oct 2009 10:36:12 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id 8C3C728C138 for ; Thu, 15 Oct 2009 10:36:12 -0700 (PDT) Received: (qmail 97081 invoked from network); 15 Oct 2009 17:36:14 -0000 Received: from unknown (HELO AndersLaptop) (anders.jagd@209.48.242.70 with login) by smtp107.biz.mail.re2.yahoo.com with SMTP; 15 Oct 2009 17:36:13 -0000 X-Yahoo-SMTP: Z9nti1.swBBshEkcTT58JGsSW0GG0Kgu_9V27Bc_1Irb1gnWTbAo X-YMail-OSG: uluW1oUVM1nA8wWLDNbPW97AcmqI5ht0LvKdrDIu0ejUV7WcTNhPbnwudvdqti_pP4fuglfDdqCsexcaGvP2I5XpGV1jn5YY_CIimczASrbsk37Hf3FrLx9IzkDzhhEAfrQOQfk37trrpt3ZaHYwYUxlQkqjqJXqarmq.gPZrcfnrVwmnoXHWw5t1yqU9d3Lb6G3J2jZJQItMO_aQVnSLIQciK614brHyU0mhm_aAPZFwRW3lrwbOGGUodsl1HiZECcuABdlhL5ZZbg0n7TIguqLYcBKiBsS6AdsQDU1azuo8OLXf0Klez8lyZ.EjDCd X-Yahoo-Newman-Property: ymail-3 From: "Anders Jagd" To: Date: Thu, 15 Oct 2009 13:36:11 -0400 Organization: Eka Systems Message-ID: <000d01ca4dbd$fd62d1b0$f8287510$@jagd@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpNvfyhBXNhT3YgRNKPTlFO9mX84A== Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] Informed move [was: A proposal for Traffic Loop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 17:36:13 -0000 Pascal, You wrote: >The draft actually allows moving to a higher rank but there's a catch. >Whereas a node can reattach right away to obtain a better rank, it needs to play a little dance that includes detach, wait & see before it can >attach at a higher rank. Wouldn't the following statement in 03 deal with exactly that "loop-hole" ? (From 5.3.2.1. Determination of Eligibility for DIO Processing) 2188 If the rank of SRC as reported in the RA-DIO message is higher 2189 than that of the node within the DAG, and SRC is not a DAG 2190 parent, then the RA-DIO message MUST NOT be considered for 2191 further processing However, my real question is then whether there are any ideas on how to enforce such a "MUST NOT" (or even detect a violation) ? Some implementation may try to differentiate itself by ignoring it. Having a rule that is not detectable/enforceable seems problematic. /Anders From richard.kelsey@ember.com Thu Oct 15 10:45:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 940A03A685A for ; Thu, 15 Oct 2009 10:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qncKIDbD8Du for ; Thu, 15 Oct 2009 10:45:04 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id BFC503A6816 for ; Thu, 15 Oct 2009 10:45:04 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Oct 2009 13:46:15 -0400 Date: Thu, 15 Oct 2009 13:43:17 -0400 Message-Id: <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Thu, 15 Oct 2009 09:09:12 -0700) From: Richard Kelsey References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 15 Oct 2009 17:46:15.0791 (UTC) FILETIME=[64C07FF0:01CA4DBF] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 17:45:05 -0000 From: Philip Levis Date: Thu, 15 Oct 2009 09:09:12 -0700 On Oct 13, 2009, at 9:02 AM, Richard Kelsey wrote: > Those who cannot learn from history are doomed to repeat it. > > We have to be careful not to learn the wrong lesson. > Hopcount without careful link assessment definitely doesn't > work. Hopcount limited to stable, symmetric links is a > different beast entirely. For example, consider the Cost/PL > column in table 1 of [1], which gives the average > transmissions per link. For most of the networks it is very > close to 1 and it never goes above 2. That's puts ETX > pretty close to hopcount for those networks, if routing is > limited to links with good ETX. I fear this assertion might misrepresent the data. An average cost of <2 does not by any means suggest that there are no links with cost >2. It could be that 80% of links have a cost of 1 and 20% have a cost of 4. Right. I wasn't as clear as I should have been. For the networks with lowest Cost/PL, such as 1.04 or 1.09, hopcount would have been nearly identical to ETX as a metric, if routing were limited to links with good ETX. As you point out, for the higher values the Cost/PL doesn't tell as much about what was happening. The fact that the highest Cost/PL are less than 2 does indicate that most of the links used had an ETX less than 1.5. -Richard Kelsey From alexandru.petrescu@gmail.com Thu Oct 15 12:24:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4A83A6984 for ; Thu, 15 Oct 2009 12:24:49 -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=[AWL=0.370, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFXRpNHEhTjA for ; Thu, 15 Oct 2009 12:24:48 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 9B2333A67AA for ; Thu, 15 Oct 2009 12:24:47 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E7235D48639; Thu, 15 Oct 2009 21:24:46 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 95214D49303; Thu, 15 Oct 2009 21:24:43 +0200 (CEST) Message-ID: <4AD776F8.9030605@gmail.com> Date: Thu, 15 Oct 2009 21:24:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:24:49 -0000 Philip Levis a écrit : > > On Oct 12, 2009, at 3:09 PM, Maxence Dalmais wrote: > >> >> I am saying that when using wireless links, a node should be aware >> that his communication could interfere with other communication. >> Less powered is the transmission signal, less noise is seen by >> neighbours. > > It also means that it's more greatly affected by interference from > neighbors: there is no free lunch. > >> A low powered node will also need less energy to communicate in a less >> noisy environnement. > > In low-power wireless chipsets, CMOS dominates power costs. E.g., a chip > that draws 60mW transmits at 1mW. Reducing transmit power typically does > not conserve much energy. Well but who cares how much energy does the CMOS consume, when what we need is link energy. >> So, it appears to me logical that when others metrics are egals to >> choose the less power needed links. > > I don't know of any strong experimental evidence supporting this > conclusion. Can you point me at some? Err... just a side note to say there's a long list of papers talking metrics which have implications on power consumptions for emitting on a link. Do you really want me to post? I'm wary to more and more negative about citing papers on this WG. Alex From alexandru.petrescu@gmail.com Thu Oct 15 12:27:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DC928C102 for ; Thu, 15 Oct 2009 12:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCAPJG42JtuI for ; Thu, 15 Oct 2009 12:27:16 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 9E64E28C13E for ; Thu, 15 Oct 2009 12:27:15 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 90B42D481D7; Thu, 15 Oct 2009 21:27:14 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8BBC0D49332; Thu, 15 Oct 2009 21:27:12 +0200 (CEST) Message-ID: <4AD7778D.7040708@gmail.com> Date: Thu, 15 Oct 2009 21:27:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> In-Reply-To: <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:27:17 -0000 Philip Levis a écrit : > I think we should keep in mind that RPL must work across multiple link > layers. E.g.: > > A -- 900MHz --> B -- 2.4GHz --> C > > ETX is a commonly used metric, Philip, what do you mean by "ETX commonly used metric"? Could you please explain, in implementation terms. Could you list some widely available software in solid software distributions, widely deployed, and using this ETX metric? Alex From mcr@marajade.sandelman.ca Thu Oct 15 12:31:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F299A3A6990 for ; Thu, 15 Oct 2009 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBGGa8+9jUuG for ; Thu, 15 Oct 2009 12:30:58 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C91AC3A67AA for ; Thu, 15 Oct 2009 12:30:58 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 96CB93428F for ; Thu, 15 Oct 2009 19:35:40 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E5B773EC2 for ; Thu, 15 Oct 2009 15:31:00 -0400 (EDT) From: Michael Richardson To: ROLL WG In-Reply-To: <4AD75A9F.6070803@acm.org> References: <4AD75A9F.6070803@acm.org> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 15 Oct 2009 15:31:00 -0400 Message-ID: <25979.1255635060@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:31:01 -0000 >>>>> "Tim" == Tim Winter writes: Tim> What do you think? I think that I do not have enough information yet. I would like to spend some more time understanding how RPL and 6LoWPAN interact. In particular, if we use RA/NA for DIO, will it work to use NR/NC instead messages in 6LoWPAN, or does it create a chicken/egg problem. I have an email from Pascal to properly understand and reply to, so can we defer this decision a week? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From alexandru.petrescu@gmail.com Thu Oct 15 12:32:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394B53A6990 for ; Thu, 15 Oct 2009 12:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6XKWjPKuF9f for ; Thu, 15 Oct 2009 12:32:24 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5438C3A67AA for ; Thu, 15 Oct 2009 12:32:22 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9FC44D488E7; Thu, 15 Oct 2009 21:32:22 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4B181D48608; Thu, 15 Oct 2009 21:32:19 +0200 (CEST) Message-ID: <4AD778C0.9020305@gmail.com> Date: Thu, 15 Oct 2009 21:32:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:32:25 -0000 JP Vasseur a écrit : > > On Oct 14, 2009, at 9:30 PM, Philip Levis wrote: > >> >> On Oct 12, 2009, at 3:09 PM, Maxence Dalmais wrote: >> >>> >>> I am saying that when using wireless links, a node should be aware >>> that his communication could interfere with other communication. >>> Less powered is the transmission signal, less noise is seen by >>> neighbours. >> >> It also means that it's more greatly affected by interference from >> neighbors: there is no free lunch. >> >>> A low powered node will also need less energy to communicate in a >>> less noisy environnement. >> >> In low-power wireless chipsets, CMOS dominates power costs. E.g., a >> chip that draws 60mW transmits at 1mW. Reducing transmit power >> typically does not conserve much energy. > > I have the same data. What is the device you commonly talk about? This 1/6 computing/transmitting fraction seems illogical to me, when considering other similar chipsets. Alex From pal@cs.stanford.edu Thu Oct 15 12:33:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27543A68ED for ; Thu, 15 Oct 2009 12:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZi6+4H6QeeI for ; Thu, 15 Oct 2009 12:33:21 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id ED3703A67AA for ; Thu, 15 Oct 2009 12:33:21 -0700 (PDT) Received: from dnab422286.stanford.edu ([171.66.34.134]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyW4j-0007Um-6j; Thu, 15 Oct 2009 12:33:25 -0700 Message-Id: <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4AD7778D.7040708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 12:33:25 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <4AD7778D.7040708@gmail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:33:22 -0000 On Oct 15, 2009, at 12:27 PM, Alexandru Petrescu wrote: > Philip Levis a =E9crit : >> I think we should keep in mind that RPL must work across multiple =20 >> link layers. E.g.: >> A -- 900MHz --> B -- 2.4GHz --> C >> ETX is a commonly used metric, > > Philip, what do you mean by "ETX commonly used metric"? > > Could you please explain, in implementation terms. > > Could you list some widely available software in solid software =20 > distributions, widely deployed, and using this ETX metric? MIT Roofnet/srcr: http://pdos.csail.mit.edu/roofnet/software.php CTP: = http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/ctp= / OLSR: http://www.olsr.org/docs/README-Link-Quality.html Phil= From alexandru.petrescu@gmail.com Thu Oct 15 12:34:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB2E3A67AA for ; Thu, 15 Oct 2009 12:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRBvaychQzHI for ; Thu, 15 Oct 2009 12:34:18 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 7E2D03A68ED for ; Thu, 15 Oct 2009 12:34:16 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id CC332D493B0; Thu, 15 Oct 2009 21:34:16 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id AED50D48869; Thu, 15 Oct 2009 21:34:13 +0200 (CEST) Message-ID: <4AD77932.5060903@gmail.com> Date: Thu, 15 Oct 2009 21:34:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <87d44oag2d.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87d44oag2d.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:34:19 -0000 Richard Kelsey a écrit : > From: Philip Levis > Date: Wed, 14 Oct 2009 21:49:10 -0700 > > I think we should keep in mind that RPL must work across multiple link > layers. E.g.: > > A -- 900MHz --> B -- 2.4GHz --> C > > Or maybe a PLC link or two. > > ETX is a commonly used metric, but typically under two simplifying > assumptions: > > 1) Routes are composed of a single link layer > 2) The link layer has a static bitrate > > If you break either assumption, it doesn't work well. ETT (expected > time of transmission) can address 2), but not 1). > > I'm wary of encoding a metric as a hard quantity. For example, > quantifying the metric as uJ breaks when nodes have differential > energy capacities. What we really want is a more abstract notion of > cost, which a particular device can use to, in a very simple way, > express its own tradeoffs. It is critical that exactly how devices > calculate this value remain unspecified. > > I would agree that this is true as far as ROLL and the IETF > is concerned. More concrete and layer-specific > specifications can, and probably will, be produced by > other organzations. > > My first thought would be a quantification of how much of a node's > "lifetime" a packet would cost. Such a cost can consider both the > receiver and transmitter. E.g., given its particular low power > algorithms and expected lifetime, how much would sending to this > destination consume? (I try to avoid using the word "link.") > > An 'available bandwidth' metric works for this. For a > battery powered device you know the desired lifetime, the > amount of energy in the battery, and how much of this will > be consumed by the device itself. The leftover energy, > divided by the desired lifetime and the cost of sending and > receiving, gives the bandwidth the device can donate to the > network. This works for energy scavenging devices as well, > assuming that the scavenging rate is predictable. > > I don't think that a single metric will be sufficient; besides some > notion of cost (hopcount, ETX, ETT, etc.), the other metric that is > critical in many applications is latency. These two -- cost and > latency -- can cover a large portion of the application design space, > and provide a sound basis for the basic specification. > > I think three metrics are needed: > - latency > - bandwidth (which subsumes energy limits, as above) > - reliability Please add to what's needed an "energy metric for link" expressed in Joules needed to send 1280bytes on that particular link. Alex > The units for the first two are straightforward. The third > is a puzzler. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Thu Oct 15 12:41:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C91E3A6927 for ; Thu, 15 Oct 2009 12:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-KsMS6dTvMz for ; Thu, 15 Oct 2009 12:41:31 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 5B4243A67AA for ; Thu, 15 Oct 2009 12:41:31 -0700 (PDT) Received: from dnab422286.stanford.edu ([171.66.34.134]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyWCc-0007nk-Qj; Thu, 15 Oct 2009 12:41:35 -0700 Message-Id: <7DEF06A2-4BC1-45F8-A1EA-37A7E9A07FB4@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4AD778C0.9020305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 12:41:33 -0700 References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> <4AD778C0.9020305@gmail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:41:32 -0000 On Oct 15, 2009, at 12:32 PM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 14, 2009, at 9:30 PM, Philip Levis wrote: >>> >>> On Oct 12, 2009, at 3:09 PM, Maxence Dalmais wrote: >>> >>>> >>>> I am saying that when using wireless links, a node should be =20 >>>> aware that his communication could interfere with other =20 >>>> communication. >>>> Less powered is the transmission signal, less noise is seen by =20 >>>> neighbours. >>> >>> It also means that it's more greatly affected by interference from =20= >>> neighbors: there is no free lunch. >>> >>>> A low powered node will also need less energy to communicate in a =20= >>>> less noisy environnement. >>> >>> In low-power wireless chipsets, CMOS dominates power costs. E.g., =20= >>> a chip that draws 60mW transmits at 1mW. Reducing transmit power =20 >>> typically does not conserve much energy. >> I have the same data. > > What is the device you commonly talk about? =46rom just one (leading) manufacturer: CC1000 (868MHz): @5mW, draws 75mW; @ 0.01mW draws 25mW CC1100 (868MHz): @10mW, draws 90mW; @0.1mW draws 42mW CC2420 (2.4GHz): @1mW, draws 50mW: @0.003mW draws 25mW CC2520 (2.4GHz): @3mW, draws 75mW: @1mW draws 60mW > This 1/6 computing/transmitting fraction seems illogical to me, when =20= > considering other similar chipsets. Please read some data sheets. Phil From mcr@marajade.sandelman.ca Thu Oct 15 12:42:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9680B3A68ED for ; Thu, 15 Oct 2009 12:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.146 X-Spam-Level: X-Spam-Status: No, score=0.146 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd7jPKuZyZnH for ; Thu, 15 Oct 2009 12:42:57 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id A49413A67AA for ; Thu, 15 Oct 2009 12:42:56 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id D0A3B3428E; Thu, 15 Oct 2009 19:47:38 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 293573EC2; Thu, 15 Oct 2009 15:42:59 -0400 (EDT) From: Michael Richardson To: d.sturek@att.net In-Reply-To: <001b01ca4d59$fb2451d0$f16cf570$@sturek@att.net> References: <001b01ca4d59$fb2451d0$f16cf570$@sturek@att.net> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 15 Oct 2009 15:42:59 -0400 Message-ID: <26777.1255635779@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: 'roll' Subject: Re: [Roll] Question on Multi-Homing in RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:42:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Don" == Don Sturek writes: Don> A question on RPL -03: Is Multi-Homing supported? Here is Don> the use case: (SmartMeter + ISP) situation described. This is a scenario that I think is completely valid. Don> Here are the questions: Don> 1) Within a DAG, could devices be Multi-Homed or are they Don> required to have a single prefix? I think they have to have a single prefix. Don> 2) Are there any limitations or suggestions on how address Don> assignment should be handled with respect to the two prefix Don> address spaces. I'm not sure if you asking about whether the prefixes have to be coordinated, or if you asking if the assignments within each prefix needs to be coordinated. Don> 3) If we would like the same devices to be able to Don> communicate to the Don> meter/headend and then also to the internet via the customers Don> ISP, would: Don> a. There need to be DAGs supporting separate prefix Don> addresses? I think the device needs to associate to two DAGs. Don> b. Can the devices in a single DAG support multihomed Don> devices? Would all devices in a given DAG need to be Don> multihomed the same way? I think all the devices involved would need to join multiple DAGs. Some of them might not be able to, and would have to pick one or the other. If they are owned/controlled by utility, I imagine it likely they would prefer the meter route. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStd7QYCLcPvd0N1lAQIfOggAgVZjK8Ej1MO266EUhc9NhsPC5yv11A2F IavNovavWJMaLCzqWHOGuyo7qBXVMfGZhNoDDD2kDP0qvAnLcMVeHoJheUrVnnUL m6a/BRJN+P4z2G0NiI10+/QWins/2EqO+m2c8r1DDQgKSVw+RrLsiYzwIRAWhb07 PljGMtSmZtGFIy0j8xAZH7vOoUBV5hJEIV0NVEx+YKjhEd82k74XIuoCTN1aRkKx 6pZd6Qv2RCjUkz/2gFb9fMML/ytDZo8N9ScZoCGFWxv1FCyw0Tb2DuAmRan6hGjc T3NyniJzo2BeH2pgqVVxhTAHwJ/zolbTzyD8583Lh2VNOsLKbi4ucg== =crr0 -----END PGP SIGNATURE----- From alexandru.petrescu@gmail.com Thu Oct 15 12:44:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA083A69B0 for ; Thu, 15 Oct 2009 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkSzGx+mSt-4 for ; Thu, 15 Oct 2009 12:44:51 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id EDBF33A68ED for ; Thu, 15 Oct 2009 12:44:49 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id DEEBBD489CA; Thu, 15 Oct 2009 21:44:49 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id CCEAED48905; Thu, 15 Oct 2009 21:44:46 +0200 (CEST) Message-ID: <4AD77BAC.7000809@gmail.com> Date: Thu, 15 Oct 2009 21:44:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <4AD7778D.7040708@gmail.com> <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> In-Reply-To: <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:44:52 -0000 Philip Levis a écrit : > > On Oct 15, 2009, at 12:27 PM, Alexandru Petrescu wrote: > >> Philip Levis a écrit : >>> I think we should keep in mind that RPL must work across multiple >>> link layers. E.g.: >>> A -- 900MHz --> B -- 2.4GHz --> C >>> ETX is a commonly used metric, >> >> Philip, what do you mean by "ETX commonly used metric"? >> >> Could you please explain, in implementation terms. >> >> Could you list some widely available software in solid software >> distributions, widely deployed, and using this ETX metric? > > > MIT Roofnet/srcr: http://pdos.csail.mit.edu/roofnet/software.php > CTP: > http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/ctp/ > OLSR: http://www.olsr.org/docs/README-Link-Quality.html How about software implementing IETF standards, geared towards advancing on the Standards Track? What are we talking about here? I more and more feel we live in very different worlds. Alex From alexandru.petrescu@gmail.com Thu Oct 15 12:46:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18CDD3A694E for ; Thu, 15 Oct 2009 12:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+eAxC7KSWfb for ; Thu, 15 Oct 2009 12:46:35 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 1E71B3A6927 for ; Thu, 15 Oct 2009 12:46:33 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id D07BAD4820C; Thu, 15 Oct 2009 21:46:32 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id A84EBD48D53; Thu, 15 Oct 2009 21:46:29 +0200 (CEST) Message-ID: <4AD77C12.3030601@gmail.com> Date: Thu, 15 Oct 2009 21:46:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> <783087DF-E8E4-4401-BB32-D0E51E236B6B@cisco.com> <4AD778C0.9020305@gmail.com> <7DEF06A2-4BC1-45F8-A1EA-37A7E9A07FB4@cs.stanford.edu> In-Reply-To: <7DEF06A2-4BC1-45F8-A1EA-37A7E9A07FB4@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:46:36 -0000 Philip Levis a écrit : > > On Oct 15, 2009, at 12:32 PM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 14, 2009, at 9:30 PM, Philip Levis wrote: >>>> >>>> On Oct 12, 2009, at 3:09 PM, Maxence Dalmais wrote: >>>> >>>>> >>>>> I am saying that when using wireless links, a node should be aware >>>>> that his communication could interfere with other communication. >>>>> Less powered is the transmission signal, less noise is seen by >>>>> neighbours. >>>> >>>> It also means that it's more greatly affected by interference from >>>> neighbors: there is no free lunch. >>>> >>>>> A low powered node will also need less energy to communicate in a >>>>> less noisy environnement. >>>> >>>> In low-power wireless chipsets, CMOS dominates power costs. E.g., a >>>> chip that draws 60mW transmits at 1mW. Reducing transmit power >>>> typically does not conserve much energy. >>> I have the same data. >> >> What is the device you commonly talk about? > > From just one (leading) manufacturer: > > CC1000 (868MHz): @5mW, draws 75mW; @ 0.01mW draws 25mW > CC1100 (868MHz): @10mW, draws 90mW; @0.1mW draws 42mW > CC2420 (2.4GHz): @1mW, draws 50mW: @0.003mW draws 25mW > CC2520 (2.4GHz): @3mW, draws 75mW: @1mW draws 60mW > >> This 1/6 computing/transmitting fraction seems illogical to me, when >> considering other similar chipsets. > > Please read some data sheets. Please implement some RFCs. Alex From alexandru.petrescu@gmail.com Thu Oct 15 12:49:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C1B3A68ED for ; Thu, 15 Oct 2009 12:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2dBC8W9eQrh for ; Thu, 15 Oct 2009 12:49:36 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E040D3A6898 for ; Thu, 15 Oct 2009 12:49:34 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id F1DACD490FF; Thu, 15 Oct 2009 21:49:33 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 96CE2D490ED; Thu, 15 Oct 2009 21:49:30 +0200 (CEST) Message-ID: <4AD77CC7.5000707@gmail.com> Date: Thu, 15 Oct 2009 21:49:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <4AD7778D.7040708@gmail.com> <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> In-Reply-To: <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:49:37 -0000 Philip Levis a écrit : > > On Oct 15, 2009, at 12:27 PM, Alexandru Petrescu wrote: > >> Philip Levis a écrit : >>> I think we should keep in mind that RPL must work across multiple >>> link layers. E.g.: >>> A -- 900MHz --> B -- 2.4GHz --> C >>> ETX is a commonly used metric, >> >> Philip, what do you mean by "ETX commonly used metric"? >> >> Could you please explain, in implementation terms. >> >> Could you list some widely available software in solid software >> distributions, widely deployed, and using this ETX metric? > > > MIT Roofnet/srcr: http://pdos.csail.mit.edu/roofnet/software.php > CTP: > http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/ctp/ > OLSR: http://www.olsr.org/docs/README-Link-Quality.html Ah the World Wide Web, h t t p something, wikipedia and google and we know everything... The software being on a website doesn't tell anything about how much it is used. How about software which is not on h t t p something yet it runs ok. Alex From alexandru.petrescu@gmail.com Thu Oct 15 12:52:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D5C3A68ED for ; Thu, 15 Oct 2009 12:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.403 X-Spam-Level: X-Spam-Status: No, score=-0.403 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJgtZL6WUaq9 for ; Thu, 15 Oct 2009 12:52:21 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 1AB3D3A690D for ; Thu, 15 Oct 2009 12:52:19 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 67408D490F6; Thu, 15 Oct 2009 21:52:18 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 10F60D49429; Thu, 15 Oct 2009 21:52:15 +0200 (CEST) Message-ID: <4AD77D6D.2080709@gmail.com> Date: Thu, 15 Oct 2009 21:52:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <993C9EBE-CF52-4645-A9AD-6F31FE2C2215@cisco.com> <200910131011.11371.hrogge@googlemail.com> <2B1F50AA-4B8B-443E-86BD-5A85FC667F3E@cs.stanford.edu> In-Reply-To: <2B1F50AA-4B8B-443E-86BD-5A85FC667F3E@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] simplicity and metrics (was: ETX metric) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:52:22 -0000 Philip Levis a écrit : > > On Oct 13, 2009, at 1:11 AM, Henning Rogge wrote: > >> >> So the question about a metric for ROLL should not only be "what's >> the best metric for our networks" but "what metric is simple enough >> that everyone can implement it on any kind of hardware". > > I agree. Well put! :) I agree on the simplicity aspects. And my answer to that question is a metric which expresses in Joules how much energy is needed to send an IPv6 1280bytes packet on that link. Is this simple? Difficult? What do you think about simplicity and this energy metric link. Alex From hrogge@googlemail.com Thu Oct 15 12:53:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0396B3A69FD for ; Thu, 15 Oct 2009 12:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFDCwh8t15fK for ; Thu, 15 Oct 2009 12:53:23 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id CBC2A3A67AA for ; Thu, 15 Oct 2009 12:53:22 -0700 (PDT) Received: by ewy4 with SMTP id 4so918951ewy.37 for ; Thu, 15 Oct 2009 12:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=kiatjquBukHcraw3xZ8k8PWVV9WdQPGpC1Jo5vhCCk8=; b=sKQ4Fl8iOvVbf+4enDx4oVUQM0MfIqR1FPRrIGaWmKz8qpiOzfEX34gJeOQi/mOX+o irn2gf472QIfHmt3XRAXEoH9g6wIPDY7wvEaMv8Batif1jiABhXNEHXvxStAsj0/jmlk 5WjWNr81b8eUmRgIFMMJKnwp2XdsXrD4WQT1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=RFQc6udfXkwwYmfApx+PC5jN7K6vfOBt8WH4aay8BGta2SiCsy60pPYu8qBWV8dzVx kg+VCzaNTRSi0Kuh/4Ur+9iDSWMgjKFGAPzOLcieykLQYGN3QuzmOMRxs0K/G4zbtaKW TK6L7LmCkbtFu3/X9veMUbjvtmpfmkugXZkew= Received: by 10.211.154.18 with SMTP id g18mr598050ebo.70.1255636403729; Thu, 15 Oct 2009 12:53:23 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 10sm227295eyz.43.2009.10.15.12.53.22 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 12:53:22 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Thu, 15 Oct 2009 21:53:17 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> <4AD77BAC.7000809@gmail.com> In-Reply-To: <4AD77BAC.7000809@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1868527.OW3f20Fssd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910152153.21821.hrogge@googlemail.com> Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 19:53:24 -0000 --nextPart1868527.OW3f20Fssd Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Donnerstag 15 Oktober 2009 21:44:44 schrieb Alexandru Petrescu: > How about software implementing IETF standards, geared towards advancing > on the Standards Track? The RFC conform implementation of OLSR does not work well. The=20 =46reifunk/Funkfeuer community networks (which are some of the largest depl= oyed=20 mesh networks) all use ETX because it does not work with hopcount. > What are we talking about here? I more and more feel we live in very > different worlds. OLSRv2 WILL contain integrated metric support because everyone in the MANET= =2DWG=20 agrees that it's necessary. We are discussing about if we integrate ETX as = the=20 easiest (and layer 1/2 independant) metric as an appendix/example into the= =20 main draft or not at the moment. Henning Rogge --nextPart1868527.OW3f20Fssd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkrXfbEACgkQcenvcwAcHWcahQCdFyobYgX7w4etw2urJU7SdIBJ AXIAnjwXNzwMuDZBx6VS2ONNMSNRAGlX =7Sf3 -----END PGP SIGNATURE----- --nextPart1868527.OW3f20Fssd-- From alexandru.petrescu@gmail.com Thu Oct 15 13:17:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC09B28C16A for ; Thu, 15 Oct 2009 13:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmi+82Ou0o+E for ; Thu, 15 Oct 2009 13:17:45 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 584D528C164 for ; Thu, 15 Oct 2009 13:17:42 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B1525D48581; Thu, 15 Oct 2009 22:17:42 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9C1BED48882; Thu, 15 Oct 2009 22:17:39 +0200 (CEST) Message-ID: <4AD78360.7080807@gmail.com> Date: Thu, 15 Oct 2009 22:17:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> <4AD77BAC.7000809@gmail.com> <200910152153.21821.hrogge@googlemail.com> In-Reply-To: <200910152153.21821.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 20:17:45 -0000 Henning Rogge a écrit : > Am Donnerstag 15 Oktober 2009 21:44:44 schrieb Alexandru Petrescu: >> How about software implementing IETF standards, geared towards advancing >> on the Standards Track? > The RFC conform implementation of OLSR does not work well. The > Freifunk/Funkfeuer community networks (which are some of the largest deployed > mesh networks) all use ETX because it does not work with hopcount. Well it seems like a large effort indeed (you claim it as some of the largest deployed mesh networks) - can I ping it? >> What are we talking about here? I more and more feel we live in very >> different worlds. > > OLSRv2 WILL contain integrated metric support because everyone in the MANET-WG > agrees that it's necessary. We are discussing about if we integrate ETX as the > easiest (and layer 1/2 independant) metric as an appendix/example into the > main draft or not at the moment. Well that sounds as good news for ETX and OLSR. Do you have some comment on link energy metrics? Alex > > Henning Rogge From hrogge@googlemail.com Thu Oct 15 13:45:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E870228C172 for ; Thu, 15 Oct 2009 13:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFCnOEz9i3Ke for ; Thu, 15 Oct 2009 13:45:57 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 5BE7F28C165 for ; Thu, 15 Oct 2009 13:45:56 -0700 (PDT) Received: by ewy4 with SMTP id 4so972116ewy.37 for ; Thu, 15 Oct 2009 13:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=X0vHliO6bopwKst9OzvVMgrSwsOL8yrSIiUXN7O+mjg=; b=LKH7dmTrXiluXEJ2JZ5UcKji1PRSDWdRAqk6osrqBHJc1/dkZdzQVUNdlp5ij0XSZ0 9lShYauVEET5wNRQyMosCB65/yOzhlyxlsmLdhvm2h4el0s9o0xscVlsfE4axY3ygLK3 EBTctyukUGMx+7MeHjevgX6VNnTuStsVCXSto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=gUhWmzRGbEllUlxJd3DsE62oI8iMLEjYVmDv2yDC/Gk+GctpRfXMphh00Yq2bN2T+H FwIpsqzNrdFS5jn2dUzxw9sQw2tQTYKLzwt2/mzUVFu98Om3ALcaYiAAUK8BUyZNtsJP tgN3bKrpT/repIaH6cpddkmG3dJXVqwvdIr5I= Received: by 10.216.87.144 with SMTP id y16mr179353wee.95.1255639558135; Thu, 15 Oct 2009 13:45:58 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 23sm5001390eya.12.2009.10.15.13.45.57 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 13:45:57 -0700 (PDT) From: Henning Rogge To: Alexandru Petrescu Date: Thu, 15 Oct 2009 22:45:51 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <200910152153.21821.hrogge@googlemail.com> <4AD78360.7080807@gmail.com> In-Reply-To: <4AD78360.7080807@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4487223.10NOO4Ka3b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910152245.56332.hrogge@googlemail.com> Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 20:45:58 -0000 --nextPart4487223.10NOO4Ka3b Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Donnerstag 15 Oktober 2009 22:17:36 schrieb Alexandru Petrescu: > Henning Rogge a =E9crit : > > Am Donnerstag 15 Oktober 2009 21:44:44 schrieb Alexandru Petrescu: > >> How about software implementing IETF standards, geared towards advanci= ng > >> on the Standards Track? > > > > The RFC conform implementation of OLSR does not work well. The > > Freifunk/Funkfeuer community networks (which are some of the largest > > deployed mesh networks) all use ETX because it does not work with > > hopcount. >=20 > Well it seems like a large effort indeed (you claim it as some of the > largest deployed mesh networks) - can I ping it? Most freifunk/funkfeuer networks are hidden between NAT routers that connec= t=20 the networks to a DSL line. I think Berlin was up to 700+ nodes some time ago, but it's a little bit=20 shrinking because DSL is easier to get today. Leipzig is and Vienna have hundreds of nodes too (Vienna 400-500 I think). > >> What are we talking about here? I more and more feel we live in very > >> different worlds. > > > > OLSRv2 WILL contain integrated metric support because everyone in the > > MANET-WG agrees that it's necessary. We are discussing about if we > > integrate ETX as the easiest (and layer 1/2 independant) metric as an > > appendix/example into the main draft or not at the moment. >=20 > Well that sounds as good news for ETX and OLSR. >=20 > Do you have some comment on link energy metrics? I think both link energy metrics and ETT have the potential to be a much=20 better metric than ETX. OLSR.org has ETX at the moment because it's the onl= y=20 metric we can support on different OS/hardware platforms. We hope to move t= o a=20 generic "linklayer data framework" soon, so we can start to experiment with= =20 ETT or similar metrics. Link energy metrics for WLAN are a little bit difficult because there are n= o=20 exact tables how many energy each specific hardware consumes for a package. Henning Rogge --nextPart4487223.10NOO4Ka3b Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkrXigQACgkQcenvcwAcHWc3VACeJMDE6pcS3x3dlAIB6DrZAQx8 cQYAnRagzfdPIkAtN4FfcroazZDDxLRe =AILD -----END PGP SIGNATURE----- --nextPart4487223.10NOO4Ka3b-- From pal@cs.stanford.edu Thu Oct 15 14:01:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE42A3A6839 for ; Thu, 15 Oct 2009 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF9XQJE+HfJZ for ; Thu, 15 Oct 2009 14:01:03 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 10AC43A67D9 for ; Thu, 15 Oct 2009 14:01:03 -0700 (PDT) Received: from dn0a20eb64.stanford.edu ([10.32.235.100]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MyXRa-0002ZS-7b; Thu, 15 Oct 2009 14:01:06 -0700 Message-Id: <96DF2DFC-8023-4CEA-9B56-AAA34EFC2FF2@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4AD77CC7.5000707@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 13:59:30 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <4AD7778D.7040708@gmail.com> <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> <4AD77CC7.5000707@gmail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6214ac49f2cb083a0c8190805312a710 Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 21:01:04 -0000 On Oct 15, 2009, at 12:49 PM, Alexandru Petrescu wrote: > Philip Levis a =E9crit : >> On Oct 15, 2009, at 12:27 PM, Alexandru Petrescu wrote: >>> Philip Levis a =E9crit : >>>> I think we should keep in mind that RPL must work across multiple =20= >>>> link layers. E.g.: >>>> A -- 900MHz --> B -- 2.4GHz --> C >>>> ETX is a commonly used metric, >>> >>> Philip, what do you mean by "ETX commonly used metric"? >>> >>> Could you please explain, in implementation terms. >>> >>> Could you list some widely available software in solid software =20 >>> distributions, widely deployed, and using this ETX metric? >> MIT Roofnet/srcr: http://pdos.csail.mit.edu/roofnet/software.php >> CTP: = http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/ctp= / >> OLSR: http://www.olsr.org/docs/README-Link-Quality.html > > Ah the World Wide Web, h t t p something, wikipedia and google and =20 > we know everything... > > The software being on a website doesn't tell anything about how much =20= > it is used. > > How about software which is not on h t t p something yet it runs ok. Meraki's technology is based on srcr (the Roofnet students from MIT =20 founded Meraki). Not an IETF standard, but a mesh protocol running on =20= 13,000+ networks, serving >4,000,000 clients. Srcr uses ETX/ETT. Sorry =20= for the http, it's to their web page, not the source code: http://meraki.com Phil= From alexandru.petrescu@gmail.com Thu Oct 15 14:16:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9489528C190 for ; Thu, 15 Oct 2009 14:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvEyzOnZ6Ae9 for ; Thu, 15 Oct 2009 14:16:40 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 6D2A328C18E for ; Thu, 15 Oct 2009 14:16:38 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 6977DD48D59; Thu, 15 Oct 2009 23:16:38 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 2639BD48B15; Thu, 15 Oct 2009 23:16:36 +0200 (CEST) Message-ID: <4AD79131.2080102@gmail.com> Date: Thu, 15 Oct 2009 23:16:33 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <4AD7778D.7040708@gmail.com> <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> <4AD77CC7.5000707@gmail.com> <96DF2DFC-8023-4CEA-9B56-AAA34EFC2FF2@cs.stanford.edu> In-Reply-To: <96DF2DFC-8023-4CEA-9B56-AAA34EFC2FF2@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 21:16:41 -0000 Philip Levis a écrit : > > On Oct 15, 2009, at 12:49 PM, Alexandru Petrescu wrote: > >> Philip Levis a écrit : >>> On Oct 15, 2009, at 12:27 PM, Alexandru Petrescu wrote: >>>> Philip Levis a écrit : >>>>> I think we should keep in mind that RPL must work across multiple >>>>> link layers. E.g.: >>>>> A -- 900MHz --> B -- 2.4GHz --> C >>>>> ETX is a commonly used metric, >>>> >>>> Philip, what do you mean by "ETX commonly used metric"? >>>> >>>> Could you please explain, in implementation terms. >>>> >>>> Could you list some widely available software in solid software >>>> distributions, widely deployed, and using this ETX metric? >>> MIT Roofnet/srcr: http://pdos.csail.mit.edu/roofnet/software.php >>> CTP: >>> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/ctp/ >>> >>> OLSR: http://www.olsr.org/docs/README-Link-Quality.html >> >> Ah the World Wide Web, h t t p something, wikipedia and google and we >> know everything... >> >> The software being on a website doesn't tell anything about how much >> it is used. >> >> How about software which is not on h t t p something yet it runs ok. > > Meraki's technology is based on srcr (the Roofnet students from MIT > founded Meraki). Not an IETF standard, but a mesh protocol running on > 13,000+ networks, serving >4,000,000 clients. Srcr uses ETX/ETT. Philip - how about some metric about which _you_ feel like you'd implement ok, and about which you feel like many people would agree with, and about which _you_ feel some people may need, and some usecases may need. (sorry being too direct to 'you', but that's what I mean, and no offence). Alex From alexandru.petrescu@gmail.com Thu Oct 15 14:27:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F77D28C180 for ; Thu, 15 Oct 2009 14:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_40=-0.185, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-55RLhEt93R for ; Thu, 15 Oct 2009 14:27:56 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id CE32E3A6918 for ; Thu, 15 Oct 2009 14:27:54 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 39692D48215; Thu, 15 Oct 2009 23:27:53 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id D776CD482DC; Thu, 15 Oct 2009 23:27:50 +0200 (CEST) Message-ID: <4AD793D4.5040409@gmail.com> Date: Thu, 15 Oct 2009 23:27:48 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <200910152153.21821.hrogge@googlemail.com> <4AD78360.7080807@gmail.com> <200910152245.56332.hrogge@googlemail.com> In-Reply-To: <200910152245.56332.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 21:27:57 -0000 Henning Rogge a écrit : > Am Donnerstag 15 Oktober 2009 22:17:36 schrieb Alexandru Petrescu: >> Henning Rogge a écrit : >>> Am Donnerstag 15 Oktober 2009 21:44:44 schrieb Alexandru Petrescu: >>>> How about software implementing IETF standards, geared towards advancing >>>> on the Standards Track? >>> The RFC conform implementation of OLSR does not work well. The >>> Freifunk/Funkfeuer community networks (which are some of the largest >>> deployed mesh networks) all use ETX because it does not work with >>> hopcount. >> Well it seems like a large effort indeed (you claim it as some of the >> largest deployed mesh networks) - can I ping it? > > Most freifunk/funkfeuer networks are hidden between NAT routers that connect > the networks to a DSL line. > > I think Berlin was up to 700+ nodes some time ago, but it's a little bit > shrinking because DSL is easier to get today. > > Leipzig is and Vienna have hundreds of nodes too (Vienna 400-500 I think). Sorry, I don't understand you. What do you mean by e.g. Vienna has 400-500 nodes? What do these nodes do? The DSL line I use does offer non-NAT and IPv6. How about Viena, Leipzig and Berlin? Also, you talk NAT: is ETX exclusively related to IPv4? Does OLSRv2 work with IPv6? >>>> What are we talking about here? I more and more feel we live in very >>>> different worlds. >>> OLSRv2 WILL contain integrated metric support because everyone in the >>> MANET-WG agrees that it's necessary. We are discussing about if we >>> integrate ETX as the easiest (and layer 1/2 independant) metric as an >>> appendix/example into the main draft or not at the moment. >> Well that sounds as good news for ETX and OLSR. >> >> Do you have some comment on link energy metrics? > > I think both link energy metrics and ETT have the potential to be a much > better metric than ETX. Ok, I don't know what ETT means. Expanding the abbreviation would suffice, don't send me to a paper. > OLSR.org has ETX at the moment because it's the only > metric we can support on different OS/hardware platforms. We hope to move to a > generic "linklayer data framework" soon, so we can start to experiment with > ETT or similar metrics. > > Link energy metrics for WLAN are a little bit difficult because there are no > exact tables how many energy each specific hardware consumes for a package. Well there is some publicly available specification data about how much Watts are needed, and dBm levels, for WiFi. When one says Watt one says Joule and time. There exist also measurements for WiFi emissions, and unpublished reports. Some relate to health studies. The lack of precision could be compensated by expressing the values as a range [min, max]. I am not sure that ETX and ETT(?) have been expressed and experimented for anything else than WiFi(?) Alex > > Henning Rogge From hrogge@googlemail.com Thu Oct 15 14:41:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6622728C0DE for ; Thu, 15 Oct 2009 14:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bQ0ol5amVNp for ; Thu, 15 Oct 2009 14:41:29 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id 6312C3A6882 for ; Thu, 15 Oct 2009 14:41:29 -0700 (PDT) Received: by ewy4 with SMTP id 4so1025699ewy.37 for ; Thu, 15 Oct 2009 14:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=VhdnVRiUX8/k46UNq7GcVeFHI8E8LF0cyqmPs9AyAa4=; b=cmYXF//7titEPajgj92rJ5ybCLlgqTpEpGE7Hp6AnA7SA11b/y+MCBLs0q7c7GW4K5 0FEN1vIX8xgFwBVWiOG9deMl56mfoXSsd1p6RKcBnjT4SUKfb3Z3byT/XlNGaX/6K+La Mvx1cL5Cpg4fDLil0fjGmhfDuGr0JYM7iNlEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=daO8cwFCgfIjgTE8VQKmaiXXRt+Q7p6HaeTjILAdTJv/ygWPF+jeM3milKwBkgU8N5 lrDdlRsLBvhmt5MPbB+C3TeDIKJW5IhzypkpWfc+PGF3oXIvKRGafHnvnlhP/SFGHwVL SU4jHYhxG7BOmbWwT/CmSImK/MfGVm7DOZUa4= Received: by 10.216.85.197 with SMTP id u47mr246001wee.133.1255642889920; Thu, 15 Oct 2009 14:41:29 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm78057eyg.10.2009.10.15.14.41.28 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 14:41:28 -0700 (PDT) From: Henning Rogge To: Alexandru Petrescu Date: Thu, 15 Oct 2009 23:41:23 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <200910152245.56332.hrogge@googlemail.com> <4AD793D4.5040409@gmail.com> In-Reply-To: <4AD793D4.5040409@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1890981.Jm6ZVpuT6Q"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910152341.27591.hrogge@googlemail.com> Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 21:41:32 -0000 --nextPart1890981.Jm6ZVpuT6Q Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Donnerstag 15 Oktober 2009 23:27:48 schrieb Alexandru Petrescu: > Henning Rogge a =E9crit : > > Most freifunk/funkfeuer networks are hidden between NAT routers that > > connect the networks to a DSL line. > > > > I think Berlin was up to 700+ nodes some time ago, but it's a little bit > > shrinking because DSL is easier to get today. > > > > Leipzig is and Vienna have hundreds of nodes too (Vienna 400-500 I > > think). >=20 > Sorry, I don't understand you. What do you mean by e.g. Vienna has > 400-500 nodes? What do these nodes do? Nodes as in OLSR instances running on a single embedded hardware with 1-3=20 interfaces. =20 > The DSL line I use does offer non-NAT and IPv6. How about Viena, > Leipzig and Berlin? At the moment all FF networks except one in South Africa (I think) are IPv4= =2E=20 IPv6 takes lot's of flash storage for the kernel part, most of our routers= =20 only have 2-4 MB of flash. > Also, you talk NAT: is ETX exclusively related to IPv4? Does OLSRv2 > work with IPv6? OLSRv1 (and the olsr.org implementation of it) can run in IPv4 or IPv6 mode. > > I think both link energy metrics and ETT have the potential to be a much > > better metric than ETX. >=20 > Ok, I don't know what ETT means. Expanding the abbreviation would > suffice, don't send me to a paper. ETT =3D Estimated Travel Time ETT =3D ETX / Transmission speed > > Link energy metrics for WLAN are a little bit difficult because there a= re > > no exact tables how many energy each specific hardware consumes for a > > package. >=20 > Well there is some publicly available specification data about how much > Watts are needed, and dBm levels, for WiFi. When one says Watt one says > Joule and time. >=20 > There exist also measurements for WiFi emissions, and unpublished > reports. Some relate to health studies. >=20 > The lack of precision could be compensated by expressing the values as a > range [min, max]. > > I am not sure that ETX and ETT(?) have been expressed and experimented > for anything else than WiFi(?) I think ETX is pretty easy to do on any kind of medium. ETT is a little bit= =20 more difficult because you have to know the transmission speed. Henning Rogge --nextPart1890981.Jm6ZVpuT6Q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkrXlwcACgkQcenvcwAcHWeMtgCeNx3n7mIZfUyZdiO0Q/IBWVrv Rn0An20B+xnQt0lAIvJteYaEXR4WkWPF =es9O -----END PGP SIGNATURE----- --nextPart1890981.Jm6ZVpuT6Q-- From alexandru.petrescu@gmail.com Thu Oct 15 15:03:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96AA53A6882 for ; Thu, 15 Oct 2009 15:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=0.673, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjqH+DyLjEp3 for ; Thu, 15 Oct 2009 15:03:19 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 544993A682B for ; Thu, 15 Oct 2009 15:03:17 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 24D02D4808E; Fri, 16 Oct 2009 00:03:16 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id C396BD4802D; Fri, 16 Oct 2009 00:03:13 +0200 (CEST) Message-ID: <4AD79C1F.1080304@gmail.com> Date: Fri, 16 Oct 2009 00:03:11 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <200910152245.56332.hrogge@googlemail.com> <4AD793D4.5040409@gmail.com> <200910152341.27591.hrogge@googlemail.com> In-Reply-To: <200910152341.27591.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 22:03:20 -0000 Henning Rogge a écrit : > Am Donnerstag 15 Oktober 2009 23:27:48 schrieb Alexandru Petrescu: >> Henning Rogge a écrit : >>> Most freifunk/funkfeuer networks are hidden between NAT routers that >>> connect the networks to a DSL line. >>> >>> I think Berlin was up to 700+ nodes some time ago, but it's a little bit >>> shrinking because DSL is easier to get today. >>> >>> Leipzig is and Vienna have hundreds of nodes too (Vienna 400-500 I >>> think). >> Sorry, I don't understand you. What do you mean by e.g. Vienna has >> 400-500 nodes? What do these nodes do? > > Nodes as in OLSR instances running on a single embedded hardware with 1-3 > interfaces. Ok. >> The DSL line I use does offer non-NAT and IPv6. How about Viena, >> Leipzig and Berlin? > > At the moment all FF networks except one in South Africa (I think) are IPv4. > IPv6 takes lot's of flash storage for the kernel part, most of our routers > only have 2-4 MB of flash. Err... an IPv6 stack doesn't take much more than IPv4 stack. If you can put an entire operating system (which seems to be a requirement of the OLSR daemon - linux/bsd/windows) then the stack is not much load. >> Also, you talk NAT: is ETX exclusively related to IPv4? Does OLSRv2 >> work with IPv6? > > OLSRv1 (and the olsr.org implementation of it) can run in IPv4 or IPv6 mode. So ETX is only for OLSRv2. So ETX is not for IPv6. Yet here we do IPv6. >>> I think both link energy metrics and ETT have the potential to be a much >>> better metric than ETX. >> Ok, I don't know what ETT means. Expanding the abbreviation would >> suffice, don't send me to a paper. > > ETT = Estimated Travel Time > > ETT = ETX / Transmission speed Ok. >>> Link energy metrics for WLAN are a little bit difficult because there are >>> no exact tables how many energy each specific hardware consumes for a >>> package. >> >> Well there is some publicly available specification data about how much >> Watts are needed, and dBm levels, for WiFi. When one says Watt one says >> Joule and time. >> >> There exist also measurements for WiFi emissions, and unpublished >> reports. Some relate to health studies. >> >> The lack of precision could be compensated by expressing the values as a >> range [min, max]. >> >> I am not sure that ETX and ETT(?) have been expressed and experimented >> for anything else than WiFi(?) > > I think ETX is pretty easy to do on any kind of medium. ETT is a little bit > more difficult because you have to know the transmission speed. I find difficult to implement a Bernoulli series. Me thinks there is not a single widely agreed rule of implementation of a Bernoulli series (Bernoulli is what ETX requires). Do you think there's a StdsTrack RFC which specifies a form of probability implementation? I don't think so. I am aware of the lengthy discussions of the probability of address collision - never documented, not agreeable, not implementable IMHO. Alex From hrogge@googlemail.com Thu Oct 15 15:19:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B6D3A682B for ; Thu, 15 Oct 2009 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sytIKj13ouEH for ; Thu, 15 Oct 2009 15:19:28 -0700 (PDT) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by core3.amsl.com (Postfix) with ESMTP id C2ABD3A67FA for ; Thu, 15 Oct 2009 15:19:27 -0700 (PDT) Received: by ewy4 with SMTP id 4so1054059ewy.37 for ; Thu, 15 Oct 2009 15:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=ihVTxF9NGpAa4L/nJgcbalGCVTWmZn1gBfOyYvXgpM0=; b=T8Q0Lo3AwxehtGKmZ4OcK99ROxneYkFIvyg8vJZ3ec5f7h6/LbgdcRleqGFB0Kp+S7 fgzQcOc1qhZTwKVeJ4IoQ9uMW43vF+R7s7ruHg+x+ax84FSFI2LVeZulqhVsPI+9hQ/Z PfL2ik2GBbr8UUJZ2YOW21+5uQ+3kOYOm4nCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=TBqsSHh0b2/y2Q/gCNNn5alHubAnn911TPQxRDxjgZ4YsKvz8CSCMrIqCgi/GXX9Hh FVJO8YXBLZyMErq1RpwiIcjzQ2g8yilEWy6V33n6KuoSiC99rA2BWD9/BXR6DQxpXqqW wtWK97sVhyUIusTG4KBj4+X1lwhAxMg/KQcg4= Received: by 10.216.86.16 with SMTP id v16mr301043wee.162.1255645168768; Thu, 15 Oct 2009 15:19:28 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm138935eyg.10.2009.10.15.15.19.27 (version=SSLv3 cipher=RC4-MD5); Thu, 15 Oct 2009 15:19:27 -0700 (PDT) From: Henning Rogge To: Alexandru Petrescu Date: Fri, 16 Oct 2009 00:19:21 +0200 User-Agent: KMail/1.12.2 (Linux/2.6.31-gentoo-r2; KDE/4.3.2; x86_64; ; ) References: <200910152341.27591.hrogge@googlemail.com> <4AD79C1F.1080304@gmail.com> In-Reply-To: <4AD79C1F.1080304@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2869566.q6gBvSbcxR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910160019.26638.hrogge@googlemail.com> Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 22:19:29 -0000 --nextPart2869566.q6gBvSbcxR Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Freitag 16 Oktober 2009 00:03:11 schrieb Alexandru Petrescu: > > At the moment all FF networks except one in South Africa (I think) are > > IPv4. IPv6 takes lot's of flash storage for the kernel part, most of our > > routers only have 2-4 MB of flash. >=20 > Err... an IPv6 stack doesn't take much more than IPv4 stack. If you can > put an entire operating system (which seems to be a requirement of the > OLSR daemon - linux/bsd/windows) then the stack is not much load. it's hundreds of kilobytes. That's much if your whole operation system is=20 stored in 2 megabytes of flash. =20 > >> Also, you talk NAT: is ETX exclusively related to IPv4? Does OLSRv2 > >> work with IPv6? > > > > OLSRv1 (and the olsr.org implementation of it) can run in IPv4 or IPv6 > > mode. >=20 > So ETX is only for OLSRv2. No=20 > So ETX is not for IPv6. No > Yet here we do IPv6. Yes ETX is totally independant from IP version or mesh net protocol. > I find difficult to implement a Bernoulli series. Me thinks there is > not a single widely agreed rule of implementation of a Bernoulli series > (Bernoulli is what ETX requires). ETX calculation based on received/lost hello messages is very easy. Henning Rogge --nextPart2869566.q6gBvSbcxR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkrXn+4ACgkQcenvcwAcHWdUsQCfbgrLWqyhREcixQITCa/hT1RJ abwAn3oG8ROSkekPW4VA+ZBMfJ6RFZNZ =ozRl -----END PGP SIGNATURE----- --nextPart2869566.q6gBvSbcxR-- From alexandru.petrescu@gmail.com Thu Oct 15 15:48:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CBF28C18E for ; Thu, 15 Oct 2009 15:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.883 X-Spam-Level: X-Spam-Status: No, score=-0.883 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk8yHCNzwjl2 for ; Thu, 15 Oct 2009 15:48:31 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 4FD7228C182 for ; Thu, 15 Oct 2009 15:48:29 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 95526D48069; Fri, 16 Oct 2009 00:48:29 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9DF94D4809D; Fri, 16 Oct 2009 00:48:25 +0200 (CEST) Message-ID: <4AD7A6B6.7080903@gmail.com> Date: Fri, 16 Oct 2009 00:48:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <200910152341.27591.hrogge@googlemail.com> <4AD79C1F.1080304@gmail.com> <200910160019.26638.hrogge@googlemail.com> In-Reply-To: <200910160019.26638.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091014-0, 14/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 22:48:32 -0000 Henning Rogge a écrit : > Am Freitag 16 Oktober 2009 00:03:11 schrieb Alexandru Petrescu: >>> At the moment all FF networks except one in South Africa (I think) are >>> IPv4. IPv6 takes lot's of flash storage for the kernel part, most of our >>> routers only have 2-4 MB of flash. >> Err... an IPv6 stack doesn't take much more than IPv4 stack. If you can >> put an entire operating system (which seems to be a requirement of the >> OLSR daemon - linux/bsd/windows) then the stack is not much load. > > it's hundreds of kilobytes. That's much if your whole operation system is > stored in 2 megabytes of flash. Well 200kbytes is 1/10 of your memory, dedicated to the stack. I find it fair. How big is your olsrd running? >>>> Also, you talk NAT: is ETX exclusively related to IPv4? Does OLSRv2 >>>> work with IPv6? >>> OLSRv1 (and the olsr.org implementation of it) can run in IPv4 or IPv6 >>> mode. >> So ETX is only for OLSRv2. > No Does OLSRv2 run IPv6 and ETX? >> I find difficult to implement a Bernoulli series. Me thinks there is >> not a single widely agreed rule of implementation of a Bernoulli series >> (Bernoulli is what ETX requires). > > ETX calculation based on received/lost hello messages is very easy. Hmm... not sure what you mean but I hear "received/lost" as some form of retransmission. I'd say that a metric should be something intrinsic to the link, not something calculable by heartbeats/hellos. E.g. a hopcount metric is intrinsic to the link (1 link is 1 hop, 2 links 2 hops), the qos/bandwidth are intrinsic to the link, the latency, etc. But of course, it is ok to propose differently. This makes me think that we may want to define what we mean by a "metric". A "routing metric" - ok, but what else? What are the requirements for defining a "routing metric"? We should also mention it being different than a performance metric. And needed by a routing protocol - and that routing protocol not necessarily RPL, but mostly RPL. Alex > > Henning Rogge From pthubert@cisco.com Thu Oct 15 22:30:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C702D3A6836 for ; Thu, 15 Oct 2009 22:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.776 X-Spam-Level: X-Spam-Status: No, score=-9.776 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUE6Wx0ETA1x for ; Thu, 15 Oct 2009 22:30:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6C63D3A67F3 for ; Thu, 15 Oct 2009 22:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1919; q=dns/txt; s=amsiport01001; t=1255671062; x=1256880662; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20Informed=20move=20[was: =20A=20proposal=20for=20Traffic=20Loop|Date:=20Fri,=2016 =20Oct=202009=2007:30:41=20+0200|Message-ID:=20<6A2A45917 5DABE4BB11DE2026AA50A5D6DD784@XMB-AMS-107.cisco.com>|To: =20"Anders=20Jagd"=20,=20"Muk ul=20Goyal"=20|Cc:=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<000d01ca4dbd$fd62d1b0$f8287510$ @jagd@ekasystems.com>|References:=20<000d01ca4dbd$fd62d1b 0$f8287510$@jagd@ekasystems.com>; bh=3KCWjrg+LWjpjFNppMdQCvCcv+V6OqZOYC/+MkvElBI=; b=fGl0zGbbBCCnsB6wiSA5unKsPWC7tWNoH0AacffB7m/3Kfsp5z4YDh2/ ucV5ewKinUXAlPIVNC26FTmB268yBYoKmY+U68hZDgoa76tkBlGiuuTPv +PaEZWCPBPIvdhdpG22ofbRHRbz3D1JHR5qiaK9wWhFDBkNP89tRtUkT3 k=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAALeh10qQ/uCWe2dsb2JhbACbEgEBFiQGpQ6YE4QwBIpx X-IronPort-AV: E=Sophos;i="4.44,570,1249257600"; d="scan'208";a="51947161" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2009 05:31:01 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9G5V1To002027; Fri, 16 Oct 2009 05:31:01 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 07:31:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 07:30:41 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6DD784@XMB-AMS-107.cisco.com> In-Reply-To: <000d01ca4dbd$fd62d1b0$f8287510$@jagd@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Informed move [was: A proposal for Traffic Loop Thread-Index: AcpNvfyhBXNhT3YgRNKPTlFO9mX84AAX73Yg References: <000d01ca4dbd$fd62d1b0$f8287510$@jagd@ekasystems.com> From: "Pascal Thubert (pthubert)" To: "Anders Jagd" , "Mukul Goyal" X-OriginalArrivalTime: 16 Oct 2009 05:31:00.0918 (UTC) FILETIME=[D8A6D560:01CA4E21] Cc: roll@ietf.org Subject: Re: [Roll] Informed move [was: A proposal for Traffic Loop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 05:30:59 -0000 Hi Anders, You are correct. I also had a chat with Mukul about that as we work on the FSM. There are a number of reasons why the node will have to look at RAs from below and we need to change that text.=20 These might include: - if the deeper neighbor as a better OCP metrics then remember it for the next sequence so as not to jump too early too high - if the deeper neighbor is a parent or a sibling going down, then it must be eliminated from the list. The new text will probably be that higher rank is not immediately selectable. The node has to wait for a new sequence, or detach/reattach upon a loss of parents. We are still waiting for the results of the poll but got few answers. Pascal >-----Original Message----- >From: Anders Jagd [mailto:anders.jagd@ekasystems.com] >Sent: jeudi 15 octobre 2009 19:36 >To: Pascal Thubert (pthubert) >Cc: roll@ietf.org >Subject: Re: [Roll] Informed move [was: A proposal for Traffic Loop > >Pascal, > >You wrote: > >>The draft actually allows moving to a higher rank but there's a catch. >>Whereas a node can reattach right away to obtain a better rank, it needs to >play a little dance that includes detach, wait & see before it can >attach >at a higher rank. > >Wouldn't the following statement in 03 deal with exactly that "loop-hole" ? > >(From 5.3.2.1. Determination of Eligibility for DIO Processing) >2188 If the rank of SRC as reported in the RA-DIO message is higher >2189 than that of the node within the DAG, and SRC is not a DAG >2190 parent, then the RA-DIO message MUST NOT be considered for >2191 further processing > >However, my real question is then whether there are any ideas on how to >enforce such a "MUST NOT" (or even detect a violation) ? Some implementation >may try to differentiate itself by ignoring it. Having a rule that is not >detectable/enforceable seems problematic. > >/Anders From privateanand@gmail.com Thu Oct 15 22:38:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE90E28C13B for ; Thu, 15 Oct 2009 22:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6Un+l+bfVEB for ; Thu, 15 Oct 2009 22:38:20 -0700 (PDT) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id C10C228C136 for ; Thu, 15 Oct 2009 22:38:20 -0700 (PDT) Received: by iwn16 with SMTP id 16so940509iwn.29 for ; Thu, 15 Oct 2009 22:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=vael4jF/cG48Ut9AYepyYavO3l3b7w2qn1D5vjeIAhw=; b=rRzXq8HDn/ayE897iuj7Fb/qbzeeawrZzug6E2e00iro/HggUWrIWOPlFvt4KANlXB v4X4MKAT4yMad1oML7eR0W8w0NymD35bCWZ6Y0RRpml7j8xe97MLo2yuQjBaKW16HDv1 45cqmiEFTUsH17VMbWegOGLQWWkjeqx2SbolE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=h37LQNr4bqX3mtOpHRAyxwvLkJxvIbnCMOssjTGHTsnXPK/vNGGHAEabK9MgVqx+hz sc9Uc2QZfz0Qpd5MPEQtDD6eu/MWVy8aH+pUYt54Z/Qp+/1whv0ZY+MIMkw88iHJe6AV 2vR6wHQ4C6mhU57mttSZELFU89TBCunhAUR/8= MIME-Version: 1.0 Received: by 10.231.122.208 with SMTP id m16mr3404146ibr.16.1255671502103; Thu, 15 Oct 2009 22:38:22 -0700 (PDT) In-Reply-To: <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> Date: Fri, 16 Oct 2009 01:38:21 -0400 Message-ID: From: "M. B. Anand" To: roll ROLL Content-Type: multipart/alternative; boundary=0016e64078f0d665ee047606cd7a Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 05:38:22 -0000 --0016e64078f0d665ee047606cd7a Content-Type: text/plain; charset=ISO-8859-1 I am not quite sure I understand the motivation for considering even less hard "lifetime" (assuming this refers to life of some limited energy source). After all, at a system level, it has to be designed so the that the life is enough for the application accounting for that subset of nodes that must try their hardest all the time in terms of consuming energy - use their highest available tx power, the slowest bitrate and the slowest code rate if those is variable,. You might argue it is a bonus if a node used less than the design and therefore last longer, but then you might simply shift the problem to some other node which has to reduce some of its lifetime forwarding. So, isn't it the case the whole thing only shifts around the bonus lifetime beyond the minimum design in varying ways among the nodes ? Instead, I would think the link metric should only worry about capturing the link's ability to get things across, no ? Lower tx power will be used if possible on any link, but that is matter safely and correctly left to the lower layer power control mechanisms. Of course, I do operate in the 20 - 30 dBm world (where, on a completely tangential note, in case anyone missed Phillip's careful wording of "In low-power wireless chipsets..", it is not true that CMOS dominates), so feel free to clobber me over the head if I am missing something. Regards, Anand. On Thu, Oct 15, 2009 at 12:49 AM, Philip Levis wrote: > I think we should keep in mind that RPL must work across multiple link > layers. E.g.: > > A -- 900MHz --> B -- 2.4GHz --> C > > ETX is a commonly used metric, but typically under two simplifying > assumptions: > > 1) Routes are composed of a single link layer > 2) The link layer has a static bitrate > > If you break either assumption, it doesn't work well. ETT (expected time of > transmission) can address 2), but not 1). > > I'm wary of encoding a metric as a hard quantity. For example, quantifying > the metric as uJ breaks when nodes have differential energy capacities. What > we really want is a more abstract notion of cost, which a particular device > can use to, in a very simple way, express its own tradeoffs. It is critical > that exactly how devices calculate this value remain unspecified. > > My first thought would be a quantification of how much of a node's > "lifetime" a packet would cost. Such a cost can consider both the receiver > and transmitter. E.g., given its particular low power algorithms and > expected lifetime, how much would sending to this destination consume? (I > try to avoid using the word "link.") > > > --0016e64078f0d665ee047606cd7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not quite sure I understand the motivation for considering even less h= ard "lifetime" (assuming this refers to life of some limited ener= gy source).

After all, at a system level, it has to be designed so t= he that the life is enough for the application accounting for that subset o= f nodes that must try their hardest all the time in terms of consuming ener= gy - use their highest available tx power, the slowest bitrate and the slow= est code rate if those is variable,.

You might argue it is a bonus if a node used less than the design and t= herefore last longer, but then you might simply shift the problem to some o= ther node which has to reduce some of its lifetime forwarding. So, isn'= t it the case the whole thing only shifts around the bonus lifetime beyond = the minimum design in varying ways among the nodes ?

Instead, I would think the link metric should only worry about capturin= g the link's ability to get things across, no ? Lower tx power will be = used if possible on any link, but that is matter safely and correctly left = to the lower layer power control mechanisms.

Of course, I do operate in the 20 - 30 dBm world (where, on a completel= y tangential note, in case anyone missed Phillip's careful wording of &= quot;In low-power wireless chipsets..", it is not true that CMOS domin= ates), so feel free to clobber me over the head if I am missing something.<= br>
Regards,
Anand.

=A0

On Thu,= Oct 15, 2009 at 12:49 AM, Philip Levis <pal@cs.stanford.edu> wrote:
I think we should keep in mind that RPL must work across multiple link laye= rs. E.g.:

A -- 900MHz --> B -- 2.4GHz --> C

ETX is a commonly used metric, but typically under two simplifying assumpti= ons:

1) Routes are composed of a single link layer
2) The link layer has a static bitrate

If you break either assumption, it doesn't work well. ETT (expected tim= e of transmission) can address 2), but not 1).

I'm wary of encoding a metric as a hard quantity. For example, quantify= ing the metric as uJ breaks when nodes have differential energy capacities.= What we really want is a more abstract notion of cost, which a particular = device can use to, in a very simple way, express its own tradeoffs. It is c= ritical that exactly how devices calculate this value remain unspecified.
My first thought would be a quantification of how much of a node's &quo= t;lifetime" a packet would cost. Such a cost can consider both the rec= eiver and transmitter. E.g., given its particular low power algorithms and = expected lifetime, how much would sending to this destination consume? (I t= ry to avoid using the word "link.")



--0016e64078f0d665ee047606cd7a-- From pthubert@cisco.com Thu Oct 15 22:50:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55BB73A6783 for ; Thu, 15 Oct 2009 22:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.813 X-Spam-Level: X-Spam-Status: No, score=-7.813 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtGrVOJwe-jz for ; Thu, 15 Oct 2009 22:50:56 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 9C9643A687F for ; Thu, 15 Oct 2009 22:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4044; q=dns/txt; s=sydiport01001; t=1255672260; x=1256881860; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20Ew:=20=20RPL=20Design=20 Questions|Date:=20Fri,=2016=20Oct=202009=2007:50:46=20+02 00|Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D6DD786@ XMB-AMS-107.cisco.com>|To:=20"Anders=20Jagd"=20,=20|Cc:=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quo ted-printable|In-Reply-To:=20<000901ca4dbc$c566f5d0$5034e 170$@jagd@ekasystems.com>|References:=20<000901ca4dbc$c56 6f5d0$5034e170$@jagd@ekasystems.com>; bh=ncJF8oBNEAaaqNox44uEHbPLdkpcla58JNI9IaoOGCY=; b=ZKtp/Px4GaOXQYfI5Mk22Civa4OmIEVV5q5TWrxAA2v9ePl+xzkIx/DQ LgMSSnDlS7pywRXTWlMpOGQAHSxwvcnED0b+jhKrfnGJCA3hgn0S9IgxZ AoT0nPjRE4fDT7VVHkG8L70k0xSni4qEV0NwN1LfOGZzSO3uG0blBahSs 0=; Authentication-Results: syd-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACqm10qQ/uCW/2dsb2JhbADAVJgWgjmBdwQ X-IronPort-AV: E=Sophos;i="4.44,570,1249257600"; d="scan'208";a="62243562" Received: from ams-core-1.cisco.com ([144.254.224.150]) by syd-iport-1.cisco.com with ESMTP; 16 Oct 2009 05:50:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9G5oq1B004152; Fri, 16 Oct 2009 05:50:52 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 07:50:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 07:50:46 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6DD786@XMB-AMS-107.cisco.com> In-Reply-To: <000901ca4dbc$c566f5d0$5034e170$@jagd@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Ew: RPL Design Questions Thread-Index: AcpNvMQZ043KuHqiR9qz7kyxgMGqBQAZZRzw References: <000901ca4dbc$c566f5d0$5034e170$@jagd@ekasystems.com> From: "Pascal Thubert (pthubert)" To: "Anders Jagd" , X-OriginalArrivalTime: 16 Oct 2009 05:50:51.0876 (UTC) FILETIME=[9E849A40:01CA4E24] Cc: roll@ietf.org Subject: Re: [Roll] Ew: RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 05:50:57 -0000 Hi Anders: All you're saying makes good sense. You might want to include additional things in your reasoning about A+B) As you point out, our route poisoning technique aims at lowering the odds of jumping in a hole. The chances can be estimated from the loss ratio on RAs. The timer can be set to cover one round trip RA/ RA echo, or multiple trickled RAs if that is determined to influence the odds in an important fashion. The protocol as will be complemented by a loop detection mechanism. A proposal was already posted "A proposal for Traffic Loop avoidance, detection and recovery". The loop detection is required even if we do not do A+B, to cover the window till DAG rebuilds, siblings loops and DAO loss loops. The local route poisoning and the global DAG rebuild provide really different services and operate at a very different level. =20 My own take is to have both if we can afford that. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Anders Jagd >Sent: jeudi 15 octobre 2009 19:27 >To: wintert@acm.org >Cc: roll@ietf.org >Subject: [Roll] Ew: RPL Design Questions > >Tim, > >As for your questions: > >>Question A: Should RPL make use of the currently proposed local ... >>Question B: Should RPL make use of a hold-up timer and related ... >>Question C: Should RPL make use of a hold-down timer and related ... > >A+B: > >My opinion would be that a Sequence number/"Heartbeat" scheme generally >provides a more reliable, efficient, and simple method compared to timer >based approaches. > >Determining reasonable settings for timer(s) may prove difficult, and no >matter what value is chosen, there is no guarantee that the scheme achieves >the intended goal, rather a likelihood. Not that I am in general against >"likelihoods", as long as they are not "too small" (not good enough), >neither "too large" (too expensive/conservative) - something not trivial to >achieve, in particular since nodes/roots rarely/never have complete atomic >snapshots in time of the full DAG, and even if they did, the DAG could be >quite unbalanced with a mix of short and long branches. > >After deciding on (or occasionally adjusting) proper timer values, those >values then have to be propagated. As of 03 this is through RA-DIO. It does >appear a bit wasteful to continuously broadcast values that typically are >quite static. However, new nodes need to be informed, so if it is not done >regularly through RA-DIO, some other way would have to be defined, basically >some signaling scheme. Either way, this sounds "expensive". > >The sequence number approach has little to no timers involved; as soon as a >new sequence number is observed, a node is good to go (merge). It appears to >basically be a semi "self-timed" approach ("semi" since root, but only root, >may need a timer for triggering the heartbeat). How frequently should this >heartbeat (sequence number increment) then happen ? Again, we run into the >"too short/too long" discussion. But what if a node wishing to merge into a >DAG (and thus needing to see a new SQN), could be allowed to request the >root to increment the sequence number ? If any other heartbeat trigger is >required, it could probably be chosen quite conservatively, and the value >certainly would not have to be propagated. > >Bursts of such "increment SQN" requests could be reduced by some form of >aggregation: Any node issuing or forwarding a "SQN update request" would >stop forwarding other such requests (drop them) until it sees a new SQN. > >C: I think some form of mechanism to limit flapping is important, but again, >I would ask how to determine and configure/propagate a proper timer value. >Can we somehow base it on the heartbeat instead (maybe multiple heartbeats) >? > >/Anders > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From henning.rogge@fkie.fraunhofer.de Thu Oct 15 23:35:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDA93A6889 for ; Thu, 15 Oct 2009 23:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqIge9d0CbSd for ; Thu, 15 Oct 2009 23:35:34 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 28EC53A693C for ; Thu, 15 Oct 2009 23:35:33 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MygPY-0000DU-0f; Fri, 16 Oct 2009 08:35:36 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MygPX-0004gF-OF; Fri, 16 Oct 2009 08:35:35 +0200 From: Henning Rogge To: roll@ietf.org Date: Fri, 16 Oct 2009 08:35:59 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <200910160019.26638.hrogge@googlemail.com> <4AD7A6B6.7080903@gmail.com> In-Reply-To: <4AD7A6B6.7080903@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7018867.r1Y1qOZP7t"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910160836.05218.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9904/Fri Oct 16 06:47:19 2009) by mailguard.fgan.de X-Scan-Signature: 3cc81a0dd098837b5944ec75a71728c5 Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 06:35:35 -0000 --nextPart7018867.r1Y1qOZP7t Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri October 16 2009 00:48:22 schrieb Alexandru Petrescu: > > it's hundreds of kilobytes. That's much if your whole operation system = is > > stored in 2 megabytes of flash. > > Well 200kbytes is 1/10 of your memory, dedicated to the stack. I find > it fair. It's 10% of our "hard disk". And that is without the necessary userspace=20 programs. Most people running a Freifunk node would consider it a waste of= =20 space. Luckily linux got LZMA compression support for the kernel, so we hav= e=20 chances to get IPv6 support into the default firmwares. > How big is your olsrd running? 100-200 kb I think. Depends on the amount of debug/logging code and the=20 architecture. In addition to this you can add a number of plugins into our= =20 routing code. > >> So ETX is only for OLSRv2. > > > > No > > Does OLSRv2 run IPv6 and ETX? OLSRv2 is a protocol (in draft status). It can easily be used with IPv6 and= =20 any kind of routing metric. The Olsr.org implementation does run OLSRv1 (with or without ETX, with IPv4= or=20 IPv6) at the moment, but I'm in the process implementing OLSRv2 (again, wit= h=20 any kind of routing metric and with IPv4/6). > > ETX calculation based on received/lost hello messages is very easy. > > Hmm... not sure what you mean but I hear "received/lost" as some form of > retransmission. > > I'd say that a metric should be something intrinsic to the link, not > something calculable by heartbeats/hellos. E.g. a hopcount metric is > intrinsic to the link (1 link is 1 hop, 2 links 2 hops), the > qos/bandwidth are intrinsic to the link, the latency, etc. > > But of course, it is ok to propose differently. The easiest way (not the best) to calculate ETX is to measure the amount of= =20 loss in both directions of the link with probing packets (hello messages fo= r=20 example). Then you just use exponential aging or a binary buffer to calcula= te=20 the average loss rate LQ/NLQ and use them to define your ETX value=20 (ETX=3D1/(LQ*NLQ)). > This makes me think that we may want to define what we mean by a > "metric". A "routing metric" - ok, but what else? > > What are the requirements for defining a "routing metric"? Routing metrics can be anything. =2D they can be a constant (hopcount) =2D they can be based on money (how much does this link cost to send traffi= c=20 over) =2D they can be measured on the link (ETX, ETT, energy, SNR, ect.) =2D they can be based on security considerations (only route traffic throug= h=20 nodes you trust enough) =2D they can be some internal state of the router (hardware/battery resourc= es of=20 the router) and of course multiple kind of metrics can be combined (that's whats called= =20 objective function in RPL). > We should also mention it being different than a performance metric. Performance (transmission speed for example) can be a routing metric too. That would be useful for QoS in mesh networks. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart7018867.r1Y1qOZP7t Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrYFE8ACgkQRIfGfFXsz+DR3ACdEZ12oz+d2Db2Q3K0prLyX519 kToAnjFdFqW9xLZ/MZlNHUNpo6X12+GV =450h -----END PGP SIGNATURE----- --nextPart7018867.r1Y1qOZP7t-- From mdurvy@cisco.com Fri Oct 16 00:11:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1584E3A6994 for ; Fri, 16 Oct 2009 00:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.67 X-Spam-Level: X-Spam-Status: No, score=-9.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND2Tbvfdard8 for ; Fri, 16 Oct 2009 00:11:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A657A3A68A2 for ; Fri, 16 Oct 2009 00:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=1488; q=dns/txt; s=amsiport01001; t=1255677121; x=1256886721; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20RE:=20[Roll]=20RPL=20Design=20Question:=20D IO/DAO=20Transport|Date:=20Fri,=2016=20Oct=202009=2009:11 :58=20+0200|Message-ID:=20<8A977BDC5A7B0E429B0F521E8D6F91 EE8021D7@XMB-AMS-103.cisco.com>|To:=20"Tim=20Winter"=20,=20"ROLL=20WG"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<4AD75A9F.6070803@acm.org> |References:=20<4AD75A9F.6070803@acm.org>; bh=O9kut97Ww3AkG7nxV8YtPyUaedAK9w8RORBFQGt+IM8=; b=ob/ZQ+FvICJZz8xMwizyS0I01ldZGSrgn+55oQTrGJs72hH4dr06BWhF v49RszJ89xzpvqYlamlh6iiJZMNR8rLH0ujQgri4/FnJivLRgVXXKfYZw b77YyGfVb+Q8mtqHUVvdDTgOqVvbnJUUrYsMuDTeK4zzGCw6ltPkHW/D0 M=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAACu510qQ/uCWe2dsb2JhbACbEwEBFiQGpFiYHYQwBA X-IronPort-AV: E=Sophos;i="4.44,570,1249257600"; d="scan'208";a="51949676" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Oct 2009 07:11:59 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9G7BxEV021807; Fri, 16 Oct 2009 07:11:59 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 09:11:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 09:11:58 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE8021D7@XMB-AMS-103.cisco.com> In-Reply-To: <4AD75A9F.6070803@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Design Question: DIO/DAO Transport Thread-Index: AcpNvEXD/6aulRlJQ2WtnnC6sOoIZQAcsS7Q References: <4AD75A9F.6070803@acm.org> From: "Mathilde Durvy (mdurvy)" To: "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 16 Oct 2009 07:11:59.0365 (UTC) FILETIME=[F3C47B50:01CA4E2F] Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 07:11:58 -0000 Hi Tim, I would vote for 2). My impression is that it would be more flexible (no contradictory interaction between ND timers and RPL timers). I also think it would allow for a cleaner implementation of RPL (clearer separation between the routing algorithm functionalities and the NS/NA processing). Best, Mathilde=20 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: jeudi, 15. octobre 2009 19:24 To: ROLL WG Subject: [Roll] RPL Design Question: DIO/DAO Transport WG, There has been some feedback regarding the implications of using Neighbor Discovery RA/NA to carry DIO/DAO for RPL. The functionality provided by DIO/DAO may be seen as a natural extension to ND, but there are concerns regarding the implications of overloading ND for use by RPL. Another option would be to request the allocation of ICMP messages to transport the DIO/DAO. What do you think? 1) Let RPL use RA/NA for DIO/DAO transport 2) Allocate 2 new ICMP messages for DIO/DAO and operate independent of ND Please do keep in mind that this would serve as a base recommendation for the core protocol, and does not necessarily preclude that another implementation-specific binding outside of the scope of RPL (e.g. 6LowPAN) may do things differently. Thanks, -RPL Authors _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From zach@sensinode.com Fri Oct 16 00:22:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190E13A6A31 for ; Fri, 16 Oct 2009 00:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ano6aTc9kGLL for ; Fri, 16 Oct 2009 00:22:01 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BF9FB3A69AA for ; Fri, 16 Oct 2009 00:22:00 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9G7LutK025742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Oct 2009 10:21:57 +0300 Message-Id: From: Zach Shelby To: Tim Winter In-Reply-To: <4AD75A9F.6070803@acm.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 10:21:57 +0300 References: <4AD75A9F.6070803@acm.org> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 07:22:02 -0000 On Oct 15, 2009, at 20:23 , Tim Winter wrote: > > What do you think? > 1) Let RPL use RA/NA for DIO/DAO transport > 2) Allocate 2 new ICMP messages for DIO/DAO and operate = independent =20 > of ND > I vote for 2. I agree with many on the list that it is a cleaner separation =20 regarding timers and implementation. As there will be some differences =20= as well between RFC4861 and 6LoWPAN-ND - this also makes RPL =20 universal for both regarding DIO/DAO. > Please do keep in mind that this would serve as a base =20 > recommendation for > the core protocol, and does not necessarily preclude that another > implementation-specific binding outside of the scope of RPL (e.g. =20 > 6LowPAN) > may do things differently. This makes sense. I would find it useful if RPL would specify the DIO/=20= DAO messages in such a way that they could be easily carried as an =20 ICMP option piggybacked e.g. on ND messages in an implementation-=20 specific binding. Zach > > > Thanks, > > -RPL Authors > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Fri Oct 16 00:27:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B7F3A6A40 for ; Fri, 16 Oct 2009 00:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwyU4t2wL6+8 for ; Fri, 16 Oct 2009 00:27:27 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 6C7EC3A6A24 for ; Fri, 16 Oct 2009 00:27:26 -0700 (PDT) Received: from [10.42.43.10] ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n9G7RQBH026246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Oct 2009 10:27:27 +0300 Message-Id: <413CDE4E-FA25-4D66-AF44-A516FDFBE4FE@sensinode.com> From: Zach Shelby To: Michael Richardson In-Reply-To: <25979.1255635060@marajade.sandelman.ca> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 10:27:28 +0300 References: <4AD75A9F.6070803@acm.org> <25979.1255635060@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) Cc: ROLL WG Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 07:27:28 -0000 On Oct 15, 2009, at 22:31 , Michael Richardson wrote: > >>>>>> "Tim" =3D=3D Tim Winter writes: > Tim> What do you think? > > I think that I do not have enough information yet. > I would like to spend some more time understanding how RPL and 6LoWPAN > interact. > > In particular, if we use RA/NA for DIO, will it work to use NR/NC > instead messages in 6LoWPAN, or does it create a chicken/egg problem. Sure, it would work nicely in my opinion (no chicken/egg problems). =20 However it makes the RPL specification much simpler and cleaner, =20 avoids timing problems and a mangled implementation if the base =20 protocol assumes its own messages. And right now RPL needs serious =20 simplification. That said, the design team has the right approach that if a vendor or =20= specific application of RPL wanted to, they could decide to bind DIO/=20 DAO on other ICMP messages such as ND-specific ones. Such a binding =20 should be specified in a separate I-D later on if found useful by a =20 critical mass. Zach > > I have an email from Pascal to properly understand and reply to, so =20= > can > we defer this decision a week? > > --=20 > ] He who is tired of Weird Al is tired of life! | =20 > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net =20= > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |=20 > device driver[ > Kyoto Plus: watch the video = > > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From pthubert@cisco.com Fri Oct 16 01:00:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7736A3A69C5 for ; Fri, 16 Oct 2009 01:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.761 X-Spam-Level: X-Spam-Status: No, score=-7.761 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPSU-3vORiJP for ; Fri, 16 Oct 2009 01:00:27 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 769DC3A685D for ; Fri, 16 Oct 2009 01:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3217; q=dns/txt; s=sjiport06001; t=1255680030; x=1256889630; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20RPL=20Design=20Question: =20DIO/DAO=20Transport|Date:=20Fri,=2016=20Oct=202009=200 9:58:57=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2026A A50A5D6DD7EE@XMB-AMS-107.cisco.com>|To:=20"Mathilde=20Dur vy=20(mdurvy)"=20,=0D=0A=20=20=20=20=20 =20=20=20"Tim=20Winter"=20,=20"ROLL=20WG "=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<8A977BDC5A7B0E429B0F521E8D6F91EE8021D7@X MB-AMS-103.cisco.com>|References:=20<4AD75A9F.6070803@acm .org>=20<8A977BDC5A7B0E429B0F521E8D6F91EE8021D7@XMB-AMS-1 03.cisco.com>; bh=JNWNEyoFiV0EPusMfEu6xl24HopGlxSimdfPQ5NWnoY=; b=fgVUfbUR5IveEr8R4qyQ6ns0BvqsOpCvDsqz+WXgKKtTstYbNlYbpHak QIjRBIKL7a526/5QI2mMheVcFrPqbBZjPyjhSiXp50sxusJazxG20RZnv QvzY+wa0ko26NpdmvWDwHUUS+1dcpsHUdR4a3iHVbBl10K7XEixmgXkNn A=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFfF10qrR7H+/2dsb2JhbADALZgXhDAE X-IronPort-AV: E=Sophos;i="4.44,571,1249257600"; d="scan'208";a="410653295" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Oct 2009 07:59:48 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9G7wiLN022181; Fri, 16 Oct 2009 07:59:48 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 09:59:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 09:58:57 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6DD7EE@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE8021D7@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Design Question: DIO/DAO Transport Thread-Index: AcpNvEXD/6aulRlJQ2WtnnC6sOoIZQAcsS7QAAEqxBA= References: <4AD75A9F.6070803@acm.org> <8A977BDC5A7B0E429B0F521E8D6F91EE8021D7@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 16 Oct 2009 07:59:05.0660 (UTC) FILETIME=[885EDFC0:01CA4E36] Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 08:00:31 -0000 Hi Tim: I vote for reusing what's already there because it may provide a lighter footprint in additional code and airspace for RPL. That was true for me but I understand it might not be for every other implementation. So I vote for 1) I am not too concerned about the timer mangling because the rate of ND messages caused by RPL will not cause any damage for which ND throttling is designed. Just a different order of magnitude in rates. What I really care for is a protocol that can be bound on several things like but not limited to RFC 4861. RA is closer in essence to what DIO needs than NA is for DAO but that's a start. And I am concerned with the Pandora box effect. Once we go along the path of having our own messages, we'll start wondering on our own hello protocol that evaluates links and metrics, and from there where do we stop? Considering the other issues we have to deal with at this time, like the loop avoidance and detection mechanisms that are under poll, I would not waste cycles on opening that box for the time being. Maybe later when we understand better what we do in fine. And when/if 6LoWPAN ND comes out, I'll probably be proposing another binding to replace NA with NR in that space because is it a lot cleaner semantically. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) >Sent: vendredi 16 octobre 2009 09:12 >To: Tim Winter; ROLL WG >Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport > >Hi Tim, > >I would vote for 2). >My impression is that it would be more flexible (no contradictory >interaction between ND timers and RPL timers). I also think it would >allow for a cleaner implementation of RPL (clearer separation between >the routing algorithm functionalities and the NS/NA processing). > >Best, >Mathilde > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Tim Winter >Sent: jeudi, 15. octobre 2009 19:24 >To: ROLL WG >Subject: [Roll] RPL Design Question: DIO/DAO Transport > >WG, > >There has been some feedback regarding the implications of using >Neighbor Discovery RA/NA to carry DIO/DAO for RPL. The functionality >provided by DIO/DAO may be seen as a natural extension to ND, but there >are concerns regarding the implications of overloading ND for use by >RPL. Another option would be to request the allocation of ICMP messages >to transport the DIO/DAO. > >What do you think? > 1) Let RPL use RA/NA for DIO/DAO transport > 2) Allocate 2 new ICMP messages for DIO/DAO and operate >independent of ND > >Please do keep in mind that this would serve as a base recommendation >for the core protocol, and does not necessarily preclude that another >implementation-specific binding outside of the scope of RPL (e.g. >6LowPAN) may do things differently. > > >Thanks, > >-RPL Authors >_______________________________________________ >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 jabeille@cisco.com Fri Oct 16 01:09:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65C53A6805 for ; Fri, 16 Oct 2009 01:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.357 X-Spam-Level: X-Spam-Status: No, score=-8.357 tagged_above=-999 required=5 tests=[AWL=-1.758, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCh7eBua1L-B for ; Fri, 16 Oct 2009 01:09:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A2EEE3A67DA for ; Fri, 16 Oct 2009 01:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jabeille@cisco.com; l=2042; q=dns/txt; s=sjiport01001; t=1255680569; x=1256890169; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Julien=20Abeille=20(jabeille)"=20|Subject:=20RE:=20[Roll]=20RPL=20Design=20Question: =20DIO/DAO=20Transport|Date:=20Fri,=2016=20Oct=202009=201 0:09:25=20+0200|Message-ID:=20|To:=20"Zach=20Shelby" =20,=20"Tim=20Winter"=20|Cc:=20"ROLL=20WG"=20|MIME-Version:=20 1.0|Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20|References:=20<4AD75A9F.6070803@acm.org>=20; bh=0WLwSlGDyYYuDaqJCcz4DuZ8LdZJP0wdwt8fgHCMDLc=; b=BO0QH+b/WuYqBlAwe9PmulFTfOkgEb0PCpYqQIamLEznRNCU3mGEAuL+ 79D1ApX0Pl+GdRduyDfdSPwrdpfDEK2+5gtsG92ixLw9OLnz43ZZEG3uG X5yiOp/NzSr72A0u8SYbLS13WjIZwNJq5BEAtFefhwi5Q1kE7oembouk2 s=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQLADfH10qrRN+K/2dsb2JhbACWSalmmBiEMAQ X-IronPort-AV: E=Sophos;i="4.44,571,1249257600"; d="scan'208";a="256962253" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2009 08:09:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9G898GW018808; Fri, 16 Oct 2009 08:09:29 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 10:09:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 10:09:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Design Question: DIO/DAO Transport Thread-Index: AcpOMWBE2RRrc7JoRXO78d3z6IxbIQABn2lw References: <4AD75A9F.6070803@acm.org> From: "Julien Abeille (jabeille)" To: "Zach Shelby" , "Tim Winter" X-OriginalArrivalTime: 16 Oct 2009 08:09:26.0695 (UTC) FILETIME=[FA894B70:01CA4E37] Cc: ROLL WG Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 08:09:26 -0000 Hi all, I also vote for 2 for the same reasons. Best, Julien > On Oct 15, 2009, at 20:23 , Tim Winter wrote: > > > > What do you think? > > 1) Let RPL use RA/NA for DIO/DAO transport > > 2) Allocate 2 new ICMP messages for DIO/DAO and operate=20 > independent=20 > > of ND > > >=20 > I vote for 2. >=20 > I agree with many on the list that it is a cleaner separation =20 > regarding timers and implementation. As there will be some=20 > differences =20 > as well between RFC4861 and 6LoWPAN-ND - this also makes RPL =20 > universal for both regarding DIO/DAO. >=20 > > Please do keep in mind that this would serve as a base =20 > > recommendation for > > the core protocol, and does not necessarily preclude that another > > implementation-specific binding outside of the scope of RPL (e.g. =20 > > 6LowPAN) > > may do things differently. >=20 > This makes sense. I would find it useful if RPL would specify=20 > the DIO/=20 > DAO messages in such a way that they could be easily carried as an =20 > ICMP option piggybacked e.g. on ND messages in an implementation-=20 > specific binding. >=20 > Zach >=20 > > > > > > Thanks, > > > > -RPL Authors > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > Mobile: +358 40 7796297 >=20 > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND >=20 > This e-mail and all attached material are confidential and=20 > may contain =20 > legally privileged information. If you are not the intended=20 > recipient, =20 > please contact the sender and delete the e-mail from your system =20 > without producing, distributing or retaining copies thereof. >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From alexandru.petrescu@gmail.com Fri Oct 16 02:36:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5320A3A63C9 for ; Fri, 16 Oct 2009 02:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOuXZ+MTRC7N for ; Fri, 16 Oct 2009 02:36:35 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 037503A6806 for ; Fri, 16 Oct 2009 02:36:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9G9aUV3025037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 11:36:30 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9G9aUsY029631; Fri, 16 Oct 2009 11:36:30 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9G9aStw021709; Fri, 16 Oct 2009 11:36:29 +0200 Message-ID: <4AD83E9C.7080005@gmail.com> Date: Fri, 16 Oct 2009 11:36:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <200910160019.26638.hrogge@googlemail.com> <4AD7A6B6.7080903@gmail.com> <200910160836.05218.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200910160836.05218.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 09:36:36 -0000 Henning Rogge a écrit : > Am Fri October 16 2009 00:48:22 schrieb Alexandru Petrescu: >>> it's hundreds of kilobytes. That's much if your whole operation system is >>> stored in 2 megabytes of flash. >> Well 200kbytes is 1/10 of your memory, dedicated to the stack. I find >> it fair. > > It's 10% of our "hard disk". And that is without the necessary userspace > programs. Most people running a Freifunk node would consider it a waste of > space. Luckily linux got LZMA compression support for the kernel, so we have > chances to get IPv6 support into the default firmwares. I think one could save space by also removing the IPv4 stack. >> How big is your olsrd running? > 100-200 kb I think. Depends on the amount of debug/logging code and the > architecture. In addition to this you can add a number of plugins into our > routing code. I think olsrd would save some space if it did not use IPv4 at all. Is this the case? >>>> So ETX is only for OLSRv2. >>> No >> Does OLSRv2 run IPv6 and ETX? > OLSRv2 is a protocol (in draft status). It can easily be used with IPv6 and > any kind of routing metric. > > The Olsr.org implementation does run OLSRv1 (with or without ETX, with IPv4 or > IPv6) at the moment, but I'm in the process implementing OLSRv2 (again, with > any kind of routing metric and with IPv4/6). > >>> ETX calculation based on received/lost hello messages is very easy. >> Hmm... not sure what you mean but I hear "received/lost" as some form of >> retransmission. >> >> I'd say that a metric should be something intrinsic to the link, not >> something calculable by heartbeats/hellos. E.g. a hopcount metric is >> intrinsic to the link (1 link is 1 hop, 2 links 2 hops), the >> qos/bandwidth are intrinsic to the link, the latency, etc. >> >> But of course, it is ok to propose differently. > The easiest way (not the best) to calculate ETX is to measure the amount of > loss in both directions of the link with probing packets (hello messages for > example). Then you just use exponential aging or a binary buffer to calculate > the average loss rate LQ/NLQ and use them to define your ETX value > (ETX=1/(LQ*NLQ)). > >> This makes me think that we may want to define what we mean by a >> "metric". A "routing metric" - ok, but what else? >> >> What are the requirements for defining a "routing metric"? > > Routing metrics can be anything. > > - they can be a constant (hopcount) > - they can be based on money (how much does this link cost to send traffic > over) I have never seen such a routing metric. > - they can be measured on the link (ETX, ETT, energy, SNR, ect.) Yes, but there is a difference between relying on live measurements and prior measurements used as constants. > - they can be based on security considerations (only route traffic through > nodes you trust enough) I haven't seen such routing metrics either. > - they can be some internal state of the router (hardware/battery resources of > the router) Never seen these. > and of course multiple kind of metrics can be combined (that's whats called > objective function in RPL). Ok. (when I say I never saw some metrics above it's about implementations of OSPF and such). >> We should also mention it being different than a performance metric. > > Performance (transmission speed for example) can be a routing metric too. > That would be useful for QoS in mesh networks. Hmm, I am afraid of making a confusion between metrics used for performance evaluation and transmission speed (performance) to be a routing metric. E.g. a metric is the meter in Switzerland against which everyone compares their rules. But I don't think a routing metric is such a concept. We could distinguish this case - saying the ROLL routing metrics are not performance evaluation metrics. Alex > > Henning Rogge > From henning.rogge@fkie.fraunhofer.de Fri Oct 16 03:15:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428CE3A6912 for ; Fri, 16 Oct 2009 03:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUIgUHgm0i3S for ; Fri, 16 Oct 2009 03:15:38 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 0BC7A3A6859 for ; Fri, 16 Oct 2009 03:15:37 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MyjqW-0003am-CR; Fri, 16 Oct 2009 12:15:40 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MyjqW-0005s6-3l; Fri, 16 Oct 2009 12:15:40 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Fri, 16 Oct 2009 12:16:05 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <200910160836.05218.henning.rogge@fkie.fraunhofer.de> <4AD83E9C.7080005@gmail.com> In-Reply-To: <4AD83E9C.7080005@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1324311.gLCCv33nml"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910161216.10209.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9905/Fri Oct 16 10:23:35 2009) by mailguard.fgan.de X-Scan-Signature: a44ad90b87c1147b5edf0a173c47bafd Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 10:15:39 -0000 --nextPart1324311.gLCCv33nml Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri October 16 2009 11:36:28 schrieb Alexandru Petrescu: > I think one could save space by also removing the IPv4 stack. This would make it a little bit difficult for people to get their transpare= nt=20 connection to the internet. Many routers in the Freifunk/Funkfeuer networks= =20 are connected to local private networks, so all of them need to be dual sta= ck=20 machines (to establish the 4in6 tunnel). > >> How big is your olsrd running? > > > > 100-200 kb I think. Depends on the amount of debug/logging code and the > > architecture. In addition to this you can add a number of plugins into > > our routing code. > > I think olsrd would save some space if it did not use IPv4 at all. Is > this the case? I don't think so. The core of the routing daemon does not care about the IP= =20 version, just the network/os specific parts do. Not much space to save. > > Routing metrics can be anything. > > > > - they can be a constant (hopcount) > > - they can be based on money (how much does this link cost to send > > traffic over) > > I have never seen such a routing metric. Think about internet and BGP... an important point of routing traffic is ho= w=20 much money do you have to pay for it. > > - they can be measured on the link (ETX, ETT, energy, SNR, ect.) > > Yes, but there is a difference between relying on live measurements and > prior measurements used as constants. Yes. > > - they can be based on security considerations (only route traffic > > through nodes you trust enough) > > I haven't seen such routing metrics either. http://en.wikipedia.org/wiki/RED/BLACK_concept Some routers might be allowed to handle "secret" traffic. Some do not. > > - they can be some internal state of the router (hardware/battery > > resources of the router) > > Never seen these. You might not want to route all your traffic through a small smart phone wh= ich=20 battery might be empty within a few minutes, so it make sense to include th= is=20 into a routing metric. > > and of course multiple kind of metrics can be combined (that's whats > > called objective function in RPL). > > Ok. > > (when I say I never saw some metrics above it's about implementations of > OSPF and such). Different routing metrics are used for different scenarios. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1324311.gLCCv33nml Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrYR+UACgkQRIfGfFXsz+D5tACfe33pG7qFYEkQaJTDVNHhhEut 4g8An2+PnvH3EOpVIUWjOPZZFWlgRlPS =qYfN -----END PGP SIGNATURE----- --nextPart1324311.gLCCv33nml-- From alexandru.petrescu@gmail.com Fri Oct 16 04:56:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E7B28C205 for ; Fri, 16 Oct 2009 04:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X90PECKhNKX for ; Fri, 16 Oct 2009 04:56:49 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 0BEE828C0DC for ; Fri, 16 Oct 2009 04:56:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9GBufnd014501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 13:56:41 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9GBuf0g005529; Fri, 16 Oct 2009 13:56:41 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9GBueUa006487; Fri, 16 Oct 2009 13:56:40 +0200 Message-ID: <4AD85F78.4050704@gmail.com> Date: Fri, 16 Oct 2009 13:56:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <200910160836.05218.henning.rogge@fkie.fraunhofer.de> <4AD83E9C.7080005@gmail.com> <200910161216.10209.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200910161216.10209.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 11:56:50 -0000 Henning Rogge a écrit : > Am Fri October 16 2009 11:36:28 schrieb Alexandru Petrescu: >> I think one could save space by also removing the IPv4 stack. > > This would make it a little bit difficult for people to get their transparent > connection to the internet. Many routers in the Freifunk/Funkfeuer networks > are connected to local private networks, so all of them need to be dual stack > machines (to establish the 4in6 tunnel). Well, I tend to agree, but I think in this WG the nodes are constrained and if one has to make choices then the IPv4 stack is a good candidate for deletion. >>>> How big is your olsrd running? >>> 100-200 kb I think. Depends on the amount of debug/logging code and the >>> architecture. In addition to this you can add a number of plugins into >>> our routing code. >> I think olsrd would save some space if it did not use IPv4 at all. Is >> this the case? > I don't think so. The core of the routing daemon does not care about the IP > version, just the network/os specific parts do. Not much space to save. Hmm... if every socket() call has a form for each address family then we sure can save some space by removing the AF_INET4 socket calls. The same with all mallocs which reserve space related to IPv4 addresses. The same with all text-to-binary conversion functions. I think there is much space to save in the olsrd memory footprint if it only did IPv6. There is also much space to save in the kernel if the IPv4 stack is removed. >>> Routing metrics can be anything. >>> >>> - they can be a constant (hopcount) >>> - they can be based on money (how much does this link cost to send >>> traffic over) >> I have never seen such a routing metric. > > Think about internet and BGP... an important point of routing traffic is how > much money do you have to pay for it. Ok, yes, makes some sense in principle. But have you ever seen any form of encoding money values in an IP message? Is it expressed in dollars or euros? How much precision? >>> - they can be measured on the link (ETX, ETT, energy, SNR, ect.) >> Yes, but there is a difference between relying on live measurements and >> prior measurements used as constants. > Yes. > >>> - they can be based on security considerations (only route traffic >>> through nodes you trust enough) >> I haven't seen such routing metrics either. > http://en.wikipedia.org/wiki/RED/BLACK_concept > > Some routers might be allowed to handle "secret" traffic. Some do not. Sounds as a good principle but what does it mean in practice? Is there a routing protocol which works like that? >>> - they can be some internal state of the router (hardware/battery >>> resources of the router) >> Never seen these. > You might not want to route all your traffic through a small smart phone which > battery might be empty within a few minutes, so it make sense to include this > into a routing metric. It's an appealing principle but what does it mean in practice? I have never seen a metric encoded in a message which quantifies how much battery is left. >>> and of course multiple kind of metrics can be combined (that's whats >>> called objective function in RPL). >> Ok. >> >> (when I say I never saw some metrics above it's about implementations of >> OSPF and such). > Different routing metrics are used for different scenarios. Ok. Alex From henning.rogge@fkie.fraunhofer.de Fri Oct 16 05:13:57 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC3D3A6A36 for ; Fri, 16 Oct 2009 05:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9OdJcA90aUz for ; Fri, 16 Oct 2009 05:13:56 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id F17F63A6A32 for ; Fri, 16 Oct 2009 05:13:55 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Mylgz-0003ou-Ug; Fri, 16 Oct 2009 14:13:58 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Mylgz-0006S4-Jo; Fri, 16 Oct 2009 14:13:57 +0200 From: Henning Rogge To: Alexandru Petrescu Date: Fri, 16 Oct 2009 14:14:17 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-10-generic; KDE/4.2.2; i686; ; ) References: <200910161216.10209.henning.rogge@fkie.fraunhofer.de> <4AD85F78.4050704@gmail.com> In-Reply-To: <4AD85F78.4050704@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2475765.h2diqiN47s"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910161414.27804.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/9905/Fri Oct 16 10:23:35 2009) by mailguard.fgan.de X-Scan-Signature: f4381aac55955176365c76ee184b90f0 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 12:13:57 -0000 --nextPart2475765.h2diqiN47s Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Fri October 16 2009 13:56:40 schrieb Alexandru Petrescu: > ... (saving space by dropping IPv4) I think this discussion is going off topic. But we can agree that you can s= ave=20 storage space and maybe memory if you limit your OS/routing agent to IPv4 o= r=20 IPv6. > >>> - they can be based on money (how much does this link cost to send > >>> traffic over) > >> > >> I have never seen such a routing metric. > > > > Think about internet and BGP... an important point of routing traffic is > > how much money do you have to pay for it. > > Ok, yes, makes some sense in principle. > > But have you ever seen any form of encoding money values in an IP message? No. > >>> - they can be based on security considerations (only route traffic > >>> through nodes you trust enough) > >> > >> I haven't seen such routing metrics either. > > > > http://en.wikipedia.org/wiki/RED/BLACK_concept > > > > Some routers might be allowed to handle "secret" traffic. Some do not. > > Sounds as a good principle but what does it mean in practice? > > Is there a routing protocol which works like that? Some time ago someone posted a plugin for the olsr.org code that used GPG f= or=20 some kind of "web of trust" and created different routing tables from it. I= t=20 was a proof of concept, but "security aware routing" is definitely somethin= g=20 to remember, especially if you have a mixture of authenticated and not=20 authenticated nodes in your network. You might want NOT to route over the n= ot=20 authenticated nodes... > > You might not want to route all your traffic through a small smart phone > > which battery might be empty within a few minutes, so it make sense to > > include this into a routing metric. > > It's an appealing principle but what does it mean in practice? I have > never seen a metric encoded in a message which quantifies how much > battery is left. Olsr.org has some experimental code to set the willingness to forward routi= ng=20 protocol traffic on the fly by looking at the battery settings. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart2475765.h2diqiN47s Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkrYY5kACgkQRIfGfFXsz+DNGQCdFD744PD6A68/uHN2ZbBoqXgS LGMAnjFARCBMScUZmiPuSTlvdKxM82OU =ZT6Z -----END PGP SIGNATURE----- --nextPart2475765.h2diqiN47s-- From pthubert@cisco.com Fri Oct 16 08:03:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 000BF3A6855 for ; Fri, 16 Oct 2009 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.712 X-Spam-Level: X-Spam-Status: No, score=-7.712 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEaM8cAITArC for ; Fri, 16 Oct 2009 08:03:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 049DD3A6817 for ; Fri, 16 Oct 2009 08:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3052; q=dns/txt; s=sjiport02001; t=1255705385; x=1256914985; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20ETX=20metric|Date:=20Fri ,=2016=20Oct=202009=2017:02:51=20+0200|Message-ID:=20<6A2 A459175DABE4BB11DE2026AA50A5D6DDAEF@XMB-AMS-107.cisco.com >|To:=20"Philip=20Levis"=20,=20"roll =20ROLL"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20<6DCBCDE6-1415-44E3-A613-A02F9F839255@cs. stanford.edu>|References:=20<200910131011.11371 .hrogge@googlemail.com><389DB2FB-DE03-476B-A6E6-11228A006 982@cisco.com><200910131553.47834.hrogge@googlemail.com>< 87r5t79t9g.fsf@kelsey-ws.hq.ember.com>=20<6DCBCDE6-1415-4 4E3-A613-A02F9F839255@cs.stanford.edu>; bh=19JRShQuvBI8fJtpd6E1O17OVipNCwL8YaGJkPcDqPI=; b=YdO3qw8kibELgvOCmNrGEX68vXPNARjbTkvaAJEH61zxNCoyW3mJ+K/V TS0n35qZLu/Moua/cyOvs8+r26vSmSom4qLMNtxXLZQdwEJX31l3/JLtA HoohuzQstoWEOgU0uf9cPfJOulTPi4tRtjzkPG+j6sdrCFCbHoeNdtJLC U=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJUn2EqrRN+J/2dsb2JhbADBI5grhDAEinQ X-IronPort-AV: E=Sophos;i="4.44,573,1249257600"; d="scan'208";a="215263970" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 16 Oct 2009 15:03:04 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9GF34kw023431; Fri, 16 Oct 2009 15:03:04 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 17:02:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Oct 2009 17:02:51 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D6DDAEF@XMB-AMS-107.cisco.com> In-Reply-To: <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] ETX metric Thread-Index: AcpNYM8Cl+c/2WoPRn6fpaWyQ0emewBDwcxg References: <200910131011.11371.hrogge@googlemail.com><389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com><200910131553.47834.hrogge@googlemail.com><87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "roll ROLL" X-OriginalArrivalTime: 16 Oct 2009 15:02:58.0234 (UTC) FILETIME=[BF5DB1A0:01CA4E71] Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 15:03:02 -0000 Hi Phil: Fully agreed.=20 This is why we are NOT looking for one-fit-it-all metric. Too many bright people already lost their hair on that problem. What we are looking for is a number of metrics and some logic to tie them together and that gives us an OCP/OF.=20 And there can be a different OCP for a different problem. Thus we are NOT looking for the perfect OCP/set of metrics that would please everybody, else we'd probably end up looking like an Egyptian scribe with no hair anywhere ;) Note that the rank IS NOT used to select the position in the DAG, but a consequence of that position as selected by the OCP, at least in normal operations. As you said earlier, it is but a proxy. As long as the OCP and the metrics are found in the DIO, the proxy is not used as an input to the OCP but generated as an output for the loop avoidance and detection processes that comes later. So what we really want in this draft is a set of OCPs that make sense in the domain where we have experience in this group. It seems that a consistent network of 802.15.4 nodes is a good problem to start with.=20 So what would be a good set of metrics and an OCP in that case? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis >Sent: jeudi 15 octobre 2009 06:49 >To: roll ROLL >Subject: Re: [Roll] ETX metric > >I think we should keep in mind that RPL must work across multiple link >layers. E.g.: > >A -- 900MHz --> B -- 2.4GHz --> C > >ETX is a commonly used metric, but typically under two simplifying >assumptions: > >1) Routes are composed of a single link layer >2) The link layer has a static bitrate > >If you break either assumption, it doesn't work well. ETT (expected >time of transmission) can address 2), but not 1). > >I'm wary of encoding a metric as a hard quantity. For example, >quantifying the metric as uJ breaks when nodes have differential >energy capacities. What we really want is a more abstract notion of >cost, which a particular device can use to, in a very simple way, >express its own tradeoffs. It is critical that exactly how devices >calculate this value remain unspecified. > >My first thought would be a quantification of how much of a node's >"lifetime" a packet would cost. Such a cost can consider both the >receiver and transmitter. E.g., given its particular low power >algorithms and expected lifetime, how much would sending to this >destination consume? (I try to avoid using the word "link.") > >I don't think that a single metric will be sufficient; besides some >notion of cost (hopcount, ETX, ETT, etc.), the other metric that is >critical in many applications is latency. These two -- cost and >latency -- can cover a large portion of the application design space, >and provide a sound basis for the basic specification. > >Thoughts? > >Phil >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Fri Oct 16 08:15:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DD1F28C0D9 for ; Fri, 16 Oct 2009 08:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Umk8uHctYnpo for ; Fri, 16 Oct 2009 08:15:06 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 1B6723A687D for ; Fri, 16 Oct 2009 08:15:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9GFF1Ph013994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 17:15:01 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9GFF19B031007; Fri, 16 Oct 2009 17:15:01 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9GFF1fK014025; Fri, 16 Oct 2009 17:15:01 +0200 Message-ID: <4AD88DF5.4000906@gmail.com> Date: Fri, 16 Oct 2009 17:15:01 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <200910131011.11371.hrogge@googlemail.com><389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com><200910131553.47834.hrogge@googlemail.com><87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D6DDAEF@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D6DDAEF@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 15:15:07 -0000 Pascal Thubert (pthubert) a écrit : > Hi Phil: > > Fully agreed. > > This is why we are NOT looking for one-fit-it-all metric. Too many > bright people already lost their hair on that problem. What we are > looking for is a number of metrics and some logic to tie them together > and that gives us an OCP/OF. > > And there can be a different OCP for a different problem. Thus we are > NOT looking for the perfect OCP/set of metrics that would please > everybody, else we'd probably end up looking like an Egyptian scribe > with no hair anywhere ;) > > Note that the rank IS NOT used to select the position in the DAG, but a > consequence of that position as selected by the OCP, at least in normal > operations. As you said earlier, it is but a proxy. As long as the OCP > and the metrics are found in the DIO, the proxy is not used as an input > to the OCP but generated as an output for the loop avoidance and > detection processes that comes later. > > So what we really want in this draft is a set of OCPs that make sense in > the domain where we have experience in this group. It seems that a > consistent network of 802.15.4 nodes is a good problem to start with. I doubt that. A set of 802.15.4 nodes would use 802.15.5 mesh 'routing' instead of RPL. I'd rather start with a heterogeneous set of low-power nodes each having multiple interfaces. Alex > > So what would be a good set of metrics and an OCP in that case? > > Pascal >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis >> Sent: jeudi 15 octobre 2009 06:49 >> To: roll ROLL >> Subject: Re: [Roll] ETX metric >> >> I think we should keep in mind that RPL must work across multiple link >> layers. E.g.: >> >> A -- 900MHz --> B -- 2.4GHz --> C >> >> ETX is a commonly used metric, but typically under two simplifying >> assumptions: >> >> 1) Routes are composed of a single link layer >> 2) The link layer has a static bitrate >> >> If you break either assumption, it doesn't work well. ETT (expected >> time of transmission) can address 2), but not 1). >> >> I'm wary of encoding a metric as a hard quantity. For example, >> quantifying the metric as uJ breaks when nodes have differential >> energy capacities. What we really want is a more abstract notion of >> cost, which a particular device can use to, in a very simple way, >> express its own tradeoffs. It is critical that exactly how devices >> calculate this value remain unspecified. >> >> My first thought would be a quantification of how much of a node's >> "lifetime" a packet would cost. Such a cost can consider both the >> receiver and transmitter. E.g., given its particular low power >> algorithms and expected lifetime, how much would sending to this >> destination consume? (I try to avoid using the word "link.") >> >> I don't think that a single metric will be sufficient; besides some >> notion of cost (hopcount, ETX, ETT, etc.), the other metric that is >> critical in many applications is latency. These two -- cost and >> latency -- can cover a large portion of the application design space, >> and provide a sound basis for the basic specification. >> >> Thoughts? >> >> Phil >> _______________________________________________ >> 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 mcr@marajade.sandelman.ca Fri Oct 16 10:07:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F01528C105; Fri, 16 Oct 2009 10:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIMMjMaKU+UX; Fri, 16 Oct 2009 10:07:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 7F77D28C0FE; Fri, 16 Oct 2009 10:07:41 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 156643428D; Fri, 16 Oct 2009 17:12:28 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id EEB8B4E7FB; Fri, 16 Oct 2009 13:07:43 -0400 (EDT) From: Michael Richardson To: "IETF ROLL" , "6lowpan" <6lowpan@ietf.org> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D66E79E@XMB-AMS-107.cisco.com> References: <21375.1255452103@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D66E79E@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 16 Oct 2009 13:07:43 -0400 Message-ID: <29673.1255712863@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] NA to transport DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 17:07:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 {I am not on 6lowpan list} (Pascal gives 6 step process of binding RPL over NR/NC.) > 1) As the DAG forms, a RPL router discovers its parents. If the ND > operation on the link is based on NR/NC then it makes sense for the OCP > to favor a parent that can reach a whiteboard so that a single NR can be > used for RPL DAOs and to maintain the registration of its own addresses > at the same time. What happens if there is no connectivity to the whiteboard? I.e. the DAG is not grounded? I think the node/router in question has to talk to the whiteboard using it's not-yet-known-to-be-unique link local address. I'm really unconfortable with the idea that the node/router has participate on a network, and change routing state of upstream nodes, using an address that is not yet unduplicated. The attacks that I can imagine are almost endless, such that I would very much want to consider doing this only with SEND. > 6) The router now owns its address(es), the right to be a router, can > send its owns RA-DIOs indicating that it can reach the whiteboard, and > the process recurses How does it transmit he RA-DIOs? They are multicast/broadcast on the directly attached link, not I guess with the help of the whiteboard. i.e. these are multicasts that have to bypass the 6lowpan multicast system, I think? I think this is important --- as it may mean that these DIOs can not be extra payloads of the "ND" (NR/NC), which would normally got to the whiteboard via unicast, right? - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBStioXYCLcPvd0N1lAQIyQQf8C2Ho+TNlO5sfHFxCNqIwpzsh/ovsHhhz TFKGj7JpsUAEGNH4nYWbkSB3mxHE+RyX6iMf59o+O57s0U3nToHM/d5+T2UUmkfC j1vwdBnzLphdPplWQFj46+PQAj0JOfq73gFciTcwYMdtLmPopo482ERE3kJfMdob IOKk9lfOK6lUni4uLDHhtkTwiJO74EDAudC5IoXGnwt32UQs/T8GVCF3plA/Fltm Nmkdt0QweTxHEybipRE754qdV7rKv4P0eIAGYcUsxKGD7xteZ7W2iQSnn70axo77 1dL8cSBfwtuuoOvDv2vI3DInX2g8Y6EShv0/aq/1bPKWErdRY5sHow== =4N7Q -----END PGP SIGNATURE----- From osk@exegin.com Fri Oct 16 10:43:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A4D3A6920 for ; Fri, 16 Oct 2009 10:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGF6LeKxKrNw for ; Fri, 16 Oct 2009 10:43:06 -0700 (PDT) Received: from rayon.exegin.com (209-139-203-37.bc.skyweb.ca [209.139.203.37]) by core3.amsl.com (Postfix) with ESMTP id 591E13A6916 for ; Fri, 16 Oct 2009 10:43:06 -0700 (PDT) Received: from [172.16.1.66] (fir.microplex.com [172.16.1.66]) by rayon.exegin.com (8.13.8/8.13.6) with ESMTP id n9GHh6Mm032264; Fri, 16 Oct 2009 10:43:07 -0700 Message-ID: <4AD8B0A5.8000604@exegin.com> Date: Fri, 16 Oct 2009 10:43:01 -0700 From: Owen Kirby User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tim Winter References: <4AD75A9F.6070803@acm.org> <8A977BDC5A7B0E429B0F521E8D6F91EE8021D7@XMB-AMS-103.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE8021D7@XMB-AMS-103.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ROLL WG Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 17:43:07 -0000 Hi Tim, I would also like to cast my vote for option 2 for the same reasons. Thanks, Owen Mathilde Durvy (mdurvy) wrote: > Hi Tim, > > I would vote for 2). > My impression is that it would be more flexible (no contradictory > interaction between ND timers and RPL timers). I also think it would > allow for a cleaner implementation of RPL (clearer separation between > the routing algorithm functionalities and the NS/NA processing). > > Best, > Mathilde > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Tim Winter > Sent: jeudi, 15. octobre 2009 19:24 > To: ROLL WG > Subject: [Roll] RPL Design Question: DIO/DAO Transport > > WG, > > There has been some feedback regarding the implications of using > Neighbor Discovery RA/NA to carry DIO/DAO for RPL. The functionality > provided by DIO/DAO may be seen as a natural extension to ND, but there > are concerns regarding the implications of overloading ND for use by > RPL. Another option would be to request the allocation of ICMP messages > to transport the DIO/DAO. > > What do you think? > 1) Let RPL use RA/NA for DIO/DAO transport > 2) Allocate 2 new ICMP messages for DIO/DAO and operate > independent of ND > > Please do keep in mind that this would serve as a base recommendation > for the core protocol, and does not necessarily preclude that another > implementation-specific binding outside of the scope of RPL (e.g. > 6LowPAN) may do things differently. > > > Thanks, > > -RPL Authors > _______________________________________________ > 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 alexandru.petrescu@gmail.com Fri Oct 16 10:55:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D444C3A67A2 for ; Fri, 16 Oct 2009 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry12c72zWURh for ; Fri, 16 Oct 2009 10:55:18 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id DDEC23A635F for ; Fri, 16 Oct 2009 10:55:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9GHtHuI006769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2009 19:55:17 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9GHtGKZ017180; Fri, 16 Oct 2009 19:55:16 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9GHtGc4013799; Fri, 16 Oct 2009 19:55:16 +0200 Message-ID: <4AD8B384.1090405@gmail.com> Date: Fri, 16 Oct 2009 19:55:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tim Winter References: <4AD75A9F.6070803@acm.org> In-Reply-To: <4AD75A9F.6070803@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 17:55:18 -0000 Tim Winter a écrit : > WG, > > There has been some feedback regarding the implications of using Neighbor > Discovery RA/NA to carry DIO/DAO for RPL. Sorry, what was that feedback? Which link layer was that feedback using? (I am not sure here we have a clear idea about the link layers used by RPL - or I may have missed something). > The functionality provided by > DIO/DAO may be seen as a natural extension to ND, but there are concerns > regarding the implications of overloading ND for use by RPL. Another option > would be to request the allocation of ICMP messages to transport the DIO/DAO. > > What do you think? > 1) Let RPL use RA/NA for DIO/DAO transport > 2) Allocate 2 new ICMP messages for DIO/DAO and operate independent of ND How about 3) use RA Flags Option RFC5175? Alex > Please do keep in mind that this would serve as a base recommendation for > the core protocol, and does not necessarily preclude that another > implementation-specific binding outside of the scope of RPL (e.g. 6LowPAN) > may do things differently. > > > Thanks, > > -RPL Authors > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Fri Oct 16 11:45:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6923A6869 for ; Fri, 16 Oct 2009 11:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BG94v7q6UTj for ; Fri, 16 Oct 2009 11:45:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E1E273A67DD for ; Fri, 16 Oct 2009 11:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=812; q=dns/txt; s=sjiport01001; t=1255718740; x=1256928340; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R OLL=20Meeting|Date:=20Fri,=2016=20Oct=202009=2011:44:20 =20-0700|Message-Id:=20|To:=20roll=20ROLL=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|Content-Transfer-Encoding:=207bit|References:=20<20091 016180828.1F7BD3A68AB@core3.amsl.com>; bh=6jsKCAkxEBMw5PA/+9k/ymwP92cZ2FJGV0wyqdCjCOs=; b=IcTlmv+UcWKtcwcWHtzGnKrGEk1CRSJZuIlrzSyX4l9IlMhTmO7ZYPsD o2PX1IR3FrSmaUV37SIfUxktTFFD1mn7GTOxbaqj2Uz99D8gyKIKdKA0R E53VdA6/H0BJe6t4hAGGvHIYMyek5nFaRS9z5+u/Ixfu5KmKinjkunQpD U=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEdc2EqrRN+J/2dsb2JhbADBFpgfhDAE X-IronPort-AV: E=Sophos;i="4.44,574,1249257600"; d="scan'208";a="257257251" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 16 Oct 2009 18:44:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9GIiNu6022596 for ; Fri, 16 Oct 2009 18:44:23 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 20:44:23 +0200 Received: from [10.2.36.135] ([10.61.101.45]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 20:44:22 +0200 Message-Id: From: JP Vasseur To: roll ROLL Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Oct 2009 11:44:20 -0700 References: <20091016180828.1F7BD3A68AB@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Oct 2009 18:44:22.0680 (UTC) FILETIME=[AD834980:01CA4E90] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16950.007 X-TM-AS-Result: No--11.414700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] ROLL Meeting X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 16 Oct 2009 18:45:36 -0000 Dear all, The ROLL WG is scheduled for Tuesday. That happens once every 10 years or so ... ;-) I won't be able to attend. David will chair the meeting. Thanks. JP. > ROLL Session 1 (2 hours) > Tuesday, Morning Session I 0900-1130 > Room Name: Acacia East > ---------------------------------------------- > > > > Requested Information: > > > --------------------------------------------------------- > Working Group Name: roll > Area Name: Routing Area > Session Requester: JP Vasseur > > Number of Sessions: 1 > Length of Session(s): 2 hours > > > Number of Attendees: 100 > Conflicts to Avoid: > First Priority: rtgarea 6lowpan manet autoconf > Second Priority: mpls ccamp > > Special Requests: > > --------------------------------------------------------- > > From jvasseur@cisco.com Sat Oct 17 08:21:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D8A3A68AE for ; Sat, 17 Oct 2009 08:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.737 X-Spam-Level: X-Spam-Status: No, score=-7.737 tagged_above=-999 required=5 tests=[AWL=-1.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvNQpA9HKR+5 for ; Sat, 17 Oct 2009 08:21:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0F75C3A6859 for ; Sat, 17 Oct 2009 08:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=19194; q=dns/txt; s=sjiport01001; t=1255792893; x=1257002493; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R OLL=20Meeting=20IETF-76|Date:=20Sat,=2017=20Oct=202009=20 08:21:00=20-0700|Message-Id:=20|To:=20roll=20ROLL=20|Mime-Version:=201.0=20(Apple=20Message=20framework=20v9 36); bh=KNYU1ElYDuFE5vWN/s4Au3i80/+3ObdWUHZPr+2MCrk=; b=JN9Ziqs7wal7vHdi1ExnCuCQs4/DTLAZIdt56Dd7tlqD5YvW7/p/mO5c HldlUhRTBCIV0xcS8MkbjmiVd8d5TY+X9q7Lr2+CjPCiI2NCychI0VH3U LbP7hIbxR2nlttswcSLwqhnUI8P8crJ3OTmCKMwchbzORufCbAa3hRVBM k=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFALp92UqrR7Hu/2dsb2JhbACCKiohvB+XSIQxBIFb X-IronPort-AV: E=Sophos;i="4.44,578,1249257600"; d="scan'208,217";a="257514603" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 17 Oct 2009 15:21:33 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9HFK4Xm018420 for ; Sat, 17 Oct 2009 15:21:33 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 17:21:12 +0200 Received: from [10.223.97.97] ([10.61.94.85]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 17:21:11 +0200 Message-Id: From: JP Vasseur To: roll ROLL Content-Type: multipart/alternative; boundary=Apple-Mail-7-460270417 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Oct 2009 08:21:00 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Oct 2009 15:21:11.0316 (UTC) FILETIME=[754E8540:01CA4F3D] Subject: [Roll] ROLL Meeting IETF-76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 17 Oct 2009 15:21:29 -0000 --Apple-Mail-7-460270417 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit TUESDAY, November 10, 2009 0800-1800 IETF Registration - 3rd Floor Foyer 0800-0900 Beverages - 3rd Floor Foyer 0900-1130 Morning Session I Orchid West INT 6man IPv6 Maintenance WG Cattleya West OPS netmod NETCONF Data Modeling Language WG Orchid Centre RAI dispatch Dispatch WG Orchid East RTG karp Keying and Authentication for Routing Protocols BOF Acacia East RTG roll Routing Over Low power and Lossy networks WG Camellia TSV dccp Datagram Congestion Control Protocol WG Cattleya East TSV pcn Congestion and Pre-Congestion Notification WG --Apple-Mail-7-460270417 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <= td style=3D"padding-top: 0.1em; padding-right: 0.5em; padding-bottom: = 0.1em; padding-left: 0.5em; margin-top: 0em; margin-right: 0em; = margin-bottom: 0em; margin-left: 0em; vertical-align: top; = border-top-style: none; border-right-style: none; border-bottom-style: = none; border-left-style: none; border-top-width: 0em; = border-right-width: 0em; border-bottom-width: 0em; border-left-width: = 0em; border-collapse: collapse; text-align: left; font-size: 0.9em; = ">Congestion and Pre-Congestion Notification = WG

TUESDAY, November 10, = 2009

0800-1800 IETF Registration - 3rd= Floor Foyer

0800-0900 Beverages - 3rd= Floor Foyer
0900-1130 Morning Session = I
Orchid = WestINT6manCattl= eya WestOPSnetmod= NETCONF Data Modeling Language WG
Orchi= d CentreRAIdispatch= Dispatch WG
Orchid = EastRTGkarpKeying and Authentication for Routing = Protocols BOF
Acacia = EastRTGrollCamelliaTSVdccpCattl= eya EastTSVpcn
= --Apple-Mail-7-460270417-- From cabo@tzi.org Sat Oct 17 11:20:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078103A6923 for ; Sat, 17 Oct 2009 11:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY7EyIEkBiSs for ; Sat, 17 Oct 2009 11:20:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id F22403A67B0 for ; Sat, 17 Oct 2009 11:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n9HIJrwP002509; Sat, 17 Oct 2009 20:19:58 +0200 (CEST) Message-Id: <55A4F71F-7FF9-4701-92BC-3799B2378602@tzi.org> From: Carsten Bormann To: JP Vasseur In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 17 Oct 2009 20:19:52 +0200 References: X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] ROLL Meeting IETF-76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 17 Oct 2009 18:20:34 -0000 > 0900-1130 Morning Session I > Orchid West INT 6man IPv6 Maintenance WG > Acacia East RTG roll Routing Over Low power and Lossy networks WG Well, at least you can be sure that your meeting will be completely undisturbed by any IPv6 expertise (and v.v., I'm afraid). Should we try to have that changed? Gruesse, Carsten From mdurvy@cisco.com Mon Oct 19 02:31:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8361B3A67DF for ; Mon, 19 Oct 2009 02:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.252 X-Spam-Level: X-Spam-Status: No, score=-7.252 tagged_above=-999 required=5 tests=[AWL=-1.674, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MRtbbThOrhP for ; Mon, 19 Oct 2009 02:31:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1962028C143 for ; Mon, 19 Oct 2009 02:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mdurvy@cisco.com; l=11327; q=dns/txt; s=amsiport01001; t=1255944671; x=1257154271; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mathilde=20Durvy=20(mdurvy)"=20|Subject:=20DAO=20packet=20format=20and=20timers|Date: =20Mon,=2019=20Oct=202009=2011:31:07=20+0200|Message-ID: =20<8A977BDC5A7B0E429B0F521E8D6F91EE802B5C@XMB-AMS-103.ci sco.com>|To:=20"ROLL=20WG"=20 |MIME-Version:=201.0; bh=8eQ/woVmOEsx5gVRLOQhAU0BYBbWLZDUn/dwZEygFp4=; b=VeW0TxFpSTy5jlz8iRGk1RJPcD8AboAFTX3KtK/GQSsADr6mMTjeSNhL T4hVPNdvyGZFik86zBFVy+Y0geN/2AuYsxQynGTgLBdhWkbHx24hDfY21 Byx9JJCJVdI1ysA+5d1SHDbXc9oqfBxOpUZW8tLSe8deNpSgyWhumswY3 g=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwAALLO20qQ/uCWe2dsb2JhbACCJy0hmBkBARYkBqgwlksChC8E X-IronPort-AV: E=Sophos;i="4.44,584,1249257600"; d="gif'147?scan'147,208,217,147";a="52127523" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2009 09:31:08 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9J9V8LZ010620 for ; Mon, 19 Oct 2009 09:31:08 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 11:31:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA509E.E3354CCF" Date: Mon, 19 Oct 2009 11:31:07 +0200 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE802B5C@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAO packet format and timers Thread-Index: AcpQnuK8ZSgEWWXBT2GqhUFy574j9w== From: "Mathilde Durvy (mdurvy)" To: "ROLL WG" X-OriginalArrivalTime: 19 Oct 2009 09:31:08.0209 (UTC) FILETIME=[E34E3A10:01CA509E] Subject: [Roll] DAO packet format and timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 09:31:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA509E.E3354CCF Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA509E.E3354CCF" ------_=_NextPart_002_01CA509E.E3354CCF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have several comments/questions/possible simplifications on Section = 5.9. =20 - Concerning the DAO packet format -- Do we need the Route Tag in the core DAO option? Isn't it more likely = that nodes would decide which prefixes to store based on a local policy = (e.g. MRU). This could potentially save 32bits per DAO. -- Would it make sense to make the Reverse Route Stack + RRCount a = sub-option? -- The variable length Prefix might break the byte alignment. Is that = desirable? -- The storage of the variable length reverse route stack in environment = without dynamic memory will be problematic. I guess it is thus expected = that such nodes do not keep DAO state and use solely source routing. =20 - 5.9.2.1.1 Destination Advertisement Timers -- Are DAO sent only on trigger from RA-DIO (with D bit set)? What does = 'propagation' of DAO means concretely? If you receive a DAO do you also = need to relay it right away? -- I have the impression that the sending NA-DAOs in response to RA-DIOs = (with D bit set) is really only testing the reachability of the neighbor = advertising the prefix not the reachability of the destination owning = the prefix. Does this justify the cost of having a DelayNA timer / = reported flag per DAO prefix per DA parent? -- Is the RemoveTimer related to the DAO lifetime associated with the = prefixes at all? =20 I would of appreciate if these 3 last points could be clarified in the = next revision of RPL. =20 Best, Mathilde =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_002_01CA509E.E3354CCF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
I have = several=20 comments/questions/possible simplifications on Section=20 5.9.
 
- = Concerning the DAO=20 packet format
-- Do = we need the=20 Route Tag in the core DAO option? Isn't it more likely that nodes=20 would decide which prefixes to store based on a local policy = (e.g.=20 MRU). This could potentially save 32bits per DAO.
-- = Would it make=20 sense to make the Reverse Route Stack + RRCount a=20 sub-option?
-- The = variable=20 length Prefix might break the byte alignment. Is that=20 desirable?
-- The storage of the variable length reverse route = stack in=20 environment without dynamic memory will be problematic. I guess it is = thus=20 expected that such nodes do not keep DAO state and use solely source=20 routing.
 
- = 5.9.2.1.1=20 Destination Advertisement Timers
-- = Are DAO sent only on trigger = from RA-DIO=20 (with D bit set)? What does 'propagation' of DAO means concretely? If = you=20 receive a DAO do you also need to relay it right=20 away?
-- I = have the=20 impression that the sending NA-DAOs in response to RA-DIOs (with D bit = set) is=20 really only testing the reachability of the neighbor advertising = the prefix=20 not the reachability of the destination owning the prefix. Does = this=20 justify the cost of having a  DelayNA timer / reported flag per DAO = prefix per=20 DA parent?
-- Is = the=20 RemoveTimer related to the DAO lifetime associated with the = prefixes=20 at all?
 
I = would of=20 appreciate if these 3 last points could be clarified in the next = revision of=20 RPL.
 
Best,
Mathilde
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_002_01CA509E.E3354CCF-- ------_=_NextPart_001_01CA509E.E3354CCF Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA509E.E3354CCF Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA509E.E3354CCF-- From Chris.Dearlove@baesystems.com Mon Oct 19 02:57:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EDB28C12A for ; Mon, 19 Oct 2009 02:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.076 X-Spam-Level: X-Spam-Status: No, score=-1.076 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOjV9xEnZWfe for ; Mon, 19 Oct 2009 02:57:41 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id EB1F73A6809 for ; Mon, 19 Oct 2009 02:57:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,584,1249254000"; d="scan'208";a="28106318" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Oct 2009 10:57:47 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9J9vquQ012711 for ; Mon, 19 Oct 2009 10:57:53 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Oct 2009 10:57:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 19 Oct 2009 10:57:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL network size and related details thread-index: AcpQooKyGSRAd7ixSGSCooRlaKyUkQ== From: "Dearlove, Christopher (UK)" To: "ROLL WG" X-OriginalArrivalTime: 19 Oct 2009 09:57:47.0003 (UTC) FILETIME=[9C42D4B0:01CA50A2] Subject: [Roll] RPL network size and related details X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 09:57:42 -0000 Looking at draft-ietf-roll-rpl-03, both the summary and the introduction contain the sentence: "Furthermore such networks may potentially comprise a large number of nodes, up to several dozens or hundreds or more nodes in the network." I don't think this is a particularly well-written sentence, and also leaves me unclear what network sizes are covered, either by intent or by what has been demonstrated in simulations or otherwise. (If there are such results, and they've been referenced on the list, my apologies, I'm afraid I haven't read quite a few of the postings. Pointers would be welcome.) If we take that as that the protocol should work with hundreds of nodes, and might work with thousands (appreciating that issues such as node density also matter) I believe that matches most of the requirements documents, but not I think the urban sensor networks one. Do any members of the Design Team have any comments? On the latter point, I think since the draft credits the Design Team, it should list them and their affiliations (and that of T. Winter) both for information and for credit. I also raised the use of the word "unique" referring to the challenges of ROLL at the time of the re-charter, and it was replaced. I would add the same here (see abstract and introduction). In fact if the design space is only hundreds of nodes I would definitely say it is not unique. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From mcr@marajade.sandelman.ca Mon Oct 19 06:32:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2218B28C14C for ; Mon, 19 Oct 2009 06:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoCedP3N7DIC for ; Mon, 19 Oct 2009 06:32:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 618F03A689A for ; Mon, 19 Oct 2009 06:32:40 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 010BA3428F for ; Mon, 19 Oct 2009 13:37:41 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E0DB04E7F9 for ; Mon, 19 Oct 2009 09:32:45 -0400 (EDT) From: Michael Richardson To: "ROLL WG" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE802B5C@XMB-AMS-103.cisco.com> References: <8A977BDC5A7B0E429B0F521E8D6F91EE802B5C@XMB-AMS-103.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 19 Oct 2009 09:32:45 -0400 Message-ID: <6645.1255959165@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] DAO packet format and timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 13:32:41 -0000 >>>>> "Mathilde" == Mathilde Durvy <(mdurvy)" > writes: Mathilde> -- Do we need the Route Tag in the core DAO option? Isn't Mathilde> it more likely that nodes would decide which prefixes to Mathilde> store based on a local policy (e.g. MRU). This could Mathilde> potentially save 32bits per DAO. My recommendation is not to count bits in savings in this way. Figure out what is sufficient, encode it as a base structure, and then figure out what the optional parts might be, and how often they are optional, and then do that. *THEN* do the PDU size calculation. If it is too big, ask what zlib with a static dictionary can do for the packet size, and only then decide to "remove" things. insert quote abut premature optimization and evil. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jvasseur@cisco.com Mon Oct 19 08:04:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B1F3A682E for ; Mon, 19 Oct 2009 08:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.595 X-Spam-Level: X-Spam-Status: No, score=-6.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9VkM7a2PdAz for ; Mon, 19 Oct 2009 08:04:44 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2D5953A67F7 for ; Mon, 19 Oct 2009 08:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=10894; q=dns/txt; s=sjiport05001; t=1255964691; x=1257174291; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20DAO=20packet=20format=20and=20timers|Date: =20Mon,=2019=20Oct=202009=2008:04:49=20-0700|Message-Id: =20<07E31921-9676-4B69-940D-8EB2690269C2@cisco.com>|To: =20Mathilde=20Durvy=20(mdurvy)=20|Cc: =20"ROLL=20WG"=20|Mime-Version:=201.0=20(A pple=20Message=20framework=20v936)|In-Reply-To:=20<8A977B DC5A7B0E429B0F521E8D6F91EE802B5C@XMB-AMS-103.cisco.com> |References:=20<8A977BDC5A7B0E429B0F521E8D6F91EE802B5C@XM B-AMS-103.cisco.com>; bh=FwaCUxS1b+h8XiWzzGmXm0EDkpUo2cq80PJzcDyGGqQ=; b=daoHcagq4kZwEnfyZTrKqdvQlx+LvfkxP43kY8cdyy7DOInAOQHf6AGm 5EAMVPOP9RcpOODUR4zxUdLzWEfFLTk0LCzoEGcl2TzPiNQ4twxgkllX7 kPOHpG56ArvN1MQw2zS8aRnoAeSLhVdl+qcuyy1JA9K4rQJqCTNn82Yuh Y=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAEYd3EqrR7Hu/2dsb2JhbACCJy0hwWqWZwKELwQ X-IronPort-AV: E=Sophos;i="4.44,585,1249257600"; d="scan'208,217";a="99546455" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2009 15:04:50 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9JF4o9V021606 for ; Mon, 19 Oct 2009 15:04:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 08:04:50 -0700 Received: from [10.2.39.197] ([10.21.151.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 08:04:49 -0700 Message-Id: <07E31921-9676-4B69-940D-8EB2690269C2@cisco.com> From: JP Vasseur To: Mathilde Durvy (mdurvy) In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE802B5C@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-9-632099236 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 08:04:49 -0700 References: <8A977BDC5A7B0E429B0F521E8D6F91EE802B5C@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Oct 2009 15:04:50.0293 (UTC) FILETIME=[8165CA50:01CA50CD] Cc: ROLL WG Subject: Re: [Roll] DAO packet format and timers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 15:04:45 -0000 --Apple-Mail-9-632099236 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Mathilde, On Oct 19, 2009, at 2:31 AM, Mathilde Durvy (mdurvy) wrote: > Hi All, > > I have several comments/questions/possible simplifications on =20 > Section 5.9. > > - Concerning the DAO packet format > -- Do we need the Route Tag in the core DAO option? Isn't it more =20 > likely that nodes would decide which prefixes to store based on a =20 > local policy (e.g. MRU). This could potentially save 32bits per DAO. I think so since it could be very useful in a number of situation. We =20= could certainly make it shorter and optional. > -- Would it make sense to make the Reverse Route Stack + RRCount a =20 > sub-option? Good idea. > -- The variable length Prefix might break the byte alignment. Is =20 > that desirable? Do you see this as a real issue ? > -- The storage of the variable length reverse route stack in =20 > environment without dynamic memory will be problematic. I guess it =20 > is thus expected that such nodes do not keep DAO state and use =20 > solely source routing. > > - 5.9.2.1.1 Destination Advertisement Timers > -- Are DAO sent only on trigger from RA-DIO (with D bit set)? What =20 > does 'propagation' of DAO means concretely? If you receive a DAO do =20= > you also need to relay it right away? > -- I have the impression that the sending NA-DAOs in response to RA-=20= > DIOs (with D bit set) is really only testing the reachability of the =20= > neighbor advertising the prefix not the reachability of the =20 > destination owning the prefix. Does this justify the cost of having =20= > a DelayNA timer / reported flag per DAO prefix per DA parent? > -- Is the RemoveTimer related to the DAO lifetime associated with =20 > the prefixes at all? > > I would of appreciate if these 3 last points could be clarified in =20 > the next revision of RPL. > Yes it must and will be clarified although some aspect (first point =20 for example) may be left to implementation. Thanks. JP. > Best, > Mathilde > > Durvy Mathilde > Software Engineer > Technology center > > mdurvy@cisco.com > Phone: +41 21 822 1725 > Mobile: +41 76 396 8116 > > Cisco Systems International S=E0rl > Av. des Uttins, 5 > CH-1180 Rolle > > Cisco home page > > > > Think before you print. > This e-mail may contain confidential and privileged material for the =20= > sole use of the intended recipient. Any review, use, distribution or =20= > disclosure by others is strictly prohibited. If you are not the =20 > intended recipient (or authorized to receive for the recipient), =20 > please contact the sender by reply e-mail and delete all copies of =20 > this message. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-9-632099236 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi = Mathilde,

On Oct 19, 2009, at 2:31 AM, Mathilde Durvy = (mdurvy) wrote:

Hi All,
 
I have = several comments/questions/possible simplifications on Section = 5.9.
 
- = Concerning the DAO packet format
-- Do we = need the Route Tag in the core DAO option? Isn't it more likely that = nodes would decide which prefixes to store based on a local = policy (e.g. MRU). This could potentially save 32bits per = DAO.

I think = so since it could be very useful in a number of situation. We could = certainly make it shorter and optional.

-- Would it make sense to make the Reverse = Route Stack + RRCount a = sub-option?

Good= idea. 

-- The = variable length Prefix might break the byte alignment. Is that = desirable?

Do = you see this as a real issue ?

=
-- The storage of the variable = length reverse route stack in environment without dynamic memory will be = problematic. I guess it is thus expected that such nodes do not keep DAO = state and use solely source routing.
 
- 5.9.2.1.1 = Destination Advertisement Timers
-- Are DAO = sent only on trigger from RA-DIO (with D bit set)? What does = 'propagation' of DAO means concretely? If you receive a DAO do you also = need to relay it right away?
=
--= I have the impression that the sending NA-DAOs in response to RA-DIOs = (with D bit set) is really only testing the reachability of the neighbor = advertising the prefix not the reachability of the destination = owning the prefix. Does this justify the cost of having = a  DelayNA timer / reported flag per DAO = prefix per DA parent?
-- Is the = RemoveTimer related to the DAO lifetime associated with the = prefixes at all?
 
=
I = would of appreciate if these 3 last points could be clarified in the = next revision of RPL.
 
=

Yes it must and will be clarified although some = aspect (first point for example) may be left to = implementation.

Thanks.

= JP.

Best,
=
Mathilde
=

Durvy = Mathilde
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: = +41 21 822 1725
Mobile: +41 76 396 = 8116

Cisco = Systems International S=E0rl
Av. des Uttins, 5
CH-1180 = Rolle

Cisco home page

 
=
3D"Think Think before you print.
This e-mail may contain = confidential and privileged material for the sole use of the = intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the = intended recipient (or authorized to receive for the recipient), = please contact the sender by reply e-mail and delete all copies = of this = message.

 
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-9-632099236-- From jvasseur@cisco.com Mon Oct 19 08:05:08 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBB93A68C3 for ; Mon, 19 Oct 2009 08:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdpSKK+T97Ns for ; Mon, 19 Oct 2009 08:05:07 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CD0503A68C0 for ; Mon, 19 Oct 2009 08:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1170; q=dns/txt; s=sjiport05001; t=1255964715; x=1257174315; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20RPL=20Design=20Question:=20DIO/DAO=20Transp ort|Date:=20Mon,=2019=20Oct=202009=2008:05:07=20-0700 |Message-Id:=20|To:=20Tim=20Winter=20|Cc:=20ROLL =20WG=20|Mime-Version:=201.0=20(Apple=20Me ssage=20framework=20v936)|Content-Transfer-Encoding:=207b it|In-Reply-To:=20<4AD75A9F.6070803@acm.org>|References: =20<4AD75A9F.6070803@acm.org>; bh=t9laqq3BC7N5GSZVzi+X0lZyWyiUj75SLvgvnK0QobQ=; b=fiFl9S9a2Y/AtKAUEQj76N7JtaIJzYW9dJY9mjK7qsnsL9LjxkyMPPNZ 5Tia7zLHbe1dKf4iiv4ar7tdiLTLwJ7zkayd+RkCH4W8f6JGX1+nw2rRd j5MsLsB4iLfqkZGzMRFfGTbRtpcionfzDhVybtfx3yYjatEqv0d0/I8ES 4=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEYd3EqrR7H+/2dsb2JhbADEX5ZnhDEE X-IronPort-AV: E=Sophos;i="4.44,585,1249257600"; d="scan'208";a="99546813" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 19 Oct 2009 15:05:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9JF58we010356; Mon, 19 Oct 2009 15:05:08 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 08:05:07 -0700 Received: from [10.2.39.197] ([10.21.151.124]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 08:05:07 -0700 Message-Id: From: JP Vasseur To: Tim Winter In-Reply-To: <4AD75A9F.6070803@acm.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 08:05:07 -0700 References: <4AD75A9F.6070803@acm.org> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Oct 2009 15:05:07.0527 (UTC) FILETIME=[8BAB7D70:01CA50CD] Cc: ROLL WG Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 15:05:08 -0000 Hi Tim, On Oct 15, 2009, at 10:23 AM, Tim Winter wrote: > WG, > > There has been some feedback regarding the implications of using > Neighbor > Discovery RA/NA to carry DIO/DAO for RPL. The functionality > provided by > DIO/DAO may be seen as a natural extension to ND, but there are > concerns > regarding the implications of overloading ND for use by RPL. > Another option > would be to request the allocation of ICMP messages to transport the > DIO/DAO. > > What do you think? > 1) Let RPL use RA/NA for DIO/DAO transport > 2) Allocate 2 new ICMP messages for DIO/DAO and operate independent > of ND > Voting for 2) mainly to avoid timers and state machine dependency. Thanks. JP. > Please do keep in mind that this would serve as a base > recommendation for > the core protocol, and does not necessarily preclude that another > implementation-specific binding outside of the scope of RPL (e.g. > 6LowPAN) > may do things differently. > > > Thanks, > > -RPL Authors > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From anders.jagd@ekasystems.com Mon Oct 19 09:24:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7C83A6899 for ; Mon, 19 Oct 2009 09:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIw1l5neAsKV for ; Mon, 19 Oct 2009 09:24:41 -0700 (PDT) Received: from smtp100.biz.mail.re2.yahoo.com (smtp100.biz.mail.re2.yahoo.com [206.190.52.46]) by core3.amsl.com (Postfix) with SMTP id 814DE3A694C for ; Mon, 19 Oct 2009 09:24:37 -0700 (PDT) Received: (qmail 82772 invoked from network); 19 Oct 2009 16:24:42 -0000 Received: from (anders.jagd@209.48.242.70 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 19 Oct 2009 09:24:42 -0700 PDT X-Yahoo-SMTP: 0HbgGv6swBAyDM4W_iY9jImykUMHKYOyMTAwyHNWIF768PM- X-YMail-OSG: bmHR8WsVM1m_6RD7nF85WKmwGKngyCjJ.WtADPXUjwC0LIFATL35gUv2kpL52LSJ9NdYnNjiatw4Tf.3aerZuLOJqIqXIQAXSW87rmG1SzmpFjR7Vz5jfuRqrO_WUA7iCPWwRrnab9tjPyreDJ0A32dFxq9heYpFbW_8sT4VqOKzzgVjC5y1_4KubsSDM.czZZBl5Gu9IrzscQOmHNqU50sREOdbOiBvzqGLeELV0FHE.DKpqg7ruOTugsMqjyz24.D2H26pn0BINbStqkXpQMEcs1cYvVqNAPh3LxLF7kJmWF_o_o2R7UVLPdURKIbU X-Yahoo-Newman-Property: ymail-3 From: "Anders Jagd" To: Date: Mon, 19 Oct 2009 12:24:43 -0400 Organization: Eka Systems Message-ID: <004801ca50d8$aa879250$ff96b6f0$@jagd@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpQ2KoNEGK4Mnx9R+m0xArX9Tnc7A== Content-Language: en-us Cc: roll@ietf.org Subject: Re: [Roll] Informed move [was: A proposal for Traffic Loop X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 16:24:42 -0000 Pascal, This is in response to two related mails of yours. My comments/suggestions are found below, but let me first set the context by quoting from your mails: Oct 9: "A proposal for Traffic Loop avoidance, detection and recovery" Oct 16: "Re: [Roll] Ew: RPL Design Questions In the latter, you correctly note how some problems are of a global nature, while some are local - this with regards to the discussion of "Sequence number" vs. "Hold-up Timer" approaches: >The protocol as will be complemented by a loop detection mechanism. A >proposal was already posted "A proposal for Traffic Loop avoidance, >detection and recovery". The loop detection is required even if we do >not do A+B, to cover the window till DAG rebuilds, siblings loops and >DAO loss loops. > >The local route poisoning and the global DAG rebuild provide really >different services and operate at a very different level. The "loop detection" that you mention was discussed in your other mail, specifically addressing the following bits proposed for the flow label: >Outwards : 1 bit >Sibling : 1 bit >Rank_error : 1 bit >DAO_Error : 1 bit >Rank : 8 bit >Instance ID : 8 bit Now for my comments: I completely agree on the "global vs. local" remark. We are aiming at a protocol suiting networks with sizes varying within many orders of magnitude. Even for one network, the DAG will be dynamic in nature, as well as possibly quite asymmetric/"unbalanced". I therefore believe the base protocol should allow for at least 3 different methods related to loop avoidance and detection (since networks have different requirements), and that this be "run-time" configurable (since networks are dynamic and may be asymmetric): 1) Sequence number/heartbeat (as related to controlled merging of floating DAGs) 2) Hold-up timer (as related to controlled merging of floating DAGs) 3) Count to infinity/"TTL" I suggest that we allocate enable flags in the DIO for this - to allow for root and other parent nodes to selectively enable sub-DAGs to use/assume each of the above methods. The root would set the flags according to management plane configuration and/or topological awareness (which may be dynamic as the network expands and contracts). Any parent node would be allowed to selectively disable (or maybe even enable) features based on localized topological awareness. With regards to your detection bits (flow label and others), I would like to suggest: ---- Instance ID bits ("Instance forwarding"): I don't think DAG "Instances" have been well enough defined to really address this, but if you are saying that we should not route between DAGs with different Instance IDs, and that we should use those bits to detect inconsistencies, then I agree. ---- Outwards, Rank, and Rank_error bits ("DAG inconsistency loop detection"): Let me first quote your mail: >A node emitting a packet must reset the Rank_error bit and the Outwards bit. >A router MUST also reset the Outwards bit if it is using the default route inwards, either via a sibling or a >parent, and set the bit if it is using a DAO route, either via a sibling or a child. >A receiver detects an inconsistency if it receives a packet going inwards from a source with a lesser Rank, >or outwards with a higher rank. >Upon inconsistency, if the Rank_error bit was not set then the Rank_error bit is set. If it was set the packet >is discarded. This is done to cover a rare re-sequencing of the DAG. I agree, this would help when encountering temporary loops. ---- Sibling bit ("Sibling loop avoidance"): I propose to generalize your "max 1 sibling forwarding" approach by allocating N bits in the flow label (N somewhere between 1 and 4) for a "horizontal TTL"/"sibling hop count". This would be initialized to some number (default 1) by any node first forwarding through a sibling, and decremented by sibling nodes again forwarding through a sibling. Upon reaching 0, packet must be either dropped or sent up the tree (at which point nodes above can re-initialize the horizontal TTL). This based on "Horizontal TTL" being enabled through the DIO. For this, I thus suggest we consider having separate TTL configuration (DIO) and count (individual packets) for "Vertical" (up or down the DAG) and "Horizontal" (sibling) flows. DIO may also include configuration of max settings for those. "Horizontal TTL = 0" possibly indicating not to route through siblings and "Vertical TTL = 0" possibly indicating not to rely on vertical TTL. Again, this to address the dynamic and varied scope of network topologies we are faced with. --- DAO_Error bit "DAO inconsistency loop detection": Let me again quote your mail: >In a general manner, a packet that goes outwards should never go inwards again. > So rather than routing inwards a packet with the Outwards bit set, the router MUST discard the packet. >If DAO recovery is in place, then the router MAY send it back to the source. I suggest we some times allow for a packet which was initially sent up the tree to "change direction" one (and only one time). This for P2P purposes. I suggest that the source node of a packet initializes a (1 bit) direction shift counter ("UTurn") to 0 (no change allowed) or 1 (one change allowed). A node wishing to change direction may do so if the bit set, but must also clear the bit. ---- In summary, I propose the following for the DIO and the flow label: DIO: 1 bit: Enable/disable "Sequence number/heartbeat" based merging 1 bit: Enable/disable "Hold-up timer" based merging TBD bits: Vertical TTL initial setting (0 -> Don't assume TTL) TBD bits: Horizontal TTL initial setting (0 -> Don't route through siblings) Could limit "Vertical TTL" bits to say 4 bits by using 1 to the power of the value chosen. For "Horizontal TTL", 4 bits, maybe less, should suffice. Flow label: 1 bit: Outwards - based on direction of packet 1 bit: Rank_error - set when detecting inconsistency of "Outwards bit" vs. "Rank relationship" TBD bits: Horizontal (sibling) TTL 1 bit: UTurn_count: - Number of remaining allowed changes of inward/outward direction 8 bit Instance ID - Pending more discussion 8 bit: Rank - To detect rank inconsistencies (pending discussion of number of bits for Rank) Best regards, Anders From pal@cs.stanford.edu Mon Oct 19 09:48:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E773A6836 for ; Mon, 19 Oct 2009 09:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ1wxdqnSm5Q for ; Mon, 19 Oct 2009 09:48:22 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 602993A679C for ; Mon, 19 Oct 2009 09:48:22 -0700 (PDT) Received: from dnab42206a.stanford.edu ([171.66.32.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1MzvPJ-0002ad-1U; Mon, 19 Oct 2009 09:48:29 -0700 Message-Id: From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4AD79131.2080102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 09:08:11 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <6DCBCDE6-1415-44E3-A613-A02F9F839255@cs.stanford.edu> <4AD7778D.7040708@gmail.com> <7F9D7480-668B-46A3-BFE9-5A8B8E7D4C83@cs.stanford.edu> <4AD77CC7.5000707@gmail.com> <96DF2DFC-8023-4CEA-9B56-AAA34EFC2FF2@cs.stanford.edu> <4AD79131.2080102@gmail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 6c66c47a22907c63296a3ecdec1f9d62 Cc: roll ROLL Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 16:48:23 -0000 On Oct 15, 2009, at 2:16 PM, Alexandru Petrescu wrote: > Philip Levis a =E9crit : >> On Oct 15, 2009, at 12:49 PM, Alexandru Petrescu wrote: >>> Philip Levis a =E9crit : >>>> On Oct 15, 2009, at 12:27 PM, Alexandru Petrescu wrote: >>>>> Philip Levis a =E9crit : >>>>>> I think we should keep in mind that RPL must work across =20 >>>>>> multiple link layers. E.g.: >>>>>> A -- 900MHz --> B -- 2.4GHz --> C >>>>>> ETX is a commonly used metric, >>>>> >>>>> Philip, what do you mean by "ETX commonly used metric"? >>>>> >>>>> Could you please explain, in implementation terms. >>>>> >>>>> Could you list some widely available software in solid software =20= >>>>> distributions, widely deployed, and using this ETX metric? >>>> MIT Roofnet/srcr: http://pdos.csail.mit.edu/roofnet/software.php >>>> CTP: = http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/net/ctp= / >>>> OLSR: http://www.olsr.org/docs/README-Link-Quality.html >>> >>> Ah the World Wide Web, h t t p something, wikipedia and google and =20= >>> we know everything... >>> >>> The software being on a website doesn't tell anything about how =20 >>> much it is used. >>> >>> How about software which is not on h t t p something yet it runs ok. >> Meraki's technology is based on srcr (the Roofnet students from MIT =20= >> founded Meraki). Not an IETF standard, but a mesh protocol running =20= >> on 13,000+ networks, serving >4,000,000 clients. Srcr uses ETX/ETT. > > Philip - how about some metric about which _you_ feel like you'd =20 > implement ok, and about which you feel like many people would agree =20= > with, and about which _you_ feel some people may need, and some =20 > usecases may need. > > (sorry being too direct to 'you', but that's what I mean, and no > offence). I think I touched on this in a prior mail; I'll reiterate. It's clear from the requirements documents that LLN applications have =20= multiple routing optimization criteria. The two which seem clearest =20 (to me) are latency and energy. Neither exists in a vacuum, it's a =20 tradeoff. E.g., one trivial way to have zero-energy routing is to =20 never send any packets (unbounded latency). I think latency is a pretty simple one to tackle, with respect to =20 metrics and route selection. I haven't heard much disagreement on =20 this: I'd love to hear what application developers on the list think. Energy (or some notion of energy cost) is a little more challenging. =20 In particular, minimizing the energy spent forwarding the packet isn't =20= the goal. There could be higher-power nodes with unlimited energy, who =20= are willing to forward. =46rom a pure energy standpoint, they are =20 unattractive, but from a notion of how much this energy "costs" the =20 system they are attractive. For this reason, I think that your proposal on a 1280-byte packet =20 doesn't quite fit the bill. Furthermore, the cost of sending a frame =20 can be highly variable. E.g., if I am synchronized with the next hop =20 then it might be cheap. If I'm not, I'll need to do some kind of =20 wakeup operation and it will be expensive. The thing which worries me about some notion of "energy cost," and =20 what makes me wary of suggesting anything just yet, is its range. =20 Packet-BB ran into this a bit with metric specifications. In =20 particular, if we decide that the range is great enough that it =20 requires some kind of simple floating point (exponential notation), =20 then one needs rules to make sure you round up when well below the =20 range set by the exponent. Otherwise, you can get into a situation =20 where adding a hop won't increase the cost, as it's outside the =20 precision allowed. Does that make sense? Phil= From alexandru.petrescu@gmail.com Mon Oct 19 13:47:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A95C3A692E for ; Mon, 19 Oct 2009 13:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icw851Ba3lx0 for ; Mon, 19 Oct 2009 13:47:47 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id D7F0B28C145 for ; Mon, 19 Oct 2009 13:47:46 -0700 (PDT) Received: by bwz23 with SMTP id 23so62080bwz.29 for ; Mon, 19 Oct 2009 13:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=RilbWTU9Hks0T8r6w7jHxIvMTxI1flF0Y4KbeeI12ik=; b=XS4+cZ/AHTwVuzRVsQHFskWztPhjagkPZSxfaKb+JFmIO92M7J3sFLms4Xcd1yKQg8 Vi4PRqty/DlL9A814PimLB/Cp0DCGVc+sCO/bccaRigU+kwoKQDaaplFs4s9B28oJ4Va NAWoNumY96aeQTo0vCbwFtEiHu7bJUy9EXAhc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=yByfkPJTdIkfeCvs9fm2enMG93c755zQuXlzjWZBsWTLHHMldq/TSvAy9pb0WiGK4y mnyCvsk8mNYVsXh8lyvgYQUboQND4hlTDSeWuI8Jgd2hkP38Wcfw7HCSgqONQaPS6yP+ lAAGwrYeRk3AH2rzPKOVmUy5Q/Kp/ijRlCSHI= MIME-Version: 1.0 Received: by 10.223.7.21 with SMTP id b21mr1007775fab.104.1255985270581; Mon, 19 Oct 2009 13:47:50 -0700 (PDT) Date: Mon, 19 Oct 2009 22:47:50 +0200 Message-ID: <840fa9b60910191347q51e67ah4c528580c3e7fffa@mail.gmail.com> From: Alexandru Petrescu To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 20:47:48 -0000 P. Levis wrote recently: > On Oct 15, 2009, at 2:16 PM, Alexandru Petrescu wrote: > >> Philip Levis a =E9crit : >>> On Oct 15, 2009, at 12:49 PM, Alexandru Petrescu wrote: >>>> Philip Levis a =E9crit : >>>>> On Oct 15, 2009, at 12:27 PM, Alexandru Petrescu wrote: >>>>>> Philip Levis a =E9crit : >>>>>>> I think we should keep in mind that RPL must work across >>>>>>> multiple link layers. E.g.: A -- 900MHz --> B -- 2.4GHz >>>>>>> --> C ETX is a commonly used metric, >>>>>> >>>>>> Philip, what do you mean by "ETX commonly used metric"? >>>>>> >>>>>> Could you please explain, in implementation terms. >>>>>> >>>>>> Could you list some widely available software in solid >>>>>> software distributions, widely deployed, and using this ETX >>>>>> metric? >>>>> MIT Roofnet/srcr: >>>>> http://pdos.csail.mit.edu/roofnet/software.php CTP: >>>>> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x/tos/lib/ne= t/ctp/ >>>>> OLSR: http://www.olsr.org/docs/README-Link-Quality.html >>>> >>>> Ah the World Wide Web, h t t p something, wikipedia and google >>>> and we know everything... >>>> >>>> The software being on a website doesn't tell anything about how >>>> much it is used. >>>> >>>> How about software which is not on h t t p something yet it >>>> runs ok. >>> Meraki's technology is based on srcr (the Roofnet students from >>> MIT founded Meraki). Not an IETF standard, but a mesh protocol >>> running on 13,000+ networks, serving >4,000,000 clients. Srcr >>> uses ETX/ETT. >> >> Philip - how about some metric about which _you_ feel like you'd >> implement ok, and about which you feel like many people would agree >> with, and about which _you_ feel some people may need, and some >> usecases may need. >> >> (sorry being too direct to 'you', but that's what I mean, and no >> offence). > > I think I touched on this in a prior mail; I'll reiterate. > > It's clear from the requirements documents that LLN applications have > multiple routing optimization criteria. The two which seem clearest > (to me) are latency and energy. Neither exists in a vacuum, it's a > tradeoff. E.g., one trivial way to have zero-energy routing is to > never send any packets (unbounded latency). > > I think latency is a pretty simple one to tackle, with respect to > metrics and route selection. I haven't heard much disagreement on > this: I'd love to hear what application developers on the list think. > > > > Energy (or some notion of energy cost) is a little more challenging. > In particular, minimizing the energy spent forwarding the packet > isn't the goal. That's what you believe, right? You could state it's not your goal. > There could be higher-power nodes with unlimited energy, who are > willing to forward. From a pure energy standpoint, they are > unattractive, but from a notion of how much this energy "costs" the > system they are attractive. > > For this reason, I think that your proposal on a 1280-byte packet > doesn't quite fit the bill. Which bill? > Furthermore, the cost of sending a frame can be highly variable. That's why I propose a range of min-max. > E.g., if I am synchronized with the next hop then it might be cheap. > If I'm not, I'll need to do some kind of wakeup operation and it will > be expensive. I agree, but we could define the distinction to be accounted for, i.e. the values recorded consider only the cases when ends are in sync. If you talk about dormant modes - I think it's a huge topic touching on about everything ROLL does. Does RPL take this into account with its timers? > The thing which worries me about some notion of "energy cost," and > what makes me wary of suggesting anything just yet, is its range. > Packet-BB ran into this a bit with metric specifications. In > particular, if we decide that the range is great enough that it > requires some kind of simple floating point (exponential notation), > then one needs rules to make sure you round up when well below the > range set by the exponent. Otherwise, you can get into a situation > where adding a hop won't increase the cost, as it's outside the > precision allowed. I think we can fix that. Precision is large enough. Range could be limited enough. This is something we could look at closer. > > Does that make sense? YEs it does in a way, except you still don't propose an energy metric that you feel like you'd implement. YOu keep raising objections about my proposal. I could raise objections about your proposal once you make it= . Alex > > Phil > From richard.kelsey@ember.com Mon Oct 19 14:40:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46A9E28C1D6 for ; Mon, 19 Oct 2009 14:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a00IG-zuQwOA for ; Mon, 19 Oct 2009 14:40:19 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4054B28C11A for ; Mon, 19 Oct 2009 14:40:19 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 17:41:36 -0400 Date: Mon, 19 Oct 2009 17:38:22 -0400 Message-Id: <87pr8j83ox.fsf@kelsey-ws.hq.ember.com> To: "Dearlove, Christopher (UK)" In-reply-to: (Chris.Dearlove@baesystems.com) From: Richard Kelsey References: X-OriginalArrivalTime: 19 Oct 2009 21:41:36.0823 (UTC) FILETIME=[EF31FC70:01CA5104] Cc: roll@ietf.org Subject: Re: [Roll] RPL network size and related details X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 21:40:20 -0000 Date: Mon, 19 Oct 2009 10:57:04 +0100 From: "Dearlove, Christopher (UK)" Looking at draft-ietf-roll-rpl-03, both the summary and the introduction contain the sentence: "Furthermore such networks may potentially comprise a large number of nodes, up to several dozens or hundreds or more nodes in the network." [...] If we take that as that the protocol should work with hundreds of nodes, and might work with thousands (appreciating that issues such as node density also matter) I believe that matches most of the requirements documents, but not I think the urban sensor networks one. I certainly think that the goal is for RPL to work with hundreds and at least up to a few thousand nodes. I know of similar routing protocols working for up to 2000 or so devices in commercial networks. We ought to be able to do as well. -Richard Kelsey From wintert@acm.org Mon Oct 19 16:01:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EADD3A6927 for ; Mon, 19 Oct 2009 16:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqaW9dst1qzR for ; Mon, 19 Oct 2009 16:01:26 -0700 (PDT) Received: from smtp102.prem.mail.ac4.yahoo.com (smtp102.prem.mail.ac4.yahoo.com [76.13.13.41]) by core3.amsl.com (Postfix) with SMTP id 95CBB28C0E5 for ; Mon, 19 Oct 2009 16:01:26 -0700 (PDT) Received: (qmail 37227 invoked from network); 19 Oct 2009 23:01:31 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp102.prem.mail.ac4.yahoo.com with SMTP; 19 Oct 2009 16:01:31 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: YIEQNX4VM1lqW2jG0Vpna3RCheW_ijqYWL10HTljf.IvFq3hcLrSs7vqoPP8sDVPsZG_cFmTkUGX_Q5YEVYF6CEICvsihsCpj0XEU4MAyiBi_QO5Uc85RSNlGIUTwRne3OL.2kv8oxl.ic1TeNYN.2KytNIWu.Y3bE_zlojKHgYzP0nQz2MUeI.UUDtbOEVV9VFO.LjotplTqHJrb80z6EAVO1p0mdM8._ORog47MtgCr__YORVjfVYN2sODnjzq5fxoxUaABIxkBf.CuNlyhiItwDv259J5v6KWF.Xu8sh_IN7yuhwnCrIVkJNy2aVgyy_CH.7rKTHrnnUiH2t5f7huYBv5sh5Ll1ggKkccd2nnop_K5QZiRn8381ix.U_92Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADCEFC3.6050306@acm.org> Date: Mon, 19 Oct 2009 19:01:23 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <87pr8j83ox.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87pr8j83ox.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL network size and related details X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 19 Oct 2009 23:01:27 -0000 I concur, based also on the knowledge of successful commercial networks using DV protocols similar in many key aspects to RPL. The text should be updated to read `thousands'. Although there is still work to do, I do believe RPL is on track to be capable to meet the requirements of the urban application scenario [RFC5548]. -Tim Richard Kelsey wrote: > Date: Mon, 19 Oct 2009 10:57:04 +0100 > From: "Dearlove, Christopher (UK)" > > Looking at draft-ietf-roll-rpl-03, both the summary and the > introduction contain the sentence: > > "Furthermore such networks may potentially comprise a large > number of nodes, up to several dozens or hundreds or more > nodes in the network." > > [...] If we take that as that the protocol > should work with hundreds of nodes, and might work with > thousands (appreciating that issues such as node density > also matter) I believe that matches most of the requirements > documents, but not I think the urban sensor networks one. > > I certainly think that the goal is for RPL to work with > hundreds and at least up to a few thousand nodes. I know of > similar routing protocols working for up to 2000 or so > devices in commercial networks. We ought to be able to do > as well. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Chris.Dearlove@baesystems.com Tue Oct 20 01:40:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A25928C0D7 for ; Tue, 20 Oct 2009 01:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcoiYQSysITE for ; Tue, 20 Oct 2009 01:40:46 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 12A033A6A08 for ; Tue, 20 Oct 2009 01:40:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,590,1249254000"; d="scan'208";a="28308833" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 20 Oct 2009 09:40:53 +0100 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id n9K8ewZn025006; Tue, 20 Oct 2009 09:40:58 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Oct 2009 09:40:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Oct 2009 09:40:03 +0100 Message-ID: In-Reply-To: <4ADCEFC3.6050306@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL network size and related details thread-index: AcpREGuWuOkF8MudRkq6aI4QT5BggwATn7GA References: <87pr8j83ox.fsf@kelsey-ws.hq.ember.com> <4ADCEFC3.6050306@acm.org> From: "Dearlove, Christopher (UK)" To: "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 20 Oct 2009 08:40:52.0816 (UTC) FILETIME=[08678500:01CA5161] Subject: Re: [Roll] RPL network size and related details X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Oct 2009 08:40:47 -0000 Good, but I think we need to distinguish the aims, the what we reasonably expect to achieve, and the what we can demonstrate has been achieved. If the text contains any non-trivial indication of scale (thousands is non-trivial, dozens is not) it ought to indicate how strong that indication is. However even at thousands I don't think this is any indication of meeting the full requirements of RFC 5548, which says: "The number of sensing nodes deployed in the urban environment in support of some applications is expected to be in the order of 10^2 to 10^7" There's rather a lot of headroom between thousands and 10^7, even if not all of those 10^7 are routing nodes. Does anyone have any evidence of the viability of such a network with, let's say 10^6 routing nodes? -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: 20 October 2009 00:01 To: ROLL WG Subject: Re: [Roll] RPL network size and related details *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. I concur, based also on the knowledge of successful commercial networks using DV protocols similar in many key aspects to RPL. The text should be updated to read `thousands'. Although there is still work to do, I do believe RPL is on track to be capable to meet the requirements of the urban application scenario [RFC5548]. -Tim Richard Kelsey wrote: > Date: Mon, 19 Oct 2009 10:57:04 +0100 > From: "Dearlove, Christopher (UK)" > > Looking at draft-ietf-roll-rpl-03, both the summary and the > introduction contain the sentence: > > "Furthermore such networks may potentially comprise a large > number of nodes, up to several dozens or hundreds or more > nodes in the network." > > [...] If we take that as that the protocol > should work with hundreds of nodes, and might work with > thousands (appreciating that issues such as node density > also matter) I believe that matches most of the requirements > documents, but not I think the urban sensor networks one. > > I certainly think that the goal is for RPL to work with > hundreds and at least up to a few thousand nodes. I know of > similar routing protocols working for up to 2000 or so > devices in commercial networks. We ought to be able to do > as well. > -Richard Kelsey > _______________________________________________ > 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 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From wintert@acm.org Tue Oct 20 07:32:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536CF3A6990 for ; Tue, 20 Oct 2009 07:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Me++aHar5U7 for ; Tue, 20 Oct 2009 07:32:47 -0700 (PDT) Received: from smtp106.prem.mail.ac4.yahoo.com (smtp106.prem.mail.ac4.yahoo.com [76.13.13.45]) by core3.amsl.com (Postfix) with SMTP id 4E29F3A6948 for ; Tue, 20 Oct 2009 07:32:47 -0700 (PDT) Received: (qmail 2439 invoked from network); 20 Oct 2009 14:32:50 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp106.prem.mail.ac4.yahoo.com with SMTP; 20 Oct 2009 07:32:50 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: uLlg7PoVM1mXbMbiParyFhxEcfjBKO6HxyshYlh3DpPHu_vdwVL4f804jLuyDRFLH72QPZ1fNGhMPH.sAav47vYwG1WsfcHtOf12X9O8MH2p8tEwzUVOKWen857UvjJtt_NBa4ujdg1d18mbbMeA7BbAEdAM7nvVYsusLyhe5cU4B6FBOCG2IIFmGXPv7cl8edxVY3RPWinZu6t00aPEyfjL8_F1gLGyN3LD_JG5C4VN0Qb8oiPit6Hjpqd3xMdo3fcA2N4XMhCf5FdaSRvJ._7n0tW7DxWa2EzOVkJSW7XMl4I5SS1EK2zP.V_oNRs4N2bAqND1.2aveznRZlsleSn2r98- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4ADDCA0D.7030400@acm.org> Date: Tue, 20 Oct 2009 10:32:45 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <87pr8j83ox.fsf@kelsey-ws.hq.ember.com> <4ADCEFC3.6050306@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL network size and related details X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Oct 2009 14:32:48 -0000 To provide some additional background, one of the RFC5548 areas that may require to operate networks on the order of 10^7 nodes are smart metering applications in support of a large utility in a dense urban area. RPL ought to allow a deployment in support of such a large network to dynamically partition itself into smaller independent operating regions, by providing for a `divide and conquer' strategy (some have used a `drainage basin' metaphor). Depending on the specifics of the deployment, implementation, number of LBRs, etc. it should be feasible to cause the partitioning such that each independent region may be operating over a target size, e.g. on the order of 10^3 nodes. Specifically, the ability to provision of LBRs to act as independent DAG roots will allow them to draw the `closest' nodes to them. As nodes affiliate themselves with specific LBR(s), and specific DAGs, they become logically partitioned and may exclude interaction with other neighboring nodes that are members of other unaffiliated DAGs. A large deployment on the order of 10^7 nodes may then logically be viewed as, e.g., ~10^4 DAGs with ~10^3 nodes each. This partitioning is dynamic and autonomous. Regards, -Tim Dearlove, Christopher (UK) wrote: > Good, but I think we need to distinguish the aims, the > what we reasonably expect to achieve, and the what we > can demonstrate has been achieved. If the text contains > any non-trivial indication of scale (thousands is > non-trivial, dozens is not) it ought to indicate how > strong that indication is. > > However even at thousands I don't think this is any > indication of meeting the full requirements of RFC 5548, > which says: > > "The number of sensing nodes deployed in the urban > environment in support of some applications is expected to be in the > order of 10^2 to 10^7" > > There's rather a lot of headroom between thousands and 10^7, > even if not all of those 10^7 are routing nodes. > > Does anyone have any evidence of the viability of such a network > with, let's say 10^6 routing nodes? > From roger.alexander@ekasystems.com Tue Oct 20 08:08:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3696028C0F1 for ; Tue, 20 Oct 2009 08:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.286 X-Spam-Level: X-Spam-Status: No, score=0.286 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ETPSb4wEmag for ; Tue, 20 Oct 2009 08:08:42 -0700 (PDT) Received: from n78.bullet.mail.sp1.yahoo.com (n78.bullet.mail.sp1.yahoo.com [98.136.44.42]) by core3.amsl.com (Postfix) with SMTP id 77D4628C0FD for ; Tue, 20 Oct 2009 08:08:42 -0700 (PDT) Received: from [216.252.122.216] by n78.bullet.mail.sp1.yahoo.com with NNFMP; 20 Oct 2009 15:08:50 -0000 Received: from [69.147.65.162] by t1.bullet.sp1.yahoo.com with NNFMP; 20 Oct 2009 15:08:50 -0000 Received: from [127.0.0.1] by omp407.mail.sp1.yahoo.com with NNFMP; 20 Oct 2009 15:08:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 647610.26671.bm@omp407.mail.sp1.yahoo.com Received: (qmail 32668 invoked by uid 60001); 20 Oct 2009 15:08:50 -0000 Message-ID: <327588.30458.qm@web1208.biz.mail.gq1.yahoo.com> X-YMail-OSG: pJ3k_0QVM1lf7ed3h1qBzuoKsi8BVvXwAA7sCtjta5PdZLxRtW1MbvmA Received: from [75.36.137.64] by web1208.biz.mail.gq1.yahoo.com via HTTP; Tue, 20 Oct 2009 08:08:49 PDT X-Mailer: YahooMailClassic/8.0.7 YahooMailWebService/0.7.347.3 Date: Tue, 20 Oct 2009 08:08:49 -0700 (PDT) From: Roger Alexander To: ROLL WG , Tim Winter In-Reply-To: <4ADDCA0D.7030400@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Roll] RPL network size and related details X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Oct 2009 15:08:43 -0000 Having successfully deployed and maintained multiple urban networks includi= ng ones of order 10^4 based on the central principle of autonomous (self-se= gmenting) network partitioning I can concur with the approach that Tim has = discussed and how it can be applied in the context of RPL (though the requi= red mechanisms would need to be further fully specified). =0A=0AOur current= on-going experience shows that there is no inherent limitation that would = prevent scalability from readily extending to networks on the order of 10^7= based on autonomous, dynamic partitioning. An important consideration of c= ourse is keeping the routing overhead low so that the partitioned segments = can be large enough to limit the number of LBRs that must be deployed.=0A= =0ARegards,=0A=0ARoger K. Alexander=0A=0A--- On Tue, 10/20/09, Tim Winter <= wintert@acm.org> wrote:=0A=0A> From: Tim Winter =0A> Subje= ct: Re: [Roll] RPL network size and related details=0A> To: "ROLL WG" =0A> Date: Tuesday, October 20, 2009, 2:32 PM=0A> To provide some= additional=0A> background, one of the RFC5548 areas that may=0A> require t= o operate networks on the order of 10^7 nodes are=0A> smart metering=0A> ap= plications in support of a large utility in a dense urban=0A> area.=0A> =0A= > RPL ought to allow a deployment in support of such a large=0A> network to= =0A> dynamically partition itself into smaller independent=0A> operating re= gions, by=0A> providing for a `divide and conquer' strategy (some have=0A> = used a `drainage=0A> basin' metaphor).=A0 Depending on the specifics of the= =0A> deployment,=0A> implementation, number of LBRs, etc. it should be feas= ible=0A> to cause the=0A> partitioning such that each independent region ma= y be=0A> operating over a=0A> target size, e.g. on the order of 10^3 nodes.= =A0=0A> Specifically, the ability to=0A> provision of LBRs to act as indepe= ndent DAG roots will=0A> allow them to draw=0A> the `closest' nodes to them= ..=A0 As nodes affiliate=0A> themselves with specific=0A> LBR(s), and specif= ic DAGs, they become logically=0A> partitioned and may exclude=0A> interact= ion with other neighboring nodes that are members=0A> of other=0A> unaffili= ated DAGs.=A0 A large deployment on the order of=0A> 10^7 nodes may then=0A= > logically be viewed as, e.g., ~10^4 DAGs with ~10^3 nodes=0A> each.=A0 Th= is=0A> partitioning is dynamic and autonomous.=0A> =0A> Regards,=0A> =0A> -= Tim=0A> =0A> =0A> Dearlove, Christopher (UK) wrote:=0A> > Good, but I think= we need to distinguish the aims,=0A> the=0A> > what we reasonably expect t= o achieve, and the what we=0A> > can demonstrate has been achieved. If the = text=0A> contains=0A> > any non-trivial indication of scale (thousands is= =0A> > non-trivial, dozens is not) it ought to indicate how=0A> > strong th= at indication is.=0A> > =0A> > However even at thousands I don't think this= is any=0A> > indication of meeting the full requirements of RFC=0A> 5548,= =0A> > which says:=0A> > =0A> > "The number of sensing nodes deployed in th= e urban=0A> > environment in support of some applications is=0A> expected t= o be in the=0A> > order of 10^2 to 10^7"=0A> > =0A> > There's rather a lot = of headroom between thousands and=0A> 10^7,=0A> > even if not all of those = 10^7 are routing nodes.=0A> > =0A> > Does anyone have any evidence of the v= iability of such=0A> a network=0A> > with, let's say 10^6 routing nodes?=0A= > > =0A> _______________________________________________=0A> Roll mailing l= ist=0A> Roll@ietf.org=0A> https://www.ietf.org/mailman/listinfo/roll=0A> From richard.kelsey@ember.com Tue Oct 20 08:15:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53D43A67FB for ; Tue, 20 Oct 2009 08:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObqdM-tc1xj5 for ; Tue, 20 Oct 2009 08:15:57 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 92A9C3A67BD for ; Tue, 20 Oct 2009 08:15:57 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 11:17:16 -0400 Date: Tue, 20 Oct 2009 11:13:59 -0400 Message-Id: <87k4yq85e0.fsf@kelsey-ws.hq.ember.com> To: Tim Winter In-reply-to: <4ADDCA0D.7030400@acm.org> (message from Tim Winter on Tue, 20 Oct 2009 10:32:45 -0400) From: Richard Kelsey References: <87pr8j83ox.fsf@kelsey-ws.hq.ember.com> <4ADCEFC3.6050306@acm.org> <4ADDCA0D.7030400@acm.org> X-OriginalArrivalTime: 20 Oct 2009 15:17:16.0556 (UTC) FILETIME=[689E3CC0:01CA5198] Cc: roll@ietf.org Subject: Re: [Roll] RPL network size and related details X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Oct 2009 15:15:58 -0000 Date: Tue, 20 Oct 2009 10:32:45 -0400 From: Tim Winter To provide some additional background, one of the RFC5548 areas that may require to operate networks on the order of 10^7 nodes are smart metering applications in support of a large utility in a dense urban area. RPL ought to allow a deployment in support of such a large network to dynamically partition itself into smaller independent operating regions, by providing for a `divide and conquer' strategy (some have used a `drainage basin' metaphor). Depending on the specifics of the deployment, implementation, number of LBRs, etc. it should be feasible to cause the partitioning such that each independent region may be operating over a target size, e.g. on the order of 10^3 nodes. Specifically, the ability to provision of LBRs to act as independent DAG roots will allow them to draw the `closest' nodes to them. As nodes affiliate themselves with specific LBR(s), and specific DAGs, they become logically partitioned and may exclude interaction with other neighboring nodes that are members of other unaffiliated DAGs. A large deployment on the order of 10^7 nodes may then logically be viewed as, e.g., ~10^4 DAGs with ~10^3 nodes each. This partitioning is dynamic and autonomous. The electric metering network in Gothenburg, Sweden works this way. They have 250k 802.15.4/ZigBee nodes of 8k are DAG roots ('concentrators' in ZigBee-speak), which averages out to about 32 nodes in each DAG. As an aside, Gothenburg's population is about 500k, so they have one node for every two people. I begin to understand all the interest in this market. There are some more details in this presentation by the Gothenburg utility's project manager: http://www.zigbee.org/imwp/download.asp?ContentID=16104 -Richard Kelsey From pthubert@cisco.com Tue Oct 20 09:26:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B0593A682A for ; Tue, 20 Oct 2009 09:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.667 X-Spam-Level: X-Spam-Status: No, score=-9.667 tagged_above=-999 required=5 tests=[AWL=0.931, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQYiSEVbsbsb for ; Tue, 20 Oct 2009 09:26:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8204E3A6778 for ; Tue, 20 Oct 2009 09:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7426; q=dns/txt; s=amsiport01001; t=1256055992; x=1257265592; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20load=20based=20parent=20selection=20and =20CAC|Date:=20Tue,=2020=20Oct=202009=2018:26:23=20+0200 |Message-ID:=20<6A2A459175DABE4BB11DE2026AA50A5D740AD0@XM B-AMS-107.cisco.com>|To:=20"roll=20ROLL"=20|MIME-Version:=201.0; bh=TF1B3oA4fr+Xbn5Pt8qncUhtxhJfv3gNzGZcTGDAr6s=; b=cC4Mvv1hpDfN7MHLvrYVbOh6qJe+uZE0523oT8tTLlKqboBpigo4C0CY t+nXDQ0qOiVMOkgOyI+tGs2a3INlU180YzEnvNdIE69PlxcqYVyNCkvru 7Gj2ANapoN2YUvLY7f3Pgubz3LAoLoyzcxwb3Ba71Ao333dKnc1TDCHgv w=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8AAHeB3UqQ/uCWe2dsb2JhbACCKCyYRwEBCwskBqZimDSEMQQ X-IronPort-AV: E=Sophos;i="4.44,592,1249257600"; d="scan'208,217";a="52275538" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2009 16:26:30 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9KGQUHY015160 for ; Tue, 20 Oct 2009 16:26:30 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 18:26:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA51A2.143EFD0D" Date: Tue, 20 Oct 2009 18:26:23 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: load based parent selection and CAC Thread-Index: AcpRohAQKrom5rOATIOvXHBn4wcbPA== From: "Pascal Thubert (pthubert)" To: "roll ROLL" X-OriginalArrivalTime: 20 Oct 2009 16:26:30.0099 (UTC) FILETIME=[14529A30:01CA51A2] Subject: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Oct 2009 16:26:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA51A2.143EFD0D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi: =20 Here's what I gathered from the industrial space: =20 'Buffered' sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer. The buffer is then transmitted at a same or different frequency than that of capture.=20 If the data capture frequency is higher than the transmit frequency then the buffer is overwritten and some readings are just lost. =20 The buffered data might be lost on the way and that's usually OK, but some applications react very badly to jitter. =20 This strikes me as resembling quite a bit to voice over radio. A technique called Load-Based Call Admission Control is used in WCDMA and WIFI to compute whether there's enough free space to take an additional call that will fit the codec characteristics. Basically that's a set of heuristics and a magical formula that uses the measure of the energy in the channel and the transmit queue delays to compute whether there's enough free space in the air.=20 =20 Obviously, using such load estimate to do routing would take us back to Arpanet and is a proven bad idea. But I thought that it could be used: - By hosts to select a router - By routers to select a next_hop between its parents for a given packet (IOW a packet forwarding time metric as opposed to a routing time metric). =20 What do you think? =20 Pascal =20 ------_=_NextPart_001_01CA51A2.143EFD0D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi:

 

Here’s what I gathered from the industrial = space:

 

‘Buffered’ sensor data is captured at a = certain frequency (typically 4Hz) and placed in a buffer.

The buffer is then transmitted at a same or = different frequency than that of capture.

If the data capture frequency is higher than the = transmit frequency then the buffer is overwritten and some readings are just = lost.

 

The buffered data might be lost on the way and = that’s usually OK, but some applications react very badly to = jitter.

 

This strikes me as resembling quite a bit to voice = over radio. A technique called Load-Based Call Admission Control is used in WCDMA = and WIFI to compute whether there’s enough free space to take an additional = call that will fit the codec characteristics. Basically that’s a set of = heuristics and a magical formula that uses the measure of the energy in the channel and = the transmit queue delays to compute whether there’s enough free space = in the air.

 

Obviously, using such load estimate to do routing = would take us back to Arpanet and is a proven bad idea. But I thought that it could = be used:

-          By hosts to select a router

-          By routers to select a next_hop between its = parents for a given packet (IOW a packet forwarding time metric as opposed to a = routing time metric).

 

What do you think?

 

Pascal

 

------_=_NextPart_001_01CA51A2.143EFD0D-- From maxence.dalmais@insa-lyon.fr Tue Oct 20 10:43:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5802D28C191 for ; Tue, 20 Oct 2009 10:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZC2qWmr-qDe for ; Tue, 20 Oct 2009 10:43:44 -0700 (PDT) Received: from smtp.insa-lyon.fr (criges14.insa-lyon.fr [134.214.76.242]) by core3.amsl.com (Postfix) with ESMTP id 37E0828C18B for ; Tue, 20 Oct 2009 10:43:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 3CF6FF1288 for ; Tue, 20 Oct 2009 19:43:48 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYgPHbmUua-I for ; Tue, 20 Oct 2009 19:43:48 +0200 (CEST) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: mdalmais1) by smtp.insa-lyon.fr (Postfix) with ESMTPSA id 86AEBF1293 for ; Tue, 20 Oct 2009 19:43:47 +0200 (CEST) Received: by qyk29 with SMTP id 29so4461212qyk.32 for ; Tue, 20 Oct 2009 10:43:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.145.149 with SMTP id s21mr528937hba.141.1256060625194; Tue, 20 Oct 2009 10:43:45 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> From: Maxence Dalmais Date: Tue, 20 Oct 2009 19:43:25 +0200 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=001485f724b661905e04766167b2 Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 20 Oct 2009 17:43:45 -0000 --001485f724b661905e04766167b2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pascal, On Tue, Oct 20, 2009 at 6:26 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hi: > > > > Here=92s what I gathered from the industrial space: > > > > =91Buffered=92 sensor data is captured at a certain frequency (typically = 4Hz) > and placed in a buffer. > > The buffer is then transmitted at a same or different frequency than that > of capture. > > If the data capture frequency is higher than the transmit frequency then > the buffer is overwritten and some readings are just lost. > > > > The buffered data might be lost on the way and that=92s usually OK, but s= ome > applications react very badly to jitter. > > > > This strikes me as resembling quite a bit to voice over radio. A techniqu= e > called Load-Based Call Admission Control is used in WCDMA and WIFI to > compute whether there=92s enough free space to take an additional call th= at > will fit the codec characteristics. Basically that=92s a set of heuristic= s and > a magical formula that uses the measure of the energy in the channel and = the > transmit queue delays to compute whether there=92s enough free space in t= he > air. > > > > Obviously, using such load estimate to do routing would take us back to > Arpanet and is a proven bad idea. But I thought that it could be used: > > - By hosts to select a router > > - By routers to select a next_hop between its parents for a give= n > packet (IOW a packet forwarding time metric as opposed to a routing time > metric). > > Yes but how would you expect "host" to use that information to select the router ? It may very well be that the router offering the lower forwarding time end up following a high forwarding time path. [adapt from JP Vasseur in RPL Metric I-D ]. Maxence. > > > What do you think? > > > Hi Pascal, Yes but how would you expect "host" to use that information to select the router ? It may very well be that the router offering the lower energy cost end up following a high energy path. > Pascal > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001485f724b661905e04766167b2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pascal,

On Tue, Oct 20, 2009 at 6:26 PM, Pascal Thub= ert (pthubert) <= pthubert@cisco.com> wrote:

Hi:

=A0

Here=92s what I gathered from the industrial space:<= /p>

=A0

=91Buffered=92 sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer.

The buffer is then transmitted at a same or differen= t frequency than that of capture.

If the data capture frequency is higher than the tra= nsmit frequency then the buffer is overwritten and some readings are just lost.

=A0

The buffered data might be lost on the way and that= =92s usually OK, but some applications react very badly to jitter.

=A0

This strikes me as resembling quite a bit to voice o= ver radio. A technique called Load-Based Call Admission Control is used in WCDMA and W= IFI to compute whether there=92s enough free space to take an additional call t= hat will fit the codec characteristics. Basically that=92s a set of heuristics = and a magical formula that uses the measure of the energy in the channel and th= e transmit queue delays to compute whether there=92s enough free space in the air.

=A0

Obviously, using such load estimate to do routing wo= uld take us back to Arpanet and is a proven bad idea. But I thought that it could be used:

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 By hosts to select a router

-=A0=A0=A0= =A0=A0=A0=A0=A0=A0 By routers to select a next_hop between its parents for a given packet (IOW a packet forwarding time metric as opposed to a routing= time metric).



Yes but how would you expect "host" to use that information= to select the router ?
It may very well be that the router offering the lower forwarding time end = up following a high forwarding time path.=A0 [adapt from JP Vasseur in RPL = Metric I-D ].

Maxence.

=A0

What do you think?

=A0

Hi Pascal,
<= br>
Yes but how would you expect "host" to use that information to se= lect the router ?
It may very well be that the router offering the lower energy cost end up f= ollowing a high energy path.

Pascal

=A0


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001485f724b661905e04766167b2-- From jvasseur@cisco.com Tue Oct 20 22:45:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE983A682B for ; Tue, 20 Oct 2009 22:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSekQyM8OI2Q for ; Tue, 20 Oct 2009 22:45:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F3C843A681D for ; Tue, 20 Oct 2009 22:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=9754; q=dns/txt; s=sjiport06001; t=1256103945; x=1257313545; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20JP=20Vasseur=20|Subject:=20R e:=20[Roll]=20load=20based=20parent=20selection=20and=20C AC|Date:=20Tue,=2020=20Oct=202009=2022:45:43=20-0700 |Message-Id:=20|To:=20Pascal=20Thubert=20(pthubert)=20|Cc:=20"roll=20ROLL"=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v93 6)|In-Reply-To:=20<6A2A459175DABE4BB11DE2026AA50A5D740AD0 @XMB-AMS-107.cisco.com>|References:=20<6A2A459175DABE4BB1 1DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com>; bh=xO9Nchxt+jp9isUihlOdRezoQu1K/c36IvuocxdpF/c=; b=f55GY2FXMoQUCVln1o3RfnUcywR442gjFZve+UTAZ7K4o6gDH8AhQwjy 0+T41vA1aclK5s99hRhDYK5hWVdswrJnNkyoLaeo1JFj75FTKnYeeqohW Q1lEIpjRDT2m6kiT7eX7iDwkcYw6uv4dEk7UPG9/e5aA6tb2dTHEUgA2w o=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAG893kqrR7H+/2dsb2JhbACCKCy9QJhehDEE X-IronPort-AV: E=Sophos;i="4.44,595,1249257600"; d="scan'208,217";a="414087632" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 21 Oct 2009 05:45:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9L5jjGX018186 for ; Wed, 21 Oct 2009 05:45:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 22:45:45 -0700 Received: from [10.2.42.214] ([10.21.113.71]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 22:45:44 -0700 Message-Id: From: JP Vasseur To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-33-771352938 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Oct 2009 22:45:43 -0700 References: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 21 Oct 2009 05:45:45.0109 (UTC) FILETIME=[BBBC6C50:01CA5211] Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Oct 2009 05:45:38 -0000 --Apple-Mail-33-771352938 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Oct 20, 2009, at 9:26 AM, Pascal Thubert (pthubert) wrote: > Hi: > > Here=92s what I gathered from the industrial space: > > =91Buffered=92 sensor data is captured at a certain frequency = (typically =20 > 4Hz) and placed in a buffer. > The buffer is then transmitted at a same or different frequency than =20= > that of capture. > If the data capture frequency is higher than the transmit frequency =20= > then the buffer is overwritten and some readings are just lost. > > The buffered data might be lost on the way and that=92s usually OK, =20= > but some applications react very badly to jitter. > > This strikes me as resembling quite a bit to voice over radio. A =20 > technique called Load-Based Call Admission Control is used in WCDMA =20= > and WIFI to compute whether there=92s enough free space to take an =20 > additional call that will fit the codec characteristics. Basically =20 > that=92s a set of heuristics and a magical formula that uses the =20 > measure of the energy in the channel and the transmit queue delays =20 > to compute whether there=92s enough free space in the air. > > Obviously, using such load estimate to do routing would take us back =20= > to Arpanet and is a proven bad idea. But I thought that it could be =20= > used: > - By hosts to select a router > - By routers to select a next_hop between its parents for a =20= > given packet (IOW a packet forwarding time metric as opposed to a =20 > routing time metric). > CAC is fairly well-known but is typically end to end (e.g. RSVP). If =20 what you want is another local decision criteria then no need to make it a routing metric. JP. > What do you think? > > Pascal > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-33-771352938 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Oct 20, 2009, = at 9:26 AM, Pascal Thubert (pthubert) wrote:

Hi:
Here=92s what I gathered from the = industrial space:
 
If the data capture frequency = is higher than the transmit frequency then the buffer is overwritten and = some readings are just lost.
The buffered data might be lost on = the way and that=92s usually OK, but some applications react very badly = to jitter.
 
Obviously, using such load estimate = to do routing would take us back to Arpanet and is a proven bad idea. = But I thought that it could be used:
- By hosts to = select a router
          By routers to = select a next_hop between its parents for a given packet (IOW a packet = forwarding time metric as opposed to a routing time = metric).
What do you = think?
 
|Subject:=20RE:=20[Roll]=20load=20based=20parent=20 selection=20and=20CAC|Date:=20Wed,=2021=20Oct=202009=2016 :29:40=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2026AA 50A5D74102B@XMB-AMS-107.cisco.com>|To:=20"JP=20Vasseur=20 (jvasseur)"=20|Cc:=20"roll=20ROLL"=20 |MIME-Version:=201.0|In-Reply-To:=20|References:=20 <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco .com>=20; bh=qxmIshoOHXnGLYJjouktoYIgbaGDX0zprL/yQfD94P8=; b=ZpMpmARYAQatwDEPTCUoYawSorfQhwnNgFsTy86sqlJY8iaEAZTJVBRF wgnA0EBrGsHm5kW+2DxnYIwSuz0TPUAhV3DID8EYV2U9FNn6Y0RIjtHJ1 coYJxH3iJPB2Bey58PwqG12DQNfj+Pg+kIqXFroRgO7+GmmDjK956GpKk 0=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoEAAK43kqrR7H+/2dsb2JhbACCKCzAfphWhDEE X-IronPort-AV: E=Sophos;i="4.44,597,1249257600"; d="scan'208,217";a="259248609" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2009 14:29:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9LETlGf007154 for ; Wed, 21 Oct 2009 14:29:49 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:29:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA525A.F074CEAD" Date: Wed, 21 Oct 2009 16:29:40 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D74102B@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] load based parent selection and CAC Thread-Index: AcpSEcFZ5E8Hc63PQxmezBmJ+KsxeAASOVcA References: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 21 Oct 2009 14:29:47.0016 (UTC) FILETIME=[F092B080:01CA525A] Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Oct 2009 14:29:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA525A.F074CEAD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi JP: =20 If the utilization metric is to be used at all then it must represent a path not a hop. So it needs to be passed along by the routers. =20 Pascal From: JP Vasseur (jvasseur)=20 Sent: mercredi 21 octobre 2009 07:46 To: Pascal Thubert (pthubert) Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC =20 =20 On Oct 20, 2009, at 9:26 AM, Pascal Thubert (pthubert) wrote: Hi: =20 Here's what I gathered from the industrial space: =20 'Buffered' sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer. The buffer is then transmitted at a same or different frequency than that of capture. If the data capture frequency is higher than the transmit frequency then the buffer is overwritten and some readings are just lost. =20 The buffered data might be lost on the way and that's usually OK, but some applications react very badly to jitter. =20 This strikes me as resembling quite a bit to voice over radio. A technique called Load-Based Call Admission Control is used in WCDMA and WIFI to compute whether there's enough free space to take an additional call that will fit the codec characteristics. Basically that's a set of heuristics and a magical formula that uses the measure of the energy in the channel and the transmit queue delays to compute whether there's enough free space in the air. =20 Obviously, using such load estimate to do routing would take us back to Arpanet and is a proven bad idea. But I thought that it could be used: - By hosts to select a router - By routers to select a next_hop between its parents for a given packet (IOW a packet forwarding time metric as opposed to a routing time metric). =20 =20 CAC is fairly well-known but is typically end to end (e.g. RSVP). If what you want is another local decision criteria then no need to make it a routing metric. =20 JP. What do you think? =20 Pascal =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CA525A.F074CEAD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi JP:

 

If the utilization metric is to be used at all then it = must represent a path not a hop. So it needs to be passed along by the = routers.

 

Pascal

From:= JP Vasseur (jvasseur)
Sent: mercredi 21 octobre 2009 07:46
To: Pascal Thubert (pthubert)
Cc: roll ROLL
Subject: Re: [Roll] load based parent selection and = CAC

 

 

On Oct 20, 2009, at 9:26 AM, Pascal Thubert = (pthubert) wrote:



Hi:

 

Here’s what I gathered from the industrial = space:

 

‘Buffered’ sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer.

The buffer is then transmitted at a same or different = frequency than that of capture.

If the data capture frequency is higher than the transmit frequency then the buffer is overwritten and some readings are just = lost.

 

The buffered data might be lost on the way and that’s usually OK, but some applications react very badly to = jitter.

 

This strikes me as resembling quite a bit to voice over = radio. A technique called Load-Based Call Admission Control is used in WCDMA and = WIFI to compute whether there’s enough free space to take an additional = call that will fit the codec characteristics. Basically that’s a set of = heuristics and a magical formula that uses the measure of the energy in the channel = and the transmit queue delays to compute whether there’s enough free = space in the air.

 

Obviously, using such load estimate to do routing would = take us back to Arpanet and is a proven bad idea. But I thought that it could be = used:

-         =  By hosts to select a = router

-         =  By routers to select a = next_hop between its parents for a given packet (IOW a packet forwarding time = metric as opposed to a routing time metric).

 

 

CAC is fairly well-known but is typically end to = end (e.g. RSVP). If what you want is another local decision = criteria

then no need to make it a routing = metric.

 

JP.



What do you think?

 

Pascal

 

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

 

------_=_NextPart_001_01CA525A.F074CEAD-- From pister@eecs.berkeley.edu Wed Oct 21 11:18:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8648C3A6861 for ; Wed, 21 Oct 2009 11:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m44uKhD2Cq5D for ; Wed, 21 Oct 2009 11:18:00 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id C914A3A682F for ; Wed, 21 Oct 2009 11:18:00 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n9LIHd2K027861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Oct 2009 11:17:40 -0700 (PDT) Message-ID: <4ADF5042.4010203@eecs.berkeley.edu> Date: Wed, 21 Oct 2009 11:17:38 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> Content-Type: multipart/alternative; boundary="------------030409020304070603080407" Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Oct 2009 18:18:05 -0000 This is a multi-part message in MIME format. --------------030409020304070603080407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pascal - it would be unseemly for the two IA requirements document editors to argue about IA requirement in public :) so I'll just present these comments as an alternative interpretation. Pascal Thubert (pthubert) wrote: > > Hi: > > > > Here's what I gathered from the industrial space: > > > > 'Buffered' sensor data is captured at a certain frequency (typically > 4Hz) and placed in a buffer. > > The buffer is then transmitted at a same or different frequency than > that of capture. > > If the data capture frequency is higher than the transmit frequency > then the buffer is overwritten and some readings are just lost. > I've never seen an application like this. The vast majority of applications sample (capture) and send immediately. A small minority sample repeatedly before sending, but none of them would just overwrite the existing data. That would show up as lost data in the network stats, and people would get mad. > > > > The buffered data might be lost on the way and that's usually OK, but > some applications react very badly to jitter. > I've never seen an application where lost data was ok, but jitter caused bad reactions. Lost data is indistinguishable from long-jitter, yes?. Again, latency above some specified max counts as lost. > > > > This strikes me as resembling quite a bit to voice over radio. A > technique called Load-Based Call Admission Control is used in WCDMA > and WIFI to compute whether there's enough free space to take an > additional call that will fit the codec characteristics. Basically > that's a set of heuristics and a magical formula that uses the measure > of the energy in the channel and the transmit queue delays to compute > whether there's enough free space in the air. > Can you elaborate on the heuristics and the magical formula? > > > > Obviously, using such load estimate to do routing would take us back > to Arpanet and is a proven bad idea. But I thought that it could be used: > > - By hosts to select a router > > - By routers to select a next_hop between its parents for a > given packet (IOW a packet forwarding time metric as opposed to a > routing time metric). > If I have several 1-hop nodes (with links to an LBR), and a whole bunch of other nodes further away routing through them, I'd really like to load balance among the 1-hop nodes. So I'd like to be able to make a decision on which 5-hop parent to join based on the 1-hop energy/lifetime metrics. Is that what you're talking about too? ksjp > > > > What do you think? > > > > Pascal > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------030409020304070603080407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pascal - it would be unseemly for the two IA requirements document editors to argue about IA requirement in public :)
so I'll just present these comments as an alternative interpretation.

Pascal Thubert (pthubert) wrote:

Hi:

 

Here’s what I gathered from the industrial space:

 

‘Buffered’ sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer.

The buffer is then transmitted at a same or different frequency than that of capture.

If the data capture frequency is higher than the transmit frequency then the buffer is overwritten and some readings are just lost.

I've never seen an application like this.  The vast majority of applications sample (capture) and send immediately.  A small minority sample repeatedly before sending, but none of them would just overwrite the existing data.  That would show up as lost data in the network stats, and people would get mad.

 

The buffered data might be lost on the way and that’s usually OK, but some applications react very badly to jitter.

I've never seen an application where lost data was ok, but jitter caused bad reactions.  Lost data is indistinguishable from long-jitter, yes?.  Again, latency above some specified max counts as lost.

 

This strikes me as resembling quite a bit to voice over radio. A technique called Load-Based Call Admission Control is used in WCDMA and WIFI to compute whether there’s enough free space to take an additional call that will fit the codec characteristics. Basically that’s a set of heuristics and a magical formula that uses the measure of the energy in the channel and the transmit queue delays to compute whether there’s enough free space in the air.

Can you elaborate on the heuristics and the magical formula?

 

Obviously, using such load estimate to do routing would take us back to Arpanet and is a proven bad idea. But I thought that it could be used:

-          By hosts to select a router

-          By routers to select a next_hop between its parents for a given packet (IOW a packet forwarding time metric as opposed to a routing time metric).

If I have several 1-hop nodes (with links to an LBR), and a whole bunch of other nodes further away routing through them, I'd really like to load balance among the 1-hop nodes.  So I'd like to be able to make a decision on which 5-hop parent to join based on the 1-hop energy/lifetime metrics.  Is that what you're talking about too?

ksjp

 

What do you think?

 

Pascal

 


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------030409020304070603080407-- From pal@cs.stanford.edu Wed Oct 21 18:41:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F3D3A68D6 for ; Wed, 21 Oct 2009 18:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ-ND2U2sQ3N for ; Wed, 21 Oct 2009 18:41:26 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 3FF023A6876 for ; Wed, 21 Oct 2009 18:41:26 -0700 (PDT) Received: from [69.38.231.138] (helo=[10.71.0.153]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N0mgJ-0005pz-1d; Wed, 21 Oct 2009 18:41:35 -0700 Message-Id: From: Philip Levis To: Alexandru Petrescu In-Reply-To: <840fa9b60910191347q51e67ah4c528580c3e7fffa@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 10:42:33 -0700 References: <840fa9b60910191347q51e67ah4c528580c3e7fffa@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 01:41:28 -0000 On Oct 19, 2009, at 1:47 PM, Alexandru Petrescu wrote: >> There could be higher-power nodes with unlimited energy, who are >> willing to forward. From a pure energy standpoint, they are >> unattractive, but from a notion of how much this energy "costs" the >> system they are attractive. >> >> For this reason, I think that your proposal on a 1280-byte packet >> doesn't quite fit the bill. > > Which bill? I'm sorry -- it's a colloquialism. I meant "For this reason, I think that your proposal on a 1280-byte packet isn't well suited to maximizing network lifetime." That doesn't mean it's not useful, or well suited to other administrative concerns. It's just that "low power" is generally -- but not always -- about maximizing network lifetime. > >> Furthermore, the cost of sending a frame can be highly variable. > > That's why I propose a range of min-max. > >> E.g., if I am synchronized with the next hop then it might be cheap. >> If I'm not, I'll need to do some kind of wakeup operation and it will >> be expensive. > > I agree, but we could define the distinction to be accounted for, i.e. > the values recorded consider only the cases when ends are in sync. > > If you talk about dormant modes - I think it's a huge topic touching > on > about everything ROLL does. Does RPL take this into account with its > timers? I think this has come up on the list maybe a half-dozen times or so (or more): this is a link layer operation. The time scales involved are not in the same order of magnitude as ROLL timers. > YEs it does in a way, except you still don't propose an energy metric > that you feel like you'd implement. YOu keep raising objections about > my proposal. I could raise objections about your proposal once you > make it. I know that the IETF is political at times, but I'd hope objections would be raised on technical concerns, rather than authorship. I don't care whose proposal we adopt: I just care that it works well, can be implemented easily, and meets application/administrative requirements. Phil From pal@cs.stanford.edu Wed Oct 21 18:41:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6234A3A691B for ; Wed, 21 Oct 2009 18:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w01W9IG4Ldct for ; Wed, 21 Oct 2009 18:41:32 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 7FB483A68D3 for ; Wed, 21 Oct 2009 18:41:32 -0700 (PDT) Received: from [69.38.231.138] (helo=[10.71.0.153]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N0mgP-0005pz-Cc; Wed, 21 Oct 2009 18:41:41 -0700 Message-Id: <96893DEE-D688-4F41-B883-D09F8F5AC23F@cs.stanford.edu> From: Philip Levis To: Richard Kelsey In-Reply-To: <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 11:06:54 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 01:41:35 -0000 On Oct 15, 2009, at 10:43 AM, Richard Kelsey wrote: > From: Philip Levis > Date: Thu, 15 Oct 2009 09:09:12 -0700 > > On Oct 13, 2009, at 9:02 AM, Richard Kelsey wrote: > >> Those who cannot learn from history are doomed to repeat it. >> >> We have to be careful not to learn the wrong lesson. >> Hopcount without careful link assessment definitely doesn't >> work. Hopcount limited to stable, symmetric links is a >> different beast entirely. For example, consider the Cost/PL >> column in table 1 of [1], which gives the average >> transmissions per link. For most of the networks it is very >> close to 1 and it never goes above 2. That's puts ETX >> pretty close to hopcount for those networks, if routing is >> limited to links with good ETX. > > I fear this assertion might misrepresent the data. An average cost > of > <2 does not by any means suggest that there are no links with cost > >2. > It could be that 80% of links have a cost of 1 and 20% have a cost > of 4. > > Right. I wasn't as clear as I should have been. For > the networks with lowest Cost/PL, such as 1.04 or 1.09, > hopcount would have been nearly identical to ETX as a > metric, if routing were limited to links with good ETX. > > As you point out, for the higher values the Cost/PL > doesn't tell as much about what was happening. The fact > that the highest Cost/PL are less than 2 does indicate > that most of the links used had an ETX less than 1.5. I agree. Steep SNR/PRR curves mean that narrowband wireless physical layers tend to have few intermediate links in the absence of external interference. But my concern is that we need to design a protocol for the hard case, not the easy one. Administrators can't always control the wireless environment: it would be a problem if RPL didn't work in Tutornet, Motelab, or Wyman-park like environments. Furthermore, RPL needs to be able to run over wider-band physical layers, or those with much more gradual SNR/PRR curves. I'm very uncomfortable with the thread of logic hat RPL's topology needs to be very stable. I think all other things being equal, a stable topology is better than a dynamic one, and it's reasonable for implementations to try to improve stability. My worry starts, however, when we start *assuming* it is stable, and relegating highly dynamic networks to an oddity only worth cursory consideration. Doing so will lead to many failed deployments and general skepticism on the engineering and utility of RPL. Phil From pal@cs.stanford.edu Wed Oct 21 18:41:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1413A68D6 for ; Wed, 21 Oct 2009 18:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljW+ypgoe-VA for ; Wed, 21 Oct 2009 18:41:44 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 238DD3A68D3 for ; Wed, 21 Oct 2009 18:41:44 -0700 (PDT) Received: from [69.38.231.138] (helo=[10.71.0.153]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N0mgb-0005pz-8b; Wed, 21 Oct 2009 18:41:53 -0700 Message-Id: From: Philip Levis To: Richard Kelsey In-Reply-To: <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 18:41:47 -0700 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: b0d2d5ababd8fe43140185de29a9e1cb Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 01:41:45 -0000 On Oct 15, 2009, at 10:43 AM, Richard Kelsey wrote: > From: Philip Levis > Date: Thu, 15 Oct 2009 09:09:12 -0700 > > On Oct 13, 2009, at 9:02 AM, Richard Kelsey wrote: > >> Those who cannot learn from history are doomed to repeat it. >> >> We have to be careful not to learn the wrong lesson. >> Hopcount without careful link assessment definitely doesn't >> work. Hopcount limited to stable, symmetric links is a >> different beast entirely. For example, consider the Cost/PL >> column in table 1 of [1], which gives the average >> transmissions per link. For most of the networks it is very >> close to 1 and it never goes above 2. That's puts ETX >> pretty close to hopcount for those networks, if routing is >> limited to links with good ETX. > > I fear this assertion might misrepresent the data. An average cost of > <2 does not by any means suggest that there are no links with cost > >2. > It could be that 80% of links have a cost of 1 and 20% have a cost > of 4. > > Right. I wasn't as clear as I should have been. For > the networks with lowest Cost/PL, such as 1.04 or 1.09, > hopcount would have been nearly identical to ETX as a > metric, if routing were limited to links with good ETX. > > As you point out, for the higher values the Cost/PL > doesn't tell as much about what was happening. The fact > that the highest Cost/PL are less than 2 does indicate > that most of the links used had an ETX less than 1.5. I agree. Steep SNR/PRR curves mean that narrowband wireless physical layers tend to have few intermediate links in the absence of external interference. But my concern is that we need to design a protocol for the hard case, not the easy one. Administrators can't always control the wireless environment: it would be a problem if RPL didn't work in Tutornet, Motelab, or Wyman-park like environments. Furthermore, RPL needs to be able to run over wider-band physical layers, or those with much more gradual SNR/PRR curves. I'm very uncomfortable with the thread of logic hat RPL's topology needs to be very stable. I think all other things being equal, a stable topology is better than a dynamic one, and it's reasonable for implementations to try to improve stability. My worry starts, however, when we start *assuming* it is stable, and relegating highly dynamic networks to an oddity only worth cursory consideration. Doing so will lead to many failed deployments and general skepticism on the engineering and utility of RPL. Phil From pthubert@cisco.com Wed Oct 21 23:17:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B44B28C104 for ; Wed, 21 Oct 2009 23:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=-2.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cBnUyV9MqLK for ; Wed, 21 Oct 2009 23:17:11 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id CBDF83A676A for ; Wed, 21 Oct 2009 23:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=16153; q=dns/txt; s=sjiport03001; t=1256192241; x=1257401841; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20load=20based=20parent=20 selection=20and=20CAC|Date:=20Thu,=2022=20Oct=202009=2008 :17:12=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2026AA 50A5D7A2885@XMB-AMS-107.cisco.com>|To:=20"Kris=20Pister" =20,=0D=0A=20=20=20=20=20=20=20 =20"Alexander=20Chernoguzov"=20,=0D=0A=20=20=20=20=20=20=20=20"Brett,=20Patri cia=20(PA62)"=20|Cc:=20"rol l=20ROLL"=20|MIME-Version:=201.0 |In-Reply-To:=20<4ADF5042.4010203@eecs.berkeley.edu> |References:=20<6A2A459175DABE4BB11DE2026AA50A5D740AD0@XM B-AMS-107.cisco.com>=20<4ADF5042.4010203@eecs.berkeley.ed u>; bh=Kl3pG1wO6uKJ76rGPezTPDx1Dh87MRrTSpU/rEN3H4M=; b=YPNCTWWj2EUolexXGNwzuFttfOZsg+DO0w02ewkFkr6czUdPzoQqR3Sx 0smdL8/p8NSg4pKTnTd/LgZJPi/8adkH3aDWyMdpv0MNuyTMj54NMzS0t 83LToi6MtAIPqawk8xG0crrq5zsf8B+sx2buPCVlmG/a/UK1iCKJFOn3p A=; Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosFAAeV30qrR7H+/2dsb2JhbACCJy2/KZhFhD0EgVyJNg X-IronPort-AV: E=Sophos;i="4.44,602,1249257600"; d="scan'208,217";a="198159648" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2009 06:17:21 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9M6HIgq011755; Thu, 22 Oct 2009 06:17:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 08:17:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA52DF.4F730DB9" Date: Thu, 22 Oct 2009 08:17:12 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D7A2885@XMB-AMS-107.cisco.com> In-Reply-To: <4ADF5042.4010203@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] load based parent selection and CAC Thread-Index: AcpSeuK5+u4wJkQ7RuyGL5L7Ie6r4gAYdDNQ References: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> <4ADF5042.4010203@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" , "Alexander Chernoguzov" , "Brett, Patricia (PA62)" X-OriginalArrivalTime: 22 Oct 2009 06:17:20.0256 (UTC) FILETIME=[4FBEA800:01CA52DF] Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 06:17:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA52DF.4F730DB9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Kris: =20 Since I'm only second hand on the buffered explanation I'll defer to my sources J=20 Alex, I'd really appreciate if you could give use more insight on the buffered data, in particular WRT sensitivity to loss and jitter? =20 There's not so much data on the formulae that we use for Load-Based Call Admission Control but for the patent we filed. You'll find all that info by googling "load-based CAC" but I cannot promise that what Cisco patented is exactly what made it in the final product. I'm not sure that we published that level of information. There is similar work on WCDMA. =20 The patented formulas can be found at: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D= 1&u =3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&d=3D= PG01&s1=3D200 80186846.PGNR.&OS=3DDN/20070198578&RS=3DDN/20080186846=20 =20 I was involved in LB-CAC when I implemented the CAC over our mesh product, in a recent life. The difference is that the metrics must be aggregated over the mesh path, so it gets a bit more complex and harder to prove. Until something changed in the mesh product since we completed that project, Cisco does not to offer the option to do load based CAC over multihop. Which is what I'm talking about here.=20 =20 Pascal From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 Sent: mercredi 21 octobre 2009 20:18 To: Pascal Thubert (pthubert) Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC =20 Pascal - it would be unseemly for the two IA requirements document editors to argue about IA requirement in public :) so I'll just present these comments as an alternative interpretation. Pascal Thubert (pthubert) wrote:=20 Hi: =20 Here's what I gathered from the industrial space: =20 'Buffered' sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer. The buffer is then transmitted at a same or different frequency than that of capture.=20 If the data capture frequency is higher than the transmit frequency then the buffer is overwritten and some readings are just lost. I've never seen an application like this. The vast majority of applications sample (capture) and send immediately. A small minority sample repeatedly before sending, but none of them would just overwrite the existing data. That would show up as lost data in the network stats, and people would get mad. =20 The buffered data might be lost on the way and that's usually OK, but some applications react very badly to jitter. I've never seen an application where lost data was ok, but jitter caused bad reactions. Lost data is indistinguishable from long-jitter, yes?. Again, latency above some specified max counts as lost. =20 This strikes me as resembling quite a bit to voice over radio. A technique called Load-Based Call Admission Control is used in WCDMA and WIFI to compute whether there's enough free space to take an additional call that will fit the codec characteristics. Basically that's a set of heuristics and a magical formula that uses the measure of the energy in the channel and the transmit queue delays to compute whether there's enough free space in the air. Can you elaborate on the heuristics and the magical formula? =20 Obviously, using such load estimate to do routing would take us back to Arpanet and is a proven bad idea. But I thought that it could be used: By hosts to select a router By routers to select a next_hop between its parents for a given packet (IOW a packet forwarding time metric as opposed to a routing time metric). If I have several 1-hop nodes (with links to an LBR), and a whole bunch of other nodes further away routing through them, I'd really like to load balance among the 1-hop nodes. So I'd like to be able to make a decision on which 5-hop parent to join based on the 1-hop energy/lifetime metrics. Is that what you're talking about too? ksjp =20 What do you think? =20 Pascal =20 =20 ________________________________ =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CA52DF.4F730DB9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Kris:

 

Since I’m only = second hand on the buffered explanation I’ll defer to my sources J

Alex, I’d = really appreciate if you could give use more insight on the buffered data, in particular = WRT sensitivity to loss and jitter?

 

There’s not so = much data on the formulae that we use for Load-Based Call Admission Control but for = the patent we filed. You’ll find all that info by googling = “load-based CAC” but I cannot promise that what Cisco patented is exactly what made it in = the final product. I’m not sure that we published that level of information. = There is similar work on WCDMA.

 

The patented formulas = can be found at:

http://appft1.uspto.= gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D1&u=3D= %2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&c= o1=3DAND&d=3DPG01&s1=3D20080186846.PGNR.&OS=3DDN/20070198578&= amp;RS=3DDN/20080186846

 

I was involved in = LB-CAC when I implemented the CAC over our mesh product, in a recent life. The difference is that = the metrics must be aggregated over the mesh path, so it gets a bit more = complex and harder to prove. Until something changed in the mesh product since = we completed that project, Cisco does not to offer the option to do load = based CAC over multihop. Which is what I’m talking about here. =

 

Pascal

From: Kris Pister [mailto:pister@eecs.berkeley.edu]
Sent: mercredi 21 octobre 2009 20:18
To: Pascal Thubert (pthubert)
Cc: roll ROLL
Subject: Re: [Roll] load based parent selection and = CAC

 

Pascal - it would be unseemly for the two IA = requirements document editors to argue about IA requirement in public :)
so I'll just present these comments as an alternative = interpretation.

Pascal Thubert (pthubert) wrote:

Hi:

 

Here’s what I gathered from the industrial = space:

 

‘Buffered’ sensor data is captured at a = certain frequency (typically 4Hz) and placed in a buffer.

The buffer is then transmitted at a same or = different frequency than that of capture.

If the data capture frequency is higher than the = transmit frequency then the buffer is overwritten and some readings are just = lost.

I've never seen an application like this.  The vast majority of = applications sample (capture) and send immediately.  A small minority sample = repeatedly before sending, but none of them would just overwrite the existing = data.  That would show up as lost data in the network stats, and people would = get mad.

 

The buffered data might be lost on the way and = that’s usually OK, but some applications react very badly to = jitter.

I've never seen an application where lost data was ok, but jitter caused bad reactions.  Lost data is indistinguishable from long-jitter, = yes?.  Again, latency above some specified max counts as lost.

 

This strikes me as resembling quite a bit to voice = over radio. A technique called Load-Based Call Admission Control is used in = WCDMA and WIFI to compute whether there’s enough free space to take an additional call that will fit the codec characteristics. Basically = that’s a set of heuristics and a magical formula that uses the measure of the = energy in the channel and the transmit queue delays to compute whether = there’s enough free space in the air.

Can you elaborate on the heuristics and the magical formula?

 

Obviously, using such load estimate to do routing = would take us back to Arpanet and is a proven bad idea. But I thought that it could = be used:

By hosts to = select a router

By routers to = select a next_hop between its parents for a given packet (IOW a packet forwarding = time metric as opposed to a routing time metric).

If I have several 1-hop nodes (with links to an LBR), and a whole bunch of = other nodes further away routing through them, I'd really like to load balance = among the 1-hop nodes.  So I'd like to be able to make a decision on = which 5-hop parent to join based on the 1-hop energy/lifetime metrics.  Is that = what you're talking about too?

ksjp

 

What do you think?

 

Pascal

 

 





 
__________________________________=
_____________
Roll mailing =
list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
  =
------_=_NextPart_001_01CA52DF.4F730DB9-- From pthubert@cisco.com Thu Oct 22 03:11:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6863A67A1 for ; Thu, 22 Oct 2009 03:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.583 X-Spam-Level: X-Spam-Status: No, score=-9.583 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNpL94MKx7D5 for ; Thu, 22 Oct 2009 03:11:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D87CC3A684F for ; Thu, 22 Oct 2009 03:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=16213; q=dns/txt; s=amsiport01001; t=1256206294; x=1257415894; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20[Roll]=20load=20based=20parent=20 selection=20and=20CAC|Date:=20Thu,=2022=20Oct=202009=2012 :11:27=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2026AA 50A5D7A29E9@XMB-AMS-107.cisco.com>|To:=20"Maxence=20Dalma is"=20|Cc:=20"roll=20ROLL" =20|MIME-Version:=201.0|In-Reply-To:=20|References:=20<6A2A459175DABE4BB11DE2026AA50A5D740AD0@X MB-AMS-107.cisco.com>=20; bh=kKeDDLZzSgQQsFvZMnlX/gieQD7Av35pxM62zFf7MQo=; b=buaZ9q91SKqWbqCJaxC/xs4ggcVo+oPeMO/+4I5B5XV+TvdFUcVlacab CrgasTje1+oKgtpZQOi1LQqgTnvR4Ubg6k+I0JCkHa5+PzgjjMXHtGK+n blRYP/Rc7Q+VwEM+71csicR3HglRyoka3R/scuu/DS2fXIpxzcCNUnUYu I=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUAAJPM30qQ/uCWe2dsb2JhbACCJy2YVQEBFiQGpk6YWoQ/BA X-IronPort-AV: E=Sophos;i="4.44,604,1249257600"; d="scan'208,217";a="52464703" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2009 10:11:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9MABVfR015069; Thu, 22 Oct 2009 10:11:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:11:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5300.070E9BCF" Date: Thu, 22 Oct 2009 12:11:27 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D7A29E9@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] load based parent selection and CAC Thread-Index: AcpRrP6VBwTwRY02R22WVjUYhqdYAgBUHhMA References: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Maxence Dalmais" X-OriginalArrivalTime: 22 Oct 2009 10:11:32.0092 (UTC) FILETIME=[074AABC0:01CA5300] Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 10:11:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5300.070E9BCF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Maxence, =20 Basically we can see 2 sorts of information. Information that is (statistically?) aggregated over time and is stable enough to be used in the graph computation, and information that is volatile and depends on the dynamics of the network thus formed and can only be used at packet forwarding time. Those 2 sorts of information operate at different time scales. =20 It appears that is the energy cost for a rather stable topology could be used for routing, in the OCP logic. So if the OCP cares for energy, I expect that the path this formed will all be with acceptable boundaries. Like EIGRP selecting feasible successors for which the cost is less than a ratio over the most favorable path. =20 But if we leave it at that, it's very possible that all the sensor data will converge over a preferred path that will saturate and drop packets. What I'm talking about here is to influence the forwarding decision over the parents that are selected by the routing in order to distribute over paths of lesser use, but that are still acceptable. =20 IOW for your question, the routing selects a DAG that is acceptable energy-wise. And then the forwarding distributes the traffic over the multiple parents to control the congestion. You'll note that congestion is typically the type of information that you DO NOT want to use for routing. ARPANET proved that this creates a causality loop and from there instability. =20 If we care for only one hop, then as JP said, this has more to do with the L2 triggers than with the metrics carried in our messages. But that simplistic process will fail if the next hop is congested to death. This is why I introduced this discussion. =20 Pascal From: Maxence Dalmais [mailto:maxence.dalmais@insa-lyon.fr]=20 Sent: mardi 20 octobre 2009 19:43 To: Pascal Thubert (pthubert) Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC =20 Hi Pascal, On Tue, Oct 20, 2009 at 6:26 PM, Pascal Thubert (pthubert) wrote: Hi: =20 Here's what I gathered from the industrial space: =20 'Buffered' sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer. The buffer is then transmitted at a same or different frequency than that of capture.=20 If the data capture frequency is higher than the transmit frequency then the buffer is overwritten and some readings are just lost. =20 The buffered data might be lost on the way and that's usually OK, but some applications react very badly to jitter. =20 This strikes me as resembling quite a bit to voice over radio. A technique called Load-Based Call Admission Control is used in WCDMA and WIFI to compute whether there's enough free space to take an additional call that will fit the codec characteristics. Basically that's a set of heuristics and a magical formula that uses the measure of the energy in the channel and the transmit queue delays to compute whether there's enough free space in the air.=20 =20 Obviously, using such load estimate to do routing would take us back to Arpanet and is a proven bad idea. But I thought that it could be used: - By hosts to select a router - By routers to select a next_hop between its parents for a given packet (IOW a packet forwarding time metric as opposed to a routing time metric). Yes but how would you expect "host" to use that information to select the router ? It may very well be that the router offering the lower forwarding time end up following a high forwarding time path. [adapt from JP Vasseur in RPL Metric I-D ]. Maxence. =20 What do you think? =20 Hi Pascal, Yes but how would you expect "host" to use that information to select the router ? It may very well be that the router offering the lower energy cost end up following a high energy path.=20 Pascal =20 =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CA5300.070E9BCF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Maxence,

 

Basically we can see 2 sorts of information. Information = that is (statistically?) aggregated over time and is stable enough to be used in = the graph computation, and information that is volatile and depends on the = dynamics of the network thus formed and can only be used at packet forwarding = time. Those 2 sorts of information operate at different time = scales.

 

It appears that is the energy cost for a rather stable = topology could be used for routing, in the OCP logic. So if the OCP cares for = energy, I expect that the path this formed will all be with acceptable boundaries. = Like EIGRP selecting feasible successors for which the cost is less than a = ratio over the most favorable path.

 

But if we leave it at that, it’s very possible that = all the sensor data will converge over a preferred path that will saturate = and drop packets. What I’m talking about here is to influence the = forwarding decision over the parents that are selected by the routing in order to distribute over paths of lesser use, but that are still = acceptable.

 

IOW for your question, the routing selects a DAG that is acceptable energy-wise. And then the forwarding distributes the traffic = over the multiple parents to control the congestion. You’ll note that = congestion is typically the type of information that you DO NOT want to use for = routing. ARPANET proved that this creates a causality loop and from there = instability.

 

If we care for only one hop, then as JP said, this has = more to do with the L2 triggers than with the metrics carried in our messages. = But that simplistic process will fail if the next hop is congested to death. This = is why I introduced this discussion.

 

Pascal

From:= Maxence = Dalmais [mailto:maxence.dalmais@insa-lyon.fr]
Sent: mardi 20 octobre 2009 19:43
To: Pascal Thubert (pthubert)
Cc: roll ROLL
Subject: Re: [Roll] load based parent selection and = CAC

 

Hi = Pascal,

On Tue, Oct 20, 2009 at 6:26 PM, Pascal Thubert = (pthubert) <pthubert@cisco.com> = wrote:

Hi:

 <= /o:p>

Here’s= what I gathered from the industrial space:

 <= /o:p>

‘Buffe= red’ sensor data is captured at a certain frequency (typically 4Hz) and = placed in a buffer.

The buffer is then transmitted at a same or different frequency than that of capture.

If the data capture frequency is higher than the transmit frequency then = the buffer is overwritten and some readings are just lost.

 <= /o:p>

The buffered data might be lost on the way and that’s usually OK, but = some applications react very badly to jitter.

 <= /o:p>

This strikes me as resembling quite a bit to voice over radio. A technique = called Load-Based Call Admission Control is used in WCDMA and WIFI to compute = whether there’s enough free space to take an additional call that will fit = the codec characteristics. Basically that’s a set of heuristics and a = magical formula that uses the measure of the energy in the channel and the = transmit queue delays to compute whether there’s enough free space in the = air.

 <= /o:p>

Obviously, using such load estimate to do routing would take us back to Arpanet and = is a proven bad idea. But I thought that it could be used:

-        = ;  By hosts to select a router

-        = ;  By routers to select a next_hop between its parents for a given = packet (IOW a packet forwarding time metric as opposed to a routing time = metric).



Yes but how would you expect "host" to use that information to select the router ?
It may very well be that the router offering the lower forwarding time = end up following a high forwarding time path.  [adapt from JP Vasseur in = RPL Metric I-D ].

Maxence.

 <= /o:p>

What do you think?

 <= /o:p>

Hi Pascal,


Yes but how would you expect "host" to use that information to = select the router ?
It may very well be that the router offering the lower energy cost end = up following a high energy path.

Pascal<= /o:p>

 <= /o:p>


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

 

------_=_NextPart_001_01CA5300.070E9BCF-- From pister@eecs.berkeley.edu Thu Oct 22 08:33:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2026B3A6A8A for ; Thu, 22 Oct 2009 08:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEH+vvVtqTnl for ; Thu, 22 Oct 2009 08:33:07 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id CD2993A6A75 for ; Thu, 22 Oct 2009 08:33:07 -0700 (PDT) Received: from [10.10.40.28] (cust-67-203-88-62.static.o1.com [67.203.88.62]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id n9MFX308013291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 08:33:04 -0700 (PDT) Message-ID: <4AE07B2E.6040900@eecs.berkeley.edu> Date: Thu, 22 Oct 2009 08:33:02 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Chernoguzov, Alexander (PA35)" References: <6A2A459175DABE4BB11DE2026AA50A5D740AD0@XMB-AMS-107.cisco.com> <4ADF5042.4010203@eecs.berkeley.edu> <6A2A459175DABE4BB11DE2026AA50A5D7A2885@XMB-AMS-107.cisco.com> <254DAB3508951146AB1A064363F27E1C502D37@HK01EV802.global.ds.honeywell.com> In-Reply-To: <254DAB3508951146AB1A064363F27E1C502D37@HK01EV802.global.ds.honeywell.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL , "Brett, Patricia \(PA62\)" Subject: Re: [Roll] load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 15:33:09 -0000 Alex - well stated, thanks. The bottom line is that periodic measurements need to be carried with high reliability and low jitter. Anything other than that is a network failure, and some control systems have smart ways of dealing with that, and some don't. ksjp Chernoguzov, Alexander (PA35) wrote: > Pascal, > Your explanation of how buffered data transfer works is very good. I > particularly like the analogy to voice over radio (or over wired IP > for that matter). > Most process control systems are built around periodic sampling. > Control algorithms (e.g. PID) execute periodically on a fixed schedule > (e.g. once a second). They assume that fresh input data is available > right before control algorithm execution. > In a networked environment, control algorithm may run on a different > node than the one providing the input data. In that case, it is > assumed that inputs are published synchronously to the control > algorithm execution and phased in such a way that input value is > delivered to the control algorithm immediately before it executes. > It is evident from the above that high jitter is in fact very similar > to packet loss. If the input is delivered to the controller node after > it did the control algorithm execution, it is not going to be used > until next execution cycle, by which time a new input value is > normally available. It also explains the over-write policy. There is > no point trying to deliver old value when new one is available few > moments later. In this discrete sampling system, only the last value > matters. > Most control algorithms know how to deal with lost data. They either > use the last received value or approximate lost value based on recent > history of the measurement. In voice analogy this is equivalent to a > short blip in conversation. > Variable jitter is a significant adversary of good control. If phasing > of input publication is variable relative to the control execution, > you get the effect of executing control some times on old input value > and some times on new input value. This results in erratic control > behavior if control algorithm was tuned to the ideal input delivery. > It also explains why high jitter is different from complete packet > loss. Variable jitter in voice analogy results in distorted sound. > Alex > > ------------------------------------------------------------------------ > *From:* Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > *Sent:* Thursday, October 22, 2009 2:17 AM > *To:* Kris Pister; Chernoguzov, Alexander (PA35); Brett, Patricia (PA62) > *Cc:* roll ROLL > *Subject:* RE: [Roll] load based parent selection and CAC > > Hi Kris: > > Since I’m only second hand on the buffered explanation I’ll defer to > my sources J > > Alex, I’d really appreciate if you could give use more insight on the > buffered data, in particular WRT sensitivity to loss and jitter? > > There’s not so much data on the formulae that we use for Load-Based > Call Admission Control but for the patent we filed. You’ll find all > that info by googling “load-based CAC” but I cannot promise that what > Cisco patented is exactly what made it in the final product. I’m not > sure that we published that level of information. There is similar > work on WCDMA. > > The patented formulas can be found at: > > http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20080186846.PGNR.&OS=DN/20070198578&RS=DN/20080186846 > > > > I was involved in LB-CAC when I implemented the CAC over our mesh > product, in a recent life. The difference is that the metrics must be > aggregated over the mesh path, so it gets a bit more complex and > harder to prove. Until something changed in the mesh product since we > completed that project, Cisco does not to offer the option to do load > based CAC over multihop. Which is what I’m talking about here. > > Pascal > > *From:* Kris Pister [mailto:pister@eecs.berkeley.edu] > *Sent:* mercredi 21 octobre 2009 20:18 > *To:* Pascal Thubert (pthubert) > *Cc:* roll ROLL > *Subject:* Re: [Roll] load based parent selection and CAC > > Pascal - it would be unseemly for the two IA requirements document > editors to argue about IA requirement in public :) > so I'll just present these comments as an alternative interpretation. > > Pascal Thubert (pthubert) wrote: > > Hi: > > Here’s what I gathered from the industrial space: > > ‘Buffered’ sensor data is captured at a certain frequency (typically > 4Hz) and placed in a buffer. > > The buffer is then transmitted at a same or different frequency than > that of capture. > > If the data capture frequency is higher than the transmit frequency > then the buffer is overwritten and some readings are just lost. > > I've never seen an application like this. The vast majority of > applications sample (capture) and send immediately. A small minority > sample repeatedly before sending, but none of them would just > overwrite the existing data. That would show up as lost data in the > network stats, and people would get mad. > > The buffered data might be lost on the way and that’s usually OK, but > some applications react very badly to jitter. > > I've never seen an application where lost data was ok, but jitter > caused bad reactions. Lost data is indistinguishable from long-jitter, > yes?. Again, latency above some specified max counts as lost. > > This strikes me as resembling quite a bit to voice over radio. A > technique called Load-Based Call Admission Control is used in WCDMA > and WIFI to compute whether there’s enough free space to take an > additional call that will fit the codec characteristics. Basically > that’s a set of heuristics and a magical formula that uses the measure > of the energy in the channel and the transmit queue delays to compute > whether there’s enough free space in the air. > > Can you elaborate on the heuristics and the magical formula? > > Obviously, using such load estimate to do routing would take us back > to Arpanet and is a proven bad idea. But I thought that it could be used: > > By hosts to select a router > > By routers to select a next_hop between its parents for a given packet > (IOW a packet forwarding time metric as opposed to a routing time metric). > > If I have several 1-hop nodes (with links to an LBR), and a whole > bunch of other nodes further away routing through them, I'd really > like to load balance among the 1-hop nodes. So I'd like to be able to > make a decision on which 5-hop parent to join based on the 1-hop > energy/lifetime metrics. Is that what you're talking about too? > > ksjp > > What do you think? > > Pascal > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From alexandru.petrescu@gmail.com Thu Oct 22 09:04:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B843A680E for ; Thu, 22 Oct 2009 09:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IeXHomLzBaq for ; Thu, 22 Oct 2009 09:04:36 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 0005C3A67FB for ; Thu, 22 Oct 2009 09:04:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9MG4cgN017151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 18:04:38 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9MG4cpF020644; Thu, 22 Oct 2009 18:04:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9MG4cHR002530; Thu, 22 Oct 2009 18:04:38 +0200 Message-ID: <4AE08296.9040403@gmail.com> Date: Thu, 22 Oct 2009 18:04:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <840fa9b60910191347q51e67ah4c528580c3e7fffa@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 16:04:37 -0000 Philip Levis a écrit : > > On Oct 19, 2009, at 1:47 PM, Alexandru Petrescu wrote: > >>> There could be higher-power nodes with unlimited energy, who are >>> willing to forward. From a pure energy standpoint, they are >>> unattractive, but from a notion of how much this energy "costs" the >>> system they are attractive. >>> >>> For this reason, I think that your proposal on a 1280-byte packet >>> doesn't quite fit the bill. >> >> Which bill? > > I'm sorry -- it's a colloquialism. I meant "For this reason, I think > that your proposal on a 1280-byte packet isn't well suited to maximizing > network lifetime." Right... so the "bill" was to maximize the network lifetime. However, I do think the 1280byte energy expenditure metrics _is_ suited to maximize network lifetime. I think network lifetime is improved by whatever can reduce the energy spent to reach a destination, and energy metrics for links are for that. I am not sure whether I have already posted this example: ------- |Router2| /-------\ IPv6 Link1 \IPv6 Link3 ----- -------/ \------- ----- |Host1|---|Router1|-----------|Router3|---|Host2| ----- ------- IPv6 Link2 ------- ----- If the energy metrics of IPv6 Link1 and 3 indicate that path to consume less energy - then taking it into account rather than the hopcount metric (IPv6 Link2) surely contributes to extending the network lifetime. This is what happens when Link1 and 3 are bluetooth and Link2 is wifi. Even if one worries of sync'ed/notsync, or dormant/awake - the inherent energy consumption of these two techs is so different that decisions are easily made. I am not sure what you understand by network lifetime - is it more like node lifetime? > That doesn't mean it's not useful, or well suited to > other administrative concerns. It's just that "low power" is generally > -- but not always -- about maximizing network lifetime. What is a network to you? To me is a set of links (more than the set of nodes). E.g. I don't worry about how much energy a node spends to access its memory but I do worry how much a node spends to send a packet. Put another way: I don't worry if the set of nodes in a network consume all their batteries simply counting to infinity, but I do care if the network nodes run out of their batteries because they send out packets through energy-hungry paths. >>> Furthermore, the cost of sending a frame can be highly variable. >> >> That's why I propose a range of min-max. >> >>> E.g., if I am synchronized with the next hop then it might be cheap. >>> If I'm not, I'll need to do some kind of wakeup operation and it will >>> be expensive. >> >> I agree, but we could define the distinction to be accounted for, i.e. >> the values recorded consider only the cases when ends are in sync. >> >> If you talk about dormant modes - I think it's a huge topic touching on >> about everything ROLL does. Does RPL take this into account with its >> timers? > > I think this has come up on the list maybe a half-dozen times or so (or > more): this is a link layer operation. The time scales involved are not > in the same order of magnitude as ROLL timers. (Well of course depends how they are encoded. I know for timers in ND have been tweaked for Mobile IP to deal with orders of magnitude of link-layers.) My point was to say the "dormant/paging" aspects are often mentioned against about anything. No reason to take it into account here. >> YEs it does in a way, except you still don't propose an energy metric >> that you feel like you'd implement. YOu keep raising objections about >> my proposal. I could raise objections about your proposal once you >> make it. > > I know that the IETF is political at times, but I'd hope objections > would be raised on technical concerns, rather than authorship. I don't > care whose proposal we adopt: I just care that it works well, can be > implemented easily, and meets application/administrative requirements. YEs, right... Let's see later... Alex From richard.kelsey@ember.com Thu Oct 22 09:08:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19CC128C16C for ; Thu, 22 Oct 2009 09:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCCp-7uvpfR4 for ; Thu, 22 Oct 2009 09:07:59 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 033C728C16A for ; Thu, 22 Oct 2009 09:07:58 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 12:09:21 -0400 Date: Thu, 22 Oct 2009 12:05:56 -0400 Message-Id: <8763a78lcr.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Wed, 21 Oct 2009 18:41:47 -0700) From: Richard Kelsey References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 22 Oct 2009 16:09:21.0399 (UTC) FILETIME=[03FEF070:01CA5332] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 16:08:00 -0000 From: Philip Levis Date: Wed, 21 Oct 2009 18:41:47 -0700 But my concern is that we need to design a protocol for the hard case, not the easy one. Administrators can't always control the wireless environment: it would be a problem if RPL didn't work in Tutornet, Motelab, or Wyman-park like environments. Furthermore, RPL needs to be able to run over wider-band physical layers, or those with much more gradual SNR/PRR curves. I am not sure I understand your point. The question at hand is the design of a link reliability metric. Coping with, and making intelligent use of, noisy or otherwise unreliable links is what this is about. I'm very uncomfortable with the thread of logic hat RPL's topology needs to be very stable. I think all other things being equal, a stable topology is better than a dynamic one, and it's reasonable for implementations to try to improve stability. My worry starts, however, when we start *assuming* it is stable, and relegating highly dynamic networks to an oddity only worth cursory consideration. Doing so will lead to many failed deployments and general skepticism on the engineering and utility of RPL. Any protocol that stores routes for future use depends on some amount of stability. If the topology is sufficiently unstable the bandwidth needed to maintain routes will overwhelm the network. Leaving the application with not enough bandwidth is just as much a routing failure as not having a working route. With a very dynamic topology the emphasis has to be on quickly and efficiently finding some route, rather than spending resources on finding one of the better routes. I am skeptical that a single protocol will work well at both ends of the spectrum. In my experience a lack of bandwidth is a bigger problem for application on ROLL-style networks than a lack of reliable connectivity. Connectivity problems can be almost always be solved by installing more repeaters. If you are out of bandwidth, there is little you can do to fix that particular installation. Bounding the routing overhead at the cost of depending on a more stable topology is the right way to go. Using a purely reactive routing strategy has the effect of shifting some of the routing design to the higher layers. Given a fixed amount of total bandwidth, the amount available to the application will depend on the stability of the links. This isn't something that application designers should have to think about. Again, the solution is to bound the reactivity, which again requires depending on a some network stability. -Richard Kelsey From richard.kelsey@ember.com Thu Oct 22 10:22:28 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C703A6887 for ; Thu, 22 Oct 2009 10:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2dYL7pwPyRW for ; Thu, 22 Oct 2009 10:22:27 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id B42303A65A6 for ; Thu, 22 Oct 2009 10:22:27 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 13:23:50 -0400 Date: Thu, 22 Oct 2009 13:20:25 -0400 Message-Id: <874opr8hwm.fsf@kelsey-ws.hq.ember.com> To: Alexandru Petrescu In-reply-to: <4AE08296.9040403@gmail.com> (message from Alexandru Petrescu on Thu, 22 Oct 2009 18:04:38 +0200) From: Richard Kelsey References: <840fa9b60910191347q51e67ah4c528580c3e7fffa@mail.gmail.com> <4AE08296.9040403@gmail.com> X-OriginalArrivalTime: 22 Oct 2009 17:23:50.0401 (UTC) FILETIME=[6BBA8710:01CA533C] Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 17:22:28 -0000 Date: Thu, 22 Oct 2009 18:04:38 +0200 From: Alexandru Petrescu I think network lifetime is improved by whatever can reduce the energy spent to reach a destination, and energy metrics for links are for that. Maximizing the lifetime of a network has at least as much to do with energy supply as with energy use. Suppose there are two routes, one of which makes use of a battery-powered relay and the other of a line-powered relay, but are otherwise identical. It is quite likely that the battery-powered device, whose designer had minimal energy consumption as a high priority, uses less energy to send a message than the line-powered device. On the other hand, relaying via the battery-powered device shortens the life of the network, while using the line-powered device does not. -Richard Kelsey From alexandru.petrescu@gmail.com Thu Oct 22 11:16:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FCB3A699D for ; Thu, 22 Oct 2009 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf9RCpggJ2xZ for ; Thu, 22 Oct 2009 11:16:38 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 800D43A69A9 for ; Thu, 22 Oct 2009 11:16:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9MIGcvC022828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Oct 2009 20:16:38 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9MIGctV004848; Thu, 22 Oct 2009 20:16:38 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9MIGcgs000457; Thu, 22 Oct 2009 20:16:38 +0200 Message-ID: <4AE0A186.6010307@gmail.com> Date: Thu, 22 Oct 2009 20:16:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <840fa9b60910191347q51e67ah4c528580c3e7fffa@mail.gmail.com> <4AE08296.9040403@gmail.com> <874opr8hwm.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <874opr8hwm.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 22 Oct 2009 18:16:39 -0000 Richard Kelsey a écrit : > Date: Thu, 22 Oct 2009 18:04:38 +0200 > From: Alexandru Petrescu > > I think network lifetime is improved by whatever can reduce the energy > spent to reach a destination, and energy metrics for links are for that. > > Maximizing the lifetime of a network has at least as much to > do with energy supply as with energy use. > > Suppose there are two routes, one of which makes use of a > battery-powered relay and the other of a line-powered relay, > but are otherwise identical. It is quite likely that the > battery-powered device, whose designer had minimal energy > consumption as a high priority, uses less energy to send a > message than the line-powered device. On the other hand, > relaying via the battery-powered device shortens the life of > the network, while using the line-powered device does not. Sounds logical. Sounds as a potential contradiction between the paths computed according to link energy metrics vs node energy metrics. I.e. the case you describe may shorten the network lifetime if link energy metrics were used and, on the contrary, extend the network lifetime if _node_ energy metrics were used. You sure realize I could describe the reverse case where link-energy metrics were more advantageous for network lifetime. Maybe a good routing protocol may be able to make proper use of both. I personally tend to consider link energy metrics more, because there exist many other link-specific metrics (qos, latency) whereas there exist no CPU-specific metric for IP networking. (or am I missing something). Alex > > -Richard Kelsey > From pthubert@cisco.com Fri Oct 23 02:48:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8842B28C0D0 for ; Fri, 23 Oct 2009 02:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.468 X-Spam-Level: X-Spam-Status: No, score=-8.468 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVJyMwdwd26I for ; Fri, 23 Oct 2009 02:48:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3DA363A6767 for ; Fri, 23 Oct 2009 02:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=28707; q=dns/txt; s=amsiport01001; t=1256291300; x=1257500900; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20FW:=20[Roll]=20load=20based=20parent=20 selection=20and=20CAC|Date:=20Fri,=2023=20Oct=202009=2011 :48:13=20+0200|Message-ID:=20<6A2A459175DABE4BB11DE2026AA 50A5D7A3023@XMB-AMS-107.cisco.com>|To:=20"roll=20ROLL"=20 |MIME-Version:=201.0; bh=75hklnUhUqMu2x5dI35bnkZAzlvetNC8339uk5X0Egw=; b=WqYMOXtOe9vfKVjqgVicuuqZBYWD8ZF2L5MrDC6bdZvT2mNqk6XdYWAa 6dv/pu1PJSBhFPDLDFPLIFEpwHn7pvdTTzE7m3ICvFd4srCJkrAn6y2+v lpHsRKTpvW1ysyJg1mV1k020SZeWySFJpLRHXpkC0Z7Tb1H+C74GsC19i c=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8AAHMY4UqQ/uCWe2dsb2JhbACCJi2YWAEBFiQGpD6YN4Q/BIFd X-IronPort-AV: E=Sophos;i="4.44,611,1249257600"; d="scan'208,217";a="52591223" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2009 09:48:18 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9N9mIgA024264 for ; Fri, 23 Oct 2009 09:48:18 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 11:48:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA53C5.F2D6FFBF" Date: Fri, 23 Oct 2009 11:48:13 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D7A3023@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] load based parent selection and CAC Thread-Index: AcpSeuK5+u4wJkQ7RuyGL5L7Ie6r4gAYdDNQAA40bdAALBZtMA== From: "Pascal Thubert (pthubert)" To: "roll ROLL" X-OriginalArrivalTime: 23 Oct 2009 09:48:18.0218 (UTC) FILETIME=[F2E420A0:01CA53C5] Subject: [Roll] FW: load based parent selection and CAC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 09:48:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA53C5.F2D6FFBF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Seems Alex's mail did not make it to the list. =20 Pascal From: Chernoguzov, Alexander (PA35) [mailto:alexander.chernoguzov@honeywell.com]=20 Sent: jeudi 22 octobre 2009 16:08 To: Pascal Thubert (pthubert); Kris Pister; Brett, Patricia (PA62) Cc: roll ROLL Subject: RE: [Roll] load based parent selection and CAC =20 Pascal, =20 Your explanation of how buffered data transfer works is very good. I particularly like the analogy to voice over radio (or over wired IP for that matter).=20 =20 Most process control systems are built around periodic sampling. Control algorithms (e.g. PID) execute periodically on a fixed schedule (e.g. once a second). They assume that fresh input data is available right before control algorithm execution.=20 =20 In a networked environment, control algorithm may run on a different node than the one providing the input data. In that case, it is assumed that inputs are published synchronously to the control algorithm execution and phased in such a way that input value is delivered to the control algorithm immediately before it executes. =20 It is evident from the above that high jitter is in fact very similar to packet loss. If the input is delivered to the controller node after it did the control algorithm execution, it is not going to be used until next execution cycle, by which time a new input value is normally available. It also explains the over-write policy. There is no point trying to deliver old value when new one is available few moments later. In this discrete sampling system, only the last value matters. =20 Most control algorithms know how to deal with lost data. They either use the last received value or approximate lost value based on recent history of the measurement. In voice analogy this is equivalent to a short blip in conversation. =20 Variable jitter is a significant adversary of good control. If phasing of input publication is variable relative to the control execution, you get the effect of executing control some times on old input value and some times on new input value. This results in erratic control behavior if control algorithm was tuned to the ideal input delivery. It also explains why high jitter is different from complete packet loss. Variable jitter in voice analogy results in distorted sound. =20 Alex =20 ________________________________ From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, October 22, 2009 2:17 AM To: Kris Pister; Chernoguzov, Alexander (PA35); Brett, Patricia (PA62) Cc: roll ROLL Subject: RE: [Roll] load based parent selection and CAC Hi Kris: =20 Since I'm only second hand on the buffered explanation I'll defer to my sources J=20 Alex, I'd really appreciate if you could give use more insight on the buffered data, in particular WRT sensitivity to loss and jitter? =20 There's not so much data on the formulae that we use for Load-Based Call Admission Control but for the patent we filed. You'll find all that info by googling "load-based CAC" but I cannot promise that what Cisco patented is exactly what made it in the final product. I'm not sure that we published that level of information. There is similar work on WCDMA. =20 The patented formulas can be found at: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D= 1&u =3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&d=3D= PG01&s1=3D200 80186846.PGNR.&OS=3DDN/20070198578&RS=3DDN/20080186846=20 =20 I was involved in LB-CAC when I implemented the CAC over our mesh product, in a recent life. The difference is that the metrics must be aggregated over the mesh path, so it gets a bit more complex and harder to prove. Until something changed in the mesh product since we completed that project, Cisco does not to offer the option to do load based CAC over multihop. Which is what I'm talking about here.=20 =20 Pascal From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 Sent: mercredi 21 octobre 2009 20:18 To: Pascal Thubert (pthubert) Cc: roll ROLL Subject: Re: [Roll] load based parent selection and CAC =20 Pascal - it would be unseemly for the two IA requirements document editors to argue about IA requirement in public :) so I'll just present these comments as an alternative interpretation. Pascal Thubert (pthubert) wrote:=20 Hi: =20 Here's what I gathered from the industrial space: =20 'Buffered' sensor data is captured at a certain frequency (typically 4Hz) and placed in a buffer. The buffer is then transmitted at a same or different frequency than that of capture.=20 If the data capture frequency is higher than the transmit frequency then the buffer is overwritten and some readings are just lost. I've never seen an application like this. The vast majority of applications sample (capture) and send immediately. A small minority sample repeatedly before sending, but none of them would just overwrite the existing data. That would show up as lost data in the network stats, and people would get mad. =20 The buffered data might be lost on the way and that's usually OK, but some applications react very badly to jitter. I've never seen an application where lost data was ok, but jitter caused bad reactions. Lost data is indistinguishable from long-jitter, yes?. Again, latency above some specified max counts as lost. =20 This strikes me as resembling quite a bit to voice over radio. A technique called Load-Based Call Admission Control is used in WCDMA and WIFI to compute whether there's enough free space to take an additional call that will fit the codec characteristics. Basically that's a set of heuristics and a magical formula that uses the measure of the energy in the channel and the transmit queue delays to compute whether there's enough free space in the air. Can you elaborate on the heuristics and the magical formula? =20 Obviously, using such load estimate to do routing would take us back to Arpanet and is a proven bad idea. But I thought that it could be used: By hosts to select a router By routers to select a next_hop between its parents for a given packet (IOW a packet forwarding time metric as opposed to a routing time metric). If I have several 1-hop nodes (with links to an LBR), and a whole bunch of other nodes further away routing through them, I'd really like to load balance among the 1-hop nodes. So I'd like to be able to make a decision on which 5-hop parent to join based on the 1-hop energy/lifetime metrics. Is that what you're talking about too? ksjp =20 What do you think? =20 Pascal =20 =20 ________________________________ =20 =20 =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CA53C5.F2D6FFBF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Seems Alex’s = mail did not make it to the list.

 

Pascal

From: Chernoguzov, Alexander (PA35) = [mailto:alexander.chernoguzov@honeywell.com]
Sent: jeudi 22 octobre 2009 16:08
To: Pascal Thubert (pthubert); Kris Pister; Brett, Patricia = (PA62)
Cc: roll ROLL
Subject: RE: [Roll] load based parent selection and = CAC

 

Pascal,

 

Your explanation of how = buffered data transfer works is very good. I particularly like the analogy to = voice over radio (or over wired IP for that matter).

 

Most process control = systems are built around periodic sampling. Control algorithms (e.g. = PID) execute periodically on a fixed schedule (e.g. once a second). They assume that = fresh input data is available right before control algorithm execution. =

 

In a networked = environment, control algorithm may run on a different node than the one providing the = input data. In that case, it is assumed that inputs are published = synchronously to the control algorithm execution and phased in such a way that input = value is delivered to the control algorithm immediately before it = executes.

 

It is evident from the = above that high jitter is in fact very similar to packet loss. If the input is delivered to the controller node after it did the control algorithm = execution, it is not going to be used until next execution cycle, by which time a = new input value is normally available. It also explains the = over-write policy. There is no point trying to deliver old value when new one is = available few moments later. In this discrete sampling system, only the last value matters.

 

Most control algorithms = know how to deal with lost data. They either use the last received value or = approximate lost value based on recent history of the measurement. In voice analogy = this is equivalent to a short blip in conversation.

 

Variable jitter is a = significant adversary of good control. If phasing of input publication is variable = relative to the control execution, you get the effect of executing control some = times on old input value and some times on new input value. This results in = erratic control behavior if control algorithm was tuned to the ideal input = delivery. It also explains why high jitter is different from complete packet loss. = Variable jitter in voice analogy results in distorted sound.

 

Alex

 

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: Thursday, October 22, 2009 2:17 AM
To: Kris Pister; Chernoguzov, Alexander (PA35); Brett, Patricia = (PA62)
Cc: roll ROLL
Subject: RE: [Roll] load based parent selection and = CAC

Hi Kris:

 

Since I’m only second hand on the buffered explanation I’ll defer = to my sources J

Alex, I’d really appreciate if you could give use more insight on the = buffered data, in particular WRT sensitivity to loss and = jitter?

 

There’s not so much data on the formulae that we use for Load-Based Call = Admission Control but for the patent we filed. You’ll find all that info by googling “load-based CAC” but I cannot promise that what = Cisco patented is exactly what made it in the final product. I’m not = sure that we published that level of information. There is similar work on = WCDMA.

 

The patented formulas can be found at:

http://appft1.uspto.= gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D1&u=3D= %2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&c= o1=3DAND&d=3DPG01&s1=3D20080186846.PGNR.&OS=3DDN/20070198578&= amp;RS=3DDN/20080186846

 

I was involved in LB-CAC when I implemented the CAC over our mesh product, in = a recent life. The difference is that the metrics must be aggregated over = the mesh path, so it gets a bit more complex and harder to prove. Until = something changed in the mesh product since we completed that project, Cisco does = not to offer the option to do load based CAC over multihop. Which is what I’m = talking about here.

 

Pascal

From: Kris Pister [mailto:pister@eecs.berkeley.edu]
Sent: mercredi 21 octobre 2009 20:18
To: Pascal Thubert (pthubert)
Cc: roll ROLL
Subject: Re: [Roll] load based parent selection and = CAC

 

Pascal - it would be = unseemly for the two IA requirements document editors to argue about IA requirement = in public :)
so I'll just present these comments as an alternative = interpretation.

Pascal Thubert (pthubert) wrote:

Hi:

 

Here’s what I = gathered from the industrial space:

 

‘Buffered’ = sensor data is captured at a certain frequency (typically 4Hz) and placed in a = buffer.

The buffer is then = transmitted at a same or different frequency than that of capture.

If the data capture = frequency is higher than the transmit frequency then the buffer is overwritten and = some readings are just lost.

I've never seen an application like this.  The vast majority of = applications sample (capture) and send immediately.  A small minority sample = repeatedly before sending, but none of them would just overwrite the existing = data.  That would show up as lost data in the network stats, and people would = get mad.

 

The buffered data = might be lost on the way and that’s usually OK, but some applications react very = badly to jitter.

I've never seen an application where lost data was ok, but jitter caused bad reactions.  Lost data is indistinguishable from long-jitter, = yes?.  Again, latency above some specified max counts as = lost.

 

This strikes me as = resembling quite a bit to voice over radio. A technique called Load-Based Call = Admission Control is used in WCDMA and WIFI to compute whether there’s = enough free space to take an additional call that will fit the codec = characteristics. Basically that’s a set of heuristics and a magical formula that uses the = measure of the energy in the channel and the transmit queue delays to compute = whether there’s enough free space in the air.

Can you elaborate on the heuristics and the magical = formula?

 

Obviously, using such = load estimate to do routing would take us back to Arpanet and is a proven bad = idea. But I thought that it could be used:

By hosts to select a router

By routers to select a next_hop between its parents for a given packet (IOW = a packet forwarding time metric as opposed to a routing time = metric).

If I have several 1-hop nodes (with links to an LBR), and a whole bunch of = other nodes further away routing through them, I'd really like to load balance = among the 1-hop nodes.  So I'd like to be able to make a decision on = which 5-hop parent to join based on the 1-hop energy/lifetime metrics.  Is that = what you're talking about too?

ksjp

 

What do you = think?

 

Pascal

 

 





 
  
____________________________________________=
___
Roll mailing list
Roll@ietf.org
https://www.ietf.org/=
mailman/listinfo/roll
 
------_=_NextPart_001_01CA53C5.F2D6FFBF-- From maxence.dalmais@insa-lyon.fr Mon Oct 12 08:00:40 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A163A67AB for ; Mon, 12 Oct 2009 08:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+IMPYrLlfFi for ; Mon, 12 Oct 2009 08:00:40 -0700 (PDT) Received: from smtp.insa-lyon.fr (criges14.insa-lyon.fr [134.214.76.242]) by core3.amsl.com (Postfix) with ESMTP id D09FC3A69B5 for ; Mon, 12 Oct 2009 08:00:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 81EFEF12EB for ; Mon, 12 Oct 2009 17:00:39 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU3njERZ96Uo for ; Mon, 12 Oct 2009 17:00:39 +0200 (CEST) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: mdalmais1) by smtp.insa-lyon.fr (Postfix) with ESMTPSA id 5250FF12D5 for ; Mon, 12 Oct 2009 17:00:39 +0200 (CEST) Received: by bwz6 with SMTP id 6so3165991bwz.37 for ; Mon, 12 Oct 2009 08:00:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.145.135 with SMTP id s7mr421520hba.143.1255359634108; Mon, 12 Oct 2009 08:00:34 -0700 (PDT) In-Reply-To: References: <4ACF754C.2000604@gmail.com> <2F8F6405-4B87-4A62-9040-717A5D956B42@cisco.com> <4AD30B6B.3030802@gmail.com> <1D93951F-F2CF-46C4-B14A-2FD251D0E715@cisco.com> <4AD32D6F.7090406@gmail.com> <1B65245C-1BC6-4ECB-9CE9-77784668DC8B@cisco.com> From: Maxence Dalmais Date: Mon, 12 Oct 2009 17:00:14 +0200 Message-ID: To: JP Vasseur Content-Type: multipart/alternative; boundary=001485f6d00e0e722d0475be3125 X-Mailman-Approved-At: Fri, 23 Oct 2009 08:12:11 -0700 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 12 Oct 2009 15:00:41 -0000 --001485f6d00e0e722d0475be3125 Content-Type: text/plain; charset=ISO-8859-1 Hi JP, The fact is that sending a high energy cost packet won't be a problem for a >> mains powered node, but it will induce noise and impact the links of the >> entire network. >> > > That is a second order effect though and not true for PLC link. It is bit > of a stretch to choose a low energy path, because of a high energy path may > cause increase noise along that path thus leading to more errors ... don't > you think ? > > Personnaly I don't think. Using high energy path will include more errors to others transmissions, ie increase retransmissions, ie increase the ETX metric. This may involve modifications in the chosen path. Maybe we could think that we don't need to take energy path into account the because ETX will automatically adapt to this. But having a highly dynamic ETX may cause others trouble, don't you think ? Maybe, energy path has to be taken in count in RPL to avoid the need of a very dynamic ETX and retransmissions. I think that when designing a new specialized protocol, we shouldn't be affraid of developing new idea. Does anyone have experience with such an altruistic routing protocol ? Cheers, Maxence. --001485f6d00e0e722d0475be3125 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi JP,


The fact is that sending a high energy cost packet won't be a problem f= or a mains powered node, but it will induce noise and impact the links of t= he entire network.

That is a second order effect though and not true for PLC link. It is bit o= f a stretch to choose a low energy path, because of a high energy path may = cause increase noise along that path thus leading to more errors ... don= 9;t you think ?


Personnaly I don't think.

Using = high energy path will include more errors to others transmissions, ie incre= ase retransmissions, ie increase the ETX metric. This may involve modificat= ions in the chosen path.
Maybe we could think that we don't need to take energy path into accoun= t the=A0 because ETX will automatically adapt to this.
But having a high= ly dynamic ETX may cause others trouble, don't you think=A0 ?
Maybe,= energy path has to be taken in count in RPL to avoid the need of a very dy= namic ETX and retransmissions.

I think that when designing a new specialized protocol, we shouldn'= t be affraid of developing new idea.
=A0=A0=A0
Does anyone have expe= rience with such an altruistic routing protocol ?

Cheers,

Ma= xence.
--001485f6d00e0e722d0475be3125-- From rfc-editor@rfc-editor.org Wed Oct 21 08:34:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62A863A6935; Wed, 21 Oct 2009 08:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.114 X-Spam-Level: X-Spam-Status: No, score=-17.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atfzh+tq9Js2; Wed, 21 Oct 2009 08:34:35 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 6ECC03A680D; Wed, 21 Oct 2009 08:34:35 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 7FDF434E790; Wed, 21 Oct 2009 08:32:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091021153211.7FDF434E790@bosco.isi.edu> Date: Wed, 21 Oct 2009 08:32:11 -0700 (PDT) X-Mailman-Approved-At: Fri, 23 Oct 2009 08:12:38 -0700 Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 5673 on Industrial Routing Requirements in Low-Power and Lossy Networks X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 21 Oct 2009 15:34:36 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5673 Title: Industrial Routing Requirements in Low-Power and Lossy Networks Author: K. Pister, Ed., P. Thubert, Ed., S. Dwars, T. Phinney Status: Informational Date: October 2009 Mailbox: kpister@dustnetworks.com, pthubert@cisco.com, sicco.dwars@shell.com, tom.phinney@cox.net Pages: 27 Characters: 67934 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-indus-routing-reqs-06.txt URL: http://www.rfc-editor.org/rfc/rfc5673.txt The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices. This memo provides information for the Internet community. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From thomas@thomasclausen.org Thu Oct 15 01:47:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1753A67C1 for ; Thu, 15 Oct 2009 01:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Sruz8bm71ns for ; Thu, 15 Oct 2009 01:47:32 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id B2EF43A67A8 for ; Thu, 15 Oct 2009 01:47:32 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[192.168.133.2]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1MyLzj-0001r2-3o; Thu, 15 Oct 2009 08:47:35 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+7k6SzmSIpnqs6PZg4XwrB Message-Id: <4B9C1EB1-65AF-424D-AD1E-D80957B8D8C7@thomasclausen.org> From: Thomas Heide Clausen To: "Mathilde Durvy (mdurvy)" In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE7AAB29@XMB-AMS-103.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-263861460 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Oct 2009 10:47:31 +0200 References: <8A977BDC5A7B0E429B0F521E8D6F91EE7AAB29@XMB-AMS-103.cisco.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 23 Oct 2009 08:13:09 -0700 Cc: ROLL WG Subject: Re: [Roll] feedback on draft-ietf-roll-rpl-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 15 Oct 2009 08:47:33 -0000 --Apple-Mail-1-263861460 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit My 2 cents... On Oct 15, 2009, at 10:44 AM, Mathilde Durvy (mdurvy) wrote: > Hi Emmanuel, > > I very much agree with your comments. Especially with the two points > below that could reduce a lot the complexity. > > # Section 2 > I am wondering if some of the terms are unecessary at this point. In > particular, DAG siblings. Since siblings introduce quite a tricky > complexity/benefit trade-off, I would be in favor of getting rid of > these in the core RPL document. This could be a welcomed > simplification. > Agree, for me siblings are note part of the core. +1 > > # Section 3.2.1: > "RPL constructs one or more DAGs". The consensus is that the core > RPL document should specify how to build a single DAG to reach a > single destination. This may be used to simplify the document a bit. > Agree. I think what is needed are just procedures to join a DAG and > leave a DAG. > +1 Thomas > Best, > Mathilde > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-1-263861460 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable My 2 = cents...

On Oct 15, 2009, at 10:44 AM, Mathilde Durvy = (mdurvy) wrote:

Hi Emmanuel,
 
I very much agree with your comments. = Especially with the two points below that could reduce a lot the = complexity.

# Section 2
=
I am wondering if some of the terms are unecessary at this point. = In particular, DAG siblings. Since siblings introduce quite a tricky = complexity/benefit trade-off, I would be in  favor of getting rid = of these in the core RPL document. This could be a welcomed = simplification.
Agree, for me siblings are = note part of the core.
=

+1

 
 # Section 3.2.1: 
=
"RPL constructs one or more DAGs". The consensus is that the core = RPL document should specify how to build a single DAG to reach a single = destination. This may be used to simplify the document a bit. 
Agree. I think what is needed are just procedures = to join a DAG and leave a = DAG.  


+1

Thomas

Best,
=
Mathilde 
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-1-263861460-- From william.polk@NIST.GOV Wed Oct 14 06:46:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7C428C104; Wed, 14 Oct 2009 06:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHSSR+evYx4m; Wed, 14 Oct 2009 06:46:00 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 9B4493A691B; Wed, 14 Oct 2009 06:45:59 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n9EDjIDE021943; Wed, 14 Oct 2009 09:45:18 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Wed, 14 Oct 2009 09:45:18 -0400 From: "Polk, William T." To: Fred Baker , David R Oran , Richard Shockey , Russ Housley , Leslie Daigle , Sean Turner , Paul Hoffman , Henning Schulzrinne , Phil Roberts , "peter@peter-dambier.de" , "dcrocker@bbiw.net" , Hiroshi Esaki , Michael Dillon , Brian E Carpenter , Ralph Droms , Michael Dillon , IESG IESG , IAB IAB , "recipe@ietf.org" , Peny Yang , "roll@ietf.org" Date: Wed, 14 Oct 2009 09:45:09 -0400 Thread-Topic: Smart Grid Bar BOF on Wednesday night at IETF 76 (Was: Doodle poll: Smart Grid Bar Bof at IETF 76) Thread-Index: AcpLpuV4ql1sjkWx30upn1dIGdyKowBLaX+k Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6FB4E2517275timpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov X-Mailman-Approved-At: Fri, 23 Oct 2009 08:13:37 -0700 Cc: "St. Pierre, James A." , "Dodson, Donna F." , "Su, David H." , "Golmie, Nada T." Subject: [Roll] Smart Grid Bar BOF on Wednesday night at IETF 76 (Was: Doodle poll: Smart Grid Bar Bof at IETF 76) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 14 Oct 2009 13:46:00 -0000 --_000_C6FB4E2517275timpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Bar BOF to discuss US Smart Grid effort will be held Wednesday night. = I was really excited to see the level of interest, and everyone that has re= sponded to date can attend on Wednesday night. Since the better date was c= lear, I wanted to announce the result ASAP rather than ask folks to hold tw= o dates on their personal schedules any longer. I will revise the poll so that only Wednesday night is an option, but would= greatly appreciate it if people would continue to register interest so I c= an reserve an appropriate room. I intend to follow up with logistics the w= eek before IETF. Thanks, Tim Polk On 10/12/09 9:45 PM, "Polk, Tim" wrote: Folks, I would like to organize a BAR BOF at IETF 76 in Hiroshima to discuss the U= S Smart Grid effort. IETF protocols will be an important component of a su= ccessful and evolutionary Smart Grid, and NIST is looking to the IETF for l= eadership. To enable participation by NIST/ITL Management, I would like to = hold the BAR BOF either Wednesday or Thursday night. NIST attendees will provide some background/history of the Smart Grid effor= ts but the primary goal of this session is to determine whether there is su= fficient interest in the community to take on work in this area. If there i= s interest, scoping of appropriate IETF contributions, and strategies for o= rganizing the response would also be fruitful topic areas. I am sending this email directly to any IETFers that have (to my knowledge)= previously indicated interest in Smart Grid. I am also sending this messa= ge to the IESG, IAB, recipe@ietf.org, and ipaction@nist.gov email lists. P= lease feel free to forward this email to anyone else that you think I may h= ave missed. If you are interested in attending the BOF, please indicate your preference= using the following doodle poll: http://www.doodle.com/q5nusbhpqfnf75yh Thanks, Tim Polk --_000_C6FB4E2517275timpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Smart Grid Bar BOF on Wednesday night at IETF 76 (Was: Doodle poll: = Smart Grid Bar Bof at IETF 76) The Bar BOF to discuss US Smart Grid effort will be held Wednesday ni= ght.  I was really excited to see the level of interest, and everyone = that has responded to date can attend on Wednesday night.  Since the b= etter date was clear, I wanted to announce the result ASAP rather than ask = folks to hold two dates on their personal schedules any longer.

I will revise the poll so that only Wednesday night is an option, but would= greatly appreciate it if people would continue to register interest so I c= an reserve an appropriate room.  I intend to follow up with logistics = the week before IETF.

Thanks,

Tim Polk


On 10/12/09 9:45 PM, "Polk, Tim" <tim.polk@nist.gov> wrote:


Folks,

I would like to organize a BAR BOF = at IETF 76 in Hiroshima to discuss the US Smart Grid effort.  IETF pro= tocols will be an important component of a successful and evolutionary Smar= t Grid, and NIST is looking to the IETF for leadership. To enable participa= tion by NIST/ITL Management, I would like to hold the BAR BOF either Wednes= day or Thursday night.

NIST attendees will provide some background/history of the Smart Grid effor= ts but the primary goal of this session is to determine whether there is su= fficient interest in the community to take on work in this area. If there i= s interest, scoping of appropriate IETF contributions, and strategies for o= rganizing the response would also be fruitful topic areas.

I am sending this email directly to= any IETFers that have (to my knowledge) previously indicated interest in S= mart Grid.  I am also sending this message to the IESG, IAB, recipe@ietf.org, and ipaction@nist.gov email lists.  Please feel free to forward this = email to anyone else that you think I may have missed.

If you are interested in attending the BOF, please indicate your preference= using the following doodle poll:

      h= ttp://www.doodle.com/q5nusbhpqfnf75yh
=
Thanks,

Tim Polk
--_000_C6FB4E2517275timpolknistgov_-- From prvs=54099d791=mukul@uwm.edu Fri Oct 23 09:23:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2AE3A68A6 for ; Fri, 23 Oct 2009 09:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNiXSLvo4aYb for ; Fri, 23 Oct 2009 09:23:52 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 0879F3A6858 for ; Fri, 23 Oct 2009 09:23:51 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 23 Oct 2009 11:24:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4E791C085DA; Fri, 23 Oct 2009 11:24:02 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnArHUEfgLKl; Fri, 23 Oct 2009 11:24:02 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 207A5C085D5; Fri, 23 Oct 2009 11:24:02 -0500 (CDT) Date: Fri, 23 Oct 2009 11:24:02 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1019652622.21495031256314353645.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 16:24:38 -0000 Hi Pascal and Tim I had a doubt about PathDigest. Sec 5.3.4.2 of rpl-3 draft says that when "The node receives a modified RA-DIO message from a DAG parent", its trickle timer is reset. Does it mean that the trickle timer is reset if a parent RIO shows modified PathDigest? Now, a modified PathDigest from the parent means that the parent's parent set changed. I was wondering why should it be an inconsistency for me. If information in this RIO does not force me to change my rank/parent_set/routing_metrics, I need not reset my trickle timer. Now, parent's changed PathDigest may be used to trigger NA-DAOs to this parent (as the draft already mentions). But I am not sure why should it cause resetting of trickle timer governing RA-DIOs. Thanks Mukul From anders.jagd@ekasystems.com Fri Oct 23 09:51:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E583D3A6883 for ; Fri, 23 Oct 2009 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcUSi1qragZj for ; Fri, 23 Oct 2009 09:51:06 -0700 (PDT) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by core3.amsl.com (Postfix) with SMTP id E495E3A67E6 for ; Fri, 23 Oct 2009 09:51:05 -0700 (PDT) Received: (qmail 37098 invoked from network); 23 Oct 2009 16:51:15 -0000 Received: from unknown (HELO PavilionLaptop) (anders.jagd@68.110.232.114 with login) by smtp103.biz.mail.re2.yahoo.com with SMTP; 23 Oct 2009 16:51:14 -0000 X-Yahoo-SMTP: Z9nti1.swBBshEkcTT58JGsSW0GG0Kgu_9V27Bc_1Irb1gnWTbAo X-YMail-OSG: 7WvzVr0VM1nPTCKXZOORCzbfHJfMuQz_RbIwuhlQAZ31xPzOyi9NPhzAwaeya2nJev.Ec7hjiBEOo8hNZMUEO2drlnXZvweqCNQTsUJK8qwDHLMlcWtsRTm4E0xqPEhVTiAFtNw3n0UyQMOlRPGz1exYOL7_rU1Qw04Ewr7c6QeZuBcCjocL4kuj3d30EaQMigUF8QU21Is9DmNmfTvgASQptGY7ApW4LYQG9ZzAr5Ay.4NYE2hk1yUJgW42_xbDAW4HBfxJTAtm18CeRhhELCe0TF2nroc2oun2t1aOq7p6FcqmkXAkpPCXTkrACATxMUfuafB5tZvd_ENhCuf0v8UTFTxiq1ZG4g-- X-Yahoo-Newman-Property: ymail-3 From: "Anders Jagd" To: "'Mukul Goyal'" , "'Pascal Thubert \(pthubert\)'" References: <1019652622.21495031256314353645.JavaMail.root@mail02.pantherlink.uwm.edu> <1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Fri, 23 Oct 2009 12:51:12 -0400 Organization: Eka Systems Message-ID: <000101ca5401$07ec7d40$17c577c0$@jagd@ekasystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpT/Vt55A3Atw9jTbK5kugA9ld6EAAAk+Zw Content-Language: en-us Cc: 'roll' Subject: Re: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 16:51:07 -0000 Also, PathDigest seems a bit expensive. I have previously suggested "D" bit might suffice, but Tim correctly replied that the message with "D" bit set could be lost, whilst a change in PathDigest would eventually be observed. Let me therefore modify my suggestion as follows: Remove PathDigest, but replace "D" bit with say D[3:0]. A change would be signaled by incrementing the current value of D[3:0]. D[3:0] would be local to each node, so basically a node would check for changes in parent node D[3:0] setting, and, when so detected, increase its own D[3:0] value - signaling this new value (indicating request for update of NAs) downstream. /Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: Friday, October 23, 2009 12:24 PM To: Pascal Thubert (pthubert) Cc: roll Subject: [Roll] PathDigest question Hi Pascal and Tim I had a doubt about PathDigest. Sec 5.3.4.2 of rpl-3 draft says that when "The node receives a modified RA-DIO message from a DAG parent", its trickle timer is reset. Does it mean that the trickle timer is reset if a parent RIO shows modified PathDigest? Now, a modified PathDigest from the parent means that the parent's parent set changed. I was wondering why should it be an inconsistency for me. If information in this RIO does not force me to change my rank/parent_set/routing_metrics, I need not reset my trickle timer. Now, parent's changed PathDigest may be used to trigger NA-DAOs to this parent (as the draft already mentions). But I am not sure why should it cause resetting of trickle timer governing RA-DIOs. Thanks Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From wintert@acm.org Fri Oct 23 10:33:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B771D3A68AD for ; Fri, 23 Oct 2009 10:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.432 X-Spam-Level: X-Spam-Status: No, score=-100.432 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVwaSI6dgup9 for ; Fri, 23 Oct 2009 10:33:21 -0700 (PDT) Received: from smtp105.prem.mail.sp1.yahoo.com (smtp105.prem.mail.sp1.yahoo.com [98.136.44.60]) by core3.amsl.com (Postfix) with SMTP id 8AB843A67FA for ; Fri, 23 Oct 2009 10:33:21 -0700 (PDT) Received: (qmail 77357 invoked from network); 23 Oct 2009 17:33:30 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp105.prem.mail.sp1.yahoo.com with SMTP; 23 Oct 2009 10:33:30 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: Dj1SazgVM1kJsuSTegUOqv9k2SRfrpcg2ovVrNEDuZ_JlybbxuEVMX6jabCaRl3vyfyVUHdgt0X279XMvdEGPaG3d87zd4wygDwIhpnF4UyUZGdbVM_Olh9oItRwe6BnEqCIrXG06rWkQetml2VXJ2_WNI7EFp4O5uEcpTg.IDnoqmxR4PDrs_5g.4HCfQthvOioDY8hzYI2ChTunciW2v0eEaqbPPEZ1lObUiLIpSeGfPNdv4Abui2YMxSKY14wQlSwgeailJEWqWbHHhY_UVceqe3_O_hWlgNqCpYj1XyBxYf.XZgg2PCmfC7QkJesMI2ophsmotQHOBgR4w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE1E8E3.5000900@acm.org> Date: Fri, 23 Oct 2009 13:33:23 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <4AD3F102.8010601@acm.org> In-Reply-To: <4AD3F102.8010601@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 17:33:22 -0000 WG, We are working towards the -04 revision, and in consideration of WG feedback on these questions have also taken into account the following: - The WG has given a clear mandate to reduce complexity - Many of these features are related to optimizations, but do not appear strictly required to operate the core protocol The mandate to reduce complexity is very clear, the feedback on the list in support of these features is less so. Therefore we do propose to take the following approach proceeding into -04: - Recommendations for DAG Splitting and Merging (Detach/Form transient floating DAG/Reattach) will be removed (loss of connectivity/sub-DAG poisoning may effectively occur by advertising rank of infinity) - Hold-Up Timer and related states/procedures will be removed - Hold-Down Timer and related states/procedures will be removed It is the objective that by removing these protocol features we are able to let the basic mechanisms of the core protocol be clear without additional complexity. We do not wish to introduce complexity by including perceived optimizations, but also realize that as the WG effort proceeds we may find it necessary to reintroduce some part of these features in some form. But for now they do not seem strictly necessary, and it is the hope that by keeping them back the WG may focus more on the core protocol. Please let us know your comments/feedback- what do you think? Thanks, -RPL Authors Tim Winter wrote: > WG, > > Please do let us know what you are thinking w/ regard to the design > Questions A, B, & C below. We hope to include your feedback into the next > revision of the document, with FSM descriptions as well. > > Thanks, > > - RPL Authors > > > > As discussed at the interim meeting, implementer feedback has > indicated that the RPL protocol as proposed appears complex, both in > description and actual FSM. > > Our plan of action is to, by end of month, deliver a -04 that will > contain actual (non-editorial) changes. The intent of this mail is > a poll over a period of 2 weeks, to help design the functional > changes. > > In this spirit, we would like the WG to work on the following > questions: > > Question A: Should RPL make use of the currently proposed local > repair mechanism (DAG splitting and merging)? > > [NO implies that DAG repairs shall be coordinated globally with > the use of DAG Sequence Number; the related mechanisms are to > be expanded for -04] > > Question B: Should RPL make use of a hold-up timer and related > states/procedures to reduce churn by coordinating the DAG merge? > > [NO implies RPL allows nodes to move (jump) between DAGs with > little coordination to reduce complexity of specification/ > implementation (perhaps w/ Optional hold-up mechanism)]. > > Question C: Should RPL make use of a hold-down timer and related > states/procedures to limit flapping when removing DAG Parents / > leaving DAGs > > [NO implies RPL allows nodes to freely remove/add DAG Parents > as and when they are able in order to reduce complexity of > specification/implementation (perhaps w/ Optional hold-down > mechanism). > > WG, we expect that this thread will contain a lot of interesting > related discussion, but in your comments please do also be sure to > try and address the initial questions A, B, and C so as to help us > better capture the WG position on these issues. Please note that A, > B, and C are to some degree orthogonal, e.g. `No Local Repair' to > Question A does not necessarily imply a particular disposition toward > the Hold-Up mechanism in Question B. > > Thanks, > > RPL Authors > > > > Some examples, derived from the present draft, are provided below: > > ------------------------------------------------------------------------ > > Example: Local Repair with Hold-Up state > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | | \ > | | `-----. > | | \ > (D) (D) (C) > | > | > | > (D) > > -1- -2- -3- > > > Figure 1: DAG Maintenance > > Consider the example depicted in Figure 1-1. In this example, Node > (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of > Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is > also an undirected sibling link between Nodes (B) and (C). > > In this example, Node (C) may safely forward to Node (A) without > creating a loop. Node (C) may not safely forward to Node (D), > contained within it's own sub-DAG, without creating a loop. Node (C) > may forward to Node (B) in some cases, e.g. the link (C)->(A) is > temporarily unavailable, but with some chance of creating a loop > (e.g. if multiple nodes in a set of siblings start forwarding > `sideways' in a cycle) and requiring the intervention of additional > mechanisms to detect and break the loop. > > Consider the case where Node (C) hears a RA-DIO message from a Node > (Z) at a lesser rank and superior position in the DAG than node (A). > Node (C) may safely undergo the process to evict node (A) from its > DAG parent set and attach directly to Node (Z) without creating a > loop, because its rank will decrease. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. Node (C) > becomes the root of its own floating, less preferred, DAG. > > o Node (D), hearing a modified RA-DIO message from Node (C), follows > Node (C) into the floating DAG. This is depicted in Figure 1-2. > In general, any node with no other options in the sub-DAG of Node > (C) will follow Node (C) into the floating DAG, maintaining the > structure of the sub-DAG. > > o Node (C) hears a RA-DIO message from Node (B) and determines it is > able to rejoin the grounded DAG by reattaching at a deeper rank to > Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in > the Hold-Up state) to coordinate this move. > > o The timer expires and Node (C) adds Node (B) to its DAG parent > set. Node (C) has now safely moved deeper within the grounded DAG > without creating any loops. Node (D), and any other sub-DAG of > Node (C), will hear the modified RA-DIO message sourced from Node > (C) and follow Node (C) in a coordinated manner to reattach to the > grounded DAG. The final DAG is depicted in Figure 1-3 > > > ------------------------------------------------------------------------ > > Example: Global Repair with Sequence Number / No Held-Up State > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | \ > | `-----. > | \ > (D) (D) (C) > > > > (D) > > -1- -2- -3- > > > Figure 2: DAG Maintenance > > Consider the example depicted in Figure 2-1, similar to that depicted > in Figure 1. Let there be a sequence number associated with the DAG, > as originated from the DAG root, with value N. Initially all nodes > have received DAG Sequence Number N. The following example offers one > possible Global Repair scenario to give a high level idea, please > note that there are details that would remain to be worked out if the > WG heads in this direction. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. At this > point Node (C) is not associated with any DAG [TBD -- Alternately > Node (C) remains associated with the DAG at rank infinity]. > > o Node (D) may possibly learn that Node (C) is no longer associated > with any DAG and itself becomes unassociated [TBD Node (D) may > also retain a sub-DAG relationship with Node (C)]. Let Node (C) > and (D) both be free from any DAG, but remember the Sequence > Number N associated with their original DAG. This is depicted in > Figure 2-2. > > o Node (C) and (D) will now be willing to reattach to the original > DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering > connectivity to the original DAG and advertising a sequence number > N+1. Since Node (C) and (D) are no longer members of the original > DAG, only a node who is still a member of the original DAG may > possibly present the sequence number N+1. Such a node who > presents N+1 must clearly have another path to the DAG root other > than via (C) and (D) and thus may offer a loop-avoiding attachment > point. > > o [TBD] The DAG Root may periodically issue sequence number > increments, causing the issue of N+1 > > o [TBD] The broken link (C)->(A) may be detected through some other > means, and signalled to or cause a trigger at the DAG Root, > causing the issue of N+1 > > o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and > determine it is able to rejoin the original DAG by immediately > reattaching j to Node (B) (No hold-up state in this example. The > DAG is now as depicted in Figure 2-3 > > o Node (C) may then subsequently send RA-DIO with DAG Sequence > number N+1, allowing Node (D) to reattach (not depicted). > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 wintert@acm.org Fri Oct 23 10:38:34 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14453A6927 for ; Fri, 23 Oct 2009 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.216 X-Spam-Level: X-Spam-Status: No, score=-102.216 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCAQJBbbkaIo for ; Fri, 23 Oct 2009 10:38:33 -0700 (PDT) Received: from smtp105.prem.mail.ac4.yahoo.com (smtp105.prem.mail.ac4.yahoo.com [76.13.13.44]) by core3.amsl.com (Postfix) with SMTP id AB7C23A68AD for ; Fri, 23 Oct 2009 10:38:33 -0700 (PDT) Received: (qmail 73351 invoked from network); 23 Oct 2009 17:38:36 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp105.prem.mail.ac4.yahoo.com with SMTP; 23 Oct 2009 10:38:36 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: yB02OZcVM1k_sLbY5aLW0C5_cRaSfljHQf8GheqBASwh7roiQrJPTBcSqq0S3CsopN3EdaW1sYUaraNB245JGn6yVRhP3IBdHyzIjb7ROkhE96bIlacKQsm_DbqKF5CSAmQqLXbeeuzkWvgcJFJ30dE65DIxYFfA.wJV_AisRldDqC1W3D5Kgpqz1fxnDIF0S8Wayea3lcnfYjf0ndajCoSdxSk0NtF8tPZsJoCSw2S1mVyBy4DbZzYD7bd7syE30DeeZedFt8fuwLBBK5Hk.Q9vZpyjhH4pMctoMtOoR12GAAHrjXE.xQbaA_GGvL_jcqtNclYVoHnf0g4l48dp4SyKYXHP.VBME3DMCGtOpElfKdWt5aM5O4MXpkRLDqz7DF.E0q7FPbDOsc_xyqAQFw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE1EA19.2050406@acm.org> Date: Fri, 23 Oct 2009 13:38:33 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ROLL WG References: <4AD75A9F.6070803@acm.org> In-Reply-To: <4AD75A9F.6070803@acm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 17:38:34 -0000 WG, Based on feedback to the list we will proceed to decouple the DIO/DAO messages from the IPv6 ND transport (RA-DIO -> DIO, NA-DAO -> DAO), and request the allocation of a new ICMP message to transport the DIO/DAO. The decoupling in the text will also make it easier for other use cases, e.g. 6LowPAN, to specify their own bindings when appropriate. Any further comments/feedback? Thanks, -RPL Authors Tim Winter wrote: > WG, > > There has been some feedback regarding the implications of using Neighbor > Discovery RA/NA to carry DIO/DAO for RPL. The functionality provided by > DIO/DAO may be seen as a natural extension to ND, but there are concerns > regarding the implications of overloading ND for use by RPL. Another option > would be to request the allocation of ICMP messages to transport the DIO/DAO. > > What do you think? > 1) Let RPL use RA/NA for DIO/DAO transport > 2) Allocate 2 new ICMP messages for DIO/DAO and operate independent of ND > > Please do keep in mind that this would serve as a base recommendation for > the core protocol, and does not necessarily preclude that another > implementation-specific binding outside of the scope of RPL (e.g. 6LowPAN) > may do things differently. > > > Thanks, > > -RPL Authors > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Fri Oct 23 11:09:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA493A6963 for ; Fri, 23 Oct 2009 11:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.613 X-Spam-Level: X-Spam-Status: No, score=-9.613 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWEIjxIsEnTR for ; Fri, 23 Oct 2009 11:08:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 239E33A67FA for ; Fri, 23 Oct 2009 11:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2436; q=dns/txt; s=amsiport01001; t=1256321350; x=1257530950; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Pascal=20Thubert=20(pthubert)"=20|Subject:=20RE:=20PathDigest=20question|Date:=20Fri ,=2023=20Oct=202009=2020:09:01=20+0200|Message-ID:=20<6A2 A459175DABE4BB11DE2026AA50A5D7A3344@XMB-AMS-107.cisco.com >|To:=20"Mukul=20Goyal"=20|Cc:=20"roll"=20 |MIME-Version:=201.0 |Content-Transfer-Encoding:=20base64|In-Reply-To:=20<1041 893305.21501211256315042042.JavaMail.root@mail02.pantherl ink.uwm.edu>|References:=20<1019652622.214950312563143536 45.JavaMail.root@mail02.pantherlink.uwm.edu>=20<104189330 5.21501211256315042042.JavaMail.root@mail02.pantherlink.u wm.edu>; bh=cBdXIcBMzWL9cVXbn7A1Gd6QaNim66Y2GIzlkgEsGV4=; b=FJHMWvhSCX5DQK4Xojoto1gMVUB8lGBY/V5zgOxpyt5wbKfiqcEabRck Bg3H9vVkB5TGe32kQ52ou5yjcJvGl7tFZkl22FAbSZmOiTA/X60dFRDJ2 2fCIgsgIv1HGDB2nykBeTPiDEpd2xyaKbwHD2eDNGjj5bDG2j/qODU9fz c=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0AAKON4UqQ/uCWe2dsb2JhbACEcpUFgTYBARYkBqVQhxGRIoEygjpTBIsf X-IronPort-AV: E=Sophos;i="4.44,613,1249257600"; d="scan'208";a="52641507" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2009 18:09:08 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9NI98KD016371; Fri, 23 Oct 2009 18:09:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 20:09:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 23 Oct 2009 20:09:01 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D7A3344@XMB-AMS-107.cisco.com> In-Reply-To: <1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PathDigest question Thread-Index: AcpT/UAuw+/gax1AQC6o+nDxJdqiqQADOWsw References: <1019652622.21495031256314353645.JavaMail.root@mail02.pantherlink.uwm.edu> <1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" X-OriginalArrivalTime: 23 Oct 2009 18:09:08.0491 (UTC) FILETIME=[EA3FE5B0:01CA540B] Cc: roll Subject: Re: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 18:09:00 -0000 SGkgTXVrdWw6DQoNCkEgcGF0aCBkaWdlc3QgdGVsbHMgdGhhdCBzb21ldGhpbmcgaGFzIGNoYW5n ZWQgaW4gdGhlIGlud2FyZHMgcGF0aCBvZiB0aGlzIG5vZGUgYW5kIHN1Z2dlc3QgdGhhdCBEQU9z IHNob3VsZCBiZSBzZW50Lg0KVGhpcyBpcyBtb3N0bHkgdXNlZnVsIGZvciBzb3VyY2Ugcm91dGUu IEZvciBzdGF0ZWZ1bCwgYWxsIHlvdSBuZWVkIHRvIGtub3cgaXMgdGhhdCB5b3VyIHBhcmVudHMg Y2hhbmdlLg0KQWxzbywgdGhpcyBpcyBtb3N0bHkgbWVhbmluZ2Z1bCBpZiB0aGUgREFPcyBkbyBu b3QgZmFuIG91dCBzaW5jZSB0aGlzIGlzIHRoZSBkaWdlc3Qgb2YgdGhlIHByZWZlcnJlZCBwYXRo LiANCg0KSSB0aGluayB0aGUgY3VycmVudCBkcmFmdCBzdWdnZXN0cyB0byBzZW5kIERBT3Mgb3Zl ciBvbmUgcGFyZW50IChhcyBvcHBvc2VkIHRvIGZhbiBvdXQpIGJ1dCBkb2VzIG5vdCBpbXBvc2Ug YW55dGhpbmcgb24gd2hpY2ggdGhhdCBwYXJlbnQgaXMgKHByZWZlcnJlZCBvciBub3QpLiANCg0K V1JUIHRyaWNrbGUsIGlmIHRoZXJlJ3Mgbm8gc291cmNlIHJvdXRlLCBJIGFncmVlIHdpdGggeW91 IGFuZCBJIGRvIG5vdCBzZWUgd2h5IHRoYXQgd291bGQgcmVxdWlyZSB0byBkbyBhbnl0aGluZy4N CklmIHRoZXJlJ3Mgc291cmNlIHJvdXRlLCB0aGVuIHRoZSBleHBvbmVudGlhbCBiYWNrb2ZmIG9m IFJBcyBtaWdodCBoZWxwIGVuc3VyZSB0aGF0IGFsbCB0aGUgY2hpbGRyZW4gcmVjb25zdHJ1Y3Qg dGhlaXIgcGF0aCBmYXN0ZXIuDQoNCldoYXQgZG8geW91IHRoaW5rPyANCg0KUGFzY2FsDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3Vs QHV3bS5lZHVdDQo+U2VudDogdmVuZHJlZGkgMjMgb2N0b2JyZSAyMDA5IDE4OjI0DQo+VG86IFBh c2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj5DYzogcm9sbA0KPlN1YmplY3Q6IFBhdGhEaWdlc3Qg cXVlc3Rpb24NCj4NCj5IaSBQYXNjYWwgYW5kIFRpbQ0KPg0KPkkgaGFkIGEgZG91YnQgYWJvdXQg UGF0aERpZ2VzdC4NCj4NCj5TZWMgNS4zLjQuMiBvZiBycGwtMyBkcmFmdCBzYXlzIHRoYXQgd2hl biAiVGhlIG5vZGUgcmVjZWl2ZXMgYSBtb2RpZmllZCBSQS1ESU8gbWVzc2FnZSBmcm9tIGEgREFH IHBhcmVudCIsIGl0cw0KPnRyaWNrbGUgdGltZXIgaXMgcmVzZXQuDQo+DQo+RG9lcyBpdCBtZWFu IHRoYXQgdGhlIHRyaWNrbGUgdGltZXIgaXMgcmVzZXQgaWYgYSBwYXJlbnQgUklPIHNob3dzIG1v ZGlmaWVkIFBhdGhEaWdlc3Q/DQo+DQo+Tm93LCBhIG1vZGlmaWVkIFBhdGhEaWdlc3QgZnJvbSB0 aGUgcGFyZW50IG1lYW5zIHRoYXQgdGhlIHBhcmVudCdzIHBhcmVudCBzZXQgY2hhbmdlZC4gSSB3 YXMgd29uZGVyaW5nIHdoeQ0KPnNob3VsZCBpdCBiZSBhbiBpbmNvbnNpc3RlbmN5IGZvciBtZS4g SWYgaW5mb3JtYXRpb24gaW4gdGhpcyBSSU8gZG9lcyBub3QgZm9yY2UgbWUgdG8gY2hhbmdlIG15 DQo+cmFuay9wYXJlbnRfc2V0L3JvdXRpbmdfbWV0cmljcywgSSBuZWVkIG5vdCByZXNldCBteSB0 cmlja2xlIHRpbWVyLg0KPg0KPk5vdywgcGFyZW50J3MgY2hhbmdlZCBQYXRoRGlnZXN0IG1heSBi ZSB1c2VkIHRvIHRyaWdnZXIgTkEtREFPcyB0byB0aGlzIHBhcmVudCAoYXMgdGhlIGRyYWZ0IGFs cmVhZHkNCj5tZW50aW9ucykuIEJ1dCBJIGFtIG5vdCBzdXJlIHdoeSBzaG91bGQgaXQgY2F1c2Ug cmVzZXR0aW5nIG9mIHRyaWNrbGUgdGltZXIgZ292ZXJuaW5nIFJBLURJT3MuDQo+DQo+VGhhbmtz DQo+TXVrdWwNCg== From alexandru.petrescu@gmail.com Fri Oct 23 11:19:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C08E3A6891 for ; Fri, 23 Oct 2009 11:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRReyj48K5qM for ; Fri, 23 Oct 2009 11:19:37 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id CB9373A6878 for ; Fri, 23 Oct 2009 11:19:36 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9NIJgH8004716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Oct 2009 20:19:42 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9NIJgA6017424; Fri, 23 Oct 2009 20:19:42 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9NIJffs019854; Fri, 23 Oct 2009 20:19:42 +0200 Message-ID: <4AE1F3BD.5030606@gmail.com> Date: Fri, 23 Oct 2009 20:19:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tim Winter References: <4AD75A9F.6070803@acm.org> <4AE1EA19.2050406@acm.org> In-Reply-To: <4AE1EA19.2050406@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 18:19:38 -0000 Tim Winter a écrit : > WG, > > Based on feedback to the list we will proceed to decouple the DIO/DAO > messages from the IPv6 ND transport (RA-DIO -> DIO, NA-DAO -> DAO), > and request the allocation of a new ICMP message to transport the > DIO/DAO. Tim, do you mean new ICMP message Types? Or code fields? Or both? The current ICMP types and codes are: http://www.iana.org/assignments/icmpv6-parameters "IPv6 ND transport" is actually ICMP because ND is nothing else than an ICMP message type. In this sense, you propose to decouple something from ICMP but still use ICMP(?) The ICMP message Types have often a Request-Response semantics (NS-NA, Echo Req-Echo Rep, HAADReq-HAADRep, etc.). The DIO and DAO are not so - they seem to be DAG Information Option and Destination Advertisement Option - simply information. Or maybe you plan to design new ICMP Types RPL-Request and RPL-Reply that each may carry both a DIO and a DAO? (I am purely speculating here). > The decoupling in the text will also make it easier for other use > cases, e.g. 6LowPAN, to specify their own bindings when appropriate. Errr... but 6LoWPAN does a special "6LoWPAN ND" which is extensions to RS-RA and NS-NA, and they also request two new ICMP message types Node-Reg/Conf (which I suppose would be different than RPL's). What do you mean by making it easier for 6LoWPAN to specify their own bindings? Bindings of what? (6LoWPAN "binding" is also a relationship between two addresses in the router). How about a unique RPL6LoWPAN Req/Response ICMP Type new pair? Alex > > Any further comments/feedback? > > Thanks, > > -RPL Authors > > > > Tim Winter wrote: >> WG, >> >> There has been some feedback regarding the implications of using >> Neighbor Discovery RA/NA to carry DIO/DAO for RPL. The >> functionality provided by DIO/DAO may be seen as a natural >> extension to ND, but there are concerns regarding the implications >> of overloading ND for use by RPL. Another option would be to >> request the allocation of ICMP messages to transport the DIO/DAO. >> >> What do you think? 1) Let RPL use RA/NA for DIO/DAO transport 2) >> Allocate 2 new ICMP messages for DIO/DAO and operate independent of >> ND >> >> Please do keep in mind that this would serve as a base >> recommendation for the core protocol, and does not necessarily >> preclude that another implementation-specific binding outside of >> the scope of RPL (e.g. 6LowPAN) may do things differently. >> >> >> Thanks, >> >> -RPL Authors _______________________________________________ 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 pthubert@cisco.com Fri Oct 23 11:29:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E295F3A697D for ; Fri, 23 Oct 2009 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.645 X-Spam-Level: X-Spam-Status: No, score=-7.645 tagged_above=-999 required=5 tests=[AWL=-1.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA6tiweF4MEt for ; Fri, 23 Oct 2009 11:29:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0240F3A6970 for ; Fri, 23 Oct 2009 11:29:09 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFOS4UqrR7Hu/2dsb2JhbADBMZg0hD8Eix8 X-IronPort-AV: E=Sophos;i="4.44,613,1249257600"; d="scan'208";a="217464532" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 23 Oct 2009 18:29:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9NITKFH028211; Fri, 23 Oct 2009 18:29:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 20:29:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Oct 2009 20:28:44 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D7A3347@XMB-AMS-107.cisco.com> In-Reply-To: <000101ca5401$07ec7d40$17c577c0$@jagd@ekasystems.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] PathDigest question Thread-Index: AcpT/Vt55A3Atw9jTbK5kugA9ld6EAAAk+ZwAANQwgA= References: <1019652622.21495031256314353645.JavaMail.root@mail02.pantherlink.uwm.edu> <1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> <000101ca5401$07ec7d40$17c577c0$@jagd@ekasystems.com> From: "Pascal Thubert (pthubert)" To: "Anders Jagd" , "Mukul Goyal" X-OriginalArrivalTime: 23 Oct 2009 18:29:19.0937 (UTC) FILETIME=[BC53E310:01CA540E] Cc: roll Subject: Re: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 23 Oct 2009 18:29:11 -0000 Hi Anders, This works fine. Likewise, Mathilde opened the discussion on the size of the prefix. I trust we'll need a general pass on compression though at some point it might be like 6LoWPAN a local optimization for a given sort of link.=20 I know that it's critical for implementations and Interop to discuss the formats early though the formats are only relevant as long as we know what we do with them. OTOH, we see more discussions on the formats than on the base mechanisms, and we end up making decisions, like the removal of the Dag Hop Timer and the DAG split / merge just announced, with almost no vote on the list. That concerns me. Cheers, Pascal >-----Original Message----- >From: Anders Jagd [mailto:anders.jagd@ekasystems.com] >Sent: vendredi 23 octobre 2009 18:51 >To: 'Mukul Goyal'; Pascal Thubert (pthubert) >Cc: 'roll' >Subject: RE: [Roll] PathDigest question > >Also, PathDigest seems a bit expensive. I have previously suggested "D" bit >might suffice, but Tim correctly replied that the message with "D" bit set >could be lost, whilst a change in PathDigest would eventually be observed. > >Let me therefore modify my suggestion as follows: Remove PathDigest, but >replace "D" bit with say D[3:0]. A change would be signaled by incrementing >the current value of D[3:0]. D[3:0] would be local to each node, so >basically a node would check for changes in parent node D[3:0] setting, and, >when so detected, increase its own D[3:0] value - signaling this new value >(indicating request for update of NAs) downstream. > >/Anders > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Mukul Goyal >Sent: Friday, October 23, 2009 12:24 PM >To: Pascal Thubert (pthubert) >Cc: roll >Subject: [Roll] PathDigest question > >Hi Pascal and Tim > >I had a doubt about PathDigest. > >Sec 5.3.4.2 of rpl-3 draft says that when "The node receives a modified >RA-DIO message from a DAG parent", its trickle timer is reset. > >Does it mean that the trickle timer is reset if a parent RIO shows modified >PathDigest? > >Now, a modified PathDigest from the parent means that the parent's parent >set changed. I was wondering why should it be an inconsistency for me. If >information in this RIO does not force me to change my >rank/parent_set/routing_metrics, I need not reset my trickle timer. > >Now, parent's changed PathDigest may be used to trigger NA-DAOs to this >parent (as the draft already mentions). But I am not sure why should it >cause resetting of trickle timer governing RA-DIOs. > >Thanks >Mukul >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From prvs=5416b228f=mukul@uwm.edu Fri Oct 23 19:56:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFB43A6811 for ; Fri, 23 Oct 2009 19:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtT2oMDKxr8a for ; Fri, 23 Oct 2009 19:56:38 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id 91E1F3A67A7 for ; Fri, 23 Oct 2009 19:56:38 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 23 Oct 2009 21:56:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4EE40C085C8; Fri, 23 Oct 2009 21:56:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv7YyHCpMAEi; Fri, 23 Oct 2009 21:56:49 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 20CFDC085A0; Fri, 23 Oct 2009 21:56:49 -0500 (CDT) Date: Fri, 23 Oct 2009 21:56:49 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1533378189.21709051256353009053.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <406954042.21708411256352623231.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 24 Oct 2009 02:56:56 -0000 Hi Pascal Thanks for the clarification. So, resetting the trickle timer (for DIO) makes sense when the parent(s) to whom DAOs are being forwarded advertize modified PathDigest and source routes are being used. In view of this clarification, I was wondering if we should modify the way PathDigest is calculated: Rather than calculating CRC-32 checksum on the PathDigest of most preferred parent concatenated with parent IDs, perhaps checksum should be calculated on the string formed by concatenating PathDigest(s) of the parent(s) to whom DAOs are forwarded and all the parent IDs. This will ensure that if any parent to whom I am forwarding DAOs changes PathDigest, my own PathDigest would change. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: "roll" Sent: Friday, October 23, 2009 1:09:01 PM GMT -06:00 US/Canada Central Subject: RE: PathDigest question Hi Mukul: A path digest tells that something has changed in the inwards path of this node and suggest that DAOs should be sent. This is mostly useful for source route. For stateful, all you need to know is that your parents change. Also, this is mostly meaningful if the DAOs do not fan out since this is the digest of the preferred path. I think the current draft suggests to send DAOs over one parent (as opposed to fan out) but does not impose anything on which that parent is (preferred or not). WRT trickle, if there's no source route, I agree with you and I do not see why that would require to do anything. If there's source route, then the exponential backoff of RAs might help ensure that all the children reconstruct their path faster. What do you think? Pascal >-----Original Message----- >From: Mukul Goyal [mailto:mukul@uwm.edu] >Sent: vendredi 23 octobre 2009 18:24 >To: Pascal Thubert (pthubert) >Cc: roll >Subject: PathDigest question > >Hi Pascal and Tim > >I had a doubt about PathDigest. > >Sec 5.3.4.2 of rpl-3 draft says that when "The node receives a modified RA-DIO message from a DAG parent", its >trickle timer is reset. > >Does it mean that the trickle timer is reset if a parent RIO shows modified PathDigest? > >Now, a modified PathDigest from the parent means that the parent's parent set changed. I was wondering why >should it be an inconsistency for me. If information in this RIO does not force me to change my >rank/parent_set/routing_metrics, I need not reset my trickle timer. > >Now, parent's changed PathDigest may be used to trigger NA-DAOs to this parent (as the draft already >mentions). But I am not sure why should it cause resetting of trickle timer governing RA-DIOs. > >Thanks >Mukul From prvs=5416b228f=mukul@uwm.edu Fri Oct 23 20:05:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB773A6851 for ; Fri, 23 Oct 2009 20:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.975 X-Spam-Level: X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDOA755qxvSc for ; Fri, 23 Oct 2009 20:05:44 -0700 (PDT) Received: from ip1mta2.uwm.edu (ip1mta2.uwm.edu [129.89.7.130]) by core3.amsl.com (Postfix) with ESMTP id BD0193A6811 for ; Fri, 23 Oct 2009 20:05:43 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip1mta2.uwm.edu with ESMTP; 23 Oct 2009 22:05:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id B2CE1C085C8; Fri, 23 Oct 2009 22:05:54 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AquoRQThzvJ; Fri, 23 Oct 2009 22:05:54 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 32E62C085A0; Fri, 23 Oct 2009 22:05:54 -0500 (CDT) Date: Fri, 23 Oct 2009 22:05:54 -0500 (CDT) From: Mukul Goyal To: Tim Winter Message-ID: <1280723487.21709961256353554171.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <4AE1E8E3.5000900@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 24 Oct 2009 03:05:45 -0000 Tim I think this is a wise approach. I support these changes to the core protocol. Regards Mukul ----- Original Message ----- From: "Tim Winter" To: "ROLL WG" Sent: Friday, October 23, 2009 12:33:23 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] RPL Design Questions WG, We are working towards the -04 revision, and in consideration of WG feedback on these questions have also taken into account the following: - The WG has given a clear mandate to reduce complexity - Many of these features are related to optimizations, but do not appear strictly required to operate the core protocol The mandate to reduce complexity is very clear, the feedback on the list in support of these features is less so. Therefore we do propose to take the following approach proceeding into -04: - Recommendations for DAG Splitting and Merging (Detach/Form transient floating DAG/Reattach) will be removed (loss of connectivity/sub-DAG poisoning may effectively occur by advertising rank of infinity) - Hold-Up Timer and related states/procedures will be removed - Hold-Down Timer and related states/procedures will be removed It is the objective that by removing these protocol features we are able to let the basic mechanisms of the core protocol be clear without additional complexity. We do not wish to introduce complexity by including perceived optimizations, but also realize that as the WG effort proceeds we may find it necessary to reintroduce some part of these features in some form. But for now they do not seem strictly necessary, and it is the hope that by keeping them back the WG may focus more on the core protocol. Please let us know your comments/feedback- what do you think? Thanks, -RPL Authors Tim Winter wrote: > WG, > > Please do let us know what you are thinking w/ regard to the design > Questions A, B, & C below. We hope to include your feedback into the next > revision of the document, with FSM descriptions as well. > > Thanks, > > - RPL Authors > > > > As discussed at the interim meeting, implementer feedback has > indicated that the RPL protocol as proposed appears complex, both in > description and actual FSM. > > Our plan of action is to, by end of month, deliver a -04 that will > contain actual (non-editorial) changes. The intent of this mail is > a poll over a period of 2 weeks, to help design the functional > changes. > > In this spirit, we would like the WG to work on the following > questions: > > Question A: Should RPL make use of the currently proposed local > repair mechanism (DAG splitting and merging)? > > [NO implies that DAG repairs shall be coordinated globally with > the use of DAG Sequence Number; the related mechanisms are to > be expanded for -04] > > Question B: Should RPL make use of a hold-up timer and related > states/procedures to reduce churn by coordinating the DAG merge? > > [NO implies RPL allows nodes to move (jump) between DAGs with > little coordination to reduce complexity of specification/ > implementation (perhaps w/ Optional hold-up mechanism)]. > > Question C: Should RPL make use of a hold-down timer and related > states/procedures to limit flapping when removing DAG Parents / > leaving DAGs > > [NO implies RPL allows nodes to freely remove/add DAG Parents > as and when they are able in order to reduce complexity of > specification/implementation (perhaps w/ Optional hold-down > mechanism). > > WG, we expect that this thread will contain a lot of interesting > related discussion, but in your comments please do also be sure to > try and address the initial questions A, B, and C so as to help us > better capture the WG position on these issues. Please note that A, > B, and C are to some degree orthogonal, e.g. `No Local Repair' to > Question A does not necessarily imply a particular disposition toward > the Hold-Up mechanism in Question B. > > Thanks, > > RPL Authors > > > > Some examples, derived from the present draft, are provided below: > > ------------------------------------------------------------------------ > > Example: Local Repair with Hold-Up state > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | | \ > | | `-----. > | | \ > (D) (D) (C) > | > | > | > (D) > > -1- -2- -3- > > > Figure 1: DAG Maintenance > > Consider the example depicted in Figure 1-1. In this example, Node > (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of > Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is > also an undirected sibling link between Nodes (B) and (C). > > In this example, Node (C) may safely forward to Node (A) without > creating a loop. Node (C) may not safely forward to Node (D), > contained within it's own sub-DAG, without creating a loop. Node (C) > may forward to Node (B) in some cases, e.g. the link (C)->(A) is > temporarily unavailable, but with some chance of creating a loop > (e.g. if multiple nodes in a set of siblings start forwarding > `sideways' in a cycle) and requiring the intervention of additional > mechanisms to detect and break the loop. > > Consider the case where Node (C) hears a RA-DIO message from a Node > (Z) at a lesser rank and superior position in the DAG than node (A). > Node (C) may safely undergo the process to evict node (A) from its > DAG parent set and attach directly to Node (Z) without creating a > loop, because its rank will decrease. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. Node (C) > becomes the root of its own floating, less preferred, DAG. > > o Node (D), hearing a modified RA-DIO message from Node (C), follows > Node (C) into the floating DAG. This is depicted in Figure 1-2. > In general, any node with no other options in the sub-DAG of Node > (C) will follow Node (C) into the floating DAG, maintaining the > structure of the sub-DAG. > > o Node (C) hears a RA-DIO message from Node (B) and determines it is > able to rejoin the grounded DAG by reattaching at a deeper rank to > Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in > the Hold-Up state) to coordinate this move. > > o The timer expires and Node (C) adds Node (B) to its DAG parent > set. Node (C) has now safely moved deeper within the grounded DAG > without creating any loops. Node (D), and any other sub-DAG of > Node (C), will hear the modified RA-DIO message sourced from Node > (C) and follow Node (C) in a coordinated manner to reattach to the > grounded DAG. The final DAG is depicted in Figure 1-3 > > > ------------------------------------------------------------------------ > > Example: Global Repair with Sequence Number / No Held-Up State > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | \ > | `-----. > | \ > (D) (D) (C) > > > > (D) > > -1- -2- -3- > > > Figure 2: DAG Maintenance > > Consider the example depicted in Figure 2-1, similar to that depicted > in Figure 1. Let there be a sequence number associated with the DAG, > as originated from the DAG root, with value N. Initially all nodes > have received DAG Sequence Number N. The following example offers one > possible Global Repair scenario to give a high level idea, please > note that there are details that would remain to be worked out if the > WG heads in this direction. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. At this > point Node (C) is not associated with any DAG [TBD -- Alternately > Node (C) remains associated with the DAG at rank infinity]. > > o Node (D) may possibly learn that Node (C) is no longer associated > with any DAG and itself becomes unassociated [TBD Node (D) may > also retain a sub-DAG relationship with Node (C)]. Let Node (C) > and (D) both be free from any DAG, but remember the Sequence > Number N associated with their original DAG. This is depicted in > Figure 2-2. > > o Node (C) and (D) will now be willing to reattach to the original > DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering > connectivity to the original DAG and advertising a sequence number > N+1. Since Node (C) and (D) are no longer members of the original > DAG, only a node who is still a member of the original DAG may > possibly present the sequence number N+1. Such a node who > presents N+1 must clearly have another path to the DAG root other > than via (C) and (D) and thus may offer a loop-avoiding attachment > point. > > o [TBD] The DAG Root may periodically issue sequence number > increments, causing the issue of N+1 > > o [TBD] The broken link (C)->(A) may be detected through some other > means, and signalled to or cause a trigger at the DAG Root, > causing the issue of N+1 > > o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and > determine it is able to rejoin the original DAG by immediately > reattaching j to Node (B) (No hold-up state in this example. The > DAG is now as depicted in Figure 2-3 > > o Node (C) may then subsequently send RA-DIO with DAG Sequence > number N+1, allowing Node (D) to reattach (not depicted). > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 root@core3.amsl.com Sat Oct 24 03:30:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C51923A67F3; Sat, 24 Oct 2009 03:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091024103001.C51923A67F3@core3.amsl.com> Date: Sat, 24 Oct 2009 03:30:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 24 Oct 2009 10:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, D. Networks Filename : draft-ietf-roll-routing-metrics-01.txt Pages : 28 Date : 2009-10-24 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-routing-metrics-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-24031653.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Sat Oct 24 03:42:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C5A3A67F3 for ; Sat, 24 Oct 2009 03:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpCZCDn-FI8Q for ; Sat, 24 Oct 2009 03:42:31 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 09DC53A6767 for ; Sat, 24 Oct 2009 03:42:29 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 85D55D480B7 for ; Sat, 24 Oct 2009 12:42:37 +0200 (CEST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 8D131D4808E for ; Sat, 24 Oct 2009 12:42:35 +0200 (CEST) Message-ID: <4AE2DA17.20701@gmail.com> Date: Sat, 24 Oct 2009 12:42:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: <20091024103001.C51923A67F3@core3.amsl.com> In-Reply-To: <20091024103001.C51923A67F3@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091023-0, 23/10/2009), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 24 Oct 2009 10:42:32 -0000 > The Expected Transmission Count (ETX) metric is defined as 1 / (Df * > Dr) where Df is the measured probability that a packet is received How do you measure that probability ^ ? > ETX: 8 bits. The Latency is encoded in 32 bits in IEEE floating > point format (see [IEEE.754.1985]). Refer to Section 3.1.2 of > [RFC3741] for a table of commonly used values. Er? That RFC "Exclusive XML Canonicalization" does not have any section 3.1.2. Are you sure you refer to the right document? (it too sounds strange to use XML carried in RPL). BTW, do you use XML to edit the metrics draft? Alex Internet-Drafts@ietf.org a écrit : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks > Author(s) : J. Vasseur, D. Networks > Filename : draft-ietf-roll-routing-metrics-01.txt > Pages : 28 > Date : 2009-10-24 > > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Sat Oct 24 05:31:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78E13A6832 for ; Sat, 24 Oct 2009 05:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.691 X-Spam-Level: X-Spam-Status: No, score=-9.691 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49Z5+0L7Tkiu for ; Sat, 24 Oct 2009 05:31:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2BFD53A67F2 for ; Sat, 24 Oct 2009 05:31:36 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcAAJ+Q4kqQ/uCWe2dsb2JhbACCJi2YYAEBFiQGomaJIAiOaoJOCIFpBA X-IronPort-AV: E=Sophos;i="4.44,617,1249257600"; d="scan'208,217";a="52680516" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2009 12:31:46 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9OCVkr7027815 for ; Sat, 24 Oct 2009 12:31:46 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 14:31:46 +0200 Received: from [172.18.20.9] ([10.61.83.39]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 14:31:43 +0200 Message-Id: <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> From: JP Vasseur To: roll ROLL Content-Type: multipart/alternative; boundary=Apple-Mail-6-1054912374 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Oct 2009 14:31:42 +0200 References: <20091024103001.C51923A67F3@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 24 Oct 2009 12:31:46.0124 (UTC) FILETIME=[F34590C0:01CA54A5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16966.007 X-TM-AS-Result: No--21.312400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 24 Oct 2009 12:31:37 -0000 --Apple-Mail-6-1054912374 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Please find below the new revision of the METRIC ID. As you know we had to wait until RPL was stable enough to update this document. This revision is thus a major update compared to the previous one. Few important comments 1) This revision of course takes into account the discussion that we had on the mailing list, 2) No metric is mandated. RPL implementation may use one or several of these metrics and we made them generic enough to be extensible. The use of the metrics will be dictated by the OF. 3) IMPORTANT: there are many ways to use metrics. It could be as simple as a cumulative hop counts or as complex as a hierarchical constraint based approach with multi-metric heuristics, both for nodes and links. We made the design quite generic to support all cases. A RPL implementation may be EXTREMELY simple and compliant to the document or more complex to handle specific situations with less constrained nodes. Waiting for your comments. Thanks. JP, Mijeom and Kris. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 24, 2009 12:30:01 PM CEDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Routing Metrics used for Path Calculation in Low > Power and Lossy Networks > Author(s) : J. Vasseur, D. Networks > Filename : draft-ietf-roll-routing-metrics-01.txt > Pages : 28 > Date : 2009-10-24 > > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-6-1054912374 Content-Type: multipart/mixed; boundary=Apple-Mail-7-1054912375 --Apple-Mail-7-1054912375 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

Please find below the new revision of the METRIC = ID. As you know we had to wait until RPL was stable enough to update = this document. This revision is thus a major update = compared to the previous one. 

Few = important comments
1) This revision of course takes into = account the discussion that we had on the mailing list,
2) No = metric is mandated. RPL implementation may use one or several of these = metrics and we made them generic enough to be extensible. The use of the = metrics will be dictated by the OF.
3) IMPORTANT: there are = many ways to use metrics. It could be as simple as a cumulative hop = counts or as complex as a hierarchical constraint based approach with = multi-metric heuristics, both for nodes and links. We made the design = quite generic to support all cases. A RPL implementation may be = EXTREMELY simple and compliant to the document or more complex to handle = specific situations with less constrained = nodes.

Waiting for your = comments.

Thanks.

JP, = Mijeom and Kris.

Begin forwarded message:

Date: October 24, 2009 12:30:01 PM = CEDT
To: i-d-announce@ietf.org
Subject: = [Roll] I-D = Action:draft-ietf-roll-routing-metrics-01.txt

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : Routing = Metrics used for Path Calculation in Low Power and Lossy = Networks
= Author(s)       : J. Vasseur, D. = Networks
= Filename        : = draft-ietf-roll-routing-metrics-01.txt
Pages =           : = 28
= Date =            : = 2009-10-24

Low power and Lossy Networks (LLNs) have unique = characteristics
compared with traditional wired and ad-hoc networks = that require the
specification of new routing metrics and = constraints.  By contrast
with typical Interior Gateway Protocol = (IGP) routing metrics using
hop counts or link metrics, this document = specifies a set of link and
node routing metrics and constraints = suitable to LLNs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr= ics-01.txt

Internet-Drafts are also available by anonymous = FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-7-1054912375 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-10-24031653.I-D@ietf.org>

--Apple-Mail-7-1054912375 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-7-1054912375-- --Apple-Mail-6-1054912374-- From pal@cs.stanford.edu Sat Oct 24 18:02:07 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 790973A68E4 for ; Sat, 24 Oct 2009 18:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.173 X-Spam-Level: X-Spam-Status: No, score=-5.173 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_05=-1.11, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaXekKRDfmFB for ; Sat, 24 Oct 2009 18:02:06 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id B99503A67DA for ; Sat, 24 Oct 2009 18:02:06 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N1rUw-0006Tt-Fk; Sat, 24 Oct 2009 18:02:18 -0700 Message-Id: From: Philip Levis To: Richard Kelsey In-Reply-To: <8763a78lcr.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Oct 2009 05:15:15 -0400 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> <8763a78lcr.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 25 Oct 2009 01:02:07 -0000 On Oct 22, 2009, at 12:05 PM, Richard Kelsey wrote: > Any protocol that stores routes for future use depends on > some amount of stability. If the topology is sufficiently > unstable the bandwidth needed to maintain routes will > overwhelm the network. Leaving the application with not > enough bandwidth is just as much a routing failure as not > having a working route. With a very dynamic topology the > emphasis has to be on quickly and efficiently finding some > route, rather than spending resources on finding one of the > better routes. I am skeptical that a single protocol will > work well at both ends of the spectrum. Some of the CTP results suggest it is possible: using datapath validation and adaptive beaconing, it's able to be much more reactive and dynamic while simultaneously sending fewer control packets. That being said, it's critical to have some kind of hysteresis. A student here at Stanford studied how hysteresis values (the threshold better a new route must be to choose it over the existing one) affects performance, and found that it's a reasonably robust value that doesn't need fine tuning. > In my experience a lack of bandwidth is a bigger problem for > application on ROLL-style networks than a lack of reliable > connectivity. Connectivity problems can be almost always be > solved by installing more repeaters. If you are out of > bandwidth, there is little you can do to fix that particular > installation. Bounding the routing overhead at the cost of > depending on a more stable topology is the right way to go. I guess this is the part I don't understand: if capacity is the limiting factor, this suggests a high duty cycle. Where does the "low power" part come in? Phil From pal@cs.stanford.edu Sat Oct 24 18:02:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6323A6976 for ; Sat, 24 Oct 2009 18:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.173 X-Spam-Level: X-Spam-Status: No, score=-5.173 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_05=-1.11, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+eHr8YN+rg3 for ; Sat, 24 Oct 2009 18:02:09 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id B5FEA3A6972 for ; Sat, 24 Oct 2009 18:02:09 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N1rUz-0006Tt-LT; Sat, 24 Oct 2009 18:02:21 -0700 Message-Id: <1B72338E-1A44-4AB3-994D-C33AF6BC602C@cs.stanford.edu> From: Philip Levis To: Richard Kelsey In-Reply-To: <8763a78lcr.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Oct 2009 21:02:16 -0400 References: <200910131011.11371.hrogge@googlemail.com> <389DB2FB-DE03-476B-A6E6-11228A006982@cisco.com> <200910131553.47834.hrogge@googlemail.com> <87r5t79t9g.fsf@kelsey-ws.hq.ember.com> <87aazsa6yy.fsf@kelsey-ws.hq.ember.com> <8763a78lcr.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: roll@ietf.org Subject: Re: [Roll] ETX metric X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 25 Oct 2009 01:02:09 -0000 On Oct 22, 2009, at 12:05 PM, Richard Kelsey wrote: > Any protocol that stores routes for future use depends on > some amount of stability. If the topology is sufficiently > unstable the bandwidth needed to maintain routes will > overwhelm the network. Leaving the application with not > enough bandwidth is just as much a routing failure as not > having a working route. With a very dynamic topology the > emphasis has to be on quickly and efficiently finding some > route, rather than spending resources on finding one of the > better routes. I am skeptical that a single protocol will > work well at both ends of the spectrum. Some of the CTP results suggest it is possible: using datapath validation and adaptive beaconing, it's able to be much more reactive and dynamic while simultaneously sending fewer control packets. That being said, it's critical to have some kind of hysteresis. A student here at Stanford studied how hysteresis values (the threshold better a new route must be to choose it over the existing one) affects performance, and found that it's a reasonably robust value that doesn't need fine tuning. > In my experience a lack of bandwidth is a bigger problem for > application on ROLL-style networks than a lack of reliable > connectivity. Connectivity problems can be almost always be > solved by installing more repeaters. If you are out of > bandwidth, there is little you can do to fix that particular > installation. Bounding the routing overhead at the cost of > depending on a more stable topology is the right way to go. I guess this is the part I don't understand: if capacity is the limiting factor, this suggests a high duty cycle. Where does the "low power" part come in? Phil From pal@cs.stanford.edu Sat Oct 24 18:20:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8283A67EF for ; Sat, 24 Oct 2009 18:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLDLp9Q+-6mk for ; Sat, 24 Oct 2009 18:20:37 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 308AE3A67DA for ; Sat, 24 Oct 2009 18:20:37 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N1rmq-0006sz-A4; Sat, 24 Oct 2009 18:20:48 -0700 Message-Id: From: Philip Levis To: JP Vasseur In-Reply-To: <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Oct 2009 18:20:47 -0700 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 25 Oct 2009 01:20:38 -0000 On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: > Dear all, > > Please find below the new revision of the METRIC ID. As you know we > had to wait until RPL was stable enough to update this document. > This revision is thus a major update compared to the previous one. > > Few important comments > 1) This revision of course takes into account the discussion that we > had on the mailing list, > 2) No metric is mandated. RPL implementation may use one or several > of these metrics and we made them generic enough to be extensible. > The use of the metrics will be dictated by the OF. > 3) IMPORTANT: there are many ways to use metrics. It could be as > simple as a cumulative hop counts or as complex as a hierarchical > constraint based approach with multi-metric heuristics, both for > nodes and links. We made the design quite generic to support all > cases. A RPL implementation may be EXTREMELY simple and compliant to > the document or more complex to handle specific situations with less > constrained nodes. 4.3.2. The Expected Transmission Count (ETX) Reliability Object The Expected Transmission Count (ETX) metric is defined as 1 / (Df * Dr) where Df is the measured probability that a packet is received by the neighbor and Dr is the measured probability that the acknowledgment packet is successfully received. I would change this to say The Expected Transmission Count (ETX) metric is the number of transmissions a node expects to make to a destination in order to successfully deliver a packet. The approach of 1 / (Df * Dr) is the approach used by Srcr, but there are other algorithms for measuring it, such as 4B and EAR. Phil From alexandru.petrescu@gmail.com Sun Oct 25 07:26:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997A53A6872 for ; Sun, 25 Oct 2009 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycfF+1V2kow0 for ; Sun, 25 Oct 2009 07:26:42 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 86D203A681B for ; Sun, 25 Oct 2009 07:26:40 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id E0E2FD48065; Sun, 25 Oct 2009 15:26:49 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id C7596D48044; Sun, 25 Oct 2009 15:26:46 +0100 (CET) Message-ID: <4AE46026.6030002@gmail.com> Date: Sun, 25 Oct 2009 15:26:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091024-0, 24/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 25 Oct 2009 14:26:43 -0000 Philip Levis a écrit : > > On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: > >> Dear all, >> >> Please find below the new revision of the METRIC ID. As you know we >> had to wait until RPL was stable enough to update this document. This >> revision is thus a major update compared to the previous one. >> >> Few important comments >> 1) This revision of course takes into account the discussion that we >> had on the mailing list, >> 2) No metric is mandated. RPL implementation may use one or several of >> these metrics and we made them generic enough to be extensible. The >> use of the metrics will be dictated by the OF. >> 3) IMPORTANT: there are many ways to use metrics. It could be as >> simple as a cumulative hop counts or as complex as a hierarchical >> constraint based approach with multi-metric heuristics, both for nodes >> and links. We made the design quite generic to support all cases. A >> RPL implementation may be EXTREMELY simple and compliant to the >> document or more complex to handle specific situations with less >> constrained nodes. > > > 4.3.2. The Expected Transmission Count (ETX) Reliability Object > > The Expected Transmission Count (ETX) metric is defined as 1 / (Df * > Dr) where Df is the measured probability that a packet is received by > the neighbor and Dr is the measured probability that the > acknowledgment packet is successfully received. > > I would change this to say > > The Expected Transmission Count (ETX) metric is the number of > transmissions > a node expects to make to a destination in order to successfully > deliver a > packet. Ok... suppose I want to implement this. Is this number a constant somewhere in a sheet? Where am I supposed to get this number in order to put it in a message? Alex > > The approach of 1 / (Df * Dr) is the approach used by Srcr, but there > are other algorithms for measuring it, such as 4B and EAR. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Mon Oct 26 01:24:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1B728C1EF for ; Mon, 26 Oct 2009 01:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.726 X-Spam-Level: X-Spam-Status: No, score=-9.726 tagged_above=-999 required=5 tests=[AWL=0.873, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUNkksTQ2OlP for ; Mon, 26 Oct 2009 01:24:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9885C28C1B1 for ; Mon, 26 Oct 2009 01:24:53 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMAADP65EqQ/uCWe2dsb2JhbACbNQEBFiQGo0SJIAiNOIJOCIFpBIsx X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="52746155" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 08:25:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9Q8P5P7017772; Mon, 26 Oct 2009 08:25:05 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 09:25:05 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 09:25:04 +0100 Message-Id: <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 09:25:03 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 08:25:05.0172 (UTC) FILETIME=[D20B0540:01CA5615] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16970.005 X-TM-AS-Result: No--15.237400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 08:24:54 -0000 On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: > > On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: > >> Dear all, >> >> Please find below the new revision of the METRIC ID. As you know we >> had to wait until RPL was stable enough to update this document. >> This revision is thus a major update compared to the previous one. >> >> Few important comments >> 1) This revision of course takes into account the discussion that >> we had on the mailing list, >> 2) No metric is mandated. RPL implementation may use one or several >> of these metrics and we made them generic enough to be extensible. >> The use of the metrics will be dictated by the OF. >> 3) IMPORTANT: there are many ways to use metrics. It could be as >> simple as a cumulative hop counts or as complex as a hierarchical >> constraint based approach with multi-metric heuristics, both for >> nodes and links. We made the design quite generic to support all >> cases. A RPL implementation may be EXTREMELY simple and compliant >> to the document or more complex to handle specific situations with >> less constrained nodes. > > > 4.3.2. The Expected Transmission Count (ETX) Reliability Object > > The Expected Transmission Count (ETX) metric is defined as 1 / (Df * > Dr) where Df is the measured probability that a packet is received > by > the neighbor and Dr is the measured probability that the > acknowledgment packet is successfully received. > > I would change this to say > > The Expected Transmission Count (ETX) metric is the number of > transmissions > a node expects to make to a destination in order to successfully > deliver a > packet. > > The approach of 1 / (Df * Dr) is the approach used by Srcr, but > there are other algorithms for measuring it, such as 4B and EAR. > Absolutely. Makes sense. I added this one as an example (I'll be more explicit about the fact that this *one* example). We want to make it implementation specific since there are many ways to compute it depending on the link layer and other parameters. Cheers. JP. > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Mon Oct 26 01:54:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A381228C187 for ; Mon, 26 Oct 2009 01:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52k+ZgQCOFgZ for ; Mon, 26 Oct 2009 01:54:46 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 9897228C102 for ; Mon, 26 Oct 2009 01:54:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9Q8soVV016472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 09:54:50 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9Q8sokM022441; Mon, 26 Oct 2009 09:54:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9Q8snXa007984; Mon, 26 Oct 2009 09:54:50 +0100 Message-ID: <4AE563D9.8000200@gmail.com> Date: Mon, 26 Oct 2009 09:54:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> In-Reply-To: <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 08:54:47 -0000 JP Vasseur a écrit : > > On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: > >> >> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >> >>> Dear all, >>> >>> Please find below the new revision of the METRIC ID. As you know we >>> had to wait until RPL was stable enough to update this document. This >>> revision is thus a major update compared to the previous one. >>> >>> Few important comments >>> 1) This revision of course takes into account the discussion that we >>> had on the mailing list, >>> 2) No metric is mandated. RPL implementation may use one or several >>> of these metrics and we made them generic enough to be extensible. >>> The use of the metrics will be dictated by the OF. >>> 3) IMPORTANT: there are many ways to use metrics. It could be as >>> simple as a cumulative hop counts or as complex as a hierarchical >>> constraint based approach with multi-metric heuristics, both for >>> nodes and links. We made the design quite generic to support all >>> cases. A RPL implementation may be EXTREMELY simple and compliant to >>> the document or more complex to handle specific situations with less >>> constrained nodes. >> >> >> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >> >> The Expected Transmission Count (ETX) metric is defined as 1 / (Df * >> Dr) where Df is the measured probability that a packet is received by >> the neighbor and Dr is the measured probability that the >> acknowledgment packet is successfully received. >> >> I would change this to say >> >> The Expected Transmission Count (ETX) metric is the number of >> transmissions >> a node expects to make to a destination in order to successfully >> deliver a >> packet. >> >> The approach of 1 / (Df * Dr) is the approach used by Srcr, but there >> are other algorithms for measuring it, such as 4B and EAR. >> > > Absolutely. Makes sense. I added this one as an example (I'll be more > explicit about the fact that this *one* example). We want to make it > implementation specific since there are many ways to compute it > depending on the link layer and other parameters. In defining ETX one would like to make sure that two different implementers implement the same way an ETX. Alex > > Cheers. > > JP. > >> Phil >> _______________________________________________ >> 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 ietf@thomasclausen.org Mon Oct 26 01:59:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB1B3A692D for ; Mon, 26 Oct 2009 01:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3IxBvNNs1lh for ; Mon, 26 Oct 2009 01:59:38 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 7B32F3A692C for ; Mon, 26 Oct 2009 01:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 09E3432317AF; Mon, 26 Oct 2009 01:59:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id DC98532317AE; Mon, 26 Oct 2009 01:59:50 -0700 (PDT) Message-Id: <822D2111-03F9-4EE9-932B-0D79F7FDC9BE@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE563D9.8000200@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-38--932485730 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 09:59:48 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 08:59:39 -0000 --Apple-Mail-38--932485730 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>> >> Absolutely. Makes sense. I added this one as an example (I'll be >> more explicit about the fact that this *one* example). We want to >> make it implementation specific since there are many ways to >> compute it depending on the link layer and other parameters. > > In defining ETX one would like to make sure that two different > implementers implement the same way an ETX. In the case where two different implementations would cause interoperability difficulties, yes. Otherwise, no. Do you think that, as long as the ETX value is unambiguous to whoever calculates it and is consistently communicated, there are interoperability difficulties? Thomas --Apple-Mail-38--932485730 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 9:54 AM, Alexandru Petrescu wrote:

Absolutely. Makes sense. I added this one as an example = (I'll be more explicit about the fact that this *one* example). We want = to make it implementation specific since there are many ways to compute = it depending on the link layer and other = parameters.

In defining ETX one would like to make = sure that two different implementers implement the same way an = ETX.

In the case where two = different implementations would cause interoperability difficulties, = yes. 

Otherwise, = no.

Do you think that, as long as the ETX value = is unambiguous to whoever calculates it and is consistently = communicated, there are interoperability = difficulties?

Thomas
= --Apple-Mail-38--932485730-- From jvasseur@cisco.com Mon Oct 26 02:11:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D30928C213 for ; Mon, 26 Oct 2009 02:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.759 X-Spam-Level: X-Spam-Status: No, score=-9.759 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BnT7smnlavv for ; Mon, 26 Oct 2009 02:11:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4A08E28C1DF for ; Mon, 26 Oct 2009 02:11:46 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAL8E5UqQ/uCWe2dsb2JhbACbNQEBFiQGo1WJIAiNPIJOCIFpBA X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="52752401" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 09:11:58 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9Q9BwK9004682; Mon, 26 Oct 2009 09:11:58 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:11:58 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:11:57 +0100 Message-Id: <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AE563D9.8000200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:11:52 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 09:11:57.0667 (UTC) FILETIME=[5E6BB330:01CA561C] Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:11:48 -0000 On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>> >>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>> >>>> Dear all, >>>> >>>> Please find below the new revision of the METRIC ID. As you know =20= >>>> we had to wait until RPL was stable enough to update this =20 >>>> document. This revision is thus a major update compared to the =20 >>>> previous one. >>>> >>>> Few important comments >>>> 1) This revision of course takes into account the discussion that =20= >>>> we had on the mailing list, >>>> 2) No metric is mandated. RPL implementation may use one or =20 >>>> several of these metrics and we made them generic enough to be =20 >>>> extensible. The use of the metrics will be dictated by the OF. >>>> 3) IMPORTANT: there are many ways to use metrics. It could be as =20= >>>> simple as a cumulative hop counts or as complex as a hierarchical =20= >>>> constraint based approach with multi-metric heuristics, both for =20= >>>> nodes and links. We made the design quite generic to support all =20= >>>> cases. A RPL implementation may be EXTREMELY simple and compliant =20= >>>> to the document or more complex to handle specific situations =20 >>>> with less constrained nodes. >>> >>> >>> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >>> >>> The Expected Transmission Count (ETX) metric is defined as 1 / (Df * >>> Dr) where Df is the measured probability that a packet is received =20= >>> by >>> the neighbor and Dr is the measured probability that the >>> acknowledgment packet is successfully received. >>> >>> I would change this to say >>> >>> The Expected Transmission Count (ETX) metric is the number of =20 >>> transmissions >>> a node expects to make to a destination in order to successfully =20 >>> deliver a >>> packet. >>> >>> The approach of 1 / (Df * Dr) is the approach used by Srcr, but =20 >>> there are other algorithms for measuring it, such as 4B and EAR. >>> >> Absolutely. Makes sense. I added this one as an example (I'll be =20 >> more explicit about the fact that this *one* example). We want to =20 >> make it implementation specific since there are many ways to =20 >> compute it depending on the link layer and other parameters. > > In defining ETX one would like to make sure that two different =20 > implementers implement the same way an ETX. > This is more of a deployment issue though. Look at OSPF/ISIS/..., we =20 do not mandate the use of a specific formula. But you're right that =20 the use of consistent metric is key (this is mentioned in Section 8). Thanks. JP. > Alex > >> Cheers. >> JP. >>> Phil >>> _______________________________________________ >>> 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 alexandru.petrescu@gmail.com Mon Oct 26 02:13:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF47B28C217 for ; Mon, 26 Oct 2009 02:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm1krn+kiwUF for ; Mon, 26 Oct 2009 02:13:09 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id DB11228C21C for ; Mon, 26 Oct 2009 02:13:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9Q9CwMl032268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:12:58 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9Q9Cv0t029797; Mon, 26 Oct 2009 10:12:58 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9Q9CvYr015959; Mon, 26 Oct 2009 10:12:57 +0100 Message-ID: <4AE56819.9070102@gmail.com> Date: Mon, 26 Oct 2009 10:12:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <822D2111-03F9-4EE9-932B-0D79F7FDC9BE@thomasclausen.org> In-Reply-To: <822D2111-03F9-4EE9-932B-0D79F7FDC9BE@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:13:09 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>> >>> Absolutely. Makes sense. I added this one as an example (I'll be more >>> explicit about the fact that this *one* example). We want to make it >>> implementation specific since there are many ways to compute it >>> depending on the link layer and other parameters. >> >> In defining ETX one would like to make sure that two different >> implementers implement the same way an ETX. > > In the case where two different implementations would cause > interoperability difficulties, yes. > > Otherwise, no. > > Do you think that, as long as the ETX value is unambiguous to whoever > calculates it and is consistently communicated, there are > interoperability difficulties? Thomas, where do I get this number: > The Expected Transmission Count (ETX) metric is the number of transmissions > a node expects to make to a destination in order to successfully deliver a > packet. Where can I get this number of transmission my node expects to make to a destination in order to successfully deliver a packet? Alex > > Thomas From alexandru.petrescu@gmail.com Mon Oct 26 02:14:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A733A68E6 for ; Mon, 26 Oct 2009 02:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY42cPihHv2G for ; Mon, 26 Oct 2009 02:14:43 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 3B8963A68D3 for ; Mon, 26 Oct 2009 02:14:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9Q9ElGe000915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:14:47 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9Q9EkeG030433; Mon, 26 Oct 2009 10:14:46 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9Q9EkUJ016667; Mon, 26 Oct 2009 10:14:46 +0100 Message-ID: <4AE56886.2070101@gmail.com> Date: Mon, 26 Oct 2009 10:14:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> In-Reply-To: <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:14:44 -0000 JP Vasseur a écrit : > > On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>> >>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>> >>>>> Dear all, >>>>> >>>>> Please find below the new revision of the METRIC ID. As you know we >>>>> had to wait until RPL was stable enough to update this document. >>>>> This revision is thus a major update compared to the previous one. >>>>> >>>>> Few important comments >>>>> 1) This revision of course takes into account the discussion that >>>>> we had on the mailing list, >>>>> 2) No metric is mandated. RPL implementation may use one or several >>>>> of these metrics and we made them generic enough to be extensible. >>>>> The use of the metrics will be dictated by the OF. >>>>> 3) IMPORTANT: there are many ways to use metrics. It could be as >>>>> simple as a cumulative hop counts or as complex as a hierarchical >>>>> constraint based approach with multi-metric heuristics, both for >>>>> nodes and links. We made the design quite generic to support all >>>>> cases. A RPL implementation may be EXTREMELY simple and compliant >>>>> to the document or more complex to handle specific situations with >>>>> less constrained nodes. >>>> >>>> >>>> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >>>> >>>> The Expected Transmission Count (ETX) metric is defined as 1 / (Df * >>>> Dr) where Df is the measured probability that a packet is received by >>>> the neighbor and Dr is the measured probability that the >>>> acknowledgment packet is successfully received. >>>> >>>> I would change this to say >>>> >>>> The Expected Transmission Count (ETX) metric is the number of >>>> transmissions >>>> a node expects to make to a destination in order to successfully >>>> deliver a >>>> packet. >>>> >>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, but >>>> there are other algorithms for measuring it, such as 4B and EAR. >>>> >>> Absolutely. Makes sense. I added this one as an example (I'll be more >>> explicit about the fact that this *one* example). We want to make it >>> implementation specific since there are many ways to compute it >>> depending on the link layer and other parameters. >> >> In defining ETX one would like to make sure that two different >> implementers implement the same way an ETX. >> > > This is more of a deployment issue though. Look at OSPF/ISIS/..., we do > not mandate the use of a specific formula. However, the hopcount metric in OSPF is univerally understood: the number of IP hops in between, and this number is well understood. I am not sure what in OSPF/ISIS/... makes you think I should look at, to make me think it's like ETX - deployment issue? Alex But you're right that the use > of consistent metric is key (this is mentioned in Section 8). > > Thanks. > > JP. > >> Alex >> >>> Cheers. >>> JP. >>>> Phil >>>> _______________________________________________ >>>> 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 jvasseur@cisco.com Mon Oct 26 02:15:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F6E3A6774 for ; Mon, 26 Oct 2009 02:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.789 X-Spam-Level: X-Spam-Status: No, score=-9.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaQFAZ-vPCr4 for ; Mon, 26 Oct 2009 02:15:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AF2E93A68D3 for ; Mon, 26 Oct 2009 02:15:41 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAOsF5UqQ/uCWe2dsb2JhbACbNQEBFiQGo2aJIAiNPYJOCIFpBA X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="52753020" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 09:15:53 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9Q9Frvm006343; Mon, 26 Oct 2009 09:15:53 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:15:53 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:15:53 +0100 Message-Id: <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AE56886.2070101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:15:52 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 09:15:53.0477 (UTC) FILETIME=[EAF97350:01CA561C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16970.006 X-TM-AS-Result: No--20.928200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:15:44 -0000 On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>> >>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> Please find below the new revision of the METRIC ID. As you =20 >>>>>> know we had to wait until RPL was stable enough to update this =20= >>>>>> document. This revision is thus a major update compared to the =20= >>>>>> previous one. >>>>>> >>>>>> Few important comments >>>>>> 1) This revision of course takes into account the discussion =20 >>>>>> that we had on the mailing list, >>>>>> 2) No metric is mandated. RPL implementation may use one or =20 >>>>>> several of these metrics and we made them generic enough to be =20= >>>>>> extensible. The use of the metrics will be dictated by the OF. >>>>>> 3) IMPORTANT: there are many ways to use metrics. It could be =20 >>>>>> as simple as a cumulative hop counts or as complex as a =20 >>>>>> hierarchical constraint based approach with multi-metric =20 >>>>>> heuristics, both for nodes and links. We made the design quite =20= >>>>>> generic to support all cases. A RPL implementation may be =20 >>>>>> EXTREMELY simple and compliant to the document or more complex =20= >>>>>> to handle specific situations with less constrained nodes. >>>>> >>>>> >>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >>>>> >>>>> The Expected Transmission Count (ETX) metric is defined as 1 / =20 >>>>> (Df * >>>>> Dr) where Df is the measured probability that a packet is =20 >>>>> received by >>>>> the neighbor and Dr is the measured probability that the >>>>> acknowledgment packet is successfully received. >>>>> >>>>> I would change this to say >>>>> >>>>> The Expected Transmission Count (ETX) metric is the number of =20 >>>>> transmissions >>>>> a node expects to make to a destination in order to successfully =20= >>>>> deliver a >>>>> packet. >>>>> >>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, but =20= >>>>> there are other algorithms for measuring it, such as 4B and EAR. >>>>> >>>> Absolutely. Makes sense. I added this one as an example (I'll be =20= >>>> more explicit about the fact that this *one* example). We want to =20= >>>> make it implementation specific since there are many ways to =20 >>>> compute it depending on the link layer and other parameters. >>> >>> In defining ETX one would like to make sure that two different =20 >>> implementers implement the same way an ETX. >>> >> This is more of a deployment issue though. Look at OSPF/ISIS/..., =20 >> we do not mandate the use of a specific formula. > > However, the hopcount metric in OSPF is univerally understood: the =20 > number of IP hops in between, and this number is well understood. > > I am not sure what in OSPF/ISIS/... makes you think I should look =20 > at, to make me think it's like ETX - deployment issue? > OSPF and ISIS do not use hop count but a static undefined link metric. JP. > Alex > > > But you're right that the use >> of consistent metric is key (this is mentioned in Section 8). >> Thanks. >> JP. >>> Alex >>> >>>> Cheers. >>>> JP. >>>>> Phil >>>>> _______________________________________________ >>>>> 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 ietf@thomasclausen.org Mon Oct 26 02:15:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E88F3A6774 for ; Mon, 26 Oct 2009 02:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFGbrpjR4Lph for ; Mon, 26 Oct 2009 02:15:43 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9F53C3A6906 for ; Mon, 26 Oct 2009 02:15:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 3404D32317AE; Mon, 26 Oct 2009 02:15:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 1F0E132317AD; Mon, 26 Oct 2009 02:15:54 -0700 (PDT) Message-Id: <38376A80-D75B-44B3-AF19-A2CA4AB2C2A2@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56819.9070102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:15:52 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <822D2111-03F9-4EE9-932B-0D79F7FDC9BE@thomasclausen.org> <4AE56819.9070102@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:15:44 -0000 On Oct 26, 2009, at 10:12 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>> >>>> Absolutely. Makes sense. I added this one as an example (I'll be =20= >>>> more explicit about the fact that this *one* example). We want to =20= >>>> make it implementation specific since there are many ways to =20 >>>> compute it depending on the link layer and other parameters. >>> >>> In defining ETX one would like to make sure that two different =20 >>> implementers implement the same way an ETX. >> In the case where two different implementations would cause =20 >> interoperability difficulties, yes. Otherwise, no. >> Do you think that, as long as the ETX value is unambiguous to =20 >> whoever calculates it and is consistently communicated, there are =20 >> interoperability difficulties? > > Thomas, where do I get this number: >> The Expected Transmission Count (ETX) metric is the number of =20 >> transmissions >> a node expects to make to a destination in order to successfully =20 >> deliver a >> packet. > > Where can I get this number of transmission my node expects to make =20= > to a destination in order to successfully deliver a packet? > I don't know, I would guess that it depends on your platform (OS, =20 hardware, applications) allowing you to make more or less accurate =20 estimates of this value. It doesn't matter, however, as long as that value is established in =20 one place (check) and so there are no ambiguities as to what that =20 value is, for a given Thomas From ietf@thomasclausen.org Mon Oct 26 02:19:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09243A687C for ; Mon, 26 Oct 2009 02:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5shbN8tada2p for ; Mon, 26 Oct 2009 02:19:50 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 98B573A657C for ; Mon, 26 Oct 2009 02:19:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id BE5BD32317AE; Mon, 26 Oct 2009 02:20:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 834CA32317B0; Mon, 26 Oct 2009 02:20:02 -0700 (PDT) Message-Id: <1D050D64-F6BE-4D1B-B92D-84F03CA887B4@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56886.2070101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:20:02 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:19:50 -0000 On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>> >>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>> >>>>>> Dear all, >>>>>> >>>>>> Please find below the new revision of the METRIC ID. As you =20 >>>>>> know we had to wait until RPL was stable enough to update this =20= >>>>>> document. This revision is thus a major update compared to the =20= >>>>>> previous one. >>>>>> >>>>>> Few important comments >>>>>> 1) This revision of course takes into account the discussion =20 >>>>>> that we had on the mailing list, >>>>>> 2) No metric is mandated. RPL implementation may use one or =20 >>>>>> several of these metrics and we made them generic enough to be =20= >>>>>> extensible. The use of the metrics will be dictated by the OF. >>>>>> 3) IMPORTANT: there are many ways to use metrics. It could be =20 >>>>>> as simple as a cumulative hop counts or as complex as a =20 >>>>>> hierarchical constraint based approach with multi-metric =20 >>>>>> heuristics, both for nodes and links. We made the design quite =20= >>>>>> generic to support all cases. A RPL implementation may be =20 >>>>>> EXTREMELY simple and compliant to the document or more complex =20= >>>>>> to handle specific situations with less constrained nodes. >>>>> >>>>> >>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >>>>> >>>>> The Expected Transmission Count (ETX) metric is defined as 1 / =20 >>>>> (Df * >>>>> Dr) where Df is the measured probability that a packet is =20 >>>>> received by >>>>> the neighbor and Dr is the measured probability that the >>>>> acknowledgment packet is successfully received. >>>>> >>>>> I would change this to say >>>>> >>>>> The Expected Transmission Count (ETX) metric is the number of =20 >>>>> transmissions >>>>> a node expects to make to a destination in order to successfully =20= >>>>> deliver a >>>>> packet. >>>>> >>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, but =20= >>>>> there are other algorithms for measuring it, such as 4B and EAR. >>>>> >>>> Absolutely. Makes sense. I added this one as an example (I'll be =20= >>>> more explicit about the fact that this *one* example). We want to =20= >>>> make it implementation specific since there are many ways to =20 >>>> compute it depending on the link layer and other parameters. >>> >>> In defining ETX one would like to make sure that two different =20 >>> implementers implement the same way an ETX. >>> >> This is more of a deployment issue though. Look at OSPF/ISIS/..., =20 >> we do not mandate the use of a specific formula. > > However, the hopcount metric in OSPF is univerally understood: the =20 > number of IP hops in between, and this number is well understood. > > I am not sure what in OSPF/ISIS/... makes you think I should look =20 > at, to make me think it's like ETX - deployment issue? It's not really the point, Alex. Think of a graph with weights (cost) =20= on the edges. It doesn't matter if the weight is 1 or "something else", as long as =20 the weights are unambiguous. If the weight for a given edge is =20 established in *one* place only, everything works fine ;) Thomas From alexandru.petrescu@gmail.com Mon Oct 26 02:29:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A42C3A657C for ; Mon, 26 Oct 2009 02:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUQDwSpXU6hN for ; Mon, 26 Oct 2009 02:29:45 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 4581B3A6358 for ; Mon, 26 Oct 2009 02:29:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9Q9TmfS015701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:29:48 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9Q9TmEo003553; Mon, 26 Oct 2009 10:29:48 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9Q9TlUh025886; Mon, 26 Oct 2009 10:29:47 +0100 Message-ID: <4AE56C0B.70005@gmail.com> Date: Mon, 26 Oct 2009 10:29:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> In-Reply-To: <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:29:46 -0000 JP Vasseur a écrit : > > On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>> >>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> Please find below the new revision of the METRIC ID. As >>>>>>> you know we had to wait until RPL was stable enough to >>>>>>> update this document. This revision is thus a major >>>>>>> update compared to the previous one. >>>>>>> >>>>>>> Few important comments 1) This revision of course takes >>>>>>> into account the discussion that we had on the mailing >>>>>>> list, 2) No metric is mandated. RPL implementation may >>>>>>> use one or several of these metrics and we made them >>>>>>> generic enough to be extensible. The use of the metrics >>>>>>> will be dictated by the OF. 3) IMPORTANT: there are many >>>>>>> ways to use metrics. It could be as simple as a >>>>>>> cumulative hop counts or as complex as a hierarchical >>>>>>> constraint based approach with multi-metric heuristics, >>>>>>> both for nodes and links. We made the design quite >>>>>>> generic to support all cases. A RPL implementation may be >>>>>>> EXTREMELY simple and compliant to the document or more >>>>>>> complex to handle specific situations with less >>>>>>> constrained nodes. >>>>>> >>>>>> >>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability >>>>>> Object >>>>>> >>>>>> The Expected Transmission Count (ETX) metric is defined as >>>>>> 1 / (Df * Dr) where Df is the measured probability that a >>>>>> packet is received by the neighbor and Dr is the measured >>>>>> probability that the acknowledgment packet is successfully >>>>>> received. >>>>>> >>>>>> I would change this to say >>>>>> >>>>>> The Expected Transmission Count (ETX) metric is the number >>>>>> of transmissions a node expects to make to a destination in >>>>>> order to successfully deliver a packet. >>>>>> >>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, >>>>>> but there are other algorithms for measuring it, such as 4B >>>>>> and EAR. >>>>>> >>>>> Absolutely. Makes sense. I added this one as an example (I'll >>>>> be more explicit about the fact that this *one* example). We >>>>> want to make it implementation specific since there are many >>>>> ways to compute it depending on the link layer and other >>>>> parameters. >>>> >>>> In defining ETX one would like to make sure that two different >>>> implementers implement the same way an ETX. >>>> >>> This is more of a deployment issue though. Look at OSPF/ISIS/..., >>> we do not mandate the use of a specific formula. >> >> However, the hopcount metric in OSPF is univerally understood: the >> number of IP hops in between, and this number is well understood. >> >> I am not sure what in OSPF/ISIS/... makes you think I should look >> at, to make me think it's like ETX - deployment issue? >> > > OSPF and ISIS do not use hop count but a static undefined link > metric. Ah! There may be a misunderstanding. I counted on this OSPF text: "The next hop calculation is invoked each time a shorter path to the destination is discovered." "Shorter" is in terms of IP hop count. Let me see later, thanks. Alex From alexandru.petrescu@gmail.com Mon Oct 26 02:32:35 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E51C3A67BD for ; Mon, 26 Oct 2009 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQJF2Rf0mKEK for ; Mon, 26 Oct 2009 02:32:34 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 395FC3A6358 for ; Mon, 26 Oct 2009 02:32:34 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9Q9WcXf018377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:32:38 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9Q9WcoC004749; Mon, 26 Oct 2009 10:32:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9Q9WcXs027428; Mon, 26 Oct 2009 10:32:38 +0100 Message-ID: <4AE56CB6.3090400@gmail.com> Date: Mon, 26 Oct 2009 10:32:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:32:35 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>> >>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> Please find below the new revision of the METRIC ID. As you know >>>>>>> we had to wait until RPL was stable enough to update this >>>>>>> document. This revision is thus a major update compared to the >>>>>>> previous one. >>>>>>> >>>>>>> Few important comments >>>>>>> 1) This revision of course takes into account the discussion that >>>>>>> we had on the mailing list, >>>>>>> 2) No metric is mandated. RPL implementation may use one or >>>>>>> several of these metrics and we made them generic enough to be >>>>>>> extensible. The use of the metrics will be dictated by the OF. >>>>>>> 3) IMPORTANT: there are many ways to use metrics. It could be as >>>>>>> simple as a cumulative hop counts or as complex as a hierarchical >>>>>>> constraint based approach with multi-metric heuristics, both for >>>>>>> nodes and links. We made the design quite generic to support all >>>>>>> cases. A RPL implementation may be EXTREMELY simple and compliant >>>>>>> to the document or more complex to handle specific situations >>>>>>> with less constrained nodes. >>>>>> >>>>>> >>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >>>>>> >>>>>> The Expected Transmission Count (ETX) metric is defined as 1 / (Df * >>>>>> Dr) where Df is the measured probability that a packet is received by >>>>>> the neighbor and Dr is the measured probability that the >>>>>> acknowledgment packet is successfully received. >>>>>> >>>>>> I would change this to say >>>>>> >>>>>> The Expected Transmission Count (ETX) metric is the number of >>>>>> transmissions >>>>>> a node expects to make to a destination in order to successfully >>>>>> deliver a >>>>>> packet. >>>>>> >>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, but >>>>>> there are other algorithms for measuring it, such as 4B and EAR. >>>>>> >>>>> Absolutely. Makes sense. I added this one as an example (I'll be >>>>> more explicit about the fact that this *one* example). We want to >>>>> make it implementation specific since there are many ways to >>>>> compute it depending on the link layer and other parameters. >>>> >>>> In defining ETX one would like to make sure that two different >>>> implementers implement the same way an ETX. >>>> >>> This is more of a deployment issue though. Look at OSPF/ISIS/..., we >>> do not mandate the use of a specific formula. >> >> However, the hopcount metric in OSPF is univerally understood: the >> number of IP hops in between, and this number is well understood. >> >> I am not sure what in OSPF/ISIS/... makes you think I should look at, >> to make me think it's like ETX - deployment issue? > > It's not really the point, Alex. Think of a graph with weights (cost) on > the edges. YEs, yes. > It doesn't matter if the weight is 1 or "something else", as long as the > weights are unambiguous. If the weight for a given edge is established > in *one* place only, everything works fine ;) That's a problem IMHO - the expected in ETX. Alex > > Thomas > > From mdurvy@cisco.com Mon Oct 26 02:37:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4107D3A682A for ; Mon, 26 Oct 2009 02:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.611 X-Spam-Level: X-Spam-Status: No, score=-9.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN8bWo-Kef-z for ; Mon, 26 Oct 2009 02:37:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C82053A6801 for ; Mon, 26 Oct 2009 02:37:12 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAJsK5UqQ/uCWe2dsb2JhbACbNgEBFiQGpBmWYoQ/BIsx X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="52755957" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 09:37:24 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9Q9bOfc013793; Mon, 26 Oct 2009 09:37:24 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:37:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 10:37:23 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE92F2ED@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D7A3344@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] PathDigest question Thread-Index: AcpT/UAuw+/gax1AQC6o+nDxJdqiqQADOWswAISE16A= References: <1019652622.21495031256314353645.JavaMail.root@mail02.pantherlink.uwm.edu><1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D7A3344@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "Mukul Goyal" , "Anders Jagd" X-OriginalArrivalTime: 26 Oct 2009 09:37:24.0782 (UTC) FILETIME=[ECA6F4E0:01CA561F] Cc: roll Subject: Re: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:37:14 -0000 Hi All, As I mention in my previous email, I don't see a clear justification for the PathDigest in the current draft. The only place where the PathDigest is mentioned (outside of the DIO format) is Section 5.9.2.1. "Destination advertisements may also be scheduled for sending when the PathDigest of the RA-DIO message has changed".=20 In addition its current definition is not very clear to me. It says that the PathDigest is "the result of a CRC-32c computation on a bit string obtained by appending the received value and the ordered set of DAG parents of the LLN Node". Which received value? The one from the 'prefered' parent? As mentioned by Mukul, does a change of PathDigest necessarily affects the receiving node? (it might not require any change locally)... I would be happy to know if someone as a clear example highlighting the use of the PathDigest. Otherwise I propose to add the removal of the PathDigest to the list of possible simplifications. Best, Mathilde -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: vendredi, 23. octobre 2009 20:09 To: Mukul Goyal Cc: roll Subject: Re: [Roll] PathDigest question Hi Mukul: A path digest tells that something has changed in the inwards path of this node and suggest that DAOs should be sent. This is mostly useful for source route. For stateful, all you need to know is that your parents change. Also, this is mostly meaningful if the DAOs do not fan out since this is the digest of the preferred path.=20 I think the current draft suggests to send DAOs over one parent (as opposed to fan out) but does not impose anything on which that parent is (preferred or not).=20 WRT trickle, if there's no source route, I agree with you and I do not see why that would require to do anything. If there's source route, then the exponential backoff of RAs might help ensure that all the children reconstruct their path faster. What do you think?=20 Pascal >-----Original Message----- >From: Mukul Goyal [mailto:mukul@uwm.edu] >Sent: vendredi 23 octobre 2009 18:24 >To: Pascal Thubert (pthubert) >Cc: roll >Subject: PathDigest question > >Hi Pascal and Tim > >I had a doubt about PathDigest. > >Sec 5.3.4.2 of rpl-3 draft says that when "The node receives a modified >RA-DIO message from a DAG parent", its trickle timer is reset. > >Does it mean that the trickle timer is reset if a parent RIO shows modified PathDigest? > >Now, a modified PathDigest from the parent means that the parent's=20 >parent set changed. I was wondering why should it be an inconsistency=20 >for me. If information in this RIO does not force me to change my rank/parent_set/routing_metrics, I need not reset my trickle timer. > >Now, parent's changed PathDigest may be used to trigger NA-DAOs to this >parent (as the draft already mentions). But I am not sure why should it cause resetting of trickle timer governing RA-DIOs. > >Thanks >Mukul _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Mon Oct 26 02:41:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AEDC3A6909 for ; Mon, 26 Oct 2009 02:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGaQ9G8voqmz for ; Mon, 26 Oct 2009 02:41:08 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id C98703A689A for ; Mon, 26 Oct 2009 02:41:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 61A8232317AE; Mon, 26 Oct 2009 02:41:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id B9E6132317B0; Mon, 26 Oct 2009 02:41:19 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56CB6.3090400@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:41:19 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <4AE56CB6.3090400@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:41:09 -0000 On Oct 26, 2009, at 10:32 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>> JP Vasseur a =E9crit : >>>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>>> >>>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> Please find below the new revision of the METRIC ID. As you =20 >>>>>>>> know we had to wait until RPL was stable enough to update =20 >>>>>>>> this document. This revision is thus a major update compared =20= >>>>>>>> to the previous one. >>>>>>>> >>>>>>>> Few important comments >>>>>>>> 1) This revision of course takes into account the discussion =20= >>>>>>>> that we had on the mailing list, >>>>>>>> 2) No metric is mandated. RPL implementation may use one or =20 >>>>>>>> several of these metrics and we made them generic enough to =20 >>>>>>>> be extensible. The use of the metrics will be dictated by the =20= >>>>>>>> OF. >>>>>>>> 3) IMPORTANT: there are many ways to use metrics. It could be =20= >>>>>>>> as simple as a cumulative hop counts or as complex as a =20 >>>>>>>> hierarchical constraint based approach with multi-metric =20 >>>>>>>> heuristics, both for nodes and links. We made the design =20 >>>>>>>> quite generic to support all cases. A RPL implementation may =20= >>>>>>>> be EXTREMELY simple and compliant to the document or more =20 >>>>>>>> complex to handle specific situations with less constrained =20 >>>>>>>> nodes. >>>>>>> >>>>>>> >>>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >>>>>>> >>>>>>> The Expected Transmission Count (ETX) metric is defined as 1 / =20= >>>>>>> (Df * >>>>>>> Dr) where Df is the measured probability that a packet is =20 >>>>>>> received by >>>>>>> the neighbor and Dr is the measured probability that the >>>>>>> acknowledgment packet is successfully received. >>>>>>> >>>>>>> I would change this to say >>>>>>> >>>>>>> The Expected Transmission Count (ETX) metric is the number of =20= >>>>>>> transmissions >>>>>>> a node expects to make to a destination in order to =20 >>>>>>> successfully deliver a >>>>>>> packet. >>>>>>> >>>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, =20 >>>>>>> but there are other algorithms for measuring it, such as 4B =20 >>>>>>> and EAR. >>>>>>> >>>>>> Absolutely. Makes sense. I added this one as an example (I'll =20 >>>>>> be more explicit about the fact that this *one* example). We =20 >>>>>> want to make it implementation specific since there are many =20 >>>>>> ways to compute it depending on the link layer and other =20 >>>>>> parameters. >>>>> >>>>> In defining ETX one would like to make sure that two different =20 >>>>> implementers implement the same way an ETX. >>>>> >>>> This is more of a deployment issue though. Look at OSPF/ISIS/..., =20= >>>> we do not mandate the use of a specific formula. >>> >>> However, the hopcount metric in OSPF is univerally understood: the =20= >>> number of IP hops in between, and this number is well understood. >>> >>> I am not sure what in OSPF/ISIS/... makes you think I should look =20= >>> at, to make me think it's like ETX - deployment issue? >> It's not really the point, Alex. Think of a graph with weights =20 >> (cost) on the edges. > > YEs, yes. > >> It doesn't matter if the weight is 1 or "something else", as long =20 >> as the weights are unambiguous. If the weight for a given edge is =20 >> established in *one* place only, everything works fine ;) > > That's a problem IMHO - the expected in ETX. As long as there's only one entity making the "expectation", =20 everything is fine. Thomas > > Alex > >> Thomas > > From alexandru.petrescu@gmail.com Mon Oct 26 02:41:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCB53A6945 for ; Mon, 26 Oct 2009 02:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrF0aA7EURta for ; Mon, 26 Oct 2009 02:41:14 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id AE8A13A6942 for ; Mon, 26 Oct 2009 02:41:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9Q9fN9w025962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:41:23 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9Q9fNwa008162; Mon, 26 Oct 2009 10:41:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9Q9fMnP028569; Mon, 26 Oct 2009 10:41:23 +0100 Message-ID: <4AE56EC2.4040308@gmail.com> Date: Mon, 26 Oct 2009 10:41:22 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <4AE56CB6.3090400@gmail.com> <558E48C2-B8E4-4020-8958-61A4A81148FA@thomasclausen.org> In-Reply-To: <558E48C2-B8E4-4020-8958-61A4A81148FA@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:41:15 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 10:32 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>>> JP Vasseur a écrit : >>>>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>>>> >>>>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> Please find below the new revision of the METRIC ID. As you >>>>>>>>> know we had to wait until RPL was stable enough to update this >>>>>>>>> document. This revision is thus a major update compared to the >>>>>>>>> previous one. >>>>>>>>> >>>>>>>>> Few important comments >>>>>>>>> 1) This revision of course takes into account the discussion >>>>>>>>> that we had on the mailing list, >>>>>>>>> 2) No metric is mandated. RPL implementation may use one or >>>>>>>>> several of these metrics and we made them generic enough to be >>>>>>>>> extensible. The use of the metrics will be dictated by the OF. >>>>>>>>> 3) IMPORTANT: there are many ways to use metrics. It could be >>>>>>>>> as simple as a cumulative hop counts or as complex as a >>>>>>>>> hierarchical constraint based approach with multi-metric >>>>>>>>> heuristics, both for nodes and links. We made the design quite >>>>>>>>> generic to support all cases. A RPL implementation may be >>>>>>>>> EXTREMELY simple and compliant to the document or more complex >>>>>>>>> to handle specific situations with less constrained nodes. >>>>>>>> >>>>>>>> >>>>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >>>>>>>> >>>>>>>> The Expected Transmission Count (ETX) metric is defined as 1 / >>>>>>>> (Df * >>>>>>>> Dr) where Df is the measured probability that a packet is >>>>>>>> received by >>>>>>>> the neighbor and Dr is the measured probability that the >>>>>>>> acknowledgment packet is successfully received. >>>>>>>> >>>>>>>> I would change this to say >>>>>>>> >>>>>>>> The Expected Transmission Count (ETX) metric is the number of >>>>>>>> transmissions >>>>>>>> a node expects to make to a destination in order to successfully >>>>>>>> deliver a >>>>>>>> packet. >>>>>>>> >>>>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, but >>>>>>>> there are other algorithms for measuring it, such as 4B and EAR. >>>>>>>> >>>>>>> Absolutely. Makes sense. I added this one as an example (I'll be >>>>>>> more explicit about the fact that this *one* example). We want to >>>>>>> make it implementation specific since there are many ways to >>>>>>> compute it depending on the link layer and other parameters. >>>>>> >>>>>> In defining ETX one would like to make sure that two different >>>>>> implementers implement the same way an ETX. >>>>>> >>>>> This is more of a deployment issue though. Look at OSPF/ISIS/..., >>>>> we do not mandate the use of a specific formula. >>>> >>>> However, the hopcount metric in OSPF is univerally understood: the >>>> number of IP hops in between, and this number is well understood. >>>> >>>> I am not sure what in OSPF/ISIS/... makes you think I should look >>>> at, to make me think it's like ETX - deployment issue? >>> It's not really the point, Alex. Think of a graph with weights (cost) >>> on the edges. >> >> YEs, yes. >> >>> It doesn't matter if the weight is 1 or "something else", as long as >>> the weights are unambiguous. If the weight for a given edge is >>> established in *one* place only, everything works fine ;) >> >> That's a problem IMHO - the expected in ETX. > > As long as there's only one entity making the "expectation", everything > is fine. WEll - there may be a risk that if my node expects 2 retransmissions and the receiving node expects me to try 3 times - we may have a problem in building a coherent ETX-aware path. Alex > > Thomas > >> >> Alex >> >>> Thomas >> >> > > From ietf@thomasclausen.org Mon Oct 26 02:41:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E79773A681D for ; Mon, 26 Oct 2009 02:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voZcUrLnDqT7 for ; Mon, 26 Oct 2009 02:41:54 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id D40F43A67AF for ; Mon, 26 Oct 2009 02:41:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 6C89132317AF; Mon, 26 Oct 2009 02:42:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 14F1032317AE; Mon, 26 Oct 2009 02:42:06 -0700 (PDT) Message-Id: <8672141F-0203-4D57-B4BF-0F09E5B167BA@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE56EC2.4040308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:42:06 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <4AE56CB6.3090400@gmail.com> <558E48C2-B8E4-4020-8958-61A4A81148FA@thomasclausen.org> <4AE56EC2.4040308@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:41:55 -0000 On Oct 26, 2009, at 10:41 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 10:32 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: >>>>> JP Vasseur a =E9crit : >>>>>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>>>> JP Vasseur a =E9crit : >>>>>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>>>>> >>>>>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>>>>> >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> Please find below the new revision of the METRIC ID. As you =20= >>>>>>>>>> know we had to wait until RPL was stable enough to update =20 >>>>>>>>>> this document. This revision is thus a major update =20 >>>>>>>>>> compared to the previous one. >>>>>>>>>> >>>>>>>>>> Few important comments >>>>>>>>>> 1) This revision of course takes into account the =20 >>>>>>>>>> discussion that we had on the mailing list, >>>>>>>>>> 2) No metric is mandated. RPL implementation may use one or =20= >>>>>>>>>> several of these metrics and we made them generic enough to =20= >>>>>>>>>> be extensible. The use of the metrics will be dictated by =20 >>>>>>>>>> the OF. >>>>>>>>>> 3) IMPORTANT: there are many ways to use metrics. It could =20= >>>>>>>>>> be as simple as a cumulative hop counts or as complex as a =20= >>>>>>>>>> hierarchical constraint based approach with multi-metric =20 >>>>>>>>>> heuristics, both for nodes and links. We made the design =20 >>>>>>>>>> quite generic to support all cases. A RPL implementation =20 >>>>>>>>>> may be EXTREMELY simple and compliant to the document or =20 >>>>>>>>>> more complex to handle specific situations with less =20 >>>>>>>>>> constrained nodes. >>>>>>>>> >>>>>>>>> >>>>>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability =20 >>>>>>>>> Object >>>>>>>>> >>>>>>>>> The Expected Transmission Count (ETX) metric is defined as =20 >>>>>>>>> 1 / (Df * >>>>>>>>> Dr) where Df is the measured probability that a packet is =20 >>>>>>>>> received by >>>>>>>>> the neighbor and Dr is the measured probability that the >>>>>>>>> acknowledgment packet is successfully received. >>>>>>>>> >>>>>>>>> I would change this to say >>>>>>>>> >>>>>>>>> The Expected Transmission Count (ETX) metric is the number =20 >>>>>>>>> of transmissions >>>>>>>>> a node expects to make to a destination in order to =20 >>>>>>>>> successfully deliver a >>>>>>>>> packet. >>>>>>>>> >>>>>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, =20= >>>>>>>>> but there are other algorithms for measuring it, such as 4B =20= >>>>>>>>> and EAR. >>>>>>>>> >>>>>>>> Absolutely. Makes sense. I added this one as an example (I'll =20= >>>>>>>> be more explicit about the fact that this *one* example). We =20= >>>>>>>> want to make it implementation specific since there are many =20= >>>>>>>> ways to compute it depending on the link layer and other =20 >>>>>>>> parameters. >>>>>>> >>>>>>> In defining ETX one would like to make sure that two different =20= >>>>>>> implementers implement the same way an ETX. >>>>>>> >>>>>> This is more of a deployment issue though. Look at OSPF/=20 >>>>>> ISIS/..., we do not mandate the use of a specific formula. >>>>> >>>>> However, the hopcount metric in OSPF is univerally understood: =20 >>>>> the number of IP hops in between, and this number is well =20 >>>>> understood. >>>>> >>>>> I am not sure what in OSPF/ISIS/... makes you think I should =20 >>>>> look at, to make me think it's like ETX - deployment issue? >>>> It's not really the point, Alex. Think of a graph with weights =20 >>>> (cost) on the edges. >>> >>> YEs, yes. >>> >>>> It doesn't matter if the weight is 1 or "something else", as long =20= >>>> as the weights are unambiguous. If the weight for a given edge is =20= >>>> established in *one* place only, everything works fine ;) >>> >>> That's a problem IMHO - the expected in ETX. >> As long as there's only one entity making the "expectation", =20 >> everything is fine. > > WEll - there may be a risk that if my node expects 2 retransmissions =20= > and the receiving node expects me to try 3 times - we may have a =20 > problem in building a coherent ETX-aware path. Why? Thomas > > Alex > >> Thomas >>> >>> Alex >>> >>>> Thomas >>> >>> > > From jvasseur@cisco.com Mon Oct 26 02:45:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654B33A6841 for ; Mon, 26 Oct 2009 02:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.817 X-Spam-Level: X-Spam-Status: No, score=-7.817 tagged_above=-999 required=5 tests=[AWL=-1.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JP0WRxGN4bN for ; Mon, 26 Oct 2009 02:44:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 70F173A6801 for ; Mon, 26 Oct 2009 02:44:59 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPMM5UqrR7Hu/2dsb2JhbADAD4kgCI08gk4IgWkE X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="217759405" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2009 09:45:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9Q9j6hV009890; Mon, 26 Oct 2009 09:45:12 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:45:10 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:45:09 +0100 Message-Id: <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AE56C0B.70005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:45:08 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 09:45:10.0281 (UTC) FILETIME=[021C7790:01CA5621] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16970.006 X-TM-AS-Result: No--18.617000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:45:00 -0000 On Oct 26, 2009, at 10:29 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>> JP Vasseur a =E9crit : >>>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>>>> Dear all, >>>>>>>> Please find below the new revision of the METRIC ID. As >>>>>>>> you know we had to wait until RPL was stable enough to >>>>>>>> update this document. This revision is thus a major >>>>>>>> update compared to the previous one. >>>>>>>> Few important comments 1) This revision of course takes >>>>>>>> into account the discussion that we had on the mailing >>>>>>>> list, 2) No metric is mandated. RPL implementation may >>>>>>>> use one or several of these metrics and we made them >>>>>>>> generic enough to be extensible. The use of the metrics >>>>>>>> will be dictated by the OF. 3) IMPORTANT: there are many >>>>>>>> ways to use metrics. It could be as simple as a >>>>>>>> cumulative hop counts or as complex as a hierarchical =20 >>>>>>>> constraint based approach with multi-metric heuristics, >>>>>>>> both for nodes and links. We made the design quite >>>>>>>> generic to support all cases. A RPL implementation may be >>>>>>>> EXTREMELY simple and compliant to the document or more >>>>>>>> complex to handle specific situations with less >>>>>>>> constrained nodes. >>>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability >>>>>>> Object >>>>>>> The Expected Transmission Count (ETX) metric is defined as >>>>>>> 1 / (Df * Dr) where Df is the measured probability that a >>>>>>> packet is received by the neighbor and Dr is the measured >>>>>>> probability that the acknowledgment packet is successfully >>>>>>> received. >>>>>>> I would change this to say >>>>>>> The Expected Transmission Count (ETX) metric is the number >>>>>>> of transmissions a node expects to make to a destination in >>>>>>> order to successfully deliver a packet. >>>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, >>>>>>> but there are other algorithms for measuring it, such as 4B >>>>>>> and EAR. >>>>>> Absolutely. Makes sense. I added this one as an example (I'll >>>>>> be more explicit about the fact that this *one* example). We >>>>>> want to make it implementation specific since there are many >>>>>> ways to compute it depending on the link layer and other >>>>>> parameters. >>>>> In defining ETX one would like to make sure that two different >>>>> implementers implement the same way an ETX. >>>> This is more of a deployment issue though. Look at OSPF/ISIS/..., >>>> we do not mandate the use of a specific formula. >>> However, the hopcount metric in OSPF is univerally understood: the >>> number of IP hops in between, and this number is well understood. >>> I am not sure what in OSPF/ISIS/... makes you think I should look >>> at, to make me think it's like ETX - deployment issue? >> OSPF and ISIS do not use hop count but a static undefined link >> metric. > > Ah! There may be a misunderstanding. > > I counted on this OSPF text: "The next hop calculation is invoked each > time a shorter path to the destination is discovered." > > "Shorter" is in terms of IP hop count. Just to close on this ... No, OSPF does not use IP Hop Count but a =20 link metric ... Same for ISIS and many others. > > Let me see later, thanks. > Sure. JP. > Alex > From alexandru.petrescu@gmail.com Mon Oct 26 02:51:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FF728C103 for ; Mon, 26 Oct 2009 02:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GLGxOY6odN3 for ; Mon, 26 Oct 2009 02:51:52 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 38CDF3A6A49 for ; Mon, 26 Oct 2009 02:51:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9Q9pkpA003416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 10:51:46 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9Q9pke9012616; Mon, 26 Oct 2009 10:51:46 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9Q9pjNS004398; Mon, 26 Oct 2009 10:51:46 +0100 Message-ID: <4AE57131.3050107@gmail.com> Date: Mon, 26 Oct 2009 10:51:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> In-Reply-To: <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:51:53 -0000 JP Vasseur a écrit : > > On Oct 26, 2009, at 10:29 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>>> JP Vasseur a écrit : >>>>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>>>>> Dear all, >>>>>>>>> Please find below the new revision of the METRIC ID. As >>>>>>>>> you know we had to wait until RPL was stable enough to >>>>>>>>> update this document. This revision is thus a major >>>>>>>>> update compared to the previous one. >>>>>>>>> Few important comments 1) This revision of course takes >>>>>>>>> into account the discussion that we had on the mailing >>>>>>>>> list, 2) No metric is mandated. RPL implementation may >>>>>>>>> use one or several of these metrics and we made them >>>>>>>>> generic enough to be extensible. The use of the metrics >>>>>>>>> will be dictated by the OF. 3) IMPORTANT: there are many >>>>>>>>> ways to use metrics. It could be as simple as a >>>>>>>>> cumulative hop counts or as complex as a hierarchical >>>>>>>>> constraint based approach with multi-metric heuristics, >>>>>>>>> both for nodes and links. We made the design quite >>>>>>>>> generic to support all cases. A RPL implementation may be >>>>>>>>> EXTREMELY simple and compliant to the document or more >>>>>>>>> complex to handle specific situations with less >>>>>>>>> constrained nodes. >>>>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability >>>>>>>> Object >>>>>>>> The Expected Transmission Count (ETX) metric is defined as >>>>>>>> 1 / (Df * Dr) where Df is the measured probability that a >>>>>>>> packet is received by the neighbor and Dr is the measured >>>>>>>> probability that the acknowledgment packet is successfully >>>>>>>> received. >>>>>>>> I would change this to say >>>>>>>> The Expected Transmission Count (ETX) metric is the number >>>>>>>> of transmissions a node expects to make to a destination in >>>>>>>> order to successfully deliver a packet. >>>>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, >>>>>>>> but there are other algorithms for measuring it, such as 4B >>>>>>>> and EAR. >>>>>>> Absolutely. Makes sense. I added this one as an example (I'll >>>>>>> be more explicit about the fact that this *one* example). We >>>>>>> want to make it implementation specific since there are many >>>>>>> ways to compute it depending on the link layer and other >>>>>>> parameters. >>>>>> In defining ETX one would like to make sure that two different >>>>>> implementers implement the same way an ETX. >>>>> This is more of a deployment issue though. Look at OSPF/ISIS/..., >>>>> we do not mandate the use of a specific formula. >>>> However, the hopcount metric in OSPF is univerally understood: the >>>> number of IP hops in between, and this number is well understood. >>>> I am not sure what in OSPF/ISIS/... makes you think I should look >>>> at, to make me think it's like ETX - deployment issue? >>> OSPF and ISIS do not use hop count but a static undefined link >>> metric. >> >> Ah! There may be a misunderstanding. >> >> I counted on this OSPF text: "The next hop calculation is invoked each >> time a shorter path to the destination is discovered." >> >> "Shorter" is in terms of IP hop count. > > Just to close on this ... No, OSPF does not use IP Hop Count but a link > metric ... > Same for ISIS and many others. JP - before closing it too quickly, for my clarification - what does that "shorter path" mean in your interpretation? Does that "shorter path" in OSPF mean it has some smaller link qualities (like smaller latencies)? Thanks, Alex > >> >> Let me see later, thanks. >> > > Sure. > > JP. > >> Alex >> > > From jvasseur@cisco.com Mon Oct 26 02:54:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7EE3A6A49 for ; Mon, 26 Oct 2009 02:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.776 X-Spam-Level: X-Spam-Status: No, score=-9.776 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1w5BkV0flXH for ; Mon, 26 Oct 2009 02:54:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 388473A67EC for ; Mon, 26 Oct 2009 02:54:51 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAEoP5UqQ/uCWe2dsb2JhbACbNgEBFiQGpESWZIQ/BA X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="52757871" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 09:55:02 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9Q9t1eB019049; Mon, 26 Oct 2009 09:55:01 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:55:01 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:55:00 +0100 Message-Id: <635A7A91-1E92-4C86-A7DC-0DD572950AB2@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AE57131.3050107@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:54:59 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> <4AE57131.3050107@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 09:55:00.0503 (UTC) FILETIME=[61E93270:01CA5622] Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:54:52 -0000 >>> [snip] >>> >>> I counted on this OSPF text: "The next hop calculation is invoked >>> each >>> time a shorter path to the destination is discovered." >>> >>> "Shorter" is in terms of IP hop count. >> Just to close on this ... No, OSPF does not use IP Hop Count but a >> link metric ... >> Same for ISIS and many others. > > JP - before closing it too quickly, for my clarification - what does > that "shorter path" mean in your interpretation? > This is not my interpretation ;-) but how OSPF/ISIS/... work. The shortest path is the one with the lowest path cost (computed using SPF) where the cost = sum of link metric, the link metric being defined by the network administrator. It may reflect the bw, latency or whatever you want. Some SP use a polynomial function of bw, latency, ... > Does that "shorter path" in OSPF mean it has some smaller link > qualities (like smaller latencies)? > > Thanks, > > Alex > >>> >>> Let me see later, thanks. >>> >> Sure. >> JP. >>> Alex >>> > > From ietf@thomasclausen.org Mon Oct 26 02:55:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5133A687B for ; Mon, 26 Oct 2009 02:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4k3d7qWgANJ for ; Mon, 26 Oct 2009 02:55:35 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 214A53A67EC for ; Mon, 26 Oct 2009 02:55:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id AD54732317AE; Mon, 26 Oct 2009 02:55:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 3B5A532317AD; Mon, 26 Oct 2009 02:55:47 -0700 (PDT) Message-Id: <2CA0FF7D-527D-4D3F-864D-DCD255CF3844@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE57131.3050107@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 10:55:44 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> <4AE57131.3050107@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 09:55:36 -0000 On Oct 26, 2009, at 10:51 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >> On Oct 26, 2009, at 10:29 AM, Alexandru Petrescu wrote: >>> JP Vasseur a =E9crit : >>>> On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: >>>>> JP Vasseur a =E9crit : >>>>>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>>>> JP Vasseur a =E9crit : >>>>>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>>>>>> Dear all, >>>>>>>>>> Please find below the new revision of the METRIC ID. As >>>>>>>>>> you know we had to wait until RPL was stable enough to >>>>>>>>>> update this document. This revision is thus a major >>>>>>>>>> update compared to the previous one. >>>>>>>>>> Few important comments 1) This revision of course takes >>>>>>>>>> into account the discussion that we had on the mailing >>>>>>>>>> list, 2) No metric is mandated. RPL implementation may >>>>>>>>>> use one or several of these metrics and we made them >>>>>>>>>> generic enough to be extensible. The use of the metrics >>>>>>>>>> will be dictated by the OF. 3) IMPORTANT: there are many >>>>>>>>>> ways to use metrics. It could be as simple as a >>>>>>>>>> cumulative hop counts or as complex as a hierarchical =20 >>>>>>>>>> constraint based approach with multi-metric heuristics, >>>>>>>>>> both for nodes and links. We made the design quite >>>>>>>>>> generic to support all cases. A RPL implementation may be >>>>>>>>>> EXTREMELY simple and compliant to the document or more >>>>>>>>>> complex to handle specific situations with less >>>>>>>>>> constrained nodes. >>>>>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability >>>>>>>>> Object >>>>>>>>> The Expected Transmission Count (ETX) metric is defined as >>>>>>>>> 1 / (Df * Dr) where Df is the measured probability that a >>>>>>>>> packet is received by the neighbor and Dr is the measured >>>>>>>>> probability that the acknowledgment packet is successfully >>>>>>>>> received. >>>>>>>>> I would change this to say >>>>>>>>> The Expected Transmission Count (ETX) metric is the number >>>>>>>>> of transmissions a node expects to make to a destination in >>>>>>>>> order to successfully deliver a packet. >>>>>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, >>>>>>>>> but there are other algorithms for measuring it, such as 4B >>>>>>>>> and EAR. >>>>>>>> Absolutely. Makes sense. I added this one as an example (I'll >>>>>>>> be more explicit about the fact that this *one* example). We >>>>>>>> want to make it implementation specific since there are many >>>>>>>> ways to compute it depending on the link layer and other >>>>>>>> parameters. >>>>>>> In defining ETX one would like to make sure that two different >>>>>>> implementers implement the same way an ETX. >>>>>> This is more of a deployment issue though. Look at OSPF/ISIS/..., >>>>>> we do not mandate the use of a specific formula. >>>>> However, the hopcount metric in OSPF is univerally understood: the >>>>> number of IP hops in between, and this number is well understood. >>>>> I am not sure what in OSPF/ISIS/... makes you think I should look >>>>> at, to make me think it's like ETX - deployment issue? >>>> OSPF and ISIS do not use hop count but a static undefined link >>>> metric. >>> >>> Ah! There may be a misunderstanding. >>> >>> I counted on this OSPF text: "The next hop calculation is invoked =20= >>> each >>> time a shorter path to the destination is discovered." >>> >>> "Shorter" is in terms of IP hop count. >> Just to close on this ... No, OSPF does not use IP Hop Count but a =20= >> link metric ... >> Same for ISIS and many others. > > JP - before closing it too quickly, for my clarification - what does =20= > that "shorter path" mean in your interpretation? > > Does that "shorter path" in OSPF mean it has some smaller link =20 > qualities (like smaller latencies)? > Would it be clearer to you if we say "least cost paths" instead? Thomas > Thanks, > > Alex > >>> >>> Let me see later, thanks. >>> >> Sure. >> JP. >>> Alex >>> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Mon Oct 26 03:22:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF083A687C for ; Mon, 26 Oct 2009 03:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab4fifyL0pZe for ; Mon, 26 Oct 2009 03:22:52 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id D76563A6837 for ; Mon, 26 Oct 2009 03:22:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9QAMui5014323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 11:22:56 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9QAMtle024029; Mon, 26 Oct 2009 11:22:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9QAMtZS018130; Mon, 26 Oct 2009 11:22:55 +0100 Message-ID: <4AE5787E.5050608@gmail.com> Date: Mon, 26 Oct 2009 11:22:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: JP Vasseur References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> <4AE57131.3050107@gmail.com> <635A7A91-1E92-4C86-A7DC-0DD572950AB2@cisco.com> In-Reply-To: <635A7A91-1E92-4C86-A7DC-0DD572950AB2@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 10:22:52 -0000 JP Vasseur a écrit : >>>> [snip] > >>>> >>>> I counted on this OSPF text: "The next hop calculation is invoked each >>>> time a shorter path to the destination is discovered." >>>> >>>> "Shorter" is in terms of IP hop count. >>> Just to close on this ... No, OSPF does not use IP Hop Count but a >>> link metric ... >>> Same for ISIS and many others. >> >> JP - before closing it too quickly, for my clarification - what does >> that "shorter path" mean in your interpretation? >> > > This is not my interpretation ;-) but how OSPF/ISIS/... work. The > shortest path is the one with the lowest path > cost (computed using SPF) where the cost = sum of link metric, the link > metric being defined by the network > administrator. It may reflect the bw, latency or whatever you want. Some > SP use a polynomial function of > bw, latency, ... JP - I begin to understand what you mean. I however am interested in the parts of OSPF (and RPL) which try to avoid loops and offer shortest paths in terms of IP number of hops. For ETX - I will come to it later. (thanks for the cost explanation) Alex From ietf@thomasclausen.org Mon Oct 26 03:24:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C443A687C for ; Mon, 26 Oct 2009 03:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXlPA4qBJDgZ for ; Mon, 26 Oct 2009 03:24:40 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id BCEFE3A6774 for ; Mon, 26 Oct 2009 03:24:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 5CC1732317AD; Mon, 26 Oct 2009 03:24:54 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 4680D32317AE; Mon, 26 Oct 2009 03:24:53 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5787E.5050608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 11:24:50 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> <4AE57131.3050107@gmail.com> <635A7A91-1E92-4C86-A7DC-0DD572950AB2@cisco.com> <4AE5787E.5050608@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 10:24:41 -0000 On Oct 26, 2009, at 11:22 AM, Alexandru Petrescu wrote: > JP Vasseur a =E9crit : >>>>> [snip] >>>>> >>>>> I counted on this OSPF text: "The next hop calculation is =20 >>>>> invoked each >>>>> time a shorter path to the destination is discovered." >>>>> >>>>> "Shorter" is in terms of IP hop count. >>>> Just to close on this ... No, OSPF does not use IP Hop Count but =20= >>>> a link metric ... >>>> Same for ISIS and many others. >>> >>> JP - before closing it too quickly, for my clarification - what =20 >>> does that "shorter path" mean in your interpretation? >>> >> This is not my interpretation ;-) but how OSPF/ISIS/... work. The =20 >> shortest path is the one with the lowest path >> cost (computed using SPF) where the cost =3D sum of link metric, the =20= >> link metric being defined by the network >> administrator. It may reflect the bw, latency or whatever you want. =20= >> Some SP use a polynomial function of >> bw, latency, ... > > JP - I begin to understand what you mean. > > I however am interested in the parts of OSPF (and RPL) which try to =20= > avoid loops and offer shortest paths in terms of IP number of hops. > > For ETX - I will come to it later. > > (thanks for the cost explanation) > As a complement to the discussion on the list, may I recommend: = http://openlibrary.org/b/OL20956283M/Applied_and_algorithmic_graph_theory Thomas > Alex > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Mon Oct 26 03:27:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0823A6893 for ; Mon, 26 Oct 2009 03:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpKriIeh-d7i for ; Mon, 26 Oct 2009 03:27:07 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 3C0C23A687C for ; Mon, 26 Oct 2009 03:27:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9QARGZC032411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 11:27:16 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9QARF8A025426; Mon, 26 Oct 2009 11:27:16 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9QARF1c019796; Mon, 26 Oct 2009 11:27:15 +0100 Message-ID: <4AE57983.7060305@gmail.com> Date: Mon, 26 Oct 2009 11:27:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> <4AE57131.3050107@gmail.com> <2CA0FF7D-527D-4D3F-864D-DCD255CF3844@thomasclausen.org> In-Reply-To: <2CA0FF7D-527D-4D3F-864D-DCD255CF3844@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 10:27:11 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 10:51 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>> On Oct 26, 2009, at 10:29 AM, Alexandru Petrescu wrote: >>>> JP Vasseur a écrit : >>>>> On Oct 26, 2009, at 10:14 AM, Alexandru Petrescu wrote: >>>>>> JP Vasseur a écrit : >>>>>>> On Oct 26, 2009, at 9:54 AM, Alexandru Petrescu wrote: >>>>>>>> JP Vasseur a écrit : >>>>>>>>> On Oct 25, 2009, at 2:20 AM, Philip Levis wrote: >>>>>>>>>> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >>>>>>>>>>> Dear all, >>>>>>>>>>> Please find below the new revision of the METRIC ID. As >>>>>>>>>>> you know we had to wait until RPL was stable enough to >>>>>>>>>>> update this document. This revision is thus a major >>>>>>>>>>> update compared to the previous one. >>>>>>>>>>> Few important comments 1) This revision of course takes >>>>>>>>>>> into account the discussion that we had on the mailing >>>>>>>>>>> list, 2) No metric is mandated. RPL implementation may >>>>>>>>>>> use one or several of these metrics and we made them >>>>>>>>>>> generic enough to be extensible. The use of the metrics >>>>>>>>>>> will be dictated by the OF. 3) IMPORTANT: there are many >>>>>>>>>>> ways to use metrics. It could be as simple as a >>>>>>>>>>> cumulative hop counts or as complex as a hierarchical >>>>>>>>>>> constraint based approach with multi-metric heuristics, >>>>>>>>>>> both for nodes and links. We made the design quite >>>>>>>>>>> generic to support all cases. A RPL implementation may be >>>>>>>>>>> EXTREMELY simple and compliant to the document or more >>>>>>>>>>> complex to handle specific situations with less >>>>>>>>>>> constrained nodes. >>>>>>>>>> 4.3.2. The Expected Transmission Count (ETX) Reliability >>>>>>>>>> Object >>>>>>>>>> The Expected Transmission Count (ETX) metric is defined as >>>>>>>>>> 1 / (Df * Dr) where Df is the measured probability that a >>>>>>>>>> packet is received by the neighbor and Dr is the measured >>>>>>>>>> probability that the acknowledgment packet is successfully >>>>>>>>>> received. >>>>>>>>>> I would change this to say >>>>>>>>>> The Expected Transmission Count (ETX) metric is the number >>>>>>>>>> of transmissions a node expects to make to a destination in >>>>>>>>>> order to successfully deliver a packet. >>>>>>>>>> The approach of 1 / (Df * Dr) is the approach used by Srcr, >>>>>>>>>> but there are other algorithms for measuring it, such as 4B >>>>>>>>>> and EAR. >>>>>>>>> Absolutely. Makes sense. I added this one as an example (I'll >>>>>>>>> be more explicit about the fact that this *one* example). We >>>>>>>>> want to make it implementation specific since there are many >>>>>>>>> ways to compute it depending on the link layer and other >>>>>>>>> parameters. >>>>>>>> In defining ETX one would like to make sure that two different >>>>>>>> implementers implement the same way an ETX. >>>>>>> This is more of a deployment issue though. Look at OSPF/ISIS/..., >>>>>>> we do not mandate the use of a specific formula. >>>>>> However, the hopcount metric in OSPF is univerally understood: the >>>>>> number of IP hops in between, and this number is well understood. >>>>>> I am not sure what in OSPF/ISIS/... makes you think I should look >>>>>> at, to make me think it's like ETX - deployment issue? >>>>> OSPF and ISIS do not use hop count but a static undefined link >>>>> metric. >>>> >>>> Ah! There may be a misunderstanding. >>>> >>>> I counted on this OSPF text: "The next hop calculation is invoked each >>>> time a shorter path to the destination is discovered." >>>> >>>> "Shorter" is in terms of IP hop count. >>> Just to close on this ... No, OSPF does not use IP Hop Count but a >>> link metric ... >>> Same for ISIS and many others. >> >> JP - before closing it too quickly, for my clarification - what does >> that "shorter path" mean in your interpretation? >> >> Does that "shorter path" in OSPF mean it has some smaller link >> qualities (like smaller latencies)? >> > > Would it be clearer to you if we say "least cost paths" instead? Well yes. In OSPF we can't say so anylonger. "Least cost paths" used throughout is clearer from what you say. One should be sure when using them coherently. There are risks. Check this in the metrics draft: "the path quality, also referred to as the path cost" I prefer high quality and low cost - as such the path quality and the path cost are contradictory; so one can't refer to the path quality as the path cost - they're completely inverse. Alex > > Thomas > >> Thanks, >> >> Alex >> >>>> >>>> Let me see later, thanks. >>>> >>> Sure. >>> JP. >>>> Alex >>>> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Mon Oct 26 03:28:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2173A6893 for ; Mon, 26 Oct 2009 03:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsbGnbB2Bp1E for ; Mon, 26 Oct 2009 03:28:46 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 04C053A68F6 for ; Mon, 26 Oct 2009 03:28:45 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9QASstN009712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 11:28:54 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9QASswi025958; Mon, 26 Oct 2009 11:28:54 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9QASrAm020425; Mon, 26 Oct 2009 11:28:54 +0100 Message-ID: <4AE579E5.4060702@gmail.com> Date: Mon, 26 Oct 2009 11:28:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <4AE56C0B.70005@gmail.com> <06746322-3ED9-4659-B1E3-1C0150FC3A47@cisco.com> <4AE57131.3050107@gmail.com> <635A7A91-1E92-4C86-A7DC-0DD572950AB2@cisco.com> <4AE5787E.5050608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 10:28:47 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 11:22 AM, Alexandru Petrescu wrote: > >> JP Vasseur a écrit : >>>>>> [snip] >>>>>> >>>>>> I counted on this OSPF text: "The next hop calculation is invoked >>>>>> each >>>>>> time a shorter path to the destination is discovered." >>>>>> >>>>>> "Shorter" is in terms of IP hop count. >>>>> Just to close on this ... No, OSPF does not use IP Hop Count but a >>>>> link metric ... >>>>> Same for ISIS and many others. >>>> >>>> JP - before closing it too quickly, for my clarification - what does >>>> that "shorter path" mean in your interpretation? >>>> >>> This is not my interpretation ;-) but how OSPF/ISIS/... work. The >>> shortest path is the one with the lowest path >>> cost (computed using SPF) where the cost = sum of link metric, the >>> link metric being defined by the network >>> administrator. It may reflect the bw, latency or whatever you want. >>> Some SP use a polynomial function of >>> bw, latency, ... >> >> JP - I begin to understand what you mean. >> >> I however am interested in the parts of OSPF (and RPL) which try to >> avoid loops and offer shortest paths in terms of IP number of hops. >> >> For ETX - I will come to it later. >> >> (thanks for the cost explanation) >> > > As a complement to the discussion on the list, may I recommend: > > http://openlibrary.org/b/OL20956283M/Applied_and_algorithmic_graph_theory SOrry the book is not clickable. ARe you kind of like trying to tell me to go back read some basics? Alex > > > Thomas > >> Alex >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From mdurvy@cisco.com Mon Oct 26 03:45:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BD828C234 for ; Mon, 26 Oct 2009 03:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[AWL=-2.177, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvNFMGgI42NT for ; Mon, 26 Oct 2009 03:45:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2840E28C231 for ; Mon, 26 Oct 2009 03:45:07 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAIb5UqrR7Ht/2dsb2JhbADAOokgCI06gk4IgWkE X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="261339809" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2009 10:45:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QAiqoZ011288; Mon, 26 Oct 2009 10:45:20 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 11:45:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 11:45:17 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE92F3A4@XMB-AMS-103.cisco.com> In-Reply-To: <4AE1E8E3.5000900@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Design Questions Thread-Index: AcpUBvfmV/kQXBUlRx+woWJpcItu1ACHeMvQ References: <4AD3F102.8010601@acm.org> <4AE1E8E3.5000900@acm.org> From: "Mathilde Durvy (mdurvy)" To: "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 26 Oct 2009 10:45:19.0249 (UTC) FILETIME=[69394810:01CA5629] Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 10:45:09 -0000 Hi Tim, All, I support the proposals made in your email. I think they are a key step in reducing the complexity of RPL. Some comments on the "Example: Global Repair with Sequence Number / No Held-Up State" as it is directly related to what the design team proposes. > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. At this > point Node (C) is not associated with any DAG [TBD -- Alternately > Node (C) remains associated with the DAG at rank infinity]. [Mathilde] Why couldn't Node (C) become the root of its own floating DAG? I don't think it adds in complexity and it would allow Node (C) sub-dag to remain connected providing some 'local' connectivity. In general I don't like the idea of maintaining nodes in an unassociated state for a potentially unbounded time period. > o Node (C) and (D) will now be willing to reattach to the original > DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering > connectivity to the original DAG and advertising a sequence number > N+1. Since Node (C) and (D) are no longer members of the original > DAG, only a node who is still a member of the original DAG may > possibly present the sequence number N+1. Such a node who > presents N+1 must clearly have another path to the DAG root other > than via (C) and (D) and thus may offer a loop-avoiding attachment > point. [Mathilde] This approach is safe but it means that the node needs to remember the initial DAG id and sequence number, i.e. keep some states about a DAG it is not part of anymore. What happens if the node joins other DAGs before going back to the original one? Does it mean you have to remember all DAGs you ever joined... Maybe an alternative would be to mandate that the DAG root increments the sequence number periodically and consider it safe to join a new DAG after waiting for (a multiple of) this period. This allows to keep less state but is probably not quite as safe. Best, Mathilde -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: vendredi, 23. octobre 2009 19:33 To: ROLL WG Subject: Re: [Roll] RPL Design Questions WG, We are working towards the -04 revision, and in consideration of WG feedback on these questions have also taken into account the following: - The WG has given a clear mandate to reduce complexity - Many of these features are related to optimizations, but do not appear strictly required to operate the core protocol The mandate to reduce complexity is very clear, the feedback on the list in support of these features is less so. Therefore we do propose to take the following approach proceeding into -04: - Recommendations for DAG Splitting and Merging (Detach/Form transient floating DAG/Reattach) will be removed (loss of connectivity/sub-DAG poisoning may effectively occur by advertising rank of infinity) - Hold-Up Timer and related states/procedures will be removed - Hold-Down Timer and related states/procedures will be removed It is the objective that by removing these protocol features we are able to let the basic mechanisms of the core protocol be clear without additional complexity. We do not wish to introduce complexity by including perceived optimizations, but also realize that as the WG effort proceeds we may find it necessary to reintroduce some part of these features in some form. But for now they do not seem strictly necessary, and it is the hope that by keeping them back the WG may focus more on the core protocol. Please let us know your comments/feedback- what do you think? Thanks, -RPL Authors Tim Winter wrote: > WG, >=20 > Please do let us know what you are thinking w/ regard to the design=20 > Questions A, B, & C below. We hope to include your feedback into the=20 > next revision of the document, with FSM descriptions as well. >=20 > Thanks, >=20 > - RPL Authors >=20 >=20 >=20 > As discussed at the interim meeting, implementer feedback has > indicated that the RPL protocol as proposed appears complex, both in > description and actual FSM. >=20 > Our plan of action is to, by end of month, deliver a -04 that will > contain actual (non-editorial) changes. The intent of this mail is > a poll over a period of 2 weeks, to help design the functional > changes. >=20 > In this spirit, we would like the WG to work on the following > questions: >=20 > Question A: Should RPL make use of the currently proposed local > repair mechanism (DAG splitting and merging)? >=20 > [NO implies that DAG repairs shall be coordinated globally with > the use of DAG Sequence Number; the related mechanisms are to > be expanded for -04] >=20 > Question B: Should RPL make use of a hold-up timer and related > states/procedures to reduce churn by coordinating the DAG merge? >=20 > [NO implies RPL allows nodes to move (jump) between DAGs with > little coordination to reduce complexity of specification/ > implementation (perhaps w/ Optional hold-up mechanism)]. >=20 > Question C: Should RPL make use of a hold-down timer and related > states/procedures to limit flapping when removing DAG Parents / > leaving DAGs >=20 > [NO implies RPL allows nodes to freely remove/add DAG Parents > as and when they are able in order to reduce complexity of > specification/implementation (perhaps w/ Optional hold-down > mechanism). >=20 > WG, we expect that this thread will contain a lot of interesting > related discussion, but in your comments please do also be sure to > try and address the initial questions A, B, and C so as to help us > better capture the WG position on these issues. Please note that A, > B, and C are to some degree orthogonal, e.g. `No Local Repair' to > Question A does not necessarily imply a particular disposition toward > the Hold-Up mechanism in Question B. >=20 > Thanks, >=20 > RPL Authors >=20 >=20 >=20 > Some examples, derived from the present draft, are provided below: >=20 > =20 > ---------------------------------------------------------------------- > -- >=20 > Example: Local Repair with Hold-Up state >=20 >=20 > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | | \ > | | `-----. > | | \ > (D) (D) (C) > | > | > | > (D) >=20 > -1- -2- -3- >=20 >=20 > Figure 1: DAG Maintenance >=20 > Consider the example depicted in Figure 1-1. In this example, Node > (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of > Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is > also an undirected sibling link between Nodes (B) and (C). >=20 > In this example, Node (C) may safely forward to Node (A) without > creating a loop. Node (C) may not safely forward to Node (D), > contained within it's own sub-DAG, without creating a loop. Node (C) > may forward to Node (B) in some cases, e.g. the link (C)->(A) is > temporarily unavailable, but with some chance of creating a loop > (e.g. if multiple nodes in a set of siblings start forwarding > `sideways' in a cycle) and requiring the intervention of additional > mechanisms to detect and break the loop. >=20 > Consider the case where Node (C) hears a RA-DIO message from a Node > (Z) at a lesser rank and superior position in the DAG than node (A). > Node (C) may safely undergo the process to evict node (A) from its > DAG parent set and attach directly to Node (Z) without creating a > loop, because its rank will decrease. >=20 > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: >=20 > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. Node (C) > becomes the root of its own floating, less preferred, DAG. >=20 > o Node (D), hearing a modified RA-DIO message from Node (C), follows > Node (C) into the floating DAG. This is depicted in Figure 1-2. > In general, any node with no other options in the sub-DAG of Node > (C) will follow Node (C) into the floating DAG, maintaining the > structure of the sub-DAG. >=20 > o Node (C) hears a RA-DIO message from Node (B) and determines it is > able to rejoin the grounded DAG by reattaching at a deeper rank to > Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in > the Hold-Up state) to coordinate this move. >=20 > o The timer expires and Node (C) adds Node (B) to its DAG parent > set. Node (C) has now safely moved deeper within the grounded DAG > without creating any loops. Node (D), and any other sub-DAG of > Node (C), will hear the modified RA-DIO message sourced from Node > (C) and follow Node (C) in a coordinated manner to reattach to the > grounded DAG. The final DAG is depicted in Figure 1-3 >=20 >=20 > =20 > ---------------------------------------------------------------------- > -- >=20 > Example: Global Repair with Sequence Number / No Held-Up State >=20 >=20 > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | \ > | `-----. > | \ > (D) (D) (C) >=20 >=20 >=20 > (D) >=20 > -1- -2- -3- >=20 >=20 > Figure 2: DAG Maintenance >=20 > Consider the example depicted in Figure 2-1, similar to that depicted > in Figure 1. Let there be a sequence number associated with the DAG, > as originated from the DAG root, with value N. Initially all nodes > have received DAG Sequence Number N. The following example offers one > possible Global Repair scenario to give a high level idea, please > note that there are details that would remain to be worked out if the > WG heads in this direction. >=20 > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: >=20 > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. At this > point Node (C) is not associated with any DAG [TBD -- Alternately > Node (C) remains associated with the DAG at rank infinity]. >=20 > o Node (D) may possibly learn that Node (C) is no longer associated > with any DAG and itself becomes unassociated [TBD Node (D) may > also retain a sub-DAG relationship with Node (C)]. Let Node (C) > and (D) both be free from any DAG, but remember the Sequence > Number N associated with their original DAG. This is depicted in > Figure 2-2. >=20 > o Node (C) and (D) will now be willing to reattach to the original > DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering > connectivity to the original DAG and advertising a sequence number > N+1. Since Node (C) and (D) are no longer members of the original > DAG, only a node who is still a member of the original DAG may > possibly present the sequence number N+1. Such a node who > presents N+1 must clearly have another path to the DAG root other > than via (C) and (D) and thus may offer a loop-avoiding attachment > point. >=20 > o [TBD] The DAG Root may periodically issue sequence number > increments, causing the issue of N+1 >=20 > o [TBD] The broken link (C)->(A) may be detected through some other > means, and signalled to or cause a trigger at the DAG Root, > causing the issue of N+1 >=20 > o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and > determine it is able to rejoin the original DAG by immediately > reattaching j to Node (B) (No hold-up state in this example. The > DAG is now as depicted in Figure 2-3 >=20 > o Node (C) may then subsequently send RA-DIO with DAG Sequence > number N+1, allowing Node (D) to reattach (not depicted). >=20 > =20 > ---------------------------------------------------------------------- > -- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=543b37f22=mukul@uwm.edu Mon Oct 26 04:18:18 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C64D28C1FC for ; Mon, 26 Oct 2009 04:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHDdK7I010J5 for ; Mon, 26 Oct 2009 04:18:16 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 6B49F3A6966 for ; Mon, 26 Oct 2009 04:18:16 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 26 Oct 2009 06:18:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4BE47C085D1; Mon, 26 Oct 2009 06:18:29 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-ztx38CXc2I; Mon, 26 Oct 2009 06:18:28 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4C40FC085CF; Mon, 26 Oct 2009 06:18:28 -0500 (CDT) Date: Mon, 26 Oct 2009 06:18:28 -0500 (CDT) From: Mukul Goyal To: "Mathilde Durvy (mdurvy)" Message-ID: <762140648.183491256555908205.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <864785050.183471256555904214.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 11:18:39 -0000 Hi Mathilde, >> o Node (C) must first detach from the DAG by removing Node (A) from >> its DAG parent set, leaving an empty DAG parent set. At this >> point Node (C) is not associated with any DAG [TBD -- Alternately >> Node (C) remains associated with the DAG at rank infinity]. [Mathilde] Why couldn't Node (C) become the root of its own floating DAG? I don't think it adds in complexity and it would allow Node (C) sub-dag to remain connected providing some 'local' connectivity. In general I don't like the idea of maintaining nodes in an unassociated state for a potentially unbounded time period. My understanding is that floating DAGs will be available as an optional feature; they are just not going to be a part of the core specs. >> o Node (C) and (D) will now be willing to reattach to the original >> DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering >> connectivity to the original DAG and advertising a sequence number >> N+1. Since Node (C) and (D) are no longer members of the original >> DAG, only a node who is still a member of the original DAG may >> possibly present the sequence number N+1. Such a node who >> presents N+1 must clearly have another path to the DAG root other >> than via (C) and (D) and thus may offer a loop-avoiding attachment >> point. [Mathilde] This approach is safe but it means that the node needs to remember the initial DAG id and sequence number, i.e. keep some states about a DAG it is not part of anymore. What happens if the node joins other DAGs before going back to the original one? Does it mean you have to remember all DAGs you ever joined... Maybe an alternative would be to mandate that the DAG root increments the sequence number periodically and consider it safe to join a new DAG after waiting for (a multiple of) this period. This allows to keep less state but is probably not quite as safe. Periodic update of seqno by the DAG root may not be desirable in many situations. Such an update forces a new DAG structure to be formed from scratch and may generate significant churn before things stablize. Would it be sufficient for a node to just consider the highest seqno DIOs received so far as fresh and all other (current and future) DIOs with smaller seqno as stale. Thanks Mukul Best, Mathilde -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter Sent: vendredi, 23. octobre 2009 19:33 To: ROLL WG Subject: Re: [Roll] RPL Design Questions WG, We are working towards the -04 revision, and in consideration of WG feedback on these questions have also taken into account the following: - The WG has given a clear mandate to reduce complexity - Many of these features are related to optimizations, but do not appear strictly required to operate the core protocol The mandate to reduce complexity is very clear, the feedback on the list in support of these features is less so. Therefore we do propose to take the following approach proceeding into -04: - Recommendations for DAG Splitting and Merging (Detach/Form transient floating DAG/Reattach) will be removed (loss of connectivity/sub-DAG poisoning may effectively occur by advertising rank of infinity) - Hold-Up Timer and related states/procedures will be removed - Hold-Down Timer and related states/procedures will be removed It is the objective that by removing these protocol features we are able to let the basic mechanisms of the core protocol be clear without additional complexity. We do not wish to introduce complexity by including perceived optimizations, but also realize that as the WG effort proceeds we may find it necessary to reintroduce some part of these features in some form. But for now they do not seem strictly necessary, and it is the hope that by keeping them back the WG may focus more on the core protocol. Please let us know your comments/feedback- what do you think? Thanks, -RPL Authors Tim Winter wrote: > WG, > > Please do let us know what you are thinking w/ regard to the design > Questions A, B, & C below. We hope to include your feedback into the > next revision of the document, with FSM descriptions as well. > > Thanks, > > - RPL Authors > > > > As discussed at the interim meeting, implementer feedback has > indicated that the RPL protocol as proposed appears complex, both in > description and actual FSM. > > Our plan of action is to, by end of month, deliver a -04 that will > contain actual (non-editorial) changes. The intent of this mail is > a poll over a period of 2 weeks, to help design the functional > changes. > > In this spirit, we would like the WG to work on the following > questions: > > Question A: Should RPL make use of the currently proposed local > repair mechanism (DAG splitting and merging)? > > [NO implies that DAG repairs shall be coordinated globally with > the use of DAG Sequence Number; the related mechanisms are to > be expanded for -04] > > Question B: Should RPL make use of a hold-up timer and related > states/procedures to reduce churn by coordinating the DAG merge? > > [NO implies RPL allows nodes to move (jump) between DAGs with > little coordination to reduce complexity of specification/ > implementation (perhaps w/ Optional hold-up mechanism)]. > > Question C: Should RPL make use of a hold-down timer and related > states/procedures to limit flapping when removing DAG Parents / > leaving DAGs > > [NO implies RPL allows nodes to freely remove/add DAG Parents > as and when they are able in order to reduce complexity of > specification/implementation (perhaps w/ Optional hold-down > mechanism). > > WG, we expect that this thread will contain a lot of interesting > related discussion, but in your comments please do also be sure to > try and address the initial questions A, B, and C so as to help us > better capture the WG position on these issues. Please note that A, > B, and C are to some degree orthogonal, e.g. `No Local Repair' to > Question A does not necessarily imply a particular disposition toward > the Hold-Up mechanism in Question B. > > Thanks, > > RPL Authors > > > > Some examples, derived from the present draft, are provided below: > > > ---------------------------------------------------------------------- > -- > > Example: Local Repair with Hold-Up state > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | | \ > | | `-----. > | | \ > (D) (D) (C) > | > | > | > (D) > > -1- -2- -3- > > > Figure 1: DAG Maintenance > > Consider the example depicted in Figure 1-1. In this example, Node > (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of > Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is > also an undirected sibling link between Nodes (B) and (C). > > In this example, Node (C) may safely forward to Node (A) without > creating a loop. Node (C) may not safely forward to Node (D), > contained within it's own sub-DAG, without creating a loop. Node (C) > may forward to Node (B) in some cases, e.g. the link (C)->(A) is > temporarily unavailable, but with some chance of creating a loop > (e.g. if multiple nodes in a set of siblings start forwarding > `sideways' in a cycle) and requiring the intervention of additional > mechanisms to detect and break the loop. > > Consider the case where Node (C) hears a RA-DIO message from a Node > (Z) at a lesser rank and superior position in the DAG than node (A). > Node (C) may safely undergo the process to evict node (A) from its > DAG parent set and attach directly to Node (Z) without creating a > loop, because its rank will decrease. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. Node (C) > becomes the root of its own floating, less preferred, DAG. > > o Node (D), hearing a modified RA-DIO message from Node (C), follows > Node (C) into the floating DAG. This is depicted in Figure 1-2. > In general, any node with no other options in the sub-DAG of Node > (C) will follow Node (C) into the floating DAG, maintaining the > structure of the sub-DAG. > > o Node (C) hears a RA-DIO message from Node (B) and determines it is > able to rejoin the grounded DAG by reattaching at a deeper rank to > Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in > the Hold-Up state) to coordinate this move. > > o The timer expires and Node (C) adds Node (B) to its DAG parent > set. Node (C) has now safely moved deeper within the grounded DAG > without creating any loops. Node (D), and any other sub-DAG of > Node (C), will hear the modified RA-DIO message sourced from Node > (C) and follow Node (C) in a coordinated manner to reattach to the > grounded DAG. The final DAG is depicted in Figure 1-3 > > > > ---------------------------------------------------------------------- > -- > > Example: Global Repair with Sequence Number / No Held-Up State > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | \ > | `-----. > | \ > (D) (D) (C) > > > > (D) > > -1- -2- -3- > > > Figure 2: DAG Maintenance > > Consider the example depicted in Figure 2-1, similar to that depicted > in Figure 1. Let there be a sequence number associated with the DAG, > as originated from the DAG root, with value N. Initially all nodes > have received DAG Sequence Number N. The following example offers one > possible Global Repair scenario to give a high level idea, please > note that there are details that would remain to be worked out if the > WG heads in this direction. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. At this > point Node (C) is not associated with any DAG [TBD -- Alternately > Node (C) remains associated with the DAG at rank infinity]. > > o Node (D) may possibly learn that Node (C) is no longer associated > with any DAG and itself becomes unassociated [TBD Node (D) may > also retain a sub-DAG relationship with Node (C)]. Let Node (C) > and (D) both be free from any DAG, but remember the Sequence > Number N associated with their original DAG. This is depicted in > Figure 2-2. > > o Node (C) and (D) will now be willing to reattach to the original > DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering > connectivity to the original DAG and advertising a sequence number > N+1. Since Node (C) and (D) are no longer members of the original > DAG, only a node who is still a member of the original DAG may > possibly present the sequence number N+1. Such a node who > presents N+1 must clearly have another path to the DAG root other > than via (C) and (D) and thus may offer a loop-avoiding attachment > point. > > o [TBD] The DAG Root may periodically issue sequence number > increments, causing the issue of N+1 > > o [TBD] The broken link (C)->(A) may be detected through some other > means, and signalled to or cause a trigger at the DAG Root, > causing the issue of N+1 > > o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and > determine it is able to rejoin the original DAG by immediately > reattaching j to Node (B) (No hold-up state in this example. The > DAG is now as depicted in Figure 2-3 > > o Node (C) may then subsequently send RA-DIO with DAG Sequence > number N+1, allowing Node (D) to reattach (not depicted). > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > 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 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Mon Oct 26 05:58:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04DA3A6860 for ; Mon, 26 Oct 2009 05:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.803 X-Spam-Level: X-Spam-Status: No, score=-9.803 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgr7n-CQy5bM for ; Mon, 26 Oct 2009 05:58:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7A0983A67DD for ; Mon, 26 Oct 2009 05:58:45 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAHs55UqQ/uCWe2dsb2JhbACbNwEBFiQGpG+WbYQ/BA X-IronPort-AV: E=Sophos;i="4.44,625,1249257600"; d="scan'208";a="52778154" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 12:58:57 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QCwvE4014906; Mon, 26 Oct 2009 12:58:57 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:58:57 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:58:56 +0100 Message-Id: <2D975A11-B7E4-4EAD-8A9C-8579CF4D6E43@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4AE2DA17.20701@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 13:58:56 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <4AE2DA17.20701@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 12:58:57.0052 (UTC) FILETIME=[1434EDC0:01CA563C] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 12:58:46 -0000 Hi, On Oct 24, 2009, at 12:42 PM, Alexandru Petrescu wrote: >> The Expected Transmission Count (ETX) metric is defined as 1 / (Df * >> Dr) where Df is the measured probability that a packet is received > > How do you measure that probability ^ ? This is one example (I'll make it explicit). Depending on the link =20 layer, you may use some link layer specific mechanism, use a probe, ... > >> ETX: 8 bits. The Latency is encoded in 32 bits in IEEE floating >> point format (see [IEEE.754.1985]). Refer to Section 3.1.2 of >> [RFC3741] for a table of commonly used values. > > Er? That RFC "Exclusive XML Canonicalization" does not have any =20 > section 3.1.2. Are you sure you refer to the right document? (it =20 > too sounds strange to use XML carried in RPL). Type, sorry, it should ready RFC3471. > > BTW, do you use XML to edit the metrics draft? > > Alex > > Internet-Drafts@ietf.org a =E9crit : >> A New Internet-Draft is available from the on-line Internet-Drafts =20= >> directories. >> This draft is a work item of the Routing Over Low power and Lossy =20 >> networks Working Group of the IETF. >> Title : Routing Metrics used for Path Calculation in = Low =20 >> Power and Lossy Networks >> Author(s) : J. Vasseur, D. Networks >> Filename : draft-ietf-roll-routing-metrics-01.txt >> Pages : 28 >> Date : 2009-10-24 >> Low power and Lossy Networks (LLNs) have unique characteristics >> compared with traditional wired and ad-hoc networks that require the >> specification of new routing metrics and constraints. By contrast >> with typical Interior Gateway Protocol (IGP) routing metrics using >> hop counts or link metrics, this document specifies a set of link and >> node routing metrics and constraints suitable to LLNs. >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-01.txt= >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> = ------------------------------------------------------------------------ >> _______________________________________________ >> 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 root@core3.amsl.com Mon Oct 26 06:15:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E39143A68FA; Mon, 26 Oct 2009 06:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026131501.E39143A68FA@core3.amsl.com> Date: Mon, 26 Oct 2009 06:15:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 13:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, D. Networks Filename : draft-ietf-roll-routing-metrics-02.txt Pages : 29 Date : 2009-10-26 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-routing-metrics-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26060328.I-D@ietf.org> --NextPart-- From jvasseur@cisco.com Mon Oct 26 06:44:21 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F95D28C229 for ; Mon, 26 Oct 2009 06:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.827 X-Spam-Level: X-Spam-Status: No, score=-9.827 tagged_above=-999 required=5 tests=[AWL=0.770, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyfHBsr+GiKz for ; Mon, 26 Oct 2009 06:44:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2992328C27E for ; Mon, 26 Oct 2009 06:44:19 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEAAAZE5UqQ/uCWe2dsb2JhbACCJC+YZAEBFiQGpRyWboQ/BA X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208,217";a="52783167" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 13:44:31 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QDiVGY029103 for ; Mon, 26 Oct 2009 13:44:31 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:44:31 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:44:30 +0100 Message-Id: <7C904A6E-5513-4462-9E9F-4183E5785B24@cisco.com> From: JP Vasseur To: roll ROLL Content-Type: multipart/alternative; boundary=Apple-Mail-27--915403969 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 14:44:30 +0100 References: <20091026131501.E39143A68FA@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 13:44:31.0246 (UTC) FILETIME=[71E9D2E0:01CA5642] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16970.007 X-TM-AS-Result: No--25.028200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 13:44:21 -0000 --Apple-Mail-27--915403969 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Specification of the OCP has been added. Thanks. JP, Mijeom and Kris. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 26, 2009 2:15:01 PM CEST > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-routing-metrics-02.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Routing Metrics used for Path Calculation in Low > Power and Lossy Networks > Author(s) : J. Vasseur, D. Networks > Filename : draft-ietf-roll-routing-metrics-02.txt > Pages : 29 > Date : 2009-10-26 > > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-27--915403969 Content-Type: multipart/mixed; boundary=Apple-Mail-28--915403968 --Apple-Mail-28--915403968 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Specification of the OCP has = been added.

Thanks.

JP, = Mijeom and Kris.

Begin forwarded message:

Date: October 26, 2009 2:15:01 PM = CEST
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-ietf-roll-routing-metrics-02.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Routing Over Low power = and Lossy networks Working Group of the IETF.


Title =           : Routing = Metrics used for Path Calculation in Low Power and Lossy = Networks
= Author(s)       : J. Vasseur, D. = Networks
= Filename        : = draft-ietf-roll-routing-metrics-02.txt
Pages =           : = 29
= Date =            : = 2009-10-26

Low power and Lossy Networks (LLNs) have unique = characteristics
compared with traditional wired and ad-hoc networks = that require the
specification of new routing metrics and = constraints.  By contrast
with typical Interior Gateway Protocol = (IGP) routing metrics using
hop counts or link metrics, this document = specifies a set of link and
node routing metrics and constraints = suitable to LLNs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr= ics-02.txt

Internet-Drafts are also available by anonymous = FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-28--915403968 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2009-10-26060328.I-D@ietf.org>

--Apple-Mail-28--915403968 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-28--915403968-- --Apple-Mail-27--915403969-- From pthubert@cisco.com Mon Oct 26 07:01:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0B83A6A3C for ; Mon, 26 Oct 2009 07:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=-2.096, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep8QQvhDtc-d for ; Mon, 26 Oct 2009 07:01:12 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 304713A6783 for ; Mon, 26 Oct 2009 07:01:12 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALZI5UqrRN+K/2dsb2JhbADBMIkgCI1Igk4IgWkE X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="261433852" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2009 14:01:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9QE1JHV010383; Mon, 26 Oct 2009 14:01:24 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:01:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA5644.C56EBC9D" Date: Mon, 26 Oct 2009 15:01:04 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D7A380C@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE92F3A4@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Design Questions Thread-Index: AcpUBvfmV/kQXBUlRx+woWJpcItu1ACHeMvQAAdP10A= References: <4AD3F102.8010601@acm.org> <4AE1E8E3.5000900@acm.org> <8A977BDC5A7B0E429B0F521E8D6F91EE92F3A4@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "Tim Winter" , "ROLL WG" X-OriginalArrivalTime: 26 Oct 2009 14:01:11.0674 (UTC) FILETIME=[C63705A0:01CA5644] Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 14:01:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5644.C56EBC9D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Mathilde: At some point, people get what they ask for. There was a not so overwhelming request to remove the Hold up and hold down states and timers so we experienced it. And yes, we have given you apparent simplicity but then, consequences arise. >> =20 >[Mathilde] This approach is safe but it means that the node needs to >remember the initial DAG id and sequence number, i.e. keep some states >about a DAG it is not part of anymore. What happens if the node joins >other DAGs before going back to the original one? Does it mean you have >to remember all DAGs you ever joined... Maybe an alternative would be to >mandate that the DAG root increments the sequence number periodically >and consider it safe to join a new DAG after waiting for (a multiple of) >this period. This allows to keep less state but is probably not quite as >safe. Please see 'implementation cost' sections in the attached mail RPL design question. (mostly Q.A) You're right the node has to keep states. In practice, the next version of the draft also introduces: - long periods of black hole (till next sequence) - overstretched routes (nodes jump too fast onto the first guy with the new sequence) Unless of course a clever implementation adds special sauce that would be toying with what's allowed and what's not. Like introduce a timer that allows to get rid of past DAG states so that the node which lost memory can faithfully jump anywhere. Is that safe?=20 -Not really, but if that timer is an order of magnitude longer than DIO propagation, well, that's certainly better than jumping anywhere blindly, because a number of the wrong targets will be eliminated by the route poisoning. -And considering that we have loop detection on the spec now, I'd assume that yes, it would be a very acceptable behavior. Guess what. I think that was what the DAG Hop Timer was doing for us. Hum. Anyway, nothing is cast in stone at this point, and we might reintroduce some timers when people realize what they really lost. Pascal >> =20 >[Mathilde] This approach is safe but it means that the node needs to >remember the initial DAG id and sequence number, i.e. keep some states >about a DAG it is not part of anymore. What happens if the node joins >other DAGs before going back to the original one? Does it mean you have >to remember all DAGs you ever joined... Maybe an alternative would be to >mandate that the DAG root increments the sequence number periodically >and consider it safe to join a new DAG after waiting for (a multiple of) >this period. This allows to keep less state but is probably not quite as >safe. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mathilde Durvy (mdurvy) >Sent: lundi 26 octobre 2009 11:45 >To: Tim Winter; ROLL WG >Subject: Re: [Roll] RPL Design Questions > >Hi Tim, All, > >I support the proposals made in your email. I think they are a key step >in reducing the complexity of RPL. > >Some comments on the "Example: Global Repair with Sequence Number / No >Held-Up State" as it is directly related to what the design team >proposes. > >> o Node (C) must first detach from the DAG by removing Node (A) >from >> its DAG parent set, leaving an empty DAG parent set. At this >> point Node (C) is not associated with any DAG [TBD -- >Alternately >> Node (C) remains associated with the DAG at rank infinity]. >[Mathilde] Why couldn't Node (C) become the root of its own floating >DAG? I don't think it adds in complexity and it would allow Node (C) >sub-dag to remain connected providing some 'local' connectivity. In >general I don't like the idea of maintaining nodes in an unassociated >state for a potentially unbounded time period. > >> o Node (C) and (D) will now be willing to reattach to the original >> DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering >> connectivity to the original DAG and advertising a sequence >number >> N+1. Since Node (C) and (D) are no longer members of the >original >> DAG, only a node who is still a member of the original DAG may >> possibly present the sequence number N+1. Such a node who >> presents N+1 must clearly have another path to the DAG root >other >> than via (C) and (D) and thus may offer a loop-avoiding >attachment >> point. >[Mathilde] This approach is safe but it means that the node needs to >remember the initial DAG id and sequence number, i.e. keep some states >about a DAG it is not part of anymore. What happens if the node joins >other DAGs before going back to the original one? Does it mean you have >to remember all DAGs you ever joined... Maybe an alternative would be to >mandate that the DAG root increments the sequence number periodically >and consider it safe to join a new DAG after waiting for (a multiple of) >this period. This allows to keep less state but is probably not quite as >safe. > >Best, >Mathilde > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Tim Winter >Sent: vendredi, 23. octobre 2009 19:33 >To: ROLL WG >Subject: Re: [Roll] RPL Design Questions > >WG, > >We are working towards the -04 revision, and in consideration of WG >feedback on these questions have also taken into account the following: > - The WG has given a clear mandate to reduce complexity > - Many of these features are related to optimizations, but do >not appear strictly required to operate the core protocol > >The mandate to reduce complexity is very clear, the feedback on the list >in support of these features is less so. Therefore we do propose to >take the following approach proceeding into -04: > - Recommendations for DAG Splitting and Merging (Detach/Form >transient floating DAG/Reattach) will be removed (loss of >connectivity/sub-DAG poisoning may effectively occur by advertising rank >of infinity) > - Hold-Up Timer and related states/procedures will be removed > - Hold-Down Timer and related states/procedures will be removed > >It is the objective that by removing these protocol features we are able >to let the basic mechanisms of the core protocol be clear without >additional complexity. We do not wish to introduce complexity by >including perceived optimizations, but also realize that as the WG >effort proceeds we may find it necessary to reintroduce some part of >these features in some form. But for now they do not seem strictly >necessary, and it is the hope that by keeping them back the WG may focus >more on the core protocol. > >Please let us know your comments/feedback- what do you think? > >Thanks, > >-RPL Authors > > > > >Tim Winter wrote: >> WG, >> >> Please do let us know what you are thinking w/ regard to the design >> Questions A, B, & C below. We hope to include your feedback into the >> next revision of the document, with FSM descriptions as well. >> >> Thanks, >> >> - RPL Authors >> >> >> >> As discussed at the interim meeting, implementer feedback has >> indicated that the RPL protocol as proposed appears complex, both >in >> description and actual FSM. >> >> Our plan of action is to, by end of month, deliver a -04 that will >> contain actual (non-editorial) changes. The intent of this mail is >> a poll over a period of 2 weeks, to help design the functional >> changes. >> >> In this spirit, we would like the WG to work on the following >> questions: >> >> Question A: Should RPL make use of the currently proposed local >> repair mechanism (DAG splitting and merging)? >> >> [NO implies that DAG repairs shall be coordinated globally >with >> the use of DAG Sequence Number; the related mechanisms are to >> be expanded for -04] >> >> Question B: Should RPL make use of a hold-up timer and related >> states/procedures to reduce churn by coordinating the DAG merge? >> >> [NO implies RPL allows nodes to move (jump) between DAGs with >> little coordination to reduce complexity of specification/ >> implementation (perhaps w/ Optional hold-up mechanism)]. >> >> Question C: Should RPL make use of a hold-down timer and related >> states/procedures to limit flapping when removing DAG Parents / >> leaving DAGs >> >> [NO implies RPL allows nodes to freely remove/add DAG Parents >> as and when they are able in order to reduce complexity of >> specification/implementation (perhaps w/ Optional hold-down >> mechanism). >> >> WG, we expect that this thread will contain a lot of interesting >> related discussion, but in your comments please do also be sure to >> try and address the initial questions A, B, and C so as to help us >> better capture the WG position on these issues. Please note that >A, >> B, and C are to some degree orthogonal, e.g. `No Local Repair' to >> Question A does not necessarily imply a particular disposition >toward >> the Hold-Up mechanism in Question B. >> >> Thanks, >> >> RPL Authors >> >> >> >> Some examples, derived from the present draft, are provided below: >> >> >> ---------------------------------------------------------------------- >> -- >> >> Example: Local Repair with Hold-Up state >> >> >> : : : >> : : : >> (A) (A) (A) >> |\ | | >> | `-----. | | >> | \ | | >> (B) (C) (B) (C) (B) >> | | \ >> | | `-----. >> | | \ >> (D) (D) (C) >> | >> | >> | >> (D) >> >> -1- -2- -3- >> >> >> Figure 1: DAG Maintenance >> >> Consider the example depicted in Figure 1-1. In this example, Node >> (A) is attached to a DAG at some rank d. Node (A) is a DAG parent >of >> Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is >> also an undirected sibling link between Nodes (B) and (C). >> >> In this example, Node (C) may safely forward to Node (A) without >> creating a loop. Node (C) may not safely forward to Node (D), >> contained within it's own sub-DAG, without creating a loop. Node >(C) >> may forward to Node (B) in some cases, e.g. the link (C)->(A) is >> temporarily unavailable, but with some chance of creating a loop >> (e.g. if multiple nodes in a set of siblings start forwarding >> `sideways' in a cycle) and requiring the intervention of additional >> mechanisms to detect and break the loop. >> >> Consider the case where Node (C) hears a RA-DIO message from a Node >> (Z) at a lesser rank and superior position in the DAG than node >(A). >> Node (C) may safely undergo the process to evict node (A) from its >> DAG parent set and attach directly to Node (Z) without creating a >> loop, because its rank will decrease. >> >> Now consider the case where the link (C)->(A) becomes nonviable, >and >> node (C) must move to a deeper rank within the DAG: >> >> o Node (C) must first detach from the DAG by removing Node (A) >from >> its DAG parent set, leaving an empty DAG parent set. Node (C) >> becomes the root of its own floating, less preferred, DAG. >> >> o Node (D), hearing a modified RA-DIO message from Node (C), >follows >> Node (C) into the floating DAG. This is depicted in Figure 1-2. >> In general, any node with no other options in the sub-DAG of >Node >> (C) will follow Node (C) into the floating DAG, maintaining the >> structure of the sub-DAG. >> >> o Node (C) hears a RA-DIO message from Node (B) and determines it >is >> able to rejoin the grounded DAG by reattaching at a deeper rank >to >> Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in >> the Hold-Up state) to coordinate this move. >> >> o The timer expires and Node (C) adds Node (B) to its DAG parent >> set. Node (C) has now safely moved deeper within the grounded >DAG >> without creating any loops. Node (D), and any other sub-DAG of >> Node (C), will hear the modified RA-DIO message sourced from >Node >> (C) and follow Node (C) in a coordinated manner to reattach to >the >> grounded DAG. The final DAG is depicted in Figure 1-3 >> >> >> >> ---------------------------------------------------------------------- >> -- >> >> Example: Global Repair with Sequence Number / No Held-Up State >> >> >> : : : >> : : : >> (A) (A) (A) >> |\ | | >> | `-----. | | >> | \ | | >> (B) (C) (B) (C) (B) >> | \ >> | `-----. >> | \ >> (D) (D) (C) >> >> >> >> (D) >> >> -1- -2- -3- >> >> >> Figure 2: DAG Maintenance >> >> Consider the example depicted in Figure 2-1, similar to that >depicted >> in Figure 1. Let there be a sequence number associated with the >DAG, >> as originated from the DAG root, with value N. Initially all nodes >> have received DAG Sequence Number N. The following example offers >one >> possible Global Repair scenario to give a high level idea, please >> note that there are details that would remain to be worked out if >the >> WG heads in this direction. >> >> Now consider the case where the link (C)->(A) becomes nonviable, >and >> node (C) must move to a deeper rank within the DAG: >> >> o Node (C) must first detach from the DAG by removing Node (A) >from >> its DAG parent set, leaving an empty DAG parent set. At this >> point Node (C) is not associated with any DAG [TBD -- >Alternately >> Node (C) remains associated with the DAG at rank infinity]. >> >> o Node (D) may possibly learn that Node (C) is no longer >associated >> with any DAG and itself becomes unassociated [TBD Node (D) may >> also retain a sub-DAG relationship with Node (C)]. Let Node (C) >> and (D) both be free from any DAG, but remember the Sequence >> Number N associated with their original DAG. This is depicted >in >> Figure 2-2. >> >> o Node (C) and (D) will now be willing to reattach to the original >> DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering >> connectivity to the original DAG and advertising a sequence >number >> N+1. Since Node (C) and (D) are no longer members of the >original >> DAG, only a node who is still a member of the original DAG may >> possibly present the sequence number N+1. Such a node who >> presents N+1 must clearly have another path to the DAG root >other >> than via (C) and (D) and thus may offer a loop-avoiding >attachment >> point. >> >> o [TBD] The DAG Root may periodically issue sequence number >> increments, causing the issue of N+1 >> >> o [TBD] The broken link (C)->(A) may be detected through some >other >> means, and signalled to or cause a trigger at the DAG Root, >> causing the issue of N+1 >> >> o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and >> determine it is able to rejoin the original DAG by immediately >> reattaching j to Node (B) (No hold-up state in this example. >The >> DAG is now as depicted in Figure 2-3 >> >> o Node (C) may then subsequently send RA-DIO with DAG Sequence >> number N+1, allowing Node (D) to reattach (not depicted). >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> 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 >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CA5644.C56EBC9D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-ams-102.cisco.com ([144.254.73.132]) by xmb-ams-107.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:19:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:19:09 +0200 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 00:19:06 -0700 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 13 Oct 2009 07:19:05 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D7J4v5004957; Tue, 13 Oct 2009 07:19:06 GMT Received: from mail.ietf.org ([64.170.98.32]) by sj-inbound-f.cisco.com with ESMTP; 13 Oct 2009 07:19:05 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7183A694E; Tue, 13 Oct 2009 00:19:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AF533A6923 for ; Tue, 13 Oct 2009 00:19:03 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG2STXId70kc for ; Tue, 13 Oct 2009 00:19:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 099F53A6831 for ; Tue, 13 Oct 2009 00:19:00 -0700 (PDT) Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Oct 2009 07:19:00 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9D7J0i7010132; Tue, 13 Oct 2009 07:19:00 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 09:19:00 +0200 Content-class: urn:content-classes:message Subject: Re: [Roll] RPL Design Questions Date: Tue, 13 Oct 2009 08:16:29 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D66E0AD@XMB-AMS-107.cisco.com> In-Reply-To: <4AD3F102.8010601@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL Design Questions Thread-Index: AcpLs5Tx2qwYAp7fTHKnpZ7vNgEWpQAGfPIQ References: <4AD3F102.8010601@acm.org> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Pascal Thubert (pthubert)" Sender: To: "Tim Winter" , "ROLL WG" Hi: I think Tim did a great job at keeping the question text simple. Thinking about his own answer on this, one might wonder what the actual cost of things is and how things are related. The good news is that as far as I can see, the 3 items of the poll are not related: - one could bypass the DAG hop Timer mechanism and still allow the split/merge mechanism that is used for loop avoidance. The result will probably be more runtime churn and more battery consumption. - Alternatively one could ignore the split/merge and stay there, simply advertising infinity to poison the broken path, and yet, the DAG hop timer would be useful to avoid churn as the new DAG is constructed to restore connectivity. - and the hold down is orthogonal, rather related of the validation process that takes place before a parent can be used at all. Even better, it appears that a network that incorporates mixed behaviors still works correctly. If I'm correct on that, then it could be possible to make those things optional, like having a fully capable node and a more constrained node's behavior, and then enable a policies in the former to more or less act as the latter. The other aspect of the question is the real cost associated to the listed items. Question A:=20 ------------ Feature benefit: When this mechanism is in place, a DAG can detach and still enable local (P2P) connectivity. There are use cases for that, though not really obvious in our requirement drafts. So obviously we'd be losing that sort of connectivity if the mechanism Implementation cost: When a node detaches, it should in theory keep some history of its previous DAGs as long as those DAGs live, so as to never jump back in the same DAG, same sequence but at a higher rank. That would be perfect loop avoidance. But that's not what the spec does. The spec attempts to mark the wrong landing sites by route poisoning and then allows any jump after a reasonable time. So the implementation cost at the end of the day is one timer, and a bit of logic to decide whether that timer should be armed at all. The current text allows overloading the DAG Hop Timer for that purpose (that's Q 2). Question B: Feature benefit: This is all about churn. There are occasions like a new sequence or a DAG accident (new root inserted or removed, split/merge...) where a DAG and sometimes neighboring nodes are impacted. If we leave it to chance, nodes will reposition a number of times before things settle, causing churn and battery depletion. This timer delays things and forces the changes to spread like a wave in one pass from the root out. Implementation cost: In theory that's one timer per parent that this node wants to jump to. In terms of implementation, this can be reduced to one timer per DAG that the node might want to jump to, and even further reduced to one timer at all if the implementation only keeps track of the most preferred DAG onto which it could jump. Note that the doc allows the node to use the same timer for Q A). The feature also requires to pass the DAG base period in the DIO. Question C)=20 Feature benefit: A node that has poor history is blacklisted. This prevents it to be reconsidered as a parent for a configurable period of time. This method avoid periodic churn and black out, or at least makes that period a lot longer. Implementation cost: In theory one timer per blacklisted node, and some data structure per blacklisted node. In practice, an implementation can use a single periodic timer and a list of the blacklisted nodes. It can for instance maintain a counter per listed node that is incremented at each tick. When the increment reaches a threshold, the node is removed from the blasklist. My vote is YES to all the questions. Keep them in the base spec.=20 And allow for a fallback behavior in the real constrained devices if that can cohabit as I think it does. Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tim Winter >Sent: mardi 13 octobre 2009 05:16 >To: ROLL WG >Subject: [Roll] RPL Design Questions > >WG, > >Please do let us know what you are thinking w/ regard to the design >Questions A, B, & C below. We hope to include your feedback into the next >revision of the document, with FSM descriptions as well. > >Thanks, > >- RPL Authors > > > > As discussed at the interim meeting, implementer feedback has > indicated that the RPL protocol as proposed appears complex, both in > description and actual FSM. > > Our plan of action is to, by end of month, deliver a -04 that will > contain actual (non-editorial) changes. The intent of this mail is > a poll over a period of 2 weeks, to help design the functional > changes. > > In this spirit, we would like the WG to work on the following > questions: > > Question A: Should RPL make use of the currently proposed local > repair mechanism (DAG splitting and merging)? > > [NO implies that DAG repairs shall be coordinated globally with > the use of DAG Sequence Number; the related mechanisms are to > be expanded for -04] > > Question B: Should RPL make use of a hold-up timer and related > states/procedures to reduce churn by coordinating the DAG merge? > > [NO implies RPL allows nodes to move (jump) between DAGs with > little coordination to reduce complexity of specification/ > implementation (perhaps w/ Optional hold-up mechanism)]. > > Question C: Should RPL make use of a hold-down timer and related > states/procedures to limit flapping when removing DAG Parents / > leaving DAGs > > [NO implies RPL allows nodes to freely remove/add DAG Parents > as and when they are able in order to reduce complexity of > specification/implementation (perhaps w/ Optional hold-down > mechanism). > > WG, we expect that this thread will contain a lot of interesting > related discussion, but in your comments please do also be sure to > try and address the initial questions A, B, and C so as to help us > better capture the WG position on these issues. Please note that A, > B, and C are to some degree orthogonal, e.g. `No Local Repair' to > Question A does not necessarily imply a particular disposition toward > the Hold-Up mechanism in Question B. > > Thanks, > > RPL Authors > > > > Some examples, derived from the present draft, are provided below: > > ------------------------------------------------------------------------ > > Example: Local Repair with Hold-Up state > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | | \ > | | `-----. > | | \ > (D) (D) (C) > | > | > | > (D) > > -1- -2- -3- > > > Figure 1: DAG Maintenance > > Consider the example depicted in Figure 1-1. In this example, Node > (A) is attached to a DAG at some rank d. Node (A) is a DAG parent of > Nodes (B) and (C). Node (C) is a DAG parent of Node (D). There is > also an undirected sibling link between Nodes (B) and (C). > > In this example, Node (C) may safely forward to Node (A) without > creating a loop. Node (C) may not safely forward to Node (D), > contained within it's own sub-DAG, without creating a loop. Node (C) > may forward to Node (B) in some cases, e.g. the link (C)->(A) is > temporarily unavailable, but with some chance of creating a loop > (e.g. if multiple nodes in a set of siblings start forwarding > `sideways' in a cycle) and requiring the intervention of additional > mechanisms to detect and break the loop. > > Consider the case where Node (C) hears a RA-DIO message from a Node > (Z) at a lesser rank and superior position in the DAG than node (A). > Node (C) may safely undergo the process to evict node (A) from its > DAG parent set and attach directly to Node (Z) without creating a > loop, because its rank will decrease. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. Node (C) > becomes the root of its own floating, less preferred, DAG. > > o Node (D), hearing a modified RA-DIO message from Node (C), follows > Node (C) into the floating DAG. This is depicted in Figure 1-2. > In general, any node with no other options in the sub-DAG of Node > (C) will follow Node (C) into the floating DAG, maintaining the > structure of the sub-DAG. > > o Node (C) hears a RA-DIO message from Node (B) and determines it is > able to rejoin the grounded DAG by reattaching at a deeper rank to > Node (B). Node (C) starts a DAG Hop timer (putting Node (B) in > the Hold-Up state) to coordinate this move. > > o The timer expires and Node (C) adds Node (B) to its DAG parent > set. Node (C) has now safely moved deeper within the grounded DAG > without creating any loops. Node (D), and any other sub-DAG of > Node (C), will hear the modified RA-DIO message sourced from Node > (C) and follow Node (C) in a coordinated manner to reattach to the > grounded DAG. The final DAG is depicted in Figure 1-3 > > > ------------------------------------------------------------------------ > > Example: Global Repair with Sequence Number / No Held-Up State > > > : : : > : : : > (A) (A) (A) > |\ | | > | `-----. | | > | \ | | > (B) (C) (B) (C) (B) > | \ > | `-----. > | \ > (D) (D) (C) > > > > (D) > > -1- -2- -3- > > > Figure 2: DAG Maintenance > > Consider the example depicted in Figure 2-1, similar to that depicted > in Figure 1. Let there be a sequence number associated with the DAG, > as originated from the DAG root, with value N. Initially all nodes > have received DAG Sequence Number N. The following example offers one > possible Global Repair scenario to give a high level idea, please > note that there are details that would remain to be worked out if the > WG heads in this direction. > > Now consider the case where the link (C)->(A) becomes nonviable, and > node (C) must move to a deeper rank within the DAG: > > o Node (C) must first detach from the DAG by removing Node (A) from > its DAG parent set, leaving an empty DAG parent set. At this > point Node (C) is not associated with any DAG [TBD -- Alternately > Node (C) remains associated with the DAG at rank infinity]. > > o Node (D) may possibly learn that Node (C) is no longer associated > with any DAG and itself becomes unassociated [TBD Node (D) may > also retain a sub-DAG relationship with Node (C)]. Let Node (C) > and (D) both be free from any DAG, but remember the Sequence > Number N associated with their original DAG. This is depicted in > Figure 2-2. > > o Node (C) and (D) will now be willing to reattach to the original > DAG at IMMEDIATELY (no hold-up mechanism) at ANY node offering > connectivity to the original DAG and advertising a sequence number > N+1. Since Node (C) and (D) are no longer members of the original > DAG, only a node who is still a member of the original DAG may > possibly present the sequence number N+1. Such a node who > presents N+1 must clearly have another path to the DAG root other > than via (C) and (D) and thus may offer a loop-avoiding attachment > point. > > o [TBD] The DAG Root may periodically issue sequence number > increments, causing the issue of N+1 > > o [TBD] The broken link (C)->(A) may be detected through some other > means, and signalled to or cause a trigger at the DAG Root, > causing the issue of N+1 > > o Let Node (C) hears a RA-DIO message with N+1 from Node (B) and > determine it is able to rejoin the original DAG by immediately > reattaching j to Node (B) (No hold-up state in this example. The > DAG is now as depicted in Figure 2-3 > > o Node (C) may then subsequently send RA-DIO with DAG Sequence > number N+1, allowing Node (D) to reattach (not depicted). > > ------------------------------------------------------------------------ > >_______________________________________________ >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 ------_=_NextPart_001_01CA5644.C56EBC9D-- From richard.kelsey@ember.com Mon Oct 26 07:18:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6270F28C2B0 for ; Mon, 26 Oct 2009 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe-bTrDRjcgL for ; Mon, 26 Oct 2009 07:18:52 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6DE6528C251 for ; Mon, 26 Oct 2009 07:18:52 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 10:20:20 -0400 Date: Mon, 26 Oct 2009 10:16:40 -0400 Message-Id: <87ws2i6y0n.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D7A380C@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <4AD3F102.8010601@acm.org> <4AE1E8E3.5000900@acm.org> <8A977BDC5A7B0E429B0F521E8D6F91EE92F3A4@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D7A380C@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 26 Oct 2009 14:20:20.0970 (UTC) FILETIME=[733FACA0:01CA5647] Cc: roll@ietf.org Subject: Re: [Roll] RPL Design Questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 14:18:53 -0000 Date: Mon, 26 Oct 2009 15:01:04 +0100 From: "Pascal Thubert (pthubert)" At some point, people get what they ask for. There was a not so overwhelming request to remove the Hold up and hold down states and timers so we experienced it. And yes, we have given you apparent simplicity but then, consequences arise. [...] Anyway, nothing is cast in stone at this point, and we might reintroduce some timers when people realize what they really lost. Pascal, I agree with you. I still think we are taking the right approach. Cutting back early and then adding features back in as necessary has two big advantages. It speeds up testing by reducing the initial effort required. It is also likely to lead to a simpler final result. The only sure way to tell if something is not needed is to try running without it. -Richard Kelsey From mcr@marajade.sandelman.ca Mon Oct 26 07:37:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B1728C29E for ; Mon, 26 Oct 2009 07:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.37 X-Spam-Level: X-Spam-Status: No, score=-0.37 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eoePwzz1q+7 for ; Mon, 26 Oct 2009 07:37:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B424928C280 for ; Mon, 26 Oct 2009 07:37:41 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 9CCD7342B9 for ; Mon, 26 Oct 2009 14:43:19 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id BFBA14E804 for ; Mon, 26 Oct 2009 10:37:52 -0400 (EDT) From: Michael Richardson To: roll ROLL In-Reply-To: <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Mon, 26 Oct 2009 10:37:52 -0400 Message-ID: <9968.1256567872@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 14:37:43 -0000 Alexandru asked where/how he can calculate the ETX. Thomas suggests that it is a deployment issue, and then suggests looking at OSPF. JP points out that OSPF and ISIS use a static undefined link metric. I want to point out that OSPF and ISIS are used in situations where there is no (or little significant) movement, and in general the link metric is configured by an operator. I do not want to have to configure all the light switches in my house. I also do not expect the builder to configure ETX metrics in them either. My impression is that RPL has to use metrics that can generally be calculated by nodes themselves. I also have no idea how I would calculate ETX, except by observing what happened before. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From ietf@thomasclausen.org Mon Oct 26 07:50:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB053A68D4 for ; Mon, 26 Oct 2009 07:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abbfC3pajwvV for ; Mon, 26 Oct 2009 07:50:10 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 91A7B3A67F1 for ; Mon, 26 Oct 2009 07:50:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 54FB232317B4; Mon, 26 Oct 2009 07:50:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 68E9432317AD; Mon, 26 Oct 2009 07:50:23 -0700 (PDT) Message-Id: <09A9ECEF-C7EE-4496-9448-D55F3387876B@thomasclausen.org> From: Thomas Heide Clausen To: Michael Richardson In-Reply-To: <9968.1256567872@marajade.sandelman.ca> Content-Type: multipart/alternative; boundary=Apple-Mail-47--911452915 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 15:50:21 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 14:50:11 -0000 --Apple-Mail-47--911452915 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Oct 26, 2009, at 3:37 PM, Michael Richardson wrote: > > Alexandru asked where/how he can calculate the ETX. > Thomas suggests that it is a deployment issue, and then suggests > looking at > OSPF. > JP points out that OSPF and ISIS use a static undefined link metric. > > I want to point out that OSPF and ISIS are used in situations where > there is no (or little significant) movement, and in general the link > metric is configured by an operator. > > I do not want to have to configure all the light switches in my house. > I also do not expect the builder to configure ETX metrics in them > either. > > My impression is that RPL has to use metrics that can generally be > calculated by nodes themselves. I also have no idea how I would > calculate ETX, except by observing what happened before. ....which is perfectly OK and, as far as I am concerned, in line with what I mentioned before: as long as the cost/weight of a link is calculated in an unambiguous manner, all is well. Thomas --Apple-Mail-47--911452915 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 3:37 PM, Michael Richardson wrote:


Alexandru asked where/how he can calculate the = ETX.
Thomas suggests that it is a deployment issue, and then suggests = looking at
OSPF.
JP points out that OSPF and ISIS use a static = undefined link metric.

I want to point out that OSPF and ISIS are = used in situations where
there is no (or little significant) = movement, and in general the link
metric is configured by an = operator.

I do not want to have to configure all the light = switches in my house.
I also do not expect the builder to configure = ETX metrics in them
either.

My impression is that RPL has to = use metrics that can generally be
calculated by nodes themselves. =  I also have no idea how I would
calculate ETX, except by = observing what happened before.

....= which is perfectly OK and, as far as I am concerned, in line with what I = mentioned before: as long as the cost/weight of a link is calculated in = an unambiguous manner, all is = well.

Thomas
= --Apple-Mail-47--911452915-- From jvasseur@cisco.com Mon Oct 26 07:51:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3352328C184 for ; Mon, 26 Oct 2009 07:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fKqW-XE-oAa for ; Mon, 26 Oct 2009 07:51:02 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EF28D3A67F1 for ; Mon, 26 Oct 2009 07:51:01 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG9U5UqrR7H+/2dsb2JhbADBVolAjTmEPwQ X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="261467388" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Oct 2009 14:51:15 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QEpEnd023653; Mon, 26 Oct 2009 14:51:15 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 20:21:14 +0530 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 20:21:13 +0530 Message-Id: <16961FC7-9FA0-4DA6-899A-8DAD0F8C00B8@cisco.com> From: JP Vasseur To: Michael Richardson In-Reply-To: <9968.1256567872@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 15:51:10 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 14:51:13.0541 (UTC) FILETIME=[C3779350:01CA564B] Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 14:51:03 -0000 Hi Michael, On Oct 26, 2009, at 3:37 PM, Michael Richardson wrote: > > Alexandru asked where/how he can calculate the ETX. > Thomas suggests that it is a deployment issue, and then suggests > looking at > OSPF. > JP points out that OSPF and ISIS use a static undefined link metric. > > I want to point out that OSPF and ISIS are used in situations where > there is no (or little significant) movement, and in general the link > metric is configured by an operator. > The comment about OSPF/ISIS was in reply to the specification on how the ETX had to be computed (deployment issue). > I do not want to have to configure all the light switches in my house. > I also do not expect the builder to configure ETX metrics in them > either. > Sure. The proposal was not to manually configure these metrics but rather that different nodes may used different techniques to compute the ETX. > My impression is that RPL has to use metrics that can generally be > calculated by nodes themselves. I also have no idea how I would > calculate ETX, except by observing what happened before. > This is one approach. Your node could also rely on PHY/MAC mechanisms when available or use probes. Thanks. JP. > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | > device driver[ > Kyoto Plus: watch the video > > then sign the petition. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Mon Oct 26 08:15:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B7F3A68AC for ; Mon, 26 Oct 2009 08:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRxVeDIg3uNz for ; Mon, 26 Oct 2009 08:15:42 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 0A5953A6839 for ; Mon, 26 Oct 2009 08:15:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9QFFrbP003923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 16:15:53 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9QFFqpU008722; Mon, 26 Oct 2009 16:15:53 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9QFFq3x021270; Mon, 26 Oct 2009 16:15:52 +0100 Message-ID: <4AE5BD28.3080807@gmail.com> Date: Mon, 26 Oct 2009 16:15:52 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> <09A9ECEF-C7EE-4496-9448-D55F3387876B@thomasclausen.org> In-Reply-To: <09A9ECEF-C7EE-4496-9448-D55F3387876B@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 15:15:42 -0000 Thomas Heide Clausen a écrit : > > On Oct 26, 2009, at 3:37 PM, Michael Richardson wrote: > >> >> Alexandru asked where/how he can calculate the ETX. >> Thomas suggests that it is a deployment issue, and then suggests >> looking at >> OSPF. >> JP points out that OSPF and ISIS use a static undefined link metric. >> >> I want to point out that OSPF and ISIS are used in situations where >> there is no (or little significant) movement, and in general the link >> metric is configured by an operator. >> >> I do not want to have to configure all the light switches in my house. >> I also do not expect the builder to configure ETX metrics in them >> either. >> >> My impression is that RPL has to use metrics that can generally be >> calculated by nodes themselves. I also have no idea how I would >> calculate ETX, except by observing what happened before. > > ....which is perfectly OK and, as far as I am concerned, in line with > what I mentioned before: as long as the cost/weight of a link is > calculated in an unambiguous manner, all is well. Well yes, but we still have to see that unambiguous manner. MAybe it will come in later. Alex From ietf@thomasclausen.org Mon Oct 26 08:18:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219863A6A03 for ; Mon, 26 Oct 2009 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SailFKQbvlW3 for ; Mon, 26 Oct 2009 08:18:05 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 38BD23A6839 for ; Mon, 26 Oct 2009 08:18:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0607C32317BA; Mon, 26 Oct 2009 08:18:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-78-229.w86-203.abo.wanadoo.fr [86.203.224.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 91C9C32317B5; Mon, 26 Oct 2009 08:18:17 -0700 (PDT) Message-Id: <0721EE75-F45C-46CC-8B15-C51794BEF2CE@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AE5BD28.3080807@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-49--909778848 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 16:18:15 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> <09A9ECEF-C7EE-4496-9448-D55F3387876B@thomasclausen.org> <4AE5BD28.3080807@gmail.com> X-Mailer: Apple Mail (2.936) Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 15:18:06 -0000 --Apple-Mail-49--909778848 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Oct 26, 2009, at 4:15 PM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Oct 26, 2009, at 3:37 PM, Michael Richardson wrote: >>> >>> Alexandru asked where/how he can calculate the ETX. >>> Thomas suggests that it is a deployment issue, and then suggests =20 >>> looking at >>> OSPF. >>> JP points out that OSPF and ISIS use a static undefined link metric. >>> >>> I want to point out that OSPF and ISIS are used in situations where >>> there is no (or little significant) movement, and in general the =20 >>> link >>> metric is configured by an operator. >>> >>> I do not want to have to configure all the light switches in my =20 >>> house. >>> I also do not expect the builder to configure ETX metrics in them >>> either. >>> >>> My impression is that RPL has to use metrics that can generally be >>> calculated by nodes themselves. I also have no idea how I would >>> calculate ETX, except by observing what happened before. >> ....which is perfectly OK and, as far as I am concerned, in line =20 >> with what I mentioned before: as long as the cost/weight of a link =20= >> is calculated in an unambiguous manner, all is well. > > Well yes, but we still have to see that unambiguous manner. MAybe =20 > it will come in later. Not really necessary. Unambiguous meaning "that link is associated =20 with one and only one cost" -> no problems. If the cost two disjoint =20 links are calculated using two different formula, still no problem. --Apple-Mail-49--909778848 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Oct 26, 2009, = at 4:15 PM, Alexandru Petrescu wrote:

Thomas = Heide Clausen a =E9crit :
On Oct 26, 2009, = at 3:37 PM, Michael Richardson wrote:

Alexandru asked where/how he can = calculate the ETX.
Thomas suggests that it is a = deployment issue, and then suggests looking = at
OSPF.
JP points out that OSPF and ISIS = use a static undefined link = metric.

I want to point out that OSPF = and ISIS are used in situations = where
there is no (or little significant) movement, and in = general the link
metric is configured by an = operator.

I do not want to have to = configure all the light switches in my = house.
I also do not expect the builder to configure ETX metrics = in them
either.

My impression is that RPL has to = use metrics that can generally = be
calculated by nodes themselves.  I also have no idea = how I would
calculate ETX, except by = observing what happened before.
....which is perfectly OK and, as far as I am concerned, = in line with what I mentioned before: as long as the cost/weight of a = link is calculated in an unambiguous manner, all is = well.

Well yes, but we still have to see that = unambiguous manner.  MAybe it will come in later.

Not = really necessary. Unambiguous meaning "that link is associated with one = and only one cost" -> no problems. If the cost two disjoint links are = calculated using two different formula, still no = problem.


= --Apple-Mail-49--909778848-- From gnawali@cs.stanford.edu Sat Oct 24 23:18:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E286E3A67EA for ; Sat, 24 Oct 2009 23:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IwgEIVOc0Mm for ; Sat, 24 Oct 2009 23:18:24 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2A03E3A67D8 for ; Sat, 24 Oct 2009 23:18:24 -0700 (PDT) Received: from mail-qy0-f203.google.com ([209.85.221.203]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1N1wR2-0007JU-4W for roll@ietf.org; Sat, 24 Oct 2009 23:18:36 -0700 Received: by qyk41 with SMTP id 41so773149qyk.29 for ; Sat, 24 Oct 2009 23:18:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.81.204 with SMTP id y12mr6538288qak.358.1256451515256; Sat, 24 Oct 2009 23:18:35 -0700 (PDT) In-Reply-To: References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> Date: Sat, 24 Oct 2009 23:18:35 -0700 Message-ID: From: Omprakash Gnawali To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 X-Mailman-Approved-At: Mon, 26 Oct 2009 09:25:31 -0700 Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 25 Oct 2009 06:19:01 -0000 On Sat, Oct 24, 2009 at 6:20 PM, Philip Levis wrote: > > On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: > >> Dear all, >> >> Please find below the new revision of the METRIC ID. As you know we had = to >> wait until RPL was stable enough to update this document. This revision = is >> thus a major update compared to the previous one. >> >> Few important comments >> 1) This revision of course takes into account the discussion that we had >> on the mailing list, >> 2) No metric is mandated. RPL implementation may use one or several of >> these metrics and we made them generic enough to be extensible. The use = of >> the metrics will be dictated by the OF. >> 3) IMPORTANT: there are many ways to use metrics. It could be as simple = as >> a cumulative hop counts or as complex as a hierarchical constraint based >> approach with multi-metric heuristics, both for nodes and links. We made= the >> design quite generic to support all cases. A RPL implementation may be >> EXTREMELY simple and compliant to the document or more complex to handle >> specific situations with less constrained nodes. > > > 4.3.2. =A0The Expected Transmission Count (ETX) Reliability Object > > =A0 The Expected Transmission Count (ETX) metric is defined as 1 / (Df * > =A0 Dr) where Df is the measured probability that a packet is received by > =A0 the neighbor and Dr is the measured probability that the > =A0 acknowledgment packet is successfully received. > > I would change this to say > > =A0 The Expected Transmission Count (ETX) metric is the number of > transmissions > =A0 a node expects to make to a destination in order to successfully deli= ver a > =A0 packet. > > The approach of 1 / (Df * Dr) is the approach used by Srcr, but there are > other algorithms for measuring it, such as 4B and EAR. I agree - we should not imply a particular method of estimating ETX, unless it is being presented as an example. However, 4B/EAR's approach also assume successful acknowledgment. - om_p From jvasseur@cisco.com Mon Oct 26 10:41:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3BA3A6B28 for ; Mon, 26 Oct 2009 10:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fc25Uzu7vYNO for ; Mon, 26 Oct 2009 10:41:24 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1ED4B3A6B4D for ; Mon, 26 Oct 2009 10:41:24 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIN85UpAZnwM/2dsb2JhbADBU4kgCI12gk4IgWkEizE X-IronPort-AV: E=Sophos;i="4.44,627,1249257600"; d="scan'208";a="64976698" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 26 Oct 2009 17:41:37 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QHfbsj018963; Mon, 26 Oct 2009 17:41:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:41:37 -0400 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 13:41:36 -0400 Message-Id: <66153FFD-664A-40F0-96FB-3A94F5C54452@cisco.com> From: JP Vasseur To: Omprakash Gnawali In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 18:41:34 +0100 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 17:41:36.0505 (UTC) FILETIME=[90D41690:01CA5663] Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 17:41:25 -0000 On Oct 25, 2009, at 7:18 AM, Omprakash Gnawali wrote: > On Sat, Oct 24, 2009 at 6:20 PM, Philip Levis > wrote: >> >> On Oct 24, 2009, at 5:31 AM, JP Vasseur wrote: >> >>> Dear all, >>> >>> Please find below the new revision of the METRIC ID. As you know >>> we had to >>> wait until RPL was stable enough to update this document. This >>> revision is >>> thus a major update compared to the previous one. >>> >>> Few important comments >>> 1) This revision of course takes into account the discussion that >>> we had >>> on the mailing list, >>> 2) No metric is mandated. RPL implementation may use one or >>> several of >>> these metrics and we made them generic enough to be extensible. >>> The use of >>> the metrics will be dictated by the OF. >>> 3) IMPORTANT: there are many ways to use metrics. It could be as >>> simple as >>> a cumulative hop counts or as complex as a hierarchical constraint >>> based >>> approach with multi-metric heuristics, both for nodes and links. >>> We made the >>> design quite generic to support all cases. A RPL implementation >>> may be >>> EXTREMELY simple and compliant to the document or more complex to >>> handle >>> specific situations with less constrained nodes. >> >> >> 4.3.2. The Expected Transmission Count (ETX) Reliability Object >> >> The Expected Transmission Count (ETX) metric is defined as 1 / >> (Df * >> Dr) where Df is the measured probability that a packet is >> received by >> the neighbor and Dr is the measured probability that the >> acknowledgment packet is successfully received. >> >> I would change this to say >> >> The Expected Transmission Count (ETX) metric is the number of >> transmissions >> a node expects to make to a destination in order to successfully >> deliver a >> packet. >> >> The approach of 1 / (Df * Dr) is the approach used by Srcr, but >> there are >> other algorithms for measuring it, such as 4B and EAR. > > I agree - we should not imply a particular method of estimating ETX, > unless it is being presented as an example. now explicitly stated in the rev-02. Thanks. JP > However, 4B/EAR's approach > also assume successful acknowledgment. > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Mon Oct 26 10:45:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C96D03A6AE7; Mon, 26 Oct 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026174501.C96D03A6AE7@core3.amsl.com> Date: Mon, 26 Oct 2009 10:45:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 17:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, D. Networks Filename : draft-ietf-roll-routing-metrics-03.txt Pages : 29 Date : 2009-10-26 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-routing-metrics-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26103900.I-D@ietf.org> --NextPart-- From pal@cs.stanford.edu Mon Oct 26 11:25:39 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC433A69A7 for ; Mon, 26 Oct 2009 11:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eToTFHG7oRCP for ; Mon, 26 Oct 2009 11:25:38 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 56FC63A6996 for ; Mon, 26 Oct 2009 11:25:38 -0700 (PDT) Received: from pat_11.qualcomm.com ([192.35.156.11] helo=[10.72.60.17]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N2UGM-0003NM-Lt; Mon, 26 Oct 2009 11:25:52 -0700 Message-Id: <6043694F-7CF5-4853-B900-09EE0F897586@cs.stanford.edu> From: Philip Levis To: Michael Richardson In-Reply-To: <9968.1256567872@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 11:25:49 -0700 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-Scan-Signature: f69c4e6b4bf914f22ae37cd490358bf0 Cc: roll ROLL Subject: Re: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 18:25:39 -0000 On Oct 26, 2009, at 7:37 AM, Michael Richardson wrote: > I do not want to have to configure all the light switches in my house. > I also do not expect the builder to configure ETX metrics in them > either. > > My impression is that RPL has to use metrics that can generally be > calculated by nodes themselves. I also have no idea how I would > calculate ETX, except by observing what happened before. There are three major algorithms out there: Srcr, 4B, and EAR. All have openly available source code. Srcr is the algorithm that was in the older text. Using periodic broadcasts with sequence numbers, nodes measure incoming packet delivery ratios using a sliding window. These broadcasts contain those incoming delivery ratios. A node therefore calculates its own incoming ratios and stores (heard from others) its outgoing ratios. It uses these ratios to estimate the probability of both a data packet and its link layer ack arriving successfully. There are follow-on modifications to Srcr, such as including variance in the cost. The Srcr algorithm is described in John Bicket's Mobicom 2003 paper entitled "A High Throughput Path Metric for Multi-Hop Wireless Routing." The Srcr implementation is described in his 2005 paper entitled "Architecture and Evaluation of an Unplanned 802.11b Mesh Network." The software can be downloaded from the MIT Roofnet site. 4B (the 4-bit link estimator) uses a hybrid approach. It uses broadcasts similarly to Srcr, and to seed its link table. These broadcast-based estimates, however, are supplemented by direct measurement of the delivery rate of data frames. Every time a node sends a packet, 4B keeps track of whether the packet was acknowledged. It uses this binary string to estimate the number of transmissions for a packet. The 4B estimator and its implementation are described in Rodrigo Fonseca's HotNets paper entitled "Four-Bit Wireless Link Estimation." The software can be downloaded as part of recent TinyOS distributions. EAR is another hybrid approach. Kyu-Han Kim's Mobicom 2006 paper "On Accurate Measurement of Link Quality In Multi-hop Wireless Mesh Networks" describes it, and his old web page has a source download for the Linux kernel. Hope this helps, Phil From alexandru.petrescu@gmail.com Mon Oct 26 11:35:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E41428C10D for ; Mon, 26 Oct 2009 11:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyIKIRV-MWNa for ; Mon, 26 Oct 2009 11:35:23 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 4B9FD3A69A3 for ; Mon, 26 Oct 2009 11:35:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9QIZUou013919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Oct 2009 19:35:30 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9QIZTcp011806; Mon, 26 Oct 2009 19:35:30 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9QIZTqt015812; Mon, 26 Oct 2009 19:35:29 +0100 Message-ID: <4AE5EBF1.9020605@gmail.com> Date: Mon, 26 Oct 2009 19:35:29 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> <6043694F-7CF5-4853-B900-09EE0F897586@cs.stanford.edu> In-Reply-To: <6043694F-7CF5-4853-B900-09EE0F897586@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] how to compute ETX (was: Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 18:35:24 -0000 Philip Levis a écrit : > > On Oct 26, 2009, at 7:37 AM, Michael Richardson wrote: > >> I do not want to have to configure all the light switches in my house. >> I also do not expect the builder to configure ETX metrics in them >> either. >> >> My impression is that RPL has to use metrics that can generally be >> calculated by nodes themselves. I also have no idea how I would >> calculate ETX, except by observing what happened before. > > There are three major algorithms out there: Srcr, 4B, and EAR. All have > openly available source code. > > Srcr is the algorithm that was in the older text. Using periodic > broadcasts with sequence numbers, nodes measure incoming packet delivery > ratios using a sliding window. These broadcasts contain those incoming > delivery ratios. A node therefore calculates its own incoming ratios and > stores (heard from others) its outgoing ratios. It uses these ratios to > estimate the probability of both a data packet and its link layer ack > arriving successfully. There are follow-on modifications to Srcr, such > as including variance in the cost. The Srcr algorithm is described in > John Bicket's Mobicom 2003 paper entitled "A High Throughput Path Metric > for Multi-Hop Wireless Routing." The Srcr implementation is described in > his 2005 paper entitled "Architecture and Evaluation of an Unplanned > 802.11b Mesh Network." The software can be downloaded from the MIT > Roofnet site. > > 4B (the 4-bit link estimator) uses a hybrid approach. It uses broadcasts > similarly to Srcr, and to seed its link table. These broadcast-based > estimates, however, are supplemented by direct measurement of the > delivery rate of data frames. Every time a node sends a packet, 4B keeps > track of whether the packet was acknowledged. It uses this binary string > to estimate the number of transmissions for a packet. The 4B estimator > and its implementation are described in Rodrigo Fonseca's HotNets paper > entitled "Four-Bit Wireless Link Estimation." The software can be > downloaded as part of recent TinyOS distributions. > > EAR is another hybrid approach. Kyu-Han Kim's Mobicom 2006 paper "On > Accurate Measurement of Link Quality In Multi-hop Wireless Mesh > Networks" describes it, and his old web page has a source download for > the Linux kernel. Phil - thanks, I set this review aside. It involves some link-layer information (a "reply" was received) and probabilities (Bernoulli? Gauss?). Putting them in IP format may not be straightforward (is a "reply" an ICMP Echo Reply? a TCP ACK?). It looks to me as if I wanted to implement a new TCP or NUD or so, not easy :-) Alex > > Hope this helps, > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From jvasseur@cisco.com Mon Oct 26 13:21:38 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBBE28C0DB; Mon, 26 Oct 2009 13:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.851 X-Spam-Level: X-Spam-Status: No, score=-9.851 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fitC8cYgAwAP; Mon, 26 Oct 2009 13:21:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DD11828C0F6; Mon, 26 Oct 2009 13:21:36 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAMeh5UqQ/uCWe2dsb2JhbACbOQEBFiQGpX+XO4Q/BA X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="52816126" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 20:21:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QKLnEP006223; Mon, 26 Oct 2009 20:21:49 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:21:49 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:21:48 +0100 Message-Id: From: JP Vasseur To: internet-drafts@ietf.org In-Reply-To: <20091026174501.C96D03A6AE7@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 21:21:48 +0100 References: <20091026174501.C96D03A6AE7@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Oct 2009 20:21:48.0907 (UTC) FILETIME=[F2443BB0:01CA5679] Cc: roll@ietf.org, i-d-announce@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 20:21:38 -0000 We just hanged the LQL semantics in order to use lower number for more reliable links (easier to minimize the path cost). JP. On Oct 26, 2009, at 6:45 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : Routing Metrics used for Path Calculation in Low > Power and Lossy Networks > Author(s) : J. Vasseur, D. Networks > Filename : draft-ietf-roll-routing-metrics-03.txt > Pages : 29 > Date : 2009-10-26 > > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Oct 26 13:50:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0823A69BB for ; Mon, 26 Oct 2009 13:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.548 X-Spam-Level: X-Spam-Status: No, score=-9.548 tagged_above=-999 required=5 tests=[AWL=1.051, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnUC71abzNRK for ; Mon, 26 Oct 2009 13:50:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 53D5E3A6935 for ; Mon, 26 Oct 2009 13:50:49 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisAAM+o5UqQ/uCWe2dsb2JhbACbOgEBFiQGphaXPYQ/BIsx X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="52817446" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 Oct 2009 20:51:01 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9QKp1Qn010616; Mon, 26 Oct 2009 20:51:01 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 21:51:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 21:50:57 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D80629A@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE92F2ED@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] PathDigest question Thread-Index: AcpT/UAuw+/gax1AQC6o+nDxJdqiqQADOWswAISE16AAGDwVYA== References: <1019652622.21495031256314353645.JavaMail.root@mail02.pantherlink.uwm.edu><1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D7A3344@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE92F2ED@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "Mukul Goyal" , "Anders Jagd" X-OriginalArrivalTime: 26 Oct 2009 20:51:01.0691 (UTC) FILETIME=[0701D8B0:01CA567E] Cc: roll Subject: Re: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 20:50:51 -0000 Hi Mathilde; A new path digest indicates a change in the preferred tree within the DAG that leads to this node. The source route path follows that tree.=20 So if the digest has changed, then the source route path is obsolete and must be reconstructed by sending a DAO. Pascal >-----Original Message----- >From: Mathilde Durvy (mdurvy) >Sent: lundi 26 octobre 2009 10:37 >To: Pascal Thubert (pthubert); Mukul Goyal; Anders Jagd >Cc: roll >Subject: RE: [Roll] PathDigest question > >Hi All, > >As I mention in my previous email, I don't see a clear justification for the PathDigest in the current draft. >The only place where the PathDigest is mentioned (outside of the DIO format) is Section 5.9.2.1. "Destination >advertisements may also be scheduled for sending when the PathDigest of the RA-DIO message has changed". > >In addition its current definition is not very clear to me. It says that the PathDigest is "the result of a >CRC-32c computation on a bit string obtained by appending the received value and the ordered set of DAG >parents of the LLN Node". Which received value? The one from the 'prefered' parent? As mentioned by Mukul, >does a change of PathDigest necessarily affects the receiving node? (it might not require any change >locally)... > >I would be happy to know if someone as a clear example highlighting the use of the PathDigest. Otherwise I >propose to add the removal of the PathDigest to the list of possible simplifications. > >Best, >Mathilde > > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) >Sent: vendredi, 23. octobre 2009 20:09 >To: Mukul Goyal >Cc: roll >Subject: Re: [Roll] PathDigest question > >Hi Mukul: > > A path digest tells that something has changed in the inwards path of this node and suggest that DAOs should >be sent. >This is mostly useful for source route. For stateful, all you need to know is that your parents change. >Also, this is mostly meaningful if the DAOs do not fan out since this is the digest of the preferred path. > >I think the current draft suggests to send DAOs over one parent (as opposed to fan out) but does not impose >anything on which that parent is (preferred or not). > >WRT trickle, if there's no source route, I agree with you and I do not see why that would require to do >anything. >If there's source route, then the exponential backoff of RAs might help ensure that all the children >reconstruct their path faster. > >What do you think? > >Pascal >>-----Original Message----- >>From: Mukul Goyal [mailto:mukul@uwm.edu] >>Sent: vendredi 23 octobre 2009 18:24 >>To: Pascal Thubert (pthubert) >>Cc: roll >>Subject: PathDigest question >> >>Hi Pascal and Tim >> >>I had a doubt about PathDigest. >> >>Sec 5.3.4.2 of rpl-3 draft says that when "The node receives a modified >>RA-DIO message from a DAG parent", its trickle timer is reset. >> >>Does it mean that the trickle timer is reset if a parent RIO shows modified PathDigest? >> >>Now, a modified PathDigest from the parent means that the parent's >>parent set changed. I was wondering why should it be an inconsistency >>for me. If information in this RIO does not force me to change my rank/parent_set/routing_metrics, I need not >reset my trickle timer. >> >>Now, parent's changed PathDigest may be used to trigger NA-DAOs to this >>parent (as the draft already mentions). But I am not sure why should it cause resetting of trickle timer >governing RA-DIOs. >> >>Thanks >>Mukul >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From root@core3.amsl.com Mon Oct 26 15:45:01 2009 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E98D33A682F; Mon, 26 Oct 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026224501.E98D33A682F@core3.amsl.com> Date: Mon, 26 Oct 2009 15:45:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 22:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-04.txt Pages : 82 Date : 2009-10-26 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of LLN routers, and support point-to- point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint-to- point traffic (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to-multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26153253.I-D@ietf.org> --NextPart-- From alexandru.petrescu@gmail.com Mon Oct 26 16:28:50 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABE8828C429 for ; Mon, 26 Oct 2009 16:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r-pnPKTKOPS for ; Mon, 26 Oct 2009 16:28:49 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5995628C163 for ; Mon, 26 Oct 2009 16:28:47 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 1FF29D4807B for ; Tue, 27 Oct 2009 00:28:58 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id D1804D48054 for ; Tue, 27 Oct 2009 00:28:55 +0100 (CET) Message-ID: <4AE630B6.5010600@gmail.com> Date: Tue, 27 Oct 2009 00:28:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: roll@ietf.org References: <20091026224501.E98D33A682F@core3.amsl.com> In-Reply-To: <20091026224501.E98D33A682F@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091026-0, 26/10/2009), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 23:28:50 -0000 draft-ietf-roll-rpl-04.txt says: > 9.1. RPL Control Message > > The RPL Control Message is an ICMP information message type that is > to be used carry DAG Information Objects, DAG Information > Solicitations, and Destination Advertisement Objects in support of > RPL operation. > > IANA has defined a ICMPv6 Type Number Registry. The suggested type > value for the RPL Control Message is 155, to be confirmed by IANA. Write TBA (To Be Assigned) instead of 155. One never knows who gets the 155 first. For example, 6LoWPAN ND may get it before RPL does, as the 6lowpan-nd draft implies: > 13. IANA Considerations > This document requires two new ICMPv6 message types: > o Node Registration (TBD1) > o Node Confirmation (TBD2) Besides, 155 decimal or hexa? (for future writings of figures, very useful to implementer to read hexa or decimal). Also, I wanted to say: ICMP messages often come in pairs: RS is type 133 decimal, RA is 134, and so on (EchoReq/Rep, RS/RA, MRA/MRS, etc.) Why not suggesting the same for RPL: RPL Req - type TBA, and RPL Resp - type TBA. Instead of making them different Codes. It's strange you talk about DAG Info Sol and Dst Adv Object as two different Codes, when they should be two different Types, as I feel it. It doesn't hurt to paste the URL of the current ICMPv6 assignments - it will get removed during IESG reviewing time anyways. If, by any chance one starts thinking that 155 approaches dangerously the limit of 255, and that you seem to apparently need a single "control" message (not a req/resp) then a possibility is to extend the RA by inventing a new flag in RA (via RFC5175 - I am a fan), and extending it with new options. > 9.4. DAG Information Object (DIO) Suboption > > IANA is requested to create a registry for the DIO Base Option > Suboptions > > +-------+------------------------------+---------------+ > | Value | Meaning | Reference | > +-------+------------------------------+---------------+ > | 0 | Pad1 - DIO Padding | This document | > | 1 | PadN - DIO suboption padding | This document | > | 2 | DAG Metric Container | This Document | > | 3 | Destination Prefix | This Document | > | 4 | DAG Timer Configuration | This Document | > +-------+------------------------------+---------------+ > > DAG Information Option (DIO) Base Option Suboptions New registry? How will it be allocated further? IETF Consensus action as the DIO Base Option? I believe it should be said here too. I must say I do not have a grasp on RPL overall, these are just simple remarks. Alex Internet-Drafts@ietf.org a écrit : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-04.txt > Pages : 82 > Date : 2009-10-26 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of LLN routers, and support point-to- point traffic > (between devices inside the LLN), point-to-multipoint traffic (from a > central control point to a subset of devices inside the LLN) and > multipoint-to- point traffic (from devices inside the LLN towards a > central control point). This document specifies the IPv6 Routing > Protocol for LLNs (RPL), which provides a mechanism whereby > multipoint-to-point traffic from devices inside the LLN towards a > central control point, as well as point-to-multipoint traffic from > the central control point to the devices inside the LLN, is > supported. Support for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From alexandru.petrescu@gmail.com Mon Oct 26 16:32:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1107728C443; Mon, 26 Oct 2009 16:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.663 X-Spam-Level: X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 895V-4abTebr; Mon, 26 Oct 2009 16:32:45 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 7964728C3E2; Mon, 26 Oct 2009 16:32:42 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id B16F6D480A6; Tue, 27 Oct 2009 00:32:53 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id A5942D48024; Tue, 27 Oct 2009 00:32:50 +0100 (CET) Message-ID: <4AE631A1.8070307@gmail.com> Date: Tue, 27 Oct 2009 00:32:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ROLL WG , 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 091026-0, 26/10/2009), Outbound message X-Antivirus-Status: Clean Subject: [Roll] IANA allocations for ICMP types X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 26 Oct 2009 23:32:46 -0000 ROLLers, 6LoWPANners, Are you groups both going to request new ICMP types for apparently similar functionalities (low-power PAN, low-power networks)? 6lowpan-nd draft says: > 13. IANA Considerations > This document requires two new ICMPv6 message types: > o Node Registration (TBD1) > o Node Confirmation (TBD2) RPL draft says: > 9.1. RPL Control Message > The RPL Control Message is an ICMP information message type that is > to be used carry DAG Information Objects, DAG Information > Solicitations, and Destination Advertisement Objects in support of > RPL operation. > IANA has defined a ICMPv6 Type Number Registry. The suggested type > value for the RPL Control Message is 155, to be confirmed by IANA. Or maybe the similarity is not that much that I see? Alex From pal@cs.stanford.edu Mon Oct 26 20:18:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C7C3A6863 for ; Mon, 26 Oct 2009 20:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivebe5nIzsLw for ; Mon, 26 Oct 2009 20:18:26 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 629F53A69DA for ; Mon, 26 Oct 2009 20:18:26 -0700 (PDT) Received: from [76.14.71.8] (helo=[192.168.1.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N2cZy-0000SB-Td; Mon, 26 Oct 2009 20:18:39 -0700 Message-Id: <947D3BE2-11A8-4520-9D19-FFEAFD34DBFC@cs.stanford.edu> From: Philip Levis To: Alexandru Petrescu In-Reply-To: <4AE5EBF1.9020605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Oct 2009 16:41:40 -0700 References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> <6043694F-7CF5-4853-B900-09EE0F897586@cs.stanford.edu> <4AE5EBF1.9020605@gmail.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: e1c7b331cb521454e7d22df558880a52 Cc: roll ROLL Subject: Re: [Roll] how to compute ETX (was: Fwd: I-D Action:draft-ietf-roll-routing-metrics-01.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 03:18:27 -0000 On Oct 26, 2009, at 11:35 AM, Alexandru Petrescu wrote: > Philip Levis a =E9crit : >> On Oct 26, 2009, at 7:37 AM, Michael Richardson wrote: >>> I do not want to have to configure all the light switches in my =20 >>> house. >>> I also do not expect the builder to configure ETX metrics in them >>> either. >>> >>> My impression is that RPL has to use metrics that can generally be >>> calculated by nodes themselves. I also have no idea how I would >>> calculate ETX, except by observing what happened before. >> There are three major algorithms out there: Srcr, 4B, and EAR. All =20= >> have openly available source code. >> Srcr is the algorithm that was in the older text. Using periodic =20 >> broadcasts with sequence numbers, nodes measure incoming packet =20 >> delivery ratios using a sliding window. These broadcasts contain =20 >> those incoming delivery ratios. A node therefore calculates its own =20= >> incoming ratios and stores (heard from others) its outgoing ratios. =20= >> It uses these ratios to estimate the probability of both a data =20 >> packet and its link layer ack arriving successfully. There are =20 >> follow-on modifications to Srcr, such as including variance in the =20= >> cost. The Srcr algorithm is described in John Bicket's Mobicom 2003 =20= >> paper entitled "A High Throughput Path Metric for Multi-Hop =20 >> Wireless Routing." The Srcr implementation is described in his 2005 =20= >> paper entitled "Architecture and Evaluation of an Unplanned 802.11b =20= >> Mesh Network." The software can be downloaded from the MIT Roofnet =20= >> site. >> 4B (the 4-bit link estimator) uses a hybrid approach. It uses =20 >> broadcasts similarly to Srcr, and to seed its link table. These =20 >> broadcast-based estimates, however, are supplemented by direct =20 >> measurement of the delivery rate of data frames. Every time a node =20= >> sends a packet, 4B keeps track of whether the packet was =20 >> acknowledged. It uses this binary string to estimate the number of =20= >> transmissions for a packet. The 4B estimator and its implementation =20= >> are described in Rodrigo Fonseca's HotNets paper entitled "Four-Bit =20= >> Wireless Link Estimation." The software can be downloaded as part =20 >> of recent TinyOS distributions. >> EAR is another hybrid approach. Kyu-Han Kim's Mobicom 2006 paper =20 >> "On Accurate Measurement of Link Quality In Multi-hop Wireless Mesh =20= >> Networks" describes it, and his old web page has a source download =20= >> for the Linux kernel. > > Phil - thanks, I set this review aside. > > It involves some link-layer information (a "reply" was received) and =20= > probabilities (Bernoulli? Gauss?). Putting them in IP format may =20 > not be straightforward (is a "reply" an ICMP Echo Reply? a TCP ACK?). The papers are pretty clear: as you're measuring a link's quality, you =20= measure link behavior. Measuring TCP acks doesn't help if you're only =20= sending UDP traffic. But measuring link layer frames does help. But the basic point here is that ETX, as a metric, has a clear =20 meaning. There's a variety of ways to calculate it, with differing =20 degrees of accuracy in different situations, but the desired value is =20= clear. Phil= From mdurvy@cisco.com Tue Oct 27 01:08:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2613C3A6878 for ; Tue, 27 Oct 2009 01:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.526 X-Spam-Level: X-Spam-Status: No, score=-9.526 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 142srUHX0GXZ for ; Tue, 27 Oct 2009 01:08:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A9EEC3A683C for ; Tue, 27 Oct 2009 01:08:51 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIAAANH5kqQ/uCWe2dsb2JhbACbOwEBFiQGo3aYHIQ/BIsz X-IronPort-AV: E=Sophos;i="4.44,631,1249257600"; d="scan'208";a="52843283" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 Oct 2009 08:09:04 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9R8940e009974; Tue, 27 Oct 2009 08:09:04 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 09:09:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 09:09:03 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE92F867@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D80629A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] PathDigest question Thread-Index: AcpT/UAuw+/gax1AQC6o+nDxJdqiqQADOWswAISE16AAGDwVYAAWq/cg References: <1019652622.21495031256314353645.JavaMail.root@mail02.pantherlink.uwm.edu><1041893305.21501211256315042042.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D7A3344@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE92F2ED@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D80629A@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "Mukul Goyal" , "Anders Jagd" X-OriginalArrivalTime: 27 Oct 2009 08:09:04.0267 (UTC) FILETIME=[BFB64DB0:01CA56DC] Cc: roll Subject: Re: [Roll] PathDigest question X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 08:08:53 -0000 Hi Pascal, Yes, I understand that. Two questions: - Can we be sure that packets follow a 'preferred path'? It seems to me that the only case where this is true is when pure source routing is used. =20 - The 'D' flag achieves the same effect but less reliably as pointed by Anders. Is that an acceptable tradeoff? Best, Mathilde =20 -----Original Message----- From: Pascal Thubert (pthubert)=20 Sent: lundi, 26. octobre 2009 21:51 To: Mathilde Durvy (mdurvy); 'Mukul Goyal'; 'Anders Jagd' Cc: 'roll' Subject: RE: [Roll] PathDigest question Hi Mathilde; A new path digest indicates a change in the preferred tree within the DAG that leads to this node. The source route path follows that tree.=20 So if the digest has changed, then the source route path is obsolete and must be reconstructed by sending a DAO. Pascal >-----Original Message----- >From: Mathilde Durvy (mdurvy) >Sent: lundi 26 octobre 2009 10:37 >To: Pascal Thubert (pthubert); Mukul Goyal; Anders Jagd >Cc: roll >Subject: RE: [Roll] PathDigest question > >Hi All, > >As I mention in my previous email, I don't see a clear justification for the PathDigest in the current draft. >The only place where the PathDigest is mentioned (outside of the DIO=20 >format) is Section 5.9.2.1. "Destination advertisements may also be scheduled for sending when the PathDigest of the RA-DIO message has changed". > >In addition its current definition is not very clear to me. It says=20 >that the PathDigest is "the result of a CRC-32c computation on a bit=20 >string obtained by appending the received value and the ordered set of=20 >DAG parents of the LLN Node". Which received value? The one from the=20 >'prefered' parent? As mentioned by Mukul, does a change of PathDigest necessarily affects the receiving node? (it might not require any change locally)... > >I would be happy to know if someone as a clear example highlighting the >use of the PathDigest. Otherwise I propose to add the removal of the PathDigest to the list of possible simplifications. > >Best, >Mathilde > > > >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of >Pascal Thubert (pthubert) >Sent: vendredi, 23. octobre 2009 20:09 >To: Mukul Goyal >Cc: roll >Subject: Re: [Roll] PathDigest question > >Hi Mukul: > > A path digest tells that something has changed in the inwards path of=20 >this node and suggest that DAOs should be sent. >This is mostly useful for source route. For stateful, all you need to know is that your parents change. >Also, this is mostly meaningful if the DAOs do not fan out since this is the digest of the preferred path. > >I think the current draft suggests to send DAOs over one parent (as=20 >opposed to fan out) but does not impose anything on which that parent is (preferred or not). > >WRT trickle, if there's no source route, I agree with you and I do not=20 >see why that would require to do anything. >If there's source route, then the exponential backoff of RAs might help >ensure that all the children reconstruct their path faster. > >What do you think? > >Pascal >>-----Original Message----- >>From: Mukul Goyal [mailto:mukul@uwm.edu] >>Sent: vendredi 23 octobre 2009 18:24 >>To: Pascal Thubert (pthubert) >>Cc: roll >>Subject: PathDigest question >> >>Hi Pascal and Tim >> >>I had a doubt about PathDigest. >> >>Sec 5.3.4.2 of rpl-3 draft says that when "The node receives a=20 >>modified RA-DIO message from a DAG parent", its trickle timer is reset. >> >>Does it mean that the trickle timer is reset if a parent RIO shows modified PathDigest? >> >>Now, a modified PathDigest from the parent means that the parent's=20 >>parent set changed. I was wondering why should it be an inconsistency=20 >>for me. If information in this RIO does not force me to change my=20 >>rank/parent_set/routing_metrics, I need not >reset my trickle timer. >> >>Now, parent's changed PathDigest may be used to trigger NA-DAOs to=20 >>this parent (as the draft already mentions). But I am not sure why=20 >>should it cause resetting of trickle timer >governing RA-DIOs. >> >>Thanks >>Mukul >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Oct 27 01:54:06 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5009928C197 for ; Tue, 27 Oct 2009 01:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VCxJzGfnxmA for ; Tue, 27 Oct 2009 01:54:05 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 2AFAF28C192 for ; Tue, 27 Oct 2009 01:54:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9R8rp7U002864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 09:53:51 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9R8rp6S018209; Tue, 27 Oct 2009 09:53:51 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9R8rnHe011753; Tue, 27 Oct 2009 09:53:51 +0100 Message-ID: <4AE6B51D.1000003@gmail.com> Date: Tue, 27 Oct 2009 09:53:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Philip Levis References: <20091024103001.C51923A67F3@core3.amsl.com> <7BDABE4F-CEAB-4470-96A4-6B48FA31E823@cisco.com> <431A991E-6355-48A8-AF54-E39F4D5C12AF@cisco.com> <4AE563D9.8000200@gmail.com> <3F7B2E93-2474-4D17-8B8A-BE70677B6B08@cisco.com> <4AE56886.2070101@gmail.com> <3FF90C60-3637-4D02-98E5-C304480FAEA8@cisco.com> <9968.1256567872@marajade.sandelman.ca> <6043694F-7CF5-4853-B900-09EE0F897586@cs.stanford.edu> <4AE5EBF1.9020605@gmail.com> <947D3BE2-11A8-4520-9D19-FFEAFD34DBFC@cs.stanford.edu> In-Reply-To: <947D3BE2-11A8-4520-9D19-FFEAFD34DBFC@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll ROLL Subject: Re: [Roll] how to compute ETX X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 08:54:06 -0000 Philip Levis a écrit : > On Oct 26, 2009, at 11:35 AM, Alexandru Petrescu wrote: > >> Philip Levis a écrit : >>> On Oct 26, 2009, at 7:37 AM, Michael Richardson wrote: >>>> I do not want to have to configure all the light switches in my house. >>>> I also do not expect the builder to configure ETX metrics in them >>>> either. >>>> >>>> My impression is that RPL has to use metrics that can generally be >>>> calculated by nodes themselves. I also have no idea how I would >>>> calculate ETX, except by observing what happened before. >>> There are three major algorithms out there: Srcr, 4B, and EAR. All >>> have openly available source code. >>> Srcr is the algorithm that was in the older text. Using periodic >>> broadcasts with sequence numbers, nodes measure incoming packet >>> delivery ratios using a sliding window. These broadcasts contain >>> those incoming delivery ratios. A node therefore calculates its own >>> incoming ratios and stores (heard from others) its outgoing ratios. >>> It uses these ratios to estimate the probability of both a data >>> packet and its link layer ack arriving successfully. There are >>> follow-on modifications to Srcr, such as including variance in the >>> cost. The Srcr algorithm is described in John Bicket's Mobicom 2003 >>> paper entitled "A High Throughput Path Metric for Multi-Hop Wireless >>> Routing." The Srcr implementation is described in his 2005 paper >>> entitled "Architecture and Evaluation of an Unplanned 802.11b Mesh >>> Network." The software can be downloaded from the MIT Roofnet site. >>> 4B (the 4-bit link estimator) uses a hybrid approach. It uses >>> broadcasts similarly to Srcr, and to seed its link table. These >>> broadcast-based estimates, however, are supplemented by direct >>> measurement of the delivery rate of data frames. Every time a node >>> sends a packet, 4B keeps track of whether the packet was >>> acknowledged. It uses this binary string to estimate the number of >>> transmissions for a packet. The 4B estimator and its implementation >>> are described in Rodrigo Fonseca's HotNets paper entitled "Four-Bit >>> Wireless Link Estimation." The software can be downloaded as part of >>> recent TinyOS distributions. >>> EAR is another hybrid approach. Kyu-Han Kim's Mobicom 2006 paper "On >>> Accurate Measurement of Link Quality In Multi-hop Wireless Mesh >>> Networks" describes it, and his old web page has a source download >>> for the Linux kernel. >> >> Phil - thanks, I set this review aside. >> >> It involves some link-layer information (a "reply" was received) and >> probabilities (Bernoulli? Gauss?). Putting them in IP format may not >> be straightforward (is a "reply" an ICMP Echo Reply? a TCP ACK?). > > The papers are pretty clear: as you're measuring a link's quality, you > measure link behavior. Measuring TCP acks doesn't help if you're only > sending UDP traffic. But measuring link layer frames does help. Ah, I suppose they use something like wifi's "ASSOCIATION RESPONSE" or "PROBE RESPONSE" when they say a "reply". Do they take into account the length of this reply? (as various reply messages in WiFi have various lenghts) and probing with short messages may prove a higher success rate than long messages. > But the basic point here is that ETX, as a metric, has a clear meaning. > There's a variety of ways to calculate it, with differing degrees of > accuracy in different situations, but the desired value is clear. Ok. I have to read their articles and code before agreeing they're clear. Currently I think the desire is clear, not the desired value. Alex > > Phil From wintert@acm.org Tue Oct 27 06:31:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B3B28C1A4 for ; Tue, 27 Oct 2009 06:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.625 X-Spam-Level: X-Spam-Status: No, score=-101.625 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, MISSING_HEADERS=1.292, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB6EDjRFc0el for ; Tue, 27 Oct 2009 06:31:16 -0700 (PDT) Received: from smtp108.prem.mail.ac4.yahoo.com (smtp108.prem.mail.ac4.yahoo.com [76.13.13.47]) by core3.amsl.com (Postfix) with SMTP id 104C228C20D for ; Tue, 27 Oct 2009 06:31:15 -0700 (PDT) Received: (qmail 74741 invoked from network); 27 Oct 2009 13:31:27 -0000 Received: from 206-83-249-194.edurostream.com (wintert@206.83.249.194 with plain) by smtp108.prem.mail.ac4.yahoo.com with SMTP; 27 Oct 2009 06:31:27 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: D_S7m24VM1m3XC9SepOQ6P2KTkSLxQM45cPQ3aa2tDvuSW9gTySHqCaPcvwjiom74gKdyWGItX.cW9ggfgDR3t6cVi.B.70zVZqbYurNsObRa_r0wZRZuTKqcZoCwnSBVsiPp.6C2JWUhdNN6zvFPaGU5Rdyo_pAEPO4Oq8_6teBfVBHmrUizICfDUXWyT06khRL23F5WlwiJH..Hjvs1C4nHBKvB38nGOa.Lq9w0mZVZkwPu4nYsZ381DAMmQTJYTpSI4aiQQFOKLP51biPpBZw6ZvlQcz4IN_QXl6FJrBLwTyGxhSKlyMkNYbxoyBoKEPzGrTGt8XLAvO29Ljt6Jg.NDf7_2_upEXbxj4JYNs35K..p88vBLrCYQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AE6F629.7070707@acm.org> Date: Tue, 27 Oct 2009 09:31:21 -0400 From: Tim Winter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: roll@ietf.org References: <20091026224501.E98D33A682F@core3.amsl.com> In-Reply-To: <20091026224501.E98D33A682F@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 13:31:17 -0000 WG, In this revision we did incorporate much of the recent feedback from the list, including - Remove recommendations for DAG splitting/merging (detach/float/reattach) - Remove Held-Up state and related procedures - Remove Held-Down state and related procedures - Clarified that a DAG Instance is in support of a single application objective / optimization, and that RPL specifies operation in a single DAG Instance - ICMPv6 message type proposed to carry DIO/DAO message + DIO/DAO revised (OCP now comes from Metric Container) - Updated DIO suboptions to be consistent with metrics draft (16 bit length) - Added use of flow label to specify DAG Instance and allow for loop detection - Misc. editorial changes We are still working to provide an FSM presentation of RPL. Regards -RPL Authors Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-04.txt > Pages : 82 > Date : 2009-10-26 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of LLN routers, and support point-to- point traffic > (between devices inside the LLN), point-to-multipoint traffic (from a > central control point to a subset of devices inside the LLN) and > multipoint-to- point traffic (from devices inside the LLN towards a > central control point). This document specifies the IPv6 Routing > Protocol for LLNs (RPL), which provides a mechanism whereby > multipoint-to-point traffic from devices inside the LLN towards a > central control point, as well as point-to-multipoint traffic from > the central control point to the devices inside the LLN, is > supported. Support for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From sung.lee@us.fujitsu.com Tue Oct 27 09:57:36 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF4128C0EC for ; Tue, 27 Oct 2009 09:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.224 X-Spam-Level: X-Spam-Status: No, score=-106.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLxxCH+GiNgJ for ; Tue, 27 Oct 2009 09:57:35 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 2C6C83A67E2 for ; Tue, 27 Oct 2009 09:57:35 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9RGwlih021757 for ; Tue, 27 Oct 2009 09:58:48 -0700 (PDT) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9RGwl0a021754 for ; Tue, 27 Oct 2009 09:58:47 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.8/8.13.8) with ESMTP id n9RGvmbH028562 for ; Tue, 27 Oct 2009 09:57:48 -0700 (PDT) Received: from [10.157.253.51] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n9RGvmN23666 for ; Tue, 27 Oct 2009 09:57:48 -0700 (PDT) Message-ID: <4AE7268A.5060209@us.fujitsu.com> Date: Tue, 27 Oct 2009 12:57:46 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] RPL Metric ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 16:57:36 -0000 Philip, Sorry for my late response. I have been quite swamped with work and travels. I read your paper and I liked it. I like your concept of using information from all three layers. Although our approach is not as "formalized" as yours, I think fundamentally we do share some similarity. I would say that one difference is that we try to reflect the existence of loop in the estimation. Since we do actively check for loop existence, we reflect that into the estimation value by penalizing it. But please note that we do not actively try to remove the loop when we find it. Our experience is that by reflecting the existence of loops in the estimation/metric, it sorts itself out over time. Thanks for sharing your paper. Best regards, Sung roll-request@ietf.org wrote: > > Message: 2 > Date: Thu, 15 Oct 2009 09:05:23 -0700 > From: Philip Levis > Subject: Re: [Roll] RPL Metric ID > To: Sung Lee > Cc: roll@ietf.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Oct 15, 2009, at 7:20 AM, Sung Lee wrote: > > >> JP and WG members, >> >> This may be considered link reliability. >> But in our experience, we found the following information very helpful >> in improving the stability of network and also (and you could say) in >> avoiding loops as well. >> >> We use what we call 'W' (weight). >> When we forward data packet, we require per-hop ACK. >> When we receive ACK, we adjust the new W to be old W -1 (W_new = >> W_old - 1). >> When we don't receive ACK, we adjust the new W to be old W + 1 >> (W_old = >> W_old +1). >> When we detect a loop, we adjust the W value to MAX. >> >> We have experimented MAX value based on real system, MAX value of 10 >> seems to be a good value to start with. >> >> Now this can be combined with other metric values you are all >> discussing. We have experimented quite a lot with combing several >> metrics with the above weight in determining the path, which so far >> seems to work in our system. >> For instance, the other metric values you are discussing (such as link >> quality, RSSI, and/or everything else - please note this can be as >> simple as hop count, RSSI, or whatever the WG determines) can be used >> with along with W value to determine. >> >> I am interested in what the WG thinks of using this 'W' as part of >> metric for RPL. >> > > Sung, > > I think the general approach of directly measuring the datapath is a > great way to have fast and accurate link estimation. CTP's 4-bit link > estimator (4B) has some similarities to what you describe, although it > smoothes estimates much more: I'd be concerned about excessive > instability in the above algorithm, as note that you can't measure a > link you're not using. > > Have you read the 4-bit paper? You can find it at http://sing.stanford.edu/singpubs.html > > Phil > > > > > From mcr@marajade.sandelman.ca Tue Oct 27 11:00:43 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CC4E3A6862 for ; Tue, 27 Oct 2009 11:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.077 X-Spam-Level: X-Spam-Status: No, score=0.077 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KU8cg2ZT+TT for ; Tue, 27 Oct 2009 11:00:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 883F03A67D9 for ; Tue, 27 Oct 2009 11:00:42 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 7452F342B3 for ; Tue, 27 Oct 2009 18:06:27 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 8CC7F4E803 for ; Tue, 27 Oct 2009 14:00:55 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <4AE6F629.7070707@acm.org> References: <20091026224501.E98D33A682F@core3.amsl.com> <4AE6F629.7070707@acm.org> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 27 Oct 2009 14:00:55 -0400 Message-ID: <6526.1256666455@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 18:00:43 -0000 >>>>> "Tim" == Tim Winter writes: Tim> - Added use of flow label to specify DAG Instance and allow for loop detection Thanks, I think this will help people link things together. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From alexandru.petrescu@gmail.com Tue Oct 27 11:22:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52EAA3A698F for ; Tue, 27 Oct 2009 11:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iVxuCPbuzIJ for ; Tue, 27 Oct 2009 11:22:21 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 5A4533A691E for ; Tue, 27 Oct 2009 11:22:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9RIMYTF005941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 19:22:34 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9RIMYnH000787; Tue, 27 Oct 2009 19:22:34 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9RIMXCK022298; Tue, 27 Oct 2009 19:22:34 +0100 Message-ID: <4AE73A69.4080406@gmail.com> Date: Tue, 27 Oct 2009 19:22:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Richardson References: <20091026224501.E98D33A682F@core3.amsl.com> <4AE6F629.7070707@acm.org> <6526.1256666455@marajade.sandelman.ca> In-Reply-To: <6526.1256666455@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 18:22:22 -0000 Michael Richardson a écrit : >>>>>> "Tim" == Tim Winter writes: > Tim> - Added use of flow label to specify DAG Instance and allow for loop detection > > Thanks, I think this will help people link things together. I think calling it a "flow label" may collide with the flow label field of IPv6 base header. Let me tell you why I say so. I recently went through an implementaiton exercise where Route Lifetime and Router Lifetime were mistaken one for the other, because they're close enough. Just a remark. Alex From mcr@marajade.sandelman.ca Tue Oct 27 11:41:41 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0923A687E for ; Tue, 27 Oct 2009 11:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujG6AA4ZNaul for ; Tue, 27 Oct 2009 11:41:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 91CAC3A63EC for ; Tue, 27 Oct 2009 11:41:40 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 64BAE3428D; Tue, 27 Oct 2009 18:47:26 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 5C9D04E803; Tue, 27 Oct 2009 14:41:54 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4AE73A69.4080406@gmail.com> References: <20091026224501.E98D33A682F@core3.amsl.com> <4AE6F629.7070707@acm.org> <6526.1256666455@marajade.sandelman.ca> <4AE73A69.4080406@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 14:41:54 -0400 Message-ID: <9254.1256668914@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 18:41:41 -0000 >>>>> "Alexandru" =3D=3D Alexandru Petrescu = writes: Alexandru> Michael Richardson a =E9crit : >>>>>>> "Tim" =3D=3D Tim Winter writes: Tim> - Added use of flow label to specify DAG Instance and allow for Tim> loop detection >> Thanks, I think this will help people link things together. Alexandru> I think calling it a "flow label" may collide with the Alexandru> flow label field of IPv6 base header. That's exactly what we need to use. The IPv6 flow label was intended precisely for this purpose. --=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 From alexandru.petrescu@gmail.com Tue Oct 27 11:49:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E90D28C110 for ; Tue, 27 Oct 2009 11:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fISoy1AMGyLQ for ; Tue, 27 Oct 2009 11:49:26 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 616B728C130 for ; Tue, 27 Oct 2009 11:49:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9RInc5o032021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Oct 2009 19:49:38 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9RInceW003230; Tue, 27 Oct 2009 19:49:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9RInbtQ026289; Tue, 27 Oct 2009 19:49:37 +0100 Message-ID: <4AE740C1.6000308@gmail.com> Date: Tue, 27 Oct 2009 19:49:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Michael Richardson References: <20091026224501.E98D33A682F@core3.amsl.com> <4AE6F629.7070707@acm.org> <6526.1256666455@marajade.sandelman.ca> <4AE73A69.4080406@gmail.com> <9254.1256668914@marajade.sandelman.ca> In-Reply-To: <9254.1256668914@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 27 Oct 2009 18:49:27 -0000 Michael Richardson a écrit : >>>>>> "Alexandru" == Alexandru Petrescu writes: > Alexandru> Michael Richardson a écrit : > >>>>>>> "Tim" == Tim Winter writes: > Tim> - Added use of flow label to specify DAG Instance and allow for > Tim> loop detection > >> Thanks, I think this will help people link things together. > > Alexandru> I think calling it a "flow label" may collide with the > Alexandru> flow label field of IPv6 base header. > > That's exactly what we need to use. > The IPv6 flow label was intended precisely for this purpose. Let's go this way then. Alex > From jabeille@cisco.com Wed Oct 28 05:51:56 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44EFA3A68E6 for ; Wed, 28 Oct 2009 05:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXXiJqabRCoI for ; Wed, 28 Oct 2009 05:51:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1FBC53A69C6 for ; Wed, 28 Oct 2009 05:51:54 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAAE/b50qQ/uCWe2dsb2JhbACCJS2YbAEBFiQGpXyYNoQ/BA X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="scan'208,217";a="52981882" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 12:52:09 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SCq9Yj026512 for ; Wed, 28 Oct 2009 12:52:09 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:52:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA57CD.756B8966" Date: Wed, 28 Oct 2009 13:52:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: clarification about source routing Thread-Index: AcpXzXTFLF/Sp6ScTYy4IDU5YIEfaw== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 28 Oct 2009 12:52:08.0544 (UTC) FILETIME=[758B0E00:01CA57CD] Subject: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 12:51:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57CD.756B8966 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 just a clarification: it seems that when using source routing, the routes are recorded when DAOs are sent, up to the DAG root. It means that routes are recorded proactively.=20 Until now, I thought that we would record routes on data (layer 5) packets. Hence I thought source routing + record route would only work in MP2P (meaning when a smart object inititates the traffic) and that it would not work if the DAG root (or another smart object, P2P mode) wants to initiate traffic. I think this was the understanding of others in ROLLE meeting. =20 if my (new) understanding is correct, record route is proactive, done with control packets (DAOs), hence this enables P2MP, MP2P, P2P.=20 Is my understanding correct? =20 Best, Julien ------_=_NextPart_001_01CA57CD.756B8966 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
just a = clarification:
it = seems that when=20 using source routing, the routes are recorded when DAOs are sent, up to = the DAG=20 root. It means that routes are recorded proactively. =
Until = now, I thought=20 that we would record routes on data (layer 5) packets. Hence I thought = source=20 routing + record route would only work in MP2P (meaning when a smart = object=20 inititates the traffic) and that it would not work if the DAG root (or = another=20 smart object, P2P mode) wants to initiate traffic. I think this was the=20 understanding of others in ROLLE meeting.
 
if my = (new)=20 understanding is correct, record route is proactive, done with control = packets=20 (DAOs), hence this enables P2MP, MP2P, P2P.
Is my = understanding=20 correct?
 
Best,
Julien
------_=_NextPart_001_01CA57CD.756B8966-- From jvasseur@cisco.com Wed Oct 28 05:59:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E4DE3A69DF for ; Wed, 28 Oct 2009 05:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.873 X-Spam-Level: X-Spam-Status: No, score=-7.873 tagged_above=-999 required=5 tests=[AWL=-1.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6pHTE-QD+oM for ; Wed, 28 Oct 2009 05:59:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6B52E3A6808 for ; Wed, 28 Oct 2009 05:59:12 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALfc50qrRN+K/2dsb2JhbADBeJg3hD8E X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="scan'208";a="218675074" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2009 12:59:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9SCxPoX028724 for ; Wed, 28 Oct 2009 12:59:27 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:59:14 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 13:59:14 +0100 Message-Id: <26C2DF71-BCC0-4927-BC21-44BE062313E9@cisco.com> From: JP Vasseur To: roll ROLL Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 13:59:13 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 12:59:14.0175 (UTC) FILETIME=[733D30F0:01CA57CE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16974.007 X-TM-AS-Result: No--6.083800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Need clarification ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 12:59:13 -0000 Dear all, As Tim pointed out, RPL Rev-04 did simplify the protocol quite significantly, which was our WG's main objective. There are still areas where the text may not be sufficiently detailed (I did receive questions from several implementers showing a lack of clarity). Could you please review and let us know where the text is not sufficiently detailed or ambiguous ? This way we could address any potential lack of clarity in rev-05 + add the FSM as promised. I'll start opening tickets, now is probably a good time. Thanks. JP. From jvasseur@cisco.com Wed Oct 28 06:00:49 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F423128C19C for ; Wed, 28 Oct 2009 06:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.836 X-Spam-Level: X-Spam-Status: No, score=-7.836 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOyc5XM6KAk0 for ; Wed, 28 Oct 2009 06:00:47 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BAF6828C125 for ; Wed, 28 Oct 2009 06:00:47 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAOPd50qrRN+K/2dsb2JhbACCJC6/I5g3hD8E X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="scan'208,217";a="218675693" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 28 Oct 2009 13:01:03 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9SCxpCC028836 for ; Wed, 28 Oct 2009 13:01:02 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:01:01 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:01:01 +0100 Message-Id: <26AFD2D3-0AA0-4AF7-BD9A-12AC9AEC555C@cisco.com> From: JP Vasseur To: Julien Abeille (jabeille) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-12--745213484 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 14:01:00 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 13:01:01.0582 (UTC) FILETIME=[B34232E0:01CA57CE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16974.007 X-TM-AS-Result: No--21.103300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 13:00:49 -0000 --Apple-Mail-12--745213484 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Julien, On Oct 28, 2009, at 1:52 PM, Julien Abeille (jabeille) wrote: > Hi all, > > just a clarification: > it seems that when using source routing, the routes are recorded > when DAOs are sent, up to the DAG root Up to a point where routes can be stored, which may or may not be the DAG Root. > . It means that routes are recorded proactively. > Until now, I thought that we would record routes on data (layer 5) > packets. Hence I thought source routing + record route would only > work in MP2P (meaning when a smart object inititates the traffic) > and that it would not work if the DAG root (or another smart object, > P2P mode) wants to initiate traffic. I think this was the > understanding of others in ROLLE meeting. > > if my (new) understanding is correct, record route is proactive, > done with control packets (DAOs), hence this enables P2MP, MP2P, P2P. > Is my understanding correct? Yes. JP. > > Best, > Julien > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-12--745213484 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Julien,

On = Oct 28, 2009, at 1:52 PM, Julien Abeille (jabeille) wrote:

=
Hi= all,
 
just a = clarification:
it seems = that when using source routing, the routes are recorded when DAOs are = sent, up to the DAG = root

Up to a = point where routes can be stored, which may or may not be the DAG = Root.

. It means = that routes are recorded proactively.
Until now, = I thought that we would record routes on data (layer 5) packets. Hence I = thought source routing + record route would only work in MP2P (meaning = when a smart object inititates the traffic) and that it would not work = if the DAG root (or another smart object, P2P mode) wants to initiate = traffic. I think this was the understanding of others in ROLLE = meeting.
 
if my (new) = understanding is correct, record route is proactive, done with control = packets (DAOs), hence this enables P2MP, MP2P, P2P.
=
Is= my understanding = correct?

Yes.

JP.

=
 
Best,
Julien
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-12--745213484-- From trac@tools.ietf.org Wed Oct 28 06:04:29 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 036813A69DF for ; Wed, 28 Oct 2009 06:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ2eATY9xbz4 for ; Wed, 28 Oct 2009 06:04:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 513C33A698B for ; Wed, 28 Oct 2009 06:04:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N38Ce-0002Fg-SP; Wed, 28 Oct 2009 06:04:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Wed, 28 Oct 2009 13:04:40 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/1 Message-ID: <055.33c31e423c5be667ade6c9932019e299@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Wed, 28 Oct 2009 06:05:08 -0700 Cc: roll@ietf.org Subject: [Roll] [roll] #1: Test X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:04:29 -0000 #1: Test --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: JP Vasseur Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Test - Please Ignore -- Ticket URL: roll From trac@tools.ietf.org Wed Oct 28 06:14:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F4F3A6934 for ; Wed, 28 Oct 2009 06:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7JM-SoRxyg4 for ; Wed, 28 Oct 2009 06:14:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 182F53A697E for ; Wed, 28 Oct 2009 06:14:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N38MJ-000831-Jl; Wed, 28 Oct 2009 06:14:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Wed, 28 Oct 2009 13:14:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/1#comment:1 Message-ID: <064.71ff62c0a62a47e839ed8447cb50bebd@tools.ietf.org> References: <055.33c31e423c5be667ade6c9932019e299@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <055.33c31e423c5be667ade6c9932019e299@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #1: Test X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:14:27 -0000 #1: Test --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: JP Vasseur Type: enhancement | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Changes (by jpv@…): * cc: roll@… (added) -- Ticket URL: roll From mdurvy@cisco.com Wed Oct 28 06:15:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CFF3A6930 for ; Wed, 28 Oct 2009 06:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.892 X-Spam-Level: X-Spam-Status: No, score=-8.892 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u17vH4eslvY6 for ; Wed, 28 Oct 2009 06:15:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 561CC3A68E6 for ; Wed, 28 Oct 2009 06:15:18 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: ATT3117764.txt : 127 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AncAACvh50qQ/uCWe2dsb2JhbACCJS0hmEsBARYkBqYAmDQChD0E X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="gif'147?txt'147?scan'147,208,217,147";a="52985957" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 13:15:30 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SDFT6a004345 for ; Wed, 28 Oct 2009 13:15:29 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:15:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA57D0.B8A798FF" Date: Wed, 28 Oct 2009 14:15:28 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE93022A@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need Clarification: Candidate neighbors Thread-Index: AcpNicNBpeCtGxHYTlaotvx1oJIeYwKROfwA From: "Mathilde Durvy (mdurvy)" To: "roll" X-OriginalArrivalTime: 28 Oct 2009 13:15:29.0884 (UTC) FILETIME=[B8CE91C0:01CA57D0] Subject: [Roll] Need Clarification: Candidate neighbors X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 13:15:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57D0.B8A798FF Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_002_01CA57D0.B8A798FF" ------_=_NextPart_002_01CA57D0.B8A798FF Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01CA57D0.B8A798FF" ------_=_NextPart_003_01CA57D0.B8A798FF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, =20 I'm resending this email as I would like to clarify the concept of = candidate neighbors (see original email below). Could you add it to your = open tickets?=20 Candidate neighbors are "neighbors that are discovered by the ND = mechanism and further qualified as statistically stable". Hence my = opinion is that we can reuse the ND neighbor cache with maybe an = additional flag (characterising the stability) to maintain candidate = neighbors. I don't think we necessarily need a separate data structure, = is my understanding correct? =20 Best, Mathilde ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Mathilde Durvy (mdurvy) Sent: jeudi, 15. octobre 2009 13:22 To: roll@ietf.org Subject: [Roll] Candidate neighbors Hi All, =20 I'm trying to understand better the need for 'candidate neighbors'. My current understanding is that 'candidate parents' (RPL) are a subset = of 'candidate neighbors' (RPL) which are themselves a subset of = 'neighbors' (ND). My question is, do we really need to maintain 'candidate neighbors' in = addition to 'neighbors' and 'candidate parents'? If yes what should be the data structure and corresponding fields for = 'candidate neighbors'? Section 5.2.1 gives very little details... I have a feeling that 'candidate neighbors' could simply be the set of = REACHABLE 'neighbors' and be associated with a DAG once they become = candidate parents. =20 Best, Mathilde =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_003_01CA57D0.B8A798FF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP,
 
I'm resending this email as I would like to=20 clarify the concept of candidate neighbors (see original email = below).=20 Could you add it to your open tickets? 
Candidate neighbors are "neighbors that are = discovered=20 by the ND mechanism and further qualified as statistically stable". = Hence=20 my opinion is that we can reuse the ND = neighbor cache=20 with maybe an additional flag (characterising the stability) to = maintain=20 candidate neighbors. I don't think we necessarily need a separate data=20 structure, is my understanding correct?
 
Best,
Mathilde
From:=20 roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of=20 Mathilde Durvy (mdurvy)
Sent: jeudi, 15. octobre 2009=20 13:22
To: roll@ietf.org
Subject: [Roll] Candidate=20 neighbors

Hi=20 All,
 
I'm = trying to=20 understand better the need for 'candidate = neighbors'.
My current = understanding is=20 that 'candidate parents' (RPL) are a subset of 'candidate neighbors' = (RPL) which=20 are themselves a subset of 'neighbors' (ND).
My = question is, do=20 we really need to maintain 'candidate neighbors' in addition to = 'neighbors' and=20 'candidate parents'?
If yes = what should=20 be the data structure and corresponding fields for 'candidate = neighbors'?=20 Section 5.2.1 gives very little details...
I have = a feeling=20 that 'candidate neighbors' could simply be the set of REACHABLE = 'neighbors' and=20 be associated with a DAG once they become candidate=20 parents.
 
Best,
Mathilde
 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_003_01CA57D0.B8A798FF-- ------_=_NextPart_002_01CA57D0.B8A798FF Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_002_01CA57D0.B8A798FF Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_002_01CA57D0.B8A798FF-- ------_=_NextPart_001_01CA57D0.B8A798FF Content-Type: text/plain; name="ATT3117764.txt" Content-Transfer-Encoding: base64 Content-Description: ATT3117764.txt Content-Disposition: inline; filename="ATT3117764.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCg== ------_=_NextPart_001_01CA57D0.B8A798FF-- From trac@tools.ietf.org Wed Oct 28 06:16:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6453A696F for ; Wed, 28 Oct 2009 06:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkGevptYWE13 for ; Wed, 28 Oct 2009 06:16:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 81A873A69C6 for ; Wed, 28 Oct 2009 06:16:19 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N38OA-0003rH-Pz; Wed, 28 Oct 2009 06:16:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Wed, 28 Oct 2009 13:16:34 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/1#comment:2 Message-ID: <064.c82937f2ffb74236a34af62217370f22@tools.ietf.org> References: <055.33c31e423c5be667ade6c9932019e299@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <055.33c31e423c5be667ade6c9932019e299@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #1: Test X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:16:20 -0000 #1: Test --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: JP Vasseur Type: enhancement | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed -- Ticket URL: roll From trac@tools.ietf.org Wed Oct 28 06:18:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910643A696F for ; Wed, 28 Oct 2009 06:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgkWlUzViqbQ for ; Wed, 28 Oct 2009 06:18:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id DFE473A68E6 for ; Wed, 28 Oct 2009 06:18:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N38Pq-0001YL-FC; Wed, 28 Oct 2009 06:18:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Wed, 28 Oct 2009 13:18:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/2 Message-ID: <055.6da83c00e1eff33bffa91eea8fe65ae4@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #2: test - please ignore X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:18:03 -0000 #2: test - please ignore --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: new Priority: trivial | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- -- Ticket URL: roll From trac@tools.ietf.org Wed Oct 28 06:18:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CB03A69AB for ; Wed, 28 Oct 2009 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlBlfs2dkIHe for ; Wed, 28 Oct 2009 06:18:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id B805528C16B for ; Wed, 28 Oct 2009 06:18:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N38QY-0003IP-2T; Wed, 28 Oct 2009 06:19:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: jpv@cisco.com X-Trac-Project: roll Date: Wed, 28 Oct 2009 13:19:02 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/2#comment:1 Message-ID: <064.9852e3dab8019d85948b47113c2cbe57@tools.ietf.org> References: <055.6da83c00e1eff33bffa91eea8fe65ae4@tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <055.6da83c00e1eff33bffa91eea8fe65ae4@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #2: test - please ignore X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:18:47 -0000 #2: test - please ignore --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: jpv@… Type: defect | Status: closed Priority: trivial | Milestone: Component: routing-metrics | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed -- Ticket URL: roll From alexandru.petrescu@gmail.com Wed Oct 28 06:24:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9EE3A697E for ; Wed, 28 Oct 2009 06:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzpjscWNMZfV for ; Wed, 28 Oct 2009 06:24:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id E867D3A68F9 for ; Wed, 28 Oct 2009 06:24:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id n9SDOTu3004654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Oct 2009 14:24:29 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id n9SDOTo4018330; Wed, 28 Oct 2009 14:24:29 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n9SDOSJS013892; Wed, 28 Oct 2009 14:24:28 +0100 Message-ID: <4AE8460C.4020200@gmail.com> Date: Wed, 28 Oct 2009 14:24:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: <055.33c31e423c5be667ade6c9932019e299@tools.ietf.org> In-Reply-To: <055.33c31e423c5be667ade6c9932019e299@tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] [roll] #1: Test X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 13:24:19 -0000 Test received ok, see it ok. I am happy an issue tracker is being used in ROLL! Alex roll issue tracker a écrit : > #1: Test > --------------------------------+------------------------------------------- > Reporter: jpv@… | Owner: JP Vasseur > Type: enhancement | Status: new > Priority: major | Milestone: > Component: rpl | Version: > Severity: Active WG Document | Keywords: > --------------------------------+------------------------------------------- > Test - Please Ignore > From mdurvy@cisco.com Wed Oct 28 06:40:44 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A218F3A69FD for ; Wed, 28 Oct 2009 06:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.411 X-Spam-Level: X-Spam-Status: No, score=-8.411 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8usZAqtHXPU for ; Wed, 28 Oct 2009 06:40:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 46A473A69E7 for ; Wed, 28 Oct 2009 06:40:40 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: logo.gif, green.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngAAAfn50qQ/uCWe2dsb2JhbACCJiwhmEsBARYkBqYlmDAChD0E X-IronPort-AV: E=Sophos;i="4.44,639,1249257600"; d="gif'147?scan'147,208,217,147";a="52991234" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 13:40:55 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SDetkA013508 for ; Wed, 28 Oct 2009 13:40:55 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:40:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA57D4.45AE22B3" Date: Wed, 28 Oct 2009 14:40:54 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE930251@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need Clarification: DA Parents Thread-Index: AcpX1EVAnB+F3kQLTrC+LqkbS2iGTw== From: "Mathilde Durvy (mdurvy)" To: "roll" X-OriginalArrivalTime: 28 Oct 2009 13:40:54.0946 (UTC) FILETIME=[45D09020:01CA57D4] Subject: [Roll] Need Clarification: DA Parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 13:40:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57D4.45AE22B3 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA57D4.45AE22B3" ------_=_NextPart_002_01CA57D4.45AE22B3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, All, =20 I see conflicting messages in the draft concerning DA parents (section = 5.10.1.1). =20 " If destination advertisements are activated in the DIO message as indicated by the `D' bit, the node sends unicast destination advertisements to one of its DA parents, that is selected as most favored for incoming outwards traffic." --> so the node does not necessarily send the unicast DAO to the parent = who sent the DIO? This seems to contradict section 5.10.1.1.1 where you = actually use a DelayDAO timer per "particular DA parent". --> Why would we keep a DA parent set if we send DAO only to the most = preferred one? =20 " The node only accepts unicast destination advertisements from any nodes but those contained in the DA parent subset." --> should a node accept DAO from nodes the are not in its sub-dag? =20 More generally do we really need the concept of 'DA parents' in addition = to 'parents'. Could we maybe mandate the DA parents =3D the Parents or = alternatively that the DA parent =3D the most preferred parent.=20 Note that having a single DA parent could save a lot of state in terms = of DelayDAO timers and reported flags. =20 Best, Mathilde =20 =09 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =09 Think before you print.=09 This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message.=09 =20 ------_=_NextPart_002_01CA57D4.45AE22B3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP, = All,
 
I see = conflicting=20 messages in the draft concerning DA parents (section=20 5.10.1.1).
 
"  If destination = advertisements are=20 activated in the DIO message as
  =20 indicated by the `D' bit, the node sends unicast=20 destination
  =20 advertisements to one of its DA parents, that is = selected as=20 most
   favored = for incoming=20 outwards traffic."
--> so the node does not necessarily send = the=20 unicast DAO to the parent who sent the DIO? This seems to contradict = section=20 5.10.1.1.1 where you actually use a DelayDAO timer per=20 "particular DA parent".
--> Why would we keep a DA parent set if = we send=20 DAO only to the most preferred one?
 
"  The node=20 only accepts unicast
  =20 destination advertisements from any nodes but those contained in=20 the
   DA parent=20 subset."
--> should a node accept DAO from nodes the = are not=20 in its sub-dag?
 
More generally=20 do we really need the concept of 'DA parents' in addition to 'parents'. = Could we=20 maybe mandate the DA parents =3D the Parents or alternatively that the = DA parent =3D=20 the most preferred parent.
Note that=20 having a single DA parent could save a lot of state in terms of DelayDAO = timers and reported flags.
 
Best,
Mathilde
 
Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822 1725
Mobile: +41 76 = 396=20 8116

 Cisco=20 Systems International S=E0rl
Av. des Uttins, = 5
CH-1180=20 Rolle

Cisco home = page

  
=20 Think before you print.This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this = message.
 
------_=_NextPart_002_01CA57D4.45AE22B3-- ------_=_NextPart_001_01CA57D4.45AE22B3 Content-Type: image/gif; name="logo.gif" Content-Transfer-Encoding: base64 Content-Description: logo.gif Content-Location: http://www.cisco.com/swa/i/logo.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA57D4.45AE22B3 Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-Description: green.gif Content-Location: http://www.cisco.com/global/EMEA/brand/signature/capital/green.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA57D4.45AE22B3-- From richard.kelsey@ember.com Wed Oct 28 07:43:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9533A682B for ; Wed, 28 Oct 2009 07:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ba0poFgYu9W for ; Wed, 28 Oct 2009 07:43:08 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 878A13A684E for ; Wed, 28 Oct 2009 07:43:08 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 10:44:40 -0400 Date: Wed, 28 Oct 2009 10:40:52 -0400 Message-Id: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: X-OriginalArrivalTime: 28 Oct 2009 14:44:40.0166 (UTC) FILETIME=[2DD2D060:01CA57DD] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 14:43:10 -0000 Date: Wed, 28 Oct 2009 13:52:07 +0100 From: "Julien Abeille (jabeille)" it seems that when using source routing, the routes are recorded when DAOs are sent, up to the DAG root. It means that routes are recorded proactively. Correct, although as JP pointed out, intermediate nodes may store the routes rather than passing them on to the root. It would be good to have an on-demand record route mechanism as well, as the DAG root may not have sufficient RAM to store routes sent proactively. I am curious as to why DAOs record the entire route. Record route makes sense when sent on demand. For proactive messages I would think that it would be simpler and much more efficient if DAOs contained only the originator's identity and its preferred parent, or possibly some set of parents. The root or whichever node caches the information could then assemble routes as needed. This would reduce the traffic generated by changes to the DAG. It would also simplify the decision of when to send a new DAO, as it would only depend on local information. if my (new) understanding is correct, record route is proactive, done with control packets (DAOs), hence this enables P2MP, MP2P, P2P. Is my understanding correct? Yes. Note that the P2P you get this way is may be limited by the bandwidth of the root. Even if intermediate nodes store routes, it is quite likely that the least common ancestor of any particular pair of nodes will be the root or one of its near descendants, again limiting the available P2P bandwidth. -Richard Kelsey From jvasseur@cisco.com Wed Oct 28 07:49:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2216928C143 for ; Wed, 28 Oct 2009 07:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.802 X-Spam-Level: X-Spam-Status: No, score=-7.802 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1WlRfn1dlVz for ; Wed, 28 Oct 2009 07:49:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4C5D628B56A for ; Wed, 28 Oct 2009 07:49:09 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEP250qrR7Hu/2dsb2JhbADBfZgtgjqCBQSBYQ X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208";a="262754393" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2009 14:49:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9SEn3pI006515; Wed, 28 Oct 2009 14:49:24 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 15:49:23 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 15:49:22 +0100 Message-Id: <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 15:49:21 +0100 References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 14:49:22.0668 (UTC) FILETIME=[D63532C0:01CA57DD] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 14:49:10 -0000 On Oct 28, 2009, at 3:40 PM, Richard Kelsey wrote: > > Date: Wed, 28 Oct 2009 13:52:07 +0100 > From: "Julien Abeille (jabeille)" > > it seems that when using source routing, the routes are recorded > when DAOs are sent, up to the DAG root. It means that routes are > recorded proactively. > > Correct, although as JP pointed out, intermediate nodes may > store the routes rather than passing them on to the root. > > It would be good to have an on-demand record route mechanism > as well, as the DAG root may not have sufficient RAM to > store routes sent proactively. > > I am curious as to why DAOs record the entire route. Record > route makes sense when sent on demand. For proactive > messages I would think that it would be simpler and much > more efficient if DAOs contained only the originator's > identity and its preferred parent, or possibly some set of > parents. The root or whichever node caches the information > could then assemble routes as needed. This would reduce the > traffic generated by changes to the DAG. It would also > simplify the decision of when to send a new DAO, as it would > only depend on local information. You still have an issue though - suppose that you have: A----B----C---- D----E---Root B and C cannot store routes. A advertises the prefix P1. How cannot you not record the IPv6 address of B and C when sending DAO to advertise P1 since you need to source route the packet from D to A ? > > if my (new) understanding is correct, record route is proactive, > done > with control packets (DAOs), hence this enables P2MP, MP2P, P2P. > Is my understanding correct? > > Yes. Note that the P2P you get this way is may be limited > by the bandwidth of the root. Even if intermediate nodes > store routes, it is quite likely that the least common > ancestor of any particular pair of nodes will be the root or > one of its near descendants, again limiting the available > P2P bandwidth. Yes, we're currently running some simulation to validate this assumption. > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Wed Oct 28 07:51:14 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB033A6893 for ; Wed, 28 Oct 2009 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id susVOOiFquGl for ; Wed, 28 Oct 2009 07:51:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id D6E103A686A for ; Wed, 28 Oct 2009 07:51:13 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N39s0-0007VV-Hm; Wed, 28 Oct 2009 07:51:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Wed, 28 Oct 2009 14:51:28 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/3 Message-ID: <055.26a8e6525010f4a9eb8b7f6b1c6a38be@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #3: Need Clarification on Candidate Neighbor X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:51:14 -0000 #3: Need Clarification on Candidate Neighbor --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Question from Mathilde Durvy: Hi All, I'm trying to understand better the need for 'candidate neighbors'. My current understanding is that 'candidate parents' (RPL) are a subset of 'candidate neighbors' (RPL) which are themselves a subset of 'neighbors' (ND). My question is, do we really need to maintain 'candidate neighbors' in addition to 'neighbors' and 'candidate parents'? If yes what should be the data structure and corresponding fields for 'candidate neighbors'? Section 5.2.1 gives very little details... I have a feeling that 'candidate neighbors' could simply be the set of REACHABLE 'neighbors' and be associated with a DAG once they become candidate parents. -- Ticket URL: roll From trac@tools.ietf.org Wed Oct 28 07:59:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 970FA28C1BD for ; Wed, 28 Oct 2009 07:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbdLJWIDFaFg for ; Wed, 28 Oct 2009 07:59:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id AD07428C1C1 for ; Wed, 28 Oct 2009 07:59:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N39zh-0007ki-81; Wed, 28 Oct 2009 07:59:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Wed, 28 Oct 2009 14:59:25 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/4 Message-ID: <055.78d9321183257c63ddf9765eee95d643@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #4: Write an FSM for RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:59:11 -0000 #4: Write an FSM for RPL --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Add the FSM to revision -05 of RPL. -- Ticket URL: roll From richard.kelsey@ember.com Wed Oct 28 09:01:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6F13A69FF for ; Wed, 28 Oct 2009 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZKaCrPChLWu for ; Wed, 28 Oct 2009 09:01:04 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 50C0C3A68BF for ; Wed, 28 Oct 2009 09:01:04 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 12:02:36 -0400 Date: Wed, 28 Oct 2009 11:58:48 -0400 Message-Id: <87hbtj7bnr.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> (message from JP Vasseur on Wed, 28 Oct 2009 15:49:21 +0100) From: Richard Kelsey References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> X-OriginalArrivalTime: 28 Oct 2009 16:02:36.0303 (UTC) FILETIME=[1104B1F0:01CA57E8] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:01:05 -0000 From: JP Vasseur Date: Wed, 28 Oct 2009 15:49:21 +0100 On Oct 28, 2009, at 3:40 PM, Richard Kelsey wrote: > I am curious as to why DAOs record the entire route. Record > route makes sense when sent on demand. For proactive > messages I would think that it would be simpler and much > more efficient if DAOs contained only the originator's > identity and its preferred parent, or possibly some set of > parents. The root or whichever node caches the information > could then assemble routes as needed. This would reduce the > traffic generated by changes to the DAG. It would also > simplify the decision of when to send a new DAO, as it would > only depend on local information. You still have an issue though - suppose that you have: A----B----C----D----E---Root B and C cannot store routes. A advertises the prefix P1. How cannot you not record the IPv6 address of B and C when sending DAO to advertise P1 since you need to source route the packet from D to A ? Because B and C send in their own DAOs with their own IPv6 address as the prefix and with their own parents. Are you suggesting that there will be nodes that will not send in DAOs containing their IPv6 addresses? If the 'D' bit is set in a DIO all nodes are supposed to send in a DAO, but I suppose they might use a different prefix. > Yes. Note that the P2P you get this way is may be limited > by the bandwidth of the root. Even if intermediate nodes > store routes, it is quite likely that the least common > ancestor of any particular pair of nodes will be the root or > one of its near descendants, again limiting the available > P2P bandwidth. Yes, we're currently running some simulation to validate this assumption. I am pretty sure it is true in the case where only the root stores routes :-). -Richard Kelsey From jvasseur@cisco.com Wed Oct 28 09:07:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A8E3A67E7 for ; Wed, 28 Oct 2009 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.77 X-Spam-Level: X-Spam-Status: No, score=-7.77 tagged_above=-999 required=5 tests=[AWL=-1.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiDhNfQq+gIq for ; Wed, 28 Oct 2009 09:07:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0EEA63A67A3 for ; Wed, 28 Oct 2009 09:07:33 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMcI6EqrR7H+/2dsb2JhbADCJZgzgjqCBQSBYQ X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208";a="262807602" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 28 Oct 2009 16:07:48 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SG7Wem025897; Wed, 28 Oct 2009 16:07:48 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:07:39 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:07:38 +0100 Message-Id: From: JP Vasseur To: Richard Kelsey In-Reply-To: <87hbtj7bnr.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 17:07:37 +0100 References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> <87hbtj7bnr.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 16:07:38.0680 (UTC) FILETIME=[C53FC380:01CA57E8] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:07:34 -0000 On Oct 28, 2009, at 4:58 PM, Richard Kelsey wrote: > > From: JP Vasseur > Date: Wed, 28 Oct 2009 15:49:21 +0100 > > On Oct 28, 2009, at 3:40 PM, Richard Kelsey wrote: > >> I am curious as to why DAOs record the entire route. Record >> route makes sense when sent on demand. For proactive >> messages I would think that it would be simpler and much >> more efficient if DAOs contained only the originator's >> identity and its preferred parent, or possibly some set of >> parents. The root or whichever node caches the information >> could then assemble routes as needed. This would reduce the >> traffic generated by changes to the DAG. It would also >> simplify the decision of when to send a new DAO, as it would >> only depend on local information. > > You still have an issue though - suppose that you have: > A----B----C----D----E---Root > B and C cannot store routes. > A advertises the prefix P1. > How cannot you not record the IPv6 address of B and C when sending > DAO > to advertise P1 since you need to source route the packet from D > to A ? > > Because B and C send in their own DAOs with their own > IPv6 address as the prefix and with their own parents. > Are you suggesting that there will be nodes that will > not send in DAOs containing their IPv6 addresses? If > the 'D' bit is set in a DIO all nodes are supposed to > send in a DAO, but I suppose they might use a different > prefix. > The point I was trying to make is that in the case above, we do need to record in the DAO the IP address of both B and C up to D. I had the impression that you were suggesting a different mechanism ? >> Yes. Note that the P2P you get this way is may be limited >> by the bandwidth of the root. Even if intermediate nodes >> store routes, it is quite likely that the least common >> ancestor of any particular pair of nodes will be the root or >> one of its near descendants, again limiting the available >> P2P bandwidth. > > Yes, we're currently running some simulation to validate this > assumption. > > I am pretty sure it is true in the case where only the root > stores routes :-). Ah yes, in this case (only the DAG can store routes) the answer is pretty straightforward ;-)) > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jabeille@cisco.com Wed Oct 28 09:17:59 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51903A69FB for ; Wed, 28 Oct 2009 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.272 X-Spam-Level: X-Spam-Status: No, score=-10.272 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq0tGKCK6Azz for ; Wed, 28 Oct 2009 09:17:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8C07B28C197 for ; Wed, 28 Oct 2009 09:17:58 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwAAFoL6EqQ/uCWe2dsb2JhbACCJiyHP5EuAQEWJAamEpgzhD8E X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208,217";a="53018509" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 16:18:12 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SGIC5T006007 for ; Wed, 28 Oct 2009 16:18:12 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:18:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA57EA.3F034A36" Date: Wed, 28 Oct 2009 17:18:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: destination oriented DAG vs DAG Thread-Index: AcpX6j7PJ85IEh5GRhOEJl9e2OoYpg== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 28 Oct 2009 16:18:12.0742 (UTC) FILETIME=[3F2DF260:01CA57EA] Subject: [Roll] destination oriented DAG vs DAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:17:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57EA.3F034A36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 is there a distinction between DAG and destination oriented DAG. From what I read I feel all DAGs are destination oriented. If this is correct I propose to remove the destination oriented DAG concept. =20 Best, Julien ------_=_NextPart_001_01CA57EA.3F034A36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
is = there=20 a distinction between DAG and destination oriented DAG. From what I = read I=20 feel all DAGs are destination oriented. If this is correct I = propose to=20 remove the destination oriented DAG concept.
 
Best,
Julien
------_=_NextPart_001_01CA57EA.3F034A36-- From jabeille@cisco.com Wed Oct 28 09:29:05 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1701128C1E1 for ; Wed, 28 Oct 2009 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZmRJBArM0nb for ; Wed, 28 Oct 2009 09:29:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7DCB328C1ED for ; Wed, 28 Oct 2009 09:29:01 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEAALMN6EqQ/uCWe2dsb2JhbACCJyuYbQEBFiQGpieYMIQ/BA X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208,217";a="53019670" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 16:29:15 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SGTFIY009372 for ; Wed, 28 Oct 2009 16:29:15 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:29:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA57EB.CA2523F4" Date: Wed, 28 Oct 2009 17:29:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multicast DAO Thread-Index: AcpX68n26de6CMdGQ6C5DfY0xaoUig== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 28 Oct 2009 16:29:15.0650 (UTC) FILETIME=[CA4DAE20:01CA57EB] Subject: [Roll] multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:29:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57EB.CA2523F4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 regarding usage of multicast DAO: in the following scenario: A / \ B C =20 if the purpose is to to allow B and C to talk to each other directly, the multicast DAO is equivalent to an unsolicited NA.=20 =20 In the scenarios like: =20 A / \ B C | D if the purpose is to have B talk to D through C (instead of A then C), then the multicast DAO (including destination prefix option) makes sense.=20 Is this scenario needed by some applications? =20 Best, Julien ------_=_NextPart_001_01CA57EB.CA2523F4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
regarding usage of=20 multicast DAO: in the following scenario:
  A
 / =20 \
B =20 C
 
if the = purpose is to=20 to allow B and C to talk to each other directly, the multicast DAO is = equivalent=20 to an unsolicited NA.
 
In the = scenarios=20 like:
 
  =20 A
  = / =20 \
B  =20 C
      |
      D
if the = purpose is to=20 have B talk to D through C (instead of A then C), then the = multicast=20 DAO (including destination prefix option) makes sense. =
Is = this scenario=20 needed by some applications?
 
Best,
Julien
------_=_NextPart_001_01CA57EB.CA2523F4-- From jabeille@cisco.com Wed Oct 28 09:43:03 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8726528C23E for ; Wed, 28 Oct 2009 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.31 X-Spam-Level: X-Spam-Status: No, score=-10.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNHRusq7Jqcx for ; Wed, 28 Oct 2009 09:43:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BA63728C22A for ; Wed, 28 Oct 2009 09:43:01 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAAADYR6EqQ/uCWe2dsb2JhbACCJS2YbAEBFiQGpjiYMoQ/BA X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208,217";a="53021132" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 16:43:15 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SGhGbB013476 for ; Wed, 28 Oct 2009 16:43:16 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:43:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA57ED.BEEF942C" Date: Wed, 28 Oct 2009 17:43:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL bootstrap question: neighbor cache and DIOs dependency Thread-Index: AcpX7b7DxymrTQkESNK0KypFH4Gp5g== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 28 Oct 2009 16:43:15.0815 (UTC) FILETIME=[BF14AF70:01CA57ED] Subject: [Roll] RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:43:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57ED.BEEF942C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 as explained in section 5.4.2 of RPL, a DIO must not be processed if the source is not in the neighbor cache. The question is how do we expect the neighbor cache to be filled?=20 topology: A | B B receives a DIO from A, A is not in B's neighbor cache: =20 NS/NA exchanges will probably not occur, as B has no good reason to send packets to A (A is not a router for B, B has most of the time no data to send to A) RS/RA exchanges: do we expect to send RAs in RPL environments? Would this be enough? If there are no frequent RAs, or unsolicited NAs, then A will likely never be in B's neighbor cache. =20 One way to solve this would be to allow SLLAO option in DIOs. Processing this option in ICMP messages (NS, RS, RA) is a well known process, and would create an entry in the neighbor cache, state STALE. =20 what do you think? =20 Julien ------_=_NextPart_001_01CA57ED.BEEF942C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
as = explained in=20 section 5.4.2 of RPL, a DIO must not be processed if the source is = not in=20 the neighbor cache. The question is how do we expect the neighbor cache = to be=20 filled?
topology:
A
|
B
B = receives a DIO=20 from A, A is not in B's neighbor cache:
 
NS/NA = exchanges will=20 probably not occur, as B has no good reason to send packets to A (A is = not a=20 router for B, B has most of the time no data to send to = A)
RS/RA = exchanges: do=20 we expect to send RAs in RPL environments? Would this be=20 enough?
If = there are no=20 frequent RAs, or unsolicited NAs, then A will likely never be in B's = neighbor=20 cache.
 
One = way to solve=20 this would be to allow SLLAO option in DIOs. Processing this option in = ICMP=20 messages (NS, RS, RA) is a well known process, and would create an = entry in=20 the neighbor cache, state STALE.
 
what = do you=20 think?
 
Julien
------_=_NextPart_001_01CA57ED.BEEF942C-- From jabeille@cisco.com Wed Oct 28 09:47:01 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2759F28C23E for ; Wed, 28 Oct 2009 09:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[AWL=-1.728, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qz6IXWO6GCQQ for ; Wed, 28 Oct 2009 09:47:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2558128C219 for ; Wed, 28 Oct 2009 09:47:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGMS6EqtJV2c/2dsb2JhbACCJiy/dJguhD8E X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208,217";a="65332517" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2009 16:47:14 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id n9SGlCwn028720 for ; Wed, 28 Oct 2009 16:47:14 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:47:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA57EE.4B1730D6" Date: Wed, 28 Oct 2009 17:47:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RPL detail: DIO base option vs DIO Thread-Index: AcpX7kreNvvxD1uBSbWLJcGG0n0wRQ== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 28 Oct 2009 16:47:11.0175 (UTC) FILETIME=[4B5DC570:01CA57EE] Subject: [Roll] RPL detail: DIO base option vs DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:47:01 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57EE.4B1730D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 what is the rationale for calling DIO base option an option, as it is mandatory for DIOs? could it be simply DIO, and sub options would be options? =20 Thank you, Julien ------_=_NextPart_001_01CA57EE.4B1730D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
what = is the=20 rationale for calling DIO base option an option, as it is mandatory for = DIOs?=20 could it be simply DIO, and sub options would be = options?
 
Thank=20 you,
Julien
------_=_NextPart_001_01CA57EE.4B1730D6-- From jabeille@cisco.com Wed Oct 28 09:49:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C263A6917 for ; Wed, 28 Oct 2009 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.235 X-Spam-Level: X-Spam-Status: No, score=-8.235 tagged_above=-999 required=5 tests=[AWL=-1.637, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJFc1HEJ+BXP for ; Wed, 28 Oct 2009 09:49:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4530D3A68AC for ; Wed, 28 Oct 2009 09:49:23 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAI8T6EqtJV2b/2dsb2JhbACCJiy/d5guhD8E X-IronPort-AV: E=Sophos;i="4.44,640,1249257600"; d="scan'208,217";a="65332829" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 28 Oct 2009 16:49:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id n9SGn5CI009128 for ; Wed, 28 Oct 2009 16:49:37 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:49:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA57EE.9D6B64A6" Date: Wed, 28 Oct 2009 17:49:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 16 bit length for DIO options Thread-Index: AcpX7p06v6VTejyFQCG1nIl/j+l+0A== From: "Julien Abeille (jabeille)" To: "ROLL WG" X-OriginalArrivalTime: 28 Oct 2009 16:49:29.0303 (UTC) FILETIME=[9DB26E70:01CA57EE] Subject: [Roll] 16 bit length for DIO options X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:49:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57EE.9D6B64A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 do we expect DIO suboptions to be longer than 255 bytes? if yes would it be ok to spell the length in multiple of 8bytes instead of bytes (value of 1 means 8 bytes, like in ND). The target is to use 8 bits instead of 16. =20 Thank you, Julien ------_=_NextPart_001_01CA57EE.9D6B64A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
do we = expect DIO=20 suboptions to be longer than 255 bytes? if yes would it be ok to spell = the=20 length in multiple of  8bytes instead of bytes (value of 1 means 8 = bytes,=20 like in ND). The target is to use 8 bits instead of = 16.
 
Thank=20 you,
Julien
------_=_NextPart_001_01CA57EE.9D6B64A6-- From richard.kelsey@ember.com Wed Oct 28 09:56:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0E63A6905 for ; Wed, 28 Oct 2009 09:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+IJlkxNLqYc for ; Wed, 28 Oct 2009 09:56:53 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 743263A6A0C for ; Wed, 28 Oct 2009 09:56:53 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 12:58:25 -0400 Date: Wed, 28 Oct 2009 12:54:37 -0400 Message-Id: <87fx93792q.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: (message from JP Vasseur on Wed, 28 Oct 2009 17:07:37 +0100) From: Richard Kelsey References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> <87hbtj7bnr.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 28 Oct 2009 16:58:25.0308 (UTC) FILETIME=[DD2E4DC0:01CA57EF] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 16:56:54 -0000 From: JP Vasseur Date: Wed, 28 Oct 2009 17:07:37 +0100 You still have an issue though - suppose that you have: A----B----C----D----E---Root B and C cannot store routes. A advertises the prefix P1. The point I was trying to make is that in the case above, we do need to record in the DAO the IP address of both B and C up to D. I had the impression that you were suggesting a different mechanism ? The mechanism is nearly the same. Let me try to explain it more clearly using your example. In your example, D stores routes. What D needs is a set of links: A---B, B---C, C---D >From this D can assemble routes to A, B, and C. As things stand now, D will receive three DAOs, two of which include non-empty reverse route stacks: A[BC], B[C], C[] I am suggesting that the reverse route stack be limited to a single hop, rather than contain the entire path. In this case, D would receive A[B], B[C], C[] In the new scheme, DAOs would be forwarded unmodified. In particular they would not get larger as they go up the DAG. Only those nodes that changed parents would need to send new DAOs. Nodes whose ancestors change parents would not need to send new DAOs. This would greatly reduce the traffic generated when a node high in the DAG changes parents. -Richard Kelsey From jvasseur@cisco.com Wed Oct 28 10:36:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 620DA3A69A5 for ; Wed, 28 Oct 2009 10:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.739 X-Spam-Level: X-Spam-Status: No, score=-7.739 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqkKcblkOBeH for ; Wed, 28 Oct 2009 10:36:11 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 969053A6847 for ; Wed, 28 Oct 2009 10:36:11 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOgd6EqrR7Ht/2dsb2JhbADCQ5gvhD8E X-IronPort-AV: E=Sophos;i="4.44,641,1249257600"; d="scan'208";a="47277714" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 28 Oct 2009 17:36:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SHZWRt024808; Wed, 28 Oct 2009 17:36:26 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 18:35:42 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 18:35:42 +0100 Message-Id: <73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87fx93792q.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 18:35:41 +0100 References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> <87hbtj7bnr.fsf@kelsey-ws.hq.ember.com> <87fx93792q.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 17:35:42.0621 (UTC) FILETIME=[12B92CD0:01CA57F5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16976.000 X-TM-AS-Result: No--19.212900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 17:36:12 -0000 Hi Richard, On Oct 28, 2009, at 5:54 PM, Richard Kelsey wrote: > > From: JP Vasseur > Date: Wed, 28 Oct 2009 17:07:37 +0100 > > > You still have an issue though - suppose that you have: > A----B----C----D----E---Root > B and C cannot store routes. > A advertises the prefix P1. > > The point I was trying to make is that in the case above, we do > need to record in the DAO the IP address of both B and C up to D. I > had the impression that you were suggesting a different mechanism ? > > The mechanism is nearly the same. Let me try to explain it > more clearly using your example. > > In your example, D stores routes. What D needs is a set of > links: > A---B, B---C, C---D > > From this D can assemble routes to A, B, and C. As things > stand now, D will receive three DAOs, two of which include > non-empty reverse route stacks: > A[BC], B[C], C[] > You would send a single DAO, not 3 since that would not scale, the Root would end up receiving quite a few DIOs. In this case, there would be a single DIO with A[BC]. Makes sense ? > I am suggesting that the reverse route stack be limited to a > single hop, rather than contain the entire path. In this > case, D would receive > A[B], B[C], C[] > > In the new scheme, DAOs would be forwarded unmodified. In > particular they would not get larger as they go up the DAG. > Only those nodes that changed parents would need to send new > DAOs. Nodes whose ancestors change parents would not need > to send new DAOs. This would greatly reduce the traffic > generated when a node high in the DAG changes parents. > > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From richard.kelsey@ember.com Wed Oct 28 11:19:24 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D37643A68D5 for ; Wed, 28 Oct 2009 11:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONKZwrNLVELO for ; Wed, 28 Oct 2009 11:19:24 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id CD7463A6843 for ; Wed, 28 Oct 2009 11:19:23 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 14:20:55 -0400 Date: Wed, 28 Oct 2009 14:17:07 -0400 Message-Id: <87bpjr7598.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> (message from JP Vasseur on Wed, 28 Oct 2009 18:35:41 +0100) From: Richard Kelsey References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> <87hbtj7bnr.fsf@kelsey-ws.hq.ember.com> <87fx93792q.fsf@kelsey-ws.hq.ember.com> <73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> X-OriginalArrivalTime: 28 Oct 2009 18:20:55.0918 (UTC) FILETIME=[63F970E0:01CA57FB] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 18:19:24 -0000 From: JP Vasseur Date: Wed, 28 Oct 2009 18:35:41 +0100 On Oct 28, 2009, at 5:54 PM, Richard Kelsey wrote: > The mechanism is nearly the same. Let me try to explain it > more clearly using your example. > > In your example, D stores routes. What D needs is a set of > links: > A---B, B---C, C---D > > From this D can assemble routes to A, B, and C. As things > stand now, D will receive three DAOs, two of which include > non-empty reverse route stacks: > A[BC], B[C], C[] JP, I am going to assume you mean DAO everywhere, not DIO. If you did mean DIO, then I do not understand what you are saying. You would send a single DAO, not 3 since that would not scale, the Root would end up receiving quite a few DIOs. Exactly my concern. In this case, there would be a single DIO with A[BC]. How does this come about? I do not think there is anything in the current draft describing how DAOs can be suppressed in this fashion. While it would help if we could suppress the DAOs from interior nodes, they are usually outnumbered by the leaf nodes. For this example, in the more likely situation of A having siblings, even with some kind of suppression D would receive multiple DAOs each with a copy of the route from B on up. -Richard Kelsey From jabeille@cisco.com Wed Oct 28 12:45:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79EBE3A6A6A for ; Wed, 28 Oct 2009 12:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.154 X-Spam-Level: X-Spam-Status: No, score=-8.154 tagged_above=-999 required=5 tests=[AWL=-1.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5mJmZ3b03g1 for ; Wed, 28 Oct 2009 12:45:53 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8AC2A3A6A69 for ; Wed, 28 Oct 2009 12:45:53 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN876EqrR7H+/2dsb2JhbADCWpgvhD8E X-IronPort-AV: E=Sophos;i="4.44,641,1249257600"; d="scan'208";a="420021493" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 28 Oct 2009 19:46:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9SJk4nv000927; Wed, 28 Oct 2009 19:46:08 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 20:46:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Oct 2009 20:46:06 +0100 Message-ID: In-Reply-To: <87bpjr7598.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] clarification about source routing Thread-Index: AcpX+1DJ1JPPdMkUTWqso5JVB6/K0gAC4EiQ References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com><0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com><87hbtj7bnr.fsf@kelsey-ws.hq.ember.com><87fx93792q.fsf@kelsey-ws.hq.ember.com><73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> <87bpjr7598.fsf@kelsey-ws.hq.ember.com> From: "Julien Abeille (jabeille)" To: "Richard Kelsey" , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 28 Oct 2009 19:46:07.0416 (UTC) FILETIME=[4AAA2380:01CA5807] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 19:45:54 -0000 Hi Richard, Not sure this is explained well in the draft, but with A - B - C - D (D as root), A sends a DAO with prefix pA, upon reception B sends DAO with prefix pA and pB, C sends DAO with prefix pA, pB, pC (B and C also add their address to the reverse route stack). C ends up sending one DAO with all three perfixes Best, Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Richard Kelsey > Sent: mercredi 28 octobre 2009 19:17 > To: JP Vasseur (jvasseur) > Cc: roll@ietf.org > Subject: Re: [Roll] clarification about source routing >=20 >=20 > From: JP Vasseur > Date: Wed, 28 Oct 2009 18:35:41 +0100 >=20 > On Oct 28, 2009, at 5:54 PM, Richard Kelsey wrote: >=20 > > The mechanism is nearly the same. Let me try to explain it > > more clearly using your example. > > > > In your example, D stores routes. What D needs is a set of > > links: > > A---B, B---C, C---D > > > > From this D can assemble routes to A, B, and C. As things > > stand now, D will receive three DAOs, two of which include > > non-empty reverse route stacks: > > A[BC], B[C], C[] >=20 > JP, >=20 > I am going to assume you mean DAO everywhere, not DIO. > If you did mean DIO, then I do not understand what you are saying. >=20 > You would send a single DAO, not 3 since that would not=20 > scale, the Root > would end up receiving quite a few DIOs. >=20 > Exactly my concern. >=20 > In this case, there would be a single DIO with A[BC]. >=20 > How does this come about? I do not think there is anything=20 > in the current draft describing how DAOs can be suppressed in=20 > this fashion. >=20 > While it would help if we could suppress the DAOs from=20 > interior nodes, they are usually outnumbered by the leaf=20 > nodes. For this example, in the more likely situation of A=20 > having siblings, even with some kind of suppression D would=20 > receive multiple DAOs each with a copy of the route from B on up. > -Richard Kelsey >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jvasseur@cisco.com Wed Oct 28 12:48:51 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843993A6A70 for ; Wed, 28 Oct 2009 12:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.71 X-Spam-Level: X-Spam-Status: No, score=-9.71 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxSCtvstBWAt for ; Wed, 28 Oct 2009 12:48:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 45A883A6A68 for ; Wed, 28 Oct 2009 12:48:50 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcAAJM86EqQ/uCWe2dsb2JhbACbQQEBFiQGplmYL4Q/BA X-IronPort-AV: E=Sophos;i="4.44,641,1249257600"; d="scan'208";a="53034205" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 28 Oct 2009 19:49:04 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9SJn4ie022880; Wed, 28 Oct 2009 19:49:04 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 20:49:04 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 20:49:03 +0100 Message-Id: <9321A3D9-1FEC-4E21-B4C0-3F83EFD92CCA@cisco.com> From: JP Vasseur To: Richard Kelsey In-Reply-To: <87bpjr7598.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 20:49:03 +0100 References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com> <0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com> <87hbtj7bnr.fsf@kelsey-ws.hq.ember.com> <87fx93792q.fsf@kelsey-ws.hq.ember.com> <73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> <87bpjr7598.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 28 Oct 2009 19:49:03.0951 (UTC) FILETIME=[B3E33DF0:01CA5807] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 19:48:51 -0000 On Oct 28, 2009, at 7:17 PM, Richard Kelsey wrote: > > From: JP Vasseur > Date: Wed, 28 Oct 2009 18:35:41 +0100 > > On Oct 28, 2009, at 5:54 PM, Richard Kelsey wrote: > >> The mechanism is nearly the same. Let me try to explain it >> more clearly using your example. >> >> In your example, D stores routes. What D needs is a set of >> links: >> A---B, B---C, C---D >> >> From this D can assemble routes to A, B, and C. As things >> stand now, D will receive three DAOs, two of which include >> non-empty reverse route stacks: >> A[BC], B[C], C[] > > JP, > > I am going to assume you mean DAO everywhere, not DIO. Arrr ... yes of course ;-) > If you did mean DIO, then I do not understand what you > are saying. > > You would send a single DAO, not 3 since that would not scale, the > Root > would end up receiving quite a few DIOs. > > Exactly my concern. > > In this case, there would be a single DIO with A[BC]. > > How does this come about? I do not think there is anything > in the current draft describing how DAOs can be suppressed > in this fashion. Then we should clarify it, this is how I would implement it for sure. DAOs are sent to parents, not targeted to any specific node. Thus in that case, A would send a DAO to B, B would send its own DAO to C, etc ... you would indeed come up with a single DAO from D to E, etc ... This need to be clarified in the document. > > While it would help if we could suppress the DAOs from > interior nodes, they are usually outnumbered by the leaf > nodes. For this example, in the more likely situation of A > having siblings, even with some kind of suppression D would > receive multiple DAOs each with a copy of the route from B > on up. But do you see an issue with this ? Cheers. JP. > -Richard Kelsey > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Wed Oct 28 13:21:58 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3399228C1FD; Wed, 28 Oct 2009 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5WtyAYQDf9w; Wed, 28 Oct 2009 13:21:57 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by core3.amsl.com (Postfix) with ESMTP id CDFA83A68E4; Wed, 28 Oct 2009 13:21:56 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKSuin86IlMLYCoB52CJKBg9pQPuwis8If@postini.com; Wed, 28 Oct 2009 13:22:13 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009102815223451-2829552 ; Wed, 28 Oct 2009 15:22:34 -0500 In-Reply-To: <26C2DF71-BCC0-4927-BC21-44BE062313E9@cisco.com> MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 28 Oct 2009 15:21:58 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 10/28/2009 03:22:00 PM, Serialize complete at 10/28/2009 03:22:00 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/28/2009 03:22:34 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/28/2009 03:22:46 PM, Serialize complete at 10/28/2009 03:22:46 PM Content-Type: multipart/alternative; boundary="=_alternative 006FE0048625765D_=" Cc: roll ROLL , roll-bounces@ietf.org Subject: Re: [Roll] Need clarification ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 20:21:58 -0000 This is a multipart message in MIME format. --=_alternative 006FE0048625765D_= Content-Type: text/plain; charset="US-ASCII" JP, For us IETF rookies - Is there a document that describes the use of the Issue Tracker? Do we send them to the Chair to be entered? Do we enter them ourselves? How do we query the tracker? What states might an issue take on? Please advise. Jerry JP Vasseur Sent by: roll-bounces@ietf.org 10/28/2009 07:58 AM To roll ROLL cc Subject [Roll] Need clarification ? Dear all, As Tim pointed out, RPL Rev-04 did simplify the protocol quite significantly, which was our WG's main objective. There are still areas where the text may not be sufficiently detailed (I did receive questions from several implementers showing a lack of clarity). Could you please review and let us know where the text is not sufficiently detailed or ambiguous ? This way we could address any potential lack of clarity in rev-05 + add the FSM as promised. I'll start opening tickets, now is probably a good time. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006FE0048625765D_= Content-Type: text/html; charset="US-ASCII"
JP,

For us IETF rookies - Is there a document that describes the use of the Issue Tracker?  Do we send them to the Chair to be entered?  Do we enter them ourselves?  How do we query the tracker?  What states might an issue take on?

Please advise.

Jerry


JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

10/28/2009 07:58 AM

To
roll ROLL <roll@ietf.org>
cc
Subject
[Roll] Need clarification ?





Dear all,

As Tim pointed out, RPL Rev-04 did simplify the protocol quite  
significantly, which was our WG's main objective.
There are still areas where the text may not be sufficiently detailed  
(I did receive questions from several implementers showing a lack of  
clarity).

Could you please review and let us know where the text is not  
sufficiently detailed or ambiguous ?

This way we could address any potential lack of clarity in rev-05 +  
add the FSM as promised.

I'll start opening tickets, now is probably a good time.

Thanks.

JP.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006FE0048625765D_=-- From richard.kelsey@ember.com Wed Oct 28 13:56:26 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABB13A6A75 for ; Wed, 28 Oct 2009 13:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPVKWW0ebr7B for ; Wed, 28 Oct 2009 13:56:25 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 683FA3A69A0 for ; Wed, 28 Oct 2009 13:56:25 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 16:57:57 -0400 Date: Wed, 28 Oct 2009 16:54:09 -0400 Message-Id: <877huf6xzi.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com><0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com><87hbtj7bnr.fsf@kelsey-ws.hq.ember.com><87fx93792q.fsf@kelsey-ws.hq.ember.com><73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> <87bpjr7598.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 28 Oct 2009 20:57:57.0542 (UTC) FILETIME=[53B32C60:01CA5811] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 20:56:26 -0000 Julien, Date: Wed, 28 Oct 2009 20:46:06 +0100 From: "Julien Abeille (jabeille)" Not sure this is explained well in the draft, but with A - B - C - D (D as root), A sends a DAO with prefix pA, upon reception B sends DAO with prefix pA and pB, C sends DAO with prefix pA, pB, pC (B and C also add their address to the reverse route stack). C ends up sending one DAO with all three perfixes The Destination Advertisement Object has space for only one prefix and one reverse route stack. Are you saying that multiple DAOs can be included in a single ICMPv6 message? To make this aggregation work, nodes higher in the DAG have to wait to receive the DAOs from their descendants. How long should they wait? -Richard Kelsey From prvs=545ea744a=mukul@uwm.edu Wed Oct 28 14:04:13 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFFD28C10E for ; Wed, 28 Oct 2009 14:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OjMh9yfnQaU for ; Wed, 28 Oct 2009 14:04:12 -0700 (PDT) Received: from ip2mta2.uwm.edu (ip2mta2.uwm.edu [129.89.7.131]) by core3.amsl.com (Postfix) with ESMTP id 16AF128C104 for ; Wed, 28 Oct 2009 14:04:12 -0700 (PDT) Received: from mta03.pantherlink.uwm.edu ([129.89.7.83]) by ip2mta2.uwm.edu with ESMTP; 28 Oct 2009 16:04:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 406C8C085C8; Wed, 28 Oct 2009 16:04:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6hfszVU1hzx; Wed, 28 Oct 2009 16:04:26 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D3C9CC085A0; Wed, 28 Oct 2009 16:04:26 -0500 (CDT) Date: Wed, 28 Oct 2009 16:04:26 -0500 (CDT) From: Mukul Goyal To: Richard Kelsey Message-ID: <1766140419.1553621256763866775.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <877huf6xzi.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 5.0.18_GA_3011.RHEL4_64 (ZimbraWebClient - [unknown] (Win)/5.0.18_GA_3011.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 21:04:44 -0000 Another question is what happens if the prefixes can't be aggregated together. i.e. what happens if I can not aggregate prefixes advertized by my children into one prefix? In this case, it seems that I will be forced to send a large number of prefixes to my parent and the parent would need to send a still larger number of prefixes to its parent and so on. This is a concern some of us have had for a long time. Thanks Mukul ----- Original Message ----- From: "Richard Kelsey" To: "Julien Abeille (jabeille)" Cc: roll@ietf.org Sent: Wednesday, October 28, 2009 3:54:09 PM GMT -06:00 US/Canada Central Subject: Re: [Roll] clarification about source routing Julien, Date: Wed, 28 Oct 2009 20:46:06 +0100 From: "Julien Abeille (jabeille)" Not sure this is explained well in the draft, but with A - B - C - D (D as root), A sends a DAO with prefix pA, upon reception B sends DAO with prefix pA and pB, C sends DAO with prefix pA, pB, pC (B and C also add their address to the reverse route stack). C ends up sending one DAO with all three perfixes The Destination Advertisement Object has space for only one prefix and one reverse route stack. Are you saying that multiple DAOs can be included in a single ICMPv6 message? To make this aggregation work, nodes higher in the DAG have to wait to receive the DAOs from their descendants. How long should they wait? -Richard Kelsey _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@marajade.sandelman.ca Wed Oct 28 17:10:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F123A6950 for ; Wed, 28 Oct 2009 17:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.966, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLxCA9SGaC-3 for ; Wed, 28 Oct 2009 17:10:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0E8973A6996 for ; Wed, 28 Oct 2009 17:10:30 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 0615234287 for ; Thu, 29 Oct 2009 00:16:22 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id EC9663EC5 for ; Wed, 28 Oct 2009 20:10:43 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 28 Oct 2009 20:10:43 -0400 Message-ID: <15332.1256775043@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] Need clarification ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 00:10:32 -0000 {please fix your mailer to not reply to the SMTP envelope from, which is roll-bounces@ietf.org. I won't be surprised if sending emails to that address causes you to be removed from the list. You'll need to talk to your IT types about getting your mail system compliant with the 20-year old RFC1123} >>>>> "Jerald" == Jerald P Martocci writes: Jerald> For us IETF rookies - Is there a document that describes the Jerald> use of the Issue Tracker? Do we send them to the Chair to Jerald> be entered? Do we enter them ourselves? How do we query Jerald> the tracker? What states might an issue take on? Issue trackers are relatively new to the IETF (less than 2 years), so the process is mostly up to our chairs, and even IETF frequent flyers may not know more than you :-) You need a datatracker.ietf.org account, that I know. Getting one is not hard, but I'm not sure what the criteria is. Usually, it has been restricted to the WG chairs, and a few other helpers. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jhui@archrock.com Wed Oct 28 18:47:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009B73A694D for ; Wed, 28 Oct 2009 18:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef-8lwwk10+O for ; Wed, 28 Oct 2009 18:47:18 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 31D5A3A6359 for ; Wed, 28 Oct 2009 18:47:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id BB05DAFA3C; Wed, 28 Oct 2009 18:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v9cO74qE+e1; Wed, 28 Oct 2009 18:47:29 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id D65E4AF842; Wed, 28 Oct 2009 18:47:28 -0700 (PDT) Message-Id: <5D0A158B-EC94-4984-9E0D-E706DA736BD6@archrock.com> From: Jonathan Hui To: Richard Kelsey In-Reply-To: <877huf6xzi.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Oct 2009 18:47:27 -0700 References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com><0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com><87hbtj7bnr.fsf@kelsey-ws.hq.ember.com><87fx93792q.fsf@kelsey-ws.hq.ember.com><73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> <87bpjr7598.fsf@kelsey-ws.hq.ember.com> <877huf6xzi.fsf@kelsey-ws.hq.ember.com> X-Mailer: Apple Mail (2.936) Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 01:47:19 -0000 On Oct 28, 2009, at 1:54 PM, Richard Kelsey wrote: > The Destination Advertisement Object has space for only one > prefix and one reverse route stack. Are you saying that > multiple DAOs can be included in a single ICMPv6 message? > > To make this aggregation work, nodes higher in the DAG have to > wait to receive the DAOs from their descendants. How long > should they wait? To make this more clear, lets replace A with X, Y, and Z hanging off of B: X \ Y - B - C - D / Z Assume again that B and C cannot store any routes. In the best case, the DAOs that D will receive are X[BC], Y[BC], and Z[BC]. As currently specified, there is no way to aggregate those three DAOs into a single DAO. It is possible to carry multiple DAOs in a single datagram, but a "stateless" node can only buffer so much before offloading DAOs to its parent(s). In a network where all nodes (except the root) do not maintain any DAO state, the sole purpose of DAOs is to communicate DAG edges to the root. The record-route format is, in some cases, more efficient because it provides a list of addresses, rather than a list of address pairs. The best case for using record-route is a long linear network - half of what it would cost to communicate address pairs. The worst case is a network that has high fan-out - a record-route message must be communicated for each leaf node. More simply, the number of DAOs that MUST be communicated scales with the number of DAG leaves. We could do a bit better in the high fain-out case by allowing a node to "terminate" a record-route when it thinks its redundant, preventing nodes further down the line from appending, but I think the complexity of doing this right outweighs the benefits. Though, as Richard mentioned, record-route is useful for on-demand purposes. It can also be extremely useful as a debugging/diagnosis tool. Given that, it seems useful to support both parent-only and record-route reporting. -- Jonathan Hui From mcr@marajade.sandelman.ca Wed Oct 28 19:44:25 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D976428C119 for ; Wed, 28 Oct 2009 19:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huLH-XXKGxoJ for ; Wed, 28 Oct 2009 19:44:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id EE35E28C0F8 for ; Wed, 28 Oct 2009 19:44:24 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id F00903428C; Thu, 29 Oct 2009 02:50:16 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id DFF003EC5; Wed, 28 Oct 2009 22:44:38 -0400 (EDT) From: Michael Richardson To: Jonathan Hui In-Reply-To: <5D0A158B-EC94-4984-9E0D-E706DA736BD6@archrock.com> References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com><0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com><87hbtj7bnr.fsf@kelsey-ws.hq.ember.com><87fx93792q.fsf@kelsey-ws.hq.ember.com><73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> <87bpjr7598.fsf@kelsey-ws.hq.ember.com> <877huf6xzi.fsf@kelsey-ws.hq.ember.com> <5D0A158B-EC94-4984-9E0D-E706DA736BD6@archrock.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 28 Oct 2009 22:44:38 -0400 Message-ID: <25852.1256784278@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 02:44:25 -0000 (XYZ/BCD analysis, which I understood, and agree with... A first!) >>>>> "Jonathan" == Jonathan Hui writes: Jonathan> We could do a bit better in the high fain-out case by Jonathan> allowing a node to "terminate" a record-route when it Jonathan> thinks its redundant, preventing nodes further down the Jonathan> line from appending, but I think the complexity of doing Jonathan> this right outweighs the benefits. Though, as Richard Jonathan> mentioned, record-route is useful for on-demand purposes. Jonathan> It can also be extremely useful as a debugging/diagnosis Jonathan> tool. Given that, it seems useful to support both Jonathan> parent-only and record-route reporting. Which one is MUST, and which one is MAY? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jvasseur@cisco.com Thu Oct 29 01:28:19 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 149683A6895; Thu, 29 Oct 2009 01:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.731 X-Spam-Level: X-Spam-Status: No, score=-9.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebxxRc2LR0wu; Thu, 29 Oct 2009 01:28:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 62F863A6806; Thu, 29 Oct 2009 01:28:17 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIAALLu6EqQ/uCWe2dsb2JhbACCJC4hmFEBARYkBqdkmAqEPwQ X-IronPort-AV: E=Sophos;i="4.44,645,1249257600"; d="scan'208,217";a="53067975" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 08:28:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T8SWMj022298; Thu, 29 Oct 2009 08:28:32 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:28:32 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 09:28:31 +0100 Message-Id: <00A735BE-AB5A-468D-9ECB-D5E5399F6A4F@cisco.com> From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-36--675163583 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 09:28:30 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 08:28:31.0728 (UTC) FILETIME=[CC663700:01CA5871] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16976.003 X-TM-AS-Result: No--31.006400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll ROLL , roll-bounces@ietf.org Subject: Re: [Roll] Need clarification ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 08:28:19 -0000 --Apple-Mail-36--675163583 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Oct 28, 2009, at 9:21 PM, Jerald.P.Martocci@jci.com wrote: > > JP, > > For us IETF rookies - Is there a document that describes the use of > the Issue Tracker? Not sure what you mean by issue tracker ? You mean the tickets ? If so, yes they are managed by the chairs. Thanks JP. > Do we send them to the Chair to be entered? Do we enter them > ourselves? How do we query the tracker? What states might an issue > take on? > > Please advise. > > Jerry > > > > JP Vasseur > Sent by: roll-bounces@ietf.org > 10/28/2009 07:58 AM > > To > roll ROLL > cc > Subject > [Roll] Need clarification ? > > > > > > Dear all, > > As Tim pointed out, RPL Rev-04 did simplify the protocol quite > significantly, which was our WG's main objective. > There are still areas where the text may not be sufficiently detailed > (I did receive questions from several implementers showing a lack of > clarity). > > Could you please review and let us know where the text is not > sufficiently detailed or ambiguous ? > > This way we could address any potential lack of clarity in rev-05 + > add the FSM as promised. > > I'll start opening tickets, now is probably a good time. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-36--675163583 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Oct 28, 2009, at 9:21 PM, Jerald.P.Martocci@jci.com = wrote:


JP,
=
For us IETF rookies - Is there = a document that describes the use of the Issue Tracker? =  

Not sure what you mean by = issue tracker ? You mean the tickets ? If so, yes they are managed by = the = chairs.

Thanks

JP.
=
Do we = send them to the Chair to be entered?  Do we enter them ourselves? =  How do we query the tracker?  What states might an issue take = on?

Please = advise.

Jerry
=


=
JP Vasseur = <jvasseur@cisco.com> =
Sent by: roll-bounces@ietf.org

<= font size=3D"1" face=3D"sans-serif">10/28/2009 07:58 AM =

To
roll ROLL <roll@ietf.org>
cc
Subject
[Roll] Need clarification = ?

=

=


Dear all,

As Tim pointed = out, RPL Rev-04 did simplify the protocol quite  
= significantly, which was our WG's main objective.
There are still = areas where the text may not be sufficiently detailed  
(I did = receive questions from several implementers showing a lack of  
= clarity).

Could you please review and let us know where the = text is not  
sufficiently detailed or ambiguous ?

= This way we could address any potential lack of clarity in rev-05 + =  
add the FSM as promised.

I'll start opening tickets, = now is probably a good time.

Thanks.

JP.
= _______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll
 =

= --Apple-Mail-36--675163583-- From jvasseur@cisco.com Thu Oct 29 02:35:48 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B053A6919 for ; Thu, 29 Oct 2009 02:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.753 X-Spam-Level: X-Spam-Status: No, score=-9.753 tagged_above=-999 required=5 tests=[AWL=0.846, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqkTwI-rsjdG for ; Thu, 29 Oct 2009 02:35:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3C61D3A68A5 for ; Thu, 29 Oct 2009 02:35:47 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAABv/6EqQ/uCWe2dsb2JhbACbRgEBFiQGp3qYFYQ9BIFi X-IronPort-AV: E=Sophos;i="4.44,645,1249257600"; d="scan'208";a="53075774" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 09:36:02 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9T9a2cm013447; Thu, 29 Oct 2009 09:36:02 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 10:36:02 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 10:36:01 +0100 Message-Id: <11544EC3-715C-40C0-A8F4-8935DB17CB90@cisco.com> From: JP Vasseur To: Jonathan Hui In-Reply-To: <5D0A158B-EC94-4984-9E0D-E706DA736BD6@archrock.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 10:35:59 +0100 References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com><0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com><87hbtj7bnr.fsf@kelsey-ws.hq.ember.com><87fx93792q.fsf@kelsey-ws.hq.ember.com><73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> <87bpjr7598.fsf@kelsey-ws.hq.ember.com> <877huf6xzi.fsf@kelsey-ws.hq.ember.com> <5D0A158B-EC94-4984-9E0D-E706DA736BD6@archrock.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 09:36:01.0873 (UTC) FILETIME=[3A794C10:01CA587B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16976.003 X-TM-AS-Result: No--22.190800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 09:35:48 -0000 Hi Jonathan, What I was referring to was to pack prefix in DAO, a very light change in the spec (just make use of TLV) and factor the common fields. This allows to reduce the number of packets very significantly as we get closer to the root. There two benefits here: 1) You send one DAO between C and D instead of 3 2) You can also pack the Reverse Route Stack whenever possible for all prefix sharing the same routes. Let's suppose that: 1) X advertises two prefixes X1 and X2 2) Y advertises two prefixes Y1, Y2 and Y3 3) Z advertised one prefix: Z1 Instead of sending 6 DAO, C would send one DAO to D would look like this: X1,X2[XBC], Y1,Y2,Y3[YBC], Z1[ZBC] Note that you could when possible also aggregates prefixes at the same time if they share a common path. BAck to you timing question Richard, it depends of the sequence of events but there is no need to wait. C could start with one DAO and then start to pack at it receives more, the same reasoning applies to other nodes. Others, thoughts ? Thanks. JP. On Oct 29, 2009, at 2:47 AM, Jonathan Hui wrote: > > On Oct 28, 2009, at 1:54 PM, Richard Kelsey wrote: > >> The Destination Advertisement Object has space for only one >> prefix and one reverse route stack. Are you saying that >> multiple DAOs can be included in a single ICMPv6 message? >> >> To make this aggregation work, nodes higher in the DAG have to >> wait to receive the DAOs from their descendants. How long >> should they wait? > > > To make this more clear, lets replace A with X, Y, and Z hanging off > of B: > > X > \ > Y - B - C - D > / > Z > > Assume again that B and C cannot store any routes. In the best > case, the DAOs that D will receive are X[BC], Y[BC], and Z[BC]. As > currently specified, there is no way to aggregate those three DAOs > into a single DAO. It is possible to carry multiple DAOs in a > single datagram, but a "stateless" node can only buffer so much > before offloading DAOs to its parent(s). > > In a network where all nodes (except the root) do not maintain any > DAO state, the sole purpose of DAOs is to communicate DAG edges to > the root. The record-route format is, in some cases, more efficient > because it provides a list of addresses, rather than a list of > address pairs. The best case for using record-route is a long > linear network - half of what it would cost to communicate address > pairs. The worst case is a network that has high fan-out - a record- > route message must be communicated for each leaf node. More simply, > the number of DAOs that MUST be communicated scales with the number > of DAG leaves. > > We could do a bit better in the high fain-out case by allowing a > node to "terminate" a record-route when it thinks its redundant, > preventing nodes further down the line from appending, but I think > the complexity of doing this right outweighs the benefits. Though, > as Richard mentioned, record-route is useful for on-demand > purposes. It can also be extremely useful as a debugging/diagnosis > tool. Given that, it seems useful to support both parent-only and > record-route reporting. > > -- > Jonathan Hui > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From trac@tools.ietf.org Thu Oct 29 05:00:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACF73A6902 for ; Thu, 29 Oct 2009 05:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 433B6iqxEiW3 for ; Thu, 29 Oct 2009 05:00:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 0D0083A6923 for ; Thu, 29 Oct 2009 05:00:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3TgD-0004Rd-DP; Thu, 29 Oct 2009 05:00:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 29 Oct 2009 12:00:37 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/roll/trac/ticket/5 Message-ID: <055.cd43776192c185ba307f01db1a65a371@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #5: DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:00:22 -0000 #5: DODAG --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- * This is currently being discussed by the RPL Author team * Email from Julien Is there a distinction between DAG and destination oriented DAG. From what I read I feel all DAGs are destination oriented. If this is correct I propose to remove the destination oriented DAG concept. -- Ticket URL: roll From trac@tools.ietf.org Thu Oct 29 05:01:17 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1713A657C for ; Thu, 29 Oct 2009 05:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHJQ0ARnq-Np for ; Thu, 29 Oct 2009 05:01:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 51A263A6908 for ; Thu, 29 Oct 2009 05:01:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3Th7-00053k-Kd; Thu, 29 Oct 2009 05:01:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 29 Oct 2009 12:01:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://rsync.tools.ietf.org/wg/roll/trac/ticket/6 Message-ID: <055.82953fb7ca07ae4f993dd45d9f020003@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #6: Multicast DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:01:18 -0000 #6: Multicast DAO --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Email from Julien regarding usage of multicast DAO: in the following scenario: A / \ B C if the purpose is to to allow B and C to talk to each other directly, the multicast DAO is equivalent to an unsolicited NA. In the scenarios like: A / \ B C | D if the purpose is to have B talk to D through C (instead of A then C), then the multicast DAO (including destination prefix option) makes sense. Is this scenario needed by some applications? Best, Julien -- Ticket URL: roll From trac@tools.ietf.org Thu Oct 29 05:02:00 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B263A6931 for ; Thu, 29 Oct 2009 05:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h17MNpbQQC0I for ; Thu, 29 Oct 2009 05:02:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 1E64E3A657C for ; Thu, 29 Oct 2009 05:02:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3Tho-0005Xo-DE; Thu, 29 Oct 2009 05:02:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 29 Oct 2009 12:02:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://rsync.tools.ietf.org/wg/roll/trac/ticket/7 Message-ID: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:02:00 -0000 #7: RPL bootstrap question: neighbor cache and DIOs dependency --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Email From Julien Hi all, as explained in section 5.4.2 of RPL, a DIO must not be processed if the source is not in the neighbor cache. The question is how do we expect the neighbor cache to be filled? topology: A | B B receives a DIO from A, A is not in B's neighbor cache: NS/NA exchanges will probably not occur, as B has no good reason to send packets to A (A is not a router for B, B has most of the time no data to send to A) RS/RA exchanges: do we expect to send RAs in RPL environments? Would this be enough? If there are no frequent RAs, or unsolicited NAs, then A will likely never be in B's neighbor cache. One way to solve this would be to allow SLLAO option in DIOs. Processing this option in ICMP messages (NS, RS, RA) is a well known process, and would create an entry in the neighbor cache, state STALE. what do you think? Julien __________ -- Ticket URL: roll From trac@tools.ietf.org Thu Oct 29 05:03:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4613A6962 for ; Thu, 29 Oct 2009 05:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhjVSIzx1fyf for ; Thu, 29 Oct 2009 05:03:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1:214:22ff:fe1f:1e54]) by core3.amsl.com (Postfix) with ESMTP id 8F8C53A692A for ; Thu, 29 Oct 2009 05:03:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1N3Tin-00062g-PS; Thu, 29 Oct 2009 05:03:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.5, by Edgewall Software To: wintert@acm.org, jpv@cisco.com X-Trac-Project: roll Date: Thu, 29 Oct 2009 12:03:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/roll/trac/ticket/8 Message-ID: <055.589c0f057f2d5ff596a835659492169c@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wintert@acm.org, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #8: DIO Option Lenght X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:03:04 -0000 #8: DIO Option Lenght --------------------------------+------------------------------------------- Reporter: jpv@… | Owner: wintert@… Type: defect | Status: new Priority: major | Milestone: Component: rpl | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------------- Email from Julien do we expect DIO suboptions to be longer than 255 bytes? if yes would it be ok to spell the length in multiple of 8bytes instead of bytes (value of 1 means 8 bytes, like in ND). The target is to use 8 bits instead of 16. -- Ticket URL: roll From pthubert@cisco.com Thu Oct 29 07:45:27 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3623A6828 for ; Thu, 29 Oct 2009 07:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.579 X-Spam-Level: X-Spam-Status: No, score=-9.579 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoqXADoCW6YU for ; Thu, 29 Oct 2009 07:45:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EAEE93A6768 for ; Thu, 29 Oct 2009 07:45:25 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="53111997" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 14:45:41 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TEjf0M023541; Thu, 29 Oct 2009 14:45:41 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:45:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 29 Oct 2009 15:45:37 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> In-Reply-To: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency Thread-Index: AcpYj7JQFyo/Efk5TGCsU8TR9EHlJgAFM81g References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> From: "Pascal Thubert (pthubert)" To: , X-OriginalArrivalTime: 29 Oct 2009 14:45:40.0961 (UTC) FILETIME=[7C792510:01CA58A6] Cc: roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 14:45:27 -0000 SGk6DQoNCkluIGZhY3QgYSBzdGFsZSBlbnRyeSBpcyBub3Qgc3VmZmljaWVudC4gV2UgbmVlZCBh biBlbnRyeSB0aGF0IGlzIHJlYWNoYWJsZS4gDQoNClRoYXQgaXMgdGhlIG1pbmltdW0gdmFsaWRh dGlvbiBwcm9jZXNzIHRoYXQgY29tZXMgd2l0aCB0aGUgZmFjdCB0aGF0IHRoZSBkcmFmdCBhcyBp dCBzdGFuZHMgdG9kYXkgZGVwZW5kcyBvbiBOUy9OQSBmbG93cyB0byBlbnN1cmUgYmlkaXIgY29u bmVjdGl2aXR5IHdpdGggdGhlIG5laWdoYm9yLiBUaGUgd2F5IEkgc2VlIGl0LCB0aGUgbm9kZSBz aG91bGQgYXQgbGVhc3QgdW5pY2FzdCBOUyB0byB0aGUgY2FuZGlkYXRlIHRvIGFzc2VydCB0aGF0 LiBJbiB0aGUgc2FtZSBmYXNoaW9uIGFzIE5VRCBhbGxvd3MgdGhlIG5vZGUgdG8gcmVtb3ZlIHRo ZSBwYXJlbnQuIEJ1dCBpZiBhIHN0cm9uZ2VyIHZhbGlkYXRpb24gbWVjaGFuaXNtIGlzIGluIHBs YWNlLCB0aGVuIHRoYXQgc2hvdWxkIHN1cGVyc2VkZSB0aGUgTlMvTkEuDQoNClNvb24gZW5vdWdo IHdlIG1pZ2h0IG5lZWQgdG8gZWxhYm9yYXRlIGEgYml0IG9uIHRoZSB2YWxpZGF0aW9uIHByb2Nl c3MuIEluIHNvbWUgZW52aXJvbm1lbnRzLCBpdCBjYW4gYmUgZG9uZSBhcyBwYXJ0IG9mIG1ldHJp Y3MgY29tcHV0YXRpb24sIGxpa2UgdXNpbmcgc3JjciByZXN1bHRzIGZvciBpbnN0YW5jZS4gVGhp bmdzIGxpa2UgdGhhdCBjYW5ub3QgYmUgaW4gdGhlIGJhc2Ugc3BlYyBidXQgdGhlbiwgZG8gdGhh dCBiZWxvbmcgdG8gbWV0cmljcywgYSBuZXcgZHJhZnQsIG9yIHNob3VsZCB2YWxpZGF0aW9uIGFi b3ZlIGFuZCBiZXlvbmQgTlMvTkEgYmUgbGVmdCB0byBpbXBsZW1lbnRhdGlvbj8NCg0KUGFzY2Fs DQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHJvbGwtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHJvbGwgaXNz dWUgdHJhY2tlcg0KPlNlbnQ6IGpldWRpIDI5IG9jdG9icmUgMjAwOSAxMzowMg0KPlRvOiB3aW50 ZXJ0QGFjbS5vcmc7IGpwdkBjaXNjby5jb20NCj5DYzogcm9sbEBpZXRmLm9yZw0KPlN1YmplY3Q6 IFtSb2xsXSBbcm9sbF0gIzc6IFJQTCBib290c3RyYXAgcXVlc3Rpb246IG5laWdoYm9yIGNhY2hl IGFuZCBESU9zIGRlcGVuZGVuY3kNCj4NCj4jNzogUlBMIGJvb3RzdHJhcCBxdWVzdGlvbjogbmVp Z2hib3IgY2FjaGUgYW5kIERJT3MgZGVwZW5kZW5jeQ0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g UmVwb3J0ZXI6ICBqcHZA4oCmICAgICAgICAgICAgICAgfCAgICAgICBPd25lcjogIHdpbnRlcnRA 4oCmDQo+ICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICB8ICAgICAgU3RhdHVzOiAgbmV3 DQo+IFByaW9yaXR5OiAgbWFqb3IgICAgICAgICAgICAgICB8ICAgTWlsZXN0b25lOg0KPkNvbXBv bmVudDogIHJwbCAgICAgICAgICAgICAgICAgfCAgICAgVmVyc2lvbjoNCj4gU2V2ZXJpdHk6ICBB Y3RpdmUgV0cgRG9jdW1lbnQgIHwgICAgS2V5d29yZHM6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiBFbWFpbCBGcm9tIEp1bGllbg0KPg0KPiBIaSBhbGwsDQo+DQo+IGFzIGV4cGxhaW5lZCBpbiBz ZWN0aW9uIDUuNC4yIG9mIFJQTCwgYSBESU8gbXVzdCBub3QgYmUgcHJvY2Vzc2VkIGlmIHRoZQ0K PiBzb3VyY2UgaXMgbm90IGluIHRoZSBuZWlnaGJvciBjYWNoZS4gVGhlIHF1ZXN0aW9uIGlzIGhv dyBkbyB3ZSBleHBlY3QgdGhlDQo+IG5laWdoYm9yIGNhY2hlIHRvIGJlIGZpbGxlZD8NCj4gdG9w b2xvZ3k6DQo+IEENCj4gfA0KPiBCDQo+IEIgcmVjZWl2ZXMgYSBESU8gZnJvbSBBLCBBIGlzIG5v dCBpbiBCJ3MgbmVpZ2hib3IgY2FjaGU6DQo+DQo+IE5TL05BIGV4Y2hhbmdlcyB3aWxsIHByb2Jh Ymx5IG5vdCBvY2N1ciwgYXMgQiBoYXMgbm8gZ29vZCByZWFzb24gdG8gc2VuZA0KPiBwYWNrZXRz IHRvIEEgKEEgaXMgbm90IGEgcm91dGVyIGZvciBCLCBCIGhhcyBtb3N0IG9mIHRoZSB0aW1lIG5v IGRhdGEgdG8NCj4gc2VuZCB0byBBKQ0KPiBSUy9SQSBleGNoYW5nZXM6IGRvIHdlIGV4cGVjdCB0 byBzZW5kIFJBcyBpbiBSUEwgZW52aXJvbm1lbnRzPyBXb3VsZCB0aGlzDQo+IGJlIGVub3VnaD8N Cj4gSWYgdGhlcmUgYXJlIG5vIGZyZXF1ZW50IFJBcywgb3IgdW5zb2xpY2l0ZWQgTkFzLCB0aGVu IEEgd2lsbCBsaWtlbHkgbmV2ZXINCj4gYmUgaW4gQidzIG5laWdoYm9yIGNhY2hlLg0KPg0KPiBP bmUgd2F5IHRvIHNvbHZlIHRoaXMgd291bGQgYmUgdG8gYWxsb3cgU0xMQU8gb3B0aW9uIGluIERJ T3MuIFByb2Nlc3NpbmcNCj4gdGhpcyBvcHRpb24gaW4gSUNNUCBtZXNzYWdlcyAoTlMsIFJTLCBS QSkgaXMgYSB3ZWxsIGtub3duIHByb2Nlc3MsIGFuZA0KPiB3b3VsZCBjcmVhdGUgYW4gZW50cnkg aW4gdGhlIG5laWdoYm9yIGNhY2hlLCBzdGF0ZSBTVEFMRS4NCj4NCj4gd2hhdCBkbyB5b3UgdGhp bms/DQo+DQo+IEp1bGllbg0KPiBfX19fX19fX19fDQo+DQo+LS0NCj5UaWNrZXQgVVJMOiA8aHR0 cDovL3JzeW5jLnRvb2xzLmlldGYub3JnL3dnL3JvbGwvdHJhYy90aWNrZXQvNz4NCj5yb2xsIDxo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcm9sbC8+DQo+DQo+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Sb2xsIG1haWxpbmcgbGlzdA0KPlJvbGxAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From pal@cs.stanford.edu Thu Oct 29 07:52:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40DE3A6782 for ; Thu, 29 Oct 2009 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MixnoaGkm+yc for ; Thu, 29 Oct 2009 07:52:16 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 0A0F83A6768 for ; Thu, 29 Oct 2009 07:52:16 -0700 (PDT) Received: from dnab42216d.stanford.edu ([171.66.33.109]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N3WM0-0006y5-Ur; Thu, 29 Oct 2009 07:52:24 -0700 Message-Id: <7208549A-51AF-4294-8522-8785A5B0CAFF@cs.stanford.edu> From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 07:51:50 -0700 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 14:52:16 -0000 On Oct 29, 2009, at 7:45 AM, Pascal Thubert (pthubert) wrote: > Hi: > > In fact a stale entry is not sufficient. We need an entry that is > reachable. > > That is the minimum validation process that comes with the fact that > the draft as it stands today depends on NS/NA flows to ensure bidir > connectivity with the neighbor. The way I see it, the node should at > least unicast NS to the candidate to assert that. In the same > fashion as NUD allows the node to remove the parent. But if a > stronger validation mechanism is in place, then that should > supersede the NS/NA. > > Soon enough we might need to elaborate a bit on the validation > process. In some environments, it can be done as part of metrics > computation, like using srcr results for instance. Things like that > cannot be in the base spec but then, do that belong to metrics, a > new draft, or should validation above and beyond NS/NA be left to > implementation? I think it should be left to implementations. Every time we specify something, we increase the complexity of the protocol and limit flexibility in future uses. We should only include something when we know for sure that there's one by-far-better way to do things (unlikely for almost anything in wireless), or when a property is needed for correctness. Phil From jabeille@cisco.com Thu Oct 29 07:54:31 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6533A692A for ; Thu, 29 Oct 2009 07:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.08 X-Spam-Level: X-Spam-Status: No, score=-8.08 tagged_above=-999 required=5 tests=[AWL=-1.481, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAbyV8UZkE5t for ; Thu, 29 Oct 2009 07:54:30 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 595863A6807 for ; Thu, 29 Oct 2009 07:54:30 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="199851332" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2009 14:54:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9TEshUM013837; Thu, 29 Oct 2009 14:54:46 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 15:54:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 15:54:43 +0100 Message-ID: In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency Thread-Index: AcpYj7JQFyo/Efk5TGCsU8TR9EHlJgAFM81gAACbBYA= References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> From: "Julien Abeille (jabeille)" To: "Pascal Thubert (pthubert)" , , X-OriginalArrivalTime: 29 Oct 2009 14:54:45.0094 (UTC) FILETIME=[C0CD4060:01CA58A7] Cc: roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 14:54:31 -0000 Hi Pascal, What I was trying to achieve is the validation. I was trying to see if standard ND (let's not diverge) can achieve this. With a LLAO, the entry would be created (STALE), then the first time you want to route a packet through the router that originated the DIO, you would send the packet, arm a delay timer... do NUD as usual. Comment on this: - depends on 6lowpan discussions... questions: - do we think this is enough? - otherwise do we need to specify a custom mechanism inside RPL? Best, Julien > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: jeudi 29 octobre 2009 15:46 > To: wintert@acm.org; jpv@cisco.com > Cc: roll > Subject: Re: [Roll] [roll] #7: RPL bootstrap question:=20 > neighbor cache andDIOs dependency >=20 > Hi: >=20 > In fact a stale entry is not sufficient. We need an entry=20 > that is reachable.=20 >=20 > That is the minimum validation process that comes with the=20 > fact that the draft as it stands today depends on NS/NA flows=20 > to ensure bidir connectivity with the neighbor. The way I see=20 > it, the node should at least unicast NS to the candidate to=20 > assert that. In the same fashion as NUD allows the node to=20 > remove the parent. But if a stronger validation mechanism is=20 > in place, then that should supersede the NS/NA. >=20 > Soon enough we might need to elaborate a bit on the=20 > validation process. In some environments, it can be done as=20 > part of metrics computation, like using srcr results for=20 > instance. Things like that cannot be in the base spec but=20 > then, do that belong to metrics, a new draft, or should=20 > validation above and beyond NS/NA be left to implementation? >=20 > Pascal >=20 > >-----Original Message----- > >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=20 > On Behalf Of=20 > >roll issue tracker > >Sent: jeudi 29 octobre 2009 13:02 > >To: wintert@acm.org; jpv@cisco.com > >Cc: roll@ietf.org > >Subject: [Roll] [roll] #7: RPL bootstrap question: neighbor=20 > cache and=20 > >DIOs dependency > > > >#7: RPL bootstrap question: neighbor cache and DIOs dependency > >--------------------------------+---------------------------- > ---------- > >--------------------------------+----- > > Reporter: jpv@... | Owner: wintert@... > > Type: defect | Status: new > > Priority: major | Milestone: > >Component: rpl | Version: > > Severity: Active WG Document | Keywords: > >--------------------------------+---------------------------- > ---------- > >--------------------------------+----- > > Email From Julien > > > > Hi all, > > > > as explained in section 5.4.2 of RPL, a DIO must not be=20 > processed if=20 > > the source is not in the neighbor cache. The question is how do we=20 > > expect the neighbor cache to be filled? > > topology: > > A > > | > > B > > B receives a DIO from A, A is not in B's neighbor cache: > > > > NS/NA exchanges will probably not occur, as B has no good reason to=20 > > send packets to A (A is not a router for B, B has most of=20 > the time no=20 > > data to send to A) RS/RA exchanges: do we expect to send RAs in RPL=20 > > environments? Would this be enough? > > If there are no frequent RAs, or unsolicited NAs, then A=20 > will likely=20 > > never be in B's neighbor cache. > > > > One way to solve this would be to allow SLLAO option in DIOs.=20 > > Processing this option in ICMP messages (NS, RS, RA) is a=20 > well known=20 > > process, and would create an entry in the neighbor cache,=20 > state STALE. > > > > what do you think? > > > > Julien > > __________ > > > >-- > >Ticket URL: > >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 >=20 From richard.kelsey@ember.com Thu Oct 29 07:56:42 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1283A6807 for ; Thu, 29 Oct 2009 07:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNVs5nnKXPg5 for ; Thu, 29 Oct 2009 07:56:41 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 1C40C3A67E6 for ; Thu, 29 Oct 2009 07:56:40 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 10:58:13 -0400 Date: Thu, 29 Oct 2009 10:54:22 -0400 Message-Id: <874opi6yjl.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: <11544EC3-715C-40C0-A8F4-8935DB17CB90@cisco.com> (message from JP Vasseur on Thu, 29 Oct 2009 10:35:59 +0100) From: Richard Kelsey References: <87my3b7f9n.fsf@kelsey-ws.hq.ember.com><0F0F43A6-1F19-4166-B589-8E9687969451@cisco.com><87hbtj7bnr.fsf@kelsey-ws.hq.ember.com><87fx93792q.fsf@kelsey-ws.hq.ember.com><73DC7200-37B8-4B96-9E4B-9DC767F605AB@cisco.com> <87bpjr7598.fsf@kelsey-ws.hq.ember.com> <877huf6xzi.fsf@kelsey-ws.hq.ember.com> <5D0A158B-EC94-4984-9E0D-E706DA736BD6@archrock.com> <11544EC3-715C-40C0-A8F4-8935DB17CB90@cisco.com> X-OriginalArrivalTime: 29 Oct 2009 14:58:13.0903 (UTC) FILETIME=[3D42F9F0:01CA58A8] Cc: roll@ietf.org Subject: Re: [Roll] clarification about source routing X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 14:56:42 -0000 I think we are focusing on minor improvements to an already not-too-bad case, where the entire DAG is sending DAOs and only the root stores the routes. The issues I was trying to address with an alternate mechanism concern: - DAOs sent in reaction to DAG changes - nodes besides the root storing routes - DAOs sent to multiple parents And most especially, how do these interact with each other? To take one example, as far as the DAG itself goes, switching to a new parent at the same depth has a very low cost, and to one at a different depth only a moderate cost. On the other hand, depending on the details of the situation, the DAO overhead of a node switching to a new parent may be very large. Suppose a few nodes besides the root are capable of storing downwards routes. If a node changes parents such that the ancestor storing the route to it does not change, then only that ancestor has to be informed of the change, and only needs to be told the identity of the new parent. All other path information can be inferred. On the other hand, if the new parent results in a new route-storing ancestor, then the entire subtree below the parent-changing node has to be reported upwards. There are a lot of complexities lurking here. We need to be clearer about what they are and how much of this we want to support. -Richard Kelsey From mcr@marajade.sandelman.ca Thu Oct 29 08:04:53 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93153A6807 for ; Thu, 29 Oct 2009 08:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dr3iIPrr023P for ; Thu, 29 Oct 2009 08:04:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 300CE3A6782 for ; Thu, 29 Oct 2009 08:04:52 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 4716C342B1 for ; Thu, 29 Oct 2009 15:10:48 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 2022A4E804 for ; Thu, 29 Oct 2009 11:05:08 -0400 (EDT) From: Michael Richardson To: roll In-Reply-To: <7208549A-51AF-4294-8522-8785A5B0CAFF@cs.stanford.edu> References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> <7208549A-51AF-4294-8522-8785A5B0CAFF@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 29 Oct 2009 11:05:08 -0400 Message-ID: <14493.1256828708@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 15:04:54 -0000 >>>>> "Philip" == Philip Levis writes: >> In fact a stale entry is not sufficient. We need an entry that is >> reachable. >> >> That is the minimum validation process that comes with the fact >> that the draft as it stands today depends on NS/NA flows to >> ensure bidir connectivity with the neighbor. The way I see it, >> the node should at least unicast NS to the candidate to assert >> that. In the same fashion as NUD allows the node to remove the >> parent. But if a stronger validation mechanism is in place, then >> that should supersede the NS/NA. >> >> Soon enough we might need to elaborate a bit on the validation >> process. In some environments, it can be done as part of metrics >> computation, like using srcr results for instance. Things like >> that cannot be in the base spec but then, do that belong to >> metrics, a new draft, or should validation above and beyond NS/NA >> be left to implementation? Philip> I think it should be left to implementations. Every time we Philip> specify something, we increase the complexity of the Philip> protocol and limit flexibility in future uses. We should Everytime you do not specify something, you leave things open to interoperability issues. If interoperability is not important to you, then just implement a proprietary protocol. As I understand the validation here, it is to assure a child that the parent that it selects will in fact be able to hear it? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jabeille@cisco.com Thu Oct 29 08:12:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150F328C0E4 for ; Thu, 29 Oct 2009 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.012 X-Spam-Level: X-Spam-Status: No, score=-8.012 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5GJXErMjHOk for ; Thu, 29 Oct 2009 08:12:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CBBC028C0DD for ; Thu, 29 Oct 2009 08:12:18 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABZO6UqrR7H+/2dsb2JhbADGEok/jlSEPQQ X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="420525518" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 15:12:33 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TFCUEe011755; Thu, 29 Oct 2009 15:12:32 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 16:12:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 16:12:24 +0100 Message-ID: In-Reply-To: <14493.1256828708@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency Thread-Index: AcpYqTx9EuZeOyV8QHuAaG5P+cqfQgAABfRw References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org><6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com><7208549A-51AF-4294-8522-8785A5B0CAFF@cs.stanford.edu> <14493.1256828708@marajade.sandelman.ca> From: "Julien Abeille (jabeille)" To: "Michael Richardson" , "roll" X-OriginalArrivalTime: 29 Oct 2009 15:12:25.0882 (UTC) FILETIME=[3914A7A0:01CA58AA] Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache andDIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 15:12:20 -0000 Hi Michael,=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Michael Richardson > Sent: jeudi 29 octobre 2009 16:05 > To: roll > Subject: Re: [Roll] [roll] #7: RPL bootstrap question:=20 > neighbor cache andDIOs dependency >=20 >=20 > >>>>> "Philip" =3D=3D Philip Levis writes: > >> In fact a stale entry is not sufficient. We need an=20 > entry that is > >> reachable. > >>=20 > >> That is the minimum validation process that comes with the fact > >> that the draft as it stands today depends on NS/NA flows to > >> ensure bidir connectivity with the neighbor. The way I see it, > >> the node should at least unicast NS to the candidate to assert > >> that. In the same fashion as NUD allows the node to remove the > >> parent. But if a stronger validation mechanism is in=20 > place, then > >> that should supersede the NS/NA. > >>=20 > >> Soon enough we might need to elaborate a bit on the validation > >> process. In some environments, it can be done as part=20 > of metrics > >> computation, like using srcr results for instance. Things like > >> that cannot be in the base spec but then, do that belong to > >> metrics, a new draft, or should validation above and=20 > beyond NS/NA > >> be left to implementation? >=20 > Philip> I think it should be left to implementations.=20 > Every time we > Philip> specify something, we increase the complexity of the > Philip> protocol and limit flexibility in future uses. We should >=20 > Everytime you do not specify something, you leave things open=20 > to interoperability issues. > If interoperability is not=20 > important to you, then just implement a proprietary protocol. >=20 > As I understand the validation here, it is to assure a child=20 > that the parent that it selects will in fact be able to hear it? >=20 Correct. It could be as simple as reachable/unreachable (ND can do this) but will be more granular.=20 Julien > --=20 > ] He who is tired of Weird Al is tired of life! =20 > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON =20 > |net architect[ > ] mcr@sandelman.ottawa.on.ca=20 > http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video=20 > > then sign the petition.=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jvasseur@cisco.com Thu Oct 29 08:22:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEB83A69D3 for ; Thu, 29 Oct 2009 08:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.79 X-Spam-Level: X-Spam-Status: No, score=-7.79 tagged_above=-999 required=5 tests=[AWL=-1.191, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKkqsOjiQvDa for ; Thu, 29 Oct 2009 08:22:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B332C3A6859 for ; Thu, 29 Oct 2009 08:22:13 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG5Q6UqrR7H+/2dsb2JhbADGHZgThD0E X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="420531638" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 15:21:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9TFKfuu021714 for ; Thu, 29 Oct 2009 15:21:21 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 16:21:20 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 16:21:20 +0100 Message-Id: <486595F1-3503-41F4-A581-D28AC87FF768@cisco.com> From: JP Vasseur To: roll ROLL Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 16:21:19 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 15:21:20.0513 (UTC) FILETIME=[77BEDF10:01CA58AB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16976.003 X-TM-AS-Result: No--0.135200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Time Shift in Europe X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 15:22:16 -0000 Tim/Phil brought to my attention that time difference between Europe and US has now changed (time shift) The call is at 5pm CET = 10:00am ET = 7:00am PST From pal@cs.stanford.edu Thu Oct 29 08:28:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AF633A697B for ; Thu, 29 Oct 2009 08:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcepOcHXdWiL for ; Thu, 29 Oct 2009 08:28:44 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 366E73A696E for ; Thu, 29 Oct 2009 08:28:44 -0700 (PDT) Received: from dnab42216d.stanford.edu ([171.66.33.109]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1N3WvN-0000uf-4g; Thu, 29 Oct 2009 08:28:39 -0700 Message-Id: From: Philip Levis To: Michael Richardson In-Reply-To: <14493.1256828708@marajade.sandelman.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 08:28:23 -0700 References: <055.6c24fd9c2058564c141489a4810f75a1@tools.ietf.org> <6A2A459175DABE4BB11DE2026AA50A5D865C60@XMB-AMS-107.cisco.com> <7208549A-51AF-4294-8522-8785A5B0CAFF@cs.stanford.edu> <14493.1256828708@marajade.sandelman.ca> X-Mailer: Apple Mail (2.936) X-Scan-Signature: f69c4e6b4bf914f22ae37cd490358bf0 Cc: roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 15:28:45 -0000 On Oct 29, 2009, at 8:05 AM, Michael Richardson wrote: > >>>>>> "Philip" == Philip Levis writes: >>> In fact a stale entry is not sufficient. We need an entry that is >>> reachable. >>> >>> That is the minimum validation process that comes with the fact >>> that the draft as it stands today depends on NS/NA flows to >>> ensure bidir connectivity with the neighbor. The way I see it, >>> the node should at least unicast NS to the candidate to assert >>> that. In the same fashion as NUD allows the node to remove the >>> parent. But if a stronger validation mechanism is in place, then >>> that should supersede the NS/NA. >>> >>> Soon enough we might need to elaborate a bit on the validation >>> process. In some environments, it can be done as part of metrics >>> computation, like using srcr results for instance. Things like >>> that cannot be in the base spec but then, do that belong to >>> metrics, a new draft, or should validation above and beyond NS/NA >>> be left to implementation? > > Philip> I think it should be left to implementations. Every time we > Philip> specify something, we increase the complexity of the > Philip> protocol and limit flexibility in future uses. We should > > Everytime you do not specify something, you leave things open to > interoperability issues. If interoperability is not important to you, > then just implement a proprietary protocol. Of course -- that's what I meant by "correctness." I'm sorry if I was too terse to be clear. You want to specify behavior sufficiently that an implementation can behave correctly and interoperate. I'm just trying to give a little push-back on adding more complexity to the draft unless it's necessary. In this case, the problem seems to stem from the fact that -04 specifies that a node MUST NOT process a DIO. If we remove that restriction, doesn't it solve the problem? I guess I'm not sure why this requires any new mechanisms or specification. An implementation may wish to use NS/NA to check how lossy communication with a particular neighbor is, but the original issue raised was one of discovery, right? Phil From pthubert@cisco.com Thu Oct 29 08:30:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC143A67EC for ; Thu, 29 Oct 2009 08:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.398 X-Spam-Level: X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGUOGbLmzjOA for ; Thu, 29 Oct 2009 08:30:11 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 304673A6783 for ; Thu, 29 Oct 2009 08:30:10 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAAFxS6UqQ/uCWe2dsb2JhbACCJiyYdQEBFiQGqhiYFAKEOwQ X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="gif'147?scan'147,208,217,147";a="53117265" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 15:30:25 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TFULI5007279 for ; Thu, 29 Oct 2009 15:30:25 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 16:30:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CA58AC.B66D08AD"; type="multipart/alternative" Date: Thu, 29 Oct 2009 16:30:08 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D865CB0@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE930251@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Need Clarification: DA Parents Thread-Index: AcpX1EVAnB+F3kQLTrC+LqkbS2iGTwA0qXiw References: <8A977BDC5A7B0E429B0F521E8D6F91EE930251@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "roll" X-OriginalArrivalTime: 29 Oct 2009 15:30:19.0434 (UTC) FILETIME=[B8F7B0A0:01CA58AC] Subject: Re: [Roll] Need Clarification: DA Parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 15:30:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA58AC.B66D08AD Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA58AC.B66D08AD" ------_=_NextPart_002_01CA58AC.B66D08AD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mathilde =20 " If destination advertisements are activated in the DIO message as indicated by the `D' bit, the node sends unicast destination advertisements to one of its DA parents, that is selected as most favored for incoming outwards traffic." --> so the node does not necessarily send the unicast DAO to the parent = who sent the DIO? This seems to contradict section 5.10.1.1.1 where you = actually use a DelayDAO timer per "particular DA parent". =20 Pascal =3D> The sentence should say that the node might use that parent = as most favored parent for incoming outwards traffic and thus send it = sDAOs to that parent. =20 --> Why would we keep a DA parent set if we send DAO only to the most = preferred one? =20 Pascal -> That is in fact a subset of the parent set. In the parent set, = you have a preferred parent for DIOs, the one you inherit metrics from. = You also have a preferred parent for DAO, that might or might not be the = same. =20 " The node only accepts unicast destination advertisements from any nodes but those contained in the DA parent subset." --> should a node accept DAO from nodes the are not in its sub-dag? =20 Pascal -> The receiver does not know that the source is in its subDAG, = that but from the fact that it gets DAOs from it. Being in the subDAG is = a decision from that source.=20 =20 More generally do we really need the concept of 'DA parents' in addition = to 'parents'. Could we maybe mandate the DA parents =3D the Parents or = alternatively that the DA parent =3D the most preferred parent.=20 =20 Pascal -> could be. That simplifies but limits.=20 Note that having a single DA parent could save a lot of state in terms = of DelayDAO timers and reported flags. =20 Yes, we are taking that path. Also the complexity of fanning out seemed = overkill at this point. =20 Cheers,=20 =20 Pascal Best, Mathilde =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 ------_=_NextPart_002_01CA58AC.B66D08AD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mathilde

 

"=   If = destination advertisements are activated in the DIO message as
=A0=A0 indicated by the `D' bit, the node sends unicast destination
=A0=A0 advertisements = to one of its DA parents, that is selected as most
=A0=A0 favored for incoming outwards = traffic."

--> so the node does not necessarily send the unicast DAO to the parent who = sent the DIO? This seems to contradict section 5.10.1.1.1 where you actually use = a DelayDAO timer per "particular DA = parent".

 

Pascal =3D> The sentence should say that the node = might use that parent as most favored parent for incoming outwards traffic and = thus send it sDAOs to that parent.

 

--> Why would we keep a DA parent set if we send DAO only to the most = preferred one?

 

Pascal -> That is in fact a subset of the parent set. = In the parent set, you have a preferred parent for DIOs, the one you inherit = metrics from. You also have a preferred parent for DAO, that might or might not = be the same.

 

"=A0 The node only accepts unicast
=A0=A0 destination advertisements from any nodes but those contained in = the
=A0=A0 DA parent subset."

--> should a node accept DAO from nodes the are not in its = sub-dag?

 

Pascal -> The receiver does not know that the source = is in its subDAG, that but from the fact that it gets DAOs from it. Being in = the subDAG is a decision from that source.

 

More generally do we really need the concept of 'DA parents' in addition to 'parents'. Could we maybe mandate the DA parents =3D the Parents or = alternatively that the DA parent =3D the most preferred parent.

 

Pascal -> could be. That simplifies but limits. =

Note that having a single DA parent could save a lot of state in terms of = DelayDAO timers and reported flags.

 

Yes, we are taking that path. Also the complexity of = fanning out seemed overkill at this point.

 

Cheers,

 

Pascal

Best,<= o:p>

Mathilde=

 

Durvy = Mathilde=
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

= Cisco Systems International S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page

 

 

3D"ThinkThink before you print.

This e-mail may contain = confidential and privileged material for the sole use of the intended recipient. = Any review, use, distribution or disclosure by others is strictly = prohibited. If you are not the intended recipient (or authorized to receive for = the recipient), please contact the sender by reply e-mail and delete all = copies of this message.


 

------_=_NextPart_002_01CA58AC.B66D08AD-- ------_=_NextPart_001_01CA58AC.B66D08AD Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA58AC.B66D08AD Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA58AC.B66D08AD-- From sung.lee@us.fujitsu.com Thu Oct 29 09:08:47 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC973A69D7 for ; Thu, 29 Oct 2009 09:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.179 X-Spam-Level: X-Spam-Status: No, score=-106.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdFmNRRDn0DZ for ; Thu, 29 Oct 2009 09:08:46 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 2EAA33A68AE for ; Thu, 29 Oct 2009 09:08:46 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9TGA0Tl014207 for ; Thu, 29 Oct 2009 09:10:00 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9TGA0wL014204 for ; Thu, 29 Oct 2009 09:10:00 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id n9TG91lZ027669 for ; Thu, 29 Oct 2009 09:09:01 -0700 (PDT) Received: from [10.157.253.54] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n9TG90822419 for ; Thu, 29 Oct 2009 09:09:00 -0700 (PDT) Message-ID: <4AE9BE1A.6080506@us.fujitsu.com> Date: Thu, 29 Oct 2009 12:08:58 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 16:08:47 -0000 Tim and WG members, I was reviewing v04 and have some concerns about current proposal. In particular, the restriction on 2 sibling hops in a row. > 5.11.4. Sibling Loop Avoidance > > When a packet is forwarded along siblings, it cannot be checked for > forward progress and may loop between siblings. Experimental > evidence has shown that one sibling hop can be very useful but is > generally sufficient to avoid loops. Based on that evidence, this > specification enforces the simple rule that a packet may not make 2 > sibling hops in a row. I recall that the experiment result was presented at the interim meeting. However, it was also pointed out that if the selected sibling is not the right one, then you risk a packet loss. If the network topology is simple enough, this may be sufficient restriction to avoid sibling loops. Without much coordinated effort of trying to figure out the "right" next hop sibling, this simple restriction will cause many packet drops if the network topology is complicated. My understanding is that ROLL is targeting for a large scale network. And I have concerns about this. I would like to hear about what others think about this. Regards, Sung > > Message: 3 > Date: Tue, 27 Oct 2009 09:31:21 -0400 > From: Tim Winter > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt > Cc: roll@ietf.org > Message-ID: <4AE6F629.7070707@acm.org> > Content-Type: text/plain; charset=ISO-8859-1 > > WG, > > In this revision we did incorporate much of the recent feedback from the > list, including > - Remove recommendations for DAG splitting/merging (detach/float/reattach) > - Remove Held-Up state and related procedures > - Remove Held-Down state and related procedures > - Clarified that a DAG Instance is in support of a single application > objective / optimization, and that RPL specifies operation in a single DAG > Instance > - ICMPv6 message type proposed to carry DIO/DAO message + DIO/DAO revised > (OCP now comes from Metric Container) > - Updated DIO suboptions to be consistent with metrics draft (16 bit length) > - Added use of flow label to specify DAG Instance and allow for loop detection > - Misc. editorial changes > > We are still working to provide an FSM presentation of RPL. > > > Regards > > -RPL Authors > > Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. >> >> >> Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks >> Author(s) : T. Winter, et al. >> Filename : draft-ietf-roll-rpl-04.txt >> Pages : 82 >> Date : 2009-10-26 >> >> Low power and Lossy Networks (LLNs) are a class of network in which >> both the routers and their interconnect are constrained: LLN routers >> typically operate with constraints on (any subset of) processing >> > > >> power, memory and energy (battery), and their interconnects are >> characterized by (any subset of) high loss rates, low data rates and >> instability. LLNs are comprised of anything from a few dozen and up >> to thousands of LLN routers, and support point-to- point traffic >> (between devices inside the LLN), point-to-multipoint traffic (from a >> central control point to a subset of devices inside the LLN) and >> multipoint-to- point traffic (from devices inside the LLN towards a >> central control point). This document specifies the IPv6 Routing >> Protocol for LLNs (RPL), which provides a mechanism whereby >> multipoint-to-point traffic from devices inside the LLN towards a >> central control point, as well as point-to-multipoint traffic from >> the central control point to the devices inside the LLN, is >> supported. Support for point-to-point traffic is also available. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > > ------------------------------ > > Message: 4 > Date: Tue, 27 Oct 2009 12:57:46 -0400 > From: Sung Lee > Subject: Re: [Roll] RPL Metric ID > To: roll@ietf.org > Message-ID: <4AE7268A.5060209@us.fujitsu.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Philip, > > Sorry for my late response. I have been quite swamped with work and > travels. > I read your paper and I liked it. I like your concept of using > information from all three layers. > Although our approach is not as "formalized" as yours, I think > fundamentally we do share some similarity. > I would say that one difference is that we try to reflect the existence > of loop in the estimation. Since we do actively check for loop > existence, we reflect that into the estimation value by penalizing it. > But please note that we do not actively try to remove the loop when we > find it. Our experience is that by reflecting the existence of loops in > the estimation/metric, it sorts itself out over time. > > Thanks for sharing your paper. > Best regards, > Sung > > roll-request@ietf.org wrote: > >> Message: 2 >> Date: Thu, 15 Oct 2009 09:05:23 -0700 >> From: Philip Levis >> Subject: Re: [Roll] RPL Metric ID >> To: Sung Lee >> Cc: roll@ietf.org >> Message-ID: >> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >> >> >> On Oct 15, 2009, at 7:20 AM, Sung Lee wrote: >> >> >> >>> JP and WG members, >>> >>> This may be considered link reliability. >>> But in our experience, we found the following information very helpful >>> in improving the stability of network and also (and you could say) in >>> avoiding loops as well. >>> >>> We use what we call 'W' (weight). >>> When we forward data packet, we require per-hop ACK. >>> When we receive ACK, we adjust the new W to be old W -1 (W_new = >>> W_old - 1). >>> When we don't receive ACK, we adjust the new W to be old W + 1 >>> (W_old = >>> W_old +1). >>> When we detect a loop, we adjust the W value to MAX. >>> >>> We have experimented MAX value based on real system, MAX value of 10 >>> seems to be a good value to start with. >>> >>> Now this can be combined with other metric values you are all >>> discussing. We have experimented quite a lot with combing several >>> metrics with the above weight in determining the path, which so far >>> seems to work in our system. >>> For instance, the other metric values you are discussing (such as link >>> quality, RSSI, and/or everything else - please note this can be as >>> simple as hop count, RSSI, or whatever the WG determines) can be used >>> with along with W value to determine. >>> >>> I am interested in what the WG thinks of using this 'W' as part of >>> metric for RPL. >>> >>> >> Sung, >> >> I think the general approach of directly measuring the datapath is a >> great way to have fast and accurate link estimation. CTP's 4-bit link >> estimator (4B) has some similarities to what you describe, although it >> smoothes estimates much more: I'd be concerned about excessive >> instability in the above algorithm, as note that you can't measure a >> link you're not using. >> >> Have you read the 4-bit paper? You can find it at http://sing.stanford.edu/singpubs.html >> >> Phil >> >> >> >> >> >> > > > ------------------------------ > > Message: 5 > Date: Tue, 27 Oct 2009 14:00:55 -0400 > From: Michael Richardson > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt > To: roll@ietf.org > Message-ID: <6526.1256666455@marajade.sandelman.ca> > > > >>>>>> "Tim" == Tim Winter writes: >>>>>> > Tim> - Added use of flow label to specify DAG Instance and allow for loop detection > > Thanks, I think this will help people link things together. > > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > > > ------------------------------ > > Message: 6 > Date: Tue, 27 Oct 2009 19:22:33 +0100 > From: Alexandru Petrescu > Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt > To: Michael Richardson > Cc: roll@ietf.org > Message-ID: <4AE73A69.4080406@gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Michael Richardson a ?crit : > >>>>>>> "Tim" == Tim Winter writes: >>>>>>> >> Tim> - Added use of flow label to specify DAG Instance and allow for loop detection >> >> Thanks, I think this will help people link things together. >> > > I think calling it a "flow label" may collide with the flow label field > of IPv6 base header. > > Let me tell you why I say so. I recently went through an implementaiton > exercise where Route Lifetime and Router Lifetime were mistaken one for > the other, because they're close enough. > > Just a remark. > > Alex > > > > > ------------------------------ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > End of Roll Digest, Vol 21, Issue 82 > ************************************ > From jvasseur@cisco.com Thu Oct 29 09:18:15 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BB4F28C107 for ; Thu, 29 Oct 2009 09:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.463 X-Spam-Level: X-Spam-Status: No, score=-7.463 tagged_above=-999 required=5 tests=[AWL=-1.464, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6uv2nP3j9Fi for ; Thu, 29 Oct 2009 09:18:13 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8C10328C0F6 for ; Thu, 29 Oct 2009 09:18:13 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFJd6UqrR7Hu/2dsb2JhbADGNYk/jluEPQSBYg X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="420574767" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2009 16:18:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9TGIQI6029156; Thu, 29 Oct 2009 16:18:29 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:18:28 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:18:27 +0100 Message-Id: <45049DAF-552D-4D3D-9846-CBA60B77BFF8@cisco.com> From: JP Vasseur To: Sung Lee In-Reply-To: <4AE9BE1A.6080506@us.fujitsu.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 17:18:26 +0100 References: <4AE9BE1A.6080506@us.fujitsu.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 16:18:28.0006 (UTC) FILETIME=[72B0CC60:01CA58B3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16976.004 X-TM-AS-Result: No--14.837600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 16:18:15 -0000 On Oct 29, 2009, at 5:08 PM, Sung Lee wrote: > Tim and WG members, > > I was reviewing v04 and have some concerns about current proposal. > In particular, the restriction on 2 sibling hops in a row. > >> 5.11.4. Sibling Loop Avoidance >> >> When a packet is forwarded along siblings, it cannot be checked for >> forward progress and may loop between siblings. Experimental >> evidence has shown that one sibling hop can be very useful but is >> generally sufficient to avoid loops. Based on that evidence, this >> specification enforces the simple rule that a packet may not make 2 >> sibling hops in a row. > > I recall that the experiment result was presented at the interim > meeting. > However, it was also pointed out that if the selected sibling is not > the > right one, then you risk a packet loss. > If the network topology is simple enough, this may be sufficient > restriction to avoid sibling loops. > Without much coordinated effort of trying to figure out the "right" > next > hop sibling, this simple restriction will cause many packet drops if > the > network topology is complicated. > > My understanding is that ROLL is targeting for a large scale network. > And I have concerns about this. > I would like to hear about what others think about this. You're quite right that the results were for a limited topology size. I would vote for making it configurable 3-bit flag that could be adjusted according to the network topology. Thoughts ? JP. > > Regards, > Sung > >> >> Message: 3 >> Date: Tue, 27 Oct 2009 09:31:21 -0400 >> From: Tim Winter >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >> Cc: roll@ietf.org >> Message-ID: <4AE6F629.7070707@acm.org> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> WG, >> >> In this revision we did incorporate much of the recent feedback >> from the >> list, including >> - Remove recommendations for DAG splitting/merging (detach/float/ >> reattach) >> - Remove Held-Up state and related procedures >> - Remove Held-Down state and related procedures >> - Clarified that a DAG Instance is in support of a single >> application >> objective / optimization, and that RPL specifies operation in a >> single DAG >> Instance >> - ICMPv6 message type proposed to carry DIO/DAO message + DIO/DAO >> revised >> (OCP now comes from Metric Container) >> - Updated DIO suboptions to be consistent with metrics draft (16 >> bit length) >> - Added use of flow label to specify DAG Instance and allow for >> loop detection >> - Misc. editorial changes >> >> We are still working to provide an FSM presentation of RPL. >> >> >> Regards >> >> -RPL Authors >> >> Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Routing Over Low power and Lossy >>> networks Working Group of the IETF. >>> >>> >>> Title : RPL: IPv6 Routing Protocol for Low power and >>> Lossy Networks >>> Author(s) : T. Winter, et al. >>> Filename : draft-ietf-roll-rpl-04.txt >>> Pages : 82 >>> Date : 2009-10-26 >>> >>> Low power and Lossy Networks (LLNs) are a class of network in which >>> both the routers and their interconnect are constrained: LLN routers >>> typically operate with constraints on (any subset of) processing >>> >> >> >>> power, memory and energy (battery), and their interconnects are >>> characterized by (any subset of) high loss rates, low data rates and >>> instability. LLNs are comprised of anything from a few dozen and up >>> to thousands of LLN routers, and support point-to- point traffic >>> (between devices inside the LLN), point-to-multipoint traffic >>> (from a >>> central control point to a subset of devices inside the LLN) and >>> multipoint-to- point traffic (from devices inside the LLN towards a >>> central control point). This document specifies the IPv6 Routing >>> Protocol for LLNs (RPL), which provides a mechanism whereby >>> multipoint-to-point traffic from devices inside the LLN towards a >>> central control point, as well as point-to-multipoint traffic from >>> the central control point to the devices inside the LLN, is >>> supported. Support for point-to-point traffic is also available. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 27 Oct 2009 12:57:46 -0400 >> From: Sung Lee >> Subject: Re: [Roll] RPL Metric ID >> To: roll@ietf.org >> Message-ID: <4AE7268A.5060209@us.fujitsu.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Philip, >> >> Sorry for my late response. I have been quite swamped with work and >> travels. >> I read your paper and I liked it. I like your concept of using >> information from all three layers. >> Although our approach is not as "formalized" as yours, I think >> fundamentally we do share some similarity. >> I would say that one difference is that we try to reflect the >> existence >> of loop in the estimation. Since we do actively check for loop >> existence, we reflect that into the estimation value by penalizing >> it. >> But please note that we do not actively try to remove the loop when >> we >> find it. Our experience is that by reflecting the existence of >> loops in >> the estimation/metric, it sorts itself out over time. >> >> Thanks for sharing your paper. >> Best regards, >> Sung >> >> roll-request@ietf.org wrote: >> >>> Message: 2 >>> Date: Thu, 15 Oct 2009 09:05:23 -0700 >>> From: Philip Levis >>> Subject: Re: [Roll] RPL Metric ID >>> To: Sung Lee >>> Cc: roll@ietf.org >>> Message-ID: >>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >>> >>> >>> On Oct 15, 2009, at 7:20 AM, Sung Lee wrote: >>> >>> >>> >>>> JP and WG members, >>>> >>>> This may be considered link reliability. >>>> But in our experience, we found the following information very >>>> helpful >>>> in improving the stability of network and also (and you could >>>> say) in >>>> avoiding loops as well. >>>> >>>> We use what we call 'W' (weight). >>>> When we forward data packet, we require per-hop ACK. >>>> When we receive ACK, we adjust the new W to be old W -1 (W_new = >>>> W_old - 1). >>>> When we don't receive ACK, we adjust the new W to be old W + 1 >>>> (W_old = >>>> W_old +1). >>>> When we detect a loop, we adjust the W value to MAX. >>>> >>>> We have experimented MAX value based on real system, MAX value of >>>> 10 >>>> seems to be a good value to start with. >>>> >>>> Now this can be combined with other metric values you are all >>>> discussing. We have experimented quite a lot with combing several >>>> metrics with the above weight in determining the path, which so far >>>> seems to work in our system. >>>> For instance, the other metric values you are discussing (such as >>>> link >>>> quality, RSSI, and/or everything else - please note this can be as >>>> simple as hop count, RSSI, or whatever the WG determines) can be >>>> used >>>> with along with W value to determine. >>>> >>>> I am interested in what the WG thinks of using this 'W' as part of >>>> metric for RPL. >>>> >>>> >>> Sung, >>> >>> I think the general approach of directly measuring the datapath is a >>> great way to have fast and accurate link estimation. CTP's 4-bit >>> link >>> estimator (4B) has some similarities to what you describe, >>> although it >>> smoothes estimates much more: I'd be concerned about excessive >>> instability in the above algorithm, as note that you can't measure a >>> link you're not using. >>> >>> Have you read the 4-bit paper? You can find it at http://sing.stanford.edu/singpubs.html >>> >>> Phil >>> >>> >>> >>> >>> >>> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 27 Oct 2009 14:00:55 -0400 >> From: Michael Richardson >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >> To: roll@ietf.org >> Message-ID: <6526.1256666455@marajade.sandelman.ca> >> >> >> >>>>>>> "Tim" == Tim Winter writes: >>>>>>> >> Tim> - Added use of flow label to specify DAG Instance and allow >> for loop detection >> >> Thanks, I think this will help people link things together. >> >> -- >> ] He who is tired of Weird Al is tired of life! | >> firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON | >> net architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | >> device driver[ >> Kyoto Plus: watch the video > > >> then sign the petition. >> >> >> ------------------------------ >> >> Message: 6 >> Date: Tue, 27 Oct 2009 19:22:33 +0100 >> From: Alexandru Petrescu >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >> To: Michael Richardson >> Cc: roll@ietf.org >> Message-ID: <4AE73A69.4080406@gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Michael Richardson a ?crit : >> >>>>>>>> "Tim" == Tim Winter writes: >>>>>>>> >>> Tim> - Added use of flow label to specify DAG Instance and >>> allow for loop detection >>> >>> Thanks, I think this will help people link things together. >>> >> >> I think calling it a "flow label" may collide with the flow label >> field >> of IPv6 base header. >> >> Let me tell you why I say so. I recently went through an >> implementaiton >> exercise where Route Lifetime and Router Lifetime were mistaken one >> for >> the other, because they're close enough. >> >> Just a remark. >> >> Alex >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> End of Roll Digest, Vol 21, Issue 82 >> ************************************ >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Thu Oct 29 09:28:46 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218023A67E7 for ; Thu, 29 Oct 2009 09:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.73 X-Spam-Level: X-Spam-Status: No, score=-9.73 tagged_above=-999 required=5 tests=[AWL=0.869, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf45tQveUiGj for ; Thu, 29 Oct 2009 09:28:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3FFB13A68AE for ; Thu, 29 Oct 2009 09:28:45 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAADJf6UqQ/uCWe2dsb2JhbACbSAEBFiQGqjKYGIQ9BA X-IronPort-AV: E=Sophos;i="4.44,646,1249257600"; d="scan'208";a="53123562" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 16:29:00 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TGT04X024395 for ; Thu, 29 Oct 2009 16:29:00 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:29:00 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 17:28:59 +0100 Message-Id: From: JP Vasseur To: roll ROLL Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 17:28:59 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 16:28:59.0966 (UTC) FILETIME=[EB5E3DE0:01CA58B4] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16976.004 X-TM-AS-Result: No-0.886400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Please change "subject Line" in long threads. Thanks. JP. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 16:28:46 -0000 From jvasseur@cisco.com Thu Oct 29 10:05:33 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A423A69EA for ; Thu, 29 Oct 2009 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.748 X-Spam-Level: X-Spam-Status: No, score=-9.748 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-lAYDZmG4IV for ; Thu, 29 Oct 2009 10:05:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1D6433A69C9 for ; Thu, 29 Oct 2009 10:05:31 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMAAJNo6UqQ/uCWe2dsb2JhbACCIxcYmHYBARYkBqpUmBaEPQQ X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208,217";a="53127416" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 17:05:47 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9TH5l1P004495 for ; Thu, 29 Oct 2009 17:05:47 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 18:05:47 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 18:05:46 +0100 Message-Id: From: JP Vasseur To: roll ROLL Content-Type: multipart/alternative; boundary=Apple-Mail-73--644128211 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 18:05:45 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 17:05:46.0742 (UTC) FILETIME=[0EB58960:01CA58BA] Subject: [Roll] Question for the WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 17:05:33 -0000 --Apple-Mail-73--644128211 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit (chair hat off) We'd like to get your input on the following issue. Referring the following text: We had that text is -03: "RPL is designed to survive and still operate, though in a somewhat degraded fashion, when confronted to such heterogeneity. The key design point is that each node is solely responsible for setting the vector of metrics that it sources in the DAG, derived in part from the metrics sourced from its preferred parent. As a result, the DAG is not broken if another node makes its decisions in as antagonistic fashion, though an end-to-end path might not fully achieve any of the optimizations that nodes along the way expect. The default operation specified in OCP 0 clarifies this point." We changed the text but still some confusion remains so let's try to clarify. Question 1: should we rely on default OCP/Metric ? Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP Option 2: the OCP/metric must always be explicitly mentioned in the DIO. Question 2: OCP/metric not understood/supported. Consider the following DAG: A / \ B C X X is a new node receiving DIO messages from B and C. The question is "What should X do when receiving a DIO specifying an OF and metric that it does not understand ?" 1) Option 1 X logs the problem and does not join the DAG at all. 2) Option 2 X logs the problem, joins the DAG selecting either B or C as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that X should not start advertising DIO with inconsistent metric (that could confuse many other nodes behind). 3) Option 3 X joins and tries to advertise "some" metrics trying to provide connectivity for more other nodes. I personally favor 2). Opinions ? Thanks. JP. --Apple-Mail-73--644128211 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable (chair hat = off)

We'd like to get your input on the following = issue. Referring the following text:

We had = that text is -03:

   = "RPL is designed = to survive and still operate, though in a = somewhat
   degraded =
fashion, when confronted to such heterogeneity.  The key
   design point is that each node is solely responsible for setting the
   vector of metrics that it sources in the DAG, derived in part from
   the metrics sourced from its preferred parent.  As a result, the DAG
   is not broken if another node makes its decisions in as antagonistic
   fashion, though an end-to-end path might not fully achieve any of the
   optimizations that nodes along the way expect.  The default operation
   specified in OCP 0 clarifies this =
point."

We changed the text = but still some confusion remains so let's try to = clarify.

Question 1: should we rely on = default OCP/Metric ?

Option 1: if the = OCP/metric is not advertised, the node should use the "default" = OCP
Option 2: the OCP/metric must always be explicitly = mentioned in the DIO.

Question 2: OCP/metric = not understood/supported.

Consider the = following DAG:

     = A
   /   \
 B   =  C

   =  X

X is a new node receiving DIO messages = from B and C.

The question is "What should X do = when receiving a DIO specifying an OF and metric that it does not = understand ?"

1) Option 1
X logs the = problem and does not join the DAG at = all. 

2) Option 2
X logs the = problem, joins the DAG selecting either B or C as a "leaf" (randomly = since it does not understand the metric or the OF). The idea of joining = as a leaf is that X should not start advertising DIO with inconsistent = metric (that could confuse many other nodes = behind).

3) Option 3 
X joins = and tries to advertise "some" metrics trying to provide connectivity for = more other nodes.

I personally favor = 2).

Opinions = ?

Thanks.

JP.
= --Apple-Mail-73--644128211-- From sung.lee@us.fujitsu.com Thu Oct 29 10:14:23 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DEC3A6918 for ; Thu, 29 Oct 2009 10:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8+PLleCu6gv for ; Thu, 29 Oct 2009 10:14:21 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (fujitsu8.fnanic.fujitsu.com [192.240.0.8]) by core3.amsl.com (Postfix) with ESMTP id 6D91D3A6882 for ; Thu, 29 Oct 2009 10:14:21 -0700 (PDT) Received: from fujitsu8.fnanic.fujitsu.com (localhost [127.0.0.1]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9THFa0s011509 for ; Thu, 29 Oct 2009 10:15:36 -0700 (PDT) Received: from fujitsuii.fna.fujitsu.com ([133.164.253.2]) by fujitsu8.fnanic.fujitsu.com (8.13.7/8.13.7) with ESMTP id n9THFZYd011469 for ; Thu, 29 Oct 2009 10:15:35 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsuii.fna.fujitsu.com (8.13.8/8.13.8) with ESMTP id n9THEYLE018013 for ; Thu, 29 Oct 2009 10:14:34 -0700 (PDT) Received: from [10.157.253.54] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6+Sun/8.11.6) with ESMTP id n9THEX825223 for ; Thu, 29 Oct 2009 10:14:33 -0700 (PDT) Message-ID: <4AE9CD78.8070405@us.fujitsu.com> Date: Thu, 29 Oct 2009 13:14:32 -0400 From: Sung Lee User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: roll@ietf.org References: <4AE9BE1A.6080506@us.fujitsu.com> In-Reply-To: <4AE9BE1A.6080506@us.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 17:14:23 -0000 Tim and WG members again, > 5.11.5. DAO Inconsistency Loop Detection and Recovery > > A DAO inconsistency happens when router that has an outwards DAO > route via a child that is a remnant from an obsolete state that is > not matched in the child. With DAO inconsistency loop recovery, a > packet can be used to recursively explore and cleanup the obsolete > DAO states along a sub-DAG. Based on our experience, the state of the network is constantly changing. We previously attempted to correct and maintain the accurate state upon loop discovery. However, we found that overall performance is better if we reflect the knowledge of loop existence (we do so into the weight we use to determine which route to take) and attempts to delivery the packet via different route. We are for attempting to recursively deliver the packet via different route, but we do have concerns about cleaning up the obsolete state. I am willing to share the details of what we do in regard to loop detection/correction. However, as I was working through that I realized that I may need some in depth discussion with editors of this spec, if WG is interested in what we can bring to the group. Would you please let me know how we can proceed? Thank you, Sung Sung Lee wrote: > Tim and WG members, > > I was reviewing v04 and have some concerns about current proposal. > In particular, the restriction on 2 sibling hops in a row. > >> 5.11.4. Sibling Loop Avoidance >> >> When a packet is forwarded along siblings, it cannot be checked for >> forward progress and may loop between siblings. Experimental >> evidence has shown that one sibling hop can be very useful but is >> generally sufficient to avoid loops. Based on that evidence, this >> specification enforces the simple rule that a packet may not make 2 >> sibling hops in a row. > > I recall that the experiment result was presented at the interim meeting. > However, it was also pointed out that if the selected sibling is not > the right one, then you risk a packet loss. > If the network topology is simple enough, this may be sufficient > restriction to avoid sibling loops. > Without much coordinated effort of trying to figure out the "right" > next hop sibling, this simple restriction will cause many packet drops > if the network topology is complicated. > > My understanding is that ROLL is targeting for a large scale network. > And I have concerns about this. > I would like to hear about what others think about this. > > Regards, > Sung > >> >> Message: 3 >> Date: Tue, 27 Oct 2009 09:31:21 -0400 >> From: Tim Winter >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >> Cc: roll@ietf.org >> Message-ID: <4AE6F629.7070707@acm.org> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> WG, >> >> In this revision we did incorporate much of the recent feedback from the >> list, including >> - Remove recommendations for DAG splitting/merging >> (detach/float/reattach) >> - Remove Held-Up state and related procedures >> - Remove Held-Down state and related procedures >> - Clarified that a DAG Instance is in support of a single >> application >> objective / optimization, and that RPL specifies operation in a >> single DAG >> Instance >> - ICMPv6 message type proposed to carry DIO/DAO message + DIO/DAO >> revised >> (OCP now comes from Metric Container) >> - Updated DIO suboptions to be consistent with metrics draft (16 >> bit length) >> - Added use of flow label to specify DAG Instance and allow for >> loop detection >> - Misc. editorial changes >> >> We are still working to provide an FSM presentation of RPL. >> >> >> Regards >> >> -RPL Authors >> >> Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Routing Over Low power and Lossy >>> networks Working Group of the IETF. >>> >>> >>> Title : RPL: IPv6 Routing Protocol for Low power and >>> Lossy Networks >>> Author(s) : T. Winter, et al. >>> Filename : draft-ietf-roll-rpl-04.txt >>> Pages : 82 >>> Date : 2009-10-26 >>> >>> Low power and Lossy Networks (LLNs) are a class of network in which >>> both the routers and their interconnect are constrained: LLN routers >>> typically operate with constraints on (any subset of) processing >>> >> >> >>> power, memory and energy (battery), and their interconnects are >>> characterized by (any subset of) high loss rates, low data rates and >>> instability. LLNs are comprised of anything from a few dozen and up >>> to thousands of LLN routers, and support point-to- point traffic >>> (between devices inside the LLN), point-to-multipoint traffic (from a >>> central control point to a subset of devices inside the LLN) and >>> multipoint-to- point traffic (from devices inside the LLN towards a >>> central control point). This document specifies the IPv6 Routing >>> Protocol for LLNs (RPL), which provides a mechanism whereby >>> multipoint-to-point traffic from devices inside the LLN towards a >>> central control point, as well as point-to-multipoint traffic from >>> the central control point to the devices inside the LLN, is >>> supported. Support for point-to-point traffic is also available. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 27 Oct 2009 12:57:46 -0400 >> From: Sung Lee >> Subject: Re: [Roll] RPL Metric ID >> To: roll@ietf.org >> Message-ID: <4AE7268A.5060209@us.fujitsu.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Philip, >> >> Sorry for my late response. I have been quite swamped with work and >> travels. >> I read your paper and I liked it. I like your concept of using >> information from all three layers. >> Although our approach is not as "formalized" as yours, I think >> fundamentally we do share some similarity. >> I would say that one difference is that we try to reflect the existence >> of loop in the estimation. Since we do actively check for loop >> existence, we reflect that into the estimation value by penalizing it. >> But please note that we do not actively try to remove the loop when we >> find it. Our experience is that by reflecting the existence of loops in >> the estimation/metric, it sorts itself out over time. >> >> Thanks for sharing your paper. >> Best regards, >> Sung >> >> roll-request@ietf.org wrote: >> >>> Message: 2 >>> Date: Thu, 15 Oct 2009 09:05:23 -0700 >>> From: Philip Levis >>> Subject: Re: [Roll] RPL Metric ID >>> To: Sung Lee >>> Cc: roll@ietf.org >>> Message-ID: >>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes >>> >>> >>> On Oct 15, 2009, at 7:20 AM, Sung Lee wrote: >>> >>> >>> >>>> JP and WG members, >>>> >>>> This may be considered link reliability. >>>> But in our experience, we found the following information very helpful >>>> in improving the stability of network and also (and you could say) in >>>> avoiding loops as well. >>>> >>>> We use what we call 'W' (weight). >>>> When we forward data packet, we require per-hop ACK. >>>> When we receive ACK, we adjust the new W to be old W -1 (W_new = >>>> W_old - 1). >>>> When we don't receive ACK, we adjust the new W to be old W + 1 >>>> (W_old = >>>> W_old +1). >>>> When we detect a loop, we adjust the W value to MAX. >>>> >>>> We have experimented MAX value based on real system, MAX value of 10 >>>> seems to be a good value to start with. >>>> >>>> Now this can be combined with other metric values you are all >>>> discussing. We have experimented quite a lot with combing several >>>> metrics with the above weight in determining the path, which so far >>>> seems to work in our system. >>>> For instance, the other metric values you are discussing (such as link >>>> quality, RSSI, and/or everything else - please note this can be as >>>> simple as hop count, RSSI, or whatever the WG determines) can be used >>>> with along with W value to determine. >>>> >>>> I am interested in what the WG thinks of using this 'W' as part of >>>> metric for RPL. >>>> >>>> >>> Sung, >>> >>> I think the general approach of directly measuring the datapath is a >>> great way to have fast and accurate link estimation. CTP's 4-bit link >>> estimator (4B) has some similarities to what you describe, although it >>> smoothes estimates much more: I'd be concerned about excessive >>> instability in the above algorithm, as note that you can't measure a >>> link you're not using. >>> >>> Have you read the 4-bit paper? You can find it at >>> http://sing.stanford.edu/singpubs.html >>> >>> Phil >>> >>> >>> >>> >>> >>> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 27 Oct 2009 14:00:55 -0400 >> From: Michael Richardson >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >> To: roll@ietf.org >> Message-ID: <6526.1256666455@marajade.sandelman.ca> >> >> >> >>>>>>> "Tim" == Tim Winter writes: >>>>>>> >> Tim> - Added use of flow label to specify DAG Instance and allow >> for loop detection >> >> Thanks, I think this will help people link things together. >> >> -- >> ] He who is tired of Weird Al is tired of life! | >> firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net >> architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ >> |device driver[ >> Kyoto Plus: watch the video >> >> then sign the petition. >> >> >> ------------------------------ >> >> Message: 6 >> Date: Tue, 27 Oct 2009 19:22:33 +0100 >> From: Alexandru Petrescu >> Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt >> To: Michael Richardson >> Cc: roll@ietf.org >> Message-ID: <4AE73A69.4080406@gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Michael Richardson a ?crit : >> >>>>>>>> "Tim" == Tim Winter writes: >>>>>>>> >>> Tim> - Added use of flow label to specify DAG Instance and allow >>> for loop detection >>> >>> Thanks, I think this will help people link things together. >>> >> >> I think calling it a "flow label" may collide with the flow label field >> of IPv6 base header. >> >> Let me tell you why I say so. I recently went through an implementaiton >> exercise where Route Lifetime and Router Lifetime were mistaken one for >> the other, because they're close enough. >> >> Just a remark. >> >> Alex >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> >> >> End of Roll Digest, Vol 21, Issue 82 >> ************************************ >> > > From jvasseur@cisco.com Thu Oct 29 10:28:37 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555A828C116 for ; Thu, 29 Oct 2009 10:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.74 X-Spam-Level: X-Spam-Status: No, score=-9.74 tagged_above=-999 required=5 tests=[AWL=0.859, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jPo2GsUqBBM for ; Thu, 29 Oct 2009 10:28:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E475F28C0F9 for ; Thu, 29 Oct 2009 10:28:35 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAAENt6UqQ/uCWe2dsb2JhbACbSAEBFiQGqwKYF4Q9BA X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="53129671" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 29 Oct 2009 17:28:51 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9THSpiP011173 for ; Thu, 29 Oct 2009 17:28:51 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 18:28:50 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 18:28:50 +0100 Message-Id: From: JP Vasseur To: roll ROLL Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 18:28:49 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 17:28:50.0294 (UTC) FILETIME=[475ED160:01CA58BD] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.600.1016-16976.004 X-TM-AS-Result: No-0.915900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Proposed Agenda has been posted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 17:28:37 -0000 http://www.ietf.org/proceedings/09nov/agenda/roll.txt From jvasseur@cisco.com Thu Oct 29 10:35:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1972B3A6784 for ; Thu, 29 Oct 2009 10:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.758 X-Spam-Level: X-Spam-Status: No, score=-7.758 tagged_above=-999 required=5 tests=[AWL=-1.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq721PHDVaUK for ; Thu, 29 Oct 2009 10:35:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 5D36B3A67B5 for ; Thu, 29 Oct 2009 10:35:51 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJtv6UqrR7Hu/2dsb2JhbADHHJgVhD0E X-IronPort-AV: E=Sophos;i="4.44,647,1249257600"; d="scan'208";a="263474999" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 29 Oct 2009 17:36:01 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9THZbcO002632 for ; Thu, 29 Oct 2009 17:36:00 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 18:35:30 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 18:35:29 +0100 Message-Id: <727A7539-C45A-480C-8860-084AB5C7848D@cisco.com> From: JP Vasseur To: roll ROLL Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Oct 2009 18:35:29 +0100 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 29 Oct 2009 17:35:30.0042 (UTC) FILETIME=[35A385A0:01CA58BE] Subject: [Roll] Slides for IETF-76 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 17:35:52 -0000 If you have a slot in IETF-76, could you please send you slides by Nov 11, noon ET ? Thanks. JP. From emmanuel.baccelli@gmail.com Thu Oct 29 11:29:12 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDA33A697C for ; Thu, 29 Oct 2009 11:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNz9ZmCva+KE for ; Thu, 29 Oct 2009 11:29:10 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id A0B923A6842 for ; Thu, 29 Oct 2009 11:29:10 -0700 (PDT) Received: by ywh13 with SMTP id 13so2204987ywh.29 for ; Thu, 29 Oct 2009 11:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=mR/Dzf2N8n7Nng/fjPmTS9RWkPPd3JtQG7pl2IERJIw=; b=egQYvNuww1XFUxsQlDzRzX6cARAwrobOsdeHacr5puwXIxaX1s1Eou4sSa2x5eaDk+ G0ax7kj3ztEwfy7xdp6EIs5DJ4atcqMhHBw0R0aAOqL2MKLyWQZlLpCeKmVpb6uLdTA5 fpYcYtWVjLf1jyQFSiPvE4eVJORabWdUQ76sE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=bTAQ3kQk3euntiu8uVt2MVZg9S2RCVWcRNn2bHo0JPV9lFImRUUSi/gGGJvVgdCS9t Jus1lP87peu0TNAnv3Wgi3vuP6zto3uHAq157IY5Zj4jVZxGGTnEZxKG+jjrqU2TZPJK JJBwPKuz+yAVA/LknopSIWJFpiUphwbEmoiqs= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.90.61.3 with SMTP id j3mr1305589aga.40.1256840963303; Thu, 29 Oct 2009 11:29:23 -0700 (PDT) In-Reply-To: <20091026224501.E98D33A682F@core3.amsl.com> References: <20091026224501.E98D33A682F@core3.amsl.com> From: Emmanuel Baccelli Date: Thu, 29 Oct 2009 19:29:03 +0100 X-Google-Sender-Auth: 9c13cec5c1f480df Message-ID: To: roll@ietf.org Content-Type: multipart/alternative; boundary=001636283980282b090477171712 Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 29 Oct 2009 18:29:12 -0000 --001636283980282b090477171712 Content-Type: text/plain; charset=ISO-8859-1 Dear Rollers, here is some feedback about draft-ietf-roll-rpl-04. Overall I think we are moving along the right direction compared to -03, but we are still somewhat far from the spec I think we should aim for, if we plan on keeping our tight standardization schedule. I insist on the fact that we should first concentrate on the "overview" section (currently Section 3) and on an explicit Applicability section. We should agree once and for all what these sections should outline, and then re-populate the rest of the document accordingly (reusing most of the corresponding existing text if possible). This is a sure way of getting somewhere if we want to converge quickly to a solid and consise document. So, focusing on an applicability section and on section 3 (overview of the protocol), I have hacked the tentative "to-the-bone" text below, during a recent jabber chat with Thomas Clausen. Essentially it aims at clarifying some key points, including the following: - this protocol is about communications from sensors to a sink, - the core set of requirements is explicit in the applicability section, - multiple instances of the protocol are not discussed in the document (the applicability section just states it is out of scope), - siblings are not considered, only parents. I think that we need to boil down to such simpler, very explicit goals if we want a clear spec soon. I note that draft-ietf-roll-rpl-04 is still in the 100 pages ball-park. I think we should aim at a spec that is less than half this size, more focused, along the above-mentionned lines. The idea is that additional considerations and companion documents should off-spring from a simple, rock-solid base. So here it is. Again, keep in mind that this is tentative text, hacked up in a hurry, so there is indeed room for improvement -- but maybe not enough room for 100 pages in my book ;) Applicability This protocol is build to support a subset of the requirements from for routing in low-power sensor networks with lossy links. This subset corresponds to a core set of functionalities that enable up to a few thousand fixed sensors to send data to a single, well known data sink. This protocol provides store-and-forward functionalities at the IP level, in order to enable such communications. The protocol is designed to work even when some, or all sensors are very limited in terms of memory (in the order of a kByte), in terms of radio link capacity (in the order of a kB/s), as well as in terms of CPU and battery capacity. Multiple instances of this protocol may be used in order to provide paths to multiple sinks. For example different traffic classes may require different paths to be calculated towards the sink, e.g. to accommodate low-latency requirements or prioritize urgent signaling. Similarly, there may be multiple nodes in the network, each of which having a distinct application significance, and for each of which a LLN router may have to calculate paths. However, the specification of the interaction between multiple instance of the protocol is out of the scope of this document. Protocol Overview As the traffic flows originate from sensors and are directed towards the sink node, each LLN router must find paths towards that sink node. The union of all these paths form a directed acyclic graph (DAG), rooted in that the sink node. This protocol supports the discovery and maintenance of such a DAG, identified uniquely by a given DAG ID, rooted at a single sink node in the network, while respecting some given environmental constraints, i.e. paths calculated according to a specific well-known path metric. The DAG can thus be seen as a collection of paths of similar kind towards similar destination. The DAG is boot-strapped by the self-aware sink, which signals its presence via an extension of IPv6 RA signalling. Such signalling spreads hop by hop, among direct neighbors: each router joining the DAG chooses a collection of parents which are closer to the root, and starts signalling the DAG in its own RAs. This signalling contains the necessary local information about the DAG, including the metric used to compute paths, the DAG ID, and the distance of the emiting router to the root of the DAG. Regards, Emmanuel On Mon, Oct 26, 2009 at 11:45 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy networks > Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy > Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-04.txt > Pages : 82 > Date : 2009-10-26 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained: LLN routers > typically operate with constraints on (any subset of) processing > power, memory and energy (battery), and their interconnects are > characterized by (any subset of) high loss rates, low data rates and > instability. LLNs are comprised of anything from a few dozen and up > to thousands of LLN routers, and support point-to- point traffic > (between devices inside the LLN), point-to-multipoint traffic (from a > central control point to a subset of devices inside the LLN) and > multipoint-to- point traffic (from devices inside the LLN towards a > central control point). This document specifies the IPv6 Routing > Protocol for LLNs (RPL), which provides a mechanism whereby > multipoint-to-point traffic from devices inside the LLN towards a > central control point, as well as point-to-multipoint traffic from > the central control point to the devices inside the LLN, is > supported. Support for point-to-point traffic is also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --001636283980282b090477171712 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Rollers,

here is some feedback about=A0draft-ietf-r= oll-rpl-04. Overall I think we are moving along the right direction compare= d to -03, but we are still somewhat far from the spec I think we should aim= for,=A0if=A0we=A0plan=A0on=A0keeping=A0our=A0tight standardization=A0sched= ule.

I insist=A0on=A0the=A0fact=A0that we=A0should first con= centrate=A0on=A0the=A0"overview" section (currently Section 3) an= d on an explicit Applicability section.=A0We=A0should=A0agree=A0once=A0and= =A0for=A0all=A0what=A0these sections should=A0outline,=A0and=A0then=A0re-po= pulate=A0the rest of the document accordingly (reusing most of the correspo= nding existing text if possible). This is a sure way of getting somewhere i= f we want to converge quickly to a solid and consise document.

So, focusing on an applicability section and on section= 3 (overview of the protocol), I have hacked the tentative "to-the-bon= e" text below, during a recent jabber chat with Thomas Clausen. Essent= ially it aims at clarifying some key points, including the following:

- this protocol is about communications from sensors to= a sink,
- the core set of requirements is explicit in the applic= ability section,
- multiple instances of the protocol are not dis= cussed in the document (the applicability section just states it is out of = scope),
- siblings are not considered, only parents.

= I think that we need to boil down to such simpler, very explicit goals if w= e want a clear spec soon. I note that=A0draft-ietf-roll-rpl-04 is still in = the 100 pages ball-park. I think we should aim at a spec that is less than = half this size, more focused, along the above-mentionned lines. The idea is= that additional considerations and companion documents should off-spring f= rom a simple, rock-solid base.=A0

So here it is. Again, keep in mind that this is tentati= ve text, hacked up in a hurry, so there is indeed room for improvement -- b= ut maybe not enough room for 100 pages in my book ;)



Applicability

<= div>This protocol is build to support a subset of the requirements from <= ;reqd. doc's> for routing in low-power sensor networks with lossy li= nks. This subset corresponds to a core set of functionalities that enable u= p to a few thousand fixed sensors to send data to a single, well known data= sink. This protocol provides store-and-forward functionalities at the IP l= evel, in order to enable such communications. The protocol is designed to w= ork even when some, or all sensors are very limited in terms of memory (in = the order of a kByte), in terms of radio link capacity (in the order of a k= B/s), as well as in terms of CPU and battery capacity.

Multiple instances of this protocol may be used in orde= r to provide paths to multiple sinks. For example different traffic classes= may require different paths to be calculated towards the sink, e.g. to acc= ommodate low-latency requirements or prioritize urgent signaling. =A0Simila= rly, there may be =A0multiple nodes in the network, each of which having a = distinct application significance, and for each of which a LLN router may h= ave to calculate paths.

However, the specification of the interaction between m= ultiple instance of the protocol is out of the scope of this document.=A0


Protocol Overview

As the traffic flows originate from sensors and are directed towards t= he sink node, each LLN router must find paths towards that sink node. The u= nion of all these paths form a directed acyclic graph (DAG), rooted in that= the sink node.

This protocol supports the discovery and maintenance of= such a=A0DAG, identified uniquely by a given DAG ID, rooted at a single si= nk node in the network, while respecting some given environmental constrain= ts, i.e. paths calculated according to a specific well-known path metric. T= he DAG can thus be seen as a collection of paths of similar kind towards si= milar destination.

The DAG is boot-strapped by the self-aware sink, which = signals its presence via an extension of IPv6 RA signalling. Such signallin= g spreads=A0hop by hop,=A0among direct neighbors: each router joining the D= AG chooses a collection of parents which are closer to the root, and starts= signalling the DAG in its own RAs. This signalling contains the necessary = local information about the DAG, including the metric used to compute paths= , the DAG ID, and the distance of the emiting router to the root of the DAG= .




Rega= rds,
Emmanuel



<= div>


On Mon, Oct 26, 2009 = at 11:45 PM, <Internet-Drafts@ietf.org> wrote:
A New Internet-Draft is available from the o= n-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks = Working Group of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : RPL: IPv6 Routing Protocol for = Low power and Lossy Networks
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Winter, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-roll-rpl-04.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 82
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-10-26

Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained: LLN routers
typically operate with constraints on (any subset of) processing
power, memory and energy (battery), and their interconnects are
characterized by (any subset of) high loss rates, low data rates and
instability. =A0LLNs are comprised of anything from a few dozen and up
to thousands of LLN routers, and support point-to- point traffic
(between devices inside the LLN), point-to-multipoint traffic (from a
central control point to a subset of devices inside the LLN) and
multipoint-to- point traffic (from devices inside the LLN towards a
central control point). =A0This document specifies the IPv6 Routing
Protocol for LLNs (RPL), which provides a mechanism whereby
multipoint-to-point traffic from devices inside the LLN towards a
central control point, as well as point-to-multipoint traffic from
the central control point to the devices inside the LLN, is
supported. =A0Support for point-to-point traffic is also available.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-0= 4.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll


--001636283980282b090477171712-- From mdurvy@cisco.com Fri Oct 30 00:53:04 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC153A6973 for ; Fri, 30 Oct 2009 00:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=-2.218, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BD+Mw+Y37+X for ; Fri, 30 Oct 2009 00:53:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D115A3A689B for ; Fri, 30 Oct 2009 00:53:02 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFAHY46kqrR7Hu/2dsb2JhbACCKCohxQWYHwKEOwQ X-IronPort-AV: E=Sophos;i="4.44,651,1249257600"; d="gif'147?scan'147,208,217,147";a="420988041" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 30 Oct 2009 07:53:19 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n9U7rIVn012523 for ; Fri, 30 Oct 2009 07:53:19 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 08:53:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5936.0B13AF89" Date: Fri, 30 Oct 2009 08:53:17 +0100 Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE98F71B@XMB-AMS-103.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D865CB0@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Need Clarification: DA Parents Thread-Index: AcpX1EVAnB+F3kQLTrC+LqkbS2iGTwA0qXiwACNvSbA= References: <8A977BDC5A7B0E429B0F521E8D6F91EE930251@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D865CB0@XMB-AMS-107.cisco.com> From: "Mathilde Durvy (mdurvy)" To: "Pascal Thubert (pthubert)" , "roll" X-OriginalArrivalTime: 30 Oct 2009 07:53:18.0480 (UTC) FILETIME=[0B37E900:01CA5936] Subject: Re: [Roll] Need Clarification: DA Parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 07:53:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5936.0B13AF89 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5936.0B13AF89" ------_=_NextPart_002_01CA5936.0B13AF89 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal,=20 =20 >From your answer I think we are pretty much aligned. Just one clarification... " The node only accepts unicast destination advertisements from any = nodes but those contained in the DA parent subset." --> should a node accept DAO from nodes the are not in its sub-dag? =20 Pascal -> The receiver does not know that the source is in its subDAG, = that but from the fact that it gets DAOs from it. Being in the subDAG is = a decision from that source. =20 =20 [Mathilde] What I meant is that a node should anyway only receive = unicast DAO from it's child. No? =20 Best, Mathilde =20 =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 ------_=_NextPart_002_01CA5936.0B13AF89 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pascal,
 
From your answer I think we are pretty much=20 aligned.
Just one = clarification...

"  The node = only=20 accepts unicast   destination advertisements = from any=20 nodes but those contained in the   DA parent=20 subset."

--> = should a node=20 accept DAO from nodes the are not in its sub-dag?

 

Pascal=20 -> The receiver does not know that the source is in its subDAG, that = but from=20 the fact that it gets DAOs from it. Being in the subDAG is a decision = from that=20 source.  

 
[Mathilde] What I=20 meant is that a node should anyway only receive unicast DAO = from it's=20 child. No?
&= nbsp;
Best,
Mathilde
 
 

 Durvy=20 Mathilde
Software=20 Engineer
Technology=20 center

mdurvy@cisco.com
Phone:=20 +41 21 822=20 1725
Mobile: +41 76 396=20 8116

Cisco=20 Systems International S=E0rl
Av.=20 des Uttins, 5
CH-1180 Rolle

Cisco home=20 page

 

 

Think before = you=20 print.

This=20 e-mail may contain confidential and privileged material for = the sole=20 use of the intended recipient. Any review, use, distribution = or=20 disclosure by others is strictly prohibited. If you are not = the=20 intended recipient (or authorized to receive for the = recipient),=20 please contact the sender by reply e-mail and delete all = copies of=20 this=20 message.


 

------_=_NextPart_002_01CA5936.0B13AF89-- ------_=_NextPart_001_01CA5936.0B13AF89 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <052234307@30102009-18F1> Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA5936.0B13AF89 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: <052234307@30102009-18F8> Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA5936.0B13AF89-- From jabeille@cisco.com Fri Oct 30 01:00:10 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1E43A6A46 for ; Fri, 30 Oct 2009 01:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.95 X-Spam-Level: X-Spam-Status: No, score=-9.95 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31DYUUaiofoV for ; Fri, 30 Oct 2009 01:00:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 591AD3A67B1 for ; Fri, 30 Oct 2009 01:00:08 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0AAGE66kqQ/uCWe2dsb2JhbACCJBYYmH4BARYkBqwBmCCEPQSBYg X-IronPort-AV: E=Sophos;i="4.44,651,1249257600"; d="scan'208,217";a="53171669" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2009 08:00:24 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9U80NUx001914 for ; Fri, 30 Oct 2009 08:00:24 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 09:00:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5937.08B22E22" Date: Fri, 30 Oct 2009 09:00:23 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Question for the WG Thread-Index: AcpYuhdk7bsi1A9aSzq1sysinSBdRgAfAbAg References: From: "Julien Abeille (jabeille)" To: "JP Vasseur (jvasseur)" , "roll ROLL" X-OriginalArrivalTime: 30 Oct 2009 08:00:23.0284 (UTC) FILETIME=[086BDB40:01CA5937] Subject: Re: [Roll] Question for the WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 08:00:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5937.08B22E22 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi JP, ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur (jvasseur) Sent: jeudi 29 octobre 2009 18:06 To: roll ROLL Subject: [Roll] Question for the WG =09 =09 (chair hat off)=20 =09 =09 We'd like to get your input on the following issue. Referring the following text: =09 =09 We had that text is -03: =09 =09 "RPL is designed to survive and still operate, though in a somewhat degraded fashion, when confronted to such heterogeneity. The key design point is that each node is solely responsible for setting the vector of metrics that it sources in the DAG, derived in part from the metrics sourced from its preferred parent. As a result, the DAG is not broken if another node makes its decisions in as antagonistic fashion, though an end-to-end path might not fully achieve any of the optimizations that nodes along the way expect. The default operation specified in OCP 0 clarifies this point." =09 =09 We changed the text but still some confusion remains so let's try to clarify. =09 =09 Question 1: should we rely on default OCP/Metric ? =09 =09 Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP Option 2: the OCP/metric must always be explicitly mentioned in the DIO. =09 [Julien] I am in favor of 2. It's a matter of configuring the root properly, which is not that muc an effort I feel. Most people will want to deploy using a specific metric, hence OCP0 means: - the network admin failed to configure the network properly - this is extra code on the sensors, that will be rarely used =09 Question 2: OCP/metric not understood/supported. =09 =09 Consider the following DAG: =09 =09 A / \ B C =09 =09 X =09 =09 X is a new node receiving DIO messages from B and C. =09 =09 The question is "What should X do when receiving a DIO specifying an OF and metric that it does not understand ?" =09 =09 1) Option 1 X logs the problem and does not join the DAG at all.=20 =09 =09 2) Option 2 X logs the problem, joins the DAG selecting either B or C as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that X should not start advertising DIO with inconsistent metric (that could confuse many other nodes behind). =09 =09 3) Option 3=20 X joins and tries to advertise "some" metrics trying to provide connectivity for more other nodes. =09 =09 I personally favor 2).=20 [Julien] question about 2: I guess the parent chosen by X will not be able to advertise anything specific to X (X does not send DAOs), except if X configures an address on a prefix routed to B/C. Hence would a good way to provide what you propose simply that X and his parent do an RS/RA exchange, RA with a prefix information option, autoconf flag set, on link flag probably not set, and router lifetime !=3D 0. This = would ensure X has a default route and X has an address forged on a prefix that his parent is advertising in DAOs up the DAG (in other terms X address is routable). If this works I am for 2. =09 =09 Opinions ? Thanks. JP. ------_=_NextPart_001_01CA5937.08B22E22 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi JP,

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur=20 (jvasseur)
Sent: jeudi 29 octobre 2009 18:06
To: = roll=20 ROLL
Subject: [Roll] Question for the = WG

(chair hat off)

We'd like to get your input on the following issue. Referring the = following text:

We had that text is -03:

  =20 "RPL is designed to survive and still = operate,=20 though in a somewhat
   =
degraded fashion, when confronted to such heterogeneity.  The key
   design point is that each node is solely responsible for setting the
   vector of metrics that it sources in the DAG, derived in part from
   the metrics sourced from its preferred parent.  As a result, the DAG
   is not broken if another node makes its decisions in as antagonistic
   fashion, though an end-to-end path might not fully achieve any of the
   optimizations that nodes along the way expect.  The default operation
   specified in OCP 0 clarifies this point."

We changed the text but still some confusion remains so let's try = to=20 clarify.

Question 1: should we rely on default OCP/Metric ?

Option 1: if the OCP/metric is not advertised, the node should = use the=20 "default" OCP
Option 2: the OCP/metric must always be explicitly mentioned in = the=20 DIO.
[Julien] I am=20 in favor of 2. It's a matter of configuring the root properly, which = is not=20 that muc an effort I feel. Most people will want to deploy using a = specific=20 metric, hence OCP0 means:
-  the network admin = failed to=20 configure the network properly
- this is extra code on the sensors, that = will be=20 rarely used
Question 2: OCP/metric not understood/supported.

Consider the following DAG:

     A
   /   \
 B    C

    X

X is a new node receiving DIO messages from B and C.

The question is "What should X do when receiving a DIO specifying = an OF=20 and metric that it does not understand ?"

1) Option 1
X logs the problem and does not join the DAG at all. 

2) Option 2
X logs the problem, joins the DAG selecting either B or C as a = "leaf"=20 (randomly since it does not understand the metric or the OF). The idea = of=20 joining as a leaf is that X should not start advertising DIO with = inconsistent=20 metric (that could confuse many other nodes behind).

3) Option 3 
X joins and tries to advertise "some" metrics trying to provide=20 connectivity for more other nodes.

I personally favor 2). 
[Julien] question about 2: I guess the parent = chosen by X=20 will not be able to advertise anything specific to X (X does not send = DAOs),=20 except if X configures an address on a prefix routed to B/C. Hence = would a=20 good way to provide what you propose simply that X and his parent do = an RS/RA=20 exchange, RA with a prefix information option, autoconf flag set, on = link flag=20 probably not set, and router lifetime !=3D 0. This would ensure X has = a default=20 route and X has an address forged on a prefix that his parent is=20 advertising in DAOs up the DAG (in other terms X address is routable). = If this=20 works I am for 2.

Opinions ?

Thanks.

JP.
------_=_NextPart_001_01CA5937.08B22E22-- From jabeille@cisco.com Fri Oct 30 06:18:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022843A699D for ; Fri, 30 Oct 2009 06:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.977 X-Spam-Level: X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZP8+-Vuzu9J for ; Fri, 30 Oct 2009 06:18:21 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D06DB3A67A1 for ; Fri, 30 Oct 2009 06:18:20 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMAACqE6kqQ/uCWe2dsb2JhbACCJyyZAQEBFiQGrX6YHYQ9BA X-IronPort-AV: E=Sophos;i="4.44,653,1249257600"; d="scan'208,217";a="53207089" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2009 13:18:36 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UDIaDJ024402 for ; Fri, 30 Oct 2009 13:18:36 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:18:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5963.7CD0B540" Date: Fri, 30 Oct 2009 14:18:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: terminology Thread-Index: AcpZY3yVfLp9zsh9RRKtSxggnTPTdQ== From: "Julien Abeille (jabeille)" To: "roll ROLL" X-OriginalArrivalTime: 30 Oct 2009 13:18:36.0656 (UTC) FILETIME=[7CF53700:01CA5963] Subject: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 13:18:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5963.7CD0B540 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I am getting headackes with up the tree, to a lower rank, inward vs down the tree, to a higher rank, outwards. Could the text only use up and down (direction), higher node, lower node (nodes/parents), and mention rank only when needed. =20 Best, Julien =20 ------_=_NextPart_001_01CA5963.7CD0B540 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I am = getting=20 headackes with up the tree, to a lower rank, inward vs down the tree, to = a=20 higher rank, outwards.
Could = the text only=20 use up and down (direction), higher node, lower node = (nodes/parents),=20  and mention rank only when needed.
 
Best,
Julien  
------_=_NextPart_001_01CA5963.7CD0B540-- From jabeille@cisco.com Fri Oct 30 06:33:52 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 590E428C0E2 for ; Fri, 30 Oct 2009 06:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.002 X-Spam-Level: X-Spam-Status: No, score=-10.002 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15gu+MRlkuGm for ; Fri, 30 Oct 2009 06:33:51 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B59793A6817 for ; Fri, 30 Oct 2009 06:33:50 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMAALSH6kqQ/uCWe2dsb2JhbACCJyyZAQEBFiQGrgKYHIQ9BA X-IronPort-AV: E=Sophos;i="4.44,653,1249257600"; d="scan'208,217";a="53208783" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 30 Oct 2009 13:34:06 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UDY6Cv029137 for ; Fri, 30 Oct 2009 13:34:06 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 14:34:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5965.A6FFAEFA" Date: Fri, 30 Oct 2009 14:34:05 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: need clarification: 5.4.1.6.1 Thread-Index: AcpZZabJSN+IL2M+SWuY+15E7Pl5+g== From: "Julien Abeille (jabeille)" To: "roll ROLL" X-OriginalArrivalTime: 30 Oct 2009 13:34:06.0412 (UTC) FILETIME=[A722B8C0:01CA5965] Subject: [Roll] need clarification: 5.4.1.6.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 13:33:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5965.A6FFAEFA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 not sure I understand point 5.4.1.6.1: if a node has no more parents, how does it poison routes up the tree. I thought this would be by sending a DAO, but if the node has no more parents, how does it perform this? Should it read outwards? =20 Thank you, Julien ------_=_NextPart_001_01CA5965.A6FFAEFA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
not = sure I=20 understand point 5.4.1.6.1: if a node has no more parents, how = does it=20 poison routes up the tree. I thought this would be by sending a DAO, but = if the node has no more parents, how does it perform = this? Should=20 it read outwards?
 
Thank=20 you,
Julien
------_=_NextPart_001_01CA5965.A6FFAEFA-- From jabeille@cisco.com Fri Oct 30 07:06:22 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F19D3A67E9 for ; Fri, 30 Oct 2009 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.025 X-Spam-Level: X-Spam-Status: No, score=-8.025 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njHO2no189bQ for ; Fri, 30 Oct 2009 07:06:21 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BE8543A67B6 for ; Fri, 30 Oct 2009 07:06:21 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAOmP6kqrR7Ht/2dsb2JhbACCJyzHTJgehD0E X-IronPort-AV: E=Sophos;i="4.44,653,1249257600"; d="scan'208,217";a="200282321" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2009 14:06:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9UE6MiU011679 for ; Fri, 30 Oct 2009 14:06:38 GMT Received: from xmb-ams-113.cisco.com ([144.254.74.88]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 15:06:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA596A.30F43D52" Date: Fri, 30 Oct 2009 15:06:35 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: what does a node do when its parent left Thread-Index: AcpZajDHtGTH5X+JRw2XuB5iUNczEw== From: "Julien Abeille (jabeille)" To: "roll ROLL" X-OriginalArrivalTime: 30 Oct 2009 14:06:35.0888 (UTC) FILETIME=[311D2700:01CA596A] Subject: [Roll] what does a node do when its parent left X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 14:06:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA596A.30F43D52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 there is uncalrity about what a node may/must do when its parent has jumped (receiving a DIO from a parent, but DAGID is different than my DAG, instance ID is equal) 5.4.1.7.1 says the node may fllow the parent or not 5.4.2.1 says the node must not (non capital) follow is it still has an alternate parent in the current DAG. =20 so what is preferred there? =20 Best, Julien ------_=_NextPart_001_01CA596A.30F43D52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
there = is uncalrity=20 about what a node may/must do when its parent has jumped (receiving a = DIO from a=20 parent, but DAGID is different than my DAG, instance ID is=20 equal)
5.4.1.7.1 says the=20 node may fllow the parent or not
5.4.2.1 says the=20 node must not (non capital) follow is it still has an alternate parent = in the=20 current DAG.
 
so = what is preferred=20 there?
 
Best,
Julien
------_=_NextPart_001_01CA596A.30F43D52-- From richard.kelsey@ember.com Fri Oct 30 07:30:54 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBB73A67B6 for ; Fri, 30 Oct 2009 07:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfSgVIH2+Leb for ; Fri, 30 Oct 2009 07:30:53 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 431CB3A67E9 for ; Fri, 30 Oct 2009 07:30:53 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 10:32:28 -0400 Date: Fri, 30 Oct 2009 10:28:30 -0400 Message-Id: <87y6mt552p.fsf@kelsey-ws.hq.ember.com> To: JP Vasseur In-reply-to: (message from JP Vasseur on Thu, 29 Oct 2009 18:05:45 +0100) From: Richard Kelsey References: X-OriginalArrivalTime: 30 Oct 2009 14:32:28.0153 (UTC) FILETIME=[CE55FE90:01CA596D] Cc: roll@ietf.org Subject: Re: [Roll] Question for the WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 14:30:54 -0000 From: JP Vasseur Date: Thu, 29 Oct 2009 18:05:45 +0100 We changed the text but still some confusion remains so let's try to clarify. Question 1: should we rely on default OCP/Metric ? Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP Option 2: the OCP/metric must always be explicitly mentioned in the DIO. I prefer option 2. Option 1 is more complicated, as there has to be a way to specify a non-default OCP, and I have no conviction that a majority of DAGs will use the default OCP. If the goal is to have a smaller base DIO, then we should put the OCP in a DIO option to be included in all DIOs sent in response to solicitations (DIS). A joining device can request a DAO in order to get the OCP, but OCPs would not be included in the majority of DIOs. This is about as complex as option 1 and saves bandwidth even when using non-default OCPs. I would still prefer option 2 over this. I am not convinced that the gain in bandwidth would be worth the added complexity of dealing with another option. Question 2: OCP/metric not understood/supported. Consider the following DAG: A / \ B C X X is a new node receiving DIO messages from B and C. The question is "What should X do when receiving a DIO specifying an OF and metric that it does not understand ?" 1) Option 1 X logs the problem and does not join the DAG at all. 2) Option 2 X logs the problem, joins the DAG selecting either B or C as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that X should not start advertising DIO with inconsistent metric (that could confuse many other nodes behind). 3) Option 3 X joins and tries to advertise "some" metrics trying to provide connectivity for more other nodes. I prefer Option 2. Option 3 would make for a lot of interoperation headaches without providing much in return. Option 1 is available whether RPL explicitly supports it or not. We can't force devices to participate in a network. -Richard Kelsey From richard.kelsey@ember.com Fri Oct 30 10:22:16 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1B93A67BD for ; Fri, 30 Oct 2009 10:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvKRUZeaVubz for ; Fri, 30 Oct 2009 10:22:15 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 8AC133A6768 for ; Fri, 30 Oct 2009 10:22:15 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 30 Oct 2009 13:23:50 -0400 Date: Fri, 30 Oct 2009 13:19:54 -0400 Message-Id: <87vdhw6bph.fsf@kelsey-ws.hq.ember.com> To: "Julien Abeille (jabeille)" In-reply-to: (jabeille@cisco.com) From: Richard Kelsey References: X-OriginalArrivalTime: 30 Oct 2009 17:23:50.0638 (UTC) FILETIME=[BF2CB0E0:01CA5985] Cc: roll@ietf.org Subject: Re: [Roll] need clarification: 5.4.1.6.1 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 17:22:16 -0000 Date: Fri, 30 Oct 2009 14:34:05 +0100 From: "Julien Abeille (jabeille)" Hi all, not sure I understand point 5.4.1.6.1: if a node has no more parents, how does it poison routes up the tree. I thought this would be by sending a DAO, but if the node has no more parents, how does it perform this? Should it read outwards? Julien, I think that the text is correct, if a bit confusing. The routes being poisoned are upward routes through the node. This is done by poison flowing downwards in DIOs as described in 5.4.1.6.2. The poisoning informs nodes lower in the DAG that they can no longer route upwards through the source of the poison. -Richard Kelsey From Jerald.P.Martocci@jci.com Fri Oct 30 11:39:45 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FF563A682B; Fri, 30 Oct 2009 11:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7mswDapMRUA; Fri, 30 Oct 2009 11:39:44 -0700 (PDT) Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by core3.amsl.com (Postfix) with ESMTP id EE40F3A6767; Fri, 30 Oct 2009 11:39:43 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKSusy+iTHd+IKDC3xMKc8b0XmiCRn++r2@postini.com; Fri, 30 Oct 2009 11:40:01 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009103013402228-3040091 ; Fri, 30 Oct 2009 13:40:22 -0500 In-Reply-To: <7208549A-51AF-4294-8522-8785A5B0CAFF@cs.stanford.edu> MIME-Version: 1.0 To: Philip Levis X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 30 Oct 2009 13:39:42 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 10/30/2009 01:39:46 PM, Serialize complete at 10/30/2009 01:39:46 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/30/2009 01:40:22 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/30/2009 01:40:37 PM, Serialize complete at 10/30/2009 01:40:37 PM Content-Type: multipart/alternative; boundary="=_alternative 006683608625765F_=" Cc: roll-bounces@ietf.org, roll Subject: Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 18:39:45 -0000 This is a multipart message in MIME format. --=_alternative 006683608625765F_= Content-Type: text/plain; charset="US-ASCII" HiPhil, Leaving Neighbor Cache building and maintenance to the discretion of the implementer seems to open the door toward non-interoperable implementations on multi-vendor systems. How one builds and maintains its neighbor cache seems to me to be a very important primitive operation of a mesh system. If all implementations must all support the full suite of messages and the implementation is just deciding which message it will use to build its cache, that's ok. However, if implementer A picks message X to build its neighbor cache while implementer B picks message Y and elects not to support message X; that would not be a good thing. The point of all this babble is to please keep in mind nonhomogeneous networks composed of many vendors' implementations. Regards, Jerry Philip Levis Sent by: roll-bounces@ietf.org 10/29/2009 09:52 AM To Pascal Thubert (pthubert) cc roll Subject Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and DIOs dependency On Oct 29, 2009, at 7:45 AM, Pascal Thubert (pthubert) wrote: > Hi: > > In fact a stale entry is not sufficient. We need an entry that is > reachable. > > That is the minimum validation process that comes with the fact that > the draft as it stands today depends on NS/NA flows to ensure bidir > connectivity with the neighbor. The way I see it, the node should at > least unicast NS to the candidate to assert that. In the same > fashion as NUD allows the node to remove the parent. But if a > stronger validation mechanism is in place, then that should > supersede the NS/NA. > > Soon enough we might need to elaborate a bit on the validation > process. In some environments, it can be done as part of metrics > computation, like using srcr results for instance. Things like that > cannot be in the base spec but then, do that belong to metrics, a > new draft, or should validation above and beyond NS/NA be left to > implementation? I think it should be left to implementations. Every time we specify something, we increase the complexity of the protocol and limit flexibility in future uses. We should only include something when we know for sure that there's one by-far-better way to do things (unlikely for almost anything in wireless), or when a property is needed for correctness. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006683608625765F_= Content-Type: text/html; charset="US-ASCII"
HiPhil,

Leaving Neighbor Cache building and maintenance to the discretion of the implementer seems to open the door toward non-interoperable implementations on multi-vendor systems.  How one builds and maintains its neighbor cache seems to me to be a very important primitive operation of a mesh system.  

If all implementations must all support the full suite of messages and the implementation is just deciding which message it will use to build its cache, that's ok.  However, if implementer A picks message X to build its neighbor cache while implementer B picks message Y and elects not to support message X; that would not be a good thing.

The point of all this babble is to please keep in mind nonhomogeneous networks composed of many vendors' implementations.

Regards,

Jerry


Philip Levis <pal@cs.stanford.edu>
Sent by: roll-bounces@ietf.org

10/29/2009 09:52 AM

To
Pascal Thubert (pthubert) <pthubert@cisco.com>
cc
roll <roll@ietf.org>
Subject
Re: [Roll] [roll] #7: RPL bootstrap question: neighbor cache and        DIOs dependency






On Oct 29, 2009, at 7:45 AM, Pascal Thubert (pthubert) wrote:

> Hi:
>
> In fact a stale entry is not sufficient. We need an entry that is  
> reachable.
>
> That is the minimum validation process that comes with the fact that  
> the draft as it stands today depends on NS/NA flows to ensure bidir  
> connectivity with the neighbor. The way I see it, the node should at  
> least unicast NS to the candidate to assert that. In the same  
> fashion as NUD allows the node to remove the parent. But if a  
> stronger validation mechanism is in place, then that should  
> supersede the NS/NA.
>
> Soon enough we might need to elaborate a bit on the validation  
> process. In some environments, it can be done as part of metrics  
> computation, like using srcr results for instance. Things like that  
> cannot be in the base spec but then, do that belong to metrics, a  
> new draft, or should validation above and beyond NS/NA be left to  
> implementation?

I think it should be left to implementations. Every time we specify  
something, we increase the complexity of the protocol and limit  
flexibility in future uses. We should only include something when we  
know for sure that there's one by-far-better way to do things  
(unlikely for almost anything in wireless), or when a property is  
needed for correctness.

Phil
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006683608625765F_=-- From Jerald.P.Martocci@jci.com Fri Oct 30 12:57:32 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AF493A6A08; Fri, 30 Oct 2009 12:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpGA5zY7-Sx6; Fri, 30 Oct 2009 12:57:30 -0700 (PDT) Received: from exprod8og113.obsmtp.com (exprod8og113.obsmtp.com [64.18.3.26]) by core3.amsl.com (Postfix) with ESMTP id 408D33A6921; Fri, 30 Oct 2009 12:57:30 -0700 (PDT) Received: from source ([192.132.24.137]) (using SSLv3) by exprod8ob113.postini.com ([64.18.7.12]) with SMTP ID DSNKSutFOg5IIrj9np7KDBZxEZjmtkHPrux/@postini.com; Fri, 30 Oct 2009 12:57:48 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2009103014581884-3048777 ; Fri, 30 Oct 2009 14:58:18 -0500 In-Reply-To: MIME-Version: 1.0 To: JP Vasseur X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 From: Jerald.P.Martocci@jci.com Message-ID: Date: Fri, 30 Oct 2009 14:57:40 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 10/30/2009 02:57:42 PM, Serialize complete at 10/30/2009 02:57:42 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/30/2009 02:58:18 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 10/30/2009 02:58:23 PM, Serialize complete at 10/30/2009 02:58:23 PM Content-Type: multipart/alternative; boundary="=_alternative 006DA6CF8625765F_=" Cc: roll ROLL , roll-bounces@ietf.org Subject: Re: [Roll] Question for the WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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, 30 Oct 2009 19:57:32 -0000 This is a multipart message in MIME format. --=_alternative 006DA6CF8625765F_= Content-Type: text/plain; charset="US-ASCII" JP, I guess I would defer my position on Question 2 below until we decide the converse issue. That is, if a node receives a data packet from another node in the LLN whose OCP it does not support, what should the receiving node do with the packet? If we decide that the packet be dropped, then I would select Question 2/Option 1. (No reason to join the DAG if it can't pass messages on the DAG). If however, we decide the packet should be sent along its merry way toward its destination even on an OCP mismatch, then we might be damaging the DAG's integrity. I think the best approach at the onset is being very explicit. As we gain experience and implementations are tested, we can add additional nuances into the protocol. Hence, my vote for Question 1 is if a node wanting to join the DAG cannot find at least one neighbor supporting its OCP, then it does not join the DAG. As for Question 2, I vote for always explicitly naming the OCP/metric. If we allow a 'default' metric that means that every node must constantly maintain a completely parallel set of parents, preferred parents, DAO states etc for the 'default' OCP even though it may never need to use the default OCP. Jerry JP Vasseur Sent by: roll-bounces@ietf.org 10/29/2009 12:05 PM To roll ROLL cc Subject [Roll] Question for the WG (chair hat off) We'd like to get your input on the following issue. Referring the following text: We had that text is -03: "RPL is designed to survive and still operate, though in a somewhat degraded fashion, when confronted to such heterogeneity. The key design point is that each node is solely responsible for setting the vector of metrics that it sources in the DAG, derived in part from the metrics sourced from its preferred parent. As a result, the DAG is not broken if another node makes its decisions in as antagonistic fashion, though an end-to-end path might not fully achieve any of the optimizations that nodes along the way expect. The default operation specified in OCP 0 clarifies this point." We changed the text but still some confusion remains so let's try to clarify. Question 1: should we rely on default OCP/Metric ? Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP Option 2: the OCP/metric must always be explicitly mentioned in the DIO. Question 2: OCP/metric not understood/supported. Consider the following DAG: A / \ B C X X is a new node receiving DIO messages from B and C. The question is "What should X do when receiving a DIO specifying an OF and metric that it does not understand ?" 1) Option 1 X logs the problem and does not join the DAG at all. 2) Option 2 X logs the problem, joins the DAG selecting either B or C as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that X should not start advertising DIO with inconsistent metric (that could confuse many other nodes behind). 3) Option 3 X joins and tries to advertise "some" metrics trying to provide connectivity for more other nodes. I personally favor 2). Opinions ? Thanks. JP._______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --=_alternative 006DA6CF8625765F_= Content-Type: text/html; charset="US-ASCII"

JP,

I guess I would defer my position on Question 2 below until we decide the converse issue.  That is, if a node receives a data packet from another node in the LLN whose OCP it does not support, what should the receiving node do with the packet?  If we decide that the packet be dropped, then I would select Question 2/Option 1. (No reason to join the DAG if it can't pass messages on the DAG).    If however, we decide the packet should be sent along its merry way toward its destination even on an OCP mismatch, then we might be damaging the DAG's integrity.  

I think the best approach at the onset is being very explicit.  As we gain experience and implementations are tested, we can add additional nuances into the protocol.  Hence, my vote for Question 1 is if a node wanting to join the DAG cannot find at least one neighbor supporting its OCP, then it does not join the DAG.  

As for Question 2, I vote for always explicitly naming the OCP/metric.  If we allow a 'default' metric that means that every node must constantly maintain a completely parallel set of parents, preferred parents, DAO states etc for the 'default' OCP even though it may never need to use the default OCP.

Jerry






JP Vasseur <jvasseur@cisco.com>
Sent by: roll-bounces@ietf.org

10/29/2009 12:05 PM

To
roll ROLL <roll@ietf.org>
cc
Subject
[Roll] Question for the WG





(chair hat off)

We'd like to get your input on the following issue. Referring the following text:

We had that text is -03:

   "RPL is designed to survive and still operate, though in a somewhat
   degraded fashion, when confronted to such heterogeneity.  The key
  design point is that each node is solely responsible for setting the
  vector of metrics that it sources in the DAG, derived in part from
  the metrics sourced from its preferred parent.  As a result, the DAG
  is not broken if another node makes its decisions in as antagonistic
  fashion, though an end-to-end path might not fully achieve any of the
  optimizations that nodes along the way expect.  The default operation
  specified in OCP 0 clarifies this point."

We changed the text but still some confusion remains so let's try to clarify.

Question 1: should we rely on default OCP/Metric ?

Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP
Option 2: the OCP/metric must always be explicitly mentioned in the DIO.

Question 2: OCP/metric not understood/supported.

Consider the following DAG:

     A
   /   \
 B    C

    X

X is a new node receiving DIO messages from B and C.

The question is "What should X do when receiving a DIO specifying an OF and metric that it does not understand ?"

1) Option 1
X logs the problem and does not join the DAG at all.

2) Option 2
X logs the problem, joins the DAG selecting either B or C as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that X should not start advertising DIO with inconsistent metric (that could confuse many other nodes behind).

3) Option 3
X joins and tries to advertise "some" metrics trying to provide connectivity for more other nodes.

I personally favor 2).

Opinions ?

Thanks.

JP._______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--=_alternative 006DA6CF8625765F_=-- From pthubert@cisco.com Sat Oct 31 05:59:09 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4625A3A68A0 for ; Sat, 31 Oct 2009 05:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.602 X-Spam-Level: X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqrVqfzyIbvo for ; Sat, 31 Oct 2009 05:59:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E91283A659B for ; Sat, 31 Oct 2009 05:59:07 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkAADfR60qQ/uCWe2dsb2JhbACCKSqZAAEBFiQGqFGYEYQ6BA X-IronPort-AV: E=Sophos;i="4.44,658,1249257600"; d="scan'208,217";a="53272260" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 12:59:25 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VCxPuW014546 for ; Sat, 31 Oct 2009 12:59:25 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 13:59:25 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5A29.F912C756" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 31 Oct 2009 13:59:25 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8662D5@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] terminology Thread-Index: AcpZY3yVfLp9zsh9RRKtSxggnTPTdQAvnBYQ References: From: "Pascal Thubert (pthubert)" To: "Julien Abeille (jabeille)" , "roll ROLL" X-OriginalArrivalTime: 31 Oct 2009 12:59:25.0525 (UTC) FILETIME=[F93E5050:01CA5A29] Subject: Re: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 31 Oct 2009 12:59:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5A29.F912C756 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would support this. What do others think? =20 Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille (jabeille) Sent: vendredi 30 octobre 2009 14:19 To: roll ROLL Subject: [Roll] terminology =20 Hi all, =20 I am getting headackes with up the tree, to a lower rank, inward vs down the tree, to a higher rank, outwards. Could the text only use up and down (direction), higher node, lower node (nodes/parents), and mention rank only when needed. =20 Best, Julien =20 ------_=_NextPart_001_01CA5A29.F912C756 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would support this. What do others = think?

 

Pascal

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Julien Abeille = (jabeille)
Sent: vendredi 30 octobre 2009 14:19
To: roll ROLL
Subject: [Roll] terminology

 

Hi all,

 

I am getting headackes with up the tree, to a lower rank, inward vs down = the tree, to a higher rank, outwards.

Could the text only use up and down (direction), higher node, lower node (nodes/parents),  and mention rank only when = needed.

 

Best,<= o:p>

Julien &= nbsp;

------_=_NextPart_001_01CA5A29.F912C756-- From pthubert@cisco.com Sat Oct 31 05:59:11 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E063D3A6908 for ; Sat, 31 Oct 2009 05:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id recDYbI5LUjG for ; Sat, 31 Oct 2009 05:59:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id ADBA33A657C for ; Sat, 31 Oct 2009 05:59:06 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.gif, image002.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUAADfR60qQ/uCWe2dsb2JhbACCKCuZAAEBFiQGqFGYEQKEOAQ X-IronPort-AV: E=Sophos;i="4.44,658,1249257600"; d="gif'147?scan'147,208,217,147";a="53272259" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 12:59:23 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VCxNFF014543 for ; Sat, 31 Oct 2009 12:59:23 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 13:59:23 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CA5A29.F7B44BEF" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 31 Oct 2009 13:59:22 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8662D4@XMB-AMS-107.cisco.com> In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE98F71B@XMB-AMS-103.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Need Clarification: DA Parents Thread-Index: AcpX1EVAnB+F3kQLTrC+LqkbS2iGTwA0qXiwACNvSbAAOz+KAA== References: <8A977BDC5A7B0E429B0F521E8D6F91EE930251@XMB-AMS-103.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D865CB0@XMB-AMS-107.cisco.com> <8A977BDC5A7B0E429B0F521E8D6F91EE98F71B@XMB-AMS-103.cisco.com> From: "Pascal Thubert (pthubert)" To: "Mathilde Durvy (mdurvy)" , "roll" X-OriginalArrivalTime: 31 Oct 2009 12:59:23.0292 (UTC) FILETIME=[F7E995C0:01CA5A29] Subject: Re: [Roll] Need Clarification: DA Parents X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 31 Oct 2009 12:59:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5A29.F7B44BEF Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CA5A29.F7B44BEF" ------_=_NextPart_002_01CA5A29.F7B44BEF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You're right, Mathilde.=20 =20 A node only sends DAO to its parents, so a router only receives DAO from = a child of his. You will note that the parent has no way to assert this at this point. =20 Pascal From: Mathilde Durvy (mdurvy)=20 Sent: vendredi 30 octobre 2009 08:53 To: Pascal Thubert (pthubert); 'roll' Subject: RE: [Roll] Need Clarification: DA Parents =20 Hi Pascal,=20 =20 >From your answer I think we are pretty much aligned. Just one clarification... =20 =20 " The node only accepts unicast destination advertisements from any = nodes but those contained in the DA parent subset." --> should a node accept DAO from nodes the are not in its sub-dag? =20 Pascal -> The receiver does not know that the source is in its subDAG, = that but from the fact that it gets DAOs from it. Being in the subDAG is = a decision from that source. =20 =20 [Mathilde] What I meant is that a node should anyway only receive = unicast DAO from it's child. No? =20 Best, Mathilde =20 =20 =20 Durvy Mathilde Software Engineer Technology center mdurvy@cisco.com =20 Phone: +41 21 822 1725 Mobile: +41 76 396 8116 Cisco Systems International S=E0rl Av. des Uttins, 5 CH-1180 Rolle Cisco home page =20 =20 =20 Think before you print. This e-mail may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply e-mail and delete all copies of this message. =20 ------_=_NextPart_002_01CA5A29.F7B44BEF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You’re right, Mathilde.

 

A node only sends DAO to its parents, so a router only = receives DAO from a child of his.

You will note that the parent has no way to assert this = at this point.

 

Pascal

From:= Mathilde = Durvy (mdurvy)
Sent: vendredi 30 octobre 2009 08:53
To: Pascal Thubert (pthubert); 'roll'
Subject: RE: [Roll] Need Clarification: DA = Parents

 

Hi Pascal,

 

From your answer I think we are pretty much = aligned.

Just one clarification...

 

 

"  The node only accepts unicast   destination advertisements from any = nodes but those contained in the   DA parent subset."

--> should a node accept DAO from nodes the are not in its = sub-dag?

 

Pascal -> The receiver does not know that the source = is in its subDAG, that but from the fact that it gets DAOs from it. Being in = the subDAG is a decision from that source.  

=

 

[Mathilde] What I meant is that a node should anyway = only receive unicast DAO from it's child. No?

 

Best,

Mathilde

 

 

Durvy = Mathilde=
Software = Engineer
Technology = center

mdurvy@cisco.com
Phone: +41 = 21 822 1725
Mobile: +41 = 76 396 8116

= Cisco Systems International S=E0rl
Av. des Uttins, 5
CH-1180 Rolle

Cisco home page

 

 

3D"ThinkThink before you = print.

This e-mail may contain = confidential and privileged material for the sole use of the intended recipient. = Any review, use, distribution or disclosure by others is strictly = prohibited. If you are not the intended recipient (or authorized to receive for = the recipient), please contact the sender by reply e-mail and delete all = copies of this message.


 

------_=_NextPart_002_01CA5A29.F7B44BEF-- ------_=_NextPart_001_01CA5A29.F7B44BEF Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CA5A29.F7B44BEF Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CA5A29.F7B44BEF-- From pthubert@cisco.com Sat Oct 31 05:59:20 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4B413A657C; Sat, 31 Oct 2009 05:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.622 X-Spam-Level: X-Spam-Status: No, score=-9.622 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hywft8UqNGrH; Sat, 31 Oct 2009 05:59:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 939443A659B; Sat, 31 Oct 2009 05:59:09 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAADfR60qQ/uCWe2dsb2JhbACCJi2ZAAEBFiQGqFGYEYQ6BIFi X-IronPort-AV: E=Sophos;i="4.44,658,1249257600"; d="scan'208,217";a="53272261" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 31 Oct 2009 12:59:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9VCxR0B014549; Sat, 31 Oct 2009 12:59:27 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Oct 2009 13:59:27 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5A29.FA1DD006" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sat, 31 Oct 2009 13:59:17 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8662D6@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Question for the WG Thread-Index: AcpZm0dSCqKnJshFSECcNpfRUNeU/gAi6V/g References: From: "Pascal Thubert (pthubert)" To: , "JP Vasseur (jvasseur)" X-OriginalArrivalTime: 31 Oct 2009 12:59:27.0308 (UTC) FILETIME=[FA4E60C0:01CA5A29] Cc: roll ROLL , roll-bounces@ietf.org Subject: Re: [Roll] Question for the WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 31 Oct 2009 12:59:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5A29.FA1DD006 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jerry I guess I would defer my position on Question 2 below until we decide the converse issue. That is, if a node receives a data packet from another node in the LLN whose OCP it does not support, what should the receiving node do with the packet? If we decide that the packet be dropped, then I would select Question 2/Option 1. (No reason to join the DAG if it can't pass messages on the DAG). If however, we decide the packet should be sent along its merry way toward its destination even on an OCP mismatch, then we might be damaging the DAG's integrity. =20 You're right. And the current text does not allow a packet to go its merry way because that would cause a loop. It leaves to policy which instances the node belongs to, and whether the instance ID in the packet can be changed. By default that is not done, unless the node participates to instance ID 0 in which case, yes. What's behind this is the need for autonomic behavior. What happens to a device - or a full network of devices - straight out of the box? If some McDo toys start RPLing together, do we need to ask the kids to configure policies and instances to get them to work? So the current text enables such operation using OCP/OF 0. That's basically what you get for hosts and routers that do not know any better, that is have no configuration at all. Whether an administered deployment should use OCP0 at all is an network planning issue. "5.11.2. Instance Forwarding =20 =20 Instance IDs is used to avoid loops between DAGs from different origins. DAGs that constructed for antagonistic constraints might contain paths that, if mixed together, would yield loops. Those loops are avoided by forwarding a packet along the DAG that is associated to a given instance. =20 The InstanceID is placed by the source in the flow label. It is not meaningful if the packet has the flow label set to all zeroes. Otherwise it MUST match the DAG instance onto which the packet is placed by any node, be it a host or router. =20 When a router receives a packet that is flagged with a given instance ID and the node can forward the packet along the DAG associated to that instance, then the router MUST do so and leave the instance ID flag unchanged. =20 If any node can not forward a packet along the DAG associated to the instance ID in the flow label, then the node MAY either change the InstanceID to match a DAG that it is using for this packet or discard the packet. That decision is based on a policy. =20 The default policy is as follows: if the node can forward along the DAG associated to the instance RPL_DEFAULT_INSTANCE then it should do so. Otherwise it should drop the packet. =20 " I think the best approach at the onset is being very explicit. As we gain experience and implementations are tested, we can add additional nuances into the protocol. Hence, my vote for Question 1 is if a node wanting to join the DAG cannot find at least one neighbor supporting its OCP, then it does not join the DAG. =20 =20 The way I understand the question that JP asks is not along this line. I think the question is whether a network that is a patchwork of instances makes any sense. The abstract rank metric enables loop avoidance in such a network, but the Objective is not guaranteed anymore and the metrics are not propagated. For me, since a node should always join along known instances first, the instance DAGs are not changed by that decision. The difference is only whether you can have stubs of OCP 0 hanging off the DAG or nodes left with no connectivity at all. I tend to allow to give connectivity to the poor chaps, but I suppose that in any controlled environment that does not make a difference. As for Question 2, I vote for always explicitly naming the OCP/metric. If we allow a 'default' metric that means that every node must constantly maintain a completely parallel set of parents, preferred parents, DAO states etc for the 'default' OCP even though it may never need to use the default OCP.=20 I think you have reversed the order of the questions J There is no must use instance 0. It is just a default when nothing is configured that can be used or not when things are configured. The question seems to be whether OCP should be in the base DIO as opposed to an option. I do not mind have a strong opinion on that since the current text only means to compress 0. It's just an optimization... Jerry=20 JP Vasseur =20 Sent by: roll-bounces@ietf.org=20 10/29/2009 12:05 PM=20 To roll ROLL =20 cc =09 Subject [Roll] Question for the WG =20 =09 (chair hat off)=20 We'd like to get your input on the following issue. Referring the following text:=20 We had that text is -03:=20 "RPL is designed to survive and still operate, though in a somewhat=20 degraded fashion, when confronted to such heterogeneity. The key design point is that each node is solely responsible for setting the vector of metrics that it sources in the DAG, derived in part from the metrics sourced from its preferred parent. As a result, the DAG is not broken if another node makes its decisions in as antagonistic fashion, though an end-to-end path might not fully achieve any of the optimizations that nodes along the way expect. The default operation specified in OCP 0 clarifies this point."=20 We changed the text but still some confusion remains so let's try to clarify.=20 Question 1: should we rely on default OCP/Metric ?=20 Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP=20 Option 2: the OCP/metric must always be explicitly mentioned in the DIO. Question 2: OCP/metric not understood/supported.=20 Consider the following DAG:=20 A=20 / \=20 B C=20 X=20 X is a new node receiving DIO messages from B and C.=20 The question is "What should X do when receiving a DIO specifying an OF and metric that it does not understand ?"=20 1) Option 1=20 X logs the problem and does not join the DAG at all.=20 2) Option 2=20 X logs the problem, joins the DAG selecting either B or C as a "leaf" (randomly since it does not understand the metric or the OF). The idea of joining as a leaf is that X should not start advertising DIO with inconsistent metric (that could confuse many other nodes behind).=20 3) Option 3=20 X joins and tries to advertise "some" metrics trying to provide connectivity for more other nodes.=20 I personally favor 2).=20 Opinions ?=20 Thanks.=20 JP._______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CA5A29.FA1DD006 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jerry


I = guess I would defer my position on Question 2 below until we decide the converse = issue.  That is, if a node receives a data packet from another node in the = LLN whose OCP it does not support, what should the receiving node do with = the packet?  If we decide that the packet be dropped, then I would = select Question 2/Option 1. (No reason to join the DAG if it can't pass = messages on the DAG).    If however, we decide the packet should be sent = along its merry way toward its destination even on an OCP mismatch, then we = might be damaging the DAG's integrity.  

You’re right. = And the current text does not allow a packet to go its merry way because that = would cause a loop. It leaves to policy which instances the node belongs to, = and whether the instance ID  in the packet can be changed. By default that is = not done, unless the node participates to instance ID 0 in which case, = yes.

What’s behind = this is the need for autonomic behavior. What happens to a device – or a = full network of devices – straight out of the = box?

If some McDo toys = start RPLing together, do we need to ask the kids to configure policies and = instances to get them to work?

So the current text = enables such operation using OCP/OF 0. That’s basically what you get for = hosts and routers that do not know any better, that is have no configuration = at all. Whether an administered deployment should use OCP0 at all is an network planning issue.

 “5.11.2.  Instance Forwarding

 
 
  =
 Instance IDs is used to avoid loops between DAGs from =
different
   origins.  DAGs that =
constructed for antagonistic constraints =
might
   contain paths that, if mixed =
together, would yield loops.  =
Those
   loops are avoided by forwarding =
a packet along the DAG that is
   =
associated to a given =
instance.
 
   =
The InstanceID is placed by the source in the flow label.  It is =
not
   meaningful if the packet has the =
flow label set to all zeroes.
   =
Otherwise it MUST match the DAG instance onto which the packet =
is
   placed by any node, be it a host or =
router.
 
   =
When a router receives a packet that is flagged with a given =
instance
   ID and the node can forward =
the packet along the DAG associated to
   =
that instance, then the router MUST do so and leave the instance =
ID
   flag =
unchanged.
 
   =
If any node can not forward a packet along the DAG associated to =
the
   instance ID in the flow label, =
then the node MAY either change the
   =
InstanceID to match a DAG that it is using for this packet or =
discard
   the packet.  That =
decision is based on a =
policy.
 
   =
The default policy is as follows: if the node can forward along =
the
   DAG associated to the instance =
RPL_DEFAULT_INSTANCE then it should do
   =
so.  Otherwise it should drop the packet.

 

“


I = think the best approach at the onset is being very explicit.  As we gain = experience and implementations are tested, we can add additional nuances into the protocol.  Hence, my vote for Question 1 is if a node wanting to = join the DAG cannot find at least one neighbor supporting its OCP, then it does = not join the DAG.  

 


The way I understand the question that JP asks is not along this line. I = think the question is whether a network that is a patchwork of instances makes any = sense. The abstract rank metric enables loop avoidance in such a network, but = the Objective is not guaranteed anymore and the metrics are not = propagated.

For me, since a node = should always join along known instances first, the instance DAGs are not = changed by that decision. The difference is only whether you can have stubs of OCP = 0 hanging off the DAG or nodes left with no connectivity at all. I tend to = allow to give connectivity to the poor chaps, but I suppose that in any = controlled environment that does not make a difference.


As for = Question 2, I vote for always explicitly naming the OCP/metric.  If we allow = a 'default' metric that means that every node must constantly maintain a completely parallel set of parents, preferred parents, DAO states etc = for the 'default' OCP even though it may never need to use the default = OCP.

I think you have = reversed the order of the questions J There is no must use instance 0. It is just a default = when nothing is configured that can be used or not when things are = configured. The question seems to be whether OCP should be in the base DIO as opposed to = an option. I do not mind have a strong opinion on that since the current = text only means to compress 0. It’s just an = optimization…


Jerry =





JP Vasseur <jvasseur@cisco.com>
Sent = by: roll-bounces@ietf.org

10/29/2009 12:05 PM

To=

roll ROLL <roll@ietf.org>

cc=

Subject=

[Roll] Question for the WG

 




(chair hat off)

We'd like to get your input on the following issue. Referring the = following text:

We had that text is -03:

   "RPL is designed to survive and still operate, though in a = somewhat
   degraded fashion, when confronted to such heterogeneity.  The = key
  design point is that each node is solely responsible for setting = the
  vector of metrics that it sources in the DAG, derived in part = from
  the metrics sourced from its preferred parent.  As a result, = the DAG
  is not broken if another node makes its decisions in as = antagonistic
  fashion, though an end-to-end path might not fully achieve any of = the
  optimizations that nodes along the way expect.  The default operation
  specified in OCP 0 clarifies this point."

We changed the text but still some confusion remains so let's try to = clarify.

Question 1: should we rely on default OCP/Metric ?

Option 1: if the OCP/metric is not advertised, the node should use the "default" OCP
Option 2: the OCP/metric must always be explicitly mentioned in the DIO. =

Question 2: OCP/metric not understood/supported.

Consider the following DAG:

     A
   /   \
 B    C

    X

X is a new node receiving DIO messages from B and C.

The question is "What should X do when receiving a DIO specifying = an OF and metric that it does not understand ?"

1) Option 1
X logs the problem and does not join the DAG at all.

2) Option 2
X logs the problem, joins the DAG selecting either B or C as a = "leaf" (randomly since it does not understand the metric or the OF). The idea = of joining as a leaf is that X should not start advertising DIO with = inconsistent metric (that could confuse many other nodes behind).

3) Option 3
X joins and tries to advertise "some" metrics trying to = provide connectivity for more other nodes.

I personally favor 2).

Opinions ?

Thanks.

JP.______________________________________________= _
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

=
------_=_NextPart_001_01CA5A29.FA1DD006-- From alexandru.petrescu@gmail.com Sat Oct 31 06:24:02 2009 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 377C23A67F0 for ; Sat, 31 Oct 2009 06:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afsmHsJxzLBX for ; Sat, 31 Oct 2009 06:24:01 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 3D9023A657C for ; Sat, 31 Oct 2009 06:23:59 -0700 (PDT) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 120BDD480A6; Sat, 31 Oct 2009 14:24:12 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id E862CD48150; Sat, 31 Oct 2009 14:24:09 +0100 (CET) Message-ID: <4AEC3A79.20501@gmail.com> Date: Sat, 31 Oct 2009 14:24:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D8662D5@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D8662D5@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091030-0, 30/10/2009), Outbound message X-Antivirus-Status: Clean Cc: roll ROLL Subject: Re: [Roll] terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 31 Oct 2009 13:24:02 -0000 Pascal Thubert (pthubert) a écrit : > I would support this. What do others think? Generally speaking I am in favour of short and common terminology. Terminology is very important to understand each other. One could run a program through the draft which counts the number of different terms used and their respective number of occurences. Ideally, one should obtain a short list with many times each term, instead of a long list of terms appearing only once. Alex > > > > Pascal > > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On > Behalf Of *Julien Abeille (jabeille) *Sent:* vendredi 30 octobre 2009 > 14:19 *To:* roll ROLL *Subject:* [Roll] terminology > > > > Hi all, > > > > I am getting headackes with up the tree, to a lower rank, inward vs > down the tree, to a higher rank, outwards. > > Could the text only use up and down (direction), higher node, lower > node (nodes/parents), and mention rank only when needed. > > > > Best, > > Julien > > > ------------------------------------------------------------------------ > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll