From 6lowpan-bounces@ietf.org Mon Jun 2 03:01: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 44BF03A6BFE; Mon, 2 Jun 2008 03: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 C365A3A688F for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 03:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 uECgLtqq9kD4 for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 03:01: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 6427E28C227 for <6lowpan@ietf.org>; Mon, 2 Jun 2008 03:01:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,577,1204498800"; d="scan'208";a="10484083" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jun 2008 12:01:07 +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 m52A17kO026030; Mon, 2 Jun 2008 12:01:07 +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 m52A17R4010197; Mon, 2 Jun 2008 10:01:07 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, 2 Jun 2008 12:01:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 12:00:34 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0EBC1@xmb-ams-337.emea.cisco.com> In-Reply-To: <584EE39DB5C3154AA3FA43DDA6EC5A0F51ACA1@AZ18EV804.global.ds.honeywell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery Thread-Index: Aci8wxIh2xlcd/nbSZ+skp4lHgyMUgDRAaGAAG/DUPAAs/CzEA== References: <584EE39DB5C3154AA3FA43DDA6EC5A0F51ACA1@AZ18EV804.global.ds.honeywell.com> From: "Pascal Thubert (pthubert)" To: "Brett, Patricia (PA62)" X-OriginalArrivalTime: 02 Jun 2008 10:01:07.0310 (UTC) FILETIME=[937540E0:01C8C497] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4622; t=1212400867; x=1213264867; 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:=20=20New=20Version=20Notification=20for=20=20draf t-thubert-6lowpan-simple-fragment-recovery |Sender:=20; bh=4IGmm95gvDsYTWZ8Esfz15CAKuqmZjEb5S6FUN3DTzU=; b=YzIV+qhlqtsT6xqHV/m5Ma1ZMfNNAJqfr5a4k19cq5UlDnoo2cNfc0oTmX QB3nEJ1ZUnSpa7kP76aVo5XFZW8abOBUbhyXestBFPpOd8bme6sSmxlY+Zf9 MdfEdXBKvE; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] New Version Notification for draft-thubert-6lowpan-simple-fragment-recovery 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 Pat: Copying 6LowPAN >(2) I could not tell if the fragment congestion problem for the >consolidated message (all fragments) would be > indicated to the higher layer for some action to be taken (e.g. >to back off) or if this proposal > is to entirely handled fragment congestion within the >fragmenting (network) layer. Thanks a bunch for reviewing the draft. I found typos and republished, in particular to use the proper terms (fragments, packets, segments, frames) at the right place. Please let me know if I still missed any. I think that the process that you are talking about fits in the overall the ECN process that the draft intentionally does not cover ;) . Consider what IP does with ECN and IP fragments: if any fragment has ECN set then the reassembled packet must have ECN set. I expect the same behaviour if we place ECN bites in a 6LoWPAN header. Should any 6LoWPAN fragment experience congestion over the LowPAN, then the recomposed IP packet should have ECN on. So if you have transport level ECN support, then the proper end-to-end mechanism should throttle the source. A B(ackward)ECN mechanism at L2 would work for a source that is within the LowPAN. So it would help when the control is in the device, and fail if the push comes from outside because there is no way to propage BECN over IP. Makes sense? Pascal >-----Original Message----- >From: Brett, Patricia (PA62) [mailto:patricia.brett@honeywell.com] >Sent: jeudi 29 mai 2008 22:18 >To: Pascal Thubert (pthubert) >Subject: RE: [sp100.11a-pdnt] FW: New Version Notification for draft-thubert-6lowpan-simple-fragment- >recovery-01 > >Hi Pascal >Two remarks: > >(1) I agree with statement regarding : > The process must complete within an acceptable time that is within > the boundaries of upper layer retries. > >(2) I could not tell if the fragment congestion problem for the >consolidated message (all fragments) would be > indicated to the higher layer for some action to be taken (e.g. >to back off) or if this proposal > is to entirely handled fragment congestion within the >fragmenting (network) layer. > > I mean I did not find anything that said a certain amount of >fragment congestion (be that 1 fragment > or a percentage of fragments, or what) for the "whole message" >(all fragments) would also be > indicated to higher layer as congestion for the message as a >whole. > You know, so then BECN could be given, and the original sending >application could also backoff. > Do you know what I mean? > >Regards, >Pat > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >Sent: Tuesday, May 27, 2008 10:40 AM >To: Phy/DLL/Network/Transport group >Subject: [sp100.11a-pdnt] FW: New Version Notification for >draft-thubert-6lowpan-simple-fragment-recovery-01 > >Hi: > >FYI I published a new version of the fragment recovery draft. It now >includes ECN echo and more details on flow control. > >For those who believe that this will be needed sonner than later :) > >http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recove r >y > >Pascal >>-----Original Message----- >>From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>Sent: vendredi 23 mai 2008 12:50 >>To: Pascal Thubert (pthubert) >>Subject: New Version Notification for >draft-thubert-6lowpan-simple-fragment-recovery-01 >> >> >>A new version of I-D, >draft-thubert-6lowpan-simple-fragment-recovery-01.txt has been >successfuly >>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. >> >> >> >>The IETF Secretariat. >> > > > >--- >You are currently subscribed to sp100.11a-pdnt as: >patricia.brett@honeywell.com To unsubscribe send a blank email to >leave-sp100.11a-pdnt-130130J@isa-online.org _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 2 03:24:29 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 EFF4D3A6930; Mon, 2 Jun 2008 03:24: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 CC9443A6930 for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 03:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=0.557, 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 13tE4chewd1U for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 03:24: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 49E313A67FE for <6lowpan@ietf.org>; Mon, 2 Jun 2008 03:24:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,577,1204498800"; d="scan'208";a="10487408" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Jun 2008 12:24:26 +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 m52AOQEo001831; Mon, 2 Jun 2008 12:24:26 +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 m52AOQOn020558; Mon, 2 Jun 2008 10:24:26 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, 2 Jun 2008 12:24:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 2 Jun 2008 12:23:52 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C0EC0C@xmb-ams-337.emea.cisco.com> In-Reply-To: <89DFB2C9-0C80-464E-B28B-001AB9C4C361@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: AcjCeJPbxa+Rz9TTSie0GSaNs9e8BwCIFX1w References: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0E89B@xmb-ams-337.emea.cisco.com> <89DFB2C9-0C80-464E-B28B-001AB9C4C361@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 02 Jun 2008 10:24:26.0332 (UTC) FILETIME=[D55711C0:01C8C49A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14575; t=1212402266; x=1213266266; 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=57CRgV1z1XFKGHz1KnV9A3Wjc5Q8v/TrSjFFqEVBPU0=; b=XQUeJ672q4zOXdT0NvpxoVu9imRcd0vZV3sSd/f19IcPgqXw0BgSy/4Y0e tni4UJ559oWtLr2piZDJZQAcKP2zNhz5nFoUJND3VkurFNnrCusW9IF8lS0M pHeguj3iWK; 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: As I expected we are off sync. >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? Do you mean D should reassemble 6LoWPAN packets? D should not see 6LoWPAN. D is an IPv6 node on the internet. >> 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. The receive interface should not have to do a route lookup to decide to terminate L2. That's what I tried to tell you in the beginning of this thread. >> 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. There's nothing in IP routing that constrains all packets to go over a single path. Let's try again. Now we have: A---->B---->C---->Router1---------->D <-----------------> <-----------> LoWPAN (same PAN ID) Internet In my view, if a routing process in router 1 computes a path from A to D and passes the source route info to A, that is still route over. If the source route path is translated into a mesh header, that's just a mapping. So I have nothing against using mesh header for route over. Looks quite natural to me. Now if we have A---->B---->C---->Router1---------->D | ^ | | +---->E---->F---->Router2-----------+ <-----------------> <-----------> LoWPAN (same PAN ID) Internet It is certainly possible for the routing to enable both routes. And if fragments are spread over those routes we have an issue. We need something to force that all fragments go through either one of the routers for recomposition. A mesh header looks like the natural way of doing this. Obvisouly, a routing header could do but RH0 is being deprecated... Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: vendredi 30 mai 2008 19:13 >To: Pascal Thubert (pthubert) >Cc: Jean Philippe Vasseur (jvasseur); Philip Levis; Mark Townsley (townsley); 6lowpan@ietf.org >Subject: Re: Complete reassemble at every hop (was: [6lowpan] New charter for 6lowpan) > > >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 Mon Jun 2 07:18: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 958153A6960; Mon, 2 Jun 2008 07:18: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 8A9973A6A0F for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 11:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRv6BtAUgIeH for <6lowpan@core3.amsl.com>; Fri, 30 May 2008 11:18:14 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.187]) by core3.amsl.com (Postfix) with ESMTP id 5A25D3A67DB for <6lowpan@ietf.org>; Fri, 30 May 2008 11:18:14 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id m64so10947rnd.18 for <6lowpan@ietf.org>; Fri, 30 May 2008 11:18:13 -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:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=6NpiW2mxFBlxLzLq6oOtQz2Ts67KpDy27NVpNYqYcPE=; b=V7ML8fega/YCDtDrZQf8YQeP6SZiLikC56SGKXAplc0mMPnmR6AsmtTKBLAIox5sPJYKbeoClsnZfnMrcq3RigxIeKnfxYGBPqtYBGftPMJ6TSgRjQ1csZxaH2kWhbKVP6k3sfADhCR7h56PcRjAiPlGlK99K986hl1NX8ODU+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QomZWe9GE3PrRGKRC+Ls51qoS9mxE49Vq/qu3/A6ZNRr4bkRT7dlG1sXqRY6x+BZlk80UuJoXFmDZUvBXH0AhSHp7Ie52hVA3Y3oevmmIRZ5pOJ/MbKiG+Oisd+kSyZ4FX02+DV2K7dlHWpYwdVt43Cd+AHbHyqxEauaU06vBiE= Received: by 10.114.13.1 with SMTP id 1mr6609212wam.96.1212171493235; Fri, 30 May 2008 11:18:13 -0700 (PDT) Received: by 10.115.91.7 with HTTP; Fri, 30 May 2008 11:18:13 -0700 (PDT) Message-ID: <86c3ed7b0805301118j18ddc19dy9a111d9073f4ca3b@mail.gmail.com> Date: Fri, 30 May 2008 20:18:13 +0200 From: "Miguel Sanchez" To: "JP Vasseur" In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: f99ece1b01a23488 X-Mailman-Approved-At: Mon, 02 Jun 2008 07:18:39 -0700 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="===============1896692861==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1896692861== Content-Type: multipart/alternative; boundary="----=_Part_11171_8377706.1212171493192" ------=_Part_11171_8377706.1212171493192 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi JP, On 5/29/08, JP Vasseur wrote: > > 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". > > > 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 wireless links. That is why I am not so sure that "practice" (done mostly with wired links and without power constraints) is very relevant here. That is why IETF MANE= T group was created; not because current routing on the Internet was wrong bu= t because a new type of problem was being addressed (mobile ad-hoc networking). 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 feedback can avoid repeating operations already performed at the link layer (i.e. link quality estimation). Just my two cents, Miguel S=E1nchez ------=_Part_11171_8377706.1212171493192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi JP,


On 5/29/08, JP Vasseur <= jvasseur@cisco.com> wrote:
Hi Phil and Carles,



On 5/28/08 1:38 AM, "Philip Levi= s" <pal@cs.stanford.edu&= gt; wrote:

> On May 27, 2008, at 2:29 AM, Carles Gomez Monteneg= ro wrote:
>>
>> At least, there are the following items listed in th= e routing
>> requirements
>> draft (http://tools.ietf.o= rg/id/draft-dokaspar-6lowpan-routreq-05.txt)
>> that route-over approach cannot provide or would provide only in = a
>> limited
>> way:
>
> I disagree whole= heartedly.


So do I.


I think there is a big confus= ion here
> between a protocol specification and a protocol implementation.
&= gt;
> These are all arguments for cross-layer design, that tightly > integrating routing and the link layer will lead to a better soluti= on.
> Practice has shown us otherwise;


Indeed, "practice&= quot; being "The Internet".



Th= ere are a couple of topics that seem to be cross-layer by nature. One of th= em seems to be power awareness. The other seems to be routing involving wir= eless links.

That is why I am not so sure that "practice" (done mostly wit= h wired links and without power constraints) is very relevant here. That is= why IETF MANET group was created; not because current routing on the Inter= net was wrong but because a new type of problem was being addressed (mobile= ad-hoc networking).

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

Just my two cents,

Miguel S=E1nchez

------=_Part_11171_8377706.1212171493192-- --===============1896692861== 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 --===============1896692861==-- From 6lowpan-bounces@ietf.org Mon Jun 2 07:18: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 C22E128C16A; Mon, 2 Jun 2008 07:18: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 B86DB28C0F1 for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 07:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.606 X-Spam-Level: * X-Spam-Status: No, score=1.606 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJlXR73evp6L for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 07:12:56 -0700 (PDT) Received: from hedwig.lancs.ac.uk (hedwig.lancs.ac.uk [148.88.0.65]) by core3.amsl.com (Postfix) with ESMTP id EE77728C0D0 for <6lowpan@ietf.org>; Mon, 2 Jun 2008 07:12:55 -0700 (PDT) Received: from webmail01.lancs.ac.uk ([148.88.1.56]) by hedwig.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1K3AmP-0004tJ-EV for 6lowpan@ietf.org; Mon, 02 Jun 2008 15:12:57 +0100 Received: from localhost ([127.0.0.1] helo=webmail01.lancs.ac.uk) by webmail01.lancs.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1K3Ajh-0003A1-TA for 6lowpan@ietf.org; Mon, 02 Jun 2008 15:10:10 +0100 Received: from 148.88.232.103 by webmail01.lancs.ac.uk with HTTP; Mon, 2 Jun 2008 15:10:09 +0100 (BST) Message-ID: <1063.148.88.232.103.1212415809.squirrel@webmail01.lancs.ac.uk> Date: Mon, 2 Jun 2008 15:10:09 +0100 (BST) From: h.rashwan@lancaster.ac.uk To: 6lowpan@ietf.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 02 Jun 2008 07:18:39 -0700 Subject: [6lowpan] 6lowpan security 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 Sir / Madam My name is Haitham ,I am PhD student at Lancaster university ,work in information security group. I am interesting to do my PhD in 6lowpan security. I would to ask you three questions ? The first one is , have you got any papers describe 6lowpan properly in much details ? the second one is , what is the security issues at present for 6lowpan , so may be i can work in it ? Do you know any good book to buy describe 6lowpan research areas ? Thank you Kind regards Haitham _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 2 09:13: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 BC8763A69A2; Mon, 2 Jun 2008 09:13: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 D40AB3A69A2 for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 09:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA4IWMRw8Y4J for <6lowpan@core3.amsl.com>; Mon, 2 Jun 2008 09:13:47 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 0DF303A69D9 for <6lowpan@ietf.org>; Mon, 2 Jun 2008 09:13:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A14DBA920A; Mon, 2 Jun 2008 09:13:48 -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 QTQ9T65kfLuB; Mon, 2 Jun 2008 09:13:42 -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 0C984A92EF; Mon, 2 Jun 2008 09:13:41 -0700 (PDT) Message-Id: <2D9F7F85-C6D7-43F8-B6C5-50D87175AC88@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C0EC0C@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 2 Jun 2008 09:13:40 -0700 References: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0E89B@xmb-ams-337.emea.cisco.com> <89DFB2C9-0C80-464E-B28B-001AB9C4C361@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0EC0C@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 Jun 2, 2008, at 3:23 AM, Pascal Thubert (pthubert) wrote: >> 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? > > Do you mean D should reassemble 6LoWPAN packets? > D should not see 6LoWPAN. D is an IPv6 node on the internet. No, I did not mean that D should reassemble 6LoWPAN packets. I simply stated that if you want to support multi-path forwarding of fragments at L2, then ideally we wouldn't limit delivering fragments into/out of a PAN through a single BbR. Your examples imply that we have to limit the multi-path through a single BbR. Of course, if you're forwarding off the BbR-connected 6LoWPAN network, then you've got to reassemble before doing so. In my example below, BbR4 acts as the fragmentation/ reassembly point for the 6LoWPAN IP Link. But if nodes in PAN 1 want to send large datagrams to PAN 2, they should be allowed to utilize both BbR 1 and BbR 2. 6LoWPAN IP Link | Traditional IP Link | /---------\ | | |- BbR 1 -\ | | PAN 1 | | | | |- BbR 2 --| | \---------/ |-- BbR4 --|-- Other IP Network | | /---------\ | | | Pan 2 |- BbR 3 -/ | \---------/ | >> 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. > > The receive interface should not have to do a route lookup to decide > to > terminate L2. That's what I tried to tell you in the beginning of this > thread. Let me try arguing it a different way. If we don't include a Mesh Addressing header, then we are implicitly requiring fragmentation/ reassembly at every hop along the way. No route lookup required. Whether or not a node actually reassembles a datagram before forwarding it again is an implementation decision. A 6LoWPAN node doing L3 routing can simply update the 802.15.4 and fragmentation header and forward the fragment on to the next hop. The next hop has no way of telling that the datagram wasn't completely reassembled then fragmented before forwarding. >> If you're doing L3 forwarding, fragments are constrained to a single >> path. The BbR is replaced with a traditional IP router. > > There's nothing in IP routing that constrains all packets to go over a > single path. IP routing doesn't constrain all datagrams to go over a single path, but L2 fragmentation with L3 forwarding does. In my diagram above, L3 forwarding implies that each BbR is, in fact, an IP router and that BbR 4 knows nothing about 6LoWPAN adaptation. As a result, you've got to constrain forwarding of all fragments for a datagram through a single BbR. > Let's try again. > > Now we have: > > A---->B---->C---->Router1---------->D > > <-----------------> <-----------> > LoWPAN (same PAN ID) Internet > > In my view, if a routing process in router 1 computes a path from A > to D > and passes the source route info to A, that is still route over. If > the > source route path is translated into a mesh header, that's just a > mapping. So I have nothing against using mesh header for route over. > Looks quite natural to me. Sure, you're following the MPLS approach of L3 routing combined with L2 forwarding. I'm not convinced that an MPLS-like approach for 6LoWPAN is the best one. It means that we have to define forwarding mechanisms along with the appropriate configuration and management mechanisms at L2. Similar functionality may be provided at L3, increasing the node resource requirements. At this stage, I prefer to have forwarding at L3 because it unifies many of the networking mechanisms into a single layer. > Now if we have > > > A---->B---->C---->Router1---------->D > | ^ > | | > +---->E---->F---->Router2-----------+ > > <-----------------> <-----------> > LoWPAN (same PAN ID) Internet > > It is certainly possible for the routing to enable both routes. And if > fragments are spread over those routes we have an issue. We need > something to force that all fragments go through either one of the If you truly want to do multipath forwarding of fragments, then I agree that you have to do it at L2. But if you're going to do that, then I'd much rather not constrain the architecture to limit forwarding through a single BbR. Instead, a "meta"-BbR should be used as the egress router to other connected IP network when reassembly is needed. Whether that's a separate BbR or an elected BbR connected directly to the PAN is an implementation decision. > routers for recomposition. A mesh header looks like the natural way of > doing this. Obvisouly, a routing header could do but RH0 is being > deprecated... Note that RFC 5095 does acknowledge benign uses of RH0 and suggests future Routing Header specifications to serve those purposes. -- Jonathan Hui > > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: vendredi 30 mai 2008 19:13 >> To: Pascal Thubert (pthubert) >> Cc: Jean Philippe Vasseur (jvasseur); Philip Levis; Mark Townsley > (townsley); 6lowpan@ietf.org >> Subject: Re: Complete reassemble at every hop (was: [6lowpan] New > charter for 6lowpan) >> >> >> 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 Tue Jun 3 03:12:07 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 6C5B93A687D; Tue, 3 Jun 2008 03:12:07 -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 88E813A6882 for <6lowpan@core3.amsl.com>; Tue, 3 Jun 2008 03:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 6IsKSn2vshSf for <6lowpan@core3.amsl.com>; Tue, 3 Jun 2008 03:12:03 -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 24D553A687D for <6lowpan@ietf.org>; Tue, 3 Jun 2008 03:12:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,582,1204498800"; d="scan'208";a="10599199" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2008 12:11:58 +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 m53ABwed029702; Tue, 3 Jun 2008 12:11:58 +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 m53ABwrq000939; Tue, 3 Jun 2008 10:11:58 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, 3 Jun 2008 12:11:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Jun 2008 12:11:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05C71FE7@xmb-ams-337.emea.cisco.com> In-Reply-To: <2D9F7F85-C6D7-43F8-B6C5-50D87175AC88@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: AcjEy6oQL657y/2xRP2gkZukj2jDNQAk6KMw References: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0E89B@xmb-ams-337.emea.cisco.com> <89DFB2C9-0C80-464E-B28B-001AB9C4C361@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0EC0C@xmb-ams-337.emea.cisco.com> <2D9F7F85-C6D7-43F8-B6C5-50D87175AC88@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 03 Jun 2008 10:11:58.0727 (UTC) FILETIME=[42255970:01C8C562] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20273; t=1212487918; x=1213351918; 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=20Complete=20reassemble=20at=20every=20ho p=20(was=3A=20[6lowpan]=20New=20charter=20for=206lowpan) |Sender:=20; bh=0TzT8tpkWPyeqNBjU9hmRbrHtZKtcc5nh9G9XFTNIs8=; b=s6Ok8hBq3j5D6DcdTWRvgAM/pwK/HwqNeT7pm/OJN+YQpgCUM/4Mrm+9fU SQFULSLLLKxZ8MpketY15cnKacpuISpMD8wrthAbT9r50ftCo7j4kssgH/I+ VQs5p42zDg; 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] 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 would not send fragments over a backbone for multiple reasons; the backbone must be native IPv6 on whatever medium is being used, so you can connect any node to it and provide end to end IPv6 connectivity with the LoWPAN field device. Anyway, it seems that we agree on what we have to do but I still fail to see which mechanism you have in mind to actually do it and what is in the packet or in the node states to enable that. For instance: - your BbR4. Do you have something in the packet that points to it like my mesh header or routing header so that all packets go towards it? - How does a node on the way decide that it should recompose the packet? I mean, how does BbR 1 know whether it is a BbR1 and not a BbR4? I disagree that this is up to implementation. The whole system must make sense and interoperate and we need an architecture that says who does what based on which info. At the moment, the only things that I figure can work are hop-by-hop fragment recomposition and mesh header to indicate the source and the destination of the fragments. What else? Pascal >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com] >Sent: lundi 2 juin 2008 18:14 >To: Pascal Thubert (pthubert) >Cc: Jean Philippe Vasseur (jvasseur); Philip Levis; Mark Townsley (townsley); 6lowpan@ietf.org >Subject: Re: Complete reassemble at every hop (was: [6lowpan] New charter for 6lowpan) > > >Hi Pascal: > >On Jun 2, 2008, at 3:23 AM, Pascal Thubert (pthubert) wrote: >>> 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? >> >> Do you mean D should reassemble 6LoWPAN packets? >> D should not see 6LoWPAN. D is an IPv6 node on the internet. > >No, I did not mean that D should reassemble 6LoWPAN packets. I simply >stated that if you want to support multi-path forwarding of fragments >at L2, then ideally we wouldn't limit delivering fragments into/out of >a PAN through a single BbR. Your examples imply that we have to limit >the multi-path through a single BbR. Of course, if you're forwarding >off the BbR-connected 6LoWPAN network, then you've got to reassemble >before doing so. In my example below, BbR4 acts as the fragmentation/ >reassembly point for the 6LoWPAN IP Link. But if nodes in PAN 1 want >to send large datagrams to PAN 2, they should be allowed to utilize >both BbR 1 and BbR 2. > > 6LoWPAN IP Link | Traditional IP Link > | > /---------\ | > | |- BbR 1 -\ | > | PAN 1 | | | > | |- BbR 2 --| | > \---------/ |-- BbR4 --|-- Other IP Network > | | > /---------\ | | > | Pan 2 |- BbR 3 -/ | > \---------/ | > >>> 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. >> >> The receive interface should not have to do a route lookup to decide >> to >> terminate L2. That's what I tried to tell you in the beginning of this >> thread. > >Let me try arguing it a different way. If we don't include a Mesh >Addressing header, then we are implicitly requiring fragmentation/ >reassembly at every hop along the way. No route lookup required. >Whether or not a node actually reassembles a datagram before >forwarding it again is an implementation decision. A 6LoWPAN node >doing L3 routing can simply update the 802.15.4 and fragmentation >header and forward the fragment on to the next hop. The next hop has >no way of telling that the datagram wasn't completely reassembled then >fragmented before forwarding. > >>> If you're doing L3 forwarding, fragments are constrained to a single >>> path. The BbR is replaced with a traditional IP router. >> >> There's nothing in IP routing that constrains all packets to go over a >> single path. > >IP routing doesn't constrain all datagrams to go over a single path, >but L2 fragmentation with L3 forwarding does. In my diagram above, L3 >forwarding implies that each BbR is, in fact, an IP router and that >BbR 4 knows nothing about 6LoWPAN adaptation. As a result, you've got >to constrain forwarding of all fragments for a datagram through a >single BbR. > >> Let's try again. >> >> Now we have: >> >> A---->B---->C---->Router1---------->D >> >> <-----------------> <-----------> >> LoWPAN (same PAN ID) Internet >> >> In my view, if a routing process in router 1 computes a path from A >> to D >> and passes the source route info to A, that is still route over. If >> the >> source route path is translated into a mesh header, that's just a >> mapping. So I have nothing against using mesh header for route over. >> Looks quite natural to me. > >Sure, you're following the MPLS approach of L3 routing combined with >L2 forwarding. I'm not convinced that an MPLS-like approach for >6LoWPAN is the best one. It means that we have to define forwarding >mechanisms along with the appropriate configuration and management >mechanisms at L2. Similar functionality may be provided at L3, >increasing the node resource requirements. At this stage, I prefer to >have forwarding at L3 because it unifies many of the networking >mechanisms into a single layer. > >> Now if we have >> >> >> A---->B---->C---->Router1---------->D >> | ^ >> | | >> +---->E---->F---->Router2-----------+ >> >> <-----------------> <-----------> >> LoWPAN (same PAN ID) Internet >> >> It is certainly possible for the routing to enable both routes. And if >> fragments are spread over those routes we have an issue. We need >> something to force that all fragments go through either one of the > >If you truly want to do multipath forwarding of fragments, then I >agree that you have to do it at L2. But if you're going to do that, >then I'd much rather not constrain the architecture to limit >forwarding through a single BbR. Instead, a "meta"-BbR should be used >as the egress router to other connected IP network when reassembly is >needed. Whether that's a separate BbR or an elected BbR connected >directly to the PAN is an implementation decision. > >> routers for recomposition. A mesh header looks like the natural way of >> doing this. Obvisouly, a routing header could do but RH0 is being >> deprecated... > >Note that RFC 5095 does acknowledge benign uses of RH0 and suggests >future Routing Header specifications to serve those purposes. > >-- >Jonathan Hui > >> >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: vendredi 30 mai 2008 19:13 >>> To: Pascal Thubert (pthubert) >>> Cc: Jean Philippe Vasseur (jvasseur); Philip Levis; Mark Townsley >> (townsley); 6lowpan@ietf.org >>> Subject: Re: Complete reassemble at every hop (was: [6lowpan] New >> charter for 6lowpan) >>> >>> >>> 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 Tue Jun 3 07:44:52 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 385F33A6967; Tue, 3 Jun 2008 07:44:52 -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 8D0103A683F for <6lowpan@core3.amsl.com>; Tue, 3 Jun 2008 07:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.236 X-Spam-Level: * X-Spam-Status: No, score=1.236 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, DEAR_SOMETHING=1.605] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lJZ+GhSvUua for <6lowpan@core3.amsl.com>; Tue, 3 Jun 2008 07:39:11 -0700 (PDT) Received: from errol.lancs.ac.uk (errol.lancs.ac.uk [148.88.0.66]) by core3.amsl.com (Postfix) with ESMTP id B51A23A682C for <6lowpan@ietf.org>; Tue, 3 Jun 2008 07:39:11 -0700 (PDT) Received: from webmail02.lancs.ac.uk ([148.88.1.57]) by errol.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1K3XfO-0003hD-GJ for 6lowpan@ietf.org; Tue, 03 Jun 2008 15:39:14 +0100 Received: from localhost ([127.0.0.1] helo=webmail02.lancs.ac.uk) by webmail02.lancs.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1K3XfN-0003Mz-Vx for 6lowpan@ietf.org; Tue, 03 Jun 2008 15:39:14 +0100 Received: from 148.88.232.103 by webmail02.lancs.ac.uk with HTTP; Tue, 3 Jun 2008 15:39:13 +0100 (BST) Message-ID: <4354.148.88.232.103.1212503953.squirrel@webmail02.lancs.ac.uk> Date: Tue, 3 Jun 2008 15:39:13 +0100 (BST) From: h.rashwan@lancaster.ac.uk To: 6lowpan@ietf.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 03 Jun 2008 07:44:50 -0700 Subject: [6lowpan] 6lowpan security 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 Sir / Madam My name is Haitham ,I am PhD student at Lancaster university ,work in information security group. I am interesting to do my PhD in 6lowpan security. I would to ask you three questions ? The first one is , have you got any papers describe 6lowpan properly in much details ? the second one is , what is the security issues at present for 6lowpan , so may be i can work in it ? Do you know any good book to buy describe 6lowpan research areas ? Thank you Kind regards Haitham _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 3 14:26: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 A57ED3A6BED; Tue, 3 Jun 2008 14:26: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 39B0A3A6AF0 for <6lowpan@core3.amsl.com>; Tue, 3 Jun 2008 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZtu+NqoV6aC for <6lowpan@core3.amsl.com>; Tue, 3 Jun 2008 14:26:17 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 55DF93A6B77 for <6lowpan@ietf.org>; Tue, 3 Jun 2008 14:25:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 594C9A92EC; Tue, 3 Jun 2008 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83tT4R9uFDEY; Tue, 3 Jun 2008 14:25:27 -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 B7BCCA91FE; Tue, 3 Jun 2008 14:25:26 -0700 (PDT) Message-Id: <4AB297CE-6A62-46ED-AD32-AF0A4ECE7BE3@archrock.com> From: Jonathan Hui To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05C71FE7@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 3 Jun 2008 14:25:25 -0700 References: <9E43D5E2-B6F0-4228-A0F9-B2206CDAB722@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0E89B@xmb-ams-337.emea.cisco.com> <89DFB2C9-0C80-464E-B28B-001AB9C4C361@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C0EC0C@xmb-ams-337.emea.cisco.com> <2D9F7F85-C6D7-43F8-B6C5-50D87175AC88@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05C71FE7@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 Jun 3, 2008, at 3:11 AM, Pascal Thubert (pthubert) wrote: > I would not send fragments over a backbone for multiple reasons; the > backbone must be native IPv6 on whatever medium is being used, so you > can connect any node to it and provide end to end IPv6 connectivity > with > the LoWPAN field device. So maybe I'm confused about the architecture you had in mind with the backbone-router draft. There is the following statement in the draft: "knowledge of the 64-bit address of another node on the same extended LoWPAN is enough to derive its link-local address and reach it over IP." That seems to imply that the BbR's are responsible for making one or more PANs appear as a single IP link. They are technically doing L2 forwarding because the Hop Limit should not get decremented between the source and destination when communicating over link-local. If that is the case, BbRs aren't simply doing IP routing. However, they do function as IP routers to route datagrams between the Extended LoWPAN network and other IP networks. > Anyway, it seems that we agree on what we have to do but I still > fail to > see which mechanism you have in mind to actually do it and what is in > the packet or in the node states to enable that. > > For instance: > - your BbR4. Do you have something in the packet that points to it > like > my mesh header or routing header so that all packets go towards it? A couple emails ago, I said that the Mesh Addressing header specified in RFC4944 is insufficient for supporting my ideal scenario for L2 forwarding and that I prefer a L2 forwarding header that identifies the ends of an IP hop. To be fair, the Mesh Addressing header was designed for L2 forwarding within a single LoPAN, not an Extended LoWPAN. > - How does a node on the way decide that it should recompose the > packet? > I mean, how does BbR 1 know whether it is a BbR1 and not a BbR4? The BbR that is elected as the IP router does the reassembly. Note that not all BbRs do not have to be full-fledged IP routers if they are simply doing L2 forwarding. > I disagree that this is up to implementation. The whole system must > make > sense and interoperate and we need an architecture that says who does > what based on which info. My comment on implementation details was w.r.t. delivering LoWPAN fragments over a LoWPAN using L3 forwarding. All I said was that complete reassembly at each hop is not strictly required. If done properly, there should be no perceivable difference in the 6LoWPAN packets being transmitted. At the protocol level, we're primarily concerned with what and how bits are passed around, but if different implementations can deliver those bits in the same way, then it is an implementation detail. > At the moment, the only things that I figure can work are hop-by-hop > fragment recomposition and mesh header to indicate the source and the > destination of the fragments. Yes, but I'd argue that a mesh header should indicate the source and destination of an IP hop. If a primary goal of L2 forwarding is to support multi-path delivery of 6LoWPAN fragments, why limit it to a single choke point in the PAN? You don't achieve any of the receiver/ spatial diversity that you were trying to achieve at all of the other hops. And that last hop often tends to be where much of the benefits can be realized. This is a good discussion to have, but I'm not convinced on the benefits of L2 forwarding over L3 forwarding in 6LoWPAN networks. I do agree that enables multi-path forwarding of fragmented IPv6 datagrams. But, as I've mentioned, it's still limited to a single choke point at the BbR. And, do we really know whether fragmented datagrams will be the common case vs. the exception? -- Jonathan Hui > > > What else? > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com] >> Sent: lundi 2 juin 2008 18:14 >> To: Pascal Thubert (pthubert) >> Cc: Jean Philippe Vasseur (jvasseur); Philip Levis; Mark Townsley > (townsley); 6lowpan@ietf.org >> Subject: Re: Complete reassemble at every hop (was: [6lowpan] New > charter for 6lowpan) >> >> >> Hi Pascal: >> >> On Jun 2, 2008, at 3:23 AM, Pascal Thubert (pthubert) wrote: >>>> 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? >>> >>> Do you mean D should reassemble 6LoWPAN packets? >>> D should not see 6LoWPAN. D is an IPv6 node on the internet. >> >> No, I did not mean that D should reassemble 6LoWPAN packets. I simply >> stated that if you want to support multi-path forwarding of fragments >> at L2, then ideally we wouldn't limit delivering fragments into/out >> of >> a PAN through a single BbR. Your examples imply that we have to limit >> the multi-path through a single BbR. Of course, if you're forwarding >> off the BbR-connected 6LoWPAN network, then you've got to reassemble >> before doing so. In my example below, BbR4 acts as the fragmentation/ >> reassembly point for the 6LoWPAN IP Link. But if nodes in PAN 1 want >> to send large datagrams to PAN 2, they should be allowed to utilize >> both BbR 1 and BbR 2. >> >> 6LoWPAN IP Link | Traditional IP Link >> | >> /---------\ | >> | |- BbR 1 -\ | >> | PAN 1 | | | >> | |- BbR 2 --| | >> \---------/ |-- BbR4 --|-- Other IP Network >> | | >> /---------\ | | >> | Pan 2 |- BbR 3 -/ | >> \---------/ | >> >>>> 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. >>> >>> The receive interface should not have to do a route lookup to decide >>> to >>> terminate L2. That's what I tried to tell you in the beginning of > this >>> thread. >> >> Let me try arguing it a different way. If we don't include a Mesh >> Addressing header, then we are implicitly requiring fragmentation/ >> reassembly at every hop along the way. No route lookup required. >> Whether or not a node actually reassembles a datagram before >> forwarding it again is an implementation decision. A 6LoWPAN node >> doing L3 routing can simply update the 802.15.4 and fragmentation >> header and forward the fragment on to the next hop. The next hop has >> no way of telling that the datagram wasn't completely reassembled >> then >> fragmented before forwarding. >> >>>> If you're doing L3 forwarding, fragments are constrained to a >>>> single >>>> path. The BbR is replaced with a traditional IP router. >>> >>> There's nothing in IP routing that constrains all packets to go over > a >>> single path. >> >> IP routing doesn't constrain all datagrams to go over a single path, >> but L2 fragmentation with L3 forwarding does. In my diagram above, L3 >> forwarding implies that each BbR is, in fact, an IP router and that >> BbR 4 knows nothing about 6LoWPAN adaptation. As a result, you've got >> to constrain forwarding of all fragments for a datagram through a >> single BbR. >> >>> Let's try again. >>> >>> Now we have: >>> >>> A---->B---->C---->Router1---------->D >>> >>> <-----------------> <-----------> >>> LoWPAN (same PAN ID) Internet >>> >>> In my view, if a routing process in router 1 computes a path from A >>> to D >>> and passes the source route info to A, that is still route over. If >>> the >>> source route path is translated into a mesh header, that's just a >>> mapping. So I have nothing against using mesh header for route over. >>> Looks quite natural to me. >> >> Sure, you're following the MPLS approach of L3 routing combined with >> L2 forwarding. I'm not convinced that an MPLS-like approach for >> 6LoWPAN is the best one. It means that we have to define forwarding >> mechanisms along with the appropriate configuration and management >> mechanisms at L2. Similar functionality may be provided at L3, >> increasing the node resource requirements. At this stage, I prefer to >> have forwarding at L3 because it unifies many of the networking >> mechanisms into a single layer. >> >>> Now if we have >>> >>> >>> A---->B---->C---->Router1---------->D >>> | ^ >>> | | >>> +---->E---->F---->Router2-----------+ >>> >>> <-----------------> <-----------> >>> LoWPAN (same PAN ID) Internet >>> >>> It is certainly possible for the routing to enable both routes. And > if >>> fragments are spread over those routes we have an issue. We need >>> something to force that all fragments go through either one of the >> >> If you truly want to do multipath forwarding of fragments, then I >> agree that you have to do it at L2. But if you're going to do that, >> then I'd much rather not constrain the architecture to limit >> forwarding through a single BbR. Instead, a "meta"-BbR should be used >> as the egress router to other connected IP network when reassembly is >> needed. Whether that's a separate BbR or an elected BbR connected >> directly to the PAN is an implementation decision. >> >>> routers for recomposition. A mesh header looks like the natural way > of >>> doing this. Obvisouly, a routing header could do but RH0 is being >>> deprecated... >> >> Note that RFC 5095 does acknowledge benign uses of RH0 and suggests >> future Routing Header specifications to serve those purposes. >> >> -- >> Jonathan Hui >> >>> >>> >>> Pascal >>> >>>> -----Original Message----- >>>> From: Jonathan Hui [mailto:jhui@archrock.com] >>>> Sent: vendredi 30 mai 2008 19:13 >>>> To: Pascal Thubert (pthubert) >>>> Cc: Jean Philippe Vasseur (jvasseur); Philip Levis; Mark Townsley >>> (townsley); 6lowpan@ietf.org >>>> Subject: Re: Complete reassemble at every hop (was: [6lowpan] New >>> charter for 6lowpan) >>>> >>>> >>>> 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 Mon Jun 9 08:25: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 5A0253A6BD5; Mon, 9 Jun 2008 08:25: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 E4B5328C165; Mon, 9 Jun 2008 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, 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 7odvYFJ9zInS; Mon, 9 Jun 2008 08:25:40 -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 AE33E3A69AA; Mon, 9 Jun 2008 08:25:39 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 17:25: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 m59FPvhm005930; Mon, 9 Jun 2008 17:25:57 +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 m59FPvKc016379; Mon, 9 Jun 2008 15:25:57 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:25:57 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:25:57 +0200 Message-ID: <484D4B7D.507@cisco.com> Date: Mon, 09 Jun 2008 17:25:49 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan 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> <1211496860.23290.41.camel@dellx1> In-Reply-To: <1211496860.23290.41.camel@dellx1> X-OriginalArrivalTime: 09 Jun 2008 15:25:57.0319 (UTC) FILETIME=[1D4CDD70:01C8CA45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13184; t=1213025157; x=1213889157; c=relaxed/simple; s=amsdkim1002; 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]=20ISA100.11a=20status=20and=2 0requirements=20(was=20RE=3A=09New=09charter=0A=20for=206low pan) |Sender:=20; bh=7dyFetNY1nNiFalgVOBxlt8uZOv4vnXd1flUpsr+oqA=; b=oQA8GdB6Kfslc3qeyKRJtro8Al6ZPsNaClUnafjW8FRjw458APuf89pmEJ NF9iB1atcbGe1p2TrFY31aLPmjKOf0WFR1Xzfu8MMmNWDlyzX6K4zDqSg35T C216mfAmJi; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 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 Geoff Mulligan wrote: > 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'm more optimistic about keeping the UDP checksum optimization. There are other forces at work which may relax the UDP checksum requirement in IPv6 in certain cases. So as long as you have well thought out reasoning, I wouldn't be afraid of keeping it in. - Mark > 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 > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 9 08:33: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 AB84A3A6AC0; Mon, 9 Jun 2008 08:33: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 901AE3A67F3 for <6lowpan@core3.amsl.com>; Mon, 9 Jun 2008 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 MnBqg+iuqf55 for <6lowpan@core3.amsl.com>; Mon, 9 Jun 2008 08:33:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 190443A6A32 for <6lowpan@ietf.org>; Mon, 9 Jun 2008 08:33:47 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 17:34:06 +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 m59FY6mK008444; Mon, 9 Jun 2008 17:34:06 +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 m59FY60p019662; Mon, 9 Jun 2008 15:34:06 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:34:05 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:34:05 +0200 Message-ID: <484D4D66.1060407@cisco.com> Date: Mon, 09 Jun 2008 17:33:58 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Jonathan Hui References: <7892795E1A87F04CADFCCF41FADD00FC05C0E73A@xmb-ams-337.emea.cisco.com> In-Reply-To: X-OriginalArrivalTime: 09 Jun 2008 15:34:05.0670 (UTC) FILETIME=[40615060:01C8CA46] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3946; t=1213025646; x=1213889646; c=relaxed/simple; s=amsdkim1002; 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]=20A=20suggestion=20...=20With =20regards=20to=20re-chartering |Sender:=20; bh=Ie6CoISDQ1xa3N1F2Ugc3Sx5SNh4lsdCzNgaYi6lznY=; b=Fl/2qZaV0CjM2r3xi5mitHoR3bA/n5BS7KgKKdPxm7kJvxuIPzKu+4sIc1 191rbACogFzQ+dKatz7Xwt15i7mL85Mz412e6W2IavUIgUqoVEbLnGs6bjFs 9zKZu+g4LQ; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 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 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. Could you provide some charter text that would help quantify what you are willing to commit to here? > Architecture > is needed at this stage, and I'm willing to help drive it. Please do. - Mark > 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 Mon Jun 9 08:56: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 D8E2F3A6C79; Mon, 9 Jun 2008 08:56: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 2B19B3A6C66; Mon, 9 Jun 2008 08:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, 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 OIvlcz+yHIIg; Mon, 9 Jun 2008 08:56:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F07F03A6C79; Mon, 9 Jun 2008 08:56:42 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 17:57:01 +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 m59Fv0e3020597; Mon, 9 Jun 2008 17:57:00 +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 m59Fv0OM028255; Mon, 9 Jun 2008 15:57:00 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:57:00 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:56:59 +0200 Message-ID: <484D52C5.2060701@cisco.com> Date: Mon, 09 Jun 2008 17:56:53 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan 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> <1211496860.23290.41.camel@dellx1> In-Reply-To: <1211496860.23290.41.camel@dellx1> X-OriginalArrivalTime: 09 Jun 2008 15:56:59.0916 (UTC) FILETIME=[737E9CC0:01C8CA49] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13296; t=1213027020; x=1213891020; c=relaxed/simple; s=amsdkim2001; 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]=20ISA100.11a=20status=20and=2 0requirements=20(was=20RE=3A=09New=09charter=0A=20for=206low pan) |Sender:=20; bh=wMCVDuFNhyOMO6GCdJkse/kENFnTO8Xrp5csSc8Gsos=; b=Xu6KDkkBwzunpaff+vtaVpOLy1W7i1Ilv49rx3oAhYywcgBfFZwQfR6L7A dRSFRUqbltses54MqWTmYe0gz+/J9cu2WgNUcytLHbMZQHXnNQ28aS8vdl0y NUHMlJzjRk; Authentication-Results: ams-dkim-2; header.From=townsley@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: 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 Geoff Mulligan wrote: > 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. It would seem to me that HC1G would be very important to understanding how ROLL is going to work. If you are routing between subnets at L3, then by definition you cannot be using link-local addressing on them. So, either ROLL is stuck with 128-bit addresses in data packets, or we figure out how to compress global addresses. Or, am I missing something obvious? - Mark > 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 > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 9 09:32: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 927E23A6976; Mon, 9 Jun 2008 09:32: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 213743A6950; Mon, 9 Jun 2008 09:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=0.080, 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 Fi-ASnwuCD7R; Mon, 9 Jun 2008 09:28:06 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 6DD643A68D7; Mon, 9 Jun 2008 09:28:06 -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 m59GRcQe024369; Mon, 9 Jun 2008 10:27:38 -0600 (MDT) From: Geoff Mulligan To: Mark Townsley In-Reply-To: <484D4B7D.507@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> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> Date: Mon, 09 Jun 2008 10:27:33 -0600 Message-Id: <1213028853.5997.20.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 X-Mailman-Approved-At: Mon, 09 Jun 2008 09:31:58 -0700 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 Mark, this is interesting news. This can save another byte and if there would be no large push against this then compressing out another byte would be good. This is currently in the HC1g draft and would allow consistency between 6lowpan and SP100. geoff On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: > Geoff Mulligan wrote: > > 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'm more optimistic about keeping the UDP checksum optimization. There > are other forces at work which may relax the UDP checksum requirement in > IPv6 in certain cases. So as long as you have well thought out > reasoning, I wouldn't be afraid of keeping it in. > > - Mark > > 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 > > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 9 09:34: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 8F6273A6B96; Mon, 9 Jun 2008 09:34: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 2671528C173; Mon, 9 Jun 2008 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, 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 w6Nj0AifUT+2; Mon, 9 Jun 2008 09:34: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 394933A695B; Mon, 9 Jun 2008 09:34:31 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 18:34:40 +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 m59GYZA5030566; Mon, 9 Jun 2008 18:34:35 +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 m59GYZjj011056; Mon, 9 Jun 2008 16:34:35 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 18:34:35 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 18:34:34 +0200 Message-ID: <484D5B93.2080802@cisco.com> Date: Mon, 09 Jun 2008 18:34:27 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> <1213028853.5997.20.camel@dellx1> In-Reply-To: <1213028853.5997.20.camel@dellx1> X-OriginalArrivalTime: 09 Jun 2008 16:34:34.0106 (UTC) FILETIME=[B318B5A0:01C8CA4E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15901; t=1213029275; x=1213893275; c=relaxed/simple; s=amsdkim2001; 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]=20ISA100.11a=20status=20and=2 0requirements=20(was=09RE=3A=09New=09charter=0A=20for=206low pan) |Sender:=20; bh=gsmUslBaQayZDIKl9/tBT5j8xdWkOijb1CDoxXjY8RQ=; b=e2O1dio6OYmQ8ppWHt+ppKXrMBSsY+cJQXpA8qOqX3CHehBnjkFFsXTGbQ Wm4iMra7yYKNgAYN147G65xY4ezbvlE6/sRePKpK1EaxtxhFnN7F8c8ojzyz lR+RdknAMA; Authentication-Results: ams-dkim-2; header.From=townsley@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: 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 Geoff Mulligan wrote: > Mark, > this is interesting news. This can save another byte and if there > would be no large push against this then compressing out another byte > would be good. > I can't promise anything, but 6lowpan certainly isn't the only place where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty much any UDP-based tunneling protocol running on a router in hardware at high scale or speeds is running into the same problem. I know of implementations today that zero out the UDP checksum, and IMHO a good implementation that is "liberal in what it accepts" would not drop the packet with a zero UDP checksum arriving over IPv6 (in fact, its annoying that one would even have to differentiate between IPv4 and IPv6 at all here if you ask me). > This is currently in the HC1g draft and would allow consistency between > 6lowpan and SP100. > I suppose that isn't a bad thing. - Mark > geoff > > On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: > >> Geoff Mulligan wrote: >> >>> 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'm more optimistic about keeping the UDP checksum optimization. There >> are other forces at work which may relax the UDP checksum requirement in >> IPv6 in certain cases. So as long as you have well thought out >> reasoning, I wouldn't be afraid of keeping it in. >> >> - Mark >> >>> 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 >>> >>> >>> > > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 9 09:58: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 5E1BB3A6C64; Mon, 9 Jun 2008 09:58: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 C80C83A6C8D; Mon, 9 Jun 2008 09:58:30 -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 wWcdTd9op9Pq; Mon, 9 Jun 2008 09:58:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 960843A6C64; Mon, 9 Jun 2008 09:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m59GwVVV001131; Mon, 9 Jun 2008 18:58:35 +0200 (CEST) Message-Id: <10CC11D0-9363-440E-BFF8-58E26A60CCEB@tzi.org> From: Carsten Bormann To: Mark Townsley In-Reply-To: <484D5B93.2080802@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 18:58:31 +0200 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> <1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , roll@ietf.org, Geoff Mulligan , 6lowpan <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 On Jun 09 2008, at 18:34, Mark Townsley wrote: > zero out the UDP checksum While I agree with the sentiment, it's maybe worthwhile to remember the rationale[/ization] for requiring a checksum: IPv6 does not have a header checksum, and the UDP checksum (which, as does the TCP checksum, covers the IPv6 pseudoheader and thus some of the more important header fields no longer protected by the IPv4 header checksum) is the only checksum that guards against misdelivery of packets. Of course, this architectural concern has to be weighed against other concerns, including implementation issues, as well as the fact that the v4/v6 asymmetry adds one more real-world IPv6 deployment issue. Just one data point here. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 10 00:33: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 D44CF3A68F2; Tue, 10 Jun 2008 00:33: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 25D403A67F3; Tue, 10 Jun 2008 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, 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 meQaPkLyQDY4; Tue, 10 Jun 2008 00:33:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 71AA33A6833; Tue, 10 Jun 2008 00:33:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,616,1204498800"; d="scan'208";a="11230063" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2008 09:34:03 +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 m5A7Y3fr010656; Tue, 10 Jun 2008 09:34:03 +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 m5A7Y3W1003966; Tue, 10 Jun 2008 07:34:03 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, 10 Jun 2008 09:34:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 09:33:19 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> In-Reply-To: <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjKZwgLFVdhUFh3QziyFpw2ZoduoAAZAcbw 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 10 Jun 2008 07:34:03.0125 (UTC) FILETIME=[5B237A50:01C8CACC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24534; t=1213083243; x=1213947243; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=09RE=3A=09New=09charter=20for=206 lowpan) |Sender:=20; bh=wonKVezO3S8d5KU/FPomky9jQQylZtNGYuGGVzEtl6k=; b=SKuKegGoUon0VA4kJLbjBAJQjGSBfjuPJh0bb197QEZWnBitKnFGcgAK/n zfxwgVcmP1cPbvD/vkqZIGl64ir2/RHPth8ciK1JKWmQMaHdg8ZJu6xeM/iJ Q934jpNMK8; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Geoff Mulligan , roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 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 Lloyd: There is some history in the ML about UDP checksum compression and ISA100.11a. On 3/3 I wrote: " Per RFC 4944: "The UDP header's checksum field is not compressed and is therefore carried in full." The UDP checksum is not the only way to protect the IP pseudo header, the UDP header and the payload. ISA 100.11a is defining a transport-level security that does all this and more, since it has a larger signature and provides mutual authentication at the same time. Also, the ISA100.11a transport-level security is usually hardware-assisted, so it requires little power or CPU time on the field device, whereas UDP checksum will be a costly CPU operation. So ISA100.11a is an example where the UDP checksum could and actually should be compressed over the LoWPAN, leaving it up to be reconstructed by a backbone router should the packet go any further than the LOWPAN itself. Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to standardize it to mean that the UDP checksum is compressed, provided that the headers and payload are equally or better protected than if the checksum was used. " Then followed a thread entitled: "[6lowpan] Compressing the UDP checksum" In short, there was a general agreement that this was doable under circumstances; In particular, the current draft under review of ISA100.11a transport section (under review) has the following text: " 1.4.3 Eliding the UDP checksum ISA100.11a uses both HC1 and HC2, and extends the UDP common compressed header encoding to compress the UDP upper layer checksum by relying on the Transport layer security to provide the same service, and more. For that purpose, the Transport layer builds an ISA100.11a pseudo-header by concatenating the UDP pseudo-header for IPv6 as described in the previous section, the source UDP port and the destination UDP port: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upper-Layer Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source UDP port | Destination UDP port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ISA100.11a pseudo-header is filled and placed before the UDP payload for the crypto process. If encryption is performed on the message, the pseudo-header is not encrypted, but the pseudo-header is part of the MIC in any case. Once the crypto process is completed, the pseudo-header is removed from the message, and the IP and UDP headers are put in its place for transmission. On the receiving side, the transport layer will restore the pseudo-header based on the received packet prior to the crypto process to validate that none of the protected fields was tempered with. When HC2 is applied, bit 3 in the UDP common compressed header encoding, which is reserved in RFC 4944, is set to express whether the checksum is elided. When so, the 8 bytes of UDP header can be compressed down to a single byte that contains the partially compressed ports, using 4 bits each. Note 1: When the packet is not protected by the Transport layer security, the UDP checksum can not be compressed and must be carried in full as prescribed by RFC 4944. If Transport Layer Security is active for a given packet, then the UDP checksum might be elided as prescribed above. Note 2: If the UDP upper layer checksum field is elided, it is up to the other endpoint across the DLL subnet to recompute the UDP checksum as part of the 6LoWPAN expansion, if necessary. This is required in particular for a middlebox such as a backbone router that forwards the uncompressed packet as opposed to terminating the transport. Note 3: If the UDP checksum is not elided and security is applied, then the UDP checksum must be computed after the security operation is complete and the security fields are filled. The UDP payload that is used for the UDP checksum includes all data from the UDP header on, including the security fields, application data and MIC fields, whether the application data is encrypted or not. " This proposal provides better guarantees than the UDP checksum alone. Part of it because the security signature is longer and the UDP checksum, and part of it because that security authenticates the data as well. Would you agree that compressing the UDP checksum is valid in this case? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Lloyd Wood >Sent: lundi 9 juin 2008 21:28 >To: Mark Townsley (townsley) >Cc: Geoff Mulligan; roll@ietf.org; Jay Werb; Polyzois,Christos A; Chernoguzov,Alexander (PA35); >6lowpan@ietf.org >Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) > > >On 9 Jun 2008, at 17:34, Mark Townsley wrote: > >> Geoff Mulligan wrote: >>> Mark, >>> this is interesting news. This can save another byte and if there >>> would be no large push against this then compressing out another byte >>> would be good. >>> >> I can't promise anything, but 6lowpan certainly isn't the only place >> where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty >> much any UDP-based tunneling protocol running on a router in >> hardware at >> high scale or speeds is running into the same problem. > >The pseudo-header checksum is the only thing preventing misdelivery; >the header gets checked once at the endpoint (IPv6) as opposed to >being checked and recomputed at every hop (IPv4). > >I'm not convinced that the IPv6 design choices here were right - I'd >have gone for a header checksum across immutable fields, skipping TTL, >CoS and the like, that wouldn't require recomputing, and which would >have constrained misdelivery to a single link, rather than the path - >this would be more useful for resends and diagnostics, while >increasing the pain for NAT. Here, IPv6 assumes a tight application/ >application control loop and path where the cost of resending a packet >across the entire path is low. > >That raw IPv6 header tunnelling sans UDP header (or GRE sans optional >checksum or MPLS) lacks any self-checking mechanism for reliability >should be of some concern. > >RFC2460 p28 section 8.1 Upper-Layer Checksums: > >[..] >o Unlike IPv4, when UDP packets are originated by an IPv6 node, the >UDP checksum is not optional. That is, whenever originating a UDP >packet, an IPv6 node must compute a UDP checksum over the packet and >the pseudo-header, and, if that computation yields a result of zero, >it must be changed to hex FFFF for placement in the UDP header. IPv6 >receivers must discard UDP packets containing a zero checksum, and >should log the error. ^^^^ >[..] > >That 'must' is clear and unambiguous. The side-effects mean that this >should NOT be thought of as an optimization. >L. > >> I know of >> implementations today that zero out the UDP checksum, and IMHO a good >> implementation that is "liberal in what it accepts" would not drop the >> packet with a zero UDP checksum arriving over IPv6 (in fact, its >> annoying that one would even have to differentiate between IPv4 and >> IPv6 >> at all here if you ask me). >>> This is currently in the HC1g draft and would allow consistency >>> between >>> 6lowpan and SP100. >>> >> I suppose that isn't a bad thing. >> >> - Mark >>> geoff >>> >>> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: >>> >>>> Geoff Mulligan wrote: >>>> >>>>> 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'm more optimistic about keeping the UDP checksum optimization. >>>> There >>>> are other forces at work which may relax the UDP checksum >>>> requirement in >>>> IPv6 in certain cases. So as long as you have well thought out >>>> reasoning, I wouldn't be afraid of keeping it in. >>>> >>>> - Mark >>>> >>>>> 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 >>>>> >>>>> >>>>> >>> >>> >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 10 03:45: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 A4C943A679C; Tue, 10 Jun 2008 03:45: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 C26B53A68BD for <6lowpan@core3.amsl.com>; Tue, 10 Jun 2008 03:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f7pBjTMMTV8 for <6lowpan@core3.amsl.com>; Tue, 10 Jun 2008 03:45:31 -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 278323A6765 for <6lowpan@ietf.org>; Tue, 10 Jun 2008 03:45:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,617,1204498800"; d="scan'208";a="11261251" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2008 12:45:51 +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 m5AAjo9R021887 for <6lowpan@ietf.org>; Tue, 10 Jun 2008 12:45: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 m5AAjot7013343 for <6lowpan@ietf.org>; Tue, 10 Jun 2008 10:45:50 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 12:45:50 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 12:45:50 +0200 Message-ID: <484E5B57.8030108@cisco.com> Date: Tue, 10 Jun 2008 12:45:43 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan@ietf.org X-OriginalArrivalTime: 10 Jun 2008 10:45:50.0436 (UTC) FILETIME=[2607CA40:01C8CAE7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=403; t=1213094750; x=1213958750; c=relaxed/simple; s=amsdkim1002; 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=20coming=20soon |Sender:=20; bh=WOtRQDkeXygaXt/oTSwLcYvpuAs7pGOHJPL1SckrM48=; b=se66KONo0L0ToWSkaDIBXDp2CZdh9ZlTsEqOgolu2sY/7vZSbpx1NJfqnt M4M2oBa+WrV9n++5RkJhmY0ar7Ah+Bw12hyVDB0pxmeSmRhKDQ01LxeZnL4/ eh4K5hJtv9; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] New charter coming soon 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 Your chairs and I spent some time on the phone yesterday working in the charter. I am expecting a revision today or tomorrow based on the recent discussions on list (including any replies from you to the comments I sent out yesterday). If we are all happy with that new version, I will start the process with the IESG Thursday. Thanks all, and keep up the good open discussions. - Mark _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 10 04:49:39 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 53E4B3A6AD8; Tue, 10 Jun 2008 04:49:39 -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 15D953A6A56; Tue, 10 Jun 2008 04:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 rKg0Qquxw7nx; Tue, 10 Jun 2008 04:49: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 9E6443A699E; Tue, 10 Jun 2008 04:49:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,617,1204498800"; d="scan'208";a="11269877" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2008 13:49:54 +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 m5ABnsPE011375; Tue, 10 Jun 2008 13:49:54 +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 m5ABnsMO011554; Tue, 10 Jun 2008 11:49:54 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, 10 Jun 2008 13:49:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 13:49:16 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjK6wCUe0ByGqbWSZ2gXeNwI0jsxAAABCsg 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" X-OriginalArrivalTime: 10 Jun 2008 11:49:54.0470 (UTC) FILETIME=[1940D460:01C8CAF0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=518; t=1213098594; x=1213962594; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=09RE=3A=09New=09charter=20for=206 lowpan) |Sender:=20; bh=DSGhhwOW6FpcIz1tSyOamCPxdsC5mzHXEWiyNvdFqdY=; b=I8lA0QrUMRDUtx1nHfLFVvrwpdETR/A9wkoHPnGSvoH4BDNvW7NPNmIq+v +rWGwOf0Ek+JnIZWrwlANHgwrHK2qJY/IV6WqY39M/icRRRel8am8E/YxfMQ jDXSAMykG2; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 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 Lloyd: This is great reading and might prevent mistakes in using UDP CS compression; but does not apply here: - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) Message Integrity Check (MIC) instead of UDP checksum. - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) - And we are designing for devices that might not have hardware assist other than maybe what's specified by 802.15.4 so that's what we use. I hope it's clearer now... Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 10 07:13: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 3A3C23A68C7; Tue, 10 Jun 2008 07:13: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 127853A6874; Tue, 10 Jun 2008 07:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 G2DeOuJKakOn; Tue, 10 Jun 2008 07:13:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DE2593A68FF; Tue, 10 Jun 2008 07:13:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,617,1204498800"; d="scan'208";a="11290274" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2008 16:13: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 m5AEDpkX002278; Tue, 10 Jun 2008 16:13:51 +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 m5AEDpWP018455; Tue, 10 Jun 2008 14:13:51 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, 10 Jun 2008 16:13:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 16:13:13 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> In-Reply-To: <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjK9WJeVzovBCloQ0GlrVDF7V/s8AABX1pw 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" X-OriginalArrivalTime: 10 Jun 2008 14:13:50.0868 (UTC) FILETIME=[34F29540:01C8CB04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3153; t=1213107231; x=1213971231; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=09RE=3A=09New=09charter=20for=206 lowpan) |Sender:=20; bh=g2g67pYOf2/6k9zZAUpWPUx9HwyOnKwS/RbhtXmYZ4A=; b=gyItGOMmoPTT32i70dPgiUrL3gMz45Ug9C/QjyjWfSjztX93kKuLqDAIWF Dtge9EEX0xOt3OSf5l2mh3pIyQcJv9OoiOkx3LWftu52VRGm1qg1uQX1NbVW UOrQG6Eeog; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 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 Lloyd: >> - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) >> Message Integrity Check (MIC) instead of UDP checksum. > >Pascal, > >End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. How >can this be "end-to-end UDP" when it clearly doesn't want to be UDP? >Sitting directly on top of IP at both endhosts and doing the pseudo- >header check yourself as a transport layer alternative to UDP, without >the overhead of unwanted UDP fields that get faked up, would seem to >make more sense here than sort-of-tunnelling in UDP from the endhost >and then subverting and reconstituting the UDP fields. [Pascal] The only fake is that we still call the ISA100.11a transport UDP though it's not. This is done to reuse the IPv6 next header and the 6LoWPAN HC2 though we know it's improper. The transport is a UDP variant in that the checksum is computed differently, has additional security properties and gets placed somewhere else. But the end to end principle is respected exactly as with original UDP. > >RFC4944 is about carrying IPv6 across 802.15.4 networks, and prohibits >UDP checksum compression for good reason. Modifying that to allow >checksum compression might work for IA100.11a if and only if both >endhosts are sitting on the 802.15.4 network communicating via >ISA100.11a, and the packet never goes any further - ie you're relying >solely on the MIC, and the UDP checksum is never used. If the packet >goes further and a reconstituted UDP checksum is required at the >endhost for an integrity check - that's the slippery slope where the >end-to-end principle has many warnings. Applying TLS across the >6lowpan part of such a path does not mitigate end-to-end concerns >here. And, thanks to NAT/relaying etc., it can't be guaranteed that >the packet will go no further - a slippery slope. > [Pascal] No. The ISA100.11a transport is end to end as usual in the IP model; both ends need to be ISA100.11a nodes so that they know how to terminate the ISA100.11a transport. The IP network in the middle is transparent and could be the Internet, that's the end to end principle. IPv6 and UDP are compressed over the LoWPAN, that's 6LoWPAN. > >> - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) > >TLS was intended and is used simply as a shorthand for transport layer >security - a term you used in the email I was replying to. I don't >accept that RFC4346 now owns the term. > >This quote to you from Geoff Mulligan on 22 May seems relevant and >applicable here: >"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." [Pascal] ISA100.11a has spent quite some effort doing its work. For instance, we made sure that the points raised in draft-ietf-tsvwg-udp-guidelines were all addressed. For the particular aspect of how we compute the checksum, we pretend it is as good or better than in the original UDP. Are you challenging that? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 10 07:59: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 6873F3A6839; Tue, 10 Jun 2008 07:59: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 735E43A6839; Tue, 10 Jun 2008 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VksXJJxHnYe; Tue, 10 Jun 2008 07:59:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2D3253A6811; Tue, 10 Jun 2008 07:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5AExX3e018401; Tue, 10 Jun 2008 16:59:36 +0200 (CEST) From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC5002@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> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> Message-Id: <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 16:59:33 +0200 X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [6lowpan] [Roll] 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 On Jun 10 2008, at 16:13, Pascal Thubert (pthubert) wrote: > we still call the ISA100.11a transport > UDP though it's not OK, so this transport protocol would like to use an 8-byte header with a source port number, a destination port number, and two highly compressible fields (redundant length, and the now redundant checksum), but it has its own *end-to-end* checksum, which is better than 16-bit one's complement and *does* include a pseudo header. Two observations: 1) compression works best when it is done cross-layer. So one would want to compress the whole stack from IP upwards to the ISA100 transport. This of course could include knowledge about the layer above UDP, just as we have included knowledge about RTP in RFC 3095/5225. 2) Given this transport, the end system is likely to want back the feature of UDPv4 that allowed sending a zero checksum. This transport is a nice example for how it was a mistake to conflate policy and mechanism in UDPv6: Encoding the *policy* not to send packets without a checksum that includes a pseudo-header with the *mechanism* to never allow zero checksums in UDPv6. Of course, you should not have mechanism that a policy makes sure you will never use, but the mechanism is already there for IPv4, and the example is exactly one such case where the policy would not imply non- use of the mechanism. Obviously, if an end system does not want protection from UDP (and it shouldn't want it in the ISA100 case), it should say so by setting the checksum to zero. The mechanism/policy conflation mentioned above makes that impossible. Changing UDPv6 at this stage is a big step. If that is not what we (the IETF/the IPv6 implementers community) want to do, there is no way for the end system to make that statement. This does not mean that we shouldn't honor it. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 10 14:51:08 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 E3BB93A6AC1; Tue, 10 Jun 2008 14:51:08 -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 A26CA3A6928; Tue, 10 Jun 2008 14:51:07 -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 XPyXVMVOI87E; Tue, 10 Jun 2008 14:51:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1A2843A67FE; Tue, 10 Jun 2008 14:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5ALotfY004195; Tue, 10 Jun 2008 23:50:58 +0200 (CEST) Message-Id: From: Carsten Bormann To: Lloyd Wood In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 23:50:55 +0200 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [6lowpan] [Roll] 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 > a. Use UDP-Lite, to avoid checksum coverage of its payload, and > still get a pseudoheader check from UDP. How does that help with getting rid of the checksum? With UDP-lite, you now have two, with different coverage. > b. Implement its own transport protocol, in parallel with UDP/TCP/ > SCTP, with its own pseudoheader check, doing payload coverage > however it likes. That's what they did. They want to do this on top of UDP, which is a usual way to build new transport protocols these days (cf. RTP). If UDPv6 were like UDPv4, this would be a better fit. >> The mechanism/policy conflation mentioned above >> makes that impossible. > > Not impossible. It comes down to the pain of using UDP-Lite, or the > pain of writing your own proper gets-a-protocol-number transport > protocol with its own pseudoheader check. Either is better from > layering/size/complexity viewpoints than layering over UDP and > turning UDP checksums off. I don't agree with "better" here. Being able to use UDP reduces complexity here; certainly from an implementation point of view (if you consider that there will be hosts with common operating systems on e.g. Ethernets that want to talk to lowpans). >> Changing UDPv6 at this stage is a big step. If that is not what we >> (the IETF/the IPv6 implementers community) want to do, there is no >> way >> for the end system to make that statement. This does not mean that >> we >> shouldn't honor it. > > Sorry, I'm unclear on the meaning of your last sentence here; the > double negative (triple from the previous sentence) doesn't help. I'm just saying that, in the first-hop/last-hop case, HC could help 2460 a little here, just (as you noted) NATs tend to "help" with maintaining that checksum, by proxying out the UDP checksum generation/ check to the next hop, as long as there is something else that provides e2e protection. In the first-hop case, it is easy for the host to make the statement (by providing a mechanism for eliding the checksum); in the last-hop case, there would need to be some agreement (implied or signaled). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 01:08: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 B8A743A69BC; Wed, 11 Jun 2008 01:08: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 A7FBF3A68DB for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 01:08:05 -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 up2u5Shr4NsA for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 01:08:04 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id D070C3A6879 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 01:08:04 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3224678wfd.31 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 01:08: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=tbkAHN9IvRZqp4juJTyxyCt7r696zQN97CGm5N52C6Y=; b=AEdWRcSDTIk3C7tAY5+CdhZQIKvDKJKjvDLk5re+GxYWeK3XVmqpcw+rMW6ker6MTu zE+gpiIaUjBDigVJkGfUmg1BeQ+XJwGkrU1WKfCKIcsGTKswLhOOgm0OUExEdDCaxqk1 9CwIQvbfEVh7tjvy5CqjLH+6Kyk9J4Ep+ykz8= 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=CcZdBbqEChT63Y3m69v7S6kK43e6hhIr9TyfPjwZgssRcOLhe7MfcJ98JLprFcOMqF Y+acUjQ2c4hQldbIETfMrUeZVkEVMr9hSDWAgNkS0O0Wx5491+711SqD86hv5LlB375g n6vxvYdErse/tmK/xqRpPBVIJnhVEuzYdXDfE= Received: by 10.143.17.13 with SMTP id u13mr2502468wfi.18.1213171707507; Wed, 11 Jun 2008 01:08:27 -0700 (PDT) Received: by 10.142.78.9 with HTTP; Wed, 11 Jun 2008 01:08:27 -0700 (PDT) Message-ID: <43b91d370806110108g4b2a6fa6uc697a89aad785d3e@mail.gmail.com> Date: Wed, 11 Jun 2008 01:08:27 -0700 From: "Samita Chakrabarti" To: "Geoff Mulligan" In-Reply-To: <1212175947.9165.10.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <1212175947.9165.10.camel@dellx1> 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, Pascal's analysis of prioritizing items makes sense to me. On 5/30/08, 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? > A summary of mesh-under requirements is needed in the architecture document even if we decide to have a separate elaborate document afterwards. Thanks, -Samita > > 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 "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 Wed Jun 11 01:12: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 AE7BB3A69FC; Wed, 11 Jun 2008 01:12: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 7FB383A69E5; Wed, 11 Jun 2008 01:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.356 X-Spam-Level: X-Spam-Status: No, score=-4.356 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, 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 n8OTW9usrh2g; Wed, 11 Jun 2008 01:12:50 -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 33A7B3A69B4; Wed, 11 Jun 2008 01:12:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,623,1204520400"; d="scan'208";a="10700520" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jun 2008 04:13: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 m5B8DEFJ021834; Wed, 11 Jun 2008 04:13: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 m5B8DErM010078; Wed, 11 Jun 2008 08:13: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); Wed, 11 Jun 2008 04:13:13 -0400 Received: from 144.254.188.136 ([144.254.188.136]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jun 2008 08:13:13 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 11 Jun 2008 10:13:10 +0200 From: JP Vasseur To: Lloyd Wood , Carsten Bormann Message-ID: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjLmvxl9hLwOgAkyk+5spkQmgCMVg== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 11 Jun 2008 08:13:13.0916 (UTC) FILETIME=[FEBB77C0:01C8CB9A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4840; t=1213171994; x=1214035994; 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[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=20RE=3A=20New=0A=20charter=20for= 206lowpan) |Sender:=20 |To:=20Lloyd=20Wood=20,=20Carsten=20Bo rmann=20; bh=spdz10fLz9s/I3LuTIB+U8oAgOrAg98QhAbGZwoV/1w=; b=yuq3+LqggEBTPSL/kPUsQPRyHsA4MaqaIYnWOO6nA8m+j4JxKvUaSNo4Dr zuLD7rsLiBJx4Gp5lSF06KV5Wg+Slau4v/T5bU+0reTK8w4TGJA3//I8+XIN E9NXc9NCAC; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] [Roll] 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 I think that the ROLL ML can be removed from this thread. Thanks. JP. On 6/11/08 12:01 AM, "Lloyd Wood" wrote: > References: > <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-3 > 37.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-96296 > 8881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B > 125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337 > .emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <12114968 > 60.23290.41.camel@dellx1> > <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> > <484D5B93.2080802@cisco.com> > <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> > <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> > > <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> > <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> > <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> > <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> > 7069-490C-AFA5-340840E9E82A@tzi.org> > X-Mailer: Apple Mail (2.924) > Return-Path: L.Wood@surrey.ac.uk > X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0358 (UTC) > FILETIME=[7BFF73E0:01C8CB45] > > inline... > > On 10 Jun 2008, at 22:50, Carsten Bormann wrote: > >>> a. Use UDP-Lite, to avoid checksum coverage of its payload, and >>> still get a pseudoheader check from UDP. >> >> How does that help with getting rid of the checksum? >> With UDP-lite, you now have two, with different coverage. >> >>> b. Implement its own transport protocol, in parallel with UDP/TCP/ >>> SCTP, with its own pseudoheader check, doing payload coverage >>> however it likes. >> >> That's what they did. > > No, ISA sits _over_ UDP, not over IP as UDP/TCP/SCTP do. > >> They want to do this on top of UDP, which is a usual way to build >> new transport protocols these days (cf. RTP). > > No, it's a way to really build more 'session-like' protocols. I > wouldn't call RTP a full transport, as it doesn't care about > describing length, or about reliability. > >> If UDPv6 were like UDPv4, this would be a better fit. >> >>>> The mechanism/policy conflation mentioned above >>>> makes that impossible. >>> >>> Not impossible. It comes down to the pain of using UDP-Lite, or the >>> pain of writing your own proper gets-a-protocol-number transport >>> protocol with its own pseudoheader check. Either is better from >>> layering/size/complexity viewpoints than layering over UDP and >>> turning UDP checksums off. >> >> I don't agree with "better" here. >> Being able to use UDP reduces complexity here; certainly from an >> implementation point of view (if you consider that there will be >> hosts with common operating systems on e.g. Ethernets that want to >> talk to lowpans). > > ...which makes removing the UDP checksum more problematic. > > >>>> Changing UDPv6 at this stage is a big step. If that is not what we >>>> (the IETF/the IPv6 implementers community) want to do, there is no >>>> way >>>> for the end system to make that statement. This does not mean >>>> that we >>>> shouldn't honor it. >>> >>> Sorry, I'm unclear on the meaning of your last sentence here; the >>> double negative (triple from the previous sentence) doesn't help. >> >> I'm just saying that, in the first-hop/last-hop case, HC could help >> 2460 a little here, just (as you noted) NATs tend to "help" with >> maintaining that checksum, > > They don't "help". Quite the opposite - by recomputing the checksum > the value of the end-to-end guarantee offered by the checksum is > reduced. HC may save bits on the wire, but it doesn't help overall > reliability. HC can't make anything as reliable, or more reliable. > > >> by proxying out the UDP checksum generation/check to the next hop, >> as long as there is something else that provides e2e protection. > > Why fake up a checksum at a proxy unless something is going to use it? > And if something does, there are e2e implications. > > (I doubt that we will ever agree here.) > >> In the first-hop case, it is easy for the host to make the >> statement (by providing a mechanism for eliding the checksum); in >> the last-hop case, there would need to be some agreement (implied or >> signaled). >> >> Gruesse, Carsten >> > > DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 01:46: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 55C8D3A69D4; Wed, 11 Jun 2008 01:46: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 1263F3A6886; Wed, 11 Jun 2008 01:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 uHxmyMOgHsFs; Wed, 11 Jun 2008 01:46:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E644D3A6971; Wed, 11 Jun 2008 01:46:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,623,1204498800"; d="scan'208";a="11361262" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2008 10:46: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 m5B8kUrH006357; Wed, 11 Jun 2008 10:46: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 m5B8kUbx027402; Wed, 11 Jun 2008 08:46:30 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 10:46:30 +0200 Received: from Townsley-MacBook.local ([64.103.30.122]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 10:46:30 +0200 Message-ID: <484F90E4.9050200@cisco.com> Date: Wed, 11 Jun 2008 10:46:28 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: roll@ietf.org, 6lowpan <6lowpan@ietf.org> References: In-Reply-To: X-OriginalArrivalTime: 11 Jun 2008 08:46:30.0248 (UTC) FILETIME=[A4A38E80:01C8CB9F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1236; t=1213173990; x=1214037990; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20HC1G=20a=20requirement=20for=20roll?=20 |Sender:=20; bh=os+CTMQxRgbRhoTvkHH1oIyevjdJzkNLWlPmvT944R8=; b=pqTEAnnJS1tNrK423g3SK6E6hH044R/AYHK3+lZ63xV6zpua5+J5Ok06M0 Arc0mokAF9WOprUiZPuFjpgccVI6P3hHQMqIwgHT8c4RqVIIXoZVzEaTiDDW KwhUAdC/Cz; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [6lowpan] HC1G a requirement for roll? 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 posed this question earlier, but it seems to have been lost in the thread discussing UDP checksums. I'd like to know if this really is important, or if there is some obvious answer that I am missing... (HC1G as explained to me is the ability to compress the address field for a non-link-local IPv6 address when transmitting - something that has not been defined by 6lowpan yet and we are making chartering decisions on). Mark Townsley wrote: > It would seem to me that HC1G would be very important to understanding > how ROLL is going to work. If you are routing between subnets at L3, > then by definition you cannot be using link-local addressing on them. > So, either ROLL is stuck with 128-bit addresses in data packets, or we > figure out how to compress global addresses. Or, am I missing something > obvious? If we have accepted that routing lowpan subnets means using a non-link-local address, which means using a globally unique address, which finally means a 128 bit address field in all lowpan data packets, then we of course do not need to define how to compress global addresses. But, I'd like to know if that decision has been made, or if there is some other solution. Thanks, - Mark _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 02:51: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 418BC3A68A1; Wed, 11 Jun 2008 02:51: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 49ED43A68A1 for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 02:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOfPV8bUHS0t for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 02:51:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D0B363A6802 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 02:51:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,623,1204498800"; d="scan'208";a="11372472" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2008 11:52:07 +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 m5B9q7pV027098; Wed, 11 Jun 2008 11:52:07 +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 m5B9q7bk002661; Wed, 11 Jun 2008 09:52:07 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); Wed, 11 Jun 2008 11:52:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 11:51:25 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05CC5394@xmb-ams-337.emea.cisco.com> In-Reply-To: <508253DB-DD52-4202-9102-50BB14DB36BC@surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjLMW33y+TuTDe3SlGq4z+t/Qdd4gAdtWKQ 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> <508253DB-DD52-4202-9102-50BB14DB36BC@surrey.ac.uk> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" X-OriginalArrivalTime: 11 Jun 2008 09:52:07.0519 (UTC) FILETIME=[CF6F6EF0:01C8CBA8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2939; t=1213177927; x=1214041927; 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]=20ISA100.11a=20status=20and=2 0requirements(was=09RE=3A=09New=09charter=20for=206lowpan) |Sender:=20; bh=aB9K5BFwA/jJ/k0hvUbvk0gbKeioW8FMLTsv90LsOUU=; b=nNLGgdUnEWkDaEZY5izL2Z7hwX7k45GAc9aOYp5U3eLpVzT8FEPr2Qzu0h dOwTl5zfjZLnDDhpdnEmmhimR9fCYYx/qpYZ5SFhcUO7NAY0Z6+5S5sA9OXZ SspI5oTeyc; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , Jose.Gutierrez@emerson.com, 6lowpan@ietf.org, "Brett, Patricia \(PA62\)" 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 Lloyd: Seems to me we are converging. I'm confident that now you have a clear image on what ISA100.11a is doing though you might still be missing a bit of the rationale behind. At this point, there is no solid|new issue against ISA100.11a transport and I do thank you for this review. >> >> Obviously, if an end system does not want protection from UDP (and it >> shouldn't want it in the ISA100 case), it should say so by setting >> the checksum to zero. > > No. It should either: > a. Use UDP-Lite, to avoid checksum coverage of its payload, and still > get a pseudoheader check from UDP. > b. Implement its own transport protocol, in parallel with UDP/TCP/ > SCTP, with its own pseudoheader check, doing payload coverage however > it likes. ISA100.11a transport is clearly b. It has both the pseudoheader check and the payload coverage. On top of that it has authentication and optional encryption though IPSec/IKE was not affordable. The rationale is tightly linked to the very constrained environment ISA100.11a operates in. >ISA100.11a should be sitting parallel to TCP/UDP/SCTP, not on top of UDP. The only difference is the pretence thing. To my best knowledge, ISA100.11a transport has all the right properties that IETF mandates. >Still, never mind; it is, of course, late to change the ISA100 design >(but, oddly, not too late to change RFCs 2460 and 4346?) . Feel free to >ignore me. ISA100.11a does not want to revinvent the wheel, this is why the group made all efforts to comply to IETF whenever possible, including IPv6, 6loWPAN, TSVWG recommendations, etc... The real question now is whether we can get that bit in 6loWPAN HC. >Wait a bit, you'll probably want that reserved bit for something more >useful in a while. (I am reminded of the furore over reusing the three >MPLS experimental bits - that kept Stewart Bryant flying round the >world for months.) That's the valid point. You need to look at Jonathan's draft; there's a plethora of bits in the NHC in the UDP case (4 left after we define one for UDP checksum conpression): http://tools.ietf.org/html/draft-hui-6lowpan-hc-00#page-9 " 3.2. LOWPAN_UDP Header Compression This document defines a compression format for UDP headers using LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 7. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |ID | S | D | C | rsv | +---+---+---+---+---+---+---+---+ Figure 7: Compressed IPv6 Multicast Address Encoding " Now, I think we might want to revisit this so that UDP is NOT the ID bit 0. Other transports might need more bits than UDP does. This is something that should be discussed as we progress draft-hui-6lowpan-hc-00 ... Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 11:55:15 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 1FBF43A68B4; Wed, 11 Jun 2008 11:55:15 -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 41DFC28B23E; Mon, 9 Jun 2008 12:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.759 X-Spam-Level: X-Spam-Status: No, score=-6.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, 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 qGwPC3yT-NyS; Mon, 9 Jun 2008 12:28:11 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id A12C23A6AAC; Mon, 9 Jun 2008 12:28:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-4.tower-83.messagelabs.com!1213039708!44627487!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 10536 invoked from network); 9 Jun 2008 19:28:29 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-4.tower-83.messagelabs.com with SMTP; 9 Jun 2008 19:28:29 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 20:28:28 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 20:28:27 +0100 Message-Id: <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> From: Lloyd Wood To: Mark Townsley In-Reply-To: <484D5B93.2080802@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 20:28:26 +0100 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> <1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 09 Jun 2008 19:28:28.0138 (UTC) FILETIME=[FE43A4A0:01C8CA66] X-Mailman-Approved-At: Wed, 11 Jun 2008 11:55:14 -0700 Cc: Geoff Mulligan , roll@ietf.org, Jay Werb , "Polyzois, Christos A" , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 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 On 9 Jun 2008, at 17:34, Mark Townsley wrote: > Geoff Mulligan wrote: >> Mark, >> this is interesting news. This can save another byte and if there >> would be no large push against this then compressing out another byte >> would be good. >> > I can't promise anything, but 6lowpan certainly isn't the only place > where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty > much any UDP-based tunneling protocol running on a router in > hardware at > high scale or speeds is running into the same problem. The pseudo-header checksum is the only thing preventing misdelivery; the header gets checked once at the endpoint (IPv6) as opposed to being checked and recomputed at every hop (IPv4). I'm not convinced that the IPv6 design choices here were right - I'd have gone for a header checksum across immutable fields, skipping TTL, CoS and the like, that wouldn't require recomputing, and which would have constrained misdelivery to a single link, rather than the path - this would be more useful for resends and diagnostics, while increasing the pain for NAT. Here, IPv6 assumes a tight application/ application control loop and path where the cost of resending a packet across the entire path is low. That raw IPv6 header tunnelling sans UDP header (or GRE sans optional checksum or MPLS) lacks any self-checking mechanism for reliability should be of some concern. RFC2460 p28 section 8.1 Upper-Layer Checksums: [..] o Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error. ^^^^ [..] That 'must' is clear and unambiguous. The side-effects mean that this should NOT be thought of as an optimization. L. > I know of > implementations today that zero out the UDP checksum, and IMHO a good > implementation that is "liberal in what it accepts" would not drop the > packet with a zero UDP checksum arriving over IPv6 (in fact, its > annoying that one would even have to differentiate between IPv4 and > IPv6 > at all here if you ask me). >> This is currently in the HC1g draft and would allow consistency >> between >> 6lowpan and SP100. >> > I suppose that isn't a bad thing. > > - Mark >> geoff >> >> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: >> >>> Geoff Mulligan wrote: >>> >>>> 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'm more optimistic about keeping the UDP checksum optimization. >>> There >>> are other forces at work which may relax the UDP checksum >>> requirement in >>> IPv6 in certain cases. So as long as you have well thought out >>> reasoning, I wouldn't be afraid of keeping it in. >>> >>> - Mark >>> >>>> 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 >>>> >>>> >>>> >> >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 11:55:15 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 4C8623A69A3; Wed, 11 Jun 2008 11:55:15 -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 706963A6765; Tue, 10 Jun 2008 04:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.759 X-Spam-Level: X-Spam-Status: No, score=-6.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, 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 wR99POX02WL2; Tue, 10 Jun 2008 04:11:55 -0700 (PDT) Received: from mail133.messagelabs.com (mail133.messagelabs.com [195.245.230.179]) by core3.amsl.com (Postfix) with SMTP id A341C3A6832; Tue, 10 Jun 2008 04:11:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-133.messagelabs.com!1213096330!21900445!11 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 21040 invoked from network); 10 Jun 2008 11:12:15 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-14.tower-133.messagelabs.com with SMTP; 10 Jun 2008 11:12:15 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 12:12:03 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 12:12:02 +0100 Message-Id: From: Lloyd Wood To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 12:12:01 +0100 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 11:12:03.0170 (UTC) FILETIME=[CF73F420:01C8CAEA] X-Mailman-Approved-At: Wed, 11 Jun 2008 11:55:14 -0700 Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 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 below On 10 Jun 2008, at 08:33, Pascal Thubert (pthubert) wrote: > > Per RFC 4944: > "The UDP header's checksum field is not compressed and is therefore > carried in full." > > The UDP checksum is not the only way to protect the IP pseudo header, > the UDP header and the payload. > ISA 100.11a is defining a transport-level security that does all this > and more, since it has a larger signature and provides mutual > authentication at the same time. The end-to-end principle tells us that that is not good enough if that is not implemented between endhosts across the entire path - this is like saying that we're going across an Ethernet link, Ethernet's CRC32 is stronger than the UDP checksum, therefore we'll just leave out the UDP checksum and recompute it once we're across the Ethernet link. RFC4944 deliberately leaves the UDP checksum alone to preserve an end- to-end integrity check - if it is altered (compressed) and then altered back, you cannot be sure that errors have not been introduced (more likely software bugs than transmission errors). Those errors cannot be easily detected by an endhost, because the checksum has been recomputed and is no longer a valid end-to-end check. A recomputed checksum is far less useful for protection - one reason why the IPv4 header checksum was simply removed in IPv6. > Also, the ISA100.11a transport-level security is usually > hardware-assisted, so it requires little power or CPU time on the > field > device, whereas UDP checksum will be a costly CPU operation. Sorry, false argument. google hardware-assisted UDP checksum. It's not computationally difficult or hard. When adding TLS and compressing the UDP header, is the UDP checksum verified across the entire payload and pseudo-header before this is done, to check that you're starting with good material? There's still an unavoidable need for a necessary UDP checksum computation there. If you're going to replace then recompute the checksum leaving the subnet, you need to compute it going in to check that what you're about to checksum across is good. > So ISA100.11a is an example where the UDP checksum could and actually > should be compressed over the LoWPAN, leaving it up to be > reconstructed > by a backbone router should the packet go any further than the LOWPAN > itself. > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > standardize it to mean that the UDP checksum is compressed, provided > that the headers and payload are equally or better protected than if > the > checksum was used. That misunderstands the end-to-end principle and the nature of protection across the entire path; it's really not equal, despite the weakness of the UDP checksum strength, because the UDP checksum is across the whole path between endhosts, and the TLS protection is not. Wait a bit, you'll probably want that reserved bit for something more useful in a while. (I am reminded of the furore over reusing the three MPLS experimental bits - that kept Stewart Bryant flying round the world for months.) > Then followed a thread entitled: > "[6lowpan] Compressing the UDP checksum" > > In short, there was a general agreement that this was doable under > circumstances; In particular, the current draft under review of > ISA100.11a transport section (under review) has the following text: > > " > 1.4.3 Eliding the UDP checksum > ISA100.11a uses both HC1 and HC2, and extends the UDP common > compressed > header encoding to compress the UDP upper layer checksum by relying on > the Transport layer security to provide the same service, and more. > For that purpose, the Transport layer builds an ISA100.11a pseudo- > header > by concatenating the UDP pseudo-header for IPv6 as described in the > previous section, the source UDP port and the destination UDP port: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Upper-Layer Packet Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | zero | Next Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source UDP port | Destination UDP port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The ISA100.11a pseudo-header is filled and placed before the UDP > payload > for the crypto process. If encryption is performed on the message, the > pseudo-header is not encrypted, but the pseudo-header is part of the > MIC > in any case. > Once the crypto process is completed, the pseudo-header is removed > from > the message, and the IP and UDP headers are put in its place for > transmission. On the receiving side, the transport layer will restore > the pseudo-header based on the received packet prior to the crypto > process to validate that none of the protected fields was tempered > with. spelling - tampered. > When HC2 is applied, bit 3 in the UDP common compressed header > encoding, > which is reserved in RFC 4944, is set to express whether the > checksum is > elided. When so, the 8 bytes of UDP header can be compressed down to a > single byte that contains the partially compressed ports, using 4 bits > each. > Note 1: When the packet is not protected by the Transport layer > security, the UDP checksum can not be compressed and must be carried > in > full as prescribed by RFC 4944. If Transport Layer Security is active > for a given packet, then the UDP checksum might be elided as > prescribed > above. > Note 2: If the UDP upper layer checksum field is elided, it is up to double space > > the other endpoint across the DLL subnet to recompute the UDP checksum > as part of the 6LoWPAN expansion, if necessary. This is required in > particular for a middlebox such as a backbone router that forwards the > uncompressed packet as opposed to terminating the transport. > Note 3: If the UDP checksum is not elided and security is applied, > then > the UDP checksum must be computed after the security operation is > complete and the security fields are filled. The UDP payload that is > used for the UDP checksum includes all data from the UDP header on, > including the security fields, application data and MIC fields, > whether > the application data is encrypted or not. > " > > This proposal provides better guarantees than the UDP checksum alone. > Part of it because the security signature is longer and the UDP > checksum, and part of it because that security authenticates the > data as > well. But it's only across the 6lowpan part of the path, not across the full path end-to-end, which is the UDP checksum's key feature. You're disobeying the spirit of the text in RFC2460. Do you really think that attention will be paid to the must in your Note 1? It's a slippery slope. > Would you agree that compressing the UDP checksum is valid in this > case? Sorry, it's not. I looked in vain for any mention of the end-to-end principle in the previous mailing list discussion. If you're only adding a header for tunnelling, UDP-Lite or something else can give you a sanity check across the tunnelling header alone, leaving protection of the tunnelled packet up to the checksum in that packet without the overhead of going over the entire paylaod. (IPv6 needs some sort of pseudo-header check from every transport protocol, and the IPv6 header doesn't have it, so UDP-Lite/IPv6 seems attractive. Leaving this up to transport layer designers seems a poor design choice.) But messing with payload integrity checks has subtle and far-reaching consequences. L. > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of > Lloyd Wood >> Sent: lundi 9 juin 2008 21:28 >> To: Mark Townsley (townsley) >> Cc: Geoff Mulligan; roll@ietf.org; Jay Werb; Polyzois,Christos A; > Chernoguzov,Alexander (PA35); >> 6lowpan@ietf.org >> Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was > RE: New charter for 6lowpan) >> >> >> On 9 Jun 2008, at 17:34, Mark Townsley wrote: >> >>> Geoff Mulligan wrote: >>>> Mark, >>>> this is interesting news. This can save another byte and if there >>>> would be no large push against this then compressing out another > byte >>>> would be good. >>>> >>> I can't promise anything, but 6lowpan certainly isn't the only place >>> where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty >>> much any UDP-based tunneling protocol running on a router in >>> hardware at >>> high scale or speeds is running into the same problem. >> >> The pseudo-header checksum is the only thing preventing misdelivery; >> the header gets checked once at the endpoint (IPv6) as opposed to >> being checked and recomputed at every hop (IPv4). >> >> I'm not convinced that the IPv6 design choices here were right - I'd >> have gone for a header checksum across immutable fields, skipping >> TTL, >> CoS and the like, that wouldn't require recomputing, and which would >> have constrained misdelivery to a single link, rather than the path - >> this would be more useful for resends and diagnostics, while >> increasing the pain for NAT. Here, IPv6 assumes a tight application/ >> application control loop and path where the cost of resending a >> packet >> across the entire path is low. >> >> That raw IPv6 header tunnelling sans UDP header (or GRE sans optional >> checksum or MPLS) lacks any self-checking mechanism for reliability >> should be of some concern. >> >> RFC2460 p28 section 8.1 Upper-Layer Checksums: >> >> [..] >> o Unlike IPv4, when UDP packets are originated by an IPv6 node, the >> UDP checksum is not optional. That is, whenever originating a UDP >> packet, an IPv6 node must compute a UDP checksum over the packet and >> the pseudo-header, and, if that computation yields a result of zero, >> it must be changed to hex FFFF for placement in the UDP header. IPv6 >> receivers must discard UDP packets containing a zero checksum, and >> should log the error. ^^^^ >> [..] >> >> That 'must' is clear and unambiguous. The side-effects mean that this >> should NOT be thought of as an optimization. >> L. >> >>> I know of >>> implementations today that zero out the UDP checksum, and IMHO a >>> good >>> implementation that is "liberal in what it accepts" would not drop > the >>> packet with a zero UDP checksum arriving over IPv6 (in fact, its >>> annoying that one would even have to differentiate between IPv4 and >>> IPv6 >>> at all here if you ask me). >>>> This is currently in the HC1g draft and would allow consistency >>>> between >>>> 6lowpan and SP100. >>>> >>> I suppose that isn't a bad thing. >>> >>> - Mark >>>> geoff >>>> >>>> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: >>>> >>>>> Geoff Mulligan wrote: >>>>> >>>>>> 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'm more optimistic about keeping the UDP checksum optimization. >>>>> There >>>>> are other forces at work which may relax the UDP checksum >>>>> requirement in >>>>> IPv6 in certain cases. So as long as you have well thought out >>>>> reasoning, I wouldn't be afraid of keeping it in. >>>>> >>>>> - Mark >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ >> >> >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 11:55:15 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 7E6A93A69E8; Wed, 11 Jun 2008 11:55:15 -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 E81DF3A69F4; Tue, 10 Jun 2008 05:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.679 X-Spam-Level: X-Spam-Status: No, score=-6.679 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 I2K7zpDoxn5x; Tue, 10 Jun 2008 05:27:11 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id 2801D3A67F5; Tue, 10 Jun 2008 05:27:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-13.tower-83.messagelabs.com!1213100851!60600154!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 15691 invoked from network); 10 Jun 2008 12:27:31 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-13.tower-83.messagelabs.com with SMTP; 10 Jun 2008 12:27:31 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 13:27:31 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 13:27:30 +0100 Message-Id: <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> From: Lloyd Wood To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 13:27:30 +0100 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 12:27:30.0635 (UTC) FILETIME=[5A0849B0:01C8CAF5] X-Mailman-Approved-At: Wed, 11 Jun 2008 11:55:14 -0700 Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 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 On 10 Jun 2008, at 12:49, Pascal Thubert (pthubert) wrote: > Hi Lloyd: > > This is great reading and might prevent mistakes in using UDP CS > compression; > but does not apply here: > > - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) > Message Integrity Check (MIC) instead of UDP checksum. Pascal, End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. How can this be "end-to-end UDP" when it clearly doesn't want to be UDP? Sitting directly on top of IP at both endhosts and doing the pseudo- header check yourself as a transport layer alternative to UDP, without the overhead of unwanted UDP fields that get faked up, would seem to make more sense here than sort-of-tunnelling in UDP from the endhost and then subverting and reconstituting the UDP fields. RFC4944 is about carrying IPv6 across 802.15.4 networks, and prohibits UDP checksum compression for good reason. Modifying that to allow checksum compression might work for IA100.11a if and only if both endhosts are sitting on the 802.15.4 network communicating via ISA100.11a, and the packet never goes any further - ie you're relying solely on the MIC, and the UDP checksum is never used. If the packet goes further and a reconstituted UDP checksum is required at the endhost for an integrity check - that's the slippery slope where the end-to-end principle has many warnings. Applying TLS across the 6lowpan part of such a path does not mitigate end-to-end concerns here. And, thanks to NAT/relaying etc., it can't be guaranteed that the packet will go no further - a slippery slope. > - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) TLS was intended and is used simply as a shorthand for transport layer security - a term you used in the email I was replying to. I don't accept that RFC4346 now owns the term. This quote to you from Geoff Mulligan on 22 May seems relevant and applicable here: "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." cheers, L. > - And we are designing for devices that might not have hardware assist > other than maybe what's specified by 802.15.4 so that's what we use. > > I hope it's clearer now... > > Pascal DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 11:55:15 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 B20CE3A6A53; Wed, 11 Jun 2008 11:55:15 -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 F1B013A6ACF; Tue, 10 Jun 2008 12:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.652 X-Spam-Level: X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 SEWbfVUx9xuF; Tue, 10 Jun 2008 12:36:57 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id CBF423A6993; Tue, 10 Jun 2008 12:36:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1213126638!54011994!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 8508 invoked from network); 10 Jun 2008 19:37:18 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-82.messagelabs.com with SMTP; 10 Jun 2008 19:37:18 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:37:18 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:37:16 +0100 Message-Id: <508253DB-DD52-4202-9102-50BB14DB36BC@surrey.ac.uk> From: Lloyd Wood To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 20:37:16 +0100 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 19:37:17.0263 (UTC) FILETIME=[640F75F0:01C8CB31] X-Mailman-Approved-At: Wed, 11 Jun 2008 11:55:14 -0700 Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [6lowpan] [Roll] 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 On 10 Jun 2008, at 15:13, Pascal Thubert (pthubert) wrote: > Hi Lloyd: > >>> - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) >>> Message Integrity Check (MIC) instead of UDP checksum. >> >> Pascal, >> >> End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. >> How >> can this be "end-to-end UDP" when it clearly doesn't want to be UDP? >> Sitting directly on top of IP at both endhosts and doing the pseudo- >> header check yourself as a transport layer alternative to UDP, >> without >> the overhead of unwanted UDP fields that get faked up, would seem to >> make more sense here than sort-of-tunnelling in UDP from the endhost >> and then subverting and reconstituting the UDP fields. > > [Pascal] The only fake is that we still call the ISA100.11a transport > UDP though it's not. This is done to reuse It's a pretence, then. (US readers: pretense.) > the IPv6 next header and the > 6LoWPAN HC2 though we know it's improper. right. > The transport is a UDP variant > in that the checksum is computed differently, has additional security > properties and gets placed somewhere else. But the end to end > principle > is respected exactly as with original UDP. But the proposed way to handle the UDP checksum does not respect the e2e UDP checksum, so this really isn't UDP; just a convenient way to stick something else on top, even if that something else has a separate, higher and therefore better, e2e check. >> RFC4944 is about carrying IPv6 across 802.15.4 networks, and >> prohibits >> UDP checksum compression for good reason. Modifying that to allow >> checksum compression might work for IA100.11a if and only if both >> endhosts are sitting on the 802.15.4 network communicating via >> ISA100.11a, and the packet never goes any further - ie you're relying >> solely on the MIC, and the UDP checksum is never used. If the packet >> goes further and a reconstituted UDP checksum is required at the >> endhost for an integrity check - that's the slippery slope where the >> end-to-end principle has many warnings. Applying TLS across the >> 6lowpan part of such a path does not mitigate end-to-end concerns >> here. And, thanks to NAT/relaying etc., it can't be guaranteed that >> the packet will go no further - a slippery slope. > > [Pascal] No. The ISA100.11a transport is end to end as usual in the IP > model; both ends need to be ISA100.11a nodes so that they know how to > terminate the ISA100.11a transport. The IP network in the middle is > transparent and could be the Internet, where the regenerated UDP checksum will be relied on by e.g. NAT boxes, which recompute the checksum again. Ugh. Okay, once NAT's involved the checksums are all messed up and regenerated and not pristine anyway. Not a convincing example. Better example: there's an application sitting on a node on the Internet, pretending to be an ISA100.11a node, and regenerating the UDP checksum so that this application can just use ordinary sockets to talk to a node on a 15.4 net is desirable and inevitable. This will make developing for ISA convenient; it is guaranteed to happen, and has properly happened already. Everything gets virtualized. What happens when the regenerated UDP checksum and the ISA checksum from a packet on the 15.4 net disagree about whether the packet is good? UDP says 'discard, so the app never sees it', but the UDP checksum is no longer really the e2e arbiter here. If ISA sat on IP direct, this would be avoided. > that's the end to end principle. > IPv6 and UDP are compressed over the LoWPAN, that's 6LoWPAN. But the UDP header is no longer being used to provide header and payload protection; it's really just in there for convenience. >>> - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) >> >> TLS was intended and is used simply as a shorthand for transport >> layer >> security - a term you used in the email I was replying to. I don't >> accept that RFC4346 now owns the term. >> >> This quote to you from Geoff Mulligan on 22 May seems relevant and >> applicable here: >> "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." > > [Pascal] ISA100.11a has spent quite some effort doing its work. For > instance, we made sure that the points raised in > draft-ietf-tsvwg-udp-guidelines were all addressed. For the particular > aspect of how we compute the checksum, we pretend it is as good or > better than in the original UDP. Are you challenging that? Yes, I'm challenging that pretence, simply because it is a pretence; thanks for the explanations to this point. I can see how ISA is e2e between ISA nodes thanks to internal consistency/pseudoheader checks; what I can't see is why that UDP header is in there having its semantics munged, when it's only used as a layering hack. Separately, the zero-checksum 'changing something well-known just because we're compensating for it by layering something else on top' idea makes me uncomfortable; the pieces will be reused badly. How long before someone says 'zero-checksum UDP is great, because it's faster, so let's do zero-checksum ISA, as that's faster too', and goes on to rediscover that implementations with UDP checksums off introduce problems? There's willingness to alter RFC2460 and RFC4346 to get a zero checksum here; how will the next group to come along alter existing specs as well? Slippery slope. (I think if ISA sat over UDP-Lite, there would be slightly less of a pretence here, as redundant coverage of the payload from a checksum that's not trustworthy would at least be removed. And there's less data for the Lite checksum to be computed across. But really, ISA over IP direct doing its own pseudoheader check without the UDP fields makes a lot more sense to me.) ISA100.11a should be sitting parallel to TCP/UDP/SCTP, not on top of UDP. Still, never mind; it is, of course, late to change the ISA100 design (but, oddly, not too late to change RFCs 2460 and 4346?) . Feel free to ignore me. cheers, L. and I'll feel free to say "told you so" in a decade or so. DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 11:55:15 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 E8BC93A6A67; Wed, 11 Jun 2008 11:55:15 -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 321473A6913; Tue, 10 Jun 2008 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.639 X-Spam-Level: X-Spam-Status: No, score=-6.639 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 eY3Qb5pwtnAN; Tue, 10 Jun 2008 12:47:48 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with SMTP id C33D33A690C; Tue, 10 Jun 2008 12:47:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-78.messagelabs.com!1213127289!49202653!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 4247 invoked from network); 10 Jun 2008 19:48:09 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-14.tower-78.messagelabs.com with SMTP; 10 Jun 2008 19:48:09 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:48:09 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:48:08 +0100 Message-Id: From: Lloyd Wood To: Carsten Bormann In-Reply-To: <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 20:48:08 +0100 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 19:48:08.0703 (UTC) FILETIME=[E85950F0:01C8CB32] X-Mailman-Approved-At: Wed, 11 Jun 2008 11:55:14 -0700 Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [6lowpan] [Roll] 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 On 10 Jun 2008, at 15:59, Carsten Bormann wrote: > > 2) Given this transport, the end system is likely to want back the > feature of UDPv4 that allowed sending a zero checksum. This transport > is a nice example for how it was a mistake to conflate policy and > mechanism in UDPv6: Encoding the *policy* not to send packets without > a checksum that includes a pseudo-header with the *mechanism* to never > allow zero checksums in UDPv6. Yes, it would have been nicer if the mandatory pseudoheader was part of the IPv6 header, rather than having to be reimplemented by every transport protocol using IPv6, including ICMP. The pseudoheader check is necessary. The payload check is not. That's what UDP-Lite gives. > Of course, you should not have mechanism that a policy makes sure you > will never use, but the mechanism is already there for IPv4, and the > example is exactly one such case where the policy would not imply non- > use of the mechanism. > > Obviously, if an end system does not want protection from UDP (and it > shouldn't want it in the ISA100 case), it should say so by setting the > checksum to zero. No. It should either: a. Use UDP-Lite, to avoid checksum coverage of its payload, and still get a pseudoheader check from UDP. b. Implement its own transport protocol, in parallel with UDP/TCP/ SCTP, with its own pseudoheader check, doing payload coverage however it likes. The endhost pseudoheader check has to come from somewhere. > The mechanism/policy conflation mentioned above > makes that impossible. Not impossible. It comes down to the pain of using UDP-Lite, or the pain of writing your own proper gets-a-protocol-number transport protocol with its own pseudoheader check. Either is better from layering/size/complexity viewpoints than layering over UDP and turning UDP checksums off. > Changing UDPv6 at this stage is a big step. If that is not what we > (the IETF/the IPv6 implementers community) want to do, there is no way > for the end system to make that statement. This does not mean that we > shouldn't honor it. Sorry, I'm unclear on the meaning of your last sentence here; the double negative (triple from the previous sentence) doesn't help. tschuess, L. DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 11:55: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 247103A6A75; Wed, 11 Jun 2008 11:55: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 DBD6328C0F4; Tue, 10 Jun 2008 15:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.631 X-Spam-Level: X-Spam-Status: No, score=-6.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 mH3renz9yDoV; Tue, 10 Jun 2008 15:00:47 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with SMTP id 27A2F28C0E9; Tue, 10 Jun 2008 15:00:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-72.messagelabs.com!1213135267!21733814!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 19762 invoked from network); 10 Jun 2008 22:01:07 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-72.messagelabs.com with SMTP; 10 Jun 2008 22:01:07 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 23:01:07 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 23:01:07 +0100 Message-Id: From: Lloyd Wood To: Carsten Bormann In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 23:01:06 +0100 X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0835 (UTC) FILETIME=[7C483CB0:01C8CB45] X-Mailman-Approved-At: Wed, 11 Jun 2008 11:55:14 -0700 Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [6lowpan] [Roll] 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 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> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> X-Mailer: Apple Mail (2.924) Return-Path: L.Wood@surrey.ac.uk X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0358 (UTC) FILETIME=[7BFF73E0:01C8CB45] inline... On 10 Jun 2008, at 22:50, Carsten Bormann wrote: >> a. Use UDP-Lite, to avoid checksum coverage of its payload, and >> still get a pseudoheader check from UDP. > > How does that help with getting rid of the checksum? > With UDP-lite, you now have two, with different coverage. > >> b. Implement its own transport protocol, in parallel with UDP/TCP/ >> SCTP, with its own pseudoheader check, doing payload coverage >> however it likes. > > That's what they did. No, ISA sits _over_ UDP, not over IP as UDP/TCP/SCTP do. > They want to do this on top of UDP, which is a usual way to build > new transport protocols these days (cf. RTP). No, it's a way to really build more 'session-like' protocols. I wouldn't call RTP a full transport, as it doesn't care about describing length, or about reliability. > If UDPv6 were like UDPv4, this would be a better fit. > >>> The mechanism/policy conflation mentioned above >>> makes that impossible. >> >> Not impossible. It comes down to the pain of using UDP-Lite, or the >> pain of writing your own proper gets-a-protocol-number transport >> protocol with its own pseudoheader check. Either is better from >> layering/size/complexity viewpoints than layering over UDP and >> turning UDP checksums off. > > I don't agree with "better" here. > Being able to use UDP reduces complexity here; certainly from an > implementation point of view (if you consider that there will be > hosts with common operating systems on e.g. Ethernets that want to > talk to lowpans). ...which makes removing the UDP checksum more problematic. >>> Changing UDPv6 at this stage is a big step. If that is not what we >>> (the IETF/the IPv6 implementers community) want to do, there is no >>> way >>> for the end system to make that statement. This does not mean >>> that we >>> shouldn't honor it. >> >> Sorry, I'm unclear on the meaning of your last sentence here; the >> double negative (triple from the previous sentence) doesn't help. > > I'm just saying that, in the first-hop/last-hop case, HC could help > 2460 a little here, just (as you noted) NATs tend to "help" with > maintaining that checksum, They don't "help". Quite the opposite - by recomputing the checksum the value of the end-to-end guarantee offered by the checksum is reduced. HC may save bits on the wire, but it doesn't help overall reliability. HC can't make anything as reliable, or more reliable. > by proxying out the UDP checksum generation/check to the next hop, > as long as there is something else that provides e2e protection. Why fake up a checksum at a proxy unless something is going to use it? And if something does, there are e2e implications. (I doubt that we will ever agree here.) > In the first-hop case, it is easy for the host to make the > statement (by providing a mechanism for eliding the checksum); in > the last-hop case, there would need to be some agreement (implied or > signaled). > > Gruesse, Carsten > DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 11 11:55: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 586FA3A6A98; Wed, 11 Jun 2008 11:55: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 4280D3A6910 for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 01:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC0Ou4gyyBEl for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 01:46:01 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id CA6F23A6886 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 01:46:00 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2113256fga.41 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 01:46:24 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=cZ7/Zd8T0el5sdJBYwQJyHchRZ+Z5erMthPOPlTxMlE=; b=ZFy+v/f8szkP/UnqPrlbkPuKyQfZ8TuDGay6Y9QUnEiitqfqCg0MJ1PYn1I1ygtwBr lJfvoI4dhWSulJD3Q53MyqSOtb3SLAoHdXcfbclFzDlczz29w/4yvBNYGVdvikjn6H99 hGjnYrLQyH3CkED6gH2cYpVf5TwiZzx2hZJZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=XHceCfflK6MRSJGhwpZ5RxDlDK4KHgvypJmv8rGyDohTOhIbXz9+/mmkfUeylZ/fYz KG6WghzlLRD62unWYqoivBjmPHuoPzBR+QdLDjWvewShnXjlS/Jg3Ofco7X7h1VpJZ1b MGbehXPOWsRFxxeFGplGtizBMxCU+ua5jdFbY= Received: by 10.86.33.19 with SMTP id g19mr4276162fgg.4.1213173984383; Wed, 11 Jun 2008 01:46:24 -0700 (PDT) Received: by 10.86.58.6 with HTTP; Wed, 11 Jun 2008 01:46:24 -0700 (PDT) Message-ID: <86c3ed7b0806110146t55234092x24226010ccdfe717@mail.gmail.com> Date: Wed, 11 Jun 2008 10:46:24 +0200 From: "Miguel Sanchez" To: "JP Vasseur" In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 980f9db1541f87a9 X-Mailman-Approved-At: Wed, 11 Jun 2008 11:55:14 -0700 Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org>, roll@ietf.org, Lloyd Wood Subject: Re: [6lowpan] [Roll] 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: multipart/mixed; boundary="===============1665074738==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1665074738== Content-Type: multipart/alternative; boundary="----=_Part_31995_14875486.1213173984368" ------=_Part_31995_14875486.1213173984368 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Please do so. Miguel S=E1nchez On Wed, Jun 11, 2008 at 10:13 AM, JP Vasseur wrote: > I think that the ROLL ML can be removed from this thread. > > Thanks. > > JP. > > > ------=_Part_31995_14875486.1213173984368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Please do so.

Miguel S=E1nchez

On = Wed, Jun 11, 2008 at 10:13 AM, JP Vasseur <jvasseur@cisco.com> wrote:
I think that the ROLL ML can be removed from this thread.

Thanks.

JP.



------=_Part_31995_14875486.1213173984368-- --===============1665074738== 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 --===============1665074738==-- From 6lowpan-bounces@ietf.org Wed Jun 11 12:02: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 37F1F3A6978; Wed, 11 Jun 2008 12:02: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 79D783A6978 for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 12:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, J_CHICKENPOX_21=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 pJvd1kYATr9N for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 12:02:43 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id E61593A67B2 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 12:02:37 -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 m5BJ33dg015769 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 13:03:03 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: multipart/mixed; boundary="=-jW4N8J6GazitI7pc8CF0" Date: Wed, 11 Jun 2008 13:02:58 -0600 Message-Id: <1213210978.5863.16.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [6lowpan] new charter text 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 --=-jW4N8J6GazitI7pc8CF0 Content-Type: text/plain Content-Transfer-Encoding: 7bit After reviewing the comments on the list and talking with Carsten and Mark, we have come up with the following text for the Charter. We hope (and think) that this reflects the input from the group and Mark plans to take this to the IESG for rechartering approval. We've had some excellent discussion on a few topics and this is great. There is no reason why we should stop the discussion and work while Mark handles the rechartering. 1. I think that the work is proceeding on the Security Analysis document 2. We have the current HC1G draft. The issue being discussed is the "compression" of the UDP checksum and it's impact on the end-to-end model. I would like to hear more input and discussion on this. Please speak up if you have thoughts on this. 3. We have some initial input on the Architecture document and I would like to hear from anyone that would volunteer to continue to work on this document. geoff --=-jW4N8J6GazitI7pc8CF0 Content-Disposition: attachment; filename=charter.txt Content-Type: text/plain; name=charter.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 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 such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. As a spin-off from that document, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. Both documents will be informational. 4. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: --------------------- - Aug 2008 - Submit Improved Header Compression document to IESG for consideration as a proposed standard. - Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC. - Sep 2008 - Submit Architecture document(s) to IESG for consideration as an Informational RFC(s) - Nov 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard --=-jW4N8J6GazitI7pc8CF0 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 --=-jW4N8J6GazitI7pc8CF0-- From 6lowpan-bounces@ietf.org Wed Jun 11 18:48: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 F10A13A6843; Wed, 11 Jun 2008 18:48:41 -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 D8E173A6843 for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 18:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=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 XSwPKah+JxJe for <6lowpan@core3.amsl.com>; Wed, 11 Jun 2008 18:48:40 -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 751DF3A67AC for <6lowpan@ietf.org>; Wed, 11 Jun 2008 18:48:39 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1380916tib.25 for <6lowpan@ietf.org>; Wed, 11 Jun 2008 18:49:03 -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=6ApCaVZHvOX0v83rDlQK40FU/me/BfY/fATwkVgWaC4=; b=IRgfum7P4SjUox6OhBHvOuI2hl1iFPPE/Gm8PPF8aydRxRLpglaouZEpBNfnq3ZOpZ HuoPiiBx2vgZJhbkivf/PT6jPfdlyklxglqB/ZpTzabzAB5xrOlKEiSoTtX8Vieym0Ya sBzAxhRFGrKEPqnVqZZMZNTydnRzaGX54TFNA= 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=XfwqQ781pTkwv7NeGHFZKpk16wtx+pnzG5UCrp/iUkX/IzB/3TkwOT/YymYCcQzmFY JSnr/4KRUEprnBbqRYw1L+ym3IRNrD9dMuAZ2hYU1hJfwL+YWSiRP5S+Fxuce7QoELX1 P4Y1Y5W6HgPAV4WDwKgaat3UbrVzFMKturOYo= Received: by 10.110.37.17 with SMTP id k17mr335580tik.13.1213235343306; Wed, 11 Jun 2008 18:49:03 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Wed, 11 Jun 2008 18:49:03 -0700 (PDT) Message-ID: <77f1dba80806111849u682b8d30n6ce5be00b31c7dc1@mail.gmail.com> Date: Thu, 12 Jun 2008 10:49:03 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" In-Reply-To: <1213210978.5863.16.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <1213210978.5863.16.camel@dellx1> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 Geoff, 6LoWPAN use-case was always in the recharter items, and there was no objection on it. Any reason to take it out? Thanks for the good work. -eunah On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: > After reviewing the comments on the list and talking with Carsten and > Mark, we have come up with the following text for the Charter. > > We hope (and think) that this reflects the input from the group and Mark > plans to take this to the IESG for rechartering approval. > > We've had some excellent discussion on a few topics and this is great. > There is no reason why we should stop the discussion and work while Mark > handles the rechartering. > > 1. I think that the work is proceeding on the Security Analysis document > 2. We have the current HC1G draft. The issue being discussed is the > "compression" of the UDP checksum and it's impact on the end-to-end > model. I would like to hear more input and discussion on this. Please > speak up if you have thoughts on this. > 3. We have some initial input on the Architecture document and I would > like to hear from anyone that would volunteer to continue to work on > this document. > > geoff > > > _______________________________________________ > 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 Jun 12 01:10: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 3D1A23A6996; Thu, 12 Jun 2008 01:10: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 44F5D3A69D9 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=-0.098, 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 GV3Zn7vBULzo for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:10:55 -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 64A933A6996 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 01:10:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,630,1204531200"; d="scan'208";a="112246048" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2008 01:11:19 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5C8BJBR030240; Thu, 12 Jun 2008 01:11:19 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5C8BJCn007626; Thu, 12 Jun 2008 08:11:19 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, 12 Jun 2008 04:11:18 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 08:11:18 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 10:11:17 +0200 From: JP Vasseur To: "Eunsook \"Eunah\" Kim" , Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjMY+N18e579t33jk62mv9zfO0Wqg== In-Reply-To: <77f1dba80806111849u682b8d30n6ce5be00b31c7dc1@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 08:11:18.0875 (UTC) FILETIME=[E4935AB0:01C8CC63] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1674; t=1213258279; x=1214122279; 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:=20Re=3A=20[6lowpan]=20new=20charter=20text |Sender:=20; bh=LYF8YCkvnzn+qs+R6PBcMnHOYYMEfCKkI84k24k1kdc=; b=Xt3ZItcF8wYTL9+ywzszrxRHbSzgShgVTfcqU2Ci7vS3t7yBNk561tdKph O0kkn79fy7NU4ESwW207j8kB4H84rfeOgjTU+57pg4zi5WsWJum8VDb4YvIT ZpswSTH+qsJNrNsPqTNmuepathK7NHNCFaulurTOxuW6crtrOAEMQ=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 Same question. On 6/12/08 3:49 AM, "Eunsook "Eunah" Kim" wrote: > Geoff, > > 6LoWPAN use-case was always in the recharter items, and there was no > objection on it. Any reason to take it out? > Thanks for the good work. > > -eunah > > On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: >> After reviewing the comments on the list and talking with Carsten and >> Mark, we have come up with the following text for the Charter. >> >> We hope (and think) that this reflects the input from the group and Mark >> plans to take this to the IESG for rechartering approval. >> >> We've had some excellent discussion on a few topics and this is great. >> There is no reason why we should stop the discussion and work while Mark >> handles the rechartering. >> >> 1. I think that the work is proceeding on the Security Analysis document >> 2. We have the current HC1G draft. The issue being discussed is the >> "compression" of the UDP checksum and it's impact on the end-to-end >> model. I would like to hear more input and discussion on this. Please >> speak up if you have thoughts on this. >> 3. We have some initial input on the Architecture document and I would >> like to hear from anyone that would volunteer to continue to work on >> this document. >> >> geoff >> >> >> _______________________________________________ >> 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 Jun 12 01:17: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 5AA7F3A69DC; Thu, 12 Jun 2008 01:17: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 4103E3A69DC for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=1.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewSZ1wDMtkUx for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:17:20 -0700 (PDT) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id C62EE3A695A for <6lowpan@ietf.org>; Thu, 12 Jun 2008 01:17:19 -0700 (PDT) Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K2C00BG8CCMS4@mailout1.samsung.com> for 6lowpan@ietf.org; Thu, 12 Jun 2008 17:17:10 +0900 (KST) Received: from ep_spt04 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K2C00DJ3CCM2T@ms7.samsung.com> for 6lowpan@ietf.org; Thu, 12 Jun 2008 17:17:10 +0900 (KST) Content-return: prohibited Date: Thu, 12 Jun 2008 08:17:10 +0000 (GMT) From: Daniel Park To: JP Vasseur Message-id: <0K2C00DJ4CCM2T@ms7.samsung.com> MIME-version: 1.0 MIME-version: 1.0 X-Priority: 3 Msgkey: 20080612081219058@soohong.park X-MTR: 20080612081219058@soohong.park X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-Generator: NamoMIME 6.0.0.3 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: soohong.park@samsung.com 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="===============0183391506==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============0183391506== Content-return: prohibited Content-type: text/html; charset=windows-1252 Content-transfer-encoding: base64 PEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9J3RleHQv aHRtbDsgY2hhcnNldD13aW5kb3dzLTEyNTInPgo8dGl0bGU+U2Ftc3VuZyBFbnRlcnByaXNlIFBv cnRhbCBteVNpbmdsZTwvdGl0bGU+CjxzdHlsZT4gUCwgdGQsIGxpIHtmb250LWZhbWlseTpBcmlh bCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7IG1hcmdpbi10b3A6NXB4O21hcmdpbi1ib3R0b206NXB4 O30gYm9keXtmb250LWZhbWlseTpBcmlhbCwgYXJpYWw7IGZvbnQtc2l6ZTo5cHQ7fTwvc3R5bGU+ CjwvSEVBRD48Qk9EWT5IYWhhaGEuLi4NCjxwPiZuYnNwOzwvcD4NCjxwPkkgYXNrZWQgdGhpcyBp c3N1ZSZuYnNwO2ZvciBNYXJrIGF0IFZhbmNvdXZlciAob3IgQ2hpY2FnbykgZWl0aGVyPC9wPg0K PHA+SUVFRSBwdWJsaWNhdGlvbiBvciBJRVRGIFJGQyBwdWJsaWNhdGlvbiBvbiB0aGUgb3BlbiBt aWMuPC9wPg0KPHA+TWFyayB0aGVuIGRpZCBhbnN3ZXIgbWUgZm9yIElFVEYgUkZDIFB1YmxpY2F0 aW9uIGF0IHRoYXQgdGltZS48L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5UaGF0IGlzIG15IG1lbW9y eS4uLjotKTwvcD4NCjxwPiZuYnNwOzwvcD4NCjxwPkRhbmllbCBQYXJrJm5ic3A7PC9wPg0KPGJy Pjxicj4tLS0tLS0tIDxiPk9yaWdpbmFsIE1lc3NhZ2U8L2I+IC0tLS0tLS08YnI+PGI+U2VuZGVy PC9iPiA6IEpQIFZhc3NldXImbHQ7anZhc3NldXJAY2lzY28uY29tJmd0Ozxicj48Yj5EYXRlPC9i PiAgIDogMjAwOC0wNi0xMiAxNzoxMSAoR01UKzA5OjAwKTxicj48Yj5UaXRsZTwvYj4gIDogUmU6 IFs2bG93cGFuXSBuZXcgY2hhcnRlciB0ZXh0PGJyPjxicj5TYW1lJm5ic3A7cXVlc3Rpb24uDQo8 YnI+DQo8YnI+DQo8YnI+T24mbmJzcDs2LzEyLzA4Jm5ic3A7Mzo0OSZuYnNwO0FNLCZuYnNwOyZx dW90O0V1bnNvb2smbmJzcDsmcXVvdDtFdW5haCZxdW90OyZuYnNwO0tpbSZxdW90OyZuYnNwOyZs dDtldW5haC5pZXRmQGdtYWlsLmNvbSZndDsmbmJzcDt3cm90ZToNCjxicj4NCjxicj4mZ3Q7Jm5i c3A7R2VvZmYsDQo8YnI+Jmd0OyZuYnNwOw0KPGJyPiZndDsmbmJzcDs2TG9XUEFOJm5ic3A7dXNl LWNhc2UmbmJzcDt3YXMmbmJzcDthbHdheXMmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3JlY2hhcnRl ciZuYnNwO2l0ZW1zLCZuYnNwO2FuZCZuYnNwO3RoZXJlJm5ic3A7d2FzJm5ic3A7bm8NCjxicj4m Z3Q7Jm5ic3A7b2JqZWN0aW9uJm5ic3A7b24mbmJzcDtpdC4mbmJzcDtBbnkmbmJzcDtyZWFzb24m bmJzcDt0byZuYnNwO3Rha2UmbmJzcDtpdCZuYnNwO291dD8NCjxicj4mZ3Q7Jm5ic3A7VGhhbmtz Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7Z29vZCZuYnNwO3dvcmsuDQo8YnI+Jmd0OyZuYnNwOw0K PGJyPiZndDsmbmJzcDstZXVuYWgNCjxicj4mZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNwO09uJm5i c3A7VGh1LCZuYnNwO0p1biZuYnNwOzEyLCZuYnNwOzIwMDgmbmJzcDthdCZuYnNwOzQ6MDImbmJz cDtBTSwmbmJzcDtHZW9mZiZuYnNwO011bGxpZ2FuJm5ic3A7Jmx0O2lldGYwOEBtdWxsaWdhbi5v cmcmZ3Q7Jm5ic3A7d3JvdGU6DQo8YnI+Jmd0OyZndDsmbmJzcDtBZnRlciZuYnNwO3Jldmlld2lu ZyZuYnNwO3RoZSZuYnNwO2NvbW1lbnRzJm5ic3A7b24mbmJzcDt0aGUmbmJzcDtsaXN0Jm5ic3A7 YW5kJm5ic3A7dGFsa2luZyZuYnNwO3dpdGgmbmJzcDtDYXJzdGVuJm5ic3A7YW5kDQo8YnI+Jmd0 OyZndDsmbmJzcDtNYXJrLCZuYnNwO3dlJm5ic3A7aGF2ZSZuYnNwO2NvbWUmbmJzcDt1cCZuYnNw O3dpdGgmbmJzcDt0aGUmbmJzcDtmb2xsb3dpbmcmbmJzcDt0ZXh0Jm5ic3A7Zm9yJm5ic3A7dGhl Jm5ic3A7Q2hhcnRlci4NCjxicj4mZ3Q7Jmd0OyZuYnNwOw0KPGJyPiZndDsmZ3Q7Jm5ic3A7V2Um bmJzcDtob3BlJm5ic3A7KGFuZCZuYnNwO3RoaW5rKSZuYnNwO3RoYXQmbmJzcDt0aGlzJm5ic3A7 cmVmbGVjdHMmbmJzcDt0aGUmbmJzcDtpbnB1dCZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtncm91 cCZuYnNwO2FuZCZuYnNwO01hcmsNCjxicj4mZ3Q7Jmd0OyZuYnNwO3BsYW5zJm5ic3A7dG8mbmJz cDt0YWtlJm5ic3A7dGhpcyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7SUVTRyZuYnNwO2ZvciZuYnNw O3JlY2hhcnRlcmluZyZuYnNwO2FwcHJvdmFsLg0KPGJyPiZndDsmZ3Q7Jm5ic3A7DQo8YnI+Jmd0 OyZndDsmbmJzcDtXZSYjMzk7dmUmbmJzcDtoYWQmbmJzcDtzb21lJm5ic3A7ZXhjZWxsZW50Jm5i c3A7ZGlzY3Vzc2lvbiZuYnNwO29uJm5ic3A7YSZuYnNwO2ZldyZuYnNwO3RvcGljcyZuYnNwO2Fu ZCZuYnNwO3RoaXMmbmJzcDtpcyZuYnNwO2dyZWF0Lg0KPGJyPiZndDsmZ3Q7Jm5ic3A7VGhlcmUm bmJzcDtpcyZuYnNwO25vJm5ic3A7cmVhc29uJm5ic3A7d2h5Jm5ic3A7d2UmbmJzcDtzaG91bGQm bmJzcDtzdG9wJm5ic3A7dGhlJm5ic3A7ZGlzY3Vzc2lvbiZuYnNwO2FuZCZuYnNwO3dvcmsmbmJz cDt3aGlsZSZuYnNwO01hcmsNCjxicj4mZ3Q7Jmd0OyZuYnNwO2hhbmRsZXMmbmJzcDt0aGUmbmJz cDtyZWNoYXJ0ZXJpbmcuDQo8YnI+Jmd0OyZndDsmbmJzcDsNCjxicj4mZ3Q7Jmd0OyZuYnNwOzEu Jm5ic3A7SSZuYnNwO3RoaW5rJm5ic3A7dGhhdCZuYnNwO3RoZSZuYnNwO3dvcmsmbmJzcDtpcyZu YnNwO3Byb2NlZWRpbmcmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO1NlY3VyaXR5Jm5ic3A7QW5hbHlz aXMmbmJzcDtkb2N1bWVudA0KPGJyPiZndDsmZ3Q7Jm5ic3A7Mi4mbmJzcDtXZSZuYnNwO2hhdmUm bmJzcDt0aGUmbmJzcDtjdXJyZW50Jm5ic3A7SEMxRyZuYnNwO2RyYWZ0LiZuYnNwOyZuYnNwO1Ro ZSZuYnNwO2lzc3VlJm5ic3A7YmVpbmcmbmJzcDtkaXNjdXNzZWQmbmJzcDtpcyZuYnNwO3RoZQ0K PGJyPiZndDsmZ3Q7Jm5ic3A7JnF1b3Q7Y29tcHJlc3Npb24mcXVvdDsmbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO1VEUCZuYnNwO2NoZWNrc3VtJm5ic3A7YW5kJm5ic3A7aXQmIzM5O3MmbmJzcDtpbXBh Y3QmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2VuZC10by1lbmQNCjxicj4mZ3Q7Jmd0OyZuYnNwO21v ZGVsLiZuYnNwOyZuYnNwO0kmbmJzcDt3b3VsZCZuYnNwO2xpa2UmbmJzcDt0byZuYnNwO2hlYXIm bmJzcDttb3JlJm5ic3A7aW5wdXQmbmJzcDthbmQmbmJzcDtkaXNjdXNzaW9uJm5ic3A7b24mbmJz cDt0aGlzLiZuYnNwOyZuYnNwO1BsZWFzZQ0KPGJyPiZndDsmZ3Q7Jm5ic3A7c3BlYWsmbmJzcDt1 cCZuYnNwO2lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3Rob3VnaHRzJm5ic3A7b24mbmJzcDt0 aGlzLg0KPGJyPiZndDsmZ3Q7Jm5ic3A7My4mbmJzcDtXZSZuYnNwO2hhdmUmbmJzcDtzb21lJm5i c3A7aW5pdGlhbCZuYnNwO2lucHV0Jm5ic3A7b24mbmJzcDt0aGUmbmJzcDtBcmNoaXRlY3R1cmUm bmJzcDtkb2N1bWVudCZuYnNwO2FuZCZuYnNwO0kmbmJzcDt3b3VsZA0KPGJyPiZndDsmZ3Q7Jm5i c3A7bGlrZSZuYnNwO3RvJm5ic3A7aGVhciZuYnNwO2Zyb20mbmJzcDthbnlvbmUmbmJzcDt0aGF0 Jm5ic3A7d291bGQmbmJzcDt2b2x1bnRlZXImbmJzcDt0byZuYnNwO2NvbnRpbnVlJm5ic3A7dG8m bmJzcDt3b3JrJm5ic3A7b24NCjxicj4mZ3Q7Jmd0OyZuYnNwO3RoaXMmbmJzcDtkb2N1bWVudC4N Cjxicj4mZ3Q7Jmd0OyZuYnNwOw0KPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Z2VvZmYNCjxicj4mZ3Q7Jmd0OyZuYnNwOw0KPGJyPiZn dDsmZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZndDsmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPGJyPiZndDsmZ3Q7Jm5ic3A7Nmxvd3BhbiZuYnNwO21h aWxpbmcmbmJzcDtsaXN0DQo8YnI+Jmd0OyZndDsmbmJzcDs2bG93cGFuQGlldGYub3JnDQo8YnI+ Jmd0OyZndDsmbmJzcDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dw YW4NCjxicj4mZ3Q7Jmd0OyZuYnNwOw0KPGJyPiZndDsmZ3Q7Jm5ic3A7DQo8YnI+Jmd0OyZuYnNw O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+Jmd0 OyZuYnNwOzZsb3dwYW4mbmJzcDttYWlsaW5nJm5ic3A7bGlzdA0KPGJyPiZndDsmbmJzcDs2bG93 cGFuQGlldGYub3JnDQo8YnI+Jmd0OyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vNmxvd3Bhbg0KPGJyPg0KPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo8YnI+Nmxvd3BhbiZuYnNwO21haWxpbmcmbmJzcDtsaXN0DQo8 YnI+Nmxvd3BhbkBpZXRmLm9yZw0KPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vNmxvd3Bhbg0KPGJyPjxwPiZuYnNwOzwvcD48cD4mbmJzcDs8L3A+PCEtLVNQOnNvb2hv bmcucGFyay0tPjxwPi0tLTwvcD4NCjxwPkRhbmllbCBQYXJrIFthdF0gU0FNU1VORyBFbGVjdHJv bmljcy48L3A+DQo8cD5TdGFuZGFyZCBBcmNoaXRlY3QsIDxhIGhyZWY9Imh0dHA6Ly9ibG9nLm5h dmVyLmNvbS9uYXRwdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9ibG9nLm5hdmVyLmNvbS9uYXRw dDwvYT48L3A+PCEtLXNvb2hvbmcucGFyazpFUC0tPjxwPiZuYnNwOzwvcD48cD4mbmJzcDs8L3A+ PC9CT0RZPjwvSFRNTD4= --===============0183391506== 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 --===============0183391506==-- From 6lowpan-bounces@ietf.org Thu Jun 12 01:42: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 DB73D3A6996; Thu, 12 Jun 2008 01:42: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 982E63A68CC for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 Y4RI8iJB25pg for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:42:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7A4ED3A6878 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 01:42:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,630,1204498800"; d="scan'208";a="11475703" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2008 10:43:04 +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 m5C8h4Dg022868; Thu, 12 Jun 2008 10:43:04 +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 m5C8h4Ik004616; Thu, 12 Jun 2008 08:43:04 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 10:43:04 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 10:43:03 +0200 Message-ID: <4850E195.2050105@cisco.com> Date: Thu, 12 Jun 2008 10:43:01 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: X-OriginalArrivalTime: 12 Jun 2008 08:43:03.0994 (UTC) FILETIME=[541D71A0:01C8CC68] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2240; t=1213260184; x=1214124184; c=relaxed/simple; s=amsdkim2001; 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=20text |Sender:=20; bh=TqDfXS/8bYbjb00XA2Di/hlaTA99TMSNvZL64+WvzdE=; b=sZ1ufVd07jYH18CPOl+XZ3QVvQx4GNkf93BC1dj+Ml3OTPV7i8CD5jPOqy u0EzkLVEgmXxEAYhntlAWeUtG6AJoxO6A79MCstcLK+G0n+0ICLndDREQ/Zt /dLTqah5xh; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 have no problem with the WG having an informational use-case work item in its charter. We have to understand that use-cases cannot cover the entire spectrum of how a protocol may get used, but can provide a general understanding and lay the groundwork for certain boundaries and requirements. - Mark JP Vasseur wrote: > Same question. > > > On 6/12/08 3:49 AM, "Eunsook "Eunah" Kim" wrote: > > >> Geoff, >> >> 6LoWPAN use-case was always in the recharter items, and there was no >> objection on it. Any reason to take it out? >> Thanks for the good work. >> >> -eunah >> >> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: >> >>> After reviewing the comments on the list and talking with Carsten and >>> Mark, we have come up with the following text for the Charter. >>> >>> We hope (and think) that this reflects the input from the group and Mark >>> plans to take this to the IESG for rechartering approval. >>> >>> We've had some excellent discussion on a few topics and this is great. >>> There is no reason why we should stop the discussion and work while Mark >>> handles the rechartering. >>> >>> 1. I think that the work is proceeding on the Security Analysis document >>> 2. We have the current HC1G draft. The issue being discussed is the >>> "compression" of the UDP checksum and it's impact on the end-to-end >>> model. I would like to hear more input and discussion on this. Please >>> speak up if you have thoughts on this. >>> 3. We have some initial input on the Architecture document and I would >>> like to hear from anyone that would volunteer to continue to work on >>> this document. >>> >>> geoff >>> >>> >>> _______________________________________________ >>> 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 Jun 12 01:44: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 7E45E3A688E; Thu, 12 Jun 2008 01:44: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 B0CC03A688E for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 gbHfXb9422uD for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:44:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 286C23A6878 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 01:44:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,630,1204498800"; d="scan'208";a="11475950" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2008 10:44:40 +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 m5C8idRj016991; Thu, 12 Jun 2008 10:44:39 +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 m5C8idVO005311; Thu, 12 Jun 2008 08:44:39 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, 12 Jun 2008 10:44:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 10:43:59 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D164BF@xmb-ams-337.emea.cisco.com> In-Reply-To: <1213210978.5863.16.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjL9hGw1XX9fNTeTXOKsseWBt3I1gAcelTQ References: <1213210978.5863.16.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 12 Jun 2008 08:44:39.0745 (UTC) FILETIME=[8D2FE310:01C8CC68] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1519; t=1213260279; x=1214124279; 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=20text |Sender:=20; bh=wAHQQXEcvC6bX7CKsRRieC4n/ZYGbndOjDIBJaAsGxc=; b=rzFPGJFITNNf36zuvirm1Z37bEfNFOIg38yfZZMjGHZXDKPZ9EzFnMv5wA 65QVFjg8o82HXRSUlssd+gXjTHnqKlAeqq/o945gXvw39THqjKzX4bm5mPfm rCjzKiKZQ+; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [6lowpan] new charter text 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: There was a clear support for the group on my proposal from May 30th. Now you took out: - 6LoWPAN use-case as Eunah points out - and the larger work on improving 6LowPAN operation (fragment recovery and whatelse) You need to explain why. There is advanced work on both and people willing to do the job. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan >Sent: mercredi 11 juin 2008 21:03 >To: 6lowpan >Subject: [6lowpan] new charter text > >After reviewing the comments on the list and talking with Carsten and >Mark, we have come up with the following text for the Charter. > >We hope (and think) that this reflects the input from the group and Mark >plans to take this to the IESG for rechartering approval. > >We've had some excellent discussion on a few topics and this is great. >There is no reason why we should stop the discussion and work while Mark >handles the rechartering. > >1. I think that the work is proceeding on the Security Analysis document >2. We have the current HC1G draft. The issue being discussed is the >"compression" of the UDP checksum and it's impact on the end-to-end >model. I would like to hear more input and discussion on this. Please >speak up if you have thoughts on this. >3. We have some initial input on the Architecture document and I would >like to hear from anyone that would volunteer to continue to work on >this document. > > geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 12 01:45: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 3A9E93A69DC; Thu, 12 Jun 2008 01:45:30 -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 43C093A6996 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.084 X-Spam-Level: X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 x-lNAgPRdTgy for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 01:45:08 -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 9FD5C3A688E for <6lowpan@ietf.org>; Thu, 12 Jun 2008 01:45:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,630,1204520400"; d="scan'208";a="10816680" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2008 04:45:34 -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 m5C8jYkd032569; Thu, 12 Jun 2008 04:45:34 -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 m5C8jYTU022915; Thu, 12 Jun 2008 08:45:34 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, 12 Jun 2008 04:45:34 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 08:45:34 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 10:45:31 +0200 From: JP Vasseur To: Mark Townsley Message-ID: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjMaKu8Ive316+LTk+VGtMs6eAJEQ== In-Reply-To: <4850E195.2050105@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 08:45:34.0440 (UTC) FILETIME=[ADC9AE80:01C8CC68] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2500; t=1213260334; x=1214124334; 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=20text |Sender:=20 |To:=20Mark=20Townsley=20; bh=ga8TUH8ukMYLXRGMuhPfN9jhD7bGx/U9YLtlJyEv8nY=; b=J8qGTSkC/iMNBbQoSV2w4q9O+Y6+v2Ur6n7KXb92chGnIpAt9L755ex6NB 71uZzdv9nToJwiwO88DI1AJl+uG8Pr0ifKjUgBBVgAQUVlBpTjxH7SQ0yXEe Z5IQ3FdWcI; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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're in sync, this is exactly in the spirit of the existing ID. Thanks. Cheers. JP. On 6/12/08 10:43 AM, "Mark Townsley" wrote: > > I have no problem with the WG having an informational use-case work item > in its charter. We have to understand that use-cases cannot cover the > entire spectrum of how a protocol may get used, but can provide a > general understanding and lay the groundwork for certain boundaries and > requirements. > > - Mark > > JP Vasseur wrote: >> Same question. >> >> >> On 6/12/08 3:49 AM, "Eunsook "Eunah" Kim" wrote: >> >> >>> Geoff, >>> >>> 6LoWPAN use-case was always in the recharter items, and there was no >>> objection on it. Any reason to take it out? >>> Thanks for the good work. >>> >>> -eunah >>> >>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: >>> >>>> After reviewing the comments on the list and talking with Carsten and >>>> Mark, we have come up with the following text for the Charter. >>>> >>>> We hope (and think) that this reflects the input from the group and Mark >>>> plans to take this to the IESG for rechartering approval. >>>> >>>> We've had some excellent discussion on a few topics and this is great. >>>> There is no reason why we should stop the discussion and work while Mark >>>> handles the rechartering. >>>> >>>> 1. I think that the work is proceeding on the Security Analysis document >>>> 2. We have the current HC1G draft. The issue being discussed is the >>>> "compression" of the UDP checksum and it's impact on the end-to-end >>>> model. I would like to hear more input and discussion on this. Please >>>> speak up if you have thoughts on this. >>>> 3. We have some initial input on the Architecture document and I would >>>> like to hear from anyone that would volunteer to continue to work on >>>> this document. >>>> >>>> geoff >>>> >>>> >>>> _______________________________________________ >>>> 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 Jun 12 02:18: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 E20223A697D; Thu, 12 Jun 2008 02:18: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 6AE6C3A697D for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 02:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 lsCWem2TdpAO for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 02:18:03 -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 D2E2D3A69EC for <6lowpan@ietf.org>; Thu, 12 Jun 2008 02:18:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,630,1204498800"; d="scan'208";a="11480946" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2008 11:18:27 +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 m5C9IROZ029401 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 11:18:27 +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 m5C9IRYI021212 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 09:18:27 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, 12 Jun 2008 11:18:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 11:17:51 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D16508@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for the new LOWPAN_NHC Thread-Index: AcjMbTBb6tiUokHfQXO7DxYgEGVWKw== From: "Pascal Thubert (pthubert)" To: "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 12 Jun 2008 09:18:27.0482 (UTC) FILETIME=[45CFFFA0:01C8CC6D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3423; t=1213262307; x=1214126307; 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:=20Proposal=20for=20the=20new=20LOWPAN_NHC |Sender:=20; bh=lyRy1scy7BS6oujAd6k1ahVsUcE+sEPjisMIX5b8PjE=; b=Vy7TGzI/6U3waBZdqmzsEv2i5YG8TnbhewtqR2bSrUARZ3kckoRN1naS2v pqBjlbL7dhxOOmeRUQqGnMtl14ohXH13SUCHyz4MvvIKC337QDi0FL0+QL8K 02mzmMj3LG; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [6lowpan] Proposal for the new LOWPAN_NHC 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: It seems that we are in a semantic loop WRT to the UDP checksum compression. For instance, ISA100 transport has all the required properties but since it computes its MIC diffently then it is not really UDP as defined but a derivative with equivalent or better properties. So maybe we need to convey that difference in the 6LoWPAN header compression to break the tie. Here's a proposal for doing so, based on Jonathan's latest draft: The idea here is to keep the spirit of Jonathan's compression but move UDP to the right because we know we do not need more bits for UDP as we know it though other transports might. For real UDP 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 1 | 1 | 0 | S | D | +---+---+---+---+---+---+---+---+ For protocols that are use UDP header format but can compress the checksum 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 1 | 1 | 0 | C | S | D | +---+---+---+---+---+---+---+---+ Current text: " This document defines a compression format for UDP headers using LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 7. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |ID | S | D | C | rsv | +---+---+---+---+---+---+---+---+ Figure 7: Compressed IPv6 Multicast Address Encoding Hui Expires September 11, 2008 [Page 9] Internet-Draft 6LoWPAN Compression of IPv6 Datagrams March 2008 ID: Identifier (bit 0): 0: Identities an IPv6 Next Header value of 17 and the LOWPAN_UDP compression format. 1: Identifies an IPv6 Next Header value other than 17, the following bits are used to identify the particular Next Header value and compression format. The bit-patterns for other Next Header values are left undefined in this document. S: Source Port (bit 1): 0: All 16 bits of Source Port are carried in-line. 1: First 12 bits of Source Port are elided and the remaining 4 bits are carried in-line. The Source Port is recovered by: P + short_port, where P is 61616 (0xF0B0). D: Destination Port (bit 2): 0: All 16 bits of Destination Port are carried in-line. 1: First 12 bits of Destination Port are elided and the remaining 4 bits are carried in-line. The Destination Port is recovered by: P + short_port, where P is 61616 (0xF0B0). C: Checksum (bit 3): 0: All 16 bits of Checksum are carried in-line. The Checksum MUST be included if there are no other end-to-end integrity checks that are stronger than what is provided by the UDP checksum. Such an integrity check MUST be end-to-end and cover the IPv6 pseudo-header, UDP header, and UDP payload. 1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it. rsv: Reserved (bits 4-7). " Jonathan: pls note the wrong text in the figure description What do you think? Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 12 05:38:14 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 4696F3A6A1C; Thu, 12 Jun 2008 05:38:14 -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 92A623A6A04 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 05:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599, J_CHICKENPOX_21=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 OftdC2ieJl5K for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 05:38:12 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id B40FF3A6927 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 05:38: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 m5CCcXSq025543; Thu, 12 Jun 2008 06:38:33 -0600 (MDT) From: Geoff Mulligan To: "Eunsook \"Eunah\" Kim" In-Reply-To: <77f1dba80806111849u682b8d30n6ce5be00b31c7dc1@mail.gmail.com> References: <1213210978.5863.16.camel@dellx1> <77f1dba80806111849u682b8d30n6ce5be00b31c7dc1@mail.gmail.com> Date: Thu, 12 Jun 2008 06:38:36 -0600 Message-Id: <1213274316.17581.11.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 It didn't seem to be a priority item. Perhaps we should consider incorporating the Use Cases into the architecture document. If not then I think once we complete the few documents we should then revisit the use cases. geoff On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > Geoff, > > 6LoWPAN use-case was always in the recharter items, and there was no > objection on it. Any reason to take it out? > Thanks for the good work. > > -eunah > > On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: > > After reviewing the comments on the list and talking with Carsten and > > Mark, we have come up with the following text for the Charter. > > > > We hope (and think) that this reflects the input from the group and Mark > > plans to take this to the IESG for rechartering approval. > > > > We've had some excellent discussion on a few topics and this is great. > > There is no reason why we should stop the discussion and work while Mark > > handles the rechartering. > > > > 1. I think that the work is proceeding on the Security Analysis document > > 2. We have the current HC1G draft. The issue being discussed is the > > "compression" of the UDP checksum and it's impact on the end-to-end > > model. I would like to hear more input and discussion on this. Please > > speak up if you have thoughts on this. > > 3. We have some initial input on the Architecture document and I would > > like to hear from anyone that would volunteer to continue to work on > > this document. > > > > geoff > > > > > > _______________________________________________ > > 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 Jun 12 06:58:14 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 754C93A6AC7; Thu, 12 Jun 2008 06:58:14 -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 7A1303A6AC7 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 06:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.083 X-Spam-Level: X-Spam-Status: No, score=-6.083 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 sPSyfNgo-0F7 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 06:58: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 412573A6AAA for <6lowpan@ietf.org>; Thu, 12 Jun 2008 06:58:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,631,1204498800"; d="scan'208";a="11521488" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2008 15:58: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 m5CDwZTW007407; Thu, 12 Jun 2008 15:58:35 +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 m5CDwZRO004309; Thu, 12 Jun 2008 13:58:35 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 15:58:35 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 15:58:35 +0200 Message-ID: <48512B89.2040005@cisco.com> Date: Thu, 12 Jun 2008 15:58:33 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <1213210978.5863.16.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D164BF@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05D164BF@xmb-ams-337.emea.cisco.com> X-OriginalArrivalTime: 12 Jun 2008 13:58:35.0296 (UTC) FILETIME=[680CE200:01C8CC94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1951; t=1213279115; x=1214143115; c=relaxed/simple; s=amsdkim2001; 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=20text |Sender:=20; bh=E4YamPu+obNMdMlmNckXa4gK5kf3S8OuH/5dAtMfFRg=; b=D9OJ2+HYmrkkWoVo/BxX4kyCuOZUmVwOIzsD2Jdd1FnLVfmlAvzFLQlsAy jyFy6qXVJ1E4/JLA/fsVxpTbTFmqb0SkOEYSNGDqt3VnXe5TDKImttActN+m /avRhR5p1Y; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 Geoff: > > There was a clear support for the group on my proposal from May 30th. > I agree. My read of the list was that there was support for your proposal. - Mark > Now you took out: > - 6LoWPAN use-case as Eunah points out > - and the larger work on improving 6LowPAN operation (fragment recovery > and whatelse) > > You need to explain why. There is advanced work on both and people > willing to do the job. > > Pascal > > >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> > Behalf Of Geoff Mulligan > >> Sent: mercredi 11 juin 2008 21:03 >> To: 6lowpan >> Subject: [6lowpan] new charter text >> >> After reviewing the comments on the list and talking with Carsten and >> Mark, we have come up with the following text for the Charter. >> >> We hope (and think) that this reflects the input from the group and >> > Mark > >> plans to take this to the IESG for rechartering approval. >> >> We've had some excellent discussion on a few topics and this is great. >> There is no reason why we should stop the discussion and work while >> > Mark > >> handles the rechartering. >> >> 1. I think that the work is proceeding on the Security Analysis >> > document > >> 2. We have the current HC1G draft. The issue being discussed is the >> "compression" of the UDP checksum and it's impact on the end-to-end >> model. I would like to hear more input and discussion on this. Please >> speak up if you have thoughts on this. >> 3. We have some initial input on the Architecture document and I would >> like to hear from anyone that would volunteer to continue to work on >> this document. >> >> geoff >> > > _______________________________________________ > 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 Jun 12 07:06:35 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 CE67828C127; Thu, 12 Jun 2008 07:06:35 -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 E21753A68D9 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 07:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 Ktw1byo6f-kg for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 07:06:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DC6E93A6AE3 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 07:06:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,631,1204498800"; d="scan'208";a="11522682" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Jun 2008 16:06:56 +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 m5CE6uep003960; Thu, 12 Jun 2008 16:06:56 +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 m5CE6uvN008272; Thu, 12 Jun 2008 14:06:56 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 16:06:56 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 16:06:54 +0200 Message-ID: <48512D7C.3000202@cisco.com> Date: Thu, 12 Jun 2008 16:06:52 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan References: <1213210978.5863.16.camel@dellx1> <77f1dba80806111849u682b8d30n6ce5be00b31c7dc1@mail.gmail.com> <1213274316.17581.11.camel@dellx1> In-Reply-To: <1213274316.17581.11.camel@dellx1> X-OriginalArrivalTime: 12 Jun 2008 14:06:54.0764 (UTC) FILETIME=[91C1A6C0:01C8CC95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2847; t=1213279616; x=1214143616; c=relaxed/simple; s=amsdkim1002; 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=20text |Sender:=20; bh=4wBL+FMocvFkWuHmw+1aGOiBnAzyJA3bS0ZCAdmvMc0=; b=ZYclv4KScIluO5mtl0pMpZC2qEgwrXzokv/K/PTYttsAGsz+4GQIP2FPyH G8lTDO1OJoBuWLJyqXRH1dyabP3OR7bLioM4OcRJFtpRdU3dGDk5qGMFrI/0 mxBS50l8iJ; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 Geoff Mulligan wrote: > It didn't seem to be a priority item. > > Perhaps we should consider incorporating the Use Cases into the > architecture document. Whether the use-cases are in the arch document or separate is somewhat orthogonal to whether they are chartered work right now. > If not then I think once we complete the few > documents we should then revisit the use cases. > I a missing why writing down use-cases is not a good thing to do sooner rather than later. I don't think it should stop protocol work in its tracks, but I see no indication right now that it would. As long as the use-cases are considered informational and can run largely in parallel* to the normative work at this stage, I don't know why we wouldn't pursue it. - Mark *If this were the very beginnings of 6lowpan, I would insist on use-cases to help drive requirements, architecture, and finally solution design. While we are somewhat past that stage, I do think they could still be very useful to ROLL, as well as going forward as we continue to debate the pros and cons of various optimizations. > geoff > > > On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > >> Geoff, >> >> 6LoWPAN use-case was always in the recharter items, and there was no >> objection on it. Any reason to take it out? >> Thanks for the good work. >> >> -eunah >> >> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: >> >>> After reviewing the comments on the list and talking with Carsten and >>> Mark, we have come up with the following text for the Charter. >>> >>> We hope (and think) that this reflects the input from the group and Mark >>> plans to take this to the IESG for rechartering approval. >>> >>> We've had some excellent discussion on a few topics and this is great. >>> There is no reason why we should stop the discussion and work while Mark >>> handles the rechartering. >>> >>> 1. I think that the work is proceeding on the Security Analysis document >>> 2. We have the current HC1G draft. The issue being discussed is the >>> "compression" of the UDP checksum and it's impact on the end-to-end >>> model. I would like to hear more input and discussion on this. Please >>> speak up if you have thoughts on this. >>> 3. We have some initial input on the Architecture document and I would >>> like to hear from anyone that would volunteer to continue to work on >>> this document. >>> >>> geoff >>> >>> >>> _______________________________________________ >>> 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 Jun 12 07:49:29 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 BDEB23A6AFE; Thu, 12 Jun 2008 07:49: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 7B29D3A6AFE for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 07:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, J_CHICKENPOX_21=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 zkjPl1s6Wl3Q for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 07:49:24 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id D909B3A6AF4 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 07:49: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 m5CEnk27026732; Thu, 12 Jun 2008 08:49:46 -0600 (MDT) From: Geoff Mulligan To: Mark Townsley In-Reply-To: <48512D7C.3000202@cisco.com> References: <1213210978.5863.16.camel@dellx1> <77f1dba80806111849u682b8d30n6ce5be00b31c7dc1@mail.gmail.com> <1213274316.17581.11.camel@dellx1> <48512D7C.3000202@cisco.com> Date: Thu, 12 Jun 2008 08:49:41 -0600 Message-Id: <1213282181.17581.32.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 It was clear that items: 1(ND), 3(Architecture) and 5(Security) were priority items. It was less clear to the three of us that use cases were a priority item. It sounds like we have people that would like to continue to work on the use cases and that completing them in parallel to the other efforts would be a "good thing". What schedule do the authors anticipate completing the document? geoff On Thu, 2008-06-12 at 16:06 +0200, Mark Townsley wrote: > Geoff Mulligan wrote: > > It didn't seem to be a priority item. > > > > Perhaps we should consider incorporating the Use Cases into the > > architecture document. > Whether the use-cases are in the arch document or separate is somewhat > orthogonal to whether they are chartered work right now. > > If not then I think once we complete the few > > documents we should then revisit the use cases. > > > I a missing why writing down use-cases is not a good thing to do sooner > rather than later. I don't think it should stop protocol work in its > tracks, but I see no indication right now that it would. As long as the > use-cases are considered informational and can run largely in parallel* > to the normative work at this stage, I don't know why we wouldn't pursue it. > > - Mark > > *If this were the very beginnings of 6lowpan, I would insist on > use-cases to help drive requirements, architecture, and finally solution > design. While we are somewhat past that stage, I do think they could > still be very useful to ROLL, as well as going forward as we continue to > debate the pros and cons of various optimizations. > > geoff > > > > > > On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > > > >> Geoff, > >> > >> 6LoWPAN use-case was always in the recharter items, and there was no > >> objection on it. Any reason to take it out? > >> Thanks for the good work. > >> > >> -eunah > >> > >> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: > >> > >>> After reviewing the comments on the list and talking with Carsten and > >>> Mark, we have come up with the following text for the Charter. > >>> > >>> We hope (and think) that this reflects the input from the group and Mark > >>> plans to take this to the IESG for rechartering approval. > >>> > >>> We've had some excellent discussion on a few topics and this is great. > >>> There is no reason why we should stop the discussion and work while Mark > >>> handles the rechartering. > >>> > >>> 1. I think that the work is proceeding on the Security Analysis document > >>> 2. We have the current HC1G draft. The issue being discussed is the > >>> "compression" of the UDP checksum and it's impact on the end-to-end > >>> model. I would like to hear more input and discussion on this. Please > >>> speak up if you have thoughts on this. > >>> 3. We have some initial input on the Architecture document and I would > >>> like to hear from anyone that would volunteer to continue to work on > >>> this document. > >>> > >>> geoff > >>> > >>> > >>> _______________________________________________ > >>> 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 Jun 12 10:48:15 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 D30E83A6917; Thu, 12 Jun 2008 10:48:15 -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 F3E883A68D7 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=-0.080, 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 AlhOwHLYwy-L for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:48:13 -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 C15793A6917 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 10:48:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,632,1204531200"; d="scan'208";a="56401032" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2008 10:48:42 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m5CHmggE006004; Thu, 12 Jun 2008 10:48:42 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5CHme9F026715; Thu, 12 Jun 2008 17:48:41 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, 12 Jun 2008 13:48:40 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 17:48:39 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 19:48:36 +0200 From: JP Vasseur To: Geoff Mulligan , "Eunsook \"Eunah\" Kim" Message-ID: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjMtInpQ8nTiCqaoES6WEM5dPZ70w== In-Reply-To: <1213274316.17581.11.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 17:48:40.0228 (UTC) FILETIME=[8C6E5640:01C8CCB4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2254; t=1213292922; x=1214156922; c=relaxed/simple; s=sjdkim4002; 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=20text |Sender:=20; bh=1K/srIMW4k8J83Cj4ckzAyafOQPlgBQpH7UuuOiZ7zI=; b=GoC2yvALu2kTHwqlLoTXPQu/aTq1ulPUjx1ofh0QEsu7xmUv3hRZRBaKwa O8EvQgElyOFzNi48HGrwKW9vDK/CSMhKcwjj58RZp+wsXZvZ3G9jrogonyQF Vup58fIUyY; Authentication-Results: sj-dkim-4; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 6/12/08 2:38 PM, "Geoff Mulligan" wrote: > It didn't seem to be a priority item. > > Perhaps we should consider incorporating the Use Cases into the > architecture document. Heu ? I do not think that it belongs there though ... If not then I think once we complete the few > documents we should then revisit the use cases. Not sure to understand ... Why not adding this item now in addition to the fragment recovery item since there was a consensus (if OK with Mark) ? Thanks. JP. > > geoff > > > On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: >> Geoff, >> >> 6LoWPAN use-case was always in the recharter items, and there was no >> objection on it. Any reason to take it out? >> Thanks for the good work. >> >> -eunah >> >> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: >>> After reviewing the comments on the list and talking with Carsten and >>> Mark, we have come up with the following text for the Charter. >>> >>> We hope (and think) that this reflects the input from the group and Mark >>> plans to take this to the IESG for rechartering approval. >>> >>> We've had some excellent discussion on a few topics and this is great. >>> There is no reason why we should stop the discussion and work while Mark >>> handles the rechartering. >>> >>> 1. I think that the work is proceeding on the Security Analysis document >>> 2. We have the current HC1G draft. The issue being discussed is the >>> "compression" of the UDP checksum and it's impact on the end-to-end >>> model. I would like to hear more input and discussion on this. Please >>> speak up if you have thoughts on this. >>> 3. We have some initial input on the Architecture document and I would >>> like to hear from anyone that would volunteer to continue to work on >>> this document. >>> >>> geoff >>> >>> >>> _______________________________________________ >>> 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 Jun 12 10: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 D21F728C11A; Thu, 12 Jun 2008 10: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 C181D3A6A7F for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 Ad+MsqrpaOR3 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:49:48 -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 653613A695A for <6lowpan@ietf.org>; Thu, 12 Jun 2008 10:49:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,632,1204531200"; d="scan'208";a="56401808" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2008 10:50:17 -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 m5CHoHkM026350; Thu, 12 Jun 2008 10:50:17 -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 m5CHoAZi026250; Thu, 12 Jun 2008 17:50:17 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, 12 Jun 2008 13:50:14 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 17:50:14 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 19:50:11 +0200 From: JP Vasseur To: Mark Townsley , Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjMtMKJsoH3Y8JI00ul1cLGuLr4dQ== In-Reply-To: <48512D7C.3000202@cisco.com> Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 17:50:14.0560 (UTC) FILETIME=[C4A84200:01C8CCB4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3303; t=1213293017; x=1214157017; 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=20text |Sender:=20; bh=ukcVU8zFnChBvNpY/QKvqCrFi4Ah50z17DlvNVwfNzE=; b=mMivkVJOWSkVz+SSnXrkTpF9DZzMntO4fMPIXZRxMHhpANXenvvWVbXgUZ XmY5aQJek9tFtL/XDeNWOvLkk8Y366GtYszIk8FDLLpKMBS/JnH0ROlGei4U qZU83CD4MO; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 6/12/08 4:06 PM, "Mark Townsley" wrote: > Geoff Mulligan wrote: >> It didn't seem to be a priority item. >> >> Perhaps we should consider incorporating the Use Cases into the >> architecture document. > Whether the use-cases are in the arch document or separate is somewhat > orthogonal to whether they are chartered work right now. >> If not then I think once we complete the few >> documents we should then revisit the use cases. >> > I a missing why writing down use-cases is not a good thing to do sooner > rather than later. I don't think it should stop protocol work in its > tracks, but I see no indication right now that it would. As long as the > use-cases are considered informational and can run largely in parallel* > to the normative work at this stage, I don't know why we wouldn't pursue it. > > - Mark > > *If this were the very beginnings of 6lowpan, I would insist on > use-cases to help drive requirements, architecture, and finally solution > design. While we are somewhat past that stage, I do think they could > still be very useful to ROLL, as well as going forward as we continue to > debate the pros and cons of various optimizations. Absolutely ! The only (but useful) objective is to document 6lowpan application, informational ID of course. Thanks. JP. >> geoff >> >> >> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: >> >>> Geoff, >>> >>> 6LoWPAN use-case was always in the recharter items, and there was no >>> objection on it. Any reason to take it out? >>> Thanks for the good work. >>> >>> -eunah >>> >>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: >>> >>>> After reviewing the comments on the list and talking with Carsten and >>>> Mark, we have come up with the following text for the Charter. >>>> >>>> We hope (and think) that this reflects the input from the group and Mark >>>> plans to take this to the IESG for rechartering approval. >>>> >>>> We've had some excellent discussion on a few topics and this is great. >>>> There is no reason why we should stop the discussion and work while Mark >>>> handles the rechartering. >>>> >>>> 1. I think that the work is proceeding on the Security Analysis document >>>> 2. We have the current HC1G draft. The issue being discussed is the >>>> "compression" of the UDP checksum and it's impact on the end-to-end >>>> model. I would like to hear more input and discussion on this. Please >>>> speak up if you have thoughts on this. >>>> 3. We have some initial input on the Architecture document and I would >>>> like to hear from anyone that would volunteer to continue to work on >>>> this document. >>>> >>>> geoff >>>> >>>> >>>> _______________________________________________ >>>> 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 Jun 12 10: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 5D5543A6830; Thu, 12 Jun 2008 10:52:30 -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 14BE43A6830 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.07 X-Spam-Level: X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 ZKnrR0+3T8EY for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:52:28 -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 0268F3A6784 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 10:52:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,632,1204531200"; d="scan'208";a="112479963" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2008 10:52:55 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5CHqtnL007783; Thu, 12 Jun 2008 10:52:55 -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 m5CHqsle029164; Thu, 12 Jun 2008 17:52:55 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, 12 Jun 2008 13:52:54 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 17:52:54 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 19:52:52 +0200 From: JP Vasseur To: Geoff Mulligan , Mark Townsley Message-ID: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjMtSJ/pt11mcFNUUmui+mMr5CG2Q== In-Reply-To: <1213282181.17581.32.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 17:52:54.0531 (UTC) FILETIME=[2401E530:01C8CCB5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4015; t=1213293175; x=1214157175; 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:=20Re=3A=20[6lowpan]=20new=20charter=20text |Sender:=20; bh=HRcMyIQ75pcu7LZ6ctBTeEaoCRQBofYgz+G8w9Ntwig=; b=B5ZiZzy9oTkVe6dPavc+90V5CgWVHhabvBp9bKysSLquiVlWJb0ag9tvtk DPWGhBTyYs6iwGObGh5jv13GlG+HOiYDjC2olsUbTul/zyWZfZhz2JfmGNHy p4cycQcy/n00hOYcoMObW2slVqlq2HqyGBna/zikG0xi1RmB2ZfiA=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 6/12/08 4:49 PM, "Geoff Mulligan" wrote: > It was clear that items: 1(ND), 3(Architecture) and 5(Security) were > priority items. It was less clear to the three of us that use cases > were a priority item. > > It sounds like we have people that would like to continue to work on the > use cases and that completing them in parallel to the other efforts > would be a "good thing". > > What schedule do the authors anticipate completing the document? Well hopefully you do not require to terminate the document before it becomes a WG item ;-) To answer your question, it is already the second revision, the third revision will be posted before Dublin and we'll be having a fairly stable ID. Thanks. JP. > > geoff > > On Thu, 2008-06-12 at 16:06 +0200, Mark Townsley wrote: >> Geoff Mulligan wrote: >>> It didn't seem to be a priority item. >>> >>> Perhaps we should consider incorporating the Use Cases into the >>> architecture document. >> Whether the use-cases are in the arch document or separate is somewhat >> orthogonal to whether they are chartered work right now. >>> If not then I think once we complete the few >>> documents we should then revisit the use cases. >>> >> I a missing why writing down use-cases is not a good thing to do sooner >> rather than later. I don't think it should stop protocol work in its >> tracks, but I see no indication right now that it would. As long as the >> use-cases are considered informational and can run largely in parallel* >> to the normative work at this stage, I don't know why we wouldn't pursue it. >> >> - Mark >> >> *If this were the very beginnings of 6lowpan, I would insist on >> use-cases to help drive requirements, architecture, and finally solution >> design. While we are somewhat past that stage, I do think they could >> still be very useful to ROLL, as well as going forward as we continue to >> debate the pros and cons of various optimizations. >>> geoff >>> >>> >>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: >>> >>>> Geoff, >>>> >>>> 6LoWPAN use-case was always in the recharter items, and there was no >>>> objection on it. Any reason to take it out? >>>> Thanks for the good work. >>>> >>>> -eunah >>>> >>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan >>>> wrote: >>>> >>>>> After reviewing the comments on the list and talking with Carsten and >>>>> Mark, we have come up with the following text for the Charter. >>>>> >>>>> We hope (and think) that this reflects the input from the group and Mark >>>>> plans to take this to the IESG for rechartering approval. >>>>> >>>>> We've had some excellent discussion on a few topics and this is great. >>>>> There is no reason why we should stop the discussion and work while Mark >>>>> handles the rechartering. >>>>> >>>>> 1. I think that the work is proceeding on the Security Analysis document >>>>> 2. We have the current HC1G draft. The issue being discussed is the >>>>> "compression" of the UDP checksum and it's impact on the end-to-end >>>>> model. I would like to hear more input and discussion on this. Please >>>>> speak up if you have thoughts on this. >>>>> 3. We have some initial input on the Architecture document and I would >>>>> like to hear from anyone that would volunteer to continue to work on >>>>> this document. >>>>> >>>>> geoff >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Jun 12 10:59:10 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 B74483A6834; Thu, 12 Jun 2008 10:59:10 -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 F020A3A6830 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, J_CHICKENPOX_21=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 cLrkvGHhjnHK for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 10:59:08 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id EEDC53A67AE for <6lowpan@ietf.org>; Thu, 12 Jun 2008 10:59:07 -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 m5CHxLJP028279; Thu, 12 Jun 2008 11:59:22 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Thu, 12 Jun 2008 11:59:18 -0600 Message-Id: <1213293558.19399.16.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 Please do not misunderstand my/our intentions. In reading the various messages about the rechartering, it did not appear to us as though the use-case was a priority item - not that it was not useful or would not be useful, just not a priority. That was the only reason it was left off of the charter. It was very clear that ND, Arch, and Security were at the top of the list. I am not at all against continuing with the use-case ID in parallel to the rest of the documents. I think that it is and could be useful. I will add it back to charter text, but please let me know a date that we can plan to have the ID completed. geoff On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: > Hi Mark, > > > On 6/12/08 4:06 PM, "Mark Townsley" wrote: > > > Geoff Mulligan wrote: > >> It didn't seem to be a priority item. > >> > >> Perhaps we should consider incorporating the Use Cases into the > >> architecture document. > > Whether the use-cases are in the arch document or separate is somewhat > > orthogonal to whether they are chartered work right now. > >> If not then I think once we complete the few > >> documents we should then revisit the use cases. > >> > > I a missing why writing down use-cases is not a good thing to do sooner > > rather than later. I don't think it should stop protocol work in its > > tracks, but I see no indication right now that it would. As long as the > > use-cases are considered informational and can run largely in parallel* > > to the normative work at this stage, I don't know why we wouldn't pursue it. > > > > - Mark > > > > *If this were the very beginnings of 6lowpan, I would insist on > > use-cases to help drive requirements, architecture, and finally solution > > design. While we are somewhat past that stage, I do think they could > > still be very useful to ROLL, as well as going forward as we continue to > > debate the pros and cons of various optimizations. > > Absolutely ! The only (but useful) objective is to document 6lowpan > application, informational ID of course. > > Thanks. > > JP. > > >> geoff > >> > >> > >> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > >> > >>> Geoff, > >>> > >>> 6LoWPAN use-case was always in the recharter items, and there was no > >>> objection on it. Any reason to take it out? > >>> Thanks for the good work. > >>> > >>> -eunah > >>> > >>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan wrote: > >>> > >>>> After reviewing the comments on the list and talking with Carsten and > >>>> Mark, we have come up with the following text for the Charter. > >>>> > >>>> We hope (and think) that this reflects the input from the group and Mark > >>>> plans to take this to the IESG for rechartering approval. > >>>> > >>>> We've had some excellent discussion on a few topics and this is great. > >>>> There is no reason why we should stop the discussion and work while Mark > >>>> handles the rechartering. > >>>> > >>>> 1. I think that the work is proceeding on the Security Analysis document > >>>> 2. We have the current HC1G draft. The issue being discussed is the > >>>> "compression" of the UDP checksum and it's impact on the end-to-end > >>>> model. I would like to hear more input and discussion on this. Please > >>>> speak up if you have thoughts on this. > >>>> 3. We have some initial input on the Architecture document and I would > >>>> like to hear from anyone that would volunteer to continue to work on > >>>> this document. > >>>> > >>>> geoff > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 Jun 12 11:00: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 3C9193A6834; Thu, 12 Jun 2008 11:00: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 CEA5128C12F for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, J_CHICKENPOX_21=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 soIYXYRFGFDV for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:00:42 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id B2C963A6834 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 11:00:42 -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 m5CI0VGv028287; Thu, 12 Jun 2008 12:00:31 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Thu, 12 Jun 2008 12:00:27 -0600 Message-Id: <1213293627.19399.18.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 would just like a date that we all feel comfortable putting in for the completion and moving to the IESG. geoff On Thu, 2008-06-12 at 19:52 +0200, JP Vasseur wrote: > Hi Geoff, > > > On 6/12/08 4:49 PM, "Geoff Mulligan" wrote: > > > It was clear that items: 1(ND), 3(Architecture) and 5(Security) were > > priority items. It was less clear to the three of us that use cases > > were a priority item. > > > > It sounds like we have people that would like to continue to work on the > > use cases and that completing them in parallel to the other efforts > > would be a "good thing". > > > > What schedule do the authors anticipate completing the document? > > Well hopefully you do not require to terminate the document before it > becomes a WG item ;-) To answer your question, it is already the second > revision, the third revision will be posted before Dublin and we'll be > having a fairly stable ID. > > Thanks. > > JP. > > > > > geoff > > > > On Thu, 2008-06-12 at 16:06 +0200, Mark Townsley wrote: > >> Geoff Mulligan wrote: > >>> It didn't seem to be a priority item. > >>> > >>> Perhaps we should consider incorporating the Use Cases into the > >>> architecture document. > >> Whether the use-cases are in the arch document or separate is somewhat > >> orthogonal to whether they are chartered work right now. > >>> If not then I think once we complete the few > >>> documents we should then revisit the use cases. > >>> > >> I a missing why writing down use-cases is not a good thing to do sooner > >> rather than later. I don't think it should stop protocol work in its > >> tracks, but I see no indication right now that it would. As long as the > >> use-cases are considered informational and can run largely in parallel* > >> to the normative work at this stage, I don't know why we wouldn't pursue it. > >> > >> - Mark > >> > >> *If this were the very beginnings of 6lowpan, I would insist on > >> use-cases to help drive requirements, architecture, and finally solution > >> design. While we are somewhat past that stage, I do think they could > >> still be very useful to ROLL, as well as going forward as we continue to > >> debate the pros and cons of various optimizations. > >>> geoff > >>> > >>> > >>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > >>> > >>>> Geoff, > >>>> > >>>> 6LoWPAN use-case was always in the recharter items, and there was no > >>>> objection on it. Any reason to take it out? > >>>> Thanks for the good work. > >>>> > >>>> -eunah > >>>> > >>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan > >>>> wrote: > >>>> > >>>>> After reviewing the comments on the list and talking with Carsten and > >>>>> Mark, we have come up with the following text for the Charter. > >>>>> > >>>>> We hope (and think) that this reflects the input from the group and Mark > >>>>> plans to take this to the IESG for rechartering approval. > >>>>> > >>>>> We've had some excellent discussion on a few topics and this is great. > >>>>> There is no reason why we should stop the discussion and work while Mark > >>>>> handles the rechartering. > >>>>> > >>>>> 1. I think that the work is proceeding on the Security Analysis document > >>>>> 2. We have the current HC1G draft. The issue being discussed is the > >>>>> "compression" of the UDP checksum and it's impact on the end-to-end > >>>>> model. I would like to hear more input and discussion on this. Please > >>>>> speak up if you have thoughts on this. > >>>>> 3. We have some initial input on the Architecture document and I would > >>>>> like to hear from anyone that would volunteer to continue to work on > >>>>> this document. > >>>>> > >>>>> geoff > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Jun 12 11:03: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 C7E733A67AB; Thu, 12 Jun 2008 11:03: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 814CF3A6784 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 Y88vrvtli6+9 for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:03:17 -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 033923A67AB for <6lowpan@ietf.org>; Thu, 12 Jun 2008 11:03:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,632,1204531200"; d="scan'208";a="40896079" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2008 11:03:46 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5CI3ksi001282; Thu, 12 Jun 2008 11:03:46 -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 m5CI3iET012368; Thu, 12 Jun 2008 18:03:46 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, 12 Jun 2008 14:03:45 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 18:03:45 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 20:03:41 +0200 From: JP Vasseur To: Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjMtqVVN9sVij4e9EODA6fZC555gw== In-Reply-To: <1213293558.19399.16.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 18:03:45.0591 (UTC) FILETIME=[A811C470:01C8CCB6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4470; t=1213293826; x=1214157826; 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:=20Re=3A=20[6lowpan]=20new=20charter=20text |Sender:=20; bh=zDY676uCp4ub8En2KTFTfniJC1E0TdQi6Ib3eaHrZ0k=; b=dTjHp3B4GHe9oTD6azylZ1v20mOm1hGNpLy4MnlrDehVNf8SlD44BLbl6I WCgin5njELZca4cZjfbyfVQzYmLlbs9T1aCWjpYEDJLhPsgJi9SP6s1n/UqA c8CFmlFqPhi57ShOPQEa7ivUi5t5Zf6erZCwdoVjhDooFJcuIOYnI=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 6/12/08 7:59 PM, "Geoff Mulligan" wrote: > Please do not misunderstand my/our intentions. In reading the various > messages about the rechartering, it did not appear to us as though the > use-case was a priority item - not that it was not useful or would not > be useful, just not a priority. That was the only reason it was left > off of the charter. It was very clear that ND, Arch, and Security were > at the top of the list. And they are on the top of the list, no question about this. > > I am not at all against continuing with the use-case ID in parallel to > the rest of the documents. I think that it is and could be useful. > > I will add it back to charter text, but please let me know a date that > we can plan to have the ID completed. Sure, what about Dec 2008 for IESG submission? Thanks. JP. > > geoff > > On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: >> Hi Mark, >> >> >> On 6/12/08 4:06 PM, "Mark Townsley" wrote: >> >>> Geoff Mulligan wrote: >>>> It didn't seem to be a priority item. >>>> >>>> Perhaps we should consider incorporating the Use Cases into the >>>> architecture document. >>> Whether the use-cases are in the arch document or separate is somewhat >>> orthogonal to whether they are chartered work right now. >>>> If not then I think once we complete the few >>>> documents we should then revisit the use cases. >>>> >>> I a missing why writing down use-cases is not a good thing to do sooner >>> rather than later. I don't think it should stop protocol work in its >>> tracks, but I see no indication right now that it would. As long as the >>> use-cases are considered informational and can run largely in parallel* >>> to the normative work at this stage, I don't know why we wouldn't pursue it. >>> >>> - Mark >>> >>> *If this were the very beginnings of 6lowpan, I would insist on >>> use-cases to help drive requirements, architecture, and finally solution >>> design. While we are somewhat past that stage, I do think they could >>> still be very useful to ROLL, as well as going forward as we continue to >>> debate the pros and cons of various optimizations. >> >> Absolutely ! The only (but useful) objective is to document 6lowpan >> application, informational ID of course. >> >> Thanks. >> >> JP. >> >>>> geoff >>>> >>>> >>>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: >>>> >>>>> Geoff, >>>>> >>>>> 6LoWPAN use-case was always in the recharter items, and there was no >>>>> objection on it. Any reason to take it out? >>>>> Thanks for the good work. >>>>> >>>>> -eunah >>>>> >>>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan >>>>> wrote: >>>>> >>>>>> After reviewing the comments on the list and talking with Carsten and >>>>>> Mark, we have come up with the following text for the Charter. >>>>>> >>>>>> We hope (and think) that this reflects the input from the group and Mark >>>>>> plans to take this to the IESG for rechartering approval. >>>>>> >>>>>> We've had some excellent discussion on a few topics and this is great. >>>>>> There is no reason why we should stop the discussion and work while Mark >>>>>> handles the rechartering. >>>>>> >>>>>> 1. I think that the work is proceeding on the Security Analysis document >>>>>> 2. We have the current HC1G draft. The issue being discussed is the >>>>>> "compression" of the UDP checksum and it's impact on the end-to-end >>>>>> model. I would like to hear more input and discussion on this. Please >>>>>> speak up if you have thoughts on this. >>>>>> 3. We have some initial input on the Architecture document and I would >>>>>> like to hear from anyone that would volunteer to continue to work on >>>>>> this document. >>>>>> >>>>>> geoff >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Jun 12 11:19: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 C2D2F3A695A; Thu, 12 Jun 2008 11:19: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 9F7AA3A685E for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, J_CHICKENPOX_21=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 1drdOeZKqu6m for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:19:22 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 674DC3A6784 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 11:19:22 -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 m5CIJoir028504; Thu, 12 Jun 2008 12:19:50 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Thu, 12 Jun 2008 12:19:46 -0600 Message-Id: <1213294786.19399.34.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 This is probably fine. Since we are already no Rev 2 we might be able to complete it sooner, but I don't want to pressure anyone. I hope that the current authors can provide some input. geoff On Thu, 2008-06-12 at 20:03 +0200, JP Vasseur wrote: > Hi Geoff, > > > On 6/12/08 7:59 PM, "Geoff Mulligan" wrote: > > > Please do not misunderstand my/our intentions. In reading the various > > messages about the rechartering, it did not appear to us as though the > > use-case was a priority item - not that it was not useful or would not > > be useful, just not a priority. That was the only reason it was left > > off of the charter. It was very clear that ND, Arch, and Security were > > at the top of the list. > > And they are on the top of the list, no question about this. > > > > > I am not at all against continuing with the use-case ID in parallel to > > the rest of the documents. I think that it is and could be useful. > > > > I will add it back to charter text, but please let me know a date that > > we can plan to have the ID completed. > > Sure, what about Dec 2008 for IESG submission? > > Thanks. > > JP. > > > > > geoff > > > > On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: > >> Hi Mark, > >> > >> > >> On 6/12/08 4:06 PM, "Mark Townsley" wrote: > >> > >>> Geoff Mulligan wrote: > >>>> It didn't seem to be a priority item. > >>>> > >>>> Perhaps we should consider incorporating the Use Cases into the > >>>> architecture document. > >>> Whether the use-cases are in the arch document or separate is somewhat > >>> orthogonal to whether they are chartered work right now. > >>>> If not then I think once we complete the few > >>>> documents we should then revisit the use cases. > >>>> > >>> I a missing why writing down use-cases is not a good thing to do sooner > >>> rather than later. I don't think it should stop protocol work in its > >>> tracks, but I see no indication right now that it would. As long as the > >>> use-cases are considered informational and can run largely in parallel* > >>> to the normative work at this stage, I don't know why we wouldn't pursue it. > >>> > >>> - Mark > >>> > >>> *If this were the very beginnings of 6lowpan, I would insist on > >>> use-cases to help drive requirements, architecture, and finally solution > >>> design. While we are somewhat past that stage, I do think they could > >>> still be very useful to ROLL, as well as going forward as we continue to > >>> debate the pros and cons of various optimizations. > >> > >> Absolutely ! The only (but useful) objective is to document 6lowpan > >> application, informational ID of course. > >> > >> Thanks. > >> > >> JP. > >> > >>>> geoff > >>>> > >>>> > >>>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > >>>> > >>>>> Geoff, > >>>>> > >>>>> 6LoWPAN use-case was always in the recharter items, and there was no > >>>>> objection on it. Any reason to take it out? > >>>>> Thanks for the good work. > >>>>> > >>>>> -eunah > >>>>> > >>>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan > >>>>> wrote: > >>>>> > >>>>>> After reviewing the comments on the list and talking with Carsten and > >>>>>> Mark, we have come up with the following text for the Charter. > >>>>>> > >>>>>> We hope (and think) that this reflects the input from the group and Mark > >>>>>> plans to take this to the IESG for rechartering approval. > >>>>>> > >>>>>> We've had some excellent discussion on a few topics and this is great. > >>>>>> There is no reason why we should stop the discussion and work while Mark > >>>>>> handles the rechartering. > >>>>>> > >>>>>> 1. I think that the work is proceeding on the Security Analysis document > >>>>>> 2. We have the current HC1G draft. The issue being discussed is the > >>>>>> "compression" of the UDP checksum and it's impact on the end-to-end > >>>>>> model. I would like to hear more input and discussion on this. Please > >>>>>> speak up if you have thoughts on this. > >>>>>> 3. We have some initial input on the Architecture document and I would > >>>>>> like to hear from anyone that would volunteer to continue to work on > >>>>>> this document. > >>>>>> > >>>>>> geoff > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 Jun 12 11:36: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 482213A6A19; Thu, 12 Jun 2008 11:36: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 404E03A6A4D for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=-0.064, 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 Sd1FSvvdLQuv for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:36:47 -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 CAEF33A6A19 for <6lowpan@ietf.org>; Thu, 12 Jun 2008 11:36:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,632,1204520400"; d="scan'208";a="10874775" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2008 14:37:14 -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 m5CIbDfp011895; Thu, 12 Jun 2008 14:37:13 -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 m5CIbCMd018211; Thu, 12 Jun 2008 18:37:13 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, 12 Jun 2008 14:37:13 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 18:37:13 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 20:37:08 +0200 From: JP Vasseur To: Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] new charter text Thread-Index: AcjMu1GZojVHgzSGkUqDh727Ljir/Q== In-Reply-To: <1213294786.19399.34.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 18:37:13.0435 (UTC) FILETIME=[54D672B0:01C8CCBB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5177; t=1213295833; x=1214159833; 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=20text |Sender:=20 |To:=20Geoff=20Mulligan=20; bh=7u0s+j6Z4yWKrsLec/LMTrUn58vfpuHri4tC09vqWBU=; b=cx83KEBCMjdHJosT15Cg4Z1NHHmj7ibeD7hOnA3fGgWDF0ekhRnvRS8KAJ wCdBPAKSaEcay9E8GFjHgVDBQ96WjEEzg7VSQxDad3H5vpZDTJu5yYRdZ/m9 Y8sYUxtqv4; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 6/12/08 8:19 PM, "Geoff Mulligan" wrote: > This is probably fine. Since we are already no Rev 2 we might be able > to complete it sooner, but I don't want to pressure anyone. I hope that > the current authors can provide some input. I'm one of them. Eunah, what do you think ? JP. > > geoff > > On Thu, 2008-06-12 at 20:03 +0200, JP Vasseur wrote: >> Hi Geoff, >> >> >> On 6/12/08 7:59 PM, "Geoff Mulligan" wrote: >> >>> Please do not misunderstand my/our intentions. In reading the various >>> messages about the rechartering, it did not appear to us as though the >>> use-case was a priority item - not that it was not useful or would not >>> be useful, just not a priority. That was the only reason it was left >>> off of the charter. It was very clear that ND, Arch, and Security were >>> at the top of the list. >> >> And they are on the top of the list, no question about this. >> >>> >>> I am not at all against continuing with the use-case ID in parallel to >>> the rest of the documents. I think that it is and could be useful. >>> >>> I will add it back to charter text, but please let me know a date that >>> we can plan to have the ID completed. >> >> Sure, what about Dec 2008 for IESG submission? >> >> Thanks. >> >> JP. >> >>> >>> geoff >>> >>> On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: >>>> Hi Mark, >>>> >>>> >>>> On 6/12/08 4:06 PM, "Mark Townsley" wrote: >>>> >>>>> Geoff Mulligan wrote: >>>>>> It didn't seem to be a priority item. >>>>>> >>>>>> Perhaps we should consider incorporating the Use Cases into the >>>>>> architecture document. >>>>> Whether the use-cases are in the arch document or separate is somewhat >>>>> orthogonal to whether they are chartered work right now. >>>>>> If not then I think once we complete the few >>>>>> documents we should then revisit the use cases. >>>>>> >>>>> I a missing why writing down use-cases is not a good thing to do sooner >>>>> rather than later. I don't think it should stop protocol work in its >>>>> tracks, but I see no indication right now that it would. As long as the >>>>> use-cases are considered informational and can run largely in parallel* >>>>> to the normative work at this stage, I don't know why we wouldn't pursue >>>>> it. >>>>> >>>>> - Mark >>>>> >>>>> *If this were the very beginnings of 6lowpan, I would insist on >>>>> use-cases to help drive requirements, architecture, and finally solution >>>>> design. While we are somewhat past that stage, I do think they could >>>>> still be very useful to ROLL, as well as going forward as we continue to >>>>> debate the pros and cons of various optimizations. >>>> >>>> Absolutely ! The only (but useful) objective is to document 6lowpan >>>> application, informational ID of course. >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>>>> geoff >>>>>> >>>>>> >>>>>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: >>>>>> >>>>>>> Geoff, >>>>>>> >>>>>>> 6LoWPAN use-case was always in the recharter items, and there was no >>>>>>> objection on it. Any reason to take it out? >>>>>>> Thanks for the good work. >>>>>>> >>>>>>> -eunah >>>>>>> >>>>>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan >>>>>>> wrote: >>>>>>> >>>>>>>> After reviewing the comments on the list and talking with Carsten and >>>>>>>> Mark, we have come up with the following text for the Charter. >>>>>>>> >>>>>>>> We hope (and think) that this reflects the input from the group and >>>>>>>> Mark >>>>>>>> plans to take this to the IESG for rechartering approval. >>>>>>>> >>>>>>>> We've had some excellent discussion on a few topics and this is great. >>>>>>>> There is no reason why we should stop the discussion and work while >>>>>>>> Mark >>>>>>>> handles the rechartering. >>>>>>>> >>>>>>>> 1. I think that the work is proceeding on the Security Analysis >>>>>>>> document >>>>>>>> 2. We have the current HC1G draft. The issue being discussed is the >>>>>>>> "compression" of the UDP checksum and it's impact on the end-to-end >>>>>>>> model. I would like to hear more input and discussion on this. Please >>>>>>>> speak up if you have thoughts on this. >>>>>>>> 3. We have some initial input on the Architecture document and I would >>>>>>>> like to hear from anyone that would volunteer to continue to work on >>>>>>>> this document. >>>>>>>> >>>>>>>> geoff >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 Jun 12 11:47: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 3B3993A67AB; Thu, 12 Jun 2008 11:47: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 AB9653A683E for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, J_CHICKENPOX_21=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 DbBoWtmZiRYD for <6lowpan@core3.amsl.com>; Thu, 12 Jun 2008 11:47:28 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 577183A67AE for <6lowpan@ietf.org>; Thu, 12 Jun 2008 11:47:28 -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 m5CIlBQ4028796; Thu, 12 Jun 2008 12:47:11 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Thu, 12 Jun 2008 12:47:08 -0600 Message-Id: <1213296428.19399.54.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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'm sorry JP. I had forgotten that you were an author. I hadn't looked at the authors and had just remembered Eunsook and Dominik. Sorry to Nicolas also. Since we want to press forward, I'll assume that Dec 08 is a comfortable date and put this missing piece back into the charter and resend it to everyone. geoff On Thu, 2008-06-12 at 20:37 +0200, JP Vasseur wrote: > > > On 6/12/08 8:19 PM, "Geoff Mulligan" wrote: > > > This is probably fine. Since we are already no Rev 2 we might be able > > to complete it sooner, but I don't want to pressure anyone. I hope that > > the current authors can provide some input. > > I'm one of them. Eunah, what do you think ? > > JP. > > > > > geoff > > > > On Thu, 2008-06-12 at 20:03 +0200, JP Vasseur wrote: > >> Hi Geoff, > >> > >> > >> On 6/12/08 7:59 PM, "Geoff Mulligan" wrote: > >> > >>> Please do not misunderstand my/our intentions. In reading the various > >>> messages about the rechartering, it did not appear to us as though the > >>> use-case was a priority item - not that it was not useful or would not > >>> be useful, just not a priority. That was the only reason it was left > >>> off of the charter. It was very clear that ND, Arch, and Security were > >>> at the top of the list. > >> > >> And they are on the top of the list, no question about this. > >> > >>> > >>> I am not at all against continuing with the use-case ID in parallel to > >>> the rest of the documents. I think that it is and could be useful. > >>> > >>> I will add it back to charter text, but please let me know a date that > >>> we can plan to have the ID completed. > >> > >> Sure, what about Dec 2008 for IESG submission? > >> > >> Thanks. > >> > >> JP. > >> > >>> > >>> geoff > >>> > >>> On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: > >>>> Hi Mark, > >>>> > >>>> > >>>> On 6/12/08 4:06 PM, "Mark Townsley" wrote: > >>>> > >>>>> Geoff Mulligan wrote: > >>>>>> It didn't seem to be a priority item. > >>>>>> > >>>>>> Perhaps we should consider incorporating the Use Cases into the > >>>>>> architecture document. > >>>>> Whether the use-cases are in the arch document or separate is somewhat > >>>>> orthogonal to whether they are chartered work right now. > >>>>>> If not then I think once we complete the few > >>>>>> documents we should then revisit the use cases. > >>>>>> > >>>>> I a missing why writing down use-cases is not a good thing to do sooner > >>>>> rather than later. I don't think it should stop protocol work in its > >>>>> tracks, but I see no indication right now that it would. As long as the > >>>>> use-cases are considered informational and can run largely in parallel* > >>>>> to the normative work at this stage, I don't know why we wouldn't pursue > >>>>> it. > >>>>> > >>>>> - Mark > >>>>> > >>>>> *If this were the very beginnings of 6lowpan, I would insist on > >>>>> use-cases to help drive requirements, architecture, and finally solution > >>>>> design. While we are somewhat past that stage, I do think they could > >>>>> still be very useful to ROLL, as well as going forward as we continue to > >>>>> debate the pros and cons of various optimizations. > >>>> > >>>> Absolutely ! The only (but useful) objective is to document 6lowpan > >>>> application, informational ID of course. > >>>> > >>>> Thanks. > >>>> > >>>> JP. > >>>> > >>>>>> geoff > >>>>>> > >>>>>> > >>>>>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > >>>>>> > >>>>>>> Geoff, > >>>>>>> > >>>>>>> 6LoWPAN use-case was always in the recharter items, and there was no > >>>>>>> objection on it. Any reason to take it out? > >>>>>>> Thanks for the good work. > >>>>>>> > >>>>>>> -eunah > >>>>>>> > >>>>>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan > >>>>>>> wrote: > >>>>>>> > >>>>>>>> After reviewing the comments on the list and talking with Carsten and > >>>>>>>> Mark, we have come up with the following text for the Charter. > >>>>>>>> > >>>>>>>> We hope (and think) that this reflects the input from the group and > >>>>>>>> Mark > >>>>>>>> plans to take this to the IESG for rechartering approval. > >>>>>>>> > >>>>>>>> We've had some excellent discussion on a few topics and this is great. > >>>>>>>> There is no reason why we should stop the discussion and work while > >>>>>>>> Mark > >>>>>>>> handles the rechartering. > >>>>>>>> > >>>>>>>> 1. I think that the work is proceeding on the Security Analysis > >>>>>>>> document > >>>>>>>> 2. We have the current HC1G draft. The issue being discussed is the > >>>>>>>> "compression" of the UDP checksum and it's impact on the end-to-end > >>>>>>>> model. I would like to hear more input and discussion on this. Please > >>>>>>>> speak up if you have thoughts on this. > >>>>>>>> 3. We have some initial input on the Architecture document and I would > >>>>>>>> like to hear from anyone that would volunteer to continue to work on > >>>>>>>> this document. > >>>>>>>> > >>>>>>>> geoff > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> 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 Jun 13 00:15: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 DC5743A6B2A; Fri, 13 Jun 2008 00:15: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 3EFC73A6B2A for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 00:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=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 90j4xkGmAWeH for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 00:15:30 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id AC26D3A6A87 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 00:15:29 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1801084tib.25 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 00:15:55 -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=W3ghBoXoK1+zaxHeUtYSAvFm61xTnK6Snqecc2UgWkU=; b=ZNryo+Ix8fE8a7E/CmwmGfQ4vh30XwoXAN/7XPYG90uG1NiQkl+bJBXBtZhwBQEnvN 7RXwOmLBD3g7W/RMo4Brj9h2OcxUh3W2fXXD1qa4GJ1+a+5IVDBcdfcSQ948FNO/9ZPw VuZQFtOWqW9zx54Cf1sblyhKM9LqCpyn0MDqc= 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=EEzH44WEuiho+GA/AsJR12+wCY2UyzSciwnHk3G2AEGIjVREZ66LA+2Mrsse3+4GtC Y4PSqUPfYfBW42fSDkvh5MPg3sLU8whGg2uocJTeCfyQEjBG7GvL9HixuQK6CPJMyKtg VGy14dd+Eckb40yBcKuGmjlVLYaU3MSZtcnNI= Received: by 10.110.70.5 with SMTP id s5mr1461165tia.27.1213341355805; Fri, 13 Jun 2008 00:15:55 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Fri, 13 Jun 2008 00:15:55 -0700 (PDT) Message-ID: <77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> Date: Fri, 13 Jun 2008 16:15:55 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" In-Reply-To: <1213296428.19399.54.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <1213296428.19399.54.camel@dellx1> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 not to involve the discussion on time. I was out of the office. Thanks JP to handle this matter. :) Dec 2008 sounds fine with me. -eunah On Fri, Jun 13, 2008 at 3:47 AM, Geoff Mulligan wrote: > I'm sorry JP. I had forgotten that you were an author. I hadn't looked > at the authors and had just remembered Eunsook and Dominik. Sorry to > Nicolas also. > > Since we want to press forward, I'll assume that Dec 08 is a comfortable > date and put this missing piece back into the charter and resend it to > everyone. > > geoff > > On Thu, 2008-06-12 at 20:37 +0200, JP Vasseur wrote: >> >> >> On 6/12/08 8:19 PM, "Geoff Mulligan" wrote: >> >> > This is probably fine. Since we are already no Rev 2 we might be able >> > to complete it sooner, but I don't want to pressure anyone. I hope that >> > the current authors can provide some input. >> >> I'm one of them. Eunah, what do you think ? >> >> JP. >> >> > >> > geoff >> > >> > On Thu, 2008-06-12 at 20:03 +0200, JP Vasseur wrote: >> >> Hi Geoff, >> >> >> >> >> >> On 6/12/08 7:59 PM, "Geoff Mulligan" wrote: >> >> >> >>> Please do not misunderstand my/our intentions. In reading the various >> >>> messages about the rechartering, it did not appear to us as though the >> >>> use-case was a priority item - not that it was not useful or would not >> >>> be useful, just not a priority. That was the only reason it was left >> >>> off of the charter. It was very clear that ND, Arch, and Security were >> >>> at the top of the list. >> >> >> >> And they are on the top of the list, no question about this. >> >> >> >>> >> >>> I am not at all against continuing with the use-case ID in parallel to >> >>> the rest of the documents. I think that it is and could be useful. >> >>> >> >>> I will add it back to charter text, but please let me know a date that >> >>> we can plan to have the ID completed. >> >> >> >> Sure, what about Dec 2008 for IESG submission? >> >> >> >> Thanks. >> >> >> >> JP. >> >> >> >>> >> >>> geoff >> >>> >> >>> On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: >> >>>> Hi Mark, >> >>>> >> >>>> >> >>>> On 6/12/08 4:06 PM, "Mark Townsley" wrote: >> >>>> >> >>>>> Geoff Mulligan wrote: >> >>>>>> It didn't seem to be a priority item. >> >>>>>> >> >>>>>> Perhaps we should consider incorporating the Use Cases into the >> >>>>>> architecture document. >> >>>>> Whether the use-cases are in the arch document or separate is somewhat >> >>>>> orthogonal to whether they are chartered work right now. >> >>>>>> If not then I think once we complete the few >> >>>>>> documents we should then revisit the use cases. >> >>>>>> >> >>>>> I a missing why writing down use-cases is not a good thing to do sooner >> >>>>> rather than later. I don't think it should stop protocol work in its >> >>>>> tracks, but I see no indication right now that it would. As long as the >> >>>>> use-cases are considered informational and can run largely in parallel* >> >>>>> to the normative work at this stage, I don't know why we wouldn't pursue >> >>>>> it. >> >>>>> >> >>>>> - Mark >> >>>>> >> >>>>> *If this were the very beginnings of 6lowpan, I would insist on >> >>>>> use-cases to help drive requirements, architecture, and finally solution >> >>>>> design. While we are somewhat past that stage, I do think they could >> >>>>> still be very useful to ROLL, as well as going forward as we continue to >> >>>>> debate the pros and cons of various optimizations. >> >>>> >> >>>> Absolutely ! The only (but useful) objective is to document 6lowpan >> >>>> application, informational ID of course. >> >>>> >> >>>> Thanks. >> >>>> >> >>>> JP. >> >>>> >> >>>>>> geoff >> >>>>>> >> >>>>>> >> >>>>>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: >> >>>>>> >> >>>>>>> Geoff, >> >>>>>>> >> >>>>>>> 6LoWPAN use-case was always in the recharter items, and there was no >> >>>>>>> objection on it. Any reason to take it out? >> >>>>>>> Thanks for the good work. >> >>>>>>> >> >>>>>>> -eunah >> >>>>>>> >> >>>>>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>>> After reviewing the comments on the list and talking with Carsten and >> >>>>>>>> Mark, we have come up with the following text for the Charter. >> >>>>>>>> >> >>>>>>>> We hope (and think) that this reflects the input from the group and >> >>>>>>>> Mark >> >>>>>>>> plans to take this to the IESG for rechartering approval. >> >>>>>>>> >> >>>>>>>> We've had some excellent discussion on a few topics and this is great. >> >>>>>>>> There is no reason why we should stop the discussion and work while >> >>>>>>>> Mark >> >>>>>>>> handles the rechartering. >> >>>>>>>> >> >>>>>>>> 1. I think that the work is proceeding on the Security Analysis >> >>>>>>>> document >> >>>>>>>> 2. We have the current HC1G draft. The issue being discussed is the >> >>>>>>>> "compression" of the UDP checksum and it's impact on the end-to-end >> >>>>>>>> model. I would like to hear more input and discussion on this. Please >> >>>>>>>> speak up if you have thoughts on this. >> >>>>>>>> 3. We have some initial input on the Architecture document and I would >> >>>>>>>> like to hear from anyone that would volunteer to continue to work on >> >>>>>>>> this document. >> >>>>>>>> >> >>>>>>>> geoff >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> 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 > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jun 13 06:58: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 DEEEE3A68EB; Fri, 13 Jun 2008 06:58: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 8D1F83A68EB for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 KnhRO0NBVVGl for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 06:58:56 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 56A703A67F5 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 06:58:56 -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 m5DDxRHY006160 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 07:59:27 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> In-Reply-To: <77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> References: <1213296428.19399.54.camel@dellx1> <77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> Content-Type: multipart/mixed; boundary="=-224Dka7geUvV4kwwUaRe" Date: Fri, 13 Jun 2008 07:59:33 -0600 Message-Id: <1213365573.19399.71.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [6lowpan] New new charter text 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 --=-224Dka7geUvV4kwwUaRe Content-Type: text/plain Content-Transfer-Encoding: 7bit With the input from the authors we've put the "Use Cases" back into the text for the charter for the working group with a delivery date of Dec 08. Attached is the NEW new charter text. geoff --=-224Dka7geUvV4kwwUaRe Content-Disposition: attachment; filename=charter.txt Content-Type: text/plain; name=charter.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 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 such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. As a spin-off from that document, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. Both documents will be informational. 4. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 5. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: --------------------- - Aug 2008 - Submit Improved Header Compression document to IESG for consideration as a proposed standard. - Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC. - Sep 2008 - Submit Architecture document(s) to IESG for consideration as an Informational RFC(s) - Nov 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard - Dec 2008 - Submit Use Case document to IESG as an Informational RFC. --=-224Dka7geUvV4kwwUaRe 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 --=-224Dka7geUvV4kwwUaRe-- From 6lowpan-bounces@ietf.org Fri Jun 13 09:01: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 2A80D3A6851; Fri, 13 Jun 2008 09:01:30 -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 8A90C3A6851 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 09:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.239, 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 PtdcbBCs8SWd for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 09:01:28 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AE5393A682E for <6lowpan@ietf.org>; Fri, 13 Jun 2008 09:01:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204531200"; d="scan'208";a="15695600" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 13 Jun 2008 09:01:57 -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 m5DG1viS026240; Fri, 13 Jun 2008 09:01:57 -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 m5DG1uw8006482; Fri, 13 Jun 2008 16:01:57 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, 13 Jun 2008 12:01:52 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 16:01:52 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 18:01:50 +0200 From: JP Vasseur To: Geoff Mulligan , 6lowpan <6lowpan@ietf.org> Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNbsoM3pueslg16k+6HMsPQSTpQQ== In-Reply-To: <1213365573.19399.71.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 16:01:52.0228 (UTC) FILETIME=[CB60E240:01C8CD6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2179; t=1213372917; x=1214236917; 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=20new=20charter=20text |Sender:=20; bh=39gqVi6ugS38cUygR1mRGpPTLSU72PZWwmzCBRA1EbY=; b=xEKRS5XMJbYNjapVvW7kPv1TqileRAoWzIP6eyPrQuqY0Sdh1vIHZ3z4/8 3BtMsJzvhnCJum5lcapKbILyWg0hzwLP1koKKKBjAB3e9MU40saWKerQ19M8 8srf0a5Kwb; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [6lowpan] New new charter text 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, Thanks for sending out the new revision. One question, one comment. Question: could you explain the rationale for leaving out the fragmentation recovery item? Comment: "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 such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. As a spin-off from that document, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. Both documents will be informational." I do not understand the rationale here: I think that we should first determine whether we both need a mesh-under *and* a route-over approach. You know my opinion: we have numerous examples in the past of such approaches that ALL failed for obvious technical reasons but this is my technical opinion. As far as 6lowpan is concerned, shouldn't we first have a discussion to get a consensus there ? *If* it turns out that both are needed, then add an introductory section in the architecture document pointing to the requirement document(s). Thus I would rather suggest not to list this as a WG item but to leave it out for the moment and continue to have the discussion until we have a consensus. Then at that point we could decide what to do. On the other hand, having a separate documents listing the 6LoWPAN specific routing requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot of sense. Thoughts ? Thanks. JP. On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: > With the input from the authors we've put the "Use Cases" back into the > text for the charter for the working group with a delivery date of Dec > 08. > > Attached is the NEW new charter text. > > geoff > > _______________________________________________ > 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 Jun 13 10:24: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 6D0C43A690F; Fri, 13 Jun 2008 10:24: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 C365D3A690F for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.480, 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 4hEXmUXAtIXe for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 10:24:42 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 47D1D3A6765 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 10:24:42 -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 m5DHP9me007857; Fri, 13 Jun 2008 11:25:09 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Fri, 13 Jun 2008 11:25:05 -0600 Message-Id: <1213377905.5961.26.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 77u/SlAsCiAgQXMgSSBzYWlkIHByZXZpb3VzbHksIHdoZW4gQ2Fyc3RlbiwgTWFyayBhbmQgSSBy ZXZpZXdlZCB0aGUKY29tbWVudHMvbWVzc2FnZXMgb24gdGhlIGxpc3QgaXQgd2FzIGNsZWFyIHRo YXQgTkQsIEFyY2hpdGVjdHVyZSwgYW5kClNlY3VyaXR5IHdlcmUgcHJpb3JpdHkgaXRlbXMgYWxv bmcgd2l0aCBkZWFsaW5nIHdpdGggZW5oYW5jZW1lbnRzIHRvCmNvbXByZXNzaW9uIG9mIG5vbiBs aW5rIGxvY2FsIGFkZHJlc3NlcyBhbmQgdGhhdCB0aGVyZSB3YXMgY2xlYXIgc3VwcG9ydAp0byB0 YWtlIHRoZXNlIG9uIHdpdGhpbiB0aGUgd29ya2luZyBncm91cC4gQW5kIG5vdyBhbHNvIHRoZSBV c2UgQ2FzZXMKZHJhZnQuCgpJIGFtIGxlc3MgY2VydGFpbiB0aGF0IHRoZXJlIGlzIGNvbnNlbnN1 cyB0aGF0IGZyYWdtZW50IHJlY292ZXJ5IGlzIGEKbmVjZXNzYXJ5IHdvcmtpbmcgZ3JvdXAgaXRl bSBhdCB0aGlzIHBvaW50LiAgU28gSSB3aWxsIGFzayB0aGUgV0cuCgpBcyB0byB5b3VyIHF1ZXN0 aW9uIGFib3V0IHRoZSBBcmNoIGRvYywgSSdtIG5vdCBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kCnRo ZSBxdWVzdGlvbiBvciB0aGUgdGltaW5nPyAgVGhlIHRleHQgZm9yIHRoaXMgaGFzbid0IGNoYW5n ZWQgZm9yCm1vbnRocy4gIEl0IHNlZW1zIHRoYXQgdGhlcmUgYXJlIG1lbWJlcnMgb2YgdGhlIFdH IHRoYXQgd2FudCB0byBzZWUgdGhlCmFyY2hpdGVjdHVyYWwgZGVzY3JpcHRpb24gdGhhdCBpbmNs dWRlcyBib3RoIGEgbWVzaCB1bmRlciBzb2x1dGlvbiBhbmQgYQpyb3V0ZSBvdmVyLiAgSG93IHdv dWxkIHlvdSBwcm9wb3NlIHRoYXQgd2UgZGV0ZXJtaW5lIGlmIHRoZXJlIGlzIGEgbmVlZApmb3Ig Ym90aD8KCmdlb2ZmCgpPbiBGcmksIDIwMDgtMDYtMTMgYXQgMTg6MDEgKzAyMDAsIEpQIFZhc3Nl dXIgd3JvdGU6Cj4gSGkgR2VvZmYsCj4gCj4gVGhhbmtzIGZvciBzZW5kaW5nIG91dCB0aGUgbmV3 IHJldmlzaW9uLiBPbmUgcXVlc3Rpb24sIG9uZSBjb21tZW50Lgo+IAo+IFF1ZXN0aW9uOiBjb3Vs ZCB5b3UgZXhwbGFpbiB0aGUgcmF0aW9uYWxlIGZvciBsZWF2aW5nIG91dCB0aGUgZnJhZ21lbnRh dGlvbgo+IHJlY292ZXJ5IGl0ZW0/Cj4gCj4gQ29tbWVudDoKPiAKPiAiMy4gUHJvZHVjZSAiNkxv V1BBTiBBcmNoaXRlY3R1cmUiIHRvIGRlc2NyaWJlIHRoZSBkZXNpZ24gYW5kCj4gaW1wbGVtZW50 YXRpb24gb2YgNkxvV1BBTiBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnQgd2lsbCBjb3ZlciB0aGUK PiBjb25jZXB0cyBvZiAiTWVzaCBVbmRlciIgYW5kICJSb3V0ZSBPdmVyIiwgODAyLjE1LjQgZGVz aWduIGlzc3VlcyBzdWNoCj4gYXMgb3BlcmF0aW9uIHdpdGggc2xlZXBpbmcgbm9kZXMsIG5ldHdv cmsgY29tcG9uZW50cyAoYm90aCBiYXR0ZXJ5LQo+IGFuZCBsaW5lLXBvd2VyZWQpLCBhZGRyZXNz aW5nLCBhbmQgSVB2NC9JUHY2IG5ldHdvcmsgY29ubmVjdGlvbnMuCj4gQXMgYSBzcGluLW9mZiBm cm9tIHRoYXQgZG9jdW1lbnQsICI2TG9XUEFOIFJvdXRpbmcgUmVxdWlyZW1lbnRzIiB3aWxsCj4g ZGVzY3JpYmUgNkxvV1BBTi1zcGVjaWZpYyByZXF1aXJlbWVudHMgb24gcm91dGluZyBwcm90b2Nv bHMgdXNlZCBpbgo+IDZMb1dQQU5zLCBhZGRyZXNzaW5nIGJvdGggdGhlICJyb3V0ZS1vdmVyIiBh bmQgIm1lc2gtdW5kZXIiIGFwcHJvYWNoLgo+IEJvdGggZG9jdW1lbnRzIHdpbGwgYmUgaW5mb3Jt YXRpb25hbC4iCj4gCj4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGhlcmU6IEkg dGhpbmsgdGhhdCB3ZSBzaG91bGQgZmlyc3QKPiBkZXRlcm1pbmUgd2hldGhlciB3ZSBib3RoIG5l ZWQgYSBtZXNoLXVuZGVyICphbmQqIGEgcm91dGUtb3ZlciBhcHByb2FjaC4gWW91Cj4ga25vdyBt eSBvcGluaW9uOiB3ZSBoYXZlIG51bWVyb3VzIGV4YW1wbGVzIGluIHRoZSBwYXN0IG9mIHN1Y2gg YXBwcm9hY2hlcwo+IHRoYXQgQUxMIGZhaWxlZCBmb3Igb2J2aW91cyB0ZWNobmljYWwgcmVhc29u cyBidXQgdGhpcyBpcyBteSB0ZWNobmljYWwKPiBvcGluaW9uLiBBcyBmYXIgYXMgNmxvd3BhbiBp cyBjb25jZXJuZWQsIHNob3VsZG4ndCB3ZSBmaXJzdCBoYXZlIGEKPiBkaXNjdXNzaW9uIHRvIGdl dCBhIGNvbnNlbnN1cyB0aGVyZSA/ICpJZiogaXQgdHVybnMgb3V0IHRoYXQgYm90aCBhcmUKPiBu ZWVkZWQsIHRoZW4gYWRkIGFuIGludHJvZHVjdG9yeSBzZWN0aW9uIGluIHRoZSBhcmNoaXRlY3R1 cmUgZG9jdW1lbnQKPiBwb2ludGluZyB0byB0aGUgcmVxdWlyZW1lbnQgZG9jdW1lbnQocykuCj4g Cj4gVGh1cyBJIHdvdWxkIHJhdGhlciBzdWdnZXN0IG5vdCB0byBsaXN0IHRoaXMgYXMgYSBXRyBp dGVtIGJ1dCB0byBsZWF2ZSBpdAo+IG91dCBmb3IgdGhlIG1vbWVudCBhbmQgY29udGludWUgdG8g aGF2ZSB0aGUgZGlzY3Vzc2lvbiB1bnRpbCB3ZSBoYXZlIGEKPiBjb25zZW5zdXMuIFRoZW4gYXQg dGhhdCBwb2ludCB3ZSBjb3VsZCBkZWNpZGUgd2hhdCB0byBkby4gT24gdGhlIG90aGVyIGhhbmQs Cj4gaGF2aW5nIGEgc2VwYXJhdGUgZG9jdW1lbnRzIGxpc3RpbmcgdGhlIDZMb1dQQU4gc3BlY2lm aWMgcm91dGluZwo+IHJlcXVpcmVtZW50cywgb3duZWQgYnkgdGhlIDZsb3dwYW4gV0cgYW5kIHJl dmlld2VkIGJ5IFJPTEwgd291bGQgbWFrZSBhIGxvdAo+IG9mIHNlbnNlLgo+IAo+IFRob3VnaHRz ID8KPiAKPiBUaGFua3MuCj4gCj4gSlAuCj4gCj4gCj4gCj4gT24gNi8xMy8wOCAzOjU5IFBNLCAi R2VvZmYgTXVsbGlnYW4iIDxpZXRmMDhAbXVsbGlnYW4ub3JnPiB3cm90ZToKPiAKPiA+IFdpdGgg dGhlIGlucHV0IGZyb20gdGhlIGF1dGhvcnMgd2UndmUgcHV0IHRoZSAiVXNlIENhc2VzIiBiYWNr IGludG8gdGhlCj4gPiB0ZXh0IGZvciB0aGUgY2hhcnRlciBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAg d2l0aCBhIGRlbGl2ZXJ5IGRhdGUgb2YgRGVjCj4gPiAwOC4KPiA+IAo+ID4gQXR0YWNoZWQgaXMg dGhlIE5FVyBuZXcgY2hhcnRlciB0ZXh0Lgo+ID4gCj4gPiBnZW9mZgo+ID4gCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gNmxvd3BhbiBtYWls aW5nIGxpc3QKPiA+IDZsb3dwYW5AaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vNmxvd3BhbgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KNmxvd3BhbiBtYWlsaW5nIGxpc3QKNmxvd3BhbkBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4K From 6lowpan-bounces@ietf.org Fri Jun 13 10:33: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 1B2583A68CE; Fri, 13 Jun 2008 10:33: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 966233A69D4 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 10:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 0zxNIGwCZn8e for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 10:33:28 -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 536453A68CE for <6lowpan@ietf.org>; Fri, 13 Jun 2008 10:33:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204520400"; d="scan'208";a="10967158" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2008 13:34:00 -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 m5DHY0Br003919; Fri, 13 Jun 2008 13:34:00 -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 m5DHY03e018662; Fri, 13 Jun 2008 17:34:00 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, 13 Jun 2008 13:33:59 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 17:33:59 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 19:33:58 +0200 From: JP Vasseur To: Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNe6j+sv9E+5tBh0GrrU+BorLQ1A== In-Reply-To: <1213377905.5961.26.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 17:33:59.0919 (UTC) FILETIME=[AA2397F0:01C8CD7B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3986; t=1213378440; x=1214242440; 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=20new=20charter=20text |Sender:=20 |To:=20Geoff=20Mulligan=20; bh=DMBEHO7BcnSrf1z3XH0Y7X7HVRwoFGMPEbvc9gJS5nk=; b=RBaT2VDmbqDTOKc/GBFzQwrgWrJeUmOjVvAunmnnxmkp+S6gvWXcogWRG1 wiDH153dPm9CXXdDwrTCnilMDRcqMsy3o86sOeH00MLVv23FqF+NBoPWK1cb j96eVi9384; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 6/13/08 7:25 PM, "Geoff Mulligan" wrote: > JP, > As I said previously, when Carsten, Mark and I reviewed the > comments/messages on the list it was clear that ND, Architecture, and > Security were priority items along with dealing with enhancements to > compression of non link local addresses and that there was clear support > to take these on within the working group. And now also the Use Cases > draft. > > I am less certain that there is consensus that fragment recovery is a > necessary working group item at this point. So I will ask the WG. > > As to your question about the Arch doc, I'm not sure that I understand > the question or the timing? The text for this hasn't changed for > months. It seems that there are members of the WG that want to see the > architectural description that includes both a mesh under solution and a > route over. How would you propose that we determine if there is a need > for both? My proposal would be to have a discussion on this topic first, trying to reach a consensus in the WG on whether or not we need to define a mesh-under solution. Once we have reached a consensus, then move on and start to incorporate it as part of the architecture ID or another document. In term of routing requirement ID, I would suggest: * To move ahead with the 6lowpan specific requirement ID, owned by the 6lowpan WG and reviewed by ROLL, * hold-off on the mesh-under routing requirements until we have reached a consensus. Makes sense ? Thanks. JP. > > geoff > > On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: >> Hi Geoff, >> >> Thanks for sending out the new revision. One question, one comment. >> >> Question: could you explain the rationale for leaving out the fragmentation >> recovery item? >> >> Comment: >> >> "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 such >> as operation with sleeping nodes, network components (both battery- >> and line-powered), addressing, and IPv4/IPv6 network connections. >> As a spin-off from that document, "6LoWPAN Routing Requirements" will >> describe 6LoWPAN-specific requirements on routing protocols used in >> 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. >> Both documents will be informational." >> >> I do not understand the rationale here: I think that we should first >> determine whether we both need a mesh-under *and* a route-over approach. You >> know my opinion: we have numerous examples in the past of such approaches >> that ALL failed for obvious technical reasons but this is my technical >> opinion. As far as 6lowpan is concerned, shouldn't we first have a >> discussion to get a consensus there ? *If* it turns out that both are >> needed, then add an introductory section in the architecture document >> pointing to the requirement document(s). >> >> Thus I would rather suggest not to list this as a WG item but to leave it >> out for the moment and continue to have the discussion until we have a >> consensus. Then at that point we could decide what to do. On the other hand, >> having a separate documents listing the 6LoWPAN specific routing >> requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot >> of sense. >> >> Thoughts ? >> >> Thanks. >> >> JP. >> >> >> >> On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: >> >>> With the input from the authors we've put the "Use Cases" back into the >>> text for the charter for the working group with a delivery date of Dec >>> 08. >>> >>> Attached is the NEW new charter text. >>> >>> geoff >>> >>> _______________________________________________ >>> 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 Jun 13 10:36:15 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 E30B53A68CE; Fri, 13 Jun 2008 10:36:15 -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 4796F3A68CE; Fri, 13 Jun 2008 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.318 X-Spam-Level: X-Spam-Status: No, score=-6.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 pOgmRvCByYb2; Fri, 13 Jun 2008 10:36:14 -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 1CF8F3A63D3; Fri, 13 Jun 2008 10:36:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204520400"; d="scan'208";a="10967431" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2008 13:36:46 -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 m5DHajYl002249; Fri, 13 Jun 2008 13:36:45 -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 m5DHajeH019716; Fri, 13 Jun 2008 17:36:45 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, 13 Jun 2008 13:36:45 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 17:36:45 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 19:36:44 +0200 From: JP Vasseur To: JP Vasseur , Geoff Mulligan , 6lowpan <6lowpan@ietf.org>, Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNbsoM3pueslg16k+6HMsPQSTpQQADUHlm In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 17:36:45.0722 (UTC) FILETIME=[0CF71FA0:01C8CD7C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2511; t=1213378605; x=1214242605; 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=20new=20charter=20text |Sender:=20 |To:=20JP=20Vasseur=20,=20Geoff=20Mulli gan=20,=0A=20=20=20=20=20=20=20=206lowp an=20<6lowpan@ietf.org>,=20; bh=p3KDLV9r4eNHryguRB8wQQ9X7ShPg0n0ZJIPuE5Vpng=; b=O2CCkYhlU12w10JKMIZ2P84IbvgxCZx+mfNebysU02FwirKPdSPn06FA7j OM2lL816TXUcA9cWEkN5MXQ5FCzMF0QsxG+NM0+ibajXuT0kg9NydEB4EOsz QcMGxJeuAD; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [6lowpan] New new charter text 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 Adding ROLL. On 6/13/08 6:01 PM, "JP Vasseur" wrote: > Hi Geoff, > > Thanks for sending out the new revision. One question, one comment. > > Question: could you explain the rationale for leaving out the fragmentation > recovery item? > > Comment: > > "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 such > as operation with sleeping nodes, network components (both battery- > and line-powered), addressing, and IPv4/IPv6 network connections. > As a spin-off from that document, "6LoWPAN Routing Requirements" will > describe 6LoWPAN-specific requirements on routing protocols used in > 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. > Both documents will be informational." > > I do not understand the rationale here: I think that we should first > determine whether we both need a mesh-under *and* a route-over approach. You > know my opinion: we have numerous examples in the past of such approaches > that ALL failed for obvious technical reasons but this is my technical > opinion. As far as 6lowpan is concerned, shouldn't we first have a > discussion to get a consensus there ? *If* it turns out that both are > needed, then add an introductory section in the architecture document > pointing to the requirement document(s). > > Thus I would rather suggest not to list this as a WG item but to leave it > out for the moment and continue to have the discussion until we have a > consensus. Then at that point we could decide what to do. On the other hand, > having a separate documents listing the 6LoWPAN specific routing > requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot > of sense. > > Thoughts ? > > Thanks. > > JP. > > > > On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: > >> With the input from the authors we've put the "Use Cases" back into the >> text for the charter for the working group with a delivery date of Dec >> 08. >> >> Attached is the NEW new charter text. >> >> geoff >> >> _______________________________________________ >> 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 Jun 13 10:36: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 6459F3A68CE; Fri, 13 Jun 2008 10:36: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 211AA3A63D3; Fri, 13 Jun 2008 10:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 AErv7ZhlHCdA; Fri, 13 Jun 2008 10:36:48 -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 C9C113A69FE; Fri, 13 Jun 2008 10:36:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204520400"; d="scan'208";a="10958318" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2008 13:37: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 m5DHbJ0v005552; Fri, 13 Jun 2008 13:37:19 -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 m5DHbJ8w020047; Fri, 13 Jun 2008 17:37:19 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, 13 Jun 2008 13:37:17 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 17:37:17 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 19:37:15 +0200 From: JP Vasseur To: JP Vasseur , Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNe6j+sv9E+5tBh0GrrU+BorLQ1AAAHVuq In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 17:37:17.0550 (UTC) FILETIME=[1FEFB0E0:01C8CD7C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4341; t=1213378639; x=1214242639; 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=20new=20charter=20text |Sender:=20 |To:=20JP=20Vasseur=20,=20Geoff=20Mulli gan=20; bh=IZMU2nMi02ptvGBX2DqS8hl7SaAYRZ/f+lVuQLPx/aM=; b=LXIj40Cvv29C9k6BGdbxVwt0Nv5UkLjJfDGJTUQTc8GJX6um47CJIyJIs8 uCA//hxSKgPD4zuTU0NiIonRLRiCqOC8jehRitSwJo7Ku+kATwZFvsgMKaIX 5wh4s8VyNq; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Adding ROLL. On 6/13/08 7:33 PM, "JP Vasseur" wrote: > Hi Geoff, > > > On 6/13/08 7:25 PM, "Geoff Mulligan" wrote: > >> JP, >> As I said previously, when Carsten, Mark and I reviewed the >> comments/messages on the list it was clear that ND, Architecture, and >> Security were priority items along with dealing with enhancements to >> compression of non link local addresses and that there was clear support >> to take these on within the working group. And now also the Use Cases >> draft. >> >> I am less certain that there is consensus that fragment recovery is a >> necessary working group item at this point. So I will ask the WG. >> >> As to your question about the Arch doc, I'm not sure that I understand >> the question or the timing? The text for this hasn't changed for >> months. It seems that there are members of the WG that want to see the >> architectural description that includes both a mesh under solution and a >> route over. How would you propose that we determine if there is a need >> for both? > > My proposal would be to have a discussion on this topic first, trying to > reach a consensus in the WG on whether or not we need to define a mesh-under > solution. Once we have reached a consensus, then move on and start to > incorporate it as part of the architecture ID or another document. > > In term of routing requirement ID, I would suggest: > * To move ahead with the 6lowpan specific requirement ID, owned by the > 6lowpan WG and reviewed by ROLL, > * hold-off on the mesh-under routing requirements until we have reached a > consensus. > > Makes sense ? > > Thanks. > > JP. > >> >> geoff >> >> On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: >>> Hi Geoff, >>> >>> Thanks for sending out the new revision. One question, one comment. >>> >>> Question: could you explain the rationale for leaving out the fragmentation >>> recovery item? >>> >>> Comment: >>> >>> "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 such >>> as operation with sleeping nodes, network components (both battery- >>> and line-powered), addressing, and IPv4/IPv6 network connections. >>> As a spin-off from that document, "6LoWPAN Routing Requirements" will >>> describe 6LoWPAN-specific requirements on routing protocols used in >>> 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. >>> Both documents will be informational." >>> >>> I do not understand the rationale here: I think that we should first >>> determine whether we both need a mesh-under *and* a route-over approach. You >>> know my opinion: we have numerous examples in the past of such approaches >>> that ALL failed for obvious technical reasons but this is my technical >>> opinion. As far as 6lowpan is concerned, shouldn't we first have a >>> discussion to get a consensus there ? *If* it turns out that both are >>> needed, then add an introductory section in the architecture document >>> pointing to the requirement document(s). >>> >>> Thus I would rather suggest not to list this as a WG item but to leave it >>> out for the moment and continue to have the discussion until we have a >>> consensus. Then at that point we could decide what to do. On the other hand, >>> having a separate documents listing the 6LoWPAN specific routing >>> requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot >>> of sense. >>> >>> Thoughts ? >>> >>> Thanks. >>> >>> JP. >>> >>> >>> >>> On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: >>> >>>> With the input from the authors we've put the "Use Cases" back into the >>>> text for the charter for the working group with a delivery date of Dec >>>> 08. >>>> >>>> Attached is the NEW new charter text. >>>> >>>> geoff >>>> >>>> _______________________________________________ >>>> 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 Jun 13 10:47:02 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 987A63A690F; Fri, 13 Jun 2008 10:47:02 -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 A1A503A690F for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 10:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.437, 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 1hICfexA6tF7 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 10:46:59 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 0B27D3A68CE for <6lowpan@ietf.org>; Fri, 13 Jun 2008 10:46:58 -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 m5DHlU6K008103; Fri, 13 Jun 2008 11:47:30 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Fri, 13 Jun 2008 11:47:26 -0600 Message-Id: <1213379246.5961.42.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 So do think that the text of the Arch doc item needs to be changed or are you thinking that it arch doc item needs to be removed completely until we have the mesh-under vs router over discussion? geoff On Fri, 2008-06-13 at 19:33 +0200, JP Vasseur wrote: > Hi Geoff, > > > On 6/13/08 7:25 PM, "Geoff Mulligan" wrote: > > > JP, > > As I said previously, when Carsten, Mark and I reviewed the > > comments/messages on the list it was clear that ND, Architecture, and > > Security were priority items along with dealing with enhancements to > > compression of non link local addresses and that there was clear support > > to take these on within the working group. And now also the Use Cases > > draft. > > > > I am less certain that there is consensus that fragment recovery is a > > necessary working group item at this point. So I will ask the WG. > > > > As to your question about the Arch doc, I'm not sure that I understand > > the question or the timing? The text for this hasn't changed for > > months. It seems that there are members of the WG that want to see the > > architectural description that includes both a mesh under solution and a > > route over. How would you propose that we determine if there is a need > > for both? > > My proposal would be to have a discussion on this topic first, trying to > reach a consensus in the WG on whether or not we need to define a mesh-under > solution. Once we have reached a consensus, then move on and start to > incorporate it as part of the architecture ID or another document. > > In term of routing requirement ID, I would suggest: > * To move ahead with the 6lowpan specific requirement ID, owned by the > 6lowpan WG and reviewed by ROLL, > * hold-off on the mesh-under routing requirements until we have reached a > consensus. > > Makes sense ? > > Thanks. > > JP. > > > > > geoff > > > > On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: > >> Hi Geoff, > >> > >> Thanks for sending out the new revision. One question, one comment. > >> > >> Question: could you explain the rationale for leaving out the fragmentation > >> recovery item? > >> > >> Comment: > >> > >> "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 such > >> as operation with sleeping nodes, network components (both battery- > >> and line-powered), addressing, and IPv4/IPv6 network connections. > >> As a spin-off from that document, "6LoWPAN Routing Requirements" will > >> describe 6LoWPAN-specific requirements on routing protocols used in > >> 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. > >> Both documents will be informational." > >> > >> I do not understand the rationale here: I think that we should first > >> determine whether we both need a mesh-under *and* a route-over approach. You > >> know my opinion: we have numerous examples in the past of such approaches > >> that ALL failed for obvious technical reasons but this is my technical > >> opinion. As far as 6lowpan is concerned, shouldn't we first have a > >> discussion to get a consensus there ? *If* it turns out that both are > >> needed, then add an introductory section in the architecture document > >> pointing to the requirement document(s). > >> > >> Thus I would rather suggest not to list this as a WG item but to leave it > >> out for the moment and continue to have the discussion until we have a > >> consensus. Then at that point we could decide what to do. On the other hand, > >> having a separate documents listing the 6LoWPAN specific routing > >> requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot > >> of sense. > >> > >> Thoughts ? > >> > >> Thanks. > >> > >> JP. > >> > >> > >> > >> On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: > >> > >>> With the input from the authors we've put the "Use Cases" back into the > >>> text for the charter for the working group with a delivery date of Dec > >>> 08. > >>> > >>> Attached is the NEW new charter text. > >>> > >>> geoff > >>> > >>> _______________________________________________ > >>> 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 Jun 13 11:02: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 C190C3A698D; Fri, 13 Jun 2008 11:02: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 31DE03A690F for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 DTw2lxfOUpya for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:02:56 -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 038443A6890 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 11:02:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,640,1204531200"; d="scan'208";a="79583838" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2008 11:03:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5DI3Swh010823; Fri, 13 Jun 2008 11:03:28 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m5DI3IMB027146; Fri, 13 Jun 2008 18:03:28 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, 13 Jun 2008 14:03:26 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 18:03:26 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 20:03:25 +0200 From: JP Vasseur To: Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNf8Y1tqCUh10BNk+R8802IeNhGA== In-Reply-To: <1213379246.5961.42.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 18:03:26.0952 (UTC) FILETIME=[C75F6E80:01C8CD7F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4719; t=1213380208; x=1214244208; 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:=20Re=3A=20[6lowpan]=20New=20new=20charter=20text |Sender:=20; bh=EMnIEZwdWw52oiDOQgu+Wu5QcskiI0TwW76QmltCNxw=; b=ZjaK49AG3SlIw3NAOw7sguc3GgORTwVaUUHrAlckF0kfipbpaQbs8bDzVx /sy/vpSoc6Ve1s1rzg1G8BKNN8c36+vvMkTH4ufZUUGjq17Kjon3Nn+RKhOW ZaE3/v/VWDpWwDjC6LEJBbAIgFhNsrAJecuWPwx29CEH/VVRcF76Q=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 would suggest to reword the text related to the architecture ID and remove the mesh-under/route over discussion for the moment. JP. On 6/13/08 7:47 PM, "Geoff Mulligan" wrote: > So do think that the text of the Arch doc item needs to be changed or > are you thinking that it arch doc item needs to be removed completely > until we have the mesh-under vs router over discussion? > > geoff > > On Fri, 2008-06-13 at 19:33 +0200, JP Vasseur wrote: >> Hi Geoff, >> >> >> On 6/13/08 7:25 PM, "Geoff Mulligan" wrote: >> >>> JP, >>> As I said previously, when Carsten, Mark and I reviewed the >>> comments/messages on the list it was clear that ND, Architecture, and >>> Security were priority items along with dealing with enhancements to >>> compression of non link local addresses and that there was clear support >>> to take these on within the working group. And now also the Use Cases >>> draft. >>> >>> I am less certain that there is consensus that fragment recovery is a >>> necessary working group item at this point. So I will ask the WG. >>> >>> As to your question about the Arch doc, I'm not sure that I understand >>> the question or the timing? The text for this hasn't changed for >>> months. It seems that there are members of the WG that want to see the >>> architectural description that includes both a mesh under solution and a >>> route over. How would you propose that we determine if there is a need >>> for both? >> >> My proposal would be to have a discussion on this topic first, trying to >> reach a consensus in the WG on whether or not we need to define a mesh-under >> solution. Once we have reached a consensus, then move on and start to >> incorporate it as part of the architecture ID or another document. >> >> In term of routing requirement ID, I would suggest: >> * To move ahead with the 6lowpan specific requirement ID, owned by the >> 6lowpan WG and reviewed by ROLL, >> * hold-off on the mesh-under routing requirements until we have reached a >> consensus. >> >> Makes sense ? >> >> Thanks. >> >> JP. >> >>> >>> geoff >>> >>> On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: >>>> Hi Geoff, >>>> >>>> Thanks for sending out the new revision. One question, one comment. >>>> >>>> Question: could you explain the rationale for leaving out the fragmentation >>>> recovery item? >>>> >>>> Comment: >>>> >>>> "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 such >>>> as operation with sleeping nodes, network components (both battery- >>>> and line-powered), addressing, and IPv4/IPv6 network connections. >>>> As a spin-off from that document, "6LoWPAN Routing Requirements" will >>>> describe 6LoWPAN-specific requirements on routing protocols used in >>>> 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. >>>> Both documents will be informational." >>>> >>>> I do not understand the rationale here: I think that we should first >>>> determine whether we both need a mesh-under *and* a route-over approach. >>>> You >>>> know my opinion: we have numerous examples in the past of such approaches >>>> that ALL failed for obvious technical reasons but this is my technical >>>> opinion. As far as 6lowpan is concerned, shouldn't we first have a >>>> discussion to get a consensus there ? *If* it turns out that both are >>>> needed, then add an introductory section in the architecture document >>>> pointing to the requirement document(s). >>>> >>>> Thus I would rather suggest not to list this as a WG item but to leave it >>>> out for the moment and continue to have the discussion until we have a >>>> consensus. Then at that point we could decide what to do. On the other >>>> hand, >>>> having a separate documents listing the 6LoWPAN specific routing >>>> requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot >>>> of sense. >>>> >>>> Thoughts ? >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>> >>>> >>>> On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: >>>> >>>>> With the input from the authors we've put the "Use Cases" back into the >>>>> text for the charter for the working group with a delivery date of Dec >>>>> 08. >>>>> >>>>> Attached is the NEW new charter text. >>>>> >>>>> geoff >>>>> >>>>> _______________________________________________ >>>>> 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 Jun 13 11:10:02 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 59FF33A682E; Fri, 13 Jun 2008 11:10:02 -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 0D4183A63D3 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 cHMDYT2L25je for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:09:59 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id CB2FD3A682E for <6lowpan@ietf.org>; Fri, 13 Jun 2008 11:09:59 -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 m5DIALs4008331; Fri, 13 Jun 2008 12:10:21 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Fri, 13 Jun 2008 12:10:17 -0600 Message-Id: <1213380617.5961.64.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Rm9sa3MsCiAgSSB0aGluayB0aGF0IG91ciBjaGFydGVyIHdpbGwgYmUgZGlzY3Vzc2VkIG9uIHRo ZSBuZXh0IElFU0cgdGVsZWNoYXQsCm5leHQgVGh1cnNkYXkhICBXZSBuZWVkIHRvIGdldCB0aGUg dGV4dCBjb3JyZWN0IGFuZCB0byBNYXJrIFdFTEwgQkVGT1JFCnRoZSBUaHVyc2RheS4KCkpQIGhh cyBzdWdnZXN0ZWQgYSBjaGFuZ2UgdG8gdGhlIHdvcmRpbmcgZm9yIHRoZSBBcmNoIERvYyBkcmFm dCBpdGVtLgpQbGVhc2Ugc2VuZCBhIG1lc3NhZ2UgaW5kaWNhdGluZyB5b3VyIHRob3VnaHRzIGFi b3V0IHRoZSBjaGFuZ2UuCgpXaGlsZSBJIHRob3VnaHQgdGhhdCB3ZSBkaWQgaGF2ZSBjb25zZW5z dXMgYXJvdW5kIHRoaXMgcGFydGljdWxhciBpdGVtIEkKd291bGQgbGlrZSB0byBtYWtlIHN1cmUg dGhhdCB3ZSBkby4KCu+7v1Nob3VsZCB3ZSByZW1vdmUgdGhlIHRleHQgYWJvdXQgbWVzaC11bmRl ciBhbmQgcm91dGUtb3Zlcj8KU2hvdWxkIHdlIGxlYXZlIHRoZSB0ZXh0IGFzIGl0IGlzPwoKCWdl b2ZmCiAKCk9uIEZyaSwgMjAwOC0wNi0xMyBhdCAyMDowMyArMDIwMCwgSlAgVmFzc2V1ciB3cm90 ZToKPiBJIHdvdWxkIHN1Z2dlc3QgdG8gcmV3b3JkIHRoZSB0ZXh0IHJlbGF0ZWQgdG8gdGhlIGFy Y2hpdGVjdHVyZSBJRCBhbmQgcmVtb3ZlCj4gdGhlIG1lc2gtdW5kZXIvcm91dGUgb3ZlciBkaXNj dXNzaW9uIGZvciB0aGUgbW9tZW50Lgo+IAo+IEpQLgo+IAo+IAo+IE9uIDYvMTMvMDggNzo0NyBQ TSwgIkdlb2ZmIE11bGxpZ2FuIiA8aWV0ZjA4QG11bGxpZ2FuLm9yZz4gd3JvdGU6Cj4gCj4gPiBT byBkbyB0aGluayB0aGF0IHRoZSB0ZXh0IG9mIHRoZSBBcmNoIGRvYyBpdGVtIG5lZWRzIHRvIGJl IGNoYW5nZWQgb3IKPiA+IGFyZSB5b3UgdGhpbmtpbmcgdGhhdCBpdCBhcmNoIGRvYyBpdGVtIG5l ZWRzIHRvIGJlIHJlbW92ZWQgY29tcGxldGVseQo+ID4gdW50aWwgd2UgaGF2ZSB0aGUgbWVzaC11 bmRlciB2cyByb3V0ZXIgb3ZlciBkaXNjdXNzaW9uPwo+ID4gCj4gPiBnZW9mZgo+ID4gCj4gPiBP biBGcmksIDIwMDgtMDYtMTMgYXQgMTk6MzMgKzAyMDAsIEpQIFZhc3NldXIgd3JvdGU6Cj4gPj4g SGkgR2VvZmYsCj4gPj4gCj4gPj4gCj4gPj4gT24gNi8xMy8wOCA3OjI1IFBNLCAiR2VvZmYgTXVs bGlnYW4iIDxpZXRmMDhAbXVsbGlnYW4ub3JnPiB3cm90ZToKPiA+PiAKPiA+Pj4gSlAsCj4gPj4+ ICAgQXMgSSBzYWlkIHByZXZpb3VzbHksIHdoZW4gQ2Fyc3RlbiwgTWFyayBhbmQgSSByZXZpZXdl ZCB0aGUKPiA+Pj4gY29tbWVudHMvbWVzc2FnZXMgb24gdGhlIGxpc3QgaXQgd2FzIGNsZWFyIHRo YXQgTkQsIEFyY2hpdGVjdHVyZSwgYW5kCj4gPj4+IFNlY3VyaXR5IHdlcmUgcHJpb3JpdHkgaXRl bXMgYWxvbmcgd2l0aCBkZWFsaW5nIHdpdGggZW5oYW5jZW1lbnRzIHRvCj4gPj4+IGNvbXByZXNz aW9uIG9mIG5vbiBsaW5rIGxvY2FsIGFkZHJlc3NlcyBhbmQgdGhhdCB0aGVyZSB3YXMgY2xlYXIg c3VwcG9ydAo+ID4+PiB0byB0YWtlIHRoZXNlIG9uIHdpdGhpbiB0aGUgd29ya2luZyBncm91cC4g QW5kIG5vdyBhbHNvIHRoZSBVc2UgQ2FzZXMKPiA+Pj4gZHJhZnQuCj4gPj4+IAo+ID4+PiBJIGFt IGxlc3MgY2VydGFpbiB0aGF0IHRoZXJlIGlzIGNvbnNlbnN1cyB0aGF0IGZyYWdtZW50IHJlY292 ZXJ5IGlzIGEKPiA+Pj4gbmVjZXNzYXJ5IHdvcmtpbmcgZ3JvdXAgaXRlbSBhdCB0aGlzIHBvaW50 LiAgU28gSSB3aWxsIGFzayB0aGUgV0cuCj4gPj4+IAo+ID4+PiBBcyB0byB5b3VyIHF1ZXN0aW9u IGFib3V0IHRoZSBBcmNoIGRvYywgSSdtIG5vdCBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kCj4gPj4+ IHRoZSBxdWVzdGlvbiBvciB0aGUgdGltaW5nPyAgVGhlIHRleHQgZm9yIHRoaXMgaGFzbid0IGNo YW5nZWQgZm9yCj4gPj4+IG1vbnRocy4gIEl0IHNlZW1zIHRoYXQgdGhlcmUgYXJlIG1lbWJlcnMg b2YgdGhlIFdHIHRoYXQgd2FudCB0byBzZWUgdGhlCj4gPj4+IGFyY2hpdGVjdHVyYWwgZGVzY3Jp cHRpb24gdGhhdCBpbmNsdWRlcyBib3RoIGEgbWVzaCB1bmRlciBzb2x1dGlvbiBhbmQgYQo+ID4+ PiByb3V0ZSBvdmVyLiAgSG93IHdvdWxkIHlvdSBwcm9wb3NlIHRoYXQgd2UgZGV0ZXJtaW5lIGlm IHRoZXJlIGlzIGEgbmVlZAo+ID4+PiBmb3IgYm90aD8KPiA+PiAKPiA+PiBNeSBwcm9wb3NhbCB3 b3VsZCBiZSB0byBoYXZlIGEgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljIGZpcnN0LCB0cnlpbmcg dG8KPiA+PiByZWFjaCBhIGNvbnNlbnN1cyBpbiB0aGUgV0cgb24gd2hldGhlciBvciBub3Qgd2Ug bmVlZCB0byBkZWZpbmUgYSBtZXNoLXVuZGVyCj4gPj4gc29sdXRpb24uIE9uY2Ugd2UgaGF2ZSBy ZWFjaGVkIGEgY29uc2Vuc3VzLCB0aGVuIG1vdmUgb24gYW5kIHN0YXJ0IHRvCj4gPj4gaW5jb3Jw b3JhdGUgaXQgYXMgcGFydCBvZiB0aGUgYXJjaGl0ZWN0dXJlIElEIG9yIGFub3RoZXIgZG9jdW1l bnQuCj4gPj4gCj4gPj4gSW4gdGVybSBvZiByb3V0aW5nIHJlcXVpcmVtZW50IElELCBJIHdvdWxk IHN1Z2dlc3Q6Cj4gPj4gKiBUbyBtb3ZlIGFoZWFkIHdpdGggdGhlIDZsb3dwYW4gc3BlY2lmaWMg cmVxdWlyZW1lbnQgSUQsIG93bmVkIGJ5IHRoZQo+ID4+IDZsb3dwYW4gV0cgYW5kIHJldmlld2Vk IGJ5IFJPTEwsCj4gPj4gKiBob2xkLW9mZiBvbiB0aGUgbWVzaC11bmRlciByb3V0aW5nIHJlcXVp cmVtZW50cyB1bnRpbCB3ZSBoYXZlIHJlYWNoZWQgYQo+ID4+IGNvbnNlbnN1cy4KPiA+PiAKPiA+ PiBNYWtlcyBzZW5zZSA/Cj4gPj4gCj4gPj4gVGhhbmtzLgo+ID4+IAo+ID4+IEpQLgo+ID4+IAo+ ID4+PiAKPiA+Pj4gZ2VvZmYKPiA+Pj4gCj4gPj4+IE9uIEZyaSwgMjAwOC0wNi0xMyBhdCAxODow MSArMDIwMCwgSlAgVmFzc2V1ciB3cm90ZToKPiA+Pj4+IEhpIEdlb2ZmLAo+ID4+Pj4gCj4gPj4+ PiBUaGFua3MgZm9yIHNlbmRpbmcgb3V0IHRoZSBuZXcgcmV2aXNpb24uIE9uZSBxdWVzdGlvbiwg b25lIGNvbW1lbnQuCj4gPj4+PiAKPiA+Pj4+IFF1ZXN0aW9uOiBjb3VsZCB5b3UgZXhwbGFpbiB0 aGUgcmF0aW9uYWxlIGZvciBsZWF2aW5nIG91dCB0aGUgZnJhZ21lbnRhdGlvbgo+ID4+Pj4gcmVj b3ZlcnkgaXRlbT8KPiA+Pj4+IAo+ID4+Pj4gQ29tbWVudDoKPiA+Pj4+IAo+ID4+Pj4gIjMuIFBy b2R1Y2UgIjZMb1dQQU4gQXJjaGl0ZWN0dXJlIiB0byBkZXNjcmliZSB0aGUgZGVzaWduIGFuZAo+ ID4+Pj4gaW1wbGVtZW50YXRpb24gb2YgNkxvV1BBTiBuZXR3b3Jrcy4gIFRoaXMgZG9jdW1lbnQg d2lsbCBjb3ZlciB0aGUKPiA+Pj4+IGNvbmNlcHRzIG9mICJNZXNoIFVuZGVyIiBhbmQgIlJvdXRl IE92ZXIiLCA4MDIuMTUuNCBkZXNpZ24gaXNzdWVzIHN1Y2gKPiA+Pj4+IGFzIG9wZXJhdGlvbiB3 aXRoIHNsZWVwaW5nIG5vZGVzLCBuZXR3b3JrIGNvbXBvbmVudHMgKGJvdGggYmF0dGVyeS0KPiA+ Pj4+IGFuZCBsaW5lLXBvd2VyZWQpLCBhZGRyZXNzaW5nLCBhbmQgSVB2NC9JUHY2IG5ldHdvcmsg Y29ubmVjdGlvbnMuCj4gPj4+PiBBcyBhIHNwaW4tb2ZmIGZyb20gdGhhdCBkb2N1bWVudCwgIjZM b1dQQU4gUm91dGluZyBSZXF1aXJlbWVudHMiIHdpbGwKPiA+Pj4+IGRlc2NyaWJlIDZMb1dQQU4t c3BlY2lmaWMgcmVxdWlyZW1lbnRzIG9uIHJvdXRpbmcgcHJvdG9jb2xzIHVzZWQgaW4KPiA+Pj4+ IDZMb1dQQU5zLCBhZGRyZXNzaW5nIGJvdGggdGhlICJyb3V0ZS1vdmVyIiBhbmQgIm1lc2gtdW5k ZXIiIGFwcHJvYWNoLgo+ID4+Pj4gQm90aCBkb2N1bWVudHMgd2lsbCBiZSBpbmZvcm1hdGlvbmFs LiIKPiA+Pj4+IAo+ID4+Pj4gSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGhlcmU6 IEkgdGhpbmsgdGhhdCB3ZSBzaG91bGQgZmlyc3QKPiA+Pj4+IGRldGVybWluZSB3aGV0aGVyIHdl IGJvdGggbmVlZCBhIG1lc2gtdW5kZXIgKmFuZCogYSByb3V0ZS1vdmVyIGFwcHJvYWNoLgo+ID4+ Pj4gWW91Cj4gPj4+PiBrbm93IG15IG9waW5pb246IHdlIGhhdmUgbnVtZXJvdXMgZXhhbXBsZXMg aW4gdGhlIHBhc3Qgb2Ygc3VjaCBhcHByb2FjaGVzCj4gPj4+PiB0aGF0IEFMTCBmYWlsZWQgZm9y IG9idmlvdXMgdGVjaG5pY2FsIHJlYXNvbnMgYnV0IHRoaXMgaXMgbXkgdGVjaG5pY2FsCj4gPj4+ PiBvcGluaW9uLiBBcyBmYXIgYXMgNmxvd3BhbiBpcyBjb25jZXJuZWQsIHNob3VsZG4ndCB3ZSBm aXJzdCBoYXZlIGEKPiA+Pj4+IGRpc2N1c3Npb24gdG8gZ2V0IGEgY29uc2Vuc3VzIHRoZXJlID8g KklmKiBpdCB0dXJucyBvdXQgdGhhdCBib3RoIGFyZQo+ID4+Pj4gbmVlZGVkLCB0aGVuIGFkZCBh biBpbnRyb2R1Y3Rvcnkgc2VjdGlvbiBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50Cj4gPj4+ PiBwb2ludGluZyB0byB0aGUgcmVxdWlyZW1lbnQgZG9jdW1lbnQocykuCj4gPj4+PiAKPiA+Pj4+ IFRodXMgSSB3b3VsZCByYXRoZXIgc3VnZ2VzdCBub3QgdG8gbGlzdCB0aGlzIGFzIGEgV0cgaXRl bSBidXQgdG8gbGVhdmUgaXQKPiA+Pj4+IG91dCBmb3IgdGhlIG1vbWVudCBhbmQgY29udGludWUg dG8gaGF2ZSB0aGUgZGlzY3Vzc2lvbiB1bnRpbCB3ZSBoYXZlIGEKPiA+Pj4+IGNvbnNlbnN1cy4g VGhlbiBhdCB0aGF0IHBvaW50IHdlIGNvdWxkIGRlY2lkZSB3aGF0IHRvIGRvLiBPbiB0aGUgb3Ro ZXIKPiA+Pj4+IGhhbmQsCj4gPj4+PiBoYXZpbmcgYSBzZXBhcmF0ZSBkb2N1bWVudHMgbGlzdGlu ZyB0aGUgNkxvV1BBTiBzcGVjaWZpYyByb3V0aW5nCj4gPj4+PiByZXF1aXJlbWVudHMsIG93bmVk IGJ5IHRoZSA2bG93cGFuIFdHIGFuZCByZXZpZXdlZCBieSBST0xMIHdvdWxkIG1ha2UgYSBsb3QK PiA+Pj4+IG9mIHNlbnNlLgo+ID4+Pj4gCj4gPj4+PiBUaG91Z2h0cyA/Cj4gPj4+PiAKPiA+Pj4+ IFRoYW5rcy4KPiA+Pj4+IAo+ID4+Pj4gSlAuCj4gPj4+PiAKPiA+Pj4+IAo+ID4+Pj4gCj4gPj4+ PiBPbiA2LzEzLzA4IDM6NTkgUE0sICJHZW9mZiBNdWxsaWdhbiIgPGlldGYwOEBtdWxsaWdhbi5v cmc+IHdyb3RlOgo+ID4+Pj4gCj4gPj4+Pj4gV2l0aCB0aGUgaW5wdXQgZnJvbSB0aGUgYXV0aG9y cyB3ZSd2ZSBwdXQgdGhlICJVc2UgQ2FzZXMiIGJhY2sgaW50byB0aGUKPiA+Pj4+PiB0ZXh0IGZv ciB0aGUgY2hhcnRlciBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgd2l0aCBhIGRlbGl2ZXJ5IGRhdGUg b2YgRGVjCj4gPj4+Pj4gMDguCj4gPj4+Pj4gCj4gPj4+Pj4gQXR0YWNoZWQgaXMgdGhlIE5FVyBu ZXcgY2hhcnRlciB0ZXh0Lgo+ID4+Pj4+IAo+ID4+Pj4+IGdlb2ZmCj4gPj4+Pj4gCj4gPj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiA+Pj4+PiA2 bG93cGFuIG1haWxpbmcgbGlzdAo+ID4+Pj4+IDZsb3dwYW5AaWV0Zi5vcmcKPiA+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4KPiA+Pj4gCj4gPiAKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCjZsb3dwYW4gbWFp bGluZyBsaXN0CjZsb3dwYW5AaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby82bG93cGFuCg== From 6lowpan-bounces@ietf.org Fri Jun 13 11:17: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 E35B03A68BD; Fri, 13 Jun 2008 11:17: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 EEBE83A63D3 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 yUahL-Nx9fLH for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:17:14 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 286EB3A689E for <6lowpan@ietf.org>; Fri, 13 Jun 2008 11:17:14 -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 m5DIHkCW008377 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 12:17:46 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Date: Fri, 13 Jun 2008 12:17:42 -0600 Message-Id: <1213381062.5961.75.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [6lowpan] New new charter text (resend) 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 77u/Rm9sa3MsIAogWyBJIGRvbid0IGtub3cgd2hhdHMgdXAgd2l0aCB0aGUgZm9ybWF0dGluZyBz byBJJ20gcmVzZW5kaW5nIHRoaXMKbWVzc2FnZS4gXQoKIEkgdGhpbmsgdGhhdCBvdXIgY2hhcnRl ciB3aWxsIGJlIGRpc2N1c3NlZCBvbiB0aGUgbmV4dCBJRVNHIHRlbGVjaGF0LApuZXh0IFRodXJz ZGF5ISAgV2UgbmVlZCB0byBnZXQgdGhlIHRleHQgY29ycmVjdCBhbmQgdG8gTWFyayBXRUxMIEJF Rk9SRQp0aGUgVGh1cnNkYXkuCgpKUCBoYXMgc3VnZ2VzdGVkIGEgY2hhbmdlIHRvIHRoZSB3b3Jk aW5nIGZvciB0aGUgQXJjaCBEb2MgZHJhZnQgaXRlbS4KClBsZWFzZSBzZW5kIGEgbWVzc2FnZSBp bmRpY2F0aW5nIHlvdXIgdGhvdWdodHMgYWJvdXQgdGhlIGNoYW5nZS4KCldoaWxlIEkgdGhvdWdo dCB0aGF0IHdlIGRpZCBoYXZlIGNvbnNlbnN1cyBhcm91bmQgdGhpcyBwYXJ0aWN1bGFyIGl0ZW0g SQp3b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSB0aGF0IHdlIGRvLgoK77u/U2hvdWxkIHdlIHJlbW92 ZSB0aGUgdGV4dCBhYm91dCBtZXNoLXVuZGVyIGFuZCByb3V0ZS1vdmVyPwoKU2hvdWxkIHdlIGxl YXZlIHRoZSB0ZXh0IGFzIGl0IGlzPwoKICAgICAgICBnZW9mZiAKCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo2bG93cGFuIG1haWxpbmcgbGlzdAo2bG93 cGFuQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxvd3Bh bgo= From 6lowpan-bounces@ietf.org Fri Jun 13 11:22:02 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 345C63A682E; Fri, 13 Jun 2008 11:22:02 -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 D57493A6851 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:22:00 -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 rF9iHk7F1qg3 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:21:57 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 039073A6774 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5DIM9T4022086; Fri, 13 Jun 2008 20:22:12 +0200 (CEST) Message-Id: <665A94BE-F894-4E68-9C5B-4D4CE2F1A734@tzi.org> From: Carsten Bormann To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 20:22:07 +0200 References: X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 would suggest to reword the text related to the architecture ID > and remove > the mesh-under/route over discussion for the moment. There appears to be some confusion here. The text about the architecture document says: > This document will cover the concepts of "Mesh Under" and "Route > Over", Any architecture document that does not define these terms would be a rather strange architecture document indeed. >>> My proposal would be to have a discussion on this topic first, >>> trying to >>> reach a consensus in the WG on whether or not we need to define a >>> mesh-under >>> solution. Why would we need such a consensus in the WG with respect to the current charter text? Right now the charter does not ask require the WG to "define a mesh- under solution", and I'm pretty sure we have had rough consensus for a while that we aren't in a position right now to define the mesh routing protocol part of that solution. So the charter proposals on the table always have left that part out. I'm a bit tired of reopening this specific discussion; it is quite clear now that there always will be L2 meshing and L3-only routing camps. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jun 13 11:25:52 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 672EC3A682E; Fri, 13 Jun 2008 11:25:52 -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 DA8493A6774 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPSMG2jYaaXf for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 11:25:50 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A31A13A63D3 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 11:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5DIPvbx023618; Fri, 13 Jun 2008 20:26:00 +0200 (CEST) Message-Id: <5B3E1634-7060-4E64-85E9-EC7AC5F039D5@tzi.org> From: Carsten Bormann To: Geoff Mulligan In-Reply-To: <1213377905.5961.26.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 13 Jun 2008 20:25:55 +0200 References: <1213377905.5961.26.camel@dellx1> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Jun 13 2008, at 19:25, Geoff Mulligan wrote: > I am less certain that there is consensus that fragment recovery is a > necessary working group item at this point. So I will ask the WG. There certainly was some interest in this optimization. I'm not feeling comfortable at this point that we can reach consensus on a solution within the time frame of this charter round. So my proposal would be to keep discussing this optimization (as we undoubtedly will do with other optimizations as well), maybe converge quickly, and then decide whether we ask for a charter extensions this round or add it to the next charter. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Jun 13 12:14:15 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 61BF43A6845; Fri, 13 Jun 2008 12:14:15 -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 3D3D23A6845 for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 12:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij5ACFgd0MIZ for <6lowpan@core3.amsl.com>; Fri, 13 Jun 2008 12:14:13 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 8AA993A6804 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 12:14:13 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so4590228wfd.31 for <6lowpan@ietf.org>; Fri, 13 Jun 2008 12:14:46 -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=H9S705XcN1Obu/J5UJMaCEXxF/M+00dn3HtG4/8J7Kk=; b=uYM9jrQRAJiUeHhU2L9s6beynELcraRRaPiCbcltTSJNaaDpJCwPtH7+cUSD4m5CEH XhfRs0eKepwfN9xRFrUdbWCihi/ZBNR28casHkvTqviEOrCi2ncU3P7anEaDjUGoYjuO ++Maj+CCQ2ngnkQyPHTea4mE7mh5uXgx/UjxM= 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=M/CGFe4zCBvYYwFH0DcrJrw/T7wgswbtytbaFuu4iqptjxsn2rlB+uvRJJHRFIpsIv N+sbxAKQxvVSHXGebhp7+CvS1BGr04p/34EeGVtq5lM5anUzHwoVNtN0O2Q9TllaJ7k6 MNcivPgp+0ZRYSyNZptdXTlll38VFVhjLtFHA= Received: by 10.142.232.20 with SMTP id e20mr1214432wfh.134.1213384486227; Fri, 13 Jun 2008 12:14:46 -0700 (PDT) Received: by 10.142.78.9 with HTTP; Fri, 13 Jun 2008 12:14:46 -0700 (PDT) Message-ID: <43b91d370806131214k26a3f9b3yc1d78d7f836764d0@mail.gmail.com> Date: Fri, 13 Jun 2008 12:14:46 -0700 From: "Samita Chakrabarti" To: "Carsten Bormann" In-Reply-To: <665A94BE-F894-4E68-9C5B-4D4CE2F1A734@tzi.org> MIME-Version: 1.0 Content-Disposition: inline References: <665A94BE-F894-4E68-9C5B-4D4CE2F1A734@tzi.org> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Carsten/Geoff: > > The text about the architecture document says: > >> This document will cover the concepts of "Mesh Under" and "Route >> Over", > > Any architecture document that does not define these terms would be a > rather strange architecture document indeed. > I agree 100% here. The current text on the charter regarding describing the concept of "Mesh Under" and "Route over" are very important. I am sure there are folks in the wg who can handle texts for the respective sections. Please keep them. Also, it seems that Arch document would be a good place to include a few use-case scenarios too for completeness. Thanks, -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jun 14 01:46: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 A93403A69CB; Sat, 14 Jun 2008 01:46: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 D37793A6A0C for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 01:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 1h+OTPi5M0zR for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 01:46:53 -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 674D93A69CB for <6lowpan@ietf.org>; Sat, 14 Jun 2008 01:46:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,643,1204520400"; d="scan'208";a="11007295" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2008 04:47: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 m5E8lJd4002209; Sat, 14 Jun 2008 04:47:19 -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 m5E8lJAP026653; Sat, 14 Jun 2008 08:47:19 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, 14 Jun 2008 04:47:18 -0400 Received: from 10.21.147.146 ([10.21.147.146]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 14 Jun 2008 08:46:21 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 14 Jun 2008 10:46:05 +0200 From: JP Vasseur To: Samita Chakrabarti , Carsten Bormann Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjN+xTUbFYqJg44HkW8AD1CZQ9Cog== In-Reply-To: <43b91d370806131214k26a3f9b3yc1d78d7f836764d0@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jun 2008 08:47:18.0961 (UTC) FILETIME=[40E9D210:01C8CDFB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1112; t=1213433239; x=1214297239; 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=20new=20charter=20text |Sender:=20 |To:=20Samita=20Chakrabarti=20,=20Carst en=20Bormann=20; bh=Mdkz/Cs3/i/p748hEJE+oOEFyND9G9Vxb4xV9I/B0QA=; b=fKzzlbzfz/DhZsYD0Eqs4+R0vfcaawBsZv0pdgnDV4QMrGtKD43fBylgJL WaC1sp1qwP/gsB4kM+ZV7jV5HLyoCHXWOzBdQcgb5VgwYCC3ovT5ayIcEZBr MCtP+C9J6D; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 6/13/08 9:14 PM, "Samita Chakrabarti" wrote: > Hi Carsten/Geoff: > >> >> The text about the architecture document says: >> >>> This document will cover the concepts of "Mesh Under" and "Route >>> Over", >> >> Any architecture document that does not define these terms would be a >> rather strange architecture document indeed. >> > > I agree 100% here. The current text on the charter regarding > describing the concept of "Mesh Under" and "Route over" are very > important. I am sure there are folks in the wg who can handle texts > for the respective sections. Please keep them. > Remember this is not a text book (referring to your comment several IETF ago Carsten) but a document that describes the 6lowpan architecture that does not specify route over and where mesh-under is not yet a given ... > Also, it seems that Arch document would be a good place to include a > few use-case scenarios too for completeness. You might have noticed that there is a separate WG item for this. Thanks. JP. > > > > Thanks, > -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jun 14 02:32: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 7B35F3A69E5; Sat, 14 Jun 2008 02:32: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 66C693A6A02 for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 02:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 hcVj2FrZaaBq for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 02:32:49 -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 531743A697F for <6lowpan@ietf.org>; Sat, 14 Jun 2008 02:32:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,643,1204520400"; d="scan'208";a="11008645" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2008 05:33:23 -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 m5E9XNbJ009030; Sat, 14 Jun 2008 05:33:23 -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 m5E9XN62003744; Sat, 14 Jun 2008 09:33: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); Sat, 14 Jun 2008 05:33:23 -0400 Received: from 10.21.147.146 ([10.21.147.146]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 14 Jun 2008 09:30:50 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 14 Jun 2008 11:30:47 +0200 From: JP Vasseur To: Carsten Bormann Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjOAVNsS8+/cIe0z0i2OaEgdy7C8Q== In-Reply-To: <665A94BE-F894-4E68-9C5B-4D4CE2F1A734@tzi.org> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jun 2008 09:33:23.0178 (UTC) FILETIME=[B083DCA0:01C8CE01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1965; t=1213436003; x=1214300003; 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=20new=20charter=20text |Sender:=20 |To:=20Carsten=20Bormann=20; bh=bUiWDiH+Jt+JG3exMin3r8ZD6gGB0ag+p20y8zCWRFc=; b=LbRUWwShHc6ZNGk6Yx0aa5hyxMf/jYba3NDcpgyOHGD+fokNgVHgtsnLII UlBBrMnL9oajAsGWmTarTaH+6XGo3GgekfDyGn1nymZ6C7dKu7/yoYLYTaUz Ed+0cvYoqd; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Carsten, On 6/13/08 8:22 PM, "Carsten Bormann" wrote: >> I would suggest to reword the text related to the architecture ID >> and remove >> the mesh-under/route over discussion for the moment. > > There appears to be some confusion here. > > The text about the architecture document says: > >> This document will cover the concepts of "Mesh Under" and "Route >> Over", > > Any architecture document that does not define these terms would be a > rather strange architecture document indeed. Well hopefully we do not need to define what Routing means at the IETF ;-) and the notion of mesh-under is a form of routing at layer 2 (not really in the scope of the IETF). Since this is a contentious debate to say the least, I was proposing to deal with it as a separate item for the moment so as to quickly move forward with the architecture document where lot of work is still needed. > >>>> My proposal would be to have a discussion on this topic first, >>>> trying to >>>> reach a consensus in the WG on whether or not we need to define a >>>> mesh-under >>>> solution. > > Why would we need such a consensus in the WG with respect to the > current charter text? > Right now the charter does not ask require the WG to "define a mesh- > under solution", and I'm pretty sure we have had rough consensus for a > while that we aren't in a position right now to define the mesh > routing protocol part of that solution. Great. > So the charter proposals on the table always have left that part out. > > I'm a bit tired of reopening this specific discussion; it is quite > clear now that there always will be L2 meshing and L3-only routing > camps. This is why I was suggesting to leave it out for the moment in order to quickly move forward on other key topics and then try to reach a final consensus documented in the separate ID. Thanks. JP. JP. > > Gruesse, Carsten > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jun 14 02:32: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 A6EC03A6A0D; Sat, 14 Jun 2008 02:32: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 B6B0F3A697F for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 02:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 5M3xPneNVL5v for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 02:32:50 -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 B24063A69E5 for <6lowpan@ietf.org>; Sat, 14 Jun 2008 02:32:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,643,1204520400"; d="scan'208";a="11008646" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2008 05:33:23 -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 m5E9XNQp010562; Sat, 14 Jun 2008 05:33: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 m5E9XNoZ008548; Sat, 14 Jun 2008 09:33: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); Sat, 14 Jun 2008 05:33:23 -0400 Received: from 10.21.147.146 ([10.21.147.146]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Sat, 14 Jun 2008 09:31:04 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sat, 14 Jun 2008 11:31:03 +0200 From: JP Vasseur To: Carsten Bormann , Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjOAVz24KQgEG2pkUanZAm1aQqwsw== In-Reply-To: <5B3E1634-7060-4E64-85E9-EC7AC5F039D5@tzi.org> Mime-version: 1.0 X-OriginalArrivalTime: 14 Jun 2008 09:33:23.0397 (UTC) FILETIME=[B0A54750:01C8CE01] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=768; t=1213436003; x=1214300003; 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=20new=20charter=20text |Sender:=20 |To:=20Carsten=20Bormann=20,=20Geoff=20Mullig an=20; bh=ftoUERN1nxL2zDzCnDRWrlGplTlLQFENIkezY8SaQk4=; b=E05ws4JxbfQGgGf6mmU6ggVoiM/tYSPIzCgTYTsbeg3LazUNt8QrhUc38p /7Hlit8LIIRgTveT0cRUCWaunCc5selmSgl3kKrqLFluYinK3moNMeo/NjtK GeDVjO0YjB; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 6/13/08 8:25 PM, "Carsten Bormann" wrote: > On Jun 13 2008, at 19:25, Geoff Mulligan wrote: > >> I am less certain that there is consensus that fragment recovery is a >> necessary working group item at this point. So I will ask the WG. > > There certainly was some interest in this optimization. > I'm not feeling comfortable at this point that we can reach consensus > on a solution within the time frame of this charter round. > So my proposal would be to keep discussing this optimization (as we > undoubtedly will do with other optimizations as well), maybe converge > quickly, and then decide whether we ask for a charter extensions this > round or add it to the next charter. OK. JP. > > Gruesse, Carsten > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Jun 14 13:31:39 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 863A03A690C; Sat, 14 Jun 2008 13:31:39 -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 A22403A690C for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 13:31:38 -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 1yv6XonZbeE4 for <6lowpan@core3.amsl.com>; Sat, 14 Jun 2008 13:31:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 27CCC3A67B2 for <6lowpan@ietf.org>; Sat, 14 Jun 2008 13:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5EKVumS028554; Sat, 14 Jun 2008 22:31:59 +0200 (CEST) Message-Id: <7D5590BF-6EC4-40A2-A241-CEADCE720AA2@tzi.org> From: Carsten Bormann To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Sat, 14 Jun 2008 22:31:54 +0200 References: X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Jun 14 2008, at 11:30, JP Vasseur wrote: >>> This document will cover the concepts of "Mesh Under" and "Route >>> Over", >> >> Any architecture document that does not define these terms would be a >> rather strange architecture document indeed. > > Well hopefully we do not need to define what Routing means at the > IETF ;-) > and the notion of mesh-under is a form of routing at layer 2 (not > really in > the scope of the IETF). > > Since this is a contentious debate to say the least, I was proposing > to deal > with it as a separate item for the moment so as to quickly move > forward with > the architecture document where lot of work is still needed. I'm still confused. What is the debate you are referring to? In case you actually do mean the mesh-under vs. route-over debate: It is pretty clear that there will be mesh-under and route-over. I cannot quite imagine reaching consensus on dropping one of them now. I also cannot imagine a coherent architecture that ignores this important distinction. So I thought we would continue to address both approaches in the architecture document. (For those who came late to 6lowpan: The assumption so far has been that 6lowpan would, as any IPv6 link is, be agnostic with respect to forwarding/routing operating on top of it, and that it would support L2 forwarding ("mesh-under"), with a slight focus on stubby lowpans. See section 4.2 of RFC 4919.) Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Jun 15 23:57: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 F20DE28C104; Sun, 15 Jun 2008 23:57: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 1AB6428C104 for <6lowpan@core3.amsl.com>; Sun, 15 Jun 2008 23:57:52 -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] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiYVUUF8rgIW for <6lowpan@core3.amsl.com>; Sun, 15 Jun 2008 23:57:51 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id BCF4A3A6973 for <6lowpan@ietf.org>; Sun, 15 Jun 2008 23:57:50 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2452355tib.25 for <6lowpan@ietf.org>; Sun, 15 Jun 2008 23:58:28 -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=ucfV4XhkE4JShlnH4URG9gINF06fCzLmozy/bnX3N9c=; b=sQW2sA63NRiahQbQkCaqHdyeguqT2p4mTJqptzP3QRxgwJfT4uzgmy3g9kWLolZ+5o wo/doZGlLHnodRVmk/xNSGVGxzTLOYI1c600F+ybw7VOYVNSuHA0hFbZLXoTCaatB+Jt 8hlcBQ3kYyNygApYzQJueIsZAT19lZzjzul+I= 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=OWkFeyFCftwW8k4ygVnHnLEkjxfbwV0p523GGqfU2EssU/8zpzEYg99ZTuI10YY8Hr 2rPxRtP7YMp2Hd6KG8U3UyYSVS7SnQE+DxYoa/4uSQzQZhwCiEvzptI0031n6vAUKNKa 4+BMmShlxf9zBy6TTEUD5y4BCFqz/o1JWB9Pw= Received: by 10.110.109.19 with SMTP id h19mr4091435tic.58.1213599508017; Sun, 15 Jun 2008 23:58:28 -0700 (PDT) Received: by 10.110.21.5 with HTTP; Sun, 15 Jun 2008 23:58:27 -0700 (PDT) Message-ID: <77f1dba80806152358y776bb58fu51785eb8efb2584@mail.gmail.com> Date: Mon, 16 Jun 2008 15:58:27 +0900 From: "Eunsook \"Eunah\" Kim" To: "Carsten Bormann" In-Reply-To: <7D5590BF-6EC4-40A2-A241-CEADCE720AA2@tzi.org> MIME-Version: 1.0 Content-Disposition: inline References: <7D5590BF-6EC4-40A2-A241-CEADCE720AA2@tzi.org> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 support the current proposed charter. I also think that 6LoWPAN architecture needs to include both approaches. Thanks. -eunah On Sun, Jun 15, 2008 at 5:31 AM, Carsten Bormann wrote: > On Jun 14 2008, at 11:30, JP Vasseur wrote: > >>>> This document will cover the concepts of "Mesh Under" and "Route >>>> Over", >>> >>> Any architecture document that does not define these terms would be a >>> rather strange architecture document indeed. >> >> Well hopefully we do not need to define what Routing means at the >> IETF ;-) >> and the notion of mesh-under is a form of routing at layer 2 (not >> really in >> the scope of the IETF). >> >> Since this is a contentious debate to say the least, I was proposing >> to deal >> with it as a separate item for the moment so as to quickly move >> forward with >> the architecture document where lot of work is still needed. > > I'm still confused. > What is the debate you are referring to? > > In case you actually do mean the mesh-under vs. route-over debate: > It is pretty clear that there will be mesh-under and route-over. > I cannot quite imagine reaching consensus on dropping one of them now. > I also cannot imagine a coherent architecture that ignores this > important distinction. > So I thought we would continue to address both approaches in the > architecture document. > > (For those who came late to 6lowpan: The assumption so far has been > that 6lowpan would, as any IPv6 link is, be agnostic with respect to > forwarding/routing operating on top of it, and that it would support > L2 forwarding ("mesh-under"), with a slight focus on stubby lowpans. > See section 4.2 of RFC 4919.) > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 01:03:35 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 B474F28C10F; Mon, 16 Jun 2008 01:03:35 -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 714D928C10E for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 01:03:34 -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 wLF9h6KYz6Ox for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 01:03:30 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by core3.amsl.com (Postfix) with ESMTP id D3FC328C10C for <6lowpan@ietf.org>; Mon, 16 Jun 2008 01:03:29 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id m5G83YUK025855; Mon, 16 Jun 2008 10:03:34 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id A87FF2CBCFD; Mon, 16 Jun 2008 11:03:11 +0200 (CEST) Received: from 217.216.91.242 by webmail.entel.upc.edu with HTTP; Mon, 16 Jun 2008 10:03:31 +0200 (CEST) Message-ID: <49197.217.216.91.242.1213603411.squirrel@webmail.entel.upc.edu> In-Reply-To: <1213380617.5961.64.camel@dellx1> References: <1213380617.5961.64.camel@dellx1> Date: Mon, 16 Jun 2008 10:03:31 +0200 (CEST) From: "Carles Gomez Montenegro" To: "Geoff Mulligan" 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 (violet.upc.es [147.83.2.51]); Mon, 16 Jun 2008 10:03:37 +0200 (CEST) Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Dear all, Geoff, I support leaving the new charter text as it is. Greetings, Carles > Folks, > I think that our charter will be discussed on the next IESG telechat, > next Thursday! We need to get the text correct and to Mark WELL BEFORE > the Thursday. > > JP has suggested a change to the wording for the Arch Doc draft item. > Please send a message indicating your thoughts about the change. > > While I thought that we did have consensus around this particular item I > would like to make sure that we do. > > =EF=BB=BFShould we remove the text about mesh-under and route-over? > Should we leave the text as it is? > > geoff > > > On Fri, 2008-06-13 at 20:03 +0200, JP Vasseur wrote: >> I would suggest to reword the text related to the architecture ID and >> remove >> the mesh-under/route over discussion for the moment. >> >> JP. >> >> >> On 6/13/08 7:47 PM, "Geoff Mulligan" wrote: >> >> > So do think that the text of the Arch doc item needs to be changed or >> > are you thinking that it arch doc item needs to be removed completely >> > until we have the mesh-under vs router over discussion? >> > >> > geoff >> > >> > On Fri, 2008-06-13 at 19:33 +0200, JP Vasseur wrote: >> >> Hi Geoff, >> >> >> >> >> >> On 6/13/08 7:25 PM, "Geoff Mulligan" wrote: >> >> >> >>> JP, >> >>> As I said previously, when Carsten, Mark and I reviewed the >> >>> comments/messages on the list it was clear that ND, Architecture, >> and >> >>> Security were priority items along with dealing with enhancements to >> >>> compression of non link local addresses and that there was clear >> support >> >>> to take these on within the working group. And now also the Use >> Cases >> >>> draft. >> >>> >> >>> I am less certain that there is consensus that fragment recovery is >> a >> >>> necessary working group item at this point. So I will ask the WG. >> >>> >> >>> As to your question about the Arch doc, I'm not sure that I >> understand >> >>> the question or the timing? The text for this hasn't changed for >> >>> months. It seems that there are members of the WG that want to see >> the >> >>> architectural description that includes both a mesh under solution >> and a >> >>> route over. How would you propose that we determine if there is a >> need >> >>> for both? >> >> >> >> My proposal would be to have a discussion on this topic first, trying >> to >> >> reach a consensus in the WG on whether or not we need to define a >> mesh-under >> >> solution. Once we have reached a consensus, then move on and start to >> >> incorporate it as part of the architecture ID or another document. >> >> >> >> In term of routing requirement ID, I would suggest: >> >> * To move ahead with the 6lowpan specific requirement ID, owned by >> the >> >> 6lowpan WG and reviewed by ROLL, >> >> * hold-off on the mesh-under routing requirements until we have >> reached a >> >> consensus. >> >> >> >> Makes sense ? >> >> >> >> Thanks. >> >> >> >> JP. >> >> >> >>> >> >>> geoff >> >>> >> >>> On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: >> >>>> Hi Geoff, >> >>>> >> >>>> Thanks for sending out the new revision. One question, one comment. >> >>>> >> >>>> Question: could you explain the rationale for leaving out the >> fragmentation >> >>>> recovery item? >> >>>> >> >>>> Comment: >> >>>> >> >>>> "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 >> such >> >>>> as operation with sleeping nodes, network components (both battery- >> >>>> and line-powered), addressing, and IPv4/IPv6 network connections. >> >>>> As a spin-off from that document, "6LoWPAN Routing Requirements" >> will >> >>>> describe 6LoWPAN-specific requirements on routing protocols used in >> >>>> 6LoWPANs, addressing both the "route-over" and "mesh-under" >> approach. >> >>>> Both documents will be informational." >> >>>> >> >>>> I do not understand the rationale here: I think that we should >> first >> >>>> determine whether we both need a mesh-under *and* a route-over >> approach. >> >>>> You >> >>>> know my opinion: we have numerous examples in the past of such >> approaches >> >>>> that ALL failed for obvious technical reasons but this is my >> technical >> >>>> opinion. As far as 6lowpan is concerned, shouldn't we first have a >> >>>> discussion to get a consensus there ? *If* it turns out that both >> are >> >>>> needed, then add an introductory section in the architecture >> document >> >>>> pointing to the requirement document(s). >> >>>> >> >>>> Thus I would rather suggest not to list this as a WG item but to >> leave it >> >>>> out for the moment and continue to have the discussion until we >> have a >> >>>> consensus. Then at that point we could decide what to do. On the >> other >> >>>> hand, >> >>>> having a separate documents listing the 6LoWPAN specific routing >> >>>> requirements, owned by the 6lowpan WG and reviewed by ROLL would >> make a lot >> >>>> of sense. >> >>>> >> >>>> Thoughts ? >> >>>> >> >>>> Thanks. >> >>>> >> >>>> JP. >> >>>> >> >>>> >> >>>> >> >>>> On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: >> >>>> >> >>>>> With the input from the authors we've put the "Use Cases" back >> into the >> >>>>> text for the charter for the working group with a delivery date of >> Dec >> >>>>> 08. >> >>>>> >> >>>>> Attached is the NEW new charter text. >> >>>>> >> >>>>> geoff >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 Mon Jun 16 01:51: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 142693A68E3; Mon, 16 Jun 2008 01:51: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 D62633A696B for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 JhFXhZgWizaz for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 01:51:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EDEF93A683B for <6lowpan@ietf.org>; Mon, 16 Jun 2008 01:51:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,651,1204498800"; d="scan'208";a="11748589" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2008 10:52:16 +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 m5G8qGx2029424; Mon, 16 Jun 2008 10:52:16 +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 m5G8qGDl017260; Mon, 16 Jun 2008 08:52:16 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); Mon, 16 Jun 2008 10:52:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 10:51:35 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D16F26@xmb-ams-337.emea.cisco.com> In-Reply-To: <1213377905.5961.26.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter text: fragment recovery item Thread-Index: AcjNeoAHUv0bn5bnSniAvay6ksICSgCEeYew References: <1213377905.5961.26.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "Jean Philippe Vasseur (jvasseur)" X-OriginalArrivalTime: 16 Jun 2008 08:52:15.0893 (UTC) FILETIME=[46B98C50:01C8CF8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5270; t=1213606336; x=1214470336; 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=20text=3A=20f ragment=20recovery=20item |Sender:=20; bh=g8PPPBC2OEuqCKaZuU25Vxxbcq+lpIzAJAVGmNSlk9g=; b=ep5aKq04Fr57v+tcqZ60be9F91tRf+aaGR9xM5tGYfIJ6WdXnCca7pyr1d pjhkP0LmVtR0QhbVDMM92BD7V7kxvXt7t5nCHgzqPMTyZnBOAofGHvue4IuN tBo1mPujwt; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New charter text: fragment recovery item 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: >> Question: could you explain the rationale for leaving out the fragmentation >> recovery item? Geoff: >I am less certain that there is consensus that fragment recovery is a >necessary working group item at this point. So I will ask the WG. Considering that 6LoWPAN packets can be as large as 2K bytes and that a 802.15.4 frame with security will carry in the order of 80 bytes of effective payload, a packet might be fragmented into about 25 fragments at the 6LoWPAN shim layer. This level of fragmentation is much higher than that traditionally experienced over the Internet with IPv4 fragments. At the same time, the use of radios increases the probability of transmission loss and Mesh-Under techniques compound that risk over multiple hops. Past experience with fragmentation has shown that missassociated or lost fragments can lead to poor network behaviour and, eventually, trouble at application layer. Enlighteneing reading on that subject is found in http://tools.ietf.org/html/draft-mathis-frag-harmful. That experience led to the definition of the Path MTU discovery protocol that avoids fragmentation over the Internet. An end-to-end fragment recovery mechanism can be a good complement to a hop-by-hop MAC level recovery with a limited number of retries. Additional flow control and Explicit Congestion Notification would help prevent congestion collapse. We have enough experience at the IETF to know that these mechanisms are required and design them properly. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan >Sent: vendredi 13 juin 2008 19:25 >To: Jean Philippe Vasseur (jvasseur) >Cc: 6lowpan >Subject: Re: [6lowpan] New new charter text > >JP, > As I said previously, when Carsten, Mark and I reviewed the >comments/messages on the list it was clear that ND, Architecture, and >Security were priority items along with dealing with enhancements to >compression of non link local addresses and that there was clear support >to take these on within the working group. And now also the Use Cases >draft. > >I am less certain that there is consensus that fragment recovery is a >necessary working group item at this point. So I will ask the WG. > >As to your question about the Arch doc, I'm not sure that I understand >the question or the timing? The text for this hasn't changed for >months. It seems that there are members of the WG that want to see the >architectural description that includes both a mesh under solution and a >route over. How would you propose that we determine if there is a need >for both? > >geoff > >On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: >> Hi Geoff, >> >> Thanks for sending out the new revision. One question, one comment. >> >> Question: could you explain the rationale for leaving out the fragmentation >> recovery item? >> >> Comment: >> >> "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 such >> as operation with sleeping nodes, network components (both battery- >> and line-powered), addressing, and IPv4/IPv6 network connections. >> As a spin-off from that document, "6LoWPAN Routing Requirements" will >> describe 6LoWPAN-specific requirements on routing protocols used in >> 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. >> Both documents will be informational." >> >> I do not understand the rationale here: I think that we should first >> determine whether we both need a mesh-under *and* a route-over approach. You >> know my opinion: we have numerous examples in the past of such approaches >> that ALL failed for obvious technical reasons but this is my technical >> opinion. As far as 6lowpan is concerned, shouldn't we first have a >> discussion to get a consensus there ? *If* it turns out that both are >> needed, then add an introductory section in the architecture document >> pointing to the requirement document(s). >> >> Thus I would rather suggest not to list this as a WG item but to leave it >> out for the moment and continue to have the discussion until we have a >> consensus. Then at that point we could decide what to do. On the other hand, >> having a separate documents listing the 6LoWPAN specific routing >> requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot >> of sense. >> >> Thoughts ? >> >> Thanks. >> >> JP. >> >> >> >> On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: >> >> > With the input from the authors we've put the "Use Cases" back into the >> > text for the charter for the working group with a delivery date of Dec >> > 08. >> > >> > Attached is the NEW new charter text. >> > >> > geoff >> > >> > _______________________________________________ >> > 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 Mon Jun 16 01:51: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 4C8713A698F; Mon, 16 Jun 2008 01:51: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 25C293A698F for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 01:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49PrciOYPp5s for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 01:51:38 -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 236F63A681A for <6lowpan@ietf.org>; Mon, 16 Jun 2008 01:51:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,651,1204498800"; d="scan'208";a="11748586" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2008 10:52:15 +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 m5G8qFFg031798; Mon, 16 Jun 2008 10:52:15 +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 m5G8qFAF017251; Mon, 16 Jun 2008 08:52:15 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, 16 Jun 2008 10:52:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 10:52:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D16F25@xmb-ams-337.emea.cisco.com> In-Reply-To: <1213381062.5961.75.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New new charter text (resend) Thread-Index: AcjNgc87ks1p5Vn1Raqiqenoeqd1qwCBjMnw References: <1213381062.5961.75.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 16 Jun 2008 08:52:14.0945 (UTC) FILETIME=[4628E510:01C8CF8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1458; t=1213606335; x=1214470335; 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=20new=20charter=20text= 20(resend) |Sender:=20; bh=dsIRSCHAYD0qxoUQqlQdFJwFQPv1bjoheGnwXR3ZnOA=; b=CJhhKjbeb7hHkV1uWLTcdhBJ7IACPlWJ2j3s6APS+hPh5tFHyenib9yYDQ jFZOu87gQYWodb50hrlQX/9WRoNygywfsdyc3PJXaFu79WgEqvxS/WwdSTBc HfiJV2MDgZ; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] New new charter text (resend) 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 SGkgR2VvZmYNCg0KSSBkbyBhZ3JlZSB3aXRoIEpQLg0KDQpQYXNjYWwNCg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogNmxvd3Bhbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 Nmxvd3Bhbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvZmYgTXVsbGlnYW4NCj5T ZW50OiB2ZW5kcmVkaSAxMyBqdWluIDIwMDggMjA6MTgNCj5UbzogNmxvd3Bhbg0KPlN1YmplY3Q6 IFs2bG93cGFuXSBOZXcgbmV3IGNoYXJ0ZXIgdGV4dCAocmVzZW5kKQ0KPg0KPkZvbGtzLA0KPiBb IEkgZG9uJ3Qga25vdyB3aGF0cyB1cCB3aXRoIHRoZSBmb3JtYXR0aW5nIHNvIEknbSByZXNlbmRp bmcgdGhpcw0KPm1lc3NhZ2UuIF0NCj4NCj4gSSB0aGluayB0aGF0IG91ciBjaGFydGVyIHdpbGwg YmUgZGlzY3Vzc2VkIG9uIHRoZSBuZXh0IElFU0cgdGVsZWNoYXQsDQo+bmV4dCBUaHVyc2RheSEg IFdlIG5lZWQgdG8gZ2V0IHRoZSB0ZXh0IGNvcnJlY3QgYW5kIHRvIE1hcmsgV0VMTCBCRUZPUkUN Cj50aGUgVGh1cnNkYXkuDQo+DQo+SlAgaGFzIHN1Z2dlc3RlZCBhIGNoYW5nZSB0byB0aGUgd29y ZGluZyBmb3IgdGhlIEFyY2ggRG9jIGRyYWZ0IGl0ZW0uDQo+DQo+UGxlYXNlIHNlbmQgYSBtZXNz YWdlIGluZGljYXRpbmcgeW91ciB0aG91Z2h0cyBhYm91dCB0aGUgY2hhbmdlLg0KPg0KPldoaWxl IEkgdGhvdWdodCB0aGF0IHdlIGRpZCBoYXZlIGNvbnNlbnN1cyBhcm91bmQgdGhpcyBwYXJ0aWN1 bGFyIGl0ZW0gSQ0KPndvdWxkIGxpa2UgdG8gbWFrZSBzdXJlIHRoYXQgd2UgZG8uDQo+DQo+77u/ U2hvdWxkIHdlIHJlbW92ZSB0aGUgdGV4dCBhYm91dCBtZXNoLXVuZGVyIGFuZCByb3V0ZS1vdmVy Pw0KPg0KPlNob3VsZCB3ZSBsZWF2ZSB0aGUgdGV4dCBhcyBpdCBpcz8NCj4NCj4gICAgICAgIGdl b2ZmDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj42bG93cGFuIG1haWxpbmcgbGlzdA0KPjZsb3dwYW5AaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCjZsb3dwYW4gbWFpbGluZyBsaXN0CjZsb3dwYW5A aWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuCg== From 6lowpan-bounces@ietf.org Mon Jun 16 02:47:02 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 41D8F3A685E; Mon, 16 Jun 2008 02:47:02 -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 46DBF3A6841 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 02:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 a1N3saFoaFBN for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 02:46: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 6580E3A6A68 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 02:46:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,652,1204498800"; d="scan'208";a="11758194" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2008 11:47:31 +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 m5G9lVe6022297; Mon, 16 Jun 2008 11:47:31 +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 m5G9lVQu016931; Mon, 16 Jun 2008 09:47:31 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, 16 Jun 2008 11:47:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 11:46:55 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D16FA8@xmb-ams-337.emea.cisco.com> In-Reply-To: <1213365573.19399.71.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNXb+b3yj663qESuCTdbrlk5+ZfwCN5eMA References: <1213296428.19399.54.camel@dellx1><77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> <1213365573.19399.71.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@ietf.org> X-OriginalArrivalTime: 16 Jun 2008 09:47:30.0924 (UTC) FILETIME=[FEA322C0:01C8CF95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1123; t=1213609651; x=1214473651; 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=20new=20charter=20text |Sender:=20; bh=PkpxhtH3esZt0PItfS/N2aXGwad9wpX6M8R6Ip4St1s=; b=H8ds5wZA2Kz3Iv8Xbt454Op9CYKLGo2OCfu0fPNaiP1sanIkAdV5IA0U5n 38fnraxSM+wAlLe4tmAJeMzQXpcp88hFuvLg2i0nkkSeT2eoI/Q1TAy4vmtN qUv1S3OJ0V; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] New new charter text 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: This part: " such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts) " Might be unwelcome. Seems to dictate solutions, which solutions might be hard to achieve at IETF. Note that I am in favor of using L2 beacons as opposed to uniquely data frames to carry RAs. Can we just remove this text for the time being, and just say that we want to " reduce the need for multicast ", "limit the need to wake up sleeping devices", that type of things? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan >Sent: vendredi 13 juin 2008 16:00 >To: 6lowpan >Subject: [6lowpan] New new charter text > >With the input from the authors we've put the "Use Cases" back into the >text for the charter for the working group with a delivery date of Dec >08. > >Attached is the NEW new charter text. > > geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 06:39: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 751BC3A691C; Mon, 16 Jun 2008 06:39: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 695543A691C for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 06:39:36 -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 jz0mlRYMPIdj for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 06:39:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1E0143A682F for <6lowpan@ietf.org>; Mon, 16 Jun 2008 06:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5GDdjeQ027506; Mon, 16 Jun 2008 15:39:48 +0200 (CEST) Message-Id: <8E34AD31-B6C1-42DA-A13F-72DE69AF6273@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05D16F26@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 15:39:44 +0200 References: <1213377905.5961.26.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D16F26@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New charter text: fragment recovery item 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 Jun 16 2008, at 10:51, Pascal Thubert (pthubert) wrote: > http://tools.ietf.org/html/draft-mathis-frag-harmful Which has since become RFC 4963, "IPv4 Reassembly Errors at High Data Rates". Mandatory reading in some of our classes (see also RFC 3819, for a more general overview of L2/L3 issues), but kind of less relevant for IPv6. (PLPMTUD is RFC 4821, but doesn't really help with the 6lowpann issue, because the IPv6 MTU *MUST* be >= 1280, and we would prefer applications to stay well below that -- there is no easy way in IPv6 to tell them.) The situation right now (RFC 4944) is that applications just have to know that large packets will have bad performance. This is a classical case of the L2/L3 not being able to tell L4/L7 something it needs to know. Fortunately, many 6lowpan applications will run custom protocols on top of UDP, so they can keep this under consideration. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 08:26:58 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 56CC13A67DF; Mon, 16 Jun 2008 08:26:58 -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 60F203A683F for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, 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 NlD0ow8cBly3 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 08:26:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BE31E3A67DF for <6lowpan@ietf.org>; Mon, 16 Jun 2008 08:26:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,653,1204498800"; d="scan'208";a="11807704" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2008 17:27:17 +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 m5GFRH0O016171; Mon, 16 Jun 2008 17:27: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 m5GFRHeH000207; Mon, 16 Jun 2008 15:27: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); Mon, 16 Jun 2008 17:27:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jun 2008 17:26:39 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D6E9E1@xmb-ams-337.emea.cisco.com> In-Reply-To: <8E34AD31-B6C1-42DA-A13F-72DE69AF6273@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New charter text: fragment recovery item Thread-Index: AcjPtn8vSwD/CkXkQYSJoHbZSPxJewADjI1g References: <1213377905.5961.26.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D16F26@xmb-ams-337.emea.cisco.com> <8E34AD31-B6C1-42DA-A13F-72DE69AF6273@tzi.org> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 16 Jun 2008 15:27:17.0510 (UTC) FILETIME=[75FD4A60:01C8CFC5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1616; t=1213630037; x=1214494037; 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=20text=3A=20f ragment=20recovery=20item |Sender:=20; bh=bv5DeYgUHjVxEMB7yQns9Jww4N9kNdL9dx8XYNIxovk=; b=S7xVEnL6k0jGA4IGlq93FcMzpQyU/xi9VYvOymZh4ED+5aCVGbsWrE7wW8 Jw4VO3X2Q9fqlHTr3sKvuIUhxqfpxYj1NwJPFql0c4S+oBbZEvc+iwUp1Pny VrMT3GrYGP; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New charter text: fragment recovery item 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 Carsten; Thanks for the pointer, it's all the more interesting that tools.ieft.org fails to refer it. I'll update the fragment recovery draft with the proper reference. Now I fail to gather your conclusion: Do you mean that applications should refrain from sending more than 80 bytes at a time to avoid 6LoWPAN fragmentation to occur? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: lundi 16 juin 2008 15:40 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Geoff Mulligan; Jean Philippe Vasseur (jvasseur); 6lowpan >Subject: Re: [6lowpan] New charter text: fragment recovery item > >On Jun 16 2008, at 10:51, Pascal Thubert (pthubert) wrote: > >> http://tools.ietf.org/html/draft-mathis-frag-harmful > >Which has since become RFC 4963, "IPv4 Reassembly Errors at High Data >Rates". >Mandatory reading in some of our classes (see also RFC 3819, for a >more general overview of L2/L3 issues), but kind of less relevant for >IPv6. > >(PLPMTUD is RFC 4821, but doesn't really help with the 6lowpann issue, >because the IPv6 MTU *MUST* be >= 1280, and we would prefer >applications to stay well below that -- there is no easy way in IPv6 >to tell them.) > >The situation right now (RFC 4944) is that applications just have to >know that large packets will have bad performance. >This is a classical case of the L2/L3 not being able to tell L4/L7 >something it needs to know. >Fortunately, many 6lowpan applications will run custom protocols on >top of UDP, so they can keep this under consideration. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 10:01: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 D673E3A6859; Mon, 16 Jun 2008 10:01: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 4AFD53A6859 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:01:36 -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 NbVDQ58aEstd for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:01:32 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id C9E6A3A6829 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 10:01:28 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so2775694ywj.49 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 10:02:02 -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=JnVt1AG/dOgGjFeATAVx1DXNc5UYGYAuC89iC/g4nzU=; b=NW0Y8vMj7S3+8ciN9DTq5FH+H41Gt0nL3FeYlrwicGpv9QwWDQp+OdCJhO41lazXJx dc5z56K3BeQeOqETmLjgvk/6JqNjaAXhRBAL5bsow3mD3eIoGROYX+QZPrJGSWQhkoXy fHvbTWgbl6kzjRt3IBWv02VWZuBeD/cnvwaHQ= 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=NZNO+wV+3i+uW66WoDs2wL0zi4FDf81fX8UxtBFUzSFCpEILAgzSOpFgRM54UgCaGm d6VS1FsY765zNVpSGUMvtN6pD6XFFCz9Vvi0Cyu+qdagV0R1XY0N+tbRWGM5+BMMKDMr Cb2L465GhFfPkiJKDgwefFXsdA94Q79Dxq8Go= Received: by 10.143.29.17 with SMTP id g17mr2444986wfj.239.1213635721346; Mon, 16 Jun 2008 10:02:01 -0700 (PDT) Received: by 10.142.78.9 with HTTP; Mon, 16 Jun 2008 10:02:01 -0700 (PDT) Message-ID: <43b91d370806161002x60141ad2k92fc6e9512398fa4@mail.gmail.com> Date: Mon, 16 Jun 2008 10:02:01 -0700 From: "Samita Chakrabarti" To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05D16FA8@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <1213296428.19399.54.camel@dellx1> <77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> <1213365573.19399.71.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D16FA8@xmb-ams-337.emea.cisco.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 6/16/08, Pascal Thubert (pthubert) wrote: > Hi Geoff: > > This part: > " > such as reusing the structure of the 802.15.4 network > (e.g., by using the coordinators), and reduce the need for multicast > by having devices talk to coordinators (without creating a single > point-of-failure, or changing the semantics of the IPv6 ND > multicasts) > " > > Might be unwelcome. Seems to dictate solutions, which solutions might be > hard to achieve at IETF. > Note that I am in favor of using L2 beacons as opposed to uniquely data > frames to carry RAs. > Can we just remove this text for the time being, and just say that we > want to > " reduce the need for multicast ", "limit the need to wake up sleeping > devices", that type of things? I respectfully disagree with you on that. The solution that reduce the need of multicast in IPv6 already exists and it has been discussed in the working group many times in the past. Please refer to: draft-chakrabarti-6lowpan-ipv6-nd-04.txt There is a need for reducing multicast and broadcast in the reduced-power and low-processing ability devices that require to save power and do not want to wake up on multicast/broadcast messages - it is pretty clear in 802.15.4 network. The charter talks about the context of IPv6 where multicast is primarily used for solicitation and advertisement and that will have to be reduced since 802.15.4 is a shared network. I'll re-submit a revised draft before this IETF. -Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 10:06: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 B42B43A69AF; Mon, 16 Jun 2008 10:06: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 500003A69AF for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:06:11 -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 fdLaZIvhuD6y for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:06:10 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 612DC3A69AA for <6lowpan@ietf.org>; Mon, 16 Jun 2008 10:06:09 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so2776868ywj.49 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 10:06:42 -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=IJpyo6c85Q6sGi+vOLh8rMM86iZQS5EgYRBQs1xNJ5A=; b=bR49A/6JapKgtQaMs53Rawlc0UKuKhxANwBpV3p8pq0iG79e2Z7pcBotyazXRFa6wA d5dAttX5FuMPZyvwGfTeuaPEh1yHjcWwNNiBBqWsSWQ2WiOtqL7NlTivFwrCIk6+iJQQ tTsdznST/8eaVo239WsEStcQMnBmrXSeKkd/o= 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=I5rGHgM6Cz6tu2m4LAoIDsnZvwvO5bq0p4REGKjMxMHvCh28vmX+VPZnzZYDWe1wrr HGjrnfHy4h7/8JylAWPf3F4a8plzPwTIkaLJwQBbzf+FrbH7Xkuvrwx2bZcXGqcerU8m CndsdxUyxZOEJXPmAAL9Nc/Uo+L4MWECIfvLI= Received: by 10.142.188.4 with SMTP id l4mr2461368wff.92.1213636001781; Mon, 16 Jun 2008 10:06:41 -0700 (PDT) Received: by 10.142.78.9 with HTTP; Mon, 16 Jun 2008 10:06:41 -0700 (PDT) Message-ID: <43b91d370806161006j22258007q4b5770fb0d843b1e@mail.gmail.com> Date: Mon, 16 Jun 2008 10:06:41 -0700 From: "Samita Chakrabarti" To: "Geoff Mulligan" In-Reply-To: <1213381062.5961.75.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <1213381062.5961.75.camel@dellx1> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text (resend) 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 SGkgR2VvZmYsCgpPdGhlciBmb2xrcyBhbmQgbXlzZWxmIGFscmVhZHkgcmVzcG9uZCB0byB0aGUg Zm9sbG93aW5nIHF1ZXN0aW9uCmJlZm9yZSBpbiB0aGUgbWFpbGluZyBsaXN0LgoKPiDvu79TaG91 bGQgd2UgcmVtb3ZlIHRoZSB0ZXh0IGFib3V0IG1lc2gtdW5kZXIgYW5kIHJvdXRlLW92ZXI/Cj4K CklNSE8sIHRoZSBhbnN3ZXIgaXMgbm8uCgpUaGUgZGlzY3Vzc2lvbiBvZiBtZXNoLXVuZGVyIGFu ZCByb3V0ZS1vdmVyIGNvbmNlcHRzIHdpdGggcmVzcGVjdCB0bwpJUHY2LW92ZXItODAyLjE1LjQg bmV0d29yayBpcyBpbXBvcnRhbnQgZm9yIGZvbGtzIHRvIHVuZGVyc3RhbmQgdGhlCm92ZXItYWxs IHBpY3R1cmUuCgo+IFNob3VsZCB3ZSBsZWF2ZSB0aGUgdGV4dCBhcyBpdCBpcz8KPgoKWWVzLCBw bGVhc2UuCgoKVGhhbmtzLgotU2FtaXRhCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCjZsb3dwYW4gbWFpbGluZyBsaXN0CjZsb3dwYW5AaWV0Zi5vcmcKaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuCg== From 6lowpan-bounces@ietf.org Mon Jun 16 10:42: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 BDB833A6840; Mon, 16 Jun 2008 10:42: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 65B303A6840 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 6QGOrB-OwqZ9 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:42:53 -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 2664C3A67DA for <6lowpan@ietf.org>; Mon, 16 Jun 2008 10:42:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,653,1204520400"; d="scan'208";a="11152235" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2008 13:43:31 -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 m5GHhVFQ022997; Mon, 16 Jun 2008 13:43:31 -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 m5GHhVZ3002723; Mon, 16 Jun 2008 17:43:31 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); Mon, 16 Jun 2008 13:43:31 -0400 Received: from 10.21.76.213 ([10.21.76.213]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Jun 2008 17:43:30 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 16 Jun 2008 19:43:28 +0200 From: JP Vasseur To: Samita Chakrabarti , Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] New new charter text (resend) Thread-Index: AcjP2Hv713UOeSMdKkyXPzp4R+GWwQ== In-Reply-To: <43b91d370806161006j22258007q4b5770fb0d843b1e@mail.gmail.com> Mime-version: 1.0 X-OriginalArrivalTime: 16 Jun 2008 17:43:31.0450 (UTC) FILETIME=[7E098DA0:01C8CFD8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=851; t=1213638211; x=1214502211; 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=20new=20charter=20text= 20(resend) |Sender:=20 |To:=20Samita=20Chakrabarti=20,=0A=20=2 0=20=20=20=20=20=20Geoff=20Mulligan=20; bh=1Bi+/wS/EiBOpAtih20DLr/hoyTGdUqcjjfy+c0wVgU=; b=Lt3O1Y/OLJpY/yjlg52BMa/8X22G1jaO5z37noQ/NMuglhwForwC/Q+mu/ xVC1Z1zB15NW/N27Lr2CfgxqFJHQMzBdYEpF849AMfhg9UMpzh8ts4b4Wi6x CEQDGpxKi1; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text (resend) 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 U28gYXQgbGVhc3QgY2FuIHdlIGFncmVlIHRvCigxKSBIYXZlICJzb21lIiBoaWdoIGxldmVsIHRl eHQgaW4gdGhlIGFyY2hpdGVjdHVyZSBJRAooMikgQSBzZXBhcmF0ZSBJRCBkZWFsaW5nIHdpdGgg dGhlIHN1YmplY3QgYW5kIHVzZWQgdG8gZHJhdyBhIGNvbnNlbnN1cy4KCk9uIDYvMTYvMDggNzow NiBQTSwgIlNhbWl0YSBDaGFrcmFiYXJ0aSIgPHNhbWl0YWMyQGdtYWlsLmNvbT4gd3JvdGU6Cgo+ IEhpIEdlb2ZmLAoKT3RoZXIgZm9sa3MgYW5kIG15c2VsZiBhbHJlYWR5IHJlc3BvbmQgdG8gdGhl IGZvbGxvd2luZwo+IHF1ZXN0aW9uCmJlZm9yZSBpbiB0aGUgbWFpbGluZyBsaXN0LgoKPiDvu79T aG91bGQgd2UgcmVtb3ZlIHRoZSB0ZXh0IGFib3V0Cj4gbWVzaC11bmRlciBhbmQgcm91dGUtb3Zl cj8KPgoKSU1ITywgdGhlIGFuc3dlciBpcyBuby4KClRoZSBkaXNjdXNzaW9uIG9mCj4gbWVzaC11 bmRlciBhbmQgcm91dGUtb3ZlciBjb25jZXB0cyB3aXRoIHJlc3BlY3QgdG8KSVB2Ni1vdmVyLTgw Mi4xNS40IG5ldHdvcmsKPiBpcyBpbXBvcnRhbnQgZm9yIGZvbGtzIHRvIHVuZGVyc3RhbmQgdGhl Cm92ZXItYWxsIHBpY3R1cmUuCgo+IFNob3VsZCB3ZSBsZWF2ZQo+IHRoZSB0ZXh0IGFzIGl0IGlz Pwo+CgpZZXMsCj4gcGxlYXNlLgoKClRoYW5rcy4KLVNhbWl0YQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwo2bG93Cj4gcGFuIG1haWxpbmcgCj4gbGlzdAo2 bG93cGFuQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNmxv d3BhbgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCjZs b3dwYW4gbWFpbGluZyBsaXN0CjZsb3dwYW5AaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby82bG93cGFuCg== From 6lowpan-bounces@ietf.org Mon Jun 16 10:50: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 9B4873A6984; Mon, 16 Jun 2008 10:50: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 A0C173A6984 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5YoZNf3-qoNb for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 10:50:11 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 4048A3A6816 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 10:50:10 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m5GHoppn008027 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 17:50:51 GMT Received: from [10.7.251.248] (punchin-nordmark.SFBay.Sun.COM [10.7.251.248]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5GHomsj328821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 10:50:48 -0700 (PDT) Message-ID: <4856A7F7.4060407@sun.com> Date: Mon, 16 Jun 2008 10:50:47 -0700 From: Erik Nordmark User-Agent: Thunderbird 2.0.0.4 (X11/20070723) MIME-Version: 1.0 To: 6lowpan@ietf.org Subject: [6lowpan] [Fwd: New Version Notification for draft-nordmark-6lowpan-reg-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org -------- Original Message -------- Subject: New Version Notification for draft-nordmark-6lowpan-reg-00 Date: Mon, 16 Jun 2008 10:44:02 -0700 (PDT) From: IETF I-D Submission Tool To: Erik.Nordmark@sun.com CC: Erik.Nordmark@sun.com A new version of I-D, draft-nordmark-6lowpan-reg-00.txt has been successfuly submitted by Erik Nordmark and posted to the IETF repository. Filename: draft-nordmark-6lowpan-reg Revision: 00 Title: Neighbor Discovery Registration Extension Creation_date: 2008-06-16 WG ID: Independent Submission Number_of_pages: 9 Abstract: In order to reduce Neighbor Discovery multicast messages it is useful if the routers on a link can maintain an authoritative list of the IPv6 and layer 2 addresses for all the hosts on the link. This draft specifies an extension to the Router Advertisement messages which trigger to hosts to send periodic registration messages which can be either unicast, multicast, or anycast. The protocol uses a soft-state approach to gather registration information. The IETF Secretariat. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 12:13:15 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 3581428C155; Mon, 16 Jun 2008 12:13:15 -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 6166628C152 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 4oHyWj-l0mPO for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 12:13:13 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 23B7B3A6AF9 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 12:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5GJDPRF009608; Mon, 16 Jun 2008 21:13:25 +0200 (CEST) Received: from ip-77-24-221-193.web.vodafone.de (ip-77-24-221-193.web.vodafone.de [77.24.221.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2BD0B6188; Mon, 16 Jun 2008 21:13:17 +0200 (CEST) Message-Id: <3E93214C-ACF5-4D30-9A62-6D2BB0A2DB90@tzi.org> From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05D6E9E1@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 21:12:10 +0200 References: <1213377905.5961.26.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D16F26@xmb-ams-337.emea.cisco.com> <8E34AD31-B6C1-42DA-A13F-72DE69AF6273@tzi.org> <7892795E1A87F04CADFCCF41FADD00FC05D6E9E1@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New charter text: fragment recovery item 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 Jun 16 2008, at 17:26, Pascal Thubert (pthubert) wrote: > Do you mean that applications should refrain from sending more than 80 > bytes at a time to avoid 6LoWPAN fragmentation to occur? In general: No. This is IPv6, so nodes MUST be able to communicate using packets of up to 1280 bytes. When designing an application protocol specifically for 6lowpans: I would try to optimize packet sizes so most packets fit in one fragment, possibly using semantic fragmentation to achieve that. I'd certainly not start sending 16-fragment packets as a matter of routine. So my (personal) summary for the discussion of this work item proposal would be: good point, but maybe not the most important optimization right now, as many applications are likely to minimize their transmission sizes anyway. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 12:22:09 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 257603A6B20; Mon, 16 Jun 2008 12:22:09 -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 E6A133A6B20 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 12:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 7pbLRDjumjU2 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 12:22:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id AEBA33A6937 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 12:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5GJMMxG017951; Mon, 16 Jun 2008 21:22:22 +0200 (CEST) Received: from ip-77-24-221-193.web.vodafone.de (ip-77-24-221-193.web.vodafone.de [77.24.221.193]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 296D36188; Mon, 16 Jun 2008 21:22:18 +0200 (CEST) Message-Id: <0D3C4D1A-BD4D-47DC-A3E2-357FD5498569@tzi.org> From: Carsten Bormann To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 21:22:10 +0200 References: X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text (resend) 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 Jun 16 2008, at 19:43, JP Vasseur wrote: > (2) A separate ID dealing with the subject and used to draw a > consensus. (Assuming you mean on the question of L2 forwarding yes [mesh-under] or no [route-over]:) As I said, I'm not sure we are even getting any closer to a consensus. Why should the WG try to make that decision? Why now? (This is not just a rethorical question!) Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Jun 16 19:36:08 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 AD1193A68F0; Mon, 16 Jun 2008 19:36:08 -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 CF0913A68F0 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 19:36:06 -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 XkOGPY+KXuOq for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 19:36:05 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id CB3B93A68AC for <6lowpan@ietf.org>; Mon, 16 Jun 2008 19:36:04 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so2000417and.122 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 19:36:44 -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=Qg6uZOq86zMKw/Ys71cewH5drpNeUMdiHKmxDq1UT7c=; b=P7DH8H+IqLYxB5NYV+77nsGvt/l0nIG9PIQzbMKqhszXSmHWZE6/ByBgYJOl98gnXS tPtZfXnho+fQRhoJ/GC3TWF7j6TtOJj3WyjJCO4p6+P0l+RaV0+Dy/wZfeVH7m87vzgU JukE9gCfiI5OQWD05+h0xWAzWrCAVfvSEhFY0= 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=nojCTL/e1XTAmRBf1F9/1WpGO3ccO9is9VVhnuAqEHJtEZ0W0Y8A2rWEqyEVAV3dNX JyuOCVeRAs2AHU64WspM9FyLHdeibH+qeubpBav5o330nYidIvZvZ/ZGWbuXIz7SQogU aTXCQ7YEYsvwPdztDY0hO6jq88+USyNV65H7o= Received: by 10.100.197.7 with SMTP id u7mr9737370anf.27.1213670204802; Mon, 16 Jun 2008 19:36:44 -0700 (PDT) Received: by 10.100.134.3 with HTTP; Mon, 16 Jun 2008 19:36:44 -0700 (PDT) Message-ID: Date: Tue, 17 Jun 2008 11:36:44 +0900 From: "Daniel Park" To: "Samita Chakrabarti" In-Reply-To: <43b91d370806161002x60141ad2k92fc6e9512398fa4@mail.gmail.com> MIME-Version: 1.0 References: <1213296428.19399.54.camel@dellx1> <77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> <1213365573.19399.71.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D16FA8@xmb-ams-337.emea.cisco.com> <43b91d370806161002x60141ad2k92fc6e9512398fa4@mail.gmail.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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="===============1308934150==" Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org --===============1308934150== Content-Type: multipart/alternative; boundary="----=_Part_7063_31784402.1213670204763" ------=_Part_7063_31784402.1213670204763 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am repeating my comments: Samita, are you working for ND-Opt revision ? That's very welcome to me and I am willing to contribute on this deliverable if any chances...:-) [cut and paste from the previous thread] This is a tip for understanding and referring how we can fat down NDP for 6lowpan networks. In 16ng working group, we tried to live up with IEEE 802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA optimization results... Hope those efforts help... Daniel Park Co-chair, 16ng working group. *8.2**. Router Advertisement* The AR SHOULD send a number (configurable value) of router advertisements as soon as the IPv6 link is established, to the MS. The AR sends unsolicited router advertisements periodically as per [RFC4861 ]. The interval between periodic router advertisements is however greater than the specification in Neighbor discovery for IPv6, and is discussed in the following section. *8.3**. Router lifetime and periodic router advertisements * The router lifetime SHOULD be set to a large value, preferably in hours. This document over-rides the specification for the value of the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) [RFC4861 ]. The AdvDefaultLifetime in the router advertisement MUST be either zero or between MaxRtrAdvInterval and 43200 seconds. The default value is 2 * MaxRtrAdvInterval. 802.16 hosts have the capability to transition to an idle mode in which case the radio link between the BS and MS is torn down. Paging is required in case the network needs to deliver packets to the MS. In order to avoid waking a mobile which is in idle mode and consuming resources on the air interface, the interval between periodic router advertisements SHOULD be set quite high. The MaxRtrAdvInterval value specified in this document over-rides the recommendation in Neighbor Discovery for IP Version 6 (IPv6) [ RFC4861]. The MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 21600 seconds. The default value for MaxRtrAdvInterval is 10800 seconds. On 6/17/08, Samita Chakrabarti wrote: > > Hi Pascal, > > On 6/16/08, Pascal Thubert (pthubert) wrote: > > Hi Geoff: > > > > This part: > > " > > such as reusing the structure of the 802.15.4 network > > (e.g., by using the coordinators), and reduce the need for multicast > > by having devices talk to coordinators (without creating a single > > point-of-failure, or changing the semantics of the IPv6 ND > > multicasts) > > " > > > > Might be unwelcome. Seems to dictate solutions, which solutions might be > > hard to achieve at IETF. > > Note that I am in favor of using L2 beacons as opposed to uniquely data > > frames to carry RAs. > > Can we just remove this text for the time being, and just say that we > > want to > > " reduce the need for multicast ", "limit the need to wake up sleeping > > devices", that type of things? > > I respectfully disagree with you on that. The solution that reduce > the need of multicast in IPv6 already exists and it has been discussed > in the working group many times in the past. Please refer to: > draft-chakrabarti-6lowpan-ipv6-nd-04.txt > > There is a need for reducing multicast and broadcast in the > reduced-power and low-processing ability devices that require to save > power and do not want to wake up on multicast/broadcast messages - it > is pretty clear in 802.15.4 network. > The charter talks about the context of IPv6 where multicast is > primarily used for solicitation and advertisement and that will have > to be reduced since 802.15.4 is a shared network. > > I'll re-submit a revised draft before this IETF. > > -Samita > _______________________________________________ > 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_7063_31784402.1213670204763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I am repeating my comments:
 
Samita, are you working for ND-Opt revision ? That's very welcome to me and I am willing to contribute on this deliverable if any chances...:-)
 
[cut and paste from the previous thread]
 
This is a tip for understanding and referring how we can fat down NDP for 6lowpan networks. In 16ng working group, we tried to live up with IEEE 802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA optimization results...

 

Hope those efforts help...

 

Daniel Park

Co-chair, 16ng working group.

 

 

8.2.  Router Advertisement

   The AR SHOULD send a number (configurable value) of router
   advertisements as soon as the IPv6 link is established, to the MS.
   The AR sends unsolicited router advertisements periodically as per
   [RFC4861].  The interval between periodic router advertisements is
   however greater than the specification in Neighbor discovery for
   IPv6, and is discussed in the following section.

8.3.  Router lifetime and periodic router advertisements

   The router lifetime SHOULD be set to a large value, preferably in
   hours.  This document over-rides the specification for the value of
   the router lifetime in Neighbor Discovery for IP Version 6 (IPv6)
   [RFC4861].  The AdvDefaultLifetime in the router advertisement MUST
   be either zero or between MaxRtrAdvInterval and 43200 seconds.  The
   default value is 2 * MaxRtrAdvInterval.

   802.16 hosts have the capability to transition to an idle mode in
   which case the radio link between the BS and MS is torn down.  Paging
   is required in case the network needs to deliver packets to the MS.
   In order to avoid waking a mobile which is in idle mode and consuming
   resources on the air interface, the interval between periodic router
   advertisements SHOULD be set quite high.  The MaxRtrAdvInterval value
   specified in this document over-rides the recommendation in Neighbor
   Discovery for IP Version 6 (IPv6) [ RFC4861].  The MaxRtrAdvInterval
   MUST be no less than 4 seconds and no greater than 21600 seconds.
   The default value for MaxRtrAdvInterval is 10800 seconds.
 



On 6/17/08, Samita Chakrabarti <samitac2@gmail.com> wrote:
Hi Pascal,

On 6/16/08, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> Hi Geoff:
>
> This part:
> "
> such as reusing the structure of the 802.15.4 network
> (e.g., by using the coordinators), and reduce the need for multicast
> by having devices talk to coordinators (without creating a single
> point-of-failure, or changing the semantics of the IPv6 ND
> multicasts)
> "
>
> Might be unwelcome. Seems to dictate solutions, which solutions might be
> hard to achieve at IETF.
> Note that I am in favor of using L2 beacons as opposed to uniquely data
> frames to carry RAs.
> Can we just remove this text for the time being, and just say that we
> want to
> " reduce the need for multicast ", "limit the need to wake up sleeping
> devices", that type of things?

I  respectfully disagree with you on that. The solution that reduce
the need of multicast in IPv6 already exists and it has been discussed
in the working group many times in the past. Please refer to:
draft-chakrabarti-6lowpan-ipv6-nd-04.txt

There is a need for reducing multicast and broadcast in the
reduced-power and low-processing ability devices that require to save
power and do not want to wake up on multicast/broadcast messages - it
is pretty clear in 802.15.4 network.
The charter talks about the context of IPv6 where multicast is
primarily used for solicitation and advertisement and that will have
to be reduced since 802.15.4 is a shared network.

I'll re-submit a revised draft before this IETF.

-Samita
_______________________________________________
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_7063_31784402.1213670204763-- --===============1308934150== 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 --===============1308934150==-- From 6lowpan-bounces@ietf.org Mon Jun 16 23:51: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 6BACB3A6A49; Mon, 16 Jun 2008 23:51: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 C0D0A3A6A44 for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 23:51:22 -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 9ekUjlIHs--J for <6lowpan@core3.amsl.com>; Mon, 16 Jun 2008 23:51:21 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 495183A68BE for <6lowpan@ietf.org>; Mon, 16 Jun 2008 23:51:20 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so5140874rvf.49 for <6lowpan@ietf.org>; Mon, 16 Jun 2008 23:52:04 -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=F/vBeTsXOiD20xMsuSCw5TgyHDD/evrl1H6NQ8Ea4zg=; b=iXaQzj2KsAWxgbASeWv+4Uh+5J70hWedDCbc6tdGzOCY4xFDPinItnkyDHOArRARUH 9PqNfUrxEKcegeJpAujIkgNlDdFQuzi6fkjuk6RiovztpTrRhAGPILld/P9VaDI5xqwe DMEona1WPjd2e3OnE8R2HzH7/rPGIdNijbiTM= 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=uFBTp/YX2L3vokpubdhZGPGMWKk8XNu6gU6174oSdVsAxTwkHUsefqmiipPVvZ0m81 snGlggdlBmMtEJVOwmGjX4cWKRNiSlsuPJkFrjYYELR1gNtOMiKZCVDcKOFDqQymtgZf 6K8b60DnsjNNCV+ULuFUkfdsVQqdImHnp1n/s= Received: by 10.143.31.11 with SMTP id i11mr2740304wfj.328.1213685524433; Mon, 16 Jun 2008 23:52:04 -0700 (PDT) Received: by 10.142.78.9 with HTTP; Mon, 16 Jun 2008 23:52:04 -0700 (PDT) Message-ID: <43b91d370806162352q23c00c91x547d412dae63f51e@mail.gmail.com> Date: Mon, 16 Jun 2008 23:52:04 -0700 From: "Samita Chakrabarti" To: "Daniel Park" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1213296428.19399.54.camel@dellx1> <77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> <1213365573.19399.71.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D16FA8@xmb-ams-337.emea.cisco.com> <43b91d370806161002x60141ad2k92fc6e9512398fa4@mail.gmail.com> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Daniel, Yes, we will have an update of the ND-OPT draft as it has currently in expired state. If you have any specific comment/contribution on ND-OPT, let's discuss off-line. The following information on ND tuning for 802.16 network is useful. Thanks, -Samita On Mon, Jun 16, 2008 at 7:36 PM, Daniel Park wrote: > I am repeating my comments: > > Samita, are you working for ND-Opt revision ? That's very welcome to me and > I am willing to contribute on this deliverable if any chances...:-) > > [cut and paste from the previous thread] > > This is a tip for understanding and referring how we can fat down NDP for > 6lowpan networks. In 16ng working group, we tried to live up with IEEE > 802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA > optimization results... > > > > Hope those efforts help... > > > > Daniel Park > > Co-chair, 16ng working group. > > > > > > 8.2. Router Advertisement > > The AR SHOULD send a number (configurable value) of router > advertisements as soon as the IPv6 link is established, to the MS. > The AR sends unsolicited router advertisements periodically as per > [RFC4861]. The interval between periodic router advertisements is > however greater than the specification in Neighbor discovery for > IPv6, and is discussed in the following section. > > 8.3. Router lifetime and periodic router advertisements > > The router lifetime SHOULD be set to a large value, preferably in > hours. This document over-rides the specification for the value of > the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) > [RFC4861]. The AdvDefaultLifetime in the router advertisement MUST > be either zero or between MaxRtrAdvInterval and 43200 seconds. The > default value is 2 * MaxRtrAdvInterval. > > 802.16 hosts have the capability to transition to an idle mode in > which case the radio link between the BS and MS is torn down. Paging > is required in case the network needs to deliver packets to the MS. > In order to avoid waking a mobile which is in idle mode and consuming > resources on the air interface, the interval between periodic router > advertisements SHOULD be set quite high. The MaxRtrAdvInterval value > specified in this document over-rides the recommendation in Neighbor > Discovery for IP Version 6 (IPv6) [ RFC4861]. The MaxRtrAdvInterval > MUST be no less than 4 seconds and no greater than 21600 seconds. > The default value for MaxRtrAdvInterval is 10800 seconds. > > > On 6/17/08, Samita Chakrabarti wrote: >> >> Hi Pascal, >> >> On 6/16/08, Pascal Thubert (pthubert) wrote: >> > Hi Geoff: >> > >> > This part: >> > " >> > such as reusing the structure of the 802.15.4 network >> > (e.g., by using the coordinators), and reduce the need for multicast >> > by having devices talk to coordinators (without creating a single >> > point-of-failure, or changing the semantics of the IPv6 ND >> > multicasts) >> > " >> > >> > Might be unwelcome. Seems to dictate solutions, which solutions might be >> > hard to achieve at IETF. >> > Note that I am in favor of using L2 beacons as opposed to uniquely data >> > frames to carry RAs. >> > Can we just remove this text for the time being, and just say that we >> > want to >> > " reduce the need for multicast ", "limit the need to wake up sleeping >> > devices", that type of things? >> >> I respectfully disagree with you on that. The solution that reduce >> the need of multicast in IPv6 already exists and it has been discussed >> in the working group many times in the past. Please refer to: >> draft-chakrabarti-6lowpan-ipv6-nd-04.txt >> >> There is a need for reducing multicast and broadcast in the >> reduced-power and low-processing ability devices that require to save >> power and do not want to wake up on multicast/broadcast messages - it >> is pretty clear in 802.15.4 network. >> The charter talks about the context of IPv6 where multicast is >> primarily used for solicitation and advertisement and that will have >> to be reduced since 802.15.4 is a shared network. >> >> I'll re-submit a revised draft before this IETF. >> >> -Samita >> _______________________________________________ >> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 17 01:01:08 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 289B63A697E; Tue, 17 Jun 2008 01:01:08 -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 136A03A697E for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 01:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 0aNgvsi4cWzH for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 01:01:06 -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 A9F673A6874 for <6lowpan@ietf.org>; Tue, 17 Jun 2008 01:01:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,657,1204498800"; d="scan'208";a="11853024" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2008 10:01:48 +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 m5H81lo2025162; Tue, 17 Jun 2008 10:01:47 +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 m5H81mbc025642; Tue, 17 Jun 2008 08:01:48 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, 17 Jun 2008 10:01:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jun 2008 10:01:13 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D6EC0B@xmb-ams-337.emea.cisco.com> In-Reply-To: <43b91d370806161002x60141ad2k92fc6e9512398fa4@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjP0r8czKdtwlV+Q8a8qiI1D5rRuAAfHzBg References: <1213296428.19399.54.camel@dellx1> <77f1dba80806130015p33960229l767afee91142fc8d@mail.gmail.com> <1213365573.19399.71.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D16FA8@xmb-ams-337.emea.cisco.com> <43b91d370806161002x60141ad2k92fc6e9512398fa4@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Samita Chakrabarti" X-OriginalArrivalTime: 17 Jun 2008 08:01:47.0849 (UTC) FILETIME=[64487390:01C8D050] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2309; t=1213689707; x=1214553707; 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=20new=20charter=20text |Sender:=20; bh=WXVvAv9qPAVmxNl3xIutsMlVmgdN9n7rSTLlRgpB6rQ=; b=one5TOzLH283XWOwRHPMA5pe/iXHsxBMOCEJH8Y6ABCIqI0afFzCFoJNjW 8nQUDq3+2sfkbyDD7d3NXFUTsrx09mrp712Breigt8ppXCr5fBGTQ1SBovL+ XhgiWogfVi; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text 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 Samita: I fail to see how we disagree ??? I am suggesting here to change the text that indicates what the solution should *be* into text that indicates what the solution should *be doing*. And we seem to agree on what it should be doing. I certainly read your draft and liked it a lot. I do think there is a need to couple proactive "white board" registration (such as detailed in the BbR draft) with your reactive model and I'm ready to work with you on that anytime. Pascal >-----Original Message----- >From: Samita Chakrabarti [mailto:samitac2@gmail.com] >Sent: lundi 16 juin 2008 19:02 >To: Pascal Thubert (pthubert) >Cc: Geoff Mulligan; 6lowpan >Subject: Re: [6lowpan] New new charter text > >Hi Pascal, > >On 6/16/08, Pascal Thubert (pthubert) wrote: >> Hi Geoff: >> >> This part: >> " >> such as reusing the structure of the 802.15.4 network >> (e.g., by using the coordinators), and reduce the need for multicast >> by having devices talk to coordinators (without creating a single >> point-of-failure, or changing the semantics of the IPv6 ND >> multicasts) >> " >> >> Might be unwelcome. Seems to dictate solutions, which solutions might be >> hard to achieve at IETF. >> Note that I am in favor of using L2 beacons as opposed to uniquely data >> frames to carry RAs. >> Can we just remove this text for the time being, and just say that we >> want to >> " reduce the need for multicast ", "limit the need to wake up sleeping >> devices", that type of things? > >I respectfully disagree with you on that. The solution that reduce >the need of multicast in IPv6 already exists and it has been discussed >in the working group many times in the past. Please refer to: >draft-chakrabarti-6lowpan-ipv6-nd-04.txt > >There is a need for reducing multicast and broadcast in the >reduced-power and low-processing ability devices that require to save >power and do not want to wake up on multicast/broadcast messages - it >is pretty clear in 802.15.4 network. >The charter talks about the context of IPv6 where multicast is >primarily used for solicitation and advertisement and that will have >to be reduced since 802.15.4 is a shared network. > > I'll re-submit a revised draft before this IETF. > >-Samita _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 17 02:01: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 0AB603A69EE; Tue, 17 Jun 2008 02:01: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 8DB9B3A6996 for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 02:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=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 jB9gvddCZfRf for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 02:01:02 -0700 (PDT) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.184]) by core3.amsl.com (Postfix) with ESMTP id A59163A69EE for <6lowpan@ietf.org>; Tue, 17 Jun 2008 02:01:01 -0700 (PDT) Received: by mu-out-0910.google.com with SMTP id g7so3731547muf.9 for <6lowpan@ietf.org>; Tue, 17 Jun 2008 02:01:40 -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=ziZ/VyhOg3GILP2fWZtUDDEdm0yJJ936MELee/hm5H8=; b=FwIum4AmcSCC6yhwnvEoL4EeCu02n6O/+qMIUGnCvnVu7b8sX3X8XV6ycKDElOSmfq Tlrors+pkY6dJKUJPUjQ9bGAcSb83sApvVIhV1AlV5IxOP3NnrICJjXN0Vn3Qb4OJDhD BpACn8zkVWNETF4sjfFhRDo5RJotiRgCVAlVQ= 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=q6k5FiPU910sx6y/S42pbHvC5Jdxr7/J85YmZwxFPlflHLfTjIGXLf2iLL0iZNmFDz /4Wct8RTlf6F2aZ5s1votQhNtXa0jINyuB7r8o7diAuPinfPXnjxR9S7v0y6QANxbWTA D99BJkKheUa5NmXuhxvU82+CxWDYUz00VvmBo= Received: by 10.103.220.18 with SMTP id x18mr1194919muq.81.1213693300362; Tue, 17 Jun 2008 02:01:40 -0700 (PDT) Received: by 10.103.17.12 with HTTP; Tue, 17 Jun 2008 02:01:40 -0700 (PDT) Message-ID: <2a3692de0806170201m2c616a0cr99045c1e22d492fb@mail.gmail.com> Date: Tue, 17 Jun 2008 11:01:40 +0200 From: "Dominik Kaspar" To: "Geoff Mulligan" In-Reply-To: <1213296428.19399.54.camel@dellx1> MIME-Version: 1.0 Content-Disposition: inline References: <1213296428.19399.54.camel@dellx1> Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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, I believe that the Use Cases document is very meaningful work. I will continue to contribute to this document and I agree that finishing the I-D until December 2008 is a feasible goal. Greetings, Dominik On Thu, Jun 12, 2008 at 8:47 PM, Geoff Mulligan wrote: > > I'm sorry JP. I had forgotten that you were an author. I hadn't looked > at the authors and had just remembered Eunsook and Dominik. Sorry to > Nicolas also. > > Since we want to press forward, I'll assume that Dec 08 is a comfortable > date and put this missing piece back into the charter and resend it to > everyone. > > geoff > > On Thu, 2008-06-12 at 20:37 +0200, JP Vasseur wrote: > > > > > > On 6/12/08 8:19 PM, "Geoff Mulligan" wrote: > > > > > This is probably fine. Since we are already no Rev 2 we might be able > > > to complete it sooner, but I don't want to pressure anyone. I hope that > > > the current authors can provide some input. > > > > I'm one of them. Eunah, what do you think ? > > > > JP. > > > > > > > > geoff > > > > > > On Thu, 2008-06-12 at 20:03 +0200, JP Vasseur wrote: > > >> Hi Geoff, > > >> > > >> > > >> On 6/12/08 7:59 PM, "Geoff Mulligan" wrote: > > >> > > >>> Please do not misunderstand my/our intentions. In reading the various > > >>> messages about the rechartering, it did not appear to us as though the > > >>> use-case was a priority item - not that it was not useful or would not > > >>> be useful, just not a priority. That was the only reason it was left > > >>> off of the charter. It was very clear that ND, Arch, and Security were > > >>> at the top of the list. > > >> > > >> And they are on the top of the list, no question about this. > > >> > > >>> > > >>> I am not at all against continuing with the use-case ID in parallel to > > >>> the rest of the documents. I think that it is and could be useful. > > >>> > > >>> I will add it back to charter text, but please let me know a date that > > >>> we can plan to have the ID completed. > > >> > > >> Sure, what about Dec 2008 for IESG submission? > > >> > > >> Thanks. > > >> > > >> JP. > > >> > > >>> > > >>> geoff > > >>> > > >>> On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: > > >>>> Hi Mark, > > >>>> > > >>>> > > >>>> On 6/12/08 4:06 PM, "Mark Townsley" wrote: > > >>>> > > >>>>> Geoff Mulligan wrote: > > >>>>>> It didn't seem to be a priority item. > > >>>>>> > > >>>>>> Perhaps we should consider incorporating the Use Cases into the > > >>>>>> architecture document. > > >>>>> Whether the use-cases are in the arch document or separate is somewhat > > >>>>> orthogonal to whether they are chartered work right now. > > >>>>>> If not then I think once we complete the few > > >>>>>> documents we should then revisit the use cases. > > >>>>>> > > >>>>> I a missing why writing down use-cases is not a good thing to do sooner > > >>>>> rather than later. I don't think it should stop protocol work in its > > >>>>> tracks, but I see no indication right now that it would. As long as the > > >>>>> use-cases are considered informational and can run largely in parallel* > > >>>>> to the normative work at this stage, I don't know why we wouldn't pursue > > >>>>> it. > > >>>>> > > >>>>> - Mark > > >>>>> > > >>>>> *If this were the very beginnings of 6lowpan, I would insist on > > >>>>> use-cases to help drive requirements, architecture, and finally solution > > >>>>> design. While we are somewhat past that stage, I do think they could > > >>>>> still be very useful to ROLL, as well as going forward as we continue to > > >>>>> debate the pros and cons of various optimizations. > > >>>> > > >>>> Absolutely ! The only (but useful) objective is to document 6lowpan > > >>>> application, informational ID of course. > > >>>> > > >>>> Thanks. > > >>>> > > >>>> JP. > > >>>> > > >>>>>> geoff > > >>>>>> > > >>>>>> > > >>>>>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > > >>>>>> > > >>>>>>> Geoff, > > >>>>>>> > > >>>>>>> 6LoWPAN use-case was always in the recharter items, and there was no > > >>>>>>> objection on it. Any reason to take it out? > > >>>>>>> Thanks for the good work. > > >>>>>>> > > >>>>>>> -eunah > > >>>>>>> > > >>>>>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan > > >>>>>>> wrote: > > >>>>>>> > > >>>>>>>> After reviewing the comments on the list and talking with Carsten and > > >>>>>>>> Mark, we have come up with the following text for the Charter. > > >>>>>>>> > > >>>>>>>> We hope (and think) that this reflects the input from the group and > > >>>>>>>> Mark > > >>>>>>>> plans to take this to the IESG for rechartering approval. > > >>>>>>>> > > >>>>>>>> We've had some excellent discussion on a few topics and this is great. > > >>>>>>>> There is no reason why we should stop the discussion and work while > > >>>>>>>> Mark > > >>>>>>>> handles the rechartering. > > >>>>>>>> > > >>>>>>>> 1. I think that the work is proceeding on the Security Analysis > > >>>>>>>> document > > >>>>>>>> 2. We have the current HC1G draft. The issue being discussed is the > > >>>>>>>> "compression" of the UDP checksum and it's impact on the end-to-end > > >>>>>>>> model. I would like to hear more input and discussion on this. Please > > >>>>>>>> speak up if you have thoughts on this. > > >>>>>>>> 3. We have some initial input on the Architecture document and I would > > >>>>>>>> like to hear from anyone that would volunteer to continue to work on > > >>>>>>>> this document. > > >>>>>>>> > > >>>>>>>> geoff > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> _______________________________________________ > > >>>>>>>> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 17 09:47: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 6D95D3A6AAD; Tue, 17 Jun 2008 09:47: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 E306C3A6AA6 for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 mY0r+m-Qz+GY for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 09:47:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E113328C1A1 for <6lowpan@ietf.org>; Tue, 17 Jun 2008 09:46:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,659,1204498800"; d="scan'208";a="11929100" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2008 18:47:28 +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 m5HGlHSv020474; Tue, 17 Jun 2008 18:47: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 m5HGlHEd002106; Tue, 17 Jun 2008 16:47: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, 17 Jun 2008 18:47:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jun 2008 18:47:17 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D6EFA5@xmb-ams-337.emea.cisco.com> In-Reply-To: <4856A7F7.4060407@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] Thread-Index: AcjP2d2WXB3FyAZhR26M+atO8HhQogAr8FvQ References: <4856A7F7.4060407@sun.com> From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , <6lowpan@ietf.org> X-OriginalArrivalTime: 17 Jun 2008 16:47:17.0712 (UTC) FILETIME=[CD8BBD00:01C8D099] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2323; t=1213721237; x=1214585237; 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]=20[Fwd=3A=20New=20Version=20N otification=20fordraft-nordmark-6lowpan-reg-00] |Sender:=20; bh=vLcuUViB9TZbsdI6Q83Y/3ZD3xziUcLQL+kpw3UMzlw=; b=DVpPcr7F2RUKn3PGWVRhevGwMjDX+9EHQ0+UTxEH4osvpmEQugN0sNmskZ vJwOF/nc9y8wpMVva14A9PVKRVFuO5ZOs93GWGZvwr+SyL913iytJ5LhLrrS vDWysFMfCS; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: 6lowpan-bounces@ietf.org Errors-To: 6lowpan-bounces@ietf.org Hi Erik: I like very much your idea of a new registration message, that's cleaner than changing NS like I do in the BbR proposal. OTOH, we do not seem to have the same model for the LoWPAN. In particular, your draft seems to assume that the host would want to reach numerous routers and register to them all. For instance, if you have an oil plant or a factory, it makes little sense for a sensor node to go all across the factory across numerous LoWPAN hops to register to a router that the node will never use. In my mind, the LoWPAN nodes form dynamic clusters around the nearest router and use it. Routers might share a faster, powered network that is called a backbone in ISA parlance, to discover and reach one another. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark >Sent: lundi 16 juin 2008 19:51 >To: 6lowpan@ietf.org >Subject: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00] > > > >-------- Original Message -------- >Subject: New Version Notification for draft-nordmark-6lowpan-reg-00 >Date: Mon, 16 Jun 2008 10:44:02 -0700 (PDT) >From: IETF I-D Submission Tool >To: Erik.Nordmark@sun.com >CC: Erik.Nordmark@sun.com > > >A new version of I-D, draft-nordmark-6lowpan-reg-00.txt has been >successfuly submitted by Erik Nordmark and posted to the IETF repository. > >Filename: draft-nordmark-6lowpan-reg >Revision: 00 >Title: Neighbor Discovery Registration Extension >Creation_date: 2008-06-16 >WG ID: Independent Submission >Number_of_pages: 9 > >Abstract: >In order to reduce Neighbor Discovery multicast messages it is useful >if the routers on a link can maintain an authoritative list of the >IPv6 and layer 2 addresses for all the hosts on the link. > >This draft specifies an extension to the Router Advertisement >messages which trigger to hosts to send periodic registration >messages which can be either unicast, multicast, or anycast. The >protocol uses a soft-state approach to gather registration >information. > > > > >The IETF Secretariat. > > >_______________________________________________ >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 Jun 17 10:42: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 2ECA83A69A1; Tue, 17 Jun 2008 10:42: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 AF95A3A67AD for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 10:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, J_CHICKENPOX_21=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 hFMFtPE7i325 for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 10:42:25 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id C002F3A69A1 for <6lowpan@ietf.org>; Tue, 17 Jun 2008 10:42:25 -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 m5HHge51012661; Tue, 17 Jun 2008 11:42:40 -0600 (MDT) From: Geoff Mulligan To: Dominik Kaspar In-Reply-To: <2a3692de0806170201m2c616a0cr99045c1e22d492fb@mail.gmail.com> References: <1213296428.19399.54.camel@dellx1> <2a3692de0806170201m2c616a0cr99045c1e22d492fb@mail.gmail.com> Date: Tue, 17 Jun 2008 11:42:35 -0600 Message-Id: <1213724555.6200.17.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] new charter text 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 Dominik, Great. Thanks. geoff On Tue, 2008-06-17 at 11:01 +0200, Dominik Kaspar wrote: > Hi, > > I believe that the Use Cases document is very meaningful work. I will > continue to contribute to this document and I agree that finishing the > I-D until December 2008 is a feasible goal. > > Greetings, > Dominik > > > On Thu, Jun 12, 2008 at 8:47 PM, Geoff Mulligan wrote: > > > > I'm sorry JP. I had forgotten that you were an author. I hadn't looked > > at the authors and had just remembered Eunsook and Dominik. Sorry to > > Nicolas also. > > > > Since we want to press forward, I'll assume that Dec 08 is a comfortable > > date and put this missing piece back into the charter and resend it to > > everyone. > > > > geoff > > > > On Thu, 2008-06-12 at 20:37 +0200, JP Vasseur wrote: > > > > > > > > > On 6/12/08 8:19 PM, "Geoff Mulligan" wrote: > > > > > > > This is probably fine. Since we are already no Rev 2 we might be able > > > > to complete it sooner, but I don't want to pressure anyone. I hope that > > > > the current authors can provide some input. > > > > > > I'm one of them. Eunah, what do you think ? > > > > > > JP. > > > > > > > > > > > geoff > > > > > > > > On Thu, 2008-06-12 at 20:03 +0200, JP Vasseur wrote: > > > >> Hi Geoff, > > > >> > > > >> > > > >> On 6/12/08 7:59 PM, "Geoff Mulligan" wrote: > > > >> > > > >>> Please do not misunderstand my/our intentions. In reading the various > > > >>> messages about the rechartering, it did not appear to us as though the > > > >>> use-case was a priority item - not that it was not useful or would not > > > >>> be useful, just not a priority. That was the only reason it was left > > > >>> off of the charter. It was very clear that ND, Arch, and Security were > > > >>> at the top of the list. > > > >> > > > >> And they are on the top of the list, no question about this. > > > >> > > > >>> > > > >>> I am not at all against continuing with the use-case ID in parallel to > > > >>> the rest of the documents. I think that it is and could be useful. > > > >>> > > > >>> I will add it back to charter text, but please let me know a date that > > > >>> we can plan to have the ID completed. > > > >> > > > >> Sure, what about Dec 2008 for IESG submission? > > > >> > > > >> Thanks. > > > >> > > > >> JP. > > > >> > > > >>> > > > >>> geoff > > > >>> > > > >>> On Thu, 2008-06-12 at 19:50 +0200, JP Vasseur wrote: > > > >>>> Hi Mark, > > > >>>> > > > >>>> > > > >>>> On 6/12/08 4:06 PM, "Mark Townsley" wrote: > > > >>>> > > > >>>>> Geoff Mulligan wrote: > > > >>>>>> It didn't seem to be a priority item. > > > >>>>>> > > > >>>>>> Perhaps we should consider incorporating the Use Cases into the > > > >>>>>> architecture document. > > > >>>>> Whether the use-cases are in the arch document or separate is somewhat > > > >>>>> orthogonal to whether they are chartered work right now. > > > >>>>>> If not then I think once we complete the few > > > >>>>>> documents we should then revisit the use cases. > > > >>>>>> > > > >>>>> I a missing why writing down use-cases is not a good thing to do sooner > > > >>>>> rather than later. I don't think it should stop protocol work in its > > > >>>>> tracks, but I see no indication right now that it would. As long as the > > > >>>>> use-cases are considered informational and can run largely in parallel* > > > >>>>> to the normative work at this stage, I don't know why we wouldn't pursue > > > >>>>> it. > > > >>>>> > > > >>>>> - Mark > > > >>>>> > > > >>>>> *If this were the very beginnings of 6lowpan, I would insist on > > > >>>>> use-cases to help drive requirements, architecture, and finally solution > > > >>>>> design. While we are somewhat past that stage, I do think they could > > > >>>>> still be very useful to ROLL, as well as going forward as we continue to > > > >>>>> debate the pros and cons of various optimizations. > > > >>>> > > > >>>> Absolutely ! The only (but useful) objective is to document 6lowpan > > > >>>> application, informational ID of course. > > > >>>> > > > >>>> Thanks. > > > >>>> > > > >>>> JP. > > > >>>> > > > >>>>>> geoff > > > >>>>>> > > > >>>>>> > > > >>>>>> On Thu, 2008-06-12 at 10:49 +0900, Eunsook "Eunah" Kim wrote: > > > >>>>>> > > > >>>>>>> Geoff, > > > >>>>>>> > > > >>>>>>> 6LoWPAN use-case was always in the recharter items, and there was no > > > >>>>>>> objection on it. Any reason to take it out? > > > >>>>>>> Thanks for the good work. > > > >>>>>>> > > > >>>>>>> -eunah > > > >>>>>>> > > > >>>>>>> On Thu, Jun 12, 2008 at 4:02 AM, Geoff Mulligan > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>>> After reviewing the comments on the list and talking with Carsten and > > > >>>>>>>> Mark, we have come up with the following text for the Charter. > > > >>>>>>>> > > > >>>>>>>> We hope (and think) that this reflects the input from the group and > > > >>>>>>>> Mark > > > >>>>>>>> plans to take this to the IESG for rechartering approval. > > > >>>>>>>> > > > >>>>>>>> We've had some excellent discussion on a few topics and this is great. > > > >>>>>>>> There is no reason why we should stop the discussion and work while > > > >>>>>>>> Mark > > > >>>>>>>> handles the rechartering. > > > >>>>>>>> > > > >>>>>>>> 1. I think that the work is proceeding on the Security Analysis > > > >>>>>>>> document > > > >>>>>>>> 2. We have the current HC1G draft. The issue being discussed is the > > > >>>>>>>> "compression" of the UDP checksum and it's impact on the end-to-end > > > >>>>>>>> model. I would like to hear more input and discussion on this. Please > > > >>>>>>>> speak up if you have thoughts on this. > > > >>>>>>>> 3. We have some initial input on the Architecture document and I would > > > >>>>>>>> like to hear from anyone that would volunteer to continue to work on > > > >>>>>>>> this document. > > > >>>>>>>> > > > >>>>>>>> geoff > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> _______________________________________________ > > > >>>>>>>> 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 17 12:33:58 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 1204E28C165; Tue, 17 Jun 2008 12:33:58 -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 8AFF928C165 for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv4xukBO090f for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 12:33:56 -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 73F3028C0E2 for <6lowpan@ietf.org>; Tue, 17 Jun 2008 12:33:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,660,1204520400"; d="scan'208";a="11281336" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Jun 2008 15:34:41 -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 m5HJYfp8002189; Tue, 17 Jun 2008 15:34:41 -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 m5HJYfnc015612; Tue, 17 Jun 2008 19:34:41 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); Tue, 17 Jun 2008 15:34:40 -0400 Received: from 10.21.121.28 ([10.21.121.28]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 17 Jun 2008 19:34:40 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Tue, 17 Jun 2008 16:55:34 +0200 From: JP Vasseur To: Carsten Bormann Message-ID: Thread-Topic: [6lowpan] New new charter text (resend) Thread-Index: AcjQijHSgsrzy+a7YUOMlU63f4crTQ== In-Reply-To: <0D3C4D1A-BD4D-47DC-A3E2-357FD5498569@tzi.org> Mime-version: 1.0 X-OriginalArrivalTime: 17 Jun 2008 19:34:40.0952 (UTC) FILETIME=[2FC88B80:01C8D0B1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=707; t=1213731281; x=1214595281; 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=20new=20charter=20text= 20(resend) |Sender:=20 |To:=20Carsten=20Bormann=20; bh=iw1bGFzOZtMO/IEKpbEEaXILxhYm1jQ3PGghxM20Sns=; b=TZ+0dAg7ObSmfA8CfuSX3B3kaqCxe9Fm3JP0seBSHQyVwBYw8jyJyn08+i TM6fzg0yczD47q5UvqOe7Kz6IbbzQnQYbqNgITZnEjS6/I1qSLPLY1ZlTwsL beLq6OKlW8; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text (resend) 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 Carsten, On 6/16/08 9:22 PM, "Carsten Bormann" wrote: > On Jun 16 2008, at 19:43, JP Vasseur wrote: > >> (2) A separate ID dealing with the subject and used to draw a >> consensus. > > > (Assuming you mean on the question of L2 forwarding yes [mesh-under] > or no [route-over]:) > > As I said, I'm not sure we are even getting any closer to a consensus. > Why should the WG try to make that decision? Why now? (This is not > just a rethorical question!) Just because it may not be a bad idea to close on this if you do not want this topic to pop again in a few month but if you think that this is not necessary, fine ... JP. > > Gruesse, Carsten > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Jun 17 13:15: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 A77FF3A6B67; Tue, 17 Jun 2008 13:15: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 A4BAA3A6B75 for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 13:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.340, 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 buWadCGsIz7C for <6lowpan@core3.amsl.com>; Tue, 17 Jun 2008 13:15:56 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id D43AB3A6B67 for <6lowpan@ietf.org>; Tue, 17 Jun 2008 13:15:55 -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 m5HKGb2Q013965; Tue, 17 Jun 2008 14:16:37 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Date: Tue, 17 Jun 2008 14:16:32 -0600 Message-Id: <1213733792.10227.28.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text (resend) 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 So then can we agree that the charter text can stand as it was sent out on 13 June. Anyone not agreeing? geoff On Tue, 2008-06-17 at 16:55 +0200, JP Vasseur wrote: > Hi Carsten, > > > On 6/16/08 9:22 PM, "Carsten Bormann" wrote: > > > On Jun 16 2008, at 19:43, JP Vasseur wrote: > > > >> (2) A separate ID dealing with the subject and used to draw a > >> consensus. > > > > > > (Assuming you mean on the question of L2 forwarding yes [mesh-under] > > or no [route-over]:) > > > > As I said, I'm not sure we are even getting any closer to a consensus. > > Why should the WG try to make that decision? Why now? (This is not > > just a rethorical question!) > > Just because it may not be a bad idea to close on this if you do not want > this topic to pop again in a few month but if you think that this is not > necessary, fine ... > > JP. > > > > > Gruesse, Carsten > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 18 02:57:58 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 43C5C3A6A98; Wed, 18 Jun 2008 02:57:58 -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 269C328C1BD for <6lowpan@core3.amsl.com>; Wed, 18 Jun 2008 02:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 z9z-oNDz4-9T for <6lowpan@core3.amsl.com>; Wed, 18 Jun 2008 02:57:56 -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 D860E3A6836 for <6lowpan@ietf.org>; Wed, 18 Jun 2008 02:57:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,663,1204520400"; d="scan'208";a="11351411" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 18 Jun 2008 05:58:43 -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 m5I9wgbJ028051; Wed, 18 Jun 2008 05:58:42 -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 m5I9wgU3007461; Wed, 18 Jun 2008 09:58:42 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); Wed, 18 Jun 2008 05:58:42 -0400 Received: from 10.21.73.5 ([10.21.73.5]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 18 Jun 2008 09:58:42 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 18 Jun 2008 11:58:40 +0200 From: JP Vasseur To: Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] New new charter text (resend) Thread-Index: AcjRKeJDl6qdAsp8ckCgRjIeNXZe5Q== In-Reply-To: <1213733792.10227.28.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 18 Jun 2008 09:58:42.0366 (UTC) FILETIME=[E3AC8DE0:01C8D129] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2588; t=1213783122; x=1214647122; 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=20new=20charter=20text= 20(resend) |Sender:=20 |To:=20Geoff=20Mulligan=20; bh=E+Nkp/h6w78+vLLPqtlU3gVnf5Il56cQHtGcoOV19Rc=; b=X9nRRxOPRObneZ2Q0wxXCBgwOGCQr6PSRgV5gaMvDGc71wyR8fuzWMHiIX GBvCGuWlrs8NjgNR8T50w3yU2JD0tv/ruHfEnqDNMt6J+niZRA+t5AotjfhQ 8/a/GXouIX; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text (resend) 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 6/17/08 10:16 PM, "Geoff Mulligan" wrote: > So then can we agree that the charter text can stand as it was sent out > on 13 June. Well I do not see a consensus here ... Looking at the emails on the subject, 2 in favor, 2 opposed. My proposal. Original text: 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 such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. As a spin-off from that document, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. Both documents will be informational. I see that some people want to see the concept of mesh-under and route over covered in the architecture document, fine (although it looks pretty straightforward). The text I'm disagreeing with is: " As a spin-off from that document, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. Both documents will be informational." Why a spin-off ? Make it a separate ID in the first place. Requirements should NOT be discussed in architecture ID. Furthermore, I would slightly reword, remove "addressing both the "route-over" and "mesh-under" approach. And mention that the document will be owned by 6owpan and reviewed by ROLL. Does it make sense ? Thanks. JP. > > Anyone not agreeing? > > geoff > > On Tue, 2008-06-17 at 16:55 +0200, JP Vasseur wrote: >> Hi Carsten, >> >> >> On 6/16/08 9:22 PM, "Carsten Bormann" wrote: >> >>> On Jun 16 2008, at 19:43, JP Vasseur wrote: >>> >>>> (2) A separate ID dealing with the subject and used to draw a >>>> consensus. >>> >>> >>> (Assuming you mean on the question of L2 forwarding yes [mesh-under] >>> or no [route-over]:) >>> >>> As I said, I'm not sure we are even getting any closer to a consensus. >>> Why should the WG try to make that decision? Why now? (This is not >>> just a rethorical question!) >> >> Just because it may not be a bad idea to close on this if you do not want >> this topic to pop again in a few month but if you think that this is not >> necessary, fine ... >> >> JP. >> >>> >>> Gruesse, Carsten >>> > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 18 04:16:39 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 CDA573A6AB8; Wed, 18 Jun 2008 04:16:39 -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 16DEC3A6AB8 for <6lowpan@core3.amsl.com>; Wed, 18 Jun 2008 04:16:39 -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 o7q3DM2EzpZf for <6lowpan@core3.amsl.com>; Wed, 18 Jun 2008 04:16:37 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2921A3A69A5 for <6lowpan@ietf.org>; Wed, 18 Jun 2008 04:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5IBGuAo008406; Wed, 18 Jun 2008 13:16:59 +0200 (CEST) Message-Id: <04CD915D-97CE-42EB-9D3D-C1DBA6351DC9@tzi.org> From: Carsten Bormann To: JP Vasseur In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 18 Jun 2008 13:16:55 +0200 References: X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] New new charter text (resend) 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 > " As a spin-off from that document, "6LoWPAN Routing Requirements" > will > describe 6LoWPAN-specific requirements on routing protocols used in > 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. > Both documents will be informational." > > Why a spin-off ? Sorry, this was poor wording on my part. > Make it a separate ID in the first place. That is what is intended. s/As a spin-off from that document/As a separate I-D/ Give that number 4, and move 4 and 5 to 5 and 6. Add "This document will be informational." at the end of 3, and change "Both documents will be informational." to "This document will be informational." at the end of 4 new. > Requirements > should NOT be discussed in architecture ID. Fine. (Hope that is fixed by the change above.) [As a side note, there are things that are called "architectural requirements" (1).] > Furthermore, I would slightly > reword, remove "addressing both the "route-over" and "mesh-under" > approach. I think this is implicit, so the verbiage is just redundant specificity, but I would like to keep it in order to not rehash this discussion every month. > And mention that the document will be owned by 6owpan and reviewed > by ROLL. Saying that explicitly won't hurt; I agree. Add "This document will be owned by the 6LOWPAN WG and developed in close cooperation with the ROLL WG." after "approach". Are we done now? Gruesse, Carsten (1) See, e.g., http://www.ibm.com/developerworks/rational/library/4706.html for a systematic approach to architectural requirements. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Jun 18 21:30:15 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 36BC63A6B15; Wed, 18 Jun 2008 21:30:15 -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 A349428B23E for <6lowpan@core3.amsl.com>; Wed, 18 Jun 2008 21:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 qXD+tC+ATJJ8 for <6lowpan@core3.amsl.com>; Wed, 18 Jun 2008 21:30:13 -0700 (PDT) Received: from grab.coslabs.com (grab.coslabs.com [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 202723A69DD for <6lowpan@ietf.org>; Wed, 18 Jun 2008 21:30: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 m5ILCiWi024244 for <6lowpan@ietf.org>; Wed, 18 Jun 2008 15:12:44 -0600 (MDT) From: Geoff Mulligan To: 6lowpan <6lowpan@ietf.org> Content-Type: multipart/mixed; boundary="=-f8JoJUPE5KMGoeAceQv3" Date: Wed, 18 Jun 2008 15:12:41 -0600 Message-Id: <1213823561.6003.88.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Subject: [6lowpan] revised new new charter text 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 --=-f8JoJUPE5KMGoeAceQv3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Perhaps i should have put rev numbers on it... After the current discussion I think that this is what we have arrived at. Please see attached. geoff --=-f8JoJUPE5KMGoeAceQv3 Content-Disposition: attachment; filename=charter.txt Content-Type: text/plain; name=charter.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 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 such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: --------------------- - Aug 2008 - Submit Improved Header Compression document to IESG for consideration as a proposed standard. - Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC. - Sep 2008 - Submit Architecture document to IESG for consideration as an Informational RFC - Sep 2008 - Submit Routing Requirements document to IESG for consideration as an Informational RFC - Nov 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard - Dec 2008 - Submit Use Case document to IESG as an Informational RFC. --=-f8JoJUPE5KMGoeAceQv3 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 --=-f8JoJUPE5KMGoeAceQv3-- From 6lowpan-bounces@ietf.org Thu Jun 19 02:38: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 D9CA13A6922; Thu, 19 Jun 2008 02:38: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 AF41F3A6B6A for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 02:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 MeQTKkMX4VQd for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 02:38:30 -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 E498F3A6922 for <6lowpan@ietf.org>; Thu, 19 Jun 2008 02:38:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,671,1204498800"; d="scan'208";a="12103356" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2008 11:39:12 +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 m5J9dCXY010243; Thu, 19 Jun 2008 11:39:12 +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 m5J9dC6X007954; Thu, 19 Jun 2008 09:39:12 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, 19 Jun 2008 11:39:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 11:38:26 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> In-Reply-To: <1213823561.6003.88.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] revised new new charter text Thread-Index: AcjRxVTVpDaEHnI2RS65hOhGvy/q7gAKqYqw References: <1213823561.6003.88.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "Carsten Bormann" X-OriginalArrivalTime: 19 Jun 2008 09:39:12.0015 (UTC) FILETIME=[5480E9F0:01C8D1F0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=587; t=1213868352; x=1214732352; 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]=20revised=20new=20new=20chart er=20text |Sender:=20; bh=kuGTEiG3wXao140QWBuEHESTy2jiQvrKTkNqor/tyVI=; b=q+6v9TE9lGexCA14pee/buPym5XccJV8TFreGFan3mgPDA2/b3tAqiWmQ8 q6xjhLtH1JiY2GfADib46L0Eu7RUOlwSyP/cqw+ws5yDtLl+O90ZilWdtHW5 53ms9NPFyj; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] revised new new charter text 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: The work on fragment recovery and flow control is still missing. I did not figure that Carsten's mail meant that e should not do it. Did I miss something? Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Geoff Mulligan >Sent: mercredi 18 juin 2008 23:13 >To: 6lowpan >Subject: [6lowpan] revised new new charter text > >Perhaps i should have put rev numbers on it... > >After the current discussion I think that this is what we have arrived >at. > >Please see attached. > > geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 19 03:01: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 DDAB928C204; Thu, 19 Jun 2008 03:01: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 58F5828C204 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 03:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 bGyPNXMZL4sQ for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 03:01:18 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id EEFA828C0FF for <6lowpan@ietf.org>; Thu, 19 Jun 2008 03:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5JA1oKH011337; Thu, 19 Jun 2008 12:01:54 +0200 (CEST) Message-Id: From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 19 Jun 2008 12:01:50 +0200 References: <1213823561.6003.88.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] revised new new charter text 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 Jun 19 2008, at 11:38, Pascal Thubert (pthubert) wrote: > The work on fragment recovery and flow control is still missing. I did > not figure that Carsten's mail meant that e should not do it. Did I > miss > something? My proposal was to spend some more time shaping these potential work items instead of including them in this round. Since we need to finish the charter now; we should not wait until we fully understand what we want to do on these issues; we can always add new work items later. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 19 06:00:09 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 3E5C428C117; Thu, 19 Jun 2008 06:00:09 -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 CB4FE28C117 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 06:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 yRFbzMMl+Hnx for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 06:00:03 -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 63E5C28C10C for <6lowpan@ietf.org>; Thu, 19 Jun 2008 06:00:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,672,1204498800"; d="scan'208";a="12131736" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2008 15:00: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 m5JD0oXx016792; Thu, 19 Jun 2008 15:00: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 m5JD0nSE012608; Thu, 19 Jun 2008 13:00: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, 19 Jun 2008 15:00:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jun 2008 15:00:14 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05D6F815@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] revised new new charter text Thread-Index: AcjR846q5Drvx7awQ/2AWf3SPnOviwAFqRRg References: <1213823561.6003.88.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" X-OriginalArrivalTime: 19 Jun 2008 13:00:50.0695 (UTC) FILETIME=[7FE0F970:01C8D20C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1677; t=1213880450; x=1214744450; 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]=20revised=20new=20new=20chart er=20text |Sender:=20; bh=sYT/CawfUCn+n804GHd1ep9fWq2oUrTkOnsymSwqAg0=; b=hOEjC4+ybRGcHn5esCECD1V0SITsZoLN24yzJd0DfsEvpf4X8RjONFk8bo UvMxdFv4Le8Ylff+PR5A750vSuiENkoG/kf3gGnX9yn4/+zepFzPa/AbJXxi NwClusaxMY; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] revised new new charter text 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 Carsten: I'm not buying this. The way the charter is worded we can do nothing on these issues because we are not chartered to and that would be distraction to the chartered items. If we wish to "fully understand what we want to do on these issues", then we need at least to charter a Problem Statement work. But I'd think that flow control and ECN are known well enough already so we could figure intuitively what they would do for 6LoWPAN; in that case, the question is really whether we think there's a need for those flow control and ECN to cover our own fragmentation, or not. It should not be rocket science for the people in this group to figure that out and I haven't seen disagreement so far. There's advanced work available from quite some time in this group on this issue, and taking that work out now seems a bit arbitrary to me. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: jeudi 19 juin 2008 12:02 >To: Pascal Thubert (pthubert) >Cc: Carsten Bormann; Geoff Mulligan; 6lowpan >Subject: Re: [6lowpan] revised new new charter text > >On Jun 19 2008, at 11:38, Pascal Thubert (pthubert) wrote: > >> The work on fragment recovery and flow control is still missing. I did >> not figure that Carsten's mail meant that e should not do it. Did I >> miss >> something? > >My proposal was to spend some more time shaping these potential work >items instead of including them in this round. >Since we need to finish the charter now; we should not wait until we >fully understand what we want to do on these issues; we can always add >new work items later. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 19 07:36: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 E9BEB3A67A2; Thu, 19 Jun 2008 07:36: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 419EF3A67A2 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 07:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqLmgrzSq19B for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 07:36:49 -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 6EFCD3A6767 for <6lowpan@ietf.org>; Thu, 19 Jun 2008 07:36:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,672,1204531200"; d="scan'208";a="81611468" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Jun 2008 07:37:40 -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 m5JEbeVA006205 for <6lowpan@ietf.org>; Thu, 19 Jun 2008 07:37:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5JEbYgY022463 for <6lowpan@ietf.org>; Thu, 19 Jun 2008 14:37:40 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 07:37:25 -0700 Received: from Townsley-MacBook.local ([10.21.124.89]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 07:37:22 -0700 Message-ID: <485A6F1A.3010301@cisco.com> Date: Thu, 19 Jun 2008 16:37:14 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> References: <1213823561.6003.88.camel@dellx1> In-Reply-To: <1213823561.6003.88.camel@dellx1> X-OriginalArrivalTime: 19 Jun 2008 14:37:23.0758 (UTC) FILETIME=[FCD03CE0:01C8D219] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8190; t=1213886260; x=1214750260; c=relaxed/simple; s=sjdkim1004; 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=20text=20-=20Last=20Call=20(or=20 you=20don't=20get=20a=20new=20charter=20before=0A=20Dublin) |Sender:=20; bh=MFJHRQuVu1SC0wEJZe4EXrd/OTWNi7uiJWf7SmB8ll4=; b=L55I4mufMW1jSgvdMru8NgR9UHn1aLdFj+dtdkvEKHQcj65Ww/KuQtsxLm t60w8L0p8Iyi3zncFo0/l8dA++2JJ3DkwBsiA7r498ALE1+RF7iZXC1tjniX 7E4EzGaW3IqpemcnySoqB88nFhLYsD3DqdxLc3SAKwwQdIG0MGH6Q=; Authentication-Results: sj-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [6lowpan] New charter text - Last Call (or you don't get a new charter before Dublin) 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 Chairs, All, This looks like a pretty good chunk of work for this recharter, and I'd like to get this to the IESG ASAP. Please know that 6lowpan can continue discussing issues outside of this charter (such as fragmentation recovery and the like) as long as it doesn't obviously begin to stand in the way of your deliverables below. Finishing all this in the next 6 months sounds a little aggressive to me, but I'm happy to support taking the current momentum you have and running with it. The only change I would make is perhaps removing the first paragraph. 6lowpan has been around long enough that I think we can consider that there is precedent for this type of activity. Please consider this a 1 week Last Call, ending June 26. Unless I hear strong objections, I will put this on the IESG Telechat for IETF review July 3 (with approval on July 17 if that goes well). You will notice that this means if the charter isn't ready to go on June 26 at the end of this last call, you won't have a new charter before Dublin. Thanks for all of the hard work, I'm looking forward to the WG meeting these aggressive deadlines. - 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 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 ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. Work Items: ----------- 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "6LoWPAN Improved Header Compression" to describe mechanisms to allow enhancements to the 6LoWPAN headers. Specifically this document will describe compression of addresses that are not link-local. Additionally this document may include other enhancements or optimizations of the HC1 or HC2 6LoWPAN headers. This document will be a proposed standard. 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 such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. This document will be informational. 4. As a separate Internet Draft, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. This document will be created and owned by this working group but is expected to be reviewed by the ROLL WG. This document will be informational. 5. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 6. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: ------------------------- The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: --------------------- - Aug 2008 - Submit Improved Header Compression document to IESG for consideration as a proposed standard. - Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC. - Sep 2008 - Submit Architecture document to IESG for consideration as an Informational RFC - Sep 2008 - Submit Routing Requirements document to IESG for consideration as an Informational RFC - Nov 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard - Dec 2008 - Submit Use Case document to IESG as an 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 Jun 19 07:37: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 5DA343A6889; Thu, 19 Jun 2008 07:37: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 0027F3A6889 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 07:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.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 JMNZid1Ao5y9 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 07:37:14 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id D89523A6767 for <6lowpan@ietf.org>; Thu, 19 Jun 2008 07:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5JEbLMF022935; Thu, 19 Jun 2008 16:37:24 +0200 (CEST) Message-Id: From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05D6F815@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 19 Jun 2008 16:37:20 +0200 References: <1213823561.6003.88.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05D6F815@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) Cc: Carsten Bormann , 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] revised new new charter text 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 Jun 19 2008, at 15:00, Pascal Thubert (pthubert) wrote: > The way the charter is worded we can do nothing on these issues > because > we are not chartered to and that would be distraction to the chartered > items. Pascal, this is not the way we want to work here -- the charter items are the ones we *promise* to deliver; but we do have a maintenance item in there, and we can use that to build problem statements and even solutions. In other words, I would look forward to a session slot in Dublin where we can make progress on this. But I don't want to hold up the charter now. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 19 08:01: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 B8D123A6898; Thu, 19 Jun 2008 08: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 2BD313A6898 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 08:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 HwlqWWaj0g-x for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 08:01:45 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 420C33A6767 for <6lowpan@ietf.org>; Thu, 19 Jun 2008 08:01:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,672,1204531200"; d="scan'208";a="16255707" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 19 Jun 2008 08:02:36 -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 m5JF2awL026367; Thu, 19 Jun 2008 08:02:36 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5JF2axP020463; Thu, 19 Jun 2008 15:02:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 08:02:36 -0700 Received: from Townsley-MacBook.local ([10.21.124.89]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jun 2008 08:02:34 -0700 Message-ID: <485A7501.7010803@cisco.com> Date: Thu, 19 Jun 2008 17:02:25 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Carsten Bormann References: <1213823561.6003.88.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05D6F815@xmb-ams-337.emea.cisco.com> In-Reply-To: X-OriginalArrivalTime: 19 Jun 2008 15:02:35.0794 (UTC) FILETIME=[820E9F20:01C8D21D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1599; t=1213887756; x=1214751756; c=relaxed/simple; s=sjdkim1004; 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]=20revised=20new=20new=20chart er=20text |Sender:=20; bh=3ZzCrZksY78/aUZuIyYiE8R5bSSME/3YW/m56eskhsM=; b=Ui+nxerHSXuvNHDJjMjD0y53ZeGoFIaNNLX7iDXs86j+F9K7Ai015TKmK3 eROLkQv6R+HPcRvhjS8u4hTwI9wIl+n5g1ZlI0sY18+niOxLQnfl3ySorvPD E4P4d84C4FVjB/eYUKr6C+zHvN1LgPgc59c9gP3S0qOhEOR2L2iCs=; Authentication-Results: sj-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] revised new new charter text 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 Carsten Bormann wrote: > On Jun 19 2008, at 15:00, Pascal Thubert (pthubert) wrote: > > >> The way the charter is worded we can do nothing on these issues >> because >> we are not chartered to and that would be distraction to the chartered >> items. >> As long as they are not a distraction, then you can work on whatever you would like :-) In the past (2 or 3 years ago?) I did slap a mandate on this group to stop talking about unchartered work before the most basic deliverables were achieved. That time has passed, and the floodgates are open again. Please contribute and do work on whatever you think is important. I'd like to take the current charter to the IESG as is if there is consensus to do so, keeping in mind that as long as you stay on track as a WG, and as long as the discussion of unchartered work isn't seemingly holding up progress on chartered work, you can discuss and work on whatever you wish on this list and in the WG meetings. Thanks, - Mark > Pascal, > > this is not the way we want to work here -- the charter items are the > ones we *promise* to deliver; but we do have a maintenance item in > there, and we can use that to build problem statements and even > solutions. > > In other words, I would look forward to a session slot in Dublin where > we can make progress on this. > But I don't want to hold up the charter now. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Jun 19 11:09: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 1E4553A694C; Thu, 19 Jun 2008 11:09: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 C761D3A6992 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 11:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PzCz3IoNkL4 for <6lowpan@core3.amsl.com>; Thu, 19 Jun 2008 11:09:28 -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 958983A684B for <6lowpan@ietf.org>; Thu, 19 Jun 2008 11:09:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,673,1204520400"; d="scan'208";a="11647234" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2008 14:10:19 -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 m5JIAJRO006304; Thu, 19 Jun 2008 14:10:19 -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 m5JIAIwV028159; Thu, 19 Jun 2008 18:10:19 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, 19 Jun 2008 14:10:18 -0400 Received: from 10.21.149.51 ([10.21.149.51]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 19 Jun 2008 18:10:18 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 19 Jun 2008 18:47:37 +0200 From: JP Vasseur To: Geoff Mulligan , 6lowpan <6lowpan@ietf.org> Message-ID: Thread-Topic: [6lowpan] revised new new charter text Thread-Index: AcjSLC3eIZ43ZyYoYEOJhXXYEf8cHA== In-Reply-To: <1213823561.6003.88.camel@dellx1> Mime-version: 1.0 X-OriginalArrivalTime: 19 Jun 2008 18:10:18.0838 (UTC) FILETIME=[BB5ABF60:01C8D237] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=449; t=1213899019; x=1214763019; 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]=20revised=20new=20new=20chart er=20text |Sender:=20 |To:=20Geoff=20Mulligan=20,=206lowpan= 20<6lowpan@ietf.org>; bh=oG0BX8U3SgBRycri8C3KfX+IsHQc+nTo5hVW8m+HF+s=; b=VcopZnaZQDISUdYpOqQloeLXZ700VgI9rMzJetmYj3246sB5CGNEeg9IgL 6fZa+riCwXxIVZVkAQFAIn0dzKPlcuDq9CPv9J/9Oiaffp4IDVsb+l5izw37 McICxtelzn; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [6lowpan] revised new new charter text 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 Thanks for the changes. Cheers. JP. On 6/18/08 11:12 PM, "Geoff Mulligan" wrote: > Perhaps i should have put rev numbers on it... > > After the current discussion I think that this is what we have arrived > at. > > Please see attached. > > geoff > > _______________________________________________ > 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 Mon Jun 23 15:21: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 392533A6A9E; Mon, 23 Jun 2008 15:21: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 6663C3A6A9E for <6lowpan@core3.amsl.com>; Mon, 23 Jun 2008 15:21:31 -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 f6kFb39a5utZ for <6lowpan@core3.amsl.com>; Mon, 23 Jun 2008 15:21:30 -0700 (PDT) Received: from whasmtp-shoe.pas.sa.earthlink.net (whasmtp-shoe.pas.sa.earthlink.net [207.217.120.47]) by core3.amsl.com (Postfix) with ESMTP id 88A013A6A9B for <6lowpan@ietf.org>; Mon, 23 Jun 2008 15:21:30 -0700 (PDT) Received: from [63.164.145.161] (helo=KDDILAB) by whasmtp-shoe.pas.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KAuPZ-0007RW-9R; Mon, 23 Jun 2008 15:21:26 -0700 From: "carl williams" To: "'Mark Townsley'" , "'Carsten Bormann'" References: <1213823561.6003.88.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC05D6F6B6@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05D6F815@xmb-ams-337.emea.cisco.com> <485A7501.7010803@cisco.com> Date: Mon, 23 Jun 2008 15:21:19 -0700 Message-ID: <00d301c8d57f$779a1a50$7500a8c0@KDDILAB> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <485A7501.7010803@cisco.com> Thread-Index: AcjSHZejG45WABVzS7+eWklHUAchyQDYYT+Q X-ELNK-Trace: aa5a20d1594cbd964b279780b5ba4f22d780f4a490ca6956abb457f1b4332f52dcd01f0b418e11a280b28020242ff1fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 63.164.145.161 Cc: '6lowpan' <6lowpan@ietf.org> Subject: Re: [6lowpan] revised new new charter text 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 and Carsten, I agree with the current charter. There was an item that Geoff Mulligan presented on mobility and sensors at the last IETF 6lowpan meeting. It is not a priority currently but will be in the future. So it is good that while the working group keeps on track with current work items that we may continue to discuss the subject that Geoff raised at the last meeting if time permits (and we continue to make progress on current agenda items). I agree with your proposal for discussing work and thanks for the hard work on the getting a new charter. Carl -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Thursday, June 19, 2008 8:02 AM To: Carsten Bormann Cc: 6lowpan Subject: Re: [6lowpan] revised new new charter text Carsten Bormann wrote: > On Jun 19 2008, at 15:00, Pascal Thubert (pthubert) wrote: > > >> The way the charter is worded we can do nothing on these issues >> because >> we are not chartered to and that would be distraction to the chartered >> items. >> As long as they are not a distraction, then you can work on whatever you would like :-) In the past (2 or 3 years ago?) I did slap a mandate on this group to stop talking about unchartered work before the most basic deliverables were achieved. That time has passed, and the floodgates are open again. Please contribute and do work on whatever you think is important. I'd like to take the current charter to the IESG as is if there is consensus to do so, keeping in mind that as long as you stay on track as a WG, and as long as the discussion of unchartered work isn't seemingly holding up progress on chartered work, you can discuss and work on whatever you wish on this list and in the WG meetings. Thanks, - Mark > Pascal, > > this is not the way we want to work here -- the charter items are the > ones we *promise* to deliver; but we do have a maintenance item in > there, and we can use that to build problem statements and even > solutions. > > In other words, I would look forward to a session slot in Dublin where > we can make progress on this. > But I don't want to hold up the charter now. > > Gruesse, Carsten > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan