From mcr@sandelman.ca Mon Jan 2 08:16:11 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1552911E809D for ; Mon, 2 Jan 2012 08:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdZuWSkFUZiK for ; Mon, 2 Jan 2012 08:16:10 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 49EB111E8098 for ; Mon, 2 Jan 2012 08:16:09 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 9276734456 for ; Mon, 2 Jan 2012 11:14:14 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6DACE98148; Mon, 2 Jan 2012 11:16:06 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 69F109812A for ; Mon, 2 Jan 2012 11:16:06 -0500 (EST) From: Michael Richardson To: IETF ROLL X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 02 Jan 2012 11:16:06 -0500 Message-ID: <24984.1325520966@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 02 Jan 2012 16:16:11 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Some comments on draft-phinney-roll-rpl-industrial-applicability-00. I promised myself during the last IETF that I'd read it, and new year's day was a good to do that. pg4: > A field device that belongs to an instance uses the OF to determine > which DODAG and which Version of that DODAG the device should join. I did not think that the OF would tell us which Version of a DODAG to use. The version simply increments... I guess if the new values from the new version do not satisfy the OF, one could stay with the previously calculated parents, etc. I was very pleased to read section 3.1. Deployment scenarii. In it, 6 scenarios are described: P1: Construction or major modification phase P2: Planned startup phase P3: Normal operation phase P4: Planned shutdown phase P5: Plant decommissioning phase. P6: Post-emergency recovery and repair phase. The analysis that follows concerns me: > The deployment scenarios for wireless LLN devices may be different in > each of these phases. In particular, during the Construction or > major modification phase (P1), LLN devices may be installed months > before the intended LLN can become usefully operational (because > needed routers and infrastructure devices are not yet installed or > active), and there are likely to be many personnel in whom the plant > owner/operator has only limited trust, such as subcontractors and > others in the plant area who have undergone only a cursory background > investigation (if any at all). In general, during this phase, plant I very much wish that this had appeared in RFC5673 as input into the security mechanism. I think that a major limitation in the current documents in the security area here. I could go on awhile about how I think things should work to solve this; I didn't do that before, because I didn't think that there was real requirements for a system a flexible as I envision.=20=20=20 NOTE: this is not a fault of this document, it's a failure of our requirements process for security. draft-phinney-roll-rpl-industrial-applicability-00 recaps too many things, and I find is way too chatty. I expect an applicability statement to be more to the point. This relates to section 3 mostly, I think. The chart in section 3.3: +---------------------+------------------------------------------------+ | Phase \ Class | 0 1 2 3 4 5 | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Construction | X X X X | +---------------------+------------------------------------------------+ | Planned startup | X X X X | +---------------------+------------------------------------------------+ | Normal operation | ? ? ? | +---------------------+------------------------------------------------+ | Planned shutdown | X X X X | +---------------------+------------------------------------------------+ |Plant decommissioning| X X X X | +---------------------+------------------------------------------------+ | Recovery and repair | X X X X X X | +---------------------+------------------------------------------------+ also is of concern. What it says is that RPL can't be used for=20 * Class 0: Emergency action - Always a critical function * Class 1: Closed loop regulatory control - Often a critical function * Class 2: Closed loop supervisory control - Usually non-critical function during any phase, except during repair. And, that we don't even know if it can be used for Normal operation! That's hardly an huge endorsement! Thank you kindly for this -00 document. I realize that section 5 is where the meat will go, and I look forward to some clear recommendations here. =2D-=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 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUATwHYRoqHRg3pndX9AQJCeQQAoP4XVCzyih0O3Vw5v9a33sJQyo14/OtO GF7mCpAJmtmjoNRT87u4kCFzjhpte9Ue5Xwd0XDQk0ZkyAgzSdwosIEkV74wFzds aUqBa8eONCSVQmL1AhvoECh0slv5VsGbyAxkX2D7/T28CenmfnzNQBcKWevFakxH YX5YgIO7UtI= =dQRz -----END PGP SIGNATURE----- --=-=-=-- From iliasr@gmail.com Wed Jan 4 07:30:13 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A592D21F875D for ; Wed, 4 Jan 2012 07:30:13 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECQcdiTuBAZD for ; Wed, 4 Jan 2012 07:30:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2697921F8739 for ; Wed, 4 Jan 2012 07:30:13 -0800 (PST) Received: by obcuz6 with SMTP id uz6so16027894obc.31 for ; Wed, 04 Jan 2012 07:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=QIY9L1XqNZ5L44O0iM+0rGWrdKLHkuk5g1Y9Fz9qZKk=; b=mD6nEg9Dy3Pk5R+Z/c9SwMrRfheOZjwpcXhPmwN+SzPFGX3/ez0VhfZgR8OHQVOSbB pVyjb1krLc5n1pKjkgZJeh9QzJFXcqVbnbLJjcUyO+7fKSyTpZC+pTzT8s+Rt9E19Ol6 /DyxBx3S/wPfiwfs8F1UCeTNAQuhSbyx3E0m4= MIME-Version: 1.0 Received: by 10.182.111.7 with SMTP id ie7mr48643265obb.4.1325691011642; Wed, 04 Jan 2012 07:30:11 -0800 (PST) Received: by 10.182.15.38 with HTTP; Wed, 4 Jan 2012 07:30:11 -0800 (PST) Date: Wed, 4 Jan 2012 16:30:11 +0100 Message-ID: From: Ilias Rinis To: roll@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [Roll] DAG repair when Root is unreachable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Jan 2012 15:30:13 -0000 Hello all, while working with RPL (using the Contiki implementation) I came along an issue which is not clearly defined in the specification, and in my mind it seems to be important in LLNs when failures and the need to repair a DAG occur. When a node becomes unreachable for some reason and the failure is not transient, RPL will initiate a local repair mechanism in order for a new route towards the DAG Root to be found quickly. The node that initiates the local repair will poison its subtree with INF rank DIOs, causing parent re-selection. Since the local repair mechanism is not explicitly specified in the specification, the question that I am facing is, what happens when the parent that becomes unreachable is the very DAG root itself? Is it possible (and how) for the nodes to join another DAG within the same instance (if present)? I was unable to locate a satisfying response to this in the specification. Quoting section 3.7.2 paragraph 2, "For example, consider the local repair mechanism that allows a node to detach from the DODAG, advertise a rank of INFINITE_RANK (in order to poison its routes / inform its sub-DODAG), and then to re-attach to the DODAG". This implicitly allows a repairing/poisoning node to join another present DAG. However, it is not clearly specified how this situation should be handled. Is this a matter left to the implementation, or is it under discussion for the specification? I would be very interested in your input on this. Thank you all for your time! Best regards, Ilias Rinis From pthubert@cisco.com Wed Jan 4 08:53:37 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4161021F8627 for ; Wed, 4 Jan 2012 08:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj5jOhhx3AWe for ; Wed, 4 Jan 2012 08:53:36 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6B91721F84E4 for ; Wed, 4 Jan 2012 08:53:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1334; q=dns/txt; s=iport; t=1325696016; x=1326905616; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=RmvXB5VOm5yrHJFR9SgdGB9NahJ/DijGBufvkgPA22A=; b=N9Kpbd97CqWU+K+Jv3jQlO7eHwjM/rOTVvdsLSaIHoEM035zvkshnzaI 4/6rGfIXlFI5hZvUsRhkcUnjbRwpw4CS9XbenFtYRE8So3bq5O9gPOOAC dltUV812iiKOF8Xg+eYRiBdEvAzmQW56qa7rJyBMLnBSvjDyopiOzPHNu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFiDBE+Q/khR/2dsb2JhbABDggWqZYEFgXIBAQEDARIBHQpECwIBCCIGGAYBVgEBBAEaGodYlzsBniSLLGMEpzk X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; d="scan'208";a="62754086" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 04 Jan 2012 16:53: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.14.3/8.14.3) with ESMTP id q04GrYvR032412; Wed, 4 Jan 2012 16:53:34 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 17:53:34 +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, 4 Jan 2012 17:52:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] DAG repair when Root is unreachable Thread-Index: AczK9cSO6nzi8FQTTzC9yUm/P4eGWwAB1PyA References: From: "Pascal Thubert (pthubert)" To: "Ilias Rinis" , X-OriginalArrivalTime: 04 Jan 2012 16:53:34.0283 (UTC) FILETIME=[655BE9B0:01CCCB01] Subject: Re: [Roll] DAG repair when Root is unreachable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Jan 2012 16:53:37 -0000 Hi Ilias: > When a node becomes unreachable for some reason and the failure is not transient, RPL will initiate a local repair mechanism in order for a new route towards the DAG Root to be found quickly. The node that initiates the local repair will poison its subtree with INF rank DIOs, causing parent re-selection. Since the local repair mechanism is not explicitly specified in the specification, the question that I am facing is, what happens when the parent that becomes unreachable is the very DAG root itself? Is it possible (and how) for the nodes to join another DAG within the same instance (if present)? [Pascal] Yes, the nodes would distribute over alternate DODAGs within the same instance. The term in the spec for that action is jump. At some point the text for jumping was merged into section 8.2.2.4 and the result is visible there in item 4, which is poorly related to the title of the section. I think that the title should be fixed prior to publication so that " within a DODAG Version" either becomes "within an instance" or simply goes away. If the is no more DODAG to attach to the node either poisons and stays there by itself, or becomes a floating root of its own DODAG, in which case communication within that floating DODAG is still possible. I hope that helps : ) Pascal From pal@cs.stanford.edu Wed Jan 4 09:33:07 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5983B21F8739 for ; Wed, 4 Jan 2012 09:33:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1wtLFZzJMao for ; Wed, 4 Jan 2012 09:33:06 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id CD1CE21F862B for ; Wed, 4 Jan 2012 09:33:06 -0800 (PST) Received: from ofdhcp161.sunet ([172.27.75.161]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1RiUi0-0003cT-Cu; Wed, 04 Jan 2012 09:33:04 -0800 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 4 Jan 2012 09:33:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ilias Rinis X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: roll@ietf.org Subject: Re: [Roll] DAG repair when Root is unreachable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 04 Jan 2012 17:33:07 -0000 On Jan 4, 2012, at 7:30 AM, Ilias Rinis wrote: > Hello all, >=20 > while working with RPL (using the Contiki implementation) I came along > an issue which is not clearly defined in the specification, and in my > mind it seems to be important in LLNs when failures and the need to > repair a DAG occur. >=20 > When a node becomes unreachable for some reason and the failure is not > transient, RPL will initiate a local repair mechanism in order for a > new route towards the DAG Root to be found quickly. The node that > initiates the local repair will poison its subtree with INF rank DIOs, > causing parent re-selection. Since the local repair mechanism is not > explicitly specified in the specification, the question that I am > facing is, what happens when the parent that becomes unreachable is > the very DAG root itself? Is it possible (and how) for the nodes to > join another DAG within the same instance (if present)? >=20 > I was unable to locate a satisfying response to this in the > specification. Quoting section 3.7.2 paragraph 2, "For example, > consider the local repair mechanism that allows a node to detach from > the DODAG, advertise a rank of INFINITE_RANK (in order to poison its > routes / inform its sub-DODAG), and then to re-attach to the DODAG". > This implicitly allows a repairing/poisoning node to join another > present DAG. However, it is not clearly specified how this situation > should be handled. >=20 > Is this a matter left to the implementation, or is it under discussion > for the specification? I would be very interested in your input on > this. >=20 > Thank you all for your time! > Best regards, > Ilias Rinis Ilias, The current specification does not state exactly how this should be = done, and it's not under discussion for the current specification. But = if, through experience and use we find there are particular recommended = strategies or algorithms, then I'd see no reason why those couldn't be = specified as guidance to implementers. It seems something better suited = to writing down what emerges as common practice than specifying a new = idea. Phil From iliasr@gmail.com Thu Jan 5 05:20:21 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B784C21F864B for ; Thu, 5 Jan 2012 05:20:21 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHhDRCFB4seJ for ; Thu, 5 Jan 2012 05:20:21 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3CE21F8839 for ; Thu, 5 Jan 2012 05:20:20 -0800 (PST) Received: by obcuz6 with SMTP id uz6so696402obc.31 for ; Thu, 05 Jan 2012 05:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AHNRrmd/VY65ldR1u+8eNMllmxZhxTxIHDlI8IK6vlo=; b=FQLGZ6XpRh2PYbGmVEPQaJnYcNqas5KUS7O/dCZ1k+8Z4uEm+jslJHLJOFMcS9C83C yGm3WB//cySLyXdd8H7AsHGR6FoOfsdWTzVlUWDAKyY6UbU2OyeQQ2fAVKUi+Z2JmeWo +PGOqWG0LXDwVP5QGXOYiXZQNcr6T7Puk1/Nc= MIME-Version: 1.0 Received: by 10.182.193.41 with SMTP id hl9mr1414141obc.44.1325769619525; Thu, 05 Jan 2012 05:20:19 -0800 (PST) Received: by 10.182.15.38 with HTTP; Thu, 5 Jan 2012 05:20:19 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Jan 2012 14:20:19 +0100 Message-ID: From: Ilias Rinis To: Philip Levis Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] DAG repair when Root is unreachable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jan 2012 13:20:21 -0000 Hello again, thank you both for your answers and your interest! @Pascal, I studied the section that you mention, indeed the title is a bit misleading! Thanks for guiding me to it! @Phil, what you say makes perfectly good sense; I feel that it would be interesting at some point to see something relevant in the spec. Thank you again, and best regards, Ilias On Wed, Jan 4, 2012 at 6:33 PM, Philip Levis wrote: > > On Jan 4, 2012, at 7:30 AM, Ilias Rinis wrote: > >> Hello all, >> >> while working with RPL (using the Contiki implementation) I came along >> an issue which is not clearly defined in the specification, and in my >> mind it seems to be important in LLNs when failures and the need to >> repair a DAG occur. >> >> When a node becomes unreachable for some reason and the failure is not >> transient, RPL will initiate a local repair mechanism in order for a >> new route towards the DAG Root to be found quickly. The node that >> initiates the local repair will poison its subtree with INF rank DIOs, >> causing parent re-selection. Since the local repair mechanism is not >> explicitly specified in the specification, the question that I am >> facing is, what happens when the parent that becomes unreachable is >> the very DAG root itself? Is it possible (and how) for the nodes to >> join another DAG within the same instance (if present)? >> >> I was unable to locate a satisfying response to this in the >> specification. Quoting section 3.7.2 paragraph 2, "For example, >> consider the local repair mechanism that allows a node to detach from >> the DODAG, advertise a rank of INFINITE_RANK (in order to poison its >> routes / inform its sub-DODAG), and then to re-attach to the DODAG". >> This implicitly allows a repairing/poisoning node to join another >> present DAG. However, it is not clearly specified how this situation >> should be handled. >> >> Is this a matter left to the implementation, or is it under discussion >> for the specification? I would be very interested in your input on >> this. >> >> Thank you all for your time! >> Best regards, >> Ilias Rinis > > Ilias, > > The current specification does not state exactly how this should be done,= and it's not under discussion for the current specification. But if, throu= gh experience and use we find there are particular recommended strategies o= r algorithms, then I'd see no reason why those couldn't be specified as gui= dance to implementers. It seems something better suited to writing down wha= t emerges as common practice than specifying a new idea. > > Phil > From adrian@olddog.co.uk Fri Jan 6 12:10:34 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626F221F85C7 for ; Fri, 6 Jan 2012 12:10:34 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUII3GBrN7KZ for ; Fri, 6 Jan 2012 12:10:33 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD721F873E for ; Fri, 6 Jan 2012 12:10:06 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q06KA3KZ018567; Fri, 6 Jan 2012 20:10:03 GMT Received: from 950129200 (adsl-89-217-79-52.adslplus.ch [89.217.79.52]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q06KA0LX018543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jan 2012 20:10:01 GMT From: "Adrian Farrel" To: "'Omprakash Gnawali'" References: <09d401cc7d25$ffa16150$fee423f0$@olddog.co.uk> In-Reply-To: Date: Fri, 6 Jan 2012 20:10:00 -0000 Message-ID: <00a201ccccaf$2d51a410$87f4ec30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEt0YKbC1e7kTaVBMPToCrcou+LQQGThtBJAk9Gqb+XHpDP4A== Content-Language: en-gb Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] AD review of draft-ietf-roll-minrank-hysteresis-of-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:10:34 -0000 Hi Omprakash, Was the action with me? I think I fumbled and no-one chased me :-( > Adrian, thanks for the feedback. I have incorporated some of your > comments, but there are some items I wanted to run by you before > posting a new version: >=20 > > In progressing the OG0 draft we learnt that there was no clear > > understanding of what an objective function is. I think your draft = does > > a good job at explaining, but in an attempt to learn from the past, = can > > you please have a look at the text that got added to the OF0 = document to > > see whether anything can be added here. >=20 > I looked through both the drafts and also rpl draft. I could mention > the relevant sections of RPL draft in the first sentence of section 1: >=20 > An objective function specifies how RPL [I-D.ietf-roll-rpl] selects > paths. >=20 > to: >=20 > An objective function describes how RPL [I-D.ietf-roll-rpl] selects > paths within the role defined in Section 3.2.1 and using the > guidelines listed in Section 14 of [I-D.ietf-roll-rpl]. >=20 > Isn't that better than every OF draft describing what an OF is and > what it is supposed to do? I understand where you are coming from. I think that, while section 14 of draft-ietf-roll-rpl is perfectly = clear, our non-RPL reviewers simply did not get the fact that an OF is an outcome = not an algorithm. Thus, when RPL was reviewed, it was read as though an OF was = an algorithm and no problems arose. However, when draft-ietf-roll-of0 was = reviewed there was huge confusion and we added paras 2 and 3 to Section 1 before = the reviewers "got it". What I suggest here is that we take the statement of abstraction from = OF0 and fold it into your I-D. How about... OLD An objective function specifies how RPL [I-D.ietf-roll-rpl] selects paths. Objective functions can choose paths based on routing metrics or constraints. For example, if an RPL instance uses an objective function that minimizes hop-count, RPL will select paths with minimum hop count. NEW An objective function (OF) describes how RPL [I-D.ietf-roll-rpl]=20 selects paths. An OF is not an algorithm, but states the outcome of the process or algorithm used by a RPL node to select and optimize=20 routes within a RPL Instance based on the information objects=20 available (such as routing metrics and constraints). For example, if a RPL instance has an objective function that minimizes hop-count, RPL will select paths with minimum hop-count. The separation of OFs from the core protocol specification allows RPL to be adapted to meet the different optimization criteria required by the wide range of deployments, applications, and network designs. Section 14 of [I-D.ietf-roll-rpl] sets out guidelines for the creation, specification, and implementation of OFs. END > > Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not > > MROFH? >=20 > We can change the name to Minimum Rank Hysteresis Objective Function. wfm > > During the review process for OF0 we ended up adding the following > > paragraph. Would you consider adding something similar to make this > > point crystal clear? > > > > =A0 The RPL specification [I-D.ietf-roll-rpl] requires the use of a > > =A0 common OF by all nodes in a network. =A0The possible use of = multiple > > =A0 OFs with a single network is for further study. >=20 > Do you prefer to repeat this in each OF draft, even though it is > already mentioned in rpl draft? Well, we ended up having to add this short paragraph in order to get OF0 = through IESG review. You can choose to add the paragraph or fight the IESG = later. I always prefer the easy approach. Does it detract from the quality of = your document? > > Section 5.1 > > > > Can you add a statement on default values? >=20 > Here is the current statement on default values: >=20 > The parameter values are assigned depending on the selected metric. > The best values for these parameters should be experimentally > determined. The working group has long experience routing with the > ETX metric. Based on those experiences, these values are > RECOMMENDED: >=20 > If you think it would be better to clarify some aspect of the above > statement or something > additional, I am happy to add those statements. I will put the above = statement > and the table of default values as a separate subsection (5.1) and manageability > will become 5.2. The text you quote is not in section 5.1 and does not mention defaults.=20 How about OLD The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT should be configurable. NEW The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST, =20 PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT SHOULD be configurable. Defaults values SHOULD be applied so that configuration is not required. Defaults for the ETX metric SHOULD use the values shown in the previous section. END > > Can you also have a look at Section 7 of the OF0 draft. This gives > > more substantive approach to describing manageability. >=20 > How about changing: >=20 > The parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST, > PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT > should be configurable. >=20 > to >=20 > Out of the box, the parameters MAX_LINK_METRIC, MAX_PATH_COST, MIN_PATH_COST, > PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT > should be set to the default values. The default value MAY be = different from the ones > described in Section 5.1. These values may be further modified = using guidelines in Section 16 > of [I-D.ietf-roll-rpl]. I think you have really only attempted to address my previous point = here. Wrt manageability I had hoped for more details. You might look at RFC = 5706 for advice (and you could use RFC 6123 as an example). I think this is only a "nice to have", and certainly you don't need to = go down the path of a 10 page section. What I really wanted to understand was = that you had considered the manageability of your work. If so, we can move on. Cheers, Adrian From yi.jiazi@gmail.com Sun Jan 8 09:42:12 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E72521F852F for ; Sun, 8 Jan 2012 09:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeeEo8RcxBzv for ; Sun, 8 Jan 2012 09:42:11 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4142F21F852D for ; Sun, 8 Jan 2012 09:42:11 -0800 (PST) Received: by wgbdr10 with SMTP id dr10so717194wgb.13 for ; Sun, 08 Jan 2012 09:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; bh=RFBIch09Jej02dWnoWkEwl15ExI8+NiYuWFrFG9RlEA=; b=E9NmwVkjGbVgTWdCMceDFambEkdq6d0XfSSk0ONpqgIOxfrDfr+rq/tZkG/ltBE9R5 6pC/dFFGWwBJHkaR2ISJDPNDvMs2Jt4Jcusvny0RRcTrXGrWKu8sebvtZM5PGf2ISaqJ Eqzq8hmXzeXFMlDL0FbvbEOZr5elgW8nIMYSE= Received: by 10.216.134.36 with SMTP id r36mr2982848wei.40.1326044530212; Sun, 08 Jan 2012 09:42:10 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id gf8sm27299220wbb.11.2012.01.08.09.42.07 (version=SSLv3 cipher=OTHER); Sun, 08 Jan 2012 09:42:09 -0800 (PST) Message-ID: <4F09D56F.2060603@gmail.com> Date: Sun, 08 Jan 2012 18:42:07 +0100 From: Jiazi YI User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: roll WG X-Enigmail-Version: 1.3.4 Content-Type: multipart/alternative; boundary="------------060108080209000409040508" Subject: [Roll] Two questions about RPL: "RPL link" and "DAODealy" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Jan 2012 17:42:12 -0000 This is a multi-part message in MIME format. --------------060108080209000409040508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello dear all, When reading the RPL draft, I have two questions: 1. In section 8.2.2.2. DODAG Roots: > In a deployment that uses non-RPL links to federate a number of LLN > roots, it is possible to run RPL over those non-RPL links and use one > router as a "backbone root". What does the "non-RPL link" mean here? And what's "RPL link"? According to the context, it seems to be "low power and lossy link"? I don't see why the *link* should be related to RPL. 2. In section 9.6. Triggering DAO messages > In the case of triggered DAOs, selecting a proper DAODelay can > greatly reduce the number of DAOs transmitted. The trigger flows > Down the DODAG; in the best case the DAOs flow Up the DODAG such that > leaves send DAOs first, with each node sending a DAO message only > once. I don't know how each node only needs to send a DAO once in non-storing mode if the DAO doesn't accumulate the path information? cheers -- Jiazi YI www.jiaziyi.com Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau Cedex France --------------060108080209000409040508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello dear all,

When reading the RPL draft, I have two questions:

1. In section 8.2.2.2. DODAG Roots:

In a deployment that uses non-RPL links to federate a number of LLN
   roots, it is possible to run RPL over those non-RPL links and use one
   router as a "backbone root".

What does the "non-RPL link" mean here? And what's "RPL link"? According to the context, it seems to be "low power and lossy link"? I don't  see why the *link* should be related to RPL.

2. In section 9.6. Triggering DAO messages

  In the case of triggered DAOs, selecting a proper DAODelay can
   greatly reduce the number of DAOs transmitted.  The trigger flows
   Down the DODAG; in the best case the DAOs flow Up the DODAG such that
   leaves send DAOs first, with each node sending a DAO message only
   once.

I don't know how each node only needs to send a DAO once in non-storing mode if the DAO doesn't accumulate the path information?

cheers
-- 
Jiazi YI

www.jiaziyi.com
Hipercom@LIX, Ecole Polytechnique
91128 Palaiseau Cedex France
--------------060108080209000409040508-- From alexandru.petrescu@gmail.com Sun Jan 8 23:44:54 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0087821F8486 for ; Sun, 8 Jan 2012 23:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_18=0.6, MANGLED_BELOW=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+sHMtPHzEEf for ; Sun, 8 Jan 2012 23:44:53 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id EDB2721F8433 for ; Sun, 8 Jan 2012 23:44:52 -0800 (PST) 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.2) with ESMTP id q097ipnV016719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Jan 2012 08:44:51 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q097io3d025112 for ; Mon, 9 Jan 2012 08:44:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id q097imY1027065 for ; Mon, 9 Jan 2012 08:44:50 +0100 Message-ID: <4F0A9AF0.8060304@gmail.com> Date: Mon, 09 Jan 2012 08:44:48 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: roll@ietf.org References: <4F09D56F.2060603@gmail.com> In-Reply-To: <4F09D56F.2060603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Two questions about RPL: "RPL link" and "DAODealy" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Jan 2012 07:44:54 -0000 Le 08/01/2012 18:42, Jiazi YI a écrit : > Hello dear all, > > When reading the RPL draft, I have two questions: > > 1. In section 8.2.2.2. DODAG Roots: > >> In a deployment that uses non-RPL links to federate a number of >> LLN roots, it is possible to run RPL over those non-RPL links and >> use one router as a"backbone root". > > What does the "non-RPL link" mean here? And what's "RPL link"? > According to the context, it seems to be "low power and lossy link"? > I don't see why the *link* should be related to RPL. I agree. Maybe it better said "links on which RPL runs" or so. "RPL link" makes little sense, but for example "802.15.4 link" would make more sense. Alex > 2. In section 9.6. Triggering DAO messages > >> In the case of triggered DAOs, selecting a proper DAODelay can >> greatly reduce the number of DAOs transmitted. The trigger flows >> Down the DODAG; in the best case the DAOs flow Up the DODAG such >> that leaves send DAOs first, with each node sending a DAO message >> only once. > > I don't know how each node only needs to send a DAO once in > non-storing mode if the DAO doesn't accumulate the path information? > > cheers > > -- Jiazi YI > > www.jiaziyi.com Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau > Cedex France > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Jan 9 09:05:09 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EE921F8764 for ; Mon, 9 Jan 2012 09:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.256 X-Spam-Level: X-Spam-Status: No, score=-9.256 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpZO5uYlthn9 for ; Mon, 9 Jan 2012 09:05:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC121F875E for ; Mon, 9 Jan 2012 09:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=16821; q=dns/txt; s=iport; t=1326128696; x=1327338296; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=H1G7xCSd9RQsXiWUg1KmGrZBTFaoAZIaGOERpiiznxs=; b=TmS2TPri+tSjnJilhQNvLRSU9DUQXD3IPajNDp86Nq1CRmrcVxbwf6l8 gVKzEG2x6hHQXkMSJ4Gzr1vGusfsVtQxOYQVFOCpZDibeRjPL9TNX7JaI jD6KtoQ9g+IsO74xqWW4BD8eQjAZTgCXRhiHmrp7qaahA06NJgWuDYBbZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOccC0+Q/khM/2dsb2JhbABEgk6qBIEFgXIBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqfWQGeRYsuYwSnQw X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; d="scan'208,217";a="125880953" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 09 Jan 2012 17:04:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q09H4s8s028054; Mon, 9 Jan 2012 17:04:54 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:04:54 +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_01CCCEF0.CEC55180" Date: Mon, 9 Jan 2012 18:03:46 +0100 Message-ID: In-Reply-To: <4F09D56F.2060603@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Two questions about RPL: "RPL link" and "DAODealy" Thread-Index: AczOLN7hLw0r+6BsR/OyYvy1Yg9HVwAvJ7kQ References: <4F09D56F.2060603@gmail.com> From: "Pascal Thubert (pthubert)" To: "Jiazi YI" , "roll WG" X-OriginalArrivalTime: 09 Jan 2012 17:04:54.0739 (UTC) FILETIME=[CF020230:01CCCEF0] Subject: Re: [Roll] Two questions about RPL: "RPL link" and "DAODealy" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Jan 2012 17:05:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCEF0.CEC55180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jiazi, =20 1) I think this is a typo for non-LLN. This is the case where you have a backbone such as Ethernet that federates multiple roots and the backbone is not a LLN but still is used as the first hop of the RPL network off the root... You'll note that in that case the whole network is a single DAG. You can alternatively make each root own its own DODAG in which case the backbone is not RPL.=20 =20 Either way, you might want to run an additional routing protocol such as OSPF over that backbone so that a packet from a node1 in subdag1 attached via root1 to node2 in subdag2 attached via root2 will go straight from root1 to root2 over the backbone. With RPL only, that packet would go via a global root that is also on that backbone. This illustrates the concept of boulevard that was discussed early in the RPL process. =20 2) Yes, this is storing only, since for all I know it refers to the aggregation that happens in storing mode, where a single DAO message can accumulate multiple targets. In non-storing, the DAO is unicast to the root directly so no such aggregation happens. In storing, the DODAG refresh could be optimized down to 1 DAO per router if, recursively, the children have a lesser delay between the trigger and the DAO emission than their parents do. So that a node gets all the targets for all of its subdag before it sends an accumulation of those plus its own information to a selection of its own parents. We used to have a mechanism in storing mode to recursively update the whole subdag as we do in non-storing (indicating that with a flag) but we abandoned that so the optimization discussed here now may only apply to a DODAGVersionNumber increment. The suggestion has lost most of its value as RPL evolved and we should probably remove it since it's only creating confusion. =20 Thanks for the review! =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jiazi YI Sent: dimanche 8 janvier 2012 18:42 To: roll WG Subject: [Roll] Two questions about RPL: "RPL link" and "DAODealy" =20 Hello dear all, When reading the RPL draft, I have two questions: 1. In section 8.2.2.2. DODAG Roots: In a deployment that uses non-RPL links to federate a number of LLN roots, it is possible to run RPL over those non-RPL links and use one router as a "backbone root".=20 What does the "non-RPL link" mean here? And what's "RPL link"? According to the context, it seems to be "low power and lossy link"? I don't see why the *link* should be related to RPL. 2. In section 9.6. Triggering DAO messages In the case of triggered DAOs, selecting a proper DAODelay can greatly reduce the number of DAOs transmitted. The trigger flows Down the DODAG; in the best case the DAOs flow Up the DODAG such that leaves send DAOs first, with each node sending a DAO message only once.=20 I don't know how each node only needs to send a DAO once in non-storing mode if the DAO doesn't accumulate the path information? cheers --=20 Jiazi YI =20 www.jiaziyi.com Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau Cedex France ------_=_NextPart_001_01CCCEF0.CEC55180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jiazi,

 

1)      = I think this is a typo for non-LLN. This is the case where you have a = backbone such as Ethernet that federates multiple roots and the backbone = is not a LLN but still is used as the first hop of the RPL network off = the root… You’ll note that in that case the whole network is = a single DAG.

