From samita.chakrabarti@ericsson.com Fri Apr 1 02:08:34 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044403A6774 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 02:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.123 X-Spam-Level: X-Spam-Status: No, score=-4.123 tagged_above=-999 required=5 tests=[AWL=2.476, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SK+mFU9pvmM for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 02:08:33 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 36BE63A6452 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 02:08:33 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p319ABpD029932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Apr 2011 04:10:12 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 1 Apr 2011 05:10:11 -0400 From: Samita Chakrabarti To: Carsten Bormann , 6lowpan WG <6lowpan@ietf.org> Date: Fri, 1 Apr 2011 05:10:10 -0400 Thread-Topic: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy Thread-Index: AcvvzKUzyYw80ybFSiSVpPISyhuSUAAfx20w Message-ID: <16D60F43CA0B724F8052D7E9323565D71919004C41@EUSAACMS0715.eamcs.ericsson.se> References: <1301488616.3846.752.camel@d430> <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> In-Reply-To: <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:08:34 -0000 =20 +1. -Samita On Mar 31, 2011, at 19:47, Carsten Bormann wrote: > It appears I was a bit quick dismissing BT-LE as a working group item dur= ing Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can very we= ll request the addition of milestones. As the support in the room for work= ing on the adaptation of 6LoWPAN for BT-LE was quite good, I'm now issuing = a call for WG adoption. >=20 > This is a call for working group adoption of=20 > draft-patil-6lowpan-v6over-btle-01.txt >=20 > Working group adoption does not mean we agree with every detail of the=20 > draft, but that we want to use it as the basis of further working=20 > group work. >=20 > Please reply to the list until >=20 > Friday, April 8, 23:59 UTC >=20 > with your position whether this document should be adopted or not. >=20 > Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From yoshihiro.ohba@toshiba.co.jp Fri Apr 1 02:18:39 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6587B3A67A2 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 02:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JADLjPolx9VF for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 02:18:38 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 5ED273A677C for <6lowpan@ietf.org>; Fri, 1 Apr 2011 02:18:38 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p319KHtl007089 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 18:20:17 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p319KHMa028801 for 6lowpan@ietf.org; Fri, 1 Apr 2011 18:20:17 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA28799; Fri, 1 Apr 2011 18:20:17 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p319KHd8027369 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 18:20:17 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p319KGRs022781; Fri, 1 Apr 2011 18:20:16 +0900 (JST) Received: from [133.199.75.216] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LIY00FTPV9Q8P20@mail.po.toshiba.co.jp> for 6lowpan@ietf.org; Fri, 01 Apr 2011 18:20:16 +0900 (JST) Date: Fri, 01 Apr 2011 18:20:07 +0900 From: Yoshihiro Ohba In-reply-to: <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> To: 6lowpan@ietf.org Message-id: <4D9598C7.8080901@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <1301488616.3846.752.camel@d430> <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:18:39 -0000 I support the BT-LE work. Yoshihiro Ohba (2011/04/01 2:53), Carsten Bormann wrote: >> Re: [6lowpan] WG adoption of 6lowpan Implementers guide > > That's what you get when you edit one message out of another. > It's been a long week... > Of course, this is about the BT-LE draft, not about the implementers guide. > Please make sure you reply with the subject of this message, in particular if it is just a "+1"... > > Sorry for the confusion, > Carsten > > On Mar 31, 2011, at 19:47, Carsten Bormann wrote: > >> It appears I was a bit quick dismissing BT-LE as a working group item during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can very well request the addition of milestones. As the support in the room for working on the adaptation of 6LoWPAN for BT-LE was quite good, I'm now issuing a call for WG adoption. >> >> This is a call for working group adoption of >> draft-patil-6lowpan-v6over-btle-01.txt >> >> Working group adoption does not mean we agree with every detail of the >> draft, but that we want to use it as the basis of further working group >> work. >> >> Please reply to the list until >> >> Friday, April 8, 23:59 UTC >> >> with your position whether this document should be adopted or not. >> >> Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Fri Apr 1 03:01:42 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECA93A67D4 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ldOrJSk5yL2 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:01:41 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 2DB463A67D3 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 03:01:41 -0700 (PDT) Received: by bwz13 with SMTP id 13so2601221bwz.31 for <6lowpan@ietf.org>; Fri, 01 Apr 2011 03:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xxWaN9mzqXKoByt6p04frBuAwAiLhZ9Co+NSnkj5GsE=; b=DIVPvi6fpnsQQgds7MEnb5p+3paHPjJN0J0c1bTADi5M1FimAinrhGeplZl4gbR5Wn Y11ns6J8s1r26GhvE9WIqRzm6VM1+111TZcCZv2TuaxmU9Q2DNgYp6Y89OY1WMQiYJUy ijnpuQAHs+r949FMHIDdNeAWmcdav/06WtnL8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=euIPv+XsHKsLtepO/yVLgMwnfGINrJDxvoB//3nB1L05KgjPiGgvbTCEavdNaNWq2a urUC7TEy/kgf8gTxGjNgqNYH42M1fIcK15PHatQF/qTiBWw6mUH+9ekVjIu9+UMlSKQS IANlpgJmpqx+RmFY40h5LbLAtHF9Vj0ocsS3k= Received: by 10.204.156.22 with SMTP id u22mr3432649bkw.100.1301652200833; Fri, 01 Apr 2011 03:03:20 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id q24sm1282477bks.9.2011.04.01.03.03.19 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 03:03:20 -0700 (PDT) Message-ID: <4D95A2E4.50609@gmail.com> Date: Fri, 01 Apr 2011 12:03:16 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carsten Bormann References: <1301488616.3846.752.camel@d430> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:01:42 -0000 http://www.ietf.org/id/draft-patil-6lowpan-v6over-btle-01.txt I think there is not much to be specified here. IPv6 runs ok over bluetooth interface, rfcs. It seems to me IMHO bt-le is just a new phy, but same mac, hence ip would not be affected. But of course, a document stating we do things over bt-le as usually as over bt, would not hurt. Is the WG re-opened? Alex Le 31/03/2011 19:47, Carsten Bormann a écrit : > It appears I was a bit quick dismissing BT-LE as a working group item > during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we > can very well request the addition of milestones. As the support in > the room for working on the adaptation of 6LoWPAN for BT-LE was quite > good, I'm now issuing a call for WG adoption. > > This is a call for working group adoption of > draft-patil-6lowpan-v6over-btle-01.txt > > Working group adoption does not mean we agree with every detail of > the draft, but that we want to use it as the basis of further working > group work. > > Please reply to the list until > > Friday, April 8, 23:59 UTC > > with your position whether this document should be adopted or not. > > Gruesse, Carsten > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Fri Apr 1 03:11:21 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC943A67E6 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPF-EGkbpRXs for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:11:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id B95C63A67A6 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 03:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p31ACqBf008222; Fri, 1 Apr 2011 12:12:52 +0200 (CEST) Received: from dhcp-9066.meeting.ietf.org (dhcp-9066.meeting.ietf.org [130.129.8.102]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4759AFD5; Fri, 1 Apr 2011 12:12:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4D95A2E4.50609@gmail.com> Date: Fri, 1 Apr 2011 12:12:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1082) Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:11:21 -0000 > It seems to me IMHO bt-le is just a new phy, but same mac, hence ip > would not be affected. =46rom the presentation, I had a different impression. > But of course, a document stating we do things over bt-le as usually = as > over bt, would not hurt. Actually, it is required, as RFC4944 and its updates only define 6LoWPAN = for IEEE 802.15.4. If two people took these documents and tried to apply them to BT-LE, = they wouldn't necessarily arrive at interoperable specifications. > Is the WG re-opened? No, it is alive and well until such a time when it is actually being = closed. All that was said is that the Prague meeting will be the last physical = meeting of the WG. We want to close our unfinished business, and a number of documents are = based on discussions that went on at least since Beijing, so if they fit = our charter and we have energy to work on them, there is no problem = doing that. Gruesse, Carsten From alexandru.petrescu@gmail.com Fri Apr 1 03:31:45 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B893A67E9 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.767 X-Spam-Level: X-Spam-Status: No, score=-3.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHz1A28ujV07 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:31:44 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 298633A67E6 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 03:31:43 -0700 (PDT) Received: by bwz13 with SMTP id 13so2620271bwz.31 for <6lowpan@ietf.org>; Fri, 01 Apr 2011 03:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H+/Cse1KDWt5A/TFXc+k0vpZsLc18aEvlvR/MqIrAiI=; b=vS0fCX/n8NvYvbr/eXjgPvYV29ND/lPWriJglEpYQYurWNVEKelp5PfAzMF2LR68x+ lcjHEtA/t1cevSsbC6N8bNMIHFualKZW6ualzWKo3myhThrQAf4HLmWY/FVv4BmbY9OG poc0/KXZ22THMe1a+5omeMchJLxkjjUZmCy64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KqJIag/wAT6VD4N3lMMzjz+GzkAjS6AQcNFc+uUwUbnfIFJMq/XIGr9qMYnOEMUJGf r45kXTAed5oMAARzxPEjlWGoVgi47Hw/tGuuGSpZinsytjDjKJQOEH0veJqgCzSRs4tA QONSSZSgxOnmLeY1u4LaOihtOemuacZZ+eDzc= Received: by 10.204.154.88 with SMTP id n24mr52353bkw.38.1301654003817; Fri, 01 Apr 2011 03:33:23 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id z18sm1302546bkf.8.2011.04.01.03.33.22 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 03:33:22 -0700 (PDT) Message-ID: <4D95A9EF.2080406@gmail.com> Date: Fri, 01 Apr 2011 12:33:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carsten Bormann References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> In-Reply-To: <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:31:45 -0000 Le 01/04/2011 12:12, Carsten Bormann a écrit : >> It seems to me IMHO bt-le is just a new phy, but same mac, hence ip >> would not be affected. > > From the presentation, I had a different impression. > >> But of course, a document stating we do things over bt-le as >> usually as over bt, would not hurt. > > Actually, it is required, as RFC4944 and its updates only define > 6LoWPAN for IEEE 802.15.4. If two people took these documents and > tried to apply them to BT-LE, they wouldn't necessarily arrive at > interoperable specifications. To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a marketing name. It seems sufficient to specify ipv6 over 802.15.4 and that would cover all variants of bluetooth. There is no ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example. I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 and rfc2460. >> Is the WG re-opened? > > No, it is alive and well until such a time when it is actually being > closed. All that was said is that the Prague meeting will be the last > physical meeting of the WG. We want to close our unfinished business, > and a number of documents are based on discussions that went on at > least since Beijing, so if they fit our charter and we have energy to > work on them, there is no problem doing that. sounds like doing new work without physical meetings... ok... Alex > > Gruesse, Carsten > From carlesgo@entel.upc.edu Fri Apr 1 03:40:50 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2DD3A67F3 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2EwWVisFqYx for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:40:50 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by core3.amsl.com (Postfix) with ESMTP id CE6C33A67ED for <6lowpan@ietf.org>; Fri, 1 Apr 2011 03:40:49 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p31AgRf6026673; Fri, 1 Apr 2011 12:42:27 +0200 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 9CB842CBD0D; Fri, 1 Apr 2011 12:42:22 +0200 (CEST) Received: from 83.50.67.65 by webmail.entel.upc.edu with HTTP; Fri, 1 Apr 2011 11:44:42 +0200 (CEST) Message-ID: <52947.83.50.67.65.1301651082.squirrel@webmail.entel.upc.edu> In-Reply-To: <4D95A9EF.2080406@gmail.com> References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> <4D95A9EF.2080406@gmail.com> Date: Fri, 1 Apr 2011 11:44:42 +0200 (CEST) From: "Carles Gomez Montenegro" To: "Alexandru Petrescu" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Fri, 01 Apr 2011 12:42:28 +0200 (CEST) Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:40:50 -0000 Hi Alex, > To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a marketing > name. It seems sufficient to specify ipv6 over 802.15.4 and that would > cover all variants of bluetooth. There is no ipv6-over-802.11n, nor > ipv6-over-wifilowpower, for example. > > I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 and > rfc2460. Are you maybe referring to 802.15.1 instead of 802.15.4? (Btw, only some of the first Bluetooth versions were ratified as parts of 802.15.1) All the best, Carles From johanna.1.nieminen@nokia.com Fri Apr 1 03:47:25 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87A5C3A67E1 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0r6o0H2rxqj for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 03:47:24 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id AF4403A67D3 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 03:47:24 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p31Amaf9015383; Fri, 1 Apr 2011 13:49:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 13:48:45 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 1 Apr 2011 12:48:44 +0200 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 12:48:38 +0200 From: To: , Thread-Topic: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-0 1.txt Thread-Index: AQHL8FpbPwaOwcVfmk2MePYwCi1T7Q== Date: Fri, 1 Apr 2011 10:48:38 +0000 Message-ID: References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org>, <4D95A9EF.2080406@gmail.com> In-Reply-To: <4D95A9EF.2080406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2011 10:48:45.0571 (UTC) FILETIME=[5FD50530:01CBF05A] X-Nokia-AV: Clean Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-0 1.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:47:25 -0000 Hi, There are major differences between 802.15.4 and bt-le in the link and phy = layers, topology etc. In fact, there are major differences between Bt and B= t-le as well. 802.15.4 can not be considered as a generalization of Blueto= oth modifications. Johanna --- alkuper=E4inen viesti --- L=E4hett=E4j=E4: "ext Alexandru Petrescu" Aihe: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt P=E4iv=E4m=E4=E4r=E4: 1. huhtikuuta 2011 Aika: 12:33:43 Le 01/04/2011 12:12, Carsten Bormann a =E9crit : >> It seems to me IMHO bt-le is just a new phy, but same mac, hence ip >> would not be affected. > > From the presentation, I had a different impression. > >> But of course, a document stating we do things over bt-le as >> usually as over bt, would not hurt. > > Actually, it is required, as RFC4944 and its updates only define > 6LoWPAN for IEEE 802.15.4. If two people took these documents and > tried to apply them to BT-LE, they wouldn't necessarily arrive at > interoperable specifications. To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a marketing name. It seems sufficient to specify ipv6 over 802.15.4 and that would cover all variants of bluetooth. There is no ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example. I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 and rfc2460. >> Is the WG re-opened? > > No, it is alive and well until such a time when it is actually being > closed. All that was said is that the Prague meeting will be the last > physical meeting of the WG. We want to close our unfinished business, > and a number of documents are based on discussions that went on at > least since Beijing, so if they fit our charter and we have energy to > work on them, there is no problem doing that. sounds like doing new work without physical meetings... ok... Alex > > Gruesse, Carsten > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From Basavaraj.Patil@nokia.com Fri Apr 1 04:14:57 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A49E3A67FA for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 04:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWu4dH17DvfL for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 04:14:56 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 116E23A67F3 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 04:14:55 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p31BGX8j022692; Fri, 1 Apr 2011 14:16:34 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 14:16:32 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 1 Apr 2011 13:16:33 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 13:16:32 +0200 From: To: , Thread-Topic: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Thread-Index: AQHL8FQObVKPa1Q8B0etKyeYMvGmppRIZn2A Date: Fri, 1 Apr 2011 11:16:31 +0000 Message-ID: In-Reply-To: <4D95A2E4.50609@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [130.129.83.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0F7CD1A27F59764E9A89EBCEE82EE220@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2011 11:16:32.0955 (UTC) FILETIME=[41ABA0B0:01CBF05E] X-Nokia-AV: Clean Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:14:57 -0000 Inline: On 4/1/11 5:03 AM, "ext Alexandru Petrescu" wrote: >http://www.ietf.org/id/draft-patil-6lowpan-v6over-btle-01.txt > >I think there is not much to be specified here. Disagree. > >IPv6 runs ok over bluetooth interface, rfcs. BT-LE is !=3D Classic BT This is what was clearly stated and explained in the presentation. > >It seems to me IMHO bt-le is just a new phy, but same mac, hence ip >would not be affected. Not true again. When you go into the details of the Phy/Mac for BT-LE you will see that it is a completely new air interface. The use cases for BT-LE are completely different from classic BT. Obviously we cannot discuss the Phy/Mac details in-depth at an IETF meeting given the 10 mins of time. And what we are specifying here is how to run IPv6 using 6lowpan techniques over an air-interface that is low-power. -Raj > >But of course, a document stating we do things over bt-le as usually as >over bt, would not hurt. > >Is the WG re-opened? > >Alex > >Le 31/03/2011 19:47, Carsten Bormann a =E9crit : >> It appears I was a bit quick dismissing BT-LE as a working group item >> during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we >> can very well request the addition of milestones. As the support in >> the room for working on the adaptation of 6LoWPAN for BT-LE was quite >> good, I'm now issuing a call for WG adoption. >> >> This is a call for working group adoption of >> draft-patil-6lowpan-v6over-btle-01.txt >> >> Working group adoption does not mean we agree with every detail of >> the draft, but that we want to use it as the basis of further working >> group work. >> >> Please reply to the list until >> >> Friday, April 8, 23:59 UTC >> >> with your position whether this document should be adopted or not. >> >> Gruesse, Carsten >> >> _______________________________________________ 6lowpan mailing list >> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From Basavaraj.Patil@nokia.com Fri Apr 1 04:15:36 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3025D3A67FA for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 04:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.088 X-Spam-Level: X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5i3754fxH0Os for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 04:15:35 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id BD5DA3A67F3 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 04:15:34 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p31BGCLx016880; Fri, 1 Apr 2011 14:17:11 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 14:17:00 +0300 Received: from 008-AM1MMR1-005.mgdnok.nokia.com (65.54.30.60) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 1 Apr 2011 13:17:00 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 13:16:59 +0200 From: To: , Thread-Topic: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Thread-Index: AQHL8FQObVKPa1Q8B0etKyeYMvGmppRIqIYAgAAFuYD//7hhAA== Date: Fri, 1 Apr 2011 11:16:59 +0000 Message-ID: In-Reply-To: <4D95A9EF.2080406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [130.129.83.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <46C3E10E2A2C364CA76AE2613CD2838B@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2011 11:17:00.0791 (UTC) FILETIME=[52431070:01CBF05E] X-Nokia-AV: Clean Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:15:36 -0000 There is a world of difference between 802.15.4 and BT-LE. On 4/1/11 5:33 AM, "ext Alexandru Petrescu" wrote: >Le 01/04/2011 12:12, Carsten Bormann a =E9crit : >>> It seems to me IMHO bt-le is just a new phy, but same mac, hence ip >>> would not be affected. >> >> From the presentation, I had a different impression. >> >>> But of course, a document stating we do things over bt-le as >>> usually as over bt, would not hurt. >> >> Actually, it is required, as RFC4944 and its updates only define >> 6LoWPAN for IEEE 802.15.4. If two people took these documents and >> tried to apply them to BT-LE, they wouldn't necessarily arrive at >> interoperable specifications. > >To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a marketing >name. It seems sufficient to specify ipv6 over 802.15.4 and that would >cover all variants of bluetooth. There is no ipv6-over-802.11n, nor >ipv6-over-wifilowpower, for example. > >I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 and >rfc2460. > >>> Is the WG re-opened? >> >> No, it is alive and well until such a time when it is actually being >> closed. All that was said is that the Prague meeting will be the last >> physical meeting of the WG. We want to close our unfinished business, >> and a number of documents are based on discussions that went on at >> least since Beijing, so if they fit our charter and we have energy to >> work on them, there is no problem doing that. > >sounds like doing new work without physical meetings... ok... > >Alex > >> >> Gruesse, Carsten >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Fri Apr 1 04:39:46 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2CF3A6806 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 04:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGj9bNjV+acP for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 04:39:45 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9C6893A6805 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 04:39:45 -0700 (PDT) Received: by bwz13 with SMTP id 13so2662572bwz.31 for <6lowpan@ietf.org>; Fri, 01 Apr 2011 04:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TsoJBJosVtKVtzhDDdSJCAAx1Y0RWKw3ROB9M5C2clM=; b=mptYtrVDltVfyrGWL4SPGR/Zo9IBKaGl1j0CNfJaoDNCGpG/LTEt2KbLEsQ9nDa1ij xcEmRwZ/kP8IlIN/pvzmtuyd4H9dWRxZSmbn7VFUwFa81Y4s+zOOIKYq7jg7VrfeNr+U dDkw1O9qBXJzToi6AJLjXLUWW5/WAte//cp90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=J5VZm/EozD7vTCjH7f3VcXg8eI6/NzeEuXYv2utBejVROZhb8BHIOpPSbr2zoaJZZc Af2YpT2TemJ4C/7grSe80iP2zpnL0hCf69szDWxEMfvQMWxV3h3dpxCh7ON7qlmnLqP2 +cvK0VGOVL//4eIsdZ/A7jxyYPzGRMu0Sn+e4= Received: by 10.204.227.193 with SMTP id jb1mr31022bkb.157.1301658085358; Fri, 01 Apr 2011 04:41:25 -0700 (PDT) Received: from [127.0.0.1] (dhcp-150a.meeting.ietf.org [130.129.21.10]) by mx.google.com with ESMTPS id t1sm1341780bkx.19.2011.04.01.04.41.23 (version=SSLv3 cipher=OTHER); Fri, 01 Apr 2011 04:41:24 -0700 (PDT) Message-ID: <4D95B9DF.3030309@gmail.com> Date: Fri, 01 Apr 2011 13:41:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: cabo@tzi.org, 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:39:46 -0000 Le 01/04/2011 13:16, Basavaraj.Patil@nokia.com a écrit : > > There is a world of difference between 802.15.4 and BT-LE. yes, but I mean from the standpoint of IP. Is the MAC address format different between bt and bt-le? (including format of multicast addresses) Is the bt-le mac still doing reassembly (as bt does) thus accept the same minimal mtu as bt, i.e.1280bytes? Is bt-le still a multicast-capable link layer, like bt is? Alex > > On 4/1/11 5:33 AM, "ext Alexandru > Petrescu" wrote: > >> Le 01/04/2011 12:12, Carsten Bormann a écrit : >>>> It seems to me IMHO bt-le is just a new phy, but same mac, >>>> hence ip would not be affected. >>> >>> From the presentation, I had a different impression. >>> >>>> But of course, a document stating we do things over bt-le as >>>> usually as over bt, would not hurt. >>> >>> Actually, it is required, as RFC4944 and its updates only define >>> 6LoWPAN for IEEE 802.15.4. If two people took these documents >>> and tried to apply them to BT-LE, they wouldn't necessarily >>> arrive at interoperable specifications. >> >> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a >> marketing name. It seems sufficient to specify ipv6 over 802.15.4 >> and that would cover all variants of bluetooth. There is no >> ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example. >> >> I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 >> and rfc2460. >> >>>> Is the WG re-opened? >>> >>> No, it is alive and well until such a time when it is actually >>> being closed. All that was said is that the Prague meeting will >>> be the last physical meeting of the WG. We want to close our >>> unfinished business, and a number of documents are based on >>> discussions that went on at least since Beijing, so if they fit >>> our charter and we have energy to work on them, there is no >>> problem doing that. >> >> sounds like doing new work without physical meetings... ok... >> >> Alex >> >>> >>> Gruesse, Carsten >>> >> >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > From robert.cragie@gridmerge.com Fri Apr 1 05:18:15 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF68E28C9BD for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 05:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj5gnyvVO5CP for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 05:18:14 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id CD49028C753 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 05:14:05 -0700 (PDT) Received: from client-86-29-238-141.pete.adsl.virginmedia.com ([86.29.238.141] helo=[192.168.1.80]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) id 1Q5dGQ-00060e-Ix for 6lowpan@ietf.org; Fri, 01 Apr 2011 13:15:43 +0100 Message-ID: <4D95C1E9.1070901@gridmerge.com> Date: Fri, 01 Apr 2011 13:15:37 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4D95B9DF.3030309@gmail.com> In-Reply-To: <4D95B9DF.3030309@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060108050803070203040009" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:18:15 -0000 This is a cryptographically signed message in MIME format. --------------ms060108050803070203040009 Content-Type: multipart/alternative; boundary="------------010302010405080103060209" This is a multi-part message in MIME format. --------------010302010405080103060209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alex, RFC4944 and 6lowpan-hc form an adaptation layer between IPv6 and,=20 currently, 802.15.4. To be clear: BT BR/EDR is not 802.15.4 BT LE is not 802.15.4 BT BR/EDR is not BT LE (MAC or PHY) So each MAC/PHY needs its own considerations when it comes to an=20 adaptation layer. My feeling is that many concepts could be abstracted=20 and maybe written in a common document but ultimately, there will be=20 three different adaptation layers. Also "bluetooth is to 802.15.4 what wifi is to 802.11" - completely=20 wrong comparison. Bluetooth has nothing to do with 802.15.4. Robert On 01/04/2011 12:41 PM, Alexandru Petrescu wrote: > Le 01/04/2011 13:16, Basavaraj.Patil@nokia.com a =E9crit : >> >> There is a world of difference between 802.15.4 and BT-LE. > > yes, but I mean from the standpoint of IP. > > Is the MAC address format different between bt and bt-le? (including > format of multicast addresses) > > Is the bt-le mac still doing reassembly (as bt does) thus accept the > same minimal mtu as bt, i.e.1280bytes? > > Is bt-le still a multicast-capable link layer, like bt is? > > Alex > > >> >> On 4/1/11 5:33 AM, "ext Alexandru >> Petrescu" wrote: >> >>> Le 01/04/2011 12:12, Carsten Bormann a =E9crit : >>>>> It seems to me IMHO bt-le is just a new phy, but same mac, >>>>> hence ip would not be affected. >>>> >>>> From the presentation, I had a different impression. >>>> >>>>> But of course, a document stating we do things over bt-le as >>>>> usually as over bt, would not hurt. >>>> >>>> Actually, it is required, as RFC4944 and its updates only define >>>> 6LoWPAN for IEEE 802.15.4. If two people took these documents >>>> and tried to apply them to BT-LE, they wouldn't necessarily >>>> arrive at interoperable specifications. >>> >>> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a >>> marketing name. It seems sufficient to specify ipv6 over 802.15.4 >>> and that would cover all variants of bluetooth. There is no >>> ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example. >>> >>> I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 >>> and rfc2460. >>> >>>>> Is the WG re-opened? >>>> >>>> No, it is alive and well until such a time when it is actually >>>> being closed. All that was said is that the Prague meeting will >>>> be the last physical meeting of the WG. We want to close our >>>> unfinished business, and a number of documents are based on >>>> discussions that went on at least since Beijing, so if they fit >>>> our charter and we have energy to work on them, there is no >>>> problem doing that. >>> >>> sounds like doing new work without physical meetings... ok... >>> >>> Alex >>> >>>> >>>> Gruesse, Carsten >>>> >>> >>> _______________________________________________ 6lowpan mailing >>> list 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --------------010302010405080103060209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

RFC4944 and 6lowpan-hc form an adaptation layer between IPv6 and, currently, 802.15.4. To be clear:

BT BR/EDR is not 802.15.4
BT LE is not 802.15.4
BT BR/EDR is not BT LE (MAC or PHY)

So each MAC/PHY needs its own considerations when it comes to an adaptation layer. My feeling is that many concepts could be abstracted and maybe written in a common document but ultimately, there will be three different adaptation layers.

Also "bluetooth is to 802.15.4 what wifi is to 802.11" - completely wrong comparison. Bluetooth has nothing to do with 802.15.4.

Robert

On 01/04/2011 12:41 PM, Alexandru Petrescu wrote:
Le 01/04/2011 13:16, Basavaraj.Patil@nokia.com a écr= it :

There is a world of difference between 802.15.4 and BT-LE.

yes, but I mean from the standpoint of IP.

Is the MAC address format different between bt and bt-le? (including
format of multicast addresses)

Is the bt-le mac still doing reassembly (as bt does) thus accept the
same minimal mtu as bt, i.e.1280bytes?

Is bt-le still a multicast-capable link layer, like bt is?

Alex



On 4/1/11 5:33 AM, "ext Alexandru
Petrescu"<alexandru.petrescu@gmail.com> wrote:

Le 01/04/2011 12:12, Carsten Bormann a écrit :
It seems to me IMHO bt-le is just a= new phy, but same mac,
hence ip would not be affected.

From the presentation, I had a different impression.

But of course, a document stating w= e do things over bt-le as
usually as over bt, would not hurt.

Actually, it is required, as RFC4944 and its updates only define
6LoWPAN for IEEE 802.15.4. If two people took these documents
and tried to apply them to BT-LE, they wouldn't necessarily
arrive at interoperable specifications.

To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a
marketing name.  It seems sufficient to specify ipv6 over 802.15.4
and that would cover all variants of bluetooth.  There is = no
ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example.

I may be wrong though about bluetooth being mostly 802.15.4 rfc4944
and rfc2460.

Is the WG re-opened?

No, it is alive and well until such a time when it is actually
being closed. All that was said is that the Prague meeting will
be the last physical meeting of the WG. We want to close our
unfinished business, and a number of documents are based on
discussions that went on at least since Beijing, so if they fit
our charter and we have energy to work on them, there is no
problem doing that.

sounds like doing new work without physical meetings... ok...

Alex


Gruesse, Carsten


_______________________________________________ 6lowpan mailing
list 6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan<= /a>


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

--------------010302010405080103060209-- --------------ms060108050803070203040009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIREjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIGPjCCBSagAwIBAgIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEX MBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29y azEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAw WhcNMTEwODMwMjM1OTU5WjCB5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQ RVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIw MDMgQ29tb2RvIExpbWl0ZWQxFjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0B CQEWG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALQCfpvU4Hd5YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1ut iDsDQqvWnt1cHgZb4N1FFbvLqV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdw lObJ1ol4FUWnFPB/A7/liT7G+FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1w gm4SRHIv7VJfgseNKQd5u55RHQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRF bWyoPEgAmGYXRwsdvmUkq8W2wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEA AaOCAh0wggIZMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRp GoTqjgTJPeVwG/HaXEXWnn/AGDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNV HSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1Ud IAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNv bW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2Eu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRp Y2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDov L2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5jb21vZG9jYS5jb20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneI VKHrpx4LJImjCEGNinH6G+PDrs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrW t5NMbwbotDQLTq0gXW6guL4ICyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV 3gmBbDPh3PVTyGfnAGOyUBSRCvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHG NnR+CZAx+qXTczLc8pL7DtDXokR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6 HSg520a9rfVXa1NqMIIGPjCCBSagAwIBAgIRALZcFI008b3qkGPLKBbwWBIwDQYJKoZIhvcN AQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMTAwODMwMDAwMDAwWhcNMTEwODMwMjM1OTU5WjCB 5DE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFU RUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5j b21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQx FjAUBgNVBAMTDVJvYmVydCBDcmFnaWUxKjAoBgkqhkiG9w0BCQEWG3JvYmVydC5jcmFnaWVA Z3JpZG1lcmdlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALQCfpvU4Hd5 YvAYACEbYRrbYd2HAm4Sz43wHJwynBBkq5GamqO/SYNrg1utiDsDQqvWnt1cHgZb4N1FFbvL qV84A0f4xc+EtWTZNYn+lfUBIsgR3RNajFEHnsrXnZN6sPdwlObJ1ol4FUWnFPB/A7/liT7G +FmAB+DAc2iTCNjfxOVxhmKShY/b8ZxIkO4fN418cNxHtq1wgm4SRHIv7VJfgseNKQd5u55R HQEmPgN7aiSyIhvAK4H9Pm1msZrklIoSqGpIR0K7gMpVmPRFbWyoPEgAmGYXRwsdvmUkq8W2 wCkr9HA5NNL0D74B+RhIus0gfUL6lgnQR/6y9F31eY0CAwEAAaOCAh0wggIZMB8GA1UdIwQY MBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRpGoTqjgTJPeVwG/HaXEXWnn/A GDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYL KwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQEC AQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNV HR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3Qt Q2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3Js MGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20v VVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wJgYDVR0RBB8wHYEbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQA3I0iUCoFSHw/yM7Ra4cdmKkfZirA7N12pCneIVKHrpx4LJImjCEGNinH6G+PD rs632O96zXzaGqq+S2cA3lX5TJ2XdKz3EwPawB6uZf6sHUrWt5NMbwbotDQLTq0gXW6guL4I Cyrmb6EdqO5km8UkgWR7lSzm8fxORPg+X41gu33zb6/cv7hV3gmBbDPh3PVTyGfnAGOyUBSR CvzbrYtkByCMXUfdTdrx7jV1iD0TjxTJe8vJbTv3zjcIcTHGNnR+CZAx+qXTczLc8pL7DtDX okR5zZUuCgPGg/UWgUfBTUB6vibrAtrX9danRwaR61QCu3R6HSg520a9rfVXa1NqMYIEYDCC BFwCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0 cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBB dXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMAkGBSsOAwIaBQCg ggJwMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQwMTEy MTUzN1owIwYJKoZIhvcNAQkEMRYEFL50E6nVwg1Dn+d7V4ghWRhWDKmDMF8GCSqGSIb3DQEJ DzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAtlwUjTTxveqQY8soFvBYEjCB1wYLKoZIhvcNAQkQAgsxgceggcQw ga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkx HjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBjyygW8FgSMA0GCSqGSIb3DQEBAQUABIIBAJtk kCdijZwB2Is4bOEL/CPpdheYy6Zf4zaiasEmLAaT6KGcf7dx9xqQhQ9uDzy+O16Ecd4ok1Fm TSkT6Uyms6ZoVGNQod9VrK2dD8xtJBlad5uljO3IWXKojhP68+bv6X3D1HnrJifdg4Y9KQuH 4s+cfn5KAUOj2EodvUo23u2fQfmp3Xy3//VNrpeAm6HLg6GFjkBb2A++0T3Q5P9dDw7cK4Mm ynXBL/SMrYZEMVl5TSE145PghDG0bcR6M2SRA5rxENaV7qrI9QmhKD1pYS81HpXi1a94NcJs 18NPyB4kYkvb1kNNmC1Qko8VVZ8PsEdCkeDKJcoFRHDCs1i2JPoAAAAAAAA= --------------ms060108050803070203040009-- From zach@sensinode.com Fri Apr 1 05:23:59 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815CB28C35B for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 05:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IPwB+xeSQEp for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 05:23:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8BD3E28DDFF for <6lowpan@ietf.org>; Fri, 1 Apr 2011 05:17:34 -0700 (PDT) Received: from [192.168.1.44] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p31CJALG000642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Apr 2011 15:19:10 +0300 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-204--916879271; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> Date: Fri, 1 Apr 2011 15:19:11 +0300 Message-Id: <09E0F2D8-7554-4009-9781-27C44892BA60@sensinode.com> References: <1301488616.3846.752.camel@d430> <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1082) Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:24:00 -0000 --Apple-Mail-204--916879271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 (co-author hat off) This is sufficiently different from 802.15.4 and without specification = hard to make interoperable between vendors. Furthermore, I believe = having a specification for 6lowpan over (something other than 802.15.4) = will be a great thing for the whole community. Zach=20 On Mar 31, 2011, at 8:53 PM, Carsten Bormann wrote: > On Mar 31, 2011, at 19:47, Carsten Bormann wrote: >=20 >> It appears I was a bit quick dismissing BT-LE as a working group item = during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can = very well request the addition of milestones. As the support in the = room for working on the adaptation of 6LoWPAN for BT-LE was quite good, = I'm now issuing a call for WG adoption. >>=20 >> This is a call for working group adoption of >> draft-patil-6lowpan-v6over-btle-01.txt >>=20 >> Working group adoption does not mean we agree with every detail of = the >> draft, but that we want to use it as the basis of further working = group >> work. >>=20 >> Please reply to the list until >>=20 >> Friday, April 8, 23:59 UTC >>=20 >> with your position whether this document should be adopted or not. >>=20 >> Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-204--916879271 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQwMTEyMTkx MVowIwYJKoZIhvcNAQkEMRYEFN0ZfzRGNskFZ05suKGpYgDLamxPMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAAjeNfbyzhOkHYBgtYz27BecKeKAP7cMsIfbf3+2CeJFTbK1cAR119Ro yc39bLj0DbiREApKAhMSsYjhp6sYn2NfcN2K96+JMhl2yuZES2HnBR5i3mOciiCJcSfceS949M8p ti0kmlviSzINZOSxopIdhLfv6XbWrD3uEjcAZnA77V78AJboqoYmuag44uR4D+cKnZKSGfQPBD2C RP8eOKXsUW0h/DAOu95uXWiBM37jxw2tkKvxOMeaFwwlbtdIu9i46KsCDUpaIPu2uP4IURNzpVyw GoEtFnEJfXRLdl0FgQBXpo5q9zSKpFWkM7f/P4FNIIEJTSugYdp8BFJpYpwAAAAAAAA= --Apple-Mail-204--916879271-- From Basavaraj.Patil@nokia.com Fri Apr 1 05:39:14 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F9E3A6876 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW99mD1V7+bi for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 05:39:13 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id B6E5D3A688A for <6lowpan@ietf.org>; Fri, 1 Apr 2011 05:38:40 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p31CeJ9e025121; Fri, 1 Apr 2011 15:40:20 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 15:40:18 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 1 Apr 2011 14:40:05 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 14:40:01 +0200 From: To: , <6lowpan@ietf.org> Thread-Topic: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy Thread-Index: AQHL8GnrPaCfkY59kU+8mE8FJgfvPw== Date: Fri, 1 Apr 2011 12:40:01 +0000 Message-ID: In-Reply-To: <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [130.129.83.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2011 12:40:18.0063 (UTC) FILETIME=[F4DE41F0:01CBF069] X-Nokia-AV: Clean Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:39:14 -0000 +1 (if I-D editor view counts) On 3/31/11 12:53 PM, "ext Carsten Bormann" wrote: >> Re: [6lowpan] WG adoption of 6lowpan Implementers guide > >That's what you get when you edit one message out of another. >It's been a long week... >Of course, this is about the BT-LE draft, not about the implementers >guide. >Please make sure you reply with the subject of this message, in >particular if it is just a "+1"... > >Sorry for the confusion, >Carsten > >On Mar 31, 2011, at 19:47, Carsten Bormann wrote: > >> It appears I was a bit quick dismissing BT-LE as a working group item >>during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can >>very well request the addition of milestones. As the support in the >>room for working on the adaptation of 6LoWPAN for BT-LE was quite good, >>I'm now issuing a call for WG adoption. >>=20 >> This is a call for working group adoption of >> draft-patil-6lowpan-v6over-btle-01.txt >>=20 >> Working group adoption does not mean we agree with every detail of the >> draft, but that we want to use it as the basis of further working group >> work. >>=20 >> Please reply to the list until >>=20 >> Friday, April 8, 23:59 UTC >>=20 >> with your position whether this document should be adopted or not. >>=20 >> Gruesse, Carsten > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From behcetsarikaya@yahoo.com Fri Apr 1 07:18:35 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A1A63A67FA for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A388o6CMM9JB for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 07:18:33 -0700 (PDT) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by core3.amsl.com (Postfix) with SMTP id 278E63A6862 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 07:18:33 -0700 (PDT) Received: from [98.139.91.63] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 01 Apr 2011 14:20:13 -0000 Received: from [98.139.91.4] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 01 Apr 2011 14:20:13 -0000 Received: from [127.0.0.1] by omp1004.mail.sp2.yahoo.com with NNFMP; 01 Apr 2011 14:20:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 784981.34105.bm@omp1004.mail.sp2.yahoo.com Received: (qmail 25375 invoked by uid 60001); 1 Apr 2011 14:20:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1301667612; bh=1rDu428cfVJ+5mE5gTSX0MM6ouUhsxV3u+qc76ciiYM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MPS2uAeRLvJn2zuMPneCkBZzLaabQ7Ww7E4om7+1Lx+RmleKXm0aQ3DXBASlGPx9CWaOs20iAajDPeCnXOE4+In1tVY7b5aIvrN8wvZn3vGE0RTRmz19AuEGFGFm5FG2qlSfi6Zf6OPeprZBqIwVDlIZgo6cD8SIxC2rWtl2HCY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1h8xQDcu3Grwkwdqeo4S7VTiwtfz2ckEk3V6gRhBDQehixeIt5pBIKCcigG5MQ1ETDc7XBDY8ovTNUMr+gjwEbDFiPTA0onwKqVARvXegqx5nZJIlnIna4vVc1hJOaTLfoQWmm59JioVtGwBpohI9cVATJ9Dgq4CnnfwBw9KZ9I=; Message-ID: <141438.15460.qm@web111415.mail.gq1.yahoo.com> X-YMail-OSG: QWu.X9kVM1lnpmxDlEBShxG9zD_4n6nFUvRiIDFNG_tkpBN MkGWB0Mdu8ozGg725RwRARYPo_bK9p5DW3iNGkfj_gRTh1D1R8MKBD8Z6PPK s1b3LkeVpS4oS9fkbqNQIR2GLQJn3Oq8EiLkzdPFJiJhlsw_SNxMaNqFv41w VzPAVmY4XcnkKLqe3seB5ghR3OVwH7uovrKLgItsY17Px64aHsExkDZKYyhn fFSZEquNp63cDZBF7wOVl6TaBnUvA9hVVUgpS5SWd4Dh8NkzifLK2Ast9mxo ibw9tTsmXe5pp.GzXJ01JIch2YUP9ayvgcn_fm2uWf0HnacUmKdNjLVgvsrd A3s.lP06VyyqLZ8beGaRQPwNlzF_zvBFsECQPGkUfcEeyaa3sFcXzsHBz9D3 p6kBP74wEY0k1gg-- Received: from [130.129.68.193] by web111415.mail.gq1.yahoo.com via HTTP; Fri, 01 Apr 2011 07:20:11 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617 References: Date: Fri, 1 Apr 2011 07:20:11 -0700 (PDT) From: Behcet Sarikaya To: Basavaraj.Patil@nokia.com, cabo@tzi.org, 6lowpan@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:18:35 -0000 +1 > +1 (if I-D editor view counts) > > On 3/31/11 12:53 PM, "ext Carsten Bormann" wrote: > > >> Re: [6lowpan] WG adoption of 6lowpan Implementers guide > > > >That's what you get when you edit one message out of another. > >It's been a long week... > >Of course, this is about the BT-LE draft, not about the implementers > >guide. > >Please make sure you reply with the subject of this message, in > >particular if it is just a "+1"... > > > >Sorry for the confusion, > >Carsten > > > >On Mar 31, 2011, at 19:47, Carsten Bormann wrote: > > > >> It appears I was a bit quick dismissing BT-LE as a working group item > >>during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can > >>very well request the addition of milestones. As the support in the > >>room for working on the adaptation of 6LoWPAN for BT-LE was quite good, > >>I'm now issuing a call for WG adoption. > >> > >> This is a call for working group adoption of > >> draft-patil-6lowpan-v6over-btle-01.txt > >> > >> Working group adoption does not mean we agree with every detail of the > >> draft, but that we want to use it as the basis of further working group > >> work. > >> > >> Please reply to the list until > >> > >> Friday, April 8, 23:59 UTC > >> > >> with your position whether this document should be adopted or not. > >> > >> Gruesse, Carsten > > > >_______________________________________________ > >6lowpan mailing list > >6lowpan@ietf.org > >https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From pthubert@cisco.com Fri Apr 1 07:25:58 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708563A6873 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 07:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.4 X-Spam-Level: X-Spam-Status: No, score=-10.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXjNycK10SUN for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 07:25:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 001813A6864 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 07:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1801; q=dns/txt; s=iport; t=1301668057; x=1302877657; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=z7w7ID0sZoomdkYoHYyZkU3dm/70qodspMoGuEFYZj0=; b=Jy9wR3ZNCVKeyBHFNPRcnAaaj6KmWXVNZC+DlsidcCu/psFlEgVkLi/Q +MFWmtkaCNxEDNwk6Y9WpkfIDY5rgCddLvJW57ep9CLGOBFzP16AYVVOY oLgcsw0s3RreoKxEYNNmx8C0W2baZdaJxF/Wq/E7j6+C3QqeueaxMjJ5i 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUAAOHflU2Q/khNgWdsb2JhbACYG409FAEBCwsmJaVNnD6FawSQeg X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="81844285" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2011 14:27:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p31ERaGt011274; Fri, 1 Apr 2011 14:27:36 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 16:27:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 16:27:32 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04441056@XMB-AMS-107.cisco.com> In-Reply-To: <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WG adoption of Transmission of IPv6 Packets overBluetooth Low Energy Thread-Index: AcvvzKiCaBkLb5DzS8ytQ59OAmYduQArDJnQ References: <1301488616.3846.752.camel@d430> <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "6lowpan WG" <6lowpan@ietf.org> X-OriginalArrivalTime: 01 Apr 2011 14:27:36.0701 (UTC) FILETIME=[F29872D0:01CBF078] Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets overBluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:25:58 -0000 I support this work. Thanks Raj and all : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Carsten Bormann > Sent: Thursday, March 31, 2011 7:54 PM > To: 6lowpan WG > Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets > overBluetooth Low Energy >=20 > > Re: [6lowpan] WG adoption of 6lowpan Implementers guide >=20 > That's what you get when you edit one message out of another. > It's been a long week... > Of course, this is about the BT-LE draft, not about the implementers guide. > Please make sure you reply with the subject of this message, in particular if it > is just a "+1"... >=20 > Sorry for the confusion, > Carsten >=20 > On Mar 31, 2011, at 19:47, Carsten Bormann wrote: >=20 > > It appears I was a bit quick dismissing BT-LE as a working group item during > Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can very well > request the addition of milestones. As the support in the room for working > on the adaptation of 6LoWPAN for BT-LE was quite good, I'm now issuing a > call for WG adoption. > > > > This is a call for working group adoption of > > draft-patil-6lowpan-v6over-btle-01.txt > > > > Working group adoption does not mean we agree with every detail of the > > draft, but that we want to use it as the basis of further working > > group work. > > > > Please reply to the list until > > > > Friday, April 8, 23:59 UTC > > > > with your position whether this document should be adopted or not. > > > > Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From oliver.hahm@fu-berlin.de Fri Apr 1 10:37:43 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDD13A690C for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 10:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKHPxszHhifS for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 10:37:42 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by core3.amsl.com (Postfix) with ESMTP id BA0BC3A6909 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 10:37:42 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for 6lowpan@ietf.org with esmtp (envelope-from ) id <1Q5iJe-0004b9-BY>; Fri, 01 Apr 2011 19:39:22 +0200 Received: from [82.113.121.197] (helo=[10.44.172.243]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for 6lowpan@ietf.org with esmtpsa (envelope-from ) id <1Q5iJd-00071E-TO>; Fri, 01 Apr 2011 19:39:22 +0200 From: Oliver Hahm To: 6lowpan@ietf.org X-Mailer: Modest 3.2 References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com> In-Reply-To: <4D95C1E9.1070901@gridmerge.com> Content-Type: text/plain; charset=utf-8 Content-ID: <1301679637.6495.11.camel@Nokia-N900> Date: Fri, 01 Apr 2011 19:40:39 +0200 Message-Id: <1301679639.6495.12.camel@Nokia-N900> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: 82.113.121.197 Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oliver Hahm List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:37:43 -0000 Hi, > So each MAC/PHY needs its own considerations when it comes to an > adaptation layer. My feeling is that many concepts could be abstracted > and maybe written in a common document in my opinion that's an interesting point. Why not writing a more generic document specifying IPv6 over low-power wireless? This could cover more common considerations about the requirements to the link layer for new 6lowpan implementations. For instance we've implemented 6lowpan [1] for our micro kernel based operating system which currently supports MSP430 as well as an ARM7. But as our transceiver (TI CC110x) is neither capable of 802.15.4 nor bt-le at the physical layer we cannot be RFC compliant. Therefore, a more generic specification for IPv6 over low-power wireless foo would be really interesting for us - and probably a lot of other people as CC1020 and CC110x are very popular transceivers for WSN. Regards Oleg [1] For clarification: we have implemented RFC4944, current ND and HC as well as the 802.15.4 frame format based on CSMA for sub-GHz band. From alexandru.petrescu@gmail.com Fri Apr 1 14:24:43 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84B428C0F9 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58HXnLJP5Ykh for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:24:42 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7423628C0D8 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 14:24:40 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 5266A940101 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 23:26:15 +0200 (CEST) Message-ID: <4D9642F6.9060709@gmail.com> Date: Fri, 01 Apr 2011 23:26:14 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com> In-Reply-To: <4D95C1E9.1070901@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110401-2, 01/04/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 21:24:44 -0000 Le 01/04/2011 14:15, Robert Cragie a écrit : > Alex, > > RFC4944 and 6lowpan-hc form an adaptation layer between IPv6 and, > currently, 802.15.4. A-ha. > To be clear: > > BT BR/EDR is not 802.15.4, BT LE is not 802.15.4, BT BR/EDR is not BT > LE (MAC or PHY) Ok; you may see some technical differences, you may direct me to the technical differences. > So each MAC/PHY needs its own considerations when it comes to an > adaptation layer. Ok, yes, when it comes to an adaptation layer; the adaptation layer is called "lowpan" in rfc4944. Yes, "lowpan" adaptation layer would need to be well adapted on each different MAC, one being BT-LE. But I am talking pure IPv6 straight over bluetooth, without "lowpan". That IPv6 over bluetooth works ok without lowpan, with "bnep". The meeting presentation slides say "BNEP can be optionally used between compressed IPv6 and BT-LE L2CAP". I agree. Moreover, bnep can also be used ok to run IPv6 over bluetooth without lowpan, without compressed IPv6. Is "lowpan" some better than "bnep"? Why would one prefer "lowpan" instead of "bnep"? Thanks for an indication. > My feeling is that many concepts could be abstracted and maybe > written in a common document but ultimately, there will be three > different adaptation layers. Ah... more adaptation layers... > Also "bluetooth is to 802.15.4 what wifi is to 802.11" - completely > wrong comparison. Bluetooth has nothing to do with 802.15.4. Yes they do: they're both PAN. Alex > > Robert > > On 01/04/2011 12:41 PM, Alexandru Petrescu wrote: >> Le 01/04/2011 13:16, Basavaraj.Patil@nokia.com a écrit : >>> >>> There is a world of difference between 802.15.4 and BT-LE. >> >> yes, but I mean from the standpoint of IP. >> >> Is the MAC address format different between bt and bt-le? >> (including format of multicast addresses) >> >> Is the bt-le mac still doing reassembly (as bt does) thus accept >> the same minimal mtu as bt, i.e.1280bytes? >> >> Is bt-le still a multicast-capable link layer, like bt is? >> >> Alex >> >> >>> >>> On 4/1/11 5:33 AM, "ext Alexandru >>> Petrescu" wrote: >>> >>>> Le 01/04/2011 12:12, Carsten Bormann a écrit : >>>>>> It seems to me IMHO bt-le is just a new phy, but same mac, >>>>>> hence ip would not be affected. >>>>> >>>>> From the presentation, I had a different impression. >>>>> >>>>>> But of course, a document stating we do things over bt-le >>>>>> as usually as over bt, would not hurt. >>>>> >>>>> Actually, it is required, as RFC4944 and its updates only >>>>> define 6LoWPAN for IEEE 802.15.4. If two people took these >>>>> documents and tried to apply them to BT-LE, they wouldn't >>>>> necessarily arrive at interoperable specifications. >>>> >>>> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a >>>> marketing name. It seems sufficient to specify ipv6 over >>>> 802.15.4 and that would cover all variants of bluetooth. There >>>> is no ipv6-over-802.11n, nor ipv6-over-wifilowpower, for >>>> example. >>>> >>>> I may be wrong though about bluetooth being mostly 802.15.4 >>>> rfc4944 and rfc2460. >>>> >>>>>> Is the WG re-opened? >>>>> >>>>> No, it is alive and well until such a time when it is >>>>> actually being closed. All that was said is that the Prague >>>>> meeting will be the last physical meeting of the WG. We want >>>>> to close our unfinished business, and a number of documents >>>>> are based on discussions that went on at least since >>>>> Beijing, so if they fit our charter and we have energy to >>>>> work on them, there is no problem doing that. >>>> >>>> sounds like doing new work without physical meetings... ok... >>>> >>>> Alex >>>> >>>>> >>>>> Gruesse, Carsten >>>>> >>>> >>>> _______________________________________________ 6lowpan >>>> mailing list 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Fri Apr 1 14:29:57 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9EB28C0ED for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82zifqteizXA for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:29:57 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B711928C102 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 14:29:50 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id CC2FE9400ED; Fri, 1 Apr 2011 23:31:25 +0200 (CEST) Message-ID: <4D96442B.3010006@gmail.com> Date: Fri, 01 Apr 2011 23:31:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carles Gomez Montenegro References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> <4D95A9EF.2080406@gmail.com> <52947.83.50.67.65.1301651082.squirrel@webmail.entel.upc.edu> In-Reply-To: <52947.83.50.67.65.1301651082.squirrel@webmail.entel.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110401-2, 01/04/2011), Outbound message X-Antivirus-Status: Clean Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 21:29:58 -0000 Le 01/04/2011 11:44, Carles Gomez Montenegro a écrit : > Hi Alex, > >> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a >> marketing name. It seems sufficient to specify ipv6 over 802.15.4 >> and that would cover all variants of bluetooth. There is no >> ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example. >> >> I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 >> and rfc2460. > > Are you maybe referring to 802.15.1 instead of 802.15.4? (Btw, only > some of the first Bluetooth versions were ratified as parts of > 802.15.1) Right, it may be so, that I may refer to a 802.15 variant (.1 maybe) as bluetooth. Also I meant rfc2464 (IPv6 ethernet) instead of rfc2460 (IPv6). Alex > > All the best, > > Carles > > From alexandru.petrescu@gmail.com Fri Apr 1 14:32:28 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685A628C10B for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6X3ZClrbhrb for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:32:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6C328C0D8 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 14:32:25 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 204169400F3 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 23:34:00 +0200 (CEST) Message-ID: <4D9644C7.1090709@gmail.com> Date: Fri, 01 Apr 2011 23:33:59 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <1301488616.3846.752.camel@d430> <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> <09E0F2D8-7554-4009-9781-27C44892BA60@sensinode.com> In-Reply-To: <09E0F2D8-7554-4009-9781-27C44892BA60@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110401-2, 01/04/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 21:32:28 -0000 Le 01/04/2011 14:19, Zach Shelby a écrit : > +1 (co-author hat off) > > This is sufficiently different from 802.15.4 and without > specification hard to make interoperable between vendors. > Furthermore, I believe having a specification for 6lowpan over > (something other than 802.15.4) will be a great thing for the whole > community. Zach, considering that supposedly BT-LE would be backwards compatible with BT, i.e. bnep would still work - why would one be tempted by lowpan in first place? Alex > > Zach > > On Mar 31, 2011, at 8:53 PM, Carsten Bormann wrote: > >> On Mar 31, 2011, at 19:47, Carsten Bormann wrote: >> >>> It appears I was a bit quick dismissing BT-LE as a working group >>> item during Tuesday's 6LoWPAN meeting. The WG is alive and >>> well, so we can very well request the addition of milestones. As >>> the support in the room for working on the adaptation of 6LoWPAN >>> for BT-LE was quite good, I'm now issuing a call for WG >>> adoption. >>> >>> This is a call for working group adoption of >>> draft-patil-6lowpan-v6over-btle-01.txt >>> >>> Working group adoption does not mean we agree with every detail >>> of the draft, but that we want to use it as the basis of further >>> working group work. >>> >>> Please reply to the list until >>> >>> Friday, April 8, 23:59 UTC >>> >>> with your position whether this document should be adopted or >>> not. >>> >>> Gruesse, Carsten >> >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Fri Apr 1 14:43:52 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCEA28C0ED for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXiAmWn-nZHA for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 14:43:52 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 3535928C111 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 14:43:48 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 2346094015E for <6lowpan@ietf.org>; Fri, 1 Apr 2011 23:45:24 +0200 (CEST) Message-ID: <4D964773.10105@gmail.com> Date: Fri, 01 Apr 2011 23:45:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 110401-2, 01/04/2011), Outbound message X-Antivirus-Status: Clean Subject: [6lowpan] BT-LE vs ANT+ X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 21:43:53 -0000 As a side note, I wonder why people prefer to work for IPv6 over BT-LE instead of IPv6 over ANT+ ? ANT+ is a very low power link layer technology very well adapted for the scenario depicted in the bt-le use case scenario (page 50 of http://tools.ietf.org/agenda/80/slides/6lowpan-0.pdf) BT-LE and ANT+ technologies seem to compete in a certain market segment related to PAN. I am asking because, from where I look, IMHO, ANT+ does seem to get some tract among manufacturers of these devices. Alex From Basavaraj.Patil@nokia.com Fri Apr 1 17:09:43 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F813A69B6 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 17:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.097 X-Spam-Level: X-Spam-Status: No, score=-103.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcKjA0tm9wuq for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 17:09:42 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 8434B3A69AE for <6lowpan@ietf.org>; Fri, 1 Apr 2011 17:09:42 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p320AVZ9019233; Sat, 2 Apr 2011 03:11:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 03:11:09 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 2 Apr 2011 02:11:09 +0200 Received: from 008-AM1MPN1-023.mgdnok.nokia.com ([169.254.3.94]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0270.002; Sat, 2 Apr 2011 02:11:09 +0200 From: To: , <6lowpan@ietf.org> Thread-Topic: [6lowpan] BT-LE vs ANT+ Thread-Index: AQHL8LYowVejAa4W0UWILxcMycQb1ZRJPiYA Date: Sat, 2 Apr 2011 00:11:07 +0000 Message-ID: In-Reply-To: <4D964773.10105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [212.47.23.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <12C6735AA2A9A446BAEA439204D2ED70@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Apr 2011 00:11:09.0911 (UTC) FILETIME=[78184E70:01CBF0CA] X-Nokia-AV: Clean Subject: Re: [6lowpan] BT-LE vs ANT+ X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 00:09:43 -0000 Alex, Do you really have a point to make in this discussion? You are all over the map with zero value. -Raj On 4/1/11 4:45 PM, "ext Alexandru Petrescu" wrote: >As a side note, > >I wonder why people prefer to work for IPv6 over BT-LE > instead of IPv6 over ANT+ >? > >ANT+ is a very low power link layer technology very well adapted for the >scenario depicted in the bt-le use case scenario (page 50 of >http://tools.ietf.org/agenda/80/slides/6lowpan-0.pdf) > >BT-LE and ANT+ technologies seem to compete in a certain market segment >related to PAN. > >I am asking because, from where I look, IMHO, ANT+ does seem to get some >tract among manufacturers of these devices. > >Alex >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From carlesgo@entel.upc.edu Fri Apr 1 17:52:24 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8433A69BD for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 17:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+0+AYgklV1o for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 17:52:23 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by core3.amsl.com (Postfix) with ESMTP id 6834C3A69BA for <6lowpan@ietf.org>; Fri, 1 Apr 2011 17:52:22 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p320s0nL025141; Sat, 2 Apr 2011 02:54:00 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 619F72CBD0D; Sat, 2 Apr 2011 02:53:55 +0200 (CEST) Received: from 83.50.67.65 by webmail.entel.upc.edu with HTTP; Sat, 2 Apr 2011 01:56:30 +0200 (CEST) Message-ID: <58261.83.50.67.65.1301702190.squirrel@webmail.entel.upc.edu> In-Reply-To: <4D96442B.3010006@gmail.com> References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> <4D95A9EF.2080406@gmail.com> <52947.83.50.67.65.1301651082.squirrel@webmail.entel.upc.edu> <4D96442B.3010006@gmail.com> Date: Sat, 2 Apr 2011 01:56:30 +0200 (CEST) From: "Carles Gomez Montenegro" To: "Alexandru Petrescu" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sat, 02 Apr 2011 02:54:00 +0200 (CEST) Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 00:52:24 -0000 >>> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a >>> marketing name. It seems sufficient to specify ipv6 over 802.15.4 >>> and that would cover all variants of bluetooth. There is no >>> ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example. >>> [...] >> Are you maybe referring to 802.15.1 instead of 802.15.4? (Btw, only >> some of the first Bluetooth versions were ratified as parts of >> 802.15.1) > > Right, it may be so, that I may refer to a 802.15 variant (.1 maybe) as > bluetooth. [...] Well, the point is that, as other folks have already explained: - Bluetooth and 802.15.4 are *not* variants of the same thing. - Bluetooth Low Energy and 802.15.4 are *not* variants of the same thing. The "802.15" prefix in the spec. code (which only applies to some of the first Bluetooth versions, and e.g. *not* to BLE) may lead you to confusion. The analogy with 802.11 variants (as in your example) cannot be done here. Carles From taurus.wf@gmail.com Sat Apr 2 00:50:29 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37463A6A4D for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 00:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZqLNdG4Rnme for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 00:50:29 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id B1A403A691A for <6lowpan@ietf.org>; Sat, 2 Apr 2011 00:50:28 -0700 (PDT) Received: by ywi6 with SMTP id 6so1916468ywi.31 for <6lowpan@ietf.org>; Sat, 02 Apr 2011 00:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=kdxa0MK4i3SOLRZDclPqpoplyPhLEthIS161yt2wB4Q=; b=jHK97BvZTuA6pw640QU08A0RgndEk60jbNB30Xa9SAGKkzSWA8MU1sE1rTUbaFn7gJ 87RzubSolSmRtH20Loy1JSzI0VnrZz+fkPJDZSXnaWFqoqnb+7thAvmQ8+9n/wOqpi6e OBKgW2WgSKIQ/sEeJb29Qb/qOThyUkb139Tek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lIx3CNI+WVaU+dSYGWuEZUd+uamRI29Q+E6AUkH/EazV5RZlHDOKo5gqtC6MnBgWaN ONiwk1m/HTsyyOlEqt5dH739Js6V3KAnXsVftPmpDaI9PTNT8PRjOpjxz7yG1dVOGyPx UJAOWC0WyCPrn0P/OluHmJ87BQwBN86Alj/BU= MIME-Version: 1.0 Received: by 10.236.72.168 with SMTP id t28mr4572094yhd.74.1301730729456; Sat, 02 Apr 2011 00:52:09 -0700 (PDT) Received: by 10.236.95.47 with HTTP; Sat, 2 Apr 2011 00:52:09 -0700 (PDT) Date: Sat, 2 Apr 2011 09:52:09 +0200 Message-ID: From: feng wang To: 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 07:50:30 -0000 hi all, +1. I support BT-LE should be adopted by WG. --=20 Wang Feng. Shawn >It appears I was a bit quick dismissing BT-LE as a working group item duri= ng Tuesday's 6LoWPAN meeting. The WG is alive and >well, so we can very we= ll request the addition of milestones. As the support in the room for work= ing on the adaptation of 6LoWPAN >for BT-LE was quite good, I'm now issuing= a call for WG adoption. >This is a call for working group adoption of >draft-patil-6lowpan-v6over-btle-01.txt >Working group adoption does not mean we agree with every detail of the >draft, but that we want to use it as the basis of further working group >work. >Please reply to the list until > Friday, April 8, 23:59 UTC > with your position whether this document should be adopted or not. > Gruesse, Carsten From alexandru.petrescu@gmail.com Sat Apr 2 03:40:08 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA043A63EC for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 03:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYW1CCfK5SOj for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 03:40:05 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 7FDF13A63EB for <6lowpan@ietf.org>; Sat, 2 Apr 2011 03:40:04 -0700 (PDT) Received: by wyb29 with SMTP id 29so4017822wyb.31 for <6lowpan@ietf.org>; Sat, 02 Apr 2011 03:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/tJnrfDmrjXFUxCuDOPJ9t8GtDHmm/6dY8iI9y2znls=; b=rTzulIuyFytwy4zCIUSUa1cPfZLiKkddSzbaAZ7vxCCstIwESdqa2rn4kr9o/+M9c/ 9gK2xqfZqCxYCovOatec7cptASJyuognBeKFRWNANmEQxI8iLF+PZjUG0nWSmRBDu4TN /QVGOXE4eTfJX2gb0hK/0FQo8tuu+qCAKObXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vyRCajDn6XgVHbK20L4k7HhPu1swc6ZecuN3E7oNGJnUNjhNWWR8TYHiR2CETPxOGm YQCM48U15hijWBvz9Il1w7Fic0QXauM/kHjHlK0p7nTXLFPJk6h10TG8zKaJewpS9vD4 WfEsi65GKq0WCbadq8TKaD9uU7VPDT46NRKME= Received: by 10.227.197.21 with SMTP id ei21mr5089414wbb.107.1301740904982; Sat, 02 Apr 2011 03:41:44 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by mx.google.com with ESMTPS id w25sm1760126wbd.39.2011.04.02.03.41.42 (version=SSLv3 cipher=OTHER); Sat, 02 Apr 2011 03:41:43 -0700 (PDT) Message-ID: <4D96FD62.4080804@gmail.com> Date: Sat, 02 Apr 2011 12:41:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] BT-LE vs ANT+ X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 10:40:08 -0000 That was a side note. Please do not call my points 0-value. One would be tempted to easily discard some points of doing work without meetings as of questionable value as well. But try to understand before discarding. Alex Le 02/04/2011 02:11, Basavaraj.Patil@nokia.com a écrit : > > Alex, > > Do you really have a point to make in this discussion? You are all > over the map with zero value. > > -Raj > > On 4/1/11 4:45 PM, "ext Alexandru > Petrescu" wrote: > >> As a side note, >> >> I wonder why people prefer to work for IPv6 over BT-LE instead of >> IPv6 over ANT+ ? >> >> ANT+ is a very low power link layer technology very well adapted >> for the scenario depicted in the bt-le use case scenario (page 50 >> of http://tools.ietf.org/agenda/80/slides/6lowpan-0.pdf) >> >> BT-LE and ANT+ technologies seem to compete in a certain market >> segment related to PAN. >> >> I am asking because, from where I look, IMHO, ANT+ does seem to >> get some tract among manufacturers of these devices. >> >> Alex _______________________________________________ 6lowpan >> mailing list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Sat Apr 2 03:51:59 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192AE3A6783 for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 03:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6kBiAKbRtpt for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 03:51:58 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3982C3A677C for <6lowpan@ietf.org>; Sat, 2 Apr 2011 03:51:58 -0700 (PDT) Received: by wyb29 with SMTP id 29so4022379wyb.31 for <6lowpan@ietf.org>; Sat, 02 Apr 2011 03:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7+WfBsOZf8vMwHvd3F3IZVw4RrQ2LGMfIM68jBzVqag=; b=bmEJ0oRqgxeRWQXIcOenuP8HalFo7OAXSQ+iqp6xHQpxdh/LSdwyEXirKuQ9yo/9CT 18/0qQo+kYI+2Y/+NK5VjRmrVaQx9doof1QpdhWRRAKTMIwCgsnCxxv7dqqh3VwzNLBh xqrj27fONst6y1XJ6f7HSvgqOCWvIxMGGylnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fK7J1nULLiMhqm3Wm4KSWjIKuY42nXlAWDynqapPdydl4VeelgTPoY13ltgpgUk8I5 GoaFjyijErUnvZoT4M7RSY51oUxSmZL2DqjncP7H5l2Je+1XJofjvzZMfyQxxs2rjKhb fkDXOCNKLN3nycGGOwMfnEXWacOar8vIDGE2k= Received: by 10.227.104.2 with SMTP id m2mr2254069wbo.35.1301741618728; Sat, 02 Apr 2011 03:53:38 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by mx.google.com with ESMTPS id o6sm1765426wbo.37.2011.04.02.03.53.36 (version=SSLv3 cipher=OTHER); Sat, 02 Apr 2011 03:53:37 -0700 (PDT) Message-ID: <4D97002D.2040606@gmail.com> Date: Sat, 02 Apr 2011 12:53:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carles Gomez Montenegro References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> <4D95A9EF.2080406@gmail.com> <52947.83.50.67.65.1301651082.squirrel@webmail.entel.upc.edu> <4D96442B.3010006@gmail.com> <58261.83.50.67.65.1301702190.squirrel@webmail.entel.upc.edu> In-Reply-To: <58261.83.50.67.65.1301702190.squirrel@webmail.entel.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 10:51:59 -0000 Le 02/04/2011 01:56, Carles Gomez Montenegro a écrit : >>>> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a >>>> marketing name. It seems sufficient to specify ipv6 over >>>> 802.15.4 and that would cover all variants of bluetooth. There >>>> is no ipv6-over-802.11n, nor ipv6-over-wifilowpower, for >>>> example. >>>> > [...] >>> Are you maybe referring to 802.15.1 instead of 802.15.4? (Btw, >>> only some of the first Bluetooth versions were ratified as parts >>> of 802.15.1) >> >> Right, it may be so, that I may refer to a 802.15 variant (.1 >> maybe) as bluetooth. > > [...] > > Well, the point is that, as other folks have already explained: > > - Bluetooth and 802.15.4 are *not* variants of the same thing. - > Bluetooth Low Energy and 802.15.4 are *not* variants of the same > thing. > > The "802.15" prefix in the spec. code (which only applies to some of > the first Bluetooth versions, and e.g. *not* to BLE) may lead you to > confusion. Yes. I am personally confused about 802.15 being or not Bluetooth and, by extension, BT-LE. It may be that BT-LE is going to be backwards compatible with Bluetooth, just speculating. Otherwise why would they keep the bluetooth name in BT-LE. Alex > The analogy with 802.11 variants (as in your example) cannot be done > here. > > Carles > From alexandru.petrescu@gmail.com Sat Apr 2 04:49:21 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602063A67BD for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 04:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypJM6MVJLBLn for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 04:49:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 957203A67B7 for <6lowpan@ietf.org>; Sat, 2 Apr 2011 04:49:18 -0700 (PDT) Received: by wwa36 with SMTP id 36so3486600wwa.13 for <6lowpan@ietf.org>; Sat, 02 Apr 2011 04:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=3N0koYtk72XyblOwCMCZCgjKgQYdnvv44MDzd5IZlR8=; b=ecJlmM9MzjRQuDbyIq59aDmBxJbLE5nQJRgAAhJ6alQqhm6a8h/Lpet1cJJg/DBAji AodhkuDv1pqq9rKCR7UK3gmuOSUK2mm40avOuaVLinrWUzj6RgGvwMJNl92TeHGGD7eC 7HwHAsvJapSHTIAySZLxKuz3Hvl0zL22Q/b8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=pWgPoA+NZ4SgLzsupJaBTVcBE/Duzr8Gxmq6J4NCOVlRCHe/hLZTN3EgoESYFMluT1 kQyMkHQ4neGbGUEWRB/FbU//Y3mfxgMfmnuuDmVKcF+c7jeMNfViE1cCWGfkIw7EndGU odXTScR347FMDoGvWs+n0cd94NQJ/2mxNcW2I= Received: by 10.227.59.210 with SMTP id m18mr5072664wbh.112.1301745059000; Sat, 02 Apr 2011 04:50:59 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by mx.google.com with ESMTPS id w12sm1631924wby.58.2011.04.02.04.50.57 (version=SSLv3 cipher=OTHER); Sat, 02 Apr 2011 04:50:58 -0700 (PDT) Message-ID: <4D970D9E.6080403@gmail.com> Date: Sat, 02 Apr 2011 13:50:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan WG <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Four points about BT-LE adaptation layer and lowpan X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 11:49:21 -0000 Raj, I think the BT-LE adaptation layer is different than the lowpan adaptation layer[*]. The points I am trying to make are: - IPv6 works ok over that BT-LE adaptation protocol spec, without modifications to lowpan (since it is not used by BT-LE). - lowpan adaptation layer may indeed need to be modified to support BT-LE Codes. This would be helpful in networks running lowpan and not BT-LE adaptation protocol. This would not be IPv6 work, though, but lowpan work. - the quantity of work seems significant, difficult to achieve in a WG which does not meet. - this seems to be adaptation layer work, and this would contradict statements that we don't do adaptation layer work at IETF. Raj - is this clearer from my side? Alex [*] BT-LE adaptation layer ("adaptation protocol spec" page 1382 of https://www.bluetooth.org/docman/handler/downloaddoc.ashx?doc_id=229737) is not the same as lowpan adaptation layer (section 5 of RFC4944). Because, for example, the message format of BT-LE on page 1404 of that BT-LE spec seems to start with a Length field, whereas the frame format on page 6 of RFC4944 starts with something different (dispatch type, mesh type, etc.) From carlesgo@entel.upc.edu Sat Apr 2 05:18:51 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1FED3A67E1 for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 05:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1jlZmHFOb1L for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 05:18:51 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by core3.amsl.com (Postfix) with ESMTP id A05CD3A67D7 for <6lowpan@ietf.org>; Sat, 2 Apr 2011 05:18:21 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p32CJxPg018415; Sat, 2 Apr 2011 14:19:59 +0200 Received: from webmail.entel.upc.edu (wireless.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 1C0792CBD0D; Sat, 2 Apr 2011 14:19:54 +0200 (CEST) Received: from 83.50.67.65 by webmail.entel.upc.edu with HTTP; Sat, 2 Apr 2011 13:22:42 +0200 (CEST) Message-ID: <60230.83.50.67.65.1301743362.squirrel@webmail.entel.upc.edu> In-Reply-To: <4D97002D.2040606@gmail.com> References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> <4D95A9EF.2080406@gmail.com> <52947.83.50.67.65.1301651082.squirrel@webmail.entel.upc.edu> <4D96442B.3010006@gmail.com> <58261.83.50.67.65.1301702190.squirrel@webmail.entel.upc.edu> <4D97002D.2040606@gmail.com> Date: Sat, 2 Apr 2011 13:22:42 +0200 (CEST) From: "Carles Gomez Montenegro" To: "Alexandru Petrescu" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sat, 02 Apr 2011 14:19:59 +0200 (CEST) Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 12:18:51 -0000 > It may be that BT-LE is going to be backwards compatible with Bluetooth, > just speculating. Otherwise why would they keep the bluetooth name in > BT-LE. > > Alex A BT-LE device cannot talk with a non-BT-LE (say "classic" Bluetooth) device. There are many differences in the protocol stacks, as for example in the PHY and Link layers. However, a dual-mode device (i.e. a device that supports both "classic" Bluetooth and BT-LE) can benefit from the fact that many elements already present in classic Bluetooth can be reused in a BT-LE implementation. BT-LE was designed from the basis of "classic" Bluetooth for optimized operation in control and monitoring applications, which typically involve devices that exhibit constraints (in energy supply, processing power, memory, etc.). For more details about all this, you may refer to the Bluetooth specs. They are publicly available. Carles From alexandru.petrescu@gmail.com Sat Apr 2 05:35:14 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674213A67E2 for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 05:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqKysHIN-49r for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 05:35:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 74E533A67D9 for <6lowpan@ietf.org>; Sat, 2 Apr 2011 05:35:11 -0700 (PDT) Received: by wyb29 with SMTP id 29so4062175wyb.31 for <6lowpan@ietf.org>; Sat, 02 Apr 2011 05:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Sk43H9cJGQcqPcfQ6l56vXH7Hl9ONSXra6LfMkUb6Dc=; b=wsWT7Z9kG9qPGf757mz9etReRpARSwuXV5HUSFYEkWHKgT/T+dOwLgBSlXXupLaV7r HymHn4CcWD/1Egik47++AtxO5Kesqlf602P/2Jlv91gRV565VRUzkFywHk8gqqWpE5sA uxpfHuyuhbykX7UPT/u7BrckKhQZ1WAl+eots= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=GB4GsPSr/NMLg5G7gsPAjy5KjbFp12hdTA/1tQIfGnF+Io7EkaXnhFxSDa3FyTYEP+ MN+9+scjGMkrP+n/hVKIfTmbC/JtevvXqxgd1LG97yqXYFYge95ZPwqd58SNk8L4fcOV B7RVyyxHY6cFQLBphOMdtnqfPTZf+RcrGtCYY= Received: by 10.227.169.77 with SMTP id x13mr5253697wby.151.1301747809804; Sat, 02 Apr 2011 05:36:49 -0700 (PDT) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by mx.google.com with ESMTPS id y29sm1806479wbd.38.2011.04.02.05.36.47 (version=SSLv3 cipher=OTHER); Sat, 02 Apr 2011 05:36:48 -0700 (PDT) Message-ID: <4D97185C.3030703@gmail.com> Date: Sat, 02 Apr 2011 14:36:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Carles Gomez Montenegro References: <1301488616.3846.752.camel@d430> <4D95A2E4.50609@gmail.com> <6C1C71A8-FC22-4751-A8C9-3320F90081A0@tzi.org> <4D95A9EF.2080406@gmail.com> <52947.83.50.67.65.1301651082.squirrel@webmail.entel.upc.edu> <4D96442B.3010006@gmail.com> <58261.83.50.67.65.1301702190.squirrel@webmail.entel.upc.edu> <4D97002D.2040606@gmail.com> <60230.83.50.67.65.1301743362.squirrel@webmail.entel.upc.edu> In-Reply-To: <60230.83.50.67.65.1301743362.squirrel@webmail.entel.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan WG <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 12:35:14 -0000 Le 02/04/2011 13:22, Carles Gomez Montenegro a écrit : >> It may be that BT-LE is going to be backwards compatible with >> Bluetooth, just speculating. Otherwise why would they keep the >> bluetooth name in BT-LE. >> >> Alex > > A BT-LE device cannot talk with a non-BT-LE (say "classic" > Bluetooth) device. Yes, I agree it may be so. This is one aspect backwards (in)compatibility. But also, if BT-LE devices will support IPv6 as BT devices do, IPv6 solves the above incompatibility issue. > There are many differences in the protocol stacks, as for example in > the PHY and Link layers. > > However, a dual-mode device (i.e. a device that supports both > "classic" Bluetooth and BT-LE) can benefit from the fact that many > elements already present in classic Bluetooth can be reused in a > BT-LE implementation. Yes, I agree. And there exist dual mode such devices supporting BT/ANT+ as well. These dual-mode devices are excellent candidates to be Routers. > BT-LE was designed from the basis of "classic" Bluetooth for > optimized operation in control and monitoring applications, which > typically involve devices that exhibit constraints (in energy supply, > processing power, memory, etc.). > > For more details about all this, you may refer to the Bluetooth > specs. They are publicly available. Yes, it's here: https://www.bluetooth.org/Technical/Specifications/adopted.htm I am looking mainly at "Core Version 4.0", Part A, "Logical Link Control and Adaptation Protocol Specification", L2CAP, as requested by section 4.5 "Basic Rate and Low Energy Combined Core Configuration". Alex > > Carles > From ben@blindcreek.com Sat Apr 2 08:04:14 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7169B3A683D for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 08:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lRJvsiY7xmb for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 08:04:13 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.58]) by core3.amsl.com (Postfix) with ESMTP id 4E3F23A683C for <6lowpan@ietf.org>; Sat, 2 Apr 2011 08:04:13 -0700 (PDT) Received: from [64.74.213.174] (port=62259 helo=[192.168.250.7]) by wilson.nswebhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q62Ob-0003Da-Ft for 6lowpan@ietf.org; Sat, 02 Apr 2011 10:05:49 -0500 Message-ID: <4D973B50.9070408@blindcreek.com> Date: Sat, 02 Apr 2011 08:05:52 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 15:04:14 -0000 To further clarify: 802.15.1 is the IEEE standard base standard for Bluetooth. If you had said 802.15.1 is to Bluetooth SIG as 802.11 is to WiFi Alliance you would be more correct. 802.15.4 was developed for very different applications and physical environments than Bluetooth. They are completely different standards. 802.14.1 and 802.15.4 are significantly different MACs, and 802.15.4 includes multiple PHY technologies. The latest revision (802.15.4-2011) includes the 3 PHY amendments approved since 2006, bringing the total of distinct PHYs to 6, with multiple banding options within some PHY specifications, all under a single, common MAC. There are at least 5 current task groups working on or finishing up further amendments. It has become the most popular downloaded standard in the 802 family and has been applied to a large variety of very different applications. Of course Bluetooth (802.15.1) has deployed in billions of devices and continues to be included in nearly all consumer devices. It is optimized for short physical range, small networks (piconets), low energy consumption, and high density of simultaneously operating piconets. Most implementations limit TX power and optimize for a range of a couple meters or less. Hope that clarification helps. > There is a world of difference between 802.15.4 and BT-LE. > > On 4/1/11 5:33 AM, "ext Alexandru Petrescu" > wrote: > >> Le 01/04/2011 12:12, Carsten Bormann a écrit : >>>> It seems to me IMHO bt-le is just a new phy, but same mac, hence ip >>>> would not be affected. >>> From the presentation, I had a different impression. >>> >>>> But of course, a document stating we do things over bt-le as >>>> usually as over bt, would not hurt. >>> Actually, it is required, as RFC4944 and its updates only define >>> 6LoWPAN for IEEE 802.15.4. If two people took these documents and >>> tried to apply them to BT-LE, they wouldn't necessarily arrive at >>> interoperable specifications. >> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a marketing >> name. It seems sufficient to specify ipv6 over 802.15.4 and that would >> cover all variants of bluetooth. There is no ipv6-over-802.11n, nor >> ipv6-over-wifilowpower, for example. >> >> I may be wrong though about bluetooth being mostly 802.15.4 rfc4944 and >> rfc2460. >> >>>> Is the WG re-opened? >>> No, it is alive and well until such a time when it is actually being >>> closed. All that was said is that the Prague meeting will be the last >>> physical meeting of the WG. We want to close our unfinished business, >>> and a number of documents are based on discussions that went on at >>> least since Beijing, so if they fit our charter and we have energy to >>> work on them, there is no problem doing that. >> sounds like doing new work without physical meetings... ok... >> >> Alex >> >>> Gruesse, Carsten >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Sat Apr 2 08:39:24 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EC928C122 for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+iE1vEXuhAV for <6lowpan@core3.amsl.com>; Sat, 2 Apr 2011 08:39:23 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DC07728C0E7 for <6lowpan@ietf.org>; Sat, 2 Apr 2011 08:39:21 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D15599401E5 for <6lowpan@ietf.org>; Sat, 2 Apr 2011 17:40:57 +0200 (CEST) Message-ID: <4D974387.1070404@gmail.com> Date: Sat, 02 Apr 2011 17:40:55 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4D973B50.9070408@blindcreek.com> In-Reply-To: <4D973B50.9070408@blindcreek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110402-0, 02/04/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 15:39:24 -0000 Thanks for clarification, Le 02/04/2011 17:05, Benjamin A. Rolfe a écrit : > To further clarify: 802.15.1 is the IEEE standard base standard for > Bluetooth. If you had said 802.15.1 is to Bluetooth SIG as 802.11 is > to WiFi Alliance you would be more correct. Ok, 802.15.1 is to Bluetooth SIG as 802.11 is to WiFi Alliance. > 802.15.4 was developed for very different applications and physical > environments than Bluetooth. They are completely different standards. > 802.14[5?].1 and 802.15.4 are significantly different MACs, and > 802.15.4 includes multiple PHY technologies. Ok. IMHO BT-LE and 802.15.4 compete in the same application and physical environment. > The latest revision (802.15.4-2011) includes the 3 PHY amendments > approved since 2006, bringing the total of distinct PHYs to 6, with > multiple banding options within some PHY specifications, all under a > single, common MAC. Ok, I wonder what that MAC is. > There are at least 5 current task groups working on or finishing up > further amendments. It has become the most popular downloaded > standard in the 802 family and has been applied to a large variety of > very different applications. Aha, 802.15.4-2011 is a popular download; but I cant find, sorry; by vote count here, it seems BT-LE is popular as well and I _can_ find the BT-LE specs. > Of course Bluetooth (802.15.1) has deployed in billions of devices > and continues to be included in nearly all consumer devices. It is > optimized for short physical range, small networks (piconets), low > energy consumption, and high density of simultaneously operating > piconets. Most implementations limit TX power and optimize for a > range of a couple meters or less. Do you mean that BT is more adapted in more constrained environments than 802.15.4? For the range in meters, I read at the 6LoWPAN WG meeting slides that BT-LE does 50-100meter. Do you know whether 802.15.4-2011 doc refers to the use of the lowpan adaptation layer (section 5 of rfc4944)? Or does it simply say IPv6 (like RFC2460 or so)? I can't find the 802.15.4-2011 document. Thanks, Alex > > Hope that clarification helps. > >> There is a world of difference between 802.15.4 and BT-LE. >> >> On 4/1/11 5:33 AM, "ext Alexandru >> Petrescu" wrote: >> >>> Le 01/04/2011 12:12, Carsten Bormann a écrit : >>>>> It seems to me IMHO bt-le is just a new phy, but same mac, >>>>> hence ip would not be affected. >>>> From the presentation, I had a different impression. >>>> >>>>> But of course, a document stating we do things over bt-le as >>>>> usually as over bt, would not hurt. >>>> Actually, it is required, as RFC4944 and its updates only >>>> define 6LoWPAN for IEEE 802.15.4. If two people took these >>>> documents and tried to apply them to BT-LE, they wouldn't >>>> necessarily arrive at interoperable specifications. >>> To me IMHO bluetooth is to 802.15.4 what wifi is to 802.11 - a >>> marketing name. It seems sufficient to specify ipv6 over 802.15.4 >>> and that would cover all variants of bluetooth. There is no >>> ipv6-over-802.11n, nor ipv6-over-wifilowpower, for example. >>> >>> I may be wrong though about bluetooth being mostly 802.15.4 >>> rfc4944 and rfc2460. >>> >>>>> Is the WG re-opened? >>>> No, it is alive and well until such a time when it is actually >>>> being closed. All that was said is that the Prague meeting >>>> will be the last physical meeting of the WG. We want to close >>>> our unfinished business, and a number of documents are based on >>>> discussions that went on at least since Beijing, so if they >>>> fit our charter and we have energy to work on them, there is no >>>> problem doing that. >>> sounds like doing new work without physical meetings... ok... >>> >>> Alex >>> >>>> Gruesse, Carsten >>>> >>> _______________________________________________ 6lowpan mailing >>> list 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ 6lowpan mailing >> list 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > From esko.dijk@philips.com Mon Apr 4 09:07:44 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 627923A69CA for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 09:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.562 X-Spam-Level: X-Spam-Status: No, score=-5.562 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edax2kxfhnIo for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 09:07:37 -0700 (PDT) Received: from TX2EHSOBE006.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by core3.amsl.com (Postfix) with ESMTP id 785083A682E for <6lowpan@ietf.org>; Mon, 4 Apr 2011 09:07:37 -0700 (PDT) Received: from mail48-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 16:09:19 +0000 Received: from mail48-tx2 (localhost.localdomain [127.0.0.1]) by mail48-tx2-R.bigfish.com (Postfix) with ESMTP id C1AFA13703F5; Mon, 4 Apr 2011 16:09:19 +0000 (UTC) X-SpamScore: -39 X-BigFish: VPS-39(zz217bL15d6O9251J542Nzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail48-tx2 (localhost.localdomain [127.0.0.1]) by mail48-tx2 (MessageSwitch) id 1301933359607431_17681; Mon, 4 Apr 2011 16:09:19 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.248]) by mail48-tx2.bigfish.com (Postfix) with ESMTP id 9046712A004F; Mon, 4 Apr 2011 16:09:19 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 16:09:14 +0000 Received: from NLHILEXH03.connect1.local (172.16.153.78) by connect1.philips.com (172.16.156.151) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 4 Apr 2011 18:09:40 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLHILEXH03.connect1.local ([172.16.153.78]) with mapi; Mon, 4 Apr 2011 18:09:13 +0200 From: "Dijk, Esko" To: Geoff Mulligan , 6lowpan <6lowpan@ietf.org> Date: Mon, 4 Apr 2011 18:08:28 +0200 Thread-Topic: [6lowpan] WG adoption of 6lowpan Implementers guide Thread-Index: Acvu1zeF2CIsOp4NQJqMk+Iz8wS/VQECuCtA Message-ID: References: <1301488616.3846.752.camel@d430> In-Reply-To: <1301488616.3846.752.camel@d430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:07:44 -0000 Dear all, I'm in favor also of adopting this document. More clarification is what I'm= looking for ;) best regards Esko Dijk -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Geoff Mulligan Sent: Wednesday 30 March 2011 14:37 To: 6lowpan Subject: [6lowpan] WG adoption of 6lowpan Implementers guide As we discussed during yesterday's meeting, 6LoWPAN WG has a non-milestone charter item for an "implementers guide" as a running document that captures clarifications and small fixes to our specifications. Carsten has submitted an initial proposal for such a document, draft-bormann-6lowpan-roadmap-00.txt. This document provides a skeleton and does not have many clarifications yet, it could serve as a basis for future work on that implementers guide. This is a call for working group adoption of draft-bormann-6lowpan-roadmap-00.txt. Working group adoption does not mean we agree with every detail of the draft, but that we want to use it as the basis of further working group work. Please reply to the list until Friday, April 8, 23:59 UTC with your position whether this document should be adopted or not. geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Mon Apr 4 09:14:04 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D3C3A682E for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 09:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.148 X-Spam-Level: X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS2bZ3O2ngRb for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 09:14:03 -0700 (PDT) Received: from VA3EHSOBE002.bigfish.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by core3.amsl.com (Postfix) with ESMTP id E34143A6813 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 09:14:02 -0700 (PDT) Received: from mail50-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.8; Mon, 4 Apr 2011 16:15:45 +0000 Received: from mail50-va3 (localhost.localdomain [127.0.0.1]) by mail50-va3-R.bigfish.com (Postfix) with ESMTP id 113A41503C8; Mon, 4 Apr 2011 16:15:45 +0000 (UTC) X-SpamScore: -16 X-BigFish: VPS-16(zzbb2cK217bL15d6O9251Jzz1202hzz8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:smtpx.philips.com; RD:smtpx.philips.com; EFVD:NLI Received: from mail50-va3 (localhost.localdomain [127.0.0.1]) by mail50-va3 (MessageSwitch) id 1301933743400872_18876; Mon, 4 Apr 2011 16:15:43 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.245]) by mail50-va3.bigfish.com (Postfix) with ESMTP id 5CA0A8B0056; Mon, 4 Apr 2011 16:15:43 +0000 (UTC) Received: from smtpx.philips.com (168.87.56.20) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 4 Apr 2011 16:15:39 +0000 Received: from nlamsexh02.connect1.local (172.16.153.23) by connect1.philips.com (172.16.156.151) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 4 Apr 2011 18:16:05 +0200 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by nlamsexh02.connect1.local ([172.16.153.23]) with mapi; Mon, 4 Apr 2011 18:15:38 +0200 From: "Dijk, Esko" To: Carsten Bormann Date: Mon, 4 Apr 2011 18:14:54 +0200 Thread-Topic: Comment on PAN IDs section in draft-bormann-6lowpan-roadmap-00 Thread-Index: Acvy428BEC+F9qH4TomE4wGDriN4NA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A337AA36B3B96E4D853E6182B2F27AE2C76B16911DNLCLUEXM03con_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] Comment on PAN IDs section in draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 16:14:04 -0000 --_000_A337AA36B3B96E4D853E6182B2F27AE2C76B16911DNLCLUEXM03con_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Carsten, here my small comments on the current draft-bormann-6lowpan-roadmap-00: "As the use of PAN identifiers in 6LoWPAN networks has since become less an= d less meaningful," perhaps good to explain why this is the case. Was it more meaningful some y= ears ago? Or is it simply less used. A distinction could be made here also between 1) using PAN IDs in the 802.1= 5.4 radios and 2) using PAN IDs in 6LoWPAN as defined in Section 6 of RFC 4= 944. "It is therefore RECOMMENDED to employ a PAN identifier of zero with 6LoWPA= N." -> maybe good to make clear that implementations may still use non-zero PAN= IDs of their choice at the 802.15.4 level? Only they do not use it in 6LoW= PAN as defined in Section 6 of RFC 4944. best regards, Esko Dijk ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_A337AA36B3B96E4D853E6182B2F27AE2C76B16911DNLCLUEXM03con_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Carsten,

 

here my small comments on the current draft-bormann-= 6lowpan-roadmap-00:

 

"As the use of PAN identifiers in 6LoWPAN netwo= rks has since become less and less meaningful,"

perhaps good to explain why this is the case. Was it= more meaningful some years ago? Or is it simply less used.

A distinction could be made here also between 1) usi= ng PAN IDs in the 802.15.4 radios and 2) using PAN IDs in 6LoWPAN as define= d in Section 6 of RFC 4944.

 

"It is therefore RECOMMENDED to employ a PAN id= entifier of zero with 6LoWPAN."

-> maybe good to make clear that implementations = may still use non-zero PAN IDs of their choice at the 802.15.4 level? Only = they do not use it in 6LoWPAN as defined in Section 6 of RFC 4944.

 

best regards,

 

Esko Dijk

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_A337AA36B3B96E4D853E6182B2F27AE2C76B16911DNLCLUEXM03con_-- From cabo@tzi.org Mon Apr 4 10:38:21 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C2228C108 for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 10:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-s7FI-ntXOe for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 10:38:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 63BB128C12A for <6lowpan@ietf.org>; Mon, 4 Apr 2011 10:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p34HdqDW029176; Mon, 4 Apr 2011 19:39:53 +0200 (CEST) Received: from [192.168.217.112] (p5B3E72A1.dip.t-dialin.net [91.62.114.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 958E6A23; Mon, 4 Apr 2011 19:39:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Mon, 4 Apr 2011 19:39:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2807BEB7-B678-4257-8F0E-D5F368DFFF40@tzi.org> References: To: "Dijk, Esko" X-Mailer: Apple Mail (2.1084) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Comment on PAN IDs section in draft-bormann-6lowpan-roadmap-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 17:38:21 -0000 Indeed, this could be clarified: On Apr 4, 2011, at 18:14, Dijk, Esko wrote: > Dear Carsten, > =20 > here my small comments on the current = draft-bormann-6lowpan-roadmap-00: > =20 > "As the use of PAN identifiers in 6LoWPAN networks has since become = less and less meaningful," > perhaps good to explain why this is the case. Was it more meaningful = some years ago? Or is it simply less used. > A distinction could be made here also between 1) using PAN IDs in the = 802.15.4 radios and 2) using PAN IDs in 6LoWPAN as defined in Section 6 = of RFC 4944. I think it would be useful to collect more data on how PAN identifiers = are actually used in 6LoWPANs. The draft text I wrote is just mirroring what implementers have been = saying the last couple of years. If you run 802.15.4 in non-associated mode, the PAN identifier is not = meaningful. If you do associate, using the PAN Id in the IPv6 address would make you = change your address each time you associate to a different PAN -- which = is exactly what the 6LoWPAN addressing model is trying to avoid. So, my question to the WG is: how are implementers using PAN identifiers = today? (Please respond on the list -- or privately, if you prefer.) > "It is therefore RECOMMENDED to employ a PAN identifier of zero with = 6LoWPAN." > -> maybe good to make clear that implementations may still use = non-zero PAN IDs of their choice at the 802.15.4 level? Only they do not = use it in 6LoWPAN as defined in Section 6 of RFC 4944. (I meant the part about not using any PAN Id in the IPv6 addresses.) Good points that can be described in more detail in the next version of = the draft -- this is exactly the discussion I was hoping to get going = with this document. Gruesse, Carsten From cabo@tzi.org Mon Apr 4 11:34:59 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E743A6407 for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 11:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbpuyDsDStYW for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 11:34:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 2D7BD3A63D2 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 11:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p34IaSqT018894; Mon, 4 Apr 2011 20:36:28 +0200 (CEST) Received: from [192.168.217.112] (p5B3E72A1.dip.t-dialin.net [91.62.114.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 27EB5A65; Mon, 4 Apr 2011 20:36:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4D974387.1070404@gmail.com> Date: Mon, 4 Apr 2011 20:36:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D973B50.9070408@blindcreek.com> <4D974387.1070404@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1084) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 18:35:00 -0000 On Apr 2, 2011, at 17:40, Alexandru Petrescu wrote: > Do you know whether 802.15.4-2011 doc refers to the use of the lowpan > adaptation layer (section 5 of rfc4944)? =20 The current version of the standard, IEEE 802.15.4-2006 does not address = layer 3 issues. (Clearly, it couldn't reference RFC 4944, which was published in 2007.) It's the other way around: RFC 4944 references IEEE 802.15.4, and one = corrigenda that has been proposed is for 4944 to reference IEEE = 802.15.4-2006 and not IEEE 802.15.4-2003. > I can't find the 802.15.4-2011 document. That isn't cooked yet. To get the current versions of the standard: http://standards.ieee.org/about/get/802/802.15.html This page also has a link titled: "IEEE Shop: Buy 802 Draft Standards" There you can buy a copy of the draft a revision of which might become = 802.15.4-2011 later. (Search for 802.15.4; the shop does not make good use of Web links.) One year later, this standard will also become available from the above = link. Gruesse, Carsten From ben@blindcreek.com Mon Apr 4 12:39:04 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E203A67A2 for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 12:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjRXd4pU4NWt for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 12:39:03 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.58]) by core3.amsl.com (Postfix) with ESMTP id E09483A6768 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 12:39:02 -0700 (PDT) Received: from [64.74.213.174] (port=65125 helo=[192.168.250.7]) by wilson.nswebhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q6pdg-0005qF-Cb for 6lowpan@ietf.org; Mon, 04 Apr 2011 14:40:42 -0500 Message-ID: <4D9A1EA3.1090705@blindcreek.com> Date: Mon, 04 Apr 2011 12:40:19 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <4D973B50.9070408@blindcreek.com> <4D974387.1070404@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:39:04 -0000 Some clarification (I hope): P802.15.4-2006 alone is not the current standard: There are three approved amendments and so the current standard is P802.15.4-2006 plus the three amendments approved (P802.15.4a-2007, P802.15.4c-2009 and P802.15.4d-2009). You need all 4 documents to know what is in the current standard. The latest revision, which is in the final stages balloting, is a "roll-up" that rolls all the approved amendments and the prior revision together into one draft. The standard is re-organized to be easier to use and facilitate future revisions more easily (there are 5 TGs working on more amendments to 15.4). The revision is almost "cooked" but as Carsten says not yet served up. The latest draft will be recirculated in a few days. It is expected to be forwarded for publication by end of April. Hope that helps. -B > On Apr 2, 2011, at 17:40, Alexandru Petrescu wrote: > >> Do you know whether 802.15.4-2011 doc refers to the use of the lowpan >> adaptation layer (section 5 of rfc4944)? > The current version of the standard, IEEE 802.15.4-2006 does not address layer 3 issues. > (Clearly, it couldn't reference RFC 4944, which was published in 2007.) > > It's the other way around: RFC 4944 references IEEE 802.15.4, and one corrigenda that has been proposed is for 4944 to reference IEEE 802.15.4-2006 and not IEEE 802.15.4-2003. > >> I can't find the 802.15.4-2011 document. > That isn't cooked yet. > > To get the current versions of the standard: > > http://standards.ieee.org/about/get/802/802.15.html > > This page also has a link titled: "IEEE Shop: Buy 802 Draft Standards" > > There you can buy a copy of the draft a revision of which might become 802.15.4-2011 later. > (Search for 802.15.4; the shop does not make good use of Web links.) > One year later, this standard will also become available from the above link. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From cabo@tzi.org Mon Apr 4 12:49:23 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137963A67A3 for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 12:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAU0eyXZ2saM for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 12:49:22 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 131AF3A6768 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 12:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p34JorKS010527; Mon, 4 Apr 2011 21:50:53 +0200 (CEST) Received: from [192.168.217.112] (p5B3E72A1.dip.t-dialin.net [91.62.114.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 95615A8D; Mon, 4 Apr 2011 21:50:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <4D9A1EA3.1090705@blindcreek.com> Date: Mon, 4 Apr 2011 21:50:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66BF0BEC-1BAC-40EA-BB95-DE15A8077ED7@tzi.org> References: <4D973B50.9070408@blindcreek.com> <4D974387.1070404@gmail.com> <4D9A1EA3.1090705@blindcreek.com> To: "Benjamin A. Rolfe" X-Mailer: Apple Mail (2.1084) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 19:49:23 -0000 On Apr 4, 2011, at 21:40, Benjamin A. Rolfe wrote: > P802.15.4-2006 alone is not the current standard: There are three = approved amendments and so the current standard is P802.15.4-2006 plus = the three amendments approved (P802.15.4a-2007, P802.15.4c-2009 and = P802.15.4d-2009). You need all 4 documents to know what is in the = current standard. So one interesting question would be -- does 6LoWPAN (RFC 4944 - HC1/2 + = HC + ND) work with all these? Gruesse, Carsten From cabo@tzi.org Mon Apr 4 13:04:06 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF503A67CC for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 13:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdSULTIS28nS for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 13:04:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id F30193A67C3 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 13:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p34K5bD6013728; Mon, 4 Apr 2011 22:05:37 +0200 (CEST) Received: from [192.168.217.112] (p5B3E72A1.dip.t-dialin.net [91.62.114.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E3E9CA95; Mon, 4 Apr 2011 22:05:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1301679639.6495.12.camel@Nokia-N900> Date: Mon, 4 Apr 2011 22:05:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com> <1301679639.6495.12.camel@Nokia-N900> To: Oliver Hahm X-Mailer: Apple Mail (2.1084) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:04:07 -0000 On Apr 1, 2011, at 19:40, Oliver Hahm wrote: > Therefore, a more generic specification for IPv6 over low-power = wireless foo would be really interesting for us - and probably a lot of = other people as CC1020 and CC110x are very popular transceivers for WSN. I think that is an interesting idea. How much of such a specification = could be generic and how much would need to be specific to each of the = radios? Can you describe the decisions you had to take in applying = 6LoWPAN to these radios? And, even better, can you write a draft? Gruesse, Carsten From ben@blindcreek.com Mon Apr 4 13:12:32 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEEB3A67CC for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 13:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOu6H0VBa9iG for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 13:12:31 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.58]) by core3.amsl.com (Postfix) with ESMTP id 8759F3A67CF for <6lowpan@ietf.org>; Mon, 4 Apr 2011 13:12:31 -0700 (PDT) Received: from [64.74.213.174] (port=51237 helo=[192.168.250.7]) by wilson.nswebhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q6q9v-00050I-Iw for 6lowpan@ietf.org; Mon, 04 Apr 2011 15:14:11 -0500 Message-ID: <4D9A266C.80403@blindcreek.com> Date: Mon, 04 Apr 2011 13:13:32 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 CC: 6lowpan@ietf.org References: <4D973B50.9070408@blindcreek.com> <4D974387.1070404@gmail.com> <4D9A1EA3.1090705@blindcreek.com> <66BF0BEC-1BAC-40EA-BB95-DE15A8077ED7@tzi.org> In-Reply-To: <66BF0BEC-1BAC-40EA-BB95-DE15A8077ED7@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 20:12:32 -0000 Yes, a very interesting question! The three approved amendments define new PHY layers. All of the currently defined PHYs share a maximum PSDU size of 127. There are some added MAC features to support new PHY features but the basic MAC has not changed. Perhaps a more specific question is, what features of the PHYs and MAC does 6LoWPAN depend on to work? -B > On Apr 4, 2011, at 21:40, Benjamin A. Rolfe wrote: > >> P802.15.4-2006 alone is not the current standard: There are three approved amendments and so the current standard is P802.15.4-2006 plus the three amendments approved (P802.15.4a-2007, P802.15.4c-2009 and P802.15.4d-2009). You need all 4 documents to know what is in the current standard. > So one interesting question would be -- does 6LoWPAN (RFC 4944 - HC1/2 + HC + ND) work with all these? > > Gruesse, Carsten > > From trac+6lowpan@trac.tools.ietf.org Wed Mar 30 14:29:37 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B399C3A6BD3 for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 14:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHZeL1-F3G6G for <6lowpan@core3.amsl.com>; Wed, 30 Mar 2011 14:29:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E18093A6BD2 for <6lowpan@ietf.org>; Wed, 30 Mar 2011 14:29:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q52yx-0003BV-71; Wed, 30 Mar 2011 14:31:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com X-Trac-Project: 6lowpan Date: Wed, 30 Mar 2011 21:31:15 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/133 Message-ID: <060.66e48e8e0a702277b0a6194727866a66@trac.tools.ietf.org> X-Trac-Ticket-ID: 133 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac+6lowpan@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 04 Apr 2011 21:36:58 -0700 Cc: 6lowpan@ietf.org Subject: [6lowpan] #133: Applicability text X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:29:37 -0000 #133: Applicability text Increased interest has been indicated on the applicability of the ND optimization techniques outside of LLNs. For example Pascal's request for mixed RFC4861 use on transitive (Ethernet) links. As concluded in the Prague WG meeting, although there surely are promising applications, this document is limited in scope to the application of the specification as a whole to LLNs. This ticket is to add text to the applicability section to explain that the WG understands the possible use of these mechanisms, but that this is out of scope of the document and needs to be specified elsewhere. -- --------------------------------+------------------------------------------- Reporter: zach@… | Owner: zach@… Type: enhancement | Status: new Priority: trivial | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- Ticket URL: 6lowpan From Gabor.Bajko@nokia.com Fri Apr 1 02:33:30 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 678D33A67B7 for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 02:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH5FK0H2bj6q for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 02:33:29 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 558073A67B3 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 02:33:29 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p319Yqn3023897 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 12:35:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 12:34:57 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 1 Apr 2011 11:34:56 +0200 Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([169.254.7.42]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Fri, 1 Apr 2011 11:34:56 +0200 From: To: <6lowpan@ietf.org> Thread-Topic: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy Thread-Index: AcvwT/22/AYqDP9LQQyro5PVX8LGew== Date: Fri, 1 Apr 2011 09:34:56 +0000 Message-ID: <7DDB35B005136A4DB9FF33E7E286EF000692F2@008-AM1MPN1-037.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.7.12 x-putclassificationandsendinfointox-header: Classification: Personal Project: Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy Sender Name: Bajko Gabor (Nokia-CIC/SiliconValley) Sender Email: Gabor.Bajko@nokia.com Send Date: Friday, April 01, 2011 Send Time: 2:34:56 AM x-tituslabs-classifications-30: TLPropertyRoot=Trial License;Classification=Personal; x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Im6yxHPDOfTH56DQQrDKX/pVS9Uw9huCIalyvktsp+dzPnXJkkolx8LnEJyky8RiexQfS+ch0O2gtRQJSiA55for5KkTly8JTZ0ZZS299Cx0Eksy9sfiustT13cXqyEUbt/3jdG1P4/hAqpN1ERpppIhrzMfHx/P/bQ3DfLMCzpNQmWLL/hQrYZBrmDrmNHfRX9/oJ/P0DrJFXkcvLkNPtcREKA0nYRXqa75GYH9eQr56NfC3g82Cl32r56CJaay3A== x-originating-ip: [130.129.23.15] Content-Type: multipart/alternative; boundary="_000_7DDB35B005136A4DB9FF33E7E286EF000692F2008AM1MPN1037mgdn_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2011 09:34:57.0113 (UTC) FILETIME=[1043F490:01CBF050] X-Nokia-AV: Clean X-Mailman-Approved-At: Mon, 04 Apr 2011 21:36:58 -0700 Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 09:33:30 -0000 --_000_7DDB35B005136A4DB9FF33E7E286EF000692F2008AM1MPN1037mgdn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 > Re: [6lowpan] WG adoption of 6lowpan Implementers guide That's what you get when you edit one message out of another. It's been a long week... Of course, this is about the BT-LE draft, not about the implementers guide. Please make sure you reply with the subject of this message, in particular = if it is just a "+1"... Sorry for the confusion, Carsten On Mar 31, 2011, at 19:47, Carsten Bormann wrote: > It appears I was a bit quick dismissing BT-LE as a working group item dur= ing Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can very we= ll request the addition of milestones. As the support in the room for work= ing on the adaptation of 6LoWPAN for BT-LE was quite good, I'm now issuing = a call for WG adoption. > > This is a call for working group adoption of > draft-patil-6lowpan-v6over-btle-01.txt > > Working group adoption does not mean we agree with every detail of the > draft, but that we want to use it as the basis of further working group > work. > > Please reply to the list until > > Friday, April 8, 23:59 UTC > > with your position whether this document should be adopted or not. > > Gruesse, Carsten --_000_7DDB35B005136A4DB9FF33E7E286EF000692F2008AM1MPN1037mgdn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

> Re: [6lowpan] WG adoption of 6lowpan Implementers gui= de

 

That's what you get when you edit one message out of anoth= er.

It's been a long week...

Of course, this is about the BT-LE draft, not about the im= plementers guide.

Please make sure you reply with the subject of this messag= e, in particular if it is just a "+1"...

 

Sorry for the confusion,

Carsten

 

On Mar 31, 2011, at 19:47, Carsten Bormann wrote:

 

> It appears I was a bit quick dismissing BT-LE as a wo= rking group item during Tuesday's 6LoWPAN meeting.  The WG is alive an= d well, so we can very well request the addition of milestones.  As the support in the room for working on the adaptation of 6LoWPAN for BT= -LE was quite good, I'm now issuing a call for WG adoption.

>

> This is a call for working group adoption of

> draft-patil-6lowpan-v6over-btle-01.txt

>

> Working group adoption does not mean we agree with ev= ery detail of the

> draft, but that we want to use it as the basis of fur= ther working group

> work.

>

> Please reply to the list until

>

>       Friday, April 8, = 23:59 UTC

>

> with your position whether this document should be ad= opted or not.

>

> Gruesse, Carsten

 

--_000_7DDB35B005136A4DB9FF33E7E286EF000692F2008AM1MPN1037mgdn_-- From trac+6lowpan@trac.tools.ietf.org Fri Apr 1 06:50:15 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BAEE3A681C for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 06:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgXmfuVY3+pQ for <6lowpan@core3.amsl.com>; Fri, 1 Apr 2011 06:50:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 68DCC3A6828 for <6lowpan@ietf.org>; Fri, 1 Apr 2011 06:50:12 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q5elS-0001Yf-VE; Fri, 01 Apr 2011 06:51:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "6lowpan issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: zach@sensinode.com, samita.chakrabarti@ericsson.com X-Trac-Project: 6lowpan Date: Fri, 01 Apr 2011 13:51:50 -0000 X-URL: http://tools.ietf.org/6lowpan/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/134 Message-ID: <073.1627a0e055623dae3f935b73ca7a33a0@trac.tools.ietf.org> X-Trac-Ticket-ID: 134 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: zach@sensinode.com, samita.chakrabarti@ericsson.com, 6lowpan@ietf.org X-SA-Exim-Mail-From: trac+6lowpan@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 04 Apr 2011 21:36:58 -0700 Cc: 6lowpan@ietf.org Subject: [6lowpan] #134: Editorial fixes for ND-15 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Reply-To: 6lowpan@ietf.org List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:50:15 -0000 #134: Editorial fixes for ND-15 Editorial Comments from Colin : Section 1.3 ( Applicability, Assumption and Goals) Consolidation or deletion of a few redundant bullet points Comment: 1) o Optimize Neighbor Discovery with a mechanism that is minimal yet sufficient for the operation in both mesh-under and route-over configurations. o Make the host to router interaction the same whether mesh-under or route-over is used. *These last two points could probably be consolidated into one point. Updated text: (Removed the 2nd bullet) o Optimize Neighbor Discovery with a mechanism that is minimal yet sufficient for the operation in both mesh-under and route-over configurations. 2) o Minimize signaling by avoiding the use of multicast flooding and reducing the use of link-scope multicast messages. o Optimize the interfaces between hosts and their default routers. *This could also also be fit in with the first two points I think ==> We like to keep the text as it is for clarity 3) o Support for sleeping hosts. o Minimize the complexity of nodes. *Point can be deleted, nobody wants complex nodes, and it's already a goal to make the mechanism 'minimal', which implies to me the nodes are not as complex ==> Updated text: Deleted Section 6.5.4 : (Next hop Determination for the Routers) Current text: It is the responsibility of the routing protocol to maintain on-link information about its registered neighbors. Tentative NCEs MUST NOT be used to maintain on-link status. Comment: NCE undefined Comment: Refer to 5.6 Proposed Change: It is the responsibility of the routing protocol of the router to maintain on-link information about its registered neighbors. Tentative NCEs MUST NOT be used to determine on-link status of the registered nodes. Section 8.2 Current text : ( contains unnecessary bracketed text) (This is needed to handle the case when multiple hosts try to register the same IPv6 address at the same time.) If no Neighbor Cache entry exists, then Updated text: Removed brackets And more updates suggested by Erik as follows: It is true that we never define "NCE". But the first time we use that acronym is in section 1.3 hence a reference in 6.5.4 doesn't seem that useful. I'd suggest the following edits to make things flow better. In section 3.5 add "(NCE)" thus change FROM: The use of explicit registrations with lifetimes plus the desire to not multicast Neighbor Solicitation messages for hosts imply that we manage the Neighbor Cache entries slightly differently than in [RFC4861]. This results in three different types of NCEs and the types specify how those entries can be removed: TO: The use of explicit registrations with lifetimes plus the desire to not multicast Neighbor Solicitation messages for hosts imply that we manage the Neighbor Cache entries (NCE) slightly differently than in [RFC4861]. This results in three different types of NCEs and the types specify how those entries can be removed: We also need to cleanup the last bullet in section 1.3. It is a bit out of place since it says a lot more than a goal or an assumption. I observe that we have a sentence about mobility in section 3.3. Thus I suggest in section 1.3 change FROM If the node loses connectivity with the default router involunterily, then the default router does not know the node has moved until it runs the unreachability detection. In order to optimize the time for detecting unreachability of a run-away node, a default-router may use link-layer indication or configure a lower NCE life-time value and low registration life-time value - so that it can remove the NCE of the run-away node as soon as possible. TO To handle the case when a node loses connectivity with the default router involunterily, the node should use a suitably low registration lifetime. -- ---------------------------------------------+------------------------------ Reporter: samita.chakrabarti@… | Owner: zach@… Type: task | Status: new Priority: major | Milestone: Component: format | Version: Severity: - | Keywords: editorial ---------------------------------------------+------------------------------ Ticket URL: 6lowpan From geoff.ietf@mulligan.com Mon Apr 4 21:55:37 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCEE3A68AC for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 21:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.325 X-Spam-Level: X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3U-ewsvt-Iv for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 21:55:36 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by core3.amsl.com (Postfix) with ESMTP id A75213A68A9 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 21:55:36 -0700 (PDT) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 924D818420 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 22:57:27 -0600 (MDT) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id BC34C7FC79 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 22:57:17 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 04 Apr 2011 22:57:18 -0600 Message-ID: <1301979438.1743.1130.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Subject: [6lowpan] WG adoption of GHC draft X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 04:55:37 -0000 This is a call for working group adoption of draft-bormann-6lowpan-ghc-02.txt This document has been discussed for the past couple of meeting. Carsten has made some improvements. As you know, just because the working group adopts a document doesn't mean we agree with every detail of the draft, but that we want to use it as the basis of further work. Please reply to the list until Friday, April 15, 23:59 UTC with your position whether this document should be adopted or not. geoff From johanna.1.nieminen@nokia.com Mon Apr 4 23:11:16 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F97E3A68B7 for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 23:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FyXZfTSXQhQ for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 23:11:12 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id CA15D3A6806 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 23:11:11 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p356B8JG012518; Tue, 5 Apr 2011 09:12:48 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 09:11:30 +0300 Received: from 008-AM1MMR1-006.mgdnok.nokia.com (65.54.30.61) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 5 Apr 2011 08:11:30 +0200 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0270.002; Tue, 5 Apr 2011 08:11:29 +0200 From: To: Thread-Topic: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Thread-Index: AQHL8FQOno4OE0HBYEe56BElkG/HEZRIqIYAgAAFuYCAAAw0gIAB0kgAgAAJy4CAA1W0gIAAEdiAgAAC8wCAAAZVAIAAwz3w Date: Tue, 5 Apr 2011 06:11:28 +0000 Message-ID: References: <4D973B50.9070408@blindcreek.com> <4D974387.1070404@gmail.com> <4D9A1EA3.1090705@blindcreek.com> <66BF0BEC-1BAC-40EA-BB95-DE15A8077ED7@tzi.org> <4D9A266C.80403@blindcreek.com> In-Reply-To: <4D9A266C.80403@blindcreek.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.34.222] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Apr 2011 06:11:30.0109 (UTC) FILETIME=[4DF9F6D0:01CBF358] X-Nokia-AV: Clean Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 06:11:16 -0000 Hi, When thinking about the solution for IPv6 over foo, the following issues ar= e most important: 1. Link layer support for SAR If SAR functionality is supported in the link layer and maximum MTU is larg= e enough, separate adaptation layer is not needed in 6LoWpan. If SAR is not= supported, then 6LoWpan adaptation layer is needed above PHY/Link layers. 2. Topology Typically mesh or star topology. In a star topology not all 6LoWpan functio= nalities are required (e.g mesh headers). 3. Memory, power consumption and price Different sensor technologies may have different optimization criteria. For= some technologies e.g. low memory and power consumption as well as price c= an be a very critical factor. Thus adding new stack to the sensor might be = undesirable - or at least low memory and power consumption are considered m= ore important than advanced functionalities. In principle, we could design a generic solution by classifying low power r= adios based on the above features. However, we are not aware of new radio t= echnologies that may emerge. Since we don't know their possible limitations= in the MAC/PHY layer it would be rather bold to claim that we have a solut= ion for "low power IPv6 over foo". In my opinion it would be best to first = pick some other radio that is not based on 802.15.4 (like Bluetooth Low Ene= rgy), specify the solution in the WG and if we still agree that requirement= s can be generalized at least for certain types of radios change the name o= f the draft or create another draft. Johanna >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >Behalf Of ext Benjamin A. Rolfe >Sent: 04 April, 2011 23:14 >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle- >01.txt > >Yes, a very interesting question! >The three approved amendments define new PHY layers. All of the >currently defined PHYs share a maximum PSDU size of 127. >There are some added MAC features to support new PHY features but the >basic MAC has not changed. >Perhaps a more specific question is, what features of the PHYs and MAC >does 6LoWPAN depend on to work? >-B > >> On Apr 4, 2011, at 21:40, Benjamin A. Rolfe wrote: >> >>> P802.15.4-2006 alone is not the current standard: There are three >approved amendments and so the current standard is P802.15.4-2006 plus >the three amendments approved (P802.15.4a-2007, P802.15.4c-2009 and >P802.15.4d-2009). You need all 4 documents to know what is in the >current standard. >> So one interesting question would be -- does 6LoWPAN (RFC 4944 - HC1/2 >+ HC + ND) work with all these? >> >> Gruesse, Carsten >> >> > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From coflynn@newae.com Mon Apr 4 23:45:13 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE27A3A68C6 for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 23:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOKzYI5ljXgT for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 23:45:12 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 4BBAD3A68B5 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 23:45:12 -0700 (PDT) Received: from [77.107.140.146] (helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q702Q-0004SK-H5; Tue, 05 Apr 2011 02:46:54 -0400 From: "Colin O'Flynn" To: "'Benjamin A. Rolfe'" References: <4D973B50.9070408@blindcreek.com> <4D974387.1070404@gmail.com> <4D9A1EA3.1090705@blindcreek.com> <66BF0BEC-1BAC-40EA-BB95-DE15A8077ED7@tzi.org> <4D9A266C.80403@blindcreek.com> In-Reply-To: <4D9A266C.80403@blindcreek.com> Date: Tue, 5 Apr 2011 07:46:51 +0200 Message-ID: <001c01cbf354$dead68a0$9c0839e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvzBN/HPJ6HpjmARvmDmUMZ6BrT4AAT2iSw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 06:45:13 -0000 Hello, > Perhaps a more specific question is, what features of the PHYs > and MAC > does 6LoWPAN depend on to work? Basically, zero. RFC4944 + 6lowpan-hc assumes/uses the following: * You have a 16-bit short address * You have a 64-bit long address (EUI) * You have a 16-bit PAN-ID (this isn't used in -hc anymore, but RFC4944 * You have a 127 byte payload * You have a 'broadcast' mode It only uses data transmissions: there is no scanning, beaconing, etc etc. All that 'extra stuff' is left up to another layer if you want to use it. -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: April 4, 2011 10:14 PM Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Yes, a very interesting question! The three approved amendments define new PHY layers. All of the currently defined PHYs share a maximum PSDU size of 127. There are some added MAC features to support new PHY features but the basic MAC has not changed. Perhaps a more specific question is, what features of the PHYs and MAC does 6LoWPAN depend on to work? -B > On Apr 4, 2011, at 21:40, Benjamin A. Rolfe wrote: > >> P802.15.4-2006 alone is not the current standard: There are three approved amendments and so the current standard is P802.15.4-2006 plus the three amendments approved (P802.15.4a-2007, P802.15.4c-2009 and P802.15.4d-2009). You need all 4 documents to know what is in the current standard. > So one interesting question would be -- does 6LoWPAN (RFC 4944 - HC1/2 + HC + ND) work with all these? > > Gruesse, Carsten > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From coflynn@newae.com Mon Apr 4 23:46:44 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2E433A68C6 for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 23:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvEi1q50xQuu for <6lowpan@core3.amsl.com>; Mon, 4 Apr 2011 23:46:44 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id D93293A68B5 for <6lowpan@ietf.org>; Mon, 4 Apr 2011 23:46:43 -0700 (PDT) Received: from [77.107.140.146] (helo=COLINNETBOOK) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Q703u-0004wq-J2; Tue, 05 Apr 2011 02:48:26 -0400 From: "Colin O'Flynn" To: "'Colin O'Flynn'" , "'Benjamin A. Rolfe'" References: <4D973B50.9070408@blindcreek.com> <4D974387.1070404@gmail.com> <4D9A1EA3.1090705@blindcreek.com> <66BF0BEC-1BAC-40EA-BB95-DE15A8077ED7@tzi.org> <4D9A266C.80403@blindcreek.com> <001c01cbf354$dead68a0$9c0839e0$@com> In-Reply-To: <001c01cbf354$dead68a0$9c0839e0$@com> Date: Tue, 5 Apr 2011 07:48:23 +0200 Message-ID: <001f01cbf355$15837ea0$408a7be0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvzBN/HPJ6HpjmARvmDmUMZ6BrT4AAT2iSwAAAoNTA= Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 06:46:45 -0000 Appologies - I'm typing on a netbook keyboard and somehow hit the 'send' shortcut by accident. The line: * You have a 16-bit PAN-ID (this isn't used in -hc anymore, but RFC4944 Should read (I wasn't done typing): * You have a 16-bit PAN-ID (this isn't used in -hc anymore, but RFC4944 still references it in broadcast frames) Regards, -Colin O'Flynn -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Colin O'Flynn Sent: April 5, 2011 7:47 AM To: 'Benjamin A. Rolfe' Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Hello, > Perhaps a more specific question is, what features of the PHYs > and MAC > does 6LoWPAN depend on to work? Basically, zero. RFC4944 + 6lowpan-hc assumes/uses the following: * You have a 16-bit short address * You have a 64-bit long address (EUI) * You have a 16-bit PAN-ID (this isn't used in -hc anymore, but RFC4944 * You have a 127 byte payload * You have a 'broadcast' mode It only uses data transmissions: there is no scanning, beaconing, etc etc. All that 'extra stuff' is left up to another layer if you want to use it. -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Benjamin A. Rolfe Sent: April 4, 2011 10:14 PM Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Yes, a very interesting question! The three approved amendments define new PHY layers. All of the currently defined PHYs share a maximum PSDU size of 127. There are some added MAC features to support new PHY features but the basic MAC has not changed. Perhaps a more specific question is, what features of the PHYs and MAC does 6LoWPAN depend on to work? -B > On Apr 4, 2011, at 21:40, Benjamin A. Rolfe wrote: > >> P802.15.4-2006 alone is not the current standard: There are three approved amendments and so the current standard is P802.15.4-2006 plus the three amendments approved (P802.15.4a-2007, P802.15.4c-2009 and P802.15.4d-2009). You need all 4 documents to know what is in the current standard. > So one interesting question would be -- does 6LoWPAN (RFC 4944 - HC1/2 + HC + ND) work with all these? > > Gruesse, Carsten > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Tue Apr 5 00:08:30 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BA43A68C6 for <6lowpan@core3.amsl.com>; Tue, 5 Apr 2011 00:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiRBBHkjQJVV for <6lowpan@core3.amsl.com>; Tue, 5 Apr 2011 00:08:29 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 064883A67EF for <6lowpan@ietf.org>; Tue, 5 Apr 2011 00:08:28 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p357A7kt004833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Apr 2011 10:10:07 +0300 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-282--589821737; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <1301488616.3846.752.camel@d430> Date: Tue, 5 Apr 2011 10:10:08 +0300 Message-Id: <7F574EFD-A7B3-485A-BAAB-9571C85FC00D@sensinode.com> References: <1301488616.3846.752.camel@d430> To: Geoff Mulligan X-Mailer: Apple Mail (2.1082) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 07:08:30 -0000 --Apple-Mail-282--589821737 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I support accepting the roadmap as our WG implementer's guide document. Zach On Mar 30, 2011, at 3:36 PM, Geoff Mulligan wrote: > As we discussed during yesterday's meeting, 6LoWPAN WG has a > non-milestone charter item for an "implementers guide" as a running > document that captures clarifications and small fixes to our > specifications. > > Carsten has submitted an initial proposal for such a document, > draft-bormann-6lowpan-roadmap-00.txt. This document provides a skeleton > and does not have many clarifications yet, it could serve as a basis for > future work on that implementers guide. > > This is a call for working group adoption of > draft-bormann-6lowpan-roadmap-00.txt. > > Working group adoption does not mean we agree with every detail of the > draft, but that we want to use it as the basis of further working group > work. > > Please reply to the list until > > Friday, April 8, 23:59 UTC > > with your position whether this document should be adopted or not. > > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-282--589821737 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQwNTA3MTAw OVowIwYJKoZIhvcNAQkEMRYEFLIkfXdgvw7Gdmx6VbaXvcDEe+FGMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBABgCE0EDOZNqk6aegTPWVb2uwo0XS+7J+2eb+JCPJlvyfOK2tqMVEphX 8mf2e0OeQCYV0BP6103XevBB7pmE1WqUj+eMOWktfj/yG1h0QGCR7+N8Wx51buzN1T6JCc2B1x7j HrISGmXsHqQIXE3xaj+0F8bwBNydjsgi1HVnEqDjGp4Pc4jqhBNrQZcIVBbGE8hFNhl14rgfWD6K y2GE2oT6gRW/HA2GaVF6dZeV4uIf/98etpD7Q7WtMFVVGIA44KcivupTldiaj9PBZJIUBrXtn920 OhFMn7HBKQX2Z+tUaT99/a9zSlr+2STYE2WGbdVeLBaeP95uto/MnnbX3d0AAAAAAAA= --Apple-Mail-282--589821737-- From c.chauvenet@watteco.com Wed Apr 6 01:45:24 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC96728C0E7 for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 01:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMlZMjUwhYvL for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 01:45:24 -0700 (PDT) Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by core3.amsl.com (Postfix) with ESMTP id E59F73A681D for <6lowpan@ietf.org>; Wed, 6 Apr 2011 01:45:23 -0700 (PDT) Received: from mail24-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.8; Wed, 6 Apr 2011 08:47:06 +0000 Received: from mail24-tx2 (localhost.localdomain [127.0.0.1]) by mail24-tx2-R.bigfish.com (Postfix) with ESMTP id 55EEF132055B; Wed, 6 Apr 2011 08:47:06 +0000 (UTC) X-SpamScore: -90 X-BigFish: VPS-90(zz1418M15caKJ1453M98dK14ffOzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB007.red002.local; RD:none; EFVD:NLI Received: from mail24-tx2 (localhost.localdomain [127.0.0.1]) by mail24-tx2 (MessageSwitch) id 130207961022529_909; Wed, 6 Apr 2011 08:46:50 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.252]) by mail24-tx2.bigfish.com (Postfix) with ESMTP id 5882913100C5; Wed, 6 Apr 2011 08:45:43 +0000 (UTC) Received: from IE2RD2HUB007.red002.local (213.199.187.153) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 6 Apr 2011 08:45:39 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB007.red002.local ([10.33.16.155]) with mapi; Wed, 6 Apr 2011 01:45:05 -0700 From: C Chauvenet To: Carsten Bormann , Oliver Hahm Date: Wed, 6 Apr 2011 01:45:02 -0700 Thread-Topic: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Thread-Index: AcvzA7eoVQ4Aw3QbQxS0tR+2Sl7PiwBMa0VQ Message-ID: References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com> <1301679639.6495.12.camel@Nokia-N900> <13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> In-Reply-To: <13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 08:45:24 -0000 Hi All,=20 I definitely push the idea of a "generic IPv6 over low power foo" specifica= tion (if achievable). IPv6 may be used over various low power media, and if a generic adaptation = layer can be designed, this may avoid to write a specification fo each low = power media (exiting and to appear) that use IPv6. By the way, low power media cannot be restricted to wireless media. We also= have to consider wired media (like low power PLC currentlty specified in I= EEE P1901.2) as they shared many requirements with well known LoWPAN techno= logies. C=E9dric. -----Message d'origine----- De=A0: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] De la par= t de Carsten Bormann Envoy=E9=A0: lundi 4 avril 2011 22:05 =C0=A0: Oliver Hahm Cc=A0: 6lowpan@ietf.org Objet=A0: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.t= xt On Apr 1, 2011, at 19:40, Oliver Hahm wrote: > Therefore, a more generic specification for IPv6 over low-power wireless = foo would be really interesting for us - and probably a lot of other people= as CC1020 and CC110x are very popular transceivers for WSN. I think that is an interesting idea. How much of such a specification coul= d be generic and how much would need to be specific to each of the radios? = Can you describe the decisions you had to take in applying 6LoWPAN to thes= e radios? And, even better, can you write a draft? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Wed Apr 6 02:21:40 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE8133A68E6 for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 02:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.415 X-Spam-Level: X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhPJKDS6IEuy for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 02:21:39 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id B1AF03A68F6 for <6lowpan@ietf.org>; Wed, 6 Apr 2011 02:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2404; q=dns/txt; s=iport; t=1302081803; x=1303291403; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=inW70ohMG8r+rPnvtxHsCvqF/DkNu5vUQelTweYqFO8=; b=cl/lCBr4MLRA36/0x01lBF8T1/NbvRyLodgMhab21S1DDqUYF+5/w/nK e0Kujytgq4KnY+Z1ypKL56ZoRI83WlUmKnPNUdd1iyw4+7WWSUn9+jLUj UNa2+WFVLkvixs0SfF4R9nnG2TM7QJ3gF2o+gwqQwMlKa//PlhZZpjKfm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMAANAwnE2Q/khNgWdsb2JhbACYLY1KFAEBFiYlpSqcFIVsBJEi X-IronPort-AV: E=Sophos;i="4.63,309,1299456000"; d="scan'208";a="24622935" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 06 Apr 2011 09:23:22 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p369NLCo001270; Wed, 6 Apr 2011 09:23:21 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 11:23:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Apr 2011 11:23:16 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D044F758E@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Thread-Index: AcvzA7eoVQ4Aw3QbQxS0tR+2Sl7PiwBMa0VQAAGG+CA= References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com><1301679639.6495.12.camel@Nokia-N900><13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> From: "Pascal Thubert (pthubert)" To: "C Chauvenet" , "Carsten Bormann" , "Oliver Hahm" X-OriginalArrivalTime: 06 Apr 2011 09:23:21.0865 (UTC) FILETIME=[45EE4790:01CBF43C] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 09:21:41 -0000 Agreed.=20 Also, I've seen interest in IPv6 over DECT, with the advantage of an = unlicensed band (mostly 1880 - 1900 MHz in Europe) that's dedicated to = the technology. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of C Chauvenet > Sent: Wednesday, April 06, 2011 10:45 AM > To: Carsten Bormann; Oliver Hahm > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle- > 01.txt >=20 > Hi All, >=20 > I definitely push the idea of a "generic IPv6 over low power foo" = specification > (if achievable). > IPv6 may be used over various low power media, and if a generic = adaptation > layer can be designed, this may avoid to write a specification fo each = low > power media (exiting and to appear) that use IPv6. > By the way, low power media cannot be restricted to wireless media. We > also have to consider wired media (like low power PLC currentlty = specified in > IEEE P1901.2) as they shared many requirements with well known LoWPAN > technologies. >=20 > C=E9dric. >=20 > -----Message d'origine----- > De=A0: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] De = la > part de Carsten Bormann Envoy=E9=A0: lundi 4 avril 2011 22:05 =C0=A0: = Oliver Hahm Cc=A0: > 6lowpan@ietf.org Objet=A0: Re: [6lowpan] WG adoption of = draft-patil-6lowpan- > v6over-btle-01.txt >=20 > On Apr 1, 2011, at 19:40, Oliver Hahm wrote: >=20 > > Therefore, a more generic specification for IPv6 over low-power = wireless > foo would be really interesting for us - and probably a lot of other = people as > CC1020 and CC110x are very popular transceivers for WSN. >=20 > I think that is an interesting idea. How much of such a specification = could be > generic and how much would need to be specific to each of the radios? = Can > you describe the decisions you had to take in applying 6LoWPAN to = these > radios? >=20 > And, even better, can you write a draft? >=20 > Gruesse, Carsten >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Wed Apr 6 03:02:59 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4AC28C123 for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 03:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.188 X-Spam-Level: X-Spam-Status: No, score=-106.188 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m41oWrIvRFE1 for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 03:02:58 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 1070D28C105 for <6lowpan@ietf.org>; Wed, 6 Apr 2011 03:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p36A4X0K016949; Wed, 6 Apr 2011 12:04:33 +0200 (CEST) Received: from [10.0.1.2] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6202D329; Wed, 6 Apr 2011 12:04:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Wed, 6 Apr 2011 12:04:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1922183C-DB17-4782-A7BB-F811D5C102F1@tzi.org> References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com> <1301679639.6495.12.camel@Nokia-N900> <13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> To: C Chauvenet X-Mailer: Apple Mail (2.1084) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 10:02:59 -0000 On Apr 6, 2011, at 10:45, C Chauvenet wrote: > I definitely push the idea of a "generic IPv6 over low power foo" = specification (if achievable). That is my point -- if there is a way to do this in a reusable, mostly = generic fashion, this would be great. I'm assuming there generally always will need to be some shim -- e.g., = if the PHY/MAC spec already has a multiplexing point, how to hook into = that, and possibly some other radio parameters that need to be set the = same on both sides for interoperability. That's why I was looking for some input from people who have done work = on the constrained networks we are talking about. Please write a (short) draft, or (alternatively) give me a few = paragraphs that could for example go into the 6LoWPAN roadmap document = until there is critical mass for a separate spec. Gruesse, Carsten From oliver.hahm@fu-berlin.de Wed Apr 6 06:18:42 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D396528C11A for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 06:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNDA2nVQqf6Y for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 06:18:42 -0700 (PDT) Received: from stillroot.org (stillroot.org [85.10.195.133]) by core3.amsl.com (Postfix) with ESMTP id D770828C0EA for <6lowpan@ietf.org>; Wed, 6 Apr 2011 06:18:41 -0700 (PDT) Received: by stillroot.org (Postfix, from userid 1007) id CD805544004; Wed, 6 Apr 2011 15:20:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by stillroot.org (Postfix) with ESMTP id 432EB544007; Wed, 6 Apr 2011 15:20:24 +0200 (CEST) Received: from stillroot.org ([127.0.0.1]) by localhost (stillroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxI31NZ86lvp; Wed, 6 Apr 2011 15:20:22 +0200 (CEST) Received: from stedten.imp.fu-berlin.de (stedten.imp.fu-berlin.de [160.45.114.7]) by stillroot.org (Postfix) with ESMTPA id 2B1C3544004; Wed, 6 Apr 2011 15:20:21 +0200 (CEST) Received: by stedten.imp.fu-berlin.de (sSMTP sendmail emulation); Wed, 06 Apr 2011 15:20:20 +0200 Date: Wed, 6 Apr 2011 15:20:20 +0200 From: Oliver Hahm To: Carsten Bormann Message-ID: <20110406132020.GI7336@stillroot.org> References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com> <1301679639.6495.12.camel@Nokia-N900> <13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Bogosity: Unsure, tests=bogofilter, spamicity=0.958814, version=1.1.7 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 13:18:42 -0000 Hi, Am Mon, Apr 04, 2011 at 10:05:25PM +0200 schrieb Carsten Bormann: > > Therefore, a more generic specification for IPv6 over low-power wireless > > foo would be really interesting for us - and probably a lot of other > > people as CC1020 and CC110x are very popular transceivers for WSN. > > I think that is an interesting idea. How much of such a specification could > be generic and how much would need to be specific to each of the radios? > Can you describe the decisions you had to take in applying 6LoWPAN to these > radios? for our current implementation we tried to change as little as possible in comparison to RFC 4944. Therefore, we also adapted the 802.15.4 frame format, though this was not the optimum choice as we had to deal with a much smaller packet size. (cc1100 supports natively only 64 byte packets.) Besides, we have a different addressing scheme at the link layer and have no PAN ids or anything comparable. In addition, we could not use 802.15.4 at the physical layer due to hardware limitations (neither DSSS nor PSSS are supported by the transceiver) and use a different media access. However, this obviously does not affect 6LoWPAN itself. > And, even better, can you write a draft? Okay, I'll try to do this and then we can see how generic such a specification could be. Regards Oleg From c.chauvenet@watteco.com Wed Apr 6 08:33:35 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BEE928C10A for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 08:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.215 X-Spam-Level: X-Spam-Status: No, score=-4.215 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fph2xLVY1UpP for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 08:33:34 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.182]) by core3.amsl.com (Postfix) with ESMTP id 8F9C43A67E7 for <6lowpan@ietf.org>; Wed, 6 Apr 2011 08:33:34 -0700 (PDT) Received: from mail211-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.8; Wed, 6 Apr 2011 15:35:17 +0000 Received: from mail211-ch1 (localhost.localdomain [127.0.0.1]) by mail211-ch1-R.bigfish.com (Postfix) with ESMTP id E4D5540848F; Wed, 6 Apr 2011 15:35:17 +0000 (UTC) X-SpamScore: -80 X-BigFish: VPS-80(zzbb2cK15caKJ98dK1fa4Lzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB007.red002.local; RD:none; EFVD:NLI Received: from mail211-ch1 (localhost.localdomain [127.0.0.1]) by mail211-ch1 (MessageSwitch) id 1302104117317289_30852; Wed, 6 Apr 2011 15:35:17 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail211-ch1.bigfish.com (Postfix) with ESMTP id 4255D1004E; Wed, 6 Apr 2011 15:35:17 +0000 (UTC) Received: from IE2RD2HUB007.red002.local (213.199.187.153) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 6 Apr 2011 15:35:12 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB007.red002.local ([10.33.16.155]) with mapi; Wed, 6 Apr 2011 08:35:00 -0700 From: C Chauvenet To: Carsten Bormann Date: Wed, 6 Apr 2011 08:34:57 -0700 Thread-Topic: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Thread-Index: Acv0QhdxdzUQwTKgRKumEdxnk7DkhAALF+MA Message-ID: References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com> <1301679639.6495.12.camel@Nokia-N900> <13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> <1922183C-DB17-4782-A7BB-F811D5C102F1@tzi.org> In-Reply-To: <1922183C-DB17-4782-A7BB-F811D5C102F1@tzi.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:33:35 -0000 Hi Carsten,=20 Working on Low Power, low data rate PLC, we find that the IEEE 802.15.4 spe= cification targeted the same application and gather the same requirements (= Small computation capabilities, Low Power, low data rate etc..). So we adapted the IEEE 802.15.4 frame format over PLC. (This is also because a low power and low data rate standard for narrow ban= d PLC such as ongoing specification in P1901.2 don't exist yet at this time= ) As a result, It does not hurt the 6loWPAN spec at all, and can be used as i= s. Our PHY layer is proprietary (until the standard comes out) but use the 802= .15.4 standard frame format. All layers above are compliant with the classical 802.15.4/6LoWPAN/IPv6 sta= ck. I would enjoy to hear what other people use, and evaluate the diversity aro= und IPv6 adaptation layers. Best, C=E9dric. -----Message d'origine----- De=A0: Carsten Bormann [mailto:cabo@tzi.org]=20 Envoy=E9=A0: mercredi 6 avril 2011 12:05 =C0=A0: C Chauvenet Cc=A0: Oliver Hahm; 6lowpan@ietf.org Objet=A0: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.t= xt On Apr 6, 2011, at 10:45, C Chauvenet wrote: > I definitely push the idea of a "generic IPv6 over low power foo" specifi= cation (if achievable). That is my point -- if there is a way to do this in a reusable, mostly gene= ric fashion, this would be great. I'm assuming there generally always will need to be some shim -- e.g., if t= he PHY/MAC spec already has a multiplexing point, how to hook into that, an= d possibly some other radio parameters that need to be set the same on both= sides for interoperability. That's why I was looking for some input from people who have done work on t= he constrained networks we are talking about. Please write a (short) draft, or (alternatively) give me a few paragraphs t= hat could for example go into the 6LoWPAN roadmap document until there is c= ritical mass for a separate spec. Gruesse, Carsten From lcma@kth.se Wed Apr 6 13:53:27 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD7628C0CF for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 13:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-him+QHuuto for <6lowpan@core3.amsl.com>; Wed, 6 Apr 2011 13:53:26 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 8347D3A68E8 for <6lowpan@ietf.org>; Wed, 6 Apr 2011 13:53:26 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 44E7A155AEA; Wed, 6 Apr 2011 22:54:39 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id LmNkzVwL3n18; Wed, 6 Apr 2011 22:54:35 +0200 (CEST) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 29F5E154136; Wed, 6 Apr 2011 22:54:34 +0200 (CEST) Received: from EXDB3.ug.kth.se ([169.254.3.112]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.01.0255.000; Wed, 6 Apr 2011 22:54:33 +0200 From: Luis Carlos Maqueda Ara To: Zach Shelby Thread-Topic: [6lowpan] WG adoption of 6lowpan Implementers guide Thread-Index: AQHL7tcwWy25kg2RkU6b1AibVGihO5ROwcgAgAJ4qgA= Date: Wed, 6 Apr 2011 20:54:32 +0000 Message-ID: References: <1301488616.3846.752.camel@d430> <7F574EFD-A7B3-485A-BAAB-9571C85FC00D@sensinode.com> In-Reply-To: <7F574EFD-A7B3-485A-BAAB-9571C85FC00D@sensinode.com> Accept-Language: en-GB, es-ES, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.101.215.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of 6lowpan Implementers guide X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:53:27 -0000 +1 On Apr 5, 2011, at 9:10 AM, Zach Shelby wrote: > I support accepting the roadmap as our WG implementer's guide document. >=20 > Zach >=20 > On Mar 30, 2011, at 3:36 PM, Geoff Mulligan wrote: >=20 >> As we discussed during yesterday's meeting, 6LoWPAN WG has a >> non-milestone charter item for an "implementers guide" as a running >> document that captures clarifications and small fixes to our >> specifications.=20 >>=20 >> Carsten has submitted an initial proposal for such a document, >> draft-bormann-6lowpan-roadmap-00.txt. This document provides a skeleton >> and does not have many clarifications yet, it could serve as a basis for >> future work on that implementers guide. >>=20 >> This is a call for working group adoption of >> draft-bormann-6lowpan-roadmap-00.txt. >>=20 >> Working group adoption does not mean we agree with every detail of the >> draft, but that we want to use it as the basis of further working group >> work. >>=20 >> Please reply to the list until >>=20 >> Friday, April 8, 23:59 UTC >>=20 >> with your position whether this document should be adopted or not. >>=20 >>=20 >> geoff >>=20 >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From canfeng-david.chen@nokia.com Fri Apr 8 03:17:34 2011 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02A13A69EE for <6lowpan@core3.amsl.com>; Fri, 8 Apr 2011 03:17: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQ8D-sgquUBK for <6lowpan@core3.amsl.com>; Fri, 8 Apr 2011 03:17:33 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id BB9B73A69B8 for <6lowpan@ietf.org>; Fri, 8 Apr 2011 03:17:33 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p38AIhBe001842 for <6lowpan@ietf.org>; Fri, 8 Apr 2011 13:19:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 13:19:10 +0300 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 8 Apr 2011 12:19:09 +0200 Received: from 008-AM1MPN1-002.mgdnok.nokia.com ([169.254.2.164]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0270.002; Fri, 8 Apr 2011 12:19:09 +0200 From: To: <6lowpan@ietf.org> Thread-Topic: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy Thread-Index: AQHL8Qrgt1F453lBGkavkEEAEs60A5RTyXPA Date: Fri, 8 Apr 2011 10:19:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.28.205.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Apr 2011 10:19:10.0330 (UTC) FILETIME=[6698FDA0:01CBF5D6] X-Nokia-AV: Clean Subject: Re: [6lowpan] WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 10:17:34 -0000 +1 Bluetooth Low Energy will be one of the core enabling technologies for mobi= le users to connect smart objects/Internet of Things. BR, Canfeng-David Chen -- That's what you get when you edit one message out of another. It's been a long week... Of course, this is about the BT-LE draft, not about the implementers guide. Please make sure you reply with the subject of this message, in particular = if it is just a "+1"... Sorry for the confusion, Carsten On Mar 31, 2011, at 19:47, Carsten Bormann wrote: >It appears I was a bit quick dismissing BT-LE as a working group item duri= ng Tuesday's 6LoWPAN meeting. The WG is alive and >well, so we can very we= ll request the addition of milestones. As the support in the room for work= ing on the adaptation of 6LoWPAN >for BT-LE was quite good, I'm now issuing= a call for WG adoption. >This is a call for working group adoption of >draft-patil-6lowpan-v6over-btle-01.txt >Working group adoption does not mean we agree with every detail of the >draft, but that we want to use it as the basis of further working group >work. >Please reply to the list until > Friday, April 8, 23:59 UTC > with your position whether this document should be adopted or not. > Gruesse, Carsten From cabo@tzi.org Mon Apr 11 15:16:09 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 913D2E066F for <6lowpan@ietfc.amsl.com>; Mon, 11 Apr 2011 15:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNPi1mUH234l for <6lowpan@ietfc.amsl.com>; Mon, 11 Apr 2011 15:16:08 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfc.amsl.com (Postfix) with ESMTP id A1F3DE067B for <6lowpan@ietf.org>; Mon, 11 Apr 2011 15:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p3BKuFoI016317; Mon, 11 Apr 2011 22:56:15 +0200 (CEST) Received: from [192.168.217.112] (p5B3E65EF.dip.t-dialin.net [91.62.101.239]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AF0F8B37; Mon, 11 Apr 2011 22:56:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> Date: Mon, 11 Apr 2011 22:56:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1301488616.3846.752.camel@d430> <13CD3D59-AFD8-41C5-B73B-8B97DEE322C6@tzi.org> To: 6lowpan WG <6lowpan@ietf.org> X-Mailer: Apple Mail (2.1084) Subject: [6lowpan] ADOPTED: Re: WG adoption of Transmission of IPv6 Packets over Bluetooth Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 22:16:09 -0000 Clearly, we have consensus to adopt this document as a working group = document. Authors: please resubmit the draft, with no change other than names, titles and = dates, as: draft-ietf-6lowpan-btle-00.txt =46rom there, this will be developed as a working group document, i.e., = we will have some discussion of each (substantive) change we want to = make on the mailing list and apply them as we reach (rough) consensus. = (This is best done through tickets, as we have been doing for ND for a = while now.) We also seem to have a lot of interest in creating other "6LoWPAN on X" = type documents. The idea to do much of this in a generic way is interesting, and it = wouldn't hurt to have some input on how to do this in the form of = individual Internet-Draft submissions. This doesn't mean there should not be such submissions for specific = technologies: If you know what needs to be done for a specific MAC/PHY = where 6LoWPAN provides significant added value, please do submit an = Internet-Draft. Gruesse, Carsten > On Mar 31, 2011, at 19:47, Carsten Bormann wrote: >=20 >> It appears I was a bit quick dismissing BT-LE as a working group item = during Tuesday's 6LoWPAN meeting. The WG is alive and well, so we can = very well request the addition of milestones. As the support in the = room for working on the adaptation of 6LoWPAN for BT-LE was quite good, = I'm now issuing a call for WG adoption. >>=20 >> This is a call for working group adoption of >> draft-patil-6lowpan-v6over-btle-01.txt >>=20 >> Working group adoption does not mean we agree with every detail of = the >> draft, but that we want to use it as the basis of further working = group >> work. >>=20 >> Please reply to the list until >>=20 >> Friday, April 8, 23:59 UTC >>=20 >> with your position whether this document should be adopted or not. >>=20 >> Gruesse, Carsten From nordmark@sonic.net Tue Apr 12 11:56:06 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 18EFAE0716 for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 11:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VP6LQoLKHF9A for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 11:56:05 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id CF2E3E08A3 for <6lowpan@ietf.org>; Tue, 12 Apr 2011 11:56:04 -0700 (PDT) Received: from [128.107.115.157] ([128.107.115.157]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3CIu37X023236 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 11:56:03 -0700 Message-ID: <4DA4A05C.2090405@sonic.net> Date: Tue, 12 Apr 2011 11:56:28 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Mukul Goyal References: <755301727.1444348.1301445124257.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <755301727.1444348.1301445124257.JavaMail.root@mail02.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Apr 2011 12:14:58 -0700 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:56:06 -0000 On 3/29/11 5:32 PM, Mukul Goyal wrote: > A router running RPL would not always know which of its registered > neighbors are themselves RPL routers. This is because an RPL node > must ignore any DIOs received from neighbors with higher (in > numerical value) "rank". Also, a DAG parent may not receive a DAO > from its child (In non-storing mode operation, it WON'T receive any > DAO at all unless it is the DAG root and in storing mode, the child > may decide not to send its DAO to this parent). > > Now, we have 2 options: > > 1) Define an "Advertize on Behalf" flag in ARO as Anders proposed and > have hosts set this flag when they send ARO inside a unicast NS to a > 6LR. If the host later decides to become a 6LR, it can resend the ARO > with this flag not set. > > 2) Lets write a "how to run RPL on a 6lowpan" document (as Pascal has > suggested) that will specify how a received DIO/DAO from a neighbor > can be used to mark that neighbor as a router in the registered > neighbor cache. Later you wrote: > I agree. That's why I think 6lowpan ND should provide a mechanism to > clearly identify a registered neighbor as a 6lowpan host or a 6lowpan > router. Sorry for the delay. I think #1 is both open-ended and undefined. In this case RPL doesn't care whether the node is a router or a host; it only care whether or not the node is an RPL speaker. Thus potentially we'd need a different flag with slightly different semantics for different routing protocols. And perhaps even need to add multiple flags for different versions or options in routing protocols (e.g., some future RPLv2, or non-storing, or something else). My take is that with 6lowpan-nd we are following the split between routing protocol and host-router interaction which has served the internet well for a long time. If one or more routing protocols need more information about its neighboring routers, then let's put the onus on providing that in the routing protocol; there we have the expertize and also we'd avoid having to revise ND to add more flags just to support a new version or new routing protocol. Thus let's do #2 and get this written down, including the assumptions that RPL makes about hosts, and then see how RPL can be extended to work correctly in the presence of hosts. My 2 cents, Erik From nordmark@sonic.net Tue Apr 12 11:59:10 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7BC16E0835 for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 11:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK0sUJpS5pD0 for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 11:59:10 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id CA432E0716 for <6lowpan@ietf.org>; Tue, 12 Apr 2011 11:59:09 -0700 (PDT) Received: from [128.107.115.157] ([128.107.115.157]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3CIx6Sk006385 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 11:59:06 -0700 Message-ID: <4DA4A114.1090203@sonic.net> Date: Tue, 12 Apr 2011 11:59:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <22230823.477101.1299157661084.JavaMail.root@mail02.pantherlink.uwm.edu> <4D91BEDA.7080907@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0439536D@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D04395561@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D04395561@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 12 Apr 2011 12:14:58 -0700 Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:59:10 -0000 On 3/30/11 1:30 AM, Pascal Thubert (pthubert) wrote: > Hi Carsten: > > RPL recognizes a movement when a DAO information has a stale > DAOSequence. The DAOSequence is an information that the owner of the > advertised target increments. > If we define an interaction whereby we redistribute ND-15 into RPL, then > (probably) the RPL router will inject a host route on behalf of the > host. > When the RPL router injects such a route and then maintains that route, > it still has has to provide an idea of the freshness of the information > that it is injecting in a DAOSequence. > When the host moves to an alternate router, it would have to provide > something so that the new router sets an updated DAOSequence that the > routing update percolates up the DODAG. > IOW, without a TID, a host cannot efficiently move from a router to the > next. Why couldn't the RPL router take a timestamp when it hears an ARO from a host, and convey that in RPL? Then that timestamp can be used to determine the most recent registration i.e., determine the most likely topological location of the host. The beauty of such an approach is that it avoids requiring having the hosts know about routing protocol-specific information like a TID. Erik From nordmark@acm.org Tue Apr 12 13:49:51 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8BD63E08AA for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrU9Bx0Xe4uf for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:49:50 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id AD4CCE06BC for <6lowpan@ietf.org>; Tue, 12 Apr 2011 13:49:50 -0700 (PDT) Received: from [128.107.115.157] ([128.107.115.157]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3CKnlL7001611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 13:49:48 -0700 Message-ID: <4DA4BB05.2060502@acm.org> Date: Tue, 12 Apr 2011 13:50:13 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "'6lowpan'" <6lowpan@ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:49:51 -0000 On 3/29/11 5:32 PM, Mukul Goyal wrote: > A router running RPL would not always know which of its registered > neighbors are themselves RPL routers. This is because an RPL node > must ignore any DIOs received from neighbors with higher (in > numerical value) "rank". Also, a DAG parent may not receive a DAO > from its child (In non-storing mode operation, it WON'T receive any > DAO at all unless it is the DAG root and in storing mode, the child > may decide not to send its DAO to this parent). > > Now, we have 2 options: > > 1) Define an "Advertize on Behalf" flag in ARO as Anders proposed and > have hosts set this flag when they send ARO inside a unicast NS to a > 6LR. If the host later decides to become a 6LR, it can resend the ARO > with this flag not set. > > 2) Lets write a "how to run RPL on a 6lowpan" document (as Pascal has > suggested) that will specify how a received DIO/DAO from a neighbor > can be used to mark that neighbor as a router in the registered > neighbor cache. Later you wrote: > I agree. That's why I think 6lowpan ND should provide a mechanism to > clearly identify a registered neighbor as a 6lowpan host or a 6lowpan > router. Sorry for the delay. I think #1 is both open-ended and undefined. In this case RPL doesn't care whether the node is a router or a host; it only care whether or not the node is an RPL speaker. Thus potentially we'd need a different flag with slightly different semantics for different routing protocols. And perhaps even need to add multiple flags for different versions or options in routing protocols (e.g., some future RPLv2, or non-storing, or something else). My take is that with 6lowpan-nd we are following the split between routing protocol and host-router interaction which has served the internet well for a long time. If one or more routing protocols need more information about its neighboring routers, then let's put the onus on providing that in the routing protocol; there we have the expertize and also we'd avoid having to revise ND to add more flags just to support a new version or new routing protocol. Thus let's do #2 and get this written down, including the assumptions that RPL makes about hosts, and then see how RPL can be extended to work correctly in the presence of hosts. My 2 cents, Erik From nordmark@acm.org Tue Apr 12 13:50:15 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8F5CE0903 for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xJUazawhlyb for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:50:15 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id 1F53CE0858 for <6lowpan@ietf.org>; Tue, 12 Apr 2011 13:50:15 -0700 (PDT) Received: from [128.107.115.157] ([128.107.115.157]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3CKoC4L001920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 13:50:13 -0700 Message-ID: <4DA4BB1E.2050002@acm.org> Date: Tue, 12 Apr 2011 13:50:38 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "'6lowpan'" <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 20:50:16 -0000 On 3/30/11 1:30 AM, Pascal Thubert (pthubert) wrote: > Hi Carsten: > > RPL recognizes a movement when a DAO information has a stale > DAOSequence. The DAOSequence is an information that the owner of the > advertised target increments. > If we define an interaction whereby we redistribute ND-15 into RPL, then > (probably) the RPL router will inject a host route on behalf of the > host. > When the RPL router injects such a route and then maintains that route, > it still has has to provide an idea of the freshness of the information > that it is injecting in a DAOSequence. > When the host moves to an alternate router, it would have to provide > something so that the new router sets an updated DAOSequence that the > routing update percolates up the DODAG. > IOW, without a TID, a host cannot efficiently move from a router to the > next. Why couldn't the RPL router take a timestamp when it hears an ARO from a host, and convey that in RPL? Then that timestamp can be used to determine the most recent registration i.e., determine the most likely topological location of the host. The beauty of such an approach is that it avoids requiring having the hosts know about routing protocol-specific information like a TID. Erik From pthubert@cisco.com Wed Apr 13 00:53:37 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A5A5E0694 for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 00:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.982 X-Spam-Level: X-Spam-Status: No, score=-9.982 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLx5u6loEgO1 for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 00:53:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 7AD80E067E for <6lowpan@ietf.org>; Wed, 13 Apr 2011 00:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4723; q=dns/txt; s=iport; t=1302681215; x=1303890815; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=kXfDVqfS/mkIb1nLO4A+qOMcf/9qzyjjAX4F2e2m/EQ=; b=Xc5M/q53ysW+RF5m3glHX8JAHSFIZIYfpNlKUAeauSkIlaH3/xn5NI0j U5LiHeLdKAq/Srtc/uUwwdsVLgMD6UN8pHf+YhRpgXB54IftLHAGvASlJ /cWLnSyyf1ogp4nUvjDuZQlJGrQJ+MMqpiaEjvHJfGjldui1z2OFlE9Bv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAEdVpU2Q/khNgWdsb2JhbACYHo1pFAEBFiYlpwScf4VuBJFi X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25506891" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 07:53:34 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3D7rYn0001044; Wed, 13 Apr 2011 07:53:34 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 09:53:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 09:53:31 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com> In-Reply-To: <4DA4BB1E.2050002@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO Thread-Index: Acv5U0swedas0Ob2TvKeyw12siUHkgAVmIDA References: <4DA4BB1E.2050002@acm.org> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 13 Apr 2011 07:53:34.0627 (UTC) FILETIME=[E3C73F30:01CBF9AF] Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 07:53:37 -0000 Hi Erik: The RPL (DAO) sequence number allows the node to increment rapidly in case of rapid changes and then lazily when the situation is stable and DAO are scarce. The increase is strictly monotonous which is critical to us. A time stamp imposes a synchronization between the routers. We do not have such mechanism in RPL. A time unit (a granularity) must be agreed upon. Within that unit, movements go undetected so the time unit must be thin grained to cover rapid changes. Yet, depending on the medium, the time unit, and the size of the network, it is not necessarily easy/possible to guarantee a strictly monotonous value with a thin grained time unit. And we have limited space (2 octets) and have to deal with wrap around, which divides the space by at least 3. So RPL went for a sequence number.=20 And we need that ND TID to redistribute 6LoWPAN ND registration as host routes into RPL if we want to allow a host to switch router over time. Note that a TID also enables to correlate an ARO in NA with the corresponding NS, thus infer loss, latency, out-of-order, etc... MIP has it for the same purpose, HA actually ignore outdated registrations, and nodes expect an ack that matches the latest registration; for ND, it is a lot easier to verify that the ack / status has the latest sequence than to go and check in the ARO that all ack'ed values are the latest ones. (RFC 3775) Sequence # A 16-bit unsigned integer used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. ... Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses. ... I think ND has the same need as MIP for a TID =3D=3D Sequence # . We = know of MIP; We know of RPL. We know of the backbone router operation. We know we'll need the TID and we know exactly why. I think we should have it in the 6LowPAN ND spec right away to avoid interop issues when we add RPL and BR operations.=20 Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark > Sent: Tuesday, April 12, 2011 10:51 PM > To: '6lowpan' > Subject: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO >=20 >=20 > On 3/30/11 1:30 AM, Pascal Thubert (pthubert) wrote: > > Hi Carsten: > > > > RPL recognizes a movement when a DAO information has a stale > > DAOSequence. The DAOSequence is an information that the owner of the > > advertised target increments. > > If we define an interaction whereby we redistribute ND-15 into RPL, > > then > > (probably) the RPL router will inject a host route on behalf of the > > host. > > When the RPL router injects such a route and then maintains that > > route, it still has has to provide an idea of the freshness of the > > information that it is injecting in a DAOSequence. > > When the host moves to an alternate router, it would have to provide > > something so that the new router sets an updated DAOSequence that the > > routing update percolates up the DODAG. > > IOW, without a TID, a host cannot efficiently move from a router to > > the next. >=20 > Why couldn't the RPL router take a timestamp when it hears an ARO from a > host, and convey that in RPL? Then that timestamp can be used to determine > the most recent registration i.e., determine the most likely topological > location of the host. >=20 > The beauty of such an approach is that it avoids requiring having the hosts > know about routing protocol-specific information like a TID. >=20 > Erik >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From abr@sdesigns.dk Wed Apr 13 04:36:02 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63133E06FA for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 04:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKhEroUB09FX for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 04:36:00 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by ietfc.amsl.com (Postfix) with ESMTP id 5D3D8E068E for <6lowpan@ietf.org>; Wed, 13 Apr 2011 04:36:00 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 13:35:58 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD8A9@zensys17.zensys.local> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO Thread-Index: Acv5U0swedas0Ob2TvKeyw12siUHkgAVmIDAAAjvHkA= References: <4DA4BB1E.2050002@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Pascal Thubert (pthubert)" , "Erik Nordmark" , "6lowpan" <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:36:02 -0000 Erik, Pascal Sometimes I cannot recognize topics that I myself initiated! If a sleeping node needs to ask a neighbor for a favour, it has nothing to do with the routing protocol. The routing protocol may be mesh-under or route-over - or none at all. The only important issue is that since the sleeping node is (well, sleeping), it cannot participate in the routing protocol communication. And that also applies to the reactive route discovery introduced with RPL P2P. Thus, I do not agree that this should be a feature of RPL. In that case it should be replicated in RPL, RPL P2P and any future routing protocol - as well as any mesh-under solution in use out there. 6LoWPAN ND is the right place for this feature. For the above reason AND because the message flow is identical to the address registration already taking place in 6LoWPAN ND. I see no need for any new fancy time stamp mechanism if this is just another information conveyed along with the ARO. (Did I miss something here?) Just my $0.05 - Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: 13. april 2011 09:54 To: Erik Nordmark; 6lowpan Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO Hi Erik: The RPL (DAO) sequence number allows the node to increment rapidly in case of rapid changes and then lazily when the situation is stable and DAO are scarce. The increase is strictly monotonous which is critical to us. A time stamp imposes a synchronization between the routers. We do not have such mechanism in RPL. A time unit (a granularity) must be agreed upon. Within that unit, movements go undetected so the time unit must be thin grained to cover rapid changes. Yet, depending on the medium, the time unit, and the size of the network, it is not necessarily easy/possible to guarantee a strictly monotonous value with a thin grained time unit. And we have limited space (2 octets) and have to deal with wrap around, which divides the space by at least 3. So RPL went for a sequence number.=20 And we need that ND TID to redistribute 6LoWPAN ND registration as host routes into RPL if we want to allow a host to switch router over time. Note that a TID also enables to correlate an ARO in NA with the corresponding NS, thus infer loss, latency, out-of-order, etc... MIP has it for the same purpose, HA actually ignore outdated registrations, and nodes expect an ack that matches the latest registration; for ND, it is a lot easier to verify that the ack / status has the latest sequence than to go and check in the ARO that all ack'ed values are the latest ones. (RFC 3775) Sequence # A 16-bit unsigned integer used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. ... Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses. ... I think ND has the same need as MIP for a TID =3D=3D Sequence # . We = know of MIP; We know of RPL. We know of the backbone router operation. We know we'll need the TID and we know exactly why. I think we should have it in the 6LowPAN ND spec right away to avoid interop issues when we add RPL and BR operations.=20 Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On=20 > Behalf Of Erik Nordmark > Sent: Tuesday, April 12, 2011 10:51 PM > To: '6lowpan' > Subject: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO >=20 >=20 > On 3/30/11 1:30 AM, Pascal Thubert (pthubert) wrote: > > Hi Carsten: > > > > RPL recognizes a movement when a DAO information has a stale=20 > > DAOSequence. The DAOSequence is an information that the owner of the > > advertised target increments. > > If we define an interaction whereby we redistribute ND-15 into RPL,=20 > > then > > (probably) the RPL router will inject a host route on behalf of the=20 > > host. > > When the RPL router injects such a route and then maintains that=20 > > route, it still has has to provide an idea of the freshness of the=20 > > information that it is injecting in a DAOSequence. > > When the host moves to an alternate router, it would have to provide > > something so that the new router sets an updated DAOSequence that the > > routing update percolates up the DODAG. > > IOW, without a TID, a host cannot efficiently move from a router to=20 > > the next. >=20 > Why couldn't the RPL router take a timestamp when it hears an ARO from a > host, and convey that in RPL? Then that timestamp can be used to determine > the most recent registration i.e., determine the most likely topological > location of the host. >=20 > The beauty of such an approach is that it avoids requiring having the hosts > know about routing protocol-specific information like a TID. >=20 > Erik >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Wed Apr 13 07:01:27 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89A6EE0756 for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 07:01:27 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Az-HhvM+5z for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 07:01:26 -0700 (PDT) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by ietfc.amsl.com (Postfix) with ESMTP id 80271E070B for <6lowpan@ietf.org>; Wed, 13 Apr 2011 07:01:26 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o143.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 5bca5ad4.0.42355.00-357.92096.p01c11o143.mxlogic.net (envelope-from ); Wed, 13 Apr 2011 08:01:26 -0600 (MDT) X-MXL-Hash: 4da5acb61dcb7e41-5616a159b5c8166c32bb264afdd391e5e5ad9d0a Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 10:01:22 -0400 Date: Wed, 13 Apr 2011 10:01:42 -0400 Message-Id: <87y63e5jy1.fsf@kelsey-ws.hq.ember.com> To: Erik Nordmark In-reply-to: <4DA4BB05.2060502@acm.org> (message from Erik Nordmark on Tue, 12 Apr 2011 13:50:13 -0700) From: Richard Kelsey References: <4DA4BB05.2060502@acm.org> X-OriginalArrivalTime: 13 Apr 2011 14:01:22.0082 (UTC) FILETIME=[4501A820:01CBF9E3] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=KVkKRpFW1FcA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=N54-gffFAAAA:8 a=04v] X-AnalysisOut: [VrEUpRax_emHffD4A:9 a=pkOZ4nQjrgbM82pxRl4A:7 a=nAPXUAfsBmE] X-AnalysisOut: [A:10 a=6S0-Uj1EKwx8YXQy:21 a=XrIsCJ-lWHHn7qQw:21] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:01:27 -0000 > Date: Tue, 12 Apr 2011 13:50:13 -0700 > From: Erik Nordmark > > On 3/29/11 5:32 PM, Mukul Goyal wrote: > > > A router running RPL would not always know which of its registered > > neighbors are themselves RPL routers. This is because an RPL node > > must ignore any DIOs received from neighbors with higher (in > > numerical value) "rank". Also, a DAG parent may not receive a DAO > > from its child (In non-storing mode operation, it WON'T receive any > > DAO at all unless it is the DAG root and in storing mode, the child > > may decide not to send its DAO to this parent). > > > > Now, we have 2 options: > > > > 1) Define an "Advertize on Behalf" flag in ARO as Anders proposed and > > have hosts set this flag when they send ARO inside a unicast NS to a > > 6LR. If the host later decides to become a 6LR, it can resend the ARO > > with this flag not set. Why is this needed? The 6LoWPAN ND draft seems clear AROs are sent by hosts. Are they also sent by routers? (I find it very confusing that "host" sometimes is used to mean hosts and routers and other times to mean hosts that do not route.) How is the router/host distinction determined when using normal, non-6LoWPAN ND? > > 2) Lets write a "how to run RPL on a 6lowpan" document (as Pascal has > > suggested) that will specify how a received DIO/DAO from a neighbor > > can be used to mark that neighbor as a router in the registered > > neighbor cache. > > Thus let's do #2 and get this written down, including the assumptions > that RPL makes about hosts, and then see how RPL can be extended to work > correctly in the presence of hosts. +1. This would be really helpful. -Richard Kelsey From richard.kelsey@ember.com Wed Apr 13 07:38:20 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03F09E073E for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLi53G78vx5c for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 07:38:19 -0700 (PDT) Received: from p01c11o142.mxlogic.net (p01c11o142.mxlogic.net [208.65.144.65]) by ietfc.amsl.com (Postfix) with ESMTP id EF6D3E0736 for <6lowpan@ietf.org>; Wed, 13 Apr 2011 07:38:18 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o142.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id a55b5ad4.0.5581.00-352.13344.p01c11o142.mxlogic.net (envelope-from ); Wed, 13 Apr 2011 08:38:19 -0600 (MDT) X-MXL-Hash: 4da5b55b17a68dbe-ff154ea57ab167132d33c4c9e0f16b16715d0b80 Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 10:38:14 -0400 Date: Wed, 13 Apr 2011 10:38:34 -0400 Message-Id: <87vcyi5i8l.fsf@kelsey-ws.hq.ember.com> To: "Anders Brandt" In-reply-to: <6D9687E95918C04A8B30A7D6DA805A3E01CCD8A9@zensys17.zensys.local> (abr@sdesigns.dk) From: Richard Kelsey References: <4DA4BB1E.2050002@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD8A9@zensys17.zensys.local> X-OriginalArrivalTime: 13 Apr 2011 14:38:14.0442 (UTC) FILETIME=[6BAD00A0:01CBF9E8] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=KVkKRpFW1FcA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=gO3uh9h2KWvP1CQcc7YA] X-AnalysisOut: [:9 a=4AYOmu6y-pnZTv2XIccA:7] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:38:20 -0000 > Date: Wed, 13 Apr 2011 13:35:58 +0200 > From: "Anders Brandt" > > Sometimes I cannot recognize topics that I myself initiated! > > If a sleeping node needs to ask a neighbor for a favour, > it has nothing to do with the routing protocol. What sort of favour did you have in mind? I thought that what the sleeping node wanted was to have messages routed to it, which could be be imagined to have something to do with the routing protocol :-). > The only important issue is that since the sleeping node is (well, > sleeping), it cannot participate in the routing protocol communication. > And that also applies to the reactive route discovery introduced with > RPL P2P. > Thus, I do not agree that this should be a feature of RPL. In that case > it should be replicated in RPL, RPL P2P and any future routing protocol > - as well as any mesh-under solution in use out there. > > 6LoWPAN ND is the right place for this feature. For the above reason AND > because the message flow is identical to the address registration > already taking place in 6LoWPAN ND. > > I see no need for any new fancy time stamp mechanism if this is just > another information conveyed along with the ARO. (Did I miss something > here?) As I understand it, the issue has to do with a sleepy node moving its network connection from one router to another. One part of this is informing the new router that the sleepy node is now a neighboring host. That is clearly a job for ND. Assuming that is solved, the new router will send a RPL DAO which will create a downward route to the sleepy node. The problem is that the old downward route via the original neighboring router is still in place. Creating the new route cannot remove the old one, because the sleepy device must be allowed to maintain links to multiple routers. What I think should happen is that NUD on the original neighboring router should detect that the sleepy host is no longer connected, at which point that router needs to send a DAO that does not include the sleepy host as a RPL target. I don't know if RPL describes removing a RPL target in this fashion. The only way to do NUD for a node that sleeps is to time it out if it is not heard from. It might be better to leave this to the link layer, because there are link layer issues involved (does the node wake on a schedule? does it send polling messages?) and because it needs to be done using a minimal amount of energy. -Richard Kelsey From richard.kelsey@ember.com Thu Apr 14 05:34:05 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8029EE087F for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 05:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIR5qqF9ARmI for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 05:34:04 -0700 (PDT) Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by ietfc.amsl.com (Postfix) with ESMTP id 45ECAE0875 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 05:34:04 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o143.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id bb9e6ad4.0.3221.00-378.7134.p01c11o143.mxlogic.net (envelope-from ); Thu, 14 Apr 2011 06:34:04 -0600 (MDT) X-MXL-Hash: 4da6e9bc2a9f8231-7246a5da26c15aeccc26a0dd57a6bb2c92ae701d Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 08:34:01 -0400 Date: Thu, 14 Apr 2011 08:34:21 -0400 Message-Id: <87bp09roz6.fsf@kelsey-ws.hq.ember.com> To: 6lowpan@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 14 Apr 2011 12:34:01.0895 (UTC) FILETIME=[3C065370:01CBFAA0] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=ATjQPXyKVZsA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=07j9UTG6Cc137h6VwI4A] X-AnalysisOut: [:9 a=Y4-8gLJmR-zOLtbucD4A:7] Subject: [6lowpan] which addresses can be registered? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:34:05 -0000 As far as I can tell from the 6LoWPAN ND draft, the only addresses that cannot be registered are multicast addresses. Is this correct? For example, can a link-local address be registered? Can any prefix be used when registering with any 6LBR? -Richard Kelsey From nordmark@acm.org Thu Apr 14 16:29:51 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 759A2E0794 for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXe4H8G4IAKu for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:29:50 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id 6686DE06C4 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 16:29:50 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3ENTlW2017373 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 16:29:47 -0700 Message-ID: <4DA78386.8050609@acm.org> Date: Thu, 14 Apr 2011 16:30:14 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "6lo >> '6lowpan'" <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:29:51 -0000 On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > Hi Erik: > > The RPL (DAO) sequence number allows the node to increment rapidly in > case of rapid changes and then lazily when the situation is stable and > DAO are scarce. The increase is strictly monotonous which is critical to > us. > > A time stamp imposes a synchronization between the routers. We do not > have such mechanism in RPL. A time unit (a granularity) must be agreed > upon. Within that unit, movements go undetected so the time unit must be > thin grained to cover rapid changes. Yet, depending on the medium, the > time unit, and the size of the network, it is not necessarily > easy/possible to guarantee a strictly monotonous value with a thin > grained time unit. And we have limited space (2 octets) and have to deal > with wrap around, which divides the space by at least 3. > > So RPL went for a sequence number. But the unstated assumption that RPL made is that all host-to-router protocols have to now be RPL aware. That doesn't sound like good design. A host isn't aware of whether the routers speak IS-IS or OSPF, so why do the hosts need to be aware of RPL by passing some TID around? > I think ND has the same need as MIP for a TID == Sequence # . We know of > MIP; We know of RPL. We know of the backbone router operation. We know > we'll need the TID and we know exactly why. I think we should have it in > the 6LowPAN ND spec right away to avoid interop issues when we add RPL > and BR operations. I don't see a need in 6lowpan-nd for a TID; the protocol works fine without it. I think RPL needs to be improved to deal with reality. Isn't there a desire for RPL to handle 4861 hosts? Those would never know about a TID. Erik From nordmark@acm.org Thu Apr 14 16:31:08 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EE9D7E0794 for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeOx9sxptHyX for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:31:08 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id 50056E0720 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 16:31:08 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3ENV4Ri022303 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 16:31:04 -0700 Message-ID: <4DA783D4.6000309@acm.org> Date: Thu, 14 Apr 2011 16:31:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "'6lowpan'" <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] Fwd: Re: which addresses can be registered? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:31:09 -0000 On 4/14/11 5:34 AM, Richard Kelsey wrote: > As far as I can tell from the 6LoWPAN ND draft, the only > addresses that cannot be registered are multicast addresses. > Is this correct? For example, can a link-local address be > registered? Can any prefix be used when registering with > any 6LBR? The draft doesn't forbid registering a link-local address, but it also doesn't require it. For multicast there is MLD, which is used to tell routers which multicast addresses the hosts want to receive. If there are applications which use multicast then it would make sense to use MLD. Erik From richard.kelsey@ember.com Thu Apr 14 16:56:05 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4981E06D0 for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwqRZac9nFNW for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:56:05 -0700 (PDT) Received: from p01c12o148.mxlogic.net (p01c12o148.mxlogic.net [208.65.145.71]) by ietfc.amsl.com (Postfix) with ESMTP id 21FDFE0677 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 16:56:05 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c12o148.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 49987ad4.0.9267.00-352.19097.p01c12o148.mxlogic.net (envelope-from ); Thu, 14 Apr 2011 17:56:05 -0600 (MDT) X-MXL-Hash: 4da789952d4bbe44-6d7673d7af0c7e500d0834eec22be43e9be81ff9 Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 19:56:04 -0400 Date: Thu, 14 Apr 2011 19:56:23 -0400 Message-Id: <87y63cqteg.fsf@kelsey-ws.hq.ember.com> To: Erik Nordmark In-reply-to: <4DA783D4.6000309@acm.org> (message from Erik Nordmark on Thu, 14 Apr 2011 16:31:32 -0700) From: Richard Kelsey References: <4DA783D4.6000309@acm.org> X-OriginalArrivalTime: 14 Apr 2011 23:56:04.0135 (UTC) FILETIME=[83949B70:01CBFAFF] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=B2qiK0X5LMMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=N54-gffFAAAA:8 a=9wl] X-AnalysisOut: [wK2QdeGf1MwhQd3YA:9 a=z8MPtEjXVtk54S7RRWEA:7 a=nAPXUAfsBmE] X-AnalysisOut: [A:10 a=XAjgxnuZKhIVLtlh:21 a=uRUCTRsWPv2TZE_X:21] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Fwd: Re: which addresses can be registered? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:56:06 -0000 > Date: Thu, 14 Apr 2011 16:31:32 -0700 > From: Erik Nordmark > > On 4/14/11 5:34 AM, Richard Kelsey wrote: > > As far as I can tell from the 6LoWPAN ND draft, the only > > addresses that cannot be registered are multicast addresses. > > Is this correct? For example, can a link-local address be > > registered? Can any prefix be used when registering with > > any 6LBR? > > The draft doesn't forbid registering a link-local address, but it also > doesn't require it. Thank you. The question arose with respect to link-local addresses derived from IEEE 802.15.4 16-bit short addresses, which require some form of DAD. Just to be clear, if there are two 6LBRs which advertise different prefixes and a host configures addresses for both prefixes, then both addresses need to be registered with both 6LBRs? -Richard Kelsey From nordmark@acm.org Thu Apr 14 17:05:37 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A7F2E061E for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 17:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZTAeZrPcdty for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 17:05:35 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id E3BF7E0680 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 17:05:34 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3F05UeW006010 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 17:05:30 -0700 Message-ID: <4DA78BE6.6@acm.org> Date: Thu, 14 Apr 2011 17:05:58 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Richard Kelsey References: <4DA783D4.6000309@acm.org> <87y63cqteg.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87y63cqteg.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Fwd: Re: which addresses can be registered? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:05:37 -0000 On 4/14/11 4:56 PM, Richard Kelsey wrote: > Thank you. The question arose with respect to link-local > addresses derived from IEEE 802.15.4 16-bit short addresses, > which require some form of DAD. To me it makes sense to register those. But one could also have link-locals based on EUI-64 and only have the globals use the short addresses. But as I said, the spec provides some flexibility here. > Just to be clear, if there are two 6LBRs which advertise > different prefixes and a host configures addresses for > both prefixes, then both addresses need to be registered > with both 6LBRs? Both addresses need to be registered for sure. IPv6 checks for duplicate addresses and not duplicate interface IDs (there was a debate and a change/clarification in this area in the early days of IPv6.) Ideally the 6LBRs are coordinated so that they both advertise both prefixes. That seems to be natural if we want one 6LBR to take over should the other one fail. But I assume that even if they don't advertise the same prefixes, it makes sense to register with both. Erik From pthubert@cisco.com Thu Apr 14 23:43:09 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6F7C8E072B for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 23:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+pv3-gHqjWC for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 23:43:08 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 08F57E073E for <6lowpan@ietf.org>; Thu, 14 Apr 2011 23:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4566; q=dns/txt; s=iport; t=1302849788; x=1304059388; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=UnUQUxkzgEKa9IPaWlPEycFpiwJw56iWj6Xqs9Qli0I=; b=BtpRS40abFxmj2jqUkZBy7aeH4+payMcEnTJJFhq/mWwldM2ry3ZwQ5c /Fip7FYxpCHRm8rHTzXx6Jl0+jqqgae4ioG+ICCzwArNutOSmY3zA0js8 nRhwcQeH4puV2iBKACs+ZtUfhPfAGztupqahv30dOUk5hkDhe0I67pIzD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgAAFfop02Q/khMgWdsb2JhbACYA41/FAEBFiYliG+fAp0BhW4EkXM X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="83684728" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 06:43:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F6h7Dh007832 for <6lowpan@ietf.org>; Fri, 15 Apr 2011 06:43:07 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 08:43:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 08:43:04 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0459F3AA@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: Acv7OA5nSPx9EwXZQPu57L7VsjplBQAAC+mg From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 15 Apr 2011 06:43:07.0044 (UTC) FILETIME=[60C4C640:01CBFB38] Subject: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:43:09 -0000 Forwarding without the mail attached (was bounced by the mailer) Pascal http://www.xtranormal.com/watch/7011357/ -----Original Message----- From: Pascal Thubert (pthubert)=20 Sent: Friday, April 15, 2011 8:41 AM To: 'Erik Nordmark' Cc: 6lowpan@ietf.org Subject: TID in ARO [was: "Advertize on Behalf" flag in ARO] Hi Erik: RPL can do what all classical IGPs can do WRT hosts. That is as long as the host address belongs to the router's prefix and stays attached to that router. When the topology becomes multilink subnet and mobility is required then it is a new problem entirely, and NO, 4861 is not a suitable interaction with the router to allow the router to redistribute a host route. Because the neighbor cache that 4861 builds is not a of the same nature as the binding table that 6LoWPAN ND builds. Another thing that 6LoWPAN ND fails to express correctly. I proposed text to explain that (attached) but it was not considered, contributing to the illusion that a cache is a table. The reality is also that those networks will need to scale to large subnets in plants, building, etc... (see the requirement drafts in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND requires a coordination between LBRs but does not say how it happens. This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and it requires a TID, for the same reason as RPL. Removing the backbone operation and the TID from the draft is ostrich policy. RPL already adapted to the new reality of large multilink subnet with inner mobility. Placing the blame on RPL is another illusionist trick. And this is not RPL last call. BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other registrations do when strict ordering is not guaranteed (MIP being an example). Say that due to some config, a node registers a lifetime of X, then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid sequence, but does not get an answer yet. Then it finally gets 2 AROs back, lifetime X and 0. What's the final state in the router? It seems we can never agree on any of this. I'd like to hear what others think.=20 Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On=20 > Behalf Of Erik Nordmark > Sent: Friday, April 15, 2011 1:30 AM > To: 6lo >> '6lowpan' > Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO >=20 >=20 > On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > > Hi Erik: > > > > The RPL (DAO) sequence number allows the node to increment rapidly=20 > > in case of rapid changes and then lazily when the situation is=20 > > stable and DAO are scarce. The increase is strictly monotonous which > > is critical to us. > > > > A time stamp imposes a synchronization between the routers. We do=20 > > not have such mechanism in RPL. A time unit (a granularity) must be=20 > > agreed upon. Within that unit, movements go undetected so the time=20 > > unit must be thin grained to cover rapid changes. Yet, depending on=20 > > the medium, the time unit, and the size of the network, it is not=20 > > necessarily easy/possible to guarantee a strictly monotonous value=20 > > with a thin grained time unit. And we have limited space (2 octets)=20 > > and have to deal with wrap around, which divides the space by at least 3. > > > > So RPL went for a sequence number. >=20 > But the unstated assumption that RPL made is that all host-to-router=20 > protocols have to now be RPL aware. That doesn't sound like good design. > A host isn't aware of whether the routers speak IS-IS or OSPF, so why=20 > do the hosts need to be aware of RPL by passing some TID around? >=20 > > I think ND has the same need as MIP for a TID =3D=3D Sequence # . We = > > know of MIP; We know of RPL. We know of the backbone router=20 > > operation. We know we'll need the TID and we know exactly why. I=20 > > think we should have it in the 6LowPAN ND spec right away to avoid=20 > > interop issues when we add RPL and BR operations. >=20 > I don't see a need in 6lowpan-nd for a TID; the protocol works fine without it. > I think RPL needs to be improved to deal with reality. Isn't there a=20 > desire for RPL to handle 4861 hosts? Those would never know about a TID. >=20 > Erik >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From nordmark@acm.org Fri Apr 15 09:38:13 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53D7FE06A9 for <6lowpan@ietfc.amsl.com>; Fri, 15 Apr 2011 09:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0akGj95p1dI for <6lowpan@ietfc.amsl.com>; Fri, 15 Apr 2011 09:38:08 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id B42B9E075C for <6lowpan@ietf.org>; Fri, 15 Apr 2011 09:38:08 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3FGc3WU022501 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2011 09:38:05 -0700 Message-ID: <4DA87488.6030606@acm.org> Date: Fri, 15 Apr 2011 09:38:32 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D0459F3AA@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0459F3AA@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:38:13 -0000 On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > RPL can do what all classical IGPs can do WRT hosts. That is as long as > the host address belongs to the router's prefix and stays attached to > that router. I just realized that we might be talking about a different definition of "host". What I mean by "host" is a node which does not participate in a routing protocol, and does not forward packets (except packets explicitly addressed to itself using e.g., a routing header). However, RPL has a different definition: 'host' refers to an LLN device that can generate but does not forward RPL traffic Basically per the RPL definition there is no such thing as a node which does not participate in the RPL protocol. IMHO what is in RPL should have been defined as a non-forwarding node, so that we can have a sane discussion without getting entangled in terminology issues. Which definition of "host" are you using above? Per the RPL definition there is no need for 6lowpan-nd, since all nodes will speak RPL. This is rather confusing, don't you think? Erik > When the topology becomes multilink subnet and mobility is required then > it is a new problem entirely, and NO, 4861 is not a suitable interaction > with the router to allow the router to redistribute a host route. > Because the neighbor cache that 4861 builds is not a of the same nature > as the binding table that 6LoWPAN ND builds. Another thing that 6LoWPAN > ND fails to express correctly. I proposed text to explain that > (attached) but it was not considered, contributing to the illusion that > a cache is a table. > > The reality is also that those networks will need to scale to large > subnets in plants, building, etc... (see the requirement drafts in > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > requires a coordination between LBRs but does not say how it happens. > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and > it requires a TID, for the same reason as RPL. Removing the backbone > operation and the TID from the draft is ostrich policy. > > RPL already adapted to the new reality of large multilink subnet with > inner mobility. Placing the blame on RPL is another illusionist trick. > And this is not RPL last call. > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > registrations do when strict ordering is not guaranteed (MIP being an > example). Say that due to some config, a node registers a lifetime of X, > then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid > sequence, but does not get an answer yet. Then it finally gets 2 AROs > back, lifetime X and 0. What's the final state in the router? > > It seems we can never agree on any of this. I'd like to hear what others > think. > > Pascal > http://www.xtranormal.com/watch/7011357/ > > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Erik Nordmark >> Sent: Friday, April 15, 2011 1:30 AM >> To: 6lo>> '6lowpan' >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO >> >> >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: >>> Hi Erik: >>> >>> The RPL (DAO) sequence number allows the node to increment rapidly >>> in case of rapid changes and then lazily when the situation is >>> stable and DAO are scarce. The increase is strictly monotonous which > >>> is critical to us. >>> >>> A time stamp imposes a synchronization between the routers. We do >>> not have such mechanism in RPL. A time unit (a granularity) must be >>> agreed upon. Within that unit, movements go undetected so the time >>> unit must be thin grained to cover rapid changes. Yet, depending on >>> the medium, the time unit, and the size of the network, it is not >>> necessarily easy/possible to guarantee a strictly monotonous value >>> with a thin grained time unit. And we have limited space (2 octets) >>> and have to deal with wrap around, which divides the space by at > least 3. >>> >>> So RPL went for a sequence number. >> >> But the unstated assumption that RPL made is that all host-to-router >> protocols have to now be RPL aware. That doesn't sound like good > design. >> A host isn't aware of whether the routers speak IS-IS or OSPF, so why >> do the hosts need to be aware of RPL by passing some TID around? >> >>> I think ND has the same need as MIP for a TID == Sequence # . We >>> know of MIP; We know of RPL. We know of the backbone router >>> operation. We know we'll need the TID and we know exactly why. I >>> think we should have it in the 6LowPAN ND spec right away to avoid >>> interop issues when we add RPL and BR operations. >> >> I don't see a need in 6lowpan-nd for a TID; the protocol works fine > without it. >> I think RPL needs to be improved to deal with reality. Isn't there a >> desire for RPL to handle 4861 hosts? Those would never know about a > TID. >> >> Erik >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From pthubert@cisco.com Mon Apr 18 01:37:54 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF55CE0737 for <6lowpan@ietfc.amsl.com>; Mon, 18 Apr 2011 01:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.444 X-Spam-Level: X-Spam-Status: No, score=0.444 tagged_above=-999 required=5 tests=[AWL=-8.957, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_BLACK=20] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np-tbkEdAjnx for <6lowpan@ietfc.amsl.com>; Mon, 18 Apr 2011 01:37:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 2AA88E06BB for <6lowpan@ietf.org>; Mon, 18 Apr 2011 01:37:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=9329; q=dns/txt; s=iport; t=1303115870; x=1304325470; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wQhJSIPOFeRBD6ednkI7Nw0iy2UtAQxokZMMI6D36ic=; b=O+lgSiZsNSxnBYMS8wTQnSPu/okFEMYutlM1nvPrcFzp3sfj8h3PNplZ l1z27ZhnXY/vs8o4MgjzgrtpCtoY0GvfSQO+w59TZLURhqvKJDvLzWfLV 1sGv7k3mReWJG9TjJyI8RV/a2yo7DSroMVEUPDQ4O5thH61+fEwsnVGQE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AAMj3q02Q/khMgWdsb2JhbACXWY4AFAEBFiYlpgGbVIVxBJF+ X-IronPort-AV: E=Sophos;i="4.64,231,1301875200"; d="scan'208";a="83975097" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2011 08:37:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3I8bmbw005210; Mon, 18 Apr 2011 08:37:48 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 10:37:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2011 10:37:45 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0464F7BB@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: Acv7i4bmipPO1g7FTC+9297u7/kRXgCEcviQAAGBHzA= References: <6A2A459175DABE4BB11DE2026AA50A5D0459F3AA@XMB-AMS-107.cisco.com> <4DA87488.6030606@acm.org> From: "Pascal Thubert (pthubert)" To: "Dijk, Esko" , "Erik Nordmark" X-OriginalArrivalTime: 18 Apr 2011 08:37:48.0593 (UTC) FILETIME=[E5BB1210:01CBFDA3] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 08:37:55 -0000 Hi Esko, Erik The discussion on RPL and hosts should happen on the RPL list under a different topic. The point being discussed here is this: The reality is also that those (LLN) networks will need to scale to large subnets in plants, building, etc... (see the requirement drafts in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND requires a coordination between LBRs but does not say how it happens. This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and it requires a TID, for the same reason as RPL. Removing the backbone operation and the TID from the draft is ostrich policy. BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other registrations do when strict ordering is not guaranteed (MIP being an example). Say that due to some config, a node registers a lifetime of X, then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid sequence, but does not get an answer yet. Then it finally gets 2 AROs back, lifetime X and 0. What's the final state in the router? I'd like to hear what others think. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO] >=20 > Hello Erik, >=20 > taking the definition you quoted: > 'host' refers to an LLN device that can generate but does not forward > RPL traffic >=20 > the question may arise what is "RPL traffic"? It is not defined in the RPL draft > it seems. Pascal clarified to me it is traffic associated to a RPL instance, not > necessarily RPL protocol messages. This means that a host could generate > RPL traffic without being aware of the existence of RPL at all. So, _not_ all > hosts have to speak RPL? > The RPL draft does not explicitly state if "hosts" in a RPL network always > speak RPL, never speak RPL, or can be mixed RPL/non-RPL speakers. >=20 > Taking the definition of 'node' in the RPL draft: > 'node' refers to any RPL device, either a host or a router >=20 > rules out (?) the option that all "hosts" are non-RPL speakers, since there > may be a "RPL device" (i.e. RPL-speaking device, I assume) that is also a host. >=20 > I communicated these perceived unclarities to Pascal and the RFC editor 2 > weeks ago. Once this is clear I think the present discussion can continue. > And then there is the related discussion of ND support for sleepy devices, > the original topic of Anders ;) >=20 > best regards, >=20 > Esko >=20 >=20 >=20 > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO] >=20 > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: >=20 > > RPL can do what all classical IGPs can do WRT hosts. That is as long > > as the host address belongs to the router's prefix and stays attached > > to that router. >=20 > I just realized that we might be talking about a different definition of "host". > What I mean by "host" is a node which does not participate in a routing > protocol, and does not forward packets (except packets explicitly addressed > to itself using e.g., a routing header). >=20 > However, RPL has a different definition: > 'host' refers to an LLN device that can generate but does not forward > RPL traffic >=20 > Basically per the RPL definition there is no such thing as a node which does > not participate in the RPL protocol. > IMHO what is in RPL should have been defined as a non-forwarding node, so > that we can have a sane discussion without getting entangled in terminology > issues. >=20 > Which definition of "host" are you using above? >=20 > Per the RPL definition there is no need for 6lowpan-nd, since all nodes will > speak RPL. This is rather confusing, don't you think? >=20 > Erik >=20 > > When the topology becomes multilink subnet and mobility is required > > then it is a new problem entirely, and NO, 4861 is not a suitable > > interaction with the router to allow the router to redistribute a host route. > > Because the neighbor cache that 4861 builds is not a of the same > > nature as the binding table that 6LoWPAN ND builds. Another thing that > > 6LoWPAN ND fails to express correctly. I proposed text to explain that > > (attached) but it was not considered, contributing to the illusion > > that a cache is a table. > > > > The reality is also that those networks will need to scale to large > > subnets in plants, building, etc... (see the requirement drafts in > > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > > requires a coordination between LBRs but does not say how it happens. > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > > and it requires a TID, for the same reason as RPL. Removing the > > backbone operation and the TID from the draft is ostrich policy. > > > > RPL already adapted to the new reality of large multilink subnet with > > inner mobility. Placing the blame on RPL is another illusionist trick. > > And this is not RPL last call. > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > > registrations do when strict ordering is not guaranteed (MIP being an > > example). Say that due to some config, a node registers a lifetime of > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > rapid sequence, but does not get an answer yet. Then it finally gets 2 > > AROs back, lifetime X and 0. What's the final state in the router? > > > > It seems we can never agree on any of this. I'd like to hear what > > others think. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > >> -----Original Message----- > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, 2011 1:30 AM > >> To: 6lo>> '6lowpan' > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > >>> Hi Erik: > >>> > >>> The RPL (DAO) sequence number allows the node to increment rapidly > >>> in case of rapid changes and then lazily when the situation is > >>> stable and DAO are scarce. The increase is strictly monotonous which > > > >>> is critical to us. > >>> > >>> A time stamp imposes a synchronization between the routers. We do > >>> not have such mechanism in RPL. A time unit (a granularity) must be > >>> agreed upon. Within that unit, movements go undetected so the time > >>> unit must be thin grained to cover rapid changes. Yet, depending on > >>> the medium, the time unit, and the size of the network, it is not > >>> necessarily easy/possible to guarantee a strictly monotonous value > >>> with a thin grained time unit. And we have limited space (2 octets) > >>> and have to deal with wrap around, which divides the space by at > > least 3. > >>> > >>> So RPL went for a sequence number. > >> > >> But the unstated assumption that RPL made is that all host-to-router > >> protocols have to now be RPL aware. That doesn't sound like good > > design. > >> A host isn't aware of whether the routers speak IS-IS or OSPF, so why > >> do the hosts need to be aware of RPL by passing some TID around? > >> > >>> I think ND has the same need as MIP for a TID =3D=3D Sequence # . = We > >>> know of MIP; We know of RPL. We know of the backbone router > >>> operation. We know we'll need the TID and we know exactly why. I > >>> think we should have it in the 6LowPAN ND spec right away to avoid > >>> interop issues when we add RPL and BR operations. > >> > >> I don't see a need in 6lowpan-nd for a TID; the protocol works fine > > without it. > >> I think RPL needs to be improved to deal with reality. Isn't there a > >> desire for RPL to handle 4861 hosts? Those would never know about a > > TID. > >> > >> Erik > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan >=20 > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notified > that any use, forwarding, dissemination, or reproduction of this message is > strictly prohibited and may be unlawful. If you are not the intended recipient, > please contact the sender by return e-mail and destroy all copies of the > original message. From gzaverucha@rim.com Mon Apr 18 08:43:17 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BBB81E0811 for <6lowpan@ietfc.amsl.com>; Mon, 18 Apr 2011 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbphq5Gm7ebs for <6lowpan@ietfc.amsl.com>; Mon, 18 Apr 2011 08:43:16 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfc.amsl.com (Postfix) with ESMTP id AF885E0813 for <6lowpan@ietf.org>; Mon, 18 Apr 2011 08:42:35 -0700 (PDT) X-AuditID: 0a41282f-b7cd3ae000006133-53-4dac5be827b5 Received: from XHT108CNC.rim.net (xht108cnc.rim.net [10.65.22.54]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id C5.EF.24883.8EB5CAD4; Mon, 18 Apr 2011 15:42:32 +0000 (GMT) Received: from XCH119CNC.rim.net ([fe80::4d6f:ee50:4d1e:78a2]) by XHT108CNC.rim.net ([fe80::5ccc:ad5f:1697:fdbb%11]) with mapi; Mon, 18 Apr 2011 11:42:33 -0400 From: Greg Zaverucha To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Mon, 18 Apr 2011 11:43:59 -0400 Thread-Topic: Comments on draft-sarikaya-6lowpan-cgand-00 Thread-Index: Acv9329dWb6aaJlkTIeSYnWCE50SAA== Message-ID: <3E12F22CC89F4E439DAC9494AC65A18D05A117CFD8@XCH119CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAZE= Subject: [6lowpan] Comments on draft-sarikaya-6lowpan-cgand-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:43:17 -0000 Comments on draft-sarikaya-6lowpan-cgand-00 "Lightweight Secure Neighbor Discovery for Low-power and Lossy Networks" I think the draft is a good idea, providing an important security feature to neighbor discovery. The draft proposes a protocol called LSEND: Lightweig= ht Secure Neighbor Discovery. Here are some comments on the draft. The introduction could do a better job of describing how LSEND relates to ot= her drafts. LSEND is very close to SEND (RFC 3971) but uses ECDSA instead of RS= A. SEND was designed to secure ND (RFC 2641) but RFC 2641 was obsoleted by RFC 4861. Do the changes from 2641 to 4861 break SEND? Can the SEND protocol be used with the 6lowpan version of neighbor discovery, described in draft-ietf-6lowpan-nd-15? (It appears so, LSEND + draft-ietf-6lowpan-nd-15 i= s described in Section 5.) In Section 1, an additional motivation is that key generation (required for= CGA on low power hosts) is computationally much cheaper with ECDSA than RSA. The references for ECDSA (there are two: SEC 1 and FIPS 186-3) should both appear in one place, I'd suggest under "Digital Signature" in Section 4.1, p= age 5. The reference to SEC 1 should also be updated to version 2.0 (May 2009). Since SEC 1 is specifying ECDSA for use with LSEND, I think it should be a normative reference. A reference to the SECG standard "SEC 2: Recommended Elliptic Curve Domain Parameters version 2.0" could also be added as an informative reference sinc= e it contains relevant information about the EC domain parameters used by LSEN= D (the named curved secp256r1). In Section 4.2, the Key Hash is computed with SHA-2 instead of SHA-1 because= of the weakness of SHA-1. From what I can tell, the Key Hash field is not authenticated (signed), since the Digital Signature Option signs the precedi= ng options (c.f., Section 5.2 of SEND, RFC 3971), and some other information, b= ut not the Key Hash. From RFC 3971, the purpose of the Key Hash is "to associa= te the signature to a particular key known by the receiver". Since the Key Hash= is being used only to help the receiver use the right key, and could be modifie= d in transit, I don't think it needs to be computed with a cryptographic hash function at all, even just truncating the public key to 128 bits would be OK= . That said, I don't see a problem with using SHA-2 here, since it must be implemented for ECDSA anyway. I just think the text is misleading by saying= the Key Hash is computed with SHA-2 for security reasons. Following the same reasoning, LSEND could reduce the size of Key Hash to 64 or 48 bits to save bandwidth, if desired. In Section 4.2 the sequence of octets to be signed is given by Section 5.2 o= f RFC 3971 (SEND). The first input is a "CGA Message Type Tag for SEND", a 128-bit constant. Should LSEND define its own CGA Message Type Tag? Figure 1, caption: LLA is undefined in this document. Section 5.1. For the given domain parameters, an 88-octet ECC public key is= not using point compression, as defined in RFC 5480, Section 2.2. By using point compression the size of the public key is reduced by 32 octets, to 56. Secti= on 4.3 should specify that point compression be used when describing how the public key is to be encoded. General comment: The fast verification feature of ECDSA would be applicable= for this draft. The ECDSA signing algorithm is not changed, but verification is implemented with an equivalent computation that is more efficient. The verification efficiency is even greater if the signer includes one bit of ``side information'' as a convenience to the verifier. In LSEND this extra= bit could come from the reserved bits in the Signature option header, or the Key Hash could be reduced from 128 bits to 127 bits. If a particular signer or verifier does not implement the fast verify techniques, they may still interoperate with those that do. The fast verify convention will allow bord= er routers to process a larger number of signatures. Page 12 of this paper describes the verification technique: http://www.cacr.math.uwaterloo.ca/techreports/2005/cacr2005-28.pdf This draft is also on the subject of fast verification: http://tools.ietf.org/html/draft-struik-ecc-efficiencies-00 Greg --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From nordmark@acm.org Wed Apr 20 16:23:02 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C50ABE0721 for <6lowpan@ietfc.amsl.com>; Wed, 20 Apr 2011 16:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFyz1ddltzpx for <6lowpan@ietfc.amsl.com>; Wed, 20 Apr 2011 16:23:02 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id 033BFE0781 for <6lowpan@ietf.org>; Wed, 20 Apr 2011 16:23:01 -0700 (PDT) Received: from [128.107.115.155] ([128.107.115.155]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3KNMwCR022125 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 16:22:59 -0700 Message-ID: <4DAF6AF6.7020708@acm.org> Date: Wed, 20 Apr 2011 16:23:34 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D0459F3AA@XMB-AMS-107.cisco.com> <4DA87488.6030606@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0464F7BB@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0464F7BB@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:23:02 -0000 On 4/18/11 1:37 AM, Pascal Thubert (pthubert) wrote: > Hi Esko, Erik > > The discussion on RPL and hosts should happen on the RPL list under a > different topic. The point being discussed here is this: But it is hard to have that discussion if we don't know whether the 'hosts' are participating in RPL or not. For this email I assume they are not. > The reality is also that those (LLN) networks will need to scale to > large subnets in plants, building, etc... (see the requirement drafts in > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > requires a coordination between LBRs but does not say how it happens. > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and > it requires a TID, for the same reason as RPL. Removing the backbone > operation and the TID from the draft is ostrich policy. Clearly the backend of the network needs to be able to handle changes in terms of the host's location, whether the backend is a set of LBRs or a set of RPL speakers. But that doesn't mean that the hosts need to be burdened with carrying a TID around. Different backends might use different mechanisms to serialize the changes to the host's location. For example, when I go to an ATM machine to take out some money from my bank, there might be transaction IDs, timestamps, and many other wonderful things happening in the backend ATM network and the bank's database. But that doesn't mean that I as a user of the ATM has to retain a transaction ID that I key into the ATM. I think we can have the same degree of decoupling between 6lowpan and the routing protocols, and we do between the ATM user and the bank's database. > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > registrations do when strict ordering is not guaranteed (MIP being an > example). Say that due to some config, a node registers a lifetime of X, > then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid > sequence, but does not get an answer yet. Then it finally gets 2 AROs > back, lifetime X and 0. What's the final state in the router? If the host changes its mind, then it would make sense for it to first listen to the ack/nak of its previous instructions before issuing a new registration. I don't see this as a difficult restriction, because I think that it will be rare that a host can't decide whether it will register or unregister. Erik From nordmark@acm.org Wed Apr 20 16:24:10 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3DE4E07CC for <6lowpan@ietfc.amsl.com>; Wed, 20 Apr 2011 16:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vly3QrGe5MEz for <6lowpan@ietfc.amsl.com>; Wed, 20 Apr 2011 16:24:09 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id B64CFE0783 for <6lowpan@ietf.org>; Wed, 20 Apr 2011 16:24:08 -0700 (PDT) Received: from [128.107.115.155] ([128.107.115.155]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3KNO4Pb022843 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 16:24:05 -0700 Message-ID: <4DAF6B38.7000604@acm.org> Date: Wed, 20 Apr 2011 16:24:40 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: nicolas.riou@schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:24:10 -0000 On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > Dear Pascal and al, > > I support the idea of reviving the TID in ARO and DAR/DAC. Supporting a > TID directly in the node initiating the initial NS appears much simpler > than time stamping in the parent router. How would you make this work if the protocol between the routers is not RPLv1, but some future version of RPL or a completely different routing protocol? The decoupling of the host-router interaction from router-router interaction has served us well in the history of the Internet. Erik > A simple and efficient method to detect mobility of hosts along a > backbone of Edge Routers is an important feature to deploy backbones of > Edge Routers in Buildings and should be clarified before closing 6LoWPAN > WG. > > Cheers, > Nicolas > > > > > > > *"Pascal Thubert (pthubert)" * > Envoyé par : 6lowpan-bounces@ietf.org > > 18/04/2011 10:37 > > > A > "Dijk, Esko" , "Erik Nordmark" > cc > 6lowpan@ietf.org > Objet > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] > > > > > > > > > Hi Esko, Erik > > The discussion on RPL and hosts should happen on the RPL list under a > different topic. The point being discussed here is this: > > The reality is also that those (LLN) networks will need to scale to > large subnets in plants, building, etc... (see the requirement drafts in > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > requires a coordination between LBRs but does not say how it happens. > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and > it requires a TID, for the same reason as RPL. Removing the backbone > operation and the TID from the draft is ostrich policy. > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > registrations do when strict ordering is not guaranteed (MIP being an > example). Say that due to some config, a node registers a lifetime of X, > then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid > sequence, but does not get an answer yet. Then it finally gets 2 AROs > back, lifetime X and 0. What's the final state in the router? > > I'd like to hear what others think. > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > > Sent: Monday, April 18, 2011 10:19 AM > > To: Erik Nordmark; Pascal Thubert (pthubert) > > Cc: 6lowpan@ietf.org > > Subject: RE: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag > in > > ARO] > > > > Hello Erik, > > > > taking the definition you quoted: > > 'host' refers to an LLN device that can generate but does not > forward > > RPL traffic > > > > the question may arise what is "RPL traffic"? It is not defined in the > RPL draft > > it seems. Pascal clarified to me it is traffic associated to a RPL > instance, not > > necessarily RPL protocol messages. This means that a host could > generate > > RPL traffic without being aware of the existence of RPL at all. So, > _not_ all > > hosts have to speak RPL? > > The RPL draft does not explicitly state if "hosts" in a RPL network > always > > speak RPL, never speak RPL, or can be mixed RPL/non-RPL speakers. > > > > Taking the definition of 'node' in the RPL draft: > > 'node' refers to any RPL device, either a host or a router > > > > rules out (?) the option that all "hosts" are non-RPL speakers, since > there > > may be a "RPL device" (i.e. RPL-speaking device, I assume) that is > also a host. > > > > I communicated these perceived unclarities to Pascal and the RFC > editor 2 > > weeks ago. Once this is clear I think the present discussion can > continue. > > And then there is the related discussion of ND support for sleepy > devices, > > the original topic of Anders ;) > > > > best regards, > > > > Esko > > > > > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Erik Nordmark > > Sent: Friday 15 April 2011 18:39 > > To: Pascal Thubert (pthubert) > > Cc: 6lowpan@ietf.org > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag > in > > ARO] > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > RPL can do what all classical IGPs can do WRT hosts. That is as long > > > as the host address belongs to the router's prefix and stays > attached > > > to that router. > > > > I just realized that we might be talking about a different definition > of "host". > > What I mean by "host" is a node which does not participate in a > routing > > protocol, and does not forward packets (except packets explicitly > addressed > > to itself using e.g., a routing header). > > > > However, RPL has a different definition: > > 'host' refers to an LLN device that can generate but does not > forward > > RPL traffic > > > > Basically per the RPL definition there is no such thing as a node > which does > > not participate in the RPL protocol. > > IMHO what is in RPL should have been defined as a non-forwarding node, > so > > that we can have a sane discussion without getting entangled in > terminology > > issues. > > > > Which definition of "host" are you using above? > > > > Per the RPL definition there is no need for 6lowpan-nd, since all > nodes will > > speak RPL. This is rather confusing, don't you think? > > > > Erik > > > > > When the topology becomes multilink subnet and mobility is required > > > then it is a new problem entirely, and NO, 4861 is not a suitable > > > interaction with the router to allow the router to redistribute a > host route. > > > Because the neighbor cache that 4861 builds is not a of the same > > > nature as the binding table that 6LoWPAN ND builds. Another thing > that > > > 6LoWPAN ND fails to express correctly. I proposed text to explain > that > > > (attached) but it was not considered, contributing to the illusion > > > that a cache is a table. > > > > > > The reality is also that those networks will need to scale to large > > > subnets in plants, building, etc... (see the requirement drafts in > > > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > > > requires a coordination between LBRs but does not say how it > happens. > > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > > > and it requires a TID, for the same reason as RPL. Removing the > > > backbone operation and the TID from the draft is ostrich policy. > > > > > > RPL already adapted to the new reality of large multilink subnet > with > > > inner mobility. Placing the blame on RPL is another illusionist > trick. > > > And this is not RPL last call. > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > other > > > registrations do when strict ordering is not guaranteed (MIP being > an > > > example). Say that due to some config, a node registers a lifetime > of > > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > > rapid sequence, but does not get an answer yet. Then it finally gets > 2 > > > AROs back, lifetime X and 0. What's the final state in the router? > > > > > > It seems we can never agree on any of this. I'd like to hear what > > > others think. > > > > > > Pascal > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > >> -----Original Message----- > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > >> Behalf Of Erik Nordmark > > >> Sent: Friday, April 15, 2011 1:30 AM > > >> To: 6lo>> '6lowpan' > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO > > >> > > >> > > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > > >>> Hi Erik: > > >>> > > >>> The RPL (DAO) sequence number allows the node to increment rapidly > > >>> in case of rapid changes and then lazily when the situation is > > >>> stable and DAO are scarce. The increase is strictly monotonous > which > > > > > >>> is critical to us. > > >>> > > >>> A time stamp imposes a synchronization between the routers. We do > > >>> not have such mechanism in RPL. A time unit (a granularity) must > be > > >>> agreed upon. Within that unit, movements go undetected so the time > > >>> unit must be thin grained to cover rapid changes. Yet, depending > on > > >>> the medium, the time unit, and the size of the network, it is not > > >>> necessarily easy/possible to guarantee a strictly monotonous value > > >>> with a thin grained time unit. And we have limited space (2 > octets) > > >>> and have to deal with wrap around, which divides the space by at > > > least 3. > > >>> > > >>> So RPL went for a sequence number. > > >> > > >> But the unstated assumption that RPL made is that all > host-to-router > > >> protocols have to now be RPL aware. That doesn't sound like good > > > design. > > >> A host isn't aware of whether the routers speak IS-IS or OSPF, so > why > > >> do the hosts need to be aware of RPL by passing some TID around? > > >> > > >>> I think ND has the same need as MIP for a TID == Sequence # . We > > >>> know of MIP; We know of RPL. We know of the backbone router > > >>> operation. We know we'll need the TID and we know exactly why. I > > >>> think we should have it in the 6LowPAN ND spec right away to avoid > > >>> interop issues when we add RPL and BR operations. > > >> > > >> I don't see a need in 6lowpan-nd for a TID; the protocol works fine > > > without it. > > >> I think RPL needs to be improved to deal with reality. Isn't there > a > > >> desire for RPL to handle 4861 hosts? Those would never know about a > > > TID. > > >> > > >> Erik > > >> > > >> _______________________________________________ > > >> 6lowpan mailing list > > >> 6lowpan@ietf.org > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > The information contained in this message may be confidential and > legally > > protected under applicable law. The message is intended solely for the > > addressee(s). If you are not the intended recipient, you are hereby > notified > > that any use, forwarding, dissemination, or reproduction of this > message is > > strictly prohibited and may be unlawful. If you are not the intended > recipient, > > please contact the sender by return e-mail and destroy all copies of > the > > original message. > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ > From pthubert@cisco.com Thu Apr 21 00:10:42 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3E21FE071B for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 00:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.502 X-Spam-Level: X-Spam-Status: No, score=-8.502 tagged_above=-999 required=5 tests=[AWL=2.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkqBFrwSiGcp for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 00:10:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 050B0E0712 for <6lowpan@ietf.org>; Thu, 21 Apr 2011 00:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=9972; q=dns/txt; s=iport; t=1303369840; x=1304579440; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=B0zOCHaXXL6bq6JSH1PtjN4U2YZLULqu88XMYcuhsVU=; b=GlNlilHfbPE98Wd3cSmbOu6DwKQtcYZ7SAINK1sSvXaxZNxYnxXnXHBf ooQMaBM6P4szExkd4RFYU66eDJ97BQmYgwfPrMvlWcAChQ07LHBAHU9JX kQTi1sH9BeKU5bGV9qbmaRHLa/Ex1F8dxmWvx4Vf6hcg+ePa9BeQuThPU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAADrXr02Q/khLgWdsb2JhbACXQY4HFAEBFiYliHCgOJxYhXYEkjc X-IronPort-AV: E=Sophos;i="4.64,250,1301875200"; d="scan'208";a="84518067" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2011 07:10:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3L7AcCb007418; Thu, 21 Apr 2011 07:10:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 09:10:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2011 09:10:36 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D046502CE@XMB-AMS-107.cisco.com> In-Reply-To: <4DAF6A31.1030800@sonic.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: Acv/sXZUNNYojxyVTvKg7J7G3LYTkQAQV8Rw References: <6A2A459175DABE4BB11DE2026AA50A5D0459F3AA@XMB-AMS-107.cisco.com> <4DA87488.6030606@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0464F7BB@XMB-AMS-107.cisco.com> <4DAF6A31.1030800@sonic.net> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" X-OriginalArrivalTime: 21 Apr 2011 07:10:38.0885 (UTC) FILETIME=[37D23550:01CBFFF3] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 07:10:42 -0000 >=20 > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > > registrations do when strict ordering is not guaranteed (MIP being an > > example). Say that due to some config, a node registers a lifetime of > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > rapid sequence, but does not get an answer yet. Then it finally gets 2 > > AROs back, lifetime X and 0. What's the final state in the router? >=20 > If the host changes its mind, then it would make sense for it to first listen to > the ack/nak of its previous instructions before issuing a new registration. >=20 > I don't see this as a difficult restriction, because I think that it will be rare that > a host can't decide whether it will register or unregister. [Pascal] Decoupling from L2 capability should serve us well also, shouldn't it? In mesh under: - you do not have end to end ack - you will have multipath - you will have out of order packets ND needs a TID.=20 Pascal > Erik >=20 > > I'd like to hear what others think. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > >> -----Original Message----- > >> From: Dijk, Esko [mailto:esko.dijk@philips.com] > >> Sent: Monday, April 18, 2011 10:19 AM > >> To: Erik Nordmark; Pascal Thubert (pthubert) > >> Cc: 6lowpan@ietf.org > >> Subject: RE: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" > >> flag > > in > >> ARO] > >> > >> Hello Erik, > >> > >> taking the definition you quoted: > >> 'host' refers to an LLN device that can generate but does not > > forward > >> RPL traffic > >> > >> the question may arise what is "RPL traffic"? It is not defined in > >> the > > RPL draft > >> it seems. Pascal clarified to me it is traffic associated to a RPL > > instance, not > >> necessarily RPL protocol messages. This means that a host could > > generate > >> RPL traffic without being aware of the existence of RPL at all. So, > > _not_ all > >> hosts have to speak RPL? > >> The RPL draft does not explicitly state if "hosts" in a RPL network > > always > >> speak RPL, never speak RPL, or can be mixed RPL/non-RPL speakers. > >> > >> Taking the definition of 'node' in the RPL draft: > >> 'node' refers to any RPL device, either a host or a router > >> > >> rules out (?) the option that all "hosts" are non-RPL speakers, since > > there > >> may be a "RPL device" (i.e. RPL-speaking device, I assume) that is > > also a host. > >> > >> I communicated these perceived unclarities to Pascal and the RFC > > editor 2 > >> weeks ago. Once this is clear I think the present discussion can > > continue. > >> And then there is the related discussion of ND support for sleepy > > devices, > >> the original topic of Anders ;) > >> > >> best regards, > >> > >> Esko > >> > >> > >> > >> -----Original Message----- > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >> Behalf Of Erik Nordmark > >> Sent: Friday 15 April 2011 18:39 > >> To: Pascal Thubert (pthubert) > >> Cc: 6lowpan@ietf.org > >> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" > >> flag > > in > >> ARO] > >> > >> On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > >> > >>> RPL can do what all classical IGPs can do WRT hosts. That is as long > >>> as the host address belongs to the router's prefix and stays > > attached > >>> to that router. > >> > >> I just realized that we might be talking about a different definition > > of "host". > >> What I mean by "host" is a node which does not participate in a > > routing > >> protocol, and does not forward packets (except packets explicitly > > addressed > >> to itself using e.g., a routing header). > >> > >> However, RPL has a different definition: > >> 'host' refers to an LLN device that can generate but does not > > forward > >> RPL traffic > >> > >> Basically per the RPL definition there is no such thing as a node > > which does > >> not participate in the RPL protocol. > >> IMHO what is in RPL should have been defined as a non-forwarding > >> node, > > so > >> that we can have a sane discussion without getting entangled in > > terminology > >> issues. > >> > >> Which definition of "host" are you using above? > >> > >> Per the RPL definition there is no need for 6lowpan-nd, since all > > nodes will > >> speak RPL. This is rather confusing, don't you think? > >> > >> Erik > >> > >>> When the topology becomes multilink subnet and mobility is required > >>> then it is a new problem entirely, and NO, 4861 is not a suitable > >>> interaction with the router to allow the router to redistribute a > > host route. > >>> Because the neighbor cache that 4861 builds is not a of the same > >>> nature as the binding table that 6LoWPAN ND builds. Another thing > > that > >>> 6LoWPAN ND fails to express correctly. I proposed text to explain > > that > >>> (attached) but it was not considered, contributing to the illusion > >>> that a cache is a table. > >>> > >>> The reality is also that those networks will need to scale to large > >>> subnets in plants, building, etc... (see the requirement drafts in > >>> ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > >>> requires a coordination between LBRs but does not say how it > > happens. > >>> This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > >>> and it requires a TID, for the same reason as RPL. Removing the > >>> backbone operation and the TID from the draft is ostrich policy. > >>> > >>> RPL already adapted to the new reality of large multilink subnet > > with > >>> inner mobility. Placing the blame on RPL is another illusionist > > trick. > >>> And this is not RPL last call. > >>> > >>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > > other > >>> registrations do when strict ordering is not guaranteed (MIP being > > an > >>> example). Say that due to some config, a node registers a lifetime > > of > >>> X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > >>> rapid sequence, but does not get an answer yet. Then it finally gets > > 2 > >>> AROs back, lifetime X and 0. What's the final state in the router? > >>> > >>> It seems we can never agree on any of this. I'd like to hear what > >>> others think. > >>> > >>> Pascal > >>> http://www.xtranormal.com/watch/7011357/ > >>> > >>> > >>>> -----Original Message----- > >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > On > >>>> Behalf Of Erik Nordmark > >>>> Sent: Friday, April 15, 2011 1:30 AM > >>>> To: 6lo>> '6lowpan' > >>>> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO > >>>> > >>>> > >>>> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > >>>>> Hi Erik: > >>>>> > >>>>> The RPL (DAO) sequence number allows the node to increment > rapidly > >>>>> in case of rapid changes and then lazily when the situation is > >>>>> stable and DAO are scarce. The increase is strictly monotonous > > which > >>> > >>>>> is critical to us. > >>>>> > >>>>> A time stamp imposes a synchronization between the routers. We do > >>>>> not have such mechanism in RPL. A time unit (a granularity) must > > be > >>>>> agreed upon. Within that unit, movements go undetected so the time > >>>>> unit must be thin grained to cover rapid changes. Yet, depending > > on > >>>>> the medium, the time unit, and the size of the network, it is not > >>>>> necessarily easy/possible to guarantee a strictly monotonous value > >>>>> with a thin grained time unit. And we have limited space (2 > > octets) > >>>>> and have to deal with wrap around, which divides the space by at > >>> least 3. > >>>>> > >>>>> So RPL went for a sequence number. > >>>> > >>>> But the unstated assumption that RPL made is that all > > host-to-router > >>>> protocols have to now be RPL aware. That doesn't sound like good > >>> design. > >>>> A host isn't aware of whether the routers speak IS-IS or OSPF, so > > why > >>>> do the hosts need to be aware of RPL by passing some TID around? > >>>> > >>>>> I think ND has the same need as MIP for a TID =3D=3D Sequence # = . We > >>>>> know of MIP; We know of RPL. We know of the backbone router > >>>>> operation. We know we'll need the TID and we know exactly why. I > >>>>> think we should have it in the 6LowPAN ND spec right away to avoid > >>>>> interop issues when we add RPL and BR operations. > >>>> > >>>> I don't see a need in 6lowpan-nd for a TID; the protocol works fine > >>> without it. > >>>> I think RPL needs to be improved to deal with reality. Isn't there > > a > >>>> desire for RPL to handle 4861 hosts? Those would never know about a > >>> TID. > >>>> > >>>> Erik > >>>> > >>>> _______________________________________________ > >>>> 6lowpan mailing list > >>>> 6lowpan@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> _______________________________________________ > >>> 6lowpan mailing list > >>> 6lowpan@ietf.org > >>> https://www.ietf.org/mailman/listinfo/6lowpan > >>> > >> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > >> > >> The information contained in this message may be confidential and > > legally > >> protected under applicable law. The message is intended solely for > >> the addressee(s). If you are not the intended recipient, you are > >> hereby > > notified > >> that any use, forwarding, dissemination, or reproduction of this > > message is > >> strictly prohibited and may be unlawful. If you are not the intended > > recipient, > >> please contact the sender by return e-mail and destroy all copies of > > the > >> original message. > > > > From pthubert@cisco.com Thu Apr 21 00:27:21 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8E1DDE0713 for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 00:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.619 X-Spam-Level: X-Spam-Status: No, score=-8.619 tagged_above=-999 required=5 tests=[AWL=1.980, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBQbxZSGJ7iy for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 00:27:19 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 57A48E070B for <6lowpan@ietf.org>; Thu, 21 Apr 2011 00:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=13182; q=dns/txt; s=iport; t=1303370839; x=1304580439; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=D5tNYKpYo3eC4Fhwx16eEijqUkySYieyVs0Uk1nhRuo=; b=GQpQPDhQhKpv75L1wj5taCERMBV8Ri06j7A0ELkK3tvCetYh51WLCX4d wrm86w0ojKYOn2us2EMAX52t6t1tdbperz70GGeNeMv20TSVcODJvqdv3 wQb6BT7axOtVc1ZTFFYg51IIVpiOH6MEv/cx0wwqm2GvCMAceRrmvntB4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAKLbr02Q/khRgWdsb2JhbACXQY4HFAEBFiYlqQ2cW4V2BJI3 X-IronPort-AV: E=Sophos;i="4.64,250,1301875200"; d="scan'208";a="26558489" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 21 Apr 2011 07:27:17 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3L7RHAc031090; Thu, 21 Apr 2011 07:27:17 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 09:27:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2011 09:27:15 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> In-Reply-To: <4DAF6B38.7000604@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: Acv/sh/X93ihejyiSZKayGB0OnPZrAAQaiUQ References: <4DAF6B38.7000604@acm.org> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , X-OriginalArrivalTime: 21 Apr 2011 07:27:17.0717 (UTC) FILETIME=[8B2BE050:01CBFFF5] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 07:27:21 -0000 Hi Erik The TID is not a strong coupling between the H2R and the R2R operations, = and it is not a coupling with a RPL version explicitly.=20 It is an abstract information that if defined properly can be used by = many forms or R2R interactions. As demonstrated by older versions of the ND spec (Backbone Router), RPL, = and MIP. 6LoWPAN ND cannot scale if the node needs to register to all LBRs. = 6LoWPAN ND does not define anymore any LBR interaction. IOW, 6LoPWAN ND lost the capability to scale when the backbone router = piece was removed from the draft.=20 Which means that it lost its capability to apply in the domains I'm = looking at (industrial and metering). With the TID, we know that we can restore scalability in the future, and = we know how. I do not know of a plan B. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Erik Nordmark [mailto:nordmark@acm.org] > Sent: Thursday, April 21, 2011 1:25 AM > To: nicolas.riou@schneider-electric.com > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag = in > ARO] >=20 > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > > > Dear Pascal and al, > > > > I support the idea of reviving the TID in ARO and DAR/DAC. = Supporting > > a TID directly in the node initiating the initial NS appears much > > simpler than time stamping in the parent router. >=20 > How would you make this work if the protocol between the routers is = not > RPLv1, but some future version of RPL or a completely different = routing > protocol? >=20 > The decoupling of the host-router interaction from router-router = interaction > has served us well in the history of the Internet. >=20 > Erik >=20 > > A simple and efficient method to detect mobility of hosts along a > > backbone of Edge Routers is an important feature to deploy backbones > > of Edge Routers in Buildings and should be clarified before closing > > 6LoWPAN WG. > > > > Cheers, > > Nicolas > > > > > > > > > > > > > > *"Pascal Thubert (pthubert)" * Envoy=E9 par : > > 6lowpan-bounces@ietf.org > > > > 18/04/2011 10:37 > > > > > > A > > "Dijk, Esko" , "Erik Nordmark" > > cc > > 6lowpan@ietf.org > > Objet > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > > > > > > > > > > > > > > > > > Hi Esko, Erik > > > > The discussion on RPL and hosts should happen on the RPL list under = a > > different topic. The point being discussed here is this: > > > > The reality is also that those (LLN) networks will need to scale to > > large subnets in plants, building, etc... (see the requirement = drafts > > in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > > requires a coordination between LBRs but does not say how it = happens. > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > > and it requires a TID, for the same reason as RPL. Removing the > > backbone operation and the TID from the draft is ostrich policy. > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all = other > > registrations do when strict ordering is not guaranteed (MIP being = an > > example). Say that due to some config, a node registers a lifetime = of > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > rapid sequence, but does not get an answer yet. Then it finally gets = 2 > > AROs back, lifetime X and 0. What's the final state in the router? > > > > I'd like to hear what others think. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > > > -----Original Message----- > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Monday, > > April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal Thubert > > (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: TID > > in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello Erik, > > > > taking the definition you quoted: > > > 'host' refers to an LLN device that can generate but does not > > forward > RPL traffic > > the question may arise what is "RPL > > traffic"? It is not defined in the RPL draft > it seems. Pascal > > clarified to me it is traffic associated to a RPL instance, not > > > necessarily RPL protocol messages. This means that a host could > > generate > RPL traffic without being aware of the existence of RPL = at > > all. So, _not_ all > hosts have to speak RPL? > > > The RPL draft does not explicitly state if "hosts" in a RPL = network > > always > speak RPL, never speak RPL, or can be mixed RPL/non-RPL > > speakers. > > > > > > Taking the definition of 'node' in the RPL draft: > > > 'node' refers to any RPL device, either a host or a router > > > > rules out (?) the option that all "hosts" are non-RPL speakers, = since > > there > may be a "RPL device" (i.e. RPL-speaking device, I assume) > > that is also a host. > > > > > > I communicated these perceived unclarities to Pascal and the RFC > > editor 2 > weeks ago. Once this is clear I think the present > > discussion can continue. > > > And then there is the related discussion of ND support for sleepy > > devices, > the original topic of Anders ;) > > best regards, > = > > > Esko > > > > -----Original Message----- > From: > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: > > Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > > > RPL can do what all classical IGPs can do WRT hosts. That is as > > long > > as the host address belongs to the router's prefix and = stays > > attached > > to that router. > > > > > > I just realized that we might be talking about a different > > definition of "host". > > > What I mean by "host" is a node which does not participate in a > > routing > protocol, and does not forward packets (except packets > > explicitly addressed > to itself using e.g., a routing header). > > > > > > However, RPL has a different definition: > > > 'host' refers to an LLN device that can generate but does not > > forward > RPL traffic > > Basically per the RPL definition there = is > > no such thing as a node which does > not participate in the RPL > > protocol. > > > IMHO what is in RPL should have been defined as a non-forwarding > > node, so > that we can have a sane discussion without getting > > entangled in terminology > issues. > > > > > > Which definition of "host" are you using above? > > > > > > Per the RPL definition there is no need for 6lowpan-nd, since all > > nodes will > speak RPL. This is rather confusing, don't you think? > > > > > > Erik > > > > > > > When the topology becomes multilink subnet and mobility is > > required > > then it is a new problem entirely, and NO, 4861 is not = a > > suitable > > interaction with the router to allow the router to > > redistribute a host route. > > > > Because the neighbor cache that 4861 builds is not a of the = same > > > > nature as the binding table that 6LoWPAN ND builds. Another = thing > > that > > 6LoWPAN ND fails to express correctly. I proposed text to > > explain that > > (attached) but it was not considered, contributing > > to the illusion > > that a cache is a table. > > > > > > > > The reality is also that those networks will need to scale to > > large > > subnets in plants, building, etc... (see the requirement > > drafts in > > ROLL). Registering to all LBRS is totally = impractical. > > 6LoWPAN ND > > requires a coordination between LBRs but does not = say > > how it happens. > > > > This problem was discussed in 6LoWPAN; the answer was in > > ND-01to07; > > and it requires a TID, for the same reason as RPL. > > Removing the > > backbone operation and the TID from the draft is = ostrich > policy. > > > > > > > > RPL already adapted to the new reality of large multilink = subnet > > with > > inner mobility. Placing the blame on RPL is another > > illusionist trick. > > > > And this is not RPL last call. > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as = all > > other > > registrations do when strict ordering is not guaranteed > > (MIP being an > > example). Say that due to some config, a node > > registers a lifetime of > > X, then deregisters (lifetime 0), then > > reregisters (lifetime X) in a > > rapid sequence, but does not get = an > > answer yet. Then it finally gets > > 2 > > > > AROs back, lifetime X and 0. What's the final state in the = router? > > > > > > > > It seems we can never agree on any of this. I'd like to hear = what > > > > others think. > > > > > > > > Pascal > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > >> -----Original Message----- > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- > bounces@ietf.org] > > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, 2011 > > 1:30 AM > >> To: 6lo>> '6lowpan' > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in > > ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) > > wrote: > > > >>> Hi Erik: > > > >>> > > > >>> The RPL (DAO) sequence number allows the node to increment > > rapidly > >>> in case of rapid changes and then lazily when the > > situation is > >>> stable and DAO are scarce. The increase is > > strictly monotonous which > > > >>> is critical to us. > > > >>> > > > >>> A time stamp imposes a synchronization between the routers. = We > > do > >>> not have such mechanism in RPL. A time unit (a = granularity) > > must be > >>> agreed upon. Within that unit, movements go = undetected > > so the time > >>> unit must be thin grained to cover rapid changes. > > Yet, depending on > >>> the medium, the time unit, and the size of > > the network, it is not > >>> necessarily easy/possible to guarantee = a > > strictly monotonous value > >>> with a thin grained time unit. And = we > > have limited space (2 > > octets) > > > >>> and have to deal with wrap around, which divides the space by > > at > > least 3. > > > >>> > > > >>> So RPL went for a sequence number. > > > >> > > > >> But the unstated assumption that RPL made is that all > > host-to-router > >> protocols have to now be RPL aware. That = doesn't > > sound like good > > design. > > > >> A host isn't aware of whether the routers speak IS-IS or OSPF, > > so why > >> do the hosts need to be aware of RPL by passing some = TID > > around? > > > >> > > > >>> I think ND has the same need as MIP for a TID =3D=3D Sequence = # . > > We > >>> know of MIP; We know of RPL. We know of the backbone = router > > > >>> operation. We know we'll need the TID and we know exactly why. = I > > > >>> think we should have it in the 6LowPAN ND spec right away to > > avoid > >>> interop issues when we add RPL and BR operations. > > > >> > > > >> I don't see a need in 6lowpan-nd for a TID; the protocol works > > fine > > without it. > > > >> I think RPL needs to be improved to deal with reality. Isn't > > there a > >> desire for RPL to handle 4861 hosts? Those would never > > know about a > > TID. > > > >> > > > >> Erik > > > >> > > > >> _______________________________________________ > > > >> 6lowpan mailing list > > > >> 6lowpan@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > The information contained in this message may be confidential and > > legally > protected under applicable law. The message is intended > > solely for the > addressee(s). If you are not the intended = recipient, > > you are hereby notified > that any use, forwarding, dissemination, = or > > reproduction of this message is > strictly prohibited and may be > > unlawful. If you are not the intended recipient, > please contact = the > > sender by return e-mail and destroy all copies of the > original > > message. > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > __________________________________________________________ > ____________ > > This email has been scanned by the MessageLabs Email Security = System. > > > __________________________________________________________ > ____________ > > From nicolas.riou@schneider-electric.com Thu Apr 21 07:30:51 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3765E068E for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=3.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBLRQe6n-CwS for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 07:30:48 -0700 (PDT) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by ietfc.amsl.com (Postfix) with ESMTP id 47512E00BE for <6lowpan@ietf.org>; Thu, 21 Apr 2011 07:30:48 -0700 (PDT) Received: from ateui02.Schneider-Electric.com ([10.198.14.10]) by mailX03.eud.schneider-electric.com with ESMTP id 2011042116103759-28867 ; Thu, 21 Apr 2011 16:10:37 +0200 To: "Erik Nordmark" MIME-Version: 1.0 X-KeepSent: 0DBCBB23:FB5BBA7F-C1257879:004686FB; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: nicolas.riou@schneider-electric.com Date: Thu, 21 Apr 2011 16:30:45 +0200 X-MIMETrack: Serialize by Router on ATEUI02.Schneider-Electric.com/T/SVR/Schneider at 21/04/2011 16:30:38, Serialize complete at 21/04/2011 16:30:38, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 21/04/2011 16:10:37, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 21/04/2011 16:10:38, Serialize complete at 21/04/2011 16:10:38 Content-Type: multipart/alternative; boundary="=_alternative 004FB85FC1257879_=" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:30:51 -0000 Message en plusieurs parties au format MIME --=_alternative 004FB85FC1257879_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Hi Erik, Comments in line... > From: Erik Nordmark [mailto:nordmark@acm.org] > Sent: Thursday, April 21, 2011 1:25 AM > To: nicolas.riou@schneider-electric.com > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag=20 in > ARO] >=20 > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > > > Dear Pascal and al, > > > > I support the idea of reviving the TID in ARO and DAR/DAC. Supporting > > a TID directly in the node initiating the initial NS appears much > > simpler than time stamping in the parent router. >=20 > How would you make this work if the protocol between the routers is not > RPLv1, but some future version of RPL or a completely different routing > protocol? =20 As Pascal answered in his post, the TID is not particularly coupled with=20 RPLv1. The TID is just an extra information provided by the node during=20 ND registration which dramatically simplifies node localization but also=20 enable DAD across a backbone of Edge Routers advertizing the same prefix. Which alternative solution would you suggest for DAD? The TID can fit in "reserved" field of ARO/DAR/DAC and thus can come=20 at no cost. Thanks to the lollipop mechanism defined in 6lowpan-nd-07 the TID can be implemented even in the most constrained devices which might not be able to consistently increment the TID. =20 Regards, Nicolas > The decoupling of the host-router interaction from router-router=20 interaction > has served us well in the history of the Internet. >=20 > Erik >=20 > > A simple and efficient method to detect mobility of hosts along a > > backbone of Edge Routers is an important feature to deploy backbones > > of Edge Routers in Buildings and should be clarified before closing > > 6LoWPAN WG. > > > > Cheers, > > Nicolas > > > > > > > > > > > > > > *"Pascal Thubert (pthubert)" * Envoy=E9 par : > > 6lowpan-bounces@ietf.org > > > > 18/04/2011 10:37 > > > > > > A > > "Dijk, Esko" , "Erik Nordmark" > > cc > > 6lowpan@ietf.org > > Objet > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf"=20 flag in > ARO] > > > > > > > > > > > > > > > > > > Hi Esko, Erik > > > > The discussion on RPL and hosts should happen on the RPL list under a > > different topic. The point being discussed here is this: > > > > The reality is also that those (LLN) networks will need to scale to > > large subnets in plants, building, etc... (see the requirement drafts > > in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > > requires a coordination between LBRs but does not say how it happens. > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > > and it requires a TID, for the same reason as RPL. Removing the > > backbone operation and the TID from the draft is ostrich policy. > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > > registrations do when strict ordering is not guaranteed (MIP being an > > example). Say that due to some config, a node registers a lifetime of > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > rapid sequence, but does not get an answer yet. Then it finally gets 2 > > AROs back, lifetime X and 0. What's the final state in the router? > > > > I'd like to hear what others think. > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > > > -----Original Message----- > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Monday, > > April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal Thubert > > (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: TID > > in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello Erik, > > > > taking the definition you quoted: > > > 'host' refers to an LLN device that can generate but does not > > forward > RPL traffic > > the question may arise what is "RPL > > traffic"? It is not defined in the RPL draft > it seems. Pascal > > clarified to me it is traffic associated to a RPL instance, not > > > necessarily RPL protocol messages. This means that a host could > > generate > RPL traffic without being aware of the existence of RPL at > > all. So, =5Fnot=5F all > hosts have to speak RPL? > > > The RPL draft does not explicitly state if "hosts" in a RPL network > > always > speak RPL, never speak RPL, or can be mixed RPL/non-RPL > > speakers. > > > > > > Taking the definition of 'node' in the RPL draft: > > > 'node' refers to any RPL device, either a host or a router > > > > rules out (?) the option that all "hosts" are non-RPL speakers, since > > there > may be a "RPL device" (i.e. RPL-speaking device, I assume) > > that is also a host. > > > > > > I communicated these perceived unclarities to Pascal and the RFC > > editor 2 > weeks ago. Once this is clear I think the present > > discussion can continue. > > > And then there is the related discussion of ND support for sleepy > > devices, > the original topic of Anders ;) > > best regards, > > > > Esko > > > > -----Original Message----- > From: > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: > > Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > > > RPL can do what all classical IGPs can do WRT hosts. That is as > > long > > as the host address belongs to the router's prefix and stays > > attached > > to that router. > > > > > > I just realized that we might be talking about a different > > definition of "host". > > > What I mean by "host" is a node which does not participate in a > > routing > protocol, and does not forward packets (except packets > > explicitly addressed > to itself using e.g., a routing header). > > > > > > However, RPL has a different definition: > > > 'host' refers to an LLN device that can generate but does not > > forward > RPL traffic > > Basically per the RPL definition there is > > no such thing as a node which does > not participate in the RPL > > protocol. > > > IMHO what is in RPL should have been defined as a non-forwarding > > node, so > that we can have a sane discussion without getting > > entangled in terminology > issues. > > > > > > Which definition of "host" are you using above? > > > > > > Per the RPL definition there is no need for 6lowpan-nd, since all > > nodes will > speak RPL. This is rather confusing, don't you think? > > > > > > Erik > > > > > > > When the topology becomes multilink subnet and mobility is > > required > > then it is a new problem entirely, and NO, 4861 is not a > > suitable > > interaction with the router to allow the router to > > redistribute a host route. > > > > Because the neighbor cache that 4861 builds is not a of the same > > > > nature as the binding table that 6LoWPAN ND builds. Another thing > > that > > 6LoWPAN ND fails to express correctly. I proposed text to > > explain that > > (attached) but it was not considered, contributing > > to the illusion > > that a cache is a table. > > > > > > > > The reality is also that those networks will need to scale to > > large > > subnets in plants, building, etc... (see the requirement > > drafts in > > ROLL). Registering to all LBRS is totally impractical. > > 6LoWPAN ND > > requires a coordination between LBRs but does not say > > how it happens. > > > > This problem was discussed in 6LoWPAN; the answer was in > > ND-01to07; > > and it requires a TID, for the same reason as RPL. > > Removing the > > backbone operation and the TID from the draft is=20 ostrich > policy. > > > > > > > > RPL already adapted to the new reality of large multilink subnet > > with > > inner mobility. Placing the blame on RPL is another > > illusionist trick. > > > > And this is not RPL last call. > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > > other > > registrations do when strict ordering is not guaranteed > > (MIP being an > > example). Say that due to some config, a node > > registers a lifetime of > > X, then deregisters (lifetime 0), then > > reregisters (lifetime X) in a > > rapid sequence, but does not get an > > answer yet. Then it finally gets > > 2 > > > > AROs back, lifetime X and 0. What's the final state in the=20 router? > > > > > > > > It seems we can never agree on any of this. I'd like to hear what > > > > others think. > > > > > > > > Pascal > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > >> -----Original Message----- > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- > bounces@ietf.org] > > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, 2011 > > 1:30 AM > >> To: 6lo>> '6lowpan' > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in > > ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) > > wrote: > > > >>> Hi Erik: > > > >>> > > > >>> The RPL (DAO) sequence number allows the node to increment > > rapidly > >>> in case of rapid changes and then lazily when the > > situation is > >>> stable and DAO are scarce. The increase is > > strictly monotonous which > > > >>> is critical to us. > > > >>> > > > >>> A time stamp imposes a synchronization between the routers. We > > do > >>> not have such mechanism in RPL. A time unit (a granularity) > > must be > >>> agreed upon. Within that unit, movements go undetected > > so the time > >>> unit must be thin grained to cover rapid changes. > > Yet, depending on > >>> the medium, the time unit, and the size of > > the network, it is not > >>> necessarily easy/possible to guarantee a > > strictly monotonous value > >>> with a thin grained time unit. And we > > have limited space (2 > > octets) > > > >>> and have to deal with wrap around, which divides the space by > > at > > least 3. > > > >>> > > > >>> So RPL went for a sequence number. > > > >> > > > >> But the unstated assumption that RPL made is that all > > host-to-router > >> protocols have to now be RPL aware. That doesn't > > sound like good > > design. > > > >> A host isn't aware of whether the routers speak IS-IS or OSPF, > > so why > >> do the hosts need to be aware of RPL by passing some TID > > around? > > > >> > > > >>> I think ND has the same need as MIP for a TID =3D=3D Sequence # . > > We > >>> know of MIP; We know of RPL. We know of the backbone router > > > >>> operation. We know we'll need the TID and we know exactly why. I > > > >>> think we should have it in the 6LowPAN ND spec right away to > > avoid > >>> interop issues when we add RPL and BR operations. > > > >> > > > >> I don't see a need in 6lowpan-nd for a TID; the protocol works > > fine > > without it. > > > >> I think RPL needs to be improved to deal with reality. Isn't > > there a > >> desire for RPL to handle 4861 hosts? Those would never > > know about a > > TID. > > > >> > > > >> Erik > > > >> > > > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > >> 6lowpan mailing list > > > >> 6lowpan@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > The information contained in this message may be confidential and > > legally > protected under applicable law. The message is intended > > solely for the > addressee(s). If you are not the intended recipient, > > you are hereby notified > that any use, forwarding, dissemination, or > > reproduction of this message is > strictly prohibited and may be > > unlawful. If you are not the intended recipient, > please contact the > > sender by return e-mail and destroy all copies of the > original > > message. > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > This email has been scanned by the MessageLabs Email Security System. > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > --=_alternative 004FB85FC1257879_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
Hi Erik,

Comments in line...

> From: Erik Nordmark [mailto:nordmark@acm.org] > Sent: Thursday, April 21, 2011 1:25 AM
> To: nicolas.riou@schneider-electric.com
> Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko
> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf&= quot; flag in
> ARO]
>
> On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote:
> >
> > Dear Pascal and al,
> >
> > I support the idea of reviving the TID in ARO and DAR/DAC. Suppor= ting
> > a TID directly in the node initiating the initial NS appears much
> > simpler than time stamping in the parent router.
>
> How would you make this work if the protocol between the routers is not
> RPLv1, but some future version of RPL or a completely different routin= g
> protocol?
As Pascal answered in his post, the TID is not parti= cularly coupled with
RPLv1. The TID is just an extra information provided by the node during
ND registration which dramatically simplifies node localization but also
enable DAD across a backbone of Edge Routers adverti= zing the same prefix.
Which alternative solution would you suggest for DAD= ?

The TID can fit in "reserved" field of ARO= /DAR/DAC and thus can come
at no cost.

Thanks to the lollipop mechanism defined in 6lowpan-= nd-07 the TID can be
implemented even in the most constrained devices whi= ch might not be able
to consistently increment the TID.
 
Regards,
Nicolas


> The decoupling of the host-router interaction from router-router inter= action
> has served us well in the history of the Internet.
>
>       Erik
>
> > A simple and efficient method to detect mobility of hosts along a
> > backbone of Edge Routers is an important feature to deploy backbo= nes
> > of Edge Routers in Buildings and should be clarified before closi= ng
> > 6LoWPAN WG.
> >
> > Cheers,
> > Nicolas
> >
> >
> >
> >
> >
> >
> > *"Pascal Thubert (pthubert)" <pthubert@cisco.com>* Envoy=E9 par :
> > 6lowpan-bounces@ietf.org
> >
> > 18/04/2011 10:37
> >
> >
> > A
> >                  "Dijk, Esko" <esko.dijk@philips.com>, "Erik Nordmark"
> > <nordmark@acm.org> cc
> >                  6lowpan@ietf.org
> > Objet
> >                  Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
> ARO]
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Esko, Erik
> >
> > The discussion on RPL and hosts should happen on the RPL list under a
> > different topic. The point being discussed here is this:
> >
> > The reality is also that those (LLN) networks will need to scale to
> > large subnets in plants, building, etc... (see the requirement drafts
> > in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND
> > requires a coordination between LBRs but does not say how it happens.
> > This problem was discussed in 6LoWPAN; the answer was in ND-01to0= 7;
> > and it requires a TID, for the same reason as RPL. Removing the > > backbone operation and the TID from the draft is ostrich policy.<= br> > >
> > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other
> > registrations do when strict ordering is not guaranteed (MIP being an
> > example). Say that due to some config, a node registers a lifetime of
> > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a
> > rapid sequence, but does not get an answer yet. Then it finally gets 2
> > AROs back, lifetime X and 0. What's the final state in the router= ?
> >
> > I'd like to hear what others think.
> >
> > Pascal
> > http://www.xtranormal.com/watch/7011357/
> >
> >
> >  > -----Original Message-----
> >  > From: Dijk, Esko [mailto:esko.dijk@philips.com]  = > Sent: Monday,
> > April 18, 2011 10:19 AM  > To: Erik Nordmark; Pascal Thubert
> > (pthubert)  > Cc: 6lowpan@ietf.org  > Subject: RE: [6lowpan] FW: TID
> > in ARO [was: "Advertize on Behalf" flag in  > ARO]  >  > Hello Erik,
> > >  > taking the definition you quoted:
> >  > 'host' refers to an LLN device that can generate but does not
> > forward  > RPL traffic  >  > the question may arise what is "RPL
> > traffic"? It is not defined in the RPL draft  > it seems. Pascal
> > clarified to me it is traffic associated to a RPL instance, not  >
> > necessarily RPL protocol messages. This means that a host could > > generate  > RPL traffic without being aware of the existe= nce of RPL at
> > all. So, =5Fnot=5F all  > hosts have to speak RPL?
> >  > The RPL draft does not explicitly state if "hosts= " in a RPL network
> > always  > speak RPL, never speak RPL, or can be mixed RPL/non-RPL
> > speakers.
> >  >
> >  > Taking the definition of 'node' in the RPL draft:
> >  > 'node' refers to any RPL device, either a host or a router  >  >
> > rules out (?) the option that all "hosts" are non-RPL speakers, since
> > there  > may be a "RPL device" (i.e. RPL-speaki= ng device, I assume)
> > that is also a host.
> >  >
> >  > I communicated these perceived unclarities to Pascal and the RFC
> > editor 2  > weeks ago. Once this is clear I think the present
> > discussion can continue.
> >  > And then there is the related discussion of ND support for sleepy
> > devices,  > the original topic of Anders ;)  >  > best regards,  >  >
> > Esko  >  >  >  > -----Original Message-----  > From:
> > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On  >
> > Behalf Of Erik Nordmark  > Sent: Friday 15 April 2011 18:39  > To:
> > Pascal Thubert (pthubert)  > Cc: 6lowpan@ietf.org  &= gt; Subject: Re:
> > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in  > ARO]
> > >  > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote:
> >  >
> >  > > RPL can do what all classical IGPs can do WRT hosts. That is as
> > long  > > as the host address belongs to the router's prefix and stays
> > attached  > > to that router.
> >  >
> >  > I just realized that we might be talking about a diffe= rent
> > definition of "host".
> >  > What I mean by "host" is a node which does not participate in a
> > routing  > protocol, and does not forward packets (except packets
> > explicitly addressed  > to itself using e.g., a routing header).
> >  >
> >  > However, RPL has a different definition:
> >  > 'host' refers to an LLN device that can generate but does not
> > forward  > RPL traffic  >  > Basically per the RPL definition there is
> > no such thing as a node which does  > not participate in the RPL
> > protocol.
> >  > IMHO what is in RPL should have been defined as a non-forwarding
> > node, so  > that we can have a sane discussion without getting
> > entangled in terminology  > issues.
> >  >
> >  > Which definition of "host" are you using above?
> >  >
> >  > Per the RPL definition there is no need for 6lowpan-nd, since all
> > nodes will  > speak RPL. This is rather confusing, don't you think?
> >  >
> >  > Erik
> >  >
> >  > > When the topology becomes multilink subnet and mobility is
> > required  > > then it is a new problem entirely, and NO, 4861 is not a
> > suitable  > > interaction with the router to allow the router to
> > redistribute a host route.
> >  > > Because the neighbor cache that 4861 builds is not a of the same
> > > > nature as the binding table that 6LoWPAN ND builds. Another thing
> > that  > > 6LoWPAN ND fails to express correctly. I proposed text to
> > explain that  > > (attached) but it was not considered, contributing
> > to the illusion  > > that a cache is a table.
> >  > >
> >  > > The reality is also that those networks will need to scale to
> > large  > > subnets in plants, building, etc... (see the requirement
> > drafts in  > > ROLL). Registering to all LBRS is total= ly impractical.
> > 6LoWPAN ND  > > requires a coordination between LBRs but does not say
> > how it happens.
> >  > > This problem was discussed in 6LoWPAN; the answer was in
> > ND-01to07;  > > and it requires a TID, for the same reason as RPL.
> > Removing the  > > backbone operation and the TID from the draft is ostrich
> policy.
> >  > >
> >  > > RPL already adapted to the new reality of large multilink subnet
> > with  > > inner mobility. Placing the blame on RPL is another
> > illusionist trick.
> >  > > And this is not RPL last call.
> >  > >
> >  > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all
> > other  > > registrations do when strict ordering is not guaranteed
> > (MIP being an  > > example). Say that due to some config, a node
> > registers a lifetime of  > > X, then deregisters (life= time 0), then
> > reregisters (lifetime X) in a  > > rapid sequence, but does not get an
> > answer yet. Then it finally gets
> > 2
> >  > > AROs back, lifetime X and 0. What's the final state in the router?
> >  > >
> >  > > It seems we can never agree on any of this. I'd like to hear what
> > > > others think.
> >  > >
> >  > > Pascal
> >  > > http://www.xtranormal.com/watch/7011357/
> >  > >
> >  > >
> >  > >> -----Original Message-----
> >  > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpa= n-
> bounces@ietf.org]
> > On  > >> Behalf Of Erik Nordmark  > >> Sent: Friday, April 15, 2011
> > 1:30 AM  > >> To: 6lo>> '6lowpan'
> >  > >> Subject: Re: [6lowpan] Fwd: Re: "Adverti= ze on Behalf" flag in
> > ARO  > >>  > >>  > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert)
> > wrote:
> >  > >>> Hi Erik:
> >  > >>>
> >  > >>> The RPL (DAO) sequence number allows the node to increment
> > rapidly  > >>> in case of rapid changes and then lazily when the
> > situation is  > >>> stable and DAO are scarce. The increase is
> > strictly monotonous which  > >  > >>> is critical to us.
> >  > >>>
> >  > >>> A time stamp imposes a synchronization between the routers. We
> > do  > >>> not have such mechanism in RPL. A time unit (a granularity)
> > must be  > >>> agreed upon. Within that unit, movements go undetected
> > so the time  > >>> unit must be thin grained to cover rapid changes.
> > Yet, depending on  > >>> the medium, the time unit, and the size of
> > the network, it is not  > >>> necessarily easy/p= ossible to guarantee a
> > strictly monotonous value  > >>> with a thin grained time unit. And we
> > have limited space (2
> > octets)
> >  > >>> and have to deal with wrap around, which divides the space by
> > at  > > least 3.
> >  > >>>
> >  > >>> So RPL went for a sequence number.
> >  > >>
> >  > >> But the unstated assumption that RPL made is that all
> > host-to-router  > >> protocols have to now be RPL aware. That doesn't
> > sound like good  > > design.
> >  > >> A host isn't aware of whether the routers speak IS-IS or OSPF,
> > so why  > >> do the hosts need to be aware of RPL by passing some TID
> > around?
> >  > >>
> >  > >>> I think ND has the same need as MIP for a TID =3D=3D Sequence # .
> > We  > >>> know of MIP; We know of RPL. We know of the backbone router
> > > >>> operation. We know we'll need the TID and we know exactly why. I
> > > >>> think we should have it in the 6LowPAN ND spec right away to
> > avoid  > >>> interop issues when we add RPL and BR operations.
> >  > >>
> >  > >> I don't see a need in 6lowpan-nd for a TID; the protocol works
> > fine  > > without it.
> >  > >> I think RPL needs to be improved to deal with reality. Isn't
> > there a  > >> desire for RPL to handle 4861 hosts? Those would never
> > know about a  > > TID.
> >  > >>
> >  > >> Erik
> >  > >>
> >  > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F
> >  > >> 6lowpan mailing list
> >  > >> 6lowpan@ietf.org
> >  > >> https://www.ietf.org/mailman/listinfo/6lowpan=
> >  > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
> >  > > 6lowpan mailing list
> >  > > 6lowpan@ietf.org
> >  > > https://www.ietf.org/mailman/listinfo/6lowpan
> >  > >
> >  >
> >  > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F
> >  > 6lowpan mailing list
> >  > 6lowpan@ietf.org
> >  > https://www.ietf.org/mailman/listinfo/6lowpan
> >  >
> >  > The information contained in this message may be confi= dential and
> > legally  > protected under applicable law. The message is intended
> > solely for the  > addressee(s). If you are not the intend= ed recipient,
> > you are hereby notified  > that any use, forwarding, dissemination, or
> > reproduction of this message is  > strictly prohibited and may be
> > unlawful. If you are not the intended recipient,  > please contact the
> > sender by return e-mail and destroy all copies of the  > original
> > message.
> >
> > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> > 6lowpan mailing list
> > 6lowpan@ietf.org
> > https://www.ietf.org/mailman/listinfo/6lowpan
> >
> >
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> > This email has been scanned by the MessageLabs Email Security System.
> >
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> >





--=_alternative 004FB85FC1257879_=-- From geoff.ietf@mulligan.com Thu Apr 21 08:40:49 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 78759E07DF for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 08:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cO2gytAitRkb for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 08:40:47 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by ietfc.amsl.com (Postfix) with ESMTP id 5EC46E07DD for <6lowpan@ietf.org>; Thu, 21 Apr 2011 08:40:47 -0700 (PDT) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 3C68A1847D; Thu, 21 Apr 2011 09:40:47 -0600 (MDT) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id C13757FD97; Thu, 21 Apr 2011 09:40:44 -0600 (MDT) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> References: <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 21 Apr 2011 09:40:45 -0600 Message-ID: <1303400445.1671.1576.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 15:40:49 -0000 Pascal, We need to close on this discussion. Back in Hiroshima the Working Group decided that Backbone router stuff and "address defense" across backbone routers was not going to be part of ND draft. It appeared that the draft was getting way to complicated and the Working Group decided to simplify things. I have not seen much support on the list for making these changes to include the TID in ND. We need to get this draft completed. If there is a large "unheard from" support group for these changes, please speak up or we shall move forward with the draft as it is. geoff On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote: > Hi Erik > > The TID is not a strong coupling between the H2R and the R2R operations, and it is not a coupling with a RPL version explicitly. > It is an abstract information that if defined properly can be used by many forms or R2R interactions. > As demonstrated by older versions of the ND spec (Backbone Router), RPL, and MIP. > > 6LoWPAN ND cannot scale if the node needs to register to all LBRs. 6LoWPAN ND does not define anymore any LBR interaction. > IOW, 6LoPWAN ND lost the capability to scale when the backbone router piece was removed from the draft. > Which means that it lost its capability to apply in the domains I'm looking at (industrial and metering). > > With the TID, we know that we can restore scalability in the future, and we know how. I do not know of a plan B. > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: Erik Nordmark [mailto:nordmark@acm.org] > > Sent: Thursday, April 21, 2011 1:25 AM > > To: nicolas.riou@schneider-electric.com > > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > ARO] > > > > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > > > > > Dear Pascal and al, > > > > > > I support the idea of reviving the TID in ARO and DAR/DAC. Supporting > > > a TID directly in the node initiating the initial NS appears much > > > simpler than time stamping in the parent router. > > > > How would you make this work if the protocol between the routers is not > > RPLv1, but some future version of RPL or a completely different routing > > protocol? > > > > The decoupling of the host-router interaction from router-router interaction > > has served us well in the history of the Internet. > > > > Erik > > > > > A simple and efficient method to detect mobility of hosts along a > > > backbone of Edge Routers is an important feature to deploy backbones > > > of Edge Routers in Buildings and should be clarified before closing > > > 6LoWPAN WG. > > > > > > Cheers, > > > Nicolas > > > > > > > > > > > > > > > > > > > > > *"Pascal Thubert (pthubert)" * Envoyé par : > > > 6lowpan-bounces@ietf.org > > > > > > 18/04/2011 10:37 > > > > > > > > > A > > > "Dijk, Esko" , "Erik Nordmark" > > > cc > > > 6lowpan@ietf.org > > > Objet > > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > ARO] > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Esko, Erik > > > > > > The discussion on RPL and hosts should happen on the RPL list under a > > > different topic. The point being discussed here is this: > > > > > > The reality is also that those (LLN) networks will need to scale to > > > large subnets in plants, building, etc... (see the requirement drafts > > > in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > > > requires a coordination between LBRs but does not say how it happens. > > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > > > and it requires a TID, for the same reason as RPL. Removing the > > > backbone operation and the TID from the draft is ostrich policy. > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > > > registrations do when strict ordering is not guaranteed (MIP being an > > > example). Say that due to some config, a node registers a lifetime of > > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > > rapid sequence, but does not get an answer yet. Then it finally gets 2 > > > AROs back, lifetime X and 0. What's the final state in the router? > > > > > > I'd like to hear what others think. > > > > > > Pascal > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > -----Original Message----- > > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Monday, > > > April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal Thubert > > > (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: TID > > > in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello Erik, > > > > > taking the definition you quoted: > > > > 'host' refers to an LLN device that can generate but does not > > > forward > RPL traffic > > the question may arise what is "RPL > > > traffic"? It is not defined in the RPL draft > it seems. Pascal > > > clarified to me it is traffic associated to a RPL instance, not > > > > necessarily RPL protocol messages. This means that a host could > > > generate > RPL traffic without being aware of the existence of RPL at > > > all. So, _not_ all > hosts have to speak RPL? > > > > The RPL draft does not explicitly state if "hosts" in a RPL network > > > always > speak RPL, never speak RPL, or can be mixed RPL/non-RPL > > > speakers. > > > > > > > > Taking the definition of 'node' in the RPL draft: > > > > 'node' refers to any RPL device, either a host or a router > > > > > rules out (?) the option that all "hosts" are non-RPL speakers, since > > > there > may be a "RPL device" (i.e. RPL-speaking device, I assume) > > > that is also a host. > > > > > > > > I communicated these perceived unclarities to Pascal and the RFC > > > editor 2 > weeks ago. Once this is clear I think the present > > > discussion can continue. > > > > And then there is the related discussion of ND support for sleepy > > > devices, > the original topic of Anders ;) > > best regards, > > > > > Esko > > > > -----Original Message----- > From: > > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: > > > Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: > > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > > > > > RPL can do what all classical IGPs can do WRT hosts. That is as > > > long > > as the host address belongs to the router's prefix and stays > > > attached > > to that router. > > > > > > > > I just realized that we might be talking about a different > > > definition of "host". > > > > What I mean by "host" is a node which does not participate in a > > > routing > protocol, and does not forward packets (except packets > > > explicitly addressed > to itself using e.g., a routing header). > > > > > > > > However, RPL has a different definition: > > > > 'host' refers to an LLN device that can generate but does not > > > forward > RPL traffic > > Basically per the RPL definition there is > > > no such thing as a node which does > not participate in the RPL > > > protocol. > > > > IMHO what is in RPL should have been defined as a non-forwarding > > > node, so > that we can have a sane discussion without getting > > > entangled in terminology > issues. > > > > > > > > Which definition of "host" are you using above? > > > > > > > > Per the RPL definition there is no need for 6lowpan-nd, since all > > > nodes will > speak RPL. This is rather confusing, don't you think? > > > > > > > > Erik > > > > > > > > > When the topology becomes multilink subnet and mobility is > > > required > > then it is a new problem entirely, and NO, 4861 is not a > > > suitable > > interaction with the router to allow the router to > > > redistribute a host route. > > > > > Because the neighbor cache that 4861 builds is not a of the same > > > > > nature as the binding table that 6LoWPAN ND builds. Another thing > > > that > > 6LoWPAN ND fails to express correctly. I proposed text to > > > explain that > > (attached) but it was not considered, contributing > > > to the illusion > > that a cache is a table. > > > > > > > > > > The reality is also that those networks will need to scale to > > > large > > subnets in plants, building, etc... (see the requirement > > > drafts in > > ROLL). Registering to all LBRS is totally impractical. > > > 6LoWPAN ND > > requires a coordination between LBRs but does not say > > > how it happens. > > > > > This problem was discussed in 6LoWPAN; the answer was in > > > ND-01to07; > > and it requires a TID, for the same reason as RPL. > > > Removing the > > backbone operation and the TID from the draft is ostrich > > policy. > > > > > > > > > > RPL already adapted to the new reality of large multilink subnet > > > with > > inner mobility. Placing the blame on RPL is another > > > illusionist trick. > > > > > And this is not RPL last call. > > > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > > > other > > registrations do when strict ordering is not guaranteed > > > (MIP being an > > example). Say that due to some config, a node > > > registers a lifetime of > > X, then deregisters (lifetime 0), then > > > reregisters (lifetime X) in a > > rapid sequence, but does not get an > > > answer yet. Then it finally gets > > > 2 > > > > > AROs back, lifetime X and 0. What's the final state in the router? > > > > > > > > > > It seems we can never agree on any of this. I'd like to hear what > > > > > others think. > > > > > > > > > > Pascal > > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- > > bounces@ietf.org] > > > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, 2011 > > > 1:30 AM > >> To: 6lo>> '6lowpan' > > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in > > > ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) > > > wrote: > > > > >>> Hi Erik: > > > > >>> > > > > >>> The RPL (DAO) sequence number allows the node to increment > > > rapidly > >>> in case of rapid changes and then lazily when the > > > situation is > >>> stable and DAO are scarce. The increase is > > > strictly monotonous which > > > >>> is critical to us. > > > > >>> > > > > >>> A time stamp imposes a synchronization between the routers. We > > > do > >>> not have such mechanism in RPL. A time unit (a granularity) > > > must be > >>> agreed upon. Within that unit, movements go undetected > > > so the time > >>> unit must be thin grained to cover rapid changes. > > > Yet, depending on > >>> the medium, the time unit, and the size of > > > the network, it is not > >>> necessarily easy/possible to guarantee a > > > strictly monotonous value > >>> with a thin grained time unit. And we > > > have limited space (2 > > > octets) > > > > >>> and have to deal with wrap around, which divides the space by > > > at > > least 3. > > > > >>> > > > > >>> So RPL went for a sequence number. > > > > >> > > > > >> But the unstated assumption that RPL made is that all > > > host-to-router > >> protocols have to now be RPL aware. That doesn't > > > sound like good > > design. > > > > >> A host isn't aware of whether the routers speak IS-IS or OSPF, > > > so why > >> do the hosts need to be aware of RPL by passing some TID > > > around? > > > > >> > > > > >>> I think ND has the same need as MIP for a TID == Sequence # . > > > We > >>> know of MIP; We know of RPL. We know of the backbone router > > > > >>> operation. We know we'll need the TID and we know exactly why. I > > > > >>> think we should have it in the 6LowPAN ND spec right away to > > > avoid > >>> interop issues when we add RPL and BR operations. > > > > >> > > > > >> I don't see a need in 6lowpan-nd for a TID; the protocol works > > > fine > > without it. > > > > >> I think RPL needs to be improved to deal with reality. Isn't > > > there a > >> desire for RPL to handle 4861 hosts? Those would never > > > know about a > > TID. > > > > >> > > > > >> Erik > > > > >> > > > > >> _______________________________________________ > > > > >> 6lowpan mailing list > > > > >> 6lowpan@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > > _______________________________________________ > > > > > 6lowpan mailing list > > > > > 6lowpan@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > _______________________________________________ > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > The information contained in this message may be confidential and > > > legally > protected under applicable law. The message is intended > > > solely for the > addressee(s). If you are not the intended recipient, > > > you are hereby notified > that any use, forwarding, dissemination, or > > > reproduction of this message is > strictly prohibited and may be > > > unlawful. If you are not the intended recipient, > please contact the > > > sender by return e-mail and destroy all copies of the > original > > > message. > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > __________________________________________________________ > > ____________ > > > This email has been scanned by the MessageLabs Email Security System. > > > > > __________________________________________________________ > > ____________ > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Thu Apr 21 12:32:17 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2CD61E07E2 for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 12:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.852 X-Spam-Level: X-Spam-Status: No, score=-8.852 tagged_above=-999 required=5 tests=[AWL=1.747, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aRwygvDIz1v for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 12:32:15 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 22DF9E07E0 for <6lowpan@ietf.org>; Thu, 21 Apr 2011 12:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=21816; q=dns/txt; s=iport; t=1303414334; x=1304623934; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=3Nvlc1rKGRRu7QAH0LV3EYiAK9IR4HXPSQeDBbFRmsc=; b=ivV1mcK2NahTQCbRmhCPlBPhqQxfbmh4XuTIsr28BpxXRvfLGIJ23Hzj OFseOf9aTX5wr7Gu+3nysCJV5piGqOK6Kq6DySaU0ITy8+qAoJxhZAqAj urkFEizFrx/hqYQ0cglHUBT5s6y6xHuseoIHSAUCZwTFnBV90sVTcRYPa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUBAJaFsE2Q/khRgWdsb2JhbACET5J8jH+BChQBARYmJadui1yQfIEpg1B9BJI3 X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="26664276" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 21 Apr 2011 19:32:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3LJWCBg004642; Thu, 21 Apr 2011 19:32:12 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 21:32:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 21 Apr 2011 21:32:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> In-Reply-To: <1303400445.1671.1576.camel@d430> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: AcwAOoD4MkFgJKs+QLCNA6lxgM/QhAAH2bNA References: <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" X-OriginalArrivalTime: 21 Apr 2011 19:32:12.0607 (UTC) FILETIME=[D02564F0:01CC005A] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 19:32:17 -0000 R2VvZmY6DQoNClRoZXJlIGlzIHR3aWNlIGFzIG11Y2ggc3VwcG9ydCBmb3IgcmVzdG9yaW5nIHRo ZSBUSUQgdGhhbiB0aGVyZSBpcyBmb3IgIG5vdCBkb2luZyBpdC4NCkJlZm9yZSB3ZSBkcm9wIHRo ZSBUSUQsIEknZCBsaWtlIHRvIHNlZSBhIHByb3Bvc2FsIHRoYXQgYWxsb3dzIGEgNkxvV1BBTiBO RCBzdWJuZXQgdG8gc2NhbGUgd2l0aCBtdWx0aXBsZSBMQlJzLCBhbGxvd3Mgbm9kZXMgdG8gbW92 ZSBmcm9tIGEgcm91dGVyIHRvIHRoZSBuZXh0LCBhbmQgdGhhdCBkb2VzIG5vdCBuZWVkIGEgVElE Lg0KT3RoZXJ3aXNlLCB3ZSBhcmUgbm90IHNwZWVkaW5nIHRvd2FyZHMgdGhlIHdhbGwsIHdlJ3Jl IGFscmVhZHkgY3Jhc2hpbmcuDQoNClBhc2NhbA0KaHR0cDovL3d3dy54dHJhbm9ybWFsLmNvbS93 YXRjaC83MDExMzU3Lw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdl b2ZmIE11bGxpZ2FuIFttYWlsdG86Z2VvZmYuaWV0ZkBtdWxsaWdhbi5jb21dDQo+IFNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAyMSwgMjAxMSA1OjQxIFBNDQo+IFRvOiBQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpDQo+IENjOiBFcmlrIE5vcmRtYXJrOyBuaWNvbGFzLnJpb3VAc2NobmVpZGVyLWVsZWN0 cmljLmNvbTsgNmxvd3BhbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogWzZsb3dwYW5dIEZXOiBU SUQgaW4gQVJPIFt3YXM6ICJBZHZlcnRpemUgb24gQmVoYWxmIiBmbGFnIGluDQo+IEFST10NCj4g DQo+IFBhc2NhbCwNCj4gICBXZSBuZWVkIHRvIGNsb3NlIG9uIHRoaXMgZGlzY3Vzc2lvbi4NCj4g DQo+IEJhY2sgaW4gSGlyb3NoaW1hIHRoZSBXb3JraW5nIEdyb3VwIGRlY2lkZWQgdGhhdCBCYWNr Ym9uZSByb3V0ZXIgc3R1ZmYgYW5kDQo+ICJhZGRyZXNzIGRlZmVuc2UiIGFjcm9zcyBiYWNrYm9u ZSByb3V0ZXJzIHdhcyBub3QgZ29pbmcgdG8gYmUgcGFydCBvZiBORA0KPiBkcmFmdC4gIEl0IGFw cGVhcmVkIHRoYXQgdGhlIGRyYWZ0IHdhcyBnZXR0aW5nIHdheSB0byBjb21wbGljYXRlZCBhbmQg dGhlDQo+IFdvcmtpbmcgR3JvdXAgZGVjaWRlZCB0byBzaW1wbGlmeSB0aGluZ3MuDQo+IA0KPiBJ IGhhdmUgbm90IHNlZW4gbXVjaCBzdXBwb3J0IG9uIHRoZSBsaXN0IGZvciBtYWtpbmcgdGhlc2Ug Y2hhbmdlcyB0byBpbmNsdWRlDQo+IHRoZSBUSUQgaW4gTkQuDQo+IA0KPiBXZSBuZWVkIHRvIGdl dCB0aGlzIGRyYWZ0IGNvbXBsZXRlZC4gIElmIHRoZXJlIGlzIGEgbGFyZ2UgInVuaGVhcmQgZnJv bSINCj4gc3VwcG9ydCBncm91cCBmb3IgdGhlc2UgY2hhbmdlcywgcGxlYXNlIHNwZWFrIHVwIG9y IHdlIHNoYWxsIG1vdmUgZm9yd2FyZA0KPiB3aXRoIHRoZSBkcmFmdCBhcyBpdCBpcy4NCj4gDQo+ IAlnZW9mZg0KPiANCj4gDQo+IA0KPiANCj4gT24gVGh1LCAyMDExLTA0LTIxIGF0IDA5OjI3ICsw MjAwLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+IEhpIEVyaWsNCj4gPg0K PiA+IFRoZSBUSUQgaXMgbm90IGEgc3Ryb25nIGNvdXBsaW5nIGJldHdlZW4gdGhlIEgyUiBhbmQg dGhlIFIyUiBvcGVyYXRpb25zLA0KPiBhbmQgaXQgaXMgbm90IGEgY291cGxpbmcgd2l0aCBhIFJQ TCB2ZXJzaW9uICBleHBsaWNpdGx5Lg0KPiA+IEl0IGlzIGFuIGFic3RyYWN0IGluZm9ybWF0aW9u IHRoYXQgaWYgZGVmaW5lZCBwcm9wZXJseSBjYW4gYmUgdXNlZCBieSBtYW55DQo+IGZvcm1zIG9y IFIyUiBpbnRlcmFjdGlvbnMuDQo+ID4gQXMgZGVtb25zdHJhdGVkIGJ5IG9sZGVyIHZlcnNpb25z IG9mIHRoZSBORCBzcGVjIChCYWNrYm9uZSBSb3V0ZXIpLCBSUEwsDQo+IGFuZCBNSVAuDQo+ID4N Cj4gPiA2TG9XUEFOIE5EIGNhbm5vdCBzY2FsZSBpZiB0aGUgbm9kZSBuZWVkcyB0byByZWdpc3Rl ciB0byBhbGwgTEJScy4NCj4gNkxvV1BBTiBORCBkb2VzIG5vdCBkZWZpbmUgYW55bW9yZSBhbnkg TEJSIGludGVyYWN0aW9uLg0KPiA+IElPVywgNkxvUFdBTiBORCBsb3N0IHRoZSBjYXBhYmlsaXR5 IHRvIHNjYWxlIHdoZW4gdGhlIGJhY2tib25lIHJvdXRlcg0KPiBwaWVjZSB3YXMgcmVtb3ZlZCBm cm9tIHRoZSBkcmFmdC4NCj4gPiBXaGljaCBtZWFucyB0aGF0IGl0IGxvc3QgaXRzIGNhcGFiaWxp dHkgdG8gYXBwbHkgaW4gdGhlIGRvbWFpbnMgSSdtIGxvb2tpbmcgYXQNCj4gKGluZHVzdHJpYWwg YW5kIG1ldGVyaW5nKS4NCj4gPg0KPiA+IFdpdGggdGhlIFRJRCwgd2Uga25vdyB0aGF0IHdlIGNh biByZXN0b3JlIHNjYWxhYmlsaXR5IGluIHRoZSBmdXR1cmUsIGFuZCB3ZQ0KPiBrbm93IGhvdy4g SSBkbyBub3Qga25vdyBvZiBhIHBsYW4gQi4NCj4gPg0KPiA+IFBhc2NhbA0KPiA+IGh0dHA6Ly93 d3cueHRyYW5vcm1hbC5jb20vd2F0Y2gvNzAxMTM1Ny8NCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogRXJpayBOb3JkbWFyayBbbWFpbHRvOm5v cmRtYXJrQGFjbS5vcmddDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjEsIDIwMTEgMToy NSBBTQ0KPiA+ID4gVG86IG5pY29sYXMucmlvdUBzY2huZWlkZXItZWxlY3RyaWMuY29tDQo+ID4g PiBDYzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgNmxvd3BhbkBpZXRmLm9yZzsgRGlqaywg RXNrbw0KPiA+ID4gU3ViamVjdDogUmU6IFs2bG93cGFuXSBGVzogVElEIGluIEFSTyBbd2FzOiAi QWR2ZXJ0aXplIG9uIEJlaGFsZiINCj4gPiA+IGZsYWcgaW4gQVJPXQ0KPiA+ID4NCj4gPiA+IE9u IDQvMjAvMTEgMToyMSBBTSwgbmljb2xhcy5yaW91QHNjaG5laWRlci1lbGVjdHJpYy5jb20gd3Jv dGU6DQo+ID4gPiA+DQo+ID4gPiA+IERlYXIgUGFzY2FsIGFuZCBhbCwNCj4gPiA+ID4NCj4gPiA+ ID4gSSBzdXBwb3J0IHRoZSBpZGVhIG9mIHJldml2aW5nIHRoZSBUSUQgaW4gQVJPIGFuZCBEQVIv REFDLg0KPiA+ID4gPiBTdXBwb3J0aW5nIGEgVElEIGRpcmVjdGx5IGluIHRoZSBub2RlIGluaXRp YXRpbmcgdGhlIGluaXRpYWwgTlMNCj4gPiA+ID4gYXBwZWFycyBtdWNoIHNpbXBsZXIgdGhhbiB0 aW1lIHN0YW1waW5nIGluIHRoZSBwYXJlbnQgcm91dGVyLg0KPiA+ID4NCj4gPiA+IEhvdyB3b3Vs ZCB5b3UgbWFrZSB0aGlzIHdvcmsgaWYgdGhlIHByb3RvY29sIGJldHdlZW4gdGhlIHJvdXRlcnMg aXMNCj4gPiA+IG5vdCBSUEx2MSwgYnV0IHNvbWUgZnV0dXJlIHZlcnNpb24gb2YgUlBMIG9yIGEg Y29tcGxldGVseSBkaWZmZXJlbnQNCj4gPiA+IHJvdXRpbmcgcHJvdG9jb2w/DQo+ID4gPg0KPiA+ ID4gVGhlIGRlY291cGxpbmcgb2YgdGhlIGhvc3Qtcm91dGVyIGludGVyYWN0aW9uIGZyb20gcm91 dGVyLXJvdXRlcg0KPiA+ID4gaW50ZXJhY3Rpb24gaGFzIHNlcnZlZCB1cyB3ZWxsIGluIHRoZSBo aXN0b3J5IG9mIHRoZSBJbnRlcm5ldC4NCj4gPiA+DQo+ID4gPiAgICAgICBFcmlrDQo+ID4gPg0K PiA+ID4gPiBBIHNpbXBsZSBhbmQgZWZmaWNpZW50IG1ldGhvZCB0byBkZXRlY3QgbW9iaWxpdHkg b2YgaG9zdHMgYWxvbmcgYQ0KPiA+ID4gPiBiYWNrYm9uZSBvZiBFZGdlIFJvdXRlcnMgaXMgYW4g aW1wb3J0YW50IGZlYXR1cmUgdG8gZGVwbG95DQo+ID4gPiA+IGJhY2tib25lcyBvZiBFZGdlIFJv dXRlcnMgaW4gQnVpbGRpbmdzIGFuZCBzaG91bGQgYmUgY2xhcmlmaWVkDQo+ID4gPiA+IGJlZm9y ZSBjbG9zaW5nIDZMb1dQQU4gV0cuDQo+ID4gPiA+DQo+ID4gPiA+IENoZWVycywNCj4gPiA+ID4g Tmljb2xhcw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPiAqIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNj by5jb20+KiBFbnZvecOpIHBhciA6DQo+ID4gPiA+IDZsb3dwYW4tYm91bmNlc0BpZXRmLm9yZw0K PiA+ID4gPg0KPiA+ID4gPiAxOC8wNC8yMDExIDEwOjM3DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4g PiA+IEENCj4gPiA+ID4gCSJEaWprLCBFc2tvIiA8ZXNrby5kaWprQHBoaWxpcHMuY29tPiwgIkVy aWsgTm9yZG1hcmsiDQo+ID4gPiA+IDxub3JkbWFya0BhY20ub3JnPiBjYw0KPiA+ID4gPiAJNmxv d3BhbkBpZXRmLm9yZw0KPiA+ID4gPiBPYmpldA0KPiA+ID4gPiAJUmU6IFs2bG93cGFuXSBGVzog VElEIGluIEFSTyBbd2FzOiAiQWR2ZXJ0aXplIG9uIEJlaGFsZiIgZmxhZyBpbg0KPiA+ID4gQVJP XQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBIaSBFc2tvLCBFcmlrDQo+ID4gPiA+DQo+ID4gPiA+ IFRoZSBkaXNjdXNzaW9uIG9uIFJQTCBhbmQgaG9zdHMgc2hvdWxkIGhhcHBlbiBvbiB0aGUgUlBM IGxpc3QNCj4gPiA+ID4gdW5kZXIgYSBkaWZmZXJlbnQgdG9waWMuIFRoZSBwb2ludCBiZWluZyBk aXNjdXNzZWQgaGVyZSBpcyB0aGlzOg0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgcmVhbGl0eSBpcyBh bHNvIHRoYXQgdGhvc2UgKExMTikgbmV0d29ya3Mgd2lsbCBuZWVkIHRvIHNjYWxlDQo+ID4gPiA+ IHRvIGxhcmdlIHN1Ym5ldHMgaW4gcGxhbnRzLCBidWlsZGluZywgZXRjLi4uIChzZWUgdGhlIHJl cXVpcmVtZW50DQo+ID4gPiA+IGRyYWZ0cyBpbiBST0xMKS4gUmVnaXN0ZXJpbmcgdG8gYWxsIExC UlMgaXMgdG90YWxseSBpbXByYWN0aWNhbC4NCj4gPiA+ID4gNkxvV1BBTiBORCByZXF1aXJlcyBh IGNvb3JkaW5hdGlvbiBiZXR3ZWVuIExCUnMgYnV0IGRvZXMgbm90IHNheQ0KPiBob3cgaXQgaGFw cGVucy4NCj4gPiA+ID4gVGhpcyBwcm9ibGVtIHdhcyBkaXNjdXNzZWQgaW4gNkxvV1BBTjsgdGhl IGFuc3dlciB3YXMgaW4NCj4gPiA+ID4gTkQtMDF0bzA3OyBhbmQgaXQgcmVxdWlyZXMgYSBUSUQs IGZvciB0aGUgc2FtZSByZWFzb24gYXMgUlBMLg0KPiA+ID4gPiBSZW1vdmluZyB0aGUgYmFja2Jv bmUgb3BlcmF0aW9uIGFuZCB0aGUgVElEIGZyb20gdGhlIGRyYWZ0IGlzIG9zdHJpY2gNCj4gcG9s aWN5Lg0KPiA+ID4gPg0KPiA+ID4gPiBCVFcgNkxvV1BBTiBORCBuZWVkcyBhIFRJRCB0byBjb3Jy ZWxhdGUgdGhlIE5TIGFuZCB0aGUgTkEgYXMgYWxsDQo+ID4gPiA+IG90aGVyIHJlZ2lzdHJhdGlv bnMgZG8gd2hlbiBzdHJpY3Qgb3JkZXJpbmcgaXMgbm90IGd1YXJhbnRlZWQgKE1JUA0KPiA+ID4g PiBiZWluZyBhbiBleGFtcGxlKS4gU2F5IHRoYXQgZHVlIHRvIHNvbWUgY29uZmlnLCBhIG5vZGUg cmVnaXN0ZXJzIGENCj4gPiA+ID4gbGlmZXRpbWUgb2YgWCwgdGhlbiBkZXJlZ2lzdGVycyAobGlm ZXRpbWUgMCksIHRoZW4gcmVyZWdpc3RlcnMNCj4gPiA+ID4gKGxpZmV0aW1lIFgpIGluIGEgcmFw aWQgc2VxdWVuY2UsIGJ1dCBkb2VzIG5vdCBnZXQgYW4gYW5zd2VyIHlldC4NCj4gPiA+ID4gVGhl biBpdCBmaW5hbGx5IGdldHMgMiBBUk9zIGJhY2ssIGxpZmV0aW1lIFggYW5kIDAuIFdoYXQncyB0 aGUgZmluYWwgc3RhdGUNCj4gaW4gdGhlIHJvdXRlcj8NCj4gPiA+ID4NCj4gPiA+ID4gSSdkIGxp a2UgdG8gaGVhciB3aGF0IG90aGVycyB0aGluay4NCj4gPiA+ID4NCj4gPiA+ID4gUGFzY2FsDQo+ ID4gPiA+IGh0dHA6Ly93d3cueHRyYW5vcm1hbC5jb20vd2F0Y2gvNzAxMTM1Ny8NCj4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g ID4gRnJvbTogRGlqaywgRXNrbyBbbWFpbHRvOmVza28uZGlqa0BwaGlsaXBzLmNvbV0gID4gU2Vu dDoNCj4gPiA+ID4gTW9uZGF5LCBBcHJpbCAxOCwgMjAxMSAxMDoxOSBBTSAgPiBUbzogRXJpayBO b3JkbWFyazsgUGFzY2FsDQo+ID4gPiA+IFRodWJlcnQNCj4gPiA+ID4gKHB0aHViZXJ0KSAgPiBD YzogNmxvd3BhbkBpZXRmLm9yZyAgPiBTdWJqZWN0OiBSRTogWzZsb3dwYW5dIEZXOg0KPiA+ID4g PiBUSUQgaW4gQVJPIFt3YXM6ICJBZHZlcnRpemUgb24gQmVoYWxmIiBmbGFnIGluICA+IEFST10g ID4gID4gSGVsbG8NCj4gPiA+ID4gRXJpaywNCj4gPiA+ID4gPiAgPiB0YWtpbmcgdGhlIGRlZmlu aXRpb24geW91IHF1b3RlZDoNCj4gPiA+ID4gID4gJ2hvc3QnIHJlZmVycyB0byBhbiBMTE4gZGV2 aWNlIHRoYXQgY2FuIGdlbmVyYXRlIGJ1dCBkb2VzIG5vdA0KPiA+ID4gPiBmb3J3YXJkICA+IFJQ TCB0cmFmZmljICA+ICA+IHRoZSBxdWVzdGlvbiBtYXkgYXJpc2Ugd2hhdCBpcyAiUlBMDQo+ID4g PiA+IHRyYWZmaWMiPyBJdCBpcyBub3QgZGVmaW5lZCBpbiB0aGUgUlBMIGRyYWZ0ICA+IGl0IHNl ZW1zLiBQYXNjYWwNCj4gPiA+ID4gY2xhcmlmaWVkIHRvIG1lIGl0IGlzIHRyYWZmaWMgYXNzb2Np YXRlZCB0byBhIFJQTCBpbnN0YW5jZSwgbm90ICA+DQo+ID4gPiA+IG5lY2Vzc2FyaWx5IFJQTCBw cm90b2NvbCBtZXNzYWdlcy4gVGhpcyBtZWFucyB0aGF0IGEgaG9zdCBjb3VsZA0KPiA+ID4gPiBn ZW5lcmF0ZSAgPiBSUEwgdHJhZmZpYyB3aXRob3V0IGJlaW5nIGF3YXJlIG9mIHRoZSBleGlzdGVu Y2Ugb2YNCj4gPiA+ID4gUlBMIGF0IGFsbC4gU28sIF9ub3RfIGFsbCAgPiBob3N0cyBoYXZlIHRv IHNwZWFrIFJQTD8NCj4gPiA+ID4gID4gVGhlIFJQTCBkcmFmdCBkb2VzIG5vdCBleHBsaWNpdGx5 IHN0YXRlIGlmICJob3N0cyIgaW4gYSBSUEwNCj4gPiA+ID4gbmV0d29yayBhbHdheXMgID4gc3Bl YWsgUlBMLCBuZXZlciBzcGVhayBSUEwsIG9yIGNhbiBiZSBtaXhlZA0KPiA+ID4gPiBSUEwvbm9u LVJQTCBzcGVha2Vycy4NCj4gPiA+ID4gID4NCj4gPiA+ID4gID4gVGFraW5nIHRoZSBkZWZpbml0 aW9uIG9mICdub2RlJyBpbiB0aGUgUlBMIGRyYWZ0Og0KPiA+ID4gPiAgPiAnbm9kZScgcmVmZXJz IHRvIGFueSBSUEwgZGV2aWNlLCBlaXRoZXIgYSBob3N0IG9yIGEgcm91dGVyICA+DQo+ID4gPiA+ ID4gcnVsZXMgb3V0ICg/KSB0aGUgb3B0aW9uIHRoYXQgYWxsICJob3N0cyIgYXJlIG5vbi1SUEwg c3BlYWtlcnMsDQo+ID4gPiA+IHNpbmNlIHRoZXJlICA+IG1heSBiZSBhICJSUEwgZGV2aWNlIiAo aS5lLiBSUEwtc3BlYWtpbmcgZGV2aWNlLCBJDQo+ID4gPiA+IGFzc3VtZSkgdGhhdCBpcyBhbHNv IGEgaG9zdC4NCj4gPiA+ID4gID4NCj4gPiA+ID4gID4gSSBjb21tdW5pY2F0ZWQgdGhlc2UgcGVy Y2VpdmVkIHVuY2xhcml0aWVzIHRvIFBhc2NhbCBhbmQgdGhlDQo+ID4gPiA+IFJGQyBlZGl0b3Ig MiAgPiB3ZWVrcyBhZ28uIE9uY2UgdGhpcyBpcyBjbGVhciBJIHRoaW5rIHRoZSBwcmVzZW50DQo+ ID4gPiA+IGRpc2N1c3Npb24gY2FuIGNvbnRpbnVlLg0KPiA+ID4gPiAgPiBBbmQgdGhlbiB0aGVy ZSBpcyB0aGUgcmVsYXRlZCBkaXNjdXNzaW9uIG9mIE5EIHN1cHBvcnQgZm9yDQo+ID4gPiA+IHNs ZWVweSBkZXZpY2VzLCAgPiB0aGUgb3JpZ2luYWwgdG9waWMgb2YgQW5kZXJzIDspICA+ICA+IGJl c3QNCj4gPiA+ID4gcmVnYXJkcywgID4gID4gRXNrbyAgPiAgPiAgPiAgPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLSAgPiBGcm9tOg0KPiA+ID4gPiA2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzo2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uICA+DQo+ID4gPiA+IEJlaGFsZiBP ZiBFcmlrIE5vcmRtYXJrICA+IFNlbnQ6IEZyaWRheSAxNSBBcHJpbCAyMDExIDE4OjM5ICA+IFRv Og0KPiA+ID4gPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICA+IENjOiA2bG93cGFuQGlldGYu b3JnICA+IFN1YmplY3Q6IFJlOg0KPiA+ID4gPiBbNmxvd3Bhbl0gRlc6IFRJRCBpbiBBUk8gW3dh czogIkFkdmVydGl6ZSBvbiBCZWhhbGYiIGZsYWcgaW4gID4NCj4gPiA+ID4gQVJPXQ0KPiA+ID4g PiA+ICA+IE9uIDQvMTQvMTEgMTE6NDMgUE0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3Jv dGU6DQo+ID4gPiA+ICA+DQo+ID4gPiA+ICA+ID4gUlBMIGNhbiBkbyB3aGF0IGFsbCBjbGFzc2lj YWwgSUdQcyBjYW4gZG8gV1JUIGhvc3RzLiBUaGF0IGlzDQo+ID4gPiA+IGFzIGxvbmcgID4gPiBh cyB0aGUgaG9zdCBhZGRyZXNzIGJlbG9uZ3MgdG8gdGhlIHJvdXRlcidzIHByZWZpeA0KPiA+ID4g PiBhbmQgc3RheXMgYXR0YWNoZWQgID4gPiB0byB0aGF0IHJvdXRlci4NCj4gPiA+ID4gID4NCj4g PiA+ID4gID4gSSBqdXN0IHJlYWxpemVkIHRoYXQgd2UgbWlnaHQgYmUgdGFsa2luZyBhYm91dCBh IGRpZmZlcmVudA0KPiA+ID4gPiBkZWZpbml0aW9uIG9mICJob3N0Ii4NCj4gPiA+ID4gID4gV2hh dCBJIG1lYW4gYnkgImhvc3QiIGlzIGEgbm9kZSB3aGljaCBkb2VzIG5vdCBwYXJ0aWNpcGF0ZSBp biBhDQo+ID4gPiA+IHJvdXRpbmcgID4gcHJvdG9jb2wsIGFuZCBkb2VzIG5vdCBmb3J3YXJkIHBh Y2tldHMgKGV4Y2VwdCBwYWNrZXRzDQo+ID4gPiA+IGV4cGxpY2l0bHkgYWRkcmVzc2VkICA+IHRv IGl0c2VsZiB1c2luZyBlLmcuLCBhIHJvdXRpbmcgaGVhZGVyKS4NCj4gPiA+ID4gID4NCj4gPiA+ ID4gID4gSG93ZXZlciwgUlBMIGhhcyBhIGRpZmZlcmVudCBkZWZpbml0aW9uOg0KPiA+ID4gPiAg PiAnaG9zdCcgcmVmZXJzIHRvIGFuIExMTiBkZXZpY2UgdGhhdCBjYW4gZ2VuZXJhdGUgYnV0IGRv ZXMgbm90DQo+ID4gPiA+IGZvcndhcmQgID4gUlBMIHRyYWZmaWMgID4gID4gQmFzaWNhbGx5IHBl ciB0aGUgUlBMIGRlZmluaXRpb24NCj4gPiA+ID4gdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBh IG5vZGUgd2hpY2ggZG9lcyAgPiBub3QgcGFydGljaXBhdGUgaW4NCj4gPiA+ID4gdGhlIFJQTCBw cm90b2NvbC4NCj4gPiA+ID4gID4gSU1ITyB3aGF0IGlzIGluIFJQTCBzaG91bGQgaGF2ZSBiZWVu IGRlZmluZWQgYXMgYQ0KPiA+ID4gPiBub24tZm9yd2FyZGluZyBub2RlLCBzbyAgPiB0aGF0IHdl IGNhbiBoYXZlIGEgc2FuZSBkaXNjdXNzaW9uDQo+ID4gPiA+IHdpdGhvdXQgZ2V0dGluZyBlbnRh bmdsZWQgaW4gdGVybWlub2xvZ3kgID4gaXNzdWVzLg0KPiA+ID4gPiAgPg0KPiA+ID4gPiAgPiBX aGljaCBkZWZpbml0aW9uIG9mICJob3N0IiBhcmUgeW91IHVzaW5nIGFib3ZlPw0KPiA+ID4gPiAg Pg0KPiA+ID4gPiAgPiBQZXIgdGhlIFJQTCBkZWZpbml0aW9uIHRoZXJlIGlzIG5vIG5lZWQgZm9y IDZsb3dwYW4tbmQsIHNpbmNlDQo+ID4gPiA+IGFsbCBub2RlcyB3aWxsICA+IHNwZWFrIFJQTC4g VGhpcyBpcyByYXRoZXIgY29uZnVzaW5nLCBkb24ndCB5b3UgdGhpbms/DQo+ID4gPiA+ICA+DQo+ ID4gPiA+ICA+IEVyaWsNCj4gPiA+ID4gID4NCj4gPiA+ID4gID4gPiBXaGVuIHRoZSB0b3BvbG9n eSBiZWNvbWVzIG11bHRpbGluayBzdWJuZXQgYW5kIG1vYmlsaXR5IGlzDQo+ID4gPiA+IHJlcXVp cmVkICA+ID4gdGhlbiBpdCBpcyBhIG5ldyBwcm9ibGVtIGVudGlyZWx5LCBhbmQgTk8sIDQ4NjEg aXMNCj4gPiA+ID4gbm90IGEgc3VpdGFibGUgID4gPiBpbnRlcmFjdGlvbiB3aXRoIHRoZSByb3V0 ZXIgdG8gYWxsb3cgdGhlDQo+ID4gPiA+IHJvdXRlciB0byByZWRpc3RyaWJ1dGUgYSBob3N0IHJv dXRlLg0KPiA+ID4gPiAgPiA+IEJlY2F1c2UgdGhlIG5laWdoYm9yIGNhY2hlIHRoYXQgNDg2MSBi dWlsZHMgaXMgbm90IGEgb2YgdGhlDQo+ID4gPiA+IHNhbWUNCj4gPiA+ID4gPiA+IG5hdHVyZSBh cyB0aGUgYmluZGluZyB0YWJsZSB0aGF0IDZMb1dQQU4gTkQgYnVpbGRzLiBBbm90aGVyDQo+ID4g PiA+ID4gPiB0aGluZw0KPiA+ID4gPiB0aGF0ICA+ID4gNkxvV1BBTiBORCBmYWlscyB0byBleHBy ZXNzIGNvcnJlY3RseS4gSSBwcm9wb3NlZCB0ZXh0DQo+ID4gPiA+IHRvIGV4cGxhaW4gdGhhdCAg PiA+IChhdHRhY2hlZCkgYnV0IGl0IHdhcyBub3QgY29uc2lkZXJlZCwNCj4gPiA+ID4gY29udHJp YnV0aW5nIHRvIHRoZSBpbGx1c2lvbiAgPiA+IHRoYXQgYSBjYWNoZSBpcyBhIHRhYmxlLg0KPiA+ ID4gPiAgPiA+DQo+ID4gPiA+ICA+ID4gVGhlIHJlYWxpdHkgaXMgYWxzbyB0aGF0IHRob3NlIG5l dHdvcmtzIHdpbGwgbmVlZCB0byBzY2FsZSB0bw0KPiA+ID4gPiBsYXJnZSAgPiA+IHN1Ym5ldHMg aW4gcGxhbnRzLCBidWlsZGluZywgZXRjLi4uIChzZWUgdGhlDQo+ID4gPiA+IHJlcXVpcmVtZW50 IGRyYWZ0cyBpbiAgPiA+IFJPTEwpLiBSZWdpc3RlcmluZyB0byBhbGwgTEJSUyBpcyB0b3RhbGx5 DQo+IGltcHJhY3RpY2FsLg0KPiA+ID4gPiA2TG9XUEFOIE5EICA+ID4gcmVxdWlyZXMgYSBjb29y ZGluYXRpb24gYmV0d2VlbiBMQlJzIGJ1dCBkb2VzIG5vdA0KPiA+ID4gPiBzYXkgaG93IGl0IGhh cHBlbnMuDQo+ID4gPiA+ICA+ID4gVGhpcyBwcm9ibGVtIHdhcyBkaXNjdXNzZWQgaW4gNkxvV1BB TjsgdGhlIGFuc3dlciB3YXMgaW4NCj4gPiA+ID4gTkQtMDF0bzA3OyAgPiA+IGFuZCBpdCByZXF1 aXJlcyBhIFRJRCwgZm9yIHRoZSBzYW1lIHJlYXNvbiBhcyBSUEwuDQo+ID4gPiA+IFJlbW92aW5n IHRoZSAgPiA+IGJhY2tib25lIG9wZXJhdGlvbiBhbmQgdGhlIFRJRCBmcm9tIHRoZSBkcmFmdCBp cw0KPiA+ID4gPiBvc3RyaWNoDQo+ID4gPiBwb2xpY3kuDQo+ID4gPiA+ICA+ID4NCj4gPiA+ID4g ID4gPiBSUEwgYWxyZWFkeSBhZGFwdGVkIHRvIHRoZSBuZXcgcmVhbGl0eSBvZiBsYXJnZSBtdWx0 aWxpbmsNCj4gPiA+ID4gc3VibmV0IHdpdGggID4gPiBpbm5lciBtb2JpbGl0eS4gUGxhY2luZyB0 aGUgYmxhbWUgb24gUlBMIGlzDQo+ID4gPiA+IGFub3RoZXIgaWxsdXNpb25pc3QgdHJpY2suDQo+ ID4gPiA+ICA+ID4gQW5kIHRoaXMgaXMgbm90IFJQTCBsYXN0IGNhbGwuDQo+ID4gPiA+ICA+ID4N Cj4gPiA+ID4gID4gPiBCVFcgNkxvV1BBTiBORCBuZWVkcyBhIFRJRCB0byBjb3JyZWxhdGUgdGhl IE5TIGFuZCB0aGUgTkEgYXMNCj4gPiA+ID4gYWxsIG90aGVyICA+ID4gcmVnaXN0cmF0aW9ucyBk byB3aGVuIHN0cmljdCBvcmRlcmluZyBpcyBub3QNCj4gPiA+ID4gZ3VhcmFudGVlZCAoTUlQIGJl aW5nIGFuICA+ID4gZXhhbXBsZSkuIFNheSB0aGF0IGR1ZSB0byBzb21lDQo+ID4gPiA+IGNvbmZp ZywgYSBub2RlIHJlZ2lzdGVycyBhIGxpZmV0aW1lIG9mICA+ID4gWCwgdGhlbiBkZXJlZ2lzdGVy cw0KPiA+ID4gPiAobGlmZXRpbWUgMCksIHRoZW4gcmVyZWdpc3RlcnMgKGxpZmV0aW1lIFgpIGlu IGEgID4gPiByYXBpZA0KPiA+ID4gPiBzZXF1ZW5jZSwgYnV0IGRvZXMgbm90IGdldCBhbiBhbnN3 ZXIgeWV0LiBUaGVuIGl0IGZpbmFsbHkgZ2V0cw0KPiA+ID4gPiAyDQo+ID4gPiA+ICA+ID4gQVJP cyBiYWNrLCBsaWZldGltZSBYIGFuZCAwLiBXaGF0J3MgdGhlIGZpbmFsIHN0YXRlIGluIHRoZSBy b3V0ZXI/DQo+ID4gPiA+ICA+ID4NCj4gPiA+ID4gID4gPiBJdCBzZWVtcyB3ZSBjYW4gbmV2ZXIg YWdyZWUgb24gYW55IG9mIHRoaXMuIEknZCBsaWtlIHRvIGhlYXINCj4gPiA+ID4gd2hhdA0KPiA+ ID4gPiA+ID4gb3RoZXJzIHRoaW5rLg0KPiA+ID4gPiAgPiA+DQo+ID4gPiA+ICA+ID4gUGFzY2Fs DQo+ID4gPiA+ICA+ID4gaHR0cDovL3d3dy54dHJhbm9ybWFsLmNvbS93YXRjaC83MDExMzU3Lw0K PiA+ID4gPiAgPiA+DQo+ID4gPiA+ICA+ID4NCj4gPiA+ID4gID4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+ID4gID4gPj4gRnJvbTogNmxvd3Bhbi1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86Nmxvd3Bhbi0NCj4gPiA+IGJvdW5jZXNAaWV0Zi5vcmddDQo+ID4gPiA+IE9uICA+ ID4+IEJlaGFsZiBPZiBFcmlrIE5vcmRtYXJrICA+ID4+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTUs DQo+ID4gPiA+IDIwMTENCj4gPiA+ID4gMTozMCBBTSAgPiA+PiBUbzogNmxvPj4gJzZsb3dwYW4n DQo+ID4gPiA+ICA+ID4+IFN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0gRndkOiBSZTogIkFkdmVydGl6 ZSBvbiBCZWhhbGYiIGZsYWcNCj4gPiA+ID4gaW4gQVJPICA+ID4+ICA+ID4+ICA+ID4+IE9uIDQv MTMvMTEgMTI6NTMgQU0sIFBhc2NhbCBUaHViZXJ0DQo+ID4gPiA+IChwdGh1YmVydCkNCj4gPiA+ ID4gd3JvdGU6DQo+ID4gPiA+ICA+ID4+PiBIaSBFcmlrOg0KPiA+ID4gPiAgPiA+Pj4NCj4gPiA+ ID4gID4gPj4+IFRoZSBSUEwgKERBTykgc2VxdWVuY2UgbnVtYmVyIGFsbG93cyB0aGUgbm9kZSB0 byBpbmNyZW1lbnQNCj4gPiA+ID4gcmFwaWRseSAgPiA+Pj4gaW4gY2FzZSBvZiByYXBpZCBjaGFu Z2VzIGFuZCB0aGVuIGxhemlseSB3aGVuIHRoZQ0KPiA+ID4gPiBzaXR1YXRpb24gaXMgID4gPj4+ IHN0YWJsZSBhbmQgREFPIGFyZSBzY2FyY2UuIFRoZSBpbmNyZWFzZSBpcw0KPiA+ID4gPiBzdHJp Y3RseSBtb25vdG9ub3VzIHdoaWNoICA+ID4gID4gPj4+IGlzIGNyaXRpY2FsIHRvIHVzLg0KPiA+ ID4gPiAgPiA+Pj4NCj4gPiA+ID4gID4gPj4+IEEgdGltZSBzdGFtcCBpbXBvc2VzIGEgc3luY2hy b25pemF0aW9uIGJldHdlZW4gdGhlIHJvdXRlcnMuDQo+ID4gPiA+IFdlIGRvICA+ID4+PiBub3Qg aGF2ZSBzdWNoIG1lY2hhbmlzbSBpbiBSUEwuIEEgdGltZSB1bml0IChhDQo+ID4gPiA+IGdyYW51 bGFyaXR5KSBtdXN0IGJlICA+ID4+PiBhZ3JlZWQgdXBvbi4gV2l0aGluIHRoYXQgdW5pdCwNCj4g PiA+ID4gbW92ZW1lbnRzIGdvIHVuZGV0ZWN0ZWQgc28gdGhlIHRpbWUgID4gPj4+IHVuaXQgbXVz dCBiZSB0aGluIGdyYWluZWQNCj4gdG8gY292ZXIgcmFwaWQgY2hhbmdlcy4NCj4gPiA+ID4gWWV0 LCBkZXBlbmRpbmcgb24gID4gPj4+IHRoZSBtZWRpdW0sIHRoZSB0aW1lIHVuaXQsIGFuZCB0aGUg c2l6ZQ0KPiA+ID4gPiBvZiB0aGUgbmV0d29yaywgaXQgaXMgbm90ICA+ID4+PiBuZWNlc3Nhcmls eSBlYXN5L3Bvc3NpYmxlIHRvDQo+ID4gPiA+IGd1YXJhbnRlZSBhIHN0cmljdGx5IG1vbm90b25v dXMgdmFsdWUgID4gPj4+IHdpdGggYSB0aGluIGdyYWluZWQNCj4gPiA+ID4gdGltZSB1bml0LiBB bmQgd2UgaGF2ZSBsaW1pdGVkIHNwYWNlICgyDQo+ID4gPiA+IG9jdGV0cykNCj4gPiA+ID4gID4g Pj4+IGFuZCBoYXZlIHRvIGRlYWwgd2l0aCB3cmFwIGFyb3VuZCwgd2hpY2ggZGl2aWRlcyB0aGUg c3BhY2UNCj4gPiA+ID4gYnkgYXQgID4gPiBsZWFzdCAzLg0KPiA+ID4gPiAgPiA+Pj4NCj4gPiA+ ID4gID4gPj4+IFNvIFJQTCB3ZW50IGZvciBhIHNlcXVlbmNlIG51bWJlci4NCj4gPiA+ID4gID4g Pj4NCj4gPiA+ID4gID4gPj4gQnV0IHRoZSB1bnN0YXRlZCBhc3N1bXB0aW9uIHRoYXQgUlBMIG1h ZGUgaXMgdGhhdCBhbGwNCj4gPiA+ID4gaG9zdC10by1yb3V0ZXIgID4gPj4gcHJvdG9jb2xzIGhh dmUgdG8gbm93IGJlIFJQTCBhd2FyZS4gVGhhdA0KPiA+ID4gPiBkb2Vzbid0IHNvdW5kIGxpa2Ug Z29vZCAgPiA+IGRlc2lnbi4NCj4gPiA+ID4gID4gPj4gQSBob3N0IGlzbid0IGF3YXJlIG9mIHdo ZXRoZXIgdGhlIHJvdXRlcnMgc3BlYWsgSVMtSVMgb3INCj4gPiA+ID4gT1NQRiwgc28gd2h5ICA+ ID4+IGRvIHRoZSBob3N0cyBuZWVkIHRvIGJlIGF3YXJlIG9mIFJQTCBieSBwYXNzaW5nDQo+ID4g PiA+IHNvbWUgVElEIGFyb3VuZD8NCj4gPiA+ID4gID4gPj4NCj4gPiA+ID4gID4gPj4+IEkgdGhp bmsgTkQgaGFzIHRoZSBzYW1lIG5lZWQgYXMgTUlQIGZvciBhIFRJRCA9PSBTZXF1ZW5jZSAjIC4N Cj4gPiA+ID4gV2UgID4gPj4+IGtub3cgb2YgTUlQOyBXZSBrbm93IG9mIFJQTC4gV2Uga25vdyBv ZiB0aGUgYmFja2JvbmUNCj4gPiA+ID4gcm91dGVyDQo+ID4gPiA+ID4gPj4+IG9wZXJhdGlvbi4g V2Uga25vdyB3ZSdsbCBuZWVkIHRoZSBUSUQgYW5kIHdlIGtub3cgZXhhY3RseQ0KPiA+ID4gPiA+ ID4+PiB3aHkuIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgaXQgaW4gdGhlIDZMb3dQQU4gTkQgc3Bl YyByaWdodA0KPiA+ID4gPiA+ID4+PiBhd2F5IHRvDQo+ID4gPiA+IGF2b2lkICA+ID4+PiBpbnRl cm9wIGlzc3VlcyB3aGVuIHdlIGFkZCBSUEwgYW5kIEJSIG9wZXJhdGlvbnMuDQo+ID4gPiA+ICA+ ID4+DQo+ID4gPiA+ICA+ID4+IEkgZG9uJ3Qgc2VlIGEgbmVlZCBpbiA2bG93cGFuLW5kIGZvciBh IFRJRDsgdGhlIHByb3RvY29sDQo+ID4gPiA+IHdvcmtzIGZpbmUgID4gPiB3aXRob3V0IGl0Lg0K PiA+ID4gPiAgPiA+PiBJIHRoaW5rIFJQTCBuZWVkcyB0byBiZSBpbXByb3ZlZCB0byBkZWFsIHdp dGggcmVhbGl0eS4gSXNuJ3QNCj4gPiA+ID4gdGhlcmUgYSAgPiA+PiBkZXNpcmUgZm9yIFJQTCB0 byBoYW5kbGUgNDg2MSBob3N0cz8gVGhvc2Ugd291bGQNCj4gPiA+ID4gbmV2ZXIga25vdyBhYm91 dCBhICA+ID4gVElELg0KPiA+ID4gPiAgPiA+Pg0KPiA+ID4gPiAgPiA+PiBFcmlrDQo+ID4gPiA+ ICA+ID4+DQo+ID4gPiA+ICA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiA+ICA+ID4+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+ID4gPiA+ ICA+ID4+IDZsb3dwYW5AaWV0Zi5vcmcNCj4gPiA+ID4gID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuDQo+ID4gPiA+ICA+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gID4gPiA2bG93cGFuIG1h aWxpbmcgbGlzdA0KPiA+ID4gPiAgPiA+IDZsb3dwYW5AaWV0Zi5vcmcNCj4gPiA+ID4gID4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCj4gPiA+ID4gID4g Pg0KPiA+ID4gPiAgPg0KPiA+ID4gPiAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gPiAgPiA2bG93cGFuIG1haWxpbmcgbGlzdA0KPiA+ID4g PiAgPiA2bG93cGFuQGlldGYub3JnDQo+ID4gPiA+ICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vNmxvd3Bhbg0KPiA+ID4gPiAgPg0KPiA+ID4gPiAgPiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUgY29uZmlkZW50aWFsDQo+ID4g PiA+IGFuZCBsZWdhbGx5ICA+IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4gVGhlIG1l c3NhZ2UgaXMNCj4gPiA+ID4gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgID4gYWRkcmVzc2VlKHMp LiBJZiB5b3UgYXJlIG5vdCB0aGUNCj4gPiA+ID4gaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJl IGhlcmVieSBub3RpZmllZCAgPiB0aGF0IGFueSB1c2UsDQo+ID4gPiA+IGZvcndhcmRpbmcsIGRp c3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIG1lc3NhZ2UgaXMgID4NCj4gPiA+ ID4gc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgYXJlIG5v dCB0aGUNCj4gPiA+ID4gaW50ZW5kZWQgcmVjaXBpZW50LCAgPiBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGJ5IHJldHVybiBlLW1haWwNCj4gPiA+ID4gYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBv ZiB0aGUgID4gb3JpZ2luYWwgbWVzc2FnZS4NCj4gPiA+ID4NCj4gPiA+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gNmxvd3BhbiBtYWls aW5nIGxpc3QNCj4gPiA+ID4gNmxvd3BhbkBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+IF9fX19fX19fX19fXw0KPiA+ID4gPiBUaGlzIGVtYWlsIGhhcyBiZWVuIHNj YW5uZWQgYnkgdGhlIE1lc3NhZ2VMYWJzIEVtYWlsIFNlY3VyaXR5DQo+IFN5c3RlbS4NCj4gPiA+ ID4NCj4gPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+IF9fX19fX19fX19fXw0KPiA+ID4gPg0KPiA+DQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA2bG93cGFu IG1haWxpbmcgbGlzdA0KPiA+IDZsb3dwYW5AaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCj4gDQoNCg== From geoff@proto6.com Thu Apr 21 12:42:04 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 64E6DE082A for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 12:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCcMinrpYdwy for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 12:42:02 -0700 (PDT) Received: from server2.coslabs.com (server2.coslabs.com [64.111.18.234]) by ietfc.amsl.com (Postfix) with ESMTP id 6A11FE0754 for <6lowpan@ietf.org>; Thu, 21 Apr 2011 12:42:02 -0700 (PDT) Received: from grab (mail.coslabs.com [199.233.92.34]) by server2.coslabs.com (Postfix) with ESMTP id 6A4FC1847D; Thu, 21 Apr 2011 13:42:04 -0600 (MDT) Received: from [199.233.92.6] (unknown [199.233.92.6]) by grab (Postfix) with ESMTP id 5B48C7FD97; Thu, 21 Apr 2011 13:41:58 -0600 (MDT) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> References: <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 21 Apr 2011 13:42:00 -0600 Message-ID: <1303414920.1671.1849.camel@d430> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 19:42:04 -0000 Pascal, I couple of people supporting the TID is not group consensus. We have had many presentations and discussions about multiple LBRs, backbone LBRs and more and none have met with the support of the working group. In your opinions we are crashing, but I fail to see that this is the opinion of the working group. If there are other in the working group that strongly advocate this TID idea or the work on multiple and backbone LBRs then they need to speak up now en masse or we must move on. geoff On Thu, 2011-04-21 at 21:32 +0200, Pascal Thubert (pthubert) wrote: > Geoff: > > There is twice as much support for restoring the TID than there is for not doing it. > Before we drop the TID, I'd like to see a proposal that allows a 6LoWPAN ND subnet to scale with multiple LBRs, allows nodes to move from a router to the next, and that does not need a TID. > Otherwise, we are not speeding towards the wall, we're already crashing. > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > -----Original Message----- > > From: Geoff Mulligan [mailto:geoff.ietf@mulligan.com] > > Sent: Thursday, April 21, 2011 5:41 PM > > To: Pascal Thubert (pthubert) > > Cc: Erik Nordmark; nicolas.riou@schneider-electric.com; 6lowpan@ietf.org > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > ARO] > > > > Pascal, > > We need to close on this discussion. > > > > Back in Hiroshima the Working Group decided that Backbone router stuff and > > "address defense" across backbone routers was not going to be part of ND > > draft. It appeared that the draft was getting way to complicated and the > > Working Group decided to simplify things. > > > > I have not seen much support on the list for making these changes to include > > the TID in ND. > > > > We need to get this draft completed. If there is a large "unheard from" > > support group for these changes, please speak up or we shall move forward > > with the draft as it is. > > > > geoff > > > > > > > > > > On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote: > > > Hi Erik > > > > > > The TID is not a strong coupling between the H2R and the R2R operations, > > and it is not a coupling with a RPL version explicitly. > > > It is an abstract information that if defined properly can be used by many > > forms or R2R interactions. > > > As demonstrated by older versions of the ND spec (Backbone Router), RPL, > > and MIP. > > > > > > 6LoWPAN ND cannot scale if the node needs to register to all LBRs. > > 6LoWPAN ND does not define anymore any LBR interaction. > > > IOW, 6LoPWAN ND lost the capability to scale when the backbone router > > piece was removed from the draft. > > > Which means that it lost its capability to apply in the domains I'm looking at > > (industrial and metering). > > > > > > With the TID, we know that we can restore scalability in the future, and we > > know how. I do not know of a plan B. > > > > > > Pascal > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > -----Original Message----- > > > > From: Erik Nordmark [mailto:nordmark@acm.org] > > > > Sent: Thursday, April 21, 2011 1:25 AM > > > > To: nicolas.riou@schneider-electric.com > > > > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko > > > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" > > > > flag in ARO] > > > > > > > > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > > > > > > > > > Dear Pascal and al, > > > > > > > > > > I support the idea of reviving the TID in ARO and DAR/DAC. > > > > > Supporting a TID directly in the node initiating the initial NS > > > > > appears much simpler than time stamping in the parent router. > > > > > > > > How would you make this work if the protocol between the routers is > > > > not RPLv1, but some future version of RPL or a completely different > > > > routing protocol? > > > > > > > > The decoupling of the host-router interaction from router-router > > > > interaction has served us well in the history of the Internet. > > > > > > > > Erik > > > > > > > > > A simple and efficient method to detect mobility of hosts along a > > > > > backbone of Edge Routers is an important feature to deploy > > > > > backbones of Edge Routers in Buildings and should be clarified > > > > > before closing 6LoWPAN WG. > > > > > > > > > > Cheers, > > > > > Nicolas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *"Pascal Thubert (pthubert)" * Envoyé par : > > > > > 6lowpan-bounces@ietf.org > > > > > > > > > > 18/04/2011 10:37 > > > > > > > > > > > > > > > A > > > > > "Dijk, Esko" , "Erik Nordmark" > > > > > cc > > > > > 6lowpan@ietf.org > > > > > Objet > > > > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > > > ARO] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Esko, Erik > > > > > > > > > > The discussion on RPL and hosts should happen on the RPL list > > > > > under a different topic. The point being discussed here is this: > > > > > > > > > > The reality is also that those (LLN) networks will need to scale > > > > > to large subnets in plants, building, etc... (see the requirement > > > > > drafts in ROLL). Registering to all LBRS is totally impractical. > > > > > 6LoWPAN ND requires a coordination between LBRs but does not say > > how it happens. > > > > > This problem was discussed in 6LoWPAN; the answer was in > > > > > ND-01to07; and it requires a TID, for the same reason as RPL. > > > > > Removing the backbone operation and the TID from the draft is ostrich > > policy. > > > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > > > > > other registrations do when strict ordering is not guaranteed (MIP > > > > > being an example). Say that due to some config, a node registers a > > > > > lifetime of X, then deregisters (lifetime 0), then reregisters > > > > > (lifetime X) in a rapid sequence, but does not get an answer yet. > > > > > Then it finally gets 2 AROs back, lifetime X and 0. What's the final state > > in the router? > > > > > > > > > > I'd like to hear what others think. > > > > > > > > > > Pascal > > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: > > > > > Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal > > > > > Thubert > > > > > (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: > > > > > TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello > > > > > Erik, > > > > > > > taking the definition you quoted: > > > > > > 'host' refers to an LLN device that can generate but does not > > > > > forward > RPL traffic > > the question may arise what is "RPL > > > > > traffic"? It is not defined in the RPL draft > it seems. Pascal > > > > > clarified to me it is traffic associated to a RPL instance, not > > > > > > necessarily RPL protocol messages. This means that a host could > > > > > generate > RPL traffic without being aware of the existence of > > > > > RPL at all. So, _not_ all > hosts have to speak RPL? > > > > > > The RPL draft does not explicitly state if "hosts" in a RPL > > > > > network always > speak RPL, never speak RPL, or can be mixed > > > > > RPL/non-RPL speakers. > > > > > > > > > > > > Taking the definition of 'node' in the RPL draft: > > > > > > 'node' refers to any RPL device, either a host or a router > > > > > > > rules out (?) the option that all "hosts" are non-RPL speakers, > > > > > since there > may be a "RPL device" (i.e. RPL-speaking device, I > > > > > assume) that is also a host. > > > > > > > > > > > > I communicated these perceived unclarities to Pascal and the > > > > > RFC editor 2 > weeks ago. Once this is clear I think the present > > > > > discussion can continue. > > > > > > And then there is the related discussion of ND support for > > > > > sleepy devices, > the original topic of Anders ;) > > best > > > > > regards, > > Esko > > > > -----Original Message----- > From: > > > > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > > > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: > > > > > Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: > > > > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > > > > > ARO] > > > > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > > > > > > > > > RPL can do what all classical IGPs can do WRT hosts. That is > > > > > as long > > as the host address belongs to the router's prefix > > > > > and stays attached > > to that router. > > > > > > > > > > > > I just realized that we might be talking about a different > > > > > definition of "host". > > > > > > What I mean by "host" is a node which does not participate in a > > > > > routing > protocol, and does not forward packets (except packets > > > > > explicitly addressed > to itself using e.g., a routing header). > > > > > > > > > > > > However, RPL has a different definition: > > > > > > 'host' refers to an LLN device that can generate but does not > > > > > forward > RPL traffic > > Basically per the RPL definition > > > > > there is no such thing as a node which does > not participate in > > > > > the RPL protocol. > > > > > > IMHO what is in RPL should have been defined as a > > > > > non-forwarding node, so > that we can have a sane discussion > > > > > without getting entangled in terminology > issues. > > > > > > > > > > > > Which definition of "host" are you using above? > > > > > > > > > > > > Per the RPL definition there is no need for 6lowpan-nd, since > > > > > all nodes will > speak RPL. This is rather confusing, don't you think? > > > > > > > > > > > > Erik > > > > > > > > > > > > > When the topology becomes multilink subnet and mobility is > > > > > required > > then it is a new problem entirely, and NO, 4861 is > > > > > not a suitable > > interaction with the router to allow the > > > > > router to redistribute a host route. > > > > > > > Because the neighbor cache that 4861 builds is not a of the > > > > > same > > > > > > > nature as the binding table that 6LoWPAN ND builds. Another > > > > > > > thing > > > > > that > > 6LoWPAN ND fails to express correctly. I proposed text > > > > > to explain that > > (attached) but it was not considered, > > > > > contributing to the illusion > > that a cache is a table. > > > > > > > > > > > > > > The reality is also that those networks will need to scale to > > > > > large > > subnets in plants, building, etc... (see the > > > > > requirement drafts in > > ROLL). Registering to all LBRS is totally > > impractical. > > > > > 6LoWPAN ND > > requires a coordination between LBRs but does not > > > > > say how it happens. > > > > > > > This problem was discussed in 6LoWPAN; the answer was in > > > > > ND-01to07; > > and it requires a TID, for the same reason as RPL. > > > > > Removing the > > backbone operation and the TID from the draft is > > > > > ostrich > > > > policy. > > > > > > > > > > > > > > RPL already adapted to the new reality of large multilink > > > > > subnet with > > inner mobility. Placing the blame on RPL is > > > > > another illusionist trick. > > > > > > > And this is not RPL last call. > > > > > > > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as > > > > > all other > > registrations do when strict ordering is not > > > > > guaranteed (MIP being an > > example). Say that due to some > > > > > config, a node registers a lifetime of > > X, then deregisters > > > > > (lifetime 0), then reregisters (lifetime X) in a > > rapid > > > > > sequence, but does not get an answer yet. Then it finally gets > > > > > 2 > > > > > > > AROs back, lifetime X and 0. What's the final state in the router? > > > > > > > > > > > > > > It seems we can never agree on any of this. I'd like to hear > > > > > what > > > > > > > others think. > > > > > > > > > > > > > > Pascal > > > > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- > > > > bounces@ietf.org] > > > > > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, > > > > > 2011 > > > > > 1:30 AM > >> To: 6lo>> '6lowpan' > > > > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag > > > > > in ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert > > > > > (pthubert) > > > > > wrote: > > > > > > >>> Hi Erik: > > > > > > >>> > > > > > > >>> The RPL (DAO) sequence number allows the node to increment > > > > > rapidly > >>> in case of rapid changes and then lazily when the > > > > > situation is > >>> stable and DAO are scarce. The increase is > > > > > strictly monotonous which > > > >>> is critical to us. > > > > > > >>> > > > > > > >>> A time stamp imposes a synchronization between the routers. > > > > > We do > >>> not have such mechanism in RPL. A time unit (a > > > > > granularity) must be > >>> agreed upon. Within that unit, > > > > > movements go undetected so the time > >>> unit must be thin grained > > to cover rapid changes. > > > > > Yet, depending on > >>> the medium, the time unit, and the size > > > > > of the network, it is not > >>> necessarily easy/possible to > > > > > guarantee a strictly monotonous value > >>> with a thin grained > > > > > time unit. And we have limited space (2 > > > > > octets) > > > > > > >>> and have to deal with wrap around, which divides the space > > > > > by at > > least 3. > > > > > > >>> > > > > > > >>> So RPL went for a sequence number. > > > > > > >> > > > > > > >> But the unstated assumption that RPL made is that all > > > > > host-to-router > >> protocols have to now be RPL aware. That > > > > > doesn't sound like good > > design. > > > > > > >> A host isn't aware of whether the routers speak IS-IS or > > > > > OSPF, so why > >> do the hosts need to be aware of RPL by passing > > > > > some TID around? > > > > > > >> > > > > > > >>> I think ND has the same need as MIP for a TID == Sequence # . > > > > > We > >>> know of MIP; We know of RPL. We know of the backbone > > > > > router > > > > > > >>> operation. We know we'll need the TID and we know exactly > > > > > > >>> why. I think we should have it in the 6LowPAN ND spec right > > > > > > >>> away to > > > > > avoid > >>> interop issues when we add RPL and BR operations. > > > > > > >> > > > > > > >> I don't see a need in 6lowpan-nd for a TID; the protocol > > > > > works fine > > without it. > > > > > > >> I think RPL needs to be improved to deal with reality. Isn't > > > > > there a > >> desire for RPL to handle 4861 hosts? Those would > > > > > never know about a > > TID. > > > > > > >> > > > > > > >> Erik > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> 6lowpan mailing list > > > > > > >> 6lowpan@ietf.org > > > > > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > _______________________________________________ > > > > > > > 6lowpan mailing list > > > > > > > 6lowpan@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 6lowpan mailing list > > > > > > 6lowpan@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > The information contained in this message may be confidential > > > > > and legally > protected under applicable law. The message is > > > > > intended solely for the > addressee(s). If you are not the > > > > > intended recipient, you are hereby notified > that any use, > > > > > forwarding, dissemination, or reproduction of this message is > > > > > > strictly prohibited and may be unlawful. If you are not the > > > > > intended recipient, > please contact the sender by return e-mail > > > > > and destroy all copies of the > original message. > > > > > > > > > > _______________________________________________ > > > > > 6lowpan mailing list > > > > > 6lowpan@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > __________________________________________________________ > > > > ____________ > > > > > This email has been scanned by the MessageLabs Email Security > > System. > > > > > > > > > > > __________________________________________________________ > > > > ____________ > > > > > > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > From nordmark@acm.org Thu Apr 21 14:39:48 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0C4C2E06F4 for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 14:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldlSnQKgloPb for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 14:39:46 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id B8918E0669 for <6lowpan@ietf.org>; Thu, 21 Apr 2011 14:39:45 -0700 (PDT) Received: from [128.107.114.52] (dhcp-128-107-114-52.cisco.com [128.107.114.52]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3LLdfMi019446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2011 14:39:41 -0700 Message-ID: <4DB0A442.4010905@acm.org> Date: Thu, 21 Apr 2011 14:40:18 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: nicolas.riou@schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 21:39:48 -0000 On 4/21/11 7:30 AM, nicolas.riou@schneider-electric.com wrote: > > Hi Erik, > > Comments in line... > > > From: Erik Nordmark [mailto:nordmark@acm.org] > > Sent: Thursday, April 21, 2011 1:25 AM > > To: nicolas.riou@schneider-electric.com > > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > ARO] > > > > On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > > > > > Dear Pascal and al, > > > > > > I support the idea of reviving the TID in ARO and DAR/DAC. Supporting > > > a TID directly in the node initiating the initial NS appears much > > > simpler than time stamping in the parent router. > > > > How would you make this work if the protocol between the routers is not > > RPLv1, but some future version of RPL or a completely different routing > > protocol? > > As Pascal answered in his post, the TID is not particularly coupled with > RPLv1. The TID is just an extra information provided by the node during > ND registration which dramatically simplifies node localization but also > enable DAD across a backbone of Edge Routers advertizing the same prefix. > Which alternative solution would you suggest for DAD? DAD works fine with what we have in ARO. If the same EUI-64 (re)registers the same IPv6 address, then it is not a duplicate. If a different EUI-64 tries to registers an IPv6 address (already registered with some other EUI-64), then it is a duplicate. That is independent whether the check is done in a 6LR or 6LBR. What do you see as the problem with DAD? Can you provide an example of what doesn't work with 6lowpan-nd? > The TID can fit in "reserved" field of ARO/DAR/DAC and thus can come > at no cost. FWIW Complexity is the true cost, because unneeded complexity leads to non-interoperability for no benefit. > Thanks to the lollipop mechanism defined in 6lowpan-nd-07 the TID can be > implemented even in the most constrained devices which might not be able > to consistently increment the TID. The lollipop stuff is not proven technology. It existed in an early draft of OSPF, and was replaced. I assume it was replaced for a reason. Any proven TID scheme would require stable storage on the device, so that the device doesn't accidentally reuse old TIDs too soon. I don't think we want to require that capability on all 6lowpan hosts, just because it is perceived too hard to have RPL keep track of things. Erik > Regards, > Nicolas > > > > The decoupling of the host-router interaction from router-router > interaction > > has served us well in the history of the Internet. > > > > Erik > > > > > A simple and efficient method to detect mobility of hosts along a > > > backbone of Edge Routers is an important feature to deploy backbones > > > of Edge Routers in Buildings and should be clarified before closing > > > 6LoWPAN WG. > > > > > > Cheers, > > > Nicolas > > > > > > > > > > > > > > > > > > > > > *"Pascal Thubert (pthubert)" * Envoyé par : > > > 6lowpan-bounces@ietf.org > > > > > > 18/04/2011 10:37 > > > > > > > > > A > > > "Dijk, Esko" , "Erik Nordmark" > > > cc > > > 6lowpan@ietf.org > > > Objet > > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > > ARO] > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Esko, Erik > > > > > > The discussion on RPL and hosts should happen on the RPL list under a > > > different topic. The point being discussed here is this: > > > > > > The reality is also that those (LLN) networks will need to scale to > > > large subnets in plants, building, etc... (see the requirement drafts > > > in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > > > requires a coordination between LBRs but does not say how it happens. > > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > > > and it requires a TID, for the same reason as RPL. Removing the > > > backbone operation and the TID from the draft is ostrich policy. > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > > > registrations do when strict ordering is not guaranteed (MIP being an > > > example). Say that due to some config, a node registers a lifetime of > > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > > rapid sequence, but does not get an answer yet. Then it finally gets 2 > > > AROs back, lifetime X and 0. What's the final state in the router? > > > > > > I'd like to hear what others think. > > > > > > Pascal > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > -----Original Message----- > > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Monday, > > > April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal Thubert > > > (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: TID > > > in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello Erik, > > > > > taking the definition you quoted: > > > > 'host' refers to an LLN device that can generate but does not > > > forward > RPL traffic > > the question may arise what is "RPL > > > traffic"? It is not defined in the RPL draft > it seems. Pascal > > > clarified to me it is traffic associated to a RPL instance, not > > > > necessarily RPL protocol messages. This means that a host could > > > generate > RPL traffic without being aware of the existence of RPL at > > > all. So, _not_ all > hosts have to speak RPL? > > > > The RPL draft does not explicitly state if "hosts" in a RPL network > > > always > speak RPL, never speak RPL, or can be mixed RPL/non-RPL > > > speakers. > > > > > > > > Taking the definition of 'node' in the RPL draft: > > > > 'node' refers to any RPL device, either a host or a router > > > > > rules out (?) the option that all "hosts" are non-RPL speakers, since > > > there > may be a "RPL device" (i.e. RPL-speaking device, I assume) > > > that is also a host. > > > > > > > > I communicated these perceived unclarities to Pascal and the RFC > > > editor 2 > weeks ago. Once this is clear I think the present > > > discussion can continue. > > > > And then there is the related discussion of ND support for sleepy > > > devices, > the original topic of Anders ;) > > best regards, > > > > > Esko > > > > -----Original Message----- > From: > > > 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: > > > Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: > > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > > > > > RPL can do what all classical IGPs can do WRT hosts. That is as > > > long > > as the host address belongs to the router's prefix and stays > > > attached > > to that router. > > > > > > > > I just realized that we might be talking about a different > > > definition of "host". > > > > What I mean by "host" is a node which does not participate in a > > > routing > protocol, and does not forward packets (except packets > > > explicitly addressed > to itself using e.g., a routing header). > > > > > > > > However, RPL has a different definition: > > > > 'host' refers to an LLN device that can generate but does not > > > forward > RPL traffic > > Basically per the RPL definition there is > > > no such thing as a node which does > not participate in the RPL > > > protocol. > > > > IMHO what is in RPL should have been defined as a non-forwarding > > > node, so > that we can have a sane discussion without getting > > > entangled in terminology > issues. > > > > > > > > Which definition of "host" are you using above? > > > > > > > > Per the RPL definition there is no need for 6lowpan-nd, since all > > > nodes will > speak RPL. This is rather confusing, don't you think? > > > > > > > > Erik > > > > > > > > > When the topology becomes multilink subnet and mobility is > > > required > > then it is a new problem entirely, and NO, 4861 is not a > > > suitable > > interaction with the router to allow the router to > > > redistribute a host route. > > > > > Because the neighbor cache that 4861 builds is not a of the same > > > > > nature as the binding table that 6LoWPAN ND builds. Another thing > > > that > > 6LoWPAN ND fails to express correctly. I proposed text to > > > explain that > > (attached) but it was not considered, contributing > > > to the illusion > > that a cache is a table. > > > > > > > > > > The reality is also that those networks will need to scale to > > > large > > subnets in plants, building, etc... (see the requirement > > > drafts in > > ROLL). Registering to all LBRS is totally impractical. > > > 6LoWPAN ND > > requires a coordination between LBRs but does not say > > > how it happens. > > > > > This problem was discussed in 6LoWPAN; the answer was in > > > ND-01to07; > > and it requires a TID, for the same reason as RPL. > > > Removing the > > backbone operation and the TID from the draft is > ostrich > > policy. > > > > > > > > > > RPL already adapted to the new reality of large multilink subnet > > > with > > inner mobility. Placing the blame on RPL is another > > > illusionist trick. > > > > > And this is not RPL last call. > > > > > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > > > other > > registrations do when strict ordering is not guaranteed > > > (MIP being an > > example). Say that due to some config, a node > > > registers a lifetime of > > X, then deregisters (lifetime 0), then > > > reregisters (lifetime X) in a > > rapid sequence, but does not get an > > > answer yet. Then it finally gets > > > 2 > > > > > AROs back, lifetime X and 0. What's the final state in the router? > > > > > > > > > > It seems we can never agree on any of this. I'd like to hear what > > > > > others think. > > > > > > > > > > Pascal > > > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- > > bounces@ietf.org] > > > On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, 2011 > > > 1:30 AM > >> To: 6lo>> '6lowpan' > > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in > > > ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) > > > wrote: > > > > >>> Hi Erik: > > > > >>> > > > > >>> The RPL (DAO) sequence number allows the node to increment > > > rapidly > >>> in case of rapid changes and then lazily when the > > > situation is > >>> stable and DAO are scarce. The increase is > > > strictly monotonous which > > > >>> is critical to us. > > > > >>> > > > > >>> A time stamp imposes a synchronization between the routers. We > > > do > >>> not have such mechanism in RPL. A time unit (a granularity) > > > must be > >>> agreed upon. Within that unit, movements go undetected > > > so the time > >>> unit must be thin grained to cover rapid changes. > > > Yet, depending on > >>> the medium, the time unit, and the size of > > > the network, it is not > >>> necessarily easy/possible to guarantee a > > > strictly monotonous value > >>> with a thin grained time unit. And we > > > have limited space (2 > > > octets) > > > > >>> and have to deal with wrap around, which divides the space by > > > at > > least 3. > > > > >>> > > > > >>> So RPL went for a sequence number. > > > > >> > > > > >> But the unstated assumption that RPL made is that all > > > host-to-router > >> protocols have to now be RPL aware. That doesn't > > > sound like good > > design. > > > > >> A host isn't aware of whether the routers speak IS-IS or OSPF, > > > so why > >> do the hosts need to be aware of RPL by passing some TID > > > around? > > > > >> > > > > >>> I think ND has the same need as MIP for a TID == Sequence # . > > > We > >>> know of MIP; We know of RPL. We know of the backbone router > > > > >>> operation. We know we'll need the TID and we know exactly why. I > > > > >>> think we should have it in the 6LowPAN ND spec right away to > > > avoid > >>> interop issues when we add RPL and BR operations. > > > > >> > > > > >> I don't see a need in 6lowpan-nd for a TID; the protocol works > > > fine > > without it. > > > > >> I think RPL needs to be improved to deal with reality. Isn't > > > there a > >> desire for RPL to handle 4861 hosts? Those would never > > > know about a > > TID. > > > > >> > > > > >> Erik > > > > >> > > > > >> _______________________________________________ > > > > >> 6lowpan mailing list > > > > >> 6lowpan@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > > _______________________________________________ > > > > > 6lowpan mailing list > > > > > 6lowpan@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > _______________________________________________ > > > > 6lowpan mailing list > > > > 6lowpan@ietf.org > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > The information contained in this message may be confidential and > > > legally > protected under applicable law. The message is intended > > > solely for the > addressee(s). If you are not the intended recipient, > > > you are hereby notified > that any use, forwarding, dissemination, or > > > reproduction of this message is > strictly prohibited and may be > > > unlawful. If you are not the intended recipient, > please contact the > > > sender by return e-mail and destroy all copies of the > original > > > message. > > > > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > __________________________________________________________ > > ____________ > > > This email has been scanned by the MessageLabs Email Security System. > > > > > __________________________________________________________ > > ____________ > > > > > > > > > From pthubert@cisco.com Thu Apr 21 23:50:02 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E605CE0804 for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 23:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.935 X-Spam-Level: X-Spam-Status: No, score=-8.935 tagged_above=-999 required=5 tests=[AWL=1.664, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxFhLzTXM1c3 for <6lowpan@ietfc.amsl.com>; Thu, 21 Apr 2011 23:50:00 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 769DCE0800 for <6lowpan@ietf.org>; Thu, 21 Apr 2011 23:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=27104; q=dns/txt; s=iport; t=1303454999; x=1304664599; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=J222fmd1y/aXGTpo65W4bDzv7U4fcEVnBFV3jcCAlEU=; b=Fhhi4FV9WSyV8hwwHihtz/tuBOxv99df3tHY032LuK4Rhwz1c6w0gyJQ 7gliLMeLpRDQ4SekYDeWATIb8lLFIM1oh3Lr2ob5sAROleXfBEfhNyCQM OK/6e4JeOZEwWz10kk14/1YG/ABQs+NdoE2sREK31USKTNeIwsKHn1/0B k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwAAAoksU2Q/khRgWdsb2JhbACEUJMDjH+BChQBARYmJYhwnRqLXJB4gSmDUH0Ekjo X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="84691479" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2011 06:49:58 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3M6nwhR017849; Fri, 22 Apr 2011 06:49:58 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 08:49:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 22 Apr 2011 08:49:53 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0470FA1D@XMB-AMS-107.cisco.com> In-Reply-To: <1303414920.1671.1849.camel@d430> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: AcwAXDNDaqjnoPz8QXCEbJuZ9EO2OwAWv7AQ References: <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> <1303414920.1671.1849.camel@d430> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" X-OriginalArrivalTime: 22 Apr 2011 06:49:57.0946 (UTC) FILETIME=[7E93B1A0:01CC00B9] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 06:50:03 -0000 R2VvZmY6DQoNCk15IHNlbnNlIGlzIHRoYXQgd2UgZmFpbGVkIHRvIG1lZXQgYSBxdW9ydW0gdG8g d29yayBlZmZpY2llbnRseSBvbiB0aGUgYmFja2JvbmUgcm91dGVyLiBBZnRlciB0aGUgc3BsaXQs IGl0IHdhcyBhbHdheXMgYSBmZXcgaGFuZHMgYm90aCB3YXlzLg0KTmV2ZXJ0aGVsZXNzLCB0aGlz IGdyb3VwIHdvcmtlZCBvbiB0aGUgcHJvYmxlbSBmb3Igb3ZlciBhIHllYXIgYWZ0ZXIgRHVibGlu LCBhbmQgdGhlIGRlc2lnbiB3YXMgcHJldHR5IGNsZWFyLiANClRoZSBUSUQgd2FzIHJlcXVpcmVk IHRvIGRpc3RyaWJ1dGUgdGhlIExCUnMuDQoNClRoaXMgdGhyZWFkIGlzIG5vdCBhYm91dCB0aGUg YmFja2JvbmUgcm91dGVyIGRyYWZ0LiBIZXJlLCB3ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgVElE IGluIHRoZSBORCBvcHRpb25zLiANCg0KU2NhbGluZyB0byB0aG91c2FuZHMgaXMgYSByZXF1aXJl bWVudCBpbiBhIG51bWJlciBvZiBlbnZpcm9ubWVudHMgSSdtIGRlYWxpbmcgd2l0aCwgaW4gcGFy dGljdWxhciBpbmR1c3RyaWFsLg0KU28gSSdtIGFza2luZyB5b3UgYW5kIHRoZSBncm91cCB3aGlj aCBwbGFuIEIgd2UgaGF2ZSB0byBzY2FsZSBpZiB0aGVyZSBpcyBubyBUSUQuIEkndmUgbm90IHNl ZW4gYW55IHNvIGZhci4NCklmIHRoZXJlJ3Mgbm9uZSB0aGVuIHllcywgd2UncmUgaGl0dGluZyBh IHdhbGwuIFRoYXQncyBwcm9ibGVtIDEuDQoNCkluIGFueSBmYXNoaW9uLCBJJ3ZlIG5vdCBzZWVu IGhvdyB0aGUgY3VycmVudCBORCAgZHJhZnQgb3BlcmF0ZXMgaWYgY29udHJvbCBwYWNrZXRzIGFy ZSBsb3N0IG9yIG91dCBvZiBvcmRlciAoZWcgbWVzaCB1bmRlcikuDQpGb3IgYWxsIEkndmUgc2Vl biwgdGhlIGhvc3QgY2Fubm90IGJlIHN1cmUgb2YgdGhlIGZpbmFsIHN0YXRlIGluIHRoZSByb3V0 ZXIgYmVjYXVzZSB0aGUgYWNrIGlzIG5vdCBjb3JyZWxhdGVkIHdpdGggdGhlIHJlcS4NClRoYXQn cyBwcm9ibGVtIDIuDQoNCkZpbmFsbHksIGEgVElEIGluIHRoZSBjb250cm9sIGFsc28gaGVscHMg cHJvdGVjdCB0aGUgcHJvdG9jb2wgYWdhaW5zdCByZXBsYXkgYXR0YWNrcy4gQW55IE1JQyBpcyBl bm91Z2guDQoNCkknZCBsaWtlIHRvIHNlZSBhIHJlYWwgc2Vuc2Ugb2YgdGhlIGdyb3VwIHdoZXRo ZXIgd2Ugd2FudCB0aGUgVElEIGluIG9yIG5vdC4gR3V5cywgcGxlYXNlPw0KDQpQYXNjYWwNCmh0 dHA6Ly93d3cueHRyYW5vcm1hbC5jb20vd2F0Y2gvNzAxMTM1Ny8NCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHZW9mZiBNdWxsaWdhbiBbbWFpbHRvOmdlb2ZmQHByb3Rv Ni5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyMSwgMjAxMSA5OjQyIFBNDQo+IFRvOiBQ YXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+IENjOiBFcmlrIE5vcmRtYXJrOyBuaWNvbGFzLnJp b3VAc2NobmVpZGVyLWVsZWN0cmljLmNvbTsgNmxvd3BhbkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS RTogWzZsb3dwYW5dIEZXOiBUSUQgaW4gQVJPIFt3YXM6ICJBZHZlcnRpemUgb24gQmVoYWxmIiBm bGFnIGluDQo+IEFST10NCj4gDQo+IFBhc2NhbCwNCj4gICBJIGNvdXBsZSBvZiBwZW9wbGUgc3Vw cG9ydGluZyB0aGUgVElEIGlzIG5vdCBncm91cCBjb25zZW5zdXMuICBXZSBoYXZlIGhhZA0KPiBt YW55IHByZXNlbnRhdGlvbnMgYW5kIGRpc2N1c3Npb25zIGFib3V0IG11bHRpcGxlIExCUnMsIGJh Y2tib25lIExCUnMgYW5kDQo+IG1vcmUgYW5kIG5vbmUgaGF2ZSBtZXQgd2l0aCB0aGUgc3VwcG9y dCBvZiB0aGUgd29ya2luZyBncm91cC4NCj4gDQo+IEluIHlvdXIgb3BpbmlvbnMgd2UgYXJlIGNy YXNoaW5nLCBidXQgSSBmYWlsIHRvIHNlZSB0aGF0IHRoaXMgaXMgdGhlIG9waW5pb24gb2YNCj4g dGhlIHdvcmtpbmcgZ3JvdXAuDQo+IA0KPiBJZiB0aGVyZSBhcmUgb3RoZXIgaW4gdGhlIHdvcmtp bmcgZ3JvdXAgdGhhdCBzdHJvbmdseSBhZHZvY2F0ZSB0aGlzIFRJRCBpZGVhIG9yDQo+IHRoZSB3 b3JrIG9uIG11bHRpcGxlIGFuZCBiYWNrYm9uZSBMQlJzIHRoZW4gdGhleSBuZWVkIHRvIHNwZWFr IHVwIG5vdyBlbg0KPiBtYXNzZSBvciB3ZSBtdXN0IG1vdmUgb24uDQo+IA0KPiAJZ2VvZmYNCj4g DQo+IA0KPiBPbiBUaHUsIDIwMTEtMDQtMjEgYXQgMjE6MzIgKzAyMDAsIFBhc2NhbCBUaHViZXJ0 IChwdGh1YmVydCkgd3JvdGU6DQo+ID4gR2VvZmY6DQo+ID4NCj4gPiBUaGVyZSBpcyB0d2ljZSBh cyBtdWNoIHN1cHBvcnQgZm9yIHJlc3RvcmluZyB0aGUgVElEIHRoYW4gdGhlcmUgaXMgZm9yICBu b3QNCj4gZG9pbmcgaXQuDQo+ID4gQmVmb3JlIHdlIGRyb3AgdGhlIFRJRCwgSSdkIGxpa2UgdG8g c2VlIGEgcHJvcG9zYWwgdGhhdCBhbGxvd3MgYSA2TG9XUEFODQo+IE5EIHN1Ym5ldCB0byBzY2Fs ZSB3aXRoIG11bHRpcGxlIExCUnMsIGFsbG93cyBub2RlcyB0byBtb3ZlIGZyb20gYSByb3V0ZXIg dG8NCj4gdGhlIG5leHQsIGFuZCB0aGF0IGRvZXMgbm90IG5lZWQgYSBUSUQuDQo+ID4gT3RoZXJ3 aXNlLCB3ZSBhcmUgbm90IHNwZWVkaW5nIHRvd2FyZHMgdGhlIHdhbGwsIHdlJ3JlIGFscmVhZHkg Y3Jhc2hpbmcuDQo+ID4NCj4gPiBQYXNjYWwNCj4gPiBodHRwOi8vd3d3Lnh0cmFub3JtYWwuY29t L3dhdGNoLzcwMTEzNTcvDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gPiBGcm9tOiBHZW9mZiBNdWxsaWdhbiBbbWFpbHRvOmdlb2ZmLmlldGZAbXVsbGlnYW4uY29t XQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDIxLCAyMDExIDU6NDEgUE0NCj4gPiA+IFRv OiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+ID4gPiBDYzogRXJpayBOb3JkbWFyazsgbmlj b2xhcy5yaW91QHNjaG5laWRlci1lbGVjdHJpYy5jb207DQo+ID4gPiA2bG93cGFuQGlldGYub3Jn DQo+ID4gPiBTdWJqZWN0OiBSZTogWzZsb3dwYW5dIEZXOiBUSUQgaW4gQVJPIFt3YXM6ICJBZHZl cnRpemUgb24gQmVoYWxmIg0KPiA+ID4gZmxhZyBpbiBBUk9dDQo+ID4gPg0KPiA+ID4gUGFzY2Fs LA0KPiA+ID4gICBXZSBuZWVkIHRvIGNsb3NlIG9uIHRoaXMgZGlzY3Vzc2lvbi4NCj4gPiA+DQo+ ID4gPiBCYWNrIGluIEhpcm9zaGltYSB0aGUgV29ya2luZyBHcm91cCBkZWNpZGVkIHRoYXQgQmFj a2JvbmUgcm91dGVyDQo+ID4gPiBzdHVmZiBhbmQgImFkZHJlc3MgZGVmZW5zZSIgYWNyb3NzIGJh Y2tib25lIHJvdXRlcnMgd2FzIG5vdCBnb2luZyB0bw0KPiA+ID4gYmUgcGFydCBvZiBORCBkcmFm dC4gIEl0IGFwcGVhcmVkIHRoYXQgdGhlIGRyYWZ0IHdhcyBnZXR0aW5nIHdheSB0bw0KPiA+ID4g Y29tcGxpY2F0ZWQgYW5kIHRoZSBXb3JraW5nIEdyb3VwIGRlY2lkZWQgdG8gc2ltcGxpZnkgdGhp bmdzLg0KPiA+ID4NCj4gPiA+IEkgaGF2ZSBub3Qgc2VlbiBtdWNoIHN1cHBvcnQgb24gdGhlIGxp c3QgZm9yIG1ha2luZyB0aGVzZSBjaGFuZ2VzIHRvDQo+ID4gPiBpbmNsdWRlIHRoZSBUSUQgaW4g TkQuDQo+ID4gPg0KPiA+ID4gV2UgbmVlZCB0byBnZXQgdGhpcyBkcmFmdCBjb21wbGV0ZWQuICBJ ZiB0aGVyZSBpcyBhIGxhcmdlICJ1bmhlYXJkIGZyb20iDQo+ID4gPiBzdXBwb3J0IGdyb3VwIGZv ciB0aGVzZSBjaGFuZ2VzLCBwbGVhc2Ugc3BlYWsgdXAgb3Igd2Ugc2hhbGwgbW92ZQ0KPiA+ID4g Zm9yd2FyZCB3aXRoIHRoZSBkcmFmdCBhcyBpdCBpcy4NCj4gPiA+DQo+ID4gPiAJZ2VvZmYNCj4g PiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiBUaHUsIDIwMTEtMDQtMjEgYXQgMDk6 MjcgKzAyMDAsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQo+ID4gPiA+IEhpIEVy aWsNCj4gPiA+ID4NCj4gPiA+ID4gVGhlIFRJRCBpcyBub3QgYSBzdHJvbmcgY291cGxpbmcgYmV0 d2VlbiB0aGUgSDJSIGFuZCB0aGUgUjJSDQo+ID4gPiA+IG9wZXJhdGlvbnMsDQo+ID4gPiBhbmQg aXQgaXMgbm90IGEgY291cGxpbmcgd2l0aCBhIFJQTCB2ZXJzaW9uICBleHBsaWNpdGx5Lg0KPiA+ ID4gPiBJdCBpcyBhbiBhYnN0cmFjdCBpbmZvcm1hdGlvbiB0aGF0IGlmIGRlZmluZWQgcHJvcGVy bHkgY2FuIGJlIHVzZWQNCj4gPiA+ID4gYnkgbWFueQ0KPiA+ID4gZm9ybXMgb3IgUjJSIGludGVy YWN0aW9ucy4NCj4gPiA+ID4gQXMgZGVtb25zdHJhdGVkIGJ5IG9sZGVyIHZlcnNpb25zIG9mIHRo ZSBORCBzcGVjIChCYWNrYm9uZQ0KPiA+ID4gPiBSb3V0ZXIpLCBSUEwsDQo+ID4gPiBhbmQgTUlQ Lg0KPiA+ID4gPg0KPiA+ID4gPiA2TG9XUEFOIE5EIGNhbm5vdCBzY2FsZSBpZiB0aGUgbm9kZSBu ZWVkcyB0byByZWdpc3RlciB0byBhbGwgTEJScy4NCj4gPiA+IDZMb1dQQU4gTkQgZG9lcyBub3Qg ZGVmaW5lIGFueW1vcmUgYW55IExCUiBpbnRlcmFjdGlvbi4NCj4gPiA+ID4gSU9XLCA2TG9QV0FO IE5EIGxvc3QgdGhlIGNhcGFiaWxpdHkgdG8gc2NhbGUgd2hlbiB0aGUgYmFja2JvbmUNCj4gPiA+ ID4gcm91dGVyDQo+ID4gPiBwaWVjZSB3YXMgcmVtb3ZlZCBmcm9tIHRoZSBkcmFmdC4NCj4gPiA+ ID4gV2hpY2ggbWVhbnMgdGhhdCBpdCBsb3N0IGl0cyBjYXBhYmlsaXR5IHRvIGFwcGx5IGluIHRo ZSBkb21haW5zDQo+ID4gPiA+IEknbSBsb29raW5nIGF0DQo+ID4gPiAoaW5kdXN0cmlhbCBhbmQg bWV0ZXJpbmcpLg0KPiA+ID4gPg0KPiA+ID4gPiBXaXRoIHRoZSBUSUQsIHdlIGtub3cgdGhhdCB3 ZSBjYW4gcmVzdG9yZSBzY2FsYWJpbGl0eSBpbiB0aGUNCj4gPiA+ID4gZnV0dXJlLCBhbmQgd2UN Cj4gPiA+IGtub3cgaG93LiBJIGRvIG5vdCBrbm93IG9mIGEgcGxhbiBCLg0KPiA+ID4gPg0KPiA+ ID4gPiBQYXNjYWwNCj4gPiA+ID4gaHR0cDovL3d3dy54dHJhbm9ybWFsLmNvbS93YXRjaC83MDEx MzU3Lw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPiA+ID4gRnJvbTogRXJpayBOb3JkbWFyayBbbWFpbHRvOm5vcmRtYXJrQGFjbS5v cmddDQo+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIEFwcmlsIDIxLCAyMDExIDE6MjUgQU0NCj4g PiA+ID4gPiBUbzogbmljb2xhcy5yaW91QHNjaG5laWRlci1lbGVjdHJpYy5jb20NCj4gPiA+ID4g PiBDYzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgNmxvd3BhbkBpZXRmLm9yZzsgRGlqaywg RXNrbw0KPiA+ID4gPiA+IFN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0gRlc6IFRJRCBpbiBBUk8gW3dh czogIkFkdmVydGl6ZSBvbiBCZWhhbGYiDQo+ID4gPiA+ID4gZmxhZyBpbiBBUk9dDQo+ID4gPiA+ ID4NCj4gPiA+ID4gPiBPbiA0LzIwLzExIDE6MjEgQU0sIG5pY29sYXMucmlvdUBzY2huZWlkZXIt ZWxlY3RyaWMuY29tIHdyb3RlOg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IERlYXIgUGFzY2Fs IGFuZCBhbCwNCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBJIHN1cHBvcnQgdGhlIGlkZWEgb2Yg cmV2aXZpbmcgdGhlIFRJRCBpbiBBUk8gYW5kIERBUi9EQUMuDQo+ID4gPiA+ID4gPiBTdXBwb3J0 aW5nIGEgVElEIGRpcmVjdGx5IGluIHRoZSBub2RlIGluaXRpYXRpbmcgdGhlIGluaXRpYWwNCj4g PiA+ID4gPiA+IE5TIGFwcGVhcnMgbXVjaCBzaW1wbGVyIHRoYW4gdGltZSBzdGFtcGluZyBpbiB0 aGUgcGFyZW50IHJvdXRlci4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhvdyB3b3VsZCB5b3UgbWFr ZSB0aGlzIHdvcmsgaWYgdGhlIHByb3RvY29sIGJldHdlZW4gdGhlIHJvdXRlcnMNCj4gPiA+ID4g PiBpcyBub3QgUlBMdjEsIGJ1dCBzb21lIGZ1dHVyZSB2ZXJzaW9uIG9mIFJQTCBvciBhIGNvbXBs ZXRlbHkNCj4gPiA+ID4gPiBkaWZmZXJlbnQgcm91dGluZyBwcm90b2NvbD8NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IFRoZSBkZWNvdXBsaW5nIG9mIHRoZSBob3N0LXJvdXRlciBpbnRlcmFjdGlvbiBm cm9tIHJvdXRlci1yb3V0ZXINCj4gPiA+ID4gPiBpbnRlcmFjdGlvbiBoYXMgc2VydmVkIHVzIHdl bGwgaW4gdGhlIGhpc3Rvcnkgb2YgdGhlIEludGVybmV0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g ICAgICAgRXJpaw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBBIHNpbXBsZSBhbmQgZWZmaWNpZW50 IG1ldGhvZCB0byBkZXRlY3QgbW9iaWxpdHkgb2YgaG9zdHMNCj4gPiA+ID4gPiA+IGFsb25nIGEg YmFja2JvbmUgb2YgRWRnZSBSb3V0ZXJzIGlzIGFuIGltcG9ydGFudCBmZWF0dXJlIHRvDQo+ID4g PiA+ID4gPiBkZXBsb3kgYmFja2JvbmVzIG9mIEVkZ2UgUm91dGVycyBpbiBCdWlsZGluZ3MgYW5k IHNob3VsZCBiZQ0KPiA+ID4gPiA+ID4gY2xhcmlmaWVkIGJlZm9yZSBjbG9zaW5nIDZMb1dQQU4g V0cuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gQ2hlZXJzLA0KPiA+ID4gPiA+ID4gTmljb2xh cw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gKiJQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPiogRW52b3nDqSBwYXIgOg0KPiA+ID4gPiA+ID4g Nmxvd3Bhbi1ib3VuY2VzQGlldGYub3JnDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gMTgvMDQv MjAxMSAxMDozNw0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBBDQo+ID4g PiA+ID4gPiAJIkRpamssIEVza28iIDxlc2tvLmRpamtAcGhpbGlwcy5jb20+LCAiRXJpayBOb3Jk bWFyayINCj4gPiA+ID4gPiA+IDxub3JkbWFya0BhY20ub3JnPiBjYw0KPiA+ID4gPiA+ID4gCTZs b3dwYW5AaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IE9iamV0DQo+ID4gPiA+ID4gPiAJUmU6IFs2bG93 cGFuXSBGVzogVElEIGluIEFSTyBbd2FzOiAiQWR2ZXJ0aXplIG9uIEJlaGFsZiINCj4gZmxhZw0K PiA+ID4gPiA+ID4gaW4NCj4gPiA+ID4gPiBBUk9dDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+DQo+ID4g PiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEhpIEVza28sIEVyaWsNCj4gPiA+ID4g PiA+DQo+ID4gPiA+ID4gPiBUaGUgZGlzY3Vzc2lvbiBvbiBSUEwgYW5kIGhvc3RzIHNob3VsZCBo YXBwZW4gb24gdGhlIFJQTCBsaXN0DQo+ID4gPiA+ID4gPiB1bmRlciBhIGRpZmZlcmVudCB0b3Bp Yy4gVGhlIHBvaW50IGJlaW5nIGRpc2N1c3NlZCBoZXJlIGlzIHRoaXM6DQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+ID4gVGhlIHJlYWxpdHkgaXMgYWxzbyB0aGF0IHRob3NlIChMTE4pIG5ldHdvcmtz IHdpbGwgbmVlZCB0bw0KPiA+ID4gPiA+ID4gc2NhbGUgdG8gbGFyZ2Ugc3VibmV0cyBpbiBwbGFu dHMsIGJ1aWxkaW5nLCBldGMuLi4gKHNlZSB0aGUNCj4gPiA+ID4gPiA+IHJlcXVpcmVtZW50IGRy YWZ0cyBpbiBST0xMKS4gUmVnaXN0ZXJpbmcgdG8gYWxsIExCUlMgaXMgdG90YWxseQ0KPiBpbXBy YWN0aWNhbC4NCj4gPiA+ID4gPiA+IDZMb1dQQU4gTkQgcmVxdWlyZXMgYSBjb29yZGluYXRpb24g YmV0d2VlbiBMQlJzIGJ1dCBkb2VzIG5vdA0KPiA+ID4gPiA+ID4gc2F5DQo+ID4gPiBob3cgaXQg aGFwcGVucy4NCj4gPiA+ID4gPiA+IFRoaXMgcHJvYmxlbSB3YXMgZGlzY3Vzc2VkIGluIDZMb1dQ QU47IHRoZSBhbnN3ZXIgd2FzIGluDQo+ID4gPiA+ID4gPiBORC0wMXRvMDc7IGFuZCBpdCByZXF1 aXJlcyBhIFRJRCwgZm9yIHRoZSBzYW1lIHJlYXNvbiBhcyBSUEwuDQo+ID4gPiA+ID4gPiBSZW1v dmluZyB0aGUgYmFja2JvbmUgb3BlcmF0aW9uIGFuZCB0aGUgVElEIGZyb20gdGhlIGRyYWZ0IGlz DQo+ID4gPiA+ID4gPiBvc3RyaWNoDQo+ID4gPiBwb2xpY3kuDQo+ID4gPiA+ID4gPg0KPiA+ID4g PiA+ID4gQlRXIDZMb1dQQU4gTkQgbmVlZHMgYSBUSUQgdG8gY29ycmVsYXRlIHRoZSBOUyBhbmQg dGhlIE5BIGFzDQo+ID4gPiA+ID4gPiBhbGwgb3RoZXIgcmVnaXN0cmF0aW9ucyBkbyB3aGVuIHN0 cmljdCBvcmRlcmluZyBpcyBub3QNCj4gPiA+ID4gPiA+IGd1YXJhbnRlZWQgKE1JUCBiZWluZyBh biBleGFtcGxlKS4gU2F5IHRoYXQgZHVlIHRvIHNvbWUNCj4gPiA+ID4gPiA+IGNvbmZpZywgYSBu b2RlIHJlZ2lzdGVycyBhIGxpZmV0aW1lIG9mIFgsIHRoZW4gZGVyZWdpc3RlcnMNCj4gPiA+ID4g PiA+IChsaWZldGltZSAwKSwgdGhlbiByZXJlZ2lzdGVycyAobGlmZXRpbWUgWCkgaW4gYSByYXBp ZCBzZXF1ZW5jZSwgYnV0DQo+IGRvZXMgbm90IGdldCBhbiBhbnN3ZXIgeWV0Lg0KPiA+ID4gPiA+ ID4gVGhlbiBpdCBmaW5hbGx5IGdldHMgMiBBUk9zIGJhY2ssIGxpZmV0aW1lIFggYW5kIDAuIFdo YXQncyB0aGUNCj4gPiA+ID4gPiA+IGZpbmFsIHN0YXRlDQo+ID4gPiBpbiB0aGUgcm91dGVyPw0K PiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEknZCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlcnMgdGhp bmsuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gUGFzY2FsDQo+ID4gPiA+ID4gPiBodHRwOi8v d3d3Lnh0cmFub3JtYWwuY29tL3dhdGNoLzcwMTEzNTcvDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ ID4NCj4gPiA+ID4gPiA+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4g PiAgPiBGcm9tOiBEaWprLCBFc2tvIFttYWlsdG86ZXNrby5kaWprQHBoaWxpcHMuY29tXSAgPiBT ZW50Og0KPiA+ID4gPiA+ID4gTW9uZGF5LCBBcHJpbCAxOCwgMjAxMSAxMDoxOSBBTSAgPiBUbzog RXJpayBOb3JkbWFyazsgUGFzY2FsDQo+ID4gPiA+ID4gPiBUaHViZXJ0DQo+ID4gPiA+ID4gPiAo cHRodWJlcnQpICA+IENjOiA2bG93cGFuQGlldGYub3JnICA+IFN1YmplY3Q6IFJFOiBbNmxvd3Bh bl0gRlc6DQo+ID4gPiA+ID4gPiBUSUQgaW4gQVJPIFt3YXM6ICJBZHZlcnRpemUgb24gQmVoYWxm IiBmbGFnIGluICA+IEFST10gID4gID4NCj4gPiA+ID4gPiA+IEhlbGxvIEVyaWssDQo+ID4gPiA+ ID4gPiA+ICA+IHRha2luZyB0aGUgZGVmaW5pdGlvbiB5b3UgcXVvdGVkOg0KPiA+ID4gPiA+ID4g ID4gJ2hvc3QnIHJlZmVycyB0byBhbiBMTE4gZGV2aWNlIHRoYXQgY2FuIGdlbmVyYXRlIGJ1dCBk b2VzDQo+ID4gPiA+ID4gPiBub3QgZm9yd2FyZCAgPiBSUEwgdHJhZmZpYyAgPiAgPiB0aGUgcXVl c3Rpb24gbWF5IGFyaXNlIHdoYXQNCj4gPiA+ID4gPiA+IGlzICJSUEwgdHJhZmZpYyI/IEl0IGlz IG5vdCBkZWZpbmVkIGluIHRoZSBSUEwgZHJhZnQgID4gaXQNCj4gPiA+ID4gPiA+IHNlZW1zLiBQ YXNjYWwgY2xhcmlmaWVkIHRvIG1lIGl0IGlzIHRyYWZmaWMgYXNzb2NpYXRlZCB0byBhDQo+ID4g PiA+ID4gPiBSUEwgaW5zdGFuY2UsIG5vdCAgPiBuZWNlc3NhcmlseSBSUEwgcHJvdG9jb2wgbWVz c2FnZXMuIFRoaXMNCj4gPiA+ID4gPiA+IG1lYW5zIHRoYXQgYSBob3N0IGNvdWxkIGdlbmVyYXRl ICA+IFJQTCB0cmFmZmljIHdpdGhvdXQgYmVpbmcNCj4gPiA+ID4gPiA+IGF3YXJlIG9mIHRoZSBl eGlzdGVuY2Ugb2YgUlBMIGF0IGFsbC4gU28sIF9ub3RfIGFsbCAgPiBob3N0cyBoYXZlIHRvDQo+ IHNwZWFrIFJQTD8NCj4gPiA+ID4gPiA+ICA+IFRoZSBSUEwgZHJhZnQgZG9lcyBub3QgZXhwbGlj aXRseSBzdGF0ZSBpZiAiaG9zdHMiIGluIGEgUlBMDQo+ID4gPiA+ID4gPiBuZXR3b3JrIGFsd2F5 cyAgPiBzcGVhayBSUEwsIG5ldmVyIHNwZWFrIFJQTCwgb3IgY2FuIGJlIG1peGVkDQo+ID4gPiA+ ID4gPiBSUEwvbm9uLVJQTCBzcGVha2Vycy4NCj4gPiA+ID4gPiA+ICA+DQo+ID4gPiA+ID4gPiAg PiBUYWtpbmcgdGhlIGRlZmluaXRpb24gb2YgJ25vZGUnIGluIHRoZSBSUEwgZHJhZnQ6DQo+ID4g PiA+ID4gPiAgPiAnbm9kZScgcmVmZXJzIHRvIGFueSBSUEwgZGV2aWNlLCBlaXRoZXIgYSBob3N0 IG9yIGEgcm91dGVyDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IHJ1bGVzIG91dCAoPykg dGhlIG9wdGlvbiB0aGF0IGFsbCAiaG9zdHMiIGFyZSBub24tUlBMDQo+ID4gPiA+ID4gPiA+IHNw ZWFrZXJzLA0KPiA+ID4gPiA+ID4gc2luY2UgdGhlcmUgID4gbWF5IGJlIGEgIlJQTCBkZXZpY2Ui IChpLmUuIFJQTC1zcGVha2luZw0KPiA+ID4gPiA+ID4gZGV2aWNlLCBJDQo+ID4gPiA+ID4gPiBh c3N1bWUpIHRoYXQgaXMgYWxzbyBhIGhvc3QuDQo+ID4gPiA+ID4gPiAgPg0KPiA+ID4gPiA+ID4g ID4gSSBjb21tdW5pY2F0ZWQgdGhlc2UgcGVyY2VpdmVkIHVuY2xhcml0aWVzIHRvIFBhc2NhbCBh bmQNCj4gPiA+ID4gPiA+IHRoZSBSRkMgZWRpdG9yIDIgID4gd2Vla3MgYWdvLiBPbmNlIHRoaXMg aXMgY2xlYXIgSSB0aGluayB0aGUNCj4gPiA+ID4gPiA+IHByZXNlbnQgZGlzY3Vzc2lvbiBjYW4g Y29udGludWUuDQo+ID4gPiA+ID4gPiAgPiBBbmQgdGhlbiB0aGVyZSBpcyB0aGUgcmVsYXRlZCBk aXNjdXNzaW9uIG9mIE5EIHN1cHBvcnQgZm9yDQo+ID4gPiA+ID4gPiBzbGVlcHkgZGV2aWNlcywg ID4gdGhlIG9yaWdpbmFsIHRvcGljIG9mIEFuZGVycyA7KSAgPiAgPiBiZXN0DQo+ID4gPiA+ID4g PiByZWdhcmRzLCAgPiAgPiBFc2tvICA+ICA+ICA+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tICA+IEZyb206DQo+ID4gPiA+ID4gPiA2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzo2bG93cGFuLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+ID4gPiA+ID4gPiA+IEJlaGFsZiBPZiBF cmlrIE5vcmRtYXJrICA+IFNlbnQ6IEZyaWRheSAxNSBBcHJpbCAyMDExIDE4OjM5ICA+IFRvOg0K PiA+ID4gPiA+ID4gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAgPiBDYzogNmxvd3BhbkBpZXRm Lm9yZyAgPiBTdWJqZWN0OiBSZToNCj4gPiA+ID4gPiA+IFs2bG93cGFuXSBGVzogVElEIGluIEFS TyBbd2FzOiAiQWR2ZXJ0aXplIG9uIEJlaGFsZiIgZmxhZyBpbg0KPiA+ID4gPiA+ID4gPiBBUk9d DQo+ID4gPiA+ID4gPiA+ICA+IE9uIDQvMTQvMTEgMTE6NDMgUE0sIFBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCkgd3JvdGU6DQo+ID4gPiA+ID4gPiAgPg0KPiA+ID4gPiA+ID4gID4gPiBSUEwgY2Fu IGRvIHdoYXQgYWxsIGNsYXNzaWNhbCBJR1BzIGNhbiBkbyBXUlQgaG9zdHMuIFRoYXQNCj4gPiA+ ID4gPiA+IGlzIGFzIGxvbmcgID4gPiBhcyB0aGUgaG9zdCBhZGRyZXNzIGJlbG9uZ3MgdG8gdGhl IHJvdXRlcidzDQo+ID4gPiA+ID4gPiBwcmVmaXggYW5kIHN0YXlzIGF0dGFjaGVkICA+ID4gdG8g dGhhdCByb3V0ZXIuDQo+ID4gPiA+ID4gPiAgPg0KPiA+ID4gPiA+ID4gID4gSSBqdXN0IHJlYWxp emVkIHRoYXQgd2UgbWlnaHQgYmUgdGFsa2luZyBhYm91dCBhIGRpZmZlcmVudA0KPiA+ID4gPiA+ ID4gZGVmaW5pdGlvbiBvZiAiaG9zdCIuDQo+ID4gPiA+ID4gPiAgPiBXaGF0IEkgbWVhbiBieSAi aG9zdCIgaXMgYSBub2RlIHdoaWNoIGRvZXMgbm90IHBhcnRpY2lwYXRlDQo+ID4gPiA+ID4gPiBp biBhIHJvdXRpbmcgID4gcHJvdG9jb2wsIGFuZCBkb2VzIG5vdCBmb3J3YXJkIHBhY2tldHMgKGV4 Y2VwdA0KPiA+ID4gPiA+ID4gcGFja2V0cyBleHBsaWNpdGx5IGFkZHJlc3NlZCAgPiB0byBpdHNl bGYgdXNpbmcgZS5nLiwgYSByb3V0aW5nIGhlYWRlcikuDQo+ID4gPiA+ID4gPiAgPg0KPiA+ID4g PiA+ID4gID4gSG93ZXZlciwgUlBMIGhhcyBhIGRpZmZlcmVudCBkZWZpbml0aW9uOg0KPiA+ID4g PiA+ID4gID4gJ2hvc3QnIHJlZmVycyB0byBhbiBMTE4gZGV2aWNlIHRoYXQgY2FuIGdlbmVyYXRl IGJ1dCBkb2VzDQo+ID4gPiA+ID4gPiBub3QgZm9yd2FyZCAgPiBSUEwgdHJhZmZpYyAgPiAgPiBC YXNpY2FsbHkgcGVyIHRoZSBSUEwNCj4gPiA+ID4gPiA+IGRlZmluaXRpb24gdGhlcmUgaXMgbm8g c3VjaCB0aGluZyBhcyBhIG5vZGUgd2hpY2ggZG9lcyAgPiBub3QNCj4gPiA+ID4gPiA+IHBhcnRp Y2lwYXRlIGluIHRoZSBSUEwgcHJvdG9jb2wuDQo+ID4gPiA+ID4gPiAgPiBJTUhPIHdoYXQgaXMg aW4gUlBMIHNob3VsZCBoYXZlIGJlZW4gZGVmaW5lZCBhcyBhDQo+ID4gPiA+ID4gPiBub24tZm9y d2FyZGluZyBub2RlLCBzbyAgPiB0aGF0IHdlIGNhbiBoYXZlIGEgc2FuZSBkaXNjdXNzaW9uDQo+ ID4gPiA+ID4gPiB3aXRob3V0IGdldHRpbmcgZW50YW5nbGVkIGluIHRlcm1pbm9sb2d5ICA+IGlz c3Vlcy4NCj4gPiA+ID4gPiA+ICA+DQo+ID4gPiA+ID4gPiAgPiBXaGljaCBkZWZpbml0aW9uIG9m ICJob3N0IiBhcmUgeW91IHVzaW5nIGFib3ZlPw0KPiA+ID4gPiA+ID4gID4NCj4gPiA+ID4gPiA+ ICA+IFBlciB0aGUgUlBMIGRlZmluaXRpb24gdGhlcmUgaXMgbm8gbmVlZCBmb3IgNmxvd3Bhbi1u ZCwNCj4gPiA+ID4gPiA+IHNpbmNlIGFsbCBub2RlcyB3aWxsICA+IHNwZWFrIFJQTC4gVGhpcyBp cyByYXRoZXIgY29uZnVzaW5nLCBkb24ndCB5b3UNCj4gdGhpbms/DQo+ID4gPiA+ID4gPiAgPg0K PiA+ID4gPiA+ID4gID4gRXJpaw0KPiA+ID4gPiA+ID4gID4NCj4gPiA+ID4gPiA+ICA+ID4gV2hl biB0aGUgdG9wb2xvZ3kgYmVjb21lcyBtdWx0aWxpbmsgc3VibmV0IGFuZCBtb2JpbGl0eQ0KPiA+ ID4gPiA+ID4gaXMgcmVxdWlyZWQgID4gPiB0aGVuIGl0IGlzIGEgbmV3IHByb2JsZW0gZW50aXJl bHksIGFuZCBOTywNCj4gPiA+ID4gPiA+IDQ4NjEgaXMgbm90IGEgc3VpdGFibGUgID4gPiBpbnRl cmFjdGlvbiB3aXRoIHRoZSByb3V0ZXIgdG8NCj4gPiA+ID4gPiA+IGFsbG93IHRoZSByb3V0ZXIg dG8gcmVkaXN0cmlidXRlIGEgaG9zdCByb3V0ZS4NCj4gPiA+ID4gPiA+ICA+ID4gQmVjYXVzZSB0 aGUgbmVpZ2hib3IgY2FjaGUgdGhhdCA0ODYxIGJ1aWxkcyBpcyBub3QgYSBvZg0KPiA+ID4gPiA+ ID4gdGhlIHNhbWUNCj4gPiA+ID4gPiA+ID4gPiBuYXR1cmUgYXMgdGhlIGJpbmRpbmcgdGFibGUg dGhhdCA2TG9XUEFOIE5EIGJ1aWxkcy4NCj4gPiA+ID4gPiA+ID4gPiBBbm90aGVyIHRoaW5nDQo+ ID4gPiA+ID4gPiB0aGF0ICA+ID4gNkxvV1BBTiBORCBmYWlscyB0byBleHByZXNzIGNvcnJlY3Rs eS4gSSBwcm9wb3NlZA0KPiA+ID4gPiA+ID4gdGV4dCB0byBleHBsYWluIHRoYXQgID4gPiAoYXR0 YWNoZWQpIGJ1dCBpdCB3YXMgbm90DQo+ID4gPiA+ID4gPiBjb25zaWRlcmVkLCBjb250cmlidXRp bmcgdG8gdGhlIGlsbHVzaW9uICA+ID4gdGhhdCBhIGNhY2hlIGlzIGEgdGFibGUuDQo+ID4gPiA+ ID4gPiAgPiA+DQo+ID4gPiA+ID4gPiAgPiA+IFRoZSByZWFsaXR5IGlzIGFsc28gdGhhdCB0aG9z ZSBuZXR3b3JrcyB3aWxsIG5lZWQgdG8NCj4gPiA+ID4gPiA+IHNjYWxlIHRvIGxhcmdlICA+ID4g c3VibmV0cyBpbiBwbGFudHMsIGJ1aWxkaW5nLCBldGMuLi4gKHNlZQ0KPiA+ID4gPiA+ID4gdGhl IHJlcXVpcmVtZW50IGRyYWZ0cyBpbiAgPiA+IFJPTEwpLiBSZWdpc3RlcmluZyB0byBhbGwgTEJS Uw0KPiA+ID4gPiA+ID4gaXMgdG90YWxseQ0KPiA+ID4gaW1wcmFjdGljYWwuDQo+ID4gPiA+ID4g PiA2TG9XUEFOIE5EICA+ID4gcmVxdWlyZXMgYSBjb29yZGluYXRpb24gYmV0d2VlbiBMQlJzIGJ1 dCBkb2VzDQo+ID4gPiA+ID4gPiBub3Qgc2F5IGhvdyBpdCBoYXBwZW5zLg0KPiA+ID4gPiA+ID4g ID4gPiBUaGlzIHByb2JsZW0gd2FzIGRpc2N1c3NlZCBpbiA2TG9XUEFOOyB0aGUgYW5zd2VyIHdh cyBpbg0KPiA+ID4gPiA+ID4gTkQtMDF0bzA3OyAgPiA+IGFuZCBpdCByZXF1aXJlcyBhIFRJRCwg Zm9yIHRoZSBzYW1lIHJlYXNvbiBhcyBSUEwuDQo+ID4gPiA+ID4gPiBSZW1vdmluZyB0aGUgID4g PiBiYWNrYm9uZSBvcGVyYXRpb24gYW5kIHRoZSBUSUQgZnJvbSB0aGUNCj4gPiA+ID4gPiA+IGRy YWZ0IGlzIG9zdHJpY2gNCj4gPiA+ID4gPiBwb2xpY3kuDQo+ID4gPiA+ID4gPiAgPiA+DQo+ID4g PiA+ID4gPiAgPiA+IFJQTCBhbHJlYWR5IGFkYXB0ZWQgdG8gdGhlIG5ldyByZWFsaXR5IG9mIGxh cmdlIG11bHRpbGluaw0KPiA+ID4gPiA+ID4gc3VibmV0IHdpdGggID4gPiBpbm5lciBtb2JpbGl0 eS4gUGxhY2luZyB0aGUgYmxhbWUgb24gUlBMIGlzDQo+ID4gPiA+ID4gPiBhbm90aGVyIGlsbHVz aW9uaXN0IHRyaWNrLg0KPiA+ID4gPiA+ID4gID4gPiBBbmQgdGhpcyBpcyBub3QgUlBMIGxhc3Qg Y2FsbC4NCj4gPiA+ID4gPiA+ICA+ID4NCj4gPiA+ID4gPiA+ICA+ID4gQlRXIDZMb1dQQU4gTkQg bmVlZHMgYSBUSUQgdG8gY29ycmVsYXRlIHRoZSBOUyBhbmQgdGhlIE5BDQo+ID4gPiA+ID4gPiBh cyBhbGwgb3RoZXIgID4gPiByZWdpc3RyYXRpb25zIGRvIHdoZW4gc3RyaWN0IG9yZGVyaW5nIGlz IG5vdA0KPiA+ID4gPiA+ID4gZ3VhcmFudGVlZCAoTUlQIGJlaW5nIGFuICA+ID4gZXhhbXBsZSku IFNheSB0aGF0IGR1ZSB0byBzb21lDQo+ID4gPiA+ID4gPiBjb25maWcsIGEgbm9kZSByZWdpc3Rl cnMgYSBsaWZldGltZSBvZiAgPiA+IFgsIHRoZW4NCj4gPiA+ID4gPiA+IGRlcmVnaXN0ZXJzIChs aWZldGltZSAwKSwgdGhlbiByZXJlZ2lzdGVycyAobGlmZXRpbWUgWCkgaW4gYQ0KPiA+ID4gPiA+ ID4gPiA+IHJhcGlkIHNlcXVlbmNlLCBidXQgZG9lcyBub3QgZ2V0IGFuIGFuc3dlciB5ZXQuIFRo ZW4gaXQNCj4gPiA+ID4gPiA+IGZpbmFsbHkgZ2V0cw0KPiA+ID4gPiA+ID4gMg0KPiA+ID4gPiA+ ID4gID4gPiBBUk9zIGJhY2ssIGxpZmV0aW1lIFggYW5kIDAuIFdoYXQncyB0aGUgZmluYWwgc3Rh dGUgaW4gdGhlIHJvdXRlcj8NCj4gPiA+ID4gPiA+ICA+ID4NCj4gPiA+ID4gPiA+ICA+ID4gSXQg c2VlbXMgd2UgY2FuIG5ldmVyIGFncmVlIG9uIGFueSBvZiB0aGlzLiBJJ2QgbGlrZSB0bw0KPiA+ ID4gPiA+ID4gaGVhciB3aGF0DQo+ID4gPiA+ID4gPiA+ID4gb3RoZXJzIHRoaW5rLg0KPiA+ID4g PiA+ID4gID4gPg0KPiA+ID4gPiA+ID4gID4gPiBQYXNjYWwNCj4gPiA+ID4gPiA+ICA+ID4gaHR0 cDovL3d3dy54dHJhbm9ybWFsLmNvbS93YXRjaC83MDExMzU3Lw0KPiA+ID4gPiA+ID4gID4gPg0K PiA+ID4gPiA+ID4gID4gPg0KPiA+ID4gPiA+ID4gID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gID4gPj4gRnJvbToNCj4gPiA+ID4gPiA+IDZsb3dwYW4tYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOjZsb3dwYW4tDQo+ID4gPiA+ID4gYm91bmNlc0BpZXRmLm9yZ10NCj4gPiA+ID4gPiA+ IE9uICA+ID4+IEJlaGFsZiBPZiBFcmlrIE5vcmRtYXJrICA+ID4+IFNlbnQ6IEZyaWRheSwgQXBy aWwgMTUsDQo+ID4gPiA+ID4gPiAyMDExDQo+ID4gPiA+ID4gPiAxOjMwIEFNICA+ID4+IFRvOiA2 bG8+PiAnNmxvd3BhbicNCj4gPiA+ID4gPiA+ICA+ID4+IFN1YmplY3Q6IFJlOiBbNmxvd3Bhbl0g RndkOiBSZTogIkFkdmVydGl6ZSBvbiBCZWhhbGYiDQo+ID4gPiA+ID4gPiBmbGFnIGluIEFSTyAg PiA+PiAgPiA+PiAgPiA+PiBPbiA0LzEzLzExIDEyOjUzIEFNLCBQYXNjYWwNCj4gPiA+ID4gPiA+ IFRodWJlcnQNCj4gPiA+ID4gPiA+IChwdGh1YmVydCkNCj4gPiA+ID4gPiA+IHdyb3RlOg0KPiA+ ID4gPiA+ID4gID4gPj4+IEhpIEVyaWs6DQo+ID4gPiA+ID4gPiAgPiA+Pj4NCj4gPiA+ID4gPiA+ ICA+ID4+PiBUaGUgUlBMIChEQU8pIHNlcXVlbmNlIG51bWJlciBhbGxvd3MgdGhlIG5vZGUgdG8N Cj4gPiA+ID4gPiA+IGluY3JlbWVudCByYXBpZGx5ICA+ID4+PiBpbiBjYXNlIG9mIHJhcGlkIGNo YW5nZXMgYW5kIHRoZW4NCj4gPiA+ID4gPiA+IGxhemlseSB3aGVuIHRoZSBzaXR1YXRpb24gaXMg ID4gPj4+IHN0YWJsZSBhbmQgREFPIGFyZSBzY2FyY2UuDQo+ID4gPiA+ID4gPiBUaGUgaW5jcmVh c2UgaXMgc3RyaWN0bHkgbW9ub3Rvbm91cyB3aGljaCAgPiA+ICA+ID4+PiBpcyBjcml0aWNhbCB0 byB1cy4NCj4gPiA+ID4gPiA+ICA+ID4+Pg0KPiA+ID4gPiA+ID4gID4gPj4+IEEgdGltZSBzdGFt cCBpbXBvc2VzIGEgc3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhlDQo+IHJvdXRlcnMuDQo+ID4g PiA+ID4gPiBXZSBkbyAgPiA+Pj4gbm90IGhhdmUgc3VjaCBtZWNoYW5pc20gaW4gUlBMLiBBIHRp bWUgdW5pdCAoYQ0KPiA+ID4gPiA+ID4gZ3JhbnVsYXJpdHkpIG11c3QgYmUgID4gPj4+IGFncmVl ZCB1cG9uLiBXaXRoaW4gdGhhdCB1bml0LA0KPiA+ID4gPiA+ID4gbW92ZW1lbnRzIGdvIHVuZGV0 ZWN0ZWQgc28gdGhlIHRpbWUgID4gPj4+IHVuaXQgbXVzdCBiZSB0aGluDQo+ID4gPiA+ID4gPiBn cmFpbmVkDQo+ID4gPiB0byBjb3ZlciByYXBpZCBjaGFuZ2VzLg0KPiA+ID4gPiA+ID4gWWV0LCBk ZXBlbmRpbmcgb24gID4gPj4+IHRoZSBtZWRpdW0sIHRoZSB0aW1lIHVuaXQsIGFuZCB0aGUNCj4g PiA+ID4gPiA+IHNpemUgb2YgdGhlIG5ldHdvcmssIGl0IGlzIG5vdCAgPiA+Pj4gbmVjZXNzYXJp bHkNCj4gPiA+ID4gPiA+IGVhc3kvcG9zc2libGUgdG8gZ3VhcmFudGVlIGEgc3RyaWN0bHkgbW9u b3Rvbm91cyB2YWx1ZSAgPiA+Pj4NCj4gPiA+ID4gPiA+IHdpdGggYSB0aGluIGdyYWluZWQgdGlt ZSB1bml0LiBBbmQgd2UgaGF2ZSBsaW1pdGVkIHNwYWNlICgyDQo+ID4gPiA+ID4gPiBvY3RldHMp DQo+ID4gPiA+ID4gPiAgPiA+Pj4gYW5kIGhhdmUgdG8gZGVhbCB3aXRoIHdyYXAgYXJvdW5kLCB3 aGljaCBkaXZpZGVzIHRoZQ0KPiA+ID4gPiA+ID4gc3BhY2UgYnkgYXQgID4gPiBsZWFzdCAzLg0K PiA+ID4gPiA+ID4gID4gPj4+DQo+ID4gPiA+ID4gPiAgPiA+Pj4gU28gUlBMIHdlbnQgZm9yIGEg c2VxdWVuY2UgbnVtYmVyLg0KPiA+ID4gPiA+ID4gID4gPj4NCj4gPiA+ID4gPiA+ICA+ID4+IEJ1 dCB0aGUgdW5zdGF0ZWQgYXNzdW1wdGlvbiB0aGF0IFJQTCBtYWRlIGlzIHRoYXQgYWxsDQo+ID4g PiA+ID4gPiBob3N0LXRvLXJvdXRlciAgPiA+PiBwcm90b2NvbHMgaGF2ZSB0byBub3cgYmUgUlBM IGF3YXJlLiBUaGF0DQo+ID4gPiA+ID4gPiBkb2Vzbid0IHNvdW5kIGxpa2UgZ29vZCAgPiA+IGRl c2lnbi4NCj4gPiA+ID4gPiA+ICA+ID4+IEEgaG9zdCBpc24ndCBhd2FyZSBvZiB3aGV0aGVyIHRo ZSByb3V0ZXJzIHNwZWFrIElTLUlTIG9yDQo+ID4gPiA+ID4gPiBPU1BGLCBzbyB3aHkgID4gPj4g ZG8gdGhlIGhvc3RzIG5lZWQgdG8gYmUgYXdhcmUgb2YgUlBMIGJ5DQo+ID4gPiA+ID4gPiBwYXNz aW5nIHNvbWUgVElEIGFyb3VuZD8NCj4gPiA+ID4gPiA+ICA+ID4+DQo+ID4gPiA+ID4gPiAgPiA+ Pj4gSSB0aGluayBORCBoYXMgdGhlIHNhbWUgbmVlZCBhcyBNSVAgZm9yIGEgVElEID09IFNlcXVl bmNlICMNCj4gLg0KPiA+ID4gPiA+ID4gV2UgID4gPj4+IGtub3cgb2YgTUlQOyBXZSBrbm93IG9m IFJQTC4gV2Uga25vdyBvZiB0aGUNCj4gYmFja2JvbmUNCj4gPiA+ID4gPiA+IHJvdXRlcg0KPiA+ ID4gPiA+ID4gPiA+Pj4gb3BlcmF0aW9uLiBXZSBrbm93IHdlJ2xsIG5lZWQgdGhlIFRJRCBhbmQg d2Uga25vdw0KPiA+ID4gPiA+ID4gPiA+Pj4gZXhhY3RseSB3aHkuIEkgdGhpbmsgd2Ugc2hvdWxk IGhhdmUgaXQgaW4gdGhlIDZMb3dQQU4gTkQNCj4gPiA+ID4gPiA+ID4gPj4+IHNwZWMgcmlnaHQg YXdheSB0bw0KPiA+ID4gPiA+ID4gYXZvaWQgID4gPj4+IGludGVyb3AgaXNzdWVzIHdoZW4gd2Ug YWRkIFJQTCBhbmQgQlIgb3BlcmF0aW9ucy4NCj4gPiA+ID4gPiA+ICA+ID4+DQo+ID4gPiA+ID4g PiAgPiA+PiBJIGRvbid0IHNlZSBhIG5lZWQgaW4gNmxvd3Bhbi1uZCBmb3IgYSBUSUQ7IHRoZSBw cm90b2NvbA0KPiA+ID4gPiA+ID4gd29ya3MgZmluZSAgPiA+IHdpdGhvdXQgaXQuDQo+ID4gPiA+ ID4gPiAgPiA+PiBJIHRoaW5rIFJQTCBuZWVkcyB0byBiZSBpbXByb3ZlZCB0byBkZWFsIHdpdGgg cmVhbGl0eS4NCj4gPiA+ID4gPiA+IElzbid0IHRoZXJlIGEgID4gPj4gZGVzaXJlIGZvciBSUEwg dG8gaGFuZGxlIDQ4NjEgaG9zdHM/IFRob3NlDQo+ID4gPiA+ID4gPiB3b3VsZCBuZXZlciBrbm93 IGFib3V0IGEgID4gPiBUSUQuDQo+ID4gPiA+ID4gPiAgPiA+Pg0KPiA+ID4gPiA+ID4gID4gPj4g RXJpaw0KPiA+ID4gPiA+ID4gID4gPj4NCj4gPiA+ID4gPiA+ICA+ID4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gPiAgPiA+PiA2bG93 cGFuIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+ID4gID4gPj4gNmxvd3BhbkBpZXRmLm9yZw0KPiA+ ID4gPiA+ID4gID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93 cGFuDQo+ID4gPiA+ID4gPiAgPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPiA+ID4gPiAgPiA+IDZsb3dwYW4gbWFpbGluZyBsaXN0DQo+ID4g PiA+ID4gPiAgPiA+IDZsb3dwYW5AaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ICA+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuDQo+ID4gPiA+ID4gPiAgPiA+DQo+ ID4gPiA+ID4gPiAgPg0KPiA+ID4gPiA+ID4gID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ICA+IDZsb3dwYW4gbWFpbGluZyBsaXN0 DQo+ID4gPiA+ID4gPiAgPiA2bG93cGFuQGlldGYub3JnDQo+ID4gPiA+ID4gPiAgPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCj4gPiA+ID4gPiA+ICA+DQo+ ID4gPiA+ID4gPiAgPiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBt YXkgYmUNCj4gPiA+ID4gPiA+IGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSAgPiBwcm90ZWN0ZWQg dW5kZXIgYXBwbGljYWJsZSBsYXcuDQo+ID4gPiA+ID4gPiBUaGUgbWVzc2FnZSBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSAgPiBhZGRyZXNzZWUocykuIElmIHlvdQ0KPiA+ID4gPiA+ID4gYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCAgPg0K PiA+ID4gPiA+ID4gdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YNCj4gPiA+ID4gPiA+IHRoaXMgbWVzc2FnZSBpcyAgPiBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmDQo+ID4gPiA+ID4gPiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCAgPiBwbGVhc2UgY29udGFjdCB0aGUNCj4gPiA+ID4g PiA+IHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2YgdGhl ICA+IG9yaWdpbmFsDQo+IG1lc3NhZ2UuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+IDZs b3dwYW4gbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiA2bG93cGFuQGlldGYub3JnDQo+ID4gPiA+ ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPg0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gX19f X19fX19fX19fDQo+ID4gPiA+ID4gPiBUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgYnkgdGhl IE1lc3NhZ2VMYWJzIEVtYWlsIFNlY3VyaXR5DQo+ID4gPiBTeXN0ZW0uDQo+ID4gPiA+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gX19fX19fX19fX19fDQo+ID4gPiA+ID4g Pg0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+ID4gPiA2bG93cGFuIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA2bG93cGFu QGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Nmxvd3Bhbg0KPiA+ID4NCj4gPg0KPiANCg0K From pthubert@cisco.com Fri Apr 22 00:30:44 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1BB49E06A7 for <6lowpan@ietfc.amsl.com>; Fri, 22 Apr 2011 00:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.011 X-Spam-Level: X-Spam-Status: No, score=-9.011 tagged_above=-999 required=5 tests=[AWL=1.588, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcAdoxV9M2Hm for <6lowpan@ietfc.amsl.com>; Fri, 22 Apr 2011 00:30:43 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 32771E0687 for <6lowpan@ietf.org>; Fri, 22 Apr 2011 00:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1467; q=dns/txt; s=iport; t=1303457443; x=1304667043; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=o9cohA0ZxEjEqb+J+jRVsaIu+0ERq+wUPamSDTj+PRU=; b=gs4uHxWQ6ddyjZUPMRGkaWI6KYA7Y2cgguOcImyk55CO3Jn9ryEv8umo wvzdIxHgXS2+1KwjI7EPxSPi9dQqQzyEZkzsmAgLN1LCXrCQ9g6v4HKk+ XPtLP3md7Nwe0wdlaV/b0K8yCeHnAaYAe+hPd8eHd6kWOBrF57j57HwNY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcEAF4usU2Q/khLgWdsb2JhbAClXhQBARYmJaYJnF2FdgSSOw X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="26718010" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 22 Apr 2011 07:30:41 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3M7Uedw031791; Fri, 22 Apr 2011 07:30:40 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 09:30:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 09:30:37 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0470FA25@XMB-AMS-107.cisco.com> In-Reply-To: <4DB0A442.4010905@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: AcwAbKrVoBRI44dBSdWftn+cgFdEKQAUWQqA References: <4DB0A442.4010905@acm.org> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , X-OriginalArrivalTime: 22 Apr 2011 07:30:40.0569 (UTC) FILETIME=[2E7E6290:01CC00BF] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 07:30:44 -0000 Hello Nicolas, Erik, > > > > As Pascal answered in his post, the TID is not particularly coupled > > with RPLv1. The TID is just an extra information provided by the node > > during ND registration which dramatically simplifies node localization > > but also enable DAD across a backbone of Edge Routers advertizing the > same prefix. > > Which alternative solution would you suggest for DAD? >=20 > DAD works fine with what we have in ARO. > If the same EUI-64 (re)registers the same IPv6 address, then it is not a > duplicate. > If a different EUI-64 tries to registers an IPv6 address (already registered with > some other EUI-64), then it is a duplicate. > That is independent whether the check is done in a 6LR or 6LBR. >=20 > What do you see as the problem with DAD? Can you provide an example of > what doesn't work with 6lowpan-nd? [Pascal] TID is not related to uniqueness/DAD. It is related to movement. A node that stays attached to the same router would not need it. Tragically, LLNs are not like that. TID enables to invalidate states that have a deprecated sequence. Typically if you want to redistribute an ND registration into something else then you need such thing. I listed in another post 3 issues with ND that can be fixed with a TID (scalability, out-of-order, and anti-replay). DAD is not in the list.=20 DAD works as long as the EUI is unique, which is an assumption we accepted for this work. Pascal From pthubert@cisco.com Fri Apr 22 00:37:41 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76507E06AA for <6lowpan@ietfc.amsl.com>; Fri, 22 Apr 2011 00:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.08 X-Spam-Level: X-Spam-Status: No, score=-9.08 tagged_above=-999 required=5 tests=[AWL=1.519, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGK+Ext5sX6k for <6lowpan@ietfc.amsl.com>; Fri, 22 Apr 2011 00:37:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 961D7E0679 for <6lowpan@ietf.org>; Fri, 22 Apr 2011 00:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1523; q=dns/txt; s=iport; t=1303457860; x=1304667460; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=wp31cOXlNpJF2XDPE4K7YmgUz27DzVX3cukNAN8MH5c=; b=TVMhJnFncdU6JgetxI4dRBnJY8QxGmp/1JU4RludydTPrJGzNFphek8j v6dwAQFTapd7jBaOcOzjERTlIC8KbYxScJuE/S8iZRDdtjhB50itVAxJj GqMa+yKkV9dbZQqbPG38g5s/Vs6UkmvfDvBLomdewJ3DoWfyAuD9MUb0V 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcEAHwvsU2Q/khMgWdsb2JhbAClXhQBARYmJYhwnRicXYV2BJI7 X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="26718732" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 22 Apr 2011 07:37:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3M7bdXl019690; Fri, 22 Apr 2011 07:37:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 09:37:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 09:37:37 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0470FA28@XMB-AMS-107.cisco.com> In-Reply-To: <4DB0A442.4010905@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: AcwAbKrVoBRI44dBSdWftn+cgFdEKQAUoWtA References: <4DB0A442.4010905@acm.org> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , X-OriginalArrivalTime: 22 Apr 2011 07:37:39.0697 (UTC) FILETIME=[28503E10:01CC00C0] Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 07:37:41 -0000 >=20 > > The TID can fit in "reserved" field of ARO/DAR/DAC and thus can come > > at no cost. >=20 > FWIW Complexity is the true cost, because unneeded complexity leads to > non-interoperability for no benefit. >=20 > > Thanks to the lollipop mechanism defined in 6lowpan-nd-07 the TID can > > be implemented even in the most constrained devices which might not be > > able to consistently increment the TID. >=20 > The lollipop stuff is not proven technology. It existed in an early draft of > OSPF, and was replaced. I assume it was replaced for a reason. >=20 [Pascal] that's FUD.=20 OSPF does not use lollipop because it is not the appropriate tool, not because it is a bad tool. Lollipop has evolved. RPL has one that avoids the well-known pitfalls like s1 Any proven TID scheme would require stable storage on the device, so that > the device doesn't accidentally reuse old TIDs too soon. I don't think we want > to require that capability on all 6lowpan hosts, just because it is perceived too > hard to have RPL keep track of things. [Pascal] Nicolas 's point exactly. If the user of the TID has an appropriate mechanism (like a modern lollipop) then the device is allowed to reboot and loose states. So we are not requiring persistent memory. And you can't just avoid something simple in the host by pushing something undeterminably complex in the router, because a RPL router is usually the exact same hardware with the same constraints as the host. Pascal From nordmark@sonic.net Thu Apr 14 16:26:32 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3BD7AE07A4 for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1OyUTu9clN6 for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:26:31 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id 794BBE0794 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 16:26:31 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3ENQRWJ019452 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 16:26:28 -0700 Message-ID: <4DA782BF.6030301@sonic.net> Date: Thu, 14 Apr 2011 16:26:55 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <4DA4BB1E.2050002@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 Apr 2011 10:47:15 -0700 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:26:32 -0000 On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > Hi Erik: > > The RPL (DAO) sequence number allows the node to increment rapidly in > case of rapid changes and then lazily when the situation is stable and > DAO are scarce. The increase is strictly monotonous which is critical to > us. > > A time stamp imposes a synchronization between the routers. We do not > have such mechanism in RPL. A time unit (a granularity) must be agreed > upon. Within that unit, movements go undetected so the time unit must be > thin grained to cover rapid changes. Yet, depending on the medium, the > time unit, and the size of the network, it is not necessarily > easy/possible to guarantee a strictly monotonous value with a thin > grained time unit. And we have limited space (2 octets) and have to deal > with wrap around, which divides the space by at least 3. > > So RPL went for a sequence number. But the unstated assumption that RPL made is that all host-to-router protocols have to now be RPL aware. That doesn't sound like good design. A host isn't aware of whether the routers speak IS-IS or OSPF, so why do the hosts need to be aware of RPL by passing some TID around? > I think ND has the same need as MIP for a TID == Sequence # . We know of > MIP; We know of RPL. We know of the backbone router operation. We know > we'll need the TID and we know exactly why. I think we should have it in > the 6LowPAN ND spec right away to avoid interop issues when we add RPL > and BR operations. I don't see a need in 6lowpan-nd for a TID; the protocol works fine without it. I think RPL needs to be improved to deal with reality. Isn't there a desire for RPL to handle 4861 hosts? Those would never know about a TID. Erik From nordmark@sonic.net Thu Apr 14 16:29:14 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5E33E0794 for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCUmxv5GRB8a for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:29:13 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id 7403AE06C4 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 16:29:13 -0700 (PDT) Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3ENTCJB021176 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 16:29:12 -0700 Message-ID: <4DA78364.3090605@sonic.net> Date: Thu, 14 Apr 2011 16:29:40 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: <87bp09roz6.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87bp09roz6.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 Apr 2011 10:47:15 -0700 Subject: Re: [6lowpan] which addresses can be registered? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:29:14 -0000 On 4/14/11 5:34 AM, Richard Kelsey wrote: > As far as I can tell from the 6LoWPAN ND draft, the only > addresses that cannot be registered are multicast addresses. > Is this correct? For example, can a link-local address be > registered? Can any prefix be used when registering with > any 6LBR? The draft doesn't forbid registering a link-local address, but it also doesn't require it. For multicast there is MLD, which is used to tell routers which multicast addresses the hosts want to receive. If there are applications which use multicast then it would make sense to use MLD. Erik From nordmark@sonic.net Wed Apr 20 16:19:48 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A6C04E0721 for <6lowpan@ietfc.amsl.com>; Wed, 20 Apr 2011 16:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62gQRLDneISt for <6lowpan@ietfc.amsl.com>; Wed, 20 Apr 2011 16:19:46 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id 86901E0759 for <6lowpan@ietf.org>; Wed, 20 Apr 2011 16:19:46 -0700 (PDT) Received: from [128.107.115.155] ([128.107.115.155]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3KNJf5Q030949 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 16:19:42 -0700 Message-ID: <4DAF6A31.1030800@sonic.net> Date: Wed, 20 Apr 2011 16:20:17 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D0459F3AA@XMB-AMS-107.cisco.com> <4DA87488.6030606@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0464F7BB@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0464F7BB@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 Apr 2011 10:47:15 -0700 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:19:48 -0000 On 4/18/11 1:37 AM, Pascal Thubert (pthubert) wrote: > Hi Esko, Erik > > The discussion on RPL and hosts should happen on the RPL list under a > different topic. The point being discussed here is this: But it is hard to have that discussion if we don't know whether the 'hosts' are participating in RPL or not. For this email I assume they are not. > The reality is also that those (LLN) networks will need to scale to > large subnets in plants, building, etc... (see the requirement drafts in > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > requires a coordination between LBRs but does not say how it happens. > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and > it requires a TID, for the same reason as RPL. Removing the backbone > operation and the TID from the draft is ostrich policy. Clearly the backend of the network needs to be able to handle changes in terms of the host's location, whether the backend is a set of LBRs or a set of RPL speakers. But that doesn't mean that the hosts need to be burdened with carrying a TID around. Different backends might use different mechanisms to serialize the changes to the host's location. For example, when I go to an ATM machine to take out some money from my bank, there might be transaction IDs, timestamps, and many other wonderful things happening in the backend ATM network and the bank's database. But that doesn't mean that I as a user of the ATM has to retain a transaction ID that I key into the ATM. I think we can have the same degree of decoupling between 6lowpan and the routing protocols, and we do between the ATM user and the bank's database. > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > registrations do when strict ordering is not guaranteed (MIP being an > example). Say that due to some config, a node registers a lifetime of X, > then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid > sequence, but does not get an answer yet. Then it finally gets 2 AROs > back, lifetime X and 0. What's the final state in the router? If the host changes its mind, then it would make sense for it to first listen to the ack/nak of its previous instructions before issuing a new registration. I don't see this as a difficult restriction, because I think that it will be rare that a host can't decide whether it will register or unregister. Erik > I'd like to hear what others think. > > Pascal > http://www.xtranormal.com/watch/7011357/ > > >> -----Original Message----- >> From: Dijk, Esko [mailto:esko.dijk@philips.com] >> Sent: Monday, April 18, 2011 10:19 AM >> To: Erik Nordmark; Pascal Thubert (pthubert) >> Cc: 6lowpan@ietf.org >> Subject: RE: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag > in >> ARO] >> >> Hello Erik, >> >> taking the definition you quoted: >> 'host' refers to an LLN device that can generate but does not > forward >> RPL traffic >> >> the question may arise what is "RPL traffic"? It is not defined in the > RPL draft >> it seems. Pascal clarified to me it is traffic associated to a RPL > instance, not >> necessarily RPL protocol messages. This means that a host could > generate >> RPL traffic without being aware of the existence of RPL at all. So, > _not_ all >> hosts have to speak RPL? >> The RPL draft does not explicitly state if "hosts" in a RPL network > always >> speak RPL, never speak RPL, or can be mixed RPL/non-RPL speakers. >> >> Taking the definition of 'node' in the RPL draft: >> 'node' refers to any RPL device, either a host or a router >> >> rules out (?) the option that all "hosts" are non-RPL speakers, since > there >> may be a "RPL device" (i.e. RPL-speaking device, I assume) that is > also a host. >> >> I communicated these perceived unclarities to Pascal and the RFC > editor 2 >> weeks ago. Once this is clear I think the present discussion can > continue. >> And then there is the related discussion of ND support for sleepy > devices, >> the original topic of Anders ;) >> >> best regards, >> >> Esko >> >> >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Erik Nordmark >> Sent: Friday 15 April 2011 18:39 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag > in >> ARO] >> >> On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: >> >>> RPL can do what all classical IGPs can do WRT hosts. That is as long >>> as the host address belongs to the router's prefix and stays > attached >>> to that router. >> >> I just realized that we might be talking about a different definition > of "host". >> What I mean by "host" is a node which does not participate in a > routing >> protocol, and does not forward packets (except packets explicitly > addressed >> to itself using e.g., a routing header). >> >> However, RPL has a different definition: >> 'host' refers to an LLN device that can generate but does not > forward >> RPL traffic >> >> Basically per the RPL definition there is no such thing as a node > which does >> not participate in the RPL protocol. >> IMHO what is in RPL should have been defined as a non-forwarding node, > so >> that we can have a sane discussion without getting entangled in > terminology >> issues. >> >> Which definition of "host" are you using above? >> >> Per the RPL definition there is no need for 6lowpan-nd, since all > nodes will >> speak RPL. This is rather confusing, don't you think? >> >> Erik >> >>> When the topology becomes multilink subnet and mobility is required >>> then it is a new problem entirely, and NO, 4861 is not a suitable >>> interaction with the router to allow the router to redistribute a > host route. >>> Because the neighbor cache that 4861 builds is not a of the same >>> nature as the binding table that 6LoWPAN ND builds. Another thing > that >>> 6LoWPAN ND fails to express correctly. I proposed text to explain > that >>> (attached) but it was not considered, contributing to the illusion >>> that a cache is a table. >>> >>> The reality is also that those networks will need to scale to large >>> subnets in plants, building, etc... (see the requirement drafts in >>> ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND >>> requires a coordination between LBRs but does not say how it > happens. >>> This problem was discussed in 6LoWPAN; the answer was in ND-01to07; >>> and it requires a TID, for the same reason as RPL. Removing the >>> backbone operation and the TID from the draft is ostrich policy. >>> >>> RPL already adapted to the new reality of large multilink subnet > with >>> inner mobility. Placing the blame on RPL is another illusionist > trick. >>> And this is not RPL last call. >>> >>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > other >>> registrations do when strict ordering is not guaranteed (MIP being > an >>> example). Say that due to some config, a node registers a lifetime > of >>> X, then deregisters (lifetime 0), then reregisters (lifetime X) in a >>> rapid sequence, but does not get an answer yet. Then it finally gets > 2 >>> AROs back, lifetime X and 0. What's the final state in the router? >>> >>> It seems we can never agree on any of this. I'd like to hear what >>> others think. >>> >>> Pascal >>> http://www.xtranormal.com/watch/7011357/ >>> >>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> Behalf Of Erik Nordmark >>>> Sent: Friday, April 15, 2011 1:30 AM >>>> To: 6lo>> '6lowpan' >>>> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO >>>> >>>> >>>> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: >>>>> Hi Erik: >>>>> >>>>> The RPL (DAO) sequence number allows the node to increment rapidly >>>>> in case of rapid changes and then lazily when the situation is >>>>> stable and DAO are scarce. The increase is strictly monotonous > which >>> >>>>> is critical to us. >>>>> >>>>> A time stamp imposes a synchronization between the routers. We do >>>>> not have such mechanism in RPL. A time unit (a granularity) must > be >>>>> agreed upon. Within that unit, movements go undetected so the time >>>>> unit must be thin grained to cover rapid changes. Yet, depending > on >>>>> the medium, the time unit, and the size of the network, it is not >>>>> necessarily easy/possible to guarantee a strictly monotonous value >>>>> with a thin grained time unit. And we have limited space (2 > octets) >>>>> and have to deal with wrap around, which divides the space by at >>> least 3. >>>>> >>>>> So RPL went for a sequence number. >>>> >>>> But the unstated assumption that RPL made is that all > host-to-router >>>> protocols have to now be RPL aware. That doesn't sound like good >>> design. >>>> A host isn't aware of whether the routers speak IS-IS or OSPF, so > why >>>> do the hosts need to be aware of RPL by passing some TID around? >>>> >>>>> I think ND has the same need as MIP for a TID == Sequence # . We >>>>> know of MIP; We know of RPL. We know of the backbone router >>>>> operation. We know we'll need the TID and we know exactly why. I >>>>> think we should have it in the 6LowPAN ND spec right away to avoid >>>>> interop issues when we add RPL and BR operations. >>>> >>>> I don't see a need in 6lowpan-nd for a TID; the protocol works fine >>> without it. >>>> I think RPL needs to be improved to deal with reality. Isn't there > a >>>> desire for RPL to handle 4861 hosts? Those would never know about a >>> TID. >>>> >>>> Erik >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> The information contained in this message may be confidential and > legally >> protected under applicable law. The message is intended solely for the >> addressee(s). If you are not the intended recipient, you are hereby > notified >> that any use, forwarding, dissemination, or reproduction of this > message is >> strictly prohibited and may be unlawful. If you are not the intended > recipient, >> please contact the sender by return e-mail and destroy all copies of > the >> original message. > > From nordmark@sonic.net Wed Apr 20 16:21:20 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F28E9E0724; Wed, 20 Apr 2011 16:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGXUL0oPszl8; Wed, 20 Apr 2011 16:21:18 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id 3B3A8E0721; Wed, 20 Apr 2011 16:21:18 -0700 (PDT) Received: from [128.107.115.155] ([128.107.115.155]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3KNL8Ne031771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Apr 2011 16:21:08 -0700 Message-ID: <4DAF6A88.4000305@sonic.net> Date: Wed, 20 Apr 2011 16:21:44 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: nicolas.riou@schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 23 Apr 2011 10:47:15 -0700 Cc: 6lowpan@ietf.org, 6lowpan-bounces@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 23:21:20 -0000 On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: > > Dear Pascal and al, > > I support the idea of reviving the TID in ARO and DAR/DAC. Supporting a > TID directly in the node initiating the initial NS appears much simpler > than time stamping in the parent router. How would you make this work if the protocol between the routers is not RPLv1, but some future version of RPL or a completely different routing protocol? Erik > A simple and efficient method to detect mobility of hosts along a > backbone of Edge Routers is an important feature to deploy backbones of > Edge Routers in Buildings and should be clarified before closing 6LoWPAN > WG. > > Cheers, > Nicolas > > > > > > > *"Pascal Thubert (pthubert)" * > Envoyé par : 6lowpan-bounces@ietf.org > > 18/04/2011 10:37 > > > A > "Dijk, Esko" , "Erik Nordmark" > cc > 6lowpan@ietf.org > Objet > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] > > > > > > > > > Hi Esko, Erik > > The discussion on RPL and hosts should happen on the RPL list under a > different topic. The point being discussed here is this: > > The reality is also that those (LLN) networks will need to scale to > large subnets in plants, building, etc... (see the requirement drafts in > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > requires a coordination between LBRs but does not say how it happens. > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; and > it requires a TID, for the same reason as RPL. Removing the backbone > operation and the TID from the draft is ostrich policy. > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all other > registrations do when strict ordering is not guaranteed (MIP being an > example). Say that due to some config, a node registers a lifetime of X, > then deregisters (lifetime 0), then reregisters (lifetime X) in a rapid > sequence, but does not get an answer yet. Then it finally gets 2 AROs > back, lifetime X and 0. What's the final state in the router? > > I'd like to hear what others think. > > Pascal > http://www.xtranormal.com/watch/7011357/ > > > > -----Original Message----- > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > > Sent: Monday, April 18, 2011 10:19 AM > > To: Erik Nordmark; Pascal Thubert (pthubert) > > Cc: 6lowpan@ietf.org > > Subject: RE: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag > in > > ARO] > > > > Hello Erik, > > > > taking the definition you quoted: > > 'host' refers to an LLN device that can generate but does not > forward > > RPL traffic > > > > the question may arise what is "RPL traffic"? It is not defined in the > RPL draft > > it seems. Pascal clarified to me it is traffic associated to a RPL > instance, not > > necessarily RPL protocol messages. This means that a host could > generate > > RPL traffic without being aware of the existence of RPL at all. So, > _not_ all > > hosts have to speak RPL? > > The RPL draft does not explicitly state if "hosts" in a RPL network > always > > speak RPL, never speak RPL, or can be mixed RPL/non-RPL speakers. > > > > Taking the definition of 'node' in the RPL draft: > > 'node' refers to any RPL device, either a host or a router > > > > rules out (?) the option that all "hosts" are non-RPL speakers, since > there > > may be a "RPL device" (i.e. RPL-speaking device, I assume) that is > also a host. > > > > I communicated these perceived unclarities to Pascal and the RFC > editor 2 > > weeks ago. Once this is clear I think the present discussion can > continue. > > And then there is the related discussion of ND support for sleepy > devices, > > the original topic of Anders ;) > > > > best regards, > > > > Esko > > > > > > > > -----Original Message----- > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Erik Nordmark > > Sent: Friday 15 April 2011 18:39 > > To: Pascal Thubert (pthubert) > > Cc: 6lowpan@ietf.org > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag > in > > ARO] > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: > > > > > RPL can do what all classical IGPs can do WRT hosts. That is as long > > > as the host address belongs to the router's prefix and stays > attached > > > to that router. > > > > I just realized that we might be talking about a different definition > of "host". > > What I mean by "host" is a node which does not participate in a > routing > > protocol, and does not forward packets (except packets explicitly > addressed > > to itself using e.g., a routing header). > > > > However, RPL has a different definition: > > 'host' refers to an LLN device that can generate but does not > forward > > RPL traffic > > > > Basically per the RPL definition there is no such thing as a node > which does > > not participate in the RPL protocol. > > IMHO what is in RPL should have been defined as a non-forwarding node, > so > > that we can have a sane discussion without getting entangled in > terminology > > issues. > > > > Which definition of "host" are you using above? > > > > Per the RPL definition there is no need for 6lowpan-nd, since all > nodes will > > speak RPL. This is rather confusing, don't you think? > > > > Erik > > > > > When the topology becomes multilink subnet and mobility is required > > > then it is a new problem entirely, and NO, 4861 is not a suitable > > > interaction with the router to allow the router to redistribute a > host route. > > > Because the neighbor cache that 4861 builds is not a of the same > > > nature as the binding table that 6LoWPAN ND builds. Another thing > that > > > 6LoWPAN ND fails to express correctly. I proposed text to explain > that > > > (attached) but it was not considered, contributing to the illusion > > > that a cache is a table. > > > > > > The reality is also that those networks will need to scale to large > > > subnets in plants, building, etc... (see the requirement drafts in > > > ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND > > > requires a coordination between LBRs but does not say how it > happens. > > > This problem was discussed in 6LoWPAN; the answer was in ND-01to07; > > > and it requires a TID, for the same reason as RPL. Removing the > > > backbone operation and the TID from the draft is ostrich policy. > > > > > > RPL already adapted to the new reality of large multilink subnet > with > > > inner mobility. Placing the blame on RPL is another illusionist > trick. > > > And this is not RPL last call. > > > > > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all > other > > > registrations do when strict ordering is not guaranteed (MIP being > an > > > example). Say that due to some config, a node registers a lifetime > of > > > X, then deregisters (lifetime 0), then reregisters (lifetime X) in a > > > rapid sequence, but does not get an answer yet. Then it finally gets > 2 > > > AROs back, lifetime X and 0. What's the final state in the router? > > > > > > It seems we can never agree on any of this. I'd like to hear what > > > others think. > > > > > > Pascal > > > http://www.xtranormal.com/watch/7011357/ > > > > > > > > >> -----Original Message----- > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > >> Behalf Of Erik Nordmark > > >> Sent: Friday, April 15, 2011 1:30 AM > > >> To: 6lo>> '6lowpan' > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO > > >> > > >> > > >> On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote: > > >>> Hi Erik: > > >>> > > >>> The RPL (DAO) sequence number allows the node to increment rapidly > > >>> in case of rapid changes and then lazily when the situation is > > >>> stable and DAO are scarce. The increase is strictly monotonous > which > > > > > >>> is critical to us. > > >>> > > >>> A time stamp imposes a synchronization between the routers. We do > > >>> not have such mechanism in RPL. A time unit (a granularity) must > be > > >>> agreed upon. Within that unit, movements go undetected so the time > > >>> unit must be thin grained to cover rapid changes. Yet, depending > on > > >>> the medium, the time unit, and the size of the network, it is not > > >>> necessarily easy/possible to guarantee a strictly monotonous value > > >>> with a thin grained time unit. And we have limited space (2 > octets) > > >>> and have to deal with wrap around, which divides the space by at > > > least 3. > > >>> > > >>> So RPL went for a sequence number. > > >> > > >> But the unstated assumption that RPL made is that all > host-to-router > > >> protocols have to now be RPL aware. That doesn't sound like good > > > design. > > >> A host isn't aware of whether the routers speak IS-IS or OSPF, so > why > > >> do the hosts need to be aware of RPL by passing some TID around? > > >> > > >>> I think ND has the same need as MIP for a TID == Sequence # . We > > >>> know of MIP; We know of RPL. We know of the backbone router > > >>> operation. We know we'll need the TID and we know exactly why. I > > >>> think we should have it in the 6LowPAN ND spec right away to avoid > > >>> interop issues when we add RPL and BR operations. > > >> > > >> I don't see a need in 6lowpan-nd for a TID; the protocol works fine > > > without it. > > >> I think RPL needs to be improved to deal with reality. Isn't there > a > > >> desire for RPL to handle 4861 hosts? Those would never know about a > > > TID. > > >> > > >> Erik > > >> > > >> _______________________________________________ > > >> 6lowpan mailing list > > >> 6lowpan@ietf.org > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > > > 6lowpan mailing list > > > 6lowpan@ietf.org > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > The information contained in this message may be confidential and > legally > > protected under applicable law. The message is intended solely for the > > addressee(s). If you are not the intended recipient, you are hereby > notified > > that any use, forwarding, dissemination, or reproduction of this > message is > > strictly prohibited and may be unlawful. If you are not the intended > recipient, > > please contact the sender by return e-mail and destroy all copies of > the > > original message. > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > ______________________________________________________________________ > From minister@dei.unipd.it Fri Apr 15 01:03:17 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 19EF0E0686 for <6lowpan@ietfc.amsl.com>; Fri, 15 Apr 2011 01:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.189 X-Spam-Level: * X-Spam-Status: No, score=1.189 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX71so0kWrtR for <6lowpan@ietfc.amsl.com>; Fri, 15 Apr 2011 01:03:16 -0700 (PDT) Received: from mail.dei.unipd.it (mail2.dei.unipd.it [147.162.2.112]) by ietfc.amsl.com (Postfix) with SMTP id 1D057E06AB for <6lowpan@ietf.org>; Fri, 15 Apr 2011 01:03:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.dei.unipd.it (Postfix) with ESMTP id BAF34169A67C; Fri, 15 Apr 2011 10:03:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at dei.unipd.it Received: from mail.dei.unipd.it ([127.0.0.1]) by localhost (mail2.dei.unipd.it [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 39TOKuPQ59x3; Fri, 15 Apr 2011 10:03:05 +0200 (CEST) Received: by mail.dei.unipd.it (Postfix, from userid 48) id 71F59169A67E; Fri, 15 Apr 2011 10:03:05 +0200 (CEST) Received: from 2.33.88.87 ([2.33.88.87]) by mail.dei.unipd.it (Horde Framework) with HTTP; Fri, 15 Apr 2011 10:03:05 +0200 Message-ID: <20110415100305.16342l7qphsc2gg0@mail.dei.unipd.it> Date: Fri, 15 Apr 2011 10:03:05 +0200 From: minister@dei.unipd.it To: Colin O'Flynn References: <20110316181810.19202jt7x4xd1eio@mail.dei.unipd.it> <000901cbe8c4$7ce13880$76a3a980$@com> In-Reply-To: <000901cbe8c4$7ce13880$76a3a980$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-Mailman-Approved-At: Sat, 23 Apr 2011 10:47:22 -0700 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] questions about lowpan_nhc fields X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 08:03:17 -0000 I understand it, but there are some other questions that I struggle with. Let's talk about fragmentation header: in this discussion http://www.ietf.org/mail-archive/web/6lowpan/current/msg02327.html authors explain their doubts about datagram_size field in RFC 4944. Since in draft I found only this sentece about it: Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 datagrams that do not fit within a single link frame. Section 5.3 of [RFC4944] defines the fragment header's datagram_size and datagram_offset values as the size and offset of the IPv6 datagram before compression. As a result, all fragment payload outside the first fragment must carry their respective portions of the IPv6 datagram before compression. This document does not change that requirement. When using the fragmentation mechanism described in Section 5.3 of [RFC4944], any header that cannot fit within the first fragment MUST NOT be compressed. I would like to have a confirm about how I think the compression and fragmentation works. Let me say I am the 6lowpan (2.5) layer, and I take a datagram from the upper layers. IPv6 and UDP add their headers without knowing anything about me and my presence between data-link layer and them. So I have a datagram with 8 byte of UDP header and 40 byte (even more if there is an extension header) of IPv6 header. I start compressing IPv6 header and, if it is possible, extension and/or UDP headers, now I have a compressed header and application layer payload. If the total length is less than the data-link MTU, I fill a single data-link message and I send it. If the total length is bigger than data-link MTU I have to come back, calculate the size of compression header (IPv6, extension and UDP headers) ask me if they suit in a single data-link message Colin O'Flynn ha scritto: > Hello Giulio, > > There are two levels of fragmentation, I think that might be causing > confusion? > > IPv6 level fragmentation DOES keep the IPv6 headers between fragments, for > example see > http://www.tcpipguide.com/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUF > ragment-4.htm . > > 6LoWPAN level fragmentation DOES NOT keep the IPv6 headers between > fragments. 6LoWPAN only repeats the 6LoWPAN header between fragments. > > The 6LoWPAN MTU is (at least) 1280 bytes. Any packet larger than fits in a > single 15.4 packet but smaller or equal to the 6LoWPAN MTU will be > fragmented at the 6LoWPAN layer. Anything larger than the 6LoWPAN MTU would > have to be fragmented at the IPv6 layer by the sender, and each of those > IPv6 fragments may have 6LoWPAN fragmentation applied. > > Hope this is a lucid explanation, let me know if it doesn't make sense. > > Regards, > > -Colin O'Flynn > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf > Of minister@dei.unipd.it > Sent: March 16, 2011 6:18 PM > To: 6lowpan@ietf.org > Subject: [6lowpan] questions about lowpan_nhc fields > > Dear authors, > I would speak about 6lowPAN hc-15 draft document. > Section 4 describes the ipv6 next header compression and in 4.2 ipv6 > extension header encoding is shown. > So incidentally in a 802.15.4 127 byte long packet I could have a mesh > header and a fragmentation header like RFC4944 describes; after those > a lowpan_IPCH dispatch with in-line ipv6 fields, like it is shown in > figure 1 on page 5. All those headers (RFC4944 and figure 1 ones) in a > single 802.15.4 packet. > But figure 11 on page 14 shows that we could have other headers like > in IPv6 (so-called extension-header), and they could be heavy like > router header or they grows on-the-fly like hop-by-hop header. > So my questions are: do those extension headers have to be present in > every fragment of an IPv6 packet? And if it is so, doesn't it seem > like wasting a lot of space? Let's say that I want to send a message > and I have to write entirely the IPv6 source and destination addresses > and I want a routing header too, even with 4 addresses, I fill 80 out > of 127 bytes only for addresses. Is this example right or I understand > wrongly the document? And after these considerations, is it necessary > to change the rule to calculate the datagram size field in RFC4944 > fragmentation header? > Best regards > Giulio Ministeri > from University of Padova, Italy > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From samita.chakrabarti@ericsson.com Mon Apr 25 12:00:20 2011 Return-Path: X-Original-To: 6lowpan@ietfc.amsl.com Delivered-To: 6lowpan@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 268C4E0794 for <6lowpan@ietfc.amsl.com>; Mon, 25 Apr 2011 12:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8OoRBbLk1YK for <6lowpan@ietfc.amsl.com>; Mon, 25 Apr 2011 12:00:19 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfc.amsl.com (Postfix) with ESMTP id 9793EE0758 for <6lowpan@ietf.org>; Mon, 25 Apr 2011 12:00:07 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3PJ06LN025014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Apr 2011 14:00:06 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.126]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 25 Apr 2011 15:00:05 -0400 From: Samita Chakrabarti To: Erik Nordmark , "Pascal Thubert (pthubert)" , "nicolas.riou@schneider-electric.com" Date: Mon, 25 Apr 2011 15:00:04 -0400 Thread-Topic: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO Thread-Index: AcwB3n9uS+E+GhjWTO+X2L8pj2uDBwBmAiDg Message-ID: <16D60F43CA0B724F8052D7E9323565D71B8FAF2786@EUSAACMS0715.eamcs.ericsson.se> References: <4DA4BB1E.2050002@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com> <4DA782BF.6030301@sonic.net> In-Reply-To: <4DA782BF.6030301@sonic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 19:00:20 -0000 =20 Hi Pascal and Nicolas, I am in agreement with the following reasons (by Erik) as to why we don't w= ant to add the TID/sequence# in the ARO message. As discussed many times in the wg that the goal of this= 6lowpan-nd work is to provide simple optimized neighbor discovery function= ality of the low-power IPv6 network. This is independent of routing protoco= l functionalities such that it works with multiple routing protocols on top= of it. If RPL or other routing protocol needs a specific information to pass arou= nd, it could do that as an option aka future extension of 6lowpan-nd. We al= ready decided/presented in the Prague wg meeting and the consensus was to = move forward with the 6lowpan-nd as it is plus the editorial changes discus= sed at the meeting slides. Besides the dependency of 6lowpan-nd on a specific routing protocol( such a= s RPL or backbone routing), I have a major concern including a feature like= sequence# in the ARO message at this point for supporting a corner case wi= thout knowing its larger impact. As for MIP, I am not sure if we want to run MIPv6 as it is in the 6lowpan n= etwork. Our design goal for 6lowpan-nd-basic is to provide the core functio= nality and then build things on top of it on a modular basis as needed. Please help in proceeding toward the basic 6lowpan-nd work done first. Best regards, -Samita | A host isn't aware of whether the routers speak IS-IS or OSPF, so why do = the hosts need to be aware of RPL by | passing some TID around? > I think ND has the same need as MIP for a TID =3D=3D Sequence # . We know= =20 > of MIP; We know of RPL. We know of the backbone router operation. We=20 > know we'll need the TID and we know exactly why. I think we should=20 > have it in the 6LowPAN ND spec right away to avoid interop issues when=20 > we add RPL and BR operations. | I don't see a need in 6lowpan-nd for a TID; the protocol works fine witho= ut it. | I think RPL needs to be improved to deal with reality. Isn't there a desi= re for RPL to handle 4861 hosts? | | | Those would never know about a TID. | Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From wassim.haddad@ericsson.com Mon Apr 25 22:08:03 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F94DE06ED for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3IJ0bnbQPF6X for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:08:02 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id F085AE06E6 for <6lowpan@ietf.org>; Mon, 25 Apr 2011 22:08:01 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p3Q57xSO020374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Apr 2011 00:07:59 -0500 Received: from client-vpn-018.edd.ericsson.se (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Tue, 26 Apr 2011 01:07:56 -0400 MIME-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset="iso-8859-1" From: Wassim Haddad In-Reply-To: <1303400445.1671.1576.camel@d430> Date: Mon, 25 Apr 2011 22:07:53 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <998E4F3E-C12E-44C7-BD80-9A1F9046E6C8@ericsson.com> References: <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> To: Geoff Mulligan X-Mailer: Apple Mail (2.1082) Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:08:03 -0000 +1=20 Regards, Wassim H. On Apr 21, 2011, at 8:40 AM, Geoff Mulligan wrote: > Pascal, > We need to close on this discussion. >=20 > Back in Hiroshima the Working Group decided that Backbone router stuff > and "address defense" across backbone routers was not going to be part > of ND draft. It appeared that the draft was getting way to = complicated > and the Working Group decided to simplify things. >=20 > I have not seen much support on the list for making these changes to > include the TID in ND. >=20 > We need to get this draft completed. If there is a large "unheard = from" > support group for these changes, please speak up or we shall move > forward with the draft as it is. >=20 > geoff >=20 >=20 >=20 >=20 > On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote: >> Hi Erik >>=20 >> The TID is not a strong coupling between the H2R and the R2R = operations, and it is not a coupling with a RPL version explicitly. >> It is an abstract information that if defined properly can be used by = many forms or R2R interactions. >> As demonstrated by older versions of the ND spec (Backbone Router), = RPL, and MIP. >>=20 >> 6LoWPAN ND cannot scale if the node needs to register to all LBRs. = 6LoWPAN ND does not define anymore any LBR interaction. >> IOW, 6LoPWAN ND lost the capability to scale when the backbone router = piece was removed from the draft. >> Which means that it lost its capability to apply in the domains I'm = looking at (industrial and metering). >>=20 >> With the TID, we know that we can restore scalability in the future, = and we know how. I do not know of a plan B. >>=20 >> Pascal >> http://www.xtranormal.com/watch/7011357/ >>=20 >>=20 >>> -----Original Message----- >>> From: Erik Nordmark [mailto:nordmark@acm.org] >>> Sent: Thursday, April 21, 2011 1:25 AM >>> To: nicolas.riou@schneider-electric.com >>> Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko >>> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" = flag in >>> ARO] >>>=20 >>> On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: >>>>=20 >>>> Dear Pascal and al, >>>>=20 >>>> I support the idea of reviving the TID in ARO and DAR/DAC. = Supporting >>>> a TID directly in the node initiating the initial NS appears much >>>> simpler than time stamping in the parent router. >>>=20 >>> How would you make this work if the protocol between the routers is = not >>> RPLv1, but some future version of RPL or a completely different = routing >>> protocol? >>>=20 >>> The decoupling of the host-router interaction from router-router = interaction >>> has served us well in the history of the Internet. >>>=20 >>> Erik >>>=20 >>>> A simple and efficient method to detect mobility of hosts along a >>>> backbone of Edge Routers is an important feature to deploy = backbones >>>> of Edge Routers in Buildings and should be clarified before closing >>>> 6LoWPAN WG. >>>>=20 >>>> Cheers, >>>> Nicolas >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> *"Pascal Thubert (pthubert)" * Envoy=E9 par : >>>> 6lowpan-bounces@ietf.org >>>>=20 >>>> 18/04/2011 10:37 >>>>=20 >>>>=20 >>>> A >>>> "Dijk, Esko" , "Erik Nordmark" >>>> cc >>>> 6lowpan@ietf.org >>>> Objet >>>> Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in >>> ARO] >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Hi Esko, Erik >>>>=20 >>>> The discussion on RPL and hosts should happen on the RPL list under = a >>>> different topic. The point being discussed here is this: >>>>=20 >>>> The reality is also that those (LLN) networks will need to scale to >>>> large subnets in plants, building, etc... (see the requirement = drafts >>>> in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN = ND >>>> requires a coordination between LBRs but does not say how it = happens. >>>> This problem was discussed in 6LoWPAN; the answer was in ND-01to07; >>>> and it requires a TID, for the same reason as RPL. Removing the >>>> backbone operation and the TID from the draft is ostrich policy. >>>>=20 >>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all = other >>>> registrations do when strict ordering is not guaranteed (MIP being = an >>>> example). Say that due to some config, a node registers a lifetime = of >>>> X, then deregisters (lifetime 0), then reregisters (lifetime X) in = a >>>> rapid sequence, but does not get an answer yet. Then it finally = gets 2 >>>> AROs back, lifetime X and 0. What's the final state in the router? >>>>=20 >>>> I'd like to hear what others think. >>>>=20 >>>> Pascal >>>> http://www.xtranormal.com/watch/7011357/ >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: Monday, >>>> April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal Thubert >>>> (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: = TID >>>> in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello = Erik, >>>>>> taking the definition you quoted: >>>>> 'host' refers to an LLN device that can generate but does not >>>> forward > RPL traffic > > the question may arise what is "RPL >>>> traffic"? It is not defined in the RPL draft > it seems. Pascal >>>> clarified to me it is traffic associated to a RPL instance, not > >>>> necessarily RPL protocol messages. This means that a host could >>>> generate > RPL traffic without being aware of the existence of RPL = at >>>> all. So, _not_ all > hosts have to speak RPL? >>>>> The RPL draft does not explicitly state if "hosts" in a RPL = network >>>> always > speak RPL, never speak RPL, or can be mixed RPL/non-RPL >>>> speakers. >>>>>=20 >>>>> Taking the definition of 'node' in the RPL draft: >>>>> 'node' refers to any RPL device, either a host or a router > > >>>> rules out (?) the option that all "hosts" are non-RPL speakers, = since >>>> there > may be a "RPL device" (i.e. RPL-speaking device, I assume) >>>> that is also a host. >>>>>=20 >>>>> I communicated these perceived unclarities to Pascal and the RFC >>>> editor 2 > weeks ago. Once this is clear I think the present >>>> discussion can continue. >>>>> And then there is the related discussion of ND support for sleepy >>>> devices, > the original topic of Anders ;) > > best regards, > = > >>>> Esko > > > > -----Original Message----- > From: >>>> 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >>>> Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: >>>> Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: >>>> [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > = ARO] >>>>>> On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: >>>>>=20 >>>>>> RPL can do what all classical IGPs can do WRT hosts. That is as >>>> long > > as the host address belongs to the router's prefix and = stays >>>> attached > > to that router. >>>>>=20 >>>>> I just realized that we might be talking about a different >>>> definition of "host". >>>>> What I mean by "host" is a node which does not participate in a >>>> routing > protocol, and does not forward packets (except packets >>>> explicitly addressed > to itself using e.g., a routing header). >>>>>=20 >>>>> However, RPL has a different definition: >>>>> 'host' refers to an LLN device that can generate but does not >>>> forward > RPL traffic > > Basically per the RPL definition there = is >>>> no such thing as a node which does > not participate in the RPL >>>> protocol. >>>>> IMHO what is in RPL should have been defined as a non-forwarding >>>> node, so > that we can have a sane discussion without getting >>>> entangled in terminology > issues. >>>>>=20 >>>>> Which definition of "host" are you using above? >>>>>=20 >>>>> Per the RPL definition there is no need for 6lowpan-nd, since all >>>> nodes will > speak RPL. This is rather confusing, don't you think? >>>>>=20 >>>>> Erik >>>>>=20 >>>>>> When the topology becomes multilink subnet and mobility is >>>> required > > then it is a new problem entirely, and NO, 4861 is = not a >>>> suitable > > interaction with the router to allow the router to >>>> redistribute a host route. >>>>>> Because the neighbor cache that 4861 builds is not a of the same >>>>>> nature as the binding table that 6LoWPAN ND builds. Another thing >>>> that > > 6LoWPAN ND fails to express correctly. I proposed text to >>>> explain that > > (attached) but it was not considered, = contributing >>>> to the illusion > > that a cache is a table. >>>>>>=20 >>>>>> The reality is also that those networks will need to scale to >>>> large > > subnets in plants, building, etc... (see the requirement >>>> drafts in > > ROLL). Registering to all LBRS is totally = impractical. >>>> 6LoWPAN ND > > requires a coordination between LBRs but does not = say >>>> how it happens. >>>>>> This problem was discussed in 6LoWPAN; the answer was in >>>> ND-01to07; > > and it requires a TID, for the same reason as RPL. >>>> Removing the > > backbone operation and the TID from the draft is = ostrich >>> policy. >>>>>>=20 >>>>>> RPL already adapted to the new reality of large multilink subnet >>>> with > > inner mobility. Placing the blame on RPL is another >>>> illusionist trick. >>>>>> And this is not RPL last call. >>>>>>=20 >>>>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all >>>> other > > registrations do when strict ordering is not guaranteed >>>> (MIP being an > > example). Say that due to some config, a node >>>> registers a lifetime of > > X, then deregisters (lifetime 0), then >>>> reregisters (lifetime X) in a > > rapid sequence, but does not get = an >>>> answer yet. Then it finally gets >>>> 2 >>>>>> AROs back, lifetime X and 0. What's the final state in the = router? >>>>>>=20 >>>>>> It seems we can never agree on any of this. I'd like to hear what >>>>>> others think. >>>>>>=20 >>>>>> Pascal >>>>>> http://www.xtranormal.com/watch/7011357/ >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- >>> bounces@ietf.org] >>>> On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, 2011 >>>> 1:30 AM > >> To: 6lo>> '6lowpan' >>>>>>> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in >>>> ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert = (pthubert) >>>> wrote: >>>>>>>> Hi Erik: >>>>>>>>=20 >>>>>>>> The RPL (DAO) sequence number allows the node to increment >>>> rapidly > >>> in case of rapid changes and then lazily when the >>>> situation is > >>> stable and DAO are scarce. The increase is >>>> strictly monotonous which > > > >>> is critical to us. >>>>>>>>=20 >>>>>>>> A time stamp imposes a synchronization between the routers. We >>>> do > >>> not have such mechanism in RPL. A time unit (a = granularity) >>>> must be > >>> agreed upon. Within that unit, movements go = undetected >>>> so the time > >>> unit must be thin grained to cover rapid = changes. >>>> Yet, depending on > >>> the medium, the time unit, and the size of >>>> the network, it is not > >>> necessarily easy/possible to = guarantee a >>>> strictly monotonous value > >>> with a thin grained time unit. And = we >>>> have limited space (2 >>>> octets) >>>>>>>> and have to deal with wrap around, which divides the space by >>>> at > > least 3. >>>>>>>>=20 >>>>>>>> So RPL went for a sequence number. >>>>>>>=20 >>>>>>> But the unstated assumption that RPL made is that all >>>> host-to-router > >> protocols have to now be RPL aware. That = doesn't >>>> sound like good > > design. >>>>>>> A host isn't aware of whether the routers speak IS-IS or OSPF, >>>> so why > >> do the hosts need to be aware of RPL by passing some = TID >>>> around? >>>>>>>=20 >>>>>>>> I think ND has the same need as MIP for a TID =3D=3D Sequence # = . >>>> We > >>> know of MIP; We know of RPL. We know of the backbone = router >>>>>>>> operation. We know we'll need the TID and we know exactly why. = I >>>>>>>> think we should have it in the 6LowPAN ND spec right away to >>>> avoid > >>> interop issues when we add RPL and BR operations. >>>>>>>=20 >>>>>>> I don't see a need in 6lowpan-nd for a TID; the protocol works >>>> fine > > without it. >>>>>>> I think RPL needs to be improved to deal with reality. Isn't >>>> there a > >> desire for RPL to handle 4861 hosts? Those would = never >>>> know about a > > TID. >>>>>>>=20 >>>>>>> Erik >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>=20 >>>>> The information contained in this message may be confidential and >>>> legally > protected under applicable law. The message is intended >>>> solely for the > addressee(s). If you are not the intended = recipient, >>>> you are hereby notified > that any use, forwarding, dissemination, = or >>>> reproduction of this message is > strictly prohibited and may be >>>> unlawful. If you are not the intended recipient, > please contact = the >>>> sender by return e-mail and destroy all copies of the > original >>>> message. >>>>=20 >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>=20 >>>>=20 >>> __________________________________________________________ >>> ____________ >>>> This email has been scanned by the MessageLabs Email Security = System. >>>>=20 >>> __________________________________________________________ >>> ____________ >>>>=20 >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From pete.st.pierre@oracle.com Mon Apr 25 22:15:27 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EB6E06CD for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 IWcRGyyxeLaA for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:15:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9641AE067C for <6lowpan@ietf.org>; Mon, 25 Apr 2011 22:15:25 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3Q5FMtj006845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Apr 2011 05:15:24 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p3Q5FMDR029932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 05:15:22 GMT Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3Q5FGFV030670; Tue, 26 Apr 2011 00:15:16 -0500 Received: from [192.168.1.56] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Apr 2011 22:15:16 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: "Pete St. Pierre" In-Reply-To: <1303414920.1671.1849.camel@d430> Date: Mon, 25 Apr 2011 22:15:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7289A47C-61EC-4E55-B201-1F4950517D3F@oracle.com> References: <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> <1303414920.1671.1849.camel@d430> To: Geoff Mulligan X-Mailer: Apple Mail (2.1084) X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4DB654ED.0001:SCFMA922111,ss=1,fgs=0 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:15:27 -0000 Geoff - I think Erik has made some very good points on this topic. I don't see a = need to make the ND draft any more complex than it already is. ...Pete On Apr 21, 2011, at 12:42 PM, Geoff Mulligan wrote: > Pascal, > I couple of people supporting the TID is not group consensus. We = have > had many presentations and discussions about multiple LBRs, backbone > LBRs and more and none have met with the support of the working group. >=20 > In your opinions we are crashing, but I fail to see that this is the > opinion of the working group. >=20 > If there are other in the working group that strongly advocate this = TID > idea or the work on multiple and backbone LBRs then they need to speak > up now en masse or we must move on. >=20 > geoff >=20 >=20 > On Thu, 2011-04-21 at 21:32 +0200, Pascal Thubert (pthubert) wrote: >> Geoff: >>=20 >> There is twice as much support for restoring the TID than there is = for not doing it. >> Before we drop the TID, I'd like to see a proposal that allows a = 6LoWPAN ND subnet to scale with multiple LBRs, allows nodes to move from = a router to the next, and that does not need a TID. >> Otherwise, we are not speeding towards the wall, we're already = crashing. >>=20 >> Pascal >> http://www.xtranormal.com/watch/7011357/ >>=20 >>> -----Original Message----- >>> From: Geoff Mulligan [mailto:geoff.ietf@mulligan.com] >>> Sent: Thursday, April 21, 2011 5:41 PM >>> To: Pascal Thubert (pthubert) >>> Cc: Erik Nordmark; nicolas.riou@schneider-electric.com; = 6lowpan@ietf.org >>> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" = flag in >>> ARO] >>>=20 >>> Pascal, >>> We need to close on this discussion. >>>=20 >>> Back in Hiroshima the Working Group decided that Backbone router = stuff and >>> "address defense" across backbone routers was not going to be part = of ND >>> draft. It appeared that the draft was getting way to complicated = and the >>> Working Group decided to simplify things. >>>=20 >>> I have not seen much support on the list for making these changes to = include >>> the TID in ND. >>>=20 >>> We need to get this draft completed. If there is a large "unheard = from" >>> support group for these changes, please speak up or we shall move = forward >>> with the draft as it is. >>>=20 >>> geoff >>>=20 >>>=20 >>>=20 >>>=20 >>> On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote: >>>> Hi Erik >>>>=20 >>>> The TID is not a strong coupling between the H2R and the R2R = operations, >>> and it is not a coupling with a RPL version explicitly. >>>> It is an abstract information that if defined properly can be used = by many >>> forms or R2R interactions. >>>> As demonstrated by older versions of the ND spec (Backbone Router), = RPL, >>> and MIP. >>>>=20 >>>> 6LoWPAN ND cannot scale if the node needs to register to all LBRs. >>> 6LoWPAN ND does not define anymore any LBR interaction. >>>> IOW, 6LoPWAN ND lost the capability to scale when the backbone = router >>> piece was removed from the draft. >>>> Which means that it lost its capability to apply in the domains I'm = looking at >>> (industrial and metering). >>>>=20 >>>> With the TID, we know that we can restore scalability in the = future, and we >>> know how. I do not know of a plan B. >>>>=20 >>>> Pascal >>>> http://www.xtranormal.com/watch/7011357/ >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Erik Nordmark [mailto:nordmark@acm.org] >>>>> Sent: Thursday, April 21, 2011 1:25 AM >>>>> To: nicolas.riou@schneider-electric.com >>>>> Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko >>>>> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" >>>>> flag in ARO] >>>>>=20 >>>>> On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: >>>>>>=20 >>>>>> Dear Pascal and al, >>>>>>=20 >>>>>> I support the idea of reviving the TID in ARO and DAR/DAC. >>>>>> Supporting a TID directly in the node initiating the initial NS >>>>>> appears much simpler than time stamping in the parent router. >>>>>=20 >>>>> How would you make this work if the protocol between the routers = is >>>>> not RPLv1, but some future version of RPL or a completely = different >>>>> routing protocol? >>>>>=20 >>>>> The decoupling of the host-router interaction from router-router >>>>> interaction has served us well in the history of the Internet. >>>>>=20 >>>>> Erik >>>>>=20 >>>>>> A simple and efficient method to detect mobility of hosts along a >>>>>> backbone of Edge Routers is an important feature to deploy >>>>>> backbones of Edge Routers in Buildings and should be clarified >>>>>> before closing 6LoWPAN WG. >>>>>>=20 >>>>>> Cheers, >>>>>> Nicolas >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> *"Pascal Thubert (pthubert)" * Envoy=E9 par : >>>>>> 6lowpan-bounces@ietf.org >>>>>>=20 >>>>>> 18/04/2011 10:37 >>>>>>=20 >>>>>>=20 >>>>>> A >>>>>> "Dijk, Esko" , "Erik Nordmark" >>>>>> cc >>>>>> 6lowpan@ietf.org >>>>>> Objet >>>>>> Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in >>>>> ARO] >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Hi Esko, Erik >>>>>>=20 >>>>>> The discussion on RPL and hosts should happen on the RPL list >>>>>> under a different topic. The point being discussed here is this: >>>>>>=20 >>>>>> The reality is also that those (LLN) networks will need to scale >>>>>> to large subnets in plants, building, etc... (see the requirement >>>>>> drafts in ROLL). Registering to all LBRS is totally impractical. >>>>>> 6LoWPAN ND requires a coordination between LBRs but does not say >>> how it happens. >>>>>> This problem was discussed in 6LoWPAN; the answer was in >>>>>> ND-01to07; and it requires a TID, for the same reason as RPL. >>>>>> Removing the backbone operation and the TID from the draft is = ostrich >>> policy. >>>>>>=20 >>>>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all >>>>>> other registrations do when strict ordering is not guaranteed = (MIP >>>>>> being an example). Say that due to some config, a node registers = a >>>>>> lifetime of X, then deregisters (lifetime 0), then reregisters >>>>>> (lifetime X) in a rapid sequence, but does not get an answer yet. >>>>>> Then it finally gets 2 AROs back, lifetime X and 0. What's the = final state >>> in the router? >>>>>>=20 >>>>>> I'd like to hear what others think. >>>>>>=20 >>>>>> Pascal >>>>>> http://www.xtranormal.com/watch/7011357/ >>>>>>=20 >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: >>>>>> Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal >>>>>> Thubert >>>>>> (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: >>>>>> TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > = Hello >>>>>> Erik, >>>>>>>> taking the definition you quoted: >>>>>>> 'host' refers to an LLN device that can generate but does not >>>>>> forward > RPL traffic > > the question may arise what is "RPL >>>>>> traffic"? It is not defined in the RPL draft > it seems. Pascal >>>>>> clarified to me it is traffic associated to a RPL instance, not = > >>>>>> necessarily RPL protocol messages. This means that a host could >>>>>> generate > RPL traffic without being aware of the existence of >>>>>> RPL at all. So, _not_ all > hosts have to speak RPL? >>>>>>> The RPL draft does not explicitly state if "hosts" in a RPL >>>>>> network always > speak RPL, never speak RPL, or can be mixed >>>>>> RPL/non-RPL speakers. >>>>>>>=20 >>>>>>> Taking the definition of 'node' in the RPL draft: >>>>>>> 'node' refers to any RPL device, either a host or a router > >>>>>>> rules out (?) the option that all "hosts" are non-RPL speakers, >>>>>> since there > may be a "RPL device" (i.e. RPL-speaking device, I >>>>>> assume) that is also a host. >>>>>>>=20 >>>>>>> I communicated these perceived unclarities to Pascal and the >>>>>> RFC editor 2 > weeks ago. Once this is clear I think the present >>>>>> discussion can continue. >>>>>>> And then there is the related discussion of ND support for >>>>>> sleepy devices, > the original topic of Anders ;) > > best >>>>>> regards, > > Esko > > > > -----Original Message----- > = From: >>>>>> 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >>>>>> Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > = To: >>>>>> Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: >>>>>> [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > >>>>>> ARO] >>>>>>>> On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: >>>>>>>=20 >>>>>>>> RPL can do what all classical IGPs can do WRT hosts. That is >>>>>> as long > > as the host address belongs to the router's prefix >>>>>> and stays attached > > to that router. >>>>>>>=20 >>>>>>> I just realized that we might be talking about a different >>>>>> definition of "host". >>>>>>> What I mean by "host" is a node which does not participate in a >>>>>> routing > protocol, and does not forward packets (except packets >>>>>> explicitly addressed > to itself using e.g., a routing header). >>>>>>>=20 >>>>>>> However, RPL has a different definition: >>>>>>> 'host' refers to an LLN device that can generate but does not >>>>>> forward > RPL traffic > > Basically per the RPL definition >>>>>> there is no such thing as a node which does > not participate in >>>>>> the RPL protocol. >>>>>>> IMHO what is in RPL should have been defined as a >>>>>> non-forwarding node, so > that we can have a sane discussion >>>>>> without getting entangled in terminology > issues. >>>>>>>=20 >>>>>>> Which definition of "host" are you using above? >>>>>>>=20 >>>>>>> Per the RPL definition there is no need for 6lowpan-nd, since >>>>>> all nodes will > speak RPL. This is rather confusing, don't you = think? >>>>>>>=20 >>>>>>> Erik >>>>>>>=20 >>>>>>>> When the topology becomes multilink subnet and mobility is >>>>>> required > > then it is a new problem entirely, and NO, 4861 is >>>>>> not a suitable > > interaction with the router to allow the >>>>>> router to redistribute a host route. >>>>>>>> Because the neighbor cache that 4861 builds is not a of the >>>>>> same >>>>>>>> nature as the binding table that 6LoWPAN ND builds. Another >>>>>>>> thing >>>>>> that > > 6LoWPAN ND fails to express correctly. I proposed text >>>>>> to explain that > > (attached) but it was not considered, >>>>>> contributing to the illusion > > that a cache is a table. >>>>>>>>=20 >>>>>>>> The reality is also that those networks will need to scale to >>>>>> large > > subnets in plants, building, etc... (see the >>>>>> requirement drafts in > > ROLL). Registering to all LBRS is = totally >>> impractical. >>>>>> 6LoWPAN ND > > requires a coordination between LBRs but does not >>>>>> say how it happens. >>>>>>>> This problem was discussed in 6LoWPAN; the answer was in >>>>>> ND-01to07; > > and it requires a TID, for the same reason as = RPL. >>>>>> Removing the > > backbone operation and the TID from the draft = is >>>>>> ostrich >>>>> policy. >>>>>>>>=20 >>>>>>>> RPL already adapted to the new reality of large multilink >>>>>> subnet with > > inner mobility. Placing the blame on RPL is >>>>>> another illusionist trick. >>>>>>>> And this is not RPL last call. >>>>>>>>=20 >>>>>>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as >>>>>> all other > > registrations do when strict ordering is not >>>>>> guaranteed (MIP being an > > example). Say that due to some >>>>>> config, a node registers a lifetime of > > X, then deregisters >>>>>> (lifetime 0), then reregisters (lifetime X) in a > > rapid >>>>>> sequence, but does not get an answer yet. Then it finally gets >>>>>> 2 >>>>>>>> AROs back, lifetime X and 0. What's the final state in the = router? >>>>>>>>=20 >>>>>>>> It seems we can never agree on any of this. I'd like to hear >>>>>> what >>>>>>>> others think. >>>>>>>>=20 >>>>>>>> Pascal >>>>>>>> http://www.xtranormal.com/watch/7011357/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- >>>>> bounces@ietf.org] >>>>>> On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, >>>>>> 2011 >>>>>> 1:30 AM > >> To: 6lo>> '6lowpan' >>>>>>>>> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag >>>>>> in ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert >>>>>> (pthubert) >>>>>> wrote: >>>>>>>>>> Hi Erik: >>>>>>>>>>=20 >>>>>>>>>> The RPL (DAO) sequence number allows the node to increment >>>>>> rapidly > >>> in case of rapid changes and then lazily when the >>>>>> situation is > >>> stable and DAO are scarce. The increase is >>>>>> strictly monotonous which > > > >>> is critical to us. >>>>>>>>>>=20 >>>>>>>>>> A time stamp imposes a synchronization between the routers. >>>>>> We do > >>> not have such mechanism in RPL. A time unit (a >>>>>> granularity) must be > >>> agreed upon. Within that unit, >>>>>> movements go undetected so the time > >>> unit must be thin = grained >>> to cover rapid changes. >>>>>> Yet, depending on > >>> the medium, the time unit, and the size >>>>>> of the network, it is not > >>> necessarily easy/possible to >>>>>> guarantee a strictly monotonous value > >>> with a thin grained >>>>>> time unit. And we have limited space (2 >>>>>> octets) >>>>>>>>>> and have to deal with wrap around, which divides the space >>>>>> by at > > least 3. >>>>>>>>>>=20 >>>>>>>>>> So RPL went for a sequence number. >>>>>>>>>=20 >>>>>>>>> But the unstated assumption that RPL made is that all >>>>>> host-to-router > >> protocols have to now be RPL aware. That >>>>>> doesn't sound like good > > design. >>>>>>>>> A host isn't aware of whether the routers speak IS-IS or >>>>>> OSPF, so why > >> do the hosts need to be aware of RPL by = passing >>>>>> some TID around? >>>>>>>>>=20 >>>>>>>>>> I think ND has the same need as MIP for a TID =3D=3D Sequence = # . >>>>>> We > >>> know of MIP; We know of RPL. We know of the backbone >>>>>> router >>>>>>>>>> operation. We know we'll need the TID and we know exactly >>>>>>>>>> why. I think we should have it in the 6LowPAN ND spec right >>>>>>>>>> away to >>>>>> avoid > >>> interop issues when we add RPL and BR operations. >>>>>>>>>=20 >>>>>>>>> I don't see a need in 6lowpan-nd for a TID; the protocol >>>>>> works fine > > without it. >>>>>>>>> I think RPL needs to be improved to deal with reality. Isn't >>>>>> there a > >> desire for RPL to handle 4861 hosts? Those would >>>>>> never know about a > > TID. >>>>>>>>>=20 >>>>>>>>> Erik >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> 6lowpan@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>> _______________________________________________ >>>>>>>> 6lowpan mailing list >>>>>>>> 6lowpan@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>=20 >>>>>>> The information contained in this message may be confidential >>>>>> and legally > protected under applicable law. The message is >>>>>> intended solely for the > addressee(s). If you are not the >>>>>> intended recipient, you are hereby notified > that any use, >>>>>> forwarding, dissemination, or reproduction of this message is > >>>>>> strictly prohibited and may be unlawful. If you are not the >>>>>> intended recipient, > please contact the sender by return e-mail >>>>>> and destroy all copies of the > original message. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>=20 >>>>>>=20 >>>>>=20 >>> __________________________________________________________ >>>>> ____________ >>>>>> This email has been scanned by the MessageLabs Email Security >>> System. >>>>>>=20 >>>>>=20 >>> __________________________________________________________ >>>>> ____________ >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>=20 >>=20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From PM@rtx.dk Tue Apr 26 00:46:28 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD7BE0720 for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 00:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJF0AsCQjmej for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 00:46:27 -0700 (PDT) Received: from VA3EHSOBE003.bigfish.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C5D94E067C for <6lowpan@ietf.org>; Tue, 26 Apr 2011 00:46:26 -0700 (PDT) Received: from mail80-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.8; Tue, 26 Apr 2011 07:46:25 +0000 Received: from mail80-va3 (localhost.localdomain [127.0.0.1]) by mail80-va3-R.bigfish.com (Postfix) with ESMTP id 445211A30226; Tue, 26 Apr 2011 07:46:25 +0000 (UTC) X-SpamScore: -105 X-BigFish: VPS-105(zz9371O542M1432N1418M15caKJ1453M98dK14ffOzz1202h1082kzz8275bh8275dh1033ILz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB010.red002.local; RD:none; EFVD:NLI Received: from mail80-va3 (localhost.localdomain [127.0.0.1]) by mail80-va3 (MessageSwitch) id 1303803984384215_6257; Tue, 26 Apr 2011 07:46:24 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.239]) by mail80-va3.bigfish.com (Postfix) with ESMTP id 55581E4804E; Tue, 26 Apr 2011 07:46:24 +0000 (UTC) Received: from IE2RD2HUB010.red002.local (213.199.187.153) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 26 Apr 2011 07:46:24 +0000 Received: from IE2RD2XVS021.red002.local ([10.33.56.25]) by IE2RD2HUB010.red002.local ([10.33.16.249]) with mapi; Tue, 26 Apr 2011 00:46:16 -0700 From: Peter Mariager To: "Pascal Thubert (pthubert)" , C Chauvenet , Carsten Bormann , Oliver Hahm Date: Tue, 26 Apr 2011 00:46:12 -0700 Thread-Topic: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt Thread-Index: AcvzA7eoVQ4Aw3QbQxS0tR+2Sl7PiwBMa0VQAAGG+CACjlf3gA== Message-ID: References: <4D95B9DF.3030309@gmail.com> <4D95C1E9.1070901@gridmerge.com><1301679639.6495.12.camel@Nokia-N900><13C0FE6D-2E82-4534-BF3A-34CBE7B5A817@tzi.org> Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: da-DK, en-US Content-Type: multipart/alternative; boundary="_000_C24CA99A3076664CA3223A9A86881DC06077775B46IE2RD2XVS021r_" MIME-Version: 1.0 X-OriginatorOrg: rtx.dk Cc: "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.txt X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 07:46:28 -0000 --_000_C24CA99A3076664CA3223A9A86881DC06077775B46IE2RD2XVS021r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal et al. Yes, this is indeed correct. I have just submitted a draft for IPv6 adaptat= ion layer over DECT Ultra Low Energy. Comments much appreciated. Best Regards, Peter Mariager From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: 6. april 2011 11:23 To: C Chauvenet; Carsten Bormann; Oliver Hahm Cc: 6lowpan@ietf.org Subject: RE: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle-01.tx= t Agreed. Also, I've seen interest in IPv6 over DECT, with the advantage of an unlice= nsed band (mostly 1880 - 1900 MHz in Europe) that's dedicated to the techno= logy. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of C Chauvenet > Sent: Wednesday, April 06, 2011 10:45 AM > To: Carsten Bormann; Oliver Hahm > Cc: 6lowpan@ietf.org > Subject: Re: [6lowpan] WG adoption of draft-patil-6lowpan-v6over-btle- > 01.txt > > Hi All, > > I definitely push the idea of a "generic IPv6 over low power foo" specifi= cation > (if achievable). > IPv6 may be used over various low power media, and if a generic adaptatio= n > layer can be designed, this may avoid to write a specification fo each lo= w > power media (exiting and to appear) that use IPv6. > By the way, low power media cannot be restricted to wireless media. We > also have to consider wired media (like low power PLC currentlty specifie= d in > IEEE P1901.2) as they shared many requirements with well known LoWPAN > technologies. > > C=E9dric. > > -----Message d'origine----- > De : 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] De la > part de Carsten Bormann Envoy=E9 : lundi 4 avril 2011 22:05 =C0 : Oliver = Hahm Cc : > 6lowpan@ietf.org Objet : Re: [6lowpan] WG adoption of draft-patil-6lowpan= - > v6over-btle-01.txt > > On Apr 1, 2011, at 19:40, Oliver Hahm wrote: > > > Therefore, a more generic specification for IPv6 over low-power wireles= s > foo would be really interesting for us - and probably a lot of other peop= le as > CC1020 and CC110x are very popular transceivers for WSN. > > I think that is an interesting idea. How much of such a specification co= uld be > generic and how much would need to be specific to each of the radios? Ca= n > you describe the decisions you had to take in applying 6LoWPAN to these > radios? > > And, even better, can you write a draft? > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --_000_C24CA99A3076664CA3223A9A86881DC06077775B46IE2RD2XVS021r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [6lowpan] WG adoption of draft-= patil-6lowpan-v6over-btle-01.txt

Hi Pascal et al.

 

= Yes, this is indeed correct. I have just submitted a draft for IPv6 adaptat= ion layer over DECT Ultra Low Energy.

Comments much appreciated.

Best Regards,
= Peter Mariager

From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = 6. april 2011 11:23
To: C Chauvenet; Carsten Bormann; Oliver Hahm=
Cc: 6lowpan@ietf.org
Subject: RE: [6lowpan] WG adoptio= n of draft-patil-6lowpan-v6over-btle-01.txt

 

Agreed.

A= lso, I've seen interest in IPv6 over DECT, with the advantage of an unlicen= sed band (mostly 1880 - 1900 MHz in Europe) that's dedicated to the technol= ogy.

Pascal
http://www.xtranormal.com/watch/7011357/

 

> -----Original Message----- =
> From: 6lowpan= -bounces@ietf.org [mailto:6lowpan-bounces@ietf.= org] On
> Behalf Of C Chauvenet
> Sent: Wednesday, April 06, 201= 1 10:45 AM
> To: Carsten Bormann; Oliver Hahm
> Cc:= 6lowpan@ietf.org
> Subject: Re: [6lowpan] WG adoption of draft-= patil-6lowpan-v6over-btle-
> 01.txt <= br>>
> H= i All,
>
> I definitely push the idea of a "gene= ric IPv6 over low power foo" specification <= br>> (if achievable= ).
> IPv6 may be used over various low power media, and if a gen= eric adaptation
> layer can be designed, this may avoid to write= a specification fo each low
> power media (exiting and to appea= r) that use IPv6.
> By the way, low power media cannot be restri= cted to wireless media. We
> also have to consider wired media = (like low power PLC currentlty specified in
<= /span>> IEEE P1901.2) as t= hey shared many requirements with well known LoWPAN
> technologi= es.
>
> C=E9dric.
>
> -----Mess= age d'origine-----
> De : 6lowpan-bounces@ietf.org [= mailto:6lowpan-bounces@ietf.org] De la =
> part de Carst= en Bormann Envoy=E9 : lundi 4 avril 2011 22:05 =C0 : Oliver Hahm = Cc :
> 6lowpan@ietf.org Objet : Re: [6lowpan] WG adopt= ion of draft-patil-6lowpan-
> v6over-btle-01.txt
>
> On Apr 1, 2011, at 19:40, Oliver Hahm wrote:
>
> > Therefore, a more generic specification for IPv6 over low-power= wireless
> foo would be really interesting for us - and probabl= y a lot of other people as
> CC1020 and CC110x are very popular= transceivers for WSN.
>
> I think that is an interes= ting idea.  How much of such a specification could be
> gen= eric and how much would need to be specific to each of the radios?  Ca= n
> you describe the decisions you had to take in applying 6LoWP= AN to these
> radios?
> <= br>> And, even bett= er, can you write a draft?
>
> Gruesse, Carsten
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinf= o/6lowpan
>
> > _______________= ________________________________
> 6lowpan mailing list
= > 6lowpan@ietf.org
> = https://www.ietf.org/mailman/listinfo/6lowpan

= --_000_C24CA99A3076664CA3223A9A86881DC06077775B46IE2RD2XVS021r_-- From m.pouillot@watteco.com Tue Apr 26 06:43:57 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B455E075D for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 06:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 ffnX5IG+o1AV for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 06:43:56 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4BFE072C for <6lowpan@ietf.org>; Tue, 26 Apr 2011 06:43:56 -0700 (PDT) Received: from mail153-ch1-R.bigfish.com (216.32.181.172) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.8; Tue, 26 Apr 2011 13:43:55 +0000 Received: from mail153-ch1 (localhost.localdomain [127.0.0.1]) by mail153-ch1-R.bigfish.com (Postfix) with ESMTP id 406D5EB8358 for <6lowpan@ietf.org>; Tue, 26 Apr 2011 13:43:55 +0000 (UTC) X-SpamScore: -7 X-BigFish: VPS-7(zz14ffOzz1202hzz8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB016.red002.local; RD:none; EFVD:NLI Received: from mail153-ch1 (localhost.localdomain [127.0.0.1]) by mail153-ch1 (MessageSwitch) id 1303825434757501_7259; Tue, 26 Apr 2011 13:43:54 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail153-ch1.bigfish.com (Postfix) with ESMTP id AD8A31490055 for <6lowpan@ietf.org>; Tue, 26 Apr 2011 13:43:54 +0000 (UTC) Received: from IE2RD2HUB016.red002.local (213.199.187.153) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 26 Apr 2011 13:43:48 +0000 Received: from IE2RD2XVS151.red002.local ([10.43.202.15]) by IE2RD2HUB016.red002.local ([10.43.198.14]) with mapi; Tue, 26 Apr 2011 06:43:48 -0700 From: M Pouillot To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Tue, 26 Apr 2011 06:44:14 -0700 Thread-Topic: snmp over 6lowpan Thread-Index: AcwEFv5Ss0jUMzPKQl+oMWCXjZ6J9Q== Message-ID: <555DED900DD42348B2995D1005EF166202600AA487@IE2RD2XVS151.red002.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_555DED900DD42348B2995D1005EF166202600AA487IE2RD2XVS151r_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: [6lowpan] snmp over 6lowpan X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:43:57 -0000 --_000_555DED900DD42348B2995D1005EF166202600AA487IE2RD2XVS151r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJJyBtIGludGVyZXN0ZWQgYnkgdGhlIHdvcmsgb24gdGhlIHNtdHAgZHJhZnQu IFdoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGlzPw0KDQpiZXN0IHJlZ2FyZHMsDQoNCk1hdGhpZXUN Cg0K --_000_555DED900DD42348B2995D1005EF166202600AA487IE2RD2XVS151r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29B Y2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxs ZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRl IGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUZSIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPkhpIGFsbCwgPG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD5JJyBtIGludGVyZXN0ZWQgYnkgdGhlIHdvcmsgb24gdGhlIHNtdHAgZHJhZnQu IFdoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGlzPyA8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPmJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPk1hdGhpZXU8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_555DED900DD42348B2995D1005EF166202600AA487IE2RD2XVS151r_-- From Basavaraj.Patil@nokia.com Tue Apr 26 06:59:44 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297EBE077A for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 06:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 snU3Dwc53X1m for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 06:59:38 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0B9E07A9 for <6lowpan@ietf.org>; Tue, 26 Apr 2011 06:59:38 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3QDxYVf001905; Tue, 26 Apr 2011 16:59:37 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 16:59:29 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 26 Apr 2011 15:59:29 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0289.008; Tue, 26 Apr 2011 15:59:28 +0200 From: To: , Thread-Topic: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] Thread-Index: AQHMBBoo5vtqRw8m/E2ZaVWwsAa2yw== Date: Tue, 26 Apr 2011 13:59:28 +0000 Message-ID: In-Reply-To: <7289A47C-61EC-4E55-B201-1F4950517D3F@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.137] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5D88059F38DF6343890C5269EAB1807A@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Apr 2011 13:59:29.0584 (UTC) FILETIME=[29529300:01CC041A] X-Nokia-AV: Clean Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:59:44 -0000 Agree. Erik has made some very good points. I don=B9t see a need for extending the ND I-D further. The core protocol should be simple enough and that will suit most use cases. However if Pascal has this special use case and applicability, he could write another I-D explicitly for that purpose. I see no reason to include Pascal's proposed enhancements in the 6lowpan ND I-D. -Raj On 4/26/11 12:15 AM, "ext Pete St. Pierre" wrote: >Geoff - >I think Erik has made some very good points on this topic. I don't see a >need to make the ND draft any more complex than it already is. > >...Pete > >On Apr 21, 2011, at 12:42 PM, Geoff Mulligan wrote: > >> Pascal, >> I couple of people supporting the TID is not group consensus. We have >> had many presentations and discussions about multiple LBRs, backbone >> LBRs and more and none have met with the support of the working group. >>=20 >> In your opinions we are crashing, but I fail to see that this is the >> opinion of the working group. >>=20 >> If there are other in the working group that strongly advocate this TID >> idea or the work on multiple and backbone LBRs then they need to speak >> up now en masse or we must move on. >>=20 >> geoff >>=20 >>=20 >> On Thu, 2011-04-21 at 21:32 +0200, Pascal Thubert (pthubert) wrote: >>> Geoff: >>>=20 >>> There is twice as much support for restoring the TID than there is for >>> not doing it. >>> Before we drop the TID, I'd like to see a proposal that allows a >>>6LoWPAN ND subnet to scale with multiple LBRs, allows nodes to move >>>from a router to the next, and that does not need a TID. >>> Otherwise, we are not speeding towards the wall, we're already >>>crashing. >>>=20 >>> Pascal >>> http://www.xtranormal.com/watch/7011357/ >>>=20 >>>> -----Original Message----- >>>> From: Geoff Mulligan [mailto:geoff.ietf@mulligan.com] >>>> Sent: Thursday, April 21, 2011 5:41 PM >>>> To: Pascal Thubert (pthubert) >>>> Cc: Erik Nordmark; nicolas.riou@schneider-electric.com; >>>>6lowpan@ietf.org >>>> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" >>>>flag in >>>> ARO] >>>>=20 >>>> Pascal, >>>> We need to close on this discussion. >>>>=20 >>>> Back in Hiroshima the Working Group decided that Backbone router >>>>stuff and >>>> "address defense" across backbone routers was not going to be part of >>>>ND >>>> draft. It appeared that the draft was getting way to complicated and >>>>the >>>> Working Group decided to simplify things. >>>>=20 >>>> I have not seen much support on the list for making these changes to >>>>include >>>> the TID in ND. >>>>=20 >>>> We need to get this draft completed. If there is a large "unheard >>>>from" >>>> support group for these changes, please speak up or we shall move >>>>forward >>>> with the draft as it is. >>>>=20 >>>> geoff >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote: >>>>> Hi Erik >>>>>=20 >>>>> The TID is not a strong coupling between the H2R and the R2R >>>>>operations, >>>> and it is not a coupling with a RPL version explicitly. >>>>> It is an abstract information that if defined properly can be used >>>>>by many >>>> forms or R2R interactions. >>>>> As demonstrated by older versions of the ND spec (Backbone Router), >>>>>RPL, >>>> and MIP. >>>>>=20 >>>>> 6LoWPAN ND cannot scale if the node needs to register to all LBRs. >>>> 6LoWPAN ND does not define anymore any LBR interaction. >>>>> IOW, 6LoPWAN ND lost the capability to scale when the backbone router >>>> piece was removed from the draft. >>>>> Which means that it lost its capability to apply in the domains I'm >>>>>looking at >>>> (industrial and metering). >>>>>=20 >>>>> With the TID, we know that we can restore scalability in the future, >>>>>and we >>>> know how. I do not know of a plan B. >>>>>=20 >>>>> Pascal >>>>> http://www.xtranormal.com/watch/7011357/ >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Erik Nordmark [mailto:nordmark@acm.org] >>>>>> Sent: Thursday, April 21, 2011 1:25 AM >>>>>> To: nicolas.riou@schneider-electric.com >>>>>> Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko >>>>>> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" >>>>>> flag in ARO] >>>>>>=20 >>>>>> On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: >>>>>>>=20 >>>>>>> Dear Pascal and al, >>>>>>>=20 >>>>>>> I support the idea of reviving the TID in ARO and DAR/DAC. >>>>>>> Supporting a TID directly in the node initiating the initial NS >>>>>>> appears much simpler than time stamping in the parent router. >>>>>>=20 >>>>>> How would you make this work if the protocol between the routers is >>>>>> not RPLv1, but some future version of RPL or a completely different >>>>>> routing protocol? >>>>>>=20 >>>>>> The decoupling of the host-router interaction from router-router >>>>>> interaction has served us well in the history of the Internet. >>>>>>=20 >>>>>> Erik >>>>>>=20 >>>>>>> A simple and efficient method to detect mobility of hosts along a >>>>>>> backbone of Edge Routers is an important feature to deploy >>>>>>> backbones of Edge Routers in Buildings and should be clarified >>>>>>> before closing 6LoWPAN WG. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Nicolas >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> *"Pascal Thubert (pthubert)" * Envoy=E9 par : >>>>>>> 6lowpan-bounces@ietf.org >>>>>>>=20 >>>>>>> 18/04/2011 10:37 >>>>>>>=20 >>>>>>>=20 >>>>>>> A >>>>>>> "Dijk, Esko" , "Erik Nordmark" >>>>>>> cc >>>>>>> 6lowpan@ietf.org >>>>>>> Objet >>>>>>> Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag >>>>>>>in >>>>>> ARO] >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Hi Esko, Erik >>>>>>>=20 >>>>>>> The discussion on RPL and hosts should happen on the RPL list >>>>>>> under a different topic. The point being discussed here is this: >>>>>>>=20 >>>>>>> The reality is also that those (LLN) networks will need to scale >>>>>>> to large subnets in plants, building, etc... (see the requirement >>>>>>> drafts in ROLL). Registering to all LBRS is totally impractical. >>>>>>> 6LoWPAN ND requires a coordination between LBRs but does not say >>>> how it happens. >>>>>>> This problem was discussed in 6LoWPAN; the answer was in >>>>>>> ND-01to07; and it requires a TID, for the same reason as RPL. >>>>>>> Removing the backbone operation and the TID from the draft is >>>>>>>ostrich >>>> policy. >>>>>>>=20 >>>>>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all >>>>>>> other registrations do when strict ordering is not guaranteed (MIP >>>>>>> being an example). Say that due to some config, a node registers a >>>>>>> lifetime of X, then deregisters (lifetime 0), then reregisters >>>>>>> (lifetime X) in a rapid sequence, but does not get an answer yet. >>>>>>> Then it finally gets 2 AROs back, lifetime X and 0. What's the >>>>>>>final state >>>> in the router? >>>>>>>=20 >>>>>>> I'd like to hear what others think. >>>>>>>=20 >>>>>>> Pascal >>>>>>> http://www.xtranormal.com/watch/7011357/ >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: >>>>>>> Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal >>>>>>> Thubert >>>>>>> (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: >>>>>>> TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello >>>>>>> Erik, >>>>>>>>> taking the definition you quoted: >>>>>>>> 'host' refers to an LLN device that can generate but does not >>>>>>> forward > RPL traffic > > the question may arise what is "RPL >>>>>>> traffic"? It is not defined in the RPL draft > it seems. Pascal >>>>>>> clarified to me it is traffic associated to a RPL instance, not > >>>>>>> necessarily RPL protocol messages. This means that a host could >>>>>>> generate > RPL traffic without being aware of the existence of >>>>>>> RPL at all. So, _not_ all > hosts have to speak RPL? >>>>>>>> The RPL draft does not explicitly state if "hosts" in a RPL >>>>>>> network always > speak RPL, never speak RPL, or can be mixed >>>>>>> RPL/non-RPL speakers. >>>>>>>>=20 >>>>>>>> Taking the definition of 'node' in the RPL draft: >>>>>>>> 'node' refers to any RPL device, either a host or a router > >>>>>>>> rules out (?) the option that all "hosts" are non-RPL speakers, >>>>>>> since there > may be a "RPL device" (i.e. RPL-speaking device, I >>>>>>> assume) that is also a host. >>>>>>>>=20 >>>>>>>> I communicated these perceived unclarities to Pascal and the >>>>>>> RFC editor 2 > weeks ago. Once this is clear I think the present >>>>>>> discussion can continue. >>>>>>>> And then there is the related discussion of ND support for >>>>>>> sleepy devices, > the original topic of Anders ;) > > best >>>>>>> regards, > > Esko > > > > -----Original Message----- > From: >>>>>>> 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >>>>>>> Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: >>>>>>> Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: >>>>>>> [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > >>>>>>> ARO] >>>>>>>>> On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: >>>>>>>>=20 >>>>>>>>> RPL can do what all classical IGPs can do WRT hosts. That is >>>>>>> as long > > as the host address belongs to the router's prefix >>>>>>> and stays attached > > to that router. >>>>>>>>=20 >>>>>>>> I just realized that we might be talking about a different >>>>>>> definition of "host". >>>>>>>> What I mean by "host" is a node which does not participate in a >>>>>>> routing > protocol, and does not forward packets (except packets >>>>>>> explicitly addressed > to itself using e.g., a routing header). >>>>>>>>=20 >>>>>>>> However, RPL has a different definition: >>>>>>>> 'host' refers to an LLN device that can generate but does not >>>>>>> forward > RPL traffic > > Basically per the RPL definition >>>>>>> there is no such thing as a node which does > not participate in >>>>>>> the RPL protocol. >>>>>>>> IMHO what is in RPL should have been defined as a >>>>>>> non-forwarding node, so > that we can have a sane discussion >>>>>>> without getting entangled in terminology > issues. >>>>>>>>=20 >>>>>>>> Which definition of "host" are you using above? >>>>>>>>=20 >>>>>>>> Per the RPL definition there is no need for 6lowpan-nd, since >>>>>>> all nodes will > speak RPL. This is rather confusing, don't you >>>>>>>think? >>>>>>>>=20 >>>>>>>> Erik >>>>>>>>=20 >>>>>>>>> When the topology becomes multilink subnet and mobility is >>>>>>> required > > then it is a new problem entirely, and NO, 4861 is >>>>>>> not a suitable > > interaction with the router to allow the >>>>>>> router to redistribute a host route. >>>>>>>>> Because the neighbor cache that 4861 builds is not a of the >>>>>>> same >>>>>>>>> nature as the binding table that 6LoWPAN ND builds. Another >>>>>>>>> thing >>>>>>> that > > 6LoWPAN ND fails to express correctly. I proposed text >>>>>>> to explain that > > (attached) but it was not considered, >>>>>>> contributing to the illusion > > that a cache is a table. >>>>>>>>>=20 >>>>>>>>> The reality is also that those networks will need to scale to >>>>>>> large > > subnets in plants, building, etc... (see the >>>>>>> requirement drafts in > > ROLL). Registering to all LBRS is >>>>>>>totally >>>> impractical. >>>>>>> 6LoWPAN ND > > requires a coordination between LBRs but does not >>>>>>> say how it happens. >>>>>>>>> This problem was discussed in 6LoWPAN; the answer was in >>>>>>> ND-01to07; > > and it requires a TID, for the same reason as RPL. >>>>>>> Removing the > > backbone operation and the TID from the draft is >>>>>>> ostrich >>>>>> policy. >>>>>>>>>=20 >>>>>>>>> RPL already adapted to the new reality of large multilink >>>>>>> subnet with > > inner mobility. Placing the blame on RPL is >>>>>>> another illusionist trick. >>>>>>>>> And this is not RPL last call. >>>>>>>>>=20 >>>>>>>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as >>>>>>> all other > > registrations do when strict ordering is not >>>>>>> guaranteed (MIP being an > > example). Say that due to some >>>>>>> config, a node registers a lifetime of > > X, then deregisters >>>>>>> (lifetime 0), then reregisters (lifetime X) in a > > rapid >>>>>>> sequence, but does not get an answer yet. Then it finally gets >>>>>>> 2 >>>>>>>>> AROs back, lifetime X and 0. What's the final state in the >>>>>>>>>router? >>>>>>>>>=20 >>>>>>>>> It seems we can never agree on any of this. I'd like to hear >>>>>>> what >>>>>>>>> others think. >>>>>>>>>=20 >>>>>>>>> Pascal >>>>>>>>> http://www.xtranormal.com/watch/7011357/ >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- >>>>>> bounces@ietf.org] >>>>>>> On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, >>>>>>> 2011 >>>>>>> 1:30 AM > >> To: 6lo>> '6lowpan' >>>>>>>>>> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag >>>>>>> in ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert >>>>>>> (pthubert) >>>>>>> wrote: >>>>>>>>>>> Hi Erik: >>>>>>>>>>>=20 >>>>>>>>>>> The RPL (DAO) sequence number allows the node to increment >>>>>>> rapidly > >>> in case of rapid changes and then lazily when the >>>>>>> situation is > >>> stable and DAO are scarce. The increase is >>>>>>> strictly monotonous which > > > >>> is critical to us. >>>>>>>>>>>=20 >>>>>>>>>>> A time stamp imposes a synchronization between the routers. >>>>>>> We do > >>> not have such mechanism in RPL. A time unit (a >>>>>>> granularity) must be > >>> agreed upon. Within that unit, >>>>>>> movements go undetected so the time > >>> unit must be thin >>>>>>>grained >>>> to cover rapid changes. >>>>>>> Yet, depending on > >>> the medium, the time unit, and the size >>>>>>> of the network, it is not > >>> necessarily easy/possible to >>>>>>> guarantee a strictly monotonous value > >>> with a thin grained >>>>>>> time unit. And we have limited space (2 >>>>>>> octets) >>>>>>>>>>> and have to deal with wrap around, which divides the space >>>>>>> by at > > least 3. >>>>>>>>>>>=20 >>>>>>>>>>> So RPL went for a sequence number. >>>>>>>>>>=20 >>>>>>>>>> But the unstated assumption that RPL made is that all >>>>>>> host-to-router > >> protocols have to now be RPL aware. That >>>>>>> doesn't sound like good > > design. >>>>>>>>>> A host isn't aware of whether the routers speak IS-IS or >>>>>>> OSPF, so why > >> do the hosts need to be aware of RPL by passing >>>>>>> some TID around? >>>>>>>>>>=20 >>>>>>>>>>> I think ND has the same need as MIP for a TID =3D=3D Sequence #= . >>>>>>> We > >>> know of MIP; We know of RPL. We know of the backbone >>>>>>> router >>>>>>>>>>> operation. We know we'll need the TID and we know exactly >>>>>>>>>>> why. I think we should have it in the 6LowPAN ND spec right >>>>>>>>>>> away to >>>>>>> avoid > >>> interop issues when we add RPL and BR operations. >>>>>>>>>>=20 >>>>>>>>>> I don't see a need in 6lowpan-nd for a TID; the protocol >>>>>>> works fine > > without it. >>>>>>>>>> I think RPL needs to be improved to deal with reality. Isn't >>>>>>> there a > >> desire for RPL to handle 4861 hosts? Those would >>>>>>> never know about a > > TID. >>>>>>>>>>=20 >>>>>>>>>> Erik >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> 6lowpan mailing list >>>>>>>>>> 6lowpan@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> 6lowpan@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 6lowpan mailing list >>>>>>>> 6lowpan@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>=20 >>>>>>>> The information contained in this message may be confidential >>>>>>> and legally > protected under applicable law. The message is >>>>>>> intended solely for the > addressee(s). If you are not the >>>>>>> intended recipient, you are hereby notified > that any use, >>>>>>> forwarding, dissemination, or reproduction of this message is > >>>>>>> strictly prohibited and may be unlawful. If you are not the >>>>>>> intended recipient, > please contact the sender by return e-mail >>>>>>> and destroy all copies of the > original message. >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>> __________________________________________________________ >>>>>> ____________ >>>>>>> This email has been scanned by the MessageLabs Email Security >>>> System. >>>>>>>=20 >>>>>>=20 >>>> __________________________________________________________ >>>>>> ____________ >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From jreddy@ti.com Tue Apr 26 08:50:57 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6129DE0681 for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 08:50:57 -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 H+qTqM2vCpGW for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 08:50:56 -0700 (PDT) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by ietfa.amsl.com (Postfix) with ESMTP id B51BCE07CC for <6lowpan@ietf.org>; Tue, 26 Apr 2011 08:50:56 -0700 (PDT) Received: from dlep35.itg.ti.com ([157.170.170.118]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id p3QFoodu012381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:50:50 -0500 Received: from dlep26.itg.ti.com (localhost [127.0.0.1]) by dlep35.itg.ti.com (8.13.7/8.13.7) with ESMTP id p3QFooin027632 for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:50:50 -0500 (CDT) Received: from dlee73.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p3QFooep018429 for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:50:50 -0500 (CDT) Received: from dlee02.ent.ti.com ([157.170.170.17]) by dlee73.ent.ti.com ([157.170.170.88]) with mapi; Tue, 26 Apr 2011 10:50:30 -0500 From: "Reddy, Joseph" To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Tue, 26 Apr 2011 10:50:27 -0500 Thread-Topic: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO Thread-Index: AcwD0PYDKjtLm146QWGGLacaxGgn5AAWH10w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 15:50:57 -0000 =20 I agree we should move forward with this draft without adding additional fe= atures.=20 -Joseph ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Apr 2011 15:00:04 -0400 From: Samita Chakrabarti To: Erik Nordmark , "Pascal Thubert (pthubert)" , "nicolas.riou@schneider-electric.com" Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO Message-ID: <16D60F43CA0B724F8052D7E9323565D71B8FAF2786@EUSAACMS0715.eamcs.ericsson.se= > =09 Content-Type: text/plain; charset=3D"us-ascii" =20 Hi Pascal and Nicolas, I am in agreement with the following reasons (by Erik) as to why we don't w= ant to add the TID/sequence# in the ARO message. As discussed many times in= the wg that the goal of this 6lowpan-nd work is to provide simple optimize= d neighbor discovery functionality of the low-power IPv6 network. This is i= ndependent of routing protocol functionalities such that it works with mult= iple routing protocols on top of it. If RPL or other routing protocol needs a specific information to pass arou= nd, it could do that as an option aka future extension of 6lowpan-nd. We al= ready decided/presented in the Prague wg meeting and the consensus was to = move forward with the 6lowpan-nd as it is plus the editorial changes discus= sed at the meeting slides. Besides the dependency of 6lowpan-nd on a specific routing protocol( such a= s RPL or backbone routing), I have a major concern including a feature like= sequence# in the ARO message at this point for supporting a corner case wi= thout knowing its larger impact. As for MIP, I am not sure if we want to run MIPv6 as it is in the 6lowpan n= etwork. Our design goal for 6lowpan-nd-basic is to provide the core functio= nality and then build things on top of it on a modular basis as needed. Please help in proceeding toward the basic 6lowpan-nd work done first. Best regards, -Samita | A host isn't aware of whether the routers speak IS-IS or OSPF, so why do = the hosts need to be aware of RPL by | passing some TID around? > I think ND has the same need as MIP for a TID =3D=3D Sequence # . We know= =20 > of MIP; We know of RPL. We know of the backbone router operation. We=20 > know we'll need the TID and we know exactly why. I think we should=20 > have it in the 6LowPAN ND spec right away to avoid interop issues when=20 > we add RPL and BR operations. | I don't see a need in 6lowpan-nd for a TID; the protocol works fine witho= ut it. | I think RPL needs to be improved to deal with reality. Isn't there a desi= re for RPL to handle 4861 hosts? | | | Those would never know about a TID. | Erik _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From behcetsarikaya@yahoo.com Tue Apr 26 10:01:13 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF6E076E for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 10:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599] 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 Dv6tk4NVZGs2 for <6lowpan@ietfa.amsl.com>; Tue, 26 Apr 2011 10:01:11 -0700 (PDT) Received: from nm26-vm1.bullet.mail.sp2.yahoo.com (nm26-vm1.bullet.mail.sp2.yahoo.com [98.139.91.231]) by ietfa.amsl.com (Postfix) with SMTP id 5E332E07BB for <6lowpan@ietf.org>; Tue, 26 Apr 2011 10:01:06 -0700 (PDT) Received: from [98.139.91.67] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000 Received: from [98.139.91.27] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 26 Apr 2011 17:01:03 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 594967.77437.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 11117 invoked by uid 60001); 26 Apr 2011 17:01:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303837263; bh=uNENozqii04nE6fk5ce0WYfvVW/lUbkj3fr3F++1LX0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=J3L1nXDgaimqDGtu1YebjuGDyAJOhnK5d/r7YAd7UoqcnaVJfKZJ0FB4IdwrLy/Wn8BYo59hmtimE9pWVAdnFsvYaUVWgAN7D+yQKlkV3xSag0ZK/f5mCuhciW14bidmzQ8ZSnThxg8V8a0N2Uk8gbfkIxeyNdSlCiHdSf0M5UI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5/9rpqRaMGfIvam9/oY8Krg7HQqt/75rpxy93sM+ppScFdiUpO65u6IWaKUosTGtMlHPFtneifxN6HdV4De9XFOl7CwZBplKIVjxOKUo5XCn+RqI8yNbT6KJFYVUIERz3HLVxPvNNnEdoJUecWvihy4W9cN0Zji1/Pn6hmqV660=; Message-ID: <205310.2728.qm@web111414.mail.gq1.yahoo.com> X-YMail-OSG: eu0gA1cVM1kd5cGOYQGdGjTY9zgHtLGyCrWW31_WahnIteV fDD2yfOgbgEBosl..5_bErGvzRQFtsTzoMVTeDZwPNinx.oA6hp7wmXjIZBX qsIEgyLJy.SHB_Eg0bUeOSwg234oLlt381FCjfdFBI9q3NiU2VJhIbqLrGcr ll5tEZMao.kfT4MgymZ8m9ZOYh_yj9GcTo4PjyjPLKAIqHW0DOssVrpd1oWw ay.rtJiRjlShPZh2wp7lRYBT9lZ2Dh2DDjbQuSNFKjAnCY2fL6Fn1Qvqa.Ea XmqYHVJMzKezQ9sKffXJMkpxaHE5jcMD2qyvwRZRm7IvXhTYbb8GAKOmA2Kj J3ReUXYZK6AgLNqtxNHyI_w_A5MxLuaat7SQnNRbL0f1PuvcoXFWywg.3yID s8ldicAHoPnAq_w-- Received: from [206.16.17.212] by web111414.mail.gq1.yahoo.com via HTTP; Tue, 26 Apr 2011 10:01:03 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> <1303414920.1671.1849.camel@d430> Date: Tue, 26 Apr 2011 10:01:03 -0700 (PDT) From: Behcet Sarikaya To: Geoff Mulligan In-Reply-To: <1303414920.1671.1849.camel@d430> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:01:13 -0000 I also think that we must move on.=0A=0AWe must move on and start looking i= nto securing 6lowpan ND?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=0A=0A> Pascal,= =0A> I couple of people supporting the TID is not group consensus. We h= ave=0A> had many presentations and discussions about multiple LBRs, backbo= ne=0A> LBRs and more and none have met with the support of the working gro= up.=0A> =0A> In your opinions we are crashing, but I fail to see that this= is the=0A> opinion of the working group.=0A> =0A> If there are other in t= he working group that strongly advocate this TID=0A> idea or the work on m= ultiple and backbone LBRs then they need to speak=0A> up now en masse or we= must move on.=0A> =0A> geoff=0A> =0A> =0A> On Thu, 2011-04-21 at 21:3= 2 +0200, Pascal Thubert (pthubert) wrote:=0A> > Geoff:=0A> > =0A> > There = is twice as much support for restoring the TID than there is for not =0A>= doing it.=0A> > Before we drop the TID, I'd like to see a proposal that al= lows a 6LoWPAN ND =0A>subnet to scale with multiple LBRs, allows nodes to = move from a router to the =0A>next, and that does not need a TID.=0A> > Ot= herwise, we are not speeding towards the wall, we're already crashing.=0A>= > =0A> > Pascal=0A> > http://www.xtranormal.com/watch/7011357/=0A> > =0A>= > > -----Original Message-----=0A> > > From: Geoff Mulligan [mailto:geoff= .ietf@mulligan.com]=0A> > > Sent: Thursday, April 21, 2011 5:41 PM=0A> > >= To: Pascal Thubert (pthubert)=0A> > > Cc: Erik Nordmark; nicolas.riou@sch= neider-electric.com; 6lowpan@ietf.org=0A> > > Subject: Re: [6lowpan] FW: T= ID in ARO [was: "Advertize on Behalf" flag in=0A> > > ARO]=0A> > > =0A> > = > Pascal,=0A> > > We need to close on this discussion.=0A> > > =0A> > > = Back in Hiroshima the Working Group decided that Backbone router stuff =0A= and=0A> > > "address defense" across backbone routers was not going to be = part of ND=0A> > > draft. It appeared that the draft was getting way to c= omplicated and the=0A> > > Working Group decided to simplify things.=0A> >= > =0A> > > I have not seen much support on the list for making these chan= ges to =0A>include=0A> > > the TID in ND.=0A> > > =0A> > > We need to get = this draft completed. If there is a large "unheard from"=0A> > > support = group for these changes, please speak up or we shall move forward=0A> > > = with the draft as it is.=0A> > > =0A> > > geoff=0A> > > =0A> > > =0A>= > > =0A> > > =0A> > > On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (= pthubert) wrote:=0A> > > > Hi Erik=0A> > > >=0A> > > > The TID is not a st= rong coupling between the H2R and the R2R =0Aoperations,=0A> > > and it is= not a coupling with a RPL version explicitly.=0A> > > > It is an abstrac= t information that if defined properly can be used by =0A>many=0A> > > for= ms or R2R interactions.=0A> > > > As demonstrated by older versions of the= ND spec (Backbone Router), =0ARPL,=0A> > > and MIP.=0A> > > >=0A> > > > = 6LoWPAN ND cannot scale if the node needs to register to all LBRs.=0A> > >= 6LoWPAN ND does not define anymore any LBR interaction.=0A> > > > IOW, 6L= oPWAN ND lost the capability to scale when the backbone router=0A> > > pie= ce was removed from the draft.=0A> > > > Which means that it lost its capa= bility to apply in the domains I'm =0A>looking at=0A> > > (industrial and = metering).=0A> > > >=0A> > > > With the TID, we know that we can restore s= calability in the future, and =0A>we=0A> > > know how. I do not know of a = plan B.=0A> > > >=0A> > > > Pascal=0A> > > > http://www.xtranormal.com/wat= ch/7011357/=0A> > > >=0A> > > >=0A> > > > > -----Original Message-----=0A>= > > > > From: Erik Nordmark [mailto:nordmark@acm.org]=0A> > > > > Sent: = Thursday, April 21, 2011 1:25 AM=0A> > > > > To: nicolas.riou@schneider-ele= ctric.com=0A> > > > > Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dij= k, Esko=0A> > > > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize= on Behalf"=0A> > > > > flag in ARO]=0A> > > > >=0A> > > > > On 4/20/11 1= :21 AM, nicolas.riou@schneider-electric.com wrote:=0A> > > > > >=0A> > > > = > > Dear Pascal and al,=0A> > > > > >=0A> > > > > > I support the idea of= reviving the TID in ARO and DAR/DAC.=0A> > > > > > Supporting a TID direc= tly in the node initiating the initial NS=0A> > > > > > appears much simpl= er than time stamping in the parent router.=0A> > > > >=0A> > > > > How wo= uld you make this work if the protocol between the routers is=0A> > > > > = not RPLv1, but some future version of RPL or a completely different=0A> > = > > > routing protocol?=0A> > > > >=0A> > > > > The decoupling of the host= -router interaction from router-router=0A> > > > > interaction has served = us well in the history of the Internet.=0A> > > > >=0A> > > > > Eri= k=0A> > > > >=0A> > > > > > A simple and efficient method to detect mobili= ty of hosts along a=0A> > > > > > backbone of Edge Routers is an important= feature to deploy=0A> > > > > > backbones of Edge Routers in Buildings an= d should be clarified=0A> > > > > > before closing 6LoWPAN WG.=0A> > > > = > >=0A> > > > > > Cheers,=0A> > > > > > Nicolas=0A> > > > > >=0A> > > > > = >=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > > *= "Pascal Thubert (pthubert)" * Envoy=E9 par :=0A> > > = > > > 6lowpan-bounces@ietf.org=0A> > > > > >=0A> > > > > > 18/04/2011 10:3= 7=0A> > > > > >=0A> > > > > >=0A> > > > > > A=0A> > > > > > "Dijk, Es= ko" , "Erik Nordmark"=0A> > > > > > cc=0A> > > > > > 6lowpan@ietf.org=0A> > > > > > Objet=0A> > > > >= > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag =0Ain= =0A> > > > > ARO]=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > >= =0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > >=0A> > > > > > Hi= Esko, Erik=0A> > > > > >=0A> > > > > > The discussion on RPL and hosts sh= ould happen on the RPL list=0A> > > > > > under a different topic. The poi= nt being discussed here is this:=0A> > > > > >=0A> > > > > > The reality i= s also that those (LLN) networks will need to scale=0A> > > > > > to larg= e subnets in plants, building, etc... (see the requirement=0A> > > > > > d= rafts in ROLL). Registering to all LBRS is totally impractical.=0A> > > > = > > 6LoWPAN ND requires a coordination between LBRs but does not say=0A> >= > how it happens.=0A> > > > > > This problem was discussed in 6LoWPAN; th= e answer was in=0A> > > > > > ND-01to07; and it requires a TID, for the sa= me reason as RPL.=0A> > > > > > Removing the backbone operation and the TI= D from the draft is =0A>ostrich=0A> > > policy.=0A> > > > > >=0A> > > > >= > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all=0A> > = > > > > other registrations do when strict ordering is not guaranteed (MIP= =0A> > > > > > being an example). Say that due to some config, a node regi= sters a=0A> > > > > > lifetime of X, then deregisters (lifetime 0), then r= eregisters=0A> > > > > > (lifetime X) in a rapid sequence, but does not ge= t an answer yet.=0A> > > > > > Then it finally gets 2 AROs back, lifetime = X and 0. What's the final =0A>state=0A> > > in the router?=0A> > > > > >= =0A> > > > > > I'd like to hear what others think.=0A> > > > > >=0A> > > >= > > Pascal=0A> > > > > > http://www.xtranormal.com/watch/7011357/=0A> > >= > > >=0A> > > > > >=0A> > > > > > > -----Original Message-----=0A> > > = > > > > From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent:=0A> > >= > > > Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal=0A> > = > > > > Thubert=0A> > > > > > (pthubert) > Cc: 6lowpan@ietf.org > Subjec= t: RE: [6lowpan] FW:=0A> > > > > > TID in ARO [was: "Advertize on Behalf" = flag in > ARO] > > Hello=0A> > > > > > Erik,=0A> > > > > > > > taking= the definition you quoted:=0A> > > > > > > 'host' refers to an LLN devic= e that can generate but does not=0A> > > > > > forward > RPL traffic > = > the question may arise what is "RPL=0A> > > > > > traffic"? It is not d= efined in the RPL draft > it seems. Pascal=0A> > > > > > clarified to me = it is traffic associated to a RPL instance, not >=0A> > > > > > necessar= ily RPL protocol messages. This means that a host could=0A> > > > > > gene= rate > RPL traffic without being aware of the existence of=0A> > > > > > = RPL at all. So, _not_ all > hosts have to speak RPL?=0A> > > > > > > The= RPL draft does not explicitly state if "hosts" in a RPL=0A> > > > > > ne= twork always > speak RPL, never speak RPL, or can be mixed=0A> > > > > > = RPL/non-RPL speakers.=0A> > > > > > >=0A> > > > > > > Taking the definit= ion of 'node' in the RPL draft:=0A> > > > > > > 'node' refers to any RPL = device, either a host or a router >=0A> > > > > > > rules out (?) the op= tion that all "hosts" are non-RPL speakers,=0A> > > > > > since there > m= ay be a "RPL device" (i.e. RPL-speaking device, I=0A> > > > > > assume) th= at is also a host.=0A> > > > > > >=0A> > > > > > > I communicated these= perceived unclarities to Pascal and the=0A> > > > > > RFC editor 2 > wee= ks ago. Once this is clear I think the present=0A> > > > > > discussion ca= n continue.=0A> > > > > > > And then there is the related discussion of N= D support for=0A> > > > > > sleepy devices, > the original topic of Ander= s ;) > > best=0A> > > > > > regards, > > Esko > > > > -----Origin= al Message----- > =0AFrom:=0A> > > > > > 6lowpan-bounces@ietf.org [mailto= :6lowpan-bounces@ietf.org] On >=0A> > > > > > Behalf Of Erik Nordmark > = Sent: Friday 15 April 2011 18:39 > To:=0A> > > > > > Pascal Thubert (pth= ubert) > Cc: 6lowpan@ietf.org > Subject: Re:=0A> > > > > > [6lowpan] FW:= TID in ARO [was: "Advertize on Behalf" flag in >=0A> > > > > > ARO]=0A> = > > > > > > > On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote:=0A> = > > > > > >=0A> > > > > > > > RPL can do what all classical IGPs can do = WRT hosts. That is=0A> > > > > > as long > > as the host address belongs = to the router's prefix=0A> > > > > > and stays attached > > to that rout= er.=0A> > > > > > >=0A> > > > > > > I just realized that we might be tal= king about a different=0A> > > > > > definition of "host".=0A> > > > > > = > What I mean by "host" is a node which does not participate in a=0A> > >= > > > routing > protocol, and does not forward packets (except packets= =0A> > > > > > explicitly addressed > to itself using e.g., a routing hea= der).=0A> > > > > > >=0A> > > > > > > However, RPL has a different defi= nition:=0A> > > > > > > 'host' refers to an LLN device that can generate = but does not=0A> > > > > > forward > RPL traffic > > Basically per the = RPL definition=0A> > > > > > there is no such thing as a node which does = > not participate in=0A> > > > > > the RPL protocol.=0A> > > > > > > IMH= O what is in RPL should have been defined as a=0A> > > > > > non-forwardin= g node, so > that we can have a sane discussion=0A> > > > > > without get= ting entangled in terminology > issues.=0A> > > > > > >=0A> > > > > > = > Which definition of "host" are you using above?=0A> > > > > > >=0A> > >= > > > > Per the RPL definition there is no need for 6lowpan-nd, since= =0A> > > > > > all nodes will > speak RPL. This is rather confusing, don'= t you =0A>think?=0A> > > > > > >=0A> > > > > > > Erik=0A> > > > > > >= =0A> > > > > > > > When the topology becomes multilink subnet and mobilit= y is=0A> > > > > > required > > then it is a new problem entirely, and NO= , 4861 is=0A> > > > > > not a suitable > > interaction with the router t= o allow the=0A> > > > > > router to redistribute a host route.=0A> > > > >= > > > Because the neighbor cache that 4861 builds is not a of the=0A> > = > > > > same=0A> > > > > > > > nature as the binding table that 6LoWPAN ND= builds. Another=0A> > > > > > > > thing=0A> > > > > > that > > 6LoWPAN = ND fails to express correctly. I proposed text=0A> > > > > > to explain th= at > > (attached) but it was not considered,=0A> > > > > > contributing t= o the illusion > > that a cache is a table.=0A> > > > > > > >=0A> > > >= > > > > The reality is also that those networks will need to scale to=0A= > > > > > > large > > subnets in plants, building, etc... (see the=0A> > = > > > > requirement drafts in > > ROLL). Registering to all LBRS is =0A>= totally=0A> > > impractical.=0A> > > > > > 6LoWPAN ND > > requires a coor= dination between LBRs but does not=0A> > > > > > say how it happens.=0A> >= > > > > > > This problem was discussed in 6LoWPAN; the answer was in=0A>= > > > > > ND-01to07; > > and it requires a TID, for the same reason as = RPL.=0A> > > > > > Removing the > > backbone operation and the TID from t= he draft is=0A> > > > > > ostrich=0A> > > > > policy.=0A> > > > > > > >= =0A> > > > > > > > RPL already adapted to the new reality of large multil= ink=0A> > > > > > subnet with > > inner mobility. Placing the blame on RP= L is=0A> > > > > > another illusionist trick.=0A> > > > > > > > And this = is not RPL last call.=0A> > > > > > > >=0A> > > > > > > > BTW 6LoWPAN N= D needs a TID to correlate the NS and the NA as=0A> > > > > > all other >= > registrations do when strict ordering is not=0A> > > > > > guaranteed = (MIP being an > > example). Say that due to some=0A> > > > > > config, a = node registers a lifetime of > > X, then deregisters=0A> > > > > > (lifet= ime 0), then reregisters (lifetime X) in a > > rapid=0A> > > > > > sequen= ce, but does not get an answer yet. Then it finally gets=0A> > > > > > 2= =0A> > > > > > > > AROs back, lifetime X and 0. What's the final state in= the =0A>router?=0A> > > > > > > >=0A> > > > > > > > It seems we can nev= er agree on any of this. I'd like to hear=0A> > > > > > what=0A> > > > > = > > > others think.=0A> > > > > > > >=0A> > > > > > > > Pascal=0A> > > >= > > > > http://www.xtranormal.com/watch/7011357/=0A> > > > > > > >=0A>= > > > > > > >=0A> > > > > > > >> -----Original Message-----=0A> > > > = > > > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-=0A> > > > > bounc= es@ietf.org]=0A> > > > > > On > >> Behalf Of Erik Nordmark > >> Sent: Fr= iday, April 15,=0A> > > > > > 2011=0A> > > > > > 1:30 AM > >> To: 6lo>> = '6lowpan'=0A> > > > > > > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize o= n Behalf" flag=0A> > > > > > in ARO > >> > >> > >> On 4/13/11 12:53 AM= , Pascal Thubert=0A> > > > > > (pthubert)=0A> > > > > > wrote:=0A> > > > = > > > >>> Hi Erik:=0A> > > > > > > >>>=0A> > > > > > > >>> The RPL (DA= O) sequence number allows the node to increment=0A> > > > > > rapidly > >= >> in case of rapid changes and then lazily when the=0A> > > > > > situati= on is > >>> stable and DAO are scarce. The increase is=0A> > > > > > stri= ctly monotonous which > > > >>> is critical to us.=0A> > > > > > > >>>= =0A> > > > > > > >>> A time stamp imposes a synchronization between the r= outers.=0A> > > > > > We do > >>> not have such mechanism in RPL. A time= unit (a=0A> > > > > > granularity) must be > >>> agreed upon. Within tha= t unit,=0A> > > > > > movements go undetected so the time > >>> unit must= be thin =0A>grained=0A> > > to cover rapid changes.=0A> > > > > > Yet, d= epending on > >>> the medium, the time unit, and the size=0A> > > > > > o= f the network, it is not > >>> necessarily easy/possible to=0A> > > > > >= guarantee a strictly monotonous value > >>> with a thin grained=0A> > >= > > > time unit. And we have limited space (2=0A> > > > > > octets)=0A> >= > > > > > >>> and have to deal with wrap around, which divides the space= =0A> > > > > > by at > > least 3.=0A> > > > > > > >>>=0A> > > > > > > = >>> So RPL went for a sequence number.=0A> > > > > > > >>=0A> > > > > > = > >> But the unstated assumption that RPL made is that all=0A> > > > > > = host-to-router > >> protocols have to now be RPL aware. That=0A> > > > > = > doesn't sound like good > > design.=0A> > > > > > > >> A host isn't a= ware of whether the routers speak IS-IS or=0A> > > > > > OSPF, so why > >= > do the hosts need to be aware of RPL by passing=0A> > > > > > some TID a= round?=0A> > > > > > > >>=0A> > > > > > > >>> I think ND has the same n= eed as MIP for a TID =3D=3D Sequence # =0A>.=0A> > > > > > We > >>> know = of MIP; We know of RPL. We know of the backbone=0A> > > > > > router=0A> >= > > > > > >>> operation. We know we'll need the TID and we know exactly= =0A> > > > > > > >>> why. I think we should have it in the 6LowPAN ND spec= right=0A> > > > > > > >>> away to=0A> > > > > > avoid > >>> interop iss= ues when we add RPL and BR operations.=0A> > > > > > > >>=0A> > > > > > = > >> I don't see a need in 6lowpan-nd for a TID; the protocol=0A> > > > > = > works fine > > without it.=0A> > > > > > > >> I think RPL needs to be= improved to deal with reality. Isn't=0A> > > > > > there a > >> desire f= or RPL to handle 4861 hosts? Those would=0A> > > > > > never know about a = > > TID.=0A> > > > > > > >>=0A> > > > > > > >> Erik=0A> > > > > > > = >>=0A> > > > > > > >> _______________________________________________=0A>= > > > > > > >> 6lowpan mailing list=0A> > > > > > > >> 6lowpan@ietf.or= g=0A> > > > > > > >> https://www.ietf.org/mailman/listinfo/6lowpan=0A> > = > > > > > > _______________________________________________=0A> > > > > = > > > 6lowpan mailing list=0A> > > > > > > > 6lowpan@ietf.org=0A> > > >= > > > > https://www.ietf.org/mailman/listinfo/6lowpan=0A> > > > > > > = >=0A> > > > > > >=0A> > > > > > > _____________________________________= __________=0A> > > > > > > 6lowpan mailing list=0A> > > > > > > 6lowpan@= ietf.org=0A> > > > > > > https://www.ietf.org/mailman/listinfo/6lowpan=0A= > > > > > > >=0A> > > > > > > The information contained in this message= may be confidential=0A> > > > > > and legally > protected under applicab= le law. The message is=0A> > > > > > intended solely for the > addressee(= s). If you are not the=0A> > > > > > intended recipient, you are hereby n= otified > that any use,=0A> > > > > > forwarding, dissemination, or repro= duction of this message is >=0A> > > > > > strictly prohibited and may be= unlawful. If you are not the=0A> > > > > > intended recipient, > please = contact the sender by return e-mail=0A> > > > > > and destroy all copies o= f the > original message.=0A> > > > > >=0A> > > > > > __________________= _____________________________=0A> > > > > > 6lowpan mailing list=0A> > > >= > > 6lowpan@ietf.org=0A> > > > > > https://www.ietf.org/mailman/listinfo/6= lowpan=0A> > > > > >=0A> > > > > >=0A> > > > >=0A> > > __________________= ________________________________________=0A> > > > > ____________=0A> > > = > > > This email has been scanned by the MessageLabs Email Security=0A> > = > System.=0A> > > > > >=0A> > > > >=0A> > > _____________________________= _____________________________=0A> > > > > ____________=0A> > > > > >=0A> >= > >=0A> > > > _______________________________________________=0A> > > > 6= lowpan mailing list=0A> > > > 6lowpan@ietf.org=0A> > > > https://www.ietf.= org/mailman/listinfo/6lowpan=0A> > > =0A> > =0A> =0A> =0A> ________________= _______________________________=0A> 6lowpan mailing list=0A> 6lowpan@ietf.= org=0A> https://www.ietf.org/mailman/listinfo/6lowpan=0A> From PM@rtx.dk Wed Apr 27 01:14:55 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1BBE06DB for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 01:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 7drUik5aKeLG for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 01:14:53 -0700 (PDT) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id BB845E06AD for <6lowpan@ietf.org>; Wed, 27 Apr 2011 01:14:53 -0700 (PDT) Received: from mail19-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.8; Wed, 27 Apr 2011 08:14:52 +0000 Received: from mail19-tx2 (localhost.localdomain [127.0.0.1]) by mail19-tx2-R.bigfish.com (Postfix) with ESMTP id 8CE872B03B5 for <6lowpan@ietf.org>; Wed, 27 Apr 2011 08:14:52 +0000 (UTC) X-SpamScore: 3 X-BigFish: VPS3(zzzz1202h1082kzz8275bh8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB004.red002.local; RD:none; EFVD:NLI Received: from mail19-tx2 (localhost.localdomain [127.0.0.1]) by mail19-tx2 (MessageSwitch) id 1303892092213242_2895; Wed, 27 Apr 2011 08:14:52 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.244]) by mail19-tx2.bigfish.com (Postfix) with ESMTP id 274421B90052 for <6lowpan@ietf.org>; Wed, 27 Apr 2011 08:14:52 +0000 (UTC) Received: from IE2RD2HUB004.red002.local (213.199.187.153) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 27 Apr 2011 08:14:51 +0000 Received: from IE2RD2XVS021.red002.local ([10.33.56.25]) by IE2RD2HUB004.red002.local ([10.33.16.64]) with mapi; Wed, 27 Apr 2011 01:14:38 -0700 From: Peter Mariager To: "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Wed, 27 Apr 2011 01:14:35 -0700 Thread-Topic: IPv6 over DECT Ultra Low Energy Thread-Index: AcwEsyTKmfK/u92ZRkaXxTCtk2A8lg== Message-ID: Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: da-DK, en-US Content-Type: multipart/alternative; boundary="_000_C24CA99A3076664CA3223A9A86881DC06077776093IE2RD2XVS021r_" MIME-Version: 1.0 X-OriginatorOrg: rtx.dk Subject: [6lowpan] IPv6 over DECT Ultra Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 08:14:55 -0000 --_000_C24CA99A3076664CA3223A9A86881DC06077776093IE2RD2XVS021r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 R2VudGxlbWVuLA0KDQpJIGFtIHZlcnkgcGxlYXNlZCB0byBzZWUgNkxvV1BBTiBiZWluZyBjb25z aWRlcmVkIGFuZCBkZXZlbG9wZWQgZm9yIG90aGVyIHdpcmVsZXNzIHN0YW5kYXJkcy4NCg0KSSB3 b3VsZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGRldmVsb3BtZW50IG9mIGEgNkxvV1BBTiBhZGFwdGF0 aW9uIGxheWVyIGZvciBERUNUIFVsdHJhIExvdyBFbmVyZ3kgKFVMRSksIGFzIERFQ1QgY2FuIGFs c28gYmUgYSB2ZXJ5IHN0cm9uZyBwbGF0Zm9ybSBmb3IgdGhlICJpbnRlcm5ldCBvZiB0aGluZ3Mi IGR1ZSB0byB0aGUgbnVtYmVyIG9mIG5ldHdvcmtzIGJlaW5nIGRlcGxveWVkIGFubnVhbGx5Lg0K DQpERUNUIFVMRSBpcyBpbiBtYW55IHdheXMgc2ltaWxhciB0byBCVExFIChzaG9ydCBwYWNrZXQg c2l6ZSwgbmV0d29yayB0b3BvbG9neSBldGMpLCBidXQgYWxzbyBoYXMgc29tZSB1bmlxdWUgcHJv cGVydGllcyBjb21wYXJlZCB0byBvdGhlciB3aXJlbGVzcyBzaG9ydC1yYW5nZSBzdGFuZGFyZHMg d2hpY2ggSSBiZWxpZXZlIG1ha2VzIGl0IHdvcnRod2hpbGUgdG8gZGV2ZWxvcCBhIDZMb1dQQU4g YWRhcHRhdGlvbiBsYXllci4NCg0KREVDVCBVTEUgTUFDL1BIWSBpcyBjdXJyZW50bHkgYmVpbmcg c3BlY2lmaWVkIGJ5IEVUU0kgc28gdGhlcmUgd2lsbCBzaG9ydGx5IGJlIGFuIGludGVyb3BlcmFi bGUgcmFkaW8gaW50ZXJmYWNlLg0KDQpZZXN0ZXJkYXksIEkgc3VibWl0dGVkIGFuIEktRCB2ZXJz aW9uIDAgZm9yIElQdjYgdHJhbnNtaXNzaW9uIG92ZXIgREVDVCBVTEUuDQpUaGlzIGlzIHN0aWxs IHZlcnkgbXVjaCB3b3JrIGluIHByb2dyZXNzIGJ1dCBJIHdvdWxkIGxpa2UgdG8gaGF2ZSBhIGZy YW1lIGZvciB0aGUgc3BlY2lmaWNhdGlvbiB3b3JrIG9yIGF0IGxlYXN0IG1ha2Ugc3VyZSBpdCBp cyBhbGlnbmVkIHdpdGggYW55IGluaXRpYXRpdmVzIHRvIG1ha2UgYSBjb21tb24gNkxvV1BBTiBh ZGFwdGF0aW9uIGxheWVyIChhcyBkaXNjdXNzZWQgaW4gdGhpcyBXRykuDQoNCkNvbW1lbnRzIGFy ZSBtdWNoIGFwcHJlY2lhdGVkLg0KQmVzdCBSZWdhcmRzLA0KUGV0ZXIgTWFyaWFnZXINCg0K --_000_C24CA99A3076664CA3223A9A86881DC06077776093IE2RD2XVS021r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPjxtZXRhIG5hbWU9R2VuZXJh dG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+ PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpD YWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjMuMGNtIDIuMGNtIDMuMGNtIDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPURBIGxpbms9Ymx1ZSB2bGluaz1wdXJw bGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPkdlbnRsZW1lbiw8 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SSBhbSB2ZXJ5IHBsZWFzZWQgdG8gc2Vl IDZMb1dQQU4gYmVpbmcgY29uc2lkZXJlZCBhbmQgZGV2ZWxvcGVkIGZvciBvdGhlciB3aXJlbGVz cyBzdGFuZGFyZHMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz5JIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGUgZGV2ZWxvcG1l bnQgb2YgYSA2TG9XUEFOIGFkYXB0YXRpb24gbGF5ZXIgZm9yIERFQ1QgVWx0cmEgTG93IEVuZXJn eSAoVUxFKSwgYXMgREVDVCBjYW4gYWxzbyBiZSBhIHZlcnkgc3Ryb25nIHBsYXRmb3JtIGZvciB0 aGUgJiM4MjIwO2ludGVybmV0IG9mIHRoaW5ncyYjODIyMTsgZHVlIHRvIHRoZSBudW1iZXIgb2Yg bmV0d29ya3MgYmVpbmcgZGVwbG95ZWQgYW5udWFsbHkuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5ERUNUIFVMRSBpcyBpbiBt YW55IHdheXMgc2ltaWxhciB0byBCVExFIChzaG9ydCBwYWNrZXQgc2l6ZSwgbmV0d29yayB0b3Bv bG9neSBldGMpLCBidXQgYWxzbyBoYXMgc29tZSB1bmlxdWUgcHJvcGVydGllcyBjb21wYXJlZCB0 byBvdGhlciB3aXJlbGVzcyBzaG9ydC1yYW5nZSBzdGFuZGFyZHMgd2hpY2ggSSBiZWxpZXZlIG1h a2VzIGl0IHdvcnRod2hpbGUgdG8gZGV2ZWxvcCBhIDZMb1dQQU4gYWRhcHRhdGlvbiBsYXllci48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTPkRFQ1QgVUxFIE1BQy9QSFkgaXMgY3VycmVudGx5IGJlaW5nIHNwZWNpZmllZCBieSBF VFNJIHNvIHRoZXJlIHdpbGwgc2hvcnRseSBiZSBhbiBpbnRlcm9wZXJhYmxlIHJhZGlvIGludGVy ZmFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPlllc3RlcmRheSwgSSBzdWJtaXR0ZWQgYW4gSS1EIHZlcnNpb24gMCBmb3Ig SVB2NiB0cmFuc21pc3Npb24gb3ZlciBERUNUIFVMRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+VGhpcyBpcyBzdGlsbCB2ZXJ5IG11Y2gg d29yayBpbiBwcm9ncmVzcyBidXQgSSB3b3VsZCBsaWtlIHRvIGhhdmUgYSBmcmFtZSBmb3IgdGhl IHNwZWNpZmljYXRpb24gd29yayBvciBhdCBsZWFzdCBtYWtlIHN1cmUgaXQgaXMgYWxpZ25lZCB3 aXRoIGFueSBpbml0aWF0aXZlcyB0byBtYWtlIGEgY29tbW9uIDZMb1dQQU4gYWRhcHRhdGlvbiBs YXllciAoYXMgZGlzY3Vzc2VkIGluIHRoaXMgV0cpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Q29tbWVudHMgYXJlIG11Y2gg YXBwcmVjaWF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiInPkJlc3QgUmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz4gPGJy Pjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5QZXRlciBNYXJpYWdlcjxicj48YnI+PC9zcGFuPjxz cGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_C24CA99A3076664CA3223A9A86881DC06077776093IE2RD2XVS021r_-- From behcetsarikaya@yahoo.com Wed Apr 27 08:27:17 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EFCE0801 for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 08:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599] 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 kdN7HdrtEmNl for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 08:27:16 -0700 (PDT) Received: from nm15-vm1.bullet.mail.sp2.yahoo.com (nm15-vm1.bullet.mail.sp2.yahoo.com [98.139.91.209]) by ietfa.amsl.com (Postfix) with SMTP id D61EBE07FF for <6lowpan@ietf.org>; Wed, 27 Apr 2011 08:27:15 -0700 (PDT) Received: from [98.139.91.70] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 27 Apr 2011 15:27:12 -0000 Received: from [98.139.91.32] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 27 Apr 2011 15:27:12 -0000 Received: from [127.0.0.1] by omp1032.mail.sp2.yahoo.com with NNFMP; 27 Apr 2011 15:27:12 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 653447.21404.bm@omp1032.mail.sp2.yahoo.com Received: (qmail 97088 invoked by uid 60001); 27 Apr 2011 15:27:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1303918032; bh=8UzaMiKLcvwGYbaSOGCEj95+YnF1BaktU8edsBmnt3A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ROYAQ4z1Rs6IO2FCcVG9uuff9IGHM0BW/jQezXMG7ZQcsTFP6Aa9Vu4f0fzij7MMLPTEo2XqUwPLiLolb7mFAvRDtmDxp39pyB3Ow7Kau4otuvtku+Lf9LGcPmzwhvQeI7O2uY3ue4P26WGwMC3BhBsrdAvBV/VBq0pXX/92U58= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=6Epjvrmm3TZ6Fi2U8ZJyjoPzzx8ArMitMY3GanRaNx+qOTh+sJbPi5pW3g/8T0jYA8ijMEVRbv7tcnaJ8BvSQjCghNwF7izKEECTYZW08s7Pa+v7Y9lGySrPkIX7VAaRlRdFluyL7oLRlOJZB95Jd5PJkapLSejTs2Gj7OLVOUA=; Message-ID: <35734.97070.qm@web111408.mail.gq1.yahoo.com> X-YMail-OSG: kvy9omkVM1mrNYAr8F5KzdF67I_CR5GQhYZMLVc3SNQkHri vm2tcRW0orZdNTeg7TPkSvgcQFvVvwbmYIMx85h8Ja0CCUpoDQ_gZW4X8ZXn B1kgJZgb2CXy1VvrO18eXz1VafH9EAHWYPOI6k.PI0RYJvLiLKHpKALsJG.Z .x0AZ0EQqZe6jwXF.zHexy2nF.llxfRM4llsldc22hnA6e8SgJt9eN2Ys4Em OREhG54HJ1S_0vZytMfpxSPSkIwe53HKY6.OUy3NURXEWrkzymK1rmAjg9as bQl0ZF3kjzH6vngBwo0X.CfnGIvqlUeratkAlzu6fCQwaPR.eY5Mf3rSeCV. P9OEu0EmkQ46SG9gZoPIuR36hXpuoMW1zalaDpkLedCx63g2xpcDKqMMZXLv lrbWGZ2pt4ddD4w-- Received: from [206.16.17.212] by web111408.mail.gq1.yahoo.com via HTTP; Wed, 27 Apr 2011 08:27:11 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 Date: Wed, 27 Apr 2011 08:27:11 -0700 (PDT) From: Behcet Sarikaya To: Greg Zaverucha , "6lowpan@ietf.org" <6lowpan@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [6lowpan] Comments on draft-sarikaya-6lowpan-cgand-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:27:17 -0000 Hi Greg, Thanks for your careful reading. My replies below. > Comments on draft-sarikaya-6lowpan-cgand-00 > "Lightweight Secure Neighbor Discovery for Low-power and Lossy Networks" > > I think the draft is a good idea, providing an important security feature > to neighbor discovery. The draft proposes a protocol called LSEND: Lightweight > Secure Neighbor Discovery. Thanks for the comments. > > Here are some comments on the draft. > > The introduction could do a better job of describing how LSEND relates to >other > drafts. LSEND is very close to SEND (RFC 3971) but uses ECDSA instead of RSA. > SEND was designed to secure ND (RFC 2641) but RFC 2641 was obsoleted by RFC > 4861. Do the changes from 2641 to 4861 break SEND? Can the SEND protocol be > used with the 6lowpan version of neighbor discovery, described in > draft-ietf-6lowpan-nd-15? (It appears so, LSEND + draft-ietf-6lowpan-nd-15 is > described in Section 5.) This should be RFC 2461 not 2641. Section 11.2 in 4861 says that SEND is one possible protocol to use for 4861 or ND. As we explained in Section 3, SEND as is can not be used so we need LSEND. > > In Section 1, an additional motivation is that key generation (required for >CGA > on low power hosts) is computationally much cheaper with ECDSA than RSA. OK > > The references for ECDSA (there are two: SEC 1 and FIPS 186-3) should both > appear in one place, I'd suggest under "Digital Signature" in Section 4.1, >page > 5. The reference to SEC 1 should also be updated to version 2.0 (May 2009). > Since SEC 1 is specifying ECDSA for use with LSEND, I think it should be a > normative reference. OK > A reference to the SECG standard "SEC 2: Recommended Elliptic Curve Domain > Parameters version 2.0" could also be added as an informative reference since > it contains relevant information about the EC domain parameters used by LSEND > (the named curved secp256r1). > OK > In Section 4.2, the Key Hash is computed with SHA-2 instead of SHA-1 because >of > the weakness of SHA-1. From what I can tell, the Key Hash field is not > authenticated (signed), since the Digital Signature Option signs the preceding > options (c.f., Section 5.2 of SEND, RFC 3971), and some other information, but > not the Key Hash. From RFC 3971, the purpose of the Key Hash is "to associate > the signature to a particular key known by the receiver". Since the Key Hash >is > being used only to help the receiver use the right key, and could be modified > in transit, I don't think it needs to be computed with a cryptographic hash > function at all, even just truncating the public key to 128 bits would be OK. > That said, I don't see a problem with using SHA-2 here, since it must be > implemented for ECDSA anyway. I just think the text is misleading by saying >the > Key Hash is computed with SHA-2 for security reasons. Following the same > reasoning, LSEND could reduce the size of Key Hash to 64 or 48 bits to save > bandwidth, if desired. Yes, as it has recently been debated on the CoAP list, SHA-2 is the way to go. As for Key Hash, in our draft, it is used as in 3971 except SHA-2. Reducing its size can be considered. > In Section 4.2 the sequence of octets to be signed is given by Section 5.2 of > RFC 3971 (SEND). The first input is a "CGA Message Type Tag for SEND", a > 128-bit constant. Should LSEND define its own CGA Message Type Tag? > Good point! We had assumed the same value as SEND. Why not a new value? Just now I generated one 0xE8C47FB7FD2BB885DAB2D31A0F2808B4 > Figure 1, caption: LLA is undefined in this document. Good catch. It should be LLN. > > Section 5.1. For the given domain parameters, an 88-octet ECC public key is >not > using point compression, as defined in RFC 5480, Section 2.2. By using point > compression the size of the public key is reduced by 32 octets, to 56. Section > 4.3 should specify that point compression be used when describing how the > public key is to be encoded. Agreed. > > General comment: The fast verification feature of ECDSA would be applicable >for > this draft. The ECDSA signing algorithm is not changed, but verification is > implemented with an equivalent computation that is more efficient. The > verification efficiency is even greater if the signer includes one bit of > ``side information'' as a convenience to the verifier. In LSEND this extra >bit > could come from the reserved bits in the Signature option header, or the Key > Hash could be reduced from 128 bits to 127 bits. If a particular signer or > verifier does not implement the fast verify techniques, they may still > interoperate with those that do. The fast verify convention will allow border > routers to process a larger number of signatures. > Page 12 of this paper describes the verification technique: > http://www.cacr.math.uwaterloo.ca/techreports/2005/cacr2005-28.pdf > This draft is also on the subject of fast verification: > http://tools.ietf.org/html/draft-struik-ecc-efficiencies-00 OK, I understand. Of course this feature (accelerated verification) could be incorporated if there is enough interest. Regards, Behcet From alexandru.petrescu@gmail.com Wed Apr 27 09:10:37 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0857FE07ED for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 09:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 VIe2mIW329cg for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 09:10:32 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 09AA4E06A3 for <6lowpan@ietf.org>; Wed, 27 Apr 2011 09:10:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p3RGAU4h018214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Wed, 27 Apr 2011 18:10:30 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p3RGATM9001785 for <6lowpan@ietf.org>; Wed, 27 Apr 2011 18:10:30 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010173.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p3RGAT8T014172 for <6lowpan@ietf.org>; Wed, 27 Apr 2011 18:10:29 +0200 Message-ID: <4DB83FF5.9000207@gmail.com> Date: Wed, 27 Apr 2011 18:10:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: 6lowpan@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [6lowpan] IPv6 over DECT Ultra Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 16:10:37 -0000 Do we have an idea whether IP (not IPv6, just IP) already works somehow over DECT? For example, ss there a product DECT telephone using TCP/IP, and display some data on LCD? Alex Le 27/04/2011 10:14, Peter Mariager a écrit : > Gentlemen, > > I am very pleased to see 6LoWPAN being considered and developed for > other wireless standards. > > I would like to propose the development of a 6LoWPAN adaptation layer > for DECT Ultra Low Energy (ULE), as DECT can also be a very strong > platform for the “internet of things” due to the number of networks > being deployed annually. > > DECT ULE is in many ways similar to BTLE (short packet size, network > topology etc), but also has some unique properties compared to other > wireless short-range standards which I believe makes it worthwhile > to develop a 6LoWPAN adaptation layer. > > DECT ULE MAC/PHY is currently being specified by ETSI so there will > shortly be an interoperable radio interface. > > Yesterday, I submitted an I-D version 0 for IPv6 transmission over > DECT ULE. > > This is still very much work in progress but I would like to have a > frame for the specification work or at least make sure it is aligned > with any initiatives to make a common 6LoWPAN adaptation layer (as > discussed in this WG). > > Comments are much appreciated. > > Best Regards, Peter Mariager > > > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From PM@rtx.dk Wed Apr 27 23:59:59 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E13AE06BD for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 23:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[AWL=-0.311, 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 ED5JPHqyNP38 for <6lowpan@ietfa.amsl.com>; Wed, 27 Apr 2011 23:59:58 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id BCA25E06B6 for <6lowpan@ietf.org>; Wed, 27 Apr 2011 23:59:58 -0700 (PDT) Received: from mail196-ch1-R.bigfish.com (216.32.181.174) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.8; Thu, 28 Apr 2011 06:59:57 +0000 Received: from mail196-ch1 (localhost.localdomain [127.0.0.1]) by mail196-ch1-R.bigfish.com (Postfix) with ESMTP id 641B010E8260; Thu, 28 Apr 2011 06:59:57 +0000 (UTC) X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dK542M1432Nzz1202h1082kzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB010.red002.local; RD:none; EFVD:NLI Received: from mail196-ch1 (localhost.localdomain [127.0.0.1]) by mail196-ch1 (MessageSwitch) id 1303973997182421_31417; Thu, 28 Apr 2011 06:59:57 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail196-ch1.bigfish.com (Postfix) with ESMTP id 212AFFA804E; Thu, 28 Apr 2011 06:59:57 +0000 (UTC) Received: from IE2RD2HUB010.red002.local (213.199.187.153) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 28 Apr 2011 06:59:55 +0000 Received: from IE2RD2XVS021.red002.local ([10.33.56.25]) by IE2RD2HUB010.red002.local ([10.33.16.249]) with mapi; Wed, 27 Apr 2011 23:59:51 -0700 From: Peter Mariager To: Alexandru Petrescu , "6lowpan@ietf.org" <6lowpan@ietf.org> Date: Wed, 27 Apr 2011 23:59:49 -0700 Thread-Topic: [6lowpan] IPv6 over DECT Ultra Low Energy Thread-Index: AcwE9bPxbs2zRqW5RlSRL/LMkQk7QgAeS+tQ Message-ID: References: <4DB83FF5.9000207@gmail.com> In-Reply-To: <4DB83FF5.9000207@gmail.com> Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: da-DK, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rtx.dk Cc: Jens Toftgaard Petersen Subject: Re: [6lowpan] IPv6 over DECT Ultra Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 06:59:59 -0000 Hi Alex Let me try to answer... There is a well defined reliable data transport (DPRS) specification for pa= cket traffic. This could potentially be used to transport e.g. 802.3 or IP = frames to a "Portable Part" (PP - the "handset" / end node in DECT terms). Besides, in the newest DECT CAT-iq specification v3.0 (TS 102 527-4) it has= also been specified how to terminate the full TCP/IP stack in the gateway = (DECT Fixed Part - the base station) and relay a subset of HTTP over to the= portable part (intended for e.g. software upgrade over the air). The problem here is that the DECT base station then has to be (mildly) appl= ication aware. The above mechanism are also only defined for "classic" DECT and without an= y power limitations in mind. I would like to enable true IP stack termination in the Portable Part and s= pecifically tailored to fit the low resource channel of DECT ULE. When such an adaptation layer has been defined it could easily be applied t= o "classic" DECT / CAT-iq as well. Best Regards,=20 Peter Mariager -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Alexandru Petrescu Sent: 27. april 2011 18:10 To: 6lowpan@ietf.org Subject: Re: [6lowpan] IPv6 over DECT Ultra Low Energy Do we have an idea whether IP (not IPv6, just IP) already works somehow over DECT? For example, ss there a product DECT telephone using TCP/IP, and display some data on LCD? Alex Le 27/04/2011 10:14, Peter Mariager a =E9crit : > Gentlemen, > > I am very pleased to see 6LoWPAN being considered and developed for > other wireless standards. > > I would like to propose the development of a 6LoWPAN adaptation layer > for DECT Ultra Low Energy (ULE), as DECT can also be a very strong > platform for the "internet of things" due to the number of networks > being deployed annually. > > DECT ULE is in many ways similar to BTLE (short packet size, network > topology etc), but also has some unique properties compared to other > wireless short-range standards which I believe makes it worthwhile > to develop a 6LoWPAN adaptation layer. > > DECT ULE MAC/PHY is currently being specified by ETSI so there will > shortly be an interoperable radio interface. > > Yesterday, I submitted an I-D version 0 for IPv6 transmission over > DECT ULE. > > This is still very much work in progress but I would like to have a > frame for the specification work or at least make sure it is aligned > with any initiatives to make a common 6LoWPAN adaptation layer (as > discussed in this WG). > > Comments are much appreciated. > > Best Regards, Peter Mariager > > > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From behcetsarikaya@yahoo.com Thu Apr 28 09:00:29 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C48E06E6 for <6lowpan@ietfa.amsl.com>; Thu, 28 Apr 2011 09:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599] 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 jWtbcLkwW64E for <6lowpan@ietfa.amsl.com>; Thu, 28 Apr 2011 09:00:25 -0700 (PDT) Received: from nm23.bullet.mail.sp2.yahoo.com (nm23.bullet.mail.sp2.yahoo.com [98.139.91.93]) by ietfa.amsl.com (Postfix) with SMTP id 385EFE0685 for <6lowpan@ietf.org>; Thu, 28 Apr 2011 09:00:22 -0700 (PDT) Received: from [98.139.91.66] by nm23.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 16:00:22 -0000 Received: from [98.139.91.34] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 16:00:22 -0000 Received: from [127.0.0.1] by omp1034.mail.sp2.yahoo.com with NNFMP; 28 Apr 2011 16:00:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 99302.36085.bm@omp1034.mail.sp2.yahoo.com Received: (qmail 87088 invoked by uid 60001); 28 Apr 2011 16:00:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1304006421; bh=OL89Arl3Z/uzilfWNby9YJq+7pwBHH2v3WcYRmIOoOw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jtn6Q4k7PCsUmbpXcSJN9aDbuIja3WsKIh9wrqYdcD1YmG9N29X0pnwcCVTRfrMCa0nPRhoZNJ9wtXeE2d2ZmqofKayynhonxBamyOTj52zWH2XX7qjpmJMrRU7z06xGIvU7NQAv9L96lXcp57IGbiRUQ3Z8W+QcTg7nH8eTe/U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HKORP0FMqX36jpFRzmtaTdzamSkxlvBSqMjymiVkcvurlc8mn12dbJrLAyzCqrYb/2iaFYa9WAvKEkvN7ONVlnXbQcmcxMa7KaG+d3toBtegn6ZbLPqXk59/Meq0Icf5GAtoq5xOAWeC6sAENaU4gVyziT8YQGF0UTIoiZJceek=; Message-ID: <528499.54470.qm@web111407.mail.gq1.yahoo.com> X-YMail-OSG: H35aI14VM1kc4ns3cpmpD1NFofsXWgacZxUeBQKDwhbLDSo gSyO4D7snsBl.PODTU.i61W1JQaMUxUDYWq9tHIkSYQsgVpiJSbtSnNi7k.c T9DBPuW2ZuwmRT9aWq1oaXipbAvaPcqofFAWrg3EtVTv2cGLl0kx8xHT58ns i_grJp.GvDrtD2.EPaZ3q99lqjizIok4ySWbxDsTNqttR1jFdUX732xTVBt2 aiOEdXN.96BUa7PjtbnIQzvgCZEQJb_TtYa0fLTFAnECuAxM9sEdM4KRy_hp UcOIpmMkM.GrDjBYazHuEfALPOTgl.X3rnj_YJNUKgja37hBrj7358YhFMef 5XUFgNCV9Sh0wnyaTIndW4VpKhOkTpxMkvAV01o620Hxo7O75kK5HijO4MWq Gf6xtHi7V6KO73A-- Received: from [206.16.17.212] by web111407.mail.gq1.yahoo.com via HTTP; Thu, 28 Apr 2011 09:00:21 PDT X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.110.299900 References: <4DB83FF5.9000207@gmail.com> Date: Thu, 28 Apr 2011 09:00:21 -0700 (PDT) From: Behcet Sarikaya To: Peter Mariager , Alexandru Petrescu , "6lowpan@ietf.org" <6lowpan@ietf.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jens Toftgaard Petersen Subject: Re: [6lowpan] IPv6 over DECT Ultra Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:00:29 -0000 =0A=0AHi all,=0A 6lowpan on links other than IEEE 802.15.4 is different an= d can not be =0Aconsidered as left-over work in 6lowpan WG, IMHO. =0A=0A A= s such, it would probably be better to look for other ways such as a BoF. = =0A6lowpan over Bluetooth seems to fall into this category as well :-).=0A= =0AMy 2 cents.=0A=0ABehcet=0A=0A> Hi Alex=0A> =0A> Let me try to answer...= =0A> =0A> There is a well defined reliable data transport (DPRS) specifica= tion for =0A>packet traffic. This could potentially be used to transport e= .g. 802.3 or IP =0A>frames to a "Portable Part" (PP - the "handset" / end = node in DECT terms).=0A> =0A> Besides, in the newest DECT CAT-iq specifica= tion v3.0 (TS 102 527-4) it has =0A>also been specified how to terminate t= he full TCP/IP stack in the gateway (DECT =0A>Fixed Part - the base station= ) and relay a subset of HTTP over to the portable =0A>part (intended for e= .g. software upgrade over the air).=0A> The problem here is that the DECT = base station then has to be (mildly) =0A>application aware.=0A> =0A> The a= bove mechanism are also only defined for "classic" DECT and without any = =0A>power limitations in mind.=0A> =0A> I would like to enable true IP sta= ck termination in the Portable Part and =0A>specifically tailored to fit t= he low resource channel of DECT ULE.=0A> =0A> When such an adaptation laye= r has been defined it could easily be applied to =0A>"classic" DECT / CAT-= iq as well.=0A> =0A> Best Regards, =0A> Peter Mariager=0A> =0A> =0A> -----= Original Message-----=0A> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bo= unces@ietf.org] On Behalf Of =0A>Alexandru Petrescu=0A> Sent: 27. april 20= 11 18:10=0A> To: 6lowpan@ietf.org=0A> Subject: Re: [6lowpan] IPv6 over DEC= T Ultra Low Energy=0A> =0A> Do we have an idea whether IP (not IPv6, just = IP) already works somehow=0A> over DECT?=0A> =0A> For example, ss there a = product DECT telephone using TCP/IP, and display=0A> some data on LCD?=0A>= =0A> Alex=0A> =0A> Le 27/04/2011 10:14, Peter Mariager a =E9crit :=0A> > = Gentlemen,=0A> >=0A> > I am very pleased to see 6LoWPAN being considered an= d developed for=0A> > other wireless standards.=0A> >=0A> > I would like t= o propose the development of a 6LoWPAN adaptation layer=0A> > for DECT U= ltra Low Energy (ULE), as DECT can also be a very strong=0A> > platform for= the "internet of things" due to the number of networks=0A> > being deploy= ed annually.=0A> >=0A> > DECT ULE is in many ways similar to BTLE (short p= acket size, network=0A> > topology etc), but also has some unique propert= ies compared to other=0A> > wireless short-range standards which I believ= e makes it worthwhile=0A> > to develop a 6LoWPAN adaptation layer.=0A> >= =0A> > DECT ULE MAC/PHY is currently being specified by ETSI so there will= =0A> > shortly be an interoperable radio interface.=0A> >=0A> > Yesterday,= I submitted an I-D version 0 for IPv6 transmission over=0A> > DECT ULE.= =0A> >=0A> > This is still very much work in progress but I would like to = have a=0A> > frame for the specification work or at least make sure it is = aligned=0A> > with any initiatives to make a common 6LoWPAN adaptation la= yer (as=0A> > discussed in this WG).=0A> >=0A> > Comments are much appreci= ated.=0A> >=0A> > Best Regards, Peter Mariager=0A> >=0A> >=0A> >=0A> > __= _____________________________________________ 6lowpan mailing list=0A> > 6l= owpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan=0A> =0A> _____= __________________________________________=0A> 6lowpan mailing list=0A> 6l= owpan@ietf.org=0A> https://www.ietf.org/mailman/listinfo/6lowpan=0A> =0A> = =0A> _______________________________________________=0A> 6lowpan mailing l= ist=0A> 6lowpan@ietf.org=0A> https://www.ietf.org/mailman/listinfo/6lowpan= =0A> From Basavaraj.Patil@nokia.com Thu Apr 28 09:17:01 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B178E0670 for <6lowpan@ietfa.amsl.com>; Thu, 28 Apr 2011 09:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 d1Jcck4pz763 for <6lowpan@ietfa.amsl.com>; Thu, 28 Apr 2011 09:17:00 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 416CBE0669 for <6lowpan@ietf.org>; Thu, 28 Apr 2011 09:17:00 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p3SGGDNb027994; Thu, 28 Apr 2011 19:16:55 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 19:16:45 +0300 Received: from 008-AM1MMR1-003.mgdnok.nokia.com (65.54.30.58) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 28 Apr 2011 18:16:44 +0200 Received: from 008-AM1MPN1-024.mgdnok.nokia.com ([169.254.4.125]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0289.008; Thu, 28 Apr 2011 18:16:44 +0200 From: To: , , , <6lowpan@ietf.org> Thread-Topic: [6lowpan] IPv6 over DECT Ultra Low Energy Thread-Index: AcwEsyTKmfK/u92ZRkaXxTCtk2A8lgAMbf+AAB8PQoAAEuC/gP//sL8A Date: Thu, 28 Apr 2011 16:16:43 +0000 Message-ID: In-Reply-To: <528499.54470.qm@web111407.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [172.19.59.21] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1C750286DDB0904F97068A11EEF57177@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Apr 2011 16:16:45.0121 (UTC) FILETIME=[AAE94B10:01CC05BF] X-Nokia-AV: Clean Cc: JTP@rtx.dk Subject: Re: [6lowpan] IPv6 over DECT Ultra Low Energy X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:17:01 -0000 Behcet, On 4/28/11 11:00 AM, "ext Behcet Sarikaya" wrote: > > >Hi all, > 6lowpan on links other than IEEE 802.15.4 is different and can not be >considered as left-over work in 6lowpan WG, IMHO. Why? Do you have good reasoning why BT-LE for example should not be work undertaken by the 6lowpan WG? 6lowpan is not air-interface specific,. Your comments are anyway redundant since the WG decided at IETF80 to take on the work of specifying IPv6 over BT-LE. -Raj >=20 > > As such, it would probably be better to look for other ways such as a >BoF.=20 >6lowpan over Bluetooth seems to fall into this category as well :-). > >My 2 cents. > >Behcet > >> Hi Alex >>=20 >> Let me try to answer... >>=20 >> There is a well defined reliable data transport (DPRS) specification >>for=20 >>packet traffic. This could potentially be used to transport e.g. 802.3 >>or IP=20 >>frames to a "Portable Part" (PP - the "handset" / end node in DECT >>terms). >>=20 >> Besides, in the newest DECT CAT-iq specification v3.0 (TS 102 527-4) >>it has=20 >>also been specified how to terminate the full TCP/IP stack in the >>gateway (DECT=20 >>Fixed Part - the base station) and relay a subset of HTTP over to the >>portable=20 >>part (intended for e.g. software upgrade over the air). >> The problem here is that the DECT base station then has to be (mildly) >>application aware. >>=20 >> The above mechanism are also only defined for "classic" DECT and >>without any=20 >>power limitations in mind. >>=20 >> I would like to enable true IP stack termination in the Portable Part >>and =20 >>specifically tailored to fit the low resource channel of DECT ULE. >>=20 >> When such an adaptation layer has been defined it could easily be >>applied to =20 >>"classic" DECT / CAT-iq as well. >>=20 >> Best Regards,=20 >> Peter Mariager >>=20 >>=20 >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>Behalf Of=20 >>Alexandru Petrescu >> Sent: 27. april 2011 18:10 >> To: 6lowpan@ietf.org >> Subject: Re: [6lowpan] IPv6 over DECT Ultra Low Energy >>=20 >> Do we have an idea whether IP (not IPv6, just IP) already works somehow >> over DECT? >>=20 >> For example, ss there a product DECT telephone using TCP/IP, and >>display >> some data on LCD? >>=20 >> Alex >>=20 >> Le 27/04/2011 10:14, Peter Mariager a =E9crit : >> > Gentlemen, >> > >> > I am very pleased to see 6LoWPAN being considered and developed for >> > other wireless standards. >> > >> > I would like to propose the development of a 6LoWPAN adaptation layer >> > for DECT Ultra Low Energy (ULE), as DECT can also be a very strong >> > platform for the "internet of things" due to the number of networks >> > being deployed annually. >> > >> > DECT ULE is in many ways similar to BTLE (short packet size, network >> > topology etc), but also has some unique properties compared to other >> > wireless short-range standards which I believe makes it worthwhile >> > to develop a 6LoWPAN adaptation layer. >> > >> > DECT ULE MAC/PHY is currently being specified by ETSI so there will >> > shortly be an interoperable radio interface. >> > >> > Yesterday, I submitted an I-D version 0 for IPv6 transmission over >> > DECT ULE. >> > >> > This is still very much work in progress but I would like to have a >> > frame for the specification work or at least make sure it is aligned >> > with any initiatives to make a common 6LoWPAN adaptation layer (as >> > discussed in this WG). >> > >> > Comments are much appreciated. >> > >> > Best Regards, Peter Mariager >> > >> > >> > >> > _______________________________________________ 6lowpan mailing list >> > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >>=20 >>=20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >>=20 >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From johanna.1.nieminen@nokia.com Fri Apr 29 02:02:56 2011 Return-Path: X-Original-To: 6lowpan@ietfa.amsl.com Delivered-To: 6lowpan@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895DDE06A2 for <6lowpan@ietfa.amsl.com>; Fri, 29 Apr 2011 02:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=2.219] 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 Uv-enZpWa-D2 for <6lowpan@ietfa.amsl.com>; Fri, 29 Apr 2011 02:02:52 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 586A8E0678 for <6lowpan@ietf.org>; Fri, 29 Apr 2011 02:02:51 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p3T92lb4013079 for <6lowpan@ietf.org>; Fri, 29 Apr 2011 12:02:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Apr 2011 12:02:50 +0300 Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 29 Apr 2011 11:02:50 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.65]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0289.008; Fri, 29 Apr 2011 11:02:49 +0200 From: To: <6lowpan@ietf.org> Thread-Topic: draft-ietf-6lowpan-btle-00 Thread-Index: AcwGTDZAjxUdEDmEQF6L8OQKfjPC2A== Date: Fri, 29 Apr 2011 09:02:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.22.238] Content-Type: multipart/alternative; boundary="_000_B2E2664E0C627144B54BB081612A221D015A38D8008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Apr 2011 09:02:50.0205 (UTC) FILETIME=[374E20D0:01CC064C] X-Nokia-AV: Clean Subject: [6lowpan] draft-ietf-6lowpan-btle-00 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 09:02:56 -0000 --_000_B2E2664E0C627144B54BB081612A221D015A38D8008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just to inform that our I-D draft-ietf-6lowpan-btle-00 is available in the WG webpage: http:= //datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/ Comments welcome. Johanna --_000_B2E2664E0C627144B54BB081612A221D015A38D8008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Just to inform that our I-D draft-ietf-6lowpan-btle-00 is available in t= he WG webpage: http://datatracker.ietf.org/doc/draft-ietf= -6lowpan-btle/
 
Comments welcome.
 
Johann= a
 
 
 
 
 --_000_B2E2664E0C627144B54BB081612A221D015A38D8008AM1MPN1007mg_--