From 6lowpan-bounces@ietf.org Thu May 8 17:07:46 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0172D3A6BB5; Thu, 8 May 2008 17:07:46 -0700 (PDT) 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 9E7213A6BB5 for <6lowpan@core3.amsl.com>; Thu, 8 May 2008 17:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MIME_QP_LONG_LINE=1.396, MPART_ALT_DIFF=0.739, 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 YfsCDX36ughs for <6lowpan@core3.amsl.com>; Thu, 8 May 2008 17:07:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0405D3A684D for <6lowpan@ietf.org>; Thu, 8 May 2008 17:07:40 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 08 May 2008 17:07:38 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4907cwe023222 for <6lowpan@ietf.org>; Thu, 8 May 2008 17:07:38 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4907brG000374 for <6lowpan@ietf.org>; Fri, 9 May 2008 00:07:38 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 20:07:37 -0400 Received: from 10.86.104.178 ([10.86.104.178]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 May 2008 00:07:37 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Thu, 08 May 2008 20:07:36 -0400 From: JP Vasseur To: <6lowpan@ietf.org> Message-ID: Thread-Topic: Any news about the re-chartering process? Thanks. Thread-Index: AcixaK+MqE4z9Lky0U+y6Mq374oQrg== Mime-version: 1.0 X-OriginalArrivalTime: 09 May 2008 00:07:37.0735 (UTC) FILETIME=[B0955170:01C8B168] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=596; t=1210291658; x=1211155658; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Any=20news=20about=20the=20re-chartering=20proc ess?=20Thanks. |Sender:=20; bh=4VByBub6lynjGs0FBoZZ/DrU5Xe0e+mLy/r1dSxSp+I=; b=XbCJg00kGJT0sqXW190TNE5TAYGYG2yP17pCVv/fR15NLp/sVHZU3LgXHw bA4sdrU/tY5svlSjRn8OJBDJ9aoWV+vk6jGALr+8xCZX508SWHOpvpvOOIno qEab0P6RtimoeXcfqxhULZPtPihO51J28yQGVLt9z0nII55aeDjxA=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [6lowpan] Any news about the re-chartering process? Thanks. 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: , Content-Type: multipart/mixed; boundary="===============0821219015==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0821219015== Content-type: multipart/alternative; boundary="B_3293122057_32378131" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3293122057_32378131 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit --B_3293122057_32378131 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Any news about the re-chartering process? Thanks. --B_3293122057_32378131-- --===============0821219015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============0821219015==-- From 6lowpan-bounces@ietf.org Tue May 13 09:11:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B691C3A6C2C; Tue, 13 May 2008 09:11:47 -0700 (PDT) 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 9BB973A6893 for <6lowpan@core3.amsl.com>; Tue, 13 May 2008 09:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e6YphTjwnJV for <6lowpan@core3.amsl.com>; Tue, 13 May 2008 09:11:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F17BE3A6C1A for <6lowpan@ietf.org>; Tue, 13 May 2008 09:11:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204531200"; d="scan'208,217";a="46393255" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 May 2008 09:09:21 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4DG9LWD012102 for <6lowpan@ietf.org>; Tue, 13 May 2008 09:09:21 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4DG9Lhq004071 for <6lowpan@ietf.org>; Tue, 13 May 2008 16:09:21 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 12:09:20 -0400 Received: from 161.44.71.254 ([161.44.71.254]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 May 2008 16:09:20 +0000 User-Agent: Microsoft-Entourage/12.1.0.080305 Date: Tue, 13 May 2008 12:09:18 -0400 From: JP Vasseur To: <6lowpan@ietf.org> Message-ID: Thread-Topic: 2nd Try -- FW: [6lowpan] Any news about the re-chartering process? Thanks. Thread-Index: AcixaK+MqE4z9Lky0U+y6Mq374oQrgDqwK4g In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 13 May 2008 16:09:20.0596 (UTC) FILETIME=[B3D22940:01C8B513] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1616; t=1210694961; x=1211558961; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=202nd=20Try=20--=20FW=3A=20[6lowpan]=20Any=20news =20about=20the=20re-chartering=20process?=0A=20Thanks. |Sender:=20; bh=qN5CMc7/If2hNA+FaXNQpz8VOEkADHkJoIyU/7Wnf9o=; b=C6h5txE6aFGN1cU449GZg4ujF3InU1193wh+rlAfQ3fbuUdROl1704BTTo dUSFc4OSpnnTg+mzO2RAwIXZq+jVFKXsxbDeqW9bE5tD54etx2IAk6vOHZs0 z4NMCRhdBo; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [6lowpan] 2nd Try -- FW: Any news about the re-chartering process? Thanks. 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: , Content-Type: multipart/mixed; boundary="===============1184779857==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1184779857== Content-type: multipart/alternative; boundary="B_3293525359_45463836" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3293525359_45463836 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit ------ Forwarded Message From: JP Vasseur Date: Thu, 08 May 2008 20:07:36 -0400 To: <6lowpan@ietf.org> Subject: [6lowpan] Any news about the re-chartering process? Thanks. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ------ End of Forwarded Message --B_3293525359_45463836 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable 2nd Try -- FW: [6lowpan] Any news about the re-chartering process? T= hanks.
------ Forwarded Message
From: JP Vasseur <jvasseur@cisco.com>
Date: Thu, 08 May 2008 20:07:36 -0400
To: <6lowpan@ietf.org>
Subject: [6lowpan] Any news about the re-chartering process? Thanks.=


__________________________= _____________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

------ End of Forwarded Message
 --B_3293525359_45463836-- --===============1184779857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1184779857==-- From 6lowpan-bounces@ietf.org Tue May 13 16:47:46 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC2F3A68D8; Tue, 13 May 2008 16:47:46 -0700 (PDT) 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 253103A68D8 for <6lowpan@core3.amsl.com>; Tue, 13 May 2008 16:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWj0w+50Pv8p for <6lowpan@core3.amsl.com>; Tue, 13 May 2008 16:47:44 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 9DD113A68B5 for <6lowpan@ietf.org>; Tue, 13 May 2008 16:47:35 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so2215889and.122 for <6lowpan@ietf.org>; Tue, 13 May 2008 16:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=J8gF8A0MmoSDmCxPZ80Lv6bsvli+9dYkdqA5EOGBLUc=; b=sHu6Hh1pvi7kl1CwxsS4OOCu4OZ7GHWw6jdx1Dgu0FEKIOzQfoEcRxGKI2hNrPWdQaAzJy4etSk0+/2KzQiUSh5pSq4MHq1UZIa7Ye22f8ENvkIP4At4y5+hYPWPkQeRsoEDAX3w35aMJXRkOuSkZ/fLcEvUTXyMQNOkBTdz9BE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=N7XEAAk9GTxFj5WBYw18mtoUZXAA5MoQOT5osJCM9Y5nqN7+leVSNxucbrBkVRJlCABBac4ApcR91GWjBkBa1gFM8XAhSXd4zZMSAv2TU0KIduKiVvxvzP6F79xj/RsgbeYaZzC+GyFqjgxUadcsNw4E9YyUJzJ6g+4MpVWH/hY= Received: by 10.100.213.4 with SMTP id l4mr512012ang.53.1210720699176; Tue, 13 May 2008 16:18:19 -0700 (PDT) Received: by 10.100.41.10 with HTTP; Tue, 13 May 2008 16:18:19 -0700 (PDT) Message-ID: Date: Wed, 14 May 2008 08:18:19 +0900 From: "Daniel Park" To: "JP Vasseur" In-Reply-To: MIME-Version: 1.0 References: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] 2nd Try -- FW: Any news about the re-chartering process? Thanks. 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: , Content-Type: multipart/mixed; boundary="===============0799970621==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0799970621== Content-Type: multipart/alternative; boundary="----=_Part_15295_17142811.1210720699175" ------=_Part_15295_17142811.1210720699175 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I didn't see this item on the IESG recent telechat 2008, either next telechat...:-( Presumably, it is still pending status. Just my thought, Daniel Park [at] Samsung Electronics On 5/14/08, JP Vasseur wrote: > > > ------ Forwarded Message > *From: *JP Vasseur > *Date: *Thu, 08 May 2008 20:07:36 -0400 > *To: *<6lowpan@ietf.org> > *Subject: *[6lowpan] Any news about the re-chartering process? Thanks. > > > ------------------------------ > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ------ End of Forwarded Message > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > -- Soohong Daniel Park [at] Samsung Electronics Standard Architect, http://blog.naver.com/natpt ------=_Part_15295_17142811.1210720699175 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I didn't see this item on the IESG recent telechat 2008, either next telechat...:-(
 
Presumably, it is still pending status.
 
Just my thought,
 
 
Daniel Park [at] Samsung Electronics

 
On 5/14/08, JP Vasseur <jvasseur@cisco.com> wrote:

------ Forwarded Message
From: JP Vasseur <jvasseur@cisco.com>
Date: Thu, 08 May 2008 20:07:36 -0400
To: <6lowpan@ietf.org>
Subject: [6lowpan] Any news about the re-chartering process? Thanks.


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

------ End of Forwarded Message

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




--
Soohong Daniel Park [at] Samsung Electronics
Standard Architect, http://blog.naver.com/natpt ------=_Part_15295_17142811.1210720699175-- --===============0799970621== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============0799970621==-- From 6lowpan-bounces@ietf.org Thu May 15 14:02:34 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE0A3A68DD; Thu, 15 May 2008 14:02:34 -0700 (PDT) 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 AFA6B3A68D0 for <6lowpan@core3.amsl.com>; Thu, 15 May 2008 14:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=0.477, 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 Z-6QaYxtbBbv for <6lowpan@core3.amsl.com>; Thu, 15 May 2008 14:02:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7E5C63A6888 for <6lowpan@ietf.org>; Thu, 15 May 2008 14:02:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,493,1204531200"; d="txt'?scan'208";a="33976964" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 15 May 2008 14:02:26 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m4FL2PUp019555 for <6lowpan@ietf.org>; Thu, 15 May 2008 14:02:25 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4FL2Fdd012405 for <6lowpan@ietf.org>; Thu, 15 May 2008 21:02:25 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 17:02:22 -0400 Received: from rtp-townsley-vpn5.cisco.com ([10.83.1.102]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 May 2008 17:02:21 -0400 Message-ID: <482CA4DC.40508@cisco.com> Date: Thu, 15 May 2008 23:02:20 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: multipart/mixed; boundary="------------030805060907020403070808" X-OriginalArrivalTime: 15 May 2008 21:02:21.0464 (UTC) FILETIME=[F7A93980:01C8B6CE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11670; t=1210885345; x=1211749345; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20New=20charter=20for=206lowpan |Sender:=20; bh=3sAszjlqdhleDwHqWEmPbWl9ZHMtzEdkB3u/lboc6Vk=; b=Hb4Nv9ds1k0UP2lSQ4PEzIoADQFOvisKLgzHrY0Ria+KnMDGrrvPylXMBN wQfn+bFIMnoyM83+NvUwxShkezieTIug7I+/yfnDA4L8FAOD8bjXWbkblsGH IngRNTYPHa; Authentication-Results: sj-dkim-4; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [6lowpan] New charter for 6lowpan 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: , Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --------------030805060907020403070808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'd like to ask the group one final time for comments on the proposed new charter. I've also asked the ROLL WG chairs to comment. As I said before, soon after the format document was published, there is nothing stopping the WG from discussing and working on new and existing items at this time. In fact, activity helps us to decide what should be in and out of the charter. Please do not construe not having a charter in place as a reason not to update drafts, or discuss topics that need to be discussed. Just as when we have BoF's and mailing lists before creating a new WG, it is good to have WG meetings and on-lists discussions when creating new WG charters. - Mark --------------030805060907020403070808 Content-Type: text/plain; name="Current Charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Current Charter.txt" Background/Introduction: Note: Given that there is not much precedent for this type of activity at the IETF, the text that follows is of an introductory nature. Hence, its objective is to give a general idea of the application area and motivations for the work. In particular, this section is not to be construed as detailing work items for the working group. That is done in the following section entitled "Scope of the Working Group." Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application-- in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) * Robustness and simplicity in routing or network fabric A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology (the ZigBee alliance, for example, is currently studying what such a work item might entail). The working group is expected to coordinate and interact with such groups. The required work includes items in the following (incomplete) list: * IP adaptation/Packet Formats and interoperability * Addressing schemes and address management * Network management * Routing in dynamically adaptive topologies * Security, including set-up and maintenance * Application programming interface * Discovery (of devices, of services, etc) * Implementation considerations Whereas at least some of the above items are within the purview of the IETF, at this point it is not clear that all of them are. Accordingly, the 6LoWPAN working group will address a reduced, more focused set of objectives. Scope of 6lowpan: Produce "Problems Statement, Assumptions and Goals for IPv6 for LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the problem statement and goals of 6lowpan networks. Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the basic packet formats and sub-IP adaptation layer for transmission of IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, header compression and address generation. Furthermore, IEEE 802.15.4 devices are expected to be deployed in mesh topologies. As such, the working group may also work on an informational document to show how to apply an existing MANET protocol to LoWPANs (e.g., AODV, OLSR, DYMO, etc). The working group will reuse existing specifications whenever reasonable and possible. The working group will also serve as a venue for ongoing discussions on other topics related to the more complete list outlined above. Additional related milestones may be added in the future via a rechartering operation. Note: As may be obvious from its official name above, this particular working group will not work on IPv4 over IEEE 802.15.4 specifications. Given the limitations of the target devices, dual-stack deployments are not practical. Because of its higher potential for header compression, its support for the huge number of devices expected and of cleanly built-in features such as address autoconfiguration, IPv6 is the exclusive focus of the working group. Goals and Milestones: Done Working group last call on draft-ietf-lowpan-goals-assumptions-xx.txt Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG for consideration of publication as Informational Done Working Group Last Call on draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG for consideration of publication as Proposed Standard --------------030805060907020403070808 Content-Type: text/plain; name="New Charter.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="New Charter.txt" Background/Introduction: Note: Given that there is not much precedent for this type of activity at the IETF, the text that follows is of an introductory nature. Hence, its objective is to give a general idea of the application area and motivations for the work. In particular, this section is not to be construed as detailing work items for the working group. That is done in the following section entitled "Scope of the Working Group." Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application-- in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: The working group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to enusre interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for build 6LoWPAN networks, paying particular attention to protocols already available. Work Items: 1. Produce “6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations” to define the required optimizations to make IPv6 ND applicable in 6lowpans, given the fact that IPv6 ND is too expensive for the devices of 6lowpan and requires multicast. This document (or these documents - as the working group delves into this topic it may determine that this should be two separate documents) will define how to bootstrap a 6lowpan network and explore ND optimizations such as reusing the 802.15.4 network structure (use the coordinators), and obviate multicast by having devices talk to coordinators without creating a single point-of-failure, and changing the IPv6 ND multicast semantics. This document will be a proposed standard. 2. Produce “Problem Statement for Stateful Header Compression in 6lowpans” to document the problem of using stateful header compression (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of stateless header compression given the assumption that stateful header compression may be too complex. This document will determine if the assumption is correct and will be an informational document. The WG will determine if the assumption is correct at this time and record the findings in this informational document. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, network components, addressing, and IPv4/IPv6 network connections. 4. Produce “Recommendations for 6lowpan Applications” to define a set of recommendations of protocols to use for applications. The recommendations will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be an informational document. 5. Produce “6lowpan Security Analysis” to define the threat model of 6lowpans and to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be an informational document. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Goals and Milestones: Jan 2008 - First Draft of Bootstrapping and ND Optimization document Feb 2008 - First Draft of Stateful Header Compression document Dec 2007 - First Draft of 6LoWPAN Architecture docuement Feb 2008 - First Draft of Applications document Mar 2008 - First Draft of Security Analysis Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to be considered as Proposed Standard Jul 2008 - Submit Stateful Header Compression document to IESG to be considered as Proposed Standard May 2008 - Submit Architecture docuement to IESG to be considered as Informational RFC Jul 2008 - Submit Applications docuement to IESG to be considered as Informational RFC Sep 2008 - Submit Security Analysis document to IESG to be considered as Informational RFC. --------------030805060907020403070808 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --------------030805060907020403070808-- From 6lowpan-bounces@ietf.org Fri May 16 01:41:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 575A83A6AFC; Fri, 16 May 2008 01:41:56 -0700 (PDT) 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 174FA3A6AFC for <6lowpan@core3.amsl.com>; Fri, 16 May 2008 01:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkWH-2ldPxMk for <6lowpan@core3.amsl.com>; Fri, 16 May 2008 01:41:52 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id D78263A6AF5 for <6lowpan@ietf.org>; Fri, 16 May 2008 01:41:51 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so498718tib.25 for <6lowpan@ietf.org>; Fri, 16 May 2008 01:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=NSvYaIxp6gyt6XvMX7BLwylyygvwBxTwnVUkIhHtovU=; b=NTh/63MY0rfwV40NtBVAHPA6o5e/mn4ahNJgSU9oso11YBC0ffpsZA3qAlpIIUznZ5asUkj0faTxqtx2DsYpPEivlUaAi3Ub0a1Swjuch8kvw52A7wovUNJ/B5fU4PiwOaep4Cyo8Mk726LSYh31eIV1itGCInX287vHDwHa2JY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pVCxYg0jyHb426m8ZmjgVo2PbdOPS58YYSKCDCDU16UJpr8pkboccb/8D0oIOT0GPYfMRqBmbQZjSE2oFxXGJmns7pvMbT/5JySmFnLW6E8vRy6RPS8/k5j0Gg0RosOzCHD5eUe8gu2enIokasHcfmBntp7WKKv4XlsBvNXiW4Q= Received: by 10.110.46.14 with SMTP id t14mr447877tit.28.1210927301760; Fri, 16 May 2008 01:41:41 -0700 (PDT) Received: by 10.110.49.17 with HTTP; Fri, 16 May 2008 01:41:41 -0700 (PDT) Message-ID: <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> Date: Fri, 16 May 2008 10:41:41 +0200 From: "Eunsook \"Eunah\" Kim" To: "Mark Townsley" In-Reply-To: <482CA4DC.40508@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear AD, and chairmen, It's good to finally see official rechater text. I think it's pretty well delivering our discussion of rechartering so far, EXCEPT one part; 6lowpan routing requirement. Last meeting (71th IETF), we discussed RR matter and agreed to see IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember correctly, we would keep this work with alignment with ROLL, as long as it's not duplicate work with ROLL. I would like to know if it is implied that the RR work is included in Architecture work, OR, if you have *intentionally* excluded the work. If the first case, I would suggest 6LoWPANers check the updated version (-05) of draft. We updated our RR draft (-05) after the meeting based on the meeting discussion, and circulated to the mailing list. If the second case, I think we should get a chance to discuss the updated version. If the meeting decide the fate of this work after that, I would accept it. However, I have problem if AD or chairmen simply exclude this item without such discussion and concensus. Would you please clarify it to me? Thanks, -eunah On Thu, May 15, 2008 at 11:02 PM, Mark Townsley wrote: > > I'd like to ask the group one final time for comments on the proposed new > charter. I've also asked the ROLL WG chairs to comment. > > As I said before, soon after the format document was published, there is > nothing stopping the WG from discussing and working on new and existing > items at this time. In fact, activity helps us to decide what should be in > and out of the charter. Please do not construe not having a charter in place > as a reason not to update drafts, or discuss topics that need to be > discussed. Just as when we have BoF's and mailing lists before creating a > new WG, it is good to have WG meetings and on-lists discussions when > creating new WG charters. > > - Mark > > > > > > > Background/Introduction: > > Note: Given that there is not much precedent for this type of activity > at the IETF, the text that follows is of an introductory > nature. Hence, its objective is to give a general idea of the > application area and motivations for the work. In particular, this > section is not to be construed as detailing work items for the working > group. That is done in the following section entitled "Scope of the > Working Group." > > Well-established fields such as control networks, and burgeoning ones > such as "sensor" (or transducer) networks, are increasingly being > based on wireless technologies. Most (but certainly not all) of these > nodes are amongst the most constrained that have ever been networked > wirelessly. Extreme low power (such that they will run potentially for > years on batteries) and extreme low cost (total device cost in single > digit dollars, and riding Moore's law to continuously reduce that > price point) are seen as essential enablers towards their deployment > in networks with the following characteristics: > > * Significantly more devices than current networks > > * Severely limited code and ram space (e.g., highly desirable to > fit the required code--MAC, IP and anything else needed to > execute the embedded application-- in, for example, 32K of flash > memory, using 8-bit microprocessors) > > * Unobtrusive but very different user interface for configuration > (e.g., using gestures or interactions involving the physical > world) > > * Robustness and simplicity in routing or network fabric > > A chief component of these devices is wireless communication > technology. In particular, the IEEE 802.15.4 standard is very > promising for the lower (physical and link) layers. As for higher > layer functions, there is considerable interest from non-IETF groups > in using IP technology (the ZigBee alliance, for example, is currently > studying what such a work item might entail). The working group is > expected to coordinate and interact with such groups. > > The required work includes items in the following (incomplete) list: > > * IP adaptation/Packet Formats and interoperability > * Addressing schemes and address management > * Network management > * Routing in dynamically adaptive topologies > * Security, including set-up and maintenance > * Application programming interface > * Discovery (of devices, of services, etc) > * Implementation considerations > > Whereas at least some of the above items are within the purview of the > IETF, at this point it is not clear that all of them are. Accordingly, > the 6LoWPAN working group will address a reduced, more focused set of > objectives. > > Scope of 6lowpan: > > Produce "Problems Statement, Assumptions and Goals for IPv6 for > LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the > problem statement and goals of 6lowpan networks. > > Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN > Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the > basic packet formats and sub-IP adaptation layer for transmission of > IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, > header compression and address generation. Furthermore, IEEE 802.15.4 > devices are expected to be deployed in mesh topologies. > > As such, the working group may also work on an informational document > to show how to apply an existing MANET protocol to LoWPANs (e.g., > AODV, OLSR, DYMO, etc). > > The working group will reuse existing specifications whenever > reasonable and possible. > > The working group will also serve as a venue for ongoing discussions > on other topics related to the more complete list outlined above. > Additional related milestones may be added in the future via a > rechartering operation. > > Note: As may be obvious from its official name above, this particular > working group will not work on IPv4 over IEEE 802.15.4 specifications. > Given the limitations of the target devices, dual-stack deployments > are not practical. Because of its higher potential for header > compression, its support for the huge number of devices expected and > of cleanly built-in features such as address autoconfiguration, IPv6 > is the exclusive focus of the working group. > Goals and Milestones: > Done Working group last call on > draft-ietf-lowpan-goals-assumptions-xx.txt > Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG > for consideration of publication as Informational > Done Working Group Last Call on > draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt > Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG > for consideration of publication as Proposed Standard > > > > Background/Introduction: > > Note: Given that there is not much precedent for this type of activity > at the IETF, the text that follows is of an introductory > nature. Hence, its objective is to give a general idea of the > application area and motivations for the work. In particular, this > section is not to be construed as detailing work items for the working > group. That is done in the following section entitled "Scope of the > Working Group." > > Well-established fields such as control networks, and burgeoning ones > such as "sensor" (or transducer) networks, are increasingly being > based on wireless technologies. Most (but certainly not all) of these > nodes are amongst the most constrained that have ever been networked > wirelessly. Extreme low power (such that they will run potentially for > years on batteries) and extreme low cost (total device cost in single > digit dollars, and riding Moore's law to continuously reduce that > price point) are seen as essential enablers towards their deployment > in networks with the following characteristics: > > * Significantly more devices than current local area networks > > * Severely limited code and ram space (e.g., highly desirable to fit > the required code--MAC, IP and anything else needed to execute the > embedded application-- in, for example, 32K of flash memory, using > 8-bit microprocessors) > > * Unobtrusive but very different user interface for configuration > (e.g., using gestures or interactions involving the physical world) > > A chief component of these devices is wireless communication > technology. In particular, the IEEE 802.15.4 standard is very > promising for the lower (physical and link) layers. As for higher > layer functions, there is considerable interest from non-IETF groups > in using IP technology. The IEEE 1451.5 standard for wireless > transducers has a chapter for 6LoWPAN and the ISA SP100 standard for > wireless industrial networks has adopted 6LoWPAN for their network > layer. This working group is expected to coordinate and interact with > such groups. > > Description of Working Group: > > The working group has completed two RFCs: "IPv6 over Low-Power > Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, > Problem Statement, and Goals" (RFC4919) that documents and discusses > the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 > Networks" (RFC4944) which defines the format for the adaptation > between IPv6 and 802.15.4. > > The Working Group will generate the necessary documents to enusre > interoperable implementations of 6LoWPAN networks and will define the > necessary security and management protocols and constructs for build > 6LoWPAN networks, paying particular attention to protocols already > available. > > Work Items: > > 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" > to define the required optimizations to make IPv6 ND applicable in > 6lowpans, given the fact that IPv6 ND is too expensive for the devices > of 6lowpan and requires multicast. > > This document (or these documents - as the working group delves into > this topic it may determine that this should be two separate > documents) will define how to bootstrap a 6lowpan network and explore > ND optimizations such as reusing the 802.15.4 network structure (use > the coordinators), and obviate multicast by having devices talk to > coordinators without creating a single point-of-failure, and changing > the IPv6 ND multicast semantics. This document will be a proposed > standard. > > 2. Produce "Problem Statement for Stateful Header Compression in > 6lowpans" to document the problem of using stateful header compression > (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of > stateless header compression given the assumption that stateful header > compression may be too complex. This document will determine if the > assumption is correct and will be an informational document. The WG > will determine if the assumption is correct at this time and record > the findings in this informational document. > > 3. Produce "6LoWPAN Architecture" to describe the design and > implementation of 6LoWPAN networks. This document will cover the > concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, > network components, addressing, and IPv4/IPv6 network connections. > > 4. Produce "Recommendations for 6lowpan Applications" to define a set > of recommendations of protocols to use for applications. The > recommendations will cover protocols for transport, application layer, > discovery, configuration and commissioning. This document will be an > informational document. > > 5. Produce "6lowpan Security Analysis" to define the threat model of > 6lowpans and to document suitability of existing key management > schemes and to discuss bootstrapping/installation/commissioning/setup > issues. This document will be an informational document. > > The working group will continue to reuse existing protocols and > mechanisms whenever reasonable and possible. > > Goals and Milestones: > > Jan 2008 - First Draft of Bootstrapping and ND Optimization document > Feb 2008 - First Draft of Stateful Header Compression document > Dec 2007 - First Draft of 6LoWPAN Architecture docuement > Feb 2008 - First Draft of Applications document > Mar 2008 - First Draft of Security Analysis > Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to > be considered as Proposed Standard > Jul 2008 - Submit Stateful Header Compression document to IESG to be > considered as Proposed Standard > May 2008 - Submit Architecture docuement to IESG to be considered as > Informational RFC > Jul 2008 - Submit Applications docuement to IESG to be considered as > Informational RFC > Sep 2008 - Submit Security Analysis document to IESG to be considered > as Informational RFC. > > > > _______________________________________________ > 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 6lowpan-bounces@ietf.org Fri May 16 07:55:11 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE7483A6993; Fri, 16 May 2008 07:55:11 -0700 (PDT) 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 C17D23A67C1 for <6lowpan@core3.amsl.com>; Fri, 16 May 2008 07:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 x5CMPE2wYZbS for <6lowpan@core3.amsl.com>; Fri, 16 May 2008 07:55:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D2DA33A68D2 for <6lowpan@ietf.org>; Fri, 16 May 2008 07:55:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,497,1204498800"; d="scan'208";a="9118553" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 May 2008 16:54:58 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4GEswGW009776 for <6lowpan@ietf.org>; Fri, 16 May 2008 16:54:58 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4GEsw1F023239 for <6lowpan@ietf.org>; Fri, 16 May 2008 14:54:58 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 16:54:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 16 May 2008 16:54:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> In-Reply-To: <482CA4DC.40508@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci2zwm4FTnKZ4LtRxuv5MyxRqMuTAAkxgqQ References: <482CA4DC.40508@cisco.com> From: "Pascal Thubert (pthubert)" To: "Mark Townsley (townsley)" , <6lowpan@ietf.org> X-OriginalArrivalTime: 16 May 2008 14:54:57.0964 (UTC) FILETIME=[CF1FCEC0:01C8B764] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2251; t=1210949698; x=1211813698; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=AiN2oTZpDzKDACZUQ8+1ITcOKW7s1Qd5PbYE7Y0NlOc=; b=vDXEy98kSvaRaOWMb5xlnKP95rnkGrV6WfXihFQQopA0ytsKBskiiEhpSZ k3vVVl1FZ4LNWoX+zE6k/ifXKnY3faJEvDUmFh5WmdROCDgr3fy13XGLCBMz ebXLLiSQQL; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark: I think we need a work item (usually implicit) around the concept of improving existing WG RFCs. RFC 4944 can be improved in several aspects: - A major one is a better fit with ISA100.11a. Getting ISA100.11a to conform to 6LoWPAN would be a major win, but is certainly not a given. At the moment, the ISA100.11a documents expose discrepencies with RFC 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve for the most part. - The issue of fragmentation. Applying RFC 4944 over a multihop radio mesh exposes the network to congestion collapse, as described in http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec overy . I think that the WG should dedicate some bandwitdth to provide additional functions that would improve the LoWPAN operation WRT flow control and recovery of fragments. Another aspect of ISA100.11a is the concept of a backbone router. It would be appropriate that the IETF comes up with a proposal to implement the concept in the IPv6 world. This partially falls under the first work item on ND but might also include ND proxy over the backbone which is a stretch to the work item. More in http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. What do you think? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Mark Townsley >(townsley) >Sent: jeudi 15 mai 2008 23:02 >To: 6lowpan@ietf.org >Subject: [6lowpan] New charter for 6lowpan > > >I'd like to ask the group one final time for comments on the proposed >new charter. I've also asked the ROLL WG chairs to comment. > >As I said before, soon after the format document was published, there is >nothing stopping the WG from discussing and working on new and existing >items at this time. In fact, activity helps us to decide what should be >in and out of the charter. Please do not construe not having a charter >in place as a reason not to update drafts, or discuss topics that need >to be discussed. Just as when we have BoF's and mailing lists before >creating a new WG, it is good to have WG meetings and on-lists >discussions when creating new WG charters. > >- Mark > > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 16 11:48:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C1E23A6B7D; Fri, 16 May 2008 11:48:12 -0700 (PDT) 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 090773A6B83 for <6lowpan@core3.amsl.com>; Fri, 16 May 2008 11:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 yOXuex7JwTpa for <6lowpan@core3.amsl.com>; Fri, 16 May 2008 11:48:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7A4C828C247 for <6lowpan@ietf.org>; Fri, 16 May 2008 11:47:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,498,1204520400"; d="scan'208";a="8477837" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 May 2008 14:47:00 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4GIl0Hb016333 for <6lowpan@ietf.org>; Fri, 16 May 2008 14:47:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4GIl0ru004417 for <6lowpan@ietf.org>; Fri, 16 May 2008 18:47:00 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 14:47:00 -0400 Received: from rtp-townsley-vpn5.cisco.com ([10.83.1.102]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 May 2008 14:46:59 -0400 Message-ID: <482DD69F.7080304@cisco.com> Date: Fri, 16 May 2008 20:46:55 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 16 May 2008 18:46:59.0654 (UTC) FILETIME=[39191E60:01C8B785] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2841; t=1210963620; x=1211827620; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20; bh=8Pwpp0P1jboz+kWOj+iNcGTe0U1TLPXepQMw8hf3Ev4=; b=vrwMtuYLtxncCplh4E/sc3lpM9spMneKtk7pBrjMetIcmZKnchp63tiI4u OW7150orq88Hwa6C8uFqhlLmJSPeRer6xOAEBdsM5Y+gxyiCqV9jpZ1lzpu8 h9CclNp3/q; Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Mark: > > I think we need a work item (usually implicit) around the concept of > improving existing WG RFCs. RFC 4944 can be improved in several aspects: > > > - A major one is a better fit with ISA100.11a. Getting ISA100.11a to > conform to 6LoWPAN would be a major win, but is certainly not a given. > At the moment, the ISA100.11a documents expose discrepencies with RFC > 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve > for the most part. > Are the resolutions backwards compatible with RFC 4944? I'm eager to improve RFC 4944, but not eager to endorse changes that inhibit interoperability. > - The issue of fragmentation. Applying RFC 4944 over a multihop radio > mesh exposes the network to congestion collapse, as described in > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > overy . I think that the WG should dedicate some bandwitdth to provide > additional functions that would improve the LoWPAN operation WRT flow > control and recovery of fragments. > Fragmentation, OK, but why is flow control a network layer issue rather than a transport layer issue? > Another aspect of ISA100.11a is the concept of a backbone router. It > would be appropriate that the IETF comes up with a proposal to implement > the concept in the IPv6 world. This partially falls under the first work > item on ND but might also include ND proxy over the backbone which is a > stretch to the work item. More in > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. > Well, don't we need to define what ND looks like on a lowpan before we decide whether it needs to be proxied or not? - Mark > What do you think? > > Pascal > > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> > Behalf Of Mark Townsley > >> (townsley) >> Sent: jeudi 15 mai 2008 23:02 >> To: 6lowpan@ietf.org >> Subject: [6lowpan] New charter for 6lowpan >> >> >> I'd like to ask the group one final time for comments on the proposed >> new charter. I've also asked the ROLL WG chairs to comment. >> >> As I said before, soon after the format document was published, there >> > is > >> nothing stopping the WG from discussing and working on new and existing >> items at this time. In fact, activity helps us to decide what should be >> in and out of the charter. Please do not construe not having a charter >> in place as a reason not to update drafts, or discuss topics that need >> to be discussed. Just as when we have BoF's and mailing lists before >> creating a new WG, it is good to have WG meetings and on-lists >> discussions when creating new WG charters. >> >> - Mark >> >> >> >> >> > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun May 18 07:33:16 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E39A3A691A; Sun, 18 May 2008 07:33:16 -0700 (PDT) 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 81FB13A695F for <6lowpan@core3.amsl.com>; Sun, 18 May 2008 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[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 LBmTw-nmAzvZ for <6lowpan@core3.amsl.com>; Sun, 18 May 2008 07:33:13 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id F35FC3A67DF for <6lowpan@ietf.org>; Sun, 18 May 2008 07:33:12 -0700 (PDT) Received: from snl-zach.local (wlan.hotspot.fortenetservices.com [62.61.65.106]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id m4IEWueR011478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6lowpan@ietf.org>; Sun, 18 May 2008 17:32:57 +0300 Message-ID: <48303ACF.8090608@sensinode.com> Date: Sun, 18 May 2008 17:18:55 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan@ietf.org References: <482CA4DC.40508@cisco.com> In-Reply-To: <482CA4DC.40508@cisco.com> Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Mark, There are two issues that I would like to see clarified. They are both = related to connecting 6lowpan networks with backbone IPv6 networks = better than we can do it now. In my opinion this is the "killer" feature = of 6lowpan. Including these in some future re-charter would be too late. 1. In my opinion the interconnection of 6lowpan and backbone networks = using ND techniques along with whiteboarding are important and worth = including into the standard track. =936lowpan Bootstrapping and 6lowpan = IPv6 ND Optimizations=94 should include definition of how to do proxy-ND = over BbRs? In other words to include some of the ideas from = draft-thubert-6lowpan-backbone-router. I would like to propose expanding = the text of that section to: ... will define how to bootstrap a 6lowpan network and explore ND optimizations such as reusing the 802.15.4 network structure (use the coordinators), the use of backbone routers, and obviate multicast by = having devices talk to coordinators without creating a single = point-of-failure, and changing the IPv6 ND multicast semantics. 2. I would also like to see further improvements to RFC4944, namely = draft-hui-6lowpan-hc as a start. I don't see a place for this at all in = the current charter. It can surely be done in a way sufficiently = backward compatible with the current RFC. Shall a separate WG item exist = for this? Otherwise the charter has my full support. - Zach Mark Townsley wrote: > = > I'd like to ask the group one final time for comments on the proposed = > new charter. I've also asked the ROLL WG chairs to comment. > = > As I said before, soon after the format document was published, there is = > nothing stopping the WG from discussing and working on new and existing = > items at this time. In fact, activity helps us to decide what should be = > in and out of the charter. Please do not construe not having a charter = > in place as a reason not to update drafts, or discuss topics that need = > to be discussed. Just as when we have BoF's and mailing lists before = > creating a new WG, it is good to have WG meetings and on-lists = > discussions when creating new WG charters. > = > - Mark > = > = > = > = > = > = > ------------------------------------------------------------------------ > = > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan -- = Zach Shelby | Head of Research | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon May 19 02:44:32 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3796E28C151; Mon, 19 May 2008 02:44:32 -0700 (PDT) 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 77D803A6916 for <6lowpan@core3.amsl.com>; Mon, 19 May 2008 02:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfzgxBVAnYE7 for <6lowpan@core3.amsl.com>; Mon, 19 May 2008 02:44:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 06D5028C12C for <6lowpan@ietf.org>; Mon, 19 May 2008 02:44:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,508,1204498800"; d="scan'208";a="9246948" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 May 2008 11:44:28 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4J9iSLG011449 for <6lowpan@ietf.org>; Mon, 19 May 2008 11:44:28 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4J9iSae020875 for <6lowpan@ietf.org>; Mon, 19 May 2008 09:44:28 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 May 2008 11:44:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 May 2008 11:43:56 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05AFD9C1@xmb-ams-337.emea.cisco.com> In-Reply-To: <482DD69F.7080304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci3hTov+BLe4GN6TEC+eC4DIeGkvwCDpBEg References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> From: "Pascal Thubert (pthubert)" To: "Mark Townsley (townsley)" X-OriginalArrivalTime: 19 May 2008 09:44:27.0942 (UTC) FILETIME=[EE014C60:01C8B994] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3876; t=1211190268; x=1212054268; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=yD+Peazu4jLCisc3k2gZi85BJtmXpe+exw32dfgkElc=; b=sOopZ14FYETWZqMs10ix7Sqc3q/N+dbdzH1qcYuxXGjhLj+kdP0Ot7VVwq pUH/wCKdrB7l/0wmfKdKyVIto9fdsmNBeBRKEphlTeK+muYR1nbXxatgj3rX muUA+8E7K6; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark; I'd say the other way around. We need to figure out whether the ISA100 concept of a backbone is a more generic one and if we agree that such a backbone federates multiple LoWPANs as a single larger link. If we agree on that then we need to design ND for that larger link. That's when the concept of a registration protocol over the LowPAN associated to proxy ND on the backbone comes into mind. This model should work whether the host on the LoWPAN gets its addresses from ND autoconf, DHCP or whatever new registration protocol that might come up to fill the gap between the two. In particular, this can impact the design of ND on the LowPAN and incline for a solution based on white board. This is why I feel it's important to discuss that now. Pascal >-----Original Message----- >From: Mark Townsley (townsley) >Sent: vendredi 16 mai 2008 20:47 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > >Pascal Thubert (pthubert) wrote: >> Hi Mark: >> >> I think we need a work item (usually implicit) around the concept of >> improving existing WG RFCs. RFC 4944 can be improved in several aspects: >> > >> >> - A major one is a better fit with ISA100.11a. Getting ISA100.11a to >> conform to 6LoWPAN would be a major win, but is certainly not a given. >> At the moment, the ISA100.11a documents expose discrepencies with RFC >> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve >> for the most part. >> >Are the resolutions backwards compatible with RFC 4944? I'm eager to >improve RFC 4944, but not eager to endorse changes that inhibit >interoperability. >> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >> mesh exposes the network to congestion collapse, as described in >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> overy . I think that the WG should dedicate some bandwitdth to provide >> additional functions that would improve the LoWPAN operation WRT flow >> control and recovery of fragments. >> >Fragmentation, OK, but why is flow control a network layer issue rather >than a transport layer issue? >> Another aspect of ISA100.11a is the concept of a backbone router. It >> would be appropriate that the IETF comes up with a proposal to implement >> the concept in the IPv6 world. This partially falls under the first work >> item on ND but might also include ND proxy over the backbone which is a >> stretch to the work item. More in >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. >> >Well, don't we need to define what ND looks like on a lowpan before we >decide whether it needs to be proxied or not? > >- Mark >> What do you think? >> >> Pascal >> >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> >> Behalf Of Mark Townsley >> >>> (townsley) >>> Sent: jeudi 15 mai 2008 23:02 >>> To: 6lowpan@ietf.org >>> Subject: [6lowpan] New charter for 6lowpan >>> >>> >>> I'd like to ask the group one final time for comments on the proposed >>> new charter. I've also asked the ROLL WG chairs to comment. >>> >>> As I said before, soon after the format document was published, there >>> >> is >> >>> nothing stopping the WG from discussing and working on new and existing >>> items at this time. In fact, activity helps us to decide what should be >>> in and out of the charter. Please do not construe not having a charter >>> in place as a reason not to update drafts, or discuss topics that need >>> to be discussed. Just as when we have BoF's and mailing lists before >>> creating a new WG, it is good to have WG meetings and on-lists >>> discussions when creating new WG charters. >>> >>> - Mark >>> >>> >>> >>> >>> >> >> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon May 19 09:36:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1666128C1F2; Mon, 19 May 2008 09:36:12 -0700 (PDT) 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 982E43A6B2F for <6lowpan@core3.amsl.com>; Mon, 19 May 2008 09:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KEelAYzDBv7 for <6lowpan@core3.amsl.com>; Mon, 19 May 2008 09:36:09 -0700 (PDT) Received: from mail.sf.archrock.com (71.16.121.216.reverse.servepath.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 802C53A6B17 for <6lowpan@ietf.org>; Mon, 19 May 2008 09:36:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 33EA3A9220; Mon, 19 May 2008 09:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIWmx23SS48I; Mon, 19 May 2008 09:36:03 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 9086BA91FE; Mon, 19 May 2008 09:36:03 -0700 (PDT) Message-Id: <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> From: Jonathan Hui To: Mark Townsley In-Reply-To: <482DD69F.7080304@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 19 May 2008 09:36:02 -0700 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark, thanks for reigniting the discussion on this. - Improving RFC 4944 is an important one. The biggest issue I have with it in the near term is that the IPv6 header compression does not allow compression of non-link-local addresses, which is an important case if we truly intend to do inter-networking. This is the most important point of the 6lopwan-hc draft. Backwards compatibility is supported by utilizing new dispatch values. But it's important to consider what the implementation costs are of supporting the LOWPAN_HC1 defined in RFC 4944, especially since 6lowpan-hc does cover most of the useful cases in LOWPAN_HC1. Something for the WG to discuss... - To your point on ND, this is precisely why the architecture draft is so important. We haven't given it as much attention lately, but it will help resolve the question your raise and many other questions in the future. For example, the architecture draft identifies two modes of operation: mesh-under and route-over. Both of which may require different ND mechanisms. This doesn't apply to just ND, but may apply questions of fragmentation, header compression, security, etc. - I hesitate a bit that we suggest possible solutions to ND in the charter ("reusing the 802.15.4 network structure (use the coordinators)") especially since the definition of such link mechanisms are still in motion within the IEEE. It seems more productive to me if we can develop mechanisms that are less dependent on the specific structure of 802.15.4 mechanisms. Rest of the charter looks good to me. Thanks. -- Jonathan Hui On May 16, 2008, at 11:46 AM, Mark Townsley wrote: > Pascal Thubert (pthubert) wrote: >> Hi Mark: >> >> I think we need a work item (usually implicit) around the concept of >> improving existing WG RFCs. RFC 4944 can be improved in several >> aspects: >> > >> >> - A major one is a better fit with ISA100.11a. Getting ISA100.11a to >> conform to 6LoWPAN would be a major win, but is certainly not a >> given. >> At the moment, the ISA100.11a documents expose discrepencies with RFC >> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve >> for the most part. >> > Are the resolutions backwards compatible with RFC 4944? I'm eager to > improve RFC 4944, but not eager to endorse changes that inhibit > interoperability. >> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >> mesh exposes the network to congestion collapse, as described in >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> overy . I think that the WG should dedicate some bandwitdth to >> provide >> additional functions that would improve the LoWPAN operation WRT flow >> control and recovery of fragments. >> > Fragmentation, OK, but why is flow control a network layer issue > rather > than a transport layer issue? >> Another aspect of ISA100.11a is the concept of a backbone router. It >> would be appropriate that the IETF comes up with a proposal to >> implement >> the concept in the IPv6 world. This partially falls under the first >> work >> item on ND but might also include ND proxy over the backbone which >> is a >> stretch to the work item. More in >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. >> > Well, don't we need to define what ND looks like on a lowpan before we > decide whether it needs to be proxied or not? > > - Mark >> What do you think? >> >> Pascal >> >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> >> Behalf Of Mark Townsley >> >>> (townsley) >>> Sent: jeudi 15 mai 2008 23:02 >>> To: 6lowpan@ietf.org >>> Subject: [6lowpan] New charter for 6lowpan >>> >>> >>> I'd like to ask the group one final time for comments on the >>> proposed >>> new charter. I've also asked the ROLL WG chairs to comment. >>> >>> As I said before, soon after the format document was published, >>> there >>> >> is >> >>> nothing stopping the WG from discussing and working on new and >>> existing >>> items at this time. In fact, activity helps us to decide what >>> should be >>> in and out of the charter. Please do not construe not having a >>> charter >>> in place as a reason not to update drafts, or discuss topics that >>> need >>> to be discussed. Just as when we have BoF's and mailing lists before >>> creating a new WG, it is good to have WG meetings and on-lists >>> discussions when creating new WG charters. >>> >>> - Mark >>> >>> >>> >>> >>> >> >> >> > > _______________________________________________ > 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 6lowpan-bounces@ietf.org Tue May 20 00:13:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D63B3A6BB5; Tue, 20 May 2008 00:13:20 -0700 (PDT) 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 90DB33A6BC2 for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 00:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF47F8YMq2q9 for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 00:12:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 1157A3A6BC0 for <6lowpan@ietf.org>; Tue, 20 May 2008 00:12:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,513,1204498800"; d="scan'208";a="9343890" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 20 May 2008 09:12:09 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4K7C9AO016374 for <6lowpan@ietf.org>; Tue, 20 May 2008 09:12:09 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4K7C9iS019574 for <6lowpan@ietf.org>; Tue, 20 May 2008 07:12:09 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 09:12:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 09:11:37 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05AFDDD3@xmb-ams-337.emea.cisco.com> In-Reply-To: <482DD69F.7080304@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci3hTov+BLe4GN6TEC+eC4DIeGkvwCwoZ0A References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> From: "Pascal Thubert (pthubert)" To: "Mark Townsley (townsley)" X-OriginalArrivalTime: 20 May 2008 07:12:09.0272 (UTC) FILETIME=[D158AB80:01C8BA48] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1070; t=1211267529; x=1212131529; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=vbCtVTM0kapJ9+x35IhITh3Xi+VcSRcpgvA9uXgqLHo=; b=bX5WDAGnXOd8GnaRynEF9E6ESDfZbeRhvlixDsp6e6Ve1k9ChLNGNAy62D bPnRUafgFpMNzn6L2o1UGNxemJoCBOY4yP/10fGGatpAC25BViKMA1YE4nEo TtI8CXawLo; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi again Mark >> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >> mesh exposes the network to congestion collapse, as described in >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> overy . I think that the WG should dedicate some bandwitdth to provide >> additional functions that would improve the LoWPAN operation WRT flow >> control and recovery of fragments. >> >Fragmentation, OK, but why is flow control a network layer issue rather >than a transport layer issue? [Pascal] I'm talking about flow control on the fragments themselves; this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes minimum, it causes a burst of fragments that should be paced and windowed. I suggest we do it in 6LoWPAN and handle the consequences of our own fragmentation rather than rely on a LLC mechanism that might not be there or adapted. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 20 05:56:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E663F3A69C8; Tue, 20 May 2008 05:56:42 -0700 (PDT) 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 BA52D3A69C8 for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 05:56:41 -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 ZS7jlHa8WUgd for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 05:56:40 -0700 (PDT) Received: from mail.nivis.com (mail.nivis.com [65.205.163.229]) by core3.amsl.com (Postfix) with SMTP id B01D43A69AE for <6lowpan@ietf.org>; Tue, 20 May 2008 05:56:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 08:56:35 -0400 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05AFDDD3@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci3hTov+BLe4GN6TEC+eC4DIeGkvwCwoZ0AAAtLxAA= References: <482CA4DC.40508@cisco.com><7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com><482DD69F.7080304@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFDDD3@xmb-ams-337.emea.cisco.com> From: "Robert Assimiti" To: "Pascal Thubert (pthubert)" , "Mark Townsley (townsley)" Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hello Pascal, I agree with you that a well defined and standardized way of doing fragment= recovery and controlling the flow of these fragments are quite needed. I also agree with you, that it belongs functionally (if not academically) i= n the 6loWPAN NWK layer. THks "The nice thing about standards is that there are so many to choose from." = - Andrew S. Tanenbaum = Robert Assimiti Executive Staff=A0Engineer Office: [678]-202-6859 Mobile: [404]-578-0205 robert.assimiti@nivis.com -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf = Of Pascal Thubert (pthubert) Sent: Tuesday, May 20, 2008 3:12 AM To: Mark Townsley (townsley) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan Hi again Mark >> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >> mesh exposes the network to congestion collapse, as described in >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> overy . I think that the WG should dedicate some bandwitdth to provide >> additional functions that would improve the LoWPAN operation WRT flow >> control and recovery of fragments. >> >Fragmentation, OK, but why is flow control a network layer issue rather >than a transport layer issue? [Pascal] I'm talking about flow control on the fragments themselves; this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes minimum, it causes a burst of fragments that should be paced and windowed. I suggest we do it in 6LoWPAN and handle the consequences of our own fragmentation rather than rely on a LLC mechanism that might not be there or adapted. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan This e-mail (including any attachments to it) is confidential, proprietary,= legally privileged, subject to copyright and is sent for the personal atte= ntion of the intended recipient only. If you have received this e-mail in e= rror, please reply to advise us immediately, delete it and destroy any prin= ted copies of it. You are notified that reading, disclosing, copying, distr= ibuting or taking any action in reliance on the contents of this informatio= n is strictly prohibited. No employee is authorized to conclude any binding= agreement on behalf of NIVIS LLC with another party by e-mail without expr= ess written confirmation by an officer of the company. Although we have tak= en reasonable precautions to ensure no viruses are present in this e-mail, = we cannot accept responsibility for any loss or damage arising from the vir= uses in this e-mail or attachments. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 20 20:43:25 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21DA3A6EE1; Tue, 20 May 2008 20:43:25 -0700 (PDT) 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 6BA4E3A6812 for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TCYiT1dl-qM for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:43:17 -0700 (PDT) Received: from mail.globalsuite.net (mail.globalsuite.net [69.46.103.200]) by core3.amsl.com (Postfix) with SMTP id 1A8B928D003 for <6lowpan@ietf.org>; Tue, 20 May 2008 08:25:00 -0700 (PDT) X-AuditID: c0a8013c-a4eeebb000006e3b-f5-4832ed4b98ea Received: from Townsley-MacBook.local (unknown [207.134.107.2]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 142354DC00B; Tue, 20 May 2008 09:24:58 -0600 (MDT) Message-ID: <4832ED46.1070304@cisco.com> Date: Tue, 20 May 2008 11:24:54 -0400 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jonathan Hui References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> In-Reply-To: <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> X-Brightmail-Tracker: AAAAAA== Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Jonathan Hui wrote: > > Hi Mark, thanks for reigniting the discussion on this. > > - Improving RFC 4944 is an important one. The biggest issue I have > with it in the near term is that the IPv6 header compression does not > allow compression of non-link-local addresses, which is an important > case if we truly intend to do inter-networking. This is the most > important point of the 6lopwan-hc draft. Backwards compatibility is > supported by utilizing new dispatch values. But it's important to > consider what the implementation costs are of supporting the > LOWPAN_HC1 defined in RFC 4944, especially since 6lowpan-hc does cover > most of the useful cases in LOWPAN_HC1. Something for the WG to > discuss... Yes, in is incumbent on us as the IETF to ensure that the 6lowpan can ultimately be a part of the wider Internet. > > - To your point on ND, this is precisely why the architecture draft is > so important. We haven't given it as much attention lately, but it > will help resolve the question your raise and many other questions in > the future. For example, the architecture draft identifies two modes > of operation: mesh-under and route-over. Both of which may require > different ND mechanisms. This doesn't apply to just ND, but may apply > questions of fragmentation, header compression, security, etc. I worry about the under/over debate. It seems that with all the effort and enthusiasm in ROLL, we might be well-served at the moment by focusing on helping them be successful with route-over than spending too much of our time on route-under. > > - I hesitate a bit that we suggest possible solutions to ND in the > charter ("reusing the 802.15.4 network structure (use the > coordinators)") especially since the definition of such link > mechanisms are still in motion within the IEEE. It seems more > productive to me if we can develop mechanisms that are less dependent > on the specific structure of 802.15.4 mechanisms. I agree that we should develop mechanisms that could work generically whenever possible. - Mark > > Rest of the charter looks good to me. > > Thanks. > > -- > Jonathan Hui > > > > On May 16, 2008, at 11:46 AM, Mark Townsley wrote: > >> Pascal Thubert (pthubert) wrote: >>> Hi Mark: >>> >>> I think we need a work item (usually implicit) around the concept of >>> improving existing WG RFCs. RFC 4944 can be improved in several >>> aspects: >>> >> >>> >>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a to >>> conform to 6LoWPAN would be a major win, but is certainly not a given. >>> At the moment, the ISA100.11a documents expose discrepencies with RFC >>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve >>> for the most part. >>> >> Are the resolutions backwards compatible with RFC 4944? I'm eager to >> improve RFC 4944, but not eager to endorse changes that inhibit >> interoperability. >>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>> mesh exposes the network to congestion collapse, as described in >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>> >>> overy . I think that the WG should dedicate some bandwitdth to provide >>> additional functions that would improve the LoWPAN operation WRT flow >>> control and recovery of fragments. >>> >> Fragmentation, OK, but why is flow control a network layer issue rather >> than a transport layer issue? >>> Another aspect of ISA100.11a is the concept of a backbone router. It >>> would be appropriate that the IETF comes up with a proposal to >>> implement >>> the concept in the IPv6 world. This partially falls under the first >>> work >>> item on ND but might also include ND proxy over the backbone which is a >>> stretch to the work item. More in >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. >>> >> Well, don't we need to define what ND looks like on a lowpan before we >> decide whether it needs to be proxied or not? >> >> - Mark >>> What do you think? >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> >>> Behalf Of Mark Townsley >>> >>>> (townsley) >>>> Sent: jeudi 15 mai 2008 23:02 >>>> To: 6lowpan@ietf.org >>>> Subject: [6lowpan] New charter for 6lowpan >>>> >>>> >>>> I'd like to ask the group one final time for comments on the proposed >>>> new charter. I've also asked the ROLL WG chairs to comment. >>>> >>>> As I said before, soon after the format document was published, there >>>> >>> is >>> >>>> nothing stopping the WG from discussing and working on new and >>>> existing >>>> items at this time. In fact, activity helps us to decide what >>>> should be >>>> in and out of the charter. Please do not construe not having a charter >>>> in place as a reason not to update drafts, or discuss topics that need >>>> to be discussed. Just as when we have BoF's and mailing lists before >>>> creating a new WG, it is good to have WG meetings and on-lists >>>> discussions when creating new WG charters. >>>> >>>> - Mark >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> _______________________________________________ >> 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 6lowpan-bounces@ietf.org Tue May 20 20:51:31 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B57F28C725; Tue, 20 May 2008 20:51:31 -0700 (PDT) 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 DC46628C6FE for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xYibAsIQdaw for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:51:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C94E828D2F1 for <6lowpan@ietf.org>; Tue, 20 May 2008 09:02:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,516,1204498800"; d="scan'208";a="9423271" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 May 2008 18:02:17 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4KG2HEE010747 for <6lowpan@ietf.org>; Tue, 20 May 2008 18:02:17 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4KG2HKS004992 for <6lowpan@ietf.org>; Tue, 20 May 2008 16:02:17 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 18:02:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 18:01:44 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> In-Reply-To: <4832EBC2.8050902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci6jMxrYwQCzYkZQ8m3LENi5fv8UQABVvLg References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFDDD3@xmb-ams-337.emea.cisco.com> <4832EBC2.8050902@cisco.com> From: "Pascal Thubert (pthubert)" To: "Mark Townsley (townsley)" X-OriginalArrivalTime: 20 May 2008 16:02:17.0301 (UTC) FILETIME=[E068B850:01C8BA92] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2494; t=1211299337; x=1212163337; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=jk6hyVm/MUNhdbbN6u0Q54vhmAIBbLp4jKEAtso55tw=; b=l+aZZ6xxKMB4su5Nx/qmHuxB+R+VXjwJvvnJPlrs2eD0O0Pchq70HvbGxx /r1GJnKMW6QJMfDcdKVwjeF+k1gIC0d+RmuQZowzE6S03oujnmOYIsO0qE+7 FRTh4PIxvp; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Again Mark: Another aspect of this is ECN. We do not have room for Explicit Congestion Notification in the 6LoWPAN headers. ECN only takes 2 bits in Frame Relay and in IP, though the bits are used differently. I have in mind that the FR version with forward and backward bits is a better fit if it acts upon the fragment flow control, though the FECN could then be mapped into IP ECN. This is additional work to the fragment recovery and I'm taking great care to present them separate. But it could become an interesting feature in some future as well. Pascal >-----Original Message----- >From: Mark Townsley (townsley) >Sent: mardi 20 mai 2008 17:18 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > >Pascal Thubert (pthubert) wrote: >> Hi again Mark >> >> >>>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>>> mesh exposes the network to congestion collapse, as described in >>>> >>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> >>>> overy . I think that the WG should dedicate some bandwitdth to >>>> >> provide >> >>>> additional functions that would improve the LoWPAN operation WRT flow >>>> control and recovery of fragments. >>>> >>>> >>> Fragmentation, OK, but why is flow control a network layer issue rather >>> than a transport layer issue? >>> >> >> [Pascal] I'm talking about flow control on the fragments themselves; >> this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above >> LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to >> cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes >> minimum, it causes a burst of fragments that should be paced and >> windowed. I suggest we do it in 6LoWPAN and handle the consequences of >> our own fragmentation rather than rely on a LLC mechanism that might not >> be there or adapted. >> >OK, that makes sense. Of course, if the higher layer transports consider >this fragmented packet lost and retransmit in the mean time we will end >up thrashing. We need to be very wary of the higher-layer transport >affects. And, of course this isn't the first time I've thought we might >need ot spin up a transport-area lowpan WG similar to what we did with >ROLL. But, sometimes its hard enough to keep 2 working groups working >and making progress, much less 3. > >- Mark >> Pascal >> >> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 20 20:54:37 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFF928C766; Tue, 20 May 2008 20:54:37 -0700 (PDT) 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 C27C228C55F for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3guuKNVyLTY for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:54:33 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 83D3028D25F for <6lowpan@ietf.org>; Tue, 20 May 2008 08:56:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,516,1204498800"; d="scan'208";a="9422524" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 May 2008 17:56:57 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4KFuvxl008843 for <6lowpan@ietf.org>; Tue, 20 May 2008 17:56:57 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4KFuvOC002693 for <6lowpan@ietf.org>; Tue, 20 May 2008 15:56:57 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 17:56:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 17:56:22 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B60A6B@xmb-ams-337.emea.cisco.com> In-Reply-To: <4832EBC2.8050902@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci6jMxrYwQCzYkZQ8m3LENi5fv8UQAA51PA References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFDDD3@xmb-ams-337.emea.cisco.com> <4832EBC2.8050902@cisco.com> From: "Pascal Thubert (pthubert)" To: "Mark Townsley (townsley)" X-OriginalArrivalTime: 20 May 2008 15:56:57.0006 (UTC) FILETIME=[217F94E0:01C8BA92] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2717; t=1211299017; x=1212163017; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=sWkpFpNSo2UdDBuEEF05Vjjg/E8plLwSyffYQvAJjTY=; b=rHtLeD1dwvXL+4vj33ljM3ZnxwJenPobxRDRRnOPzd5J9iWT9SWLZYVteY YnxJPVlFaisIn+W6F5lWrQ+0BaDaVGAvJ0PSGqbtNQaMogLfbw3M8Sciy9Je cSJNo8/XUq; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark: It would be great to get some help from transport area but forking a WG could be overkill for the task at hand. We know that we'll get less than 32 fragments, so we can acknowledge the received ones with a simple DWORD bitmap, and we do not really need a complex sliding window but rather a simple number of outstanding fragments that we can play with for flow control. For those who doubt that the feature is really important, I have compiled some references and history on fragments in the Internet in my draft; it appears that a multihop Low Power & Lossy mesh can be worse a situation than many we've seen in the past and getting dozens of fragments just do not help. This is why I strongly suggest that we add fragment control and recovery to the charter. Pascal >-----Original Message----- >From: Mark Townsley (townsley) >Sent: mardi 20 mai 2008 17:18 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > >Pascal Thubert (pthubert) wrote: >> Hi again Mark >> >> >>>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>>> mesh exposes the network to congestion collapse, as described in >>>> >>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> >>>> overy . I think that the WG should dedicate some bandwitdth to >>>> >> provide >> >>>> additional functions that would improve the LoWPAN operation WRT flow >>>> control and recovery of fragments. >>>> >>>> >>> Fragmentation, OK, but why is flow control a network layer issue rather >>> than a transport layer issue? >>> >> >> [Pascal] I'm talking about flow control on the fragments themselves; >> this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above >> LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to >> cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes >> minimum, it causes a burst of fragments that should be paced and >> windowed. I suggest we do it in 6LoWPAN and handle the consequences of >> our own fragmentation rather than rely on a LLC mechanism that might not >> be there or adapted. >> >OK, that makes sense. Of course, if the higher layer transports consider >this fragmented packet lost and retransmit in the mean time we will end >up thrashing. We need to be very wary of the higher-layer transport >affects. And, of course this isn't the first time I've thought we might >need ot spin up a transport-area lowpan WG similar to what we did with >ROLL. But, sometimes its hard enough to keep 2 working groups working >and making progress, much less 3. > >- Mark >> Pascal >> >> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 20 20:55:13 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202F63A6FB4; Tue, 20 May 2008 20:55:13 -0700 (PDT) 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 EEC223A6F91 for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edTMiHV3yLXT for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:55:07 -0700 (PDT) Received: from mail.globalsuite.net (mail.globalsuite.net [69.46.103.200]) by core3.amsl.com (Postfix) with SMTP id A345328D1B0 for <6lowpan@ietf.org>; Tue, 20 May 2008 08:47:07 -0700 (PDT) X-AuditID: c0a8013c-a26e9bb000006e3b-53-4832f27ac0b9 Received: from Townsley-MacBook.local (unknown [207.134.107.2]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 3F0654DC006; Tue, 20 May 2008 09:47:06 -0600 (MDT) Message-ID: <4832F276.70406@cisco.com> Date: Tue, 20 May 2008 11:47:02 -0400 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Eunsook \"Eunah\" Kim" References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> In-Reply-To: <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> X-Brightmail-Tracker: AAAAAA== Cc: 6lowpan@ietf.org, roll-chairs@tools.ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Eunsook "Eunah" Kim wrote: > Dear AD, and chairmen, > > It's good to finally see official rechater text. > It's only proposed text. > I think it's pretty well delivering our discussion of rechartering so > far, EXCEPT one part; 6lowpan routing requirement. > Last meeting (71th IETF), we discussed RR matter and agreed to see > IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember > correctly, we would keep this work with alignment with ROLL, as long > as it's not duplicate work with ROLL. > You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what are your expectations from 6lowpan with respect to the routing-requirements document? http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt I have some more questions for you specifically: Should that be pulled into roll, or left in 6lowpan? Is roll considering the L2"route-under" model at all? Is there anything that the L3 "route-over" model might not provide that is listed as a requirement for 6lowpan's "route-under" model? If 6lowpan were to work on an L2 "route-under" model, would there be constructs (e.g., the routing protocol itself and any low-power modifications) from ROLL that we would invariably want to try and reuse? > I would like to know if it is implied that the RR work is included in > Architecture work, OR, if you have *intentionally* excluded the work. > > If the first case, I would suggest 6LoWPANers check the updated > version (-05) of draft. We updated our RR draft (-05) after the > meeting based on the meeting discussion, and circulated to the mailing > list. > > If the second case, I think we should get a chance to discuss the > updated version. If the meeting decide the fate of this work after > that, I would accept it. However, I have problem if AD or chairmen > simply exclude this item without such discussion and concensus > There has never been any intention to go against consensus or limit discussion on this topic. So, let's use this thread to get to the bottom of what we want to do as a group here. - Mark > Would you please clarify it to me? > > Thanks, > > -eunah > > On Thu, May 15, 2008 at 11:02 PM, Mark Townsley wrote: > >> I'd like to ask the group one final time for comments on the proposed new >> charter. I've also asked the ROLL WG chairs to comment. >> >> As I said before, soon after the format document was published, there is >> nothing stopping the WG from discussing and working on new and existing >> items at this time. In fact, activity helps us to decide what should be in >> and out of the charter. Please do not construe not having a charter in place >> as a reason not to update drafts, or discuss topics that need to be >> discussed. Just as when we have BoF's and mailing lists before creating a >> new WG, it is good to have WG meetings and on-lists discussions when >> creating new WG charters. >> >> - Mark >> >> >> >> >> >> >> Background/Introduction: >> >> Note: Given that there is not much precedent for this type of activity >> at the IETF, the text that follows is of an introductory >> nature. Hence, its objective is to give a general idea of the >> application area and motivations for the work. In particular, this >> section is not to be construed as detailing work items for the working >> group. That is done in the following section entitled "Scope of the >> Working Group." >> >> Well-established fields such as control networks, and burgeoning ones >> such as "sensor" (or transducer) networks, are increasingly being >> based on wireless technologies. Most (but certainly not all) of these >> nodes are amongst the most constrained that have ever been networked >> wirelessly. Extreme low power (such that they will run potentially for >> years on batteries) and extreme low cost (total device cost in single >> digit dollars, and riding Moore's law to continuously reduce that >> price point) are seen as essential enablers towards their deployment >> in networks with the following characteristics: >> >> * Significantly more devices than current networks >> >> * Severely limited code and ram space (e.g., highly desirable to >> fit the required code--MAC, IP and anything else needed to >> execute the embedded application-- in, for example, 32K of flash >> memory, using 8-bit microprocessors) >> >> * Unobtrusive but very different user interface for configuration >> (e.g., using gestures or interactions involving the physical >> world) >> >> * Robustness and simplicity in routing or network fabric >> >> A chief component of these devices is wireless communication >> technology. In particular, the IEEE 802.15.4 standard is very >> promising for the lower (physical and link) layers. As for higher >> layer functions, there is considerable interest from non-IETF groups >> in using IP technology (the ZigBee alliance, for example, is currently >> studying what such a work item might entail). The working group is >> expected to coordinate and interact with such groups. >> >> The required work includes items in the following (incomplete) list: >> >> * IP adaptation/Packet Formats and interoperability >> * Addressing schemes and address management >> * Network management >> * Routing in dynamically adaptive topologies >> * Security, including set-up and maintenance >> * Application programming interface >> * Discovery (of devices, of services, etc) >> * Implementation considerations >> >> Whereas at least some of the above items are within the purview of the >> IETF, at this point it is not clear that all of them are. Accordingly, >> the 6LoWPAN working group will address a reduced, more focused set of >> objectives. >> >> Scope of 6lowpan: >> >> Produce "Problems Statement, Assumptions and Goals for IPv6 for >> LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the >> problem statement and goals of 6lowpan networks. >> >> Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN >> Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the >> basic packet formats and sub-IP adaptation layer for transmission of >> IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, >> header compression and address generation. Furthermore, IEEE 802.15.4 >> devices are expected to be deployed in mesh topologies. >> >> As such, the working group may also work on an informational document >> to show how to apply an existing MANET protocol to LoWPANs (e.g., >> AODV, OLSR, DYMO, etc). >> >> The working group will reuse existing specifications whenever >> reasonable and possible. >> >> The working group will also serve as a venue for ongoing discussions >> on other topics related to the more complete list outlined above. >> Additional related milestones may be added in the future via a >> rechartering operation. >> >> Note: As may be obvious from its official name above, this particular >> working group will not work on IPv4 over IEEE 802.15.4 specifications. >> Given the limitations of the target devices, dual-stack deployments >> are not practical. Because of its higher potential for header >> compression, its support for the huge number of devices expected and >> of cleanly built-in features such as address autoconfiguration, IPv6 >> is the exclusive focus of the working group. >> Goals and Milestones: >> Done Working group last call on >> draft-ietf-lowpan-goals-assumptions-xx.txt >> Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG >> for consideration of publication as Informational >> Done Working Group Last Call on >> draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >> Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG >> for consideration of publication as Proposed Standard >> >> >> >> Background/Introduction: >> >> Note: Given that there is not much precedent for this type of activity >> at the IETF, the text that follows is of an introductory >> nature. Hence, its objective is to give a general idea of the >> application area and motivations for the work. In particular, this >> section is not to be construed as detailing work items for the working >> group. That is done in the following section entitled "Scope of the >> Working Group." >> >> Well-established fields such as control networks, and burgeoning ones >> such as "sensor" (or transducer) networks, are increasingly being >> based on wireless technologies. Most (but certainly not all) of these >> nodes are amongst the most constrained that have ever been networked >> wirelessly. Extreme low power (such that they will run potentially for >> years on batteries) and extreme low cost (total device cost in single >> digit dollars, and riding Moore's law to continuously reduce that >> price point) are seen as essential enablers towards their deployment >> in networks with the following characteristics: >> >> * Significantly more devices than current local area networks >> >> * Severely limited code and ram space (e.g., highly desirable to fit >> the required code--MAC, IP and anything else needed to execute the >> embedded application-- in, for example, 32K of flash memory, using >> 8-bit microprocessors) >> >> * Unobtrusive but very different user interface for configuration >> (e.g., using gestures or interactions involving the physical world) >> >> A chief component of these devices is wireless communication >> technology. In particular, the IEEE 802.15.4 standard is very >> promising for the lower (physical and link) layers. As for higher >> layer functions, there is considerable interest from non-IETF groups >> in using IP technology. The IEEE 1451.5 standard for wireless >> transducers has a chapter for 6LoWPAN and the ISA SP100 standard for >> wireless industrial networks has adopted 6LoWPAN for their network >> layer. This working group is expected to coordinate and interact with >> such groups. >> >> Description of Working Group: >> >> The working group has completed two RFCs: "IPv6 over Low-Power >> Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, >> Problem Statement, and Goals" (RFC4919) that documents and discusses >> the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 >> Networks" (RFC4944) which defines the format for the adaptation >> between IPv6 and 802.15.4. >> >> The Working Group will generate the necessary documents to enusre >> interoperable implementations of 6LoWPAN networks and will define the >> necessary security and management protocols and constructs for build >> 6LoWPAN networks, paying particular attention to protocols already >> available. >> >> Work Items: >> >> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" >> to define the required optimizations to make IPv6 ND applicable in >> 6lowpans, given the fact that IPv6 ND is too expensive for the devices >> of 6lowpan and requires multicast. >> >> This document (or these documents - as the working group delves into >> this topic it may determine that this should be two separate >> documents) will define how to bootstrap a 6lowpan network and explore >> ND optimizations such as reusing the 802.15.4 network structure (use >> the coordinators), and obviate multicast by having devices talk to >> coordinators without creating a single point-of-failure, and changing >> the IPv6 ND multicast semantics. This document will be a proposed >> standard. >> >> 2. Produce "Problem Statement for Stateful Header Compression in >> 6lowpans" to document the problem of using stateful header compression >> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of >> stateless header compression given the assumption that stateful header >> compression may be too complex. This document will determine if the >> assumption is correct and will be an informational document. The WG >> will determine if the assumption is correct at this time and record >> the findings in this informational document. >> >> 3. Produce "6LoWPAN Architecture" to describe the design and >> implementation of 6LoWPAN networks. This document will cover the >> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, >> network components, addressing, and IPv4/IPv6 network connections. >> >> 4. Produce "Recommendations for 6lowpan Applications" to define a set >> of recommendations of protocols to use for applications. The >> recommendations will cover protocols for transport, application layer, >> discovery, configuration and commissioning. This document will be an >> informational document. >> >> 5. Produce "6lowpan Security Analysis" to define the threat model of >> 6lowpans and to document suitability of existing key management >> schemes and to discuss bootstrapping/installation/commissioning/setup >> issues. This document will be an informational document. >> >> The working group will continue to reuse existing protocols and >> mechanisms whenever reasonable and possible. >> >> Goals and Milestones: >> >> Jan 2008 - First Draft of Bootstrapping and ND Optimization document >> Feb 2008 - First Draft of Stateful Header Compression document >> Dec 2007 - First Draft of 6LoWPAN Architecture docuement >> Feb 2008 - First Draft of Applications document >> Mar 2008 - First Draft of Security Analysis >> Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to >> be considered as Proposed Standard >> Jul 2008 - Submit Stateful Header Compression document to IESG to be >> considered as Proposed Standard >> May 2008 - Submit Architecture docuement to IESG to be considered as >> Informational RFC >> Jul 2008 - Submit Applications docuement to IESG to be considered as >> Informational RFC >> Sep 2008 - Submit Security Analysis document to IESG to be considered >> as Informational RFC. >> >> >> >> _______________________________________________ >> 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 6lowpan-bounces@ietf.org Tue May 20 20:57:33 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92523A72B5; Tue, 20 May 2008 20:57:33 -0700 (PDT) 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 7477B3A6F48 for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwJ1MzRoE2rt for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:57:27 -0700 (PDT) Received: from mail.globalsuite.net (mail.globalsuite.net [69.46.103.200]) by core3.amsl.com (Postfix) with SMTP id 723CD28CF96 for <6lowpan@ietf.org>; Tue, 20 May 2008 08:18:32 -0700 (PDT) X-AuditID: c0a8013c-a26e9bb000006e3b-11-4832ebc675ea Received: from Townsley-MacBook.local (unknown [207.134.107.2]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id C03454DC003; Tue, 20 May 2008 09:18:29 -0600 (MDT) Message-ID: <4832EBC2.8050902@cisco.com> Date: Tue, 20 May 2008 11:18:26 -0400 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFDDD3@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05AFDDD3@xmb-ams-337.emea.cisco.com> X-Brightmail-Tracker: AAAAAA== Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi again Mark > > >>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>> mesh exposes the network to congestion collapse, as described in >>> >>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > >>> overy . I think that the WG should dedicate some bandwitdth to >>> > provide > >>> additional functions that would improve the LoWPAN operation WRT flow >>> control and recovery of fragments. >>> >>> >> Fragmentation, OK, but why is flow control a network layer issue rather >> than a transport layer issue? >> > > [Pascal] I'm talking about flow control on the fragments themselves; > this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above > LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to > cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes > minimum, it causes a burst of fragments that should be paced and > windowed. I suggest we do it in 6LoWPAN and handle the consequences of > our own fragmentation rather than rely on a LLC mechanism that might not > be there or adapted. > OK, that makes sense. Of course, if the higher layer transports consider this fragmented packet lost and retransmit in the mean time we will end up thrashing. We need to be very wary of the higher-layer transport affects. And, of course this isn't the first time I've thought we might need ot spin up a transport-area lowpan WG similar to what we did with ROLL. But, sometimes its hard enough to keep 2 working groups working and making progress, much less 3. - Mark > Pascal > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 21 14:57:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FDB3A67E2; Wed, 21 May 2008 14:57:27 -0700 (PDT) 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 607503A6966 for <6lowpan@core3.amsl.com>; Wed, 21 May 2008 14:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1jyGgA-5RLp for <6lowpan@core3.amsl.com>; Wed, 21 May 2008 14:57:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E78A83A6938 for <6lowpan@ietf.org>; Wed, 21 May 2008 14:57:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,522,1204531200"; d="scan'208";a="49011455" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 21 May 2008 14:57:30 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4LLvTxU024934 for <6lowpan@ietf.org>; Wed, 21 May 2008 14:57:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4LLvTwG022645 for <6lowpan@ietf.org>; Wed, 21 May 2008 21:57:29 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 May 2008 14:57:29 -0700 Received: from Townsley-MacBook.local ([10.21.146.228]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 May 2008 14:57:28 -0700 Message-ID: <48349AC5.5000907@cisco.com> Date: Wed, 21 May 2008 17:57:25 -0400 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD9C1@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05AFD9C1@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 21 May 2008 21:57:29.0294 (UTC) FILETIME=[A9C286E0:01C8BB8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4561; t=1211407049; x=1212271049; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=PObUVA20nGUri+grByFqqy+IBLCKex5Y8nngZDXFftk=; b=lyhsoSEY5FlAjnEtfkPGdpAIVD15gb+hxzjkcVLei98kJMIU5NBWQeJHLl TBkis/eFJWzlKmnJnDBl1gOKTplK0ASOal672U01L5sPOk7J1at36Fz3aMWN GrJXhAo3AS; Authentication-Results: sj-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Mark; > > I'd say the other way around. We need to figure out whether the ISA100 > concept of a backbone is a more generic one and if we agree that such a > backbone federates multiple LoWPANs as a single larger link. > Let me see if I understand, are you saying this is for a lowpan not based on 802.15.4? - Mark > If we agree on that then we need to design ND for that larger link. > That's when the concept of a registration protocol over the LowPAN > associated to proxy ND on the backbone comes into mind. > > This model should work whether the host on the LoWPAN gets its addresses > from ND autoconf, DHCP or whatever new registration protocol that might > come up to fill the gap between the two. In particular, this can impact > the design of ND on the LowPAN and incline for a solution based on white > board. > > This is why I feel it's important to discuss that now. > > Pascal > >> -----Original Message----- >> From: Mark Townsley (townsley) >> Sent: vendredi 16 mai 2008 20:47 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> Pascal Thubert (pthubert) wrote: >> >>> Hi Mark: >>> >>> I think we need a work item (usually implicit) around the concept of >>> improving existing WG RFCs. RFC 4944 can be improved in several >>> > aspects: > >>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a to >>> conform to 6LoWPAN would be a major win, but is certainly not a >>> > given. > >>> At the moment, the ISA100.11a documents expose discrepencies with RFC >>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve >>> for the most part. >>> >>> >> Are the resolutions backwards compatible with RFC 4944? I'm eager to >> improve RFC 4944, but not eager to endorse changes that inhibit >> interoperability. >> >>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>> mesh exposes the network to congestion collapse, as described in >>> >>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > >>> overy . I think that the WG should dedicate some bandwitdth to >>> > provide > >>> additional functions that would improve the LoWPAN operation WRT flow >>> control and recovery of fragments. >>> >>> >> Fragmentation, OK, but why is flow control a network layer issue rather >> than a transport layer issue? >> >>> Another aspect of ISA100.11a is the concept of a backbone router. It >>> would be appropriate that the IETF comes up with a proposal to >>> > implement > >>> the concept in the IPv6 world. This partially falls under the first >>> > work > >>> item on ND but might also include ND proxy over the backbone which is >>> > a > >>> stretch to the work item. More in >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. >>> >>> >> Well, don't we need to define what ND looks like on a lowpan before we >> decide whether it needs to be proxied or not? >> >> - Mark >> >>> What do you think? >>> >>> Pascal >>> >>> >>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> >>>> >>> Behalf Of Mark Townsley >>> >>> >>>> (townsley) >>>> Sent: jeudi 15 mai 2008 23:02 >>>> To: 6lowpan@ietf.org >>>> Subject: [6lowpan] New charter for 6lowpan >>>> >>>> >>>> I'd like to ask the group one final time for comments on the >>>> > proposed > >>>> new charter. I've also asked the ROLL WG chairs to comment. >>>> >>>> As I said before, soon after the format document was published, >>>> > there > >>> is >>> >>> >>>> nothing stopping the WG from discussing and working on new and >>>> > existing > >>>> items at this time. In fact, activity helps us to decide what should >>>> > be > >>>> in and out of the charter. Please do not construe not having a >>>> > charter > >>>> in place as a reason not to update drafts, or discuss topics that >>>> > need > >>>> to be discussed. Just as when we have BoF's and mailing lists before >>>> creating a new WG, it is good to have WG meetings and on-lists >>>> discussions when creating new WG charters. >>>> >>>> - Mark >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 21 15:19:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2993A6902; Wed, 21 May 2008 15:19:55 -0700 (PDT) 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 6EDBD3A68B4 for <6lowpan@core3.amsl.com>; Wed, 21 May 2008 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5OsCp5W1X6p for <6lowpan@core3.amsl.com>; Wed, 21 May 2008 15:19:53 -0700 (PDT) Received: from mail.sf.archrock.com (unknown [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 3CC773A6902 for <6lowpan@ietf.org>; Wed, 21 May 2008 15:19:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 59549A92FB; Wed, 21 May 2008 15:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjqPBFKFbr-y; Wed, 21 May 2008 15:19:52 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id D20ACA92F5; Wed, 21 May 2008 15:19:51 -0700 (PDT) Message-Id: <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> From: Jonathan Hui To: Mark Townsley In-Reply-To: <4832ED46.1070304@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 21 May 2008 15:19:51 -0700 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark: On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >> - To your point on ND, this is precisely why the architecture draft >> is so important. We haven't given it as much attention lately, but >> it will help resolve the question your raise and many other >> questions in the future. For example, the architecture draft >> identifies two modes of operation: mesh-under and route-over. Both >> of which may require different ND mechanisms. This doesn't apply to >> just ND, but may apply questions of fragmentation, header >> compression, security, etc. > I worry about the under/over debate. It seems that with all the > effort and enthusiasm in ROLL, we might be well-served at the moment > by focusing on helping them be successful with route-over than > spending too much of our time on route-under. I worry too, especially since it will pull the WG in different directions. I'm with you on the preference for route-over, but others in this group feel strongly about mesh-under as well, especially since ISA100.11a seems to have adopted a mesh-under approach. I've personally been focused on developing route-over solutions while being conscious of supporting mesh-under when possible (evident with 6lowpan- hc). However, things will start to diverge when we start to talk about bootstrapping, ND, etc. So we should make a conscious decision of whether we're supporting one or both. -- Jonathan Hui > >> >> - I hesitate a bit that we suggest possible solutions to ND in the >> charter ("reusing the 802.15.4 network structure (use the >> coordinators)") especially since the definition of such link >> mechanisms are still in motion within the IEEE. It seems more >> productive to me if we can develop mechanisms that are less >> dependent on the specific structure of 802.15.4 mechanisms. > I agree that we should develop mechanisms that could work > generically whenever possible. > > - Mark >> >> Rest of the charter looks good to me. >> >> Thanks. >> >> -- >> Jonathan Hui >> >> >> >> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Mark: >>>> >>>> I think we need a work item (usually implicit) around the concept >>>> of >>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>> aspects: >>>> >>> >>>> >>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>> to >>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>> given. >>>> At the moment, the ISA100.11a documents expose discrepencies with >>>> RFC >>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>> resolve >>>> for the most part. >>>> >>> Are the resolutions backwards compatible with RFC 4944? I'm eager to >>> improve RFC 4944, but not eager to endorse changes that inhibit >>> interoperability. >>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>> radio >>>> mesh exposes the network to congestion collapse, as described in >>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>> overy . I think that the WG should dedicate some bandwitdth to >>>> provide >>>> additional functions that would improve the LoWPAN operation WRT >>>> flow >>>> control and recovery of fragments. >>>> >>> Fragmentation, OK, but why is flow control a network layer issue >>> rather >>> than a transport layer issue? >>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>> It >>>> would be appropriate that the IETF comes up with a proposal to >>>> implement >>>> the concept in the IPv6 world. This partially falls under the >>>> first work >>>> item on ND but might also include ND proxy over the backbone >>>> which is a >>>> stretch to the work item. More in >>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>> . >>>> >>> Well, don't we need to define what ND looks like on a lowpan >>> before we >>> decide whether it needs to be proxied or not? >>> >>> - Mark >>>> What do you think? >>>> >>>> Pascal >>>> >>>> >>>>> -----Original Message----- >>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>> On >>>>> >>>> Behalf Of Mark Townsley >>>> >>>>> (townsley) >>>>> Sent: jeudi 15 mai 2008 23:02 >>>>> To: 6lowpan@ietf.org >>>>> Subject: [6lowpan] New charter for 6lowpan >>>>> >>>>> >>>>> I'd like to ask the group one final time for comments on the >>>>> proposed >>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>> >>>>> As I said before, soon after the format document was published, >>>>> there >>>>> >>>> is >>>> >>>>> nothing stopping the WG from discussing and working on new and >>>>> existing >>>>> items at this time. In fact, activity helps us to decide what >>>>> should be >>>>> in and out of the charter. Please do not construe not having a >>>>> charter >>>>> in place as a reason not to update drafts, or discuss topics >>>>> that need >>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>> before >>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>> discussions when creating new WG charters. >>>>> >>>>> - Mark >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 6lowpan-bounces@ietf.org Thu May 22 00:06:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9B7E3A6AB9; Thu, 22 May 2008 00:06:50 -0700 (PDT) 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 AA25E3A68EA for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 00:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koWLjz8sH0Lo for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 00:06:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7EBFD28C138 for <6lowpan@ietf.org>; Thu, 22 May 2008 00:05:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,524,1204498800"; d="scan'208";a="9586111" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 May 2008 09:05:56 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4M75uWO003864 for <6lowpan@ietf.org>; Thu, 22 May 2008 09:05:56 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4M75ul9006920 for <6lowpan@ietf.org>; Thu, 22 May 2008 07:05:56 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 09:05:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 May 2008 09:05:22 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B60FEF@xmb-ams-337.emea.cisco.com> In-Reply-To: <48349AC5.5000907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci7jbC8D4e4lNnaQVSnXGtK/nZG1wAS98uA References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD9C1@xmb-ams-337.emea.cisco.com> <48349AC5.5000907@cisco.com> From: "Pascal Thubert (pthubert)" To: "Mark Townsley (townsley)" X-OriginalArrivalTime: 22 May 2008 07:05:56.0066 (UTC) FILETIME=[47B97420:01C8BBDA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5163; t=1211439956; x=1212303956; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=fiGpH0Qfm7JwlGVJaJSPuOdMNJLmVsFiv3jtpUCsrcg=; b=EOGBcZo0PaCzOM4oJejiBmDlAKLfvAeePJv2n7eIo49ZLRNgbvaSUN4Ahg IqxrxlMZ8suqv36kVzlOV174zLAIjIFpCWdHQftYY4OnNOA7HWWZPFIor9nD DIADGWZYva; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark: I'm saying that if we agree that the need for a high speed backbone is not limited to ISA100 then it makes sense to specify it in 6LoWPAN. At the moment, the LowPAN is 802.15.4 but the backbone is anything, though Ethernet is a foremost candidate. Still I do hope that what we design can easily be applied to other LoWPANs (LP WIFI, 802.15.4a, ISA100 DLL) but that is not what I was discussing here. Sorry for the confusion. Pascal >-----Original Message----- >From: Mark Townsley (townsley) >Sent: mercredi 21 mai 2008 23:57 >To: Pascal Thubert (pthubert) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > >Pascal Thubert (pthubert) wrote: >> Hi Mark; >> >> I'd say the other way around. We need to figure out whether the ISA100 >> concept of a backbone is a more generic one and if we agree that such a >> backbone federates multiple LoWPANs as a single larger link. >> >Let me see if I understand, are you saying this is for a lowpan not >based on 802.15.4? > >- Mark >> If we agree on that then we need to design ND for that larger link. >> That's when the concept of a registration protocol over the LowPAN >> associated to proxy ND on the backbone comes into mind. >> >> This model should work whether the host on the LoWPAN gets its addresses >> from ND autoconf, DHCP or whatever new registration protocol that might >> come up to fill the gap between the two. In particular, this can impact >> the design of ND on the LowPAN and incline for a solution based on white >> board. >> >> This is why I feel it's important to discuss that now. >> >> Pascal >> >>> -----Original Message----- >>> From: Mark Townsley (townsley) >>> Sent: vendredi 16 mai 2008 20:47 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> Pascal Thubert (pthubert) wrote: >>> >>>> Hi Mark: >>>> >>>> I think we need a work item (usually implicit) around the concept of >>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>> >> aspects: >> >>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a to >>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>> >> given. >> >>>> At the moment, the ISA100.11a documents expose discrepencies with RFC >>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve >>>> for the most part. >>>> >>>> >>> Are the resolutions backwards compatible with RFC 4944? I'm eager to >>> improve RFC 4944, but not eager to endorse changes that inhibit >>> interoperability. >>> >>>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>>> mesh exposes the network to congestion collapse, as described in >>>> >>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> >>>> overy . I think that the WG should dedicate some bandwitdth to >>>> >> provide >> >>>> additional functions that would improve the LoWPAN operation WRT flow >>>> control and recovery of fragments. >>>> >>>> >>> Fragmentation, OK, but why is flow control a network layer issue rather >>> than a transport layer issue? >>> >>>> Another aspect of ISA100.11a is the concept of a backbone router. It >>>> would be appropriate that the IETF comes up with a proposal to >>>> >> implement >> >>>> the concept in the IPv6 world. This partially falls under the first >>>> >> work >> >>>> item on ND but might also include ND proxy over the backbone which is >>>> >> a >> >>>> stretch to the work item. More in >>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. >>>> >>>> >>> Well, don't we need to define what ND looks like on a lowpan before we >>> decide whether it needs to be proxied or not? >>> >>> - Mark >>> >>>> What do you think? >>>> >>>> Pascal >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>>> >>>>> >>>> Behalf Of Mark Townsley >>>> >>>> >>>>> (townsley) >>>>> Sent: jeudi 15 mai 2008 23:02 >>>>> To: 6lowpan@ietf.org >>>>> Subject: [6lowpan] New charter for 6lowpan >>>>> >>>>> >>>>> I'd like to ask the group one final time for comments on the >>>>> >> proposed >> >>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>> >>>>> As I said before, soon after the format document was published, >>>>> >> there >> >>>> is >>>> >>>> >>>>> nothing stopping the WG from discussing and working on new and >>>>> >> existing >> >>>>> items at this time. In fact, activity helps us to decide what should >>>>> >> be >> >>>>> in and out of the charter. Please do not construe not having a >>>>> >> charter >> >>>>> in place as a reason not to update drafts, or discuss topics that >>>>> >> need >> >>>>> to be discussed. Just as when we have BoF's and mailing lists before >>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>> discussions when creating new WG charters. >>>>> >>>>> - Mark >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >> >> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 22 00:48:12 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628B128C129; Thu, 22 May 2008 00:48:12 -0700 (PDT) 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 3EA8C3A69F4; Thu, 22 May 2008 00:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.979 X-Spam-Level: X-Spam-Status: No, score=-6.979 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFfhIoy2NG0q; Thu, 22 May 2008 00:48:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 4DD6B3A6A5A; Thu, 22 May 2008 00:48:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,524,1204498800"; d="scan'208";a="9590612" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 May 2008 09:48:08 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4M7m800016083; Thu, 22 May 2008 09:48:08 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4M7m82n022852; Thu, 22 May 2008 07:48:08 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 09:48:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 May 2008 09:47:34 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> In-Reply-To: <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) Thread-Index: Aci7kNbmHT5GGQ+2TY2at3c8aAYrNQASYm6A References: <482CA4DC.40508@cisco.com><7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com><482DD69F.7080304@cisco.com><208D4602-AE7F-457E-9377-962968881CDE@archrock.com><4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 22 May 2008 07:48:08.0356 (UTC) FILETIME=[2D163E40:01C8BBE0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8542; t=1211442488; x=1212306488; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20ISA100.11a=20=20status=20and=20requirements=20( was=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowpan) |Sender:=20; bh=OytlN4Ai8tRteqoM335ysDVg5t0Sn/McD6Ga9h/1tLI=; b=ojIMJOqErIL5v6zm2LVDxc4fXusNCr1+vDkZjnIVVBCbfOrctMEkwoFiKz q/PF+8JdgYR2uwFWcOGWVd33WRtHvdnTHmy2Mu7RQeE60HQUaqvMPBuWq3qF GVWP4DueEA; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi: My understanding is that defining how mesh-under computes its routes is out of scope for the IETF overall. I'm not even sure we need to document requirements in that space. It's good that we push some requirements to ROLL on route-over, and that's certainly the right time to do so. To Jonathan: I do not completely agree that ISA100 is mesh under. The routing is not specified and left to the system manager implementation. My personal hope is to promote a ROLL solution in ISA100.11a next release. See http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . So the current release of ISA100.11a is at the same level as 6LoWPAN on the matter of routing. In a same fashion, ISA does not define the backbone operation, the fragment recovery mechanism or the Explicit Congestion Notification. For all those features, there's a hope at ISA that the IETF will come up with more generic solutions that they can apply. But time is running out. 6LoWPAN hasn't produced anything for the last 6 months. At this rate, ISA will have to define everything on its own and hopefully publish an informational to this group. At the moment, the first draft of ISA100.11a is in letter ballot. The current draft mostly applies 6loWPAN formats over ISA100.11a DLL, which is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN so ISA is using NaLP headers starting with b'00'. What ISA needs from 6LoWPAN in very short term is in that order: - promote Jonathan's draft as a convergence specification so ISA can at least use standard HC headers. This enables: non-Link-Local-Address compression Hops limit compression UDP checksum compression Better placement of HC2 Which are all mandatory for ISA100.11a - better define the NaLPs. There should be a way to indicate to a 6LoWPAN node whether a NaLP can be skipped and what its length is. - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes to report congestion. - specify a fragment flow control and recovery protocol at the 6LoWPAN Shim layer There is no rocket science in any of this and it all could/should be carried out swiftly. What ISA needs in longer term: - define backbone operation when the backbone federates multiple LoWPANs into a single link (or subnet, TBD). This is more theoretical work for us. Related to proxy ND, a new registration protocols, multilink subnet, etc... Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: jeudi 22 mai 2008 00:20 >To: Mark Townsley (townsley) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > > >Hi Mark: > >On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>> - To your point on ND, this is precisely why the architecture draft >>> is so important. We haven't given it as much attention lately, but >>> it will help resolve the question your raise and many other >>> questions in the future. For example, the architecture draft >>> identifies two modes of operation: mesh-under and route-over. Both >>> of which may require different ND mechanisms. This doesn't apply to >>> just ND, but may apply questions of fragmentation, header >>> compression, security, etc. >> I worry about the under/over debate. It seems that with all the >> effort and enthusiasm in ROLL, we might be well-served at the moment >> by focusing on helping them be successful with route-over than >> spending too much of our time on route-under. > >I worry too, especially since it will pull the WG in different >directions. I'm with you on the preference for route-over, but others >in this group feel strongly about mesh-under as well, especially since >ISA100.11a seems to have adopted a mesh-under approach. I've >personally been focused on developing route-over solutions while being >conscious of supporting mesh-under when possible (evident with 6lowpan- >hc). However, things will start to diverge when we start to talk about >bootstrapping, ND, etc. So we should make a conscious decision of >whether we're supporting one or both. > >-- >Jonathan Hui > >> >>> >>> - I hesitate a bit that we suggest possible solutions to ND in the >>> charter ("reusing the 802.15.4 network structure (use the >>> coordinators)") especially since the definition of such link >>> mechanisms are still in motion within the IEEE. It seems more >>> productive to me if we can develop mechanisms that are less >>> dependent on the specific structure of 802.15.4 mechanisms. >> I agree that we should develop mechanisms that could work >> generically whenever possible. >> >> - Mark >>> >>> Rest of the charter looks good to me. >>> >>> Thanks. >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Mark: >>>>> >>>>> I think we need a work item (usually implicit) around the concept >>>>> of >>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>> aspects: >>>>> >>>> >>>>> >>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>> to >>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>> given. >>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>> RFC >>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>> resolve >>>>> for the most part. >>>>> >>>> Are the resolutions backwards compatible with RFC 4944? I'm eager to >>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>> interoperability. >>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>> radio >>>>> mesh exposes the network to congestion collapse, as described in >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>> provide >>>>> additional functions that would improve the LoWPAN operation WRT >>>>> flow >>>>> control and recovery of fragments. >>>>> >>>> Fragmentation, OK, but why is flow control a network layer issue >>>> rather >>>> than a transport layer issue? >>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>> It >>>>> would be appropriate that the IETF comes up with a proposal to >>>>> implement >>>>> the concept in the IPv6 world. This partially falls under the >>>>> first work >>>>> item on ND but might also include ND proxy over the backbone >>>>> which is a >>>>> stretch to the work item. More in >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>> . >>>>> >>>> Well, don't we need to define what ND looks like on a lowpan >>>> before we >>>> decide whether it needs to be proxied or not? >>>> >>>> - Mark >>>>> What do you think? >>>>> >>>>> Pascal >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>> On >>>>>> >>>>> Behalf Of Mark Townsley >>>>> >>>>>> (townsley) >>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>> To: 6lowpan@ietf.org >>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>> >>>>>> >>>>>> I'd like to ask the group one final time for comments on the >>>>>> proposed >>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>> >>>>>> As I said before, soon after the format document was published, >>>>>> there >>>>>> >>>>> is >>>>> >>>>>> nothing stopping the WG from discussing and working on new and >>>>>> existing >>>>>> items at this time. In fact, activity helps us to decide what >>>>>> should be >>>>>> in and out of the charter. Please do not construe not having a >>>>>> charter >>>>>> in place as a reason not to update drafts, or discuss topics >>>>>> that need >>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>> before >>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>> discussions when creating new WG charters. >>>>>> >>>>>> - Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 6lowpan-bounces@ietf.org Thu May 22 09:14:42 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959C228C13A; Thu, 22 May 2008 09:14:42 -0700 (PDT) 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 AE3833A68B2; Thu, 22 May 2008 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USUbAgg6XfI6; Thu, 22 May 2008 09:14:23 -0700 (PDT) Received: from mail.sf.archrock.com (unknown [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 6C37528C158; Thu, 22 May 2008 09:14:17 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id DC225A935E; Thu, 22 May 2008 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZRnP00t8rZA; Thu, 22 May 2008 09:14:09 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id AAFBBA921E; Thu, 22 May 2008 09:14:09 -0700 (PDT) Message-Id: <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 22 May 2008 09:14:06 -0700 References: <482CA4DC.40508@cisco.com><7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com><482DD69F.7080304@cisco.com><208D4602-AE7F-457E-9377-962968881CDE@archrock.com><4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org, "Polyzois, Christos A" Subject: Re: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, So let's drop the mesh-under/route-over terminology for a second, I think they are confusing since everyone seems to have a different definition for those terms. What I am mainly concerned about is the kind of IP Link abstraction 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. 802.15.4 and possible others through a BbR), what I've been calling mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the radio range of 802.15.4), what I've been calling route-over. My point to Mark's concern was that solutions to some work items within 6LoWPAN will be different depending on our IP Link abstraction. From what I understand, ISA100.11a has chosen option (i). But to your point below, using IP routing to provide connectivity between nodes within the same IP Link doesn't seem right to me, so it'd be great if you could help me see a path to get there. A lot of this confusion can be cleaned up within the 6LoWPAN architecture document. But I think Mark's concern still stands: whether or not we're focused on one or both of these IP Link abstractions. -- Jonathan Hui On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: > Hi: > > My understanding is that defining how mesh-under computes its routes > is > out of scope for the IETF overall. I'm not even sure we need to > document > requirements in that space. It's good that we push some requirements > to > ROLL on route-over, and that's certainly the right time to do so. > > To Jonathan: I do not completely agree that ISA100 is mesh under. The > routing is not specified and left to the system manager > implementation. > My personal hope is to promote a ROLL solution in ISA100.11a next > release. See > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > > So the current release of ISA100.11a is at the same level as 6LoWPAN > on > the matter of routing. > > In a same fashion, ISA does not define the backbone operation, the > fragment recovery mechanism or the Explicit Congestion Notification. > For > all those features, there's a hope at ISA that the IETF will come up > with more generic solutions that they can apply. But time is running > out. > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > ISA will have to define everything on its own and hopefully publish an > informational to this group. > > At the moment, the first draft of ISA100.11a is in letter ballot. The > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, > which > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > so ISA is using NaLP headers starting with b'00'. > > What ISA needs from 6LoWPAN in very short term is in that order: > - promote Jonathan's draft as a convergence specification so ISA can > at > least use standard HC headers. > This enables: non-Link-Local-Address compression > Hops limit compression > UDP checksum compression > Better placement of HC2 > Which are all mandatory for ISA100.11a > - better define the NaLPs. > There should be a way to indicate to a 6LoWPAN node whether a NaLP > can > be skipped and what its length is. > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > to report congestion. > - specify a fragment flow control and recovery protocol at the 6LoWPAN > Shim layer > There is no rocket science in any of this and it all could/should be > carried out swiftly. > > What ISA needs in longer term: > - define backbone operation when the backbone federates multiple > LoWPANs > into a single link (or subnet, TBD). > This is more theoretical work for us. Related to proxy ND, a new > registration protocols, multilink subnet, etc... > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: jeudi 22 mai 2008 00:20 >> To: Mark Townsley (townsley) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> >> Hi Mark: >> >> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>> - To your point on ND, this is precisely why the architecture draft >>>> is so important. We haven't given it as much attention lately, but >>>> it will help resolve the question your raise and many other >>>> questions in the future. For example, the architecture draft >>>> identifies two modes of operation: mesh-under and route-over. Both >>>> of which may require different ND mechanisms. This doesn't apply to >>>> just ND, but may apply questions of fragmentation, header >>>> compression, security, etc. >>> I worry about the under/over debate. It seems that with all the >>> effort and enthusiasm in ROLL, we might be well-served at the moment >>> by focusing on helping them be successful with route-over than >>> spending too much of our time on route-under. >> >> I worry too, especially since it will pull the WG in different >> directions. I'm with you on the preference for route-over, but others >> in this group feel strongly about mesh-under as well, especially >> since >> ISA100.11a seems to have adopted a mesh-under approach. I've >> personally been focused on developing route-over solutions while >> being >> conscious of supporting mesh-under when possible (evident with >> 6lowpan- >> hc). However, things will start to diverge when we start to talk >> about >> bootstrapping, ND, etc. So we should make a conscious decision of >> whether we're supporting one or both. >> >> -- >> Jonathan Hui >> >>> >>>> >>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>> charter ("reusing the 802.15.4 network structure (use the >>>> coordinators)") especially since the definition of such link >>>> mechanisms are still in motion within the IEEE. It seems more >>>> productive to me if we can develop mechanisms that are less >>>> dependent on the specific structure of 802.15.4 mechanisms. >>> I agree that we should develop mechanisms that could work >>> generically whenever possible. >>> >>> - Mark >>>> >>>> Rest of the charter looks good to me. >>>> >>>> Thanks. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi Mark: >>>>>> >>>>>> I think we need a work item (usually implicit) around the concept >>>>>> of >>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>> aspects: >>>>>> >>>>> >>>>>> >>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>> to >>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>> given. >>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>> RFC >>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>> resolve >>>>>> for the most part. >>>>>> >>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > to >>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>> interoperability. >>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>> radio >>>>>> mesh exposes the network to congestion collapse, as described in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>> provide >>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>> flow >>>>>> control and recovery of fragments. >>>>>> >>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>> rather >>>>> than a transport layer issue? >>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>> It >>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>> implement >>>>>> the concept in the IPv6 world. This partially falls under the >>>>>> first work >>>>>> item on ND but might also include ND proxy over the backbone >>>>>> which is a >>>>>> stretch to the work item. More in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>> . >>>>>> >>>>> Well, don't we need to define what ND looks like on a lowpan >>>>> before we >>>>> decide whether it needs to be proxied or not? >>>>> >>>>> - Mark >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>> On >>>>>>> >>>>>> Behalf Of Mark Townsley >>>>>> >>>>>>> (townsley) >>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>> To: 6lowpan@ietf.org >>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>> >>>>>>> >>>>>>> I'd like to ask the group one final time for comments on the >>>>>>> proposed >>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>> >>>>>>> As I said before, soon after the format document was published, >>>>>>> there >>>>>>> >>>>>> is >>>>>> >>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>> existing >>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>> should be >>>>>>> in and out of the charter. Please do not construe not having a >>>>>>> charter >>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>> that need >>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>> before >>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>> discussions when creating new WG charters. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 6lowpan-bounces@ietf.org Thu May 22 16:29:11 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80D313A6AFF; Thu, 22 May 2008 16:29:11 -0700 (PDT) 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 CC2853A6968; Thu, 22 May 2008 16:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAq81WTnZLvj; Thu, 22 May 2008 16:29:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 638A23A6807; Thu, 22 May 2008 16:29:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9070060" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2008 19:29:07 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNT7BI025155; Thu, 22 May 2008 19:29:07 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNT744016366; Thu, 22 May 2008 23:29:07 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:07 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:07 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 08:07:16 -0400 From: JP Vasseur To: "David E. Culler" , Mark Townsley Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci8HYWBI63i0eSCHUCAHP2V00SofA== In-Reply-To: <4833379D.7070904@eecs.berkeley.edu> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:07.0809 (UTC) FILETIME=[A18B1510:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17613; t=1211498947; x=1212362947; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20=22David=20E.=20Culler=22=20,=0A=20=20=20=20=20=20=20=20Mark=20Townsley=20; bh=F3Gi2cmaJO/h2aqF1aXOCNYxmLpwCTUjlu3e6CwOgow=; b=b1FblCaQMZmjLMbfdCWi74xS4LivNc+zGWfCOlrDDc27PrDquFgxk6/+rZ NZ9Eef3RcT4JpS7zLH40cs+p/yNVPZhblcc5Rk9FKDlqZ++yT3xxN18Gk2Tp BvcZwKmbQq; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org, roll-chairs@tools.ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, On 5/20/08 1:42 PM, "David E. Culler" wrote: > Here's my take from ROLL. JP may want to weigh in. For sure, mesh under is clearly out of the scope of ROLL. That said, if there are specifics issues that must be addressed (for example) to take into account 15.4 link specific characteristic they can be addressed as part of the "routing link and node metric" ROLL WG item. By the way I thought that the authors had mentioned to respin their document to focus on 15.4 specific specific aspects. With no ROLL co-chair hat ... my technical comment here is that I would HIGHY want to stress the issue of trying to combine routing decisions at multiple layers. We now have almost two decades of experience and almost (if not all attempt in that direction) have *failed*, leading to complex *and* poorly efficient routing decision: lack of end to end routing consistency, multi-layer recovery issue (timer-based bottom-up approach is usually quite ineffective), ... Further, I would say that there are IMO further higher priorities for 6lowpan. Thanks. JP. > > ROLL has a series of routing requirements documents. We'd like 6LoWPAN > to review, comment, and potentially contribute to those. I think that > it makes sense to continue to run them through ROLL. They are to be > used to guide the analysis of existing routing protocols. I6LoWPAN > might want to use them to guide 6LoWPAN efforts as well. > > ROLL is looking at routing (L3) over low-power and lossy links - > including but not limited to 802.15.4. It is not looking at mesh-under > (L2) forwarding, which the 6LoWPAN adaptation layer provides some > support for. The "requirements" documents in 6LoWPAN so far have been > of a very general observational nature. Perhaps those will become more > focused on the issues most germane to 6LoWPAN. If there is to be more > work on L2 meshing, 6LoWPAN would likely be the only home for it in > IETF. There has been lots of discussion about providing the equivalents > of ICMPv6 and IPv6 hop-by-hop options for mesh under, but it's not clear > if that is on the table. It certainly is not within ROLL. > > A key place of cooperation seems like the ND, Autoconf, ICMPv6 aspects. > For example, how will router advertisements be utilized? To date, much > of the 6LoWPAN ND and bootsrapping discussion has been from 802.15.4 MAC > concepts-up (eg. PAN coordinator) rather than IP down (e.g., DHCPv6). > Being in the internet area, 6LoWPAN is well positioned to lead efforts > that cut across areas. > > D > > > > Mark Townsley wrote: >> Eunsook "Eunah" Kim wrote: >>> Dear AD, and chairmen, >>> >>> It's good to finally see official rechater text. >>> >> It's only proposed text. >>> I think it's pretty well delivering our discussion of rechartering so >>> far, EXCEPT one part; 6lowpan routing requirement. >>> Last meeting (71th IETF), we discussed RR matter and agreed to see >>> IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember >>> correctly, we would keep this work with alignment with ROLL, as long >>> as it's not duplicate work with ROLL. >>> >> You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what >> are your expectations from 6lowpan with respect to the >> routing-requirements document? >> >> http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt >> >> I have some more questions for you specifically: >> >> Should that be pulled into roll, or left in 6lowpan? Is roll >> considering the L2"route-under" model at all? Is there anything that >> the L3 "route-over" model might not provide that is listed as a >> requirement for 6lowpan's "route-under" model? If 6lowpan were to work >> on an L2 "route-under" model, would there be constructs (e.g., the >> routing protocol itself and any low-power modifications) from ROLL >> that we would invariably want to try and reuse? >>> I would like to know if it is implied that the RR work is included in >>> Architecture work, OR, if you have *intentionally* excluded the work. >>> If the first case, I would suggest 6LoWPANers check the updated >>> version (-05) of draft. We updated our RR draft (-05) after the >>> meeting based on the meeting discussion, and circulated to the mailing >>> list. >>> >>> If the second case, I think we should get a chance to discuss the >>> updated version. If the meeting decide the fate of this work after >>> that, I would accept it. However, I have problem if AD or chairmen >>> simply exclude this item without such discussion and concensus >>> >> There has never been any intention to go against consensus or limit >> discussion on this topic. So, let's use this thread to get to the >> bottom of what we want to do as a group here. >> >> - Mark >>> Would you please clarify it to me? >>> >>> Thanks, >>> >>> -eunah >>> >>> On Thu, May 15, 2008 at 11:02 PM, Mark Townsley >>> wrote: >>> >>>> I'd like to ask the group one final time for comments on the >>>> proposed new >>>> charter. I've also asked the ROLL WG chairs to comment. >>>> >>>> As I said before, soon after the format document was published, >>>> there is >>>> nothing stopping the WG from discussing and working on new and existing >>>> items at this time. In fact, activity helps us to decide what should >>>> be in >>>> and out of the charter. Please do not construe not having a charter >>>> in place >>>> as a reason not to update drafts, or discuss topics that need to be >>>> discussed. Just as when we have BoF's and mailing lists before >>>> creating a >>>> new WG, it is good to have WG meetings and on-lists discussions when >>>> creating new WG charters. >>>> >>>> - Mark >>>> >>>> >>>> >>>> >>>> >>>> >>>> Background/Introduction: >>>> >>>> Note: Given that there is not much precedent for this type of activity >>>> at the IETF, the text that follows is of an introductory >>>> nature. Hence, its objective is to give a general idea of the >>>> application area and motivations for the work. In particular, this >>>> section is not to be construed as detailing work items for the working >>>> group. That is done in the following section entitled "Scope of the >>>> Working Group." >>>> >>>> Well-established fields such as control networks, and burgeoning ones >>>> such as "sensor" (or transducer) networks, are increasingly being >>>> based on wireless technologies. Most (but certainly not all) of these >>>> nodes are amongst the most constrained that have ever been networked >>>> wirelessly. Extreme low power (such that they will run potentially for >>>> years on batteries) and extreme low cost (total device cost in single >>>> digit dollars, and riding Moore's law to continuously reduce that >>>> price point) are seen as essential enablers towards their deployment >>>> in networks with the following characteristics: >>>> >>>> * Significantly more devices than current networks >>>> >>>> * Severely limited code and ram space (e.g., highly desirable to >>>> fit the required code--MAC, IP and anything else needed to >>>> execute the embedded application-- in, for example, 32K of flash >>>> memory, using 8-bit microprocessors) >>>> >>>> * Unobtrusive but very different user interface for configuration >>>> (e.g., using gestures or interactions involving the physical >>>> world) >>>> >>>> * Robustness and simplicity in routing or network fabric >>>> >>>> A chief component of these devices is wireless communication >>>> technology. In particular, the IEEE 802.15.4 standard is very >>>> promising for the lower (physical and link) layers. As for higher >>>> layer functions, there is considerable interest from non-IETF groups >>>> in using IP technology (the ZigBee alliance, for example, is currently >>>> studying what such a work item might entail). The working group is >>>> expected to coordinate and interact with such groups. >>>> >>>> The required work includes items in the following (incomplete) list: >>>> >>>> * IP adaptation/Packet Formats and interoperability >>>> * Addressing schemes and address management >>>> * Network management >>>> * Routing in dynamically adaptive topologies >>>> * Security, including set-up and maintenance >>>> * Application programming interface >>>> * Discovery (of devices, of services, etc) >>>> * Implementation considerations >>>> >>>> Whereas at least some of the above items are within the purview of the >>>> IETF, at this point it is not clear that all of them are. Accordingly, >>>> the 6LoWPAN working group will address a reduced, more focused set of >>>> objectives. >>>> >>>> Scope of 6lowpan: >>>> >>>> Produce "Problems Statement, Assumptions and Goals for IPv6 for >>>> LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the >>>> problem statement and goals of 6lowpan networks. >>>> >>>> Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN >>>> Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the >>>> basic packet formats and sub-IP adaptation layer for transmission of >>>> IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, >>>> header compression and address generation. Furthermore, IEEE 802.15.4 >>>> devices are expected to be deployed in mesh topologies. >>>> >>>> As such, the working group may also work on an informational document >>>> to show how to apply an existing MANET protocol to LoWPANs (e.g., >>>> AODV, OLSR, DYMO, etc). >>>> >>>> The working group will reuse existing specifications whenever >>>> reasonable and possible. >>>> >>>> The working group will also serve as a venue for ongoing discussions >>>> on other topics related to the more complete list outlined above. >>>> Additional related milestones may be added in the future via a >>>> rechartering operation. >>>> >>>> Note: As may be obvious from its official name above, this particular >>>> working group will not work on IPv4 over IEEE 802.15.4 specifications. >>>> Given the limitations of the target devices, dual-stack deployments >>>> are not practical. Because of its higher potential for header >>>> compression, its support for the huge number of devices expected and >>>> of cleanly built-in features such as address autoconfiguration, IPv6 >>>> is the exclusive focus of the working group. >>>> Goals and Milestones: >>>> Done Working group last call on >>>> draft-ietf-lowpan-goals-assumptions-xx.txt >>>> Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to >>>> IESG >>>> for consideration of publication as Informational >>>> Done Working Group Last Call on >>>> draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >>>> Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >>>> to IESG >>>> for consideration of publication as Proposed Standard >>>> >>>> >>>> >>>> Background/Introduction: >>>> >>>> Note: Given that there is not much precedent for this type of activity >>>> at the IETF, the text that follows is of an introductory >>>> nature. Hence, its objective is to give a general idea of the >>>> application area and motivations for the work. In particular, this >>>> section is not to be construed as detailing work items for the working >>>> group. That is done in the following section entitled "Scope of the >>>> Working Group." >>>> >>>> Well-established fields such as control networks, and burgeoning ones >>>> such as "sensor" (or transducer) networks, are increasingly being >>>> based on wireless technologies. Most (but certainly not all) of these >>>> nodes are amongst the most constrained that have ever been networked >>>> wirelessly. Extreme low power (such that they will run potentially for >>>> years on batteries) and extreme low cost (total device cost in single >>>> digit dollars, and riding Moore's law to continuously reduce that >>>> price point) are seen as essential enablers towards their deployment >>>> in networks with the following characteristics: >>>> >>>> * Significantly more devices than current local area networks >>>> >>>> * Severely limited code and ram space (e.g., highly desirable to fit >>>> the required code--MAC, IP and anything else needed to execute the >>>> embedded application-- in, for example, 32K of flash memory, using >>>> 8-bit microprocessors) >>>> >>>> * Unobtrusive but very different user interface for configuration >>>> (e.g., using gestures or interactions involving the physical world) >>>> >>>> A chief component of these devices is wireless communication >>>> technology. In particular, the IEEE 802.15.4 standard is very >>>> promising for the lower (physical and link) layers. As for higher >>>> layer functions, there is considerable interest from non-IETF groups >>>> in using IP technology. The IEEE 1451.5 standard for wireless >>>> transducers has a chapter for 6LoWPAN and the ISA SP100 standard for >>>> wireless industrial networks has adopted 6LoWPAN for their network >>>> layer. This working group is expected to coordinate and interact with >>>> such groups. >>>> >>>> Description of Working Group: >>>> >>>> The working group has completed two RFCs: "IPv6 over Low-Power >>>> Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, >>>> Problem Statement, and Goals" (RFC4919) that documents and discusses >>>> the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 >>>> Networks" (RFC4944) which defines the format for the adaptation >>>> between IPv6 and 802.15.4. >>>> >>>> The Working Group will generate the necessary documents to enusre >>>> interoperable implementations of 6LoWPAN networks and will define the >>>> necessary security and management protocols and constructs for build >>>> 6LoWPAN networks, paying particular attention to protocols already >>>> available. >>>> >>>> Work Items: >>>> >>>> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" >>>> to define the required optimizations to make IPv6 ND applicable in >>>> 6lowpans, given the fact that IPv6 ND is too expensive for the devices >>>> of 6lowpan and requires multicast. >>>> >>>> This document (or these documents - as the working group delves into >>>> this topic it may determine that this should be two separate >>>> documents) will define how to bootstrap a 6lowpan network and explore >>>> ND optimizations such as reusing the 802.15.4 network structure (use >>>> the coordinators), and obviate multicast by having devices talk to >>>> coordinators without creating a single point-of-failure, and changing >>>> the IPv6 ND multicast semantics. This document will be a proposed >>>> standard. >>>> >>>> 2. Produce "Problem Statement for Stateful Header Compression in >>>> 6lowpans" to document the problem of using stateful header compression >>>> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of >>>> stateless header compression given the assumption that stateful header >>>> compression may be too complex. This document will determine if the >>>> assumption is correct and will be an informational document. The WG >>>> will determine if the assumption is correct at this time and record >>>> the findings in this informational document. >>>> >>>> 3. Produce "6LoWPAN Architecture" to describe the design and >>>> implementation of 6LoWPAN networks. This document will cover the >>>> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, >>>> network components, addressing, and IPv4/IPv6 network connections. >>>> >>>> 4. Produce "Recommendations for 6lowpan Applications" to define a set >>>> of recommendations of protocols to use for applications. The >>>> recommendations will cover protocols for transport, application layer, >>>> discovery, configuration and commissioning. This document will be an >>>> informational document. >>>> >>>> 5. Produce "6lowpan Security Analysis" to define the threat model of >>>> 6lowpans and to document suitability of existing key management >>>> schemes and to discuss bootstrapping/installation/commissioning/setup >>>> issues. This document will be an informational document. >>>> >>>> The working group will continue to reuse existing protocols and >>>> mechanisms whenever reasonable and possible. >>>> >>>> Goals and Milestones: >>>> >>>> Jan 2008 - First Draft of Bootstrapping and ND Optimization document >>>> Feb 2008 - First Draft of Stateful Header Compression document >>>> Dec 2007 - First Draft of 6LoWPAN Architecture docuement >>>> Feb 2008 - First Draft of Applications document >>>> Mar 2008 - First Draft of Security Analysis >>>> Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to >>>> be considered as Proposed Standard >>>> Jul 2008 - Submit Stateful Header Compression document to IESG to be >>>> considered as Proposed Standard >>>> May 2008 - Submit Architecture docuement to IESG to be considered as >>>> Informational RFC >>>> Jul 2008 - Submit Applications docuement to IESG to be considered as >>>> Informational RFC >>>> Sep 2008 - Submit Security Analysis document to IESG to be considered >>>> as Informational RFC. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 6lowpan-bounces@ietf.org Thu May 22 16:29:19 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3A4C3A6B78; Thu, 22 May 2008 16:29:19 -0700 (PDT) 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 D4F353A6B7B; Thu, 22 May 2008 16:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.625 X-Spam-Level: X-Spam-Status: No, score=-5.625 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24eaGDQoL9ch; Thu, 22 May 2008 16:29:17 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 57CA23A6968; Thu, 22 May 2008 16:29:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9079590" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 May 2008 19:29:14 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNTEuo015676; Thu, 22 May 2008 19:29:14 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNTEYt016402; Thu, 22 May 2008 23:29:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:14 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:14 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 08:12:50 -0400 From: JP Vasseur To: "Pascal Thubert (pthubert)" , Jonathan Hui , "Mark Townsley (townsley)" Message-ID: Thread-Topic: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) Thread-Index: Aci7kNbmHT5GGQ+2TY2at3c8aAYrNQASYm6AABD6/iM= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:14.0809 (UTC) FILETIME=[A5B73290:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9475; t=1211498954; x=1212362954; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20ISA100.11a=20status=20and=2 0requirements=20(was=20RE=3A=20New=20charter=0A=20for=206low pan) |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20,=0A=20=20=20=20=20=20=20=20Jonathan=20Hui=20,=0A=20=20=20=20=20=20=20=20=22Mark=20Townsley=20( townsley)=22=20; bh=iaJ17L31JrUKt9FLdnjmqz4r8blu8uL5bwewTnmlb0g=; b=XFXYtgRp2t+2eDG/Z1eDZOLzNy+fHdCeFzG02pIxhhe/zA4trKoRAShueV 2JwtO8ykc8MfqRQk/AnlgbRDhhTJCYRO6hJ0vc53Tklb09WZX7IfHz7rwLyR 3WAqfWUgk8; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "Chernoguzov, Alexander \(PA35\)" , roll@ietf.org, 6lowpan@ietf.org, Jay Werb , "Polyzois, Christos A" Subject: Re: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, On 5/22/08 12:47 AM, "Pascal Thubert (pthubert)" wrote: > Hi: > > My understanding is that defining how mesh-under computes its routes is > out of scope for the IETF overall. I'm not even sure we need to document > requirements in that space. Well you just saw my reply to the other email, we're in sync. It's good that we push some requirements to > ROLL on route-over, and that's certainly the right time to do so. > > To Jonathan: I do not completely agree that ISA100 is mesh under. The > routing is not specified and left to the system manager implementation. > My personal hope is to promote a ROLL solution in ISA100.11a next > release. See > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > Considering the quick progress we hope to have something soon. > So the current release of ISA100.11a is at the same level as 6LoWPAN on > the matter of routing. > > In a same fashion, ISA does not define the backbone operation, the > fragment recovery mechanism or the Explicit Congestion Notification. For > all those features, there's a hope at ISA that the IETF will come up > with more generic solutions that they can apply. But time is running > out. > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > ISA will have to define everything on its own and hopefully publish an > informational to this group. Sharing your view. > > At the moment, the first draft of ISA100.11a is in letter ballot. The > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, which > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > so ISA is using NaLP headers starting with b'00'. > > What ISA needs from 6LoWPAN in very short term is in that order: > - promote Jonathan's draft as a convergence specification so ISA can at > least use standard HC headers. > This enables: non-Link-Local-Address compression > Hops limit compression > UDP checksum compression > Better placement of HC2 > Which are all mandatory for ISA100.11a > - better define the NaLPs. > There should be a way to indicate to a 6LoWPAN node whether a NaLP can > be skipped and what its length is. > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > to report congestion. This would be worth having a discussion on this, probably a specific thread. > - specify a fragment flow control and recovery protocol at the 6LoWPAN > Shim layer Will reply to this in another email thread. > There is no rocket science in any of this and it all could/should be > carried out swiftly. > > What ISA needs in longer term: > - define backbone operation when the backbone federates multiple LoWPANs > into a single link (or subnet, TBD). Mmmm "Subnet" please. > This is more theoretical work for us. Related to proxy ND, a new > registration protocols, multilink subnet, etc... Thanks. JP. > > Pascal > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui >> Sent: jeudi 22 mai 2008 00:20 >> To: Mark Townsley (townsley) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> >> Hi Mark: >> >> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>> - To your point on ND, this is precisely why the architecture draft >>>> is so important. We haven't given it as much attention lately, but >>>> it will help resolve the question your raise and many other >>>> questions in the future. For example, the architecture draft >>>> identifies two modes of operation: mesh-under and route-over. Both >>>> of which may require different ND mechanisms. This doesn't apply to >>>> just ND, but may apply questions of fragmentation, header >>>> compression, security, etc. >>> I worry about the under/over debate. It seems that with all the >>> effort and enthusiasm in ROLL, we might be well-served at the moment >>> by focusing on helping them be successful with route-over than >>> spending too much of our time on route-under. >> >> I worry too, especially since it will pull the WG in different >> directions. I'm with you on the preference for route-over, but others >> in this group feel strongly about mesh-under as well, especially since >> ISA100.11a seems to have adopted a mesh-under approach. I've >> personally been focused on developing route-over solutions while being >> conscious of supporting mesh-under when possible (evident with 6lowpan- >> hc). However, things will start to diverge when we start to talk about >> bootstrapping, ND, etc. So we should make a conscious decision of >> whether we're supporting one or both. >> >> -- >> Jonathan Hui >> >>> >>>> >>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>> charter ("reusing the 802.15.4 network structure (use the >>>> coordinators)") especially since the definition of such link >>>> mechanisms are still in motion within the IEEE. It seems more >>>> productive to me if we can develop mechanisms that are less >>>> dependent on the specific structure of 802.15.4 mechanisms. >>> I agree that we should develop mechanisms that could work >>> generically whenever possible. >>> >>> - Mark >>>> >>>> Rest of the charter looks good to me. >>>> >>>> Thanks. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi Mark: >>>>>> >>>>>> I think we need a work item (usually implicit) around the concept >>>>>> of >>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>> aspects: >>>>>> >>>>> >>>>>> >>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>> to >>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>> given. >>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>> RFC >>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>> resolve >>>>>> for the most part. >>>>>> >>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > to >>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>> interoperability. >>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>> radio >>>>>> mesh exposes the network to congestion collapse, as described in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>> provide >>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>> flow >>>>>> control and recovery of fragments. >>>>>> >>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>> rather >>>>> than a transport layer issue? >>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>> It >>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>> implement >>>>>> the concept in the IPv6 world. This partially falls under the >>>>>> first work >>>>>> item on ND but might also include ND proxy over the backbone >>>>>> which is a >>>>>> stretch to the work item. More in >>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>> . >>>>>> >>>>> Well, don't we need to define what ND looks like on a lowpan >>>>> before we >>>>> decide whether it needs to be proxied or not? >>>>> >>>>> - Mark >>>>>> What do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>> On >>>>>>> >>>>>> Behalf Of Mark Townsley >>>>>> >>>>>>> (townsley) >>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>> To: 6lowpan@ietf.org >>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>> >>>>>>> >>>>>>> I'd like to ask the group one final time for comments on the >>>>>>> proposed >>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>> >>>>>>> As I said before, soon after the format document was published, >>>>>>> there >>>>>>> >>>>>> is >>>>>> >>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>> existing >>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>> should be >>>>>>> in and out of the charter. Please do not construe not having a >>>>>>> charter >>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>> that need >>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>> before >>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>> discussions when creating new WG charters. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 22 16:29:24 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DBC28C178; Thu, 22 May 2008 16:29:24 -0700 (PDT) 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 083293A6BC9 for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.411 X-Spam-Level: X-Spam-Status: No, score=-5.411 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOCoXVVzGY8M for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8F20D3A6BA0 for <6lowpan@ietf.org>; Thu, 22 May 2008 16:29:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9079594" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 May 2008 19:29:21 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNTLfF015698; Thu, 22 May 2008 19:29:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNTLCA016424; Thu, 22 May 2008 23:29:21 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:21 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:20 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 10:09:07 -0400 From: JP Vasseur To: Jonathan Hui , Mark Townsley Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci8LoszR/Iu+3TKMkawy206zMlTnQ== In-Reply-To: <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:21.0028 (UTC) FILETIME=[A96C2440:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6368; t=1211498961; x=1212362961; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20Jonathan=20Hui=20,=20Mark=20Towns ley=20; bh=sHNtlBNxP2nWwLnBsP+eDUyUxsyc7y2SzyNG4sANOgE=; b=nfkg/lfw9BMj6W4amIy1r8874MVEHCoelb5SeU3fUGeyeGqyMCGjQ6USRC xrWafG6EF5XQs0AUocLxSfdt54PEJ1Dtz1GQDXLIZODZZpjUpoo0M9FBkCrN cjH6bgSXOs; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan, On 5/21/08 3:19 PM, "Jonathan Hui" wrote: > > Hi Mark: > > On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>> - To your point on ND, this is precisely why the architecture draft >>> is so important. We haven't given it as much attention lately, but >>> it will help resolve the question your raise and many other >>> questions in the future. For example, the architecture draft >>> identifies two modes of operation: mesh-under and route-over. Both >>> of which may require different ND mechanisms. This doesn't apply to >>> just ND, but may apply questions of fragmentation, header >>> compression, security, etc. >> I worry about the under/over debate. It seems that with all the >> effort and enthusiasm in ROLL, we might be well-served at the moment >> by focusing on helping them be successful with route-over than >> spending too much of our time on route-under. > > I worry too, especially since it will pull the WG in different > directions. I'm with you on the preference for route-over, but others > in this group feel strongly about mesh-under as well, especially since > ISA100.11a seems to have adopted a mesh-under approach. I've > personally been focused on developing route-over solutions while being > conscious of supporting mesh-under when possible (evident with 6lowpan- > hc). However, things will start to diverge when we start to talk about > bootstrapping, ND, etc. So we should make a conscious decision of > whether we're supporting one or both. And I agree with, hence my previous email ... So far I have heard any strong valid argument in support of both but I can certainly list a number of reasons why not doing both. But for the time being I think that we should try to quickly converge to get the new charter stabilized to get back to Mark; there are IMO a long list of items on which we should quickly move on (stateful header compression, security, ...). Thanks. JP. > > -- > Jonathan Hui > >> >>> >>> - I hesitate a bit that we suggest possible solutions to ND in the >>> charter ("reusing the 802.15.4 network structure (use the >>> coordinators)") especially since the definition of such link >>> mechanisms are still in motion within the IEEE. It seems more >>> productive to me if we can develop mechanisms that are less >>> dependent on the specific structure of 802.15.4 mechanisms. >> I agree that we should develop mechanisms that could work >> generically whenever possible. >> >> - Mark >>> >>> Rest of the charter looks good to me. >>> >>> Thanks. >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>> >>>> Pascal Thubert (pthubert) wrote: >>>>> Hi Mark: >>>>> >>>>> I think we need a work item (usually implicit) around the concept >>>>> of >>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>> aspects: >>>>> >>>> >>>>> >>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>> to >>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>> given. >>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>> RFC >>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>> resolve >>>>> for the most part. >>>>> >>>> Are the resolutions backwards compatible with RFC 4944? I'm eager to >>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>> interoperability. >>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>> radio >>>>> mesh exposes the network to congestion collapse, as described in >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>> provide >>>>> additional functions that would improve the LoWPAN operation WRT >>>>> flow >>>>> control and recovery of fragments. >>>>> >>>> Fragmentation, OK, but why is flow control a network layer issue >>>> rather >>>> than a transport layer issue? >>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>> It >>>>> would be appropriate that the IETF comes up with a proposal to >>>>> implement >>>>> the concept in the IPv6 world. This partially falls under the >>>>> first work >>>>> item on ND but might also include ND proxy over the backbone >>>>> which is a >>>>> stretch to the work item. More in >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>> . >>>>> >>>> Well, don't we need to define what ND looks like on a lowpan >>>> before we >>>> decide whether it needs to be proxied or not? >>>> >>>> - Mark >>>>> What do you think? >>>>> >>>>> Pascal >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>> On >>>>>> >>>>> Behalf Of Mark Townsley >>>>> >>>>>> (townsley) >>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>> To: 6lowpan@ietf.org >>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>> >>>>>> >>>>>> I'd like to ask the group one final time for comments on the >>>>>> proposed >>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>> >>>>>> As I said before, soon after the format document was published, >>>>>> there >>>>>> >>>>> is >>>>> >>>>>> nothing stopping the WG from discussing and working on new and >>>>>> existing >>>>>> items at this time. In fact, activity helps us to decide what >>>>>> should be >>>>>> in and out of the charter. Please do not construe not having a >>>>>> charter >>>>>> in place as a reason not to update drafts, or discuss topics >>>>>> that need >>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>> before >>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>> discussions when creating new WG charters. >>>>>> >>>>>> - Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 6lowpan-bounces@ietf.org Thu May 22 16:29:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCAE28C19A; Thu, 22 May 2008 16:29:26 -0700 (PDT) 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 E343528C1A1 for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.435 X-Spam-Level: X-Spam-Status: No, score=-5.435 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq8Eb-Pl1hXD for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BC6143A6BA6 for <6lowpan@ietf.org>; Thu, 22 May 2008 16:29:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9070072" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2008 19:29:22 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNTMle025210 for <6lowpan@ietf.org>; Thu, 22 May 2008 19:29:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNTMXH029430 for <6lowpan@ietf.org>; Thu, 22 May 2008 23:29:22 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:22 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:21 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 10:22:25 -0400 From: JP Vasseur To: Mark Townsley , "Pascal Thubert (pthubert)" Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci8MGbYidB/RzFK20WmJYbSLRF7Dg== In-Reply-To: <4832EBC2.8050902@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:22.0106 (UTC) FILETIME=[AA10A1A0:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2654; t=1211498962; x=1212362962; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20Mark=20Townsley=20,=0A=20=20=20= 20=20=20=20=20=22Pascal=20Thubert=20(pthubert)=22=20; bh=kJKFwbhvkb/a/NL9Hl0lml1eK4baWWu8FBp/qAhXeSE=; b=OG0YVuf8JpUzORYRfPu6QRikhIUAXyYohs/uCEdkdhz7GQip6UHXQdDEuR Bxu5NYZ+OlCLy8uYlZPQiDE28kVHoN+QZ8Usuug3WhbYa8ki0I4BCf/oGzb9 Xqfvxtvv9R; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Just one side note ... I also think that adding a WG item on fragment recovery is needed. That said, we will need to be vigilant here. Mark is right saying that adding too much of flow control there may badly impact the transport layer thus resulting in high delays, waste of energy should the two flow control mechanism get completely out of sync. But that can be discussed once we'll get the work item added if there is a agreement of the WG for doing so. Mark, we had also a discussion with the Transport AD during the ROLL BOF ... Yes, there is transport work to be done there for LLN (Low power and lossy networks) (not specifically lowpan). Thanks. JP. On 5/20/08 8:18 AM, "Mark Townsley" wrote: > Pascal Thubert (pthubert) wrote: >> Hi again Mark >> >> >>>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>>> mesh exposes the network to congestion collapse, as described in >>>> >>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >> >>>> overy . I think that the WG should dedicate some bandwitdth to >>>> >> provide >> >>>> additional functions that would improve the LoWPAN operation WRT flow >>>> control and recovery of fragments. >>>> >>>> >>> Fragmentation, OK, but why is flow control a network layer issue rather >>> than a transport layer issue? >>> >> >> [Pascal] I'm talking about flow control on the fragments themselves; >> this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above >> LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to >> cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes >> minimum, it causes a burst of fragments that should be paced and >> windowed. I suggest we do it in 6LoWPAN and handle the consequences of >> our own fragmentation rather than rely on a LLC mechanism that might not >> be there or adapted. >> > OK, that makes sense. Of course, if the higher layer transports consider > this fragmented packet lost and retransmit in the mean time we will end > up thrashing. We need to be very wary of the higher-layer transport > affects. And, of course this isn't the first time I've thought we might > need ot spin up a transport-area lowpan WG similar to what we did with > ROLL. But, sometimes its hard enough to keep 2 working groups working > and making progress, much less 3. > > - Mark >> Pascal >> >> >> > > _______________________________________________ > 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 6lowpan-bounces@ietf.org Thu May 22 16:29:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2EA328C1B8; Thu, 22 May 2008 16:29:26 -0700 (PDT) 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 C83BB28C1A1 for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.451 X-Spam-Level: X-Spam-Status: No, score=-5.451 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVmze+fZ2IQs for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:24 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8ADA13A6B85 for <6lowpan@ietf.org>; Thu, 22 May 2008 16:29:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9070074" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2008 19:29:23 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNTNTQ015715; Thu, 22 May 2008 19:29:23 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNTNv5016434; Thu, 22 May 2008 23:29:23 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:23 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:23 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 10:24:06 -0400 From: JP Vasseur To: Mark Townsley , Jonathan Hui Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci8MKMMc8L648v3j0mNCx4prN4/vg== In-Reply-To: <4832ED46.1070304@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:23.0544 (UTC) FILETIME=[AAEC0D80:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5853; t=1211498963; x=1212362963; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20Mark=20Townsley=20,=20Jonathan=2 0Hui=20; bh=9G6HSuRXudI0mCH5sqSXhYyYuVAwqiSJC2+e1Ben4mE=; b=G3HLZo0inH8LuzOGnpRrdJFuE7K5vYECtdM005J9XKhFZVJRy0N2YbniqF 4LX6Jublmt8tMqtNeTKr4pa695hmSlOjMshPXvK01jtCXD2gvb66cauWg5G0 s6GpuFhR9i; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark, On 5/20/08 8:24 AM, "Mark Townsley" wrote: > Jonathan Hui wrote: >> >> Hi Mark, thanks for reigniting the discussion on this. >> >> - Improving RFC 4944 is an important one. The biggest issue I have >> with it in the near term is that the IPv6 header compression does not >> allow compression of non-link-local addresses, which is an important >> case if we truly intend to do inter-networking. This is the most >> important point of the 6lopwan-hc draft. Backwards compatibility is >> supported by utilizing new dispatch values. But it's important to >> consider what the implementation costs are of supporting the >> LOWPAN_HC1 defined in RFC 4944, especially since 6lowpan-hc does cover >> most of the useful cases in LOWPAN_HC1. Something for the WG to >> discuss... > Yes, in is incumbent on us as the IETF to ensure that the 6lowpan can > ultimately be a part of the wider Internet. Exactly. A key WG item. >> >> - To your point on ND, this is precisely why the architecture draft is >> so important. We haven't given it as much attention lately, but it >> will help resolve the question your raise and many other questions in >> the future. For example, the architecture draft identifies two modes >> of operation: mesh-under and route-over. Both of which may require >> different ND mechanisms. This doesn't apply to just ND, but may apply >> questions of fragmentation, header compression, security, etc. > I worry about the under/over debate. It seems that with all the effort > and enthusiasm in ROLL, we might be well-served at the moment by > focusing on helping them be successful with route-over than spending too > much of our time on route-under. Can't agree more. >> >> - I hesitate a bit that we suggest possible solutions to ND in the >> charter ("reusing the 802.15.4 network structure (use the >> coordinators)") especially since the definition of such link >> mechanisms are still in motion within the IEEE. It seems more >> productive to me if we can develop mechanisms that are less dependent >> on the specific structure of 802.15.4 mechanisms. > I agree that we should develop mechanisms that could work generically > whenever possible. > > - Mark >> >> Rest of the charter looks good to me. >> >> Thanks. >> >> -- >> Jonathan Hui >> >> >> >> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >> >>> Pascal Thubert (pthubert) wrote: >>>> Hi Mark: >>>> >>>> I think we need a work item (usually implicit) around the concept of >>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>> aspects: >>>> >>> >>>> >>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a to >>>> conform to 6LoWPAN would be a major win, but is certainly not a given. >>>> At the moment, the ISA100.11a documents expose discrepencies with RFC >>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve >>>> for the most part. >>>> >>> Are the resolutions backwards compatible with RFC 4944? I'm eager to >>> improve RFC 4944, but not eager to endorse changes that inhibit >>> interoperability. >>>> - The issue of fragmentation. Applying RFC 4944 over a multihop radio >>>> mesh exposes the network to congestion collapse, as described in >>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>> >>>> overy . I think that the WG should dedicate some bandwitdth to provide >>>> additional functions that would improve the LoWPAN operation WRT flow >>>> control and recovery of fragments. >>>> >>> Fragmentation, OK, but why is flow control a network layer issue rather >>> than a transport layer issue? >>>> Another aspect of ISA100.11a is the concept of a backbone router. It >>>> would be appropriate that the IETF comes up with a proposal to >>>> implement >>>> the concept in the IPv6 world. This partially falls under the first >>>> work >>>> item on ND but might also include ND proxy over the backbone which is a >>>> stretch to the work item. More in >>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. >>>> >>> Well, don't we need to define what ND looks like on a lowpan before we >>> decide whether it needs to be proxied or not? >>> >>> - Mark >>>> What do you think? >>>> >>>> Pascal >>>> >>>> >>>>> -----Original Message----- >>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>>> >>>> Behalf Of Mark Townsley >>>> >>>>> (townsley) >>>>> Sent: jeudi 15 mai 2008 23:02 >>>>> To: 6lowpan@ietf.org >>>>> Subject: [6lowpan] New charter for 6lowpan >>>>> >>>>> >>>>> I'd like to ask the group one final time for comments on the proposed >>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>> >>>>> As I said before, soon after the format document was published, there >>>>> >>>> is >>>> >>>>> nothing stopping the WG from discussing and working on new and >>>>> existing >>>>> items at this time. In fact, activity helps us to decide what >>>>> should be >>>>> in and out of the charter. Please do not construe not having a charter >>>>> in place as a reason not to update drafts, or discuss topics that need >>>>> to be discussed. Just as when we have BoF's and mailing lists before >>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>> discussions when creating new WG charters. >>>>> >>>>> - Mark >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 6lowpan-bounces@ietf.org Thu May 22 16:29:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA0828C1C1; Thu, 22 May 2008 16:29:27 -0700 (PDT) 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 DB08C28C1B1 for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.462 X-Spam-Level: X-Spam-Status: No, score=-5.462 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9kij6mMZILx for <6lowpan@core3.amsl.com>; Thu, 22 May 2008 16:29:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 95ED228C194 for <6lowpan@ietf.org>; Thu, 22 May 2008 16:29:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,526,1204520400"; d="scan'208";a="9070075" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2008 19:29:24 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4MNTO5T015719 for <6lowpan@ietf.org>; Thu, 22 May 2008 19:29:24 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4MNTOJV029443 for <6lowpan@ietf.org>; Thu, 22 May 2008 23:29:24 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 May 2008 19:29:24 -0400 Received: from 10.21.97.96 ([10.21.97.96]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 May 2008 23:29:24 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 22 May 2008 10:30:48 -0400 From: JP Vasseur To: "Pascal Thubert (pthubert)" , "Mark Townsley (townsley)" Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci6jMxrYwQCzYkZQ8m3LENi5fv8UQABVvLgAGfanaE= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 22 May 2008 23:29:24.0544 (UTC) FILETIME=[AB84A400:01C8BC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3284; t=1211498964; x=1212362964; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20,=0A=20=20=20=20=20=20=20=20=22Mark=20Townsley=20(town sley)=22=20; bh=cWvZCHBaHmnkWjAGNJO5mAgjWrHYb4yqZw7WpkBcTn4=; b=TU2xXN1iUjWH6VA3JXAwqMzwjXLtXVWSd/lktGgn8OrJ3BAs4LFaYgCsLv 0O917sfda/hySwIPSv+X67ptfUNnbpuGDeCti/aa0dFGeaOcuZ/Vs3KTpOGd rokWRhY0M8; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, Just a word of cautious though. It is not the number of needed bits that matters here but what you do with them. ECN is clearly a fairly big WG item (Look at the history of IP in that area or even FR by the way where several pretty sophisticated mechanisms had been designed to handle this - or trivial task). I would personally suggest to not add this to the WG charter for the moment. Thanks. JP. On 5/20/08 9:01 AM, "Pascal Thubert (pthubert)" wrote: > Hi Again Mark: > > Another aspect of this is ECN. We do not have room for Explicit > Congestion Notification in the 6LoWPAN headers. ECN only takes 2 bits in > Frame Relay and in IP, though the bits are used differently. I have in > mind that the FR version with forward and backward bits is a better fit > if it acts upon the fragment flow control, though the FECN could then be > mapped into IP ECN. > > This is additional work to the fragment recovery and I'm taking great > care to present them separate. But it could become an interesting > feature in some future as well. > > Pascal > >> -----Original Message----- >> From: Mark Townsley (townsley) >> Sent: mardi 20 mai 2008 17:18 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> Pascal Thubert (pthubert) wrote: >>> Hi again Mark >>> >>> >>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop > radio >>>>> mesh exposes the network to congestion collapse, as described in >>>>> >>>>> >>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>> >>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>> >>> provide >>> >>>>> additional functions that would improve the LoWPAN operation WRT > flow >>>>> control and recovery of fragments. >>>>> >>>>> >>>> Fragmentation, OK, but why is flow control a network layer issue > rather >>>> than a transport layer issue? >>>> >>> >>> [Pascal] I'm talking about flow control on the fragments themselves; >>> this is either a LLC (the likes of 802.2 or LAPB) or a shim layer > above >>> LLC problem (that would be us). The 802.15.4 MAC/PHY was not design > to >>> cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 > bytes >>> minimum, it causes a burst of fragments that should be paced and >>> windowed. I suggest we do it in 6LoWPAN and handle the consequences > of >>> our own fragmentation rather than rely on a LLC mechanism that might > not >>> be there or adapted. >>> >> OK, that makes sense. Of course, if the higher layer transports > consider >> this fragmented packet lost and retransmit in the mean time we will end >> up thrashing. We need to be very wary of the higher-layer transport >> affects. And, of course this isn't the first time I've thought we might >> need ot spin up a transport-area lowpan WG similar to what we did with >> ROLL. But, sometimes its hard enough to keep 2 working groups working >> and making progress, much less 3. >> >> - Mark >>> Pascal >>> >>> >>> > > _______________________________________________ > 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 6lowpan-bounces@ietf.org Thu May 22 16:53:46 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497CA3A6B7C; Thu, 22 May 2008 16:53:46 -0700 (PDT) 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 BFFF73A752C for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbqO-gUcD8P0 for <6lowpan@core3.amsl.com>; Tue, 20 May 2008 20:37:33 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.93]) by core3.amsl.com (Postfix) with ESMTP id 6204728E4EC for <6lowpan@ietf.org>; Tue, 20 May 2008 13:42:32 -0700 (PDT) Received: from [128.107.28.164] ([128.107.28.164]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id m4KKgBRe005014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 May 2008 13:42:12 -0700 (PDT) Message-ID: <4833379D.7070904@eecs.berkeley.edu> Date: Tue, 20 May 2008 13:42:05 -0700 From: "David E. Culler" User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Mark Townsley References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> In-Reply-To: <4832F276.70406@cisco.com> X-Mailman-Approved-At: Thu, 22 May 2008 16:53:44 -0700 Cc: 6lowpan@ietf.org, roll-chairs@tools.ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Here's my take from ROLL. JP may want to weigh in. ROLL has a series of routing requirements documents. We'd like 6LoWPAN to review, comment, and potentially contribute to those. I think that it makes sense to continue to run them through ROLL. They are to be used to guide the analysis of existing routing protocols. I6LoWPAN might want to use them to guide 6LoWPAN efforts as well. ROLL is looking at routing (L3) over low-power and lossy links - including but not limited to 802.15.4. It is not looking at mesh-under (L2) forwarding, which the 6LoWPAN adaptation layer provides some support for. The "requirements" documents in 6LoWPAN so far have been of a very general observational nature. Perhaps those will become more focused on the issues most germane to 6LoWPAN. If there is to be more work on L2 meshing, 6LoWPAN would likely be the only home for it in IETF. There has been lots of discussion about providing the equivalents of ICMPv6 and IPv6 hop-by-hop options for mesh under, but it's not clear if that is on the table. It certainly is not within ROLL. A key place of cooperation seems like the ND, Autoconf, ICMPv6 aspects. For example, how will router advertisements be utilized? To date, much of the 6LoWPAN ND and bootsrapping discussion has been from 802.15.4 MAC concepts-up (eg. PAN coordinator) rather than IP down (e.g., DHCPv6). Being in the internet area, 6LoWPAN is well positioned to lead efforts that cut across areas. D Mark Townsley wrote: > Eunsook "Eunah" Kim wrote: >> Dear AD, and chairmen, >> >> It's good to finally see official rechater text. >> > It's only proposed text. >> I think it's pretty well delivering our discussion of rechartering so >> far, EXCEPT one part; 6lowpan routing requirement. >> Last meeting (71th IETF), we discussed RR matter and agreed to see >> IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember >> correctly, we would keep this work with alignment with ROLL, as long >> as it's not duplicate work with ROLL. >> > You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what > are your expectations from 6lowpan with respect to the > routing-requirements document? > > http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt > > I have some more questions for you specifically: > > Should that be pulled into roll, or left in 6lowpan? Is roll > considering the L2"route-under" model at all? Is there anything that > the L3 "route-over" model might not provide that is listed as a > requirement for 6lowpan's "route-under" model? If 6lowpan were to work > on an L2 "route-under" model, would there be constructs (e.g., the > routing protocol itself and any low-power modifications) from ROLL > that we would invariably want to try and reuse? >> I would like to know if it is implied that the RR work is included in >> Architecture work, OR, if you have *intentionally* excluded the work. >> If the first case, I would suggest 6LoWPANers check the updated >> version (-05) of draft. We updated our RR draft (-05) after the >> meeting based on the meeting discussion, and circulated to the mailing >> list. >> >> If the second case, I think we should get a chance to discuss the >> updated version. If the meeting decide the fate of this work after >> that, I would accept it. However, I have problem if AD or chairmen >> simply exclude this item without such discussion and concensus >> > There has never been any intention to go against consensus or limit > discussion on this topic. So, let's use this thread to get to the > bottom of what we want to do as a group here. > > - Mark >> Would you please clarify it to me? >> >> Thanks, >> >> -eunah >> >> On Thu, May 15, 2008 at 11:02 PM, Mark Townsley >> wrote: >> >>> I'd like to ask the group one final time for comments on the >>> proposed new >>> charter. I've also asked the ROLL WG chairs to comment. >>> >>> As I said before, soon after the format document was published, >>> there is >>> nothing stopping the WG from discussing and working on new and existing >>> items at this time. In fact, activity helps us to decide what should >>> be in >>> and out of the charter. Please do not construe not having a charter >>> in place >>> as a reason not to update drafts, or discuss topics that need to be >>> discussed. Just as when we have BoF's and mailing lists before >>> creating a >>> new WG, it is good to have WG meetings and on-lists discussions when >>> creating new WG charters. >>> >>> - Mark >>> >>> >>> >>> >>> >>> >>> Background/Introduction: >>> >>> Note: Given that there is not much precedent for this type of activity >>> at the IETF, the text that follows is of an introductory >>> nature. Hence, its objective is to give a general idea of the >>> application area and motivations for the work. In particular, this >>> section is not to be construed as detailing work items for the working >>> group. That is done in the following section entitled "Scope of the >>> Working Group." >>> >>> Well-established fields such as control networks, and burgeoning ones >>> such as "sensor" (or transducer) networks, are increasingly being >>> based on wireless technologies. Most (but certainly not all) of these >>> nodes are amongst the most constrained that have ever been networked >>> wirelessly. Extreme low power (such that they will run potentially for >>> years on batteries) and extreme low cost (total device cost in single >>> digit dollars, and riding Moore's law to continuously reduce that >>> price point) are seen as essential enablers towards their deployment >>> in networks with the following characteristics: >>> >>> * Significantly more devices than current networks >>> >>> * Severely limited code and ram space (e.g., highly desirable to >>> fit the required code--MAC, IP and anything else needed to >>> execute the embedded application-- in, for example, 32K of flash >>> memory, using 8-bit microprocessors) >>> >>> * Unobtrusive but very different user interface for configuration >>> (e.g., using gestures or interactions involving the physical >>> world) >>> >>> * Robustness and simplicity in routing or network fabric >>> >>> A chief component of these devices is wireless communication >>> technology. In particular, the IEEE 802.15.4 standard is very >>> promising for the lower (physical and link) layers. As for higher >>> layer functions, there is considerable interest from non-IETF groups >>> in using IP technology (the ZigBee alliance, for example, is currently >>> studying what such a work item might entail). The working group is >>> expected to coordinate and interact with such groups. >>> >>> The required work includes items in the following (incomplete) list: >>> >>> * IP adaptation/Packet Formats and interoperability >>> * Addressing schemes and address management >>> * Network management >>> * Routing in dynamically adaptive topologies >>> * Security, including set-up and maintenance >>> * Application programming interface >>> * Discovery (of devices, of services, etc) >>> * Implementation considerations >>> >>> Whereas at least some of the above items are within the purview of the >>> IETF, at this point it is not clear that all of them are. Accordingly, >>> the 6LoWPAN working group will address a reduced, more focused set of >>> objectives. >>> >>> Scope of 6lowpan: >>> >>> Produce "Problems Statement, Assumptions and Goals for IPv6 for >>> LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the >>> problem statement and goals of 6lowpan networks. >>> >>> Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN >>> Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the >>> basic packet formats and sub-IP adaptation layer for transmission of >>> IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, >>> header compression and address generation. Furthermore, IEEE 802.15.4 >>> devices are expected to be deployed in mesh topologies. >>> >>> As such, the working group may also work on an informational document >>> to show how to apply an existing MANET protocol to LoWPANs (e.g., >>> AODV, OLSR, DYMO, etc). >>> >>> The working group will reuse existing specifications whenever >>> reasonable and possible. >>> >>> The working group will also serve as a venue for ongoing discussions >>> on other topics related to the more complete list outlined above. >>> Additional related milestones may be added in the future via a >>> rechartering operation. >>> >>> Note: As may be obvious from its official name above, this particular >>> working group will not work on IPv4 over IEEE 802.15.4 specifications. >>> Given the limitations of the target devices, dual-stack deployments >>> are not practical. Because of its higher potential for header >>> compression, its support for the huge number of devices expected and >>> of cleanly built-in features such as address autoconfiguration, IPv6 >>> is the exclusive focus of the working group. >>> Goals and Milestones: >>> Done Working group last call on >>> draft-ietf-lowpan-goals-assumptions-xx.txt >>> Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to >>> IESG >>> for consideration of publication as Informational >>> Done Working Group Last Call on >>> draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >>> Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >>> to IESG >>> for consideration of publication as Proposed Standard >>> >>> >>> >>> Background/Introduction: >>> >>> Note: Given that there is not much precedent for this type of activity >>> at the IETF, the text that follows is of an introductory >>> nature. Hence, its objective is to give a general idea of the >>> application area and motivations for the work. In particular, this >>> section is not to be construed as detailing work items for the working >>> group. That is done in the following section entitled "Scope of the >>> Working Group." >>> >>> Well-established fields such as control networks, and burgeoning ones >>> such as "sensor" (or transducer) networks, are increasingly being >>> based on wireless technologies. Most (but certainly not all) of these >>> nodes are amongst the most constrained that have ever been networked >>> wirelessly. Extreme low power (such that they will run potentially for >>> years on batteries) and extreme low cost (total device cost in single >>> digit dollars, and riding Moore's law to continuously reduce that >>> price point) are seen as essential enablers towards their deployment >>> in networks with the following characteristics: >>> >>> * Significantly more devices than current local area networks >>> >>> * Severely limited code and ram space (e.g., highly desirable to fit >>> the required code--MAC, IP and anything else needed to execute the >>> embedded application-- in, for example, 32K of flash memory, using >>> 8-bit microprocessors) >>> >>> * Unobtrusive but very different user interface for configuration >>> (e.g., using gestures or interactions involving the physical world) >>> >>> A chief component of these devices is wireless communication >>> technology. In particular, the IEEE 802.15.4 standard is very >>> promising for the lower (physical and link) layers. As for higher >>> layer functions, there is considerable interest from non-IETF groups >>> in using IP technology. The IEEE 1451.5 standard for wireless >>> transducers has a chapter for 6LoWPAN and the ISA SP100 standard for >>> wireless industrial networks has adopted 6LoWPAN for their network >>> layer. This working group is expected to coordinate and interact with >>> such groups. >>> >>> Description of Working Group: >>> >>> The working group has completed two RFCs: "IPv6 over Low-Power >>> Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, >>> Problem Statement, and Goals" (RFC4919) that documents and discusses >>> the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 >>> Networks" (RFC4944) which defines the format for the adaptation >>> between IPv6 and 802.15.4. >>> >>> The Working Group will generate the necessary documents to enusre >>> interoperable implementations of 6LoWPAN networks and will define the >>> necessary security and management protocols and constructs for build >>> 6LoWPAN networks, paying particular attention to protocols already >>> available. >>> >>> Work Items: >>> >>> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" >>> to define the required optimizations to make IPv6 ND applicable in >>> 6lowpans, given the fact that IPv6 ND is too expensive for the devices >>> of 6lowpan and requires multicast. >>> >>> This document (or these documents - as the working group delves into >>> this topic it may determine that this should be two separate >>> documents) will define how to bootstrap a 6lowpan network and explore >>> ND optimizations such as reusing the 802.15.4 network structure (use >>> the coordinators), and obviate multicast by having devices talk to >>> coordinators without creating a single point-of-failure, and changing >>> the IPv6 ND multicast semantics. This document will be a proposed >>> standard. >>> >>> 2. Produce "Problem Statement for Stateful Header Compression in >>> 6lowpans" to document the problem of using stateful header compression >>> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of >>> stateless header compression given the assumption that stateful header >>> compression may be too complex. This document will determine if the >>> assumption is correct and will be an informational document. The WG >>> will determine if the assumption is correct at this time and record >>> the findings in this informational document. >>> >>> 3. Produce "6LoWPAN Architecture" to describe the design and >>> implementation of 6LoWPAN networks. This document will cover the >>> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, >>> network components, addressing, and IPv4/IPv6 network connections. >>> >>> 4. Produce "Recommendations for 6lowpan Applications" to define a set >>> of recommendations of protocols to use for applications. The >>> recommendations will cover protocols for transport, application layer, >>> discovery, configuration and commissioning. This document will be an >>> informational document. >>> >>> 5. Produce "6lowpan Security Analysis" to define the threat model of >>> 6lowpans and to document suitability of existing key management >>> schemes and to discuss bootstrapping/installation/commissioning/setup >>> issues. This document will be an informational document. >>> >>> The working group will continue to reuse existing protocols and >>> mechanisms whenever reasonable and possible. >>> >>> Goals and Milestones: >>> >>> Jan 2008 - First Draft of Bootstrapping and ND Optimization document >>> Feb 2008 - First Draft of Stateful Header Compression document >>> Dec 2007 - First Draft of 6LoWPAN Architecture docuement >>> Feb 2008 - First Draft of Applications document >>> Mar 2008 - First Draft of Security Analysis >>> Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to >>> be considered as Proposed Standard >>> Jul 2008 - Submit Stateful Header Compression document to IESG to be >>> considered as Proposed Standard >>> May 2008 - Submit Architecture docuement to IESG to be considered as >>> Informational RFC >>> Jul 2008 - Submit Applications docuement to IESG to be considered as >>> Informational RFC >>> Sep 2008 - Submit Security Analysis document to IESG to be considered >>> as Informational RFC. >>> >>> >>> >>> _______________________________________________ >>> 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 6lowpan-bounces@ietf.org Thu May 22 16:53:46 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E6B28C161; Thu, 22 May 2008 16:53:46 -0700 (PDT) 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 C2F7728C164; Thu, 22 May 2008 15:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.655 X-Spam-Level: X-Spam-Status: No, score=-0.655 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEdbWB6zSoqJ; Thu, 22 May 2008 15:54:23 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 3F69E28C13A; Thu, 22 May 2008 15:54:23 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m4MMsCWV009470; Thu, 22 May 2008 16:54:13 -0600 (MDT) From: Geoff Mulligan To: Jonathan Hui In-Reply-To: <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> Date: Thu, 22 May 2008 16:54:20 -0600 Message-Id: <1211496860.23290.41.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 X-Mailman-Approved-At: Thu, 22 May 2008 16:53:44 -0700 Cc: roll@ietf.org, Jay Werb , "Polyzois, Christos A" , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Aren't both abstractions equally valid? I think that the biggest issue with a mesh under is that there is no one standard for it. ISA100 is one; I have done another using AODVtiny; I think Jennic has one using their mesh protocol and there are others. If IEEE had defined a multi-hop L2 mesh then we could point at that and define a solution for ND and bootstrapping and security and ... for it. The WG decided a couple of meetings ago that we would focus on solutions for the Route Over abstraction. [If while we are doing this we can keep in mind some of the issues w.r.t. mesh under that's good.] Somewhat independent from this is the HC1G draft that is important to deal with since we do need a way to efficiently handle non-local addresses. So as to remove the mesh under vs. route over issues from the HC1G draft I would like to see the draft updated to remove the UDP checksum optimization. I would like to ask the WG if we should consider taking draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of removing the UDP checksum compression. geoff On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: > Hi Pascal, > > So let's drop the mesh-under/route-over terminology for a second, I > think they are confusing since everyone seems to have a different > definition for those terms. > > What I am mainly concerned about is the kind of IP Link abstraction > 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. > 802.15.4 and possible others through a BbR), what I've been calling > mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the > radio range of 802.15.4), what I've been calling route-over. My point > to Mark's concern was that solutions to some work items within 6LoWPAN > will be different depending on our IP Link abstraction. From what I > understand, ISA100.11a has chosen option (i). But to your point below, > using IP routing to provide connectivity between nodes within the same > IP Link doesn't seem right to me, so it'd be great if you could help > me see a path to get there. > > A lot of this confusion can be cleaned up within the 6LoWPAN > architecture document. But I think Mark's concern still stands: > whether or not we're focused on one or both of these IP Link > abstractions. > > -- > Jonathan Hui > > On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: > > > Hi: > > > > My understanding is that defining how mesh-under computes its routes > > is > > out of scope for the IETF overall. I'm not even sure we need to > > document > > requirements in that space. It's good that we push some requirements > > to > > ROLL on route-over, and that's certainly the right time to do so. > > > > To Jonathan: I do not completely agree that ISA100 is mesh under. The > > routing is not specified and left to the system manager > > implementation. > > My personal hope is to promote a ROLL solution in ISA100.11a next > > release. See > > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > > > > So the current release of ISA100.11a is at the same level as 6LoWPAN > > on > > the matter of routing. > > > > In a same fashion, ISA does not define the backbone operation, the > > fragment recovery mechanism or the Explicit Congestion Notification. > > For > > all those features, there's a hope at ISA that the IETF will come up > > with more generic solutions that they can apply. But time is running > > out. > > > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > > ISA will have to define everything on its own and hopefully publish an > > informational to this group. > > > > At the moment, the first draft of ISA100.11a is in letter ballot. The > > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, > > which > > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > > so ISA is using NaLP headers starting with b'00'. > > > > What ISA needs from 6LoWPAN in very short term is in that order: > > - promote Jonathan's draft as a convergence specification so ISA can > > at > > least use standard HC headers. > > This enables: non-Link-Local-Address compression > > Hops limit compression > > UDP checksum compression > > Better placement of HC2 > > Which are all mandatory for ISA100.11a > > - better define the NaLPs. > > There should be a way to indicate to a 6LoWPAN node whether a NaLP > > can > > be skipped and what its length is. > > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > > to report congestion. > > - specify a fragment flow control and recovery protocol at the 6LoWPAN > > Shim layer > > There is no rocket science in any of this and it all could/should be > > carried out swiftly. > > > > What ISA needs in longer term: > > - define backbone operation when the backbone federates multiple > > LoWPANs > > into a single link (or subnet, TBD). > > This is more theoretical work for us. Related to proxy ND, a new > > registration protocols, multilink subnet, etc... > > > > Pascal > > > >> -----Original Message----- > >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Jonathan Hui > >> Sent: jeudi 22 mai 2008 00:20 > >> To: Mark Townsley (townsley) > >> Cc: 6lowpan@ietf.org > >> Subject: Re: [6lowpan] New charter for 6lowpan > >> > >> > >> Hi Mark: > >> > >> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: > >>>> - To your point on ND, this is precisely why the architecture draft > >>>> is so important. We haven't given it as much attention lately, but > >>>> it will help resolve the question your raise and many other > >>>> questions in the future. For example, the architecture draft > >>>> identifies two modes of operation: mesh-under and route-over. Both > >>>> of which may require different ND mechanisms. This doesn't apply to > >>>> just ND, but may apply questions of fragmentation, header > >>>> compression, security, etc. > >>> I worry about the under/over debate. It seems that with all the > >>> effort and enthusiasm in ROLL, we might be well-served at the moment > >>> by focusing on helping them be successful with route-over than > >>> spending too much of our time on route-under. > >> > >> I worry too, especially since it will pull the WG in different > >> directions. I'm with you on the preference for route-over, but others > >> in this group feel strongly about mesh-under as well, especially > >> since > >> ISA100.11a seems to have adopted a mesh-under approach. I've > >> personally been focused on developing route-over solutions while > >> being > >> conscious of supporting mesh-under when possible (evident with > >> 6lowpan- > >> hc). However, things will start to diverge when we start to talk > >> about > >> bootstrapping, ND, etc. So we should make a conscious decision of > >> whether we're supporting one or both. > >> > >> -- > >> Jonathan Hui > >> > >>> > >>>> > >>>> - I hesitate a bit that we suggest possible solutions to ND in the > >>>> charter ("reusing the 802.15.4 network structure (use the > >>>> coordinators)") especially since the definition of such link > >>>> mechanisms are still in motion within the IEEE. It seems more > >>>> productive to me if we can develop mechanisms that are less > >>>> dependent on the specific structure of 802.15.4 mechanisms. > >>> I agree that we should develop mechanisms that could work > >>> generically whenever possible. > >>> > >>> - Mark > >>>> > >>>> Rest of the charter looks good to me. > >>>> > >>>> Thanks. > >>>> > >>>> -- > >>>> Jonathan Hui > >>>> > >>>> > >>>> > >>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: > >>>> > >>>>> Pascal Thubert (pthubert) wrote: > >>>>>> Hi Mark: > >>>>>> > >>>>>> I think we need a work item (usually implicit) around the concept > >>>>>> of > >>>>>> improving existing WG RFCs. RFC 4944 can be improved in several > >>>>>> aspects: > >>>>>> > >>>>> > >>>>>> > >>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a > >>>>>> to > >>>>>> conform to 6LoWPAN would be a major win, but is certainly not a > >>>>>> given. > >>>>>> At the moment, the ISA100.11a documents expose discrepencies with > >>>>>> RFC > >>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc > >>>>>> resolve > >>>>>> for the most part. > >>>>>> > >>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > > to > >>>>> improve RFC 4944, but not eager to endorse changes that inhibit > >>>>> interoperability. > >>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop > >>>>>> radio > >>>>>> mesh exposes the network to congestion collapse, as described in > >>>>>> > > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > >>>>>> overy . I think that the WG should dedicate some bandwitdth to > >>>>>> provide > >>>>>> additional functions that would improve the LoWPAN operation WRT > >>>>>> flow > >>>>>> control and recovery of fragments. > >>>>>> > >>>>> Fragmentation, OK, but why is flow control a network layer issue > >>>>> rather > >>>>> than a transport layer issue? > >>>>>> Another aspect of ISA100.11a is the concept of a backbone router. > >>>>>> It > >>>>>> would be appropriate that the IETF comes up with a proposal to > >>>>>> implement > >>>>>> the concept in the IPv6 world. This partially falls under the > >>>>>> first work > >>>>>> item on ND but might also include ND proxy over the backbone > >>>>>> which is a > >>>>>> stretch to the work item. More in > >>>>>> > > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > >>>>>> . > >>>>>> > >>>>> Well, don't we need to define what ND looks like on a lowpan > >>>>> before we > >>>>> decide whether it needs to be proxied or not? > >>>>> > >>>>> - Mark > >>>>>> What do you think? > >>>>>> > >>>>>> Pascal > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > >>>>>>> On > >>>>>>> > >>>>>> Behalf Of Mark Townsley > >>>>>> > >>>>>>> (townsley) > >>>>>>> Sent: jeudi 15 mai 2008 23:02 > >>>>>>> To: 6lowpan@ietf.org > >>>>>>> Subject: [6lowpan] New charter for 6lowpan > >>>>>>> > >>>>>>> > >>>>>>> I'd like to ask the group one final time for comments on the > >>>>>>> proposed > >>>>>>> new charter. I've also asked the ROLL WG chairs to comment. > >>>>>>> > >>>>>>> As I said before, soon after the format document was published, > >>>>>>> there > >>>>>>> > >>>>>> is > >>>>>> > >>>>>>> nothing stopping the WG from discussing and working on new and > >>>>>>> existing > >>>>>>> items at this time. In fact, activity helps us to decide what > >>>>>>> should be > >>>>>>> in and out of the charter. Please do not construe not having a > >>>>>>> charter > >>>>>>> in place as a reason not to update drafts, or discuss topics > >>>>>>> that need > >>>>>>> to be discussed. Just as when we have BoF's and mailing lists > >>>>>>> before > >>>>>>> creating a new WG, it is good to have WG meetings and on-lists > >>>>>>> discussions when creating new WG charters. > >>>>>>> > >>>>>>> - Mark > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 22 17:19:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66E3C3A6B30; Thu, 22 May 2008 17:19:05 -0700 (PDT) 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 E157A3A6B30; Thu, 22 May 2008 17:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av2qEGFMkaPw; Thu, 22 May 2008 17:19:02 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id A54B33A6C0D; Thu, 22 May 2008 17:18:46 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m4N0ITb7009945; Thu, 22 May 2008 18:18:29 -0600 (MDT) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> Date: Thu, 22 May 2008 18:18:37 -0600 Message-Id: <1211501917.23290.59.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Pascal, On Thu, 2008-05-22 at 09:47 +0200, Pascal Thubert (pthubert) wrote: > Hi: > > My understanding is that defining how mesh-under computes its routes is > out of scope for the IETF overall. I'm not even sure we need to document > requirements in that space. It's good that we push some requirements to > ROLL on route-over, and that's certainly the right time to do so. > I'm not completely positive that this is true, but I do think that it is not in the scope of 6lowpan right now. > To Jonathan: I do not completely agree that ISA100 is mesh under. The > routing is not specified and left to the system manager implementation. > My personal hope is to promote a ROLL solution in ISA100.11a next > release. See > http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > I have to disagree. While the system manager can choose some routing options, my understanding of the ISA100 DLL is that it does offer a mesh under layer 2. > So the current release of ISA100.11a is at the same level as 6LoWPAN on > the matter of routing. > > In a same fashion, ISA does not define the backbone operation, the > fragment recovery mechanism or the Explicit Congestion Notification. For > all those features, there's a hope at ISA that the IETF will come up > with more generic solutions that they can apply. But time is running > out. > > 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > ISA will have to define everything on its own and hopefully publish an > informational to this group. > > At the moment, the first draft of ISA100.11a is in letter ballot. The > current draft mostly applies 6loWPAN formats over ISA100.11a DLL, which > is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > so ISA is using NaLP headers starting with b'00'. And this still needs to be discussed in ISA100. I'm not sure that a NALP is the correct header and we have had this discussion in ISA100. I'm hoping that this will be corrected in a subsequent draft. > > What ISA needs from 6LoWPAN in very short term is in that order: > - promote Jonathan's draft as a convergence specification so ISA can at > least use standard HC headers. > This enables: non-Link-Local-Address compression > Hops limit compression > UDP checksum compression > Better placement of HC2 > Which are all mandatory for ISA100.11a I don't think that these are all mandatory. The problem with the current ISA100 draft is that there was a clear statement that ISA100 would be compliant with 6lowpan and the application layer has chosen not to be compliant and to try to push changes into 6lowpan to make 6lowpan compliant with ISA100. There is some concern that has been expressed that we are prematurely optimizing the headers. I'm not convinced that the benefits of saving 3 bytes outweighs un-thought-of issues that might come about because of these optimizations. > - better define the NaLPs. > There should be a way to indicate to a 6LoWPAN node whether a NaLP can > be skipped and what its length is. I'm not sure that 6lowpan should specify this. I think that is what a nalp is for. The bits following it are unknown. I think that ISA100 should apply for a dispatch value and should include a dll header length so that it can be skipped. > - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > to report congestion. > - specify a fragment flow control and recovery protocol at the 6LoWPAN > Shim layer > There is no rocket science in any of this and it all could/should be > carried out swiftly. > > What ISA needs in longer term: > - define backbone operation when the backbone federates multiple LoWPANs > into a single link (or subnet, TBD). > This is more theoretical work for us. Related to proxy ND, a new > registration protocols, multilink subnet, etc... > > Pascal > > >-----Original Message----- > >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jonathan Hui > >Sent: jeudi 22 mai 2008 00:20 > >To: Mark Townsley (townsley) > >Cc: 6lowpan@ietf.org > >Subject: Re: [6lowpan] New charter for 6lowpan > > > > > >Hi Mark: > > > >On May 20, 2008, at 8:24 AM, Mark Townsley wrote: > >>> - To your point on ND, this is precisely why the architecture draft > >>> is so important. We haven't given it as much attention lately, but > >>> it will help resolve the question your raise and many other > >>> questions in the future. For example, the architecture draft > >>> identifies two modes of operation: mesh-under and route-over. Both > >>> of which may require different ND mechanisms. This doesn't apply to > >>> just ND, but may apply questions of fragmentation, header > >>> compression, security, etc. > >> I worry about the under/over debate. It seems that with all the > >> effort and enthusiasm in ROLL, we might be well-served at the moment > >> by focusing on helping them be successful with route-over than > >> spending too much of our time on route-under. > > > >I worry too, especially since it will pull the WG in different > >directions. I'm with you on the preference for route-over, but others > >in this group feel strongly about mesh-under as well, especially since > >ISA100.11a seems to have adopted a mesh-under approach. I've > >personally been focused on developing route-over solutions while being > >conscious of supporting mesh-under when possible (evident with 6lowpan- > >hc). However, things will start to diverge when we start to talk about > >bootstrapping, ND, etc. So we should make a conscious decision of > >whether we're supporting one or both. > > > >-- > >Jonathan Hui > > > >> > >>> > >>> - I hesitate a bit that we suggest possible solutions to ND in the > >>> charter ("reusing the 802.15.4 network structure (use the > >>> coordinators)") especially since the definition of such link > >>> mechanisms are still in motion within the IEEE. It seems more > >>> productive to me if we can develop mechanisms that are less > >>> dependent on the specific structure of 802.15.4 mechanisms. > >> I agree that we should develop mechanisms that could work > >> generically whenever possible. > >> > >> - Mark > >>> > >>> Rest of the charter looks good to me. > >>> > >>> Thanks. > >>> > >>> -- > >>> Jonathan Hui > >>> > >>> > >>> > >>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: > >>> > >>>> Pascal Thubert (pthubert) wrote: > >>>>> Hi Mark: > >>>>> > >>>>> I think we need a work item (usually implicit) around the concept > >>>>> of > >>>>> improving existing WG RFCs. RFC 4944 can be improved in several > >>>>> aspects: > >>>>> > >>>> > >>>>> > >>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a > >>>>> to > >>>>> conform to 6LoWPAN would be a major win, but is certainly not a > >>>>> given. > >>>>> At the moment, the ISA100.11a documents expose discrepencies with > >>>>> RFC > >>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc > >>>>> resolve > >>>>> for the most part. > >>>>> > >>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > to > >>>> improve RFC 4944, but not eager to endorse changes that inhibit > >>>> interoperability. > >>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop > >>>>> radio > >>>>> mesh exposes the network to congestion collapse, as described in > >>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > >>>>> overy . I think that the WG should dedicate some bandwitdth to > >>>>> provide > >>>>> additional functions that would improve the LoWPAN operation WRT > >>>>> flow > >>>>> control and recovery of fragments. > >>>>> > >>>> Fragmentation, OK, but why is flow control a network layer issue > >>>> rather > >>>> than a transport layer issue? > >>>>> Another aspect of ISA100.11a is the concept of a backbone router. > >>>>> It > >>>>> would be appropriate that the IETF comes up with a proposal to > >>>>> implement > >>>>> the concept in the IPv6 world. This partially falls under the > >>>>> first work > >>>>> item on ND but might also include ND proxy over the backbone > >>>>> which is a > >>>>> stretch to the work item. More in > >>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > >>>>> . > >>>>> > >>>> Well, don't we need to define what ND looks like on a lowpan > >>>> before we > >>>> decide whether it needs to be proxied or not? > >>>> > >>>> - Mark > >>>>> What do you think? > >>>>> > >>>>> Pascal > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > >>>>>> On > >>>>>> > >>>>> Behalf Of Mark Townsley > >>>>> > >>>>>> (townsley) > >>>>>> Sent: jeudi 15 mai 2008 23:02 > >>>>>> To: 6lowpan@ietf.org > >>>>>> Subject: [6lowpan] New charter for 6lowpan > >>>>>> > >>>>>> > >>>>>> I'd like to ask the group one final time for comments on the > >>>>>> proposed > >>>>>> new charter. I've also asked the ROLL WG chairs to comment. > >>>>>> > >>>>>> As I said before, soon after the format document was published, > >>>>>> there > >>>>>> > >>>>> is > >>>>> > >>>>>> nothing stopping the WG from discussing and working on new and > >>>>>> existing > >>>>>> items at this time. In fact, activity helps us to decide what > >>>>>> should be > >>>>>> in and out of the charter. Please do not construe not having a > >>>>>> charter > >>>>>> in place as a reason not to update drafts, or discuss topics > >>>>>> that need > >>>>>> to be discussed. Just as when we have BoF's and mailing lists > >>>>>> before > >>>>>> creating a new WG, it is good to have WG meetings and on-lists > >>>>>> discussions when creating new WG charters. > >>>>>> > >>>>>> - Mark > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 23 00:49:53 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 860BD3A6C73; Fri, 23 May 2008 00:49:53 -0700 (PDT) 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 5113D3A6C01; Fri, 23 May 2008 00:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.042 X-Spam-Level: X-Spam-Status: No, score=-7.042 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hU+4KPN6hWi; Fri, 23 May 2008 00:49:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 58B473A6C73; Fri, 23 May 2008 00:48:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,528,1204498800"; d="scan'208";a="9701664" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 May 2008 09:48:41 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4N7me2u025569; Fri, 23 May 2008 09:48:40 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4N7mei9018997; Fri, 23 May 2008 07:48:41 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 May 2008 09:48:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 09:48:08 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B6148E@xmb-ams-337.emea.cisco.com> In-Reply-To: <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) Thread-Index: Aci8JwhP5EG8Whb3Sk+ZsgRvA4gH/gAga9Sg References: <482CA4DC.40508@cisco.com><7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com><482DD69F.7080304@cisco.com><208D4602-AE7F-457E-9377-962968881CDE@archrock.com><4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 23 May 2008 07:48:40.0838 (UTC) FILETIME=[6ADC5A60:01C8BCA9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11329; t=1211528920; x=1212392920; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20ISA100.11a=20=20status=20and=20requirem ents=20(was=20RE=3A=20[6lowpan]=20New=20charter=20for=206low pan) |Sender:=20; bh=BwVStKpvilR8NbcWaf/BU+WrLibosktc5qOIQv4dgSw=; b=v8AUIUha351RAGGGYhgel7Nwem7h9oXG50KNYyn7f1u7rc/K9Fp+IQCiNE wjqL08AEBghQa7nms7+/esCd9GP/RfKvciCJUdrfu4lgqbiyWcMU+LR/40kc yPNKoht147; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org, "Polyzois, Christos A" Subject: Re: [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: I agree we need a definition of mesh under; and that we have not found one yet that satisties us all. For me, mesh under is when L2 takes care of the connectivity between nodes and L3 sees everyone on the media. E.g. NBMA. And route over is when IP has to take care of routing between nodes. E.g. P2MP. What is important is that the route over has an end to end scope across the radio hops and the rest of the way. Whereas mesh under optimizes within the mesh but could create an overall poor end to end path, like a zig zag. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: jeudi 22 mai 2008 18:14 >To: Pascal Thubert (pthubert) >Cc: Mark Townsley (townsley); 6lowpan@ietf.org; Jay Werb; Polyzois, Christos A; Chernoguzov, >Alexander (PA35); Robert Assimiti; roll@ietf.org >Subject: Re: ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan) > > >Hi Pascal, > >So let's drop the mesh-under/route-over terminology for a second, I >think they are confusing since everyone seems to have a different >definition for those terms. > >What I am mainly concerned about is the kind of IP Link abstraction >6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. >802.15.4 and possible others through a BbR), what I've been calling >mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >radio range of 802.15.4), what I've been calling route-over. My point >to Mark's concern was that solutions to some work items within 6LoWPAN >will be different depending on our IP Link abstraction. From what I >understand, ISA100.11a has chosen option (i). But to your point below, >using IP routing to provide connectivity between nodes within the same >IP Link doesn't seem right to me, so it'd be great if you could help >me see a path to get there. > >A lot of this confusion can be cleaned up within the 6LoWPAN >architecture document. But I think Mark's concern still stands: >whether or not we're focused on one or both of these IP Link >abstractions. > >-- >Jonathan Hui > >On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: > >> Hi: >> >> My understanding is that defining how mesh-under computes its routes >> is >> out of scope for the IETF overall. I'm not even sure we need to >> document >> requirements in that space. It's good that we push some requirements >> to >> ROLL on route-over, and that's certainly the right time to do so. >> >> To Jonathan: I do not completely agree that ISA100 is mesh under. The >> routing is not specified and left to the system manager >> implementation. >> My personal hope is to promote a ROLL solution in ISA100.11a next >> release. See >> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >> >> So the current release of ISA100.11a is at the same level as 6LoWPAN >> on >> the matter of routing. >> >> In a same fashion, ISA does not define the backbone operation, the >> fragment recovery mechanism or the Explicit Congestion Notification. >> For >> all those features, there's a hope at ISA that the IETF will come up >> with more generic solutions that they can apply. But time is running >> out. >> >> 6LoWPAN hasn't produced anything for the last 6 months. At this rate, >> ISA will have to define everything on its own and hopefully publish an >> informational to this group. >> >> At the moment, the first draft of ISA100.11a is in letter ballot. The >> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >> which >> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN >> so ISA is using NaLP headers starting with b'00'. >> >> What ISA needs from 6LoWPAN in very short term is in that order: >> - promote Jonathan's draft as a convergence specification so ISA can >> at >> least use standard HC headers. >> This enables: non-Link-Local-Address compression >> Hops limit compression >> UDP checksum compression >> Better placement of HC2 >> Which are all mandatory for ISA100.11a >> - better define the NaLPs. >> There should be a way to indicate to a 6LoWPAN node whether a NaLP >> can >> be skipped and what its length is. >> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes >> to report congestion. >> - specify a fragment flow control and recovery protocol at the 6LoWPAN >> Shim layer >> There is no rocket science in any of this and it all could/should be >> carried out swiftly. >> >> What ISA needs in longer term: >> - define backbone operation when the backbone federates multiple >> LoWPANs >> into a single link (or subnet, TBD). >> This is more theoretical work for us. Related to proxy ND, a new >> registration protocols, multilink subnet, etc... >> >> Pascal >> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Jonathan Hui >>> Sent: jeudi 22 mai 2008 00:20 >>> To: Mark Townsley (townsley) >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> >>> Hi Mark: >>> >>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>> - To your point on ND, this is precisely why the architecture draft >>>>> is so important. We haven't given it as much attention lately, but >>>>> it will help resolve the question your raise and many other >>>>> questions in the future. For example, the architecture draft >>>>> identifies two modes of operation: mesh-under and route-over. Both >>>>> of which may require different ND mechanisms. This doesn't apply to >>>>> just ND, but may apply questions of fragmentation, header >>>>> compression, security, etc. >>>> I worry about the under/over debate. It seems that with all the >>>> effort and enthusiasm in ROLL, we might be well-served at the moment >>>> by focusing on helping them be successful with route-over than >>>> spending too much of our time on route-under. >>> >>> I worry too, especially since it will pull the WG in different >>> directions. I'm with you on the preference for route-over, but others >>> in this group feel strongly about mesh-under as well, especially >>> since >>> ISA100.11a seems to have adopted a mesh-under approach. I've >>> personally been focused on developing route-over solutions while >>> being >>> conscious of supporting mesh-under when possible (evident with >>> 6lowpan- >>> hc). However, things will start to diverge when we start to talk >>> about >>> bootstrapping, ND, etc. So we should make a conscious decision of >>> whether we're supporting one or both. >>> >>> -- >>> Jonathan Hui >>> >>>> >>>>> >>>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>>> charter ("reusing the 802.15.4 network structure (use the >>>>> coordinators)") especially since the definition of such link >>>>> mechanisms are still in motion within the IEEE. It seems more >>>>> productive to me if we can develop mechanisms that are less >>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>> I agree that we should develop mechanisms that could work >>>> generically whenever possible. >>>> >>>> - Mark >>>>> >>>>> Rest of the charter looks good to me. >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Hi Mark: >>>>>>> >>>>>>> I think we need a work item (usually implicit) around the concept >>>>>>> of >>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>>> aspects: >>>>>>> >>>>>> >>>>>>> >>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>>> to >>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>>> given. >>>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>>> RFC >>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>>> resolve >>>>>>> for the most part. >>>>>>> >>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager >> to >>>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>>> interoperability. >>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>>> radio >>>>>>> mesh exposes the network to congestion collapse, as described in >>>>>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>>> provide >>>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>>> flow >>>>>>> control and recovery of fragments. >>>>>>> >>>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>>> rather >>>>>> than a transport layer issue? >>>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>>> It >>>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>>> implement >>>>>>> the concept in the IPv6 world. This partially falls under the >>>>>>> first work >>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>> which is a >>>>>>> stretch to the work item. More in >>>>>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>>> . >>>>>>> >>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>> before we >>>>>> decide whether it needs to be proxied or not? >>>>>> >>>>>> - Mark >>>>>>> What do you think? >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>>> On >>>>>>>> >>>>>>> Behalf Of Mark Townsley >>>>>>> >>>>>>>> (townsley) >>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>> To: 6lowpan@ietf.org >>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>> >>>>>>>> >>>>>>>> I'd like to ask the group one final time for comments on the >>>>>>>> proposed >>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>> >>>>>>>> As I said before, soon after the format document was published, >>>>>>>> there >>>>>>>> >>>>>>> is >>>>>>> >>>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>>> existing >>>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>>> should be >>>>>>>> in and out of the charter. Please do not construe not having a >>>>>>>> charter >>>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>>> that need >>>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>>> before >>>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>>> discussions when creating new WG charters. >>>>>>>> >>>>>>>> - Mark >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 6lowpan-bounces@ietf.org Fri May 23 03:51:40 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FA83A6A16; Fri, 23 May 2008 03:51:40 -0700 (PDT) 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 E10663A69D1 for <6lowpan@core3.amsl.com>; Fri, 23 May 2008 03:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.708 X-Spam-Level: X-Spam-Status: No, score=-6.708 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 sM1fSJY6lkyq for <6lowpan@core3.amsl.com>; Fri, 23 May 2008 03:51:34 -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 AE8A93A69D4 for <6lowpan@ietf.org>; Fri, 23 May 2008 03:51:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,529,1204498800"; d="scan'208";a="9726906" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 May 2008 12:51:30 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4NApUwO023950 for <6lowpan@ietf.org>; Fri, 23 May 2008 12:51:30 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4NApU4l006213 for <6lowpan@ietf.org>; Fri, 23 May 2008 10:51:30 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 May 2008 12:51:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 12:50:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci6jMxrYwQCzYkZQ8m3LENi5fv8UQABVvLgAGfanaEAH2mnYA== References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Jean Philippe Vasseur (jvasseur)" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 23 May 2008 10:51:30.0092 (UTC) FILETIME=[F50BAEC0:01C8BCC2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4592; t=1211539890; x=1212403890; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=SnRI4yEDyYpwnfdWEsd1wN+yDMNOKAmNjMwhCORHA/c=; b=U6LpkZ4mSZfZY8ANc/oWW61MkurpQCl+IMNL0yl+YfCuOh+dPQ1MPZs6vV wq6pgEInBIIfHfrzCSxY2AYWY056hQEGPlaHr65dtzII6nUsZq+XH1DIgLo7 +Y9s6m38AM; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi JP: I see your concern. I'd argue that ECN is now pretty well defined now in RFC 3168, and that the basic operation is pretty simple: emulate a packet loss in RED but save the packet. So the real problem is not ECN itself but what RED becomes in a LowPAN forwarding node. And that is something that the node will have to define whether it does ECN or RED. If we do not have ECN then the LowPAN forwarding nodes will have to destroy frames which might be fragments. Considering the cost of energy and bandwidth to getting the frame up to that forwarding node, the latency introduced by transport layer time out, and the risk of congestion collapse introduced by resending the whole segment, I'd suggest that ECN is actually a good idea. Please have a careful look at: http://www.ietf.org/internet-drafts/draft-thubert-6lowpan-simple-fragmen t-recovery-01.txt that I just update with additions on flow control operation and ECN-echo support. Pascal >-----Original Message----- >From: Jean Philippe Vasseur (jvasseur) >Sent: jeudi 22 mai 2008 16:31 >To: Pascal Thubert (pthubert); Mark Townsley (townsley) >Cc: 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > >Hi Pascal, > >Just a word of cautious though. It is not the number of needed bits that >matters here but what you do with them. ECN is clearly a fairly big WG item >(Look at the history of IP in that area or even FR by the way where several >pretty sophisticated mechanisms had been designed to handle this - or >trivial task). I would personally suggest to not add this to the WG charter >for the moment. > >Thanks. > >JP. > > >On 5/20/08 9:01 AM, "Pascal Thubert (pthubert)" wrote: > >> Hi Again Mark: >> >> Another aspect of this is ECN. We do not have room for Explicit >> Congestion Notification in the 6LoWPAN headers. ECN only takes 2 bits in >> Frame Relay and in IP, though the bits are used differently. I have in >> mind that the FR version with forward and backward bits is a better fit >> if it acts upon the fragment flow control, though the FECN could then be >> mapped into IP ECN. >> >> This is additional work to the fragment recovery and I'm taking great >> care to present them separate. But it could become an interesting >> feature in some future as well. >> >> Pascal >> >>> -----Original Message----- >>> From: Mark Townsley (townsley) >>> Sent: mardi 20 mai 2008 17:18 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi again Mark >>>> >>>> >>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >> radio >>>>>> mesh exposes the network to congestion collapse, as described in >>>>>> >>>>>> >>>> >> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>> >>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>> >>>> provide >>>> >>>>>> additional functions that would improve the LoWPAN operation WRT >> flow >>>>>> control and recovery of fragments. >>>>>> >>>>>> >>>>> Fragmentation, OK, but why is flow control a network layer issue >> rather >>>>> than a transport layer issue? >>>>> >>>> >>>> [Pascal] I'm talking about flow control on the fragments themselves; >>>> this is either a LLC (the likes of 802.2 or LAPB) or a shim layer >> above >>>> LLC problem (that would be us). The 802.15.4 MAC/PHY was not design >> to >>>> cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 >> bytes >>>> minimum, it causes a burst of fragments that should be paced and >>>> windowed. I suggest we do it in 6LoWPAN and handle the consequences >> of >>>> our own fragmentation rather than rely on a LLC mechanism that might >> not >>>> be there or adapted. >>>> >>> OK, that makes sense. Of course, if the higher layer transports >> consider >>> this fragmented packet lost and retransmit in the mean time we will end >>> up thrashing. We need to be very wary of the higher-layer transport >>> affects. And, of course this isn't the first time I've thought we might >>> need ot spin up a transport-area lowpan WG similar to what we did with >>> ROLL. But, sometimes its hard enough to keep 2 working groups working >>> and making progress, much less 3. >>> >>> - Mark >>>> Pascal >>>> >>>> >>>> >> >> _______________________________________________ >> 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 6lowpan-bounces@ietf.org Fri May 23 06:33:06 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA06528C26B; Fri, 23 May 2008 06:33:06 -0700 (PDT) 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 07E9128C259 for <6lowpan@core3.amsl.com>; Fri, 23 May 2008 06:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.694 X-Spam-Level: X-Spam-Status: No, score=-6.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 55iueg2F6M8Q for <6lowpan@core3.amsl.com>; Fri, 23 May 2008 06:33:04 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9FAAC28C0DB for <6lowpan@ietf.org>; Fri, 23 May 2008 06:33:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,529,1204498800"; d="scan'208";a="9746908" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 May 2008 15:32:59 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4NDWx73005269 for <6lowpan@ietf.org>; Fri, 23 May 2008 15:32:59 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4NDWw42006517 for <6lowpan@ietf.org>; Fri, 23 May 2008 13:32:59 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 May 2008 15:32:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 May 2008 15:31:39 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05B616DE@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-01 Thread-Index: Aci8wxIh2xlcd/nbSZ+skp4lHgyMUgAFhFlw From: "Pascal Thubert (pthubert)" To: <6lowpan@ietf.org> X-OriginalArrivalTime: 23 May 2008 13:32:12.0305 (UTC) FILETIME=[6840A010:01C8BCD9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=913; t=1211549579; x=1212413579; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-thubert-6lowpan-simple-fragment-recovery-01=20 |Sender:=20; bh=YElQ3IksDwjmNWWjcfvZS7PCAEX8anvfbavAZmBPRuM=; b=AF1TdhpjdE4apr1byE2X7vs/ojcXjrq82mPfKDiaHExElaAkABu4EVPf9/ BZm+PmM9kumZcO/sr7poofSbjABsKtza9R4yYLHvoPw7zJ99hAQ/0XX1UNEw FCCpTwS4He; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] FW: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery-01 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org A new version of I-D, draft-thubert-6lowpan-simple-fragment-recovery-01.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository. Filename: draft-thubert-6lowpan-simple-fragment-recovery Revision: 01 Title: LoWPAN simple fragment Recovery Creation_date: 2008-05-23 WG ID: Independent Submission Number_of_pages: 12 Abstract: Considering that 6LoWPAN packets can be as large as 2K bytes and that an 802.15.4 frame with security will carry in the order of 80 bytes of effective payload, a packet might end up fragmented into as many as 25 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to recover individual fragments between 6LoWPAN endpoints. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 23 11:16:27 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0076028C2C7; Fri, 23 May 2008 11:16:27 -0700 (PDT) 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 56A0A28C2CA for <6lowpan@core3.amsl.com>; Fri, 23 May 2008 11:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opBvcPgTvXTj for <6lowpan@core3.amsl.com>; Fri, 23 May 2008 11:16:21 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 038B128C278 for <6lowpan@ietf.org>; Fri, 23 May 2008 11:16:21 -0700 (PDT) Received: from dnab423328.stanford.edu ([171.66.51.40]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1JzboS-00079h-ER; Fri, 23 May 2008 11:16:20 -0700 Message-Id: <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> From: Philip Levis To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 23 May 2008 10:45:35 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: > Hi JP: > > I see your concern. > > I'd argue that ECN is now pretty well defined now in RFC 3168, and > that > the basic operation is pretty simple: emulate a packet loss in RED but > save the packet. So the real problem is not ECN itself but what RED > becomes in a LowPAN forwarding node. And that is something that the > node > will have to define whether it does ECN or RED. > > If we do not have ECN then the LowPAN forwarding nodes will have to > destroy frames which might be fragments. Considering the cost of > energy > and bandwidth to getting the frame up to that forwarding node, the > latency introduced by transport layer time out, and the risk of > congestion collapse introduced by resending the whole segment, I'd > suggest that ECN is actually a good idea. This gets back to the point I brought up December 14, 2006. In lossy networks, end-to-end fragmentation and assembly is a real problem. It makes much more sense to do per-hop fragmentation and assembly. In the former, the number of retransmitted fragments is exponential in the number of hops; in the latter, it is linear. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon May 26 07:18:47 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41483A6BAC; Mon, 26 May 2008 07:18:47 -0700 (PDT) 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 DB6043A68A9 for <6lowpan@core3.amsl.com>; Mon, 26 May 2008 07:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.683 X-Spam-Level: X-Spam-Status: No, score=-6.683 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 av1sWedP3o9x for <6lowpan@core3.amsl.com>; Mon, 26 May 2008 07:18:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8E8053A6B8A for <6lowpan@ietf.org>; Mon, 26 May 2008 07:18:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,542,1204498800"; d="scan'208";a="9910319" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 26 May 2008 16:18:35 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4QEIZTQ015208; Mon, 26 May 2008 16:18:35 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4QEIYpT029373; Mon, 26 May 2008 14:18:34 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 May 2008 16:18:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 16:18:01 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> In-Reply-To: <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: Aci9ATbenq/OAlF/TpqjW8euNoJlUgCOEaEA References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Jonathan Hui" X-OriginalArrivalTime: 26 May 2008 14:18:34.0890 (UTC) FILETIME=[620AA6A0:01C8BF3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2401; t=1211811515; x=1212675515; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=THMLS+meqB9IuMOpjPh71OwlCKxayDAO7XDstJ4QTVo=; b=jglTUfvmxNc6B0zQaXeXTKeZ0b1ty7GYEblQ8AH7WdS8BrLvoC3/5PZTJL T159Hw1TRFgvwsNgEYH4Kt7IT5N0TGdUUezw7sOiEycolw48GhTcWX8ktE8j 2zo/ZypFcG; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Phil: We do agree on the problem. Per-hop reassembly, though, comes at the expense of that traffic fluidity that was so desirable to the ATM designers. In other words, because per-hop reassembly forces each intermediate node to store and forward a full packet, it is augmenting the latency of the flow and the memory requirements on the forwarding nodes on the way. This is why I had in mind to couple a few per-hop recovery with a more solid end-to-end recovery and flow control mechanism between the LoWPAN endpoints. Now I wonder what this discussion becomes in route over v.s. mesh under. In route over, it seems that the forwarding node terminates a link so it has to reassemble before it forwards on a different link that might or might not be a LoWPAN; so maybe we end up doing the same thing in that case. Jonathan, what do you think? Pascal >-----Original Message----- >From: Philip Levis [mailto:pal@cs.stanford.edu] >Sent: vendredi 23 mai 2008 19:46 >To: Pascal Thubert (pthubert) >Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > > >On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: > >> Hi JP: >> >> I see your concern. >> >> I'd argue that ECN is now pretty well defined now in RFC 3168, and >> that >> the basic operation is pretty simple: emulate a packet loss in RED but >> save the packet. So the real problem is not ECN itself but what RED >> becomes in a LowPAN forwarding node. And that is something that the >> node >> will have to define whether it does ECN or RED. >> >> If we do not have ECN then the LowPAN forwarding nodes will have to >> destroy frames which might be fragments. Considering the cost of >> energy >> and bandwidth to getting the frame up to that forwarding node, the >> latency introduced by transport layer time out, and the risk of >> congestion collapse introduced by resending the whole segment, I'd >> suggest that ECN is actually a good idea. > >This gets back to the point I brought up December 14, 2006. In lossy >networks, end-to-end fragmentation and assembly is a real problem. It >makes much more sense to do per-hop fragmentation and assembly. In the >former, the number of retransmitted fragments is exponential in the >number of hops; in the latter, it is linear. > >Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 27 02:29:54 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4594C3A68C2; Tue, 27 May 2008 02:29:54 -0700 (PDT) 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 D9F8F3A682D for <6lowpan@core3.amsl.com>; Tue, 27 May 2008 02:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 v-pIKGTnHKuo for <6lowpan@core3.amsl.com>; Tue, 27 May 2008 02:29:51 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) by core3.amsl.com (Postfix) with ESMTP id 629893A6784 for <6lowpan@ietf.org>; Tue, 27 May 2008 02:29:50 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.1/8.13.1) with ESMTP id m4R9TOXd019147; Tue, 27 May 2008 11:29:25 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 24A362CBCFC; Tue, 27 May 2008 12:28:55 +0200 (CEST) Received: from 193.184.21.116 by webmail.entel.upc.edu with HTTP; Tue, 27 May 2008 11:29:19 +0200 (CEST) Message-ID: <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> In-Reply-To: <4832F276.70406@cisco.com> References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> Date: Tue, 27 May 2008 11:29:19 +0200 (CEST) From: "Carles Gomez Montenegro" To: "Mark Townsley" User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 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 (dash.upc.es [147.83.2.50]); Tue, 27 May 2008 11:29:40 +0200 (CEST) Cc: 6lowpan@ietf.org, roll-chairs@tools.ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark, I would like to answer to one of the questions you raised regarding the mesh-under Vs. route-over paradigms. > Is there anything that the L3 > "route-over" model might not provide that is listed as a requirement for > 6lowpan's "route-under" model? At least, there are the following items listed in the routing requirements draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) that route-over approach cannot provide or would provide only in a limited way: - [R03] (use of 802.15.4 link layer feedback for power efficient operation) - [R05] (use of mesh-under neighbor discovery for 6LoWPAN) - [R06] (use of 802.15.4 beacons to deal with hibernating/unresponsive nodes) - [R09] (about exploiting 802.15.4 join/leave messages) - [R11] (on applying security mechanisms of 802.15.4 for securing the routing protocol). - [R12] (802.15.4 constraint on message sizes due to its small MTU) - [R13] (on using 802.15.4 link layer feedback for link connectivity maintenance) - [R14] (on taking advantage of the LQI parameter, which is very critical in routing decisions in 802.15.4 environments) In my opinion, the "routing link and node metric" ROLL item can only partially capture some of the specificities that may affect routing in 802.15.4 environments. Even if LQI parameter can be provided from 802.15.4 to layer three, all the specific 802.15.4 features (see the list above) can only be fully exploited following a mesh-under approach. Hence, in my opinion, routing decisions and efficiency of routing protocol operation within a LoWPAN would be seriously limited if a route-over approach was followed. Thanks, Carles > Eunsook "Eunah" Kim wrote: >> Dear AD, and chairmen, >> >> It's good to finally see official rechater text. >> > It's only proposed text. >> I think it's pretty well delivering our discussion of rechartering so >> far, EXCEPT one part; 6lowpan routing requirement. >> Last meeting (71th IETF), we discussed RR matter and agreed to see >> IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember >> correctly, we would keep this work with alignment with ROLL, as long >> as it's not duplicate work with ROLL. >> > You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what > are your expectations from 6lowpan with respect to the > routing-requirements document? > > http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt > > I have some more questions for you specifically: > > Should that be pulled into roll, or left in 6lowpan? Is roll considering > the L2"route-under" model at all? Is there anything that the L3 > "route-over" model might not provide that is listed as a requirement for > 6lowpan's "route-under" model? If 6lowpan were to work on an L2 > "route-under" model, would there be constructs (e.g., the routing > protocol itself and any low-power modifications) from ROLL that we would > invariably want to try and reuse? >> I would like to know if it is implied that the RR work is included in >> Architecture work, OR, if you have *intentionally* excluded the work. >> >> If the first case, I would suggest 6LoWPANers check the updated >> version (-05) of draft. We updated our RR draft (-05) after the >> meeting based on the meeting discussion, and circulated to the mailing >> list. >> >> If the second case, I think we should get a chance to discuss the >> updated version. If the meeting decide the fate of this work after >> that, I would accept it. However, I have problem if AD or chairmen >> simply exclude this item without such discussion and concensus >> > There has never been any intention to go against consensus or limit > discussion on this topic. So, let's use this thread to get to the bottom > of what we want to do as a group here. > > - Mark >> Would you please clarify it to me? >> >> Thanks, >> >> -eunah >> >> On Thu, May 15, 2008 at 11:02 PM, Mark Townsley >> wrote: >> >>> I'd like to ask the group one final time for comments on the proposed >>> new >>> charter. I've also asked the ROLL WG chairs to comment. >>> >>> As I said before, soon after the format document was published, there >>> is >>> nothing stopping the WG from discussing and working on new and existing >>> items at this time. In fact, activity helps us to decide what should be >>> in >>> and out of the charter. Please do not construe not having a charter in >>> place >>> as a reason not to update drafts, or discuss topics that need to be >>> discussed. Just as when we have BoF's and mailing lists before creating >>> a >>> new WG, it is good to have WG meetings and on-lists discussions when >>> creating new WG charters. >>> >>> - Mark >>> >>> >>> >>> >>> >>> >>> Background/Introduction: >>> >>> Note: Given that there is not much precedent for this type of activity >>> at the IETF, the text that follows is of an introductory >>> nature. Hence, its objective is to give a general idea of the >>> application area and motivations for the work. In particular, this >>> section is not to be construed as detailing work items for the working >>> group. That is done in the following section entitled "Scope of the >>> Working Group." >>> >>> Well-established fields such as control networks, and burgeoning ones >>> such as "sensor" (or transducer) networks, are increasingly being >>> based on wireless technologies. Most (but certainly not all) of these >>> nodes are amongst the most constrained that have ever been networked >>> wirelessly. Extreme low power (such that they will run potentially for >>> years on batteries) and extreme low cost (total device cost in single >>> digit dollars, and riding Moore's law to continuously reduce that >>> price point) are seen as essential enablers towards their deployment >>> in networks with the following characteristics: >>> >>> * Significantly more devices than current networks >>> >>> * Severely limited code and ram space (e.g., highly desirable to >>> fit the required code--MAC, IP and anything else needed to >>> execute the embedded application-- in, for example, 32K of flash >>> memory, using 8-bit microprocessors) >>> >>> * Unobtrusive but very different user interface for configuration >>> (e.g., using gestures or interactions involving the physical >>> world) >>> >>> * Robustness and simplicity in routing or network fabric >>> >>> A chief component of these devices is wireless communication >>> technology. In particular, the IEEE 802.15.4 standard is very >>> promising for the lower (physical and link) layers. As for higher >>> layer functions, there is considerable interest from non-IETF groups >>> in using IP technology (the ZigBee alliance, for example, is currently >>> studying what such a work item might entail). The working group is >>> expected to coordinate and interact with such groups. >>> >>> The required work includes items in the following (incomplete) list: >>> >>> * IP adaptation/Packet Formats and interoperability >>> * Addressing schemes and address management >>> * Network management >>> * Routing in dynamically adaptive topologies >>> * Security, including set-up and maintenance >>> * Application programming interface >>> * Discovery (of devices, of services, etc) >>> * Implementation considerations >>> >>> Whereas at least some of the above items are within the purview of the >>> IETF, at this point it is not clear that all of them are. Accordingly, >>> the 6LoWPAN working group will address a reduced, more focused set of >>> objectives. >>> >>> Scope of 6lowpan: >>> >>> Produce "Problems Statement, Assumptions and Goals for IPv6 for >>> LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the >>> problem statement and goals of 6lowpan networks. >>> >>> Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN >>> Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the >>> basic packet formats and sub-IP adaptation layer for transmission of >>> IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, >>> header compression and address generation. Furthermore, IEEE 802.15.4 >>> devices are expected to be deployed in mesh topologies. >>> >>> As such, the working group may also work on an informational document >>> to show how to apply an existing MANET protocol to LoWPANs (e.g., >>> AODV, OLSR, DYMO, etc). >>> >>> The working group will reuse existing specifications whenever >>> reasonable and possible. >>> >>> The working group will also serve as a venue for ongoing discussions >>> on other topics related to the more complete list outlined above. >>> Additional related milestones may be added in the future via a >>> rechartering operation. >>> >>> Note: As may be obvious from its official name above, this particular >>> working group will not work on IPv4 over IEEE 802.15.4 specifications. >>> Given the limitations of the target devices, dual-stack deployments >>> are not practical. Because of its higher potential for header >>> compression, its support for the huge number of devices expected and >>> of cleanly built-in features such as address autoconfiguration, IPv6 >>> is the exclusive focus of the working group. >>> Goals and Milestones: >>> Done Working group last call on >>> draft-ietf-lowpan-goals-assumptions-xx.txt >>> Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to >>> IESG >>> for consideration of publication as Informational >>> Done Working Group Last Call on >>> draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt >>> Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to >>> IESG >>> for consideration of publication as Proposed Standard >>> >>> >>> >>> Background/Introduction: >>> >>> Note: Given that there is not much precedent for this type of activity >>> at the IETF, the text that follows is of an introductory >>> nature. Hence, its objective is to give a general idea of the >>> application area and motivations for the work. In particular, this >>> section is not to be construed as detailing work items for the working >>> group. That is done in the following section entitled "Scope of the >>> Working Group." >>> >>> Well-established fields such as control networks, and burgeoning ones >>> such as "sensor" (or transducer) networks, are increasingly being >>> based on wireless technologies. Most (but certainly not all) of these >>> nodes are amongst the most constrained that have ever been networked >>> wirelessly. Extreme low power (such that they will run potentially for >>> years on batteries) and extreme low cost (total device cost in single >>> digit dollars, and riding Moore's law to continuously reduce that >>> price point) are seen as essential enablers towards their deployment >>> in networks with the following characteristics: >>> >>> * Significantly more devices than current local area networks >>> >>> * Severely limited code and ram space (e.g., highly desirable to fit >>> the required code--MAC, IP and anything else needed to execute the >>> embedded application-- in, for example, 32K of flash memory, using >>> 8-bit microprocessors) >>> >>> * Unobtrusive but very different user interface for configuration >>> (e.g., using gestures or interactions involving the physical world) >>> >>> A chief component of these devices is wireless communication >>> technology. In particular, the IEEE 802.15.4 standard is very >>> promising for the lower (physical and link) layers. As for higher >>> layer functions, there is considerable interest from non-IETF groups >>> in using IP technology. The IEEE 1451.5 standard for wireless >>> transducers has a chapter for 6LoWPAN and the ISA SP100 standard for >>> wireless industrial networks has adopted 6LoWPAN for their network >>> layer. This working group is expected to coordinate and interact with >>> such groups. >>> >>> Description of Working Group: >>> >>> The working group has completed two RFCs: "IPv6 over Low-Power >>> Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, >>> Problem Statement, and Goals" (RFC4919) that documents and discusses >>> the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 >>> Networks" (RFC4944) which defines the format for the adaptation >>> between IPv6 and 802.15.4. >>> >>> The Working Group will generate the necessary documents to enusre >>> interoperable implementations of 6LoWPAN networks and will define the >>> necessary security and management protocols and constructs for build >>> 6LoWPAN networks, paying particular attention to protocols already >>> available. >>> >>> Work Items: >>> >>> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" >>> to define the required optimizations to make IPv6 ND applicable in >>> 6lowpans, given the fact that IPv6 ND is too expensive for the devices >>> of 6lowpan and requires multicast. >>> >>> This document (or these documents - as the working group delves into >>> this topic it may determine that this should be two separate >>> documents) will define how to bootstrap a 6lowpan network and explore >>> ND optimizations such as reusing the 802.15.4 network structure (use >>> the coordinators), and obviate multicast by having devices talk to >>> coordinators without creating a single point-of-failure, and changing >>> the IPv6 ND multicast semantics. This document will be a proposed >>> standard. >>> >>> 2. Produce "Problem Statement for Stateful Header Compression in >>> 6lowpans" to document the problem of using stateful header compression >>> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of >>> stateless header compression given the assumption that stateful header >>> compression may be too complex. This document will determine if the >>> assumption is correct and will be an informational document. The WG >>> will determine if the assumption is correct at this time and record >>> the findings in this informational document. >>> >>> 3. Produce "6LoWPAN Architecture" to describe the design and >>> implementation of 6LoWPAN networks. This document will cover the >>> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, >>> network components, addressing, and IPv4/IPv6 network connections. >>> >>> 4. Produce "Recommendations for 6lowpan Applications" to define a set >>> of recommendations of protocols to use for applications. The >>> recommendations will cover protocols for transport, application layer, >>> discovery, configuration and commissioning. This document will be an >>> informational document. >>> >>> 5. Produce "6lowpan Security Analysis" to define the threat model of >>> 6lowpans and to document suitability of existing key management >>> schemes and to discuss bootstrapping/installation/commissioning/setup >>> issues. This document will be an informational document. >>> >>> The working group will continue to reuse existing protocols and >>> mechanisms whenever reasonable and possible. >>> >>> Goals and Milestones: >>> >>> Jan 2008 - First Draft of Bootstrapping and ND Optimization document >>> Feb 2008 - First Draft of Stateful Header Compression document >>> Dec 2007 - First Draft of 6LoWPAN Architecture docuement >>> Feb 2008 - First Draft of Applications document >>> Mar 2008 - First Draft of Security Analysis >>> Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to >>> be considered as Proposed Standard >>> Jul 2008 - Submit Stateful Header Compression document to IESG to be >>> considered as Proposed Standard >>> May 2008 - Submit Architecture docuement to IESG to be considered as >>> Informational RFC >>> Jul 2008 - Submit Applications docuement to IESG to be considered as >>> Informational RFC >>> Sep 2008 - Submit Security Analysis document to IESG to be considered >>> as Informational RFC. >>> >>> >>> >>> _______________________________________________ >>> 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 6lowpan-bounces@ietf.org Tue May 27 09:29:57 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062683A6A1A; Tue, 27 May 2008 09:29:57 -0700 (PDT) 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 77B2B3A687B for <6lowpan@core3.amsl.com>; Tue, 27 May 2008 09:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 digcK9l090un for <6lowpan@core3.amsl.com>; Tue, 27 May 2008 09:29:54 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 9AB603A6C5E for <6lowpan@ietf.org>; Tue, 27 May 2008 09:26:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 35A13A920A; Tue, 27 May 2008 09:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18jmOCFzehTG; Tue, 27 May 2008 09:26:35 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id C1CA1A9389; Tue, 27 May 2008 09:26:35 -0700 (PDT) Message-Id: <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 09:26:35 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.919.2) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, I see a few underlying issues in this discussion. First is whether or not route-over implies complete reassembly at every hop. In my view, it doesn't. A node could simply cache the datagram tag when the first fragment arrives and forward the subsequent fragments accordingly. Note that this also saves header overhead because the mesh header doesn't have to be included in every fragment. When forwarding between different links, reassembly has to happen anyway. The second issue is whether or not we constrain forwarding fragments of a given datagram to a single path. This is where mesh-under and route-over diverge. But to me, there are a lot of advantages to constraining delivery of a datagram to a single path. Hop-by-hop recovery can ensure in-order delivery. Hop-by-hop congestion control becomes much more meaningful. It's unclear to me what end-to-end congestion notification means in a mesh-under setting. We can also take advantage of link optimizations to increase throughput and decrease latency. And, as mentioned before, reduces header overhead by not needing addressing information in subsequent fragments. The third issue is whether or not end-to-end mechanisms should be used for recovery and congestion control. I think we agree that hop-by-hop mechanisms are required regardless. They increase reliability and can provide effective congestion control and mitigation. To me, hop-by-hop mechanisms are generally much more effective than end-to-end ones because they react to local conditions and can quickly provide back- pressure all the way to the source. From a reliability standpoint, we've seen solutions deliver >99.9% without end-to-end recovery. So one question is how much more reliability do we really need? and does it justify the added energy overhead and code size? -- Jonathan Hui On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > > We do agree on the problem. > > Per-hop reassembly, though, comes at the expense of that traffic > fluidity that was so desirable to the ATM designers. In other words, > because per-hop reassembly forces each intermediate node to store and > forward a full packet, it is augmenting the latency of the flow and > the > memory requirements on the forwarding nodes on the way. > > This is why I had in mind to couple a few per-hop recovery with a more > solid end-to-end recovery and flow control mechanism between the > LoWPAN > endpoints. > > Now I wonder what this discussion becomes in route over v.s. mesh > under. > In route over, it seems that the forwarding node terminates a link > so it > has to reassemble before it forwards on a different link that might or > might not be a LoWPAN; so maybe we end up doing the same thing in that > case. > > Jonathan, what do you think? > > Pascal > >> -----Original Message----- >> From: Philip Levis [mailto:pal@cs.stanford.edu] >> Sent: vendredi 23 mai 2008 19:46 >> To: Pascal Thubert (pthubert) >> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); > 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> >> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi JP: >>> >>> I see your concern. >>> >>> I'd argue that ECN is now pretty well defined now in RFC 3168, and >>> that >>> the basic operation is pretty simple: emulate a packet loss in RED > but >>> save the packet. So the real problem is not ECN itself but what RED >>> becomes in a LowPAN forwarding node. And that is something that the >>> node >>> will have to define whether it does ECN or RED. >>> >>> If we do not have ECN then the LowPAN forwarding nodes will have to >>> destroy frames which might be fragments. Considering the cost of >>> energy >>> and bandwidth to getting the frame up to that forwarding node, the >>> latency introduced by transport layer time out, and the risk of >>> congestion collapse introduced by resending the whole segment, I'd >>> suggest that ECN is actually a good idea. >> >> This gets back to the point I brought up December 14, 2006. In lossy >> networks, end-to-end fragmentation and assembly is a real problem. It >> makes much more sense to do per-hop fragmentation and assembly. In >> the >> former, the number of retransmitted fragments is exponential in the >> number of hops; in the latter, it is linear. >> >> Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 27 22:34:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895663A6A52; Tue, 27 May 2008 22:34:50 -0700 (PDT) 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 C870B3A6A52 for <6lowpan@core3.amsl.com>; Tue, 27 May 2008 22:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 762VBS-IkzEd for <6lowpan@core3.amsl.com>; Tue, 27 May 2008 22:34:43 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 744DB3A67B7 for <6lowpan@ietf.org>; Tue, 27 May 2008 22:34:43 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1EJG-0005K9-Fu; Tue, 27 May 2008 22:34:50 -0700 Message-Id: From: Philip Levis To: Jonathan Hui In-Reply-To: <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 22:34:50 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On May 27, 2008, at 9:26 AM, Jonathan Hui wrote: > > > The third issue is whether or not end-to-end mechanisms should be > used for recovery and congestion control. I think we agree that hop- > by-hop mechanisms are required regardless. They increase reliability > and can provide effective congestion control and mitigation. To me, > hop-by-hop mechanisms are generally much more effective than end-to- > end ones because they react to local conditions and can quickly > provide back-pressure all the way to the source. From a reliability > standpoint, we've seen solutions deliver >99.9% without end-to-end > recovery. So one question is how much more reliability do we really > need? and does it justify the added energy overhead and code size? This is an excellent point. On one hand, it is critical that we do not preclude end-to-end recovery mechanisms, at the very least for the end- to-end argument. On the other, we might be getting a bit ahead of ourselves here; it's not clear at all whether the benefits of these mechanisms (increased layer 3 delivery ratios) significantly outweigh their costs (code size and energy). Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 27 22:38:19 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C363A6C5D; Tue, 27 May 2008 22:38:19 -0700 (PDT) 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 EC61E3A6C5B; Tue, 27 May 2008 22:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIEyVs1UR1UN; Tue, 27 May 2008 22:38:18 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 375463A6C46; Tue, 27 May 2008 22:38:15 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1EMf-0005Tu-Md; Tue, 27 May 2008 22:38:22 -0700 From: Philip Levis To: Carles Gomez Montenegro In-Reply-To: <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> X-Priority: 3 (Normal) References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> Message-Id: <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 27 May 2008 22:38:21 -0700 X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote: > > At least, there are the following items listed in the routing > requirements > draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) > that route-over approach cannot provide or would provide only in a > limited > way: I disagree wholeheartedly. I think there is a big confusion here between a protocol specification and a protocol implementation. These are all arguments for cross-layer design, that tightly integrating routing and the link layer will lead to a better solution. Practice has shown us otherwise; only by clearly separating concerns do you give a protocol the flexibility needed to evolve over time. What happens when a new low power link layer emerges? Having N different solutions, each with their own details, which somehow need to be made to work well together, seems like a path of brittle and difficult to manage networks. Switches are good, to a point; there's a reason you have routers. The purpose of a protocol specification, IMO, is to specify what is needed for interoperability; there should, in theory, be multiple possible implementations (and by that, I mean power saving approaches) that can all interoperate. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 28 00:04:21 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F04B28C131; Wed, 28 May 2008 00:04:21 -0700 (PDT) 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 6459E3A6767 for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 00:04:20 -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 0PYEjPTVhfNA for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 00:04:18 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id AE6153A6C6E for <6lowpan@ietf.org>; Wed, 28 May 2008 00:04:17 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2526075tib.25 for <6lowpan@ietf.org>; Wed, 28 May 2008 00:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VF5x9xkq954yV3qztNVBozTil+TWUHWx4q6sj7OWTxg=; b=XNpUGE0DeHqc9LIGvvGHhJfusbwFtZVfbKY2r8+PmtBgWlNLaMQQV6lnPyUumT0xdQ71ZO6Kzk9/rX/sdhWoDwdJXae2MpXHmddbv1qT9RTisUYWobbVzINm2mzwAWcf6wquJlD1TV1Q4tdSQkWBY71DtINTsn3hAQlbUhGPXNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MfWC/RerK0e8J0WyPlbIdQxXUsyPePJElusT7Sq3EXF8o8Pjice/36/hPjGSop95LgrCUt8CuSKyEyimG1f3+bbBP6O7kFjtHZbmKxEo46Y7eX8XeIzfP0RDwv6IucRnaUSVYT5E04/mwRn4X+MIrqzTmmR3tgoZy4bfnJEjNLY= Received: by 10.110.49.6 with SMTP id w6mr324567tiw.6.1211958262052; Wed, 28 May 2008 00:04:22 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 28 May 2008 00:04:21 -0700 (PDT) Message-ID: <77f1dba80805280004j3716631fs197cc1d7a553b381@mail.gmail.com> Date: Wed, 28 May 2008 16:04:21 +0900 From: "Eunsook \"Eunah\" Kim" To: "Carles Gomez Montenegro" In-Reply-To: <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> Cc: 6lowpan@ietf.org, roll-chairs@tools.ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Mark, As Carles mentioned, and as already ROLL chairs replied, ROLL is not considering L2 "route-under". I don't want to debate the preference and benefits between 'route-over' and 'mesh-under'. Just want to mention that the current document was written based on the necessity to check if 6LOWPAN has its own specific routing requitments or not. As I remember, 71th meeting discussed to make 6LoWPAN RR work with a tight alignment with ROLL, avoiding duplicate work, and I believe that -05 is handling well on this matter. At this stage it may be too early to answer if mesh-under related issues of 6LoWPAN don't need to be studied when route-over is provided, since only 3 application specific requirements drafts are available from ROLL so far. I think that this work is related to the current mesh-under ND. Before route-over becomes very clear, we can study in pararell. We can, later, provide mesh-under as informational or just give some issues as an input to route-over. To see this, I think we need to study more, meaning we need this item alive. Thanks, -eunah On 5/27/08, Carles Gomez Montenegro wrote: > Hi Mark, > > I would like to answer to one of the questions you raised regarding the > mesh-under Vs. route-over paradigms. > > > Is there anything that the L3 > > "route-over" model might not provide that is listed as a requirement for > > 6lowpan's "route-under" model? > > At least, there are the following items listed in the routing requirements > draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) > that route-over approach cannot provide or would provide only in a limited > way: > > - [R03] (use of 802.15.4 link layer feedback for power efficient operation) > - [R05] (use of mesh-under neighbor discovery for 6LoWPAN) > - [R06] (use of 802.15.4 beacons to deal with hibernating/unresponsive nodes) > - [R09] (about exploiting 802.15.4 join/leave messages) > - [R11] (on applying security mechanisms of 802.15.4 for securing the > routing protocol). > - [R12] (802.15.4 constraint on message sizes due to its small MTU) > - [R13] (on using 802.15.4 link layer feedback for link connectivity > maintenance) > - [R14] (on taking advantage of the LQI parameter, which is very critical > in routing decisions in 802.15.4 environments) > > In my opinion, the "routing link and node metric" ROLL item can only > partially capture some of the specificities that may affect routing in > 802.15.4 environments. Even if LQI parameter can be provided from 802.15.4 > to layer three, all the specific 802.15.4 features (see the list above) > can only be fully exploited following a mesh-under approach. Hence, in my > opinion, routing decisions and efficiency of routing protocol operation > within a LoWPAN would be seriously limited if a route-over approach was > followed. > > Thanks, > > Carles > > > > > > > > > > > > > > > Eunsook "Eunah" Kim wrote: > >> Dear AD, and chairmen, > >> > >> It's good to finally see official rechater text. > >> > > It's only proposed text. > >> I think it's pretty well delivering our discussion of rechartering so > >> far, EXCEPT one part; 6lowpan routing requirement. > >> Last meeting (71th IETF), we discussed RR matter and agreed to see > >> IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember > >> correctly, we would keep this work with alignment with ROLL, as long > >> as it's not duplicate work with ROLL. > >> > > You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what > > are your expectations from 6lowpan with respect to the > > routing-requirements document? > > > > http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt > > > > I have some more questions for you specifically: > > > > Should that be pulled into roll, or left in 6lowpan? Is roll considering > > the L2"route-under" model at all? Is there anything that the L3 > > "route-over" model might not provide that is listed as a requirement for > > 6lowpan's "route-under" model? If 6lowpan were to work on an L2 > > "route-under" model, would there be constructs (e.g., the routing > > protocol itself and any low-power modifications) from ROLL that we would > > invariably want to try and reuse? > >> I would like to know if it is implied that the RR work is included in > >> Architecture work, OR, if you have *intentionally* excluded the work. > >> > >> If the first case, I would suggest 6LoWPANers check the updated > >> version (-05) of draft. We updated our RR draft (-05) after the > >> meeting based on the meeting discussion, and circulated to the mailing > >> list. > >> > >> If the second case, I think we should get a chance to discuss the > >> updated version. If the meeting decide the fate of this work after > >> that, I would accept it. However, I have problem if AD or chairmen > >> simply exclude this item without such discussion and concensus > >> > > There has never been any intention to go against consensus or limit > > discussion on this topic. So, let's use this thread to get to the bottom > > of what we want to do as a group here. > > > > - Mark > >> Would you please clarify it to me? > >> > >> Thanks, > >> > >> -eunah > >> > >> On Thu, May 15, 2008 at 11:02 PM, Mark Townsley > >> wrote: > >> > >>> I'd like to ask the group one final time for comments on the proposed > >>> new > >>> charter. I've also asked the ROLL WG chairs to comment. > >>> > >>> As I said before, soon after the format document was published, there > >>> is > >>> nothing stopping the WG from discussing and working on new and existing > >>> items at this time. In fact, activity helps us to decide what should be > >>> in > >>> and out of the charter. Please do not construe not having a charter in > >>> place > >>> as a reason not to update drafts, or discuss topics that need to be > >>> discussed. Just as when we have BoF's and mailing lists before creating > >>> a > >>> new WG, it is good to have WG meetings and on-lists discussions when > >>> creating new WG charters. > >>> > >>> - Mark > >>> > >>> > >>> > >>> > >>> > >>> > >>> Background/Introduction: > >>> > >>> Note: Given that there is not much precedent for this type of activity > >>> at the IETF, the text that follows is of an introductory > >>> nature. Hence, its objective is to give a general idea of the > >>> application area and motivations for the work. In particular, this > >>> section is not to be construed as detailing work items for the working > >>> group. That is done in the following section entitled "Scope of the > >>> Working Group." > >>> > >>> Well-established fields such as control networks, and burgeoning ones > >>> such as "sensor" (or transducer) networks, are increasingly being > >>> based on wireless technologies. Most (but certainly not all) of these > >>> nodes are amongst the most constrained that have ever been networked > >>> wirelessly. Extreme low power (such that they will run potentially for > >>> years on batteries) and extreme low cost (total device cost in single > >>> digit dollars, and riding Moore's law to continuously reduce that > >>> price point) are seen as essential enablers towards their deployment > >>> in networks with the following characteristics: > >>> > >>> * Significantly more devices than current networks > >>> > >>> * Severely limited code and ram space (e.g., highly desirable to > >>> fit the required code--MAC, IP and anything else needed to > >>> execute the embedded application-- in, for example, 32K of flash > >>> memory, using 8-bit microprocessors) > >>> > >>> * Unobtrusive but very different user interface for configuration > >>> (e.g., using gestures or interactions involving the physical > >>> world) > >>> > >>> * Robustness and simplicity in routing or network fabric > >>> > >>> A chief component of these devices is wireless communication > >>> technology. In particular, the IEEE 802.15.4 standard is very > >>> promising for the lower (physical and link) layers. As for higher > >>> layer functions, there is considerable interest from non-IETF groups > >>> in using IP technology (the ZigBee alliance, for example, is currently > >>> studying what such a work item might entail). The working group is > >>> expected to coordinate and interact with such groups. > >>> > >>> The required work includes items in the following (incomplete) list: > >>> > >>> * IP adaptation/Packet Formats and interoperability > >>> * Addressing schemes and address management > >>> * Network management > >>> * Routing in dynamically adaptive topologies > >>> * Security, including set-up and maintenance > >>> * Application programming interface > >>> * Discovery (of devices, of services, etc) > >>> * Implementation considerations > >>> > >>> Whereas at least some of the above items are within the purview of the > >>> IETF, at this point it is not clear that all of them are. Accordingly, > >>> the 6LoWPAN working group will address a reduced, more focused set of > >>> objectives. > >>> > >>> Scope of 6lowpan: > >>> > >>> Produce "Problems Statement, Assumptions and Goals for IPv6 for > >>> LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the > >>> problem statement and goals of 6lowpan networks. > >>> > >>> Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN > >>> Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the > >>> basic packet formats and sub-IP adaptation layer for transmission of > >>> IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, > >>> header compression and address generation. Furthermore, IEEE 802.15.4 > >>> devices are expected to be deployed in mesh topologies. > >>> > >>> As such, the working group may also work on an informational document > >>> to show how to apply an existing MANET protocol to LoWPANs (e.g., > >>> AODV, OLSR, DYMO, etc). > >>> > >>> The working group will reuse existing specifications whenever > >>> reasonable and possible. > >>> > >>> The working group will also serve as a venue for ongoing discussions > >>> on other topics related to the more complete list outlined above. > >>> Additional related milestones may be added in the future via a > >>> rechartering operation. > >>> > >>> Note: As may be obvious from its official name above, this particular > >>> working group will not work on IPv4 over IEEE 802.15.4 specifications. > >>> Given the limitations of the target devices, dual-stack deployments > >>> are not practical. Because of its higher potential for header > >>> compression, its support for the huge number of devices expected and > >>> of cleanly built-in features such as address autoconfiguration, IPv6 > >>> is the exclusive focus of the working group. > >>> Goals and Milestones: > >>> Done Working group last call on > >>> draft-ietf-lowpan-goals-assumptions-xx.txt > >>> Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to > >>> IESG > >>> for consideration of publication as Informational > >>> Done Working Group Last Call on > >>> draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt > >>> Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to > >>> IESG > >>> for consideration of publication as Proposed Standard > >>> > >>> > >>> > >>> Background/Introduction: > >>> > >>> Note: Given that there is not much precedent for this type of activity > >>> at the IETF, the text that follows is of an introductory > >>> nature. Hence, its objective is to give a general idea of the > >>> application area and motivations for the work. In particular, this > >>> section is not to be construed as detailing work items for the working > >>> group. That is done in the following section entitled "Scope of the > >>> Working Group." > >>> > >>> Well-established fields such as control networks, and burgeoning ones > >>> such as "sensor" (or transducer) networks, are increasingly being > >>> based on wireless technologies. Most (but certainly not all) of these > >>> nodes are amongst the most constrained that have ever been networked > >>> wirelessly. Extreme low power (such that they will run potentially for > >>> years on batteries) and extreme low cost (total device cost in single > >>> digit dollars, and riding Moore's law to continuously reduce that > >>> price point) are seen as essential enablers towards their deployment > >>> in networks with the following characteristics: > >>> > >>> * Significantly more devices than current local area networks > >>> > >>> * Severely limited code and ram space (e.g., highly desirable to fit > >>> the required code--MAC, IP and anything else needed to execute the > >>> embedded application-- in, for example, 32K of flash memory, using > >>> 8-bit microprocessors) > >>> > >>> * Unobtrusive but very different user interface for configuration > >>> (e.g., using gestures or interactions involving the physical world) > >>> > >>> A chief component of these devices is wireless communication > >>> technology. In particular, the IEEE 802.15.4 standard is very > >>> promising for the lower (physical and link) layers. As for higher > >>> layer functions, there is considerable interest from non-IETF groups > >>> in using IP technology. The IEEE 1451.5 standard for wireless > >>> transducers has a chapter for 6LoWPAN and the ISA SP100 standard for > >>> wireless industrial networks has adopted 6LoWPAN for their network > >>> layer. This working group is expected to coordinate and interact with > >>> such groups. > >>> > >>> Description of Working Group: > >>> > >>> The working group has completed two RFCs: "IPv6 over Low-Power > >>> Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, > >>> Problem Statement, and Goals" (RFC4919) that documents and discusses > >>> the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 > >>> Networks" (RFC4944) which defines the format for the adaptation > >>> between IPv6 and 802.15.4. > >>> > >>> The Working Group will generate the necessary documents to enusre > >>> interoperable implementations of 6LoWPAN networks and will define the > >>> necessary security and management protocols and constructs for build > >>> 6LoWPAN networks, paying particular attention to protocols already > >>> available. > >>> > >>> Work Items: > >>> > >>> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations" > >>> to define the required optimizations to make IPv6 ND applicable in > >>> 6lowpans, given the fact that IPv6 ND is too expensive for the devices > >>> of 6lowpan and requires multicast. > >>> > >>> This document (or these documents - as the working group delves into > >>> this topic it may determine that this should be two separate > >>> documents) will define how to bootstrap a 6lowpan network and explore > >>> ND optimizations such as reusing the 802.15.4 network structure (use > >>> the coordinators), and obviate multicast by having devices talk to > >>> coordinators without creating a single point-of-failure, and changing > >>> the IPv6 ND multicast semantics. This document will be a proposed > >>> standard. > >>> > >>> 2. Produce "Problem Statement for Stateful Header Compression in > >>> 6lowpans" to document the problem of using stateful header compression > >>> (2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of > >>> stateless header compression given the assumption that stateful header > >>> compression may be too complex. This document will determine if the > >>> assumption is correct and will be an informational document. The WG > >>> will determine if the assumption is correct at this time and record > >>> the findings in this informational document. > >>> > >>> 3. Produce "6LoWPAN Architecture" to describe the design and > >>> implementation of 6LoWPAN networks. This document will cover the > >>> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, > >>> network components, addressing, and IPv4/IPv6 network connections. > >>> > >>> 4. Produce "Recommendations for 6lowpan Applications" to define a set > >>> of recommendations of protocols to use for applications. The > >>> recommendations will cover protocols for transport, application layer, > >>> discovery, configuration and commissioning. This document will be an > >>> informational document. > >>> > >>> 5. Produce "6lowpan Security Analysis" to define the threat model of > >>> 6lowpans and to document suitability of existing key management > >>> schemes and to discuss bootstrapping/installation/commissioning/setup > >>> issues. This document will be an informational document. > >>> > >>> The working group will continue to reuse existing protocols and > >>> mechanisms whenever reasonable and possible. > >>> > >>> Goals and Milestones: > >>> > >>> Jan 2008 - First Draft of Bootstrapping and ND Optimization document > >>> Feb 2008 - First Draft of Stateful Header Compression document > >>> Dec 2007 - First Draft of 6LoWPAN Architecture docuement > >>> Feb 2008 - First Draft of Applications document > >>> Mar 2008 - First Draft of Security Analysis > >>> Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to > >>> be considered as Proposed Standard > >>> Jul 2008 - Submit Stateful Header Compression document to IESG to be > >>> considered as Proposed Standard > >>> May 2008 - Submit Architecture docuement to IESG to be considered as > >>> Informational RFC > >>> Jul 2008 - Submit Applications docuement to IESG to be considered as > >>> Informational RFC > >>> Sep 2008 - Submit Security Analysis document to IESG to be considered > >>> as Informational RFC. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 6lowpan-bounces@ietf.org Wed May 28 01:05:32 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8EA3A6CA4; Wed, 28 May 2008 01:05:17 -0700 (PDT) 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 9634B3A6C92 for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 01:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vcegjeE5R1Hn for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 01:04:44 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id EE3DA3A6CA9 for <6lowpan@ietf.org>; Wed, 28 May 2008 01:04:12 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2539236tib.25 for <6lowpan@ietf.org>; Wed, 28 May 2008 01:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=3OEqorSDCS1j01HMP+obuvQB52m6rXqknCrWFLvkZ7I=; b=YMz5JBDPB5E6g0l4GSY4Ezce7q2i77Pkf8RdaGVFQ83dvcfSSj+2RJp2tZ5wQQGqzp0qGALCrJeppfBKKGRUsZVxk3LdCeOMI2Zur5Jcpy0ddQPWHoe8XqIEZSEXYBVc5OxEbwHNuulpAH7skqdPiPNf69ybEK87zUo45LJJ+QQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qtQNUJLS2wt9g6YRHEvd9b21K2/pBvwkANKKqFctaq/0SBus3g0SbKLwX1SgOKkZN7wgy2rvppRvgicro/BgETc4PVsuCDRTVHqDqu+zfD6JcDdLQ74Gix850Sn4ZNgyrLbSdUNSw9+hNHUuiSRNBJWNRaUkJpvYx6t/L9CF/s8= Received: by 10.110.69.5 with SMTP id r5mr332396tia.17.1211961854733; Wed, 28 May 2008 01:04:14 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 28 May 2008 01:04:14 -0700 (PDT) Message-ID: <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> Date: Wed, 28 May 2008 17:04:14 +0900 From: "Eunsook \"Eunah\" Kim" To: "Philip Levis" In-Reply-To: <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Dear Philip, > What happens when a new low power link layer emerges? Having N > different solutions, each with their own details, which somehow need > to be made to work well together, seems like a path of brittle and > difficult to manage networks. Switches are good, to a point; there's a > reason you have routers. > We don't talk about solutions. We want to see if 6LoWPAN has special routing requirements due to 802.15.4 specific or not. If route-over solutions can be provided to fit the requirements of 6LoWPAN, I'm happy. -eunah _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 28 09:18:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D69B3A6AC7; Wed, 28 May 2008 09:18:45 -0700 (PDT) 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 DD9473A6AA5; Wed, 28 May 2008 09:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rko6rM51khVz; Wed, 28 May 2008 09:18:43 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 304DA3A6AB1; Wed, 28 May 2008 09:18:43 -0700 (PDT) Received: from dnab42327d.stanford.edu ([171.66.50.125]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1OMV-000542-LI; Wed, 28 May 2008 09:18:51 -0700 Message-Id: <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> From: Philip Levis To: Eunsook Eunah Kim In-Reply-To: <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 28 May 2008 08:36:24 -0700 References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > Dear Philip, > >> What happens when a new low power link layer emerges? Having N >> different solutions, each with their own details, which somehow need >> to be made to work well together, seems like a path of brittle and >> difficult to manage networks. Switches are good, to a point; >> there's a >> reason you have routers. >> > > We don't talk about solutions. We want to see if 6LoWPAN has special > routing requirements due to 802.15.4 specific or not. If route-over > solutions can be provided to fit the requirements of 6LoWPAN, I'm > happy. Exactly: as soon as you start talking about things like LQI, you are coupling yourself not only to a specific link layer, but also a specific implementation of that link layer. In practice, many networks use the 802.15.4 link layer but not its MAC layer, as it has terrible energy properties. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 28 20:01:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31B93A6AD8; Wed, 28 May 2008 20:01:50 -0700 (PDT) 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 40B4B3A6AD8 for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 20:01: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmsgTMVUz8un for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 20:01:44 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 24B3B3A6CF9 for <6lowpan@ietf.org>; Wed, 28 May 2008 20:01:19 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2774217tib.25 for <6lowpan@ietf.org>; Wed, 28 May 2008 20:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=/5qYXHJj15d9gSOSdUABGTDrrRepIEZslfLlPPIsIK8=; b=tIofAClJ9BYCz3IhcnlPTNneV/9WRudyqKMi3LAk22gaujOZlmIUapFEW+O2ygOsk2Do+oUcBjM4jnYB6777i/mr8G8sGNC3uIA7jW6/gBArwF5lKNC9ikeLmkJ8nUzRBzoP8mmLOo4xXJktunOoEMdws4nnfnR1Z9qiAhds4Wo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kp0Pfhr6uktEa6hQPzHbHa8r235dbiYM51eQWYEvMvNcYAbouR+BhyYfTnw5HNTEc+e9i7iL01lJtF2Vw7SnDsy+rMeOdTPrJAyftivFf6GLGilKvj/vXFfXf/iXKSzQPEVgN6gEx93YdElLqVRw6MAcMvYpXRrGL1Zg6w90sJ4= Received: by 10.110.15.9 with SMTP id 9mr463691tio.50.1212029654396; Wed, 28 May 2008 19:54:14 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 28 May 2008 19:54:14 -0700 (PDT) Message-ID: <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> Date: Thu, 29 May 2008 11:54:14 +0900 From: "Eunsook \"Eunah\" Kim" To: "Philip Levis" In-Reply-To: <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Philip, Thanks for the comment. LQI in the draft was mentioned for one requirement, and it is given as just one of the examples for routing matrics to utilize possible information to build up better routing metrics for low power networks. If you think we shouldn't bond 6LoWPAN to use MAC metrics, I'm okay with that. We can rule out it, but keep doing the study about routing matrics. Thank you. -eunah On 5/29/08, Philip Levis wrote: > > On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > > > Dear Philip, > > > > > > > What happens when a new low power link layer emerges? Having N > > > different solutions, each with their own details, which somehow need > > > to be made to work well together, seems like a path of brittle and > > > difficult to manage networks. Switches are good, to a point; there's a > > > reason you have routers. > > > > > > > > > > We don't talk about solutions. We want to see if 6LoWPAN has special > > routing requirements due to 802.15.4 specific or not. If route-over > > solutions can be provided to fit the requirements of 6LoWPAN, I'm > > happy. > > > > Exactly: as soon as you start talking about things like LQI, you are > coupling yourself not only to a specific link layer, but also a specific > implementation of that link layer. In practice, many networks use the > 802.15.4 link layer but not its MAC layer, as it has terrible energy > properties. > > Phil > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 28 21:02:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE2C3A6941; Wed, 28 May 2008 21:02:20 -0700 (PDT) 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 761CC3A6CE0; Wed, 28 May 2008 21:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLs0nxKTA6X0; Wed, 28 May 2008 21:02:17 -0700 (PDT) Received: from wilson.nswebhost.com (wilson.nswebhost.com [65.254.51.10]) by core3.amsl.com (Postfix) with ESMTP id 7DF953A6781; Wed, 28 May 2008 21:02:05 -0700 (PDT) Received: from [64.74.213.174] (helo=RunningDog2) by wilson.nswebhost.com with smtp (Exim 4.68) (envelope-from ) id 1K1ZL6-0003ni-QI; Wed, 28 May 2008 23:02:09 -0500 Message-ID: <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> From: "Benjamin A. Rolfe" To: , <6lowpan@ietf.org> References: <482CA4DC.40508@cisco.com><77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com><4832F276.70406@cisco.com><2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu><19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu><77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com><46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> Date: Wed, 28 May 2008 21:02:07 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-ClamAntiVirus-Scanner: This mail is clean 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 Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Sorry, first post to the list, so forgive if I'm sounding like a newbie... How would one get link quality information to the upper layers other than via a MAC service? I can see inserting a shim-layer service to isolate upper layers form the different MACs which may be under it, so as to provide a consistent service interface. Of course you can only get what the MAC provides, but the shim layer and upper layer's can be designed to handle gracefully different MAC capabilities (at least consistently). I'm asking with a bit of a bias here: I'm currently working on MAC enhancements for 802.15.4 (in task group "e" in 802.15), including a proposal for enhanced link assessment information from the MAC. So of course I'd suggest not ruling out some better link metrics in the 802.15.4 MAC at some point, although upper layers still need to deal with existing 802.15.4 devices. So the general thinking from upper layer uses is very interesting. Thanks -Ben ----- Original Message ----- From: "Eunsook "Eunah" Kim" To: "Philip Levis" Cc: ; <6lowpan@ietf.org> Sent: Wednesday, May 28, 2008 7:54 PM Subject: Re: [6lowpan] New charter for 6lowpan > Philip, > Thanks for the comment. LQI in the draft was mentioned for one > requirement, and it is given as just one of the examples for routing > matrics to utilize possible information to build up better routing > metrics for low power networks. If you think we shouldn't bond 6LoWPAN > to use MAC metrics, I'm okay with that. We can rule out it, but keep > doing the study about routing matrics. Thank you. > > -eunah > > On 5/29/08, Philip Levis wrote: >> >> On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: >> >> > Dear Philip, >> > >> > >> > > What happens when a new low power link layer emerges? Having N >> > > different solutions, each with their own details, which somehow need >> > > to be made to work well together, seems like a path of brittle and >> > > difficult to manage networks. Switches are good, to a point; there's >> > > a >> > > reason you have routers. >> > > >> > > >> > >> > We don't talk about solutions. We want to see if 6LoWPAN has special >> > routing requirements due to 802.15.4 specific or not. If route-over >> > solutions can be provided to fit the requirements of 6LoWPAN, I'm >> > happy. >> > >> >> Exactly: as soon as you start talking about things like LQI, you are >> coupling yourself not only to a specific link layer, but also a specific >> implementation of that link layer. In practice, many networks use the >> 802.15.4 link layer but not its MAC layer, as it has terrible energy >> properties. >> >> Phil >> > _______________________________________________ > 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 6lowpan-bounces@ietf.org Wed May 28 21:54:51 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13AD53A6957; Wed, 28 May 2008 21:54:51 -0700 (PDT) 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 E4C103A6804 for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 21:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_71=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-Yu5dzZvRx4 for <6lowpan@core3.amsl.com>; Wed, 28 May 2008 21:54:43 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188]) by core3.amsl.com (Postfix) with ESMTP id C527B3A68E8 for <6lowpan@ietf.org>; Wed, 28 May 2008 21:54:42 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2794599tib.25 for <6lowpan@ietf.org>; Wed, 28 May 2008 21:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9qw3OrUVCcfBZFk22KWCwkTdwAY6FtBqzu4nHKEaoMA=; b=pzyErBjVftc2U180L+Kjb6X1JRVXLzIyC2bbJd1q8Ze568q0TWKZW8AdiTsS7mBzlA4NzijiO/OcVQtD4MmwEvPggD9KAeSrNAFTe0dEVIuCgKJdJsws1Xty+W5T1c9bXwnaSkti5JfU+rJseSXT6CDBTN7atKFV7XLPFIqhlg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p8aIsnWJzA4P9iEi06ER0nfb4emWYPdKx7DYEgzXcnpMESBOs/EldzldqSOeVTBoldVhoQr8J8rXvhltnJKDFTGMYWR/32lSjdsovzGAHdQ/o39lcAPGoVDMCWqsUpOxC1yHJJWAmwGCBL4+UecIUjWJU4cbZvjssY03b+9ceuY= Received: by 10.110.28.15 with SMTP id b15mr481906tib.26.1212036888686; Wed, 28 May 2008 21:54:48 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 28 May 2008 21:54:48 -0700 (PDT) Message-ID: <77f1dba80805282154g66f1db7dw2c501ec37337c864@mail.gmail.com> Date: Thu, 29 May 2008 13:54:48 +0900 From: "Eunsook \"Eunah\" Kim" To: "Benjamin A. Rolfe" In-Reply-To: <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> MIME-Version: 1.0 Content-Disposition: inline References: <482CA4DC.40508@cisco.com> <77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com> <4832F276.70406@cisco.com> <2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu> <19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu> <77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com> <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Benjamin, On 5/29/08, Benjamin A. Rolfe wrote: > Sorry, first post to the list, so forgive if I'm sounding like a newbie... > How would one get link quality information to the upper layers other than > via a MAC service? We are in the same track. That's why I think we need to utilize information from MAC for 6lowpan routing matrics. > I can see inserting a shim-layer service to isolate upper layers form the > different MACs which may be under it, so as to provide a consistent service > interface. Of course you can only get what the MAC provides, but the shim > layer and upper layer's can be designed to handle gracefully different MAC > capabilities (at least consistently). > :) > I'm asking with a bit of a bias here: I'm currently working on MAC > enhancements for 802.15.4 (in task group "e" in 802.15), including a > proposal for enhanced link assessment information from the MAC. So of course > I'd suggest not ruling out some better link metrics in the 802.15.4 MAC at > some point, although upper layers still need to deal with existing 802.15.4 > devices. So the general thinking from upper layer uses is very interesting. > Thanks > -Ben > The current 6LoWPAN RR draft has been started with the reason you concern, and we've kept working on it, as I believe that there are necessity of this work nevertheless some folks have different opinion(I'm trying to listen other side too). Thank you for sharing your thought. :) - eunah > > ----- Original Message ----- > From: "Eunsook "Eunah" Kim" > To: "Philip Levis" > Cc: ; <6lowpan@ietf.org> > Sent: Wednesday, May 28, 2008 7:54 PM > Subject: Re: [6lowpan] New charter for 6lowpan > > > > Philip, > > Thanks for the comment. LQI in the draft was mentioned for one > > requirement, and it is given as just one of the examples for routing > > matrics to utilize possible information to build up better routing > > metrics for low power networks. If you think we shouldn't bond 6LoWPAN > > to use MAC metrics, I'm okay with that. We can rule out it, but keep > > doing the study about routing matrics. Thank you. > > > > -eunah > > > > On 5/29/08, Philip Levis wrote: > >> > >> On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > >> > >> > Dear Philip, > >> > > >> > > >> > > What happens when a new low power link layer emerges? Having N > >> > > different solutions, each with their own details, which somehow need > >> > > to be made to work well together, seems like a path of brittle and > >> > > difficult to manage networks. Switches are good, to a point; there's > >> > > a > >> > > reason you have routers. > >> > > > >> > > > >> > > >> > We don't talk about solutions. We want to see if 6LoWPAN has special > >> > routing requirements due to 802.15.4 specific or not. If route-over > >> > solutions can be provided to fit the requirements of 6LoWPAN, I'm > >> > happy. > >> > > >> > >> Exactly: as soon as you start talking about things like LQI, you are > >> coupling yourself not only to a specific link layer, but also a specific > >> implementation of that link layer. In practice, many networks use the > >> 802.15.4 link layer but not its MAC layer, as it has terrible energy > >> properties. > >> > >> Phil > >> > > _______________________________________________ > > 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 6lowpan-bounces@ietf.org Wed May 28 22:50:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC2D3A68AE; Wed, 28 May 2008 22:50:01 -0700 (PDT) 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 CEF9A3A68AE; Wed, 28 May 2008 22:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 l8663Uzkg4yT; Wed, 28 May 2008 22:49:58 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 431AE3A67AB; Wed, 28 May 2008 22:49:52 -0700 (PDT) Received: from [76.14.71.180] (helo=[192.168.2.101]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1K1b1K-0000KG-0G; Wed, 28 May 2008 22:49:50 -0700 In-Reply-To: <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> References: <482CA4DC.40508@cisco.com><77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com><4832F276.70406@cisco.com><2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu><19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu><77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com><46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Message-Id: From: Philip Levis Date: Wed, 28 May 2008 22:49:40 -0700 To: Benjamin A. Rolfe X-Mailer: Apple Mail (2.753) X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org On May 28, 2008, at 9:02 PM, Benjamin A. Rolfe wrote: > Sorry, first post to the list, so forgive if I'm sounding like a > newbie... > How would one get link quality information to the upper layers > other than > via a MAC service? > I can see inserting a shim-layer service to isolate upper layers > form the > different MACs which may be under it, so as to provide a consistent > service > interface. Of course you can only get what the MAC provides, but > the shim > layer and upper layer's can be designed to handle gracefully > different MAC > capabilities (at least consistently). > > I'm asking with a bit of a bias here: I'm currently working on MAC > enhancements for 802.15.4 (in task group "e" in 802.15), including a > proposal for enhanced link assessment information from the MAC. So > of course > I'd suggest not ruling out some better link metrics in the 802.15.4 > MAC at > some point, although upper layers still need to deal with existing > 802.15.4 > devices. So the general thinking from upper layer uses is very > interesting. > Thanks > This is a very good question. It turns out to be very difficult, for two major reasons: separation of concerns and time scale. For the sake of simplicity, let's just consider the simplest link quality metric, the packet reception ratio. By separation of concerns, I mean that the MAC layer has to maintain state to generate link estimates. However, the MAC layer does not know which links are useful to a network layer. That is, it could learn and estimate the best links, but those links could be not very good for routing. For example, they could lead to a disconnected network, or high stretch routes. By time scale, I mean that if the average PRR over ten seconds is 50%, that could be due to bursts of high and bursts of low reception. Let's say that an application sends a packet every one second, the link layer transmits 5 times, and the 50% PRR is due to 5 seconds of 0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will transmit 25 packets, with no successful deliveries. Meanwhile, during the 5 seconds of 100%, it will transmit five packets with 5 deliveries. While the PRR over the 10 second window was 50%, the link layer observed a PRR of 16% (5/30). Most radio chips (e.g., CC2420 and RF230) provide LQI as chip correlation values over some number of packet octets. These physical layer measurements effectively add significant bits to the SNR in the sharp part of the BER curve, and are amazingly useful. However, because they are only taken on successful packets, they suffer from measurement bias; in the example above of 50% PRR, a network layer would see all packets having an excellent LQI value, even though packets are lost. This happens in practice, when you have channel variations. Within the TinyOS community, our conclusion is that the MAC layer needs to provide 2 bits of information to the network layer. The first, the "white bit," is a simplification of things like LQI or SNR and essentially indicates whether a received packet had a very low BER, indicating it is probably -- but not certainly -- a good link. The second, the "ack bit" is signaled on each link layer transmission and indicates whether the transmitter received a layer 2 ack. A paper in HotNets last year quantified the benefits each of the bits provides.[1] Phil [1] http://enl.usc.edu/papers/abstract/Fonseca07.html _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 29 00:00:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DC23A696F; Thu, 29 May 2008 00:00:28 -0700 (PDT) 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 7CFB23A696F for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 00:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKuw20MUPhqf for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 00:00:26 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 572A63A68A6 for <6lowpan@ietf.org>; Thu, 29 May 2008 00:00:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A9C81A93A2; Thu, 29 May 2008 00:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tamuKA4i-Cbf; Thu, 29 May 2008 00:00:19 -0700 (PDT) Received: from [10.0.1.199] (adsl-71-142-65-177.dsl.pltn13.pacbell.net [71.142.65.177]) by mail.sf.archrock.com (Postfix) with ESMTP id 93069A939D; Thu, 29 May 2008 00:00:18 -0700 (PDT) From: Jonathan Hui To: 6lowpan@ietf.org In-Reply-To: X-Priority: 3 References: <482CA4DC.40508@cisco.com><77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com><4832F276.70406@cisco.com><2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu><19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu><77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com><46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> Message-Id: Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 29 May 2008 00:00:17 -0700 X-Mailer: Apple Mail (2.924) Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org We are diverging from the original issue of the route-over/mesh-under debate raised by Mark for the new 6lowpan charter. However, I do feel that increasing cross-layer cooperation while maintaining the layering is an interesting and important question and the discussion should continue in a separate thread. The route-over/mesh-under issue covers more than just routing - it defines how we abstract the IP link and covers issues of fragment delivery, multicast emulation, neighbor discovery, autoconf, etc. While mesh-under is an acceptable approach for extending IP connectivity to 6lowpan devices, the real issue is that "IEEE 802.15.4" is a very loaded term today. There are many link-layers that could be well-suited for 6lowpan (both existing and in development) that utilize 802.15.4 radios, but not the 802.15.4 multihop meshing itself. The real problem with IEEE 802.15.4 is that it fails to define a true low-power solution for a multihop mesh, which is explicitly stated in IEEE 802.15.4-2006. Work is under way in IEEE 802.15.4e to address this issue, but it is still in the formative stages. Given where we are today, it is most desirable for us to develop solutions that do not assume specific functionality specified in IEEE 802.15.4-2006 for creating a multihop mesh (e.g. beacons, coordinators, etc.). It would be a shame if, for each specific 802.15.4 multihop mesh technology, we or others have to come up with a variety of different solutions (routing being only one piece of that) to successfully create an IP link. W.r.t. the routing requirements draft, I think we would be much better off by developing a "requirements document for 6lowpan mesh-under subnetwork designs", something that others could use when developing their own L2 mesh-layer on 802.15.4 radios. This is something the 6LoWPAN Architecture draft could include or could be broken out into a separate document. -- Jonathan Hui On May 28, 2008, at 10:49 PM, Philip Levis wrote: > > On May 28, 2008, at 9:02 PM, Benjamin A. Rolfe wrote: >> Sorry, first post to the list, so forgive if I'm sounding like a >> newbie... >> How would one get link quality information to the upper layers >> other than >> via a MAC service? >> I can see inserting a shim-layer service to isolate upper layers >> form the >> different MACs which may be under it, so as to provide a consistent >> service >> interface. Of course you can only get what the MAC provides, but >> the shim >> layer and upper layer's can be designed to handle gracefully >> different MAC >> capabilities (at least consistently). >> >> I'm asking with a bit of a bias here: I'm currently working on MAC >> enhancements for 802.15.4 (in task group "e" in 802.15), including a >> proposal for enhanced link assessment information from the MAC. So >> of course >> I'd suggest not ruling out some better link metrics in the 802.15.4 >> MAC at >> some point, although upper layers still need to deal with existing >> 802.15.4 >> devices. So the general thinking from upper layer uses is very >> interesting. >> Thanks >> > > This is a very good question. It turns out to be very difficult, for > two major reasons: separation of concerns and time scale. For the > sake of simplicity, let's just consider the simplest link quality > metric, the packet reception ratio. > > By separation of concerns, I mean that the MAC layer has to maintain > state to generate link estimates. However, the MAC layer does not > know which links are useful to a network layer. That is, it could > learn and estimate the best links, but those links could be not very > good for routing. For example, they could lead to a disconnected > network, or high stretch routes. > > By time scale, I mean that if the average PRR over ten seconds is > 50%, that could be due to bursts of high and bursts of low reception. > Let's say that an application sends a packet every one second, the > link layer transmits 5 times, and the 50% PRR is due to 5 seconds of > 0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will > transmit 25 packets, with no successful deliveries. Meanwhile, during > the 5 seconds of 100%, it will transmit five packets with 5 > deliveries. While the PRR over the 10 second window was 50%, the link > layer observed a PRR of 16% (5/30). > > Most radio chips (e.g., CC2420 and RF230) provide LQI as chip > correlation values over some number of packet octets. These physical > layer measurements effectively add significant bits to the SNR in the > sharp part of the BER curve, and are amazingly useful. However, > because they are only taken on successful packets, they suffer from > measurement bias; in the example above of 50% PRR, a network layer > would see all packets having an excellent LQI value, even though > packets are lost. This happens in practice, when you have channel > variations. > > Within the TinyOS community, our conclusion is that the MAC layer > needs to provide 2 bits of information to the network layer. The > first, the "white bit," is a simplification of things like LQI or SNR > and essentially indicates whether a received packet had a very low > BER, indicating it is probably -- but not certainly -- a good link. > The second, the "ack bit" is signaled on each link layer transmission > and indicates whether the transmitter received a layer 2 ack. A paper > in HotNets last year quantified the benefits each of the bits > provides.[1] > > Phil > > [1] http://enl.usc.edu/papers/abstract/Fonseca07.html > > > > _______________________________________________ > 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 6lowpan-bounces@ietf.org Thu May 29 00:20:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D793A6884; Thu, 29 May 2008 00:20:49 -0700 (PDT) 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 8E1C43A6884 for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 00:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[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 jGn0eajfWYgD for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 00:20:45 -0700 (PDT) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by core3.amsl.com (Postfix) with ESMTP id 8C1F13A67E3 for <6lowpan@ietf.org>; Thu, 29 May 2008 00:20:45 -0700 (PDT) Received: from smtp1-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp1-g19.free.fr (Postfix) with ESMTP id BD2161AB2E8; Thu, 29 May 2008 09:20:43 +0200 (CEST) Received: from [192.168.0.1] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) by smtp1-g19.free.fr (Postfix) with ESMTP id 6AFC41AB2A8; Thu, 29 May 2008 09:20:43 +0200 (CEST) In-Reply-To: References: <482CA4DC.40508@cisco.com><77f1dba80805160141q74c297e1h84f05b6dd8a7d5d8@mail.gmail.com><4832F276.70406@cisco.com><2419.193.184.21.116.1211880559.squirrel@webmail.entel.upc.edu><19CD83B4-82E9-4D0F-8789-02C5ED55343C@cs.stanford.edu><77f1dba80805280104w4dc33365pd9693eff0eafd0@mail.gmail.com><46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> <77f1dba80805281954u7f97f472q86c4261e51f6e498@mail.gmail.com> <024101c8c140$c4b9fc90$0efaa8c0@RunningDog2> Mime-Version: 1.0 (Apple Message framework v753) X-Priority: 3 Message-Id: From: Bernard Tourancheau Date: Thu, 29 May 2008 09:20:38 +0200 To: Jonathan Hui X-Mailer: Apple Mail (2.753) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonanthan, I completly agree with you. Moreover, the spec. should be open enough = to be able to take advantages of link layer specific properties. At the extrem, as some proprietary systems are already running, = should it precludes the usage of another mesh layer on an = architecture running 6lowPAN ? -- Bernard. Le 29 mai 08 =E0 09:00, Jonathan Hui a =E9crit : > > We are diverging from the original issue of the route-over/mesh-under > debate raised by Mark for the new 6lowpan charter. However, I do feel > that increasing cross-layer cooperation while maintaining the layering > is an interesting and important question and the discussion should > continue in a separate thread. > > The route-over/mesh-under issue covers more than just routing - it > defines how we abstract the IP link and covers issues of fragment > delivery, multicast emulation, neighbor discovery, autoconf, etc. > While mesh-under is an acceptable approach for extending IP > connectivity to 6lowpan devices, the real issue is that "IEEE > 802.15.4" is a very loaded term today. There are many link-layers that > could be well-suited for 6lowpan (both existing and in development) > that utilize 802.15.4 radios, but not the 802.15.4 multihop meshing > itself. The real problem with IEEE 802.15.4 is that it fails to define > a true low-power solution for a multihop mesh, which is explicitly > stated in IEEE 802.15.4-2006. Work is under way in IEEE 802.15.4e to > address this issue, but it is still in the formative stages. > > Given where we are today, it is most desirable for us to develop > solutions that do not assume specific functionality specified in IEEE > 802.15.4-2006 for creating a multihop mesh (e.g. beacons, > coordinators, etc.). It would be a shame if, for each specific > 802.15.4 multihop mesh technology, we or others have to come up with a > variety of different solutions (routing being only one piece of that) > to successfully create an IP link. > > W.r.t. the routing requirements draft, I think we would be much better > off by developing a "requirements document for 6lowpan mesh-under > subnetwork designs", something that others could use when developing > their own L2 mesh-layer on 802.15.4 radios. This is something the > 6LoWPAN Architecture draft could include or could be broken out into a > separate document. > > -- > Jonathan Hui > > > > On May 28, 2008, at 10:49 PM, Philip Levis wrote: > >> >> On May 28, 2008, at 9:02 PM, Benjamin A. Rolfe wrote: >>> Sorry, first post to the list, so forgive if I'm sounding like a >>> newbie... >>> How would one get link quality information to the upper layers >>> other than >>> via a MAC service? >>> I can see inserting a shim-layer service to isolate upper layers >>> form the >>> different MACs which may be under it, so as to provide a consistent >>> service >>> interface. Of course you can only get what the MAC provides, but >>> the shim >>> layer and upper layer's can be designed to handle gracefully >>> different MAC >>> capabilities (at least consistently). >>> >>> I'm asking with a bit of a bias here: I'm currently working on MAC >>> enhancements for 802.15.4 (in task group "e" in 802.15), including a >>> proposal for enhanced link assessment information from the MAC. So >>> of course >>> I'd suggest not ruling out some better link metrics in the 802.15.4 >>> MAC at >>> some point, although upper layers still need to deal with existing >>> 802.15.4 >>> devices. So the general thinking from upper layer uses is very >>> interesting. >>> Thanks >>> >> >> This is a very good question. It turns out to be very difficult, for >> two major reasons: separation of concerns and time scale. For the >> sake of simplicity, let's just consider the simplest link quality >> metric, the packet reception ratio. >> >> By separation of concerns, I mean that the MAC layer has to maintain >> state to generate link estimates. However, the MAC layer does not >> know which links are useful to a network layer. That is, it could >> learn and estimate the best links, but those links could be not very >> good for routing. For example, they could lead to a disconnected >> network, or high stretch routes. >> >> By time scale, I mean that if the average PRR over ten seconds is >> 50%, that could be due to bursts of high and bursts of low reception. >> Let's say that an application sends a packet every one second, the >> link layer transmits 5 times, and the 50% PRR is due to 5 seconds of >> 0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will >> transmit 25 packets, with no successful deliveries. Meanwhile, during >> the 5 seconds of 100%, it will transmit five packets with 5 >> deliveries. While the PRR over the 10 second window was 50%, the link >> layer observed a PRR of 16% (5/30). >> >> Most radio chips (e.g., CC2420 and RF230) provide LQI as chip >> correlation values over some number of packet octets. These physical >> layer measurements effectively add significant bits to the SNR in the >> sharp part of the BER curve, and are amazingly useful. However, >> because they are only taken on successful packets, they suffer from >> measurement bias; in the example above of 50% PRR, a network layer >> would see all packets having an excellent LQI value, even though >> packets are lost. This happens in practice, when you have channel >> variations. >> >> Within the TinyOS community, our conclusion is that the MAC layer >> needs to provide 2 bits of information to the network layer. The >> first, the "white bit," is a simplification of things like LQI or SNR >> and essentially indicates whether a received packet had a very low >> BER, indicating it is probably -- but not certainly -- a good link. >> The second, the "ack bit" is signaled on each link layer transmission >> and indicates whether the transmitter received a layer 2 ack. A paper >> in HotNets last year quantified the benefits each of the bits >> provides.[1] >> >> Phil >> >> [1] http://enl.usc.edu/papers/abstract/Fonseca07.html >> >> >> >> _______________________________________________ >> 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 6lowpan-bounces@ietf.org Thu May 29 01:07:56 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72CD3A696F; Thu, 29 May 2008 01:07:56 -0700 (PDT) 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 C5C8C3A68C6 for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 01:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 lBTXwq+1hIYo for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 01:07:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E725C3A6980 for <6lowpan@ietf.org>; Thu, 29 May 2008 01:07:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,560,1204498800"; d="scan'208";a="10187648" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 May 2008 10:07:50 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4T87o7W003211; Thu, 29 May 2008 10:07:50 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4T87o7n007956; Thu, 29 May 2008 08:07:50 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 10:07:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 10:07:16 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0E0C6@xmb-ams-337.emea.cisco.com> In-Reply-To: <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Complete reassemble at every hop (was: [6lowpan] New charter for 6lowpan) Thread-Index: AcjAFnpbLzOs8HHiSwKCU6YIR5KcRABScT5A References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 29 May 2008 08:07:50.0384 (UTC) FILETIME=[1685A700:01C8C163] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6179; t=1212048470; x=1212912470; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20Complete=20reassemble=20at=20every=20hop=20(was =3A=20[6lowpan]=20New=20charter=20for=206lowpan) |Sender:=20; bh=0lQLae8pZAxVOTZULLW2p0sYLMNWarohoeM5gcjez/w=; b=DlrcvLRhEpNtnCTfu3HGTzwvwrCbyYF3l9pFifxivLXa9CbGRfphKI0G0k S0EDg70nbW7mZjqEdsSZUo+q83k5f9zmnBTDU16AE+B7cOWYNluHhb9soK7B KnM1/XpyKA; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: [6lowpan] Complete reassemble at every hop (was: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: I'm trying here to break the thread into components because it's getting unreadable. >First is whether or not route-over implies complete reassembly at >every hop. In my view, it doesn't. A node could simply cache the >datagram tag when the first fragment arrives and forward the >subsequent fragments accordingly. Note that this also saves header >overhead because the mesh header doesn't have to be included in every >fragment. When forwarding between different links, reassembly has to >happen anyway. > This should be addressed in the architecture very clearly. Whether the path is computed at L2 or L3, there's a need to decide and express clearly in the packet what is the source that does the 6LowPAN compression, and what is the destination that expands the packet. An interface on a router should not have to make assumptions on whether a packet will be routed on another interface of the same type or not. I've been trying to parse another of your mails on the same subject and still fail to understand the model you have in mind for what goes in the mesh header if any and what is uncompressed over a multihop LowPAN path. I believe that a few examples with figures would help a lot and that they should end up in the architecture doc once we agree on them. Fair? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 27 mai 2008 18:27 >To: Pascal Thubert (pthubert) >Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > > >Hi Pascal, I see a few underlying issues in this discussion. > >First is whether or not route-over implies complete reassembly at >every hop. In my view, it doesn't. A node could simply cache the >datagram tag when the first fragment arrives and forward the >subsequent fragments accordingly. Note that this also saves header >overhead because the mesh header doesn't have to be included in every >fragment. When forwarding between different links, reassembly has to >happen anyway. > >The second issue is whether or not we constrain forwarding fragments >of a given datagram to a single path. This is where mesh-under and >route-over diverge. But to me, there are a lot of advantages to >constraining delivery of a datagram to a single path. Hop-by-hop >recovery can ensure in-order delivery. Hop-by-hop congestion control >becomes much more meaningful. It's unclear to me what end-to-end >congestion notification means in a mesh-under setting. We can also >take advantage of link optimizations to increase throughput and >decrease latency. And, as mentioned before, reduces header overhead by >not needing addressing information in subsequent fragments. > >The third issue is whether or not end-to-end mechanisms should be used >for recovery and congestion control. I think we agree that hop-by-hop >mechanisms are required regardless. They increase reliability and can >provide effective congestion control and mitigation. To me, hop-by-hop >mechanisms are generally much more effective than end-to-end ones >because they react to local conditions and can quickly provide back- >pressure all the way to the source. From a reliability standpoint, >we've seen solutions deliver >99.9% without end-to-end recovery. So >one question is how much more reliability do we really need? and does >it justify the added energy overhead and code size? > >-- >Jonathan Hui > > > >On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: > >> Hi Phil: >> >> We do agree on the problem. >> >> Per-hop reassembly, though, comes at the expense of that traffic >> fluidity that was so desirable to the ATM designers. In other words, >> because per-hop reassembly forces each intermediate node to store and >> forward a full packet, it is augmenting the latency of the flow and >> the >> memory requirements on the forwarding nodes on the way. >> >> This is why I had in mind to couple a few per-hop recovery with a more >> solid end-to-end recovery and flow control mechanism between the >> LoWPAN >> endpoints. >> >> Now I wonder what this discussion becomes in route over v.s. mesh >> under. >> In route over, it seems that the forwarding node terminates a link >> so it >> has to reassemble before it forwards on a different link that might or >> might not be a LoWPAN; so maybe we end up doing the same thing in that >> case. >> >> Jonathan, what do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> Sent: vendredi 23 mai 2008 19:46 >>> To: Pascal Thubert (pthubert) >>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >> 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> >>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi JP: >>>> >>>> I see your concern. >>>> >>>> I'd argue that ECN is now pretty well defined now in RFC 3168, and >>>> that >>>> the basic operation is pretty simple: emulate a packet loss in RED >> but >>>> save the packet. So the real problem is not ECN itself but what RED >>>> becomes in a LowPAN forwarding node. And that is something that the >>>> node >>>> will have to define whether it does ECN or RED. >>>> >>>> If we do not have ECN then the LowPAN forwarding nodes will have to >>>> destroy frames which might be fragments. Considering the cost of >>>> energy >>>> and bandwidth to getting the frame up to that forwarding node, the >>>> latency introduced by transport layer time out, and the risk of >>>> congestion collapse introduced by resending the whole segment, I'd >>>> suggest that ECN is actually a good idea. >>> >>> This gets back to the point I brought up December 14, 2006. In lossy >>> networks, end-to-end fragmentation and assembly is a real problem. It >>> makes much more sense to do per-hop fragmentation and assembly. In >>> the >>> former, the number of retransmitted fragments is exponential in the >>> number of hops; in the latter, it is linear. >>> >>> Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 29 01:23:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33533A68C6; Thu, 29 May 2008 01:23:18 -0700 (PDT) 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 E0EF23A68A6 for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 01:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 U7GttgzocPYo for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 01:23:12 -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 DF6C33A68C6 for <6lowpan@ietf.org>; Thu, 29 May 2008 01:23:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,560,1204498800"; d="scan'208";a="10189757" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 May 2008 10:23:05 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4T8N5oW008565; Thu, 29 May 2008 10:23:05 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4T8N5Px014636; Thu, 29 May 2008 08:23:05 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 10:23:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 10:22:32 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0E0D7@xmb-ams-337.emea.cisco.com> In-Reply-To: <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjAFnpbLzOs8HHiSwKCU6YIR5KcRABTJHjg References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 29 May 2008 08:23:05.0490 (UTC) FILETIME=[37F7BF20:01C8C165] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2059; t=1212049385; x=1212913385; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=c7BUfFWPaKeU/OPhZ+VTf+V31M5PKDHrdRYXf5RPxGU=; b=Z84j0bvvBFMLrN7HjHSxTGz0OiNGpR5s5wd6mSEuoiyjGrCg8Ai76h2jFy z30ip3luGYz3xuKeWyuZVBhr4OQ0beJ0Gzfzpzb2p5XbMLn9SBUbsJBijKUZ IwEKlQeoKG; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: >The second issue is whether or not we constrain forwarding fragments >of a given datagram to a single path. This is where mesh-under and >route-over diverge. But to me, there are a lot of advantages to >constraining delivery of a datagram to a single path. Hop-by-hop >recovery can ensure in-order delivery. Hop-by-hop congestion control >becomes much more meaningful. It's unclear to me what end-to-end >congestion notification means in a mesh-under setting. We can also >take advantage of link optimizations to increase throughput and >decrease latency. And, as mentioned before, reduces header overhead by >not needing addressing information in subsequent fragments. [Pascal] This is a critical design point. We had long talks with Rick Enns on this. A classical Internet behavior when doing multipath load balancing is to attach a flow on a given path. The reasoning is that if TCP flows are balanced over multiple paths, then all the flows experience the speed of the slowest path. This is due to the reaction of TCP flow control to packets being delayed and arriving out of order. So it's generally better to assign intelligently (based on feed back) or blindly (round robin and hash) the flows to the paths and try your luck. Is this the case here too? Another angle on this is that if we allow fragments over multiple paths, the reassembly process still forces all the paths to converge at the intermediate point where reassembly occurs. Say we have a destination outside of the LoWPAN. We could theoretically have to paths from a mote to that destination over 2 different sinks (default gateways). But that's not possible for fragments because one of the gateways needs all the fragments to reassemble the packet. Finally if we define ECN in 6LowPAN, for instance in the mesh header where it would make sense, then there's always a way for the layer below to pass its congestion information so that the 6LoWPAN mesh handler sets the flag in the mesh header. Many questions... Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 29 01:28:00 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F8E28C201; Thu, 29 May 2008 01:28:00 -0700 (PDT) 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 B99223A6942 for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 01:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 uO7aSh1ZKxYC for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 01:27:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0950528C264 for <6lowpan@ietf.org>; Thu, 29 May 2008 01:25:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,560,1204498800"; d="scan'208";a="10190162" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 May 2008 10:25:51 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4T8PpSQ009528; Thu, 29 May 2008 10:25:51 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4T8PpDl015978; Thu, 29 May 2008 08:25:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 10:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 10:25:18 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0E0E0@xmb-ams-337.emea.cisco.com> In-Reply-To: <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fragments and multipath (was: RE: [6lowpan] New charter for 6lowpan) Thread-Index: AcjAFnpbLzOs8HHiSwKCU6YIR5KcRABTq4zQ References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 29 May 2008 08:25:51.0421 (UTC) FILETIME=[9ADECED0:01C8C165] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6979; t=1212049551; x=1212913551; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20Fragments=20and=20multipath=20(was=3A=20RE=3A=2 0[6lowpan]=20New=20charter=20for=206lowpan) |Sender:=20; bh=/2c2nLcWjInvNW2Fa2ePyBTozIp92aNp7b3645h+ckU=; b=QOCnteF+J6Vzx0Jy75nNrn/+9PKt+8bLhcTKMxzNnzrZjd2/VMC5jlV6Mf dLKuu4/33KLNCGyskdTPyWeLM/lMGqSHufbe3eFo6ff+z2NnLqdkfJNA4Axy dZBU1Bbaq2; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: [6lowpan] Fragments and multipath (was: RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: Resending, I forgot to change the title >The second issue is whether or not we constrain forwarding fragments of >a given datagram to a single path. This is where mesh-under and >route-over diverge. But to me, there are a lot of advantages to >constraining delivery of a datagram to a single path. Hop-by-hop >recovery can ensure in-order delivery. Hop-by-hop congestion control >becomes much more meaningful. It's unclear to me what end-to-end >congestion notification means in a mesh-under setting. We can also take >advantage of link optimizations to increase throughput and decrease >latency. And, as mentioned before, reduces header overhead by not >needing addressing information in subsequent fragments. [Pascal] This is a critical design point. We had long talks with Rick Enns on this. A classical Internet behavior when doing multipath load balancing is to attach a flow on a given path. The reasoning is that if TCP flows are balanced over multiple paths, then all the flows experience the speed of the slowest path. This is due to the reaction of TCP flow control to packets being delayed and arriving out of order. So it's generally better to assign intelligently (based on feed back) or blindly (round robin and hash) the flows to the paths and try your luck. Is this the case here too? Another angle on this is that if we allow fragments over multiple paths, the reassembly process still forces all the paths to converge at the intermediate point where reassembly occurs. Say we have a destination outside of the LoWPAN. We could theoretically have to paths from a mote to that destination over 2 different sinks (default gateways). But that's not possible for fragments because one of the gateways needs all the fragments to reassemble the packet. Finally if we define ECN in 6LowPAN, for instance in the mesh header where it would make sense, then there's always a way for the layer below to pass its congestion information so that the 6LoWPAN mesh handler sets the flag in the mesh header. Many questions... Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 27 mai 2008 18:27 >To: Pascal Thubert (pthubert) >Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > > >Hi Pascal, I see a few underlying issues in this discussion. > >First is whether or not route-over implies complete reassembly at >every hop. In my view, it doesn't. A node could simply cache the >datagram tag when the first fragment arrives and forward the >subsequent fragments accordingly. Note that this also saves header >overhead because the mesh header doesn't have to be included in every >fragment. When forwarding between different links, reassembly has to >happen anyway. > >The second issue is whether or not we constrain forwarding fragments >of a given datagram to a single path. This is where mesh-under and >route-over diverge. But to me, there are a lot of advantages to >constraining delivery of a datagram to a single path. Hop-by-hop >recovery can ensure in-order delivery. Hop-by-hop congestion control >becomes much more meaningful. It's unclear to me what end-to-end >congestion notification means in a mesh-under setting. We can also >take advantage of link optimizations to increase throughput and >decrease latency. And, as mentioned before, reduces header overhead by >not needing addressing information in subsequent fragments. > >The third issue is whether or not end-to-end mechanisms should be used >for recovery and congestion control. I think we agree that hop-by-hop >mechanisms are required regardless. They increase reliability and can >provide effective congestion control and mitigation. To me, hop-by-hop >mechanisms are generally much more effective than end-to-end ones >because they react to local conditions and can quickly provide back- >pressure all the way to the source. From a reliability standpoint, >we've seen solutions deliver >99.9% without end-to-end recovery. So >one question is how much more reliability do we really need? and does >it justify the added energy overhead and code size? > >-- >Jonathan Hui > > > >On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: > >> Hi Phil: >> >> We do agree on the problem. >> >> Per-hop reassembly, though, comes at the expense of that traffic >> fluidity that was so desirable to the ATM designers. In other words, >> because per-hop reassembly forces each intermediate node to store and >> forward a full packet, it is augmenting the latency of the flow and >> the >> memory requirements on the forwarding nodes on the way. >> >> This is why I had in mind to couple a few per-hop recovery with a more >> solid end-to-end recovery and flow control mechanism between the >> LoWPAN >> endpoints. >> >> Now I wonder what this discussion becomes in route over v.s. mesh >> under. >> In route over, it seems that the forwarding node terminates a link >> so it >> has to reassemble before it forwards on a different link that might or >> might not be a LoWPAN; so maybe we end up doing the same thing in that >> case. >> >> Jonathan, what do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> Sent: vendredi 23 mai 2008 19:46 >>> To: Pascal Thubert (pthubert) >>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >> 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> >>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi JP: >>>> >>>> I see your concern. >>>> >>>> I'd argue that ECN is now pretty well defined now in RFC 3168, and >>>> that >>>> the basic operation is pretty simple: emulate a packet loss in RED >> but >>>> save the packet. So the real problem is not ECN itself but what RED >>>> becomes in a LowPAN forwarding node. And that is something that the >>>> node >>>> will have to define whether it does ECN or RED. >>>> >>>> If we do not have ECN then the LowPAN forwarding nodes will have to >>>> destroy frames which might be fragments. Considering the cost of >>>> energy >>>> and bandwidth to getting the frame up to that forwarding node, the >>>> latency introduced by transport layer time out, and the risk of >>>> congestion collapse introduced by resending the whole segment, I'd >>>> suggest that ECN is actually a good idea. >>> >>> This gets back to the point I brought up December 14, 2006. In lossy >>> networks, end-to-end fragmentation and assembly is a real problem. It >>> makes much more sense to do per-hop fragmentation and assembly. In >>> the >>> former, the number of retransmitted fragments is exponential in the >>> number of hops; in the latter, it is linear. >>> >>> Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 29 05:07:04 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E010128C25F; Thu, 29 May 2008 05:07:04 -0700 (PDT) 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 1AE7228C23E for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 05:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.3 X-Spam-Level: X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 bmFo8J67RYaL for <6lowpan@core3.amsl.com>; Thu, 29 May 2008 05:07:00 -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 06F6628C138 for <6lowpan@ietf.org>; Thu, 29 May 2008 05:06:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,561,1204498800"; d="scan'208";a="10222059" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 May 2008 14:06:31 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4TC6VQd016773; Thu, 29 May 2008 14:06:31 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4TC6VIt027735; Thu, 29 May 2008 12:06:31 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 14:06:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 May 2008 14:05:57 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0E24D@xmb-ams-337.emea.cisco.com> In-Reply-To: <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: end-to-end vs. hop-by-hop flow control and recovery (was:RE: [6lowpan] New charter for 6lowpan) Thread-Index: AcjAFnpbLzOs8HHiSwKCU6YIR5KcRABaK31g References: <7892795E1A87F04CADFCCF41FADD00FC05B60A78@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05B615E5@xmb-ams-337.emea.cisco.com> <600DB223-92D7-4635-BD33-2763CA909E8B@cs.stanford.edu> <7892795E1A87F04CADFCCF41FADD00FC05BB9329@xmb-ams-337.emea.cisco.com> <71871A78-B675-4F3F-8BDD-11BD08A193F7@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 29 May 2008 12:06:31.0282 (UTC) FILETIME=[6E714520:01C8C184] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8689; t=1212062791; x=1212926791; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20end-to-end=20vs.=20hop-by-hop=20flow=20control= 20and=20recovery=20(was=3ARE=3A=20[6lowpan]=20New=20charter= 20for=206lowpan) |Sender:=20; bh=ceaGIYQ7BVfrlY66ohwE9c90vsw9xBM7ukaDPWjP038=; b=HgPKjbc2gObjj8JpKhVRmgeLJTarQ4FSnVorYCD5rnVVBZ2MFi5ZHvCUXH CbGK+FNra8S3REaGzXWhZBtLuuXHAVQficZrdnZkW/mZ95xrRLBYiT0nm92n 9XvRbiUQbQ; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan@ietf.org Subject: [6lowpan] end-to-end vs. hop-by-hop flow control and recovery (was:RE: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: Jonathan: >>The third issue is whether or not end-to-end mechanisms should be used >>for recovery and congestion control. I think we agree that hop-by-hop >>mechanisms are required regardless. They increase reliability and can >>provide effective congestion control and mitigation. To me, hop-by-hop >>mechanisms are generally much more effective than end-to-end ones >>because they react to local conditions and can quickly provide back- >>pressure all the way to the source. From a reliability standpoint, >>we've seen solutions deliver >99.9% without end-to-end recovery. So >>one question is how much more reliability do we really need? and does >>it justify the added energy overhead and code size? Phil: >This is an excellent point. On one hand, it is critical that we do not preclude end-to-end recovery >mechanisms, at the very least for the end- to-end argument. On the other, we might be getting a bit >ahead of ourselves here; it's not clear at all whether the benefits of these mechanisms (increased >layer 3 delivery ratios) significantly outweigh their costs (code size and energy). Pascal: For the sake of clarity for anyone reading this thread, the discussion here is about end-to-end LoWPAN path not end-to-end IP path. We have been discussing whether fragmentation can happen end-to-end and here the question is about flow control and recovery. - for flow control I'd argue that the source should be throttled but if possible not all the hops on the way one by one. Hop by hop flow control leads to a general and slow backoff all the way to the source that will impact other connections which should not be impacted. - for recovery, some level of hop by hop recovery helps fro sure but there are limits. For instance is inteferences jam a given node, all the retries will fail, even if it has an alternate next hop. Also, if you have built a graph made of non congruent paths, then end to end retry enables to try an entirely new path. I suspect a mix of the 2 can do better. About the cost of it, well we need to design simple and low overhead. I listed a number of requirements in my draft: Number of fragments The recovery mechanism must support highly fragmented packets, with a maximum of 32 fragments per packet. Minimimum acknowledgement overhead Because the radio is half duplex, and because of silent time spent in the various medium access mechanisms, an acknowledgement consumes roughly as many resources as data fragment. The recovery mechanism should be able to acknowledge multiple fragments in a single message. Controlled latency The recovery mechanism must succeed or give up within the time boundary imposed by the recovery process of the Upper Layer Protocols. Support for out-of-order fragment delivery A Mesh-Under load balancing mechanism such as the ISA100 Data Link Layer can introduce out-of-sequence packets. The recovery mechanism must account for packets that appear lost but are actually only delayed over a different path. Optional flow control The aggregation of multiple concurrent flows may lead to the saturation of the radio network and congestion collapse. The recovery mechanism should provide means for controlling the number of fragments in transit over the LoWPAN. Backward compatibility A node that implements this draft should be able to communicate with a node that implements [RFC4944]. This draft assumes that compatibility information about the remote LoWPAN endpoint is obtained by external means. More in: http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover y Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: mardi 27 mai 2008 18:27 >To: Pascal Thubert (pthubert) >Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); 6lowpan@ietf.org >Subject: Re: [6lowpan] New charter for 6lowpan > > >Hi Pascal, I see a few underlying issues in this discussion. > >First is whether or not route-over implies complete reassembly at >every hop. In my view, it doesn't. A node could simply cache the >datagram tag when the first fragment arrives and forward the >subsequent fragments accordingly. Note that this also saves header >overhead because the mesh header doesn't have to be included in every >fragment. When forwarding between different links, reassembly has to >happen anyway. > >The second issue is whether or not we constrain forwarding fragments >of a given datagram to a single path. This is where mesh-under and >route-over diverge. But to me, there are a lot of advantages to >constraining delivery of a datagram to a single path. Hop-by-hop >recovery can ensure in-order delivery. Hop-by-hop congestion control >becomes much more meaningful. It's unclear to me what end-to-end >congestion notification means in a mesh-under setting. We can also >take advantage of link optimizations to increase throughput and >decrease latency. And, as mentioned before, reduces header overhead by >not needing addressing information in subsequent fragments. > >The third issue is whether or not end-to-end mechanisms should be used >for recovery and congestion control. I think we agree that hop-by-hop >mechanisms are required regardless. They increase reliability and can >provide effective congestion control and mitigation. To me, hop-by-hop >mechanisms are generally much more effective than end-to-end ones >because they react to local conditions and can quickly provide back- >pressure all the way to the source. From a reliability standpoint, >we've seen solutions deliver >99.9% without end-to-end recovery. So >one question is how much more reliability do we really need? and does >it justify the added energy overhead and code size? > >-- >Jonathan Hui > > > >On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: > >> Hi Phil: >> >> We do agree on the problem. >> >> Per-hop reassembly, though, comes at the expense of that traffic >> fluidity that was so desirable to the ATM designers. In other words, >> because per-hop reassembly forces each intermediate node to store and >> forward a full packet, it is augmenting the latency of the flow and >> the >> memory requirements on the forwarding nodes on the way. >> >> This is why I had in mind to couple a few per-hop recovery with a more >> solid end-to-end recovery and flow control mechanism between the >> LoWPAN >> endpoints. >> >> Now I wonder what this discussion becomes in route over v.s. mesh >> under. >> In route over, it seems that the forwarding node terminates a link >> so it >> has to reassemble before it forwards on a different link that might or >> might not be a LoWPAN; so maybe we end up doing the same thing in that >> case. >> >> Jonathan, what do you think? >> >> Pascal >> >>> -----Original Message----- >>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>> Sent: vendredi 23 mai 2008 19:46 >>> To: Pascal Thubert (pthubert) >>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >> 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> >>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi JP: >>>> >>>> I see your concern. >>>> >>>> I'd argue that ECN is now pretty well defined now in RFC 3168, and >>>> that >>>> the basic operation is pretty simple: emulate a packet loss in RED >> but >>>> save the packet. So the real problem is not ECN itself but what RED >>>> becomes in a LowPAN forwarding node. And that is something that the >>>> node >>>> will have to define whether it does ECN or RED. >>>> >>>> If we do not have ECN then the LowPAN forwarding nodes will have to >>>> destroy frames which might be fragments. Considering the cost of >>>> energy >>>> and bandwidth to getting the frame up to that forwarding node, the >>>> latency introduced by transport layer time out, and the risk of >>>> congestion collapse introduced by resending the whole segment, I'd >>>> suggest that ECN is actually a good idea. >>> >>> This gets back to the point I brought up December 14, 2006. In lossy >>> networks, end-to-end fragmentation and assembly is a real problem. It >>> makes much more sense to do per-hop fragmentation and assembly. In >>> the >>> former, the number of retransmitted fragments is exponential in the >>> number of hops; in the latter, it is linear. >>> >>> Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 29 08:48:11 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C49528C17A; Thu, 29 May 2008 08:48:11 -0700 (PDT) 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 41F6728C23E; Thu, 29 May 2008 08:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 63rPoBlmdlA6; Thu, 29 May 2008 08:48:08 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4A09128C17A; Thu, 29 May 2008 08:48:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204531200"; d="scan'208";a="73641106" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 May 2008 08:48:07 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFm75m031930; Thu, 29 May 2008 08:48:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFm7mk016598; Thu, 29 May 2008 15:48:07 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:48:06 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:48:06 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:48:02 -0400 From: JP Vasseur To: Philip Levis , "Benjamin A. Rolfe" Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjBo2BTFQVY2oG0o0mY9pN0fWLrrw== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:48:06.0945 (UTC) FILETIME=[63467110:01C8C1A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4455; t=1212076087; x=1212940087; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20; bh=5fjOFCjLIr1a8A8RMmMDwLFxfK9Syu+4FWrDwqKKdO0=; b=hnn9oby4dzZl/YSKbbq+NaD2Q/f8rk49rssy7LG+dlLIFZJEqCNy0HBDs9 QJpwTi3dR+xT1byMFIfAQMF3tsO9z7Sg1xrUQkFLUGlRrzSJXDO+DfPNnc34 MDvfJ5MJkn; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Phil, I share your analysis, it is a difficult thing to do, especially with very unstable links. But this is also true with many other technologies. Look at QoS with RED when you need to decide when dropping packet based on queue length with bursty traffic: you use low pass filters. They are not perfect but good enough. As you pointed out below, you could end up collapsing the metric to 1 bit or provide a more granular indicator/metric but in all cases you need to make sure that the mechanism is robust enough to avoid routing oscillation: an interesting topic of discussion to come ... Cheers. JP. On 5/29/08 1:49 AM, "Philip Levis" wrote: > > On May 28, 2008, at 9:02 PM, Benjamin A. Rolfe wrote: >> Sorry, first post to the list, so forgive if I'm sounding like a >> newbie... >> How would one get link quality information to the upper layers >> other than >> via a MAC service? >> I can see inserting a shim-layer service to isolate upper layers >> form the >> different MACs which may be under it, so as to provide a consistent >> service >> interface. Of course you can only get what the MAC provides, but >> the shim >> layer and upper layer's can be designed to handle gracefully >> different MAC >> capabilities (at least consistently). >> >> I'm asking with a bit of a bias here: I'm currently working on MAC >> enhancements for 802.15.4 (in task group "e" in 802.15), including a >> proposal for enhanced link assessment information from the MAC. So >> of course >> I'd suggest not ruling out some better link metrics in the 802.15.4 >> MAC at >> some point, although upper layers still need to deal with existing >> 802.15.4 >> devices. So the general thinking from upper layer uses is very >> interesting. >> Thanks >> > > This is a very good question. It turns out to be very difficult, for > two major reasons: separation of concerns and time scale. For the > sake of simplicity, let's just consider the simplest link quality > metric, the packet reception ratio. > > By separation of concerns, I mean that the MAC layer has to maintain > state to generate link estimates. However, the MAC layer does not > know which links are useful to a network layer. That is, it could > learn and estimate the best links, but those links could be not very > good for routing. For example, they could lead to a disconnected > network, or high stretch routes. > > By time scale, I mean that if the average PRR over ten seconds is > 50%, that could be due to bursts of high and bursts of low reception. > Let's say that an application sends a packet every one second, the > link layer transmits 5 times, and the 50% PRR is due to 5 seconds of > 0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will > transmit 25 packets, with no successful deliveries. Meanwhile, during > the 5 seconds of 100%, it will transmit five packets with 5 > deliveries. While the PRR over the 10 second window was 50%, the link > layer observed a PRR of 16% (5/30). > > Most radio chips (e.g., CC2420 and RF230) provide LQI as chip > correlation values over some number of packet octets. These physical > layer measurements effectively add significant bits to the SNR in the > sharp part of the BER curve, and are amazingly useful. However, > because they are only taken on successful packets, they suffer from > measurement bias; in the example above of 50% PRR, a network layer > would see all packets having an excellent LQI value, even though > packets are lost. This happens in practice, when you have channel > variations. > > Within the TinyOS community, our conclusion is that the MAC layer > needs to provide 2 bits of information to the network layer. The > first, the "white bit," is a simplification of things like LQI or SNR > and essentially indicates whether a received packet had a very low > BER, indicating it is probably -- but not certainly -- a good link. > The second, the "ack bit" is signaled on each link layer transmission > and indicates whether the transmitter received a layer 2 ack. A paper > in HotNets last year quantified the benefits each of the bits > provides.[1] > > Phil > > [1] http://enl.usc.edu/papers/abstract/Fonseca07.html > > > > _______________________________________________ > 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 6lowpan-bounces@ietf.org Thu May 29 08:48:20 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE1128C221; Thu, 29 May 2008 08:48:20 -0700 (PDT) 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 7D85328C176; Thu, 29 May 2008 08:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 soHR1NRGuvwe; Thu, 29 May 2008 08:48:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 21E113A6A79; Thu, 29 May 2008 08:48:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204520400"; d="scan'208";a="9555330" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 May 2008 11:48:14 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFmEdW020700; Thu, 29 May 2008 11:48:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFmEJK022367; Thu, 29 May 2008 15:48:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:48:14 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:48:13 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:48:09 -0400 From: JP Vasseur To: Philip Levis , Eunsook Eunah Kim Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjBo2SA9K8k2G+YIUCdbfN4e4lQ+Q== In-Reply-To: <46F9415E-C501-4232-B314-75333E78C4B6@cs.stanford.edu> Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:48:14.0012 (UTC) FILETIME=[677CC7C0:01C8C1A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1469; t=1212076094; x=1212940094; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20Philip=20Levis=20,=0A=20=20=20= 20=20=20=20=20Eunsook=20Eunah=20Kim=20; bh=DK0lFVvTPp3a3fdHWeZKzN7AsEldEZtLKJrk208g65A=; b=iPcrzAxnWmX+fCSqraLXBE6vOnGBS8ZYgVkbD1HsfSnvXFYklid5mL+y5l 2T7GNyg42A4tMt2mSDVkfp9kK3Q95BabJ9YyBwJta7/3RniXkbTlC+zKOS1o wqwg4FwCSF; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org In that particular example (LQI), translate it into a routing link metric and we'll achieve what you're trying to do. The use of a dynamic metric has to be studied with great care of course to prevent oscillations. Look at the ARPANET experiment using dynamic metrics. JP. On 5/28/08 11:36 AM, "Philip Levis" wrote: > > On May 28, 2008, at 1:04 AM, Eunsook Eunah Kim wrote: > >> Dear Philip, >> >>> What happens when a new low power link layer emerges? Having N >>> different solutions, each with their own details, which somehow need >>> to be made to work well together, seems like a path of brittle and >>> difficult to manage networks. Switches are good, to a point; >>> there's a >>> reason you have routers. >>> >> >> We don't talk about solutions. We want to see if 6LoWPAN has special >> routing requirements due to 802.15.4 specific or not. If route-over >> solutions can be provided to fit the requirements of 6LoWPAN, I'm >> happy. > > Exactly: as soon as you start talking about things like LQI, you are > coupling yourself not only to a specific link layer, but also a > specific implementation of that link layer. In practice, many networks > use the 802.15.4 link layer but not its MAC layer, as it has terrible > energy properties. > > Phil > _______________________________________________ > 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 6lowpan-bounces@ietf.org Thu May 29 08:48:28 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C73F28C176; Thu, 29 May 2008 08:48:28 -0700 (PDT) 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 6545A3A6A79; Thu, 29 May 2008 08:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 TjH9syez0OHE; Thu, 29 May 2008 08:48:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 630F828C176; Thu, 29 May 2008 08:48:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,562,1204520400"; d="scan'208";a="9555364" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 29 May 2008 11:48:19 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4TFmJPW020823; Thu, 29 May 2008 11:48:19 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4TFmJ4R023542; Thu, 29 May 2008 15:48:19 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 May 2008 11:48:18 -0400 Received: from 10.21.118.139 ([10.21.118.139]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 29 May 2008 15:48:18 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 29 May 2008 11:48:15 -0400 From: JP Vasseur To: Philip Levis , Carles Gomez Montenegro Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjBo2gT8B0FO8W5I0yiQWBZn+AUFw== Mime-version: 1.0 X-OriginalArrivalTime: 29 May 2008 15:48:18.0934 (UTC) FILETIME=[6A6BD160:01C8C1A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2079; t=1212076099; x=1212940099; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20Philip=20Levis=20,=0A=20=20=20= 20=20=20=20=20Carles=20Gomez=20Montenegro=20; bh=+wx+pWx8GLIqQdJv0bWvCvqX+lTwaEft4NtCC0qcalQ=; b=PtzbTWVh5Zt4foxFktCz3nhyxa2/45PuZWqJ/IYt1aKGjQdqVBi66F+rUD g2H1R39et66ke1K6yDqDSwwBpdZaEMcjrOTe0CN126rs6HEmRYhMElxkdshB gyrbjVV0O9; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Phil and Carles, On 5/28/08 1:38 AM, "Philip Levis" wrote: > On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote: >> >> At least, there are the following items listed in the routing >> requirements >> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt) >> that route-over approach cannot provide or would provide only in a >> limited >> way: > > I disagree wholeheartedly. So do I. I think there is a big confusion here > between a protocol specification and a protocol implementation. > > These are all arguments for cross-layer design, that tightly > integrating routing and the link layer will lead to a better solution. > Practice has shown us otherwise; Indeed, "practice" being "The Internet". only by clearly separating concerns > do you give a protocol the flexibility needed to evolve over time. > What happens when a new low power link layer emerges? Having N > different solutions, each with their own details, which somehow need > to be made to work well together, seems like a path of brittle and > difficult to manage networks. Switches are good, to a point; there's a > reason you have routers. > > The purpose of a protocol specification, IMO, is to specify what is > needed for interoperability; there should, in theory, be multiple > possible implementations (and by that, I mean power saving approaches) > that can all interoperate. Indeed. Carles, we're not saying that L3 should not take into account the specific characteristics of L2. This is why we have the following WG item: "- Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs." There are a few cases where cross-layer "collaboration" may be quite powerful but we need to be very careful at what we're doing here. Thanks. JP. > > Phil > > _______________________________________________ > 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 6lowpan-bounces@ietf.org Fri May 30 00:26:48 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0945C3A6C10; Fri, 30 May 2008 00:26:48 -0700 (PDT) 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 F10AB3A67A4 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 00:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usi-aMq65W60 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 00:26:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DFFEC3A6CC7 for <6lowpan@ietf.org>; Fri, 30 May 2008 00:26:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,565,1204520400"; d="scan'208";a="9628488" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 May 2008 03:26:02 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4U7Q2Av025344; Fri, 30 May 2008 03:26:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4U7Q2ed019416; Fri, 30 May 2008 07:26:02 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 03:26:02 -0400 Received: from 144.254.93.8 ([144.254.93.8]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 May 2008 07:26:02 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 30 May 2008 04:11:10 +0200 From: JP Vasseur To: "Pascal Thubert (pthubert)" , Jonathan Hui Message-ID: Thread-Topic: [6lowpan] New charter for 6lowpan Thread-Index: AcjAFnpbLzOs8HHiSwKCU6YIR5KcRABTJHjgACXYRSo= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0E0D7@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 30 May 2008 07:26:02.0570 (UTC) FILETIME=[6A295AA0:01C8C226] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2575; t=1212132362; x=1212996362; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20charter=20for=206lowp an |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20,=0A=20=20=20=20=20=20=20=20Jonathan=20Hui=20; bh=GGWL0zdcRwVSAANtjqM5wJAUuY4EAWXwhG//2mPWDSQ=; b=Yu2Zc7yp8m94HVyyJMMqzQpDZJWql65iXsEdgRiisXH6VuNR9RVhD3a+UE B+ofnHApTCAMlf72RJNoFkNCYOfkrpk9JyZ6kQgH0u8+P9voHCA1gMFzgC3B 5zlKwnfTlW; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] New charter for 6lowpan 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, On 5/29/08 4:22 AM, "Pascal Thubert (pthubert)" wrote: > Hi Jonathan: > >> The second issue is whether or not we constrain forwarding fragments >> of a given datagram to a single path. This is where mesh-under and >> route-over diverge. But to me, there are a lot of advantages to >> constraining delivery of a datagram to a single path. Hop-by-hop >> recovery can ensure in-order delivery. Hop-by-hop congestion control >> becomes much more meaningful. It's unclear to me what end-to-end >> congestion notification means in a mesh-under setting. We can also >> take advantage of link optimizations to increase throughput and >> decrease latency. And, as mentioned before, reduces header overhead by >> not needing addressing information in subsequent fragments. > > [Pascal] This is a critical design point. We had long talks with Rick > Enns on this. > > A classical Internet behavior when doing multipath load balancing is to > attach a flow on a given path. The reasoning is that if TCP flows are > balanced over multiple paths, then all the flows experience the speed of > the slowest path. This is due to the reaction of TCP flow control to > packets being delayed and arriving out of order. > > So it's generally better to assign intelligently (based on feed back) or > blindly (round robin and hash) the flows to the paths and try your luck. > Is this the case here too? And ... This is not the only issue. Should you need to apply RED mechanisms, the use of multiple path for a single flow becomes challenging since you may end up affecting many more flow than needed. > > Another angle on this is that if we allow fragments over multiple paths, > the reassembly process still forces all the paths to converge at the > intermediate point where reassembly occurs. Say we have a destination > outside of the LoWPAN. We could theoretically have to paths from a mote > to that destination over 2 different sinks (default gateways). But > that's not possible for fragments because one of the gateways needs all > the fragments to reassemble the packet. > This is one of the issues that I also pointed out when highlighting the shortcomings of combining mesh under and route over. > Finally if we define ECN in 6LowPAN, for instance in the mesh header > where it would make sense, then there's always a way for the layer below > to pass its congestion information so that the 6LoWPAN mesh handler sets > the flag in the mesh header. > > Many questions... > JP. > Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 30 00:26:49 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A0B93A6CA3; Fri, 30 May 2008 00:26:49 -0700 (PDT) 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 82B863A6881 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8R+Ef+1tp94 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 00:26:46 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A8BF13A6CD2 for <6lowpan@ietf.org>; Fri, 30 May 2008 00:26:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,565,1204520400"; d="scan'208";a="9637447" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 30 May 2008 03:26:03 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4U7Q3PY024763; Fri, 30 May 2008 03:26:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4U7Q3jp019421; Fri, 30 May 2008 07:26:03 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 03:26:03 -0400 Received: from 144.254.93.8 ([144.254.93.8]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 May 2008 07:26:03 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 30 May 2008 04:16:50 +0200 From: JP Vasseur To: "Pascal Thubert (pthubert)" , Jonathan Hui Message-ID: Thread-Topic: Complete reassemble at every hop (was: [6lowpan] New charter for 6lowpan) Thread-Index: AcjAFnpbLzOs8HHiSwKCU6YIR5KcRABScT5AACa+Kc4= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0E0C6@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 30 May 2008 07:26:03.0115 (UTC) FILETIME=[6A7C83B0:01C8C226] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6993; t=1212132363; x=1212996363; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20Complete=20reassemble=20at=20every=20ho p=20(was=3A=20[6lowpan]=20New=20charter=20for=0A=206lowpan) |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20,=0A=20=20=20=20=20=20=20=20Jonathan=20Hui=20; bh=A/4ECSMI5Hwh5Ae+7b0Uv2qiICerJixeZv/FGCNS800=; b=I2FRb/MAi0W4vhnRi4n9PxOA8B72Ydyg0uXGDRGz1U2PP7b/TVOLo6dnK4 2TzdyeThN3u0OqGdGwIAAwk1ZCK83EC4kZ9aRbrnonS0RZLI50oNY3xP0dtv 19rNLIHQep; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Complete reassemble at every hop (was: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, On 5/29/08 4:07 AM, "Pascal Thubert (pthubert)" wrote: > Hi Jonathan: > > I'm trying here to break the thread into components because it's getting > unreadable. > >> First is whether or not route-over implies complete reassembly at >> every hop. In my view, it doesn't. A node could simply cache the >> datagram tag when the first fragment arrives and forward the >> subsequent fragments accordingly. Oops ! You mean route a fragment based on the routing decision made for the first fragment ? Not sure I personally like this, since this introduces some states on intermediate nodes, which has strong implication. Further, this means that a fragmented packet cannot be rerouted along a backup path once the first fragment has been sent out since nodes along the alternate path would not have the required states to route them. Note that this also saves header >> overhead because the mesh header doesn't have to be included in every >> fragment. When forwarding between different links, reassembly has to >> happen anyway. >> > > This should be addressed in the architecture very clearly. Whether the > path is computed at L2 or L3, there's a need to decide and express > clearly in the packet what is the source that does the 6LowPAN > compression, and what is the destination that expands the packet. An > interface on a router should not have to make assumptions on whether a > packet will be routed on another interface of the same type or not. > > I've been trying to parse another of your mails on the same subject and > still fail to understand the model you have in mind for what goes in the > mesh header if any and what is uncompressed over a multihop LowPAN path. > I believe that a few examples with figures would help a lot and that > they should end up in the architecture doc once we agree on them. > > Fair? Indeed. Cheers, JP. > > Pascal >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: mardi 27 mai 2008 18:27 >> To: Pascal Thubert (pthubert) >> Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley > (townsley); 6lowpan@ietf.org >> Subject: Re: [6lowpan] New charter for 6lowpan >> >> >> Hi Pascal, I see a few underlying issues in this discussion. >> >> First is whether or not route-over implies complete reassembly at >> every hop. In my view, it doesn't. A node could simply cache the >> datagram tag when the first fragment arrives and forward the >> subsequent fragments accordingly. Note that this also saves header >> overhead because the mesh header doesn't have to be included in every >> fragment. When forwarding between different links, reassembly has to >> happen anyway. >> >> The second issue is whether or not we constrain forwarding fragments >> of a given datagram to a single path. This is where mesh-under and >> route-over diverge. But to me, there are a lot of advantages to >> constraining delivery of a datagram to a single path. Hop-by-hop >> recovery can ensure in-order delivery. Hop-by-hop congestion control >> becomes much more meaningful. It's unclear to me what end-to-end >> congestion notification means in a mesh-under setting. We can also >> take advantage of link optimizations to increase throughput and >> decrease latency. And, as mentioned before, reduces header overhead by >> not needing addressing information in subsequent fragments. >> >> The third issue is whether or not end-to-end mechanisms should be used >> for recovery and congestion control. I think we agree that hop-by-hop >> mechanisms are required regardless. They increase reliability and can >> provide effective congestion control and mitigation. To me, hop-by-hop >> mechanisms are generally much more effective than end-to-end ones >> because they react to local conditions and can quickly provide back- >> pressure all the way to the source. From a reliability standpoint, >> we've seen solutions deliver >99.9% without end-to-end recovery. So >> one question is how much more reliability do we really need? and does >> it justify the added energy overhead and code size? >> >> -- >> Jonathan Hui >> >> >> >> On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi Phil: >>> >>> We do agree on the problem. >>> >>> Per-hop reassembly, though, comes at the expense of that traffic >>> fluidity that was so desirable to the ATM designers. In other words, >>> because per-hop reassembly forces each intermediate node to store and >>> forward a full packet, it is augmenting the latency of the flow and >>> the >>> memory requirements on the forwarding nodes on the way. >>> >>> This is why I had in mind to couple a few per-hop recovery with a > more >>> solid end-to-end recovery and flow control mechanism between the >>> LoWPAN >>> endpoints. >>> >>> Now I wonder what this discussion becomes in route over v.s. mesh >>> under. >>> In route over, it seems that the forwarding node terminates a link >>> so it >>> has to reassemble before it forwards on a different link that might > or >>> might not be a LoWPAN; so maybe we end up doing the same thing in > that >>> case. >>> >>> Jonathan, what do you think? >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>> Sent: vendredi 23 mai 2008 19:46 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >>> 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>> >>>> >>>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>>> >>>>> Hi JP: >>>>> >>>>> I see your concern. >>>>> >>>>> I'd argue that ECN is now pretty well defined now in RFC 3168, and >>>>> that >>>>> the basic operation is pretty simple: emulate a packet loss in RED >>> but >>>>> save the packet. So the real problem is not ECN itself but what RED >>>>> becomes in a LowPAN forwarding node. And that is something that the >>>>> node >>>>> will have to define whether it does ECN or RED. >>>>> >>>>> If we do not have ECN then the LowPAN forwarding nodes will have to >>>>> destroy frames which might be fragments. Considering the cost of >>>>> energy >>>>> and bandwidth to getting the frame up to that forwarding node, the >>>>> latency introduced by transport layer time out, and the risk of >>>>> congestion collapse introduced by resending the whole segment, I'd >>>>> suggest that ECN is actually a good idea. >>>> >>>> This gets back to the point I brought up December 14, 2006. In lossy >>>> networks, end-to-end fragmentation and assembly is a real problem. > It >>>> makes much more sense to do per-hop fragmentation and assembly. In >>>> the >>>> former, the number of retransmitted fragments is exponential in the >>>> number of hops; in the latter, it is linear. >>>> >>>> Phil > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 30 00:26:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5FB3A6CE7; Fri, 30 May 2008 00:26:50 -0700 (PDT) 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 5C75E3A6B52 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 00:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64D765bCeq05 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 00:26:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4CA273A6CCC for <6lowpan@ietf.org>; Fri, 30 May 2008 00:26:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,565,1204520400"; d="scan'208,217";a="9628489" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 May 2008 03:26:04 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4U7Q49M025348 for <6lowpan@ietf.org>; Fri, 30 May 2008 03:26:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4U7Q3Tv018362 for <6lowpan@ietf.org>; Fri, 30 May 2008 07:26:03 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 03:26:03 -0400 Received: from 144.254.93.8 ([144.254.93.8]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 30 May 2008 07:26:03 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 30 May 2008 04:25:01 +0200 From: JP Vasseur To: <6lowpan@ietf.org> Message-ID: Thread-Topic: A suggestion ... With regards to re-chartering Thread-Index: AcjB/FygQ04APyTUxUeT7O8OowwGYw== Mime-version: 1.0 X-OriginalArrivalTime: 30 May 2008 07:26:03.0867 (UTC) FILETIME=[6AEF42B0:01C8C226] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2172; t=1212132364; x=1212996364; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20A=20suggestion=20...=20With=20regards=20to=20re -chartering |Sender:=20 |To:=20<6lowpan@ietf.org>; bh=7ZWLfpDPncRuYdhfXJiM5JdYa6z1Fri+DCnuqEe3eNY=; b=kTw9aZDtb5JLwi570bSdwJ2ZntiMXPVyMaO0OKOArND7G9hWORPDwUt6/e 0mte4AHKtp8SOtHKAQBEMpeYJ7EyDGTB1nWb4esHikVdyla7+g1xM8Of3nDG pdO0w9CQLL; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: multipart/mixed; boundary="===============1962646662==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1962646662== Content-type: multipart/alternative; boundary="B_3294984362_5176202" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3294984362_5176202 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Just a suggestion for the chairs and the WG. We have discussed many important items for 6lowpan. For several of them, all important, I think that there was a clear agreement: statefull header compression, security, Architecture ID, fragmentation, ..... For other ones such as the =B3Mesh-under=B2 and =B3Route over=B2 discussion, there are diverging point of views. So why not trying to quickly re-charter adding the items for which there is a consensus and continue the discussion on the open issues in the meantime until we have an agreement at which point the WG may re-charter ? As we all know, the WG has been fairly slow in term of progress and it is I think now urgent to move on. Thoughts ? Thanks. JP. --B_3294984362_5176202 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable A suggestion ... With regards to re-chartering Hi,

Just a suggestion for the chairs and the WG.

We have discussed many important items for 6lowpan.

For several of them, all important, I think that there was a clear agreemen= t: statefull header compression, security, Architecture ID, fragmentation, .= .... For other ones such as the “Mesh-under” and “Route ov= er” discussion, there are diverging point of views.

So why not trying to quickly re-charter adding the items for which there is= a consensus and continue the discussion on the open issues in the meantime = until we have an agreement at which point the WG may re-charter ?

As we all know, the WG has been fairly slow in term of progress and it is I= think now urgent to move on.

Thoughts ?

Thanks.

JP. --B_3294984362_5176202-- --===============1962646662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============1962646662==-- From 6lowpan-bounces@ietf.org Fri May 30 03:43:01 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4AC3A68BF; Fri, 30 May 2008 03:43:01 -0700 (PDT) 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 5FB1C3A68BF for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 03:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiaOR4FTzamQ for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 03:42:55 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id E778A3A6867 for <6lowpan@ietf.org>; Fri, 30 May 2008 03:42:54 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so62693and.122 for <6lowpan@ietf.org>; Fri, 30 May 2008 03:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=jCbYPUZC99BAtfwPGD0OEWS2hR+9M9Wp9WyLWCxqZYo=; b=FZGpeeE/mBMvuZjl0LHzemd9ZLPqBop90VuztLNEPt70z0OWLgyB9ExoxakoOeS2ywXezXNOKgJ4s2t7kNFf35W1oGG3sOE5IBQQ0ISwI9VX6cBfEUJ4NLWJbLZcBXQpmQ2AcvnSlwfteGkfow4b2qsVczlb4P9hlavICFdZgMs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lyd1BaqWn04+s7+4mU8fd8js2W/+dc99TRMFPM3AZqxsroTRnDntZPAPf6zCQd6wP+HVJtTV6Arjzuwf8/oB5C5SbOr8CjG/Y1SEzVY1mHWuIbB52ez9XDmdtw6L/OYF8JE3vODfqYUvRmmDo+T1POWG9oXaLBP9Cx5yjYkTRqw= Received: by 10.100.210.9 with SMTP id i9mr1115100ang.119.1212144171856; Fri, 30 May 2008 03:42:51 -0700 (PDT) Received: by 10.100.134.3 with HTTP; Fri, 30 May 2008 03:42:51 -0700 (PDT) Message-ID: Date: Fri, 30 May 2008 19:42:51 +0900 From: "Daniel Park" To: "JP Vasseur" In-Reply-To: MIME-Version: 1.0 References: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: multipart/mixed; boundary="===============2084161007==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============2084161007== Content-Type: multipart/alternative; boundary="----=_Part_5721_30478778.1212144171865" ------=_Part_5721_30478778.1212144171865 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline + 1 -- Soohong Daniel Park [at] Samsung Electronics Standard Architect, http://blog.naver.com/natpt On 5/30/08, JP Vasseur wrote: > > Hi, > > *Just a suggestion* for the chairs and the WG. > > We have discussed many important items for 6lowpan. > > For several of them, all important, I think that there was a clear > agreement: statefull header compression, security, Architecture ID, > fragmentation, ..... For other ones such as the "Mesh-under" and "Route > over" discussion, there are diverging point of views. > > So why not trying to quickly re-charter adding the items for which there is > a consensus and continue the discussion on the open issues in the meantime > until we have an agreement at which point the WG may re-charter ? > > As we all know, the WG has been fairly slow in term of progress and it is I > think now urgent to move on. > > Thoughts ? > > Thanks. > > JP. > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > ------=_Part_5721_30478778.1212144171865 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
+ 1
 
--
Soohong Daniel Park [at] Samsung Electronics
Standard Architect, http://blog.naver.com/natpt

 
On 5/30/08, JP Vasseur <jvasseur@cisco.com> wrote:
Hi,

Just a suggestion for the chairs and the WG.

We have discussed many important items for 6lowpan.

For several of them, all important, I think that there was a clear agreement: statefull header compression, security, Architecture ID, fragmentation, ..... For other ones such as the "Mesh-under" and "Route over" discussion, there are diverging point of views.

So why not trying to quickly re-charter adding the items for which there is a consensus and continue the discussion on the open issues in the meantime until we have an agreement at which point the WG may re-charter ?

As we all know, the WG has been fairly slow in term of progress and it is I think now urgent to move on.

Thoughts ?

Thanks.

JP.

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




------=_Part_5721_30478778.1212144171865-- --===============2084161007== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============2084161007==-- From 6lowpan-bounces@ietf.org Fri May 30 05:49:38 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7241F28C1DD; Fri, 30 May 2008 05:49:38 -0700 (PDT) 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 0FA3428C1D9 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 05:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.624 X-Spam-Level: X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.975, 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 SZq0qXXF9pSV for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 05:49:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5292428C1DE for <6lowpan@ietf.org>; Fri, 30 May 2008 05:49:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,566,1204498800"; d="scan'208";a="10341114" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 May 2008 14:49:22 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4UCnMiQ018782 for <6lowpan@ietf.org>; Fri, 30 May 2008 14:49:22 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4UCnM1J008270 for <6lowpan@ietf.org>; Fri, 30 May 2008 12:49:22 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 14:49:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 14:48:48 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] A suggestion ... With regards to re-chartering Thread-Index: AcjB/FygQ04APyTUxUeT7O8OowwGYwAVJgcQ References: From: "Pascal Thubert (pthubert)" To: "Jean Philippe Vasseur (jvasseur)" , <6lowpan@ietf.org> X-OriginalArrivalTime: 30 May 2008 12:49:22.0474 (UTC) FILETIME=[9567C8A0:01C8C253] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2584; t=1212151762; x=1213015762; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20A=20suggestion=20...=20With =20regards=20to=20re-chartering |Sender:=20; bh=WXJHvDMN0ZRG4f5+uwVzpDpKzpVdevYwfDD+0D0fpc8=; b=LWIzNAr05zvvl/IoxftqBLGg4rq3JUjmu0xB4gn4Lu3546dkX0tslgeR6N ejAIDcWKkAsvA9HI+MqYqs6Avb2UUgIYbZ+kW/BrHgwr2MjAK0w6ikrKyp+w AUUQutfjU/; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi JP Works with me. I went through the published work and the recent thread " New charter for 6lowpan". My conclusion is as follows: >From the reworked charter, we should keep Work Items 1, 3, and 5 which appear of foremost importance, drop 2 and 4 because pragmatically we are not advanced enough in these areas. For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple with draft-thubert-6lowpan-backbone-router and we have most of the content we need to make a standard track doc. For 3) we have draft-culler-6lowpan-architecture. It needs improvement in particular in explaining route over vs. mesh under in details as we currently discuss in the ML. Also mobility, backbone... but we have people interested in the discussion (see current threads) so we should work it out. For 5) we have draft-daniel-6lowpan-security-analysis. We need to make sure we have people committed to the effort but the current draft looks good already. To those 3, I'd add: Explore requirements and usages. --------------------------------- We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. I'd add to it some words on existing standards that need or use 6LowPAN. In particular, we need to place ISA100 requirements in there to be able to better serve them later. RFC 4944 maintenance and improvements ------------------------------------- This should cover at least 6lowpan HC and fragment recovery efforts. We can discuss if we want ECN in that work item as well. What do you think? Pascal ________________________________________ From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Jean Philippe Vasseur (jvasseur) Sent: vendredi 30 mai 2008 04:25 To: 6lowpan@ietf.org Subject: [6lowpan] A suggestion ... With regards to re-chartering Hi, Just a suggestion for the chairs and the WG. We have discussed many important items for 6lowpan. For several of them, all important, I think that there was a clear agreement: stateful header compression, security, Architecture ID, fragmentation, ..... For other ones such as the "Mesh-under" and "Route over" discussion, there are diverging point of views. So why not trying to quickly re-charter adding the items for which there is a consensus and continue the discussion on the open issues in the meantime until we have an agreement at which point the WG may re-charter ? As we all know, the WG has been fairly slow in term of progress and it is I think now urgent to move on. Thoughts ? Thanks. JP. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 30 08:14:22 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC7D3A68EF; Fri, 30 May 2008 08:14:22 -0700 (PDT) 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 12EA03A69F2 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 08:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 lbQAb3PfxJ7U for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 08:14:16 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id DD5593A68A2 for <6lowpan@ietf.org>; Fri, 30 May 2008 08:14:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A6822A92E5; Fri, 30 May 2008 08:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WucfCcXDG6nv; Fri, 30 May 2008 08:14:09 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 764E7A92EE; Fri, 30 May 2008 08:14:09 -0700 (PDT) Message-Id: From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 08:14:08 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Everyone, In support of most of this. For ND, we should add work on route-over as well, which I've committed to at the last WG meeting. Architecture is needed at this stage, and I'm willing to help drive it. RFC 4944 maintenance is needed as well. I still think we need some document to define requirements for a L2 meshing over 802.15.4 subnetwork. As I've said before, this could be a separate document or a part of the architecture document. I hope we can close on this quickly... -- Jonathan Hui On May 30, 2008, at 5:48 AM, Pascal Thubert (pthubert) wrote: > Hi JP > > Works with me. I went through the published work and the recent > thread " > New charter for 6lowpan". > My conclusion is as follows: > > From the reworked charter, we should keep Work Items 1, 3, and 5 which > appear of foremost importance, drop 2 and 4 because pragmatically we > are > not advanced enough in these areas. > > For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple > with > draft-thubert-6lowpan-backbone-router and we have most of the > content we > need to make a standard track doc. > > For 3) we have draft-culler-6lowpan-architecture. It needs improvement > in particular in explaining route over vs. mesh under in details as we > currently discuss in the ML. Also mobility, backbone... but we have > people interested in the discussion (see current threads) so we should > work it out. > > For 5) we have draft-daniel-6lowpan-security-analysis. We need to make > sure we have people committed to the effort but the current draft > looks > good already. > > To those 3, I'd add: > > Explore requirements and usages. > --------------------------------- > We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. > I'd > add to it some words on existing standards that need or use 6LowPAN. > In > particular, we need to place ISA100 requirements in there to be able > to > better serve them later. > > RFC 4944 maintenance and improvements > ------------------------------------- > This should cover at least 6lowpan HC and fragment recovery efforts. > We > can discuss if we want ECN in that work item as well. > > What do you think? > > Pascal > ________________________________________ > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jean Philippe Vasseur (jvasseur) > Sent: vendredi 30 mai 2008 04:25 > To: 6lowpan@ietf.org > Subject: [6lowpan] A suggestion ... With regards to re-chartering > > Hi, > > Just a suggestion for the chairs and the WG. > > We have discussed many important items for 6lowpan. > > For several of them, all important, I think that there was a clear > agreement: stateful header compression, security, Architecture ID, > fragmentation, ..... For other ones such as the "Mesh-under" and > "Route > over" discussion, there are diverging point of views. > > So why not trying to quickly re-charter adding the items for which > there > is a consensus and continue the discussion on the open issues in the > meantime until we have an agreement at which point the WG may re- > charter > ? > > As we all know, the WG has been fairly slow in term of progress and it > is I think now urgent to move on. > > Thoughts ? > > Thanks. > > JP. > _______________________________________________ > 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 6lowpan-bounces@ietf.org Fri May 30 08:32:55 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC353A68D8; Fri, 30 May 2008 08:32:55 -0700 (PDT) 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 AC3A33A68D8 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 08:32:53 -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 9-qg9j2TU0WB for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 08:32:49 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 62F7B3A67DB for <6lowpan@ietf.org>; Fri, 30 May 2008 08:32:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 4678CA92EF; Fri, 30 May 2008 08:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL0y3qu7536X; Fri, 30 May 2008 08:32:43 -0700 (PDT) Received: from [192.168.7.66] (69-12-164-139.sfo.archedrock.com [69.12.164.139]) by mail.sf.archrock.com (Postfix) with ESMTP id 77F06A92EE; Fri, 30 May 2008 08:32:43 -0700 (PDT) Message-Id: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> From: Jonathan Hui To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 08:32:42 -0700 References: X-Mailer: Apple Mail (2.924) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Complete reassemble at every hop (was: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal and JP, see below: On May 29, 2008, at 7:16 PM, JP Vasseur wrote: >>> First is whether or not route-over implies complete reassembly at >>> every hop. In my view, it doesn't. A node could simply cache the >>> datagram tag when the first fragment arrives and forward the >>> subsequent fragments accordingly. > > Oops ! You mean route a fragment based on the routing decision made > for the > first fragment ? Not sure I personally like this, since this > introduces some > states on intermediate nodes, which has strong implication. > Further, this means that a fragmented packet cannot be rerouted > along a > backup path once the first fragment has been sent out since nodes > along the > alternate path would not have the required states to route them. Yes, it does consume extra state, but the overhead is pretty small, around 10-bytes for caching two tags, two addresses, and timing information. When the last fragment rolls by, you can quickly clean up the state. It's still an open question for me how may simultaneous flows of fragmented datagrams is truly needed. Re-routing mid-stream is arguably less important for delivering a fragmented datagram, especially due to temporal properties of the link. > Note that this also saves header >>> overhead because the mesh header doesn't have to be included in >>> every >>> fragment. When forwarding between different links, reassembly has to >>> happen anyway. >>> >> >> This should be addressed in the architecture very clearly. Whether >> the >> path is computed at L2 or L3, there's a need to decide and express >> clearly in the packet what is the source that does the 6LowPAN >> compression, and what is the destination that expands the packet. An >> interface on a router should not have to make assumptions on >> whether a >> packet will be routed on another interface of the same type or not. Yes, I've said all along that the architecture document is necessary. Where reassembly happens has been pretty clear in my mind, and must happen before you exit a 6lowpan-based IP link. >> I've been trying to parse another of your mails on the same subject >> and >> still fail to understand the model you have in mind for what goes >> in the >> mesh header if any and what is uncompressed over a multihop LowPAN >> path. >> I believe that a few examples with figures would help a lot and that >> they should end up in the architecture doc once we agree on them. The Mesh Addressing header is currently defined in RFC4944 and the addresses carried within that header identify the end-points of an IP hop. With L3 forwarding, the Mesh Addressing header contains the same addresses as the 802.15.4 header and so the Mesh Addressing header can be elided. I've provided a few examples at the WG meetings. Can you tell me what specific scenarios you're confused about, so I can address them directly? -- Jonathan Hui >> >> >> Fair? > > Indeed. > > Cheers, > > JP. > >> >> Pascal >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: mardi 27 mai 2008 18:27 >>> To: Pascal Thubert (pthubert) >>> Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley >> (townsley); 6lowpan@ietf.org >>> Subject: Re: [6lowpan] New charter for 6lowpan >>> >>> >>> Hi Pascal, I see a few underlying issues in this discussion. >>> >>> First is whether or not route-over implies complete reassembly at >>> every hop. In my view, it doesn't. A node could simply cache the >>> datagram tag when the first fragment arrives and forward the >>> subsequent fragments accordingly. Note that this also saves header >>> overhead because the mesh header doesn't have to be included in >>> every >>> fragment. When forwarding between different links, reassembly has to >>> happen anyway. >>> >>> The second issue is whether or not we constrain forwarding fragments >>> of a given datagram to a single path. This is where mesh-under and >>> route-over diverge. But to me, there are a lot of advantages to >>> constraining delivery of a datagram to a single path. Hop-by-hop >>> recovery can ensure in-order delivery. Hop-by-hop congestion control >>> becomes much more meaningful. It's unclear to me what end-to-end >>> congestion notification means in a mesh-under setting. We can also >>> take advantage of link optimizations to increase throughput and >>> decrease latency. And, as mentioned before, reduces header >>> overhead by >>> not needing addressing information in subsequent fragments. >>> >>> The third issue is whether or not end-to-end mechanisms should be >>> used >>> for recovery and congestion control. I think we agree that hop-by- >>> hop >>> mechanisms are required regardless. They increase reliability and >>> can >>> provide effective congestion control and mitigation. To me, hop-by- >>> hop >>> mechanisms are generally much more effective than end-to-end ones >>> because they react to local conditions and can quickly provide back- >>> pressure all the way to the source. From a reliability standpoint, >>> we've seen solutions deliver >99.9% without end-to-end recovery. So >>> one question is how much more reliability do we really need? and >>> does >>> it justify the added energy overhead and code size? >>> >>> -- >>> Jonathan Hui >>> >>> >>> >>> On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hi Phil: >>>> >>>> We do agree on the problem. >>>> >>>> Per-hop reassembly, though, comes at the expense of that traffic >>>> fluidity that was so desirable to the ATM designers. In other >>>> words, >>>> because per-hop reassembly forces each intermediate node to store >>>> and >>>> forward a full packet, it is augmenting the latency of the flow and >>>> the >>>> memory requirements on the forwarding nodes on the way. >>>> >>>> This is why I had in mind to couple a few per-hop recovery with a >> more >>>> solid end-to-end recovery and flow control mechanism between the >>>> LoWPAN >>>> endpoints. >>>> >>>> Now I wonder what this discussion becomes in route over v.s. mesh >>>> under. >>>> In route over, it seems that the forwarding node terminates a link >>>> so it >>>> has to reassemble before it forwards on a different link that might >> or >>>> might not be a LoWPAN; so maybe we end up doing the same thing in >> that >>>> case. >>>> >>>> Jonathan, what do you think? >>>> >>>> Pascal >>>> >>>>> -----Original Message----- >>>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>>> Sent: vendredi 23 mai 2008 19:46 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >>>> 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>> >>>>> >>>>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi JP: >>>>>> >>>>>> I see your concern. >>>>>> >>>>>> I'd argue that ECN is now pretty well defined now in RFC 3168, >>>>>> and >>>>>> that >>>>>> the basic operation is pretty simple: emulate a packet loss in >>>>>> RED >>>> but >>>>>> save the packet. So the real problem is not ECN itself but what >>>>>> RED >>>>>> becomes in a LowPAN forwarding node. And that is something that >>>>>> the >>>>>> node >>>>>> will have to define whether it does ECN or RED. >>>>>> >>>>>> If we do not have ECN then the LowPAN forwarding nodes will >>>>>> have to >>>>>> destroy frames which might be fragments. Considering the cost of >>>>>> energy >>>>>> and bandwidth to getting the frame up to that forwarding node, >>>>>> the >>>>>> latency introduced by transport layer time out, and the risk of >>>>>> congestion collapse introduced by resending the whole segment, >>>>>> I'd >>>>>> suggest that ECN is actually a good idea. >>>>> >>>>> This gets back to the point I brought up December 14, 2006. In >>>>> lossy >>>>> networks, end-to-end fragmentation and assembly is a real problem. >> It >>>>> makes much more sense to do per-hop fragmentation and assembly. In >>>>> the >>>>> former, the number of retransmitted fragments is exponential in >>>>> the >>>>> number of hops; in the latter, it is linear. >>>>> >>>>> Phil >> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 30 09:32:50 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FDE3A69EC; Fri, 30 May 2008 09:32:50 -0700 (PDT) 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 DAD3C3A69EC for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 09:32: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEF41YAW-NST for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 09:32:45 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 95C7D3A68B1 for <6lowpan@ietf.org>; Fri, 30 May 2008 09:32:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2D88BA92F4; Fri, 30 May 2008 09:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi5uJnaHXLah; Fri, 30 May 2008 09:32:39 -0700 (PDT) Received: from [192.168.7.85] (69-12-164-136.sfo.archedrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 0C608A934F; Fri, 30 May 2008 09:32:39 -0700 (PDT) Message-Id: <016BECD3-E32B-42BD-AC8B-677D5D651DBB@archrock.com> From: Jonathan Hui To: Geoff Mulligan In-Reply-To: <1212163859.8681.53.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 09:32:38 -0700 References: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> <1212163859.8681.53.camel@dellx1> X-Mailer: Apple Mail (2.924) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Geoff, On May 30, 2008, at 9:10 AM, Geoff Mulligan wrote: > Jonathan, > We have the ID for routing requirements. Could this, or a portion of > it, be the starting point for the L2 meshing (mehs under) requirements > document. Just to be clear, I was referring to my earlier proposal of having a document something like: "requirements and suggestions for 6lowpan mesh-under subnetwork designs". Routing is only one piece of that, and we can certainly start by taking the existing ID for routing requirements. But there are a lot of other issues (e.g. whether or not multicast emulation is supported and if so what properties do we expect of it, what kind of latencies do we expect, what kind of traffic flows do we assume, if not arbitrary point-to-point, etc.). These are all useful items for other SDOs to refer to. > I've been thinking about the Routing Requirements doc. Should 6lowpan > generate a ID that is a WG doc for use by ROLL as requirements for > Route > Over or should we (members of 6lowpan) just make sure that the current > drafts within roll address our needs and concerns and the the Routing > Requirements draft should instead be focused on mesh under. The primary value of having a doc come from 6LoWPAN is that we can state 6LoWPAN-specific requirements. The ROLL requirements have them in more general terms (e.g. low throughput, small MTU, etc.), while 6LoWPAN can state some hard constraints (e.g. 250 kbps at 2.4GHz, 127 byte MTU (smaller after headers), etc.). I'm not sure how important it is to state the specifics, but if we feel it is important then I'm fine with that. -- Jonathan Hui > > > geoff > > On Fri, 2008-05-30 at 08:14 -0700, Jonathan Hui wrote: >> Hi Everyone, >> >> In support of most of this. For ND, we should add work on route-over >> as well, which I've committed to at the last WG meeting. Architecture >> is needed at this stage, and I'm willing to help drive it. RFC 4944 >> maintenance is needed as well. >> >> I still think we need some document to define requirements for a L2 >> meshing over 802.15.4 subnetwork. As I've said before, this could >> be a >> separate document or a part of the architecture document. >> >> I hope we can close on this quickly... >> >> -- >> Jonathan Hui >> >> On May 30, 2008, at 5:48 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi JP >>> >>> Works with me. I went through the published work and the recent >>> thread " >>> New charter for 6lowpan". >>> My conclusion is as follows: >>> >>> From the reworked charter, we should keep Work Items 1, 3, and 5 >>> which >>> appear of foremost importance, drop 2 and 4 because pragmatically we >>> are >>> not advanced enough in these areas. >>> >>> For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple >>> with >>> draft-thubert-6lowpan-backbone-router and we have most of the >>> content we >>> need to make a standard track doc. >>> >>> For 3) we have draft-culler-6lowpan-architecture. It needs >>> improvement >>> in particular in explaining route over vs. mesh under in details >>> as we >>> currently discuss in the ML. Also mobility, backbone... but we have >>> people interested in the discussion (see current threads) so we >>> should >>> work it out. >>> >>> For 5) we have draft-daniel-6lowpan-security-analysis. We need to >>> make >>> sure we have people committed to the effort but the current draft >>> looks >>> good already. >>> >>> To those 3, I'd add: >>> >>> Explore requirements and usages. >>> --------------------------------- >>> We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. >>> I'd >>> add to it some words on existing standards that need or use 6LowPAN. >>> In >>> particular, we need to place ISA100 requirements in there to be able >>> to >>> better serve them later. >>> >>> RFC 4944 maintenance and improvements >>> ------------------------------------- >>> This should cover at least 6lowpan HC and fragment recovery efforts. >>> We >>> can discuss if we want ECN in that work item as well. >>> >>> What do you think? >>> >>> Pascal >>> ________________________________________ >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Jean Philippe Vasseur (jvasseur) >>> Sent: vendredi 30 mai 2008 04:25 >>> To: 6lowpan@ietf.org >>> Subject: [6lowpan] A suggestion ... With regards to re-chartering >>> >>> Hi, >>> >>> Just a suggestion for the chairs and the WG. >>> >>> We have discussed many important items for 6lowpan. >>> >>> For several of them, all important, I think that there was a clear >>> agreement: stateful header compression, security, Architecture ID, >>> fragmentation, ..... For other ones such as the "Mesh-under" and >>> "Route >>> over" discussion, there are diverging point of views. >>> >>> So why not trying to quickly re-charter adding the items for which >>> there >>> is a consensus and continue the discussion on the open issues in the >>> meantime until we have an agreement at which point the WG may re- >>> charter >>> ? >>> >>> As we all know, the WG has been fairly slow in term of progress >>> and it >>> is I think now urgent to move on. >>> >>> Thoughts ? >>> >>> Thanks. >>> >>> JP. >>> _______________________________________________ >>> 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 6lowpan-bounces@ietf.org Fri May 30 09:33:26 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1AB3A695C; Fri, 30 May 2008 09:33:26 -0700 (PDT) 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 5562F3A69F9 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 09:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aWZMZxhzm31 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 09:13:07 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id CFF1F3A6C2C for <6lowpan@ietf.org>; Fri, 30 May 2008 09:11:12 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m4UGAqgs019030; Fri, 30 May 2008 10:10:53 -0600 (MDT) From: Geoff Mulligan To: Jonathan Hui In-Reply-To: References: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> Date: Fri, 30 May 2008 10:10:59 -0600 Message-Id: <1212163859.8681.53.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 X-Mailman-Approved-At: Fri, 30 May 2008 09:33:19 -0700 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Jonathan, We have the ID for routing requirements. Could this, or a portion of it, be the starting point for the L2 meshing (mehs under) requirements document. I've been thinking about the Routing Requirements doc. Should 6lowpan generate a ID that is a WG doc for use by ROLL as requirements for Route Over or should we (members of 6lowpan) just make sure that the current drafts within roll address our needs and concerns and the the Routing Requirements draft should instead be focused on mesh under. geoff On Fri, 2008-05-30 at 08:14 -0700, Jonathan Hui wrote: > Hi Everyone, > > In support of most of this. For ND, we should add work on route-over > as well, which I've committed to at the last WG meeting. Architecture > is needed at this stage, and I'm willing to help drive it. RFC 4944 > maintenance is needed as well. > > I still think we need some document to define requirements for a L2 > meshing over 802.15.4 subnetwork. As I've said before, this could be a > separate document or a part of the architecture document. > > I hope we can close on this quickly... > > -- > Jonathan Hui > > On May 30, 2008, at 5:48 AM, Pascal Thubert (pthubert) wrote: > > > Hi JP > > > > Works with me. I went through the published work and the recent > > thread " > > New charter for 6lowpan". > > My conclusion is as follows: > > > > From the reworked charter, we should keep Work Items 1, 3, and 5 which > > appear of foremost importance, drop 2 and 4 because pragmatically we > > are > > not advanced enough in these areas. > > > > For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple > > with > > draft-thubert-6lowpan-backbone-router and we have most of the > > content we > > need to make a standard track doc. > > > > For 3) we have draft-culler-6lowpan-architecture. It needs improvement > > in particular in explaining route over vs. mesh under in details as we > > currently discuss in the ML. Also mobility, backbone... but we have > > people interested in the discussion (see current threads) so we should > > work it out. > > > > For 5) we have draft-daniel-6lowpan-security-analysis. We need to make > > sure we have people committed to the effort but the current draft > > looks > > good already. > > > > To those 3, I'd add: > > > > Explore requirements and usages. > > --------------------------------- > > We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. > > I'd > > add to it some words on existing standards that need or use 6LowPAN. > > In > > particular, we need to place ISA100 requirements in there to be able > > to > > better serve them later. > > > > RFC 4944 maintenance and improvements > > ------------------------------------- > > This should cover at least 6lowpan HC and fragment recovery efforts. > > We > > can discuss if we want ECN in that work item as well. > > > > What do you think? > > > > Pascal > > ________________________________________ > > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > > Behalf Of Jean Philippe Vasseur (jvasseur) > > Sent: vendredi 30 mai 2008 04:25 > > To: 6lowpan@ietf.org > > Subject: [6lowpan] A suggestion ... With regards to re-chartering > > > > Hi, > > > > Just a suggestion for the chairs and the WG. > > > > We have discussed many important items for 6lowpan. > > > > For several of them, all important, I think that there was a clear > > agreement: stateful header compression, security, Architecture ID, > > fragmentation, ..... For other ones such as the "Mesh-under" and > > "Route > > over" discussion, there are diverging point of views. > > > > So why not trying to quickly re-charter adding the items for which > > there > > is a consensus and continue the discussion on the open issues in the > > meantime until we have an agreement at which point the WG may re- > > charter > > ? > > > > As we all know, the WG has been fairly slow in term of progress and it > > is I think now urgent to move on. > > > > Thoughts ? > > > > Thanks. > > > > JP. > > _______________________________________________ > > 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 6lowpan-bounces@ietf.org Fri May 30 09:48:05 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A3B28C1E3; Fri, 30 May 2008 09:48:05 -0700 (PDT) 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 D11913A6C0E for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 09:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.780, 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 8eWLaVk+gRkG for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 09:48:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D23CD3A6B32 for <6lowpan@ietf.org>; Fri, 30 May 2008 09:45:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,568,1204498800"; d="scan'208";a="10373333" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 May 2008 18:45:50 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m4UGjo1P032737; Fri, 30 May 2008 18:45:50 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4UGjo9X014959; Fri, 30 May 2008 16:45:50 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 May 2008 18:45:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 May 2008 18:45:15 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0E89B@xmb-ams-337.emea.cisco.com> In-Reply-To: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Complete reassemble at every hop (was: [6lowpan] New charter for 6lowpan) Thread-Index: AcjCan9mGGjMuNSmRGyRQzewjcHxpAABN7jg References: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Jean Philippe Vasseur (jvasseur)" X-OriginalArrivalTime: 30 May 2008 16:45:50.0149 (UTC) FILETIME=[9DEB2F50:01C8C274] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10696; t=1212165950; x=1213029950; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20Complete=20reassemble=20at=20every=20ho p=20(was=3A=20[6lowpan]=20New=20charter=20for=206lowpan) |Sender:=20; bh=1NVGwZPHquCYhrXWdhKJOeXGkuH0bPoghinXZmnEb7s=; b=Bp03zQl1U4Pfydg+wP5eP+Y+gUL3Yttje8VzmHYr/ObmA7PF6zCDcstX7T ZSU4rMcSe5rP4vyI7obcWP7yyg97Yq7IEAYjRpp6MmjpAPeHlob8Wkh3/Uhs qzikqKkV7C; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Complete reassemble at every hop (was: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan: >>> I've been trying to parse another of your mails on the same subject >>> and >>> still fail to understand the model you have in mind for what goes >>> in the >>> mesh header if any and what is uncompressed over a multihop LowPAN >>> path. >>> I believe that a few examples with figures would help a lot and that >>> they should end up in the architecture doc once we agree on them. > >The Mesh Addressing header is currently defined in RFC4944 and the >addresses carried within that header identify the end-points of an IP >hop. With L3 forwarding, the Mesh Addressing header contains the same >addresses as the 802.15.4 header and so the Mesh Addressing header can >be elided. I've provided a few examples at the WG meetings. Can you >tell me what specific scenarios you're confused about, so I can >address them directly? Say the path over a LoWPAN from a node A to a Backbone Router BbR is via B and C Say A sends a packet to D that is reachable over the BbR that acts as default gateway and 6LoWPAN termination for the LoWPAN. A---->B---->C---->BbR---------->D <-----------------> <-----------> LoWPAN Backbone How I see things: If we use a mesh header then it will show (A->BbR) all the way through the LoWPAN In particular, between B and C, it seems to me that the frame should have: - (b->c) in the MAC hdr; - (a->BbR) in the mesh header; - and indicate in the HC that A address is compressed whereas D is not. That seems to work whether the routing is computed at L2 or L3. Now if you do not have a mesh header, I fail to understand: 1) How the receive interface in C knows that the 6LowPAN continues (it is not the LoWPAN endpoint so it should not reassemble) 2) How we make sure that all fragments reach BbR for reassembly. Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: vendredi 30 mai 2008 17:33 >To: Jean Philippe Vasseur (jvasseur) >Cc: Pascal Thubert (pthubert); Philip Levis; Mark Townsley (townsley); 6lowpan@ietf.org >Subject: Re: Complete reassemble at every hop (was: [6lowpan] New charter for 6lowpan) > > >Hi Pascal and JP, see below: >On May 29, 2008, at 7:16 PM, JP Vasseur wrote: >>>> First is whether or not route-over implies complete reassembly at >>>> every hop. In my view, it doesn't. A node could simply cache the >>>> datagram tag when the first fragment arrives and forward the >>>> subsequent fragments accordingly. >> >> Oops ! You mean route a fragment based on the routing decision made >> for the >> first fragment ? Not sure I personally like this, since this >> introduces some >> states on intermediate nodes, which has strong implication. >> Further, this means that a fragmented packet cannot be rerouted >> along a >> backup path once the first fragment has been sent out since nodes >> along the >> alternate path would not have the required states to route them. > >Yes, it does consume extra state, but the overhead is pretty small, >around 10-bytes for caching two tags, two addresses, and timing >information. When the last fragment rolls by, you can quickly clean up >the state. It's still an open question for me how may simultaneous >flows of fragmented datagrams is truly needed. Re-routing mid-stream >is arguably less important for delivering a fragmented datagram, >especially due to temporal properties of the link. > >> Note that this also saves header >>>> overhead because the mesh header doesn't have to be included in >>>> every >>>> fragment. When forwarding between different links, reassembly has to >>>> happen anyway. >>>> >>> >>> This should be addressed in the architecture very clearly. Whether >>> the >>> path is computed at L2 or L3, there's a need to decide and express >>> clearly in the packet what is the source that does the 6LowPAN >>> compression, and what is the destination that expands the packet. An >>> interface on a router should not have to make assumptions on >>> whether a >>> packet will be routed on another interface of the same type or not. > >Yes, I've said all along that the architecture document is necessary. >Where reassembly happens has been pretty clear in my mind, and must >happen before you exit a 6lowpan-based IP link. > >>> I've been trying to parse another of your mails on the same subject >>> and >>> still fail to understand the model you have in mind for what goes >>> in the >>> mesh header if any and what is uncompressed over a multihop LowPAN >>> path. >>> I believe that a few examples with figures would help a lot and that >>> they should end up in the architecture doc once we agree on them. > >The Mesh Addressing header is currently defined in RFC4944 and the >addresses carried within that header identify the end-points of an IP >hop. With L3 forwarding, the Mesh Addressing header contains the same >addresses as the 802.15.4 header and so the Mesh Addressing header can >be elided. I've provided a few examples at the WG meetings. Can you >tell me what specific scenarios you're confused about, so I can >address them directly? > >-- >Jonathan Hui > >>> >>> >>> Fair? >> >> Indeed. >> >> Cheers, >> >> JP. >> >>> >>> Pascal >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: mardi 27 mai 2008 18:27 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley >>> (townsley); 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>> >>>> >>>> Hi Pascal, I see a few underlying issues in this discussion. >>>> >>>> First is whether or not route-over implies complete reassembly at >>>> every hop. In my view, it doesn't. A node could simply cache the >>>> datagram tag when the first fragment arrives and forward the >>>> subsequent fragments accordingly. Note that this also saves header >>>> overhead because the mesh header doesn't have to be included in >>>> every >>>> fragment. When forwarding between different links, reassembly has to >>>> happen anyway. >>>> >>>> The second issue is whether or not we constrain forwarding fragments >>>> of a given datagram to a single path. This is where mesh-under and >>>> route-over diverge. But to me, there are a lot of advantages to >>>> constraining delivery of a datagram to a single path. Hop-by-hop >>>> recovery can ensure in-order delivery. Hop-by-hop congestion control >>>> becomes much more meaningful. It's unclear to me what end-to-end >>>> congestion notification means in a mesh-under setting. We can also >>>> take advantage of link optimizations to increase throughput and >>>> decrease latency. And, as mentioned before, reduces header >>>> overhead by >>>> not needing addressing information in subsequent fragments. >>>> >>>> The third issue is whether or not end-to-end mechanisms should be >>>> used >>>> for recovery and congestion control. I think we agree that hop-by- >>>> hop >>>> mechanisms are required regardless. They increase reliability and >>>> can >>>> provide effective congestion control and mitigation. To me, hop-by- >>>> hop >>>> mechanisms are generally much more effective than end-to-end ones >>>> because they react to local conditions and can quickly provide back- >>>> pressure all the way to the source. From a reliability standpoint, >>>> we've seen solutions deliver >99.9% without end-to-end recovery. So >>>> one question is how much more reliability do we really need? and >>>> does >>>> it justify the added energy overhead and code size? >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>> >>>> On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: >>>> >>>>> Hi Phil: >>>>> >>>>> We do agree on the problem. >>>>> >>>>> Per-hop reassembly, though, comes at the expense of that traffic >>>>> fluidity that was so desirable to the ATM designers. In other >>>>> words, >>>>> because per-hop reassembly forces each intermediate node to store >>>>> and >>>>> forward a full packet, it is augmenting the latency of the flow and >>>>> the >>>>> memory requirements on the forwarding nodes on the way. >>>>> >>>>> This is why I had in mind to couple a few per-hop recovery with a >>> more >>>>> solid end-to-end recovery and flow control mechanism between the >>>>> LoWPAN >>>>> endpoints. >>>>> >>>>> Now I wonder what this discussion becomes in route over v.s. mesh >>>>> under. >>>>> In route over, it seems that the forwarding node terminates a link >>>>> so it >>>>> has to reassemble before it forwards on a different link that might >>> or >>>>> might not be a LoWPAN; so maybe we end up doing the same thing in >>> that >>>>> case. >>>>> >>>>> Jonathan, what do you think? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>>>> Sent: vendredi 23 mai 2008 19:46 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >>>>> 6lowpan@ietf.org >>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>> >>>>>> >>>>>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>>>>> >>>>>>> Hi JP: >>>>>>> >>>>>>> I see your concern. >>>>>>> >>>>>>> I'd argue that ECN is now pretty well defined now in RFC 3168, >>>>>>> and >>>>>>> that >>>>>>> the basic operation is pretty simple: emulate a packet loss in >>>>>>> RED >>>>> but >>>>>>> save the packet. So the real problem is not ECN itself but what >>>>>>> RED >>>>>>> becomes in a LowPAN forwarding node. And that is something that >>>>>>> the >>>>>>> node >>>>>>> will have to define whether it does ECN or RED. >>>>>>> >>>>>>> If we do not have ECN then the LowPAN forwarding nodes will >>>>>>> have to >>>>>>> destroy frames which might be fragments. Considering the cost of >>>>>>> energy >>>>>>> and bandwidth to getting the frame up to that forwarding node, >>>>>>> the >>>>>>> latency introduced by transport layer time out, and the risk of >>>>>>> congestion collapse introduced by resending the whole segment, >>>>>>> I'd >>>>>>> suggest that ECN is actually a good idea. >>>>>> >>>>>> This gets back to the point I brought up December 14, 2006. In >>>>>> lossy >>>>>> networks, end-to-end fragmentation and assembly is a real problem. >>> It >>>>>> makes much more sense to do per-hop fragmentation and assembly. In >>>>>> the >>>>>> former, the number of retransmitted fragments is exponential in >>>>>> the >>>>>> number of hops; in the latter, it is linear. >>>>>> >>>>>> Phil >>> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 30 10:13:18 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B051328C1E5; Fri, 30 May 2008 10:13:18 -0700 (PDT) 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 85D3B3A69EC for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 10:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYVFTakidfQR for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 10:13:15 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D146928C1E4 for <6lowpan@ietf.org>; Fri, 30 May 2008 10:13:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9368BA9354; Fri, 30 May 2008 10:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOsAAg3V84hk; Fri, 30 May 2008 10:13:09 -0700 (PDT) Received: from [192.168.7.85] (69-12-164-136.sfo.archedrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 00657A9351; Fri, 30 May 2008 10:13:08 -0700 (PDT) Message-Id: <89DFB2C9-0C80-464E-B28B-001AB9C4C361@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0E89B@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 30 May 2008 10:13:07 -0700 References: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0E89B@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Complete reassemble at every hop (was: New charter for 6lowpan) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, On May 30, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote: > Say the path over a LoWPAN from a node A to a Backbone Router BbR is > via > B and C > Say A sends a packet to D that is reachable over the BbR that acts as > default > gateway and 6LoWPAN termination for the LoWPAN. > > A---->B---->C---->BbR---------->D > <-----------------> <-----------> > LoWPAN Backbone > > How I see things: > If we use a mesh header then it will show (A->BbR) all the way through > the LoWPAN > In particular, between B and C, it seems to me that the frame should > have: > - (b->c) in the MAC hdr; > - (a->BbR) in the mesh header; > - and indicate in the HC that A address is compressed whereas D is > not. > That seems to work whether the routing is computed at L2 or L3. Okay. Given your scenario, the Mesh Addressing header may not identify the endpoints of an IP hop. For me, things get more complex and confusing in this scenario. You're trying to bridge one or more 802.15.4 PANs using a different link technology but the Mesh Addressing header doesn't provide the means to address nodes in other PANs. To cleanly support the scenario where multiple PANs connected over a different link technology appear as a single link, I'd much rather see a Mesh Addressing header that can hold PANIDs of the source and destination and then simply bridge 802.15.4 frames across the backbone network. Then you aren't constrained to forcing all fragments to ingress/egress through a single BbR. If you truly want to enable multi-path routing, then why not support it in full? > Now if you do not have a mesh header, I fail to understand: > 1) How the receive interface in C knows that the 6LowPAN continues > (it is not the LoWPAN endpoint so it should not reassemble) If you're doing L3 forwarding, then simply match on the IPv6 destination address. If you're doing L2 forwarding, then you need the Mesh Addressing header if you're forwarding over >1 802.15.4 hop. > 2) How we make sure that all fragments reach BbR for reassembly. If you're doing L3 forwarding, fragments are constrained to a single path. The BbR is replaced with a traditional IP router. -- Jonathan Hui > > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: vendredi 30 mai 2008 17:33 >> To: Jean Philippe Vasseur (jvasseur) >> Cc: Pascal Thubert (pthubert); Philip Levis; Mark Townsley >> (townsley); > 6lowpan@ietf.org >> Subject: Re: Complete reassemble at every hop (was: [6lowpan] New > charter for 6lowpan) >> >> >> Hi Pascal and JP, see below: >> On May 29, 2008, at 7:16 PM, JP Vasseur wrote: >>>>> First is whether or not route-over implies complete reassembly at >>>>> every hop. In my view, it doesn't. A node could simply cache the >>>>> datagram tag when the first fragment arrives and forward the >>>>> subsequent fragments accordingly. >>> >>> Oops ! You mean route a fragment based on the routing decision made >>> for the >>> first fragment ? Not sure I personally like this, since this >>> introduces some >>> states on intermediate nodes, which has strong implication. >>> Further, this means that a fragmented packet cannot be rerouted >>> along a >>> backup path once the first fragment has been sent out since nodes >>> along the >>> alternate path would not have the required states to route them. >> >> Yes, it does consume extra state, but the overhead is pretty small, >> around 10-bytes for caching two tags, two addresses, and timing >> information. When the last fragment rolls by, you can quickly clean >> up >> the state. It's still an open question for me how may simultaneous >> flows of fragmented datagrams is truly needed. Re-routing mid-stream >> is arguably less important for delivering a fragmented datagram, >> especially due to temporal properties of the link. >> >>> Note that this also saves header >>>>> overhead because the mesh header doesn't have to be included in >>>>> every >>>>> fragment. When forwarding between different links, reassembly has > to >>>>> happen anyway. >>>>> >>>> >>>> This should be addressed in the architecture very clearly. Whether >>>> the >>>> path is computed at L2 or L3, there's a need to decide and express >>>> clearly in the packet what is the source that does the 6LowPAN >>>> compression, and what is the destination that expands the packet. >>>> An >>>> interface on a router should not have to make assumptions on >>>> whether a >>>> packet will be routed on another interface of the same type or not. >> >> Yes, I've said all along that the architecture document is necessary. >> Where reassembly happens has been pretty clear in my mind, and must >> happen before you exit a 6lowpan-based IP link. >> >>>> I've been trying to parse another of your mails on the same subject >>>> and >>>> still fail to understand the model you have in mind for what goes >>>> in the >>>> mesh header if any and what is uncompressed over a multihop LowPAN >>>> path. >>>> I believe that a few examples with figures would help a lot and >>>> that >>>> they should end up in the architecture doc once we agree on them. >> >> The Mesh Addressing header is currently defined in RFC4944 and the >> addresses carried within that header identify the end-points of an IP >> hop. With L3 forwarding, the Mesh Addressing header contains the same >> addresses as the 802.15.4 header and so the Mesh Addressing header >> can >> be elided. I've provided a few examples at the WG meetings. Can you >> tell me what specific scenarios you're confused about, so I can >> address them directly? >> >> -- >> Jonathan Hui >> >>>> >>>> >>>> Fair? >>> >>> Indeed. >>> >>> Cheers, >>> >>> JP. >>> >>>> >>>> Pascal >>>>> -----Original Message----- >>>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>>> Sent: mardi 27 mai 2008 18:27 >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley >>>> (townsley); 6lowpan@ietf.org >>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>> >>>>> >>>>> Hi Pascal, I see a few underlying issues in this discussion. >>>>> >>>>> First is whether or not route-over implies complete reassembly at >>>>> every hop. In my view, it doesn't. A node could simply cache the >>>>> datagram tag when the first fragment arrives and forward the >>>>> subsequent fragments accordingly. Note that this also saves header >>>>> overhead because the mesh header doesn't have to be included in >>>>> every >>>>> fragment. When forwarding between different links, reassembly has > to >>>>> happen anyway. >>>>> >>>>> The second issue is whether or not we constrain forwarding > fragments >>>>> of a given datagram to a single path. This is where mesh-under and >>>>> route-over diverge. But to me, there are a lot of advantages to >>>>> constraining delivery of a datagram to a single path. Hop-by-hop >>>>> recovery can ensure in-order delivery. Hop-by-hop congestion > control >>>>> becomes much more meaningful. It's unclear to me what end-to-end >>>>> congestion notification means in a mesh-under setting. We can also >>>>> take advantage of link optimizations to increase throughput and >>>>> decrease latency. And, as mentioned before, reduces header >>>>> overhead by >>>>> not needing addressing information in subsequent fragments. >>>>> >>>>> The third issue is whether or not end-to-end mechanisms should be >>>>> used >>>>> for recovery and congestion control. I think we agree that hop-by- >>>>> hop >>>>> mechanisms are required regardless. They increase reliability and >>>>> can >>>>> provide effective congestion control and mitigation. To me, hop- >>>>> by- >>>>> hop >>>>> mechanisms are generally much more effective than end-to-end ones >>>>> because they react to local conditions and can quickly provide > back- >>>>> pressure all the way to the source. From a reliability standpoint, >>>>> we've seen solutions deliver >99.9% without end-to-end recovery. >>>>> So >>>>> one question is how much more reliability do we really need? and >>>>> does >>>>> it justify the added energy overhead and code size? >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> >>>>> >>>>> On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Hi Phil: >>>>>> >>>>>> We do agree on the problem. >>>>>> >>>>>> Per-hop reassembly, though, comes at the expense of that traffic >>>>>> fluidity that was so desirable to the ATM designers. In other >>>>>> words, >>>>>> because per-hop reassembly forces each intermediate node to store >>>>>> and >>>>>> forward a full packet, it is augmenting the latency of the flow > and >>>>>> the >>>>>> memory requirements on the forwarding nodes on the way. >>>>>> >>>>>> This is why I had in mind to couple a few per-hop recovery with a >>>> more >>>>>> solid end-to-end recovery and flow control mechanism between the >>>>>> LoWPAN >>>>>> endpoints. >>>>>> >>>>>> Now I wonder what this discussion becomes in route over v.s. mesh >>>>>> under. >>>>>> In route over, it seems that the forwarding node terminates a >>>>>> link >>>>>> so it >>>>>> has to reassemble before it forwards on a different link that > might >>>> or >>>>>> might not be a LoWPAN; so maybe we end up doing the same thing in >>>> that >>>>>> case. >>>>>> >>>>>> Jonathan, what do you think? >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Philip Levis [mailto:pal@cs.stanford.edu] >>>>>>> Sent: vendredi 23 mai 2008 19:46 >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >>>>>> 6lowpan@ietf.org >>>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>>> >>>>>>> >>>>>>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>>> Hi JP: >>>>>>>> >>>>>>>> I see your concern. >>>>>>>> >>>>>>>> I'd argue that ECN is now pretty well defined now in RFC 3168, >>>>>>>> and >>>>>>>> that >>>>>>>> the basic operation is pretty simple: emulate a packet loss in >>>>>>>> RED >>>>>> but >>>>>>>> save the packet. So the real problem is not ECN itself but what >>>>>>>> RED >>>>>>>> becomes in a LowPAN forwarding node. And that is something that >>>>>>>> the >>>>>>>> node >>>>>>>> will have to define whether it does ECN or RED. >>>>>>>> >>>>>>>> If we do not have ECN then the LowPAN forwarding nodes will >>>>>>>> have to >>>>>>>> destroy frames which might be fragments. Considering the cost >>>>>>>> of >>>>>>>> energy >>>>>>>> and bandwidth to getting the frame up to that forwarding node, >>>>>>>> the >>>>>>>> latency introduced by transport layer time out, and the risk of >>>>>>>> congestion collapse introduced by resending the whole segment, >>>>>>>> I'd >>>>>>>> suggest that ECN is actually a good idea. >>>>>>> >>>>>>> This gets back to the point I brought up December 14, 2006. In >>>>>>> lossy >>>>>>> networks, end-to-end fragmentation and assembly is a real > problem. >>>> It >>>>>>> makes much more sense to do per-hop fragmentation and assembly. > In >>>>>>> the >>>>>>> former, the number of retransmitted fragments is exponential in >>>>>>> the >>>>>>> number of hops; in the latter, it is linear. >>>>>>> >>>>>>> Phil >>>> >>> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 30 12:18:21 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083343A6891; Fri, 30 May 2008 12:18:21 -0700 (PDT) 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 E61E63A687B for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 12:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJRjGW-DkVmJ for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 12:18:18 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 97DF73A6891 for <6lowpan@ietf.org>; Fri, 30 May 2008 12:18:18 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m4UJIBPP020836; Fri, 30 May 2008 13:18:11 -0600 (MDT) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> Date: Fri, 30 May 2008 13:18:06 -0600 Message-Id: <1212175086.9165.6.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org I basically agree with Pascal. I think that we have a good start on items 1, 3 and 5. As for security we have a commitment from Shouichi and Robert to take the draft from Daniel and complete it. I think that we should move forward with HC1g as part of the 4944 improvement and maintenance. geoff On Fri, 2008-05-30 at 14:48 +0200, Pascal Thubert (pthubert) wrote: > Hi JP > > Works with me. I went through the published work and the recent thread " > New charter for 6lowpan". > My conclusion is as follows: > > >From the reworked charter, we should keep Work Items 1, 3, and 5 which > appear of foremost importance, drop 2 and 4 because pragmatically we are > not advanced enough in these areas. > > For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple with > draft-thubert-6lowpan-backbone-router and we have most of the content we > need to make a standard track doc. > > For 3) we have draft-culler-6lowpan-architecture. It needs improvement > in particular in explaining route over vs. mesh under in details as we > currently discuss in the ML. Also mobility, backbone... but we have > people interested in the discussion (see current threads) so we should > work it out. > > For 5) we have draft-daniel-6lowpan-security-analysis. We need to make > sure we have people committed to the effort but the current draft looks > good already. > > To those 3, I'd add: > > Explore requirements and usages. > --------------------------------- > We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. I'd > add to it some words on existing standards that need or use 6LowPAN. In > particular, we need to place ISA100 requirements in there to be able to > better serve them later. > > RFC 4944 maintenance and improvements > ------------------------------------- > This should cover at least 6lowpan HC and fragment recovery efforts. We > can discuss if we want ECN in that work item as well. > > What do you think? > > Pascal > ________________________________________ > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jean Philippe Vasseur (jvasseur) > Sent: vendredi 30 mai 2008 04:25 > To: 6lowpan@ietf.org > Subject: [6lowpan] A suggestion ... With regards to re-chartering > > Hi, > > Just a suggestion for the chairs and the WG. > > We have discussed many important items for 6lowpan. > > For several of them, all important, I think that there was a clear > agreement: stateful header compression, security, Architecture ID, > fragmentation, ..... For other ones such as the "Mesh-under" and "Route > over" discussion, there are diverging point of views. > > So why not trying to quickly re-charter adding the items for which there > is a consensus and continue the discussion on the open issues in the > meantime until we have an agreement at which point the WG may re-charter > ? > > As we all know, the WG has been fairly slow in term of progress and it > is I think now urgent to move on. > > Thoughts ? > > Thanks. > > JP. > _______________________________________________ > 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 6lowpan-bounces@ietf.org Fri May 30 12:32:45 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89E693A68EB; Fri, 30 May 2008 12:32:45 -0700 (PDT) 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 377673A68EB for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 12:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOoBKtdXXrJ0 for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 12:32:39 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 0B6833A67A4 for <6lowpan@ietf.org>; Fri, 30 May 2008 12:32:38 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m4UJWWRg020927; Fri, 30 May 2008 13:32:32 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Fri, 30 May 2008 13:32:27 -0600 Message-Id: <1212175947.9165.10.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Q291bGQgaXRlbSAzIC0gdGhlIGFyY2hpdGVjdHVyZSB3b3JrIGl0ZW0gaW5jbHVkZSB0aGUgcmVx dWlyZW1lbnRzIGZvcgptZXNoIHVuZGVyIGFzIG1lbnRpb25lZCBieSBKb25hdGhhbiBhbmQgc2hv dWxkIHRoYXQgYmUgYSBzaW5nbGUKZG9jdW1lbnQ/Cgo+RnJvbSBQYXNjYWwgSSBpbmZlcnJlZCB0 aGF0IHdlIHdvdWxkIHBvc3Rwb25lIGl0ZW0gMiBhbmQgdGhlIEhDMWcgd291bGQKZmFsbCB1bmRl ciB1cGRhdGVzIHRvIDQ5NDQuCgoJZ2VvZmYKCk9uIEZyaSwgMjAwOC0wNS0zMCBhdCAwNDoyNSAr MDIwMCwgSlAgVmFzc2V1ciB3cm90ZToKPiBIaSwKPiAKPiBKdXN0IGEgc3VnZ2VzdGlvbiBmb3Ig dGhlIGNoYWlycyBhbmQgdGhlIFdHLiAKPiAKPiBXZSBoYXZlIGRpc2N1c3NlZCBtYW55IGltcG9y dGFudCBpdGVtcyBmb3IgNmxvd3Bhbi4gCj4gCj4gRm9yIHNldmVyYWwgb2YgdGhlbSwgYWxsIGlt cG9ydGFudCwgSSB0aGluayB0aGF0IHRoZXJlIHdhcyBhIGNsZWFyCj4gYWdyZWVtZW50OiBzdGF0 ZWZ1bGwgaGVhZGVyIGNvbXByZXNzaW9uLCBzZWN1cml0eSwgQXJjaGl0ZWN0dXJlIElELAo+IGZy YWdtZW50YXRpb24sIC4uLi4uIEZvciBvdGhlciBvbmVzIHN1Y2ggYXMgdGhlIOKAnE1lc2gtdW5k ZXLigJ0gYW5kCj4g4oCcUm91dGUgb3ZlcuKAnSBkaXNjdXNzaW9uLCB0aGVyZSBhcmUgZGl2ZXJn aW5nIHBvaW50IG9mIHZpZXdzLgo+IAo+IFNvIHdoeSBub3QgdHJ5aW5nIHRvIHF1aWNrbHkgcmUt Y2hhcnRlciBhZGRpbmcgdGhlIGl0ZW1zIGZvciB3aGljaAo+IHRoZXJlIGlzIGEgY29uc2Vuc3Vz IGFuZCBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgb3BlbiBpc3N1ZXMgaW4KPiB0aGUg bWVhbnRpbWUgdW50aWwgd2UgaGF2ZSBhbiBhZ3JlZW1lbnQgYXQgd2hpY2ggcG9pbnQgdGhlIFdH IG1heQo+IHJlLWNoYXJ0ZXIgPwo+IAo+IEFzIHdlIGFsbCBrbm93LCB0aGUgV0cgaGFzIGJlZW4g ZmFpcmx5IHNsb3cgaW4gdGVybSBvZiBwcm9ncmVzcyBhbmQgaXQKPiBpcyBJIHRoaW5rIG5vdyB1 cmdlbnQgdG8gbW92ZSBvbi4KPiAKPiBUaG91Z2h0cyA/Cj4gCj4gVGhhbmtzLgo+IAo+IEpQLiAK PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IDZsb3dw YW4gbWFpbGluZyBsaXN0Cj4gNmxvd3BhbkBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vNmxvd3BhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KNmxvd3BhbiBtYWlsaW5nIGxpc3QKNmxvd3BhbkBpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4K From 6lowpan-bounces@ietf.org Sat May 31 04:36:36 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2833A696B; Sat, 31 May 2008 04:36:36 -0700 (PDT) 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 315393A6C2C for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 04:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 jwMT-e+IxvlV for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 04:36:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6BA3F3A6C45 for <6lowpan@ietf.org>; Sat, 31 May 2008 04:35:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204520400"; d="scan'208";a="9735512" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2008 07:35:04 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4VBZ4fp031954; Sat, 31 May 2008 07:35:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4VBZ4Pd016942; Sat, 31 May 2008 11:35:04 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 07:35:04 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 11:35:03 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 13:35:02 +0200 From: JP Vasseur To: Geoff Mulligan , Jonathan Hui Message-ID: Thread-Topic: [6lowpan] A suggestion ... With regards to re-chartering Thread-Index: AcjDEl0rlxYMqZ+Fq02DpESSqAt4bQ== In-Reply-To: <1212163859.8681.53.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 11:35:04.0334 (UTC) FILETIME=[5E8F5AE0:01C8C312] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4827; t=1212233704; x=1213097704; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20A=20suggestion=20...=20With =20regards=20to=20re-chartering |Sender:=20 |To:=20Geoff=20Mulligan=20,=20Jonathan= 20Hui=20; bh=w6YeasKDhuRiF4Hy1xndCEX3smFOBM5AMly3n3Jj73A=; b=JqOwFvfVjvWp4wSWNDVnBPPDbA3dnJ+agFxzzmU+RDlrNYCpBnT0U1xL2V 2wSQiOOYcWm7lzjEd8h87oJHtRrTV2fRKR8QlNzaO41ZB20AJuAJch4CiCQz VxHfEcMzC3; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi, On 5/30/08 6:10 PM, "Geoff Mulligan" wrote: > Jonathan, > We have the ID for routing requirements. Could this, or a portion of > it, be the starting point for the L2 meshing (mehs under) requirements > document. > > I've been thinking about the Routing Requirements doc. Should 6lowpan > generate a ID that is a WG doc for use by ROLL as requirements for Route > Over or should we (members of 6lowpan) just make sure that the current > drafts within roll address our needs and concerns and the the Routing > Requirements draft should instead be focused on mesh under. I would without hesitation vote for the later and concentrate here on all pretty urgent items. Thanks. JP. > > geoff > > On Fri, 2008-05-30 at 08:14 -0700, Jonathan Hui wrote: >> Hi Everyone, >> >> In support of most of this. For ND, we should add work on route-over >> as well, which I've committed to at the last WG meeting. Architecture >> is needed at this stage, and I'm willing to help drive it. RFC 4944 >> maintenance is needed as well. >> >> I still think we need some document to define requirements for a L2 >> meshing over 802.15.4 subnetwork. As I've said before, this could be a >> separate document or a part of the architecture document. >> >> I hope we can close on this quickly... >> >> -- >> Jonathan Hui >> >> On May 30, 2008, at 5:48 AM, Pascal Thubert (pthubert) wrote: >> >>> Hi JP >>> >>> Works with me. I went through the published work and the recent >>> thread " >>> New charter for 6lowpan". >>> My conclusion is as follows: >>> >>> From the reworked charter, we should keep Work Items 1, 3, and 5 which >>> appear of foremost importance, drop 2 and 4 because pragmatically we >>> are >>> not advanced enough in these areas. >>> >>> For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple >>> with >>> draft-thubert-6lowpan-backbone-router and we have most of the >>> content we >>> need to make a standard track doc. >>> >>> For 3) we have draft-culler-6lowpan-architecture. It needs improvement >>> in particular in explaining route over vs. mesh under in details as we >>> currently discuss in the ML. Also mobility, backbone... but we have >>> people interested in the discussion (see current threads) so we should >>> work it out. >>> >>> For 5) we have draft-daniel-6lowpan-security-analysis. We need to make >>> sure we have people committed to the effort but the current draft >>> looks >>> good already. >>> >>> To those 3, I'd add: >>> >>> Explore requirements and usages. >>> --------------------------------- >>> We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. >>> I'd >>> add to it some words on existing standards that need or use 6LowPAN. >>> In >>> particular, we need to place ISA100 requirements in there to be able >>> to >>> better serve them later. >>> >>> RFC 4944 maintenance and improvements >>> ------------------------------------- >>> This should cover at least 6lowpan HC and fragment recovery efforts. >>> We >>> can discuss if we want ECN in that work item as well. >>> >>> What do you think? >>> >>> Pascal >>> ________________________________________ >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Jean Philippe Vasseur (jvasseur) >>> Sent: vendredi 30 mai 2008 04:25 >>> To: 6lowpan@ietf.org >>> Subject: [6lowpan] A suggestion ... With regards to re-chartering >>> >>> Hi, >>> >>> Just a suggestion for the chairs and the WG. >>> >>> We have discussed many important items for 6lowpan. >>> >>> For several of them, all important, I think that there was a clear >>> agreement: stateful header compression, security, Architecture ID, >>> fragmentation, ..... For other ones such as the "Mesh-under" and >>> "Route >>> over" discussion, there are diverging point of views. >>> >>> So why not trying to quickly re-charter adding the items for which >>> there >>> is a consensus and continue the discussion on the open issues in the >>> meantime until we have an agreement at which point the WG may re- >>> charter >>> ? >>> >>> As we all know, the WG has been fairly slow in term of progress and it >>> is I think now urgent to move on. >>> >>> Thoughts ? >>> >>> Thanks. >>> >>> JP. >>> _______________________________________________ >>> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat May 31 04:52:30 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D7B3A6C62; Sat, 31 May 2008 04:52:29 -0700 (PDT) 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 723A03A6C61 for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 04:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 9rsvLgpoiTly for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 04:52:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A99013A6C69 for <6lowpan@ietf.org>; Sat, 31 May 2008 04:52:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204531200"; d="scan'208";a="106486329" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 May 2008 04:52:16 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4VBqGZJ021210 for <6lowpan@ietf.org>; Sat, 31 May 2008 04:52:16 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4VBqGl2014407 for <6lowpan@ietf.org>; Sat, 31 May 2008 11:52:16 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 07:52:15 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 11:52:15 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 13:52:13 +0200 From: JP Vasseur To: "Pascal Thubert (pthubert)" , <6lowpan@ietf.org> Message-ID: Thread-Topic: [6lowpan] A suggestion ... With regards to re-chartering Thread-Index: AcjB/FygQ04APyTUxUeT7O8OowwGYwAVJgcQADDzvZ8= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 11:52:15.0740 (UTC) FILETIME=[C5536BC0:01C8C314] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3540; t=1212234736; x=1213098736; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20A=20suggestion=20...=20With =20regards=20to=20re-chartering |Sender:=20; bh=aI4aRMa6jkKXupftj4yITnHsz6MHNS15gMtC3eHDNf0=; b=STP/i0DR/Vt0oeCy94AZyvFWGKLVFQAsd6MPifjWaw+SJ2rvT1DtSy41B8 QYaxxukok5oSjn+xn6YA6ZiDMJNhtFM3miGhclMxspx84R+voMgaynSaFODT sG3HxXxDIO; Authentication-Results: sj-dkim-3; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, We're in sync - addition comment in line. On 5/30/08 2:48 PM, "Pascal Thubert (pthubert)" wrote: > Hi JP > > Works with me. I went through the published work and the recent thread " > New charter for 6lowpan". > My conclusion is as follows: > > From the reworked charter, we should keep Work Items 1, 3, and 5 which > appear of foremost importance, drop 2 and 4 because pragmatically we are > not advanced enough in these areas. > > For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple with > draft-thubert-6lowpan-backbone-router and we have most of the content we > need to make a standard track doc. Yes. > > For 3) we have draft-culler-6lowpan-architecture. It needs improvement > in particular in explaining route over vs. mesh under in details as we > currently discuss in the ML. For the time being, let's try to re-charter and get it as a WG item. Stating whether we need text on mesh-under versus router over for 6lowpan in the architecture document is I think premature. IMO we first need to draw a consensus on this topic in the WG and decide what to do from there (why not documenting the decision in an informational ID (Chairs' call). Also mobility, backbone... but we have > people interested in the discussion (see current threads) so we should > work it out. Yes. + other items. The ID needs lots of work for sure. This was a very first cut. > > For 5) we have draft-daniel-6lowpan-security-analysis. We need to make > sure we have people committed to the effort but the current draft looks > good already. Yes. > > To those 3, I'd add: > > Explore requirements and usages. > --------------------------------- > We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. I'd > add to it some words on existing standards that need or use 6LowPAN. In > particular, we need to place ISA100 requirements in there to be able to > better serve them later. Excellent idea, although I guess that you did not mean "requirement" but applicability statement. > > RFC 4944 maintenance and improvements > ------------------------------------- > This should cover at least 6lowpan HC and fragment recovery efforts. Probably tow different WG items but yes, agree! We > can discuss if we want ECN in that work item as well. > > What do you think? Looks good to me. Thanks. JP. > > Pascal > ________________________________________ > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Jean Philippe Vasseur (jvasseur) > Sent: vendredi 30 mai 2008 04:25 > To: 6lowpan@ietf.org > Subject: [6lowpan] A suggestion ... With regards to re-chartering > > Hi, > > Just a suggestion for the chairs and the WG. > > We have discussed many important items for 6lowpan. > > For several of them, all important, I think that there was a clear > agreement: stateful header compression, security, Architecture ID, > fragmentation, ..... For other ones such as the "Mesh-under" and "Route > over" discussion, there are diverging point of views. > > So why not trying to quickly re-charter adding the items for which there > is a consensus and continue the discussion on the open issues in the > meantime until we have an agreement at which point the WG may re-charter > ? > > As we all know, the WG has been fairly slow in term of progress and it > is I think now urgent to move on. > > Thoughts ? > > Thanks. > > JP. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat May 31 04:57:11 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D1F3A6AB9; Sat, 31 May 2008 04:57:11 -0700 (PDT) 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 EC5163A6C33 for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 04:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 whq9FuOlzPw4 for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 04:57:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C0CA23A6AB9 for <6lowpan@ietf.org>; Sat, 31 May 2008 04:57:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204520400"; d="scan'208";a="9735934" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2008 07:57:08 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4VBv84g002988; Sat, 31 May 2008 07:57:08 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4VBv8jh021350; Sat, 31 May 2008 11:57:08 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 07:57:08 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 11:57:07 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 13:57:03 +0200 From: JP Vasseur To: Jonathan Hui , "Pascal Thubert (pthubert)" Message-ID: Thread-Topic: [6lowpan] A suggestion ... With regards to re-chartering Thread-Index: AcjDFXCL1Rydb7LC2Em7k9x9XiQiNA== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 11:57:08.0256 (UTC) FILETIME=[73ADD200:01C8C315] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3975; t=1212235028; x=1213099028; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20A=20suggestion=20...=20With =20regards=20to=20re-chartering |Sender:=20 |To:=20Jonathan=20Hui=20,=0A=20=20=20=20 =20=20=20=20=22Pascal=20Thubert=20=20=20(pthubert)=22=20; bh=IVpczAPaa4fttFQdxU9sISD7WtXY455G9gf2nwidcjA=; b=O0hRn/uGAy1hO5BlbIVjypjY9lKMoLpqZlOl4C4s83ti+Io7qyThMBAT+N ml+sj8jpQAaAiXypA+M5JczJMhpfRIsjq34+g67wo2DM1/sEkg5mMc46Ss6J RZFLibusaf; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Jonathan, On 5/30/08 5:14 PM, "Jonathan Hui" wrote: > > Hi Everyone, > > In support of most of this. For ND, we should add work on route-over > as well, which I've committed to at the last WG meeting. Yes we captured the notes :-) Architecture > is needed at this stage, and I'm willing to help drive it. We do need a deep pass at the architecture doc. Let's work together off-line on this. RFC 4944 > maintenance is needed as well. > > I still think we need some document to define requirements for a L2 > meshing over 802.15.4 subnetwork. As I've said before, this could be a > separate document or a part of the architecture document. At the very least I'd say a separate document once we'll have an agreement on whether we need L2 meshing work here. Cheers. JP. > > I hope we can close on this quickly... > > -- > Jonathan Hui > > On May 30, 2008, at 5:48 AM, Pascal Thubert (pthubert) wrote: > >> Hi JP >> >> Works with me. I went through the published work and the recent >> thread " >> New charter for 6lowpan". >> My conclusion is as follows: >> >> From the reworked charter, we should keep Work Items 1, 3, and 5 which >> appear of foremost importance, drop 2 and 4 because pragmatically we >> are >> not advanced enough in these areas. >> >> For 1) we have draft-chakrabarti-6lowpan-ipv6-nd that we can couple >> with >> draft-thubert-6lowpan-backbone-router and we have most of the >> content we >> need to make a standard track doc. >> >> For 3) we have draft-culler-6lowpan-architecture. It needs improvement >> in particular in explaining route over vs. mesh under in details as we >> currently discuss in the ML. Also mobility, backbone... but we have >> people interested in the discussion (see current threads) so we should >> work it out. >> >> For 5) we have draft-daniel-6lowpan-security-analysis. We need to make >> sure we have people committed to the effort but the current draft >> looks >> good already. >> >> To those 3, I'd add: >> >> Explore requirements and usages. >> --------------------------------- >> We have a draft, draft-ekim-6lowpan-scenarios that we can leverage. >> I'd >> add to it some words on existing standards that need or use 6LowPAN. >> In >> particular, we need to place ISA100 requirements in there to be able >> to >> better serve them later. >> >> RFC 4944 maintenance and improvements >> ------------------------------------- >> This should cover at least 6lowpan HC and fragment recovery efforts. >> We >> can discuss if we want ECN in that work item as well. >> >> What do you think? >> >> Pascal >> ________________________________________ >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Jean Philippe Vasseur (jvasseur) >> Sent: vendredi 30 mai 2008 04:25 >> To: 6lowpan@ietf.org >> Subject: [6lowpan] A suggestion ... With regards to re-chartering >> >> Hi, >> >> Just a suggestion for the chairs and the WG. >> >> We have discussed many important items for 6lowpan. >> >> For several of them, all important, I think that there was a clear >> agreement: stateful header compression, security, Architecture ID, >> fragmentation, ..... For other ones such as the "Mesh-under" and >> "Route >> over" discussion, there are diverging point of views. >> >> So why not trying to quickly re-charter adding the items for which >> there >> is a consensus and continue the discussion on the open issues in the >> meantime until we have an agreement at which point the WG may re- >> charter >> ? >> >> As we all know, the WG has been fairly slow in term of progress and it >> is I think now urgent to move on. >> >> Thoughts ? >> >> Thanks. >> >> JP. >> _______________________________________________ >> 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 6lowpan-bounces@ietf.org Sat May 31 05:50:59 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 348393A69D6; Sat, 31 May 2008 05:50:59 -0700 (PDT) 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 515123A6805; Sat, 31 May 2008 05:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.888 X-Spam-Level: X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 TADg+fyaFZPn; Sat, 31 May 2008 05:50:54 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2AE7A3A6932; Sat, 31 May 2008 05:50:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204520400"; d="scan'208,217";a="9737304" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2008 08:50:53 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4VCorMp012945; Sat, 31 May 2008 08:50:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m4VCorQF002055; Sat, 31 May 2008 12:50:53 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 08:50:53 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 12:50:53 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 14:50:51 +0200 From: JP Vasseur To: Miguel Sanchez Message-ID: Thread-Topic: [Roll] [6lowpan] New charter for 6lowpan Thread-Index: AcjDHPSVkcfQpsAQHkujyE93ZsuSyA== In-Reply-To: <86c3ed7b0805301118j18ddc19dy9a111d9073f4ca3b@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 12:50:53.0506 (UTC) FILETIME=[F613EA20:01C8C31C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6420; t=1212238253; x=1213102253; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[Roll]=20[6lowpan]=20New=20charter=20fo r=206lowpan |Sender:=20 |To:=20Miguel=20Sanchez=20; bh=QHUaNAnLnMdQ8GRr7w1yZjRbO6z7+98KY7Rx3SIkgUg=; b=jKsCxD8y7hI7S5M8m2jwbKb1/9L/duwl/xHeZecE724Sw+5r64Mp+TL1bh wqjSn0z0LjK4ve4IabLlnBEQQLJ/QgUd8jvC242xWGPCu5pLfIfG1FohjSgA uuk8lj6VFl; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] New charter for 6lowpan 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: , Content-Type: multipart/mixed; boundary="===============0167873384==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0167873384== Content-type: multipart/alternative; boundary="B_3295090251_6258788" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3295090251_6258788 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Miguel, On 5/30/08 8:18 PM, "Miguel Sanchez" wrote: > Hi JP, >=20 >=20 > On 5/29/08, JP Vasseur wrote: >> Hi Phil and Carles, >> =20 >>=20 >> =20 >> On 5/28/08 1:38 AM, "Philip Levis" wrote: >> =20 >>> > On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote: >>>> >> >>>> >> At least, there are the following items listed in the routing >>>> >> requirements >>>> >> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.= txt) >>>> >> that route-over approach cannot provide or would provide only in a >>>> >> limited >>>> >> way: >>> > >>> > I disagree wholeheartedly. >> =20 >> =20 >> So do I. >> =20 >>=20 >> I think there is a big confusion here >>> > between a protocol specification and a protocol implementation. >>> > >>> > These are all arguments for cross-layer design, that tightly >>> > integrating routing and the link layer will lead to a better solutio= n. >>> > Practice has shown us otherwise; >> =20 >> =20 >> Indeed, "practice" being "The Internet". >> =20 >>=20 >=20 > There are a couple of topics that seem to be cross-layer by nature. One o= f > them seems to be power awareness. The other seems to be routing involving > wireless links.=20 >=20 > JP> I=B9m not against cross-layer if we know what we=B9re doing. You=B9re quite > right that some issues benefit from cross-layer (e.g. Deep packet inspect= ion, > even sometime dataware routing, ...). >=20 > That is why I am not so sure that "practice" (done mostly with wired link= s and > without power constraints) is very relevant here. That is why IETF MANET = group > was created; not because current routing on the Internet was wrong but be= cause > a new type of problem was being addressed (mobile ad-hoc networking). >=20 > JP> And this is also why ROLL was created, because we had to work on a > different set of issues, constraints, ... See the BOF slides. >=20 > I do not see how MAC feedback can be bad, as not being a mandatory featur= e > network layer can always just ignore it. However I can see how such a fee= dback > can avoid repeating operations already performed at the link layer (i.e. = link > quality estimation). >=20 > JP> Surely but the original email was going much further in term of layer > violation ... >=20 > Thanks. >=20 > JP. >=20 > Just my two cents, >=20 > Miguel S=E1nchez >=20 >=20 --B_3295090251_6258788 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Roll] [6lowpan] New charter for 6lowpan Hi Miguel,


On 5/30/08 8:18 PM, "Miguel Sanchez" <misan@disca.upv.es> wrote:

<= SPAN STYLE=3D'font-size:13pt'>Hi JP,


On 5/29/08, JP Vasseur <jvasseur@cis= co.com> wrote:
<= SPAN STYLE=3D'font-size:13pt'>Hi Phil and Carles,
 

 
 On 5/28/08 1:38 AM, "Philip Levis" <pal@cs.stanford.edu> wrote:
 
 > On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote:
 >>
 >> At least, there are the following items listed in the routin= g
 >> requirements
 >> draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-= 05.txt)
 >> that route-over approach cannot provide or would provide onl= y in a
 >> limited
 >> way:
 >
 > I disagree wholeheartedly.
 
 
So do I.
 

 I think there is a big confusion here
 > between a protocol specification and a protocol implementation.<= BR>  >
 > These are all arguments for cross-layer design, that tightly
 > integrating routing and the link layer will lead to a better sol= ution.
 > Practice has shown us otherwise;
 
 
Indeed, "practice" being "The Internet".
 

=
There are a couple of topics that seem to be cross-layer by nature. One of = them seems to be power awareness. The other seems to be routing involving wi= reless links.

JP> I’m not against cross-layer if we know what we’= ;re doing. You’re quite right that some issues benefit from cross-= layer (e.g. Deep packet inspection, even sometime dataware routing, ...).
That is why I am not so sure that "practice" (done mostly with wi= red links and without power constraints) is very relevant here. That is why = IETF MANET group was created; not because current routing on the Internet wa= s wrong but because a new type of problem was being addressed (mobile ad-hoc= networking).

JP> And this is also why ROLL was created, because we had to work on a d= ifferent set of issues, constraints, ... See the BOF slides.

I do not see how MAC feedback can be bad, as not being a mandatory feature = network layer can always just ignore it. However I can see how such a feedba= ck can avoid repeating operations already performed at the link layer (i.e. = link quality estimation).

JP> Surely but the original email was going much further in term of laye= r violation ...

Thanks.

JP.

Just my two cents,

Miguel Sánchez


--B_3295090251_6258788-- --===============0167873384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --===============0167873384==-- From 6lowpan-bounces@ietf.org Sat May 31 06:00:23 2008 Return-Path: <6lowpan-bounces@ietf.org> X-Original-To: 6lowpan-archive@megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5303A6A64; Sat, 31 May 2008 06:00:23 -0700 (PDT) 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 2C2F03A6A64 for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 06:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUf07EpgxFcS for <6lowpan@core3.amsl.com>; Sat, 31 May 2008 06:00:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 034C53A6932 for <6lowpan@ietf.org>; Sat, 31 May 2008 06:00:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,570,1204520400"; d="scan'208";a="9737585" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 31 May 2008 09:00:18 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m4VD0Iet014837; Sat, 31 May 2008 09:00:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m4VD0IhY010927; Sat, 31 May 2008 13:00:18 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 May 2008 09:00:17 -0400 Received: from 10.21.115.225 ([10.21.115.225]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 31 May 2008 13:00:17 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 31 May 2008 15:00:16 +0200 From: JP Vasseur To: Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] A suggestion ... With regards to re-chartering Thread-Index: AcjDHkVZBEziCzA2/kW44E37b0nFhQ== In-Reply-To: <1212175947.9165.10.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 31 May 2008 13:00:17.0983 (UTC) FILETIME=[468844F0:01C8C31E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1622; t=1212238818; x=1213102818; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20A=20suggestion=20...=20With =20regards=20to=20re-chartering |Sender:=20 |To:=20Geoff=20Mulligan=20; bh=8jBTDSf/B4qxPQRyOXjDCF0+DlMTdXgyQbK5E6pjx08=; b=CCb2pow3pNb8lOrg6jsU3iNbcAeCFd/i7BThX6YRlYzAWMoKq6bTU0xSk2 GTycx6BGl+QlzFr+1CVjRT1FFaQNKMJrE0TIDqzaIjOOSm14T5uX2Cz+LbZJ etJZ38+VUf; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] A suggestion ... With regards to re-chartering 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Geoff, On 5/30/08 9:32 PM, "Geoff Mulligan" wrote: > Could item 3 - the architecture work item include the requirements for > mesh under as mentioned by Jonathan and should that be a single > document? > = If OK with you, I would prefer to keep the mesh-under routing requirements separate from the architecture ID. Once we WG will have converged on this topic, this could be added. Thanks. JP. >> From Pascal I inferred that we would postpone item 2 and the HC1g would > fall under updates to 4944. > = > geoff > = > On Fri, 2008-05-30 at 04:25 +0200, JP Vasseur wrote: >> Hi, >> = >> Just a suggestion for the chairs and the WG. >> = >> We have discussed many important items for 6lowpan. >> = >> For several of them, all important, I think that there was a clear >> agreement: statefull header compression, security, Architecture ID, >> fragmentation, ..... For other ones such as the =B3Mesh-under=B2 and >> =B3Route over=B2 discussion, there are diverging point of views. >> = >> So why not trying to quickly re-charter adding the items for which >> there is a consensus and continue the discussion on the open issues in >> the meantime until we have an agreement at which point the WG may >> re-charter ? >> = >> As we all know, the WG has been fairly slow in term of progress and it >> is I think now urgent to move on. >> = >> Thoughts ? >> = >> Thanks. >> = >> JP. = >> _______________________________________________ >> 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