You can alternatively make each root own its own DODAG in which case = the backbone is not RPL.

 

Either way, you might want to run an additional routing protocol such = as OSPF over that backbone so that a packet from a node1 in subdag1 = attached via  root1 to node2 in subdag2 attached via root2 will go = straight from root1 to root2 over the backbone. With RPL only, that = packet would go via a global root that is also on that backbone. This = illustrates the concept of boulevard that was discussed early in the RPL = process.

 

2)      = Yes, this is storing only, since for all I know it refers to the = aggregation that happens in storing mode, where a single DAO message can = accumulate multiple targets. In non-storing, the DAO is unicast to the = root directly so no such aggregation happens. In storing, the DODAG = refresh could be optimized down to 1 DAO per router if, recursively, the = children have a lesser delay between the trigger and the DAO emission = than their parents do. So that a node gets all the targets for all of = its subdag before it sends an accumulation of those plus its own = information to a selection of its own parents. We used to have a = mechanism in storing mode to recursively update the whole subdag as we = do in non-storing (indicating that with a flag) but we abandoned that so = the optimization discussed here now may only apply to a = DODAGVersionNumber increment. The suggestion has lost most of its value = as RPL evolved and we should probably remove it since it’s only = creating confusion.

 

Thanks for the review!

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Jiazi YI
Sent: dimanche 8 janvier 2012 = 18:42
To: roll WG
Subject: [Roll] Two questions = about RPL: "RPL link" and = "DAODealy"

 

Hello dear = all,

When reading the RPL draft, I have two questions:

1. = In section 8.2.2.2. DODAG Roots:


In a deployment that uses non-RPL links to =
federate a number of LLN
   roots, it is possible to run RPL =
over those non-RPL links and use one
   router as a "backbone =
root".


What does = the "non-RPL link" mean here? And what's "RPL link"? = According to the context, it seems to be "low power and lossy = link"? I don't  see why the *link* should be related to = RPL.

2. In section 9.6. Triggering DAO = messages


  In the case of triggered DAOs, =
selecting a proper DAODelay can
   greatly reduce the number of =
DAOs transmitted.  The trigger flows
   Down the DODAG; in the best case =
the DAOs flow Up the DODAG such that
   leaves send DAOs first, with =
each node sending a DAO message only
   once.


I don't know how each node only needs to send a = DAO once in non-storing mode if the DAO doesn't accumulate the path = information?

cheers

-- =

Jiazi =
YI
 
www.jiaziyi.com
=
Hipercom@LIX, Ecole Polytechnique
91128 Palaiseau =
Cedex France
------_=_NextPart_001_01CCCEF0.CEC55180-- From yi.jiazi@gmail.com Mon Jan 9 12:32:25 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1620A21F85E3 for ; Mon, 9 Jan 2012 12:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fq8MKvFo7AQ7 for ; Mon, 9 Jan 2012 12:32:23 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF56F21F85DF for ; Mon, 9 Jan 2012 12:32:22 -0800 (PST) Received: by wibhj6 with SMTP id hj6so3728410wib.31 for ; Mon, 09 Jan 2012 12:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=9yQLqLQgBvanbzGbUrcX0lYl8fdV2XTAGFf+k7HcB2Y=; b=OEJcUYb6WcUf9Sydk1dU2UIo8GZ2V+BbOuQWanar55VMxnvAR5i2sjtYnBcgHYijZh ymDwZH2JiA2aiqtgr+FKFhzMbxKHWvM3sGJIMaTa5qgG2KlDwP0bKiWctdIgXDovxw0+ Xlr6quvBG2zUX70lUDKVVDTFnRIrmqrgQEf3E= Received: by 10.181.13.179 with SMTP id ez19mr29982629wid.11.1326141141887; Mon, 09 Jan 2012 12:32:21 -0800 (PST) Received: from jy-mac-pro.home (vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr. [89.87.201.6]) by mx.google.com with ESMTPS id u5sm80603883wbm.2.2012.01.09.12.32.19 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 12:32:20 -0800 (PST) Message-ID: <4F0B4ED2.8080107@gmail.com> Date: Mon, 09 Jan 2012 21:32:18 +0100 From: Jiazi YI User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4F09D56F.2060603@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/alternative; boundary="------------000601070806070401020402" Cc: roll WG Subject: Re: [Roll] Two questions about RPL: "RPL link" and "DAODealy" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 09 Jan 2012 20:32:25 -0000 This is a multi-part message in MIME format. --------------000601070806070401020402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Pascal, Thanks for you detailed answer. 1) It makes much more sense when "non-LLN" is used. 2) There is no problem if it's for storing only. However, in the current draft, it's a little confusing. Hopefully it can be clarified. regards On 1/9/12 6:03 PM, Pascal Thubert (pthubert) wrote: > > Hello Jiazi, > > > > 1) I think this is a typo for non-LLN. This is the case where you > have a backbone such as Ethernet that federates multiple roots and the > backbone is not a LLN but still is used as the first hop of the RPL > network off the root... You'll note that in that case the whole > network is a single DAG. > > You can alternatively make each root own its own DODAG in which case > the backbone is not RPL. > > > > Either way, you might want to run an additional routing protocol such > as OSPF over that backbone so that a packet from a node1 in subdag1 > attached via root1 to node2 in subdag2 attached via root2 will go > straight from root1 to root2 over the backbone. With RPL only, that > packet would go via a global root that is also on that backbone. This > illustrates the concept of boulevard that was discussed early in the > RPL process. > > > > 2) Yes, this is storing only, since for all I know it refers to > the aggregation that happens in storing mode, where a single DAO > message can accumulate multiple targets. In non-storing, the DAO is > unicast to the root directly so no such aggregation happens. In > storing, the DODAG refresh could be optimized down to 1 DAO per router > if, recursively, the children have a lesser delay between the trigger > and the DAO emission than their parents do. So that a node gets all > the targets for all of its subdag before it sends an accumulation of > those plus its own information to a selection of its own parents. We > used to have a mechanism in storing mode to recursively update the > whole subdag as we do in non-storing (indicating that with a flag) but > we abandoned that so the optimization discussed here now may only > apply to a DODAGVersionNumber increment. The suggestion has lost most > of its value as RPL evolved and we should probably remove it since > it's only creating confusion. > > > > Thanks for the review! > > > > Pascal > > > > *From:*roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf > Of *Jiazi YI > *Sent:* dimanche 8 janvier 2012 18:42 > *To:* roll WG > *Subject:* [Roll] Two questions about RPL: "RPL link" and "DAODealy" > > > > Hello dear all, > > When reading the RPL draft, I have two questions: > > 1. In section 8.2.2.2. DODAG Roots: > > > In a deployment that uses non-RPL links to federate a number of LLN > roots, it is possible to run RPL over those non-RPL links and use one > router as a "backbone root". > > > What does the "non-RPL link" mean here? And what's "RPL link"? > According to the context, it seems to be "low power and lossy link"? I > don't see why the *link* should be related to RPL. > > 2. In section 9.6. Triggering DAO messages > > > In the case of triggered DAOs, selecting a proper DAODelay can > greatly reduce the number of DAOs transmitted. The trigger flows > Down the DODAG; in the best case the DAOs flow Up the DODAG such that > leaves send DAOs first, with each node sending a DAO message only > once. > > > I don't know how each node only needs to send a DAO once in > non-storing mode if the DAO doesn't accumulate the path information? > > cheers > > -- > Jiazi YI > > www.jiaziyi.com > Hipercom@LIX, Ecole Polytechnique > 91128 Palaiseau Cedex France -- Jiazi YI www.jiaziyi.com Hipercom@LIX, Ecole Polytechnique 91128 Palaiseau Cedex France --------------000601070806070401020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Pascal,

Thanks for you detailed answer.

1) It makes much more sense when "non-LLN" is used.

2) There is no problem if it's for storing only. However, in the current draft, it's a little confusing. Hopefully it can be clarified.

regards

On 1/9/12 6:03 PM, Pascal Thubert (pthubert) wrote:

Hello Jiazi,

 

1)      I think this is a typo for non-LLN. This is the case where you have a backbone such as Ethernet that federates multiple roots and the backbone is not a LLN but still is used as the first hop of the RPL network off the root… You’ll note that in that case the whole network is a single DAG.

You can alternatively make each root own its own DODAG in which case the backbone is not RPL.

 

Either way, you might want to run an additional routing protocol such as OSPF over that backbone so that a packet from a node1 in subdag1 attached via  root1 to node2 in subdag2 attached via root2 will go straight from root1 to root2 over the backbone. With RPL only, that packet would go via a global root that is also on that backbone. This illustrates the concept of boulevard that was discussed early in the RPL process.

 

2)      Yes, this is storing only, since for all I know it refers to the aggregation that happens in storing mode, where a single DAO message can accumulate multiple targets. In non-storing, the DAO is unicast to the root directly so no such aggregation happens. In storing, the DODAG refresh could be optimized down to 1 DAO per router if, recursively, the children have a lesser delay between the trigger and the DAO emission than their parents do. So that a node gets all the targets for all of its subdag before it sends an accumulation of those plus its own information to a selection of its own parents. We used to have a mechanism in storing mode to recursively update the whole subdag as we do in non-storing (indicating that with a flag) but we abandoned that so the optimization discussed here now may only apply to a DODAGVersionNumber increment. The suggestion has lost most of its value as RPL evolved and we should probably remove it since it’s only creating confusion.

 

Thanks for the review!

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jiazi YI
Sent: dimanche 8 janvier 2012 18:42
To: roll WG
Subject: [Roll] Two questions about RPL: "RPL link" and "DAODealy"

 

Hello dear all,

When reading the RPL draft, I have two questions:

1. In section 8.2.2.2. DODAG Roots:


In a deployment that uses non-RPL links to federate a number of LLN
   roots, it is possible to run RPL over those non-RPL links and use one
   router as a "backbone root".


What does the "non-RPL link" mean here? And what's "RPL link"? According to the context, it seems to be "low power and lossy link"? I don't  see why the *link* should be related to RPL.

2. In section 9.6. Triggering DAO messages


  In the case of triggered DAOs, selecting a proper DAODelay can
   greatly reduce the number of DAOs transmitted.  The trigger flows
   Down the DODAG; in the best case the DAOs flow Up the DODAG such that
   leaves send DAOs first, with each node sending a DAO message only
   once.


I don't know how each node only needs to send a DAO once in non-storing mode if the DAO doesn't accumulate the path information?

cheers

-- 
Jiazi YI
 
www.jiaziyi.com
Hipercom@LIX, Ecole Polytechnique
91128 Palaiseau Cedex France

-- 
Jiazi YI

www.jiaziyi.com
Hipercom@LIX, Ecole Polytechnique
91128 Palaiseau Cedex France
--------------000601070806070401020402-- From leitian.hust@gmail.com Thu Jan 5 10:42:40 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2962421F85B0 for ; Thu, 5 Jan 2012 10:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pebeKLngrC1Y for ; Thu, 5 Jan 2012 10:42:40 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D483921F8594 for ; Thu, 5 Jan 2012 10:42:39 -0800 (PST) Received: by yhjj72 with SMTP id j72so314266yhj.31 for ; Thu, 05 Jan 2012 10:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=mm0kwut6qsrO8Ix45Eh96Kym50Vt7s32JW8+gPCbMxM=; b=lvRu8ngYFSVuzIRNN2eqEKMnpnwTA6MC01ZVQB1f0B4dbbpSmStA1T8lcdKSnkd542 cBiu007W+9Xw7JXfsMSdarzXIR8ezfVIa1cF5ogJ7vgAIrgCm5xk/x3q7U81sam04sD9 Z9OiMJNK/BJx9f7ZJLCOuqp+4Bn2pRGEC10E8= Received: by 10.236.46.232 with SMTP id r68mr3395475yhb.80.1325788959538; Thu, 05 Jan 2012 10:42:39 -0800 (PST) Received: from [192.168.1.7] (CPE-76-84-57-190.neb.res.rr.com. [76.84.57.190]) by mx.google.com with ESMTPS id v35sm24185922yhj.14.2012.01.05.10.42.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 10:42:36 -0800 (PST) From: Lei Tian Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 12:42:35 -0600 Message-Id: <673F7C9D-3D32-4413-B337-7165E6C1E32B@GMAIL.COM> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 10 Jan 2012 08:05:17 -0800 Subject: [Roll] 2nd CFP: 7th IEEE International Conference on Networking, Architecture, and Storage (NAS 2012) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jan 2012 18:42:40 -0000 [We apologize if you receive multiple copies of this CFP.] ---------------------------------------------------------------------- IEEE NAS 2012=20 Dates: June 28-30 Xiamen, Fujian, China CALL FOR PAPERS ******************************************************************** The 7th IEEE International Conference on Networking, Architecture, and = Storage (NAS 2012) http://www.nas-conference.org/ ********************************************************************* OVERVIEW -------------------------------------------------------------- The 7th IEEE International Conference on Networking, Architecture, and = Storage (NAS 2012) will be held from June 28 =E2=88=92 30, 2012 at = Xiamen, Fujian, China. It will serve as an international forum to bring = together researchers and practitioners from academia and industry to = discuss cutting-edge research on networking, high-performance computer = architecture, and parallel and distributed data storage technologies. = NAS 2012 will expose participants to the most recent developments in the = interdisciplinary areas. NAS has been successfully held in Dalian in 2011(NAS'11), Macau in = 2010(NAS'10), Zhang Jia Jie in 2009 (NAS'09), Chongqing in 2008 = (NAS'08), Guilin in 2007 (NAS'07), and Shenyang in 2006 (NAS'06). IMPORTANT DATES -------------------------------------------------------------- Submission Deadline: February 24th, 2012 Notification of acceptance: April 15th, 2012 Camera-ready Paper: May 5th, 2012 Conference: June 28-30, 2012 TOPICS -------------------------------------------------------------- The topics of interest include, but are not limited to: * Network security and privacy * Virtual and overlay networks * Network applications and services * Ad hoc and sensor networks * Networks and protocols * Network architectures * Processor architectures * Cache and memory systems * Parallel and multi-core systems * Impact of (emerging) technologies on architectures * Network information theory & network coding * Power and energy efficient architectures and techniques * Storage management * Storage performance and scalability * File systems, object-based storage, and block storage * Energy-aware storage * Architecture and applications of solid state disks * Performance evaluation * Network Storage * Innovative HW/SW tradeoffs We are pleased to invite you to submit papers to NAS 2012. All=20 submissions will be peer reviewed by our scientific committee and the accepted papers will be included in Ei. Also we would like to announce that a number of experts and leading researchers in the field of Networking, Architecture, and Storage will be delivering=20 keynote lectures. CONFERENCE ORGANIZORS -------------------------------------------------------------- Steering Committee -------------------------------- Xubin He, Virginia Commonwealth University, USA Hong Jiang, University of Nebraska - Lincoln, USA Changsheng Xie, Huazhong University of Science and Technology, China Qing Yang, University of Rhode Island, USA Andr=C3=A9 Brinkmann, Johannes Gutenberg-Universit=C3=A4t Mainz, Germany Honorable General Chairs -------------------------------- Ying Zhang, Xiamen University, China General Co-Chairs -------------------------------- Zhiyong Xu, Suffolk University, USA Lin Wang, Xiamen University, China Program Co-Chairs -------------------------------- Carlos Maltzahn, University of California Santa Cruz, USA Xiao Qin, Auburn University, USA Vice Program Chairs [Networking] -------------------------------- Lisong Xu, University of Nebraska-Lincoln, USA Murat Yuksel, University of Nevada, Reno, USA Vice Program Chairs [Architecture] -------------------------------- Guangyu Sun, Peking University, China Yiran Chen, University of Pittsburgh Vice Program Chairs [Storage] -------------------------------- Jun Wang, University of Central Florida, USA John Bent, EMC, USA Publicity Co-Chairs -------------------------------- Lei Tian, University of Nebraska-Lincoln, USA Hanzi Wang, Xiamen University, China Local Arrangement Co-Chairs -------------------------------- Cuihua Li, Xiamen University, China Da Lu, Xiamen University, China Publication Co-Chairs -------------------------------- Jizhong Han, Chinese Academy of Sciences, China Registration and Finance Co-Chairs -------------------------------- Yunqi Lei, Xiamen University, China Suzhen Wu, Xiamen University, China For more information regarding NAS 2012, please refer to the link below: http://www.nas-conference.org/NAS-2012/index.html From Alireza.Sahami@vis.uni-stuttgart.de Wed Dec 14 07:43:50 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B0321F86A5; Wed, 14 Dec 2011 07:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjyY6-1+sC0Y; Wed, 14 Dec 2011 07:43:49 -0800 (PST) Received: from Bagatelle.visus.uni-stuttgart.de (bagatelle.informatik.uni-stuttgart.de [129.69.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 12E8C21F84DB; Wed, 14 Dec 2011 07:43:45 -0800 (PST) Received: from BAGATELLE.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7]) by Bagatelle.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7%19]) with mapi id 14.01.0355.002; Wed, 14 Dec 2011 16:43:39 +0100 From: Alireza Sahami To: Alireza Sahami Thread-Topic: INSS 2012 - Deadline is approaching December 24th Thread-Index: AQHMunclexKnh+QL1EiJ15kf7uicPg== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.69.180.21] Content-Type: multipart/alternative; boundary="_000_CB0E82B824807alirezasahamivisunistuttgartde_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 Jan 2012 08:05:17 -0800 Subject: [Roll] INSS 2012 - Deadline is approaching December 24th X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 14 Dec 2011 15:43:50 -0000 X-Original-Date: Wed, 14 Dec 2011 15:43:38 +0000 X-List-Received-Date: Wed, 14 Dec 2011 15:43:50 -0000 --_000_CB0E82B824807alirezasahamivisunistuttgartde_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D (Please accept our apologies if you receive multiple copies of this CFP.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Call for Papers The Ninth International Conference of Networked Sensing Systems (INSS 2012) Antwerp, Belgium, June 11-14, 2012 Submission Deadline: December 24, 2011 http://www.inss-conf.org/2012 Scope and Theme: --------------- During the past years, the International Conference on Networked Sensing Sy= stems (INSS) has established itself as a scientific event where academic an= d industrial experts from the areas of next generation sensor systems, sens= or network applications, and measurement and control engineering come toget= her. The INSS provides a forum to hear about the latest developments in the= se areas, to exchange ideas, and to start up collaborations within these fi= elds and between industry and academia. INSS 2012 is the ninth annual conference in the series, and features a high= ly selective technical program. We invite outstanding research papers from = the field of sensor technology, wireless networking, or applications of net= worked sensor systems. The conference especially encourages submissions tha= t investigate research issues shared between all the three areas. INSS 2012 invites the submission of regular, short, and industry papers. Al= l submissions will be peer-reviewed and evaluated on the basis of originali= ty, significance of contribution, technical correctness, and presentation. = Papers submitted must not be under simultaneous review for any other confer= ence, journal, workshop, or other publication. All accepted papers will be = published at IEEE Xplore digital library. Authors are required to attend th= e conference to present their work. Regular/Short Paper Track ------------------------- Regular papers must be 4-8 pages long (two-column format) and include an ab= stract of 100-150 words. Short papers must be 2-4 pages long (two-column fo= rmat) and include an abstract of 100-150 words. All papers should be format= ted according to the IEEE transactions format. Short papers are suitable fo= r interactive discussions. Presentation time of accepted regular and short = papers is decided on acceptance notification. Topics of regular/short paper= track include but are not limited to: o Theoretical Study on Networked Sensing Systems o Applications of Networked Sensing Systems o Prototypes, Field Studies & Test beds for Networked Sensing Systems o Safety and Security of Networked Sensing Systems o Data Management for Networked Sensing Systems o Middleware for Networked Sensing Systems o Self-Organizing Networked Sensing Systems and Autonomic/Bio-Inspired Syst= ems o Intelligent Sensing Systems o Sensor Phenomena and Modeling o Sensors and Sensing Systems o Sensors and Actuators for Smart Meter and Smart Grid Applications o Human Behavior Sensing and Ambient Support o Human Health Monitoring and Biomedical Measurement o Measurement and Control Issues in Networked Sensing Systems o Networked Sensing Systems involving Haptic Interactions o Materials, Design, Fabrication, and Packaging of Sensors Industry Paper Track -------------------- INSS also offers an industry track. In this track, new and interesting deve= lopments in networks for industrial applications can be recognized, whether= in the area of sensor systems, wireless networks, industrial network appli= cations, networks for safety related systems and applications, different se= curity aspects in networks fault tolerant and redundant networks and many o= thers. This session focuses on innovative, new and interesting network appl= ications and research results for industries or developments which will be = important in the near future. The industry track intends to provide discuss= ion for practitioners, developers, and researchers in order to examine prac= tical issues.?Industry papers are suitable for industry researchers to pres= ent not only technical, but also practical issues surrounding production, d= eployment, and commercialisation of networked sensing technology. Industry = papers must be 2-4 pages long (two-column format) and include an abstract o= f 100-150 words. Papers should be formatted according to the IEEE transacti= ons format. The submitted industry papers will be reviewed by industry trac= k TPC members and accepted papers will be presented in the main conference'= s industry track session. The industry track aims at providing a forum amon= g practitioners, developers, and researchers to discuss practical issues in= cluding but not limited to: o Designing networked sensing systems for commercial applications o Service models and architectures for successful deployments o Production engineering for networked sensing systems o Deployment and evaluation of networked sensing systems in practical appli= cations Paper submission ---------------- Submissions should be in PDF format and will be handled through EDAS. http://edas.info/N11501 Important Dates (both regular/short and industry tracks) -------------------------------------------------------- Paper Submissions Due: December 24th, 2011 Notification of Acceptance: March 15th, 2012 Camera-Ready Papers: April 15th, 2012 Conference Dates: June 11 - 14, 2012 Committees ---------- Honorary Chair: Danny Goderis, Bell Labs, Alcatel-Lucent, Belgium General Chairs: Fahim Kawsar, Bell Labs, Alcatel-Lucent, Belgium Tian He, University of Minnesota, USA Program Chair: Hiroyuki Shinoda, University of Tokyo, Japan Program Vice Chairs: Hedda Schmidtke, TecO and Karlsruhe Institute of Technology, Germany Niwat Thepvilojanapong, Mie University, Japan Simon Egerton, Monash University, Malaysia and Australia Industrial Track Chairs: Xueli An, Bell Labs, Alcatel-Lucent, Belgium Bing Zhang, NICT, Japan Workshop Chairs: Fabio Pianese, Bell Labs, Alcatel-Lucent, Belgium Takuro Yonezawa, Keio University, Japan Poster Chairs: Andreas Bulling, University of Cambridge / Lancaster University, UK Jean-Baptiste Labrune, Bell Labs, Alcatel-Lucent, France Demonstration Chairs: Mathieu Boussard, Bell Labs, Alcatel-Lucent, France Till Riedel, TecO and Karlsruhe Institute of Technology, Germany IEEE Liaison Chair: Kohei Ohnishi, Keio University, Japan Web Chair: Henning Schild, Bell Labs, Alcatel-Lucent, Belgium Publicity Chair: Alireza Sahami, University of Stuttgart, Germany Student Volunteer Chair: Jo Vermeulen, Hasselt University, Belgium Publication Chair: Hiroki Ishizuka, University of Tokyo, Japan Local Arrangement: Brigitte Van Dam, Alcatel-Lucent, Belgium Rita Daelemans, Alcatel-Lucent, Belgium Technical Program Committee: Tarek Abdelzaher, University of Illinois, Urbana Champaign Michael Beigl, KIT Christian Decker, TecO, University of Karlsruhe Simon Egerton, Monash University David Evans, University of Cambridge Yu Gu, Singapore University of Technology and Design Satoshi Honda, Keio University Hideto Iwaoka, Kanazawa Institute of Technology Yoshihiro Kawahara, The University of Tokyo Hideyuki Kawashima, University of Tsukuba Fahim Kawsar, Bell Labs Daeyoung Kim, Korea Advanced Institute of Science and Technology Narito Kurata, Kajima Satoshi Kurihara, Osaka University Marc Langheinrich, University of Lugano (USI) Hyunyoung Lee, Texas A&M University Pedro Marron, University of Duisburg-Essen and Fraunhofer FKIE Masateru Minami, Shibaura Institute of Technology Jin Nakazawa, Keio University Hiroshi Noguchi, The University of Tokyo Marcelo Pias, Cambridge University Till Riedel, TecO, Karlsruhe Institute of Technology Hedda Schmidtke, KIT TecO Hiroyuki Shinoda, University of Tokyo Niwat Thepvilojanapong, Mie University Yoshito Tobe, Tokyo Denki University Kristof Van Laerhoven, TU Darmstadt Matthias Woehrle, Delft University of Technology Gang Zhou, College of William and Mary --_000_CB0E82B824807alirezasahamivisunistuttgartde_ Content-Type: text/html; charset="us-ascii" Content-ID: <745E5FFF9CB2C844A0F8D561D4DC411B@visus.uni-stuttgart.de> Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
(Please accept our apologies if you receive multiple copies of this CF= P.)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Call for Papers
The Ninth International Conference of Networked Sensing Systems (INSS = 2012)

Antwerp, Belgium, June 11-14, 2012
Submission Deadline: December 24, 2011
http://www.inss-conf.org/2012

Scope and Theme:
---------------
During the past years, the International Conference on Networked Sensi= ng Systems (INSS) has established itself as a scientific event where academ= ic and industrial experts from the areas of next generation sensor systems,= sensor network applications, and measurement and control engineering come together. The INSS provides a for= um to hear about the latest developments in these areas, to exchange ideas,= and to start up collaborations within these fields and between industry an= d academia.

INSS 2012 is the ninth annual conference in the series, and features a= highly selective technical program. We invite outstanding research papers = from the field of sensor technology, wireless networking, or applications o= f networked sensor systems. The conference especially encourages submissions that investigate research iss= ues shared between all the three areas.

INSS 2012 invites the submission of regular, short, and industry paper= s. All submissions will be peer-reviewed and evaluated on the basis of orig= inality, significance of contribution, technical correctness, and presentat= ion. Papers submitted must not be under simultaneous review for any other conference, journal, workshop, or = other publication. All accepted papers will be published at IEEE Xplore dig= ital library. Authors are required to attend the conference to present thei= r work.

Regular/Short Paper Track
-------------------------
Regular papers must be 4-8 pages long (two-column format) and include = an abstract of 100-150 words. Short papers must be 2-4 pages long (two-colu= mn format) and include an abstract of 100-150 words. All papers should be f= ormatted according to the IEEE transactions format. Short papers are suitable for interactive discussions. Presentatio= n time of accepted regular and short papers is decided on acceptance notifi= cation. Topics of regular/short paper track include but are not limited to:=
o Theo= retical Study on Networked Sensing Systems
o Appl= ications of Networked Sensing Systems
o Prot= otypes, Field Studies & Test beds for Networked Sensing Systems
o Safe= ty and Security of Networked Sensing Systems
o Data= Management for Networked Sensing Systems
o Midd= leware for Networked Sensing Systems 
o Self= -Organizing Networked Sensing Systems and Autonomic/Bio-Inspired Systems
o Inte= lligent Sensing Systems
o Sens= or Phenomena and Modeling
o Sens= ors and Sensing Systems
o Sens= ors and Actuators for Smart Meter and Smart Grid Applications 
o Huma= n Behavior Sensing and Ambient Support
o Huma= n Health Monitoring and Biomedical Measurement
o Meas= urement and Control Issues in Networked Sensing Systems
o Netw= orked Sensing Systems involving Haptic Interactions
o Mate= rials, Design, Fabrication, and Packaging of Sensors

Industry Paper Track
--------------------
INSS also offers an industry track. In this track, new and interesting= developments in networks for industrial applications can be recognized, wh= ether in the area of sensor systems, wireless networks, industrial network = applications, networks for safety related systems and applications, different security aspects in networks f= ault tolerant and redundant networks and many others. This session focuses = on innovative, new and interesting network applications and research result= s for industries or developments which will be important in the near future. The industry track intends to = provide discussion for practitioners, developers, and researchers in order = to examine practical issues.?Industry papers are suitable for industry rese= archers to present not only technical, but also practical issues surrounding production, deployment, and commerci= alisation of networked sensing technology. Industry papers must be 2-4 page= s long (two-column format) and include an abstract of 100-150 words. Papers= should be formatted according to the IEEE transactions format. The submitted industry papers will be review= ed by industry track TPC members and accepted papers will be presented in t= he main conference's industry track session. The industry track aims at pro= viding a forum among practitioners, developers, and researchers to discuss practical issues including but not = limited to:
o Desi= gning networked sensing systems for commercial applications
o Serv= ice models and architectures for successful deployments
o Prod= uction engineering for networked sensing systems
o Depl= oyment and evaluation of networked sensing systems in practical application= s

Paper submission
----------------
Submissions should be in PDF format and will be handled through EDAS.&= nbsp;
http://edas.info/N11501

Important Dates (both regular/short and industry tracks) 
--------------------------------------------------------
Paper Submissions Due: December 24th, 2011 
Notification of Acceptance: March 15th, 2012
Camera-Ready Papers: April 15th, 2012
Conference Dates: June 11 - 14, 2012

Committees
----------

