From 6lowpan-bounces@ietf.org Tue May 01 11:35:20 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuNq-0003zY-Eh; Tue, 01 May 2007 11:35:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiuNm-0003v2-Vg for 6lowpan@lists.ietf.org; Tue, 01 May 2007 11:35:15 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HiuNm-0008Jp-LM for 6lowpan@lists.ietf.org; Tue, 01 May 2007 11:35:14 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 783482AC7C; Tue, 1 May 2007 15:34:44 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HiuNI-00080t-8h; Tue, 01 May 2007 11:34:44 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 01 May 2007 11:34:44 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 6lowpan mailing list <6lowpan@lists.ietf.org>, Internet Architecture Board , 6lowpan chair <6lowpan-chairs@tools.ietf.org>, RFC Editor Subject: [6lowpan] Protocol Action: 'Transmission of IPv6 Packets over IEEE 802.15.4 Networks' to Proposed Standard X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org The IESG has approved the following document: - 'Transmission of IPv6 Packets over IEEE 802.15.4 Networks ' as a Proposed Standard This document is the product of the IPv6 over Low power WPAN Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-format-13.txt Technical Summary 6LoWPAN is specification describing how to utilize IPv6 on top of low power, low data rate, low cost personal area networks. These networks today being built using IEEE 802.15.4 standard radios. These radios have an extremely limited frame size which makes it necessary to define an adaptation layer to support link layer fragmentation and reassembly. Additionally since these networks utilize low power transmission it is necessary for the adaptation layer to support network layer mesh capabilities. This specification defines the header format for this adaptation layer. Working Group Summary During the working group last call on the format document, several minor problems were recognized related to the layout of the fields in the adaptation header. At that time, David Culler and Jonathan Hui presented a new header encoding that provided for a overall smaller header and also "fixed" the earlier problems. This new encoding, rather than relying on a single monolithic header, utilizes multiple smaller "stacked" headers (similar to IPv6). Jonathan presented this new encoding at the November IETF. There was some concern about such a significant change at that late date, but it was agreed that the working group would take a concentrated look at the proposal and also the impact on code complexity and implementation. The Chairs set a 1 month deadline to get feedback from the group and especially those organizations that had already started implementing the previous version of 6LoWPAN. Very shortly after the IETF meeting an implementation for parsing the new header was sent to the list and over the next couple of weeks the feedback from the group was generally positive. During this time the document editors published a new revision and we started a new WGLC. This final WGLC proceeded without any substantial comments to the document. Document Quality There are at least 6 independent implementations of this protocol being worked on and all concerns raised during the review and WGLC have been addressed. Geoff Mulligan is the Document Shepherd. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 09 14:08:56 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlqar-0003cD-TN; Wed, 09 May 2007 14:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlqaq-0003c8-Jk for 6lowpan@ietf.org; Wed, 09 May 2007 14:08:52 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlqap-0006mi-DB for 6lowpan@ietf.org; Wed, 09 May 2007 14:08:52 -0400 Received: by wr-out-0506.google.com with SMTP id 71so298913wri for <6lowpan@ietf.org>; Wed, 09 May 2007 11:08:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=q6nTy+qkcwsd5Hz2/eTKlFGhh7VQ8BCmgmatSwqtAfbFFhrEUJ/f1DnNGQAC68TT2z7IH2TaajW0i9cXPmaiAPCVetFJpkfPWT5CPNTqwip07pPGwED9ebIdXOjdLrwumAFxbaVdgp37IIJqJCSCERBg7bUtTFWe6oRiHT6FTMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=MH1eywMWqlr5WGVC2xFG3Fh6gUTZPesqG8xYRNyokrWKSC6KE3mqVtH1HarnLl3RDezcqLFTjTmrg6lke4Y+BhEL4I/4gUouNkMurMjy5+Pjt8sy7AW+GIsubDgnvYhd/KUU5M+ZqgcoJJ/kzYj4eKN/nHORZjpTEiE5N5TlK5c= Received: by 10.78.204.1 with SMTP id b1mr224826hug.1178734130284; Wed, 09 May 2007 11:08:50 -0700 (PDT) Received: by 10.78.18.18 with HTTP; Wed, 9 May 2007 11:08:50 -0700 (PDT) Message-ID: <374005f30705091108g4a5aac86t463a80f8f43962a4@mail.gmail.com> Date: Wed, 9 May 2007 23:38:50 +0530 From: "Ian Chakeres" To: 6lowpan <6lowpan@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "Charles E. Perkins \(work\)" Subject: [6lowpan] 6lowpan devices contraints X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I've been having a side discussion about 6lowpan (sensor) devices and ran across a question I couldn't answer. In 6lowpan devices which is more precious energy for transmitting bits or memory? Put another way, given the choice between transmitting more bits & using less memory or transmitting fewer bits & using more memory - which is more appropriate for 6lowpan (sensor) devices? Ian Chakeres _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 09 21:34:21 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxXu-0004vG-BL; Wed, 09 May 2007 21:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlxXt-0004vA-5S for 6lowpan@ietf.org; Wed, 09 May 2007 21:34:17 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlxXr-00006A-V6 for 6lowpan@ietf.org; Wed, 09 May 2007 21:34:17 -0400 Received: by wr-out-0506.google.com with SMTP id 71so430236wri for <6lowpan@ietf.org>; Wed, 09 May 2007 18:34:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=O1kBuBgabJViIPJRC1OSPpxS6eGetgqY2MvcOLxlqYGYJRHed8r3n/UIRVsFAT3KMVc/bnbMJWrCPCZAfmKfctJ90iaGWj9cbD3G+BLoQYKLYDMSaG6wPThb+yAoBk3MwDvYt9AjVfKqGnl5GKa7eWUJw5oqzC10ggtjb6CD7/k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=E8dr5YWyreBxZUWuMEIISIPcfHlms1xTf4IU58VyDc/O35LQGXfJYQxUkoceakJupSuH/w+4c5u1Xkh08vFlCA4O2v0J4DB9zgFGmjjkLklkYb1yk067Fzvuf+c8GteQ01XIFovnhBM41S4GdJwtzZeZzKnckVbp4ATgbMnNn9w= Received: by 10.78.183.8 with SMTP id g8mr290167huf.1178760854951; Wed, 09 May 2007 18:34:14 -0700 (PDT) Received: by 10.78.18.18 with HTTP; Wed, 9 May 2007 18:34:14 -0700 (PDT) Message-ID: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> Date: Thu, 10 May 2007 07:04:14 +0530 From: "Ian Chakeres" To: 6lowpan <6lowpan@ietf.org>, rsn@itef.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Charles E. Perkins \(work\)" Subject: [6lowpan] Re: 6lowpan devices constraints X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Also, I'm adding RSN. It appears that my question might have been misinterpreted or more likely I presented the two choices inappropriately. Let me try pose the question in another way. How much short term memory can we expect these devices to have? And how much can we use for routing functions? Can a routing function make use of 100's or 1000's of bytes of short term memory? My understanding was that memory is scarce and very hard limited. Alternatively, energy though scarce does not have as hard a limit. Ian Chakeres _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 10 20:30:35 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJ1m-0006Zk-7b; Thu, 10 May 2007 20:30:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJ1l-0006Zf-Ko for 6lowpan@ietf.org; Thu, 10 May 2007 20:30:33 -0400 Received: from 66.237.74.130.ptr.us.xo.net ([66.237.74.130] helo=mail.dustnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmJ1j-0006cW-51 for 6lowpan@ietf.org; Thu, 10 May 2007 20:30:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [6lowpan] Re: 6lowpan devices constraints Date: Thu, 10 May 2007 17:30:29 -0700 Message-ID: <3D8BC6C339A9894C9955EF58D3722D65FBF143@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Re: 6lowpan devices constraints thread-index: AceSo1o3+KRseLv6ShG5dfBdC9horAAui6Ri References: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> From: "Kris Pister" To: "Ian Chakeres" , "6lowpan" <6lowpan@ietf.org>, X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: "Charles E. Perkins \(work\)" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Ian - motes today have between 2kB and 10kB of RAM typically, and 50kB = to 128kB of flash. Many have a separate flash with many hundreds of kB = (slower, more energy intensive to access). Cheap processors have come a = long way since the first motes in 2000/2001 where we had 8kB of flash = and 512B of RAM (but still did some pretty neat things, e.g. = http://robotics.eecs.berkeley.edu/~pister/29Palms0103). People are spoiled now, and it's only going to get worse. I mean = better. Several companies have demonstrateded and/or announced motes with 32 bit = processors and ten times more RAM and flash. These 32 bit cores often = burn less power per MHz than the cheesy 8 bit processors with which they = compete. You can assume that others will follow suit. In 0.18um CMOS, = you get about 10kB of SRAM per square millimeter, and 100kB of flash per = square millimeter. 32 bit cores are around a half a square millimeter. = 8 bit cores are only about half that size. Radios and all of the analog = peripherals are very very roughly 5mm2. In volume, tested functional = chips cost very very roughly $0.10/mm2 . So today a 32bit core and = 100kB of flash and 10kB of RAM is comparable in size to the = radio+peripherals. Radios and most of the peripherals don't scale much = as you go to 0.13um or 90nm, but the digital does, so in a few years the = cost of the core(s) and memory will have shrunk by 2..,4..,8..X, or more = likely the relative die area will be about the same, but you'll just = have a lot more memory. =20 Transmitted packets cost you a few milliseconds at roughly 20mA today, = or roughly 100uC (microCoulombs). The trick is receiving the packet - = how do you know when it's coming? There are several approaches: * If you're time-synchronized, then the receiver can turn on for a = couple of milliseconds and cost you maybe 50 uC if there's no packet, = and 100uC if there is one. If you do this once a second, that's 50uA to = get 1/2 second average latency when idle, or 100uA to receive one packet = per second. That's TSMP (time synchronized mesh protocol). * If you don't want to time synchronize, you can do preamble sampling. = You still turn your receiver on regularly, and listen to hear if anyone = is transmitting a long preamble. If they are, you stay awake until the = packet shows up. This is LPL (low power listening) if you're a tinyOS = person. You burn less charge on the listens - maybe only 20uC if = there's nothing to hear - but you probably want to do them more often. = If you sample once per second, then maybe you only burn 20uA to get the = same 1/2 second latency, but...now the transmitter of a packet has to = send a 1 second long preamble before each packet so that you stay awake, = meaning a TX now costs 20,000uC, not 100uC. The receiver on average is = going to have to listen to half of the preamble, which is going to cost = 10,000uC if you only sample once a second. So you probably sample a lot = more often, and burn a lot more power on idle listening. Not very = efficient, but hey, at least it's easy. * If you're lucky enough to have a powered infrastructure, then use = WiFi. Hmm. Try again: if you're lucky enough to have a powered = infrastructure, and for some reason are still interested in using = 802.15.4, then transmit whenever you want, and listen immediately after = your transmitions to see if the local powered router has anything to say = to you in return. =20 ksjp -- Prof. EECS, UC Berkeley Founder & CTO, Dust Networks ________________________________ From: Ian Chakeres [mailto:ian.chakeres@gmail.com] Sent: Wed 5/9/2007 6:34 PM To: 6lowpan; rsn@itef.org Cc: Charles E. Perkins (work) Subject: [6lowpan] Re: 6lowpan devices constraints Also, I'm adding RSN. It appears that my question might have been misinterpreted or more likely I presented the two choices inappropriately. Let me try pose the question in another way. How much short term memory can we expect these devices to have? And how much can we use for routing functions? Can a routing function make use of 100's or 1000's of bytes of short term memory? My understanding was that memory is scarce and very hard limited. Alternatively, energy though scarce does not have as hard a limit. Ian Chakeres _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 11 02:48:53 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOvs-0008Mc-4y; Fri, 11 May 2007 02:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmOvr-0008MX-95 for 6lowpan@ietf.org; Fri, 11 May 2007 02:48:51 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmOvq-0001vo-Uk for 6lowpan@ietf.org; Fri, 11 May 2007 02:48:51 -0400 Received: by an-out-0708.google.com with SMTP id c34so244598anc for <6lowpan@ietf.org>; Thu, 10 May 2007 23:48:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=tIeSi8EgolCpoWLZ3QqDwvRwQH4b/By36/nevAWL8q27dFIbB9tnF1JdmFTCkUGg3nuFoMS8WfmU2ArDBYn5d0k/errQQZ/+1fdrlVKAqeMm0QhKoiY6Luq+LEZMNmlqshXRTHNZPGEA9IKfm6jhSPW8RGf9yiiLjYyLy25SVIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=h8QD3zX+QV0Y/qg2w4k6roUaKKnp8ydeB2qkqUq3Yv5MF87+G0cMYyYvaNEb2e6GPqpAcBMF0srfqB7z23GdiX70h3dTqOo1IoM0f0nChUvnYGdxJVW7Qx+BxgYZQyFyRLrjcPMFO7s2CWfnSU9saCUazP3Whf5cs4VJzvehn7U= Received: by 10.100.199.12 with SMTP id w12mr1954165anf.1178866130422; Thu, 10 May 2007 23:48:50 -0700 (PDT) Received: by 10.100.11.14 with HTTP; Thu, 10 May 2007 23:48:50 -0700 (PDT) Message-ID: <1edd46e70705102348w9a88460na60bfa860910e71f@mail.gmail.com> Date: Thu, 10 May 2007 23:48:50 -0700 From: "Joe Polastre" To: "Kris Pister" Subject: Re: [6lowpan] Re: 6lowpan devices constraints In-Reply-To: <3D8BC6C339A9894C9955EF58D3722D65FBF143@dust-exch-02.dusthq.dust-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> <3D8BC6C339A9894C9955EF58D3722D65FBF143@dust-exch-02.dusthq.dust-inc.com> X-Google-Sender-Auth: 7b07f310a112e5a5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "Charles E. Perkins \(work\)" , rsn@itef.org, 6lowpan <6lowpan@ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > * If you're time-synchronized, then the receiver can turn on for a couple of milliseconds and cost you maybe 50 uC if there's no packet, and 100uC if there is one. If you do this once a second, that's 50uA to get 1/2 second average latency when idle, or 100uA to receive one packet per second. That's TSMP (time synchronized mesh protocol). > * If you don't want to time synchronize, you can do preamble sampling. You still turn your receiver on regularly, and listen to hear if anyone is transmitting a long preamble. If they are, you stay awake until the packet shows up. This is LPL (low power listening) if you're a tinyOS person. You burn less charge on the listens - maybe only 20uC if there's nothing to hear - but you probably want to do them more often. If you sample once per second, then maybe you only burn 20uA to get the same 1/2 second latency, but...now the transmitter of a packet has to send a 1 second long preamble before each packet so that you stay awake, meaning a TX now costs 20,000uC, not 100uC. The receiver on average is going to have to listen to half of the preamble, which is going to cost 10,000uC if you only sample once a second. So you probably sample a lot more often, and burn a lot more power on idle listening. Not very efficient, but hey, at least it's easy. This is a very naive approach, and Kris, we've talked about this. Many protocols can detect when others are sampling the channel (I believe you call this "time synchronization", although really it can be done with LPL) and detect when to receive a packet based will be received on this information. If you can setup a purely peer-to-peer network (please take out that horrible server) and give us an ability to interact with ANY sensor network at any point, a ton of our customers would love to see that functionality. Time synchronization is not the answer, NOR is low power listening. Both are TOOLS, which is what many people forget. We need these tools to enable a networking system that CUSTOMERS (yes, I said it), customers are looking to use. Most of our customers couldn't care less whether a TSMP (WTF is that?) or an LPL (WTF did you say?) is used, they care about how to get alerts to their personnel (an application). This is what we should be focused on, not whose random networking junk is better than the other random startup's networking junk. -Joe, > * If you're lucky enough to have a powered infrastructure, then use WiFi. Hmm. Try again: if you're lucky enough to have a powered infrastructure, and for some reason are still interested in using 802.15.4, then transmit whenever you want, and listen immediately after your transmitions to see if the local powered router has anything to say to you in return. > > ksjp > -- > Prof. EECS, UC Berkeley > Founder & CTO, Dust Networks > > ________________________________ > > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Sent: Wed 5/9/2007 6:34 PM > To: 6lowpan; rsn@itef.org > Cc: Charles E. Perkins (work) > Subject: [6lowpan] Re: 6lowpan devices constraints > > > > Also, I'm adding RSN. > > It appears that my question might have been misinterpreted or more > likely I presented the two choices inappropriately. Let me try pose > the question in another way. > > How much short term memory can we expect these devices to have? And > how much can we use for routing functions? Can a routing function make > use of 100's or 1000's of bytes of short term memory? > > My understanding was that memory is scarce and very hard limited. > Alternatively, energy though scarce does not have as hard a limit. > > Ian Chakeres > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri May 11 11:24:00 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWyN-0003mP-CJ; Fri, 11 May 2007 11:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmWyM-0003mK-Aj for 6lowpan@ietf.org; Fri, 11 May 2007 11:23:58 -0400 Received: from 66.237.74.130.ptr.us.xo.net ([66.237.74.130] helo=mail.dustnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmWyL-0004qF-T0 for 6lowpan@ietf.org; Fri, 11 May 2007 11:23:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [6lowpan] Re: 6lowpan devices constraints Date: Fri, 11 May 2007 08:23:56 -0700 Message-ID: <3D8BC6C339A9894C9955EF58D3722D65912542@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Re: 6lowpan devices constraints thread-index: AceTmG87xUIHVPSOR9Gx/GjBFz3FCgARcxsg From: "Kris Pister" To: "Joe Polastre" , "6lowpan" <6lowpan@ietf.org>, X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: "Charles E. Perkins \(work\)" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Joe - sorry, I meant to be informative, not antagonistic. I know that some very nice work on time synchronized channel polling (SCP) has been done by Ye et al. at USC/ISI. It sounds like we are in agreement that there are a number of MAC-layer "tools", including TSMP, SCP, and LPL. Since these protocols have wildly different performance characteristics, I think that it's important for RSN and 6lowPAN to have at least a high level abstraction of how they work and what the performance tradeoffs are. I think that my numbers for TSMP and LPL are correct. Maybe you could give us some numbers and insight for synchronized LPL (either SCP or something similar)? ksjp -----Original Message----- From: joe.polastre@gmail.com [mailto:joe.polastre@gmail.com] On Behalf Of Joe Polastre Sent: Thursday, May 10, 2007 11:49 PM To: Kris Pister Cc: Ian Chakeres; 6lowpan; rsn@itef.org; Charles E. Perkins (work) Subject: Re: [6lowpan] Re: 6lowpan devices constraints > * If you're time-synchronized, then the receiver can turn on for a couple of milliseconds and cost you maybe 50 uC if there's no packet, and 100uC if there is one. If you do this once a second, that's 50uA to get 1/2 second average latency when idle, or 100uA to receive one packet per second. That's TSMP (time synchronized mesh protocol). > * If you don't want to time synchronize, you can do preamble sampling. You still turn your receiver on regularly, and listen to hear if anyone is transmitting a long preamble. If they are, you stay awake until the packet shows up. This is LPL (low power listening) if you're a tinyOS person. You burn less charge on the listens - maybe only 20uC if there's nothing to hear - but you probably want to do them more often. If you sample once per second, then maybe you only burn 20uA to get the same 1/2 second latency, but...now the transmitter of a packet has to send a 1 second long preamble before each packet so that you stay awake, meaning a TX now costs 20,000uC, not 100uC. The receiver on average is going to have to listen to half of the preamble, which is going to cost 10,000uC if you only sample once a second. So you probably sample a lot more often, and burn a lot more power on idle listening. Not very efficient, but hey, at least it's easy. This is a very naive approach, and Kris, we've talked about this. Many protocols can detect when others are sampling the channel (I believe you call this "time synchronization", although really it can be done with LPL) and detect when to receive a packet based will be received on this information. If you can setup a purely peer-to-peer network (please take out that horrible server) and give us an ability to interact with ANY sensor network at any point, a ton of our customers would love to see that functionality. Time synchronization is not the answer, NOR is low power listening. Both are TOOLS, which is what many people forget. We need these tools to enable a networking system that CUSTOMERS (yes, I said it), customers are looking to use. Most of our customers couldn't care less whether a TSMP (WTF is that?) or an LPL (WTF did you say?) is used, they care about how to get alerts to their personnel (an application). This is what we should be focused on, not whose random networking junk is better than the other random startup's networking junk. -Joe, > * If you're lucky enough to have a powered infrastructure, then use WiFi. Hmm. Try again: if you're lucky enough to have a powered infrastructure, and for some reason are still interested in using 802.15.4, then transmit whenever you want, and listen immediately after your transmitions to see if the local powered router has anything to say to you in return. > > ksjp > -- > Prof. EECS, UC Berkeley > Founder & CTO, Dust Networks > > ________________________________ > > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Sent: Wed 5/9/2007 6:34 PM > To: 6lowpan; rsn@itef.org > Cc: Charles E. Perkins (work) > Subject: [6lowpan] Re: 6lowpan devices constraints > > > > Also, I'm adding RSN. > > It appears that my question might have been misinterpreted or more > likely I presented the two choices inappropriately. Let me try pose > the question in another way. > > How much short term memory can we expect these devices to have? And > how much can we use for routing functions? Can a routing function make > use of 100's or 1000's of bytes of short term memory? > > My understanding was that memory is scarce and very hard limited. > Alternatively, energy though scarce does not have as hard a limit. > > Ian Chakeres > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat May 12 23:33:36 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hn4ps-00016x-VE; Sat, 12 May 2007 23:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hn4ps-00016k-9e for 6lowpan@ietf.org; Sat, 12 May 2007 23:33:28 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hn4pr-0005ul-17 for 6lowpan@ietf.org; Sat, 12 May 2007 23:33:28 -0400 Received: by ug-out-1314.google.com with SMTP id 72so847355ugd for <6lowpan@ietf.org>; Sat, 12 May 2007 20:33:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=qx8eExcp4VCRFUS0kmwZlfLO2Wi6Bv5Pv/Rrxv8zi73cRBSbjA9ccbw8tqEvW9vge+WkzWRsk96zSaSva1GjF8y+/WodCksB9101mK/XlJwytdMcfaUmHoNABBHmkpmzkyRcuDKDU2SssLRi/tJp/kjL3ZBH7Dd77Swjr48xTnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NvH7xrU64FVmcv3gRecbFdZuTbqUdCIkSf/6QzYy+wt8TEA7ZO5g3qz8IbD1gKg7Gu53FAzAFndxHAprZ/diWnWL6ivAOA2IxBg3bzfP7T8b2GlGP6aNv6eLChzKnGzc0/ssBnGPdOkOH3cXBM9aWCN3wKGoSLE9HpsNzyCQWK0= Received: by 10.78.83.15 with SMTP id g15mr1662216hub.1179027206276; Sat, 12 May 2007 20:33:26 -0700 (PDT) Received: by 10.78.33.14 with HTTP; Sat, 12 May 2007 20:33:26 -0700 (PDT) Message-ID: <374005f30705122033n7989a1eap32346178cbdfef3b@mail.gmail.com> Date: Sun, 13 May 2007 09:03:26 +0530 From: "Ian Chakeres" To: rsn@ietf.org In-Reply-To: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 6lowpan <6lowpan@ietf.org> Subject: [6lowpan] 6lowpan devices constraints X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org adding RSN to the conversation It appears that my question might have been misinterpreted or more likely I presented the two choices inappropriately. Let me try pose the question in another way. How much short term memory can we expect these devices to have? And how much can we use for routing functions? Can a routing function make use of 100's or 1000's of bytes of short term memory? My understanding was that memory is scarce and very hard limited. Alternatively, energy though scarce does not have as hard a limit. Ian Chakeres _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun May 13 00:32:12 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hn5kh-0004uu-HE; Sun, 13 May 2007 00:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hn5kg-0004uc-9r; Sun, 13 May 2007 00:32:10 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hn5ke-0005bD-Sy; Sun, 13 May 2007 00:32:10 -0400 Received: from [127.0.0.1] (mpls.saloits.com [216.243.132.62]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l4D4Vsdc036929; Sat, 12 May 2007 23:32:06 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <464694B2.9060201@saloits.com> Date: Sat, 12 May 2007 23:31:46 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Subject: Re: [6lowpan] 6lowpan devices constraints References: <374005f30705091834o49417256m944eab1bdbbc1371@mail.gmail.com> <374005f30705122033n7989a1eap32346178cbdfef3b@mail.gmail.com> In-Reply-To: <374005f30705122033n7989a1eap32346178cbdfef3b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Ian Chakeres wrote: > How much short term memory can we expect these devices to have? And > how much can we use for routing functions? Can a routing function make > use of 100's or 1000's of bytes of short term memory? I believe that in some markets (e.g., home automation) vendors will try to include the absolute minimum amount of memory in large-volume, cost-sensitive (consumer-grade) products. A few cents-per-device cost reduction times a few tens-of-millions of units starts to add up to (sort of) real money. On the other hand, I suspect that there will also be classes of devices sold into these very cost-competitive markets that are slightly less cost sensitive. For example, vendors might be convinced to put a bit more memory in the wired/wireless gateways (are we allowed to say that word?) if we can give them a good reason to. Another strategy is to assume that the lowest-end devices will have enough memory to support the ZigBee protocol stack, and so we should ensure that we work with these devices. After we achieve that objective, we can use any leftover (RAM) memory for buffers. > My understanding was that memory is scarce and very hard limited. > Alternatively, energy though scarce does not have as hard a limit. I think that there will be two classes of devices in most of these networks: battery-powered and mains-powered. For a battery-powered device, energy consumption translates directly into product lifetime (for some devices) or at least into mean-time-to-battery-replacement. For mains-powered devices (e.g., wired/wireless gateways or home automation controllers) energy will be essentially unlimited. I believe that routing protocols that can more effectively accommodate both energy-constrained devices and and energy-rich devices will better meet the needs of these markets than will routing protocols that don't differentiate between these classes of devices. If nobody else beats me to it, I will go look up the characteristics of some of the current 802.14.4/ZigBee SOC products. -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue May 22 22:36:50 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqgiV-0006bq-R5; Tue, 22 May 2007 22:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqgiS-0006bS-E6; Tue, 22 May 2007 22:36:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqgiQ-0000uh-Qk; Tue, 22 May 2007 22:36:44 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 May 2007 04:36:43 +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 l4N2agsK027782; Wed, 23 May 2007 04:36:42 +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.12.10/8.12.6) with ESMTP id l4N2agDR017577; Wed, 23 May 2007 02:36:42 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, 23 May 2007 04:36:41 +0200 Received: from [10.43.1.84] ([10.58.48.2]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 04:36:39 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) To: 6lowpan@ietf.org, manet@ietf.org Message-Id: References: From: JP Vasseur Date: Wed, 23 May 2007 04:36:29 +0200 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 May 2007 02:36:39.0721 (UTC) FILETIME=[31041990:01C79CE3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21164; t=1179887802; x=1180751802; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20Next=20step=20for=20RSN=20? |Sender:=20; bh=nszXfkFYBn+gYSCcipPEMd4OOeaEbgDmphSRiJzgT/8=; b=mhSbiuH+8ugURn4Y4+AOlq8nbh8fNHwfrp2ZGJfvXyxxo3nhV/Z12ZBRc24df9pZ1+eLsaaC fmRpiBHGqm8q/uwV0JcoC1ittF9k4uApEfsnJdIlFXIvhar9XwJZuwqD; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: Subject: [6lowpan] Fwd: Next step for RSN ? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============1130583519==" Errors-To: 6lowpan-bounces@ietf.org --===============1130583519== Content-Type: multipart/alternative; boundary=Apple-Mail-166--282872936 --Apple-Mail-166--282872936 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI - Feel free to register to RSN and provide feed-back if of interest. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: May 23, 2007 4:33:31 AM GMT+02:00 > To: rsn@ietf.org > Cc: David Culler > Subject: Next step for RSN ? > > Dear List members, > > Looking at the number of people who registered to this list, there > seems to be a strong interest in designing a Routing solution for > Sensor Networks. David and I had during the last few months a > number of off-line discussions with positive feed-back and support, > it is now a good time to use the Mailing List to gauge whether > there is a consensus on whether to work on this topic. > > David provided an excellent problem statement below. I'd like to > add a few comments and get feed-back from the ML members on whether > we collectively want to work on this item. > > With no doubt, we'll see many other radio networks emerging soon > and sensor networks will soon be made links using various layer1/2 > protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non > wireless links. Such networks will also comprise sensor nodes with > a wide range of capabilities, which makes the routing fairly unique > in term of requirement. Thus the proposal is to design a IP routing > solution specifically for sensor networks, that would of course be > independent to the L1/L2 protocol in use (it may be desirable to > take into account link layer attributes when calculating a route > but the routing process would not be tied up with the link layer). > > It looks fairly obvious that a network made of N "mesh-under" > routing protocols is very unlikely to satisfy an end to end path > constraint and would be fairly complex to manage and tune. We all > remember the issue of IP routing over ATM PVCs routed by PNNI. > Think of this with N "Mesh-under" routing protocols. That said, > this is not to say that we exclude the use of "mesh-under" > solutions, but we propose to define a IP-based routing protocol. > > What would be a charter proposal ? > > First we would need to spend a good amount of time on the routing > requirements. David and I posted a first revision of a generic > requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next > revision will soon be posted accounting for the comments received > so far. I would propose to continue to list the generic > requirements in this draft and have other application-specific > routing requirements drafts discussed in other IDs: for home > networking, industrial applications, ... Such approach has been > successfully adopted in other WGs. > > The second step would consist of making a survey on the existing > routing protocols and see whether (1) they could be used as such > (2) they should be adapted (for instance, see whether AODV or OLR > or RIP could be made energy efficient, could support some form of > constrained based routing, ...) or (3) we should design a new > generic new protocol. > > Note that we may not be able to satisfy all the requirements, and > this might be perfectly acceptable and should be documented. > Indeed, we all know that Sensor Networks may significantly differ > in term of degree of mobility, link layer reliability/bandwidth, > node constraints, ... A very good outcome of this work might be > that the newly defined/adapted protocol could satisfy the > requirement IDs A, B, D and E but not C. > > So please use this list to provide feed-back on whether you would > support such initiative and if so your contribution is more than > welcome. Note that several people already mentioned some interest > and we do expect to see new IDs posted before Chicago. > > JP and David. > > Begin forwarded message: > >> From: "dculler" >> Date: May 23, 2007 1:24:58 AM GMT+02:00 >> To: >> Subject: [RSN] Interest in the Interplay of "routing" and "meshing" >> Reply-To: dculler@archrock.com >> >> Several of the comments on this list have touched on the issue of >> different kinds of "multihop routing" in the context of sensor >> networks. Is there interest in working on how these forms of >> routing tie together? >> >> To make the question more grounded: Low power radios have >> relatively short range. IEEE 802.15.4 radios are typically 1 mW >> transmit power, vs 100 mW for 802.11, and have typical ranges in >> 10s to 100 m. Generally speaking, the power required to >> communicate a given distance by radio grows polynomially with >> distance. In typical settings it grows like the cube, but it can >> be much worse near the ground or somewhat better with directional >> antennas. The cost to communicate hop-by-hop grows only linearly, >> and it offers the potential to route around obstacles and enhance >> reliability through "receiver diversity". >> >> The question is at what layer(s) in the stack this routing occurs >> and how it relates to IP routing more generally. Most multihop >> protocols in the sensor network research community are effectively >> at layer2 - they form a single "patch" of homogeneous media. >> Logically, they are a subnet, although few of the protocols >> address what happens beyond the "patch" of sensor nodes, other >> than that some of the nodes are "gateways". Current industry >> standards, such as Zigbee, Zwave, and wirelessHART, are also a >> "multihop link", leaving open the question of how nodes within the >> sensor patch communicate with nodes outside. >> >> 6LoWPAN provides a compressed header format for "mesh routing", >> meaning multihop forwarding of packets within the 802.15.4 link. >> Such a link is assumed to be formed by a contiguously connected >> set of 802.15.4 nodes. The presence of such "mesh routing" >> capabilities does not eliminate the need for layer 3 routing. If >> a 15.4 node communicates with a remote node, say an 802.11 node, >> how is routing and forwarding carried out? If two "LoWPAN >> subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4- >> to-15.4 routing occur? The 6LoWPAN header format is, of course, a >> general solution for carrying IP over 802.15.4, so it is able to >> express these other forms of routing, as well. In the extreme >> case, each individual node is an IP link and all routing is done >> at the IP layer. On the other hand, patches of nodes may want to >> function as a logical subnet, even if the wireless multihop >> routing is done at the IP layer. At this point, the concerns >> overlap with those addressed in autoconf (cf., draft-ietf-autoconf- >> manetarch-01). >> >> There is substantial commonality of concerns at the different >> layers of multihop routing, but also differences. It is also >> important to separate the process of forming a routing topology >> from the process of forwarding packets. Both of which are >> distinct (but not entirely independent of) how power management >> (turning on/off the radios) is performed. >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn > --Apple-Mail-166--282872936 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI - Feel free to register to = RSN and provide feed-back if of interest.

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = May 23, 2007 4:33:31 AM GMT+02:00
Cc: David = Culler <dculler@archrock.com>
Subject: Next step for RSN = ?

