From gnawali@cs.uh.edu Mon Sep 3 07:21:36 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 67DE121F863C for ; Mon, 3 Sep 2012 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahbrDxOim7WJ for ; Mon, 3 Sep 2012 07:21:35 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id C384021F8630 for ; Mon, 3 Sep 2012 07:21:35 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id D905D23CA7D for ; Mon, 3 Sep 2012 09:21:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bay3BOQykhX4 for ; Mon, 3 Sep 2012 09:21:17 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 01A2623CA78 for ; Mon, 3 Sep 2012 09:21:17 -0500 (CDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by it.cs.uh.edu (Postfix) with ESMTP id 9220F2A280BF for ; Mon, 3 Sep 2012 09:25:31 -0500 (CDT) Received: by vbbez10 with SMTP id ez10so6292224vbb.31 for ; Mon, 03 Sep 2012 07:21:21 -0700 (PDT) Received: by 10.58.85.165 with SMTP id i5mr2276614vez.5.1346682081852; Mon, 03 Sep 2012 07:21:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.41 with HTTP; Mon, 3 Sep 2012 07:21:01 -0700 (PDT) From: Omprakash Gnawali Date: Mon, 3 Sep 2012 09:21:01 -0500 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] your comments on rpl implementation and deployment 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, 03 Sep 2012 14:21:36 -0000 I am planning to update draft-gnawali-roll-rpl-recommendations in the next few days. I will add something about leaf nodes. It will be great to also hear from rest of the WG their experiences and suggestions from their experiences so we can document them in the draft. JP, do you have any suggestions and insights from the deployment you described in the recent draft? There might be some lessons from that deployment others could learn and I would love to incorporate them in the draft. Here is the link to the current version of the draft: http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03 - om_p From pal@cs.stanford.edu Mon Sep 3 14:36: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 44F1421F8598 for ; Mon, 3 Sep 2012 14:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDlMSU6iuw77 for ; Mon, 3 Sep 2012 14:36:43 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B87021F84A1 for ; Mon, 3 Sep 2012 14:36:42 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1T8eJx-0006yE-8Z; Mon, 03 Sep 2012 14:36:37 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> Date: Mon, 3 Sep 2012 14:36:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1278) X-Scan-Signature: 58355bea2820b4cf9b9c8322cdf0b49d Cc: JeongGil Ko , roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 03 Sep 2012 21:36:44 -0000 On Aug 23, 2012, at 10:06 PM, JP Vasseur (jvasseur) wrote: > Thanks for your feed-back, great discussion. If we have sufficient = requirements for such a case (let's see what the WG says) It seems like so far no one has presented a strong case; I'd argue that = we should table it until it's needed. RPL is complicated enough already. Phil From jvasseur@cisco.com Mon Sep 3 23:38: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 B1BEC21F84A0 for ; Mon, 3 Sep 2012 23:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf2s8Ml9DA2M for ; Mon, 3 Sep 2012 23:38:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 333B321F849C for ; Mon, 3 Sep 2012 23:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1087; q=dns/txt; s=iport; t=1346740724; x=1347950324; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4gso7qOTeF4UvlsPNnPUnDB2HLEFLXVuoDdZoLZayMY=; b=HLAhHmPnAylOD3zk73cG3qWxVodvx1c8NTPDPkOabWiScdZED533UZ3S IhKP/DbR4Bb7asixpNQ6NCbztNNtA0Z8A9kj67EM29/ZFRpviHq9KQcz6 Fg6eslH05L3jOrLKMLWDazee4hPAUF/am7NK7W3PSZ0AfEinv76X+85w0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD6hRVCtJV2a/2dsb2JhbABFDrsagQeCIAEBAQMBAQEBDwEnNAsFCwIBCDYQJwslAgQOBSKHZQYLmjGfeIsNhlJgA5VZgRSNH4Fngik6 X-IronPort-AV: E=Sophos;i="4.80,365,1344211200"; d="scan'208";a="117942606" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 04 Sep 2012 06:38:43 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q846chc3029313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 06:38:43 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.209]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Tue, 4 Sep 2012 01:38:43 -0500 From: "JP Vasseur (jvasseur)" To: Omprakash Gnawali Thread-Topic: [Roll] your comments on rpl implementation and deployment Thread-Index: AQHNimft5hkxHCrVGU2B0jpCUox8kg== Date: Tue, 4 Sep 2012 06:38:42 +0000 Message-ID: <0E76A7FB-9C79-41F5-92CA-0637563478F0@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.233] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19160.004 x-tm-as-result: No--35.554700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ROLL WG Subject: Re: [Roll] your comments on rpl implementation and deployment 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, 04 Sep 2012 06:38:44 -0000 Hi, On Sep 3, 2012, at 4:21 PM, Omprakash Gnawali wrote: > I am planning to update draft-gnawali-roll-rpl-recommendations in the > next few days. I will add something about leaf nodes. It will be great > to also hear from rest of the WG their experiences and suggestions > from their experiences so we can document them in the draft. >=20 > JP, do you have any suggestions and insights from the deployment you > described in the recent draft? There might be some lessons from that > deployment others could learn and I would love to incorporate them in > the draft. >=20 Not really, it worked as planned with tuning of course of various parameter= s. We will update the draft soon in light of another large scale deployment and will let you know, thanks for asking. Thanks. JP. > Here is the link to the current version of the draft: > http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03 >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From sensys@cfpmail.info Mon Jul 23 16:27:59 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 C701711E80FA for ; Mon, 23 Jul 2012 16:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UjZ9IorCiPQ2 for ; Mon, 23 Jul 2012 16:27:59 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC52D11E80F3 for ; Mon, 23 Jul 2012 16:27:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5704266vbb.31 for ; Mon, 23 Jul 2012 16:27:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=5yTsK94a4Zdlp105g4wdeA8Vq6E36WObKO2B1BXtoZQ=; b=DJeXA3cA8PlFT9W59RbXAKnq58u/0gtIDOjCT/Tzhj5Un6wrG8fU2oO8vD7fAO7AjV rcNOdNAU+v4HcUd3dpaRvAnZs4tbBVYTz6JrGHFnY3KkaVvftkb+NnNbkypwOceWHp77 1KeJqFEaSFkNbG1aQ77017DjnSJ4VRq7svqM5Wb3FYH+Ci/0MstGwjUtRgm6+YFfrJVA F4Jb7jUaqStgFzUN00QjZG2ZtxA1ewiMMBTEzErL9aootKNWGpBDl+U1FeHLdhaKPX7s Vn4WMxd8DpwQxTW+RJIgQMh2URvz0gCXk7jlViFUp4j62cV7nYEuZ9f5R82QbfT2Z6ca OLPQ== MIME-Version: 1.0 Received: by 10.52.98.8 with SMTP id ee8mr12308313vdb.58.1343086077952; Mon, 23 Jul 2012 16:27:57 -0700 (PDT) Received: by 10.58.58.50 with HTTP; Mon, 23 Jul 2012 16:27:57 -0700 (PDT) X-Originating-IP: [71.88.215.247] Message-ID: From: "SenSys'12 Publicity" To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlvMlW8iNjbzfLMy3rrWRr2CkWDLxYxOv1/DaB5Ay1Hz1KrhbnqB5BwVz7/s/oPs2hMN8np X-Mailman-Approved-At: Tue, 04 Sep 2012 01:37:30 -0700 Subject: [Roll] [CFP] SenSys 2012 Demo: The ACM Conference on Embedded Networked Sensor 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: Mon, 23 Jul 2012 23:28:00 -0000 X-Original-Date: Mon, 23 Jul 2012 19:27:57 -0400 X-List-Received-Date: Mon, 23 Jul 2012 23:28:00 -0000 SenSys 2012 solicits demonstrations showing innovative research and applications. Demos which demonstrate working systems, new platforms and tools, innovative applications, ground breaking ideas, and other revolutionary concepts related to SenSys are welcome. Submissions from both industry and universities are encouraged. Demos will be evaluated based on technical merit and innovation as well as their potential to stimulate interesting discussions and exchange of ideas. All accepted demos will appear in Sensys 2012 proceedings. Best Demo Award(s) During the conference, all demos will be evaluated based on technical merit, innovation, implementation completeness, and presentation quality to select the best demo(s). The selected demos will receive awards that will be announced during the conference. DEMO SUBMISSION INSTRUCTIONS Submit a two-page description of your demo explaining the details of what you will be presenting in as much detail as possible. If you plan to demonstrate any technology involving non-standard RF transmissions, please state this explicitly in your demo description. This will allow us to minimize interference between demos. Demos should be submitted to: http://dachs.ece.utah.edu/sensys_demo_submissions/ Authors should format their two-page demo abstracts according to the formatting guidelines provided for full paper submissions. Demo submissions should be in PDF format. IMPORTANT DATES Two-page demo descriptions: 11:59pm (PST), July 27, 2012 Notification of acceptance: August 6, 2012 Camera-ready abstract: August 17, 2012 Conference dates: November 6-9, 2012 SenSys 2011 DEMO CHAIRS Jakob Eriksson (University of Illinois, Chicago), jakob@uic.edu Pei Zhang (CMU), peizhang@cmu.edu From sensys@cfpmail.info Mon Jul 23 16:29: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 3F34211E80FA for ; Mon, 23 Jul 2012 16:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sBzPoRdCDStJ for ; Mon, 23 Jul 2012 16:29:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3D4711E80F7 for ; Mon, 23 Jul 2012 16:29:05 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5704870vbb.31 for ; Mon, 23 Jul 2012 16:29:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=2lPfc/Ha8No85PZ1nRd5nQ49dMiZ503Zg31VyvhA6ts=; b=Q0bwtOcUmke7JMnVIQZf64tIghmYuao7yhAzQsJo21ZOd69T6OgWrwPrXw5bLvZLyL G3I/rZ2AJYBo1JKBEecWMrhW8QzxtRzvqIcmhflutfY0vp/oJ4+VhaDd64XY0jRreADX hPU7Ct+/zIiyxg+0MOOkCufozujjqXEDvZgr9Pn0aFQpsgFuvTT+I+Gqlx9+ORrveItn j5HwzdICe6nzVBQz/KT6Y0FRjkbKOWeO/+JGRlTToG8MHCVeSGOdreBGpE5qpgWbQIbe EnCUKpGXvkLr2Qu81Y1y7zV/5e98s2DyFLB0wxR40nbEB0JTL+6fGp95sb+Y5lXGro7/ h5xQ== MIME-Version: 1.0 Received: by 10.220.106.135 with SMTP id x7mr14111055vco.28.1343086145359; Mon, 23 Jul 2012 16:29:05 -0700 (PDT) Received: by 10.58.58.50 with HTTP; Mon, 23 Jul 2012 16:29:05 -0700 (PDT) X-Originating-IP: [71.88.215.247] Message-ID: From: "SenSys'12 Publicity" To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlW/DcSGTNsx0fc1GGXO79xIGiOLrsE15OBqWcB6JL2XulzkQuFaicNxMcp2O2CRJ3nwBL+ X-Mailman-Approved-At: Tue, 04 Sep 2012 01:37:30 -0700 Subject: [Roll] [CFP] SenSys 2012 Poster: The ACM Conference on Embedded Networked Sensor Systems / Poster 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: Mon, 23 Jul 2012 23:29:07 -0000 X-Original-Date: Mon, 23 Jul 2012 19:29:05 -0400 X-List-Received-Date: Mon, 23 Jul 2012 23:29:07 -0000 The poster session at SenSys provides a forum for researchers to present their work and receive feedback from experts attending the conference. The areas of interest are the same as the main track (see the call for papers for details). As with previous editions of SenSys, the best poster will be provided with an award. We explicitly encourage submissions from students. Posters must be submitted as a single PDF containing no more than 3 pages. The first two pages should contain an abstract describing the research content of the poster, along with title, authors, institutional affiliations and contact information. The third page should contain a thumbnail draft of the poster's contents. Please submit your poster proposal as a PDF on the submission website: http://dachs.ece.utah.edu/sensys_poster_submissions. Poster abstracts will appear in the conference proceeding. Important dates: Three-page poster abstracts July 27, 2012, 11:59pm PST Notification of acceptance August 10, 2012 Camera-ready abstract August 21, 2012 Poster Chair Thomas Schmid (University of Utah) From sensys@cfpmail.info Mon Jul 23 16:45: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 0D70E11E80FA for ; Mon, 23 Jul 2012 16:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 eaxpLiWWo5MY for ; Mon, 23 Jul 2012 16:45:11 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1F6411E80F6 for ; Mon, 23 Jul 2012 16:45:10 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5685413vcb.31 for ; Mon, 23 Jul 2012 16:45:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=4TxT1VZGbTHUc0zzzsvSJcnepIs2L8pZKJy2Pa8gRHs=; b=Nn6DeT8PWTu6nHn+o8iCh2Kg5lSeoHMhoH248BZiuTVPZ6HjGZZLE9d7bxG9yLVFJf +0Ra0hEK8xR9QIRHQgoNSD0enCVrEjmeFFZhCri2htlkdU1RqO9KnQgfpiZ5DYaX96mK kWzSjkBtymajTA3Iiqi3kF49LPVW224YalZc9L/g+Z+6iwBb4vgyRAS5FnondhZDQD8w zOujWUMirgQn+fTBudCMKo2ShF94HBO8gNPqwzxFnEcdb9oAxeC27aodZPcCtENbRRmK nlHPC3ZVcQFA61a9mE0ojBNXCMnZYyV4f/+MGB4ez0Dtd+dSE6Ru/uEXunyozjbAqR1k 5xFA== MIME-Version: 1.0 Received: by 10.220.106.135 with SMTP id x7mr14139168vco.28.1343087110434; Mon, 23 Jul 2012 16:45:10 -0700 (PDT) Received: by 10.58.58.50 with HTTP; Mon, 23 Jul 2012 16:45:10 -0700 (PDT) X-Originating-IP: [131.107.0.126] Message-ID: From: "SenSys'12 Publicity" To: "SenSys'12 Publicity" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk0/b4ftfD6XXGTmYeYnJVWviemxuVoae/XGcXbYr25RbCi+2JH8kSXxaaz1iVwt+0org/7 X-Mailman-Approved-At: Tue, 04 Sep 2012 01:37:30 -0700 Subject: [Roll] PhoneSense 2012 (SUBMISSION EXTENSION: 1 Aug 2012) w/ SenSys 2012, Toronto, Canada, 6 Nov 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: , Date: Mon, 23 Jul 2012 23:45:12 -0000 X-Original-Date: Mon, 23 Jul 2012 16:45:10 -0700 X-List-Received-Date: Mon, 23 Jul 2012 23:45:12 -0000 PhoneSense 2012: 3rd International Workshop on Sensing Applications on Mobile Phones (with SenSys 2012) 6 November 2012 Toronto, Canada http://research.microsoft.com/en-us/um/redmond/events/phonesense2012 Important Dates --------------- =95 Paper submissions due: 1 August 2012, 9:00 p.m. PDT (NEW - EXTENSION) =95 Notification of acceptance: 12 September 2012 Organizers ---------- Program Co-Chairs David Chu (Microsoft Research) Ramesh Govindan (USC) Program Committee Gaetano Borriello (University of Washington) Eyal de Lara (University of Toronto) Deborah Estrin (UCLA) Deepak Ganesan (UMass Amherst) Shyamnath Gollakota (MIT) Ben Greenstein (Google) Richard Han (University of Colorado) Anthony LaMarca (Intel Labs) Jie Liu (Microsoft Research) Alexander Varshavsky (AT&T Labs) Steering Committee ------------------ Deborah Estrin (UCLA) Aman Kansal (Microsoft Research) Deepak Ganesan (UMass Amherst) Overview -------- Mobile phones provide a widespread platform for deploying sensing applications. Multiple factors, including the large number of sensors available on phones with new ones being introduced in newer models, proximity to user=92s immediate environment, broadband connectivity, and the potential to provide actionable information, make the phone a compelling platform for many sensing applications. The emergence of the mobile computing cloud further expands the scope of possible use cases. Sensing applications can use the mobile phones and cloud resources to sense, mine, and learn human behaviors and intentions to provide personalized feedback and persuasion. Example sensing application domains include personalized mobile information delivery, context aware social networking, healthcare, games and entertainment, education, device and environment customization, safety, and mobile business. The efficient and effective design of mobile sensing applications opens up many interesting technical challenges. The PhoneSense workshop promotes exchange of ideas among academic and industrial researchers in research areas such as sensing, mobile computing, location, energy efficiency, data management, data mining, machine learning, inference, privacy, user incentives and applications. The workshop considers hot topics, position papers, novel ideas, in-progress work on system architecture, enabling technologies, and emerging applications. Topics of interest include, but are not limited to: =95 Novel Applications =95 Mining large scale sensor and location data =95 Mobile cloud and sensing interfaces =95 Incentive models for mobile data collection =95 Interaction between phones and humans =95 Novel mobile sensor accessories =95 Sensing and machine learning techniques =95 Persuasion models and techniques to close the loop with users =95 Privacy =95 Participatory sensing, crowdsourcing, and opportunistic sensing paradig= ms =95 Activity recognition and subjective sensing =95 Programming models =95 Experiment and campaign design =95 Integration of on-phone and off-phone sensing =95 Personalization, geo-targeting =95 Personal health monitoring using mobile phones =95 Data quality issues =95 Experience with app store delivery systems and large scale deployment What to Submit -------------- Submissions must be at most 5 single-spaced 8.5" x 11" pages, including figures, tables, and references, two-column format, using 10-point type with ACM proceedings format. Submissions will be reviewed by the program committee for novelty, relevance, and quality. PhoneSense is single-blind, so authors should include their names on their paper submissions. For more details, see http://research.microsoft.com/en-us/um/redmond/events/phonesense2012. From wwwrun@rfc-editor.org Fri Aug 3 11:21: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 B9B7621F8DE7 for ; Fri, 3 Aug 2012 11:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, NO_RELAYS=-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 vgtKMAqaLrRb for ; Fri, 3 Aug 2012 11:21:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 505CB21F8D80 for ; Fri, 3 Aug 2012 11:21:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E790172F70A; Fri, 3 Aug 2012 11:20:27 -0700 (PDT) To: jpv@cisco.com, mjkim@kt.com, kpister@dustnetworks.com, nicolas.dejean@coronis.com, dominique.barthel@orange-ftgroup.com, stbryant@cisco.com, adrian@olddog.co.uk, mcr+ietf@sandelman.ca, jpv@cisco.com From: RFC Errata System Message-Id: <20120803182027.E790172F70A@rfc-editor.org> X-Mailman-Approved-At: Tue, 04 Sep 2012 01:37:30 -0700 Cc: roll@ietf.org, nduong@purdue.edu, rfc-editor@rfc-editor.org Subject: [Roll] [Editorial Errata Reported] RFC6551 (3307) 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: Fri, 03 Aug 2012 18:21:13 -0000 X-Original-Date: Fri, 3 Aug 2012 11:20:27 -0700 (PDT) X-List-Received-Date: Fri, 03 Aug 2012 18:21:13 -0000 The following errata report has been submitted for RFC6551, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6551&eid=3307 -------------------------------------- Type: Editorial Reported by: Duong Nguyen Section: 2.1 Original Text ------------- As far as the constraint is concerned, the object body will carry a Node Energy constraint object defined in Section 3.1 indicating that nodes must be mains-powered: Corrected Text -------------- As far as the constraint is concerned, the object body will carry a Node Energy constraint object defined in Section 3.2 indicating that nodes must be mains-powered: Notes ----- Node Energy object is mentioned in section 3.2 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6551 (draft-ietf-roll-routing-metrics-18) -------------------------------------- Title : Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From ietf-ipr@ietf.org Fri Aug 3 14:32:47 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 9EB9121E8049; Fri, 3 Aug 2012 14:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 pRjymRuPvJdK; Fri, 3 Aug 2012 14:32:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE98011E80A3; Fri, 3 Aug 2012 14:32:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: jonhui@cisco.com, richard.kelsey@silabs.com X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120803213246.28190.52136.idtracker@ietfa.amsl.com> X-Mailman-Approved-At: Tue, 04 Sep 2012 01:37:30 -0700 Cc: roll@ietf.org, ipr-announce@ietf.org Subject: [Roll] IPR Disclosure: Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast-01 belonging to Nokia Corporation 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: Fri, 03 Aug 2012 21:32:47 -0000 X-Original-Date: Fri, 03 Aug 2012 14:32:46 -0700 X-List-Received-Date: Fri, 03 Aug 2012 21:32:47 -0000 Dear Jonathan Hui, Richard Kelsey: An IPR disclosure that pertains to your Internet-Draft entitled "Multicast Forwarding Using Trickle" (draft-ietf-roll-trickle-mcast) was submitted to = the IETF Secretariat on 2012-08-03 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1858/). The title of the IPR disclosure is "Lars Eggert's Statement about IPR related to draft-ietf-roll-trickle-mcast= -01 belonging to Nokia Corporation.""); The IETF Secretariat From wwwrun@rfc-editor.org Wed Aug 8 21:32: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 CC8A311E817A for ; Wed, 8 Aug 2012 21:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, NO_RELAYS=-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 DAyCiyzat0kI for ; Wed, 8 Aug 2012 21:32:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 768AE21F85D6 for ; Wed, 8 Aug 2012 21:32:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 252ACB1E002; Wed, 8 Aug 2012 21:31:44 -0700 (PDT) To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, stbryant@cisco.com, adrian@olddog.co.uk, mcr+ietf@sandelman.ca, jpv@cisco.com From: RFC Errata System Message-Id: <20120809043144.252ACB1E002@rfc-editor.org> X-Mailman-Approved-At: Tue, 04 Sep 2012 01:37:30 -0700 Cc: roll@ietf.org, nduong@purdue.edu, rfc-editor@rfc-editor.org Subject: [Roll] [Editorial Errata Reported] RFC6550 (3311) 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: Thu, 09 Aug 2012 04:32:55 -0000 X-Original-Date: Wed, 8 Aug 2012 21:31:44 -0700 (PDT) X-List-Received-Date: Thu, 09 Aug 2012 04:32:55 -0000 The following errata report has been submitted for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=3311 -------------------------------------- Type: Editorial Reported by: Duong Nguyen Section: 6.7.10 Original Text ------------- R: 1-bit router address flag. When set, it indicates that the Prefix field contains a complete IPv6 address assigned to the sending router that can be used as parent in a target option. Corrected Text -------------- R: 1-bit router address flag. When set, it indicates that the Prefix field contains a complete IPv6 address assigned to the sending router that can be used as parent in a transit option. Notes ----- parent address is carried in transit option, not target option. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From sensys@cfpmail.info Mon Sep 3 22:36:04 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 D891121F8527 for ; Mon, 3 Sep 2012 22:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XR2iXntNuXK for ; Mon, 3 Sep 2012 22:36:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACDC21F851E for ; Mon, 3 Sep 2012 22:36:04 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so7149847vcb.31 for ; Mon, 03 Sep 2012 22:36:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=6O1uJ+2FTzYgcipHgrsup4Xn+SsR3cxwfFIF1KHelN4=; b=f1Wla2SSIhHtJocaT+XGUmEEFFBTe+QYoJrMJMUcHkl+Qk+cvfdpAG89+fEl9uYm4H aI92bMcVcLUnSFogI58aVB7Ve5S2ipwVSowFxZ3xResgpkySvKI6DHu7DQtHzIW6TFRT K8oOtZqMgs7MNA6rR8HsZTjWpPP9mMATYTH0Drzjwph19Z4g2xrbM+HDK6SNzzM9Ghxm qSepl9kwqc0MSuoMIUJnjy6U59C6HH9qO0YnRSRiypQckwus9NQmvZEsU7MsETksMQpY pHxkKTfg/A/HdSLhGXgdjB+iaTqXbcoetkBHRWb6m8U4FQON4tiyq3cUcELHtGoSKUJf 46gg== MIME-Version: 1.0 Received: by 10.52.16.239 with SMTP id j15mr11229911vdd.7.1346736963382; Mon, 03 Sep 2012 22:36:03 -0700 (PDT) Received: by 10.58.4.40 with HTTP; Mon, 3 Sep 2012 22:36:03 -0700 (PDT) X-Originating-IP: [58.32.203.132] Date: Tue, 4 Sep 2012 13:36:03 +0800 Message-ID: From: "SenSys'12 Publicity" To: "SenSys'12 Publicity" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmoc+ZWPPUjvIb4X6wa6YiG6i4wxL6+DpOISAf/IVa/l1qfyF0c1Bl6Wh/KUNbXwdkCLtjc X-Mailman-Approved-At: Tue, 04 Sep 2012 01:37:30 -0700 Subject: [Roll] SenSys 2012 Registration is now open 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, 04 Sep 2012 05:36:05 -0000 ===================================== C A L L F O R P A R T I C I P A T I O N **** ACM SenSys 2012 **** Toronto, Canada November 6-9, 2010 http://sensys.acm.org/2012/ ===================================== WE ARE NOW ACCEPTING BOTH HOTEL AND CONFERENCE/WORKSHOP REGISTRATIONS. THE LIST OF ACCEPTED DEMOS AND POSTERS ARE ALSO AVAILABLE. WE WILL ANNOUNCE THE FULL PROGRAM SHORTLY The 10th ACM Conference on Embedded Networked Sensor Systems (SenSys 2012) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedded computation capabilities allow for an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. SenSys provides a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact, present and exchange research results, and demonstrate their work in a hands-on research exhibition. We seek technical papers describing original, previously unpublished research results. === Committees Organizing committee General Chair Rasit Eskicioglu (University of Manitoba) Program Chairs Andrew T. Campbell (Dartmouth College) Koen Langendoen (Delft University of Technology) Poster Chair Thomas Schmid (University of Utah) Demo Chairs Jakob Eriksson (University of Illinois, Chicago) Pei Zhang (CMU) Local Arrangements Chairs Geoffrey Challen (University of Buffalo) Publicity Chairs Qing Cao (University of Tennessee) Alberta Cerpa (UC Merced) Xiaofan Jiang (Intel Labs China) Chiara Petrioli (University of Rome La Sapienza) Publication Chair Karthik Dantu (Harvard University) Workshop Chair Bodhi Priyantha (Microsoft Research) N2Women Chair Geethapriya Thamilarasu (SUNYIT) Doctoral Colloquium Chair Polly Huang (NTU) Student Travel Award Chair Radu Stoleru (Texas A&M University) Web Site Chair Chieh-Jan Mike Liang (Microsoft Research Asia) Technical program committee Tarek Abdelzaher (UIUC) Philippe Bonnet (Copenhagen) Srdjan Capkun (ETH Zurich) Geoffrey Challen (Buffalo) Hao Chu (NTU) Landon Cox (Duke University) Prabal Dutta (Michigan) Jakob Eriksson (UIC) Deepak Ganesan (UMASS Amherst) Jie Gao (Stony Brook) Omprakash Gnawali (Houston) Santosh Kumar (Memphis) Brano Kusy (CSIRO) Philip Levis (Stanford) Chenyang Lu (WUSTL) Cecilia Mascolo (Cambridge) Emiliano Miluzzo (AT&T Labs) Thomas Moscibroda (Microsoft) Luca Mottola (SICS) Amy Murphy (FBK) Vijay Raghunathan (Purdue) Utz Roedig (Lancaster) Anthony Rowe (CMU) Sivan Toledo (Tel-Aviv) Niki Trigoni (Oxford) Kamin Whitehouse (Virginia) From abdussalambaryun@gmail.com Tue Sep 4 03:04: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 31F9021F862A for ; Tue, 4 Sep 2012 03:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1lMtGGj1wBF for ; Tue, 4 Sep 2012 03:04:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A624021F8568 for ; Tue, 4 Sep 2012 03:04:33 -0700 (PDT) Received: by iabz21 with SMTP id z21so9833789iab.31 for ; Tue, 04 Sep 2012 03:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IJElxxY9hB99ygOllY0pX+Bi9BusGyZwF4Ivd0WQnOM=; b=PG7RqCWW5kiMcmxJYdgTjzcw6vU2L9K5GezwUu3TnxYHLtN7JJrZv/SlaqHEFzAurp 5eYdo9Kv/2e8FCtJ5yMrqXjbN1nTeatwCXCoOw/cjJcVjFkx+mk0BwsPY5ApIlo4QHxC 9hRHASneLdrzN7IbUqtClAofjw2C8ojlrTx8vULxql33ePR1sKcC/9dl6LLR5lXVT8L8 HhdbWUW++sjbXhJ2WNbqr5BEtQegjy7RYNCvPERwDfeIhP57XNoRpMVIvLwgpSVyJjeg dtrPYd7T1iWYXZxufWvXL/+Q7qZNAkg+ZzM+UpdEfVG9JiPgGhRFzuUK7FmgAslYmjPE qt6w== MIME-Version: 1.0 Received: by 10.50.41.169 with SMTP id g9mr13521945igl.4.1346753073261; Tue, 04 Sep 2012 03:04:33 -0700 (PDT) Received: by 10.64.38.130 with HTTP; Tue, 4 Sep 2012 03:04:33 -0700 (PDT) In-Reply-To: <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> Date: Tue, 4 Sep 2012 12:04:33 +0200 Message-ID: From: Abdussalam Baryun To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 04 Sep 2012 10:04:34 -0000 Hi Philip, I also think that RPL is complicated, for good reasons, but not always complicated protocols should not be optimized or assisted by others. However, new ideas and drafts are always recommended. AB On 9/3/12, Philip Levis wrote: > > On Aug 23, 2012, at 10:06 PM, JP Vasseur (jvasseur) wrote: > >> Thanks for your feed-back, great discussion. If we have sufficient >> requirements for such a case (let's see what the WG says) > > It seems like so far no one has presented a strong case; I'd argue that we > should table it until it's needed. RPL is complicated enough already. > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Tue Sep 4 09:54: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 E530411E80A3 for ; Tue, 4 Sep 2012 09:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAEHWhhO1CTM for ; Tue, 4 Sep 2012 09:54:29 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1AD21E8042 for ; Tue, 4 Sep 2012 09:54:29 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[10.111.222.26]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1T8wOR-0003Ya-So; Tue, 04 Sep 2012 09:54:28 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: Date: Tue, 4 Sep 2012 09:17:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 04 Sep 2012 16:54:30 -0000 On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: > Hi Philip, >=20 > I also think that RPL is complicated, for good reasons, but not always > complicated protocols should not be optimized or assisted by others. > However, new ideas and drafts are always recommended. As an academic, I agree wholeheartedly. Also as an academic, I'd argue = that new ideas which do not have a strong application pull are the = province of research, not standardization. Our goal here is to = standardize practice for interoperability, not come up with new ideas. = But that's just my 2 cents. Phil From jeonggil.ko@gmail.com Tue Sep 4 17:36:36 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 AD5A321E8054 for ; Tue, 4 Sep 2012 17:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08QWTkU-5yCD for ; Tue, 4 Sep 2012 17:36:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7F7521E8053 for ; Tue, 4 Sep 2012 17:36:33 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so26673pbb.31 for ; Tue, 04 Sep 2012 17:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=00wyTsS6R7+H1rCGZQjYdvbpE4NiiJlYdiLp+KPkHgw=; b=VoGN2pvNNPp0wh0Gwj/97sxs/eSacnHO+e/GYYyz9qxRHbYeS1RB7v/69vcwfRunc3 v1RIM8dq3UUnSEFcZXO8lNy+397h3Tr1PrgomKBTe+YgF1lSx5pPlDwa/cPBgYsAQLks OwVy8JDirP+4WYyuz4DISVlUU9vnFU1mvz3PD3fFwGGJl2ZyAQZd5hYKhGXJNI/1v0Sa fvPnlgtUVH32z7E1UBSWR5VEl7+wUTl1L40s38bBa26+PTXCJDQZGP1x/qP7FJwd57pA hrWQW0y2jkWpL+XUi7j8y6XQE8TjnafmOS+JFmLb3ZJrAjPMoHmCcjMK+iYLQreF4tql BZrw== Received: by 10.68.241.226 with SMTP id wl2mr49512152pbc.62.1346805393403; Tue, 04 Sep 2012 17:36:33 -0700 (PDT) Received: from [10.211.8.161] ([129.254.38.231]) by mx.google.com with ESMTPS id rm9sm122112pbc.72.2012.09.04.17.36.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 17:36:32 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JeongGil Ko In-Reply-To: Date: Wed, 5 Sep 2012 09:36:29 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr> References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1278) Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 05 Sep 2012 00:36:36 -0000 Phil, With the RFC 6550, developers can build applications with storing mode = or not-storing mode nodes. In some cases they 'can' design systems to be = mixed, but since either one of the modes should act as a leaf node, they = may result in forming non-optimal routes (in both traffic directions). While it may not be a general application (I think it can be but others = may think differently), we are currently designing a system where = (relatively) resource-rich nodes act as sub-DODAG heads (I am using this = expression due to the lack of a better term) and a larger number of = resource-constraint nodes act as sensing units. Basically it's a network = with device heterogeneity and the two devices have their respective = tasks in the network. This doesn't necessarily mean that these resource = constraint nodes are always positioned physically at a corner of the = network to act as leaf nodes. The physical location of any of these = nodes can be at locations where by using it to forward packets, can = increase the efficiency of packet forwarding on the DODAG. Thus, but = forcing a set of nodes to be leaf nodes, we may miss a chance to have = more efficient routing paths. In such a network, given RFC 6550, to make sure that the default route = performs at its optimal, a system designer needs to select between the = storing or non-storing mode (this is the only way we can have all the = nodes in the network capable of forwarding packets). First, since we = have memory constraints, we do not want the resource constraint nodes to = implement storing mode; thus, a full storing mode network is not an = option. On the other hand, implementing the entire network with = non-storing mode would be inefficient since packets would always have to = travel to the DODAG root for all downwards packets (not saying its not = going to work but less efficient). An alternative would be to implement = non-storing mode for nodes that cannot meet the heavier memory = requirements and for the nodes that can spare some space to store = routes... use the storing mode. This can help cut the stretch of the = packets that travel to non-root destinations. Networks with device = heterogeneity (a mix of powerful and 'dumb' nodes) can choose to use = such 'mixed' network configuration to preserve the upwards routing = performance and also perform downwards routing efficiently. The draft = simply proposes a few light weight changes that are required to make = this happen. I agree with you that if a proposal not realist nor useful in real life, = that it is meaningless (or less meaningful) to push the proposal on the = standards track. Nevertheless, I believe that we should make sure that = RPL can allow/tolerate for various network configurations so that it is = not the standards that is limiting the development of new systems. My = $0.02 :) Thanks! -John On Sep 5, 2012, at 1:17 AM, Philip Levis wrote: >=20 > On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: >=20 >> Hi Philip, >>=20 >> I also think that RPL is complicated, for good reasons, but not = always >> complicated protocols should not be optimized or assisted by others. >> However, new ideas and drafts are always recommended. >=20 >=20 > As an academic, I agree wholeheartedly. Also as an academic, I'd argue = that new ideas which do not have a strong application pull are the = province of research, not standardization. Our goal here is to = standardize practice for interoperability, not come up with new ideas. = But that's just my 2 cents. >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Sep 4 18:29: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 3E8BA21F84CE for ; Tue, 4 Sep 2012 18:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZA0rPuFy3ly for ; Tue, 4 Sep 2012 18:29:07 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1A8321F84C9 for ; Tue, 4 Sep 2012 18:29:07 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1T94QT-0007nx-LW; Tue, 04 Sep 2012 18:29:06 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr> Date: Tue, 4 Sep 2012 18:29:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10F4D589-F3F6-400D-9F34-B93FDC2E5A42@cs.stanford.edu> References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr> To: JeongGil Ko X-Mailer: Apple Mail (2.1278) X-Scan-Signature: a2fe995cb7ed4309b2d212c2bd713a7d Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 05 Sep 2012 01:29:08 -0000 In that case, you're the application that is the compelling use case. = eIt would be great if you could write a document that more concretely = lays out your arguments below; they seem sound to me, but one short = email seems insufficient to motivate a significant protocol addition. A = more detailed design document would also clearly specify the constraints = of the solution. For example, from your description below, it sounds = like complete mixed mode is unnecessary; instead, allowing non-storing = trees off of a storing network would be sufficient. It could be that = setup covers 99% of the mixed use cases, and it is much much simpler = than arbitrary compositions. Phi On Sep 4, 2012, at 5:36 PM, JeongGil Ko wrote: > Phil, >=20 > With the RFC 6550, developers can build applications with storing mode = or not-storing mode nodes. In some cases they 'can' design systems to be = mixed, but since either one of the modes should act as a leaf node, they = may result in forming non-optimal routes (in both traffic directions). >=20 > While it may not be a general application (I think it can be but = others may think differently), we are currently designing a system where = (relatively) resource-rich nodes act as sub-DODAG heads (I am using this = expression due to the lack of a better term) and a larger number of = resource-constraint nodes act as sensing units. Basically it's a network = with device heterogeneity and the two devices have their respective = tasks in the network. This doesn't necessarily mean that these resource = constraint nodes are always positioned physically at a corner of the = network to act as leaf nodes. The physical location of any of these = nodes can be at locations where by using it to forward packets, can = increase the efficiency of packet forwarding on the DODAG. Thus, but = forcing a set of nodes to be leaf nodes, we may miss a chance to have = more efficient routing paths. >=20 > In such a network, given RFC 6550, to make sure that the default route = performs at its optimal, a system designer needs to select between the = storing or non-storing mode (this is the only way we can have all the = nodes in the network capable of forwarding packets). First, since we = have memory constraints, we do not want the resource constraint nodes to = implement storing mode; thus, a full storing mode network is not an = option. On the other hand, implementing the entire network with = non-storing mode would be inefficient since packets would always have to = travel to the DODAG root for all downwards packets (not saying its not = going to work but less efficient). An alternative would be to implement = non-storing mode for nodes that cannot meet the heavier memory = requirements and for the nodes that can spare some space to store = routes... use the storing mode. This can help cut the stretch of the = packets that travel to non-root destinations. Networks with device = heterogeneity (a mix of powerful and 'dumb' nodes) can choose to use = such 'mixed' network configuration to preserve the upwards routing = performance and also perform downwards routing efficiently. The draft = simply proposes a few light weight changes that are required to make = this happen. >=20 > I agree with you that if a proposal not realist nor useful in real = life, that it is meaningless (or less meaningful) to push the proposal = on the standards track. Nevertheless, I believe that we should make sure = that RPL can allow/tolerate for various network configurations so that = it is not the standards that is limiting the development of new systems. = My $0.02 :) >=20 > Thanks! >=20 > -John >=20 >=20 > On Sep 5, 2012, at 1:17 AM, Philip Levis wrote: >=20 >>=20 >> On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: >>=20 >>> Hi Philip, >>>=20 >>> I also think that RPL is complicated, for good reasons, but not = always >>> complicated protocols should not be optimized or assisted by others. >>> However, new ideas and drafts are always recommended. >>=20 >>=20 >> As an academic, I agree wholeheartedly. Also as an academic, I'd = argue that new ideas which do not have a strong application pull are the = province of research, not standardization. Our goal here is to = standardize practice for interoperability, not come up with new ideas. = But that's just my 2 cents. >>=20 >> Phil >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 Phil From jeonggil.ko@gmail.com Tue Sep 4 18:34:26 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 E9D9911E808D for ; Tue, 4 Sep 2012 18:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG4ocVvTtZ2h for ; Tue, 4 Sep 2012 18:34:26 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42D4521F84CE for ; Tue, 4 Sep 2012 18:34:26 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so80995pbb.31 for ; Tue, 04 Sep 2012 18:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YFptWDZESSbE9EReg1oRge1ZYaVjSW7bNbnu9Io95HI=; b=FCW4Fvbb6v3C4/h2POAFvwPR13yXt3lv/xPoL/MRSEh9BQTgWsxLsnqnmvAJYv7tJk Vr938GHTQnivR02adxtI9SB7nm/nl5s8I0TJx6NdIDYEA1CTGIPDViufIDFeSgt8YJB0 3SoENeioeFOusNhhdjZDNlxQg1z3WHdFG2lIvb+46sYqmjXSNFpQko+jwxqqvyQ5MzbI 2rxre1UMeRgivT93WG2M7EF5vbgEVvopdb+5/4updjVaTqYvJc29RXzJ7HjF0siTi7rg mRngwijW+AXejARKxkypR5bwDnZEYvleFVblGWaWtKSXmrchxNnSz9kkWluWLT1sC2K8 oOng== Received: by 10.68.226.167 with SMTP id rt7mr49760681pbc.146.1346808865711; Tue, 04 Sep 2012 18:34:25 -0700 (PDT) Received: from [10.211.8.161] ([129.254.38.231]) by mx.google.com with ESMTPS id tq4sm252308pbc.11.2012.09.04.18.34.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Sep 2012 18:34:24 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JeongGil Ko In-Reply-To: <10F4D589-F3F6-400D-9F34-B93FDC2E5A42@cs.stanford.edu> Date: Wed, 5 Sep 2012 10:34:21 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1BACA0A8-CF05-418E-9C5E-657FB0713037@etri.re.kr> References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr> <10F4D589-F3F6-400D-9F34-B93FDC2E5A42@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1278) Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 05 Sep 2012 01:34:27 -0000 Phil, Thanks for your feedback. Nice idea with the additional informative = documentation. I will get together with the authors of the draft to = discuss and initiate an informative document. Thanks! -John On Sep 5, 2012, at 10:29 AM, Philip Levis wrote: > In that case, you're the application that is the compelling use case. = eIt would be great if you could write a document that more concretely = lays out your arguments below; they seem sound to me, but one short = email seems insufficient to motivate a significant protocol addition. A = more detailed design document would also clearly specify the constraints = of the solution. For example, from your description below, it sounds = like complete mixed mode is unnecessary; instead, allowing non-storing = trees off of a storing network would be sufficient. It could be that = setup covers 99% of the mixed use cases, and it is much much simpler = than arbitrary compositions. >=20 > Phi >=20 > On Sep 4, 2012, at 5:36 PM, JeongGil Ko wrote: >=20 >> Phil, >>=20 >> With the RFC 6550, developers can build applications with storing = mode or not-storing mode nodes. In some cases they 'can' design systems = to be mixed, but since either one of the modes should act as a leaf = node, they may result in forming non-optimal routes (in both traffic = directions). >>=20 >> While it may not be a general application (I think it can be but = others may think differently), we are currently designing a system where = (relatively) resource-rich nodes act as sub-DODAG heads (I am using this = expression due to the lack of a better term) and a larger number of = resource-constraint nodes act as sensing units. Basically it's a network = with device heterogeneity and the two devices have their respective = tasks in the network. This doesn't necessarily mean that these resource = constraint nodes are always positioned physically at a corner of the = network to act as leaf nodes. The physical location of any of these = nodes can be at locations where by using it to forward packets, can = increase the efficiency of packet forwarding on the DODAG. Thus, but = forcing a set of nodes to be leaf nodes, we may miss a chance to have = more efficient routing paths. >>=20 >> In such a network, given RFC 6550, to make sure that the default = route performs at its optimal, a system designer needs to select between = the storing or non-storing mode (this is the only way we can have all = the nodes in the network capable of forwarding packets). First, since we = have memory constraints, we do not want the resource constraint nodes to = implement storing mode; thus, a full storing mode network is not an = option. On the other hand, implementing the entire network with = non-storing mode would be inefficient since packets would always have to = travel to the DODAG root for all downwards packets (not saying its not = going to work but less efficient). An alternative would be to implement = non-storing mode for nodes that cannot meet the heavier memory = requirements and for the nodes that can spare some space to store = routes... use the storing mode. This can help cut the stretch of the = packets that travel to non-root destinations. Networks with device = heterogeneity (a mix=20 > of powerful and 'dumb' nodes) can choose to use such 'mixed' network = configuration to preserve the upwards routing performance and also = perform downwards routing efficiently. The draft simply proposes a few = light weight changes that are required to make this happen. >>=20 >> I agree with you that if a proposal not realist nor useful in real = life, that it is meaningless (or less meaningful) to push the proposal = on the standards track. Nevertheless, I believe that we should make sure = that RPL can allow/tolerate for various network configurations so that = it is not the standards that is limiting the development of new systems. = My $0.02 :) >>=20 >> Thanks! >>=20 >> -John >>=20 >>=20 >> On Sep 5, 2012, at 1:17 AM, Philip Levis wrote: >>=20 >>>=20 >>> On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: >>>=20 >>>> Hi Philip, >>>>=20 >>>> I also think that RPL is complicated, for good reasons, but not = always >>>> complicated protocols should not be optimized or assisted by = others. >>>> However, new ideas and drafts are always recommended. >>>=20 >>>=20 >>> As an academic, I agree wholeheartedly. Also as an academic, I'd = argue that new ideas which do not have a strong application pull are the = province of research, not standardization. Our goal here is to = standardize practice for interoperability, not come up with new ideas. = But that's just my 2 cents. >>>=20 >>> Phil >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jvasseur@cisco.com Wed Sep 5 04:08:46 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 6021A21F8499 for ; Wed, 5 Sep 2012 04:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HBOJiRkrphw for ; Wed, 5 Sep 2012 04:08:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 87A1E21F84D7 for ; Wed, 5 Sep 2012 04:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=5561; q=dns/txt; s=iport; t=1346843318; x=1348052918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q/WEBvg8QULt5AAxcZym2vHfchoabY5lOeHNs0YRtho=; b=YYdJf+/f4TlmDPLwXPfOfCOD8TfgN69pDGmRPqFTCrSVVkrHsphNCauG c1rp4cJsR0bolq0D5yLgFIaXamciPrmXkC8oTBoJUN2zsH7aUDQXynbnk RlLsuSlshf7yMTvw4gEWPC6cNeWcYgjHncu6O78Y5cxH82iAB44rO5Va4 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMIxR1CtJV2b/2dsb2JhbABFuxyBB4IgAQEBAwEBAQEPASc0CwULAgEIGB4QJwslAgQOBRkCB4dlBguaIKAeBIsRhiJgA5VZjjOBZ4JjgWE X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208";a="118431117" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 05 Sep 2012 11:08:38 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q85B8bdX013932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Sep 2012 11:08:37 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.209]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 06:08:37 -0500 From: "JP Vasseur (jvasseur)" To: JeongGil Ko Thread-Topic: [Roll] mixture of storing and non-storing nodes Thread-Index: AQHNi1bLG86C0q30QUWKLgR8P2Swxg== Date: Wed, 5 Sep 2012 11:08:36 +0000 Message-ID: <6A41B5D8-316A-4958-9259-AD37DD5DE9DC@cisco.com> References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr> <10F4D589-F3F6-400D-9F34-B93FDC2E5A42@cs.stanford.edu> <1BACA0A8-CF05-418E-9C5E-657FB0713037@etri.re.kr> In-Reply-To: <1BACA0A8-CF05-418E-9C5E-657FB0713037@etri.re.kr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.233] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19164.003 x-tm-as-result: No--41.499600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4A99B65AFF42AA4BA57CBA7FC545398A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 05 Sep 2012 11:08:46 -0000 Fully agreeing with Phil; as RPL is being deployed and mature, we need to b= e careful not to add anything that is not strongly motivated by a concrete use case and requirements. Thanks for your work. JP. On Sep 5, 2012, at 3:34 AM, JeongGil Ko wrote: > Phil, >=20 > Thanks for your feedback. Nice idea with the additional informative docum= entation. I will get together with the authors of the draft to discuss and = initiate an informative document. >=20 > Thanks! >=20 > -John >=20 >=20 > On Sep 5, 2012, at 10:29 AM, Philip Levis wrote: >=20 >> In that case, you're the application that is the compelling use case. eI= t would be great if you could write a document that more concretely lays ou= t your arguments below; they seem sound to me, but one short email seems in= sufficient to motivate a significant protocol addition. A more detailed des= ign document would also clearly specify the constraints of the solution. Fo= r example, from your description below, it sounds like complete mixed mode = is unnecessary; instead, allowing non-storing trees off of a storing networ= k would be sufficient. It could be that setup covers 99% of the mixed use c= ases, and it is much much simpler than arbitrary compositions. >>=20 >> Phi >>=20 >> On Sep 4, 2012, at 5:36 PM, JeongGil Ko wrote: >>=20 >>> Phil, >>>=20 >>> With the RFC 6550, developers can build applications with storing mode = or not-storing mode nodes. In some cases they 'can' design systems to be mi= xed, but since either one of the modes should act as a leaf node, they may = result in forming non-optimal routes (in both traffic directions). >>>=20 >>> While it may not be a general application (I think it can be but others= may think differently), we are currently designing a system where (relativ= ely) resource-rich nodes act as sub-DODAG heads (I am using this expression= due to the lack of a better term) and a larger number of resource-constrai= nt nodes act as sensing units. Basically it's a network with device heterog= eneity and the two devices have their respective tasks in the network. This= doesn't necessarily mean that these resource constraint nodes are always p= ositioned physically at a corner of the network to act as leaf nodes. The p= hysical location of any of these nodes can be at locations where by using i= t to forward packets, can increase the efficiency of packet forwarding on t= he DODAG. Thus, but forcing a set of nodes to be leaf nodes, we may miss a = chance to have more efficient routing paths. >>>=20 >>> In such a network, given RFC 6550, to make sure that the default route = performs at its optimal, a system designer needs to select between the stor= ing or non-storing mode (this is the only way we can have all the nodes in = the network capable of forwarding packets). First, since we have memory con= straints, we do not want the resource constraint nodes to implement storing= mode; thus, a full storing mode network is not an option. On the other han= d, implementing the entire network with non-storing mode would be inefficie= nt since packets would always have to travel to the DODAG root for all down= wards packets (not saying its not going to work but less efficient). An alt= ernative would be to implement non-storing mode for nodes that cannot meet = the heavier memory requirements and for the nodes that can spare some space= to store routes... use the storing mode. This can help cut the stretch of = the packets that travel to non-root destinations. Networks with device hete= rogeneity (a mix >=20 >> of powerful and 'dumb' nodes) can choose to use such 'mixed' network con= figuration to preserve the upwards routing performance and also perform dow= nwards routing efficiently. The draft simply proposes a few light weight c= hanges that are required to make this happen. >>>=20 >>> I agree with you that if a proposal not realist nor useful in real life= , that it is meaningless (or less meaningful) to push the proposal on the s= tandards track. Nevertheless, I believe that we should make sure that RPL c= an allow/tolerate for various network configurations so that it is not the = standards that is limiting the development of new systems. My $0.02 :) >>>=20 >>> Thanks! >>>=20 >>> -John >>>=20 >>>=20 >>> On Sep 5, 2012, at 1:17 AM, Philip Levis wrote: >>>=20 >>>>=20 >>>> On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: >>>>=20 >>>>> Hi Philip, >>>>>=20 >>>>> I also think that RPL is complicated, for good reasons, but not alway= s >>>>> complicated protocols should not be optimized or assisted by others. >>>>> However, new ideas and drafts are always recommended. >>>>=20 >>>>=20 >>>> As an academic, I agree wholeheartedly. Also as an academic, I'd argue= that new ideas which do not have a strong application pull are the provinc= e of research, not standardization. Our goal here is to standardize practic= e for interoperability, not come up with new ideas. But that's just my 2 ce= nts. >>>>=20 >>>> Phil >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>=20 >>=20 >> Phil >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jeonggil.ko@gmail.com Wed Sep 5 04:24: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 C018721F8624 for ; Wed, 5 Sep 2012 04:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUXtrfnaJWbu for ; Wed, 5 Sep 2012 04:24:20 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4F5621F8628 for ; Wed, 5 Sep 2012 04:24:20 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so776829pbb.31 for ; Wed, 05 Sep 2012 04:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hO5vyXh8mX2gdMPwN04JMf2jxlEkYiT8CSO2L9ImlT0=; b=tkjDqPYfnU5oLlLk2Kx+fKbrepFTAwOHA+cCs1sy9y6iToFNl8yiWu0F9dlGkI5e++ BzGnTZVq/+H7lm1b9abzCvRkq5S6HWrV0+1zzvNihfZxKZfhseNv5iQ015Mu02ZLhB6X M7sthLpOPFY//yg+Ldigl9ROQ2QMRKWldAxkK8pPsVt747DIGBpvk5y6V8RU0yFJWwtM 3LHLO22hTDZi3VYBNJuyvoTUURS4CFry7aNGEZf9hs7HLO0BZnnQMrMZ6n6kuMFplSvb qFZUMXckJgt+UvK1yJ9QWsOsGbD0oDecIyZ3caGHeFvOi7u7LsYZHOjJzFRmEmIppjkn hT3g== Received: by 10.66.85.71 with SMTP id f7mr48545403paz.5.1346844260548; Wed, 05 Sep 2012 04:24:20 -0700 (PDT) Received: from [10.211.8.161] ([129.254.38.231]) by mx.google.com with ESMTPS id pj10sm1226163pbb.46.2012.09.05.04.23.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Sep 2012 04:23:49 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JeongGil Ko In-Reply-To: <6A41B5D8-316A-4958-9259-AD37DD5DE9DC@cisco.com> Date: Wed, 5 Sep 2012 20:23:30 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9B06D337-D23B-42C5-B39D-8C6AC58D9DD9@etri.re.kr> References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> <8BE556E9-734D-4691-80C5-19CD7132E5D2@etri.re.kr> <10F4D589-F3F6-400D-9F34-B93FDC2E5A42@cs.stanford.edu> <1BACA0A8-CF05-418E-9C5E-657FB0713037@etri.re.kr> <6A41B5D8-316A-4958-9259-AD37DD5DE9DC@cisco.com> To: JP Vasseur (jvasseur) X-Mailer: Apple Mail (2.1278) Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 05 Sep 2012 11:24:21 -0000 JP, Thanks for your feedback as well! As a RPL implementer, I too fully = agree that RPL should not get any more complex for a random reason. I = just wanted to introduce a case where there was definitely an issue with = performance inefficiency and proposed a potential solution to the issue. = As said in an earlier email, I think its fair to say that an additional = document stating the use case and system level requirements can help = convince others of the issue that we address with the work. Thanks! :) -John On Sep 5, 2012, at 8:08 PM, JP Vasseur (jvasseur) wrote: >=20 > Fully agreeing with Phil; as RPL is being deployed and mature, we need = to be careful not to add anything that is not strongly > motivated by a concrete use case and requirements. Thanks for your = work. >=20 > JP. >=20 > On Sep 5, 2012, at 3:34 AM, JeongGil Ko wrote: >=20 >> Phil, >>=20 >> Thanks for your feedback. Nice idea with the additional informative = documentation. I will get together with the authors of the draft to = discuss and initiate an informative document. >>=20 >> Thanks! >>=20 >> -John >>=20 >>=20 >> On Sep 5, 2012, at 10:29 AM, Philip Levis wrote: >>=20 >>> In that case, you're the application that is the compelling use = case. eIt would be great if you could write a document that more = concretely lays out your arguments below; they seem sound to me, but one = short email seems insufficient to motivate a significant protocol = addition. A more detailed design document would also clearly specify the = constraints of the solution. For example, from your description below, = it sounds like complete mixed mode is unnecessary; instead, allowing = non-storing trees off of a storing network would be sufficient. It could = be that setup covers 99% of the mixed use cases, and it is much much = simpler than arbitrary compositions. >>>=20 >>> Phi >>>=20 >>> On Sep 4, 2012, at 5:36 PM, JeongGil Ko wrote: >>>=20 >>>> Phil, >>>>=20 >>>> With the RFC 6550, developers can build applications with storing = mode or not-storing mode nodes. In some cases they 'can' design systems = to be mixed, but since either one of the modes should act as a leaf = node, they may result in forming non-optimal routes (in both traffic = directions). >>>>=20 >>>> While it may not be a general application (I think it can be but = others may think differently), we are currently designing a system where = (relatively) resource-rich nodes act as sub-DODAG heads (I am using this = expression due to the lack of a better term) and a larger number of = resource-constraint nodes act as sensing units. Basically it's a network = with device heterogeneity and the two devices have their respective = tasks in the network. This doesn't necessarily mean that these resource = constraint nodes are always positioned physically at a corner of the = network to act as leaf nodes. The physical location of any of these = nodes can be at locations where by using it to forward packets, can = increase the efficiency of packet forwarding on the DODAG. Thus, but = forcing a set of nodes to be leaf nodes, we may miss a chance to have = more efficient routing paths. >>>>=20 >>>> In such a network, given RFC 6550, to make sure that the default = route performs at its optimal, a system designer needs to select between = the storing or non-storing mode (this is the only way we can have all = the nodes in the network capable of forwarding packets). First, since we = have memory constraints, we do not want the resource constraint nodes to = implement storing mode; thus, a full storing mode network is not an = option. On the other hand, implementing the entire network with = non-storing mode would be inefficient since packets would always have to = travel to the DODAG root for all downwards packets (not saying its not = going to work but less efficient). An alternative would be to implement = non-storing mode for nodes that cannot meet the heavier memory = requirements and for the nodes that can spare some space to store = routes... use the storing mode. This can help cut the stretch of the = packets that travel to non-root destinations. Networks with device = heterogeneity (a mix >>=20 >>> of powerful and 'dumb' nodes) can choose to use such 'mixed' network = configuration to preserve the upwards routing performance and also = perform downwards routing efficiently. The draft simply proposes a few = light weight changes that are required to make this happen. >>>>=20 >>>> I agree with you that if a proposal not realist nor useful in real = life, that it is meaningless (or less meaningful) to push the proposal = on the standards track. Nevertheless, I believe that we should make sure = that RPL can allow/tolerate for various network configurations so that = it is not the standards that is limiting the development of new systems. = My $0.02 :) >>>>=20 >>>> Thanks! >>>>=20 >>>> -John >>>>=20 >>>>=20 >>>> On Sep 5, 2012, at 1:17 AM, Philip Levis wrote: >>>>=20 >>>>>=20 >>>>> On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: >>>>>=20 >>>>>> Hi Philip, >>>>>>=20 >>>>>> I also think that RPL is complicated, for good reasons, but not = always >>>>>> complicated protocols should not be optimized or assisted by = others. >>>>>> However, new ideas and drafts are always recommended. >>>>>=20 >>>>>=20 >>>>> As an academic, I agree wholeheartedly. Also as an academic, I'd = argue that new ideas which do not have a strong application pull are the = province of research, not standardization. Our goal here is to = standardize practice for interoperability, not come up with new ideas. = But that's just my 2 cents. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>=20 >>>=20 >>> Phil >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From abdussalambaryun@gmail.com Sun Sep 9 14:55:50 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 B1BFA21F8596 for ; Sun, 9 Sep 2012 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeLGsHCW8F3u for ; Sun, 9 Sep 2012 14:55:50 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B36621F8595 for ; Sun, 9 Sep 2012 14:55:50 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so521938vcb.31 for ; Sun, 09 Sep 2012 14:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YVO1ud7wfw6DX0R/v/3sivSYkV1HwBBureTulFBTH4s=; b=gZ9oknM9CeyNQoIvRJMQ2vL3wKkpFXgN8ZHLFX+vz5LPwVMDSCdlhE2cEKtK2YgGsN 0f5yg1pB0LCBk3nKu/5Vj7D0DrR97CKpf0UbMI3MvSiaPk324sS+/0/RsXiDS4bhvVv4 j0bpn2WalJ5sdUwaYJu/NeLUDeB1h/YyscmLx1ELz5jtOjPruvIKjAKTxVC6Fj7LF9BI 7YFlAxONvZ1/3grA6t2etR+/WllhcjLktsCBWdHKRNa0MY3EGOZ0Go69Kjd62t20GQD+ VyojVJYUnW92+Cs9Wh8YQngqlypAgsvZEjBd/HySgmF3QnquSppdEczqdkUeSJIPc+S8 G0WA== MIME-Version: 1.0 Received: by 10.58.12.231 with SMTP id b7mr18231260vec.28.1347227749556; Sun, 09 Sep 2012 14:55:49 -0700 (PDT) Received: by 10.220.2.83 with HTTP; Sun, 9 Sep 2012 14:55:48 -0700 (PDT) In-Reply-To: References: <952CC507-2BA2-4005-B44A-0E40308E15AF@cisco.com> <1EEC52C7-5B67-459D-A579-D809F5426BD0@cs.stanford.edu> Date: Sun, 9 Sep 2012 23:55:48 +0200 Message-ID: From: Abdussalam Baryun To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] mixture of storing and non-storing nodes 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, 09 Sep 2012 21:55:50 -0000 On 9/4/12, Philip Levis wrote: > > On Sep 4, 2012, at 3:04 AM, Abdussalam Baryun wrote: >> I also think that RPL is complicated, for good reasons, but not always >> complicated protocols should not be optimized or assisted by others. >> However, new ideas and drafts are always recommended. > > As an academic, I agree wholeheartedly. Also as an academic, I'd argue that > new ideas which do not have a strong application pull are the province of > research, not standardization. Our goal here is to standardize practice for > interoperability, not come up with new ideas. But that's just my 2 cents. > I disagree that we only "standardize practice for interoperability", but we also standard to solve problems that face LLNs and RPL, by new ideas/protocols. For example, RPL is an IETF standard but still not fully in practice, yet was a good idea to standard. Furthermore, there are many deployment results not shown in IETF, but used by researchers or companies elsewhere. I am working on a new protocol to be standard by IETF because it will solve an important LLN routing problem. AB From esko.dijk@philips.com Mon Sep 10 04:43:03 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 43B1321F8668 for ; Mon, 10 Sep 2012 04:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3FSNtkwlwXX for ; Mon, 10 Sep 2012 04:43:02 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3B11621F8534 for ; Mon, 10 Sep 2012 04:43:02 -0700 (PDT) Received: from mail49-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Sep 2012 11:43:01 +0000 Received: from mail49-co1 (localhost [127.0.0.1]) by mail49-co1-R.bigfish.com (Postfix) with ESMTP id 2D599800E3; Mon, 10 Sep 2012 11:43:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -44 X-BigFish: VPS-44(zz217bL98dI15d6O9251J936eI103dK542M1432Izz1202h1d1ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h1155h) Received: from mail49-co1 (localhost.localdomain [127.0.0.1]) by mail49-co1 (MessageSwitch) id 1347277379495550_27597; Mon, 10 Sep 2012 11:42:59 +0000 (UTC) Received: from CO1EHSMHS027.bigfish.com (unknown [10.243.78.250]) by mail49-co1.bigfish.com (Postfix) with ESMTP id 761BC780042; Mon, 10 Sep 2012 11:42:59 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS027.bigfish.com (10.243.66.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Sep 2012 11:42:53 +0000 Received: from 011-DB3MMR1-014.MGDPHG.emi.philips.com (10.128.28.98) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.2.309.3; Mon, 10 Sep 2012 12:42:32 +0100 Received: from 011-DB3MPN2-083.MGDPHG.emi.philips.com ([169.254.3.124]) by 011-DB3MMR1-014.MGDPHG.emi.philips.com ([10.128.28.98]) with mapi id 14.02.0309.003; Mon, 10 Sep 2012 12:42:32 +0100 From: "Dijk, Esko" To: Dario Tedeschi Thread-Topic: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) Thread-Index: AQHNcaAmVDiypUQcCEeYvwAemcuHJ5dtsRIggAZoPwCAD4+3oA== Date: Mon, 10 Sep 2012 11:42:31 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618AEE87C@011-DB3MPN2-083.MGDPHG.emi.philips.com> References: <5871F86F-9CC3-4DBB-8778-9A9FFE0B6CB2@cisco.com> <031DD135F9160444ABBE3B0C36CED618AE0766@011-DB3MPN2-081.MGDPHG.emi.philips.com> <607772EC-5636-4C7C-9DF1-1DCDF9EF4E85@exegin.com> In-Reply-To: <607772EC-5636-4C7C-9DF1-1DCDF9EF4E85@exegin.com> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) 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, 10 Sep 2012 11:43:03 -0000 > The IPv6-in-IPv6 is needed so that the Trickle Multicast hop-by-hop optio= n can be removed > or inserted when a site-local (or higher) scoped multicast datagram leave= s or enters a RPL domain. Without encapsulation, also the hop-by-hop option can be inserted or remove= d into the header. In that case the IP destination address is indeed site-l= ocal or global scope, but I don't see a problem there - is there? (RPL take= s this approach and also the current Trickle Multicast draft.) Besides the benefit of this approach is that non-router nodes can also rece= ive the multicast at the correct address (e.g. a global scope multicast add= ress X they are listening for). > Secondly, IPv6-in-IPv6 should compress quite well using 6LoWPAN, because= the IPv6 addresses=20 > in the inner packet are elided from the IPv6 addresses in the outer heade= r. True, the outer (encapsulating) header can be small e.g. the 4 bytes I ment= ioned. But with the proposed encapsulation the IP source address (in the en= capsulated, inner header) is not usable anymore to indicate Seed ID so that= 's an additional 16 bytes lost.=20 Esko -----Original Message----- From: Dario Tedeschi [mailto:dat@exegin.com]=20 Sent: Friday 31 August 2012 16:41 To: Dijk, Esko Cc: Jonathan Hui (johui); roll@ietf.org Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) The IPv6-in-IPv6 is needed so that the Trickle Multicast hop-by-hop option = can be removed or inserted when a site-local (or higher) scoped multicast d= atagram leaves or enters a RPL domain. If a device doesn't require or expec= t highly scoped multicasts to leave the RPL domain it could choose to origi= nate a multicast datagram with a Trickle Multicast option and need not enca= psulate. However, in the interest of consistency, it would be better if all= nodes handled multicasts in the same way. Otherwise you end up with router= s having to support both tunnelled and non-tunneled multicasts, which gets = a bit complicated. Secondly, IPv6-in-IPv6 should compress quite well using 6LoWPAN, because t= he IPv6 addresses in the inner packet are elided from the IPv6 addresses in= the outer header. -Dario On 2012-08-27, at 6:45 , Dijk, Esko wrote: > Hello Jonathan, >=20 > great to see that this draft includes many improvements. However the adde= d overhead of the newly introduced IPv6-in-IPv6 encapsulation and the remov= al of the 0-byte "seed-id=3D=3DIPv6-source-address" option is worrying. For= example in a typical use in a 6LoWPAN 802.15.4 network, an extra 6LoWPAN I= PHC header is included (+4 bytes) and a seed-id (+16 bytes) field compared = to the same situation using the 'old' Trickle Multicast. >=20 > That's 20 bytes more overhead and space is already scarce. (With 2-byte s= eed-ids we can get this 20 down to 6 bytes, but that implies some seed-id a= ssignment process is needed which was not needed in Trickle Multicast.) >=20 > The reason is given as follows: >> IPv6-in-IPv6 encapsulation is necessary to support Path MTU discovery wh= en the MPL >> forwarder is not the source of the original multicast packet. IPv6- >> in-IPv6 encapsulation also allows an MPL forwarder to remove the MPL >> Option when forwarding the original multicast packet over a link that >> does not support MPL. > Why is Path MTU discovery necessary here? (Isn't it optional?) Sensible a= pplications would stay far, far away from the MTU size e.g. 1280 bytes in 6= LoWPAN, especially for multicast. > And why is encapsulation needed to support it? (Maybe there is a referenc= e that explains this?) >=20 > Is it possible to 'fix' the problem and use the compactness of the 'old' = (v00) packet format in the new draft? >=20 > best regards, > Esko >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of J= onathan Hui (johui) > Sent: Friday 3 August 2012 19:48 > To: roll@ietf.org > Subject: [Roll] draft-ietf-roll-trickle-mcast-02 (proposed text) >=20 >=20 > We've been working on an update to draft-ietf-roll-trickle-mcast. I've a= ttached a draft of the proposed text. Note that we will *not* be presentin= g this draft at the ROLL WG meeting. >=20 > In a prior mail, I noted some deficiencies with the initial draft that wa= s posted. We will discuss some of these deficiencies at the ROLL WG meetin= g today. The purpose of this mail is to give you some insight into solving= those deficiencies as well as incorporating suggestions that were brought = up on the list. If you get a chance to glance through before the WG meetin= g, great. In either case, let's continue the discussion on the list. >=20 > Always looking for your feedback, especially from implementors. >=20 > Thanks! >=20 > -- > Jonathan Hui >=20 >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wwwrun@rfc-editor.org Mon Sep 10 17:18:43 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 04DAB21F8731; Mon, 10 Sep 2012 17:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.358 X-Spam-Level: X-Spam-Status: No, score=-101.358 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7or3Cpf+kZ07; Mon, 10 Sep 2012 17:18:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0D721F872E; Mon, 10 Sep 2012 17:18:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67AD6B1E005; Mon, 10 Sep 2012 17:15:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120911001538.67AD6B1E005@rfc-editor.org> Date: Mon, 10 Sep 2012 17:15:38 -0700 (PDT) Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 6719 on The Minimum Rank with Hysteresis Objective Function 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, 11 Sep 2012 00:18:43 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6719 Title: The Minimum Rank with Hysteresis Objective Function Author: O. Gnawali, P. Levis Status: Standards Track Stream: IETF Date: September 2012 Mailbox: gnawali@cs.uh.edu, pal@cs.stanford.edu Pages: 13 Characters: 29637 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-minrank-hysteresis-of-11.txt URL: http://www.rfc-editor.org/rfc/rfc6719.txt The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function (MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPL Destination Information Object (DIO) messages advertise. [STANDARDS-TRACK] This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gnawali@cs.uh.edu Tue Sep 11 13:36:45 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 9DFD521F8713 for ; Tue, 11 Sep 2012 13:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7AzRfrLTwju for ; Tue, 11 Sep 2012 13:36:45 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 61E0821F8624 for ; Tue, 11 Sep 2012 13:36:40 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 84A7623CA8B for ; Tue, 11 Sep 2012 15:36:33 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjmmvvIa1xpQ for ; Tue, 11 Sep 2012 15:36:31 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 85F1F23CA8A for ; Tue, 11 Sep 2012 15:36:31 -0500 (CDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by it.cs.uh.edu (Postfix) with ESMTP id 3C45D2A280C3 for ; Tue, 11 Sep 2012 15:41:24 -0500 (CDT) Received: by vcbfo14 with SMTP id fo14so1378054vcb.31 for ; Tue, 11 Sep 2012 13:36:37 -0700 (PDT) Received: by 10.52.21.82 with SMTP id t18mr21868290vde.66.1347395797067; Tue, 11 Sep 2012 13:36:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.198.41 with HTTP; Tue, 11 Sep 2012 13:36:16 -0700 (PDT) In-Reply-To: <20120911092619.17893.9225.idtracker@ietfa.amsl.com> References: <20120911092619.17893.9225.idtracker@ietfa.amsl.com> From: Omprakash Gnawali Date: Tue, 11 Sep 2012 15:36:16 -0500 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-04.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: Tue, 11 Sep 2012 20:36:45 -0000 I added this text to the draft: 11. Prevent Situations That Make Nodes Leaf When different nodes in a single network run different OFs, have incompatible metrics, or run a mix of storing and non-storing modes[I-D.ko-roll-mix-network-pathology], the nodes may not join the DODAG or join as leaf nodes which do not extend DODAG connectivity as described in Section 8.5 of [RFC6550]. Thus, operating as a leaf node in the middle of a network can lead to network partitioning even though the network is physically connected. Generally avoid configurations that force some nodes to operate as leaf nodes even though the leaf nodes are at the physical edge of the network. Comments welcome. - om_p ---------- Forwarded message ---------- From: Date: Tue, Sep 11, 2012 at 4:26 AM Subject: New Version Notification for draft-gnawali-roll-rpl-recommendations-04.txt To: gnawali@cs.uh.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-rpl-recommendations-04.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: draft-gnawali-roll-rpl-recommendations Revision: 04 Title: Recommendations for Efficient Implementation of RPL Creation date: 2012-09-11 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-gnawali-roll-rpl-recommendations-04.txt Status: http://datatracker.ietf.org/doc/draft-gnawali-roll-rpl-recommendations Htmlized: http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-gnawali-roll-rpl-recommendations-04 Abstract: RPL is a flexible routing protocol applicable to a wide range of Low Power and Lossy Networks. To enable this wide applicability, RPL provides many configuration options and gives implementers choices on how to implement various components of RPL. Drawing on our experiences, we distill the design choices and configuration parameters that lead to efficient RPL implementations and operations. The IETF Secretariat From prvs=5967ffd52=Tzeta.Tsao@cooperindustries.com Wed Sep 12 17:58: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 BD1A921F859C for ; Wed, 12 Sep 2012 17:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiVn0sksM8jr for ; Wed, 12 Sep 2012 17:58:01 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 20EAD21F8570 for ; Wed, 12 Sep 2012 17:58:01 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.80,413,1344225600"; d="scan'208";a="68838926" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 12 Sep 2012 20:58:00 -0400 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Sep 2012 20:58:00 -0400 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: Wed, 12 Sep 2012 20:57:45 -0400 Message-ID: <85A23E0910B2FB4B8EF60D0888CB0836012FEB89@EVS2.nam.ci.root> In-Reply-To: <20120913005523.28191.64644.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-04.txt Thread-Index: Ac2RSnXxWcYpXP99QIOaKcitSHcydQAAAmBA References: <20120913005523.28191.64644.idtracker@ietfa.amsl.com> From: "Tsao, Tzeta" To: X-OriginalArrivalTime: 13 Sep 2012 00:58:00.0556 (UTC) FILETIME=[D24E32C0:01CD914A] Subject: [Roll] FW: New Version Notification fordraft-alexander-roll-mikey-lln-key-mgmt-04.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, 13 Sep 2012 00:58:01 -0000 V0csDQoNCldlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIG1pbm9yIGVkaXRvcmlhbCBjaGFu Z2VzLCB0byB0b3VjaCB0aGUgZGF0ZXMgYW5kIGluIHdhaXRpbmcgZm9yIHRoZSBXRydzIGZ1cnRo ZXIgaW5wdXQuDQoNClRoYW5rcywNClR6ZXRhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTIsIDIwMTIgODo1NSBQTQ0K VG86IFRzYW8sIFR6ZXRhDQpDYzogQWxleGFuZGVyLCBSb2dlcg0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdt dC0wNC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYWxleGFuZGVyLXJvbGwt bWlrZXktbGxuLWtleS1tZ210LTA0LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBUemV0YSBUc2FvIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmls ZW5hbWU6CSBkcmFmdC1hbGV4YW5kZXItcm9sbC1taWtleS1sbG4ta2V5LW1nbXQNClJldmlzaW9u OgkgMDQNClRpdGxlOgkJIEFkYXB0ZWQgTXVsdGltZWRpYSBJbnRlcm5ldCBLRVlpbmcgKEFNSUtF WSk6IEFuIGV4dGVuc2lvbiBvZiBNdWx0aW1lZGlhIEludGVybmV0IEtFWWluZyAoTUlLRVkpIE1l dGhvZHMgZm9yIEdlbmVyaWMgTExOIEVudmlyb25tZW50cw0KQ3JlYXRpb24gZGF0ZToJIDIwMTIt MDktMTINCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA0 Mg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1hbGV4YW5kZXItcm9sbC1taWtleS1sbG4ta2V5LW1nbXQtMDQudHh0DQpTdGF0dXM6ICAg ICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWxleGFuZGVyLXJv bGwtbWlrZXktbGxuLWtleS1tZ210DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWFsZXhhbmRlci1yb2xsLW1pa2V5LWxsbi1rZXktbWdtdC0wNA0KRGlm ZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1hbGV4 YW5kZXItcm9sbC1taWtleS1sbG4ta2V5LW1nbXQtMDQNCg0KQWJzdHJhY3Q6DQogICBNdWx0aW1l ZGlhIEludGVybmV0IEtleWluZyAoTUlLRVkpIGlzIGEga2V5IG1hbmFnZW1lbnQgcHJvdG9jb2wg dXNlZA0KICAgZm9yIHJlYWwtdGltZSBhcHBsaWNhdGlvbnMuICBBcyBzdGFuZGFyZGl6ZWQgd2l0 aGluIFJGQzM4MzAgaXQNCiAgIGRlZmluZXMgZm91ciBrZXkgZGlzdHJpYnV0aW9uIG1ldGhvZHMs IGluY2x1ZGluZyBwcmUtc2hhcmVkIGtleXMsDQogICBwdWJsaWMta2V5IGVuY3J5cHRpb24sIGFu ZCBEaWZmaWUtSGVsbG1hbiBrZXkgZXhjaGFuZ2UsIHdpdGgNCiAgIGFsbG93YW5jZXMgZm9yIHJl YWR5IHByb3RvY29sIGV4dGVuc2lvbi4gIEEgbnVtYmVyIG9mIGFkZGl0aW9uYWwNCiAgIG1ldGhv ZHMgaGF2ZSBiZWVuIGRldmVsb3BlZCBhbmQgY29udGludWUgdG8gYmUgYnVpbHQgZnJvbSB0aGUg YmFzZQ0KICAgcHJvdG9jb2wgKHNlZSBmb3IgZXhhbXBsZSwgUkZDNDQ0MiwgUkZDNDU2MywgUkZD NDY1MCwgUkZDNDczOCwNCiAgIFJGQzU0MTAsIFJGQzYwNDMgYW5kIFJGQzYyNjcuICBIb3dldmVy LCBpbiBzcGl0ZSBvZiBpdHMgZXh0ZW5zaWJpbGl0eQ0KICAgYW5kIG1vcmUgZ2VuZXJhbCBhcHBs aWNhYmlsaXR5LCBNSUtFWSBhbmQgaXRzIHJlbGF0ZWQgZXh0ZW5zaW9ucyBoYXZlDQogICBwcmlt YXJpbHkgZm9jdXNlZCBvbiB0aGUgc3VwcG9ydCBvZiB0aGUgU2VjdXJlIFJlYWwtdGltZSBUcmFu c3BvcnQNCiAgIFByb3RvY29sIChTUlRQKS4NCg0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMg YSBzaW1wbGUgYWRhcHRhdGlvbiBvZiB0aGUgTUlLRVkNCiAgIHNwZWNpZmljYXRpb24gdG8gYWxs b3cgdGhlIGJhc2UgcHJvdG9jb2wgYW5kIGl0cyB2YXJpb3VzIGtleQ0KICAgbWFuYWdlbWVudCBt b2RlIGV4dGVuc2lvbnMgdG8gYmUgcmVhZGlseSBhcHBsaWVkIGluIG1vcmUgZ2VuZXJhbA0KICAg ZW52aXJvbm1lbnRzIGJleW9uZCB0aGUgbXVsdGltZWRpYSBTUlRQIGRvbWFpbi4gIEluIHBhcnRp Y3VsYXIsIHRoZQ0KICAgZG9jdW1lbnQgZGVmaW5lcyBhIHJlcHVycG9zaW5nIG9mIHRoZSBNSUtF WSBtdWx0aW1lZGlhIGNyeXB0bw0KICAgc2Vzc2lvbnMgc3RydWN0dXJlIGFuZCBpbnRyb2R1Y2Vz IGEgc2V0IG9mIG1lc3NhZ2UgZXh0ZW5zaW9ucyB0byB0aGUNCiAgIGJhc2Ugc3BlY2lmaWNhdGlv biB0byBhbGxvdyB0aGUgTUlLRVkga2V5IG1hbmFnZW1lbnQgbWV0aG9kcyB0byBiZQ0KICAgYXBw bGllZCB3aXRoaW4gTG93LXBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTExOcykgYW5kIG90aGVy IGdlbmVyYWwNCiAgIGNvbnN0cmFpbmVkLWRldmljZSBuZXR3b3Jrcy4NCg0KDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From internet-drafts@ietf.org Mon Sep 17 00:48:24 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 D1C3421F846B; Mon, 17 Sep 2012 00:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eV6BIS659Pvo; Mon, 17 Sep 2012 00:48:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6272A21F846C; Mon, 17 Sep 2012 00:48:24 -0700 (PDT) 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: 4.34 Message-ID: <20120917074824.8597.68053.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 00:48:24 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-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: Mon, 17 Sep 2012 07:48:25 -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 networks= Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point R= oute in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-06.txt Pages : 20 Date : 2012-09-17 Abstract: This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-measurement-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-measurement-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=6009e54dc=mukul@uwm.edu Mon Sep 17 00:50: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 9805521F84A7 for ; Mon, 17 Sep 2012 00:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKrtrBh0-DAm for ; Mon, 17 Sep 2012 00:50:12 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id E88AF21F846C for ; Mon, 17 Sep 2012 00:50:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EACTVVlB/AAAB/2dsb2JhbABFhge5NQEBAQQBAQEgSzcEAQEDAg0ZAikmAggGEwmHdwuZSo5DiQKJB4EhigAbhTuBEgOIVo0MgRSPDYMEgXk Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 427AF120A79 for ; Mon, 17 Sep 2012 02:50:11 -0500 (CDT) X-Virus-Scanned: amavisd-new at Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTMsDCZipjjm for ; Mon, 17 Sep 2012 02:50:11 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 0EBAF1208BB for ; Mon, 17 Sep 2012 02:50:11 -0500 (CDT) Date: Mon, 17 Sep 2012 02:50:11 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <273992499.371290.1347868211029.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120917074824.8597.68053.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: I-D Action: draft-ietf-roll-p2p-measurement-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: Mon, 17 Sep 2012 07:50:12 -0000 Just minor IANA-related changes. Thanks Mukul ----- Forwarded Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Monday, September 17, 2012 2:48:24 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-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 : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-06.txt Pages : 20 Date : 2012-09-17 Abstract: This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-measurement-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-measurement-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From stoleru@cse.tamu.edu Thu Sep 20 11:54:17 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 F3EB421F86FF for ; Thu, 20 Sep 2012 11:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN643HFgZJKQ for ; Thu, 20 Sep 2012 11:54:13 -0700 (PDT) Received: from smtp.cs.tamu.edu (mailhost.cs.tamu.edu [128.194.138.107]) by ietfa.amsl.com (Postfix) with ESMTP id 28A9721F86EF for ; Thu, 20 Sep 2012 11:54:11 -0700 (PDT) Received: from [128.194.143.227] (radu-pc.cs.tamu.edu [128.194.143.227]) by smtp.cs.tamu.edu (Postfix) with ESMTP id 740AB9120 for ; Thu, 20 Sep 2012 13:54:11 -0500 (CDT) Message-ID: <505B665A.3010806@cse.tamu.edu> Date: Thu, 20 Sep 2012 13:54:18 -0500 From: Radu Stoleru User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [Roll] Call for Applications - SenSys 2012 Student Travel Grants 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, 20 Sep 2012 18:54:17 -0000 Please accept our apologies if you have received multiple copies of this announcement =================================================================== Call for Applications - SenSys 2012 Student Travel Grants With the support from the U.S. National Science Foundation (NSF), a limited number of Student Travel Grants is available. **************************************** Application Deadline: September 23, 2012 **************************************** For "Eligibility" and "How to Apply", please consult: http://sensys.acm.org/2012/Docs/StudentTravelGrant2012.pdf Under‐represented minority students, as well as students pursuing their graduate studies in Minority Serving Institutions are specifically encouraged to apply. From prvs=606e97eb4=stoleru@cse.tamu.edu Sat Sep 22 19:15:19 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 06D0921F8573 for ; Sat, 22 Sep 2012 19:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaPG0iv73FI2 for ; Sat, 22 Sep 2012 19:15:18 -0700 (PDT) Received: from os-mail-5.cis.tamu.edu (os-mail-5.tamu.edu [165.91.22.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1988F21F856C for ; Sat, 22 Sep 2012 19:15:17 -0700 (PDT) X-TAMU-Auth-ID: stoleru X-TAMU-SenderIP: 74.195.97.72 X-HAT: SG None, P $RELAY, L incoming_auth X-SRBS: None X-EXTLoop1: 74.195.97.72 X-IronPort-AV: E=Sophos;i="4.80,469,1344229200"; d="scan'208,217";a="6143285" From: Radu Stoleru Content-Type: multipart/alternative; boundary="Apple-Mail=_D567E9E6-D7D3-4425-AADE-AC83AE176839" Date: Sat, 22 Sep 2012 21:15:17 -0500 Message-Id: <8E76B5F1-13D7-4B2D-841B-F51B6DD0FD94@cse.tamu.edu> To: roll@ietf.org Mime-Version: 1.0 (Apple Message framework v1280) X-Mailer: Apple Mail (2.1280) Subject: [Roll] Call for Applications - ICNP 2012 Student Travel Grants 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, 23 Sep 2012 02:15:19 -0000 --Apple-Mail=_D567E9E6-D7D3-4425-AADE-AC83AE176839 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Call for Applications - ICNP 2012 Student Travel Grants With the support from the U.S. National Science Foundation (NSF), a = limited number of Student Travel Grants is available. ************************************************* Application Deadline: September 23, 2012 ************************************************** For "Eligibility" and "How to Apply", please consult: https://icnp12.cs.umd.edu/travel/index.html Under=E2=80=90represented minority students, as well as students = pursuing their graduate studies in Minority Serving Institutions are = specifically encouraged to apply. Student Travel Award Co=E2=80=90Chairs Tommaso Melodia, SUNY at Buffalo=20 Radu Stoleru, Texas A&M University= --Apple-Mail=_D567E9E6-D7D3-4425-AADE-AC83AE176839 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Call = for Applications - ICNP 2012 Student Travel Grants

With the = support from the U.S. National Science Foundation (NSF), a limited = number of Student Travel Grants is = available.

*************************************************
App= lication Deadline: September 23, = 2012
**************************************************

For = "Eligibility" and "How to Apply", please consult:

https://icnp12.cs.umd= .edu/travel/index.html

Under=E2=80=90represented minority = students, as well as students pursuing their graduate studies in = Minority Serving Institutions are specifically encouraged to = apply.


Student Travel Award Co=E2=80=90Chairs
Tommaso = Melodia, SUNY at Buffalo 
Radu Stoleru, Texas A&M = University= --Apple-Mail=_D567E9E6-D7D3-4425-AADE-AC83AE176839--