Honorary Chair:
Danny Goderis, Bell Labs, Alcatel-Lucent, Belgium

General Chairs:
Fahim Kawsar, Bell Labs, Alcatel-Lucent, Belgium
Tian He, University of Minnesota, USA

Program Chair:
Hiroyuki Shinoda, University of Tokyo, Japan

Program Vice Chairs:
Hedda Schmidtke, TecO and Karlsruhe Institute of Technology, Germany
Niwat Thepvilojanapong, Mie University, Japan
Simon Egerton, Monash University, Malaysia and Australia

Industrial Track Chairs:
Xueli An, Bell Labs, Alcatel-Lucent, Belgium
Bing Zhang, NICT, Japan

Workshop Chairs:
Fabio Pianese, Bell Labs, Alcatel-Lucent, Belgium
Takuro Yonezawa, Keio University, Japan

Poster Chairs:
Andreas Bulling, University of Cambridge / Lancaster University, UK
Jean-Baptiste Labrune, Bell Labs, Alcatel-Lucent, France

Demonstration Chairs:
Mathieu Boussard, Bell Labs, Alcatel-Lucent, France
Till Riedel, TecO and Karlsruhe Institute of Technology, Germany

IEEE Liaison Chair:
Kohei Ohnishi, Keio University, Japan

Web Chair:
Henning Schild, Bell Labs, Alcatel-Lucent, Belgium

Publicity Chair:
Alireza Sahami, University of Stuttgart, Germany

Student Volunteer Chair:
Jo Vermeulen, Hasselt University, Belgium

Publication Chair:
Hiroki Ishizuka, University of Tokyo, Japan

Local Arrangement:
Brigitte Van Dam, Alcatel-Lucent, Belgium
Rita Daelemans, Alcatel-Lucent, Belgium

Technical Program Committee:
Tarek Abdelzaher, University of Illinois, Urbana Champaign
Michael Beigl, KIT
Christian Decker, TecO, University of Karlsruhe
Simon Egerton, Monash University
David Evans, University of Cambridge
Yu Gu, Singapore University of Technology and Design
Satoshi Honda, Keio University
Hideto Iwaoka, Kanazawa Institute of Technology
Yoshihiro Kawahara, The University of Tokyo
Hideyuki Kawashima, University of Tsukuba
Fahim Kawsar, Bell Labs
Daeyoung Kim, Korea Advanced Institute of Science and Technology
Narito Kurata, Kajima
Satoshi Kurihara, Osaka University
Marc Langheinrich, University of Lugano (USI)
Hyunyoung Lee, Texas A&M University
Pedro Marron, University of Duisburg-Essen and Fraunhofer FKIE
Masateru Minami, Shibaura Institute of Technology
Jin Nakazawa, Keio University
Hiroshi Noguchi, The University of Tokyo
Marcelo Pias, Cambridge University
Till Riedel, TecO, Karlsruhe Institute of Technology
Hedda Schmidtke, KIT TecO
Hiroyuki Shinoda, University of Tokyo
Niwat Thepvilojanapong, Mie University
Yoshito Tobe, Tokyo Denki University
Kristof Van Laerhoven, TU Darmstadt
Matthias Woehrle, Delft University of Technology
Gang Zhou, College of William and Mary
--_000_CB0E82B824807alirezasahamivisunistuttgartde_-- From Alireza.Sahami@vis.uni-stuttgart.de Sat Dec 24 02:08:02 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E1521F84A8; Sat, 24 Dec 2011 02:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98nAf3u72SlV; Sat, 24 Dec 2011 02:08:01 -0800 (PST) Received: from Bagatelle.visus.uni-stuttgart.de (bagatelle.visus.uni-stuttgart.de [129.69.215.10]) by ietfa.amsl.com (Postfix) with ESMTP id 822C121F8495; Sat, 24 Dec 2011 02:07:59 -0800 (PST) Received: from BAGATELLE.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7]) by Bagatelle.visus.uni-stuttgart.de ([fe80::ac27:a88c:6e43:c5d7%19]) with mapi id 14.02.0247.003; Sat, 24 Dec 2011 11:07:53 +0100 From: Alireza Sahami To: Alireza Sahami Thread-Topic: Deadline Extended- INSS 2012: International Conference of Networked Sensing Systems Thread-Index: AQHMwiPmjnlUO5oLxUCmJfzZTg8IZw== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [93.94.245.143] Content-Type: multipart/alternative; boundary="_000_CB1B62FD24EBCalirezasahamivisunistuttgartde_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 Jan 2012 08:05:17 -0800 Subject: [Roll] Deadline Extended- INSS 2012: International Conference of Networked Sensing Systems X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 24 Dec 2011 10:08:02 -0000 X-Original-Date: Sat, 24 Dec 2011 10:07:52 +0000 X-List-Received-Date: Sat, 24 Dec 2011 10:08:02 -0000 --_000_CB1B62FD24EBCalirezasahamivisunistuttgartde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Apologies for cross posting Call for Papers The Ninth International Conference of Networked Sensing Systems (INSS 2012) Antwerp, Belgium, June 11-14, 2012 Extended Submission Deadline: January 16, 2012 http://www.inss-conf.org/2012 Scope and Theme: --------------- During the past years, the International Conference on Networked Sensing Sy= stems (INSS) has established itself as a scientific event where academic an= d industrial experts from the areas of next generation sensor systems, sens= or network applications, and measurement and control engineering come toget= her. The INSS provides a forum to hear about the latest developments in the= se areas, to exchange ideas, and to start up collaborations within these fi= elds and between industry and academia. INSS 2012 is the ninth annual conference in the series, and features a high= ly selective technical program. We invite outstanding research papers from = the field of sensor technology, wireless networking, or applications of net= worked sensor systems. The conference especially encourages submissions tha= t investigate research issues shared between all the three areas. INSS 2012 invites the submission of regular, short, and industry papers. Al= l submissions will be peer-reviewed and evaluated on the basis of originali= ty, significance of contribution, technical correctness, and presentation. = Papers submitted must not be under simultaneous review for any other confer= ence, journal, workshop, or other publication. All accepted papers will be = published at IEEE Xplore digital library. Authors are required to attend th= e conference to present their work. Regular/Short Paper Track ------------------------- Regular papers must be 4-8 pages long (two-column format) and include an ab= stract of 100-150 words. Short papers must be 2-4 pages long (two-column fo= rmat) and include an abstract of 100-150 words. All papers should be format= ted according to the IEEE transactions format. Short papers are suitable fo= r interactive discussions. Presentation time of accepted regular and short = papers is decided on acceptance notification. Topics of regular/short paper= track include but are not limited to: o Theoretical Study on Networked Sensing Systems o Applications of Networked Sensing Systems o Prototypes, Field Studies & Test beds for Networked Sensing Systems o Safety and Security of Networked Sensing Systems o Data Management for Networked Sensing Systems o Middleware for Networked Sensing Systems o Self-Organizing Networked Sensing Systems and Autonomic/Bio-Inspired S= ystems o Intelligent Sensing Systems o Sensor Phenomena and Modeling o Sensors and Sensing Systems o Sensors and Actuators for Smart Meter and Smart Grid Applications o Human Behavior Sensing and Ambient Support o Human Health Monitoring and Biomedical Measurement o Measurement and Control Issues in Networked Sensing Systems o Networked Sensing Systems involving Haptic Interactions o Materials, Design, Fabrication, and Packaging of Sensors Industry Paper Track -------------------- INSS also offers an industry track. In this track, new and interesting deve= lopments in networks for industrial applications can be recognized, whether= in the area of sensor systems, wireless networks, industrial network appli= cations, networks for safety related systems and applications, different se= curity aspects in networks fault tolerant and redundant networks and many o= thers. This session focuses on innovative, new and interesting network appl= ications and research results for industries or developments which will be = important in the near future. The industry track intends to provide discuss= ion for practitioners, developers, and researchers in order to examine prac= tical issues. Industry papers are suitable for industry researchers to pres= ent not only technical, but also practical issues surrounding production, d= eployment, and commercialisation of networked sensing technology. Industry = papers must be 2-4 pages long (two-column format) and include an abstract o= f 100-150 words. Papers should be formatted according to the IEEE transacti= ons format. The submitted industry papers will be reviewed by industry trac= k TPC members and accepted papers will be presented in the main conference'= s industry track session. The industry track aims at providing a forum amon= g practitioners, developers, and researchers to discuss practical issues in= cluding but not limited to: o Designing networked sensing systems for commercial applications o Service models and architectures for successful deployments o Production engineering for networked sensing systems o Deployment and evaluation of networked sensing systems in practical ap= plications Paper submission ---------------- Submissions should be in PDF format and will be handled through EDAS. http://edas.info/N11501 Important Dates (both regular/short and industry tracks) -------------------------------------------------------- Paper Submissions Due: January 16th, 2012 Notification of Acceptance: March 15th, 2012 Camera-Ready Papers: April 15th, 2012 Conference Dates: June 11 - 14, 2012 Committees ---------- Honorary Chair: Danny Goderis, Bell Labs, Alcatel-Lucent, Belgium General Chairs: Fahim Kawsar, Bell Labs, Alcatel-Lucent, Belgium Tian He, University of Minnesota, USA Program Chair: Hiroyuki Shinoda, University of Tokyo, Japan Program Vice Chairs: Niwat Thepvilojanapong, Mie University, Japan Hedda Schmidtke, Germany Simon Egerton, Monash University, Malaysia and Australia Industrial Track Chairs: Xueli An, Bell Labs, Alcatel-Lucent, Belgium Bing Zhang, NICT, Japan Workshop Chairs: Fabio Pianese, Bell Labs, Alcatel-Lucent, Belgium Takuro Yonezawa, Keio University, Japan Poster Chairs: Andreas Bulling, University of Cambridge / Lancaster University, UK Jean-Baptiste Labrune, Bell Labs, Alcatel-Lucent, France Demonstration Chairs: Mathieu Boussard, Bell Labs, Alcatel-Lucent, France Till Riedel, TecO and Karlsruhe Institute of Technology, Germany IEEE Liaison Chairs: Makoto Iwasaki, Nagoya Institute of Technology Kiyoshi Ohishi, Nagaoka University of Technology Kohei Ohnishi, Keio University, Japan Web Chair: Henning Schild, Bell Labs, Alcatel-Lucent, Belgium Publicity Chair: Alireza Sahami, Univeristy of Stuttgart, Germany Student Volunteer Chair: Jo Vermeulen, Hasselt University, Belgium Publication Chair: Hiroki Ishizuka, University of Tokyo, Japan Local Arrangement: Brigitte Van Dam, Alcatel-Lucent, Belgium Rita Daelemans, Alcatel-Lucent, Belgium Technical Program Committee: Abdelsalam Helal, University of Florida Alexander De Luca, University of Munich Andreas Bulling, University of Cambridge Anthony Rowe, Carnegie Mellon University Christian Decker, TecO, University of Karlsruhe David Evans, University of Cambridge Daeyoung Kim, Korea Advanced Institute of Science and Technology Florian Michahelles, ETH Zurich Gang Zhou, College of William and Mary Gerd Kortuem, Lancaster University Hideyuki Kawashima, University of Tsukuba Hideto Iwaoka, Kanazawa Institute of Technology Hiroshi Noguchi, The University of Tokyo Hyunyoung Lee, Texas A&M University Jin Nakazawa, Keio University Kristof Van Laerhoven, TU Darmstadt Matthias Woehrle, Delft University of Technology Masateru Minami, Shibaura Institute of Technology Marc Langheinrich, University of Lugano (USI) Marcelo Pias, Cambridge University Michael Beigl, Karlsruhe Institute of Technology Narito Kurata, Kajima Paul Havinga, University of Twente Pedro Marr=DBn, University of Duisburg-Essen and Fraunhofer FKIE Petteri Nurmi, Helsinki Institute for Information Technology HIIT Polly Huang, National Taiwan University Satoshi Kurihara, Osaka University Satoshi Honda, Keio University Shan Lin, Temple University Susanna Pirttikangas, University of Oulu Tatsuo Nakajima, Waseda University Tarek Abdelzaher, University of Illinois, Urbana Champaign Thomas Pl=88tz, Newcastle University Till Riedel, TecO, Karlsruhe Institute of Technology Yoshihiro Kawahara, The University of Tokyo Yoshito Tobe, Tokyo Denki University Yu Gu, Singapore University of Technology and Design Industrial Track Committee: Azman Lim, Japan Advanced Institute of Science and Technology (JAIST) Cheng Guo, Technologic University of Delft Christoph Mayer, Karlsruhe Institute of Technology (KIT) Michael Timmers, Alcatel-Lucent Bell Labs Nicolaie Fantana, ABB AG Forschungszentrum Deutschland Rui Teng, National Institute of Information and Communications Technology Takashi Matsuda, National Institute of Information and Communications Techn= ology Tuncer Baykas, National Institute of Information and Communications Technol= ogy --_000_CB1B62FD24EBCalirezasahamivisunistuttgartde_ Content-Type: text/html; charset="Windows-1252" Content-ID: <765FD498FD13D44F8F9D2695B2BC453B@visus.uni-stuttgart.de> Content-Transfer-Encoding: quoted-printable
Apologies for cross posting

Call for Papers
The Ninth International Conference of Networked Sensing Systems (INSS = 2012)

Antwerp, Belgium, June 11-14, 2012
Extended Submission Deadline: January 16, 2012

Scope and Theme:
---------------
During the past years, the International Conference on Networked Sensi= ng Systems (INSS) has established itself as a scientific event where academ= ic and industrial experts from the areas of next generation sensor systems,= sensor network applications, and measurement and control engineering come together. The INSS provides a for= um to hear about the latest developments in these areas, to exchange ideas,= and to start up collaborations within these fields and between industry an= d academia.

INSS 2012 is the ninth annual conference in the series, and features a= highly selective technical program. We invite outstanding research papers = from the field of sensor technology, wireless networking, or applications o= f networked sensor systems. The conference especially encourages submissions that investigate research iss= ues shared between all the three areas.

INSS 2012 invites the submission of regular, short, and industry paper= s. All submissions will be peer-reviewed and evaluated on the basis of orig= inality, significance of contribution, technical correctness, and presentat= ion. Papers submitted must not be under simultaneous review for any other conference, journal, workshop, or = other publication. All accepted papers will be published at IEEE Xplore dig= ital library. Authors are required to attend the conference to present thei= r work.

Regular/Short Paper Track
-------------------------
Regular papers must be 4-8 pages long (two-column format) and include = an abstract of 100-150 words. Short papers must be 2-4 pages long (two-colu= mn format) and include an abstract of 100-150 words. All papers should be f= ormatted according to the IEEE transactions format. Short papers are suitable for interactive discussions. Presentatio= n time of accepted regular and short papers is decided on acceptance notifi= cation. Topics of regular/short paper track include but are not limited to:=
o    Theoretical Study on Networked Sensing Systems
o    Applications of Networked Sensing Systems
o    Prototypes, Field Studies & Test beds for Networked= Sensing Systems
o    Safety and Security of Networked Sensing Systems
o    Data Management for Networked Sensing Systems
o    Middleware for Networked Sensing Systems
o    Self-Organizing Networked Sensing Systems and Autonomic= /Bio-Inspired Systems
o    Intelligent Sensing Systems
o    Sensor Phenomena and Modeling
o    Sensors and Sensing Systems
o    Sensors and Actuators for Smart Meter and Smart Grid Ap= plications
o    Human Behavior Sensing and Ambient Support
o    Human Health Monitoring and Biomedical Measurement
o    Measurement and Control Issues in Networked Sensing Sys= tems
o    Networked Sensing Systems involving Haptic Interactions=
o    Materials, Design, Fabrication, and Packaging of Sensor= s

Industry Paper Track
--------------------
INSS also offers an industry track. In this track, new and interesting= developments in networks for industrial applications can be recognized, wh= ether in the area of sensor systems, wireless networks, industrial network = applications, networks for safety related systems and applications, different security aspects in networks f= ault tolerant and redundant networks and many others. This session focuses = on innovative, new and interesting network applications and research result= s for industries or developments which will be important in the near future. The industry track intends to = provide discussion for practitioners, developers, and researchers in order = to examine practical issues. Industry papers are suitable for industry rese= archers to present not only technical, but also practical issues surrounding production, deployment, and commerci= alisation of networked sensing technology. Industry papers must be 2-4 page= s long (two-column format) and include an abstract of 100-150 words. Papers= should be formatted according to the IEEE transactions format. The submitted industry papers will be review= ed by industry track TPC members and accepted papers will be presented in t= he main conference's industry track session. The industry track aims at pro= viding a forum among practitioners, developers, and researchers to discuss practical issues including but not = limited to:
o    Designing networked sensing systems for commercial appl= ications
o    Service models and architectures for successful deploym= ents
o    Production engineering for networked sensing systems
o    Deployment and evaluation of networked sensing systems = in practical applications

Paper submission
----------------
Submissions should be in PDF format and will be handled through EDAS.<= /div>

Important Dates (both regular/short and industry tracks)
--------------------------------------------------------
Paper Submissions Due: January 16th, 2012
Notification of Acceptance: March 15th, 2012
Camera-Ready Papers: April 15th, 2012
Conference Dates: June 11 - 14, 2012

Committees
----------

Honorary Chair:
Danny Goderis, Bell Labs, Alcatel-Lucent, Belgium

General Chairs:
Fahim Kawsar, Bell Labs, Alcatel-Lucent, Belgium
Tian He, University of Minnesota, USA

Program Chair:
Hiroyuki Shinoda, University of Tokyo, Japan

Program Vice Chairs:
Niwat Thepvilojanapong, Mie University, Japan
Hedda Schmidtke, Germany
Simon Egerton, Monash University, Malaysia and Australia

Industrial Track Chairs:
Xueli An, Bell Labs, Alcatel-Lucent, Belgium
Bing Zhang, NICT, Japan

Workshop Chairs:
Fabio Pianese, Bell Labs, Alcatel-Lucent, Belgium
Takuro Yonezawa, Keio University, Japan

Poster Chairs:
Andreas Bulling, University of Cambridge / Lancaster University, UK
Jean-Baptiste Labrune, Bell Labs, Alcatel-Lucent, France

Demonstration Chairs:
Mathieu Boussard, Bell Labs, Alcatel-Lucent, France
Till Riedel, TecO and Karlsruhe Institute of Technology, Germany

IEEE Liaison Chairs:
Makoto Iwasaki, Nagoya Institute of Technology
Kiyoshi Ohishi, Nagaoka University of Technology
Kohei Ohnishi, Keio University, Japan

Web Chair:
Henning Schild, Bell Labs, Alcatel-Lucent, Belgium

Publicity Chair:
Alireza Sahami, Univeristy of Stuttgart, Germany

Student Volunteer Chair:
Jo Vermeulen, Hasselt University, Belgium

Publication Chair:
Hiroki Ishizuka, University of Tokyo, Japan

Local Arrangement:
Brigitte Van Dam, Alcatel-Lucent, Belgium
Rita Daelemans, Alcatel-Lucent, Belgium

Technical Program Committee:
Abdelsalam Helal, University of Florida
Alexander De Luca, University of Munich
Andreas Bulling, University of Cambridge
Anthony Rowe, Carnegie Mellon University
Christian Decker, TecO, University of Karlsruhe
David Evans, University of Cambridge
Daeyoung Kim, Korea Advanced Institute of Science and Technology
Florian Michahelles, ETH Zurich
Gang Zhou, College of William and Mary
Gerd Kortuem, Lancaster University
Hideyuki Kawashima, University of Tsukuba
Hideto Iwaoka, Kanazawa Institute of Technology
Hiroshi Noguchi, The University of Tokyo
Hyunyoung Lee, Texas A&M University
Jin Nakazawa, Keio University
Kristof Van Laerhoven, TU Darmstadt
Matthias Woehrle, Delft University of Technology
Masateru Minami, Shibaura Institute of Technology
Marc Langheinrich, University of Lugano (USI)
Marcelo Pias, Cambridge University
Michael Beigl, Karlsruhe Institute of Technology
Narito Kurata, Kajima
Paul Havinga, University of Twente
Pedro Marr=DBn, University of Duisburg-Essen and Fraunhofer FKIE
Petteri Nurmi, Helsinki Institute for Information Technology HIIT
Polly Huang, National Taiwan University
Satoshi Kurihara, Osaka University
Satoshi Honda, Keio University
Shan Lin, Temple University
Susanna Pirttikangas, University of Oulu
Tatsuo Nakajima, Waseda University
Tarek Abdelzaher, University of Illinois, Urbana Champaign
Thomas Pl=88tz, Newcastle University
Till Riedel, TecO, Karlsruhe Institute of Technology
Yoshihiro Kawahara, The University of Tokyo
Yoshito Tobe, Tokyo Denki University
Yu Gu, Singapore University of Technology and Design

Industrial Track Committee:
Azman Lim, Japan Advanced Institute of Science and Technology (JAIST)<= /div>
Cheng Guo, Technologic University of Delft
Christoph Mayer, Karlsruhe Institute of Technology (KIT)
Michael Timmers, Alcatel-Lucent Bell Labs
Nicolaie Fantana, ABB AG Forschungszentrum Deutschland
Rui Teng, National Institute of Information and Communications Technol= ogy
Takashi Matsuda, National Institute of Information and Communications = Technology
Tuncer Baykas, National Institute of Information and Communications Te= chnology
--_000_CB1B62FD24EBCalirezasahamivisunistuttgartde_-- From internet-drafts@ietf.org Thu Jan 12 10:49:29 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D0721F86C8; Thu, 12 Jan 2012 10:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNAkV28YJ-3T; Thu, 12 Jan 2012 10:49:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A050E21F85E6; Thu, 12 Jan 2012 10:49:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112184928.3644.48946.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 10:49:28 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-framework-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jan 2012 18:49:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : A Security Framework for Routing over Low Power and Loss= y Networks Author(s) : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Filename : draft-ietf-roll-security-framework-07.txt Pages : 49 Date : 2012-01-12 This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 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-security-framework-07.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-security-framework-07.txt From prvs=3515d3c19=Tzeta.Tsao@cooperindustries.com Thu Jan 12 10:53:44 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A58B21F85E0 for ; Thu, 12 Jan 2012 10:53:44 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTW1QsVAnIa5 for ; Thu, 12 Jan 2012 10:53:44 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id D87B521F85DF for ; Thu, 12 Jan 2012 10:53:43 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.71,499,1320642000"; d="scan'208";a="38235140" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 12 Jan 2012 13:53:42 -0500 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 13:53:43 -0500 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, 12 Jan 2012 13:52:54 -0500 Message-ID: <85A23E0910B2FB4B8EF60D0888CB08361B48F4@EVS2.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-roll-security-framework-07.txt Thread-Index: AczRWusdGMOFFknYQxyjo5NaJF8dbQAAAm+g From: "Tsao, Tzeta" To: X-OriginalArrivalTime: 12 Jan 2012 18:53:43.0692 (UTC) FILETIME=[81CE6CC0:01CCD15B] Subject: [Roll] FW: New Version Notification for draft-ietf-roll-security-framework-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jan 2012 18:53:44 -0000 V0csDQoNCldlIGhhdmUgcG9zdGVkIGRyYWZ0LWlldGYtcm9sbC1zZWN1cml0eS1mcmFtZXdvcmst MDcsIHdoaWNoIHNob3VsZCBiZSBhdmFpbGFibGUgZnJvbSB0aGUgcmVwb3NpdG9yeSBzaG9ydGx5 OyB3ZSBoYXZlIGFkZGVkIG1hdGVyaWFsIHRvIGNsYXJpZnkgdGhlIGtleSBtYW5hZ2VtZW50IGlz c3Vlcy4NCg0KVGhhbmtzLA0KVHpldGENCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDEyLCAyMDEyIDE6NDkgUE0NClRvOiBU c2FvLCBUemV0YQ0KQ2M6IHZhbmVzYS5kYXphQHVwZi5lZHU7IGFuZ2VsLmxvemFub0B1cGYuZWR1 OyBtaXNjaGEuZG9obGVyQGN0dGMuZXM7IEFsZXhhbmRlciwgUm9nZXI7IFRzYW8sIFR6ZXRhDQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtcm9sbC1zZWN1 cml0eS1mcmFtZXdvcmstMDcudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRm LXJvbGwtc2VjdXJpdHktZnJhbWV3b3JrLTA3LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFR6ZXRhIFRzYW8gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpGaWxlbmFtZToJIGRyYWZ0LWlldGYtcm9sbC1zZWN1cml0eS1mcmFtZXdvcmsNClJldmlzaW9u OgkgMDcNClRpdGxlOgkJIEEgU2VjdXJpdHkgRnJhbWV3b3JrIGZvciBSb3V0aW5nIG92ZXIgTG93 IFBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDEtMTINCldH IElEOgkJIHJvbGwNCk51bWJlciBvZiBwYWdlczogNDkNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRv Y3VtZW50IHByZXNlbnRzIGEgc2VjdXJpdHkgZnJhbWV3b3JrIGZvciByb3V0aW5nIG92ZXIgbG93 DQogICBwb3dlciBhbmQgbG9zc3kgbmV0d29ya3MgKExMTikuICBUaGUgZGV2ZWxvcG1lbnQgYnVp bGRzIHVwb24gcHJldmlvdXMNCiAgIHdvcmsgb24gcm91dGluZyBzZWN1cml0eSBhbmQgYWRhcHRz IHRoZSBhc3Nlc3NtZW50cyB0byB0aGUgaXNzdWVzIGFuZA0KICAgY29uc3RyYWludHMgc3BlY2lm aWMgdG8gbG93IHBvd2VyIGFuZCBsb3NzeSBuZXR3b3Jrcy4gIEEgc3lzdGVtYXRpYw0KICAgYXBw cm9hY2ggaXMgdXNlZCBpbiBkZWZpbmluZyBhbmQgZXZhbHVhdGluZyB0aGUgc2VjdXJpdHkgdGhy ZWF0cyBhbmQNCiAgIGlkZW50aWZ5aW5nIGFwcGxpY2FibGUgY291bnRlcm1lYXN1cmVzLiAgVGhl c2UgYXNzZXNzbWVudHMgcHJvdmlkZQ0KICAgdGhlIGJhc2lzIG9mIHRoZSBzZWN1cml0eSByZWNv bW1lbmRhdGlvbnMgZm9yIGluY29ycG9yYXRpb24gaW50byBsb3cNCiAgIHBvd2VyLCBsb3NzeSBu ZXR3b3JrIHJvdXRpbmcgcHJvdG9jb2xzLiAgQXMgYW4gaWxsdXN0cmF0aW9uLCB0aGlzDQogICBm cmFtZXdvcmsgaXMgYXBwbGllZCB0byBJUHY2IFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dl ciBhbmQgTG9zc3kNCiAgIE5ldHdvcmtzIChSUEwpLg0KDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From azdvir@gmail.com Sun Jan 15 02:45:37 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A11121F845A for ; Sun, 15 Jan 2012 02:45:37 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu9HPXIr5T48 for ; Sun, 15 Jan 2012 02:45:37 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA3DF21F8458 for ; Sun, 15 Jan 2012 02:45:36 -0800 (PST) Received: by wics10 with SMTP id s10so447990wic.31 for ; Sun, 15 Jan 2012 02:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=jlB1qjoYdS1w2oyMOwkcoJHNSin3135ff4EEdsQfask=; b=aPOqVTFAu7EdhS9tw6kAl2wilQIp14PaHNEIRhgTdzeZtDaqbx2dFZs8o6MA9BEYqk q+NnmWLxG/f8C7aTqTO+eX/Zw7XmUStmsWfagP6e4Dl1zepamhjGD82Hj8lTJPH1cNfz xpF48LgEFU2bTCngZxYS9UDJXkqJeo91esffQ= Received: by 10.180.100.234 with SMTP id fb10mr7639246wib.5.1326624335970; Sun, 15 Jan 2012 02:45:35 -0800 (PST) Received: from userPC ([193.106.55.211]) by mx.google.com with ESMTPS id gy6sm8759647wib.11.2012.01.15.02.45.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 15 Jan 2012 02:45:35 -0800 (PST) From: "amit" To: Date: Sun, 15 Jan 2012 12:45:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczTcoGsLwg6yHUcRAWHHzjXrzhyOg== Content-Language: he Subject: [Roll] draft-dvir-roll-security-authentication-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 Jan 2012 10:45:37 -0000 We will appreciate comments from the working group.=20 A new version of I-D, draft-dvir-roll-security-authentication-01.txt has = been successfully submitted by Amit Dvir and posted to the IETF = repository. Filename: draft-dvir-roll-security-authentication Revision: 01 Title: Version Number and Rank Authentication Creation date: 2012-01-08 WG ID: Individual Submission Number of pages: 24 Abstract: Designing a routing protocol for large low-power and lossy networks (LLNs), consisting of thousands of constrained nodes and unreliable links, presents new challenges. The IPv6 Routing Protocol for Low- power and Lossy Networks (RPL), have been developed by the IETF ROLL Working Group as a preferred routing protocol to provide IPv6 routing functionality in LLNs. Unfortunately, the currently available security services in RPL will not protect against a compromised internal node that can construct and disseminate fake messages. Therefore, in RPL special security care must be taken when the Destination Oriented Directed Acyclic Graph (DODAG) root is updating the Version Number by which reconstruction of the routing topology can be initiated. The same care also must be taken to prevent an internal attacker (compromised DODAG node) to publish decreased Rank value, which causes a large part of the DODAG to connect to the DODAG root via the attacker and give it the ability to eavesdrop or manipulate a large part of the network traffic. In this document, a new security service is described that prevents any misbehaving DODAG node from illegitimately increasing the Version Number or publish illegitimately decreased Rank values. = =20 From azdvir@gmail.com Tue Jan 17 06:16:55 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED0921F85F2 for ; Tue, 17 Jan 2012 06:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OFZKLro5cjB for ; Tue, 17 Jan 2012 06:16:53 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 59E4E21F85E4 for ; Tue, 17 Jan 2012 06:16:53 -0800 (PST) Received: by eeit10 with SMTP id t10so1313185eei.31 for ; Tue, 17 Jan 2012 06:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=lyg0TPlojmxriZToxj4aDLKXt8eAtHvRtwxspXCxE2o=; b=e01KgesGFq4s3vMaxmiG3KrwF4wsw2zrZvtC+K8f+Gov7n5h2OQi9nr2PxPB3aAk0o QFaaShOu0xUCRKB3vUzfWJ9leI9hZ1MZtXgl2hoEOjFlO/5OcEuzL2rgzf71SbNYwnYf ZGroRCg6gdgpcQDqpUTO1vZbC8iCuKgxaoyPY= Received: by 10.213.34.212 with SMTP id m20mr4311873ebd.30.1326809812141; Tue, 17 Jan 2012 06:16:52 -0800 (PST) Received: from userPC (bzq-84-109-52-93.red.bezeqint.net. [84.109.52.93]) by mx.google.com with ESMTPS id t59sm86415638eeh.10.2012.01.17.06.16.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 06:16:51 -0800 (PST) From: "amit" To: Date: Tue, 17 Jan 2012 16:16:49 +0200 Message-ID: <1de4401ccd522$a87b9ee0$f972dca0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczVImJYMExAuJjkTziXDbPzYA8Ymg== Content-Language: he Subject: [Roll] Roll Digest, Vol 48, Issue 1 - roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jan 2012 14:16:55 -0000 Regarding your security comment, don=92t you think that the basic = assumption of the RPL draft that the devices are trusted, is problematic. Moreover, roll-rpl-industrial-applicability consider the case that other layers = will take care about the security (section 5.3), however, counting on upper = layer can't solve security problems of the RPL parameters and the link layer = can't be trusted when node can be compromise.=20 I know that compromise is out of the scope but maybe we need to start thinking about those cases. -----=E4=E5=E3=F2=E4 =EE=F7=E5=F8=E9=FA----- =EE=E0=FA: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = =E1=F9=ED roll-request@ietf.org =F0=F9=EC=E7: =E9=E5=ED=A0=E1 02 =E9=F0=E5=E0=F8 2012 22:00 =E0=EC: roll@ietf.org =F0=E5=F9=E0: Roll Digest, Vol 48, Issue 1 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get = MIME or Plain Text Digests?" to MIME. You can set this option globally for all = the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. roll-rpl-industrial-applicability (Michael Richardson) ---------------------------------------------------------------------- Message: 1 Date: Mon, 02 Jan 2012 11:16:06 -0500 From: Michael Richardson To: IETF ROLL Subject: [Roll] roll-rpl-industrial-applicability Message-ID: <24984.1325520966@marajade.sandelman.ca> Content-Type: text/plain; charset=3D"us-ascii" Some comments on draft-phinney-roll-rpl-industrial-applicability-00. I promised myself during the last IETF that I'd read it, and new year's = day was a good to do that. pg4: > A field device that belongs to an instance uses the OF to determine > which DODAG and which Version of that DODAG the device should join. I did not think that the OF would tell us which Version of a DODAG to = use. The version simply increments... I guess if the new values from the new version do not satisfy the OF, one could stay with the previously = calculated parents, etc. I was very pleased to read section 3.1. Deployment scenarii. In it, 6 scenarios are described: P1: Construction or major modification phase P2: Planned startup phase P3: Normal operation phase P4: Planned shutdown phase P5: Plant decommissioning phase. P6: Post-emergency recovery and repair phase. The analysis that follows concerns me: > The deployment scenarios for wireless LLN devices may be different = in > each of these phases. In particular, during the Construction or > major modification phase (P1), LLN devices may be installed months > before the intended LLN can become usefully operational (because > needed routers and infrastructure devices are not yet installed or > active), and there are likely to be many personnel in whom the plant > owner/operator has only limited trust, such as subcontractors and > others in the plant area who have undergone only a cursory = background > investigation (if any at all). In general, during this phase, plant I very much wish that this had appeared in RFC5673 as input into the security mechanism. I think that a major limitation in the current documents in the security area here. I could go on awhile about how I = think things should work to solve this; I didn't do that before, because I = didn't think that there was real requirements for a system a flexible as I envision. =20 NOTE: this is not a fault of this document, it's a failure of our requirements process for security. draft-phinney-roll-rpl-industrial-applicability-00 recaps too many = things, and I find is way too chatty. I expect an applicability statement to be more to the point. This relates to section 3 mostly, I think. The chart in section 3.3: +---------------------+------------------------------------------------+ | Phase \ Class | 0 1 2 3 4 5 | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Construction | X X X X | +---------------------+------------------------------------------------+ | Planned startup | X X X X | +---------------------+------------------------------------------------+ | Normal operation | ? ? ? | +---------------------+------------------------------------------------+ | Planned shutdown | X X X X | +---------------------+------------------------------------------------+ |Plant decommissioning| X X X X | +---------------------+------------------------------------------------+ | Recovery and repair | X X X X X X | +---------------------+------------------------------------------------+ also is of concern. What it says is that RPL can't be used for=20 * Class 0: Emergency action - Always a critical function * Class 1: Closed loop regulatory control - Often a critical function * Class 2: Closed loop supervisory control - Usually non-critical function during any phase, except during repair. And, that we don't even know if = it can be used for Normal operation! That's hardly an huge endorsement! Thank you kindly for this -00 document. I realize that section 5 is = where the meat will go, and I look forward to some clear recommendations here. --=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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: not available URL: ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 48, Issue 1 *********************************** From pthubert@cisco.com Tue Jan 17 07:41:57 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0805C21F855B for ; Tue, 17 Jan 2012 07:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.338 X-Spam-Level: X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzO9M9377mzl for ; Tue, 17 Jan 2012 07:41:56 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 597D021F8557 for ; Tue, 17 Jan 2012 07:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8196; q=dns/txt; s=iport; t=1326814915; x=1328024515; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=dgAnnRCOHiaGjE24lHKfevXyH1Sg0059IBY8GrA3nGg=; b=L720Vo7FOIY2MKWyk6QL0w+3tPmqctQigswZrmlDCR/qVrcpSPZ2rKsf Cg1ko/RKyJp2wa+U5nFhzJUIpM6sjKq2onBf+RgPGm+ICixpvDY1A3qzB AAgNJZesZhHkvyUHD43rGbBnW1rVMqNi42zZqGNit6u6de21orB43hwQM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAE2VFU+Q/khM/2dsb2JhbABErD+BBoEFgXIBAQEDAQEBAQ8BHR4gEAcEAgEGAhEDAQEBCwIBAxcBBgEbCwoVCQgBAQQBEggBEAQEAYdYCJhRAZEbjSeJFQYPNgEFUAEEBwELAQIBAQgBAQFMCkpIgSBXCQgFAQEBAoJHYwSGcpoAhmE X-IronPort-AV: E=Sophos;i="4.71,523,1320624000"; d="scan'208";a="63855019" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 17 Jan 2012 15:41:54 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0HFfsRI001555; Tue, 17 Jan 2012 15:41:54 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 16:41:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2012 16:40:30 +0100 Message-ID: In-Reply-To: <1de4401ccd522$a87b9ee0$f972dca0$@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Roll Digest, Vol 48, Issue 1 - roll-rpl-industrial-applicability Thread-Index: AczVImJYMExAuJjkTziXDbPzYA8YmgACyIaQ References: <1de4401ccd522$a87b9ee0$f972dca0$@gmail.com> From: "Pascal Thubert (pthubert)" To: "amit" , X-OriginalArrivalTime: 17 Jan 2012 15:41:54.0119 (UTC) FILETIME=[89A1B570:01CCD52E] Subject: Re: [Roll] Roll Digest, Vol 48, Issue 1 - roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jan 2012 15:41:57 -0000 Hello Amit In practice, as of today, the main standards in the industrial space = rely on L2 security that is set up during a join process.=20 ISA100.11a that also has our traditional upper layers uses the same = crypto at L2 and L4 but has no L3 security. This enables to reuse = hardware support that is available in common chipsets. The RPL draft provides for securing its own when L2 security is not in = place but I do not see that in use in industrial space any time soon. Was that your questions? Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = amit Sent: mardi 17 janvier 2012 15:17 To: roll@ietf.org Subject: [Roll] Roll Digest, Vol 48,Issue 1 - = roll-rpl-industrial-applicability Regarding your security comment, don=92t you think that the basic = assumption of the RPL draft that the devices are trusted, is = problematic. Moreover, roll-rpl-industrial-applicability consider the = case that other layers will take care about the security (section 5.3), = however, counting on upper layer can't solve security problems of the = RPL parameters and the link layer can't be trusted when node can be = compromise.=20 I know that compromise is out of the scope but maybe we need to start = thinking about those cases. -----=E4=E5=E3=F2=E4 =EE=F7=E5=F8=E9=FA----- =EE=E0=FA: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] = =E1=F9=ED roll-request@ietf.org =F0=F9=EC=E7: =E9=E5=ED=A0=E1 02 =E9=F0=E5=E0=F8 2012 22:00 =E0=EC: roll@ietf.org =F0=E5=F9=E0: Roll Digest, Vol 48, Issue 1 If you have received this digest without all the individual message = attachments you will need to update your digest options in your list = subscription. To do so, go to=20 https://www.ietf.org/mailman/listinfo/roll Click the 'Unsubscribe or edit options' button, log in, and set "Get = MIME or Plain Text Digests?" to MIME. You can set this option globally = for all the list digests you receive at this point. Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. roll-rpl-industrial-applicability (Michael Richardson) ---------------------------------------------------------------------- Message: 1 Date: Mon, 02 Jan 2012 11:16:06 -0500 From: Michael Richardson To: IETF ROLL Subject: [Roll] roll-rpl-industrial-applicability Message-ID: <24984.1325520966@marajade.sandelman.ca> Content-Type: text/plain; charset=3D"us-ascii" Some comments on draft-phinney-roll-rpl-industrial-applicability-00. I promised myself during the last IETF that I'd read it, and new year's = day was a good to do that. pg4: > A field device that belongs to an instance uses the OF to determine > which DODAG and which Version of that DODAG the device should join. I did not think that the OF would tell us which Version of a DODAG to = use. The version simply increments... I guess if the new values from the new = version do not satisfy the OF, one could stay with the previously = calculated parents, etc. I was very pleased to read section 3.1. Deployment scenarii. In it, 6 scenarios are described: P1: Construction or major modification phase P2: Planned startup phase P3: Normal operation phase P4: Planned shutdown phase P5: Plant decommissioning phase. P6: Post-emergency recovery and repair phase. The analysis that follows concerns me: > The deployment scenarios for wireless LLN devices may be different = in > each of these phases. In particular, during the Construction or > major modification phase (P1), LLN devices may be installed months > before the intended LLN can become usefully operational (because > needed routers and infrastructure devices are not yet installed or > active), and there are likely to be many personnel in whom the plant > owner/operator has only limited trust, such as subcontractors and > others in the plant area who have undergone only a cursory = background > investigation (if any at all). In general, during this phase, plant I very much wish that this had appeared in RFC5673 as input into the = security mechanism. I think that a major limitation in the current = documents in the security area here. I could go on awhile about how I = think things should work to solve this; I didn't do that before, because = I didn't think that there was real requirements for a system a flexible as I envision. =20 NOTE: this is not a fault of this document, it's a failure of our requirements process for security. draft-phinney-roll-rpl-industrial-applicability-00 recaps too many = things, and I find is way too chatty. I expect an applicability = statement to be more to the point. This relates to section 3 mostly, I = think. The chart in section 3.3: +---------------------+------------------------------------------------+ | Phase \ Class | 0 1 2 3 4 5 | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Construction | X X X X | +---------------------+------------------------------------------------+ | Planned startup | X X X X | +---------------------+------------------------------------------------+ | Normal operation | ? ? ? | +---------------------+------------------------------------------------+ | Planned shutdown | X X X X | +---------------------+------------------------------------------------+ |Plant decommissioning| X X X X | +---------------------+------------------------------------------------+ | Recovery and repair | X X X X X X | +---------------------+------------------------------------------------+ also is of concern. What it says is that RPL can't be used for=20 * Class 0: Emergency action - Always a critical function * Class 1: Closed loop regulatory control - Often a critical function * Class 2: Closed loop supervisory control - Usually non-critical function during any phase, except during repair. And, that we don't even know if = it can be used for Normal operation! That's hardly an huge endorsement! Thank you kindly for this -00 document. I realize that section 5 is = where the meat will go, and I look forward to some clear recommendations = here. --=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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: not available URL: ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 48, Issue 1 *********************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Jan 17 07:49:53 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D230D21F85C0 for ; Tue, 17 Jan 2012 07:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.483 X-Spam-Level: X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13psKFDLigk7 for ; Tue, 17 Jan 2012 07:49:53 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5408421F857F for ; Tue, 17 Jan 2012 07:49:53 -0800 (PST) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 985C034466 for ; Tue, 17 Jan 2012 10:47:47 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2DB029845D; Tue, 17 Jan 2012 10:49:48 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 28A8F98147 for ; Tue, 17 Jan 2012 10:49:48 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <1de4401ccd522$a87b9ee0$f972dca0$@gmail.com> References: <1de4401ccd522$a87b9ee0$f972dca0$@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 17 Jan 2012 10:49:48 -0500 Message-ID: <29348.1326815388@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] roll-rpl-industrial-applicability comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jan 2012 15:49:53 -0000 --=-=-= "security comment' extracted from original email below. What I see is that the LLN (I say this because it might be more than RPL) needs to be able to provide a variety of security services over the lifetime of the LLN. In particular it seems to me that the LLN needs to provide a relatively trivial security system during initial building of the plant. By this, I mean, very trivial to configure, perhaps involving well known "secret"s, not necessarily weak encryption. In fact, you want to do all the testing with the full key strength so that if there are cryptographic related performance problems they show up immediately. You disclose nothing useful to the untrusted contractors who install things as they configure the system using the maint/field password. (To recall the situation of VAX/VMS in the 1980s) Then, the plant has to be "upgraded" to full security, and this has to be done easily by internal personnel. This means that the upgrade has to be performed using standard protocols, physical interfaces and user interfaces! There is a risk, of course, that the plant will go into production with the factory default passwords. I want to further point out that in many places, some part of the plant is ALWAYS under going maintenance, and so the LLN has to be able to deal with multiple security simultaenous security regimes. Can the current Layer-2 solutions deal with this? I know that 802.1x/EAP protocols support it, but in the field, it's either unimplemented, or too hard to support. Can Zigbee's security model? What we need to do, I think, is to realize that we have to have some coupling of layer-2 and layer-3 security services. Too much is bad, but we need at least channel binding. >>>>> "amit" == amit writes: amit> Regarding your security comment, don't you think that the amit> basic assumption of the RPL draft that the devices are amit> trusted, is problematic. Moreover, amit> roll-rpl-industrial-applicability consider the case that other amit> layers will take care about the security (section 5.3), amit> however, counting on upper layer can't solve security problems amit> of the RPL parameters and the link layer can't be trusted when amit> node can be compromise. I know that compromise is out of the amit> scope but maybe we need to start thinking about those cases. mcr> The analysis that follows concerns me: mcr> The deployment scenarios for wireless LLN devices may be mcr> different in each of these phases. In particular, during the mcr> Construction or major modification phase (P1), LLN devices may be mcr> installed months before the intended LLN can become usefully mcr> operational (because needed routers and infrastructure devices mcr> are not yet installed or active), and there are likely to be many mcr> personnel in whom the plant owner/operator has only limited mcr> trust, such as subcontractors and others in the plant area who mcr> have undergone only a cursory background investigation (if any at mcr> all). In general, during this phase, plant --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUATxWYnIqHRg3pndX9AQKu/QQAx69GFALmBJMvWVVmyRaT5xaNb4p8dF50 8pVAKkYX1FZxNd8XKLl/NvC/3r04phxIrNOb9MlBGb7QFHiS27uqH8ehQ5Up7aVv QUjGujR2D4XhnCXOCX6Yc0/8nIhebeNc35Mhz68FOqPe3HfZpWYVbE138r8CAtxb oJx4RNKGWgQ= =kM0v -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Jan 17 09:36:57 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3821F84B2 for ; Tue, 17 Jan 2012 09:36:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf2Hg0zGDzQb for ; Tue, 17 Jan 2012 09:36:57 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 902EC21F8498 for ; Tue, 17 Jan 2012 09:36:56 -0800 (PST) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 4876D34474; Tue, 17 Jan 2012 12:34:52 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2EAEB9845D; Tue, 17 Jan 2012 12:36:53 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 1D63F98147; Tue, 17 Jan 2012 12:36:53 -0500 (EST) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: References: <1de4401ccd522$a87b9ee0$f972dca0$@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 17 Jan 2012 12:36:52 -0500 Message-ID: <17121.1326821812@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: amit , roll@ietf.org Subject: Re: [Roll] Roll Digest, Vol 48, Issue 1 - roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jan 2012 17:36:57 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> Was that your questions? Amit was responding to my email, wherein I noted that our security features do not in fact meet the expectations of the industrial applicability statement. Nor, as far as I can see, do layer-2 mechanisms help at all, as they provide no way to limit trust to subcontractors. They are boolean (you either have the network key, or you do not). > The analysis that follows concerns me: >> The deployment scenarios for wireless LLN devices may be >> different in each of these phases. In particular, during the >> Construction or major modification phase (P1), LLN devices may be >> installed months before the intended LLN can become usefully >> operational (because needed routers and infrastructure devices >> are not yet installed or active), and there are likely to be many >> personnel in whom the plant owner/operator has only limited >> trust, such as subcontractors and others in the plant area who >> have undergone only a cursory background investigation (if any at >> all). In general, during this phase, plant > I very much wish that this had appeared in RFC5673 as input > into the security mechanism. I think that a major > limitation in the current documents in the security area > here. From adrian@olddog.co.uk Thu Jan 19 05:09:35 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08A121F85FF for ; Thu, 19 Jan 2012 05:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDIIGjVP9dnA for ; Thu, 19 Jan 2012 05:09:35 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id F242F21F85CD for ; Thu, 19 Jan 2012 05:09:33 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0JD9WGV017979 for ; Thu, 19 Jan 2012 13:09:32 GMT Received: from 950129200 ([195.43.57.40]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0JD9Smc017955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Jan 2012 13:09:31 GMT From: "Adrian Farrel" To: References: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net> In-Reply-To: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net> Date: Thu, 19 Jan 2012 13:09:26 -0000 Message-ID: <018201ccd6ab$9628a6e0$c279f4a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGIGc8x5e5FgzvuP5ruMo4T0hoDT5adIaQA Content-Language: en-gb Subject: [Roll] FW: Smart Object Security Workshop Announcement X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 13:09:35 -0000 I am unclear as to why this announcement was not also sent to the ROLL working group, but I have no objection to you knowing about it :-) Cheers, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > Sent: 19 January 2012 10:22 > To: IETF-Discussion list > Subject: Smart Object Security Workshop Announcement > > Hi all, > > we would like to make you aware of a workshop on Smart Object Security on the > 23rd March 2012 in Paris (attached to the IETF meeting). > > We are seeking input from participants to share their thoughts about the ability > to utilize existing and widely deployed security mechanisms for smart objects. > > In particular, we are interested to hear about: > . What techniques for issuing credentials have been deployed? > . What extensions are useful to make existing security protocols more > suitable for smart objects? > . What type of credentials are frequently used? > . What experience has been gained when implementing and deploying > application layer, transport layer, network layer, and link layer security > mechanisms (or a mixture of all of them)? > . How can "clever" implementations make security protocols a better fit > for constrained devices? > . Are there lessons we can learn from existing deployments? > > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ > > If you plan to participate at the workshop please drop us a message (with a short > description of what you are planning to contribute) and we can give you an early > notice regarding your participation. > > Greetings > The Workshop Organizers > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From internet-drafts@ietf.org Thu Jan 19 07:50:35 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BA121F863F; Thu, 19 Jan 2012 07:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pEOSmJmsZ48; Thu, 19 Jan 2012 07:50:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B4221F8573; Thu, 19 Jan 2012 07:50:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120119155021.32532.97987.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2012 07:50:21 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Jan 2012 15:50:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-06.txt Pages : 27 Date : 2012-01-19 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover and establish, on demand, a route to another IPv6 router in the LLN such that the discovered route meets specified metrics constraints, without necessarily going along the DAG links established by core RPL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-06.txt From prvs=358905b19=mukul@uwm.edu Thu Jan 19 09:08:16 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE89721F863F for ; Thu, 19 Jan 2012 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2BoC4CNUTKz for ; Thu, 19 Jan 2012 09:08:15 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id D0E4A21F8572 for ; Thu, 19 Jan 2012 09:08:15 -0800 (PST) Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip1mta.uwm.edu with ESMTP; 19 Jan 2012 11:08:12 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 05EBD12E3D0 for ; Thu, 19 Jan 2012 11:08:13 -0600 (CST) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVhRVagQwlwB for ; Thu, 19 Jan 2012 11:08:11 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D266212E3D2 for ; Thu, 19 Jan 2012 11:08:11 -0600 (CST) Date: Thu, 19 Jan 2012 11:08:11 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <173526495.942408.1326992891757.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120119155021.32532.97987.idtracker@ietfa.amsl.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 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Jan 2012 17:08:16 -0000 Hi all This version of the draft is the result of extensive testing with two P2P-RPL implementations (by INRIA and Sigma Design) and a thorough review by the authors and implementors. I will be posting the main differences over the previous version shortly. We (the authors) think that we are done with the draft and it is ready for the last call. Kindly review this draft and let me know if you would like to see any changes before the last call begins. I will be requesting a last call on this draft in a week or so. Hopefully, this will give enough time for people to send comments. Thanks Mukul ----- Forwarded Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Thursday, January 19, 2012 9:50:21 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-06.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 : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-06.txt Pages : 27 Date : 2012-01-19 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover and establish, on demand, a route to another IPv6 router in the LLN such that the discovered route meets specified metrics constraints, without necessarily going along the DAG links established by core RPL. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-06.txt _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=35965d075=mukul@uwm.edu Thu Jan 19 19:05:21 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE54E21F85BB for ; Thu, 19 Jan 2012 19:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH9YWv3VvRXQ for ; Thu, 19 Jan 2012 19:05:21 -0800 (PST) Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0631C21F8598 for ; Thu, 19 Jan 2012 19:04:27 -0800 (PST) Received: from localhost (HELO mta04.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 19 Jan 2012 21:04:26 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 790E42B3EC3 for ; Thu, 19 Jan 2012 21:02:20 -0600 (CST) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuYS42tCfb3N for ; Thu, 19 Jan 2012 21:02:20 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 402082B3EC2 for ; Thu, 19 Jan 2012 21:02:20 -0600 (CST) Date: Thu, 19 Jan 2012 21:04:26 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <788248661.950837.1327028666290.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2140773132.950289.1327023602900.JavaMail.root@mail17.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 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Changes in p2p-rpl-06 over p2p-rpl-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Jan 2012 03:05:21 -0000 Here is a summary of the changes in p2p-rpl-06 over p2p-rpl-05: 1. Introduced a new Mode of Operation - P2P Route Discovery Mode. DIOs in P2P-RPL MUST use this MOP. This ensures that RPL routers that do not understand P2P-RPL may only join as leaf nodes in the temporary DAGs used in P2P-RPL and do not inadvertently participate in a P2P-RPL route discovery. 2. Specified a default DODAG Configuration Option that comes in effect if the P2P mode DIO does not include an explicit one. 3. Replaced "Rem" field in P2P Route Discovery Option with "MaxRank/NH" field: a) Rem field was used to indicate the number of empty slots in the Address vector. We thought that it would be possible for a node to simply modify a received DIO and transmit it. But, later on, we realized that since a DIO transmission is triggered by the Trickle timer firing, a router would have to always create a new DIO packet. Thus, there was no point any more in carrying empty slots in the Address vector. So, we replaced "Rem" field with a "MaxRank/NH" field. b) The "MaxRank/NH" field serves as the MaxRank when the P2P Route Discovery Option is carried inside a DIO. This field can be used to specify a constraint on the max rank that a router can have in the temporary DAG being used for a P2P-RPL route discovery. This field provides a way to specify a constraint without including a Metric Container. This field is particularly useful if OF0 (which does not use RPL routing metrics) is the objective function in use. Now, a P2P mode DIO, using OF0 as the OF, can avoid including a Metric Container (and thus save some bytes). c) The "MaxRank/NH" field serves as the "NH(Next Hop)" field when the P2P Route Discovery Option is carried inside a DRO. This field indicates the index of the next hop address inside the Address vector. 4. Clarified that all routers participating in a P2P-RPL route discovery, including the origin and the target MUST join the temporary DAG being created for the purpose. 5. Changes to how "Consistent/Inconsistent" events are defined for Trickle operation in P2P-RPL: a) New rule: The receipt of a P2P mode DIO from a parent in the temporary DAG is considered neither "consistent" nor "inconsistent" if it does not allow the router to advertise a better route than before. In the absence of this rule, a router was suppressing its DIO because it received a "consistent" DIO from its parent. (The redundancy constant was 1). This was hampering the route discovery. b) Clarified that the Imin parameter SHOULD be set taking in account the connectivity within the network. A small Imin value in a highly connected LLN could cause a DIO storm. This is because the first receipt of a DIO about a temporary DAG is treated as an inconsistent event and would cause the Trickle timer to reset to Imin. c) Clarified that Imax should be set to a large value so that it is not a factor in the Trickle operation during the limited life of the temporary DAG. d) Clarified that redundancy constant should be set to a value larger than 1 if packet loss rates are high. For moderate/low packet loss rates, the redundancy constant should be 1 to avoid unnecessary DIO generation. 6. Specified that a received P2P mode DIO must be dropped if the advertized rank is INFINITE_RANK (so any DIO advertized by a non-P2P-RPL router, that joined the temporary DAG as a leaf, would be dropped) or more than the MaxRank. 7. Added a section on interoperability with core RPL. Thanks Mukul From emmanuel.baccelli@gmail.com Fri Jan 20 02:44:44 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7187321F8576 for ; Fri, 20 Jan 2012 02:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO0ibw3JBr24 for ; Fri, 20 Jan 2012 02:44:43 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D53E121F8589 for ; Fri, 20 Jan 2012 02:44:42 -0800 (PST) Received: by qcsc1 with SMTP id c1so263469qcs.31 for ; Fri, 20 Jan 2012 02:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=qREYXlZC6KFHK5x6NWG0Zy8z1kGyOTrVUh81PaHDRLA=; b=JToZ2r9vExjZqYxTwqRJbbAvcQlg6vfuLuR0w/5OKQ+m8ZpKwvIu8zepklIZFetzEH zamW9GbqCkHoTSVXy3+Qdag6iIHsXHyWOuOm19wHaaGnbWlFkOaa2sGAKfVQ0sRbBAGK W/tcz2FkVnnBWghohg1nQGZ5acJuGxLqag7w8= Received: by 10.229.76.149 with SMTP id c21mr10841015qck.5.1327056282280; Fri, 20 Jan 2012 02:44:42 -0800 (PST) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.230.83 with HTTP; Fri, 20 Jan 2012 02:44:21 -0800 (PST) In-Reply-To: <1185055681.338580.1327028730983.JavaMail.root@zmbs1.inria.fr> References: <2140773132.950289.1327023602900.JavaMail.root@mail17.pantherlink.uwm.edu> <1185055681.338580.1327028730983.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Fri, 20 Jan 2012 11:44:21 +0100 X-Google-Sender-Auth: Ly6z0lkBe28ZqaRYFMdywCCD9K8 Message-ID: To: ROLL WG Content-Type: multipart/alternative; boundary=00235429e34c4d64f004b6f35ef9 Subject: Re: [Roll] Changes in p2p-rpl-06 over p2p-rpl-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Jan 2012 10:44:44 -0000 --00235429e34c4d64f004b6f35ef9 Content-Type: text/plain; charset=ISO-8859-1 Dear all, as mentioned by Mukul in his previous mail, the changes from -05 to -06 were prompted by the results of the latest P2P-RPL interop. This interop was carried out last month with INRIA's implementation against Sigma Design's implementation, and a report is available here http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf Experiments with P2P-RPL have also taken place on the Senslab testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz, see for instance the experiments documented in http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf The INRIA implementation is available upon request. Best regards, Emmanuel http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf On Fri, Jan 20, 2012 at 4:05 AM, Mukul Goyal wrote: > Here is a summary of the changes in p2p-rpl-06 over p2p-rpl-05: > > 1. Introduced a new Mode of Operation - P2P Route Discovery Mode. DIOs in > P2P-RPL MUST use this MOP. This ensures that RPL routers that do not > understand P2P-RPL may only join as leaf nodes in the temporary DAGs used > in P2P-RPL and do not inadvertently participate in a P2P-RPL route > discovery. > > 2. Specified a default DODAG Configuration Option that comes in effect if > the P2P mode DIO does not include an explicit one. > > 3. Replaced "Rem" field in P2P Route Discovery Option with "MaxRank/NH" > field: > > a) Rem field was used to indicate the number of empty slots in the Address > vector. We thought that it would be possible for a node to simply modify a > received DIO and transmit it. But, later on, we realized that since a DIO > transmission is triggered by the Trickle timer firing, a router would have > to always create a new DIO packet. Thus, there was no point any more in > carrying empty slots in the Address vector. So, we replaced "Rem" field > with a "MaxRank/NH" field. > > b) The "MaxRank/NH" field serves as the MaxRank when the P2P Route > Discovery Option is carried inside a DIO. This field can be used to specify > a constraint on the max rank that a router can have in the temporary DAG > being used for a P2P-RPL route discovery. This field provides a way to > specify a constraint without including a Metric Container. This field is > particularly useful if OF0 (which does not use RPL routing metrics) is the > objective function in use. Now, a P2P mode DIO, using OF0 as the OF, can > avoid including a Metric Container (and thus save some bytes). > > c) The "MaxRank/NH" field serves as the "NH(Next Hop)" field when the P2P > Route Discovery Option is carried inside a DRO. This field indicates the > index of the next hop address inside the Address vector. > > 4. Clarified that all routers participating in a P2P-RPL route discovery, > including the origin and the target MUST join the temporary DAG being > created for the purpose. > > 5. Changes to how "Consistent/Inconsistent" events are defined for Trickle > operation in P2P-RPL: > a) New rule: The receipt of a P2P mode DIO from a parent in the temporary > DAG > is considered neither "consistent" nor "inconsistent" if it does > not allow the router to advertise a better route than before. > In the absence of this rule, a router was suppressing its DIO because it > received a "consistent" DIO from its parent. (The redundancy constant was > 1). This was hampering the route discovery. > > b) Clarified that the Imin parameter SHOULD be set taking in account the > connectivity within the network. A small Imin value in a highly connected > LLN could cause a DIO storm. This is because the first receipt of a DIO > about a temporary DAG is treated as an inconsistent event and would cause > the Trickle timer to reset to Imin. > > c) Clarified that Imax should be set to a large value so that it is not a > factor in the Trickle operation during the limited life of the temporary > DAG. > > d) Clarified that redundancy constant should be set to a value larger than > 1 if packet loss rates are high. For moderate/low packet loss rates, the > redundancy constant should be 1 to avoid unnecessary DIO generation. > > 6. Specified that a received P2P mode DIO must be dropped if the > advertized rank is INFINITE_RANK (so any DIO advertized by a non-P2P-RPL > router, that joined the temporary DAG as a leaf, would be dropped) or more > than the MaxRank. > > 7. Added a section on interoperability with core RPL. > > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00235429e34c4d64f004b6f35ef9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,