= Dear List members,

Looking at the number of = people who registered to this list, there seems to be a strong interest = in designing a Routing solution for Sensor Networks. David and I had = during the last few months a number of off-line discussions with = positive feed-back and support, it is now a good time to use the Mailing = List to gauge whether there is a consensus on whether to work on this = topic.

David = provided an excellent problem statement below. I'd like to add a few = comments and get feed-back from the ML members on whether we = collectively want to work on this item.

With no doubt, we'll see many other radio = networks emerging soon and sensor networks will soon be made links using = various layer1/2 protocols defined by other SDOs: 802.15.4, Wifi, WiMax = but also non wireless links. Such networks will also comprise = sensor nodes with a wide range of capabilities, which makes the = routing fairly unique in term of requirement. Thus the proposal is = to design a IP routing solution specifically for sensor networks, that = would of course be independent to the L1/L2 protocol in use (it may be = desirable to take into account link layer attributes when calculating a = route but the routing process would not be tied up with the link = layer).=A0

It looks fairly obvious that a network made = of N "mesh-under" routing protocols is very unlikely to satisfy an end = to end path constraint and would be fairly complex to manage and tune. = We all remember the issue of IP routing over ATM PVCs routed by PNNI. = Think of this with N "Mesh-under" routing protocols. That said, this is = not to say that we exclude the use of "mesh-under" solutions, but we = propose to define a IP-based routing protocol.=A0

What would be a = charter proposal ?

First we would need to = spend a good amount of time on the routing requirements. David and I = posted a first revision of a generic requirement draft = (draft-culler-rsn-routing-reqs-00.txt); the next revision will soon be = posted accounting for the comments received so far. I would propose to = continue to list the generic requirements in this draft and have other = application-specific routing requirements drafts discussed in other IDs: = for home networking, industrial applications, ... Such approach has been = successfully adopted in other WGs.

The second step would = consist of making a survey on the existing routing protocols and see = whether (1) they could be used as such (2) they should be adapted (for = instance, see whether AODV or OLR or RIP could be made energy efficient, = could support some form of constrained based routing, ...) or (3) we = should design a new generic new protocol.=A0

Note that we may not be = able to satisfy all the requirements, and this might be perfectly = acceptable and should be documented. Indeed, we all know that Sensor = Networks may significantly differ in term of degree of mobility, link = layer reliability/bandwidth, node constraints, ... A very good outcome = of this work might be that the newly defined/adapted protocol could = satisfy the requirement IDs A, B, D and E but not C.=A0

So please use this list to = provide feed-back on whether you would support such initiative and if so = your contribution is more than welcome. Note that several people already = mentioned some interest and we do expect to see new IDs posted before = Chicago.

JP and = David.

Begin forwarded message:

From: = "dculler" <dculler@archrock.com>
Date: May 23, 2007 1:24:58 AM = GMT+02:00
Subject: = [RSN] Interest in the Interplay of "routing" and = "meshing"
=

Several of = the comments on this list have touched on the=A0issue of different kinds = of "multihop routing" in the context of sensor networks.=A0 Is there = interest in working on how these=A0forms of routing=A0tie = together?
=A0
To make the = question more grounded:=A0 Low power radios have relatively short = range.=A0 IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 = mW for 802.11, and have typical ranges in 10s to 100 m.=A0 Generally = speaking, the power required to communicate a given distance by radio = grows polynomially with distance.=A0 In typical settings it grows like = the cube, but it can be much worse near the ground or somewhat better = with directional antennas.=A0=A0The cost to communicate=A0hop-by-hop = grows only linearly, and it offers the potential to route around = obstacles and enhance reliability through "receiver diversity".=A0 =
=A0
The = question is at what layer(s) in the stack this routing occurs and how it = relates to IP routing more generally.=A0 Most multihop protocols in the = sensor network research community are effectively at layer2 - they form = a single "patch" of homogeneous media.=A0 Logically, they are a subnet, = although few of the protocols address what happens beyond the "patch" of = sensor nodes, other than that some of the nodes are "gateways".=A0 = Current industry standards,=A0such as=A0Zigbee, Zwave, and wirelessHART, = are also a "multihop link", leaving open the question of how nodes = within the sensor patch communicate with nodes = outside.
=A0
6LoWPAN = provides a compressed header format for "mesh routing", meaning multihop = forwarding of packets within the 802.15.4 link.=A0 Such a link is = assumed to be formed by a contiguously connected set of 802.15.4 nodes.=A0= The presence of such "mesh routing" capabilities does not eliminate the = need for layer 3 routing.=A0 If a 15.4 node communicates with a remote = node, say an 802.11 node, how is routing and forwarding carried out?=A0 = If two "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how = does 15.4-to-15.4 routing occur?=A0 The 6LoWPAN header format is, of = course, a general solution for carrying IP over 802.15.4, so it is able = to express these other forms of routing, as well.=A0 In the extreme = case, each individual node is an IP link and all routing is done at the = IP layer.=A0 On the other hand, patches of nodes may want to function as = a logical subnet, even if the wireless multihop routing is done at the = IP layer.=A0 At this point, the concerns overlap with those addressed in = autoconf (cf., draft-ietf-autoconf-manetarch-01).
=
=A0
There is = substantial commonality of concerns at the different layers of multihop = routing, but also differences.=A0 It is also important to separate the = process of forming a routing topology from the process of forwarding = packets.=A0 Both of which are distinct (but not entirely independent of) = how power management (turning on/off the radios) is = performed.
=A0
=A0
RSN mailing list
=


= --Apple-Mail-166--282872936-- --===============1130583519== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1130583519==-- From 6lowpan-bounces@ietf.org Wed May 23 10:36:03 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqrwY-0002Ii-N2; Wed, 23 May 2007 10:36:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqrwX-0002DP-VK for 6lowpan@ietf.org; Wed, 23 May 2007 10:36:01 -0400 Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqrwX-0004OX-GQ for 6lowpan@ietf.org; Wed, 23 May 2007 10:36:01 -0400 Received: from smtpscan-eur6.philips.com (smtpscan-eur6.mail.philips.com [130.144.57.169]) by gw-eur4.philips.com (Postfix) with ESMTP id C33444974C for <6lowpan@ietf.org>; Wed, 23 May 2007 14:35:56 +0000 (UTC) Received: from smtpscan-eur6.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id E58869B9 for <6lowpan@ietf.org>; Wed, 23 May 2007 14:35:55 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur6.philips.com (Postfix) with ESMTP id 0AB789B6 for <6lowpan@ietf.org>; Wed, 23 May 2007 14:35:54 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id AF7E7A5 for <6lowpan@ietf.org>; Wed, 23 May 2007 14:35:44 +0000 (GMT) In-Reply-To: <464694B2.9060201@saloits.com> To: 6lowpan <6lowpan@ietf.org> MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Anthony Schoofs Date: Wed, 23 May 2007 16:31:02 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.5HF1002 | November 23, 2006) at 23/05/2007 16:37:46, Serialize complete at 23/05/2007 16:37:46 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============0332481383==" Errors-To: 6lowpan-bounces@ietf.org This is a multipart message in MIME format. --===============0332481383== Content-Type: multipart/alternative; boundary="=_alternative 004F8A20C12572E4_=" This is a multipart message in MIME format. --=_alternative 004F8A20C12572E4_= Content-Type: text/plain; charset="US-ASCII" Dear all, In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Internet Draft, section Dispatch type and Header page 7, is mentionned that ".. other non-LowPAN protocols that wish to coexist with LowPAN nodes should include a byte matching this pattern (00 xxxxxx) ..". I had a look at the ZigBee network header and especially at the Frame Type sub-field (the 3 first bits after the 802.15.4 MAC header). For acknowledgement and command frames, the Frame Type value is either 010 or 011 (data frames start with 00). Consequently, it might happen that you get a match with a LoWPAN pattern, and then a problem of coexistence between LowPAN nodes and ZigBee nodes. I would like to know if this coexistence issue was raised before and if it is a matter for the 6LoWPAN WG. Best regards, Anthony -- Anthony Schoofs Philips Research High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Email: anthony.schoofs@philips.com --=_alternative 004F8A20C12572E4_= Content-Type: text/html; charset="US-ASCII"
Dear all,