as mentioned by Mukul in his previous mail, th= e changes from -05 to -06 were prompted by the results of the latest P2P-RP= L interop.=A0This interop was carried out last month with INRIA's imple= mentation against Sigma Design's implementation, and a report is availa= ble here h= ttp://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf

Experiments with P2P-RPL have also taken place on the S= enslab testbed gathering boards based on MSP430 and 802.15.4 at 2.4GHz, see= for instance the experiments documented in=A0http://hal.archives-ou= vertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf

The INRIA implementation is available upon request.=A0<= /div>

Best regards,

Emmanuel









http://hal.inria.fr/docs/0= 0/66/16/29/PDF/RR-7864.pdf

On Fri, Ja= n 20, 2012 at 4:05 AM, Mukul Goyal <mukul@uwm.edu> wrote:
Here= is a summary of the changes in p2p-rpl-06 over p2p-rpl-05:

1. Introduced a new Mode of Operation - P2P Route Discovery Mode. DIOs in P= 2P-RPL MUST use this MOP. This ensures that RPL routers that do not underst= and P2P-RPL may only join as leaf nodes in the temporary DAGs used in P2P-R= PL and do not inadvertently participate in a P2P-RPL route discovery.

2. Specified a default DODAG Configuration Option that comes in effect if t= he P2P mode DIO does not include an explicit one.

3. Replaced "Rem" field in P2P Route Discovery Option with "= MaxRank/NH" field:

a) Rem field was used to indicate the number of empty slots in the Address = vector. We thought that it would be possible for a node to simply modify a = received DIO and transmit it. But, later on, we realized that since a DIO t= ransmission is triggered by the Trickle timer firing, a router would have t= o always create a new DIO packet. Thus, there was no point any more in carr= ying empty slots in the Address vector. So, we replaced "Rem" fie= ld with a "MaxRank/NH" field.

b) The "MaxRank/NH" field serves as the MaxRank when the P2P Rout= e Discovery Option is carried inside a DIO. This field can be used to speci= fy a constraint on the max rank that a router can have in the temporary DAG= being used for a P2P-RPL route discovery. This field provides a way to spe= cify a constraint without including a Metric Container. This field is parti= cularly useful if OF0 (which does not use RPL routing metrics) is the objec= tive function in use. Now, a P2P mode DIO, using OF0 as the OF, can avoid i= ncluding a Metric Container (and thus save some bytes).

c) The "MaxRank/NH" field serves as the "NH(Next Hop)" = field when the P2P Route Discovery Option is carried inside a DRO. This fie= ld indicates the index of the next hop address inside the Address vector.
4. Clarified that all routers participating in a P2P-RPL route discovery, i= ncluding the origin and the target MUST join the temporary DAG being create= d for the purpose.

5. Changes to how "Consistent/Inconsistent" events are defined fo= r Trickle operation in P2P-RPL:
a) New rule: The receipt of a P2P mode DIO from a parent in the temporary D= AG
=A0 =A0 =A0is considered neither "consistent" nor "inconsis= tent" if it does
=A0 =A0 =A0not allow the router to advertise a better route than before. In the absence of this rule, a router was suppressing its DIO because it re= ceived a "consistent" DIO from its parent. (The redundancy consta= nt was 1). This was hampering the route discovery.

b) Clarified that the Imin parameter SHOULD be set taking in account the co= nnectivity within the network. A small Imin value in a highly connected LLN= could cause a DIO storm. This is because the first receipt of a DIO about = a temporary DAG is treated as an inconsistent event and would cause the Tri= ckle timer to reset to Imin.

c) Clarified that Imax should be set to a large value so that it is not a f= actor in the Trickle operation during the limited life of the temporary DAG= .

d) Clarified that redundancy constant should be set to a value larger than = 1 if packet loss rates are high. For moderate/low packet loss rates, the re= dundancy constant should be 1 to avoid unnecessary DIO generation.

6. Specified that a received P2P mode DIO must be dropped if the advertized= rank is INFINITE_RANK (so any DIO advertized by a non-P2P-RPL router, that= joined the temporary DAG as a leaf, would be dropped) or more than the Max= Rank.

7. Added a section on interoperability with core RPL.

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

--00235429e34c4d64f004b6f35ef9-- From emmanuel.baccelli@gmail.com Fri Jan 20 02:51:22 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AD621F860E for ; Fri, 20 Jan 2012 02:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JawO5H44c+E6 for ; Fri, 20 Jan 2012 02:51:21 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D94121F85DB for ; Fri, 20 Jan 2012 02:51:21 -0800 (PST) Received: by qady23 with SMTP id y23so296892qad.10 for ; Fri, 20 Jan 2012 02:51:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=uoVEEhdd2Rdz6/bQDPO9mu9pPFJCAmTnYzvkBqjyujQ=; b=oBX+cQf8yNKH4lSbiGin+NT+SwgZHnlW3zXvxhg6uS+XbsFDm5ok5HcIMdwFVKuc/3 iBt9Tm923fZxusmP5N/cNiX0BI8erZ23li5pkzCK+nk0/oCV2EfG+D+PGnWM2dBavylu AKaDmCQx9HZuIRA57b/BEyUvKoATH66rreCks= Received: by 10.224.174.71 with SMTP id s7mr32138386qaz.4.1327056680632; Fri, 20 Jan 2012 02:51:20 -0800 (PST) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.230.83 with HTTP; Fri, 20 Jan 2012 02:50:59 -0800 (PST) In-Reply-To: <1848827675.336382.1326992905151.JavaMail.root@zmbs1.inria.fr> References: <20120119155021.32532.97987.idtracker@ietfa.amsl.com> <1848827675.336382.1326992905151.JavaMail.root@zmbs1.inria.fr> From: Emmanuel Baccelli Date: Fri, 20 Jan 2012 11:50:59 +0100 X-Google-Sender-Auth: GCXLlRshDVBH9N73zxg0FG0b0XM Message-ID: To: roll Content-Type: multipart/alternative; boundary=20cf30334c930bc31604b6f37674 Subject: Re: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-rpl-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Jan 2012 10:51:22 -0000 --20cf30334c930bc31604b6f37674 Content-Type: text/plain; charset=ISO-8859-1 Dear all, indeed, please do send us your comments/nits at this point (i.e. do not wait for any upcoming last call ;). Cheers, Emmanuel On Thu, Jan 19, 2012 at 6:08 PM, Mukul Goyal wrote: > Hi all > > This version of the draft is the result of extensive testing with two > P2P-RPL implementations (by INRIA and Sigma Design) and a thorough review > by the authors and implementors. I will be posting the main differences > over the previous version shortly. > > We (the authors) think that we are done with the draft and it is ready for > the last call. > > Kindly review this draft and let me know if you would like to see any > changes before the last call begins. I will be requesting a last call on > this draft in a week or so. Hopefully, this will give enough time for > people to send comments. > > Thanks > Mukul > > ----- Forwarded Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Sent: Thursday, January 19, 2012 9:50:21 AM > Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-06.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 : Reactive Discovery of Point-to-Point Routes in > Low Power and Lossy Networks > Author(s) : Mukul Goyal > Emmanuel Baccelli > Matthias Philipp > Anders Brandt > Jerald Martocci > Filename : draft-ietf-roll-p2p-rpl-06.txt > Pages : 27 > Date : 2012-01-19 > > This document specifies a point-to-point route discovery mechanism, > complementary to the RPL core functionality. This mechanism allows > an IPv6 router to discover and establish, on demand, a route to > another IPv6 router in the LLN such that the discovered route meets > specified metrics constraints, without necessarily going along the > DAG links established by core RPL. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-06.txt > > _______________________________________________ > 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 > --20cf30334c930bc31604b6f37674 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,
indeed, please do send us your comments/nits at this point (i= .e. do not wait for any upcoming last call ;).
Cheers,
= Emmanuel

On Thu, Jan 19, 2012 at 6:08 PM,= Mukul Goyal <mukul@u= wm.edu> wrote:
Hi all

This version of the draft is the result of extensive testing with two P2P-R= PL implementations (by INRIA and Sigma Design) and a thorough review by the= authors and implementors. I will be posting the main differences over the = previous version shortly.

We (the authors) think that we are done with the draft and it is ready for = the last call.

Kindly review this draft and let me know if you would like to see any chang= es before the last call begins. I will be requesting a last call on this dr= aft in a week or so. Hopefully, this will give enough time for people to se= nd comments.

Thanks
Mukul

----- Forwarded Message -----
From: internet-drafts@ietf.org<= /a>
To: i-d-announce@ietf.org
Cc: roll@ietf.org
Sent: Thursday, January 19, 2012 9:50:21 AM
Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-06.txt


A New Internet-Draft is avail= able from the on-line Internet-Drafts directories. This draft is a work ite= m of the Routing Over Low power and Lossy networks Working Group of the IET= F.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Reactive Discovery of Point-to-= Point Routes in Low Power and Lossy Networks
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mukul Goyal
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Emmanuel Baccelli
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Matthias Philipp
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Anders Brandt
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jerald Martocci
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-roll-p2p-rpl-06.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 27
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-19

=A0 This document specifies a point-to-point route discovery mechanism, =A0 complementary to the RPL core functionality. =A0This mechanism allows<= br> =A0 an IPv6 router to discover and establish, on demand, a route to
=A0 another IPv6 router in the LLN such that the discovered route meets =A0 specified metrics constraints, without necessarily going along the
=A0 DAG links established by core RPL.


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

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p= -rpl-06.txt

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

--20cf30334c930bc31604b6f37674-- From e.mingozzi@iet.unipi.it Wed Jan 25 06:07:49 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62C921F85D5 for ; Wed, 25 Jan 2012 06:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.03 X-Spam-Level: ** X-Spam-Status: No, score=2.03 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hvAix3mJQ6m for ; Wed, 25 Jan 2012 06:07:45 -0800 (PST) Received: from smtp.ing.unipi.it (smtp.ing.unipi.it [131.114.28.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8200821F85C0 for ; Wed, 25 Jan 2012 06:07:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ing.unipi.it (Postfix) with ESMTP id E1CEC7C0A6; Wed, 25 Jan 2012 15:07:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at smtp.ing.unipi.it Received: from smtp.ing.unipi.it ([127.0.0.1]) by localhost (smtp.ing.unipi.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS8-5pf+i1zu; Wed, 25 Jan 2012 15:07:42 +0100 (CET) Received: from mingozziPC (cng4.iet.unipi.it [131.114.58.100]) (Authenticated sender: a009395) by smtp.ing.unipi.it (Postfix) with ESMTPSA id B2EEC7C099; Wed, 25 Jan 2012 15:07:42 +0100 (CET) From: "Enzo Mingozzi" To: Date: Wed, 25 Jan 2012 15:08:08 +0100 Organization: University of Pisa Message-ID: <001501ccdb6a$c3f680b0$4be38210$@mingozzi@iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczac3AoK/QpUJt0RGaXiYjsMT7jYg== Content-Language: it Subject: [Roll] IEEE IoT-SoS 2012: call for papers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: e.mingozzi@iet.unipi.it List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:07:49 -0000 ------------------------------------------------------------------------ - Our apologies if you receive multiple copies of this CFP - ------------------------------------------------------------------------ ***** PAPER SUBMISSION DEADLINE ***** FEBRUARY 17, 2012 (11:59pm EST) ------------------------------------------------------------------------ CALL FOR PAPERS IoT-SoS 2012 First IEEE Workshop on the Internet of Things: Smart Objects and Services http://www.ing.unipi.it/iot-sos2012 co-located with IEEE WoWMoM 2012 sponsored by IEEE, IEEE Computer Society June 25, 2012 San Francisco, CA, USA ------------------------------------------------------------------------ The Internet of Things (IoT) is a novel paradigm which is shaping the evolution of the future Internet. According to the vision underlying the IoT, the next step in increasing the ubiquity of the Internet, after connecting people anytime and everywhere, is to connect inanimate objects. By providing objects with embedded communication capabilities and a common addressing scheme, a highly distributed and ubiquitous network of seamlessly connected heterogeneous devices is formed, which can be fully integrated into the current Internet and mobile networks, thus allowing for the development of new intelligent services available anytime, anywhere, by anyone and anything. Such a vision is also becoming known under the name of Machine-to-Machine (M2M), where the absence of human interaction in the system dynamics is further stressed. Many applications with high social and business impact fall under the IoT/M2M umbrella, including personal healthcare, smart grid, surveillance, home automation, intelligent transportation, while it is expected that new ones will emerge once the enabling technologies reach a stable state. At the moment, two of the most important challenges are: i) the definition of architectures, protocols and algorithms for an efficient interconnection of smart objects, both between themselves and with the (Future) Internet; and ii) the creation of value-added services, esp. open and interoperable, enabled by the interconnection of things / machines / smart objects, in such a way that they can be integrated with current and new business and development processes. The aim of this workshop is to bring together practitioners and researchers from both academia and industry in order to have a forum for discussion and technical presentations on the recent advances in theory, application and implementation of the Internet of Things concept: technologies, protocols, algorithms, and services. Topics of interest include, but are not limited to: - System architectures for the IoT/M2M - Communication protocols for the IoT/M2M - Service platforms for the IoT/M2M - Enabling technologies and standards for the IoT/M2M - Mobility management - Context awareness - Sustainable design - Location-based services and geographic information systems - Experimental prototypes and large-scale testbed infrastructures - Performance evaluation of IoT/M2M solutions - Convergence with the Internet of Services - Applications, including: eHealth/mHealth; Smart Grid/Smart Metering; connected consumer; fleet management; surveillance; Intelligent Transportation Systems; Smart House/Neighborhood/City - Business development and processes - Industrial use cases showing gaps to be filled by future research PAPER SUBMISSION AND PUBLICATION All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Papers must be submitted electronically to EDAS by February 17, 2012, 11:59pm EST. You can find detailed submission instructions at http://www.ing.unipi.it/iot-sos2012/submission.shtml. Submission implies the willingness of at least one author to attend the workshop and present the paper. Accepted papers will be included in the main proceedings of IEEE WoWMoM 2012 and published by IEEE. IMPORTANT DATES Manuscripts Due: February 17, 2012. Acceptance Notification: April 6, 2012. Camera-ready Submission: 2nd half April 2012. WORKSHOP CO-CHAIRS Jaudelice Cavalcante de Oliveira, Drexel University, PA, USA. Claudio Cicconetti, INTECS, Italy. Xiaohua Jia, City University of Hong Kong, Hong Kong. Enzo Mingozzi, University of Pisa, Italy. TECHNICAL PROGRAM COMMITTEE (TO BE COMPLETED) Baris Atakan, Georgia Institute of Technology, USA. Biao Chen, University of Macau, Macao. Zixue Cheng, University of Aizu, Japan. Huang Chuanhe, Whuhan University, P.R. China. Thomas Clausen, Ecole Polytechnique, France. Gianni Di Caro, IDSIA, Switzerland. Hongwei Du, Harbin Institute of Technology, P.R. China. Andrzej Duda, Grenoble Institute of Technology, France. Omprakash Gnawali, University of Houston, USA. Mukul Goyal, University of Wisconsin - Milwaukee, USA. Burhan Gulbahar, Koc University, Turkey. Yuan Guo, Wilson, Ham & Holman, USA. Stephan Haller, SAP (Switzerland) Inc., Switzerland. Antonio Iera, University Mediterranea of Reggio Calabria, Italy. Sofoklis Kyriazakos, Aalborg Universitet, Denmark. Antonis Litke, Converge, Greece. Hai Liu, Hong Kong Baptist University, Hong Kong. Alessandro Mamelli, Hewlett-Packard, Italy. Belen Martinez, Tecnalia, Spain. Tommaso Melodia, SUNY at Buffalo, USA. Francisco Javier Nieto De-Santos, ATOS, Spain. Dario Pompili, Rutgers University, USA. Kay Romer, University of Lubeck, Germany. Michele Rossi, University of Padova, Italy. Paul Russell, InterDigital, USA. Enrico Scarrone, Telecom Italia LAB, Italy. Jean-Philippe Vasseur, Cisco Systems, USA. Serdar Vural, University of Surrey, UK. Dexiang Wang, University of Florida, USA. Yan Zhang, Simula Research Laboratory and University of Oslo, Norway. From melvin@amatiscontrols.com Wed Jan 25 11:09:35 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B17C21F855A for ; Wed, 25 Jan 2012 11:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i0Fz20-DPmT for ; Wed, 25 Jan 2012 11:09:32 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA52421F8552 for ; Wed, 25 Jan 2012 11:09:25 -0800 (PST) Received: by wgbed3 with SMTP id ed3so4301603wgb.13 for ; Wed, 25 Jan 2012 11:09:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.99.100 with SMTP id ep4mr30441170wib.7.1327518564792; Wed, 25 Jan 2012 11:09:24 -0800 (PST) Received: by 10.180.92.226 with HTTP; Wed, 25 Jan 2012 11:09:24 -0800 (PST) X-Originating-IP: [184.158.97.239] Date: Wed, 25 Jan 2012 13:09:24 -0600 Message-ID: From: Melvin A To: roll@ietf.org X-Gm-Message-State: ALoCoQl7WpMfI9ouOrctULjO5u4pkcYXxu8Xsc6DQuTQVhXOCGYlW+VUSY4p5T1xgXsfuKp8aD1Q Content-Type: multipart/alternative; boundary=f46d04428e5c7cba4c04b75f000b Subject: [Roll] RPL and extension headers with trickle multicast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Jan 2012 19:09:35 -0000 --f46d04428e5c7cba4c04b75f000b Content-Type: text/plain; charset=ISO-8859-1 I have question regarding the RPL extensions (*draft-ietf-6man-rpl-option-06 *) and trickle multicast (*draft-ietf-roll-trickle-mcast-00*) Both of the documents listed above expects data packets to have very different information in the IPv6 Hop-by-hop option header . The draft-ietf-6man-rpl-option-06* *expects packet direction, RPLInstanceID, etc, whereas draft-ietf-roll-trickle-mcast-00 expects SeedID, Sequence, etc. Are the expectations for a (storing-mode with multicast support RPL implementation) multicast data packet to have two (2) hop-by-hop headers? If the answer to the previous question is "yes" wouldn't that conflict with RFC-2640 Section 4.1 "Each extension header should occur at most once, except for the Destination Options header which should occur at most twice"? If the answer is "no" what are the expectations on what to included in the data messages? Thanks in advance Melvin R Aguirre --f46d04428e5c7cba4c04b75f000b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have question regarding the RPL extensions (draft-ietf-6man-rpl-option= -06) and trickle multicast (draft-ietf-roll-trickle-mcast-00)
Both of the documents listed above expects data packets to have very d= ifferent information in the IPv6 Hop-by-hop option header . The draft-ietf-= 6man-rpl-option-06 expects packet direction, RPLInstanceID, etc, whe= reas draft-ietf-roll-trickle-mcast-00 expects SeedID, Sequence, etc.

Are the expectations for a (storing-mode with multicast support RPL imp= lementation) multicast data packet=A0 to have two (2) hop-by-hop headers? <= br>If the answer to the previous question is "yes" wouldn't t= hat conflict with RFC-2640 Section 4.1 "Each extension header should o= ccur at most once, except for the=A0=A0=A0 Destination Options header which= should occur at most twice"?
If the answer is "no" what are the expectations on what to includ= ed in the data messages?


Thanks in advance
Melvin R Aguirre








--f46d04428e5c7cba4c04b75f000b--

From cedric-2.lavenu@edf.fr  Wed Jan 25 13:02:08 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBED11E80D4 for ; Wed, 25 Jan 2012 13:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.833
X-Spam-Level: 
X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=1.815,  BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2m31fDI2iwp for ; Wed, 25 Jan 2012 13:02:08 -0800 (PST)
Received: from mtagate1.edf.fr (mtagate1.edf.fr [192.54.193.60]) by ietfa.amsl.com (Postfix) with ESMTP id AE8A111E80B9 for ; Wed, 25 Jan 2012 13:02:06 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.71,570,1320620400";  d="scan'208,217";a="353147290"
Received: from unknown (HELO XHUB003AU.notes.edfgdf.fr) ([10.122.19.74]) by CLAF1MTA1.edf.fr with ESMTP; 25 Jan 2012 21:58:16 +0100
Auto-Submitted: auto-generated
From: Cedric-2 LAVENU 
To: roll@ietf.org
Message-ID: 
Date: Wed, 25 Jan 2012 22:02:01 +0100
MIME-Version: 1.0
Content-type: multipart/alternative;  Boundary="0__=4EBBF303DFE00C1B8f9e8a93df938690918c4EBBF303DFE00C1B"
Content-Disposition: inline
Subject: [Roll] Cedric-2 LAVENU est absent(e).
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 25 Jan 2012 21:02:08 -0000

--0__=4EBBF303DFE00C1B8f9e8a93df938690918c4EBBF303DFE00C1B
Content-type: text/plain; charset=US-ASCII


Je serai absent(e) du  24/01/2012 au 30/01/2012.

I will be out of office until january 30th. I will answer your email as soon as possible.
--0__=4EBBF303DFE00C1B8f9e8a93df938690918c4EBBF303DFE00C1B
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline



Je serai absent(e) du  24/01/2012 au 30/01/2012.



I will be out of office until january 30th. I will answer your email as soon as possible.
--0__=4EBBF303DFE00C1B8f9e8a93df938690918c4EBBF303DFE00C1B--


From esko.dijk@philips.com  Thu Jan 26 02:21:49 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8606B21F86D6 for ; Thu, 26 Jan 2012 02:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.049
X-Spam-Level: 
X-Spam-Status: No, score=-4.049 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uK5zB+dKAYm for ; Thu, 26 Jan 2012 02:21:48 -0800 (PST)
Received: from AM1EHSOBE003.bigfish.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 4639421F86B9 for ; Thu, 26 Jan 2012 02:21:48 -0800 (PST)
Received: from mail27-am1-R.bigfish.com (10.3.201.243) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jan 2012 10:21:47 +0000
Received: from mail27-am1 (localhost [127.0.0.1])	by mail27-am1-R.bigfish.com (Postfix) with ESMTP id 18849260435; Thu, 26 Jan 2012 10:21:47 +0000 (UTC)
X-SpamScore: -39
X-BigFish: VPS-39(zz217bL15d6O9251Jc85fh1443Nzz1202hzz1033IL8275bh8275dhz2dhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail27-am1 (localhost.localdomain [127.0.0.1]) by mail27-am1 (MessageSwitch) id 1327573304712455_10027; Thu, 26 Jan 2012 10:21:44 +0000 (UTC)
Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.241])	by mail27-am1.bigfish.com (Postfix) with ESMTP id AA40B1E0045; Thu, 26 Jan 2012 10:21:44 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jan 2012 10:21:44 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.28]) by 011-DB3MMR1-007.MGDPHG.emi.philips.com ([10.128.28.57]) with mapi id 14.01.0355.003; Thu, 26 Jan 2012 10:21:43 +0000
From: "Dijk, Esko" 
To: Melvin A 
Thread-Topic: [Roll] RPL and extension headers with trickle multicast
Thread-Index: AQHM25TlLMlrZzkzWkKXhScDj2ceKZYebAyg
Date: Thu, 26 Jan 2012 10:22:57 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED6180593B8@011-DB3MPN1-012.MGDPHG.emi.philips.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.101]
Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED6180593B8011DB3MPN1012MGDP_"
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "roll@ietf.org" 
Subject: Re: [Roll] RPL and extension headers with trickle multicast
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 26 Jan 2012 10:21:49 -0000