In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Internet Draft, section Dispatch type and Header page 7, is mentionned that  ".. other non-LowPAN protocols that wish to coexist with LowPAN nodes should include a byte matching this pattern (00 xxxxxx) ..".

I had a look at the ZigBee network header and especially at the Frame Type sub-field (the 3 first bits after the 802.15.4 MAC header).
For acknowledgement and command frames, the Frame Type value is either 010 or 011 (data frames start with 00).

Consequently, it might happen that you get a match with a LoWPAN pattern, and then a problem of coexistence between LowPAN nodes and ZigBee nodes.

I would like to know if this coexistence issue was raised before and if it is a matter for the 6LoWPAN WG.

Best regards,
Anthony

--
Anthony Schoofs
Philips Research
High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands
Email: anthony.schoofs@philips.com

--=_alternative 004F8A20C12572E4_=-- --===============0332481383== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============0332481383==-- From 6lowpan-bounces@ietf.org Wed May 23 14:52:59 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqvxD-0007TN-02; Wed, 23 May 2007 14:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqvxA-0007Sd-Kf for 6lowpan@ietf.org; Wed, 23 May 2007 14:52:56 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqvxA-0008Mj-AE for 6lowpan@ietf.org; Wed, 23 May 2007 14:52:56 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id DED5382A40 for <6lowpan@ietf.org>; Wed, 23 May 2007 20:52:55 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08477-05; Wed, 23 May 2007 20:52:53 +0200 (CEST) Received: from bike-planet (p5489f17a.dip.t-dialin.net [84.137.241.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id E5DC98284E; Wed, 23 May 2007 20:52:52 +0200 (CEST) Received: by bike-planet (Postfix, from userid 1000) id 0FB00327F5; Wed, 23 May 2007 20:52:52 +0200 (CEST) Date: Wed, 23 May 2007 20:52:51 +0200 From: Matus Harvan To: 6lowpan@ietf.org Message-ID: <20070523185251.GA16770@bike-planet.students.iu-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [6lowpan] 6lowpan implementation for TinyOS 2.0 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hello, I have implemented a 6lowpan/IPv6 stack for TinyOS 2.0. The implementation parses Mesh Addressing and Broadcast headers. 6lowpan fragmentation and fragment reassembly are fully supported. The 6lowpan-specified HC1 compression of the IPv6 header and the HC_UDP compression of the UDP header are supported as well as handling of the uncompressed headers. The implementation can respond to ICMP echo requests and handles communication over the UDP protocol. It has been tested on the TelosB and MicaZ motes. In addition a 6lowpan-translating daemon has been implemented to allow a linux PC to use a mote as an 802.15.4 interface. Shortcomings and missing features: * 6lowpan payload is sent as Active Message payload. This means that the 802.15.4 payload is prefixed with the 1-byte AM Type field. * non-zero Traffic Class and Flow Label are not supported by the current HC1 implementation * UDP port numbers compression is not supported and port numbers are always sent in full by the current HC_UDP implementation * Neighbor Discovery has not been implemented and link local broadcasts are used instead. * Not all fragments of a datagram seem to be always received by the mote. A workaround is to add a usleep(10000) before sending subsequent fragments in the daemon on the PC. More details can be found in my MSc Thesis http://www.eecs.iu-bremen.de/users/harvan/docs/msc-thesis.pdf Source code is available from http://www.eecs.iu-bremen.de/users/harvan/files/6lowpan.tar.gz Best regards, Matus _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 23 15:08:55 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqwCc-0001ia-Rr; Wed, 23 May 2007 15:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqwCb-0001iU-9V for 6lowpan@ietf.org; Wed, 23 May 2007 15:08:53 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqwCZ-0007Ak-TZ for 6lowpan@ietf.org; Wed, 23 May 2007 15:08:53 -0400 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HqwCW-0003sL-Ui; Wed, 23 May 2007 12:08:49 -0700 Message-ID: <4654971D.400@cs.stanford.edu> Date: Wed, 23 May 2007 12:33:49 -0700 From: Philip Levis User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Matus Harvan Subject: Re: [6lowpan] 6lowpan implementation for TinyOS 2.0 References: <20070523185251.GA16770@bike-planet.students.iu-bremen.de> In-Reply-To: <20070523185251.GA16770@bike-planet.students.iu-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Matus Harvan wrote: > Hello, > > I have implemented a 6lowpan/IPv6 stack for TinyOS 2.0. > > The implementation parses Mesh Addressing and Broadcast > headers. 6lowpan fragmentation and fragment reassembly are fully > supported. The 6lowpan-specified HC1 compression of the IPv6 header > and the HC_UDP compression of the UDP header are supported as well as > handling of the uncompressed headers. The implementation can respond > to ICMP echo requests and handles communication over the UDP > protocol. It has been tested on the TelosB and MicaZ motes. > > In addition a 6lowpan-translating daemon has been implemented to > allow a linux PC to use a mote as an 802.15.4 interface. > > Shortcomings and missing features: > * 6lowpan payload is sent as Active Message payload. This means that > the 802.15.4 payload is prefixed with the 1-byte AM Type field. > * non-zero Traffic Class and Flow Label are not supported by the > current HC1 implementation > * UDP port numbers compression is not supported and port numbers are > always sent in full by the current HC_UDP implementation > * Neighbor Discovery has not been implemented and link local > broadcasts are used instead. > * Not all fragments of a datagram seem to be always received by the > mote. A workaround is to add a usleep(10000) before sending subsequent > fragments in the daemon on the PC. > > More details can be found in my MSc Thesis > http://www.eecs.iu-bremen.de/users/harvan/docs/msc-thesis.pdf > > Source code is available from > http://www.eecs.iu-bremen.de/users/harvan/files/6lowpan.tar.gz > Matus, This is great news. The TinyOS net2 working group would love to get this into the TinyOS distribution. Omprakash Gnawali (USC) is the chair, you should contact him if you're interested. Recently, net2 has been focused on a binary dissemination protocol, but its future agenda is focused on pulling in new protocols, such as a ZigBee stack and a DYMO implementation. Have you taken a look at TEP 125? Jonathan Hui, David Moss, and I proposed introducing a new frame format for TinyOS (the I-Frame) which would allow it to exist along side a 6lowpan network without causing packet confusion. To some degree, we were waiting for a solid 6lowpan implementation before pushing this forward. The 2.0.2 release is slated for early July. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 23 17:27:01 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqyMD-0003DL-3H; Wed, 23 May 2007 17:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqyMB-0003D5-Qd for 6lowpan@ietf.org; Wed, 23 May 2007 17:26:55 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqyMA-0007T1-Ge for 6lowpan@ietf.org; Wed, 23 May 2007 17:26:55 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71AA082A38; Wed, 23 May 2007 23:26:53 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20120-04; Wed, 23 May 2007 23:26:48 +0200 (CEST) Received: from bike-planet (p5489f17a.dip.t-dialin.net [84.137.241.122]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTP id 78CA082A0B; Wed, 23 May 2007 23:26:48 +0200 (CEST) Received: by bike-planet (Postfix, from userid 1000) id 8486732895; Wed, 23 May 2007 23:26:47 +0200 (CEST) Date: Wed, 23 May 2007 23:26:47 +0200 From: Matus Harvan To: Philip Levis Subject: Re: [6lowpan] 6lowpan implementation for TinyOS 2.0 Message-ID: <20070523212647.GB21143@iu-bremen.de> References: <20070523185251.GA16770@bike-planet.students.iu-bremen.de> <4654971D.400@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4654971D.400@cs.stanford.edu> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 6lowpan@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Wed, May 23, 2007 at 12:33:49PM -0700, Philip Levis wrote: > Have you taken a look at TEP 125? Jonathan Hui, David Moss, and I > proposed introducing a new frame format for TinyOS (the I-Frame) which > would allow it to exist along side a 6lowpan network without causing > packet confusion. Yes, TEP 125 promises the implementation of an I-Frame to show up soon in tinyos-2.x/tos/chips/cc2420. I was hoping that this would allow me to use the whole 802.15.4 payload once it shows up without having to change things in tinyos-2.x/tos/chips/cc2420 or at least minimize the necessary changes. Hence, I have not tried to implement something myself. > To some degree, we were waiting for a solid 6lowpan > implementation before pushing this forward. The 2.0.2 release is slated > for early July. If an I-Frame implementation would make it easier to get rid of the AM Type field I'm happy to use it. I also have not optimized my buffers and structures heavily, but it may be then possible to directly embed something like a message_t in lowpan_pkt_t and use it instead of a uint8_t[102]. lowpan_pkt_t is a struct I am using to represent a packet. Matus _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 24 02:58:22 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr7HA-0004in-Op; Thu, 24 May 2007 02:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr7H9-0004iS-6x for 6lowpan@ietf.org; Thu, 24 May 2007 02:58:19 -0400 Received: from web81905.mail.mud.yahoo.com ([68.142.207.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hr7H8-0007jG-QY for 6lowpan@ietf.org; Thu, 24 May 2007 02:58:19 -0400 Received: (qmail 39963 invoked by uid 60001); 24 May 2007 06:58:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=LNOv3HmiK5NwlgWErsw6Iyg+QJpEMWjr50QnfGFX2TbWHLEnJJIQZgPxZIhX0R2JFyJ5w1E2MbmwJ7nopXxMGaBr8DtP0Oj9H70DDB4smb6VZJPLmbDUhFE6YBDEYrMwiM9MYtSTcp2H87nAfUw9ySUbMtaHlUSWWwlV/bGft2w=; X-YMail-OSG: beX4mhQVM1mPw9yQjiXIkarv5gT9TA5pXIY50MlceWEWLhIzs.xTsQxfeYhGry4cUmSfdRKJgllfdmMxzkYGB4FigKxCLjF5jgQlK7atrf7_n_5TieE- Received: from [24.16.90.95] by web81905.mail.mud.yahoo.com via HTTP; Wed, 23 May 2007 23:58:18 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Wed, 23 May 2007 23:58:18 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Dispatch value bit pattern for 6lowPAN To: Anthony Schoofs , 6lowpan <6lowpan@ietf.org>, geoff@mulligan.org MIME-Version: 1.0 Message-ID: <316749.37986.qm@web81905.mail.mud.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============0288566423==" Errors-To: 6lowpan-bounces@ietf.org --===============0288566423== Content-Type: multipart/alternative; boundary="0-2027334266-1179989898=:37986" --0-2027334266-1179989898=:37986 Content-Type: text/plain; charset=ascii Geoff as a Zigbee member tried to coordinate this with them. However, as I understand it, we were unable to obtain clear information even of this frame available to non-members, even if it was for the purpose of avoiding conflicts. That is why we ended up choosing the current value. Geoff? -gabriel ----- Original Message ---- From: Anthony Schoofs To: 6lowpan <6lowpan@ietf.org> Sent: Wednesday, May 23, 2007 7:31:02 AM Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN Dear all, In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Internet Draft, section Dispatch type and Header page 7, is mentionned that ".. other non-LowPAN protocols that wish to coexist with LowPAN nodes should include a byte matching this pattern (00 xxxxxx) ..". I had a look at the ZigBee network header and especially at the Frame Type sub-field (the 3 first bits after the 802.15.4 MAC header). For acknowledgement and command frames, the Frame Type value is either 010 or 011 (data frames start with 00). Consequently, it might happen that you get a match with a LoWPAN pattern, and then a problem of coexistence between LowPAN nodes and ZigBee nodes. I would like to know if this coexistence issue was raised before and if it is a matter for the 6LoWPAN WG. Best regards, Anthony -- Anthony Schoofs Philips Research High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Email: anthony.schoofs@philips.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-2027334266-1179989898=:37986 Content-Type: text/html; charset=ascii
Geoff as a Zigbee member tried to coordinate this with them. However, as I understand it, we were unable to obtain clear information even of this
frame available to non-members, even if it was for the purpose of avoiding conflicts. That is why we ended up choosing the current value.

Geoff?

-gabriel



----- Original Message ----
From: Anthony Schoofs <anthony.schoofs@philips.com>
To: 6lowpan <6lowpan@ietf.org>
Sent: Wednesday, May 23, 2007 7:31:02 AM
Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN


Dear all,

In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Internet Draft, section Dispatch type and Header page 7, is mentionned that  ".. other non-LowPAN protocols that wish to coexist with LowPAN nodes should include a byte matching this pattern (00 xxxxxx) ..".

I had a look at the ZigBee network header and especially at the Frame Type sub-field (the 3 first bits after the 802.15.4 MAC header).
For acknowledgement and command frames, the Frame Type value is either 010 or 011 (data frames start with 00).

Consequently, it might happen that you get a match with a LoWPAN pattern, and then a problem of coexistence between LowPAN nodes and ZigBee nodes.

I would like to know if this coexistence issue was raised before and if it is a matter for the 6LoWPAN WG.

Best regards,
Anthony

--
Anthony Schoofs
Philips Research
High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands
Email: anthony.schoofs@philips.com

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

--0-2027334266-1179989898=:37986-- --===============0288566423== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============0288566423==-- From 6lowpan-bounces@ietf.org Thu May 24 09:11:22 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrD69-0001Dh-K6; Thu, 24 May 2007 09:11:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrD68-0001DV-1A for 6lowpan@ietf.org; Thu, 24 May 2007 09:11:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrD66-0008CU-MN for 6lowpan@ietf.org; Thu, 24 May 2007 09:11:20 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 May 2007 09:11:19 -0400 X-IronPort-AV: i="4.14,573,1170651600"; d="scan'208"; a="121924806:sNHT47018754" 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 l4ODBIjV022057; Thu, 24 May 2007 09:11:18 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4ODBEBe013409; Thu, 24 May 2007 13:11:14 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 09:11:14 -0400 Received: from [10.83.1.100] ([10.83.1.100]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 09:11:13 -0400 Message-ID: <46558EF0.2040309@cisco.com> Date: Thu, 24 May 2007 15:11:12 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: 6lowpan@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 May 2007 13:11:13.0835 (UTC) FILETIME=[015E97B0:01C79E05] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3755; t=1180012278; x=1180876278; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=206lowpan=20rechartering |Sender:=20 |To:=206lowpan@ietf.org; bh=EBo84sC1tacHFZe3ji/gPFgAsICzbkMsTFckgi8hoZU=; b=hw3zheZLmARqNtAhjeNAExOVud16wcjbkbw3iPKreUJFogxq3NZo7jVWjpqA8V/fd/sEu8wa AULOMEgLKqMKdWuBk4oHaNT/1bG239Ue1jEdC7k8leAcc3x3s95UfIQp; Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 6lowpan-chairs@tools.ietf.org Subject: [6lowpan] 6lowpan rechartering X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Folks, I'd like the group to continue its work on rechartering. RSN is starting to work on the routing piece, and this group needs to formulate its charter in concert with this for the remaining items. Starting with what we have from the last meeting, I'll offer the group my thoughts on each as work items to start discussion. Please give your feedback now, I'd like for the chairs to be able to get a proposed charter together in time for Chicago. I copied text from http://www3.ietf.org/proceedings/07mar/slides/6lowpan-0.pdf > Charter 1/5 > > Produce “6lowpan Bootstrapping and 6lowpan IPv6 ND > Optimizations” to define the required optimizations to make > IPv6 ND applicable in 6lowpans, given the fact that IPv6 ND > is too expensive for the devices of 6lowpan and requires > multicast. This document will define how to bootstrap a > 6lowpan network and explore ND optimizations such as > reusing the 802.15.4 network structure (use the > coordinators), and obviate multicast by having devices talk > to coordinators without creating a single point-of-failure, and > changing the IPv6 ND multicast semantics. This document > will be a proposed standard. Bootstrapping and ND would seem to be related, but separate, work items (but feel free to convince me otherwise). I think this work item needs better scoping with respect to what "bootstrapping" really means. Also, it would be nice to get away from 802.15.4-specific jargon (e.g., you shouldn't have to be intimately familiar with 802.15.4 to understand what the work item is). > Charter 2/5 > > Produce “Problem Statement for Stateful Header > Compression in 6lowpans” to document the problem of > using stateful header compression (2507, ROHC) in > 6lowpans. Currently 6lowpan only specifies the use of > stateless header compression given the assumption that > stateful header compression may be too complex. This > document will determine if the assumption is correct and will > be an informational document. I see no problem documenting this informationally, I would hope that it wouldn't slow down PS work though. > > Charter 3/5 > > Produce “Recommendations for 6lowpan > Applications” to define a set of recommendations of > protocols to use for applications. The recommendations > will cover protocols for transport, application layer, > discovery, configuration and commissioning. This > document will be an informational document. This sounds more like an overall framework document. I wonder why Routing isn't listed here. > > Charter 4/5 > > Produce “6lowpan Mesh Routing” to evaluate different > mesh routing protocols for use within 6lowpans. While most > routing protocols are defined above the IP layer, 6lowpan > requires a mesh routing protocol below the IP layer. “6lowpan > Mesh Routing” may be several proposed standard > documents. Something to discuss with RSN so that we have a clear understanding of the goals of MAC vs. IP routing, whether we need to do both or not, how much of the mechanism could be shared if we do need both, etc. > > Charter 5/5 > > Produce “6lowpan Security Analysis” to define the threat > model of 6lowpans and to document suitability of existing > key management schemes and to discuss > bootstrapping/installation/commissioning/setup issues. This > document will be an informational document. Yes, and we will want to appoint a security adviser unless we already have an expert in the group. These Charter items, with some cleanup and tightening, seem like a reasonable start to me. I'd like to know what others in the group believe, and if we have editors and energy lined up for the tasks. Thanks, - Mark > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu May 24 12:00:55 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFkE-00025Y-Kt; Thu, 24 May 2007 12:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFkD-00025D-PC for 6lowpan@ietf.org; Thu, 24 May 2007 12:00:53 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrFkB-0002aE-Sh for 6lowpan@ietf.org; Thu, 24 May 2007 12:00:53 -0400 Received: by wa-out-1112.google.com with SMTP id m16so194030waf for <6lowpan@ietf.org>; Thu, 24 May 2007 09:00:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WIaV39H08DVkjrKuYF9y+lD2rZavfWmq6PUqjSbSL96HEYfV6Vf2+03Z4RNWyYHkwPeTHCxJIxbWSsUlcW16kvFo643Q1xEACvbf1oIMi7gzWVrRHTxXaEeMPcAqnfyIyqxiUV8ci0MYqs6hUnjU4GhxV/DyMu7JMddu6sCdPHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BcVj4lSnXvwz+y/+AH/xA6p4sfzDgFn7EnfzMy2utgQ13lzxYj9OpaHLlFEMlq+9z97yeJFsKikM3w5bzzRojL33RLhjMjalwo6sOVWVRQ+ywgf8sgOwdzbaTShhryN9An2kxEtN5OyzXfYAkxiqQsCc18jGpJE90vCPPs+MsgY= Received: by 10.114.103.1 with SMTP id a1mr966099wac.1180022449960; Thu, 24 May 2007 09:00:49 -0700 (PDT) Received: by 10.114.24.11 with HTTP; Thu, 24 May 2007 09:00:49 -0700 (PDT) Message-ID: Date: Fri, 25 May 2007 01:00:49 +0900 From: "Ki-Hyung Kim" To: "Mark Townsley" Subject: Re: [6lowpan] 6lowpan rechartering In-Reply-To: <46558EF0.2040309@cisco.com> MIME-Version: 1.0 References: <46558EF0.2040309@cisco.com> X-Spam-Score: 0.8 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: 6lowpan@ietf.org, 6lowpan-chairs@tools.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============1648736759==" Errors-To: 6lowpan-bounces@ietf.org --===============1648736759== Content-Type: multipart/alternative; boundary="----=_Part_130652_1471750.1180022449700" ------=_Part_130652_1471750.1180022449700 Content-Type: text/plain; charset=EUC-KR; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIE1hcmssClRoaXMgaXMgS2ktSHl1bmcgS2ltLiBJdCBpcyBhIGdyZWF0IG5ld3MgZnJvbSB5 b3UuCldlIGhhdmUgYmVlbiB3YWl0aW5nIGZvciB0aGlzIHN0YXJ0IG9mIHJlY2hhcnRlcmluZyBz byBsb25nIHRpbWUuCgpNeSBjb21tZW50cyBhcmUgaW4tbGluZS4KCgpPbiA1LzI0LzA3LCBNYXJr IFRvd25zbGV5IDx0b3duc2xleUBjaXNjby5jb20+IHdyb3RlOgoKPgo+IEZvbGtzLAo+Cj4gSSdk IGxpa2UgdGhlIGdyb3VwIHRvIGNvbnRpbnVlIGl0cyB3b3JrIG9uIHJlY2hhcnRlcmluZy4gUlNO IGlzIHN0YXJ0aW5nCj4gdG8gd29yayBvbiB0aGUgcm91dGluZyBwaWVjZSwgYW5kIHRoaXMgZ3Jv dXAgbmVlZHMgdG8gZm9ybXVsYXRlIGl0cwo+IGNoYXJ0ZXIgaW4gY29uY2VydCB3aXRoIHRoaXMg Zm9yIHRoZSByZW1haW5pbmcgaXRlbXMuCj4KPiBTdGFydGluZyB3aXRoIHdoYXQgd2UgaGF2ZSBm cm9tIHRoZSBsYXN0IG1lZXRpbmcsIEknbGwgb2ZmZXIgdGhlIGdyb3VwIG15Cj4gdGhvdWdodHMg b24gZWFjaCBhcyB3b3JrIGl0ZW1zIHRvIHN0YXJ0IGRpc2N1c3Npb24uIFBsZWFzZSBnaXZlIHlv dXIKPiBmZWVkYmFjayBub3csIEknZCBsaWtlIGZvciB0aGUgY2hhaXJzIHRvIGJlIGFibGUgdG8g Z2V0IGEgcHJvcG9zZWQKPiBjaGFydGVyIHRvZ2V0aGVyIGluIHRpbWUgZm9yIENoaWNhZ28uCj4K PiBJIGNvcGllZCB0ZXh0IGZyb20KPiBodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8w N21hci9zbGlkZXMvNmxvd3Bhbi0wLnBkZgo+Cj4gPiBDaGFydGVyIDEvNQo+ID4KPiA+IFByb2R1 Y2UgIjZsb3dwYW4gQm9vdHN0cmFwcGluZyBhbmQgNmxvd3BhbiBJUHY2IE5ECj4gPiBPcHRpbWl6 YXRpb25zIiB0byBkZWZpbmUgdGhlIHJlcXVpcmVkIG9wdGltaXphdGlvbnMgdG8gbWFrZQo+ID4g SVB2NiBORCBhcHBsaWNhYmxlIGluIDZsb3dwYW5zLCBnaXZlbiB0aGUgZmFjdCB0aGF0IElQdjYg TkQKPiA+IGlzIHRvbyBleHBlbnNpdmUgZm9yIHRoZSBkZXZpY2VzIG9mIDZsb3dwYW4gYW5kIHJl cXVpcmVzCj4gPiBtdWx0aWNhc3QuIFRoaXMgZG9jdW1lbnQgd2lsbCBkZWZpbmUgaG93IHRvIGJv b3RzdHJhcCBhCj4gPiA2bG93cGFuIG5ldHdvcmsgYW5kIGV4cGxvcmUgTkQgb3B0aW1pemF0aW9u cyBzdWNoIGFzCj4gPiByZXVzaW5nIHRoZSA4MDIuMTUuNCBuZXR3b3JrIHN0cnVjdHVyZSAodXNl IHRoZQo+ID4gY29vcmRpbmF0b3JzKSwgYW5kIG9idmlhdGUgbXVsdGljYXN0IGJ5IGhhdmluZyBk ZXZpY2VzIHRhbGsKPiA+IHRvIGNvb3JkaW5hdG9ycyB3aXRob3V0IGNyZWF0aW5nIGEgc2luZ2xl IHBvaW50LW9mLWZhaWx1cmUsIGFuZAo+ID4gY2hhbmdpbmcgdGhlIElQdjYgTkQgbXVsdGljYXN0 IHNlbWFudGljcy4gVGhpcyBkb2N1bWVudAo+ID4gd2lsbCBiZSBhIHByb3Bvc2VkIHN0YW5kYXJk Lgo+Cj4gQm9vdHN0cmFwcGluZyBhbmQgTkQgd291bGQgc2VlbSB0byBiZSByZWxhdGVkLCBidXQg c2VwYXJhdGUsIHdvcmsgaXRlbXMKPiAoYnV0IGZlZWwgZnJlZSB0byBjb252aW5jZSBtZSBvdGhl cndpc2UpLiBJIHRoaW5rIHRoaXMgd29yayBpdGVtIG5lZWRzCj4gYmV0dGVyIHNjb3Bpbmcgd2l0 aCByZXNwZWN0IHRvIHdoYXQgImJvb3RzdHJhcHBpbmciIHJlYWxseSBtZWFucy4gQWxzbywKPiBp dCB3b3VsZCBiZSBuaWNlIHRvIGdldCBhd2F5IGZyb20gODAyLjE1LjQtc3BlY2lmaWMgamFyZ29u IChlLmcuLCB5b3UKPiBzaG91bGRuJ3QgaGF2ZSB0byBiZSBpbnRpbWF0ZWx5IGZhbWlsaWFyIHdp dGggODAyLjE1LjQgdG8gdW5kZXJzdGFuZAo+IHdoYXQgdGhlIHdvcmsgaXRlbSBpcykuCgoKS2lt OiBZZXMsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBib290c3RyYXBwaW5nIGFuZCBORCBzaG91bGQg YmUgc2VwYXJhdGUKaXRlbXMsIGV2ZW4gdGhvdWdoIHRoZXkgYXJlIHJlbGF0ZWQuIEluIG9yZGVy IHRvIGdldCBpbnRlcm9wZXJhYmxlIDZsb3dwYW4KcHJvZHVjdHMsIHdlIHNob3VsZCBoYXZlIGEg Y29tbW9uIGJvb3RzdHJhcHBpbmcgcHJvdG9jb2wuIEEgc2Vuc29yIG5vZGUKc2hvdWxkIGludGVy LXdvcmsgd2l0aCBuZWlnaGJvcnMgYW5kIDZsb3dwYW4gcm91dGVycyB3aGVuIGl0IGJvb3RzIG9y IG1vdmVzCnRvIHRoZSBuZXcgNmxvd3BhbiByZWdpb24uCgoKCgo+ID4gQ2hhcnRlciAyLzUKPiA+ Cj4gPiBQcm9kdWNlICJQcm9ibGVtIFN0YXRlbWVudCBmb3IgU3RhdGVmdWwgSGVhZGVyCj4gPiBD b21wcmVzc2lvbiBpbiA2bG93cGFucyIgdG8gZG9jdW1lbnQgdGhlIHByb2JsZW0gb2YKPiA+IHVz aW5nIHN0YXRlZnVsIGhlYWRlciBjb21wcmVzc2lvbiAoMjUwNywgUk9IQykgaW4KPiA+IDZsb3dw YW5zLiBDdXJyZW50bHkgNmxvd3BhbiBvbmx5IHNwZWNpZmllcyB0aGUgdXNlIG9mCj4gPiBzdGF0 ZWxlc3MgaGVhZGVyIGNvbXByZXNzaW9uIGdpdmVuIHRoZSBhc3N1bXB0aW9uIHRoYXQKPiA+IHN0 YXRlZnVsIGhlYWRlciBjb21wcmVzc2lvbiBtYXkgYmUgdG9vIGNvbXBsZXguIFRoaXMKPiA+IGRv Y3VtZW50IHdpbGwgZGV0ZXJtaW5lIGlmIHRoZSBhc3N1bXB0aW9uIGlzIGNvcnJlY3QgYW5kIHdp bGwKPiA+IGJlIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuCj4KPiBJIHNlZSBubyBwcm9ibGVt IGRvY3VtZW50aW5nIHRoaXMgaW5mb3JtYXRpb25hbGx5LCBJIHdvdWxkIGhvcGUgdGhhdCBpdAo+ IHdvdWxkbid0IHNsb3cgZG93biBQUyB3b3JrIHRob3VnaC4KPgo+ID4KPiA+IENoYXJ0ZXIgMy81 Cj4gPgo+ID4gUHJvZHVjZSAiUmVjb21tZW5kYXRpb25zIGZvciA2bG93cGFuCj4gPiBBcHBsaWNh dGlvbnMiIHRvIGRlZmluZSBhIHNldCBvZiByZWNvbW1lbmRhdGlvbnMgb2YKPiA+IHByb3RvY29s cyB0byB1c2UgZm9yIGFwcGxpY2F0aW9ucy4gVGhlIHJlY29tbWVuZGF0aW9ucwo+ID4gd2lsbCBj b3ZlciBwcm90b2NvbHMgZm9yIHRyYW5zcG9ydCwgYXBwbGljYXRpb24gbGF5ZXIsCj4gPiBkaXNj b3ZlcnksIGNvbmZpZ3VyYXRpb24gYW5kIGNvbW1pc3Npb25pbmcuIFRoaXMKPiA+IGRvY3VtZW50 IHdpbGwgYmUgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudC4KPgo+IFRoaXMgc291bmRzIG1vcmUg bGlrZSBhbiBvdmVyYWxsIGZyYW1ld29yayBkb2N1bWVudC4gSSB3b25kZXIgd2h5Cj4gUm91dGlu ZyBpc24ndCBsaXN0ZWQgaGVyZS4KCgpLaW06IEkgdGhpbmsgdGhlIHRpdGxlIGFuZCB0aGUgZGV0 YWlscyBvZiB0aGlzIGl0ZW0gc2VlbSB0byBiZSBhIGxpdHRsZSBiaXQKb3V0IG9mIGZvY3VzLiBN eSBpZGVhIGlzIHRvIHNlcGFyYXRlIHRoaXMgaXRlbSBpbnRvIHRoZSBmb2xsb3dpbmcgdHdvIGl0 ZW1zLgooTXVjaCBvZiB0aGlzIGlkZWEgd2FzIGFscmVhZHkgZGlzY3Vzc2VkIHdpdGggR2VvZmYg YW5kIERhdmlkIEN1bGxlciBhdCB0aGUKbGFzdCBJRVRGIG1lZXRpbmcpCktpbTogRmlyc3QgaXRl bSBpcyBSZWNvbW1lbmRhdGlvbnMgZm9yIDZsb3dwYW4gQXBwbGljYXRpb25zIHdoaWNoIHN0YXRl cyBhbmQKY2xhc3NpZmllcyB0eXBpY2FsIDZsb3dwYW4gYXBwbGljYXRpb25zIGFuZCBwb3NzaWJs ZSBwcm90b2NvbCByZXF1aXJlbWVudHMKYW5kIGFkYXB0YXRpb25zIGZvciBlYWNoIG9mIHRoZW0u CgpLaW06IFNlY29uZCBpdGVtIGlzIDZsb3dwYW4gTmV0d29yayBBcmNoaXRlY3R1cmUgd2hpY2gg c3RhdGVzIHRoZQphcmNoaXRlY3R1cmUgb2YgdGhlIElQIG92ZXIgTG9XUEFOLiBJdCBzdGF0ZXMg cm91dGluZyBwcm90b2NvbHMgKE1lc2ggdW5kZXIKSVAsIFJvdXRlIG92ZXIgSVAsIG9yIGJvdGgg b2YgdGhlbSwgc2NhbGFibGUgcm91dGluZywgb3Igb3RoZXIgY2FuZGlkYXRlCnJvdXRpbmcgcHJv dG9jb2xzKSwgY29tbWlzc2lvbmluZywgYm9vdHN0cmFwcGluZywgTkQsIHJlbGlhYmxlIGFuZCBl ZmZpY2llbnQKZGVsaXZlcnkgb2YgcGFja2V0cyAob3IgZnJhZ21lbnRzKSwgY29uZmlndXJhdGlv biwgZGlzY292ZXJ5IG9mIG5ldHdvcmtzIGFuZApzZXJ2aWNlcyksIGFuZCBtb2JpbGl0eSBzdXBw b3J0LgoKCj4KPiBDaGFydGVyIDQvNQo+Cj4gUHJvZHVjZSAiNmxvd3BhbiBNZXNoIFJvdXRpbmci IHRvIGV2YWx1YXRlIGRpZmZlcmVudAo+IG1lc2ggcm91dGluZyBwcm90b2NvbHMgZm9yIHVzZSB3 aXRoaW4gNmxvd3BhbnMuIFdoaWxlIG1vc3QKPiByb3V0aW5nIHByb3RvY29scyBhcmUgZGVmaW5l ZCBhYm92ZSB0aGUgSVAgbGF5ZXIsIDZsb3dwYW4KPiByZXF1aXJlcyBhIG1lc2ggcm91dGluZyBw cm90b2NvbCBiZWxvdyB0aGUgSVAgbGF5ZXIuICI2bG93cGFuCj4gTWVzaCBSb3V0aW5nIiBtYXkg YmUgc2V2ZXJhbCBwcm9wb3NlZCBzdGFuZGFyZAo+IGRvY3VtZW50cy4KClNvbWV0aGluZyB0byBk aXNjdXNzIHdpdGggUlNOIHNvIHRoYXQgd2UgaGF2ZSBhIGNsZWFyIHVuZGVyc3RhbmRpbmcgb2YK dGhlIGdvYWxzIG9mIE1BQyB2cy4gSVAgcm91dGluZywgd2hldGhlciB3ZSBuZWVkIHRvIGRvIGJv dGggb3Igbm90LCBob3cKbXVjaCBvZiB0aGUgbWVjaGFuaXNtIGNvdWxkIGJlIHNoYXJlZCBpZiB3 ZSBkbyBuZWVkIGJvdGgsIGV0Yy4KCktpbTogSSB0aGluayB3ZSBuZWVkIHJvdXRpbmcgcHJvdG9j b2xzIHVuZGVybmVhdGggSVAsIHJlZ2FyZGxlc3Mgb2YgdGhlCmVmZm9ydHMgYXQgUlNOIChJIGFn cmVlIHdpdGggSlAgYW5kIERhdmlkIHRoYXQgaXQgaXMgdmFsdWFibGUgdG8gdHJ5IHRvIGZpbmQK cG9zc2libGUgcm91dGluZyBwcm90b2NvbHMgZm9yIHNlbnNvciBuZXR3b3JrcyBlc3BlY2lhbGx5 IG92ZXIgSVApLgpUaGlzIGlzIGJlY2F1c2Ugd2Ugd2lsbCBoYXZlIGxvdHMgb2YgNmxvd3BhbiBm cmFnbWVudHMgb2YgSVAgcGFja2V0cyAob2YKY291cnNlIGRlcGVuZGluZyBvbiB0aGUgYXBwbGlj YXRpb25zIGFuZCBwYWNrZXQgc2l6ZSkuIFRoZSBmcmFnbWVudHMgc2hvdWxkCmFueXdheSBiZSBy b3V0ZWQgdW5kZXJuZWF0aCBJUCBiZWNhdXNlIHRoZSBmcmFnbWVudHMgY2FuIG5vdCBiZSBzZWVu IGFib3ZlCklQLiBNZXNoIHJvdXRpbmcgcHJvdG9jb2wgaXMgb25lIG9mIHRoZSBjYW5kaWRhdGVz LCBhbmQgYSBzY2FsYWJsZSByb3V0aW5nCnByb3RvY29sIGNvdWxkIGJlIGFuIGFsdGVybmF0ZSBj aG9pY2UgZXNwZWNpYWxseSB3aGVuIGxvdHMgb2YgNmxvd3BhbiBub2RlcwphcmUgdG8gYmUgZGVw bG95ZWQgaW4gYSBuZXR3b3JrLCBpbiB0aGF0IGEgcm91dGluZyBwcm90b2NvbCBiYXNlZCBvbiB0 aGUKcm91dGluZyB0YWJsZSBvbiBzZW5zb3Igbm9kZXMgbWlnaHQgaW5jdXIgdG9vIG11Y2ggb3Zl cmhlYWQgdG8gbWFuYWdlCnJvdXRpbmcgdGFibGUgdXBkYXRlcy4KCgo+Cj4gQ2hhcnRlciA1LzUK Pgo+IFByb2R1Y2UgIjZsb3dwYW4gU2VjdXJpdHkgQW5hbHlzaXMiIHRvIGRlZmluZSB0aGUgdGhy ZWF0Cj4gbW9kZWwgb2YgNmxvd3BhbnMgYW5kIHRvIGRvY3VtZW50IHN1aXRhYmlsaXR5IG9mIGV4 aXN0aW5nCj4ga2V5IG1hbmFnZW1lbnQgc2NoZW1lcyBhbmQgdG8gZGlzY3Vzcwo+IGJvb3RzdHJh cHBpbmcvaW5zdGFsbGF0aW9uL2NvbW1pc3Npb25pbmcvc2V0dXAgaXNzdWVzLiBUaGlzCj4gZG9j dW1lbnQgd2lsbCBiZSBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LgoKWWVzLCBhbmQgd2Ugd2ls bCB3YW50IHRvIGFwcG9pbnQgYSBzZWN1cml0eSBhZHZpc2VyIHVubGVzcyB3ZSBhbHJlYWR5Cmhh dmUgYW4gZXhwZXJ0IGluIHRoZSBncm91cC4KClRoZXNlIENoYXJ0ZXIgaXRlbXMsIHdpdGggc29t ZSBjbGVhbnVwIGFuZCB0aWdodGVuaW5nLCBzZWVtIGxpa2UgYQpyZWFzb25hYmxlIHN0YXJ0IHRv IG1lLiBJJ2QgbGlrZSB0byBrbm93IHdoYXQgb3RoZXJzIGluIHRoZSBncm91cApiZWxpZXZlLCBh bmQgaWYgd2UgaGF2ZSBlZGl0b3JzIGFuZCBlbmVyZ3kgbGluZWQgdXAgZm9yIHRoZSB0YXNrcy4K CktpbTogT3ZlcmFsbCwgSSBob3BlIHdlIGNvdWxkIHN0YXJ0IG9mZiB0aGUgd29ya3Mgb24gUFMg YXMgd2VsbCBhcyB0aGUKaW5mb3JtYXRpb25hbCBkb2N1bWVudHMuClRoZSByb3V0aW5nIHByb3Rv Y29sIGNvdWxkIGJlIG9uZSBvZiB0aGVtLiBJbmRlZWQsIHRoZSBtYXJrZXQgaXMgd2FpdGluZyBm b3IKdGhlIDZsb3dwYW4gcHJvZHVjdHMuCldlIHNwZW50IHR3byBhbmQgaGFsZiB5ZWFycyBmb3Ig bWFraW5nIG9uZSBQUyBkb2N1bWVudC4gVGhhdCBpcyBqdXN0IHN0YXJ0Cm9mIHRoZSBhY3R1YWwg aW1wYWN0IG9uIHRoZSBtYXJrZXQuCldlIG5lZWQgdG8gZG8gc29tZSB3b3JrIGF0IGxlYXN0IHJv dXRpbmcgcHJvdG9jb2xzIEFTQVAgd2hpbGUgc3RhcnRpbmcgb2ZmCnRoZSBzZW5zb3Itb3AgdGVz dGluZyAoc2Vuc29yIG5ldHdvcmsgdmVyc2lvbiBvZiBpbnRlcm9wKS4KClRoYW5rcywKCi0gTWFy awo+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KNmxv d3BhbiBtYWlsaW5nIGxpc3QKNmxvd3BhbkBpZXRmLm9yZwpodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby82bG93cGFuCgoKCgotLSAKS2ktSHl1bmcgS2ltICix6LHix/wsINDd 0cP6+ykKQXNzb2NpYXRlIFByb2Zlc3NvcgpEaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBhbmQgQ29t cHV0ZXIgRW5nLiwgQWpvdSBVbml2ZXJzaXR5LCBTdXdvbiwgS29yZWEKNDQyLTc0OQpUZWw6ICs4 Mi0zMS0yMTktMjQzMywgQ2VsOiArODItMTctNzYwLTI1NTEsICBGYXg6ICs4Mi0zMS0yMTktMjQz MwpodHRwOi8vd3d3LjZsb3dwYW4ub3JnCg== ------=_Part_130652_1471750.1180022449700 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgTWFyaywgPC9kaXY+CjxkaXY+VGhpcyBpcyBLaS1IeXVuZyBLaW0uJm5ic3A7SXQg aXMgYSBncmVhdCBuZXdzIGZyb20geW91LjwvZGl2Pgo8ZGl2PldlIGhhdmUgYmVlbiB3YWl0aW5n IGZvciB0aGlzIHN0YXJ0IG9mIHJlY2hhcnRlcmluZyBzbyBsb25nIHRpbWUuPC9kaXY+CjxkaXY+ Jm5ic3A7PC9kaXY+CjxkaXY+TXkgY29tbWVudHMgYXJlIGluLWxpbmUuPC9kaXY+CjxkaXY+PGJy PiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNS8yNC8wNywg PGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPk1hcmsgVG93bnNsZXk8L2I+ICZsdDs8YSBocmVm PSJtYWlsdG86dG93bnNsZXlAY2lzY28uY29tIj50b3duc2xleUBjaXNjby5jb208L2E+Jmd0OyB3 cm90ZTo8L3NwYW4+PC9kaXY+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVG VDogI2NjYyAxcHggc29saWQiPjxicj5Gb2xrcyw8YnI+PGJyPkkmIzM5O2QgbGlrZSB0aGUgZ3Jv dXAgdG8gY29udGludWUgaXRzIHdvcmsgb24gcmVjaGFydGVyaW5nLiBSU04gaXMgc3RhcnRpbmc8 YnI+dG8gd29yayBvbiB0aGUgcm91dGluZyBwaWVjZSwgYW5kIHRoaXMgZ3JvdXAgbmVlZHMgdG8g Zm9ybXVsYXRlIGl0cwo8YnI+Y2hhcnRlciBpbiBjb25jZXJ0IHdpdGggdGhpcyBmb3IgdGhlIHJl bWFpbmluZyBpdGVtcy48YnI+PGJyPlN0YXJ0aW5nIHdpdGggd2hhdCB3ZSBoYXZlIGZyb20gdGhl IGxhc3QgbWVldGluZywgSSYjMzk7bGwgb2ZmZXIgdGhlIGdyb3VwIG15PGJyPnRob3VnaHRzIG9u IGVhY2ggYXMgd29yayBpdGVtcyB0byBzdGFydCBkaXNjdXNzaW9uLiBQbGVhc2UgZ2l2ZSB5b3Vy PGJyPmZlZWRiYWNrIG5vdywgSSYjMzk7ZCBsaWtlIGZvciB0aGUgY2hhaXJzIHRvIGJlIGFibGUg dG8gZ2V0IGEgcHJvcG9zZWQKPGJyPmNoYXJ0ZXIgdG9nZXRoZXIgaW4gdGltZSBmb3IgQ2hpY2Fn by48YnI+PGJyPkkgY29waWVkIHRleHQgZnJvbTxicj48YSBocmVmPSJodHRwOi8vd3d3My5pZXRm Lm9yZy9wcm9jZWVkaW5ncy8wN21hci9zbGlkZXMvNmxvd3Bhbi0wLnBkZiI+aHR0cDovL3d3dzMu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDdtYXIvc2xpZGVzLzZsb3dwYW4tMC5wZGY8L2E+PGJyPjxi cj4mZ3Q7IENoYXJ0ZXIgMS81Cjxicj4mZ3Q7PGJyPiZndDsgUHJvZHVjZSAiNmxvd3BhbiBCb290 c3RyYXBwaW5nIGFuZCA2bG93cGFuIElQdjYgTkQ8YnI+Jmd0OyBPcHRpbWl6YXRpb25zIiB0byBk ZWZpbmUgdGhlIHJlcXVpcmVkIG9wdGltaXphdGlvbnMgdG8gbWFrZTxicj4mZ3Q7IElQdjYgTkQg YXBwbGljYWJsZSBpbiA2bG93cGFucywgZ2l2ZW4gdGhlIGZhY3QgdGhhdCBJUHY2IE5EPGJyPiZn dDsgaXMgdG9vIGV4cGVuc2l2ZSBmb3IgdGhlIGRldmljZXMgb2YgNmxvd3BhbiBhbmQgcmVxdWly ZXMKPGJyPiZndDsgbXVsdGljYXN0LiBUaGlzIGRvY3VtZW50IHdpbGwgZGVmaW5lIGhvdyB0byBi b290c3RyYXAgYTxicj4mZ3Q7IDZsb3dwYW4gbmV0d29yayBhbmQgZXhwbG9yZSBORCBvcHRpbWl6 YXRpb25zIHN1Y2ggYXM8YnI+Jmd0OyByZXVzaW5nIHRoZSA4MDIuMTUuNCBuZXR3b3JrIHN0cnVj dHVyZSAodXNlIHRoZTxicj4mZ3Q7IGNvb3JkaW5hdG9ycyksIGFuZCBvYnZpYXRlIG11bHRpY2Fz dCBieSBoYXZpbmcgZGV2aWNlcyB0YWxrCjxicj4mZ3Q7IHRvIGNvb3JkaW5hdG9ycyB3aXRob3V0 IGNyZWF0aW5nIGEgc2luZ2xlIHBvaW50LW9mLWZhaWx1cmUsIGFuZDxicj4mZ3Q7IGNoYW5naW5n IHRoZSBJUHY2IE5EIG11bHRpY2FzdCBzZW1hbnRpY3MuIFRoaXMgZG9jdW1lbnQ8YnI+Jmd0OyB3 aWxsIGJlIGEgcHJvcG9zZWQgc3RhbmRhcmQuPGJyPjxicj5Cb290c3RyYXBwaW5nIGFuZCBORCB3 b3VsZCBzZWVtIHRvIGJlIHJlbGF0ZWQsIGJ1dCBzZXBhcmF0ZSwgd29yayBpdGVtcwo8YnI+KGJ1 dCBmZWVsIGZyZWUgdG8gY29udmluY2UgbWUgb3RoZXJ3aXNlKS4gSSB0aGluayB0aGlzIHdvcmsg aXRlbSBuZWVkczxicj5iZXR0ZXIgc2NvcGluZyB3aXRoIHJlc3BlY3QgdG8gd2hhdCAmcXVvdDti b290c3RyYXBwaW5nJnF1b3Q7IHJlYWxseSBtZWFucy4gQWxzbyw8YnI+aXQgd291bGQgYmUgbmlj ZSB0byBnZXQgYXdheSBmcm9tIDgwMi4xNS40LXNwZWNpZmljIGphcmdvbiAoCmUuZy4sIHlvdTxi cj5zaG91bGRuJiMzOTt0IGhhdmUgdG8gYmUgaW50aW1hdGVseSBmYW1pbGlhciB3aXRoIDgwMi4x NS40IHRvIHVuZGVyc3RhbmQ8YnI+d2hhdCB0aGUgd29yayBpdGVtIGlzKS48L2Jsb2NrcXVvdGU+ CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+S2ltOiBZZXMsIEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBi b290c3RyYXBwaW5nIGFuZCBORCBzaG91bGQgYmUgc2VwYXJhdGUgaXRlbXMsIGV2ZW4gdGhvdWdo IHRoZXkgYXJlIHJlbGF0ZWQuIEluIG9yZGVyIHRvJm5ic3A7Z2V0IGludGVyb3BlcmFibGUgNmxv d3BhbiBwcm9kdWN0cywgd2Ugc2hvdWxkIGhhdmUgYSBjb21tb24gYm9vdHN0cmFwcGluZyBwcm90 b2NvbC4gQSBzZW5zb3Igbm9kZSBzaG91bGQgaW50ZXItd29yayB3aXRoIG5laWdoYm9ycyBhbmQg Nmxvd3BhbiByb3V0ZXJzIHdoZW4gaXQgYm9vdHMgb3IgbW92ZXMgdG8gdGhlIG5ldyA2bG93cGFu IHJlZ2lvbi4KPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+PGJyPiZuYnNwOzwvZGl2Pgo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsg TUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4m Z3Q7IENoYXJ0ZXIgMi81PGJyPiZndDs8YnI+Jmd0OyBQcm9kdWNlICJQcm9ibGVtIFN0YXRlbWVu dCBmb3IgU3RhdGVmdWwgSGVhZGVyPGJyPiZndDsgQ29tcHJlc3Npb24gaW4gNmxvd3BhbnMiIHRv IGRvY3VtZW50IHRoZSBwcm9ibGVtIG9mCjxicj4mZ3Q7IHVzaW5nIHN0YXRlZnVsIGhlYWRlciBj b21wcmVzc2lvbiAoMjUwNywgUk9IQykgaW48YnI+Jmd0OyA2bG93cGFucy4gQ3VycmVudGx5IDZs b3dwYW4gb25seSBzcGVjaWZpZXMgdGhlIHVzZSBvZjxicj4mZ3Q7IHN0YXRlbGVzcyBoZWFkZXIg Y29tcHJlc3Npb24gZ2l2ZW4gdGhlIGFzc3VtcHRpb24gdGhhdDxicj4mZ3Q7IHN0YXRlZnVsIGhl YWRlciBjb21wcmVzc2lvbiBtYXkgYmUgdG9vIGNvbXBsZXguIFRoaXMKPGJyPiZndDsgZG9jdW1l bnQgd2lsbCBkZXRlcm1pbmUgaWYgdGhlIGFzc3VtcHRpb24gaXMgY29ycmVjdCBhbmQgd2lsbDxi cj4mZ3Q7IGJlIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQuPGJyPjxicj5JIHNlZSBubyBwcm9i bGVtIGRvY3VtZW50aW5nIHRoaXMgaW5mb3JtYXRpb25hbGx5LCBJIHdvdWxkIGhvcGUgdGhhdCBp dDxicj53b3VsZG4mIzM5O3Qgc2xvdyBkb3duIFBTIHdvcmsgdGhvdWdoLgo8YnI+PGJyPiZndDs8 YnI+Jmd0OyBDaGFydGVyIDMvNTxicj4mZ3Q7PGJyPiZndDsgUHJvZHVjZSAiUmVjb21tZW5kYXRp b25zIGZvciA2bG93cGFuPGJyPiZndDsgQXBwbGljYXRpb25zIiB0byBkZWZpbmUgYSBzZXQgb2Yg cmVjb21tZW5kYXRpb25zIG9mPGJyPiZndDsgcHJvdG9jb2xzIHRvIHVzZSBmb3IgYXBwbGljYXRp b25zLiBUaGUgcmVjb21tZW5kYXRpb25zPGJyPiZndDsgd2lsbCBjb3ZlciBwcm90b2NvbHMgZm9y IHRyYW5zcG9ydCwgYXBwbGljYXRpb24gbGF5ZXIsCjxicj4mZ3Q7IGRpc2NvdmVyeSwgY29uZmln dXJhdGlvbiBhbmQgY29tbWlzc2lvbmluZy4gVGhpczxicj4mZ3Q7IGRvY3VtZW50IHdpbGwgYmUg YW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudC48YnI+PGJyPlRoaXMgc291bmRzIG1vcmUgbGlrZSBh biBvdmVyYWxsIGZyYW1ld29yayBkb2N1bWVudC4gSSB3b25kZXIgd2h5PGJyPlJvdXRpbmcgaXNu JiMzOTt0IGxpc3RlZCBoZXJlLjwvYmxvY2txdW90ZT4KCjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+ S2ltOiBJIHRoaW5rIHRoZSB0aXRsZSBhbmQgdGhlIGRldGFpbHMgb2YgdGhpcyBpdGVtIHNlZW0g dG8gYmUgYSBsaXR0bGUgYml0IG91dCBvZiBmb2N1cy4gTXkgaWRlYSBpcyB0byBzZXBhcmF0ZSB0 aGlzIGl0ZW0gaW50byB0aGUgZm9sbG93aW5nIHR3byBpdGVtcy4gKE11Y2ggb2YgdGhpcyBpZGVh IHdhcyBhbHJlYWR5IGRpc2N1c3NlZCB3aXRoIEdlb2ZmIGFuZCBEYXZpZCBDdWxsZXIgYXQgdGhl IGxhc3QgSUVURiBtZWV0aW5nKQo8L2Rpdj4KPGRpdj5LaW06IEZpcnN0IGl0ZW0gaXMgUmVjb21t ZW5kYXRpb25zIGZvciA2bG93cGFuIEFwcGxpY2F0aW9ucyB3aGljaCBzdGF0ZXMgYW5kIGNsYXNz aWZpZXMgdHlwaWNhbCA2bG93cGFuIGFwcGxpY2F0aW9ucyBhbmQgcG9zc2libGUgcHJvdG9jb2wg cmVxdWlyZW1lbnRzIGFuZCBhZGFwdGF0aW9ucyBmb3IgZWFjaCBvZiB0aGVtLjwvZGl2Pgo8ZGl2 PiZuYnNwOzwvZGl2Pgo8ZGl2PktpbTogU2Vjb25kIGl0ZW0gaXMgNmxvd3BhbiBOZXR3b3JrIEFy Y2hpdGVjdHVyZSB3aGljaCBzdGF0ZXMmbmJzcDt0aGUgYXJjaGl0ZWN0dXJlIG9mIHRoZSBJUCBv dmVyIExvV1BBTi4gSXQgc3RhdGVzIHJvdXRpbmcgcHJvdG9jb2xzIChNZXNoIHVuZGVyIElQLCBS b3V0ZSBvdmVyIElQLCBvciBib3RoIG9mIHRoZW0sIHNjYWxhYmxlIHJvdXRpbmcsIG9yIG90aGVy IGNhbmRpZGF0ZSByb3V0aW5nIHByb3RvY29scyksIGNvbW1pc3Npb25pbmcsIGJvb3RzdHJhcHBp bmcsIE5ELCByZWxpYWJsZSBhbmQgZWZmaWNpZW50IGRlbGl2ZXJ5IG9mIHBhY2tldHMgKG9yIGZy YWdtZW50cyksIGNvbmZpZ3VyYXRpb24sIGRpc2NvdmVyeSBvZiBuZXR3b3JrcyBhbmQgc2Vydmlj ZXMpLCBhbmQmbmJzcDttb2JpbGl0eSBzdXBwb3J0Lgo8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4K PGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4mZ3Q7PGJyPiZndDsgQ2hhcnRlciA0LzU8YnI+Jmd0Ozxi cj4mZ3Q7IFByb2R1Y2UgIjZsb3dwYW4gTWVzaCBSb3V0aW5nIiB0byBldmFsdWF0ZSBkaWZmZXJl bnQ8YnI+Jmd0OyBtZXNoIHJvdXRpbmcgcHJvdG9jb2xzIGZvciB1c2Ugd2l0aGluIDZsb3dwYW5z LiBXaGlsZSBtb3N0PGJyPiZndDsgcm91dGluZyBwcm90b2NvbHMgYXJlIGRlZmluZWQgYWJvdmUg dGhlIElQIGxheWVyLCA2bG93cGFuCjxicj4mZ3Q7IHJlcXVpcmVzIGEgbWVzaCByb3V0aW5nIHBy b3RvY29sIGJlbG93IHRoZSBJUCBsYXllci4gIjZsb3dwYW48YnI+Jmd0OyBNZXNoIFJvdXRpbmci IG1heSBiZSBzZXZlcmFsIHByb3Bvc2VkIHN0YW5kYXJkPGJyPiZndDsgZG9jdW1lbnRzLjxicj48 YnI+U29tZXRoaW5nIHRvIGRpc2N1c3Mgd2l0aCBSU04gc28gdGhhdCB3ZSBoYXZlIGEgY2xlYXIg dW5kZXJzdGFuZGluZyBvZgo8YnI+dGhlIGdvYWxzIG9mIE1BQyB2cy4gSVAgcm91dGluZywgd2hl dGhlciB3ZSBuZWVkIHRvIGRvIGJvdGggb3Igbm90LCBob3c8YnI+bXVjaCBvZiB0aGUgbWVjaGFu aXNtIGNvdWxkIGJlIHNoYXJlZCBpZiB3ZSBkbyBuZWVkIGJvdGgsIGV0Yy48L2Rpdj4KPGRpdj4m bmJzcDs8L2Rpdj4KPGRpdj5LaW06IEkgdGhpbmsgd2UgbmVlZCZuYnNwO3JvdXRpbmcgcHJvdG9j b2xzIHVuZGVybmVhdGggSVAsIHJlZ2FyZGxlc3Mgb2YgdGhlIGVmZm9ydHMgYXQgUlNOIChJIGFn cmVlIHdpdGggSlAgYW5kIERhdmlkIHRoYXQgaXQgaXMgdmFsdWFibGUgdG8mbmJzcDt0cnkgdG8g ZmluZCBwb3NzaWJsZSByb3V0aW5nIHByb3RvY29scyBmb3Igc2Vuc29yIG5ldHdvcmtzIGVzcGVj aWFsbHkgb3ZlciBJUCkuCjwvZGl2Pgo8ZGl2PlRoaXMgaXMgYmVjYXVzZSB3ZSB3aWxsIGhhdmUg bG90cyBvZiA2bG93cGFuIGZyYWdtZW50cyBvZiBJUCBwYWNrZXRzIChvZiBjb3Vyc2UgZGVwZW5k aW5nIG9uIHRoZSBhcHBsaWNhdGlvbnMgYW5kIHBhY2tldCBzaXplKS4gVGhlIGZyYWdtZW50cyBz aG91bGQgYW55d2F5IGJlIHJvdXRlZCB1bmRlcm5lYXRoIElQIGJlY2F1c2UgdGhlIGZyYWdtZW50 cyBjYW4gbm90IGJlIHNlZW4gYWJvdmUgSVAuIE1lc2ggcm91dGluZyBwcm90b2NvbCZuYnNwO2lz IG9uZSBvZiB0aGUgY2FuZGlkYXRlcywgYW5kIGEgc2NhbGFibGUgcm91dGluZyBwcm90b2NvbCBj b3VsZCBiZSBhbiBhbHRlcm5hdGUgY2hvaWNlIGVzcGVjaWFsbHkgd2hlbiBsb3RzIG9mIDZsb3dw YW4gbm9kZXMgYXJlIHRvIGJlIGRlcGxveWVkIGluIGEgbmV0d29yaywgaW4gdGhhdCBhIHJvdXRp bmcgcHJvdG9jb2wgYmFzZWQgb24gdGhlIHJvdXRpbmcgdGFibGUgb24gc2Vuc29yIG5vZGVzIG1p Z2h0IGluY3VyIHRvbyBtdWNoIG92ZXJoZWFkIHRvIG1hbmFnZSByb3V0aW5nIHRhYmxlIHVwZGF0 ZXMuIAo8L2Rpdj4KPGRpdj48YnI+PGJyPiZndDs8YnI+Jmd0OyBDaGFydGVyIDUvNTxicj4mZ3Q7 PGJyPiZndDsgUHJvZHVjZSAiNmxvd3BhbiBTZWN1cml0eSBBbmFseXNpcyIgdG8gZGVmaW5lIHRo ZSB0aHJlYXQ8YnI+Jmd0OyBtb2RlbCBvZiA2bG93cGFucyBhbmQgdG8gZG9jdW1lbnQgc3VpdGFi aWxpdHkgb2YgZXhpc3Rpbmc8YnI+Jmd0OyBrZXkgbWFuYWdlbWVudCBzY2hlbWVzIGFuZCB0byBk aXNjdXNzCjxicj4mZ3Q7IGJvb3RzdHJhcHBpbmcvaW5zdGFsbGF0aW9uL2NvbW1pc3Npb25pbmcv c2V0dXAgaXNzdWVzLiBUaGlzPGJyPiZndDsgZG9jdW1lbnQgd2lsbCBiZSBhbiBpbmZvcm1hdGlv bmFsIGRvY3VtZW50Ljxicj48YnI+WWVzLCBhbmQgd2Ugd2lsbCB3YW50IHRvIGFwcG9pbnQgYSBz ZWN1cml0eSBhZHZpc2VyIHVubGVzcyB3ZSBhbHJlYWR5PGJyPmhhdmUgYW4gZXhwZXJ0IGluIHRo ZSBncm91cC4KPGJyPjxicj5UaGVzZSBDaGFydGVyIGl0ZW1zLCB3aXRoIHNvbWUgY2xlYW51cCBh bmQgdGlnaHRlbmluZywgc2VlbSBsaWtlIGE8YnI+cmVhc29uYWJsZSBzdGFydCB0byBtZS4gSSYj Mzk7ZCBsaWtlIHRvIGtub3cgd2hhdCBvdGhlcnMgaW4gdGhlIGdyb3VwPGJyPmJlbGlldmUsIGFu ZCBpZiB3ZSBoYXZlIGVkaXRvcnMgYW5kIGVuZXJneSBsaW5lZCB1cCBmb3IgdGhlIHRhc2tzLjwv ZGl2PgoKPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5LaW06IE92ZXJhbGwsIEkgaG9wZSB3ZSBjb3Vs ZCBzdGFydCBvZmYgdGhlIHdvcmtzIG9uIFBTIGFzIHdlbGwgYXMgdGhlIGluZm9ybWF0aW9uYWwg ZG9jdW1lbnRzLjwvZGl2Pgo8ZGl2PlRoZSByb3V0aW5nIHByb3RvY29sIGNvdWxkIGJlIG9uZSBv ZiB0aGVtLiBJbmRlZWQsIHRoZSBtYXJrZXQgaXMgd2FpdGluZyBmb3IgdGhlIDZsb3dwYW4gcHJv ZHVjdHMuIDwvZGl2Pgo8ZGl2PldlIHNwZW50IHR3byBhbmQgaGFsZiB5ZWFycyBmb3IgbWFraW5n IG9uZSBQUyBkb2N1bWVudC4gVGhhdCBpcyBqdXN0Jm5ic3A7c3RhcnQgb2YgdGhlIGFjdHVhbCBp bXBhY3Qgb24gdGhlIG1hcmtldC48L2Rpdj4KPGRpdj5XZSBuZWVkIHRvIGRvIHNvbWUgd29yayBh dCBsZWFzdCByb3V0aW5nIHByb3RvY29scyBBU0FQIHdoaWxlJm5ic3A7c3RhcnRpbmcgb2ZmIHRo ZSBzZW5zb3Itb3AgdGVzdGluZyAoc2Vuc29yIG5ldHdvcmsgdmVyc2lvbiBvZiBpbnRlcm9wKS48 YnI+PGJyPlRoYW5rcyw8YnI+PGJyPi0gTWFyazxicj4mZ3Q7PGJyPjxicj48YnI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPGJyPjZsb3dwYW4gbWFpbGlu ZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzo2bG93cGFuQGlldGYub3JnIj42bG93cGFuQGlldGYu b3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by82bG93cGFuIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFu PC9hPjxicj4mbmJzcDs8L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPgo8YnI+LS0gPGJyPktpLUh5 dW5nIEtpbSAoseix4sf8LCDQ3dHD+vspPGJyPkFzc29jaWF0ZSBQcm9mZXNzb3I8YnI+RGl2aXNp b24gb2YgSW5mb3JtYXRpb24gYW5kIENvbXB1dGVyIEVuZy4sIEFqb3UgVW5pdmVyc2l0eSwgU3V3 b24sIEtvcmVhIDQ0Mi03NDk8YnI+VGVsOiArODItMzEtMjE5LTI0MzMsIENlbDogKzgyLTE3LTc2 MC0yNTUxLCZuYnNwOyZuYnNwO0ZheDogKzgyLTMxLTIxOS0yNDMzIDxhIGhyZWY9Imh0dHA6Ly93 d3cuNmxvd3Bhbi5vcmciPgpodHRwOi8vd3d3LjZsb3dwYW4ub3JnPC9hPiAK ------=_Part_130652_1471750.1180022449700-- --===============1648736759== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1648736759==-- From 6lowpan-bounces@ietf.org Sat May 26 19:34:52 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hs5ma-0002Oh-0N; Sat, 26 May 2007 19:34:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hs5mY-0002Oc-7C for 6lowpan@ietf.org; Sat, 26 May 2007 19:34:46 -0400 Received: from 66.237.74.130.ptr.us.xo.net ([66.237.74.130] helo=mail.dustnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hs5mX-0006m7-T5 for 6lowpan@ietf.org; Sat, 26 May 2007 19:34:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [6lowpan] Dispatch value bit pattern for 6lowPAN Date: Sat, 26 May 2007 16:34:44 -0700 Message-ID: <3D8BC6C339A9894C9955EF58D3722D65FBF18F@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Dispatch value bit pattern for 6lowPAN thread-index: AcedR7dQtQoMpS8STcqemWOVqsIJjwCokXBT References: From: "Kris Pister" To: "Anthony Schoofs" , "6lowpan" <6lowpan@ietf.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I don't understand why we care. There are hundreds if not thousands of = companies developing proprietary solutions with 15.4 radios that will = not conform with 6lowpan, zigbee, HART, or any other 15.4-based wireless = standard. Perhaps more importantly, the crc16 fcs is not sufficient to = guarantee the integrity of received frames - roughly one out of a = million will be corrupted in major ways but still bear a valid fcs. =20 So what are we hoping that these bits in the dispatch will do for us? = No matter how well we coordinate between standards, I guarantee that our = radios will receive the occasional bogus packet with a "correct" = dispatch byte and length. You can try to type-check the fields all you = want, but occasionally you will execute on a payload that is at least = partly pure noise. One alternative is to build extra redundancy into = the headers, but header compression moves us in the other direction: if = we do our job right we squeeze all of that redundancy out by design. =20 The simplest way to deal with this problem is to use a MAC layer MIC-32 = in conjunction with the fcs. If we build secure networks, we need that = anyway. If we want an "open" network with no security, then we can = define a default (semi-random) MAC-MIC key that all 6lowpan devices will = use. For most applications this reduces the probability of undetected = errors to an acceptably low level. The alternative is to have our motes periodically do unpredictable = things. This is fine in a one hour demo or a one month pilot, but is = generally frowned on in production. =20 ksjp ________________________________ From: Anthony Schoofs [mailto:anthony.schoofs@philips.com] Sent: Wed 5/23/2007 7:31 AM To: 6lowpan Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN Dear all,=20 In the "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" = Internet Draft, section Dispatch type and Header page 7, is mentionned = that ".. other non-LowPAN protocols that wish to coexist with LowPAN = nodes should include a byte matching this pattern (00 xxxxxx) ..".=20 I had a look at the ZigBee network header and especially at the Frame = Type sub-field (the 3 first bits after the 802.15.4 MAC header).=20 For acknowledgement and command frames, the Frame Type value is either = 010 or 011 (data frames start with 00).=20 Consequently, it might happen that you get a match with a LoWPAN = pattern, and then a problem of coexistence between LowPAN nodes and = ZigBee nodes.=20 I would like to know if this coexistence issue was raised before and if = it is a matter for the 6LoWPAN WG.=20 Best regards,=20 Anthony=20 -- Anthony Schoofs Philips Research High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Email: anthony.schoofs@philips.com=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon May 28 04:39:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsaky-000886-28; Mon, 28 May 2007 04:39:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsakx-00087v-2u for 6lowpan@ietf.org; Mon, 28 May 2007 04:39:11 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsakw-0001Gc-Pn for 6lowpan@ietf.org; Mon, 28 May 2007 04:39:11 -0400 Received: by wx-out-0506.google.com with SMTP id t5so1037612wxc for <6lowpan@ietf.org>; Mon, 28 May 2007 01:39:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; 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; b=gEw2rAYY5C8jbwnCpXI3kE4FXHi6umQ7Q6oEqEKoZqfeapiD66AFIr6KuoWGpli+t4YeYERKQ+XQA4QXVNn1TXy6rTVvJyu79JgDUhuNQ9MEF0MEvojKumNN+0Qi9t/hkbCOdTotzajbKMLgTHeaReli3PTNTTghtx32orprWeY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bK3fiLDSj8S4/hXv1ANGOFqRfb4YBqWw6vXi1VBP/DDmtjQz+rwlpzEMdLWvKJPiVFkN1x//BQQfzN9TveSZCzOM/Ci8Bxq/KVcOvLP8BBp4W6IwuUx/Pz8HmnTtWDK/QVSD8Lvp1PsjTbrwE/0olItamZl35qGZIc/S+GlX/Kw= Received: by 10.90.115.4 with SMTP id n4mr3670613agc.1180341550379; Mon, 28 May 2007 01:39:10 -0700 (PDT) Received: by 10.90.68.6 with HTTP; Mon, 28 May 2007 01:39:05 -0700 (PDT) Message-ID: <77f1dba80705280139w510719c5u5f6fd078e01b616a@mail.gmail.com> Date: Mon, 28 May 2007 17:39:05 +0900 From: "Eunsook \"Eunah\" Kim" To: "Ki-Hyung Kim" Subject: Re: [6lowpan] 6lowpan rechartering In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46558EF0.2040309@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: 6lowpan@ietf.org, 6lowpan-chairs@tools.ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi all, It's good that we resume the rechartering discussion. Comments are inline; > > > Charter 1/5 > > > > > > > Charter 2/5 > > > > > > > > > Charter 3/5 > > > > > > Produce "Recommendations for 6lowpan > > > Applications" to define a set of recommendations of > > > protocols to use for applications. The recommendations > > > will cover protocols for transport, application layer, > > > discovery, configuration and commissioning. This > > > document will be an informational document. > > > > This sounds more like an overall framework document. I wonder why > > Routing isn't listed here. > > Kim: I think the title and the details of this item seem to be a little bit > out of focus. My idea is to separate this item into the following two items. > (Much of this idea was already discussed with Geoff and David Culler at the > last IETF meeting) > Kim: First item is Recommendations for 6lowpan Applications which states and > classifies typical 6lowpan applications and possible protocol requirements > and adaptations for each of them. > > Kim: Second item is 6lowpan Network Architecture which states the > architecture of the IP over LoWPAN. It states routing protocols (Mesh under > IP, Route over IP, or both of them, scalable routing, or other candidate > routing protocols), commissioning, bootstrapping, ND, reliable and efficient > delivery of packets (or fragments), configuration, discovery of networks and > services), and mobility support. > > I agree that this work should be done by two steps; (1) 6lowpan applications. (2) 6lowpan architecture based on the considerations which are discussed in (1) However, I have a little bit different view about the scope of the architecture work(2). Although Architecture work is for drawing broad view of all necessary tech. for 6lowpan, I don't think Architecture should state all the technology. I don't believe we can make such a "giant" document. It may delay whole standard processing. IMHO, we'd better focus on showing what is covered in 6lowpan, instead of stating all technical solutions in one document. Please let me know if I misunderstand your point. > > > > Charter 4/5 > > > > Produce "6lowpan Mesh Routing" to evaluate different > > mesh routing protocols for use within 6lowpans. While most > > routing protocols are defined above the IP layer, 6lowpan > > requires a mesh routing protocol below the IP layer. "6lowpan > > Mesh Routing" may be several proposed standard > > documents. > > Something to discuss with RSN so that we have a clear understanding of > the goals of MAC vs. IP routing, whether we need to do both or not, how > much of the mechanism could be shared if we do need both, etc. > > Kim: I think we need routing protocols underneath IP, regardless of the > efforts at RSN (I agree with JP and David that it is valuable to try to find > possible routing protocols for sensor networks especially over IP). > This is because we will have lots of 6lowpan fragments of IP packets (of > course depending on the applications and packet size). The fragments should > anyway be routed underneath IP because the fragments can not be seen above > IP. Mesh routing protocol is one of the candidates, and a scalable routing > protocol could be an alternate choice especially when lots of 6lowpan nodes > are to be deployed in a network, in that a routing protocol based on the > routing table on sensor nodes might incur too much overhead to manage > routing table updates. > > We really need to clear this item. Do we want to do routing issues in 6lowpan? or do we just want to adapt routing protocol(s) from other WG? About the necessary of mesh under routing, I agree with KIM. RSN targets IP layer routing which covers all possible sensor networks, independently from L2/L1. 6lowpan specifically targets IEEE 802.15.4, and the short-term solution (before RSN builds up the powerful all-covered routing protocol for various sensor networks) for 6lowpan will surely be working on mesh-under routing; we can end up with adapting an existing one or designing a new protocol. The thing is that we need to study on this item in either case. I hope we can have a good discussion on rechartering before the next IETF. Best, - Eunsook Kim _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed May 30 19:24:20 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXWd-0005eo-IJ; Wed, 30 May 2007 19:24:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXWc-0005ee-Aw for 6lowpan@ietf.org; Wed, 30 May 2007 19:24:18 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtXWb-0003nf-3u for 6lowpan@ietf.org; Wed, 30 May 2007 19:24:18 -0400 Received: by wx-out-0506.google.com with SMTP id t5so1704346wxc for <6lowpan@ietf.org>; Wed, 30 May 2007 16:24:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=p/4YrJr1hCu3/GgTLWTWIMeni9nf/UKgPjMHghQpfTo8o0fdT79eBRiijZeiowf3s4h6q/swBt9hmQj8+gk3JtKSpQpwKvAULQMLj9JD46YSk2hkYMhnyFhv9fvDRszGIRroyzqS8V2OBA103GzV9ATD+V7ZXgA5+QhYfEDe9rU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=H84irxbMzGQERGEvMTdtAMRGFpBcSLcnBFVVHCBm8klVtC29KE/TT4EgFWNk8QyUdbKhwFtS01WFvgQmrSkaf9q8DQnWv8QjuTZdoQE5Y4HGIxPO08Bjdq5kqiEZYlk1ytGm1VLMv5xbX9YKSLmiIsvvKrW8cYYEMNN1ODACBco= Received: by 10.70.23.2 with SMTP id 2mr12868736wxw.1180567456915; Wed, 30 May 2007 16:24:16 -0700 (PDT) Received: by 10.70.49.15 with HTTP; Wed, 30 May 2007 16:24:16 -0700 (PDT) Message-ID: Date: Wed, 30 May 2007 16:24:16 -0700 From: "David Culler" To: 6lowpan@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [6lowpan] Feedback on 6LoWPAN tutorial X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============1278339307==" Errors-To: 6lowpan-bounces@ietf.org --===============1278339307== Content-Type: multipart/alternative; boundary="----=_Part_5201_32072982.1180567456882" ------=_Part_5201_32072982.1180567456882 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I would like to get feedback/corrections on a 6LoWPAN tutorial that I've put together with Jonathan Hui. The pdf is at http://www.archrock.com/downloads/resources/6LoWPAN-tutorial.pdf. Thanks in advance. ------=_Part_5201_32072982.1180567456882 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would like to get feedback/corrections on a 6LoWPAN tutorial that I've put together with Jonathan Hui.  The pdf is at http://www.archrock.com/downloads/resources/6LoWPAN-tutorial.pdf . 

Thanks in advance.
------=_Part_5201_32072982.1180567456882-- --===============1278339307== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1278339307==-- From 6lowpan-bounces@ietf.org Wed May 30 19:38:44 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXkX-0004Bj-Ul; Wed, 30 May 2007 19:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtXkV-0004Be-Td for 6lowpan@ietf.org; Wed, 30 May 2007 19:38:39 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtXkU-0006VJ-LV for 6lowpan@ietf.org; Wed, 30 May 2007 19:38:39 -0400 Received: by wx-out-0506.google.com with SMTP id t5so1706522wxc for <6lowpan@ietf.org>; Wed, 30 May 2007 16:38:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=QH9CUl/cTMQOcA1OP4h7nvhEAJHTy7a+QEXr0L1lhKCV2d4guwmm7pwbllAT1W8ySMwtbKOs7fPHR98TgMX0KEEs0BYS6KuLfHtiLe9n4FUu6hLEf4eQbGIpWOp5EVtBBqY21KHQMQro4Llx2Vt6q7ADO2XCARY3TFdweJNnMHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=n9KJpEIoT7Ye1YngdP6hiY9EQO0mysm2N4achkIGomCE57m4e70B2mY9ZFw0Jb2nA4KVGI034d/OF+Du5Gyih/UALJAB9jjcCppSTtPCcNEWXeTlsC/jZSjEavx7kzLhZLxDZl/hMnfdQmGr6TtWx/vZYCzK47zjUHQ+NmA3J4Y= Received: by 10.70.87.11 with SMTP id k11mr12830534wxb.1180568318458; Wed, 30 May 2007 16:38:38 -0700 (PDT) Received: by 10.70.49.15 with HTTP; Wed, 30 May 2007 16:38:38 -0700 (PDT) Message-ID: Date: Wed, 30 May 2007 16:38:38 -0700 From: "David Culler" To: 6lowpan@ietf.org, anthony.schoofs@philips.com Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============1282861146==" Errors-To: 6lowpan-bounces@ietf.org --===============1282861146== Content-Type: multipart/alternative; boundary="----=_Part_5281_27386111.1180568318419" ------=_Part_5281_27386111.1180568318419 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Anthony, There was a good bit of discussion on the partitioning of the dispatch field following the San Diego meeting. Many felt that ideally, the protocol identifier would have been carried in the 15.4 header, so we were back filling. There was discussion about utilizing only a small fraction of the initial dispatch address space, so there would be more room for coexistence with other protocols. There was not a lot of discussion about whether we could define the initial dispatch in such a way that it would provide backward-going coexistence pre-existing protocols, since none of the proprietary or industry forum protocols seemed to have considered leaving room for others to fit alongside. Perhaps the forward-going hope was that new efforts would at least live along side of 6LoWPAN and all the protocols built on top of it. ------=_Part_5281_27386111.1180568318419 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Anthony,
     There was a good bit of discussion on the partitioning of the dispatch field following the San Diego meeting.  Many felt that ideally, the protocol identifier would have been carried in the 15.4 header, so we were back filling.  There was discussion about utilizing only a small fraction of the initial dispatch address space, so there would be more room for coexistence with other protocols.  There was not a lot of discussion about whether we could define the initial dispatch in such a way that it would provide backward-going coexistence pre-existing protocols, since none of the proprietary or industry forum protocols seemed to have considered leaving room for others to fit alongside.  Perhaps the forward-going hope was that new efforts would at least live along side of 6LoWPAN and all the protocols built on top of it.


------=_Part_5281_27386111.1180568318419-- --===============1282861146== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1282861146==-- From 6lowpan-bounces@ietf.org Thu May 31 09:42:19 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htkuw-0002EU-F3; Thu, 31 May 2007 09:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htkuv-0002EP-LV for 6lowpan@ietf.org; Thu, 31 May 2007 09:42:17 -0400 Received: from mpls-relay-02.inet.qwest.net ([63.226.138.12]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Htkuu-0006Ui-3e for 6lowpan@ietf.org; Thu, 31 May 2007 09:42:17 -0400 Received: (qmail 34899 invoked by uid 0); 31 May 2007 13:35:34 -0000 Received: from unknown (HELO scorp01.corp.cmdinfo.com) (65.120.79.6) by mpls-relay-02.inet.qwest.net with SMTP; 31 May 2007 13:35:34 -0000 Date: Thu, 31 May 2007 09:37:03 -0400 Message-ID: <7158315D3917854D9AD5B36BFF8CD3F1E45F8C@scorp01.corp.cmdinfo.com> From: "Dave Green" To: "David Culler" , 6lowpan@ietf.org X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [6lowpan] Feedback on 6LoWPAN tutorial In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Feedback on 6LoWPAN tutorial Thread-index: AcejEeTGYBxalLy7Rl2ZiKhB6dkNcAAdKXbA References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============1388467873==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1388467873== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A388.C6C51C8B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A388.C6C51C8B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave:=20 =20 Regarding this statement in your 6LowPAN tutorial: The most highly sensitive networks use IP internally, but are completely disconnected from all other computers. =20 Best practice recommendation from Command Information to ensure your sensitive system is both physically and logically disconnected from other computers:=20 *Physical separation from outside networks is not a perfect security model as occasional accidental and malicious security breaches can happen when someone 'plugs in the wrong wire' * We also recommend a 'policy-based' model to give you logical separation from the 'I'nternet:=20 -Utilize encryption between all nodes of your systems and IPsec from any gateway to outside application controllers. -Address your network with RFC 4193 Unique Local Addresses (ULAs) -Firewall any gateways to outside, and do actual penetration testing to ensure your gateway has no openings =20 We recommend this for people doing building control, security, & process automation with BACNetIP and 6LowPAN type technologies.=20 =20 David Green VP of Research and Development | Command Information =20 13655 Dulles Technology Drive, Herndon, VA 20171 Office: 703.561.5937 | Mobile: +1-703-899-9663 2610:00F8::/32 =20 Green@Commandinformation.com =20 =20 =20 From: David Culler [mailto:david.culler@gmail.com]=20 Sent: Wednesday, May 30, 2007 7:24 PM To: 6lowpan@ietf.org Subject: [6lowpan] Feedback on 6LoWPAN tutorial =20 I would like to get feedback/corrections on a 6LoWPAN tutorial that I've put together with Jonathan Hui. The pdf is at http://www.archrock.com/downloads/resources/6LoWPAN-tutorial.pdf . =20 Thanks in advance. ------_=_NextPart_001_01C7A388.C6C51C8B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave:

 

Regarding this statement in your 6LowPAN tutorial: The = most highly sensitive networks use IP internally, but are completely disconnected = from all other computers.

 

Best practice recommendation from Command Information to ensure your = sensitive system is both physically and logically disconnected from other = computers:

*Physical separation from outside networks is not a perfect security model as = occasional accidental and malicious security breaches can happen when someone ‘plugs in = the wrong wire’

* We also recommend a ‘policy-based’ model to give you logical = separation from the ‘I’nternet:

-Utilize encryption between all nodes of your systems and IPsec from any gateway = to outside application controllers.

-Address your network with RFC 4193 Unique Local Addresses = (ULAs)

-Firewall any gateways to outside, and do actual penetration testing to ensure = your gateway has no openings

 

We recommend this for people doing building control, security, & = process automation with BACNetIP and 6LowPAN type technologies.

 

David Green

VP of Research and Development | Command = Information

13655 Dulles Technology Drive, Herndon, VA = 20171

Office: 703.561.5937 | = Mobile: +1-703-899-9663

2610:00F8::/32<= /a><= o:p>

Green@Commandinformation.com

 

 

From:= David = Culler [mailto:david.culler@gmail.com]
Sent: Wednesday, May 30, 2007 7:24 PM
To: 6lowpan@ietf.org
Subject: [6lowpan] Feedback on 6LoWPAN = tutorial

 

I would like to get feedback/corrections on a = 6LoWPAN tutorial that I've put together with Jonathan Hui.  The pdf is at = http://www.archrock.com/downloads/resources/6LoWPAN-tutorial.pdf . 

Thanks in advance.

------_=_NextPart_001_01C7A388.C6C51C8B-- --===============1388467873== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1388467873==-- From 6lowpan-bounces@ietf.org Thu May 31 12:26:31 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtnTq-0002cx-5m; Thu, 31 May 2007 12:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtnTo-0002Un-0u for 6lowpan@ietf.org; Thu, 31 May 2007 12:26:28 -0400 Received: from 66.237.74.130.ptr.us.xo.net ([66.237.74.130] helo=mail.dustnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtnTn-0002E3-9R for 6lowpan@ietf.org; Thu, 31 May 2007 12:26:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [6lowpan] Dispatch value bit pattern for 6lowPAN Date: Thu, 31 May 2007 09:26:25 -0700 Message-ID: <3D8BC6C339A9894C9955EF58D3722D6591257C@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Dispatch value bit pattern for 6lowPAN thread-index: AcejE6sm/JgGQ3hqSPa65vd1VHV7zQAhtxWg From: "Kris Pister" To: "David Culler" , <6lowpan@ietf.org>, X-Spam-Score: 0.1 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============0735112668==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0735112668== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A3A0.6F2F0185" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A3A0.6F2F0185 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David - nice tutorial. That's very helpful. =20 Regarding the dispatch discussion, I'm still concerned that this appears to be leading people to draw the wrong conclusions, or worse, carry forward the wrong assumptions. =20 Successful coexistence has nothing to do with the first two bits of the network header. Any implementations that make that assumption are doomed. Even if we could get the whole world to agree on dispatch values, those bits (and others) are still going to get flipped undetected every now and then between TX and RX. None of the proprietary protocols and international standards with which I've been associated have ignored the issue of coexistence. Quite the contrary, we've spent countless hours in discussion and debate on the topic. =20 The conclusion is that without a message integrity check above and beyond the 802.15.4 FCS, you're doomed. With the CRC16, you can probably get away with a 2 byte MIC, but 4 is safer and in any case that's what the 15.4 standard supports. So if you've got to have MIC, then coexistence is simple. We can choose a default 6lowPAN key (0x495056366F766572366C6F7750414E21 encodes "IPv6over6lowPAN" nicely in 128 bits :-) ), and unless someone intentionally uses that same key, then the chances of 6lowPAN networks having coexistence problems with SmartMesh or HART or sp100 (or zigbee with security turned on) are effectively zero. The only coexistence problems then are for people who *don't* use a MIC (e.g. zigbee with security turned off), and the problem is for them, not for us. Once the MAC layer has signed off on the MIC, then your network layer knows with confidence that this is in fact a valid packet, and *then* it can look at the first two bits of the network header and do its job. =20 This seems really simple and obvious to me. Am I missing something? =20 ksjp =20 Kristofer S.J.Pister, Founder & CTO Dust Networks, 30695 Huntwood Ave.=20 Hayward, CA 94544 510-548-DUST ________________________________ From: David Culler [mailto:david.culler@gmail.com]=20 Sent: Wednesday, May 30, 2007 4:39 PM To: 6lowpan@ietf.org; anthony.schoofs@philips.com Subject: [6lowpan] Dispatch value bit pattern for 6lowPAN =20 Anthony, There was a good bit of discussion on the partitioning of the dispatch field following the San Diego meeting. Many felt that ideally, the protocol identifier would have been carried in the 15.4 header, so we were back filling. There was discussion about utilizing only a small fraction of the initial dispatch address space, so there would be more room for coexistence with other protocols. There was not a lot of discussion about whether we could define the initial dispatch in such a way that it would provide backward-going coexistence pre-existing protocols, since none of the proprietary or industry forum protocols seemed to have considered leaving room for others to fit alongside. Perhaps the forward-going hope was that new efforts would at least live along side of 6LoWPAN and all the protocols built on top of it.=20 ------_=_NextPart_001_01C7A3A0.6F2F0185 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David – nice tutorial.  = That’s very helpful.

 

Regarding the dispatch discussion, = I’m still concerned that this appears to be leading people to draw the wrong conclusions, or worse, carry forward the wrong = assumptions.

 

Successful coexistence has nothing = to do with the first two bits of the network header.  Any implementations = that make that assumption are doomed.  Even if we could get the whole = world to agree on dispatch values, those bits (and others) are still going to get flipped undetected every now and then between TX and RX.  None of = the proprietary protocols and international standards with which I’ve = been associated have ignored the issue of coexistence.  Quite the = contrary, we’ve spent countless hours in discussion and debate on the = topic.

 

The conclusion is that without a = message integrity check above and beyond the 802.15.4 FCS, you’re doomed. =  With the CRC16, you can probably get away with a 2 byte MIC, but 4 is safer = and in any case that’s what the 15.4 standard supports.  So if = you’ve got to have MIC, then coexistence is simple.  We can choose a = default 6lowPAN key (0x495056366F766572366C6F7750414E21 encodes = “IPv6over6lowPAN” nicely in 128 bits J ), and unless someone intentionally uses that same key, = then the chances of 6lowPAN networks having coexistence problems with SmartMesh = or HART or sp100 (or zigbee with security turned on) are effectively zero. =  The only coexistence problems then are for people who *don’t* use a MIC (e.g. zigbee with security turned off), and the problem is for = them, not for us.

Once the MAC layer has signed off = on the MIC, then your network layer knows with confidence that this is in fact = a valid packet, and *then* it can = look at the first two bits of the network header and do its = job.

 

This seems really simple and = obvious to me.  Am I missing something?

 

ksjp

 

Kristofer S.J.Pister, = Founder & CTO

Dust Networks, 30695 Huntwood = Ave.
Hayward, CA 94544
510-548-DUST

From: David = Culler [mailto:david.culler@gmail.com]
Sent: Wednesday, May 30, = 2007 4:39 PM
To: 6lowpan@ietf.org; anthony.schoofs@philips.com
Subject: [6lowpan] = Dispatch value bit pattern for 6lowPAN

 

Anthony,
     There was a good bit of discussion on the = partitioning of the dispatch field following the San Diego meeting.  Many felt that ideally, = the protocol identifier would have been carried in the 15.4 header, so we = were back filling.  There was discussion about utilizing only a small = fraction of the initial dispatch address space, so there would be more room for = coexistence with other protocols.  There was not a lot of discussion about = whether we could define the initial dispatch in such a way that it would provide backward-going coexistence pre-existing protocols, since none of the proprietary or industry forum protocols seemed to have considered = leaving room for others to fit alongside.  Perhaps the forward-going hope was = that new efforts would at least live along side of 6LoWPAN and all the protocols = built on top of it.

------_=_NextPart_001_01C7A3A0.6F2F0185-- --===============0735112668== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============0735112668==-- From 6lowpan-bounces@ietf.org Thu May 31 12:45:42 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtnmP-0007xU-OZ; Thu, 31 May 2007 12:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtnmO-0007xJ-O5 for 6lowpan@ietf.org; Thu, 31 May 2007 12:45:40 -0400 Received: from web81914.mail.mud.yahoo.com ([68.142.207.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtnmO-0003jG-0h for 6lowpan@ietf.org; Thu, 31 May 2007 12:45:40 -0400 Received: (qmail 6954 invoked by uid 60001); 31 May 2007 16:45:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=d8VxOFhqZNdbEWFki7PaXzykkkvloAeXcJoY2CxbkfMNlJ7qGT00QufZcCaNnJjsvcluRxIZef4e3Z50UWFuDBAvBU5l4aaXefIYzB5fx9H5AoMhQUEYwdlfZQJQ45Haw/Tm7DQGNFvliOhaS5PbGbdlO/2NS+YNFb26WpEQCZc=; X-YMail-OSG: ANITgrgVM1lmgzk7ED56fuDCIXAXFxZjeVs_q9kDu1oBwQxdDmSZ6lhT2.KfqeA7NlEow2yXKZmIMPvjxWRg_OeqJjA_tUjYOGp3omTF29f5eTc- Received: from [24.16.90.95] by web81914.mail.mud.yahoo.com via HTTP; Thu, 31 May 2007 09:45:39 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Thu, 31 May 2007 09:45:39 -0700 (PDT) From: gabriel montenegro Subject: Re: [6lowpan] Dispatch value bit pattern for 6lowPAN To: Kris Pister , David Culler , 6lowpan@ietf.org, anthony.schoofs@philips.com MIME-Version: 1.0 Message-ID: <664352.5568.qm@web81914.mail.mud.yahoo.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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="===============1948869995==" Errors-To: 6lowpan-bounces@ietf.org --===============1948869995== Content-Type: multipart/alternative; boundary="0-1167019276-1180629939=:5568" --0-1167019276-1180629939=:5568 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On the conflict. When we discussed this, two arguments that were done were:= =0A- most deployment in the near and perhaps even far term were expected to= be private (i.e, not zigbee, not 6lowpan, completely uncoordinated).=0A I= do remember seeing such an analyst report, but can't remember details any = more.=0A- most (all?) deployments of 6lowpan were expected to use AES, so t= his conflict would be avoided in practical terms.=0A=0ABecause of arguments= like the above, I think there was not much motivation to try harder at coo= rdination with Zigbee. So I think your conclusion is in line=0Awith previou= s discussions. Having said that, I think your proposal of a 6lowpan default= key for AES makes sense for those deployments that don't actually =0Ause A= ES already. I still think it's not a very critical point as I'd expect most= deployments will have AES turned on. =0A=0AAt any rate, this might be an i= nteresting individual submission, perhaps you can write it up?=0A=0A=0A-gab= riel=0A=0A----- Original Message ----=0AFrom: Kris Pister =0ATo: David Culler ; 6lowpan@ietf.org; an= thony.schoofs@philips.com=0ASent: Thursday, May 31, 2007 9:26:25 AM=0ASubje= ct: RE: [6lowpan] Dispatch value bit pattern for 6lowPAN=0A=0A=0A=0A=0A =0A= =0A=0A =0A=0A =0A=0A =0A=0A =0A=0A =0A=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0ADavid =96 nice tutorial. Tha= t=92s=0Avery helpful.=0A =0A=0A =0A =0A=0ARegarding the dispatch discussio= n, I=92m=0Astill concerned that this appears to be leading people to draw t= he wrong=0Aconclusions, or worse, carry forward the wrong assumptions.=0A = =0A=0A =0A =0A=0ASuccessful coexistence has nothing to do=0Awith the first= two bits of the network header. Any implementations that=0Amake that assu= mption are doomed. Even if we could get the whole world to=0Aagree on disp= atch values, those bits (and others) are still going to get=0Aflipped undet= ected every now and then between TX and RX. None of the=0Aproprietary prot= ocols and international standards with which I=92ve been=0Aassociated have = ignored the issue of coexistence. Quite the contrary, we=92ve=0Aspent coun= tless hours in discussion and debate on the topic.=0A =0A=0A =0A =0A=0AThe= conclusion is that without a message=0Aintegrity check above and beyond th= e 802.15.4 FCS, you=92re doomed. With=0Athe CRC16, you can probably get aw= ay with a 2 byte MIC, but 4 is safer and in=0Aany case that=92s what the 15= .4 standard supports. So if you=92ve=0Agot to have MIC, then coexistence i= s simple. We can choose a default=0A6lowPAN key (0x495056366F766572366C6F7= 750414E21 encodes =93IPv6over6lowPAN=94=0Anicely in 128 bits J ), and unles= s someone intentionally uses that same key, then the=0Achances of 6lowPAN n= etworks having coexistence problems with SmartMesh or HART=0Aor sp100 (or z= igbee with security turned on) are effectively zero. The only=0Acoexistenc= e problems then are for people who *don=92t*=0Ause a MIC (e.g. zigbee with = security turned off), and the problem is for them,=0Anot for us.=0A =0A=0AO= nce the MAC layer has signed off on the=0AMIC, then your network layer know= s with confidence that this is in fact a valid=0Apacket, and *then* it can = look at=0Athe first two bits of the network header and do its job.=0A =0A= =0A =0A =0A=0AThis seems really simple and obvious to=0Ame. Am I missing = something?=0A =0A=0A =0A =0A=0Aksjp=0A =0A=0A =0A =0A=0A=0A=0AKristofer S= .J.Pister, Founder &=0ACTO=0A =0A=0ADust Networks, =0A30695 Huntwood Ave. = =0A=0AHayward, CA 94544=0A=0A510-548-DUST=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0AFrom: David Culler=0A[mailto:david.culler@gmail.com] =0A=0ASent= : Wednesday, May 30, 2007 4:39=0APM=0A=0ATo: 6lowpan@ietf.org;=0Aanthony.sc= hoofs@philips.com=0A=0ASubject: [6lowpan] Dispatch value=0Abit pattern for = 6lowPAN=0A =0A=0A=0A=0A=0A =0A =0A=0AAnthony,=0A=0A There was a good b= it of discussion on the partitioning of=0Athe dispatch field following the = San=0A Diego meeting. Many felt that ideally, the=0Aprotocol identifier w= ould have been carried in the 15.4 header, so we were back=0Afilling. Ther= e was discussion about utilizing only a small fraction of=0Athe initial dis= patch address space, so there would be more room for coexistence=0Awith oth= er protocols. There was not a lot of discussion about whether we=0Acould d= efine the initial dispatch in such a way that it would provide=0Abackward-g= oing coexistence pre-existing protocols, since none of the=0Aproprietary or= industry forum protocols seemed to have considered leaving room=0Afor othe= rs to fit alongside. Perhaps the forward-going hope was that new=0Aefforts= would at least live along side of 6LoWPAN and all the protocols built=0Aon= top of it. =0A=0A=0A=0A=0A =0A=0A=0A=0A=0A________________________________= _______________=0A6lowpan mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ie= tf.org/mailman/listinfo/6lowpan=0A=0A=0A=0A=0A --0-1167019276-1180629939=:5568 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On the conflict. When we discussed this, two arguments= that were done were:
- most deployment in the near and perhaps even far= term were expected to be private (i.e, not zigbee, not 6lowpan, completely= uncoordinated).
  I do remember seeing such an analyst report, but= can't remember details any more.
- most (all?) deployments of 6lowpan w= ere expected to use AES, so this conflict would be avoided in practical ter= ms.

Because of arguments like the above, I think there was not much = motivation to try harder at coordination with Zigbee. So I think your concl= usion is in line
with previous discussions. Having said that, I think yo= ur proposal of a 6lowpan default key for AES makes sense for those deployme= nts that don't actually
use AES already. I still think it's not a very critical point= as I'd expect most deployments will have AES turned on.

At any rat= e, this might be an interesting individual submission, perhaps you can writ= e it up?
=0A
-gabriel

----- Original Message ----
F= rom: Kris Pister <kpister@dustnetworks.com>
To: David Culler <d= avid.culler@gmail.com>; 6lowpan@ietf.org; anthony.schoofs@philips.comSent: Thursday, May 31, 2007 9:26:25 AM
Subject: RE: [6lowpan] Dispatch= value bit pattern for 6lowPAN

=0A=0A=0A =0A =0A=0A =0A=0A =0A=0A = =0A=0A =0A=0A =0A=0A =0A=0A=0A=0A=0A=0A
=0A=0A

David =96 nice tutorial.&= nbsp; That=92s=0Avery helpful.

=0A=0A

 

=0A=0ARegarding the di= spatch discussion, I=92m=0Astill concerned that this appears to be leading = people to draw the wrong=0Aconclusions, or worse, carry forward the wrong a= ssumptions.

=0A=0A

 

=0A=0A

Successful coexistence has nothing = to do=0Awith the first two bits of the network header.  Any implementa= tions that=0Amake that assumption are doomed.  Even if we could get th= e whole world to=0Aagree on dispatch values, those bits (and others) are st= ill going to get=0Aflipped undetected every now and then between TX and RX.=  None of the=0Aproprietary protocols and international standards with= which I=92ve been=0Aassociated have ignored the issue of coexistence. = ; Quite the contrary, we=92ve=0Aspent countless hours in discussion and deb= ate on the topic.

=0A=0A

 

=0A=0A

The conclusion is that withou= t a message=0Aintegrity check above and beyond the 802.15.4 FCS, you=92re d= oomed.  With=0Athe CRC16, you can probably get away with a 2 byte MIC,= but 4 is safer and in=0Aany case that=92s what the 15.4 standard supports.=   So if you=92ve=0Agot to have MIC, then coexistence is simple.  = We can choose a default=0A6lowPAN key (0x495056366F766572366C6F7750414E21 e= ncodes =93IPv6over6lowPAN=94=0Anicely in 128 bits J ), and unless someone intentionally uses that same key, then = the=0Achances of 6lowPAN networks having coexistence problems with SmartMes= h or HART=0Aor sp100 (or zigbee with security turned on) are effectively ze= ro.  The only=0Acoexistence problems then are for people who *don=92t*=0Ause a MIC (e.g. zigbee = with security turned off), and the problem is for them,=0Anot for us.

=0A=0A

Once the MAC layer has signed off on the=0AMIC, then your network laye= r knows with confidence that this is in fact a valid=0Apacket, and *then* it can look at=0Athe first = two bits of the network header and do its job.

=0A=0A

 

=0A=0A

= This seems really simple and obvious to=0Ame.  Am I missing something?=

=0A=0A

 

=0A=0A

ksjp

=0A=0A

 

=0A= =0A
=0A=0A

Kristofer S.J.Pister, Founder &=0ACTO

=0A=0A

= Dust Networks, =0A30695 Huntwood Ave.
=0AHayward, CA = 94544
=0A510-548-DUST

=0A=0A
=0A=0A
= =0A=0A
=0A=0A
=0A= =0A
=0A=0A

From: David Culler=0A[mailto:david= .culler@gmail.com]
=0ASent: Wednesday, May 30, 2007 4:39=0APM
=0ATo: 6lowpan@ietf.org;=0Aanthony.schoofs@philips.com
= =0ASubject: [6lowpan] Disp= atch value=0Abit pattern for 6lowPAN

=0A=0A
=0A=0A  

=0A=0A

= Anthony,
=0A     There w= as a good bit of discussion on the partitioning of=0Athe dispatch field fol= lowing the San=0A Diego meeting.  Many felt that ideally, the=0Aproto= col identifier would have been carried in the 15.4 header, so we were back= =0Afilling.  There was discussion about utilizing only a small fractio= n of=0Athe initial dispatch address space, so there would be more room for = coexistence=0Awith other protocols.  There was not a lot of discussion= about whether we=0Acould define the initial dispatch in such a way that it= would provide=0Abackward-going coexistence pre-existing protocols, since n= one of the=0Aproprietary or industry forum protocols seemed to have conside= red leaving room=0Afor others to fit alongside.  Perhaps the forward-g= oing hope was that new=0Aefforts would at least live along side of 6LoWPAN = and all the protocols built=0Aon top of it.
=0A
=0A =0A=0A

=0A=0A
_______________________________________________6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailma= n/listinfo/6lowpan

--0-1167019276-1180629939=:5568-- --===============1948869995== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1948869995==-- From 6lowpan-bounces@ietf.org Thu May 31 23:11:40 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtxY7-0002Mw-5q; Thu, 31 May 2007 23:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtxY5-0002MN-Sy for 6lowpan@ietf.org; Thu, 31 May 2007 23:11:33 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtxY4-0000Fg-J2 for 6lowpan@ietf.org; Thu, 31 May 2007 23:11:33 -0400 Received: by nz-out-0506.google.com with SMTP id z31so369711nzd for <6lowpan@ietf.org>; Thu, 31 May 2007 20:11:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:reply-to:to:references:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=MhQwU3ILcbg0Thf9bEtrUnWOxGSWTSfkRPB44Ib7qiY1WUyeKTO2pVEobkidhQMte1msgNrisiY9J9t0ZcWKflfLRm6+ebBOfN4mmwXCxqiFjBBL3/w+3T60fnDMa53FI2sRudCjaAyoMl4OI4IedAuBSPZuNIbhVtAccwn2Jus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:reply-to:to:references:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=GNW3BvLXx4+2d/ZU93cvoZdLnbcojedCi5DJS+4IP9nWBayWNIZ/lBeoV/sCJT16Kv2cAnsWB7PhZjowZCCWPGK10NT87Sf3GD7H47JqoRFmoym5exDoGfMDx2WBq43dG5CxGEpvFK6u/Qz5qevm5Q8KsRD8rcYqZYabuUdAoeE= Received: by 10.114.134.1 with SMTP id h1mr1367583wad.1180667491133; Thu, 31 May 2007 20:11:31 -0700 (PDT) Received: from hhw-cf98901ef08 ( [211.71.71.147]) by mx.google.com with ESMTP id v35sm550316wah.2007.05.31.20.11.25; Thu, 31 May 2007 20:11:30 -0700 (PDT) Date: Fri, 1 Jun 2007 11:10:12 +0800 From: "=?utf-8?B?6ZyN5a6P5Lyf?=" To: "=?utf-8?B?Nmxvd3BhbkBpZXRmLm9yZw==?=" <6lowpan@ietf.org> References: Message-ID: <200706011109397818216@gmail.com> X-mailer: Foxmail 6, 01, 102, 12 [cn] Mime-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [6lowpan] =?utf-8?q?CFP=5F3rd_International_Conference_on_Mobile?= =?utf-8?q?_Ad-hoc_and_Sensor_Networks_=28MSN=E2=80=9907=29?= X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xiaosongshu2000@gmail.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="===============1106159131==" Errors-To: 6lowpan-bounces@ietf.org --===============1106159131== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IENhbGwgZm9yIFBhcGVycw0KM3JkIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBNb2JpbGUg QWQtaG9jIGFuZCBTZW5zb3IgTmV0d29ya3MgKE1TTuKAmTA3KQ0KDQogIDEyIOKAkyAxNCBEZWNl bWJlciAyMDA3LCBCZWlqaW5nLCBDaGluYQ0KDQpodHRwOi8vY29uZmVyZW5jZS5ianR1LmVkdS5j bg0KDQpDT05GRVJFTkNFIFRPUElDUyANCg0KRm9sbG93aW5nIHRoZSBzdWNjZXNzIG9mIHRoZSBw YXN0IHR3byBjb25mZXJlbmNlcywgTVNO4oCZMDUgaW4gV3VoYW4sIENoaW5hIGFuZCBNU07igJkw NiBpbiBIb25nIEtvbmcsIE1TTuKAmTA3IHByb3ZpZGVzIGEgZm9ydW0gZm9yIHJlc2VhcmNoZXJz IGFuZCBwcmFjdGl0aW9uZXJzIHRvIGV4Y2hhbmdlIHJlc2VhcmNoIHJlc3VsdHMgYW5kIHNoYXJl IGRldmVsb3BtZW50IGV4cGVyaWVuY2VzLiBUb3BpY3Mgb2YgaW50ZXJlc3QgaW5jbHVkZSwgYnV0 IGFyZSBub3QgbGltaXRlZCB0bywgdGhlIGZvbGxvd2luZyBhcmVhcyBpbiBtb2JpbGUgYWQgaG9j IGFuZCBzZW5zb3IgbmV0d29ya3M6IA0KDQrigKIgTmV0d29yayBhcmNoaXRlY3R1cmUgYW5kIHBy b3RvY29scyANCg0K4oCiIFNvZnR3YXJlIHBsYXRmb3JtcyBhbmQgZGV2ZWxvcG1lbnQgdG9vbHMg DQoNCuKAoiBTZWxmLW9yZ2FuaXphdGlvbiBhbmQgc3luY2hyb25pemF0aW9uIA0KDQrigKIgUm91 dGluZyBhbmQgZGF0YSBkaXNzZW1pbmF0aW9uIA0KDQrigKIgRmFpbHVyZSByZXNpbGllbmNlIGFu ZCBmYXVsdCBpc29sYXRpb24gDQoNCuKAoiBFbmVyZ3kgTWFuYWdlbWVudCANCg0K4oCiIERhdGEs IGluZm9ybWF0aW9uLCBhbmQgc2lnbmFsIHByb2Nlc3NpbmcgDQoNCuKAoiBTZWN1cml0eSBhbmQg cHJpdmFjeSANCg0K4oCiIE5ldHdvcmsgcGxhbm5pbmcsIHByb3Zpc2lvbmluZywgYW5kIGRlcGxv eW1lbnQgDQoNCuKAoiBEZXZlbG9wbWVudHMgYW5kIGFwcGxpY2F0aW9ucyANCg0K4oCiIEludGVn cmF0aW9uIHdpdGggb3RoZXIgc3lzdGVtIA0KDQpQQVBFUiBTVUJNSVNTSU9OIA0KDQpNU04gaW52 aXRlcyBhdXRob3JzIHRvIHN1Ym1pdCBvcmlnaW5hbCBhbmQgdW5wdWJsaXNoZWQgd29yay4gU3Vi bWlzc2lvbnMgc2hvdWxkIGluY2x1ZGUgYW4gYWJzdHJhY3QsIGtleSB3b3JkcywgdGhlIGUtbWFp bCBhZGRyZXNzIG9mIHRoZSBjb3JyZXNwb25kaW5nIGF1dGhvciwgYW5kIG11c3Qgbm90IGV4Y2Vl ZCAxNSBwYWdlcywgaW5jbHVkaW5nIHRhYmxlcyBhbmQgZmlndXJlcywgd2l0aCBQREYsIFBvc3RT Y3JpcHQsIG9yIE1TV29yZCBmb3JtYXQuICBFbGVjdHJvbmljIHN1Ym1pc3Npb24gdGhyb3VnaCB0 aGUgc3VibWlzc2lvbiB3ZWJzaXRlIGlzIHN0cm9uZ2x5IGVuY291cmFnZWQuIFN1Ym1pc3Npb24g b2YgYSBwYXBlciBzaG91bGQgYmUgcmVnYXJkZWQgYXMgYW4gdW5kZXJ0YWtpbmcgdGhhdCwgc2hv dWxkIHRoZSBwYXBlciBiZSBhY2NlcHRlZCwgYXQgbGVhc3Qgb25lIG9mIHRoZSBhdXRob3JzIHdp bGwgcmVnaXN0ZXIgYW5kIGF0dGVuZCB0aGUgY29uZmVyZW5jZSB0byBwcmVzZW50IHRoZSB3b3Jr LiANCg0KUFJPQ0VFRElOR1MNClRoZSBjb25mZXJlbmNlIHByb2NlZWRpbmdzIHdpbGwgYmUgcHVi bGlzaGVkIGFzIFNwcmluZ2VyLUxOQ1Mgc2VyaWVzIChwZW5kaW5nKSBhbmQgZGlzdHJpYnV0ZWQg YXQgdGhlIGNvbmZlcmVuY2UuIE9uZSBCZXN0IFBhcGVyIGFuZCBvbmUgQmVzdCBTdHVkZW50IFBh cGVyIHdpbGwgYmUgc2VsZWN0ZWQgZm9yIGF3YXJkcy4gRWFjaCB3aW5uZXIgd2lsbCBiZSBwcmVz ZW50ZWQgYXQgdGhlIGNvbmZlcmVuY2Ugd2l0aCBhIGNlcnRpZmljYXRlIGFuZCBVUyQxMDAuDQpJ TVBPUlRBTlQgREFURVMgDQogDQoNCuKAoiAgU3VibWlzc2lvbiBkZWFkbGluZTogICAgICAgICAg ICAgICAgICAzMCBKdW5lLCAyMDA3DQoNCuKAoiAgTm90aWZpY2F0aW9uIG9mIGFjY2VwdGFuY2U6 ICAgICAgICAxIEF1Z3VzdCAyMDA3DQoNCuKAoiAgRmluYWwgTWFudXNjcmlwdCBkdWU6ICAgICAg ICAgICAgICAgICAxIFNlcHRlbWJlciAyMDA3DQoNCg0KDQpHZW5lcmFsIENvLUNoYWlycyANCkpp YW5ub25nIENhbywgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVuaXYuLCBISw0KRGF2ZSBKb2huc29u LCBSaWNlIFVuaXYuLCBVU0EgDQoNClByb2dyYW0gQ28tQ2hhaXJzIA0KSG9uZ2tlIFpoYW5nLCBC ZWlqaW5nIEppYW90b25nIFVuaXYuLCBDaGluYQ0KU3RlcGhlbiBPbGFyaXUsIE9sZCBEb21pbmlv biBVbml2LiwgVVNBDQoNClB1YmxpY2F0aW9uIENoYWlyIA0KWmhhbmcgTGluZywgVHNpbmdodWEg VW5pdi4sIENoaW5hDQoNCkxvY2FsIE9yZ2FuaXphdGlvbiBDaGFpciANCllhanVhbiBRaW4sIEJl aWppbmcgSmlhb3RvbmcgVW5pdi4sIENoaW5hDQoNClByb2dyYW0gQ29tbWl0dGVlIE1lbWJlcnMN ClBsZWFzZSBzZWUgTVNOJzA3IFdlYnNpdGUgZm9yIHRoZSBsaXN0IG9mIHByb2dyYW0gY29tbWl0 dGVlIG1lbWJlcnMNCg0KU3RlZXJpbmcgQ29tbWl0dGVlDQpYaWFvaHVhIEppYSAoQ2hhaXIpLCBD aXR5IFVuaXYuIG9mIEhvbmcgS29uZywgSEsNCkppYW5ub25nIENhbyAoQ28tQ2hhaXIpLCBIb25n IEtvbmcgUG9seXRlY2huaWMgVW5pdi4sIEhLDQpTYWphbCBLLiBEYXMsIFVuaXYuIG9mIFRleGFz IGF0IEFybGluZ3RvbiwgVVNBDQpJdmFuIFN0b2ptZW5vdmljLCBVbml2LiBvZiBPdHRhd2EsIENh bmFkYQ0KSmllIFd1LCBGbG9yaWRhIEF0YWxhbnRpYyBVbml2LiwgVVNBDQoNCldlYm1hc3RlciAN Ckhvbmd3ZWkgSHVvLCBCZWlqaW5nIEppYW90b25nIFVuaXYuLCBDaGluYSAoaHdodW9AYmp0dS5l ZHUuY24pIA0KDQp3ZWJzaXRlOiAgaHR0cDovL2NvbmZlcmVuY2UuYmp0dS5lZHUuY24NCg0K --===============1106159131== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1106159131==-- From 6lowpan-bounces@ietf.org Thu May 31 23:12:53 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtxZN-00052G-8H; Thu, 31 May 2007 23:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtxZL-000526-UI for 6lowpan@ietf.org; Thu, 31 May 2007 23:12:51 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtxZK-0000b4-Ft for 6lowpan@ietf.org; Thu, 31 May 2007 23:12:51 -0400 Received: by wa-out-1112.google.com with SMTP id m16so495369waf for <6lowpan@ietf.org>; Thu, 31 May 2007 20:12:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:reply-to:to:references:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=TMr0LowRVXRHcZ9GykNxqtMUHXLPsDhMc/5lvWgQ4wsqevIhY1pEoZ97KuWKV8SyUdoVejFttd3XvPxjpAyBqYp1fCuDh/3wSDXQTcdUIyjj2mdToQicnu4h+kRUmOI+s6sVHy32xVJ+EflIar5EJbwe4zWNg1LTvJB7nQu291E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:reply-to:to:references:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=VSk7CobTeb7+nxNdUFsJEcOEnaOhXPXjBlryVxeDlR8irf++EqoR5N1fTPIeZh2r3+4GdhSE7rCHDUtfVwjNkNQOVZvfmGpXgqoIM09+ePb3IzZrjG9aBlG2NVYPU3Qdaw1O9DDMGKSrQhY85MYSTYqgBAXpzQuvM7T3kMSr1Aw= Received: by 10.114.254.1 with SMTP id b1mr1366362wai.1180667568389; Thu, 31 May 2007 20:12:48 -0700 (PDT) Received: from hhw-cf98901ef08 ( [211.71.71.147]) by mx.google.com with ESMTP id m24sm542536waf.2007.05.31.20.11.19; Thu, 31 May 2007 20:12:47 -0700 (PDT) Date: Fri, 1 Jun 2007 11:11:14 +0800 From: "=?utf-8?B?6ZyN5a6P5Lyf?=" To: "=?utf-8?B?Nmxvd3BhbkBpZXRmLm9yZw==?=" <6lowpan@ietf.org> References: Message-ID: <200706011110572966127@gmail.com> X-mailer: Foxmail 6, 01, 102, 12 [cn] Mime-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [6lowpan] =?utf-8?q?CFP=5F3rd_International_Conference_on_Mobile?= =?utf-8?q?_Ad-hoc_and_Sensor_Networks_=28MSN=E2=80=9907=29?= X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: xiaosongshu2000@gmail.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="===============1359711467==" Errors-To: 6lowpan-bounces@ietf.org --===============1359711467== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IENhbGwgZm9yIFBhcGVycw0KM3JkIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBvbiBNb2JpbGUg QWQtaG9jIGFuZCBTZW5zb3IgTmV0d29ya3MgKE1TTuKAmTA3KQ0KDQogIDEyIOKAkyAxNCBEZWNl bWJlciAyMDA3LCBCZWlqaW5nLCBDaGluYQ0KDQpodHRwOi8vY29uZmVyZW5jZS5ianR1LmVkdS5j bg0KDQpDT05GRVJFTkNFIFRPUElDUyANCg0KRm9sbG93aW5nIHRoZSBzdWNjZXNzIG9mIHRoZSBw YXN0IHR3byBjb25mZXJlbmNlcywgTVNO4oCZMDUgaW4gV3VoYW4sIENoaW5hIGFuZCBNU07igJkw NiBpbiBIb25nIEtvbmcsIE1TTuKAmTA3IHByb3ZpZGVzIGEgZm9ydW0gZm9yIHJlc2VhcmNoZXJz IGFuZCBwcmFjdGl0aW9uZXJzIHRvIGV4Y2hhbmdlIHJlc2VhcmNoIHJlc3VsdHMgYW5kIHNoYXJl IGRldmVsb3BtZW50IGV4cGVyaWVuY2VzLiBUb3BpY3Mgb2YgaW50ZXJlc3QgaW5jbHVkZSwgYnV0 IGFyZSBub3QgbGltaXRlZCB0bywgdGhlIGZvbGxvd2luZyBhcmVhcyBpbiBtb2JpbGUgYWQgaG9j IGFuZCBzZW5zb3IgbmV0d29ya3M6IA0KDQrigKIgTmV0d29yayBhcmNoaXRlY3R1cmUgYW5kIHBy b3RvY29scyANCg0K4oCiIFNvZnR3YXJlIHBsYXRmb3JtcyBhbmQgZGV2ZWxvcG1lbnQgdG9vbHMg DQoNCuKAoiBTZWxmLW9yZ2FuaXphdGlvbiBhbmQgc3luY2hyb25pemF0aW9uIA0KDQrigKIgUm91 dGluZyBhbmQgZGF0YSBkaXNzZW1pbmF0aW9uIA0KDQrigKIgRmFpbHVyZSByZXNpbGllbmNlIGFu ZCBmYXVsdCBpc29sYXRpb24gDQoNCuKAoiBFbmVyZ3kgTWFuYWdlbWVudCANCg0K4oCiIERhdGEs IGluZm9ybWF0aW9uLCBhbmQgc2lnbmFsIHByb2Nlc3NpbmcgDQoNCuKAoiBTZWN1cml0eSBhbmQg cHJpdmFjeSANCg0K4oCiIE5ldHdvcmsgcGxhbm5pbmcsIHByb3Zpc2lvbmluZywgYW5kIGRlcGxv eW1lbnQgDQoNCuKAoiBEZXZlbG9wbWVudHMgYW5kIGFwcGxpY2F0aW9ucyANCg0K4oCiIEludGVn cmF0aW9uIHdpdGggb3RoZXIgc3lzdGVtIA0KDQpQQVBFUiBTVUJNSVNTSU9OIA0KDQpNU04gaW52 aXRlcyBhdXRob3JzIHRvIHN1Ym1pdCBvcmlnaW5hbCBhbmQgdW5wdWJsaXNoZWQgd29yay4gU3Vi bWlzc2lvbnMgc2hvdWxkIGluY2x1ZGUgYW4gYWJzdHJhY3QsIGtleSB3b3JkcywgdGhlIGUtbWFp bCBhZGRyZXNzIG9mIHRoZSBjb3JyZXNwb25kaW5nIGF1dGhvciwgYW5kIG11c3Qgbm90IGV4Y2Vl ZCAxNSBwYWdlcywgaW5jbHVkaW5nIHRhYmxlcyBhbmQgZmlndXJlcywgd2l0aCBQREYsIFBvc3RT Y3JpcHQsIG9yIE1TV29yZCBmb3JtYXQuICBFbGVjdHJvbmljIHN1Ym1pc3Npb24gdGhyb3VnaCB0 aGUgc3VibWlzc2lvbiB3ZWJzaXRlIGlzIHN0cm9uZ2x5IGVuY291cmFnZWQuIFN1Ym1pc3Npb24g b2YgYSBwYXBlciBzaG91bGQgYmUgcmVnYXJkZWQgYXMgYW4gdW5kZXJ0YWtpbmcgdGhhdCwgc2hv dWxkIHRoZSBwYXBlciBiZSBhY2NlcHRlZCwgYXQgbGVhc3Qgb25lIG9mIHRoZSBhdXRob3JzIHdp bGwgcmVnaXN0ZXIgYW5kIGF0dGVuZCB0aGUgY29uZmVyZW5jZSB0byBwcmVzZW50IHRoZSB3b3Jr LiANCg0KUFJPQ0VFRElOR1MNClRoZSBjb25mZXJlbmNlIHByb2NlZWRpbmdzIHdpbGwgYmUgcHVi bGlzaGVkIGFzIFNwcmluZ2VyLUxOQ1Mgc2VyaWVzIChwZW5kaW5nKSBhbmQgZGlzdHJpYnV0ZWQg YXQgdGhlIGNvbmZlcmVuY2UuIE9uZSBCZXN0IFBhcGVyIGFuZCBvbmUgQmVzdCBTdHVkZW50IFBh cGVyIHdpbGwgYmUgc2VsZWN0ZWQgZm9yIGF3YXJkcy4gRWFjaCB3aW5uZXIgd2lsbCBiZSBwcmVz ZW50ZWQgYXQgdGhlIGNvbmZlcmVuY2Ugd2l0aCBhIGNlcnRpZmljYXRlIGFuZCBVUyQxMDAuDQpJ TVBPUlRBTlQgREFURVMgDQogDQoNCuKAoiAgU3VibWlzc2lvbiBkZWFkbGluZTogICAgICAgICAg ICAgICAgICAzMCBKdW5lLCAyMDA3DQoNCuKAoiAgTm90aWZpY2F0aW9uIG9mIGFjY2VwdGFuY2U6 ICAgICAgICAxIEF1Z3VzdCAyMDA3DQoNCuKAoiAgRmluYWwgTWFudXNjcmlwdCBkdWU6ICAgICAg ICAgICAgICAgICAxIFNlcHRlbWJlciAyMDA3DQoNCg0KDQpHZW5lcmFsIENvLUNoYWlycyANCkpp YW5ub25nIENhbywgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVuaXYuLCBISw0KRGF2ZSBKb2huc29u LCBSaWNlIFVuaXYuLCBVU0EgDQoNClByb2dyYW0gQ28tQ2hhaXJzIA0KSG9uZ2tlIFpoYW5nLCBC ZWlqaW5nIEppYW90b25nIFVuaXYuLCBDaGluYQ0KU3RlcGhlbiBPbGFyaXUsIE9sZCBEb21pbmlv biBVbml2LiwgVVNBDQoNClB1YmxpY2F0aW9uIENoYWlyIA0KWmhhbmcgTGluZywgVHNpbmdodWEg VW5pdi4sIENoaW5hDQoNCkxvY2FsIE9yZ2FuaXphdGlvbiBDaGFpciANCllhanVhbiBRaW4sIEJl aWppbmcgSmlhb3RvbmcgVW5pdi4sIENoaW5hDQoNClByb2dyYW0gQ29tbWl0dGVlIE1lbWJlcnMN ClBsZWFzZSBzZWUgTVNOJzA3IFdlYnNpdGUgZm9yIHRoZSBsaXN0IG9mIHByb2dyYW0gY29tbWl0 dGVlIG1lbWJlcnMNCg0KU3RlZXJpbmcgQ29tbWl0dGVlDQpYaWFvaHVhIEppYSAoQ2hhaXIpLCBD aXR5IFVuaXYuIG9mIEhvbmcgS29uZywgSEsNCkppYW5ub25nIENhbyAoQ28tQ2hhaXIpLCBIb25n IEtvbmcgUG9seXRlY2huaWMgVW5pdi4sIEhLDQpTYWphbCBLLiBEYXMsIFVuaXYuIG9mIFRleGFz IGF0IEFybGluZ3RvbiwgVVNBDQpJdmFuIFN0b2ptZW5vdmljLCBVbml2LiBvZiBPdHRhd2EsIENh bmFkYQ0KSmllIFd1LCBGbG9yaWRhIEF0YWxhbnRpYyBVbml2LiwgVVNBDQoNCldlYm1hc3RlciAN Ckhvbmd3ZWkgSHVvLCBCZWlqaW5nIEppYW90b25nIFVuaXYuLCBDaGluYSAoaHdodW9AYmp0dS5l ZHUuY24pIA0KDQp3ZWJzaXRlOiAgaHR0cDovL2NvbmZlcmVuY2UuYmp0dS5lZHUuY24NCg0K --===============1359711467== 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://www1.ietf.org/mailman/listinfo/6lowpan --===============1359711467==--