--_000_031DD135F9160444ABBE3B0C36CED6180593B8011DB3MPN1012MGDP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Melvin,

I would assume that in your described case the two options are present in t=
he same IPv6 Hop-by-hop Options header:

1.       RPL Option

2.       Trickle Multicast Option

You describe a router implementation that basically includes two possible w=
ays to route multicast packets: RPL and Trickle multicast.  I assume a rout=
er may also select only one of these two mechanisms for routing a multicast=
 packet e.g. depending on destination?

regards,
Esko


Esko Dijk

Philips Corporate Technologies, Research
High Tech Campus 34, Eindhoven, The Netherlands
esko.dijk@philips.com

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mel=
vin A
Sent: Wednesday 25 January 2012 20:09
To: roll@ietf.org
Subject: [Roll] RPL and extension headers with trickle multicast

I have question regarding the RPL extensions (draft-ietf-6man-rpl-option-06=
) and trickle multicast (draft-ietf-roll-trickle-mcast-00)

Both of the documents listed above expects data packets to have very differ=
ent information in the IPv6 Hop-by-hop option header . The draft-ietf-6man-=
rpl-option-06 expects packet direction, RPLInstanceID, etc, whereas draft-i=
etf-roll-trickle-mcast-00 expects SeedID, Sequence, etc.

Are the expectations for a (storing-mode with multicast support RPL impleme=
ntation) multicast data packet  to have two (2) hop-by-hop headers?
If the answer to the previous question is "yes" wouldn't that conflict with=
 RFC-2640 Section 4.1 "Each extension header should occur at most once, exc=
ept for the    Destination Options header which should occur at most twice"=
?
If the answer is "no" what are the expectations on what to included in the =
data messages?


Thanks in advance
Melvin R Aguirre







________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.

--_000_031DD135F9160444ABBE3B0C36CED6180593B8011DB3MPN1012MGDP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable










Hello Melvin,

 


I would assume that in =
your described case the two options are present in the same IPv6 Hop-by-hop=
 Options header:


1.      
RPL Option


2.      
Trickle Multicast Option<=
/span>


 


You describe a router i=
mplementation that basically includes two possible ways to route multicast =
packets: RPL and Trickle multicast.  I assume a router may
 also select only one of these two mechanisms for routing a multicast packe=
t e.g. depending on destination?  


 


regards,


Esko


 


 


Esko Dijk


 


Philips Corporate Technologies, Research


High Tech Campus 34, Eindhoven, The Netherlands

esko.dijk@philips.com


 




From: roll-b=
ounces@ietf.org [mailto:roll-bounces@ietf.org]
On Behalf Of Melvin A

Sent: Wednesday 25 January 2012 20:09

To: roll@ietf.org

Subject: [Roll] RPL and extension headers with trickle multicast




 


I have question regar=
ding the RPL extensions (draft-ietf-6man-rpl-option-06) and trickle =
multicast (draft-ietf-roll-trickle-mcast-00)



Both of the documents listed above expects data packets to have very differ=
ent information in the IPv6 Hop-by-hop option header . The draft-ietf-6man-=
rpl-option-06
expects packet direction, RPLInstanceID, etc, whereas draft-ietf-roll-t=
rickle-mcast-00 expects SeedID, Sequence, etc.




Are the expectations for a (storing-mode with multicast support RPL impleme=
ntation) multicast data packet  to have two (2) hop-by-hop headers?


If the answer to the previous question is "yes" wouldn't that con=
flict with RFC-2640 Section 4.1 "Each extension header should occur at=
 most once, except for the    Destination Options header whi=
ch should occur at most twice"?

If the answer is "no" what are the expectations on what to includ=
ed in the data messages?





Thanks in advance

Melvin R Aguirre














 







The information contained in=
 this message may be confidential and legally protected under applicable la=
w. The message is intended solely for the addressee(s). If you are not the =
intended recipient, you are hereby notified
 that any use, forwarding, dissemination, or reproduction of this message i=
s strictly prohibited and may be unlawful. If you are not the intended reci=
pient, please contact the sender by return e-mail and destroy all copies of=
 the original message.





--_000_031DD135F9160444ABBE3B0C36CED6180593B8011DB3MPN1012MGDP_--

From internet-drafts@ietf.org  Sat Jan 28 16:33:16 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F313B21F8543; Sat, 28 Jan 2012 16:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.585
X-Spam-Level: 
X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT5ryKqVtQxa; Sat, 28 Jan 2012 16:33:15 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9252821F8476; Sat, 28 Jan 2012 16:33:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20120129003315.20253.38055.idtracker@ietfa.amsl.com>
Date: Sat, 28 Jan 2012 16:33:15 -0800
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-07.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Jan 2012 00:33:16 -0000

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

	Title           : Reactive Discovery of Point-to-Point Routes in Low Power=
 and Lossy Networks
	Author(s)       : Mukul Goyal
                          Emmanuel Baccelli
                          Matthias Philipp
                          Anders Brandt
                          Jerald Martocci
	Filename        : draft-ietf-roll-p2p-rpl-07.txt
	Pages           : 27
	Date            : 2012-01-28

   This document specifies a point-to-point route discovery mechanism,
   complementary to the RPL core functionality.  This mechanism allows
   an IPv6 router to discover and establish, on demand, a route to
   another IPv6 router in the LLN such that the discovered route meets
   specified metrics constraints, without necessarily going along the
   DAG links established by core RPL.


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

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-07.txt


From prvs=3681a06aa=mukul@uwm.edu  Sat Jan 28 16:39:13 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BD421F85C0 for ; Sat, 28 Jan 2012 16:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.527
X-Spam-Level: 
X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7Yiby9ubcMC for ; Sat, 28 Jan 2012 16:39:13 -0800 (PST)
Received: from ip2mta.uwm.edu (smtp.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id DEF9221F85B8 for ; Sat, 28 Jan 2012 16:39:12 -0800 (PST)
Received: from localhost (HELO mta02.pantherlink.uwm.edu) ([127.0.0.1]) by ip2mta.uwm.edu with ESMTP; 28 Jan 2012 18:39:12 -0600
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 5257212E3C2 for ; Sat, 28 Jan 2012 18:39:12 -0600 (CST)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5A+h61CFbx1 for ; Sat, 28 Jan 2012 18:39:12 -0600 (CST)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 129DC12E3BF for ; Sat, 28 Jan 2012 18:39:12 -0600 (CST)
Date: Sat, 28 Jan 2012 18:39:12 -0600 (CST)
From: Mukul Goyal 
To: roll  
Message-ID: <817159311.1048013.1327797551887.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <20120129003315.20253.14619.idtracker@ietfa.amsl.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 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-p2p-rpl-07.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 29 Jan 2012 00:39:13 -0000

Hi all

A very minor update over p2p-rpl-06. 

The DIOIntervalMin value in the default configuration option for a P2P mode DIO is specified as 6, which translates to Imin value of 64ms for Trickle operation. We somehow forgot to specify this in p2p-rpl-06.

Thanks
Mukul

----- Forwarded Message -----
From: internet-drafts@ietf.org
To: mukul@uwm.edu
Cc: "jerald p martocci" , "emmanuel baccelli" , mukul@uwm.edu, "matthias philipp" , abr@sdesigns.dk
Sent: Saturday, January 28, 2012 6:33:15 PM
Subject: New Version Notification for draft-ietf-roll-p2p-rpl-07.txt

A new version of I-D, draft-ietf-roll-p2p-rpl-07.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository.

Filename:	 draft-ietf-roll-p2p-rpl
Revision:	 07
Title:		 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks
Creation date:	 2012-01-29
WG ID:		 roll
Number of pages: 27

Abstract:
   This document specifies a point-to-point route discovery mechanism,
   complementary to the RPL core functionality.  This mechanism allows
   an IPv6 router to discover and establish, on demand, a route to
   another IPv6 router in the LLN such that the discovered route meets
   specified metrics constraints, without necessarily going along the
   DAG links established by core RPL.

                                                                                  


The IETF Secretariat

From jpv@cisco.com  Mon Jan 30 06:48:01 2012
Return-Path: 
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE7621F85B4 for ; Mon, 30 Jan 2012 06:48:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQskCoKGzSZY for ; Mon, 30 Jan 2012 06:48:00 -0800 (PST)
Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id AEAD221F8584 for ; Mon, 30 Jan 2012 06:47:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7738; q=dns/txt; s=iport; t=1327934880; x=1329144480; h=from:subject:date:message-id:to:mime-version; bh=IOUCMUZZNrw0/Q5Tin8YI7cr2YUVdAHDqDTbb0sIcKs=; b=ACbD0UNpmBnM4vCyIwEzJQgL8VI5OJRnnZF6qcNufqZQrz91boP29m3H 26krk88UGb9DZ01FE+ZmFp4gHKWjIup0Q0V6ghzK+NePXikphBsJOf1XJ Z662ph2EPZlD02kY1eqq5Gv9TEHDMJFmPhLSb8RyWqKXNYbc6lUblz05Z U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAFusJk9Io8UY/2dsb2JhbABDgk2tD4ILAYElfxwZh2OYa4EnAZ4iiC0aHwMECwEIAQUJBgMEgxkDFQILAwIODCUHCQoLNIJUYwSVGoVWjHw
X-IronPort-AV: E=Sophos;i="4.71,592,1320624000"; d="scan'208,217";a="4424063"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 30 Jan 2012 14:47:57 +0000
Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0UElv8m019351 for ; Mon, 30 Jan 2012 14:47:57 GMT
Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 30 Jan 2012 22:47:57 +0800
Received: from [10.60.114.231] ([10.60.114.231]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 30 Jan 2012 22:47:56 +0800
From: JP Vasseur 
Content-Type: multipart/alternative; boundary="Apple-Mail=_6772218A-F296-402F-891E-2928F4B27D90"
Date: Mon, 30 Jan 2012 15:47:54 +0100
Message-Id: <02956E9B-F07F-4AF3-816C-CCC3C4B90A91@cisco.com>
To: roll WG 
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-OriginalArrivalTime: 30 Jan 2012 14:47:56.0882 (UTC) FILETIME=[27754B20:01CCDF5E]
Subject: [Roll] IETF-83 - Slot ?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: 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, 30 Jan 2012 14:48:01 -0000

--Apple-Mail=_6772218A-F296-402F-891E-2928F4B27D90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear all,

As a reminder, here are the "important" dates:

IETF 83: March 25-30, 2012, Paris, France
Download .ICS file of important dates for IETF 83
Subscribe to important dates calendar for IETF 83: =
http://www.ietf.org/meeting/83/IETF-83-important-dates.ics

2011-12-19 (Week of): IETF Online Registration opens.
2011-12-19 (Monday): Working Group and BOF scheduling begins. To request =
a Working Group session, use the IETF Meeting Session Request Tool.
2012-01-30 (Monday): Cutoff date for requests to schedule Working Group =
meetings at 17:00 PT (UTC -8). To request a Working Group session, use =
the IETF Meeting Session Request Tool.
2012-02-13 (Monday): Cutoff date for BOF proposal requests to Area =
Directors at 17:00 PT (UTC -8). To request a BOF, please see =
instructions on Requesting a BOF.
2012-02-16 (Thursday): Cutoff date for Area Directors to approve BOFs at =
17:00 PT (UTC -8).
2012-02-23 (Thursday): Preliminary agenda published for comment.
2012-02-27 (Monday): Cutoff date for requests to reschedule Working =
Group and BOF meetings 17:00 PT (UTC -8).
2012-02-27 (Monday): Working Group Chair approval for initial document =
(Version -00) submissions appreciated by 17:00 PT (UTC -8).
2012-03-02 (Friday): Final agenda to be published.
2012-03-05 (Monday): Internet Draft Cut-off for initial document (-00) =
submission by 17:00 PT (UTC -8), upload using IETF ID Submission Tool.
2012-03-12 (Monday): Internet Draft final submission cut-off by 17:00 PT =
(UTC -7), upload using IETF ID Submission Tool.
2012-03-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (UTC =
-7), upload using IETF Meeting Materials Management Tool.
2012-03-16 (Friday): Early Bird registration and payment cut-off at =
17:00 PT (UTC -7).
2012-03-19 (Monday): Revised Working Group agendas due by 17:00 PT (UTC =
-7), upload using IETF Meeting Materials Management Tool.
2012-03-19 (Monday): Registration cancellation cut-off at 17:00 PT (UTC =
-7).
2012-03-23 (Friday): Final Pre-Registration and Pre-Payment cut-off at =
17:00 local meeting time.
2012-03-25 - 2012-03-30: 83rd IETF Meeting in Paris, France.
2012-04-27 (Friday): Proceedings submission cutoff date by 17:00 PT (UTC =
-7), upload using IETF Meeting Materials Management Tool.
2012-05-16 (Wednesday): Proceedings submission corrections cutoff date =
by 17:00 PT (UTC -7), upload usingIETF Meeting Materials Management =
Tool.


Please tell us before March 7 if you would like to have a "slot" for the =
ROLL WG meeting at IETF-83 ?

Thanks.

JP.=

--Apple-Mail=_6772218A-F296-402F-891E-2928F4B27D90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Dear =
all,

As a reminder, here are the "important" =
dates:

IETF =
83: March 25-30, 2012, Paris, =
France
Download .ICS file of important dates for IETF 83
Subscribe to =
important dates calendar for IETF 83: http:/=
/www.ietf.org/meeting/83/IETF-83-important-dates.ics
    =
IETF Meeting Session Request Tool.
  • 2012-01-30 =
(Monday): Cutoff date for requests to schedule Working =
Group meetings at 17:00 PT (UTC -8). To request a Working Group session, =
use the =
IETF Meeting Session Request Tool.
  • 2012-02-13 =
(Monday): Cutoff date for BOF proposal requests to Area =
Directors at 17:00 PT (UTC -8). To request a BOF, please see =
instructions on Requesting a =
BOF.
  • 2012-02-16 (Thursday): Cutoff =
date for Area Directors to approve BOFs at 17:00 PT (UTC =
-8).
  • 2012-02-23 (Thursday): Preliminary =
agenda published for comment.
  • 2012-02-27 =
(Monday): Cutoff date for requests to reschedule Working =
Group and BOF meetings 17:00 PT (UTC -8).
  • 2012-02-27 =
(Monday): Working Group Chair approval for initial =
document (Version -00) submissions appreciated by 17:00 PT (UTC =
-8).
  • 2012-03-02 (Friday): Final agenda to =
be published.
  • 2012-03-05 =
(Monday): Internet Draft Cut-off for initial document =
(-00) submission by 17:00 PT (UTC -8), upload using IETF ID Submission =
Tool.
  • 2012-03-12 (Monday): Internet =
Draft final submission cut-off by 17:00 PT (UTC -7), upload =
using IETF ID =
Submission Tool.
  • 2012-03-14 =
(Wednesday): Draft Working Group agendas due by 17:00 PT =
(UTC -7), upload using IETF =
Meeting Materials Management Tool.
  • 2012-03-16 =
(Friday): Early Bird registration and payment cut-off at =
17:00 PT (UTC -7).
  • 2012-03-19 =
(Monday): Revised Working Group agendas due by 17:00 PT =
(UTC -7), upload using IETF =
Meeting Materials Management Tool.
  • 2012-03-19 =
(Monday): Registration cancellation cut-off at 17:00 PT =
(UTC -7).
  • 2012-03-23 (Friday): Final =
Pre-Registration and Pre-Payment cut-off at 17:00 local meeting =
time.
  • 2012-03-25 - 2012-03-30: 83rd IETF Meeting in =
Paris, France.
  • 2012-04-27 =
(Friday): Proceedings submission cutoff date by 17:00 PT =
(UTC -7), upload using IETF =
Meeting Materials Management Tool.
  • 2012-05-16 =
(Wednesday): Proceedings submission corrections cutoff =
date by 17:00 PT (UTC -7), upload usingIETF =
Meeting Materials Management =
Tool.


Please tell us before March =
7 if you would like to have a "slot" for the ROLL WG meeting at IETF-83 =
?

Thanks.

JP.
= --Apple-Mail=_6772218A-F296-402F-891E-2928F4B27